The stakes for software development teams (and all the rest of us, actually) are already rather high and increasing daily. On top of the countless changes with software design and development, we have new and unexpected places where software shows up. The attack surface for software grows exponentially as we see new technology and new ways of using software emerge and flourish. Now, development teams are responsible not just for security, but for safety as well. Imagine trying to live with yourself knowing IoT software you helped to design was shipped with design defects that caused someone’s death…
We all recognize that for most software development projects, time and budget are fixed values, and the introduction of “extra security work” is generally not well received by software development teams, so it’s incumbent on security practitioners to make security work simpler, palatable – and consistent.
The best place then to introduce the security design and architecture review is when the Scrum team is engaged in the functional design and architecture review of the software. Threat modeling is best performed during design work so that necessary security controls and countermeasures can be defined for the development phase of the software. OWASP describes the benefits of threat modeling:
- Builds a secure design
- Efficient investment of resources; appropriately prioritize security, development, and other tasks
- Brings security and development together to collaborate on a shared understanding of the system
- Identifies threats and compliance requirements and evaluates their risk
- Defines the need for required controls
- Balances risks, controls, and usability
- Identifies where building a control is unnecessary, based on acceptable risk
- Documents threats and mitigation
- Ensures that business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
- Identifies specific types of security tests and scenarios to test the application under the acceptance criteria dictates
When conducting a security review, the assurance requirements of the software should be considered, bearing in mind the cost and time constraints and the need for trade-offs. Generating a security plan from the review is a good start for documenting the security design and using it as a check-and-balance guide during and after development. Architecture reviews should be both broad and deep.
Like peer reviews, architecture and design reviews should include key members of the analysis and design team, the development team, security experts, and SDLC process governance personnel.
Perform Threat and Application Risk Modeling
Threat modeling includes determining the attack surface of the software by examining its functionality for trust boundaries, entry points, data flow, and exit points. Threat models are only useful once the design documentation that represents the application’s architecture is more or less finalized, so that the threat model is based on the intended, likely future of the software.
Threat modeling is helpful to:
-
Ensuring that the design complements the security objectives
-
Making trade-off and prioritization-of-effort decisions
-
Reducing the risk of security issues during development and operations.
Risk assessments of software can be accomplished by ranking the threats as they pertain to your organization’s business objectives, compliance and regulatory requirements, and security exposures. Once understood and prioritized, those newly uncovered threats can then be sent into a phase of planning countermeasures and/or changing the design to remove defects.
An article from MSDN entitled “Lessons Learned from Five Years of Building More Secure Software” underscores the fact that many software security vulnerabilities are design defects. When people are exclusively focused on finding security issues in code, that person runs the risk of missing entire classes of vulnerabilities. Security issues in design, such as business logic flaws, cannot be detected in code and need to be inspected by performing threat models and application risk assessments during the design sprint.
Threat modeling is an iterative-structured technique used to identify the threats to the software under design. Threat modeling breaks the software into physical and logical constructs generating software artifacts that include data flow diagrams, end-to-end deployment scenarios, documented entry and exit points, protocols, components, identities, and services.
Attack surface analysis is a subset of threat modeling and can be performed when generating the software context to zero in on the parts of the software that are exposed to untrusted users. These areas are then analyzed for security issues. Once the software context is generated, pertinent threats and vulnerabilities can be identified and treated.
The benefits of threat modeling clearly outweigh the effort it takes to conduct them, and any work conducted becomes reusable for the lifetime of the application. It’s worth the effort for gains in assurance that your software is free of design defects that could affect health and safety – the life you save may be your own!
(Adapted from Merkow, M. S. (2022). Practical security for Agile and DevOps. Auerbach Publications.)