Measures For SSDLC (Secure Software Development Life Cycle)

Learn About Various Security Measures to Implement For a Secure SDLC or SSDLC: 

As technology is growing rapidly, the security-related threats of hacking and stealing of secured data have also increased accordingly. So, no doubt that technology growth is throwing challenges to the software makers to ensure that their software is strong and robust against the security threats and vulnerabilities.

A software product cannot be released, even if it functions perfectly for the intended functionality unless it proves to be highly secured and meets the specified and regulated security and privacy standards, especially in sectors like Defense, Finance, and Healthcare that involve personal and financial data.

One cannot afford to have a security defect in the product when it is deployed, be it high or medium severity. Hence it is very essential to protect the software and the data from any kind of attack, malicious threats, vulnerabilities and ensure the software’s trustworthiness to the end-user.

As against our traditional software development, testing at the last phase after the entire software is developed is no more effective. With the implementation of Agile, DevOps and ShiftLeft concept, it is essential to carry out testing at early as well as every phase of the application life cycle.

Having said that, the security of the software cannot be built or even tested at the last stage and thus it needs to be built at every phase to ensure the total security of the software.

Security Measures For SSDLC

Enlisted below are the various means of security-related measures that can be implemented across the software development life cycle in order to ensure Secure SDLC or SSDLC and as much as possible, the defects are not allowed to carry forward to the next phase.

The various security analysis and assessments at which security needs to be built in SDLC phases are.

1. Requirements Phase
2. Planning Phase
3. Architecture and Design Phase: Security Risk Assessment based on the design.
4. Development Phase: Secure Code Analysis, a static analysis of the code for security.
5. Implementation Phase: Dynamic Code Analysis, an application security testing.
6. Testing – Pre Deployment Phase: Penetration Testing and Vulnerability Analysis.

#1) Requirements Phase

• Primarily, in order to ensure that necessary security measures are built in the software, Security-related Specific Requirements need to be clearly captured during the requirements phase with enough details and expected results.
• While identifying the typical use cases and business scenarios, a clear set of Security related Use Cases and Scenarios for verification purposes need to be identified in order to capture the security features and design security testing scenarios.

Given below are a few sample examples that illustrate the explicit security-related requirements that can be captured.

Sec-Req-01: The system is required to have authentication measures in place at all gateways and entrance points.

Sec-Req-02: The system is required to implement authentication via a secure login screen.

Sec-Req-03: PERSONAL DATA shall be encrypted at rest.

#2) Planning Phase

At a high level, but not just limited to these, the following points need to be taken care of at the Planning Phase.

• A strong, Dedicated Security Team, functioning outside the PMO (project management office) of the program team, consisting of Security Officer, Security Architects, Security Testers to be formed to carry out and manage all the security-related activities of the program in an unbiased manner. For each of these roles, a clear RnR (roles and responsibilities) and RACI are defined.
• Any escalations, ambiguities related to the Security issues need to be handled by the PSO (Product Security Officer) so that the security team functions smoothly and helps in making the right decisions.
• A robust Security Testing Strategy specifying how to implement the security-related requirements, how, when and what to test, what tools should be used at each stage, needs to be identified.
• It is mandatory to involve the Security Point of Contact for all the technical/review discussions related to the program so that the security team is aware of any changes happening to the program.

#3) Architecture And Design Phase

Paying more attention to the security aspects early-on during the Design Phase shall help to prevent the security risks and reduce considerable efforts in Design changes later on in the SDLC.

While designing the software, and the infrastructure on which the software will be hosted upon, all possible Security Design Implementations need to be well designed with the involvement of the security architects.

Any ambiguity and conflicts between the functional and non-functional Design and Architecture aspects need to be sorted out through brainstorming sessions involving the right stakeholders.

During this phase, a detailed Product Security Risk Assessment, which is also sometimes called ‘Static Assessment’ needs to be carried out by the Security team of experts.

Security Risk Assessment includes a review of the programs from a Security standpoint at the preliminary design/architecture stage to identify the security-related flaws from the Design perspective and accordingly raise the Product Security Risks to the project team to address them and avoid entering into the next phase.

These assessments are carried out based on the Organizational/Industrial security guidelines, standards, and controls outlined in those documents. E.g. UXW 00320, UXW 030017

During Product Security Risk Assessment:

• Requirements, Features, User Stories, and their Design Documents are reviewed, based on the details, artifacts shared by the Project team, E.g. Design Documents (HLDD and LLDD). The assessments also involve discussions with the relevant project team members in case of the absence of documents or to clarify if any doubts.
• Gaps are identified while mapping the Security Requirements of the program against the set standards and other best practices. Sometimes threat models are also developed based on the identified gaps.
• These gaps are identified as potential Security Risks also includes suggesting possible mitigations for implementation, are raised & managed.
• Once these Mitigations are implemented by the project team, they are verified for the closure via appropriate test cases designed by the System Test team.
• Risk Management Matrix, which provides traceability, is prepared to track these risks. Approval and sign off with the residual risk will be taken by the Security Architect and PSO.

