Seamless Security Integration Strategies in Software Development

During the software development, builders face challenges between building a better product faster versus dealing with various responsibilities that come with software development. Getting security right is one of them. Due to the increased cyber attacks, organizations started focusing on security, which resulted in developers spending more time in security-related activities in recent years. 

This brings up the critical need for integrating security practices in the software in the early stage instead of making security an afterthought. Integrating security practices early and more often will not only reduce the cost but also be more effective. In this article, we will talk about how we can achieve that. 

Scope

This article will discuss how security can be integrated into various stages of the software development lifecycle (SDLC). We will primarily focus on design, coding (implementation), testing, and CI/CD (deployment). If you are interested in extensive high-level security software practices, please refer to the NIST Secure Software Development Framework (SSDF) [1].

Introduction to Critical Security Concepts

Before we go too far, it is very important for every developer to understand couple of critical security concepts. This will come in handy each step of the way during the software development.

1. McCumber Cube

This is a security model introduced by John McCumber in 1991 to establish and evaluate information security programs. It is represented as a three-dimensional Rubik's cube.

1. Information characteristics
2. Information state
3. Security countermeasures

I am going to talk about information characteristics only briefly because this is a critical goal every developer should keep in mind when designing and building a software system.

Information Characteristics

• Confidentiality. Sensitive information should not be disclosed to unauthorized users.
• Integrity. Information should not be modified, which results in questioning its reliability.
• Availability. Authorized users should be able to access the systems reliably when needed.

2. Threat Model

As per NIST, 'A form of risk assessment that models aspects of the attack and defense sides of a logical entity, such as a piece of data, an application, a host, a system, or an environment' [3].

In short, you will take your system architecture and assess each component, their entry points, data, and their access path to check what can go wrong and how an attacker can exploit it. STRIDE is the most commonly used framework during the threat model [4]. If you are interested more in this topic, there are lots of resources available online about threat modeling.

Security During SDLC

Security-related activities during software development are not one-and-done in the SDLC. They directly or indirectly play a role in each stage. If done correctly in each stage, they reduce a lot of additional costs due to rework, prevent scheduling delays, and create a better working dynamic between software and security teams. 

In each of the following stages, keep the McCumber Cube and threat modeling in mind and think like an attacker when you develop.

Security During the Design

During the software design, developers generally list out the functional and non-functional requirements. Functional requirements are essential for the system to work and serve its purpose, e.g., when I select a candy from the vending machine, it should give me the candy. 

Non-functional requirements are critical in supporting the system's functioning correctly, e.g., a candy machine should be working when one tries to use it. They are also defined by many '-ilities' [5]. One of the critical non-functional requirements is Security. It should include how your system's Authentication (AuthN) and Authorization (AuthZ) should work at each entry and exit point of the system. 

Also, how the system would protect the CIA properties, also known as CIA Triad [6]. These are absolutely critical security properties every design should discuss and have a solution planned. If done correctly, this will reduce a significant amount of rework later in the development stage, which will be very expensive. 

Security During the Coding

Coding is a significant stage in any software development phase. Almost any developer’s first focus would be (should be) to make the system work to meet the functional requirements. But some of the critical security requirements, such as Authorization logic and addressing common security vulnerabilities, including but not limited to input validation, encryption, and adding sufficient logging to investigate during incidents, need special attention. 

For any of the security-related coding components, it is advisable to include a security team member during the code review. This will help get early feedback and not to wait till later in the stages to rework everything, which will also attribute to lots of rework and re-testing and a whole lot of additional rework.

Security During the Testing

A lot of security incidents are reported because of weak test environments and credentials or sensitive information leaked from test environments. It is essential to have a functional testing environment that is secure. Proper separation between production and non-production environments and proper anonymization of the data for test purposes are very critical security requirements. 

Additionally, writing some security-specific test cases for AuthN and AuthZ-related unit test cases will make sure these functions are working correctly during every release. 

Security During the CI/CD Integration

Most teams have CI/CD integration these days for deployment and every release should have basic security validations such as security configuration checks, automated security integration tests. Finding or building such tools and integrating them with CI/CD pipelines will make sure every release is secure, reduces manual work and catches potential security issues before reaching the production. 

Automation Opportunities

The above sections talked about how security can be improved in each stage of the SDLC. However, doing it every time is a chore, and developers dread doing it. Automating some or all of these functions in each stage may require some initial investment, but that will save a lot in terms of cost, provide a better developer experience, and be less error-prone in the long run. 

There is an opportunity to automate things in the coding, testing, and deployment stages. For example, running some automated code scanning tool during the code review, writing automated integration test cases to make sure the AuthN and AuthZ test cases are always working, and integrating security configuration scanners are very critical in reducing lots of manual work during every release and also it makes sure every release is more secure. 

In addition, during the automation, it is possible to have false positives during the initial stages; it is important to spend some time in the early stage to work on identifying the false positives and reduce the noise and customize the automation in such a way that it is effective.

How and When to Engage

One other critical component besides technical expectations is effectively engaging with security teams. Most organizations have limited security resources, so whenever developers need to make effective use of their time, this may require properly documenting all the work, asking for specific security recommendations, and involving them in critical code reviews. 

Also, security practitioners involved in your project will have a variety of experiences; they can be application security engineers, pen testers, or security program managers. It is very important to tailor the message and learn how to tell the story in such a way that the audience from any background understands; it will make the collaboration efficient and save time for everyone involved.

Conclusion

Building software and shipping cool things are the core of software development, but that is not the only thing that makes better software. Security plays a critical role, among other things, such as operational excellence. 

Security should not be an afterthought; it should be integrated with each stage of the software development. If you try to do everything at the end of the project, you may even end up redesigning some of the components and rewriting large parts of your code, which is basically redoing the entire project. So, embedding security practices in each stage, automating them to reduce the overhead, and engaging effectively with security teams are critical for the seamless integration of security in software development. 

References

1. NIST Secure Software Development Framework (SSDF): https://csrc.nist.gov/pubs/sp/800/218/final
2. McCumber cube figure: https://www.researchgate.net/figure/The-Original-McCumber-Model_fig1_235470635
3. Threat Model Definition: https://csrc.nist.gov/glossary/term/threat_modeling
4. STRIDE: https://www.softwaresecured.com/post/stride-threat-modelling
5. The 7 Software “-ilities” You Need To Know: https://codesqueeze.com/the-7-software-ilities-you-need-to-know/
6. CIA Triad: https://www.nccoe.nist.gov/publication/1800-26/VolA/index.html

The opinions expressed in this article are solely those of the authors and not their employers.