Adding “Secure” to your SDLC

Oct - 16
2018

Adding “Secure” to your SDLC

Have you ever asked you yourself one of the following questions:

  • “Will the new features we are deploying withstand a cyber attack?”
  • “How do we measure the level of security our Software platform has at any point of time?”
  • “How do we establish a continuous process of validating the security for every release?”

This article will help you find the answers.

 

“Secure SDLC” is a holistic approach of managing the risk associated with cyber-threats at all stages of software development life-cycle.  It helps the company catch security issues early in the process and re-mediate the risk in the most efficient way.

Some of the recent data breaches:

  • 2018 Google 500,000 account data breach
  • 2018 Facebook 50M account data breach
  • 2018 NewEgg Credit Card theft for 2 months worth of transactions

The underlying reason for all 3 breaches above was the weakness of the process that was meant to prevent introduction of software bugs  into production environment. Bugs were released in public domain and went undetected for prolonged periods of time, allowing hackers to find and exploit them. Even though breached companies above did have information security teams and the process to prevent an incident from happening, it proved to be insufficient.

Secure SDLC describes the overall framework that can be implemented into any organization to re-mediate cyber-security risks. The actual success of implementation relies largely on the people who participate in this new process. Secure SDLC can be broken down into the following steps

  • Threat Assessment
  • Developer Education
  • Security Requirements
  • Code Review
  • Security Testing
  • Vulnerability Management

Threat Assessment

Initial assessments should include identification of all potential threats to the organization based on the software projects. Threat is an agent of a malicious intent motivated to gain unauthorized access, change the functionality of the software in malicious way or ex-filtrate sensitive information the application stores and processes. Agents could be both external and internal to the organization. The goal of this step is to list of threat agents and their motivations to attack. The assessment should be conducted by business owners and other stakeholders with participation of security auditors to provide additional perspective.

Developer Education

It is important to get your IT Team educated about the risks and outcomes of releasing new features and functionality. Each contributor should have a basic understanding of how their contribution could affect the security posture of the entire product. Some of the aspects of this training are:

  • Threat Models
  • Secure Architecture
  • Implications of using of 3rd party code & tools
  • Build technical security guidelines
  • Keep everyone up to date with emerging threats in digital landscape

The education should include training sessions with both developers, managers and security experts involved in collaborative process of designing the architecture and guidelines in response to the threats identified at Threat Assessment stage. Its important for everyone to have the same understanding of threat agents, remediation techniques and attack vectors. Its useful to adapt a case study approach in this training to clearly articulate the inputs and outcomes of the potential security incident, for example review cases like the one below:

“Release of insecure feature” that results in vulnerability of “Arbitrary code execution”. This vulnerability combined with insecure architecture results in a security incident that undermines the value of the digital product to its customers and creates negative publicity around the product.

Action Items:

  • Improve the architecture
  • Create a guideline & the test for the specific type of vulnerability

 

Security Requirements

Security Requirements needs to be formulated for any application within an organization.  Here are just few examples of security requirements for an application that support authentication:

  • User Lockout after 5 failed attempts
  • Mask confidential data on display
  • Protect PII in transit and in storage

Security requirements are formed by company stakeholders with the help of IT Team and security experts. The requirements are affected by the following:

  • Threats that particular application is facing
  • Compliance level the company is seeking: SOC2, GDPR, PCI, or others
  • Overall goals of Information Security Policy for organization
  • Sensitivity of information processed & stored by the software application at different stages

Formulating Security Requirements is a crucial stage in developing Secure SDLC process as it makes it possible to perform security validation by checking the software application against the requirements with a simple “succeed” or “fail” outcome.

 

Code Review

80% of the bugs get caught during the manual code review process. Tests may not catch some of the bugs because they do not always cover 100% of all scenarios. It’s important that people reviewing the code have full understanding of the architecture, security requirements and security controls of the application. Applying this knowledge to the proposed changes in the code in the context of new functionality to be released is the most essential step of the process that can prevent a security incident from occurring. It is helpful to identify the security-critical parts of the software, review and test them with extra care and attention. It is useful to design a minimum code-level security standard that must be met in order to pass a security checkpoint in the deployment pipeline. Anything below this standard will not be passed to production environment until it’s fixed.

 

Security Testing

The security testing plan represents an enforcement of security requirements designed in previous steps during code release cycles. Security testing can be performed via automated unit and functional tests as well as manually. The critical part of security testing is the creative thinking that’s needed to come up with scenarios of malicious application use or mis-use. Those scenarios get incorporated into security tests that execute automatically on each code release. Security Testing always bears the risk of not including sufficient amount of scenarios into the test framework. Those missed scenarios could become valid exploits used by an attacker. We see an example of that in recent Facebook breach that was caused by the lack of sufficient testing of “View As” functionality together with Video Player component. Security testing is one of the last stages new feature or functionality goes through before being released to the public. This step represents the last line of defense in the deployment process.

 

Vulnerability Management

This process relates to post deployment activities of discovering and re-mediating a security issue. At the heart of this process is incident response plan that needs to be formulated and executed in case security issue is discovered. A security issue may include any of the following events:

  • Receipt of vulnerability report from 3rd party
  • Compromise or other security breach
  • Internal discovery of critical and high risk vulnerabilities

It’s important to form a security response team that will mitigate the discovered vulnerability in accordance with the plan and provide a report to company stakeholders on the incident and remediation process.

 

Conclusion

Secure SDLC helps establish the framework for maintaining a better security stance of each release, but it’s up the individuals involved in it to set the standard for the quality of verification that’s being performed on the system. After all the quality of verification becomes the key differentiator between success and failure of Secure SDLC process.

 

If you have any questions

If you need help integrating Security Framework into your SDLC process, do not hesitate to reach out:

LinkedIn: https://www.linkedin.com/in/whitehacklabs