Typical threat patterns that are identified at the design phase are related to Input Validation, Audit/Log Management, Configurations, and encryptions. The risks identification includes attacking vulnerabilities like Weak Passwords, Simple Brute Force Attacks, etc.,

Typical reviews include risks related to access to personal data, audit trails access, blacklisting-whitelisting entities, data cleaning, and deletion activity.

Sample Test Scenarios Include:

• Buffer Overflow Vulnerability: To ensure that by manually fuzzing parameters, it should not be possible to slow down the server and force the server not to respond (Denial of Service).
• Data Sanitization: To ensure that proper data sanitization happens for every Input and Output so that the attacker cannot inject and store the malicious content in the system.

#4) Development Phase

Secure Code Analysis is a Static Code Assessment method that is used to assess the Secure Code of the various features of software using an automated Scanning tool. Example: Fortify.

This analysis is carried out on every code check-in/build to scan the code generated for the security threats. This assessment is generally done at a User Story level.

• Fortify scans via plugins need to be installed on the Developer’s machines.
• Fortify needs to be integrated with the build template.
• Automated scanning will be carried out on all the builds on a daily basis.
• The scan result will be analyzed by the Security team for false positives.
• Defects identified by this assessment are raised and managed to the closure, so that seepage is minimized/zeroed to the next level.

Sample Test Scenarios Include:

• To ensure that sensitive data is not sent in plain text during data transmission.
• To ensure secure data transmission, external-facing API’s must be deployed on an HTTPS channel.

#5) Implementation Phase

Dynamic Code Analysis is nothing but Application Security Testing, which is also called OWASP (Open Web Application Security Project) testing. Vulnerability Analysis and Penetration Testing (VAPT) needs to be carried at the implementation/Testing Phase.

This analysis assesses the binaries and some environment configurations and further strengthens the code for the security requirements.

As part of this analysis, the Dynamic Behavior or functionality of various features of the programs are analyzed for security-related vulnerabilities. Stipulated use cases and business scenarios are also used to carry out dynamic code analysis.

This activity is performed on the Test Builds using various security tools with an automated and manual approach.

• HP WebInspect, Burp Suite, ZAP and SOAP UI tools are generally used to check vulnerabilities against standard vulnerability databases (Example: OWASP Top 10)
• This activity though is mainly automated, due to certain tools restrictions, some manual work may be required to triage false positives.
• This is ideally done on a separate environment (System Testing Environment), where the software ready for testing is deployed.
• Vulnerabilities need to be raised and taken to closure with the suggested Mitigations.

Typical threat patterns identified during this analysis are related to Input validation, Broken Authentication & Session Management, Sensitive data exposure, XSS and Password Management.

Sample Test Scenarios include,

• Password Management: To ensure that the passwords are not stored in plain text in the config files or anywhere in the system.
• System Information Leak: To ensure that the system information is not leaked at any point, the information revealed by printStackTrace could help the adversary from a plan of attack.

#6) Testing – Pre Deployment Phase

Penetration Testing, Pen Test in short and Infra VAPT (Vulnerability Analysis and Penetration Testing), is the full-blown holistic test with full solution and configurations (including network) that is ideally done on a pre-prod or production-like environment.

This is mainly carried out to identify the DB Vulnerabilities and Server Vulnerabilities along with any other Vulnerabilities. This is the last stage of Security Testing that would be conducted. Hence this also includes verification of earlier reported defects and risks.

• Tools like Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP that are available in the market are used to carry out Pen testing.
• Scanning of web applications using automated tools and exploitation for further verification is done during this testing. Testing is done to simulate the real attacker’s behavior and hence it may include a few negative tests also.
• Infrastructure Vulnerability assessment includes scanning, analysis and security configuration review of infrastructure (networks, systems, and servers) to identify the vulnerabilities and check the resilience against the targeted attacks.
• This is carried out on a pre-production or production-like environment, where the software, that is ready to deploy is tested and hence simulates the real-time environment.
• Vulnerabilities are identified using both scanners and manual techniques to eliminate false positives. Also, real-time business scenarios will be carried out during manual testing.
• A final report on the entire Security Analysis that is carried out for the whole program will be produced highlighting the status of the high risks items if any.

Sample Test Scenarios include,

• To ensure vulnerable HTTP methods are not enabled.
• To ensure sensitive information of the other users is not visible in clear text over the network.
• To ensure validation for File Upload is implemented to avoid upload of a malicious file.

Tabular Summary For SSDLC

The below table summarizes the different aspects of security analysis that are explained above.

Conclusion

Thus, with the implementation of all of these security-related aspects integrated across the various phases of SDLC helps the organization to identify the security defects early in the cycle and enables the organization to implement appropriate mitigations, thereby avoiding the High-Risk Security Defects in the Live System.

The study also shows that a majority of the security defects are induced into the software during the development stage, i.e. during the Coding Phase, wherein the coding has not sufficiently taken care of all the security aspects, due to whatever reasons.

Ideally, no developer would want to write a bad code that compromises security. Thus in order to guide the developers on how to write a Secure Software, the upcoming tutorial covers Best Practices and the Coding Guidelines for Developers, to ensure better Security of the Software.

We hope this tutorial on Secure SDLC or SSDLC was helpful!!