Any software is the result of a confluence of people, processes and technology. In order for software to be secure, it must integrate relevant security processes. Software is secure, if it can guarantee certain operational features even when under malicious attack. The guiding principles of software design security can be condensed into an acronym, CIAA, which stands for
• Confidentiality: Only authorized people (or processes) can get access.
• Integrity: The presented data is unaltered.
• Availability: The system and its data are available even under adverse circumstances.
• Authenticity: Users are who they claim to be.
Software design is an important activity which takes the requirements
as an input—particularly the specification of a system's external behavior—and deconstructs the system at possibly multiple levels into components and their interactions. So this step produces a description of the software's internal structure which serves as the basis for software design security, namely:
• Assurance of the software design's agreement with the specifications, typically the constraints regarding aspects and future evolution of the design.
• The rationale for software design decisions.
• The assurance case portion related to software design, including argument and evidence for the design's conformance to external behavior.
• The system's security policy.
• Other relevant constraints.
Software design normally includes descriptions of the architecture, components, interfaces and other characteristics of a system or component. The design of secure software systems is critically dependent on understanding the security of single components. To attain best possible security, software design must follow certain principles and guidelines.
• It needs to be consistent with a security policy.
• It needs to incorporate the necessary security functionality.
• It needs to ensure that specifications are met and the expected behavior is performed.
• It should employ a separation of mechanisms, duties and privileges, including the principle of least privilege.
• It should be able to defend against outside attacks on the infrastructure and other components.
The design of any software system is (among other things) an exercise in risk management, that tries to identify the things that can go wrong before they happen so that decision-makers are prepared if they happen. Software design security should follow a process-oriented approach, and ensure that the following activities are carried out.
• Developing use/misuse cases: Work with the architecture group to model use and misuse cases. While use cases depict the application's functionality, the inverse of the use cases (misuse cases) is modeled to understand and address the software design's security aspects. Create standard case templates that can always come in handy.
• Performing software security design and architecture reviews: The security architect should get involved when the teams are engaged in the functional design and architecture review of the software. To ease this process, try using the checklist approach, since that works great and can be tracked. It is imperative that the security architect works closely with the architecture team to generate a software security plan which outlines its design in detail. The same can be used as a check-and-balance guide during and after development.
• Performing threat and risk modeling: Threat modeling helps in determining the software's attack surface by examining its functionality for trust boundaries, entry points, data flows and exit points. If you are not familiar with the technique, use a threat modeling tool, because it always comes in handy for this exercise. The next activity that follows is risk modeling of software. It is accomplished by ranking the threats as they pertain to the organization's business objectives, compliance and regulatory requirements, and security exposures.
• Generating test cases: Try and use a combination of misuse cases, security design and architecture reviews, as well as threat and risk modeling, to generate a detailed security requirements document (technical details), which the developers can then use to write code. You can also use this plan to generate security test cases which should be executed during testing. Using a scenario-based security testing template is effective in ensuring that the bare minimal security test cases are performed in every software development effort.
• Guiding: While performing the above tasks, take some time to document them, because they can serve as guidance or knowledge base. Document the best practices for secure architecture and design, review checklists and design considerations, which can be used as standard guidance tools organization-wide. These are living documents which get updated with changes in technology. Good practice calls for documenting design decisions made for security reasons, as well as ensuring traceability of design items and decisions to requirements and code. Traceability is essential for the assurance case.
Developers need to know software design security principles and how they are employed in design. They need to know ways to recognize whether these principles were used in a design, and know how to evaluate designs and proposed changes, including improvements. Finally, plan for defense in depth (that is, layered defenses), and do not rely on silver bullets—because they don't exist.
About the author: Bithal Bhardwaj is a strategic advisor with OWASP India, has helped organize various OWASP events, including the recent Securitybyte & OWASP AppSec Asia 2009. He is a frequent speaker at conferences, and has authored several articles on information security. He has over a decade of experience in IT, as well as played a major role in establishing and executing large information security programs.