Have you ever tried to navigate the PCI website and gotten lost and confused?
Are you part of the 99% of companies that must traverse the PCI Compliance landscape as part of the “Self-Assessment” or “do-it-yourself” crowd?
Have you been overwhelmed by vendor claims of “PCI made easy” or “PCI Compliance in 10 minutes” or “PCI in a Box”?
Does it bother you that the answers to your questions are often tied to the product/solution the vendor is selling?
I’ll be honest – my first reaction when I heard about the SANS Consensus Audit Guidelines (CAG), was that our industry didn’t really need yet another framework or standard. But when I read them, I realized this was put together by experienced security professionals who all too often were successful on multiple occasions in breaking into systems during a penetration test at the same customer, or had to perform incident response for the same customer a third or fourth time.
For a field that loves statistics, computer security sure treats them casually. In order to get my humble BA in Psychology, I absorbed my share of course hours in statistics and testing methods, including a set of lectures based upon Darrell Huff's brilliant book, "How to Lie with Statistics" - which I highly recommend. It's fun easy reading satire - those lectures had the effect of making me hyper-skeptical about any large, round, number that's thrown my way.
I've been asked repeatedly for my opinion about the APT1 report, and every time I try to respond I find myself waffling. The reason is simple: I think the report is a good thing, a sign of deep dysfunction in security, a stimulant to information sharing, an indicator of failed foreign policy, a brilliant marketing maneuver and a bit of business as usual. It's hard to pull those together into a simple, "yes, it's a good thing!" answer.
According to a recent report, the U.S. Navy sees 110,000 cyber attacks every hour. In October, the world’s largest Internet search and advertising service warned thousands of users to beware of state-sponsored attacks.
SSL is one of the most commonly used protocols to provide encryption for a variety of different applications. As such, it has come under great scrutiny over the years. While SSL misconfiguration is commonplace, one of the more recent attacks against SSL is to steal the Certificate Authority (CA) certificate. (In a paper released in July 2012, NIST warned that this type of attack would increase). Access to this certificate allows the attacker to issue valid certificates, and in the case of a code-signing certificate, use it to sign malware. Malware executing with this level of trust increases the chances of successfully being installed on the system. Other CA certificates are used to generate website certificates used by attackers to impersonate secure access to a given website.
Whenever there is a new vulnerability in popular software found on users’ desktops, such as Java, Adobe Reader, Adobe Flash, or Mozilla Firefox, the media goes into a frenzy and a lot of articles are published on the topic (often not containing much useful information). The most recent case is a particularly nasty vulnerability affecting Oracle Java, which can be successfully exploited on Windows, OS X, and Linux. While this vulnerability is generating buzz, it’s not all that different from any other popular software in use on users’ desktops that contains a vulnerability. Additionally, there is likely a population of exploits for such software that has yet to be disclosed and is being bought and sold on the black market. In fact, journalist Brian Krebs interviewed the creator of the Blackhole exploit kit who stated, "he was surprised that someone would just leak such a reliable exploit, which he said would fetch at least $100,000 if sold privately in the criminal underground."
Furthermore, it has been known for some time that a Java applet can be used to trick clients into running a malicious payload. Functionality within the Social Engineering Toolkit (SET) allows you to construct a fake website and distribute such a payload. The difference is that the user will have to click "Allow" for this action to occur. While this will decrease the success rate of malware deployment using this method, it will work on Windows, OS X, and Linux.
You don't have to look very hard to find an article discussing password breaches. Recently, there was a lot of buzz around LinkedIn, LastFM, and eHarmony, three very large sites suffering from passwords being leaked to the public. This is not a new phenomenon (earlier this year everyone was all up in arms about the Zappos password breach), but one that continues to garner attention in the media.
However, what most journalists are saying about password breaches is likely different from what I am about to tell you -- it simply does not matter how strong your password is, how it is encrypted when stored by the provider, or how the transport layer is encrypted (e.g., SSL). Here's why:
Many websites today, primarily for performance reasons, are using traditional one-way hashing algorithms to store your passwords (such as MD5 or SHA1). This means you give the website a password, it computes a cryptographic hash and stores it in a database of some kind. The plaintext password should never be written to disk. The next time you login, the website computes the hash in the same manner and compares it to the value stored in the database.
This is all well and good, until someone obtains a copy of the password hashes. Obtaining the hashes, without any other protections, such as password salting, two or more users with the same password will have the same hash value. This allows attackers to generate very large databases of already-hashed passwords and make a comparison. Hardware on graphics processing units (GPU) can help accelerate the process. There are also websites that will provide hash-cracking services (submit the hash to a website and get the cleartext password in return). Several of these sites also use “Rainbow Tables,” a form of lookup tables which takes a bit longer, but allows for smaller tables. A ‘salt’ will help slow down this process, a little. Salts are a random string appended to the password such that user's passwords are different. However, sometimes developers implement salts incorrectly, and use the same salt for each user or store the salt where attackers can obtain it (or calculate it). Even if salts are implemented correctly, the processing power of GPUs can be used to crack the salted password hashes in more time, using even larger pre-computed password dictionaries than ones without a salt. What does all this mean? Likely, at least a few websites (internal to your organization or external) are storing your password using a hash that can be reversed in a relatively short timeframe, depending on the hash used and computing power of the attacker.