Subscribe to the RSA blogs and podcasts for the latest posts and security updates!
At the European Identity and Cloud (EIC) Conference 2012 last week, I finally got what Craig Burton has been saying for some time now: “Baking your core competency into an open API is an economic imperative.” What brought it home for me was the presentation by 3Scale’s Steven Willmott, focusing on what he called “turning [...]
It’s this last point that I’d like to dive into. Our analysis of the data does not point to a flaw in the RSA algorithm itself but instead points to an important problem in cryptosystem implementations as a whole. In particular, good cryptography (including RSA’s) depends on proper implementation. The importance of proper implementation is critical and can not be overstated. Let me draw a simple analogy here.
The importance of visibility and collaboration in cryptography was confirmed recently by academic work exposing a flaw in AES. One August researchers from the University of Leuven, in association with Microsoft, announced the discovery of the first flaw in the AES algorithm. This flaw enables the decryption of AES-encrypted data if the key length is 128 bits. Any discovery of a flaw is significant, particularly in an algorithm as widely used as AES. But the flaw does not represent a significant liability for data encrypted with AES. Exploiting this vulnerability requires a very specific set of circumstances. So the more significant risks for data encrypted with AES continue to be key management issues related both to the strength and entropy of the key and to the protection of the key.
Recently we saw a major indictment of 111 individuals from an “identity theft operation” based in Queens, NY. I suppose we will learn more details as the prosecutors make their case, but from the original reads it looks more like a counterfeit credit card operation versus a full identity theft operation. One key difference between the two is someone using your identity to open new lines of credit as opposed to just capturing your card data and making a duplicate to go on a shopping spree.
The debate in Washington, DC over what the role of government should be to help improve our nation’s cyber security posture is in full swing as the U.S. Congress considers a range of policy approaches. Because cyber has emerged as a significant national and economic security problem, proposals range from handing the U.S. Department of Homeland Security new authority to regulate critical infrastructure to tasking the U.S. Securities and Exchange Commission to clarify corporate disclosure requirements for cyber security breaches.
Threat modeling isn’t all that’s required in engineering built-in security, not by a long shot. You need to have effective design principles to ensure security (threat modeling is one), effective secure coding practices and effective testing.
The PCI Security Standards Council released an updated Prioritized Approach document for PCI DSS 2.0 on May 31 with associated tools and change documentation. I posted about the version of this document made to address PCI DSS 1.2 in 2009, and many of my comments still carry forward with this version. But let me take a moment to refresh the content as more than two years have passed since the original post.
The PCI Security Standards Council announced on May 23 the new PCI Board of Advisors for 2011 and 2012. There are some familiar names on the list as some of these companies are in their third term on the board, and there are some new faces, namely RSA, the Security Division of EMC. I am the representative from RSA that will be participating on behalf of the company.
Interesting note from Visa yesterday. They have given non-US merchants an escape hatch for validating PCI DSS compliance annually if they meet four specific requirements.
The release of PCI DSS V2 is a welcome update, even though most of the changes from PCI DSS V1.2 are relatively minor. But there are a number of areas that PCI DSS has not addressed and that are critical to the security of credit card information. Some of these, such as the impact of virtualization and cloud, are already recognized as concerns. But at least one area has, at least as far as I know, not yet been put on the table for discussion. This area concerns best practices for protecting against increasingly sophisticated social engineering attacks. These attacks may attempt to steal credit card information directly. Or they may seek to install malware that can steal the information, such as through man-in-the-browser attacks.
