Implementing a Secure Software Development Life Cycle — Part 2
The Secure Software Development Life Cycle
Security is not a matter of fences, tools or products you can buy and just plug in into your processes. Instead, security is part of the process, each and every step of your software development process should include some effort to maintain your applications secure. At the beginning it will be challenging to change the paradigm and train your people to implement it right, but once the process is matured and polished you will see the return of the investment.
Regardless of the project management methodology you implement for creating your software products -Agile, Waterfall o any other variation, the security pieces will need to be embedded to each stage of your software lifecycle, this way you will be sure that you are covering both, the business requirements and the security requirements all the time. In fact, the essence of your process of construction of software should not change drastically, instead it will be just enhanced.
Following, we will review some of the security activities that a regular software development life cycle could include. Although the implementation of these tasks and deliverables may change depending on the particular product, strategy or current processes, this should give you a good starting point to understand the implication of implementing a secure process.
Preparation Phase
In the preparation phase is where you have to evaluate the security scope and requirements you have to cover to deliver a secure and quality product, in addition to prepare the team and infrastructure for the implementation of the project. This phase will have an exponential impact in the subsequent ones as it is at this point where you will build your team and define the security expectations that should be met throughout the software life cycle.
Project Inception
In this phase your current security posture and the product security requirements should be evaluated to later estimate the costs of security, this will influence the feasibility of the project and the decision of continuing with the intended scope and budget considered or if any adjustments will be needed. In this step it is important to involve a security expert that can provide an insight on the technicalities and get a clear idea of the full impact and capabilities to establish realistic expectations.
Training and Awareness
Training your team in advance is essential for a good execution, your team will need to have at least the basic understanding of the security features and best practices required beforehand to ensure a good implementation. But the learning process doesn’t end with one or two trainings, it is important to maintain a continuous learning and awareness plan that would reinforce the understanding of the security risks and mitigation procedures, along with a constant adaptation to the new threats that come every day. You could also consider having at least one or two security experts in the team that could coach the less experienced ones and also help to catch missing requirements on time to reduce the probability of getting issues later in the process.
In addition to knowing the security technicisms, you team must also have a good understanding of the whole secure development process and what is expected from everyone, including the distinct security reviews and deliverables that need to be covered throughout the software lifecycle.
Secure Best Practices
Besides implementing the regular best practices for coding and testing to improve performance, maintainability, scalability etc., it is important to review and establish the best practices and procedures for secure coding and testing, these practices should cover at least the top 10 vulnerabilities defined by OWASP as well as the basic security principles to ensure confidentiality, integrity, availability, non-repudiation, etc., and should be clearly documented and available to everyone for reference all the time.
It is important to highlight the difference from secure coding best practices and secure coding policies, the best practices provide a general secure framework that could be implemented while coding or testing, however, they do not necessary represent the procedures required by the secure coding policies established based on the particular security needs of every product or application. In other words, the secure coding policies are the minimum secure coding requirements to be implemented for a particular application, for example the minimum encryption key length or the level of logging required for specific functions of the application. The secure coding and testing policies are usually defined during the analysis and design phases.
Define Security Roles
To improve the communications and the distribution of responsibilities, it is essential to clearly define security roles within each of the teams involved in the software development process (Development Team, IT Security, DevOps, etc.), these roles can be dedicated to security activities only or a combination of other activities in the teams. The people in these roles will have higher participation in the security activities such as the definition of the security best practices and policies, the security architecture reviews or the corporate security policy updates.
Creating these roles will also help to centralize the communications through fewer people and will prevent the overcommunication, which could cause distractions for those that are not essentially required in all the security activities, in addition to prevent the miscommunication because of unclear responsibilities or multiple points of contact. Moreover, by defining authority roles like a security advisor or a security lead, you can define who will be responsible for approving the code and testing reviews or signing off requirements and documentation.
Security Response Plan
There will be security defects in your software, therefore it is important to define the security response process that should clearly describe how to proceed in case of any security incidents, this will save time and costs for everybody if properly developed and implemented. The response plan should include at least the following activities:
· Vulnerability or threat reporting
· Assess of the impacts (real or potential)
· Establish communication channels
· Notify to the impacted people
· Create and test the fix
· Release (emergency or regular)
· Evaluate lessons learnt
· Update best practices, procedures and policies as needed
These activities involve technical and management tasks that could be executed in parallel, while the management team is handling the communications and assessing the business impacts the technical teams are working on the fix and its quick integration.
Setting Up the Environments
Another important aspect that needs to be clearly established in the secure development process is the definition and procedures for each environment needed for your application, each of these environments will have different purpose and in turn will need different requirements and procedures. Some of the common environments defined in a regular development process are:
· Local
· Development/Integration
· Testing (QA, UAT, Integration, Automation)
· Staging/Pre-Production/Demo
· Production
The particular implementation of these environments will vary by organization and the particular business needs for each application, depending on the size of your team or the complexity of the application you may need more or less environments, and you have to consider that every environment represents costs and maintainability effort so it is important to efficiently define what you need in particular.
Moreover, while defining and creating the environments you have to evaluate the specific security needs for each of them and define the procedures and policies to be enforced by everyone involved. These procedures should cover the tasks needed for the creation and disposal of environments or applications, including the configuration of firewalls, network segmentation, whitelisting IPs, setting up access controls, etc., in addition to specifying the communications and authorizations required before executing any changes. You will also need to identify the dependencies form the product being developed to other components, either internal or external, so you can define the trust boundaries and restrict any traffic or features that are not necessary.
Implementation Phase
In the implementation phase the product and its security features will be incrementally developed and refined. Each activity in this phase will have an exponential impact on the subsequent ones, so you have to put special attention on the first stages to avoid missing important pieces that could come up later and affect the costs and deliveries.
Throughout the whole implementation phase different security features and reviews will be executed along with the implementation of the business requirements, so due care and due diligence is required the same way as any other tasks.
Analysis
One of the most important tasks to be included in the analysis as part of the secure development process is the design of the security architecture for the new application, which will allow you to get the full picture of the security implications the new piece of software will bring so you can determine the risks involved. The drafting of the security architecture should outline in a high level the interactions of the application with other components, both internal and external, as well as the different trust boundaries involved. This will help you to identify the attack surface and plan for the necessary actions to maintain your risks in an acceptable level, in addition to aid in the definition of the threat models and data flow diagrams during the design phase.
The analysis stage is also a good point to define which of the secure coding best practices outlined in the preparation phase will be require based on the particular security needs of the application and which ones will be nice-to-have. You can enforce this by creating secure coding policies, where you can specify the minimum security requirements to be covered, like the acceptable cryptography cyphers and key lengths, the authentication and authorization mechanisms or also define secure code checklist that can be used during the code reviews.
The same idea applies for testing, you can establish secure testing policies where you define the types of security testing required for the different pieces and types of components. For example, load testing can be used to prevent denial of service attacks by simulating big loads of traffic, fuzzing can prevent memory overflow or overrun attacks by entering unexpected values in your inputs and automation testing can be helpful to prevent race conditions by executing the same operation multiple times simultaneously, just to mention a few.
Design
As part of the design of your product, including the business logic and technical requirements, it is important to also account for the security requirements identified during the security architecture design. During this stage you will need to expand on the evaluation and design of the trust boundaries and data flows for your application to identify the risk areas and take appropriate actions to keep your application secure. You can do this by creating threat models that will help you to define a complete picture of the interactions between each of the components and actors involved, with a particular focus on security. There are some tools available you can use to create your models, one free and decent option is the Microsoft Threat Model Tool, below you can see a sample threat model so you can get a better idea.
To get the best out of this process you will need to have at least one experienced professional with a good understanding of security, and preferably with experience creating threat models, as this may be a complex process that would require a lot of thought and communication.
Another important part of the design of your application is the design of the security tools that will be required to setup and manage the security of your application, this could include an admin module or an installation wizard where the user can customize the security features like privacy, access permissions, authentication mechanisms, etc. It is essential that these security tools implement safe default settings, including deny by default or disable sensitive components unless they are strictly required, in addition to include clear documentation that would guide the user to do a safe implementation understanding the implication of each configuration.
Build
During the build of your software product, the developers will need to cover each and every security feature previously designed, including the implementation of the secure coding policies and best practices, to ensure the appropriate execution the security advisors or any other role previously defined will have to perform the secure code reviews by following the security checklist previously defined.
In addition to the manual validations performed with the code reviews, some application security testing tools can be leveraged during the development process (and even for testing), this will help the developers to catch missing security requirements or detect insecure code during the coding or integration stages, so they are suggested or required to do the fixes before continuing to the next phases. Besides ensuring better security coverage, the use of these tools provides considerable costs and effort savings by reducing the number of defects caused by human errors or by missing security requirements in early stages. The options for application security testing available are many and keep evolving fast as the application security practices keep getting more popularity, some of the most common tools are:
· Static Application Security Testing (SAST).
Covers the security analysis of code at rest, which could be at the coding phase with the help of IDE plug-ins that could validate the code on real time while the developer codes or it could be during the integration phase when the code integrated with the rest of the source code.
· Dynamic Application Security Testing (DAST)
Covers the security analysis with the application running by simulating the basic malicious tactics used by attackers, including testing typical vulnerabilities like SQL Injection or Cross-Site Scripting.
· Interactive Application Security Testing (IAST)
Implements a combination of both, static and dynamic analysis, this way you can have a complete vision of all the components involved regardless if they are available to the front end or not.
· Mobile Application Security Testing (MAST)
Covers particular vulnerabilities commonly present in mobile applications.
· Software Composition Analysis (SCA)
Evaluates the third-party components referenced and implemented in the code by comparing it to a previously defined list of known vulnerable components and versions.
· Database Security Scanning
Checks for updated patches and versions, weak passwords, configuration errors, access control issues, etc.
Testing
Testers are also an important line of defense in the secure development process, in addition to testing the functionality of the product, the testing team will need to also validate that all security requirements are met. In this phase, tools like Dynamic or Interactive Security Testing as well as fuzzing and other automated testing tools can be implemented. The testing team will also have to make sure that the bug tracking process includes security and privacy information, such as the bug causes (like Buffer Overflow, SQL Injection or Weak Authentication) as well as the effects (Spoofing, Tampering or Information Disclosure).
Deployment
Once the product is built and tested, the deployment stage plays an important role in security, regardless how secure and fancy the product may be, if it is not properly implemented during the deployment, all the security effort previously spent is useless. So, it is important to run a thorough security check before signing off the deployment.
Delivery Phase
The delivery phase is where the client or the final user receives the product, but before it is handed over, a quick review of the security requirements and features needs to performed, this should be just like a protocol to follow as the security features were gradually implemented and tuned during the previous phases, however, things could have been missed and at this point is where it is decided if they will be fixed before delivery or pushed to a later release or update.
Once the product is ready to go the customer experience team (or sometimes client itself), performs the last customizations and configurations. During this process a good documentation of the security tools as well as an easy-to-use interface come very handy.
Continuous Improvement
It is a fact that the technology evolves at an exponential rate so adaptability is key for a software product to thrive throughout the years, this is why it is important to keep learning and protecting from the new threats coming form day to day. A good security training and awareness program is vital to keep your workforce up to date and engaged all the time.
Another good practice to keep your products and organization secure is to implement a Red Team program, so you can leverage the experience form security organizations dedicated to test and try to break your security by implementing the latest tools and exploits that a real attacker would implement.
