Posts Tagged ‘designing for security
Securing against software attacks
Software is a central and critical aspect of the computer (and embedded system) security problem. Software defects with security ramifications —including implementation bugs such as buffer overflows and design flaws such as inconsistent error handling — promise to be with us for years. All too often, malicious intruders can hack into systems by exploiting software defects. Moreover, Internet-enabled software applications present the most common security risk encountered today, with software’s ever expanding complexity and extensibility adding further fuel to the fire.
Software security’s best practices leverage good software engineering practice and involve thinking about security early in the software design life cycle (SDLC), knowing and understanding common threats (including language-based flaws and pitfalls), designing for security, and subjecting all software artifacts to thorough objective risk analyses and testing.
Security is an emergent property of a software system. This is a subtle point often lost on development people who tend to focus on functionality. Obviously, there are security functions in the world, and most modern software includes security features, but adding features such as SSL (for cryptographically protecting communications) does not present a complete solution to the security problem. A security problem is more likely to arise because of a problem in a standard part of the system (e.g., the API to the server) than in some given security feature. This is an important reason why software security must be part of a full lifecycle approach. Just as you cannot test quality into a piece of software, you can not spray paint security features onto a design and expect it to become secure.
Figure 1: Software security best practices applied to various software artifacts in the Software Design Life Cycle (SDLC)
As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem. There is no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years. Figure 1 specifies one set of best practices and shows how software practitioners can apply them to the various software artifacts produced during software development. Although the artifacts are shown laid out in a linear sequence, most organizations follow an iterative approach, which means that best practices will be cycled through more than once as the software evolves.
Software security best practices apply at various levels:
- The requirements level: Security requirements must cover both overt functional security (e.g., the use of applied cryptography) and emergent characteristics.
- The design and architecture level: A system must be coherent and present a unified security architecture that takes into account security principles (such as the principle of least privilege).
- The code level: Static analysis tools — tools that scan source code for common vulnerabilities — can discover implementation bugs at the code level.
Risks crop up during all stages of the software life cycle, so a constant risk analysis thread, with recurring risk tracking and monitoring activities, is highly recommended. Security testing must encompass two strategies: testing security functionality with standard functional testing techniques, and risk-based security testing based on attack patterns and threat models. Penetration testing is also useful, especially if an architectural risk analysis is specifically driving the tests.