standards

Geeks.com, certified as “hacker-safe” by ScanAlert (McAfee), has been hacked.

From ComputerWeekly.com:

Reports say Geeks.com sent out a letter at the weekend to its customers, admitting that customer information, including names, addresses, telephone numbers, e-mail addresses, credit card numbers, expiration dates, and card verification numbers, may have fallen into the wrong hands.

As a comment in this article mentions, this incident once again highlights the issue of encrypting customer data. Not “only” to secure the customers creditcards but also to stay clear of lawsuits and other liability issues.

I think I read somewhere about this being a requirement for this kind of vendor/merchant:

3.2.2 Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions

Well well, this is yet another wake up call for those that are not yet handling their data the correct (secure) way.

Cheers,

so did a lot of serious security incidents.

During last week, we saw…

- The largest newspaper in Sweden get their e-mail systems hacked

Apparently, the intrusion was made by initally hacking the newspapers intranet (which was connected to the internet!) and once the attackers had access to the intranet users names and passwords, they just tried those against their webmail system. Apparently people use the same passwords in different systems The group claiming the hack was “Vuxna Förbannade Hackare” (In english: Mature Pissed-Off Hackers) and apparently it was motivated by the fact that the newspaper did not have any coverage of their previous attack on the TV channel TV3’s website.

During the past week the hackers has been releasing more and more internal details from Aftonbladet such as e-mails and user details for partner websites etc. and they have stated that they will continue until the newspaper admits that they have been hacked on the front page of the website.

- The Largest ISP in Sweden looses 2 weeks worth of e-mail for 300 000 customers

This was an OMFG experience. Apparently, according to the information now available, there had been no backups taken (or they had been corrupt), monitoring or maintenance of the affected systems since the 14 December. Telia are now offering 20£ vouchers (only usable in Telia stores) to all affected customers and are also going to handle more serious data losses on a case-by-case basis.

And why did this happen? Well, apparently the guy that was monitoring the systems quit. (Period.)

Nice way to follow routines and policies guys…

- A USB stick containing hundreds of pages of US NATO reports left in a library

Some of the material found had the classification “secret“, but this has not been verified by the newspaper reporting.

Apparently this information was left in one of Stockholms largest libraries on an unencrypted USB stick.. heh.. I mean, encrypted USB sticks are soooo hard to come by these days, so why use them?

This has also been reported on by “The Register“:

According to Swedish daily Aftonbladet, the stick contained material on NATO’s ISAF peace-keeping force in Afghanistan, as well as an intelligence report on the attempted assassination of Lebanon’s defense minister and the murder of Sri Lanka’s foreign minister.

Word of advise, do not trust anyone else with your data people

Cheers and good luck in this 20£ corporate voucher world!

… reported by Dan Shumow and Niels Ferguson about 4 months ago?

I did a quick post about it here after reading about it at Bruce Schneier’s blog.

The problem is that NSA submitted an elliptic curve algorithm for inclusion in a new NIST standard for random number generation which contains certain constant values whose origin is unknown. Might not sound as something important but as discovered earlier this could open up the possibility for a “secret key” which could allow for unlocking of encrypted data. The fact that NSA submitted this (much slower than the others) algorithm also helps stir up the crypto community.

Not much has since been reported on the issue, until yesterday (by Schneier again).

The big news is that the flawed PRNG is to be shipped with SP1 for Windows Vista. It is not going to be the default PRNG, but it is still going to be included as an option to developers.

Why is this a problem? Well,

First, you are damn sure going to have to look real close at any application you employ to secure your data as you are in the hands of the developers of the applications. More or less, you will have to request the source code if you really want to be sure, and even then it can be a real hassle to find any references to the offending algorithm.

Second. Why did they implement a flawed algorithm found by their own analysts? Yes, Dan Shumow and Niels Ferguson is employed by Microsoft. Specially as they have been urgently patching other PRNG flaws in their OS’s recently. Some say this is to meet the whole NIST standard, but come on, who would implement a crypto technology that is flawed. I mean, that kind of breaks the whole idea of cryptography in the first place.

Third, what if Microsoft issues a patch or security update which silently sets Dual_EC_DRBG to the default PRNG ? Then all your data could be read by “someone”. Do you trust MS? This leads me to the…

Final point. Who has the skeleton key? NSA? Microsoft? Someone else?

After my post mentioning the PCI DSS I got some questions like “PCI D..what?” and “What is that anyways? I’ve heard of it but never read anything about it”. Well, after reading this, you people should feel a bit enlightened. Hopefully, CISSPs and similar will not find this as new information, but you might enjoy the refresher. So, read on folks, this is gonna be a (…another) long one.

PCI DSS stands for “Payment Card Industry Data Security Standard” and it was created by the larger players in the credit card business to ensure that those little 1’s and 0’s, that usually reside on your physical magnetic-strip card, does not end up in the hands of a criminal.The first version of the standard was developed and agreed upon in late 2004 and was (still is) intended to provide guidance for organizations that transfer, store or process credit card information in computer security related issues. The first standard was revised in 2006 to make it more up-to-date and more relevant to the current situation.The use of the word “Guidance” is used a bit freely in the description according to me, as if a requirement in the standard is not met by the merchant he might lose his right to handle the kind of data described in the standard, effectively shutting down their business (this is not a bad thing, btw).Before the PCI DSS was widely agreed upon, many of the CC companies had their own standards and recommendations regarding data security, such as: CISP/AIS (Visa), SDP (MasterCard), DSOP (AmEx), I&C (Discover) and DSP (JSB). The above mentioned was also the primary participants in the discussion that later led to the standard. Most of these financial actors still have their own security programs but they have aligned them so that they all have the same objective, help merchants become PCI DSS standard compliant.

The PCI Data Security Standard consists of 12 topics in 6 different categories. These are called “control objectives” and are:

• Build and maintain a Secure Network
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• Protect Cardholder Data
  • Requirement 3: Protect stored cardholder data
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks
• Maintain a Vulnerability Management Program
  • Requirement 5: Use and regularly update anti-virus software
  • Requirement 6: Develop and maintain secure systems and applications
• Implement Strong Access Control Measures
  • Requirement 7: Restrict access to cardholder data by business need-to-know
  • Requirement 8: Assign a unique ID to each person with computer access
  • Requirement 9: Restrict physical access to cardholder data
• Regularly Monitor and Test Networks
  • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Requirement 11: Regularly test security systems and processes
• Maintain an Information Security Policy
  • Requirement 12: Maintain a policy that addresses information security

In order to verify whether or not the merchants/service providers are really compliant they have to undergo self-assessments, quarterly PCI Security Scans and possibly PCI Security Audits (Depending on the size and amount of sensitive information handled).

The PCI Security Scans are to be performed by a ASV (or, Approved Scanning Vendor) and is non-intrusive in their nature. This means that the scans should not interrupt day-to-day business or cause any damage to the systems evaluated. After one of these scans the ASV compiles a report detailing the different issues found, the associated risk (you will need a CISSP for this ) and also provide some guidance on how to remedy the issues. Every weakness found should also be categorised in a scale from one to five, five being worst case scenario. The PCI DSS considers level 3 to 5 as a failure to comply and a direct danger to cardholder data. This type of scans was the topic of discussion in the webinar that I based my previous related post on.

If you are a large merchant or service provider you might also be the subject of a PCI Security Audit which consists of a review of internal policies & documentation, internal penetration-testing & security evaluation and also interviews of selected personnel. This is done to actually verify that all guidelines in the PCI DSS has been implemented as they should.

One very interesting document regarding both types of audits was written in late 2006 by consultants from the German security company SRC. In that document (which contains a lot of good info) they listed the top 10 types of vulnerabilities found for both methods (internal/external). What’s very serious about the ones they listed are that they are very old. For example, I used one of them to compromise a network in 2002! This kind of vulnerability should not be present in any company that seriously tries to be secure. No matter the size. They are easily scanned for and can be exploited in under one minute. You can find the whole document here.

Other references on this subject:

PCI Security Standards

PCI Answers - This post was very interesting.

PCI Answers PCI Forum

PCI DSS News and Information

IT Governance PCI DSS information

Google…

That’s it for me now. If I’m mistaken about something or if someone has any questions please drop me a comment or an e-mail!

Cheers,

I’m not an advocate or fan of Microsofts technology, implementation of standards or politics. That’s for sure. However this is actually really interesting for us that are stuck in our corporate environment with Windows:

I was recently visiting a larger company in Sweden that is in the testing stage of a large deployment of Windows Vista. This deployment will be done on a pretty big userbase that has somewhat special security demands and for that reason they are following the SSLF (or SS-LF) baseline presented by Microsoft in the Windows Vista Security Guide. In that same guide you will also find information about a lighter security model called Enterprise Client (EC). The EC-baseline provides a more simple and less intrusive security baseline but it did not fill the requirements for this particular company.

I was quite impressed with the work they had done and how well it seems to have fallen out and decided to read up on these baselines. I mean, more security for Windows systems is not a bad thing and if you can do this easily then it would be great.

The definition of the two baselines in the Windows Vista Security Guide are:

• Enterprise Client (EC). Client computers in this environment are located in a domain that uses Active Directory and only need to communicate with systems running Windows Server 2003. The client computers in this environment include a mixture: some run Windows Vista whereas others run Windows XP….
• Specialized Security – Limited Functionality (SSLF). Concern for security in this environment is so great that a significant loss of functionality and manageability is acceptable. For example, military and intelligence agency computers operate in this type of environment. The client computers in this environment run only Windows Vista…”

The whole process of securing the clients are done via Active Directory group policies and the implementation of these can be very much simplified by using pre-made scripts (also included in the security guide).

The main downside for me with this policy (SSLF) is that it might cause a minor conflict with the brand new “Panda For Desktops” (formerly known as ClientShield) but there is an easy remedy for that particular problem. Guess why I was there btw hehe…

Here is a short list of resources for more information:

• Windows Vista Security Guide - The whole guide, including everything.
• Lou Bolanis blog with links related to SSLF - More interesting links.
  
• Technet Security Guidance Center - Security information regarding all MS products.

And as a bonus, the delicious, the enormously useful (as not many run on an SSLF baseline) but also quite CTO friendly:

• Fundamental Computer Investigation Guide for Windows

This should be an prerequisite for all administrators running a +100 user network. Sure would make my life a hell of a lot easier during intrusion investigations

Cheers and drive safe (winter in Sweden now) !

Bruce Schneier on one of the “Deterministic Random Bit Generators” supplied by the U.S. government:

“But today there’s an even bigger stink brewing around Dual_EC_DRBG. In an informal presentation (.pdf) at the CRYPTO 2007 conference in August, Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described a backdoor.”

To copy common phrasing of the author himself, This is a big deal.

Find the whole article here.

I downloaded and listened in on the web application security talk that Jeremiah Grossman (WhiteHat Security (coordinators of the talk), Robert “RSnake” Hansen (SecTheory), Chris Paggen (Cisco) and Jordan Wiens (Network Computing) had. This was an unscripted roundtable discussion and it was very interesting to me, as I’m not so skilled in the areas that they discussed (getting there, more on that in later posts). Full info on the talk can be found at:

http://jeremiahgrossman.blogspot.com/2007/11/live-online-roundtable-episode-1.html

For me, the part of the talk dealing with WAF’s (web application firewalls) and normalization of input was quite interesting. As discussed, there really is no good way to do it if the customer or developer do not know they way his server and webapps handles input (and output for that matter) and which features are needed. However, if there is good documentation of the webapp that is to be protected, you might get away with some normalization (and then why not do it). WAF’s in general is not something you “just plug in” and some more fine tuning will most likely be needed if normalization is something that you want to do.

Another thing that i thought was actually more interesting, was hearing these people that are specialists on web security discuss the PCI DSS and what their experience and comments on it were.

One good thing with the PCI DSS is that for an CTO/Administrator/Security engineer that is really dedicated to providing good security for his company and it’s clients, the standard can be used to push up security budgets and raise awareness in upper-management. However, the money will also have to be well spent, and that’s where some of the participants see a problem.

That problem is that companys and departments with dedicated budgets will try to hold down costs, sometimes even if they have the money needed for a thorough security solution, all for increased profit. This in turn might lead them to cheaper and less reliable certified scanners and vulnerability testers, that might not find holes where there actually are plenty. What does this lead to? Well, not much for those trying to fill the PCI’s requirements, as they will still pass (AND with no problems detected, wohooo). The cost, as usual, ends up with the customer that gets his or hers creditcard-data stolen from the site.

An update on this were posted by RSnake (one of the participants) on the 11/11-07.

Another topic regarding the PCI DSS that was discussed was it’s unclarity in certain paragraphs that might lead to total or partial circumvention of the upholding of the standard. No comments regarding this but it does indeed sound pretty serious if that’s the case

More information on the PCI DSS here. And I also recommend you all to visit the link in the top of this post and listen to the whole webinar.

Cheers,