Wednesday, April 10, 2013

An Iceberg of Software Security


What is software security? What makes one software product more secure than another? Is it a set of security features that it supports? Or is it a number of security tests that it passes?  Or maybe it's a set of best practices that it follows? The answer is none of the above and all of them together plus more. For example, is a product that implements a two-factor authentication more secure than the one that only relies on one factor? In theory, yes, but in practice it depends on the correctness of the implementation of each feature. A security feature without a proper design, implementation, testing, and correct usage does not automatically make a product secure. True software security is much more complex than a set of features, tests, or documents. It is defined by a complex interaction of multiple factors, with every single one of them being essential. At the end, security is usually measured not by how much of it was done correctly, but by how much was actually missed and compromised as a result.

That's why software security is hard and requires a systematic approach with continuous execution. In my experience in working on software security, I find that different groups of people usually care about or emphasize different aspects of software security. Depending on a situation, prioritizing one security aspect over another might make sense, but in order to evaluate an overall security of a product, generally, they all need to be considered together. More specifically, I believe that there are four main areas that need to be addressed in order to build secure software that can also can be deployed and used securely:
  1. a security stance
  2. secure software 
  3. security features
  4. security documentation 
Having a security stance means to have a clear story about a product's security architecture and risks, security controls, hardening and limitations. A well-defined security stance helps maintaining and improving security of the product as new features are implemented and deployed. To build secure software, i.e. software that can withstand malicious attacks, security should be built in into its development lifecycle. More specifically, there should be a continuous process of evaluating and managing security risks (new and old), taking them into consideration and addressing in the architecture, design, implementation, testing, and deployment of software. It's important to note that this applies not only to new feature or functionality, but also to the entire product as any addition has an associated security risk and potential consequences on the overall security of the system. Building security into software development lifecycle is a complex and perhaps the most time consuming component of software security as it's the only way to ensure that everything else (i.e., the security stance, features and documentation) holds.

To use the iceberg analogy, the security stance and how security of a software is ensured are the fundamental parts of security but they are are mostly invisible to end users. In fact, I'd speculate that they are not that much appreciated and often overlooked by a general public. They're often assumed to be given until something goes wrong. What users usually see and appreciate is features and functionality. Together with documentation they make up the tip of the iceberg. While security features are obviously necessary, they should not be mistaken for software security. It's not a number of features that matters, but correctness of their design and implementation and their contribution to overall security of the product.  Each piece of software should have a set of fundamental security features, such as authentication and authorization, and a set of features that are necessary for its secure usage and deployment given its purpose and design.

Documentation is another important aspect of software security. Providing an end user with a clear explanation of the supported security controls and features and architectural constraints is truly essential to the security of the final deployed product. Documentation helps users to evaluate, understand, correctly use and improve on available security controls. In fact, lack of proper documentation can hurt security of a system if less secure options are chosen due to lack of user understanding of available controls.

As a part of security initiative in Eucalyptus Systems, we are working on addressing all four areas explained above. Putting it all together is not easy and does not happen overnight, but given enough determination it's absolutely possible. In the last few months, we have been mainly focusing on reviewing and defining Eucalyptus security architecture (more on that topic in one of my next posts) and incorporating security concerns into the product development lifecycle (see my  previous post). Eucalyptus user-facing security features so far have been mainly defined by AWS features, such as IAM and EC2 security groups, but this most likely be changing as differences between private and public cloud will become more prominent. Security-related documentation is the area where Eucalyptus probably lacks the most and needs to improve on. Eucalyptus Installation Guide already contains some information related to security, but this information needs to be presented in a more concise and uniform way. To start off, in the upcoming (3.3) release, we will improve our documentation around how to setup firewalls around Eucalyptus components. For the following release, a Eucalyptus hardening guide and IAM best practices are some of the high priority items. 











No comments:

Post a Comment