“My software is secure, I use encryption!” How many times have we, software security practitioners, heard this when engaging with software development teams?
I certainly have, and this is typically followed by a barrage of questions to the development team that signifies that they are about to enter a tumultuous zone:
- Which algorithm have you implemented? What key size?
- Where do you store the encryption key? How do you change it?
- Which implementation of the encryption algorithm did you use?
Many security practitioners, including software developers, forget that encryption is a means and not an end. Obviously, software security assurance is much broader than encryption, but even in the area of implementing encryption in applications, the framework I outlined in my previous post applies. Making good use of encryption in software development touches all aspects of software security assurance:
- Policy and Standard: Software developers need to be told which algorithms, key length, key handling and other practices are prescribed by the security organization for use in the product or application that they develop. Furthermore, the standard needs to keep up with the latest advances in cryptography and in cryptanalysis in order to phase out weaker or broken algorithms. In our EMC Product Security Policy, 15 out of the 80 requirements are related to encryption and key or certificate management.
- People: Developing awareness among the software engineering community about the best practices for using cryptography is critical. Education of software developers on the appropriate use of cryptography should not be limited to reviewing internal standards, but should explain why developers should not invent their own cryptographic algorithms and should explain the legal ramifications of implementing encryption in software. Restrictions around the world on export and use of encryption algorithms often influence design decisions that software developers make. At EMC, we review encryption requirements in our general security engineering awareness training. We also have a specialized training module for software engineers that have to actually implement encryption in their code.
- Process: The software development process must provide the framework for making the right decisions about implementing encryption:
- First, during requirement definition, identifying where the software will be used and any other specific constraints that may influence the implementation of encryption
- Then, during software design, performing threat modeling not only ensures that encryption is used to address the intended threats, but also validates that encryption is implemented properly. An example that perfectly illustrates this point relates to the requirement for encrypting stored Personally Identifiable Information (PII). Encrypting data as part of the storage layer will prevent PII disclosure if the storage device is physically stolen, but not if an attacker takes control of the host where the software is running. For the latter, you need to implement strong authentication and access control within the application.
Another important consideration to be made during the design of the software relates to its maintainability. The software is likely to live longer than the algorithm performing encryption. Designing the ability to replace the encryption algorithm in the software is always a good investment.
-
- Finally during software development and testing, encryption implementation needs to be reviewed and fully tested.
At EMC, we have made these practices part of our standard security development lifecycle.
- Technology: Choosing the right encryption algorithm is not sufficient, unless you use a proven implementation of that algorithm. Critical considerations that need to be applied in selecting an implementation of a cryptographic algorithm include the provider’s expertise and trustworthiness, performance of the implementation and the availability of external certification such as FIPS 140. At EMC, we are lucky enough to have RSA as part of the EMC family, so the FIPS 140 validated RSA BSAFE cryptographic libraries are available to all EMC developers.
- Customer Operations: Locking the house does not do any good, if you leave the key in the mailbox. Likewise, organizations that use applications with embedded encryption should always consider the practices required to ensure the proper deployment of their solution, with a special focus on the process for changing and archiving keys (key management). At EMC, many of our products that implement encryption give specific guidelines in security configuration guides or in white papers about such practices. Several of our products providing data at rest encryption also interface with external key management platforms such as RSA Key Manager.
If you follow all these steps, you will still be unable to claim your software is totally secure, but you can be more confident your implementation of encryption does not create a false sense of security to your internal or external customers.
