Chapter 3. Secure Software Design
Secure software should not contain design flaws with security implications.
Design flaws may or may not be encountered during normal use of a software application, and may not lead to a security failure. However, if a flaw with security implications is discovered by an attacker, an attacker could induce a failure by setting up specific conditions to exploit the flaw.
Therefore, the design process should include activities for decreasing the likelihood that the design will contain flaws, so that the software will perform as required, even under attack.
The design process should include a design specification that is easily comprehensible and traceable. For example, the Data and Analysis Center for Software (DACS)[38] writes that:
Comprehensibility will make the design specification easier to analyze to reveal possible vulnerabilities and weaknesses. A specification that is fully traceable will make it easy to determine whether the design satisfies all of its requirements, including its security-relevant requirements. This traceability should be backward and forward, i.e., it should be possible to trace forward from a requirement to its manifestation in the design, and backward from a point in the design to derive the requirement(s) satisfied at that point. It should also be possible to trace forward from any point in the design to its manifestation in the implemented code, and backward from the code to the part of the design realized by that code.
This ...
Get The CSSLP™ Prep Guide: Mastering the Certified Secure Software Lifecycle Professional now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.