Applications are rarely built with security in mind. As has been the case for more than 20 years, time and resource constraints hinder developers’ ability to put the necessary security precautions in place. In fact, 49% of respondents to a 2021 ZeroNorth survey said the pressure to release new applications makes it difficult to spend time ensuring software security.
Building security into the software development lifecycle (SDLC), a process known as security by design, offers many benefits, including increased quality and performance and reduced costs. Security by design, however, isn’t easy. Beyond resource and time constraints, software complexity and the constant introduction of new features and software revisions make security by design a difficult task to achieve.
Advances in software use and coding practices also hinder full adoption of security by design. Continuous integration and continuous deployment (CI/CD) and reuse of open source code speed the fielding of software but complicate software security. Issues created by CI/CD and software reuse must be addressed.
In addition, customers want easy-to-use applications and customized features. Turning these into a reality, however, requires complex software. Plus, rushing development and creating unsecure software leads to software flaws and vulnerabilities in the future.
Let’s look at the top security-by-design principles and discover how and why threat modeling fits into the SDLC.
10 security-by-design principles
Designing security into software is a goal many organizations strive to capture. Achieving this goal requires rethinking the overall governance model for software security. Applications don’t just need to perform tasks; they must do so with a security-as-quality mindset.
The first step is to accept that software will be attacked immediately upon fielding. As a result, checks and controls must be embedded into every iteration of the DevOps process. An iterative process offers more touchpoints and enables discovery and remediation of security vulnerabilities early in the SDLC. This way, if something is missed in design, it can be caught in development.
DevOps teams should apply the following security-by-design principles into the SDLC:
- Build security considerations into the software requirements specification
- Address possible abuse cases (e.g., how users may misuse the software).
- Create and enforce secure code guidelines.
- Use appropriate security tools.
- Conduct security audits at multiple stages of the SDLC.
- Conduct vulnerability testing that includes negative testing and penetration testing.
- Incorporate security within deployment and maintenance processes.
- Ensure reused software is from trusted sources and properly evaluated.
- Provide feedback throughout the process on security effectiveness.
- Educate developers and QA teams on secure coding techniques.
How threat modeling fits into security by design
Another step to add to the SLDC is threat modeling. Threat modeling is a security engineering activity designed to document hidden security risks that may not be anticipated or obvious. The threat modeling process attempts to uncover possible attack vectors and prioritize the risks software is susceptible to so development teams can focus their attention on the most relevant risks.
The benefits of applying threat modeling in the SDLC include the following:
- knowledge of the probability, potential harm and priority of attacks;
- prioritized security efforts;
- the ability to weigh security decisions against design goals; and
- confirmation that appropriate countermeasures are designed into an application.
Integrating security into the SDLC is possible, but as with all journeys, it requires taking the first step. With determined attackers not letting up, the time to focus on incorporating security-by-design principles and threat modeling practices is now. Take that first step today.