With organizations moving towards higher levels of digitalization, the role of software has increased multifold. This has led to increased numbers of data breaches and the average size [1] of data breach has increased 1.8 in 2017. A breach is defined as an event in which an individual’s name and a medical record and/or financial record or debit card is potentially put at risk. In most cases hackers exploit vulnerabilities in the software for the breach. Hence it is of utmost importance for software vendors to prevent vulnerability creep in software. IBM System Science Institute indicates that the cost of fixing an issue increases exponentially through the lifecycle phases [2] – implementation (6,5 X times), testing (15 X times) and maintenance (100 X times). Typical costs of security incident response range from $4000 to upwards of $40,000 as indicated in [3], [4].

Understanding the current secure development lifecycle

Some large software engineering organizations have adopted secure practices in their software development lifecycle [SDLC][5]. These secure practices are largely similar across organizations.

 

Let us take a close look at the Secure Development Lifecycle [SDL][6] as defined by Microsoft – SDL is a software development process that helps developers build more secure software and address security compliance requirements while reducing development costs. SDL has the following phases:

  1. Training
    1. SDL Practice #1 – Core Security Training
  2. Requirements
    1. SDL Practice #2 – Establish Security and Privacy Requirements
    2. SDL Practice #3 – Create Quality Gates / Bug Bars
    3. SDL Practice #4 – Perform Security and Privacy Risk Assessments
  3. Design
    1. SDL Practice #5 – Establish Design Requirements
    2. SDL Practice #6 – Attack Surface Analysis / Reduction
    3. SDL Practice #7 – Use Threat Modeling
  4. Implementation
    1. SDL Practice #8 – Use Approved Tools
    2. SDL Practice #9 – Deprecate Unsafe Functions
    3. SDL Practice #10 – Perform Static Analysis
  5. Verification
    1. SDL Practice #11 – Perform Dynamic Analysis
    2. SDL Practice #12 – Fuzz Testing
    3. SDL Practice #13 – Attack Surface Review
  6. Release
    1. SDL Practice #14 – Create Incident Response Plan
    2. SDL Practice #15 – Conduct Final Security Review
    3. SDL Practice #16 – Certify Release and Archive
  7. Response
    1. SDL Practice #17 – Execute Incident Response Plan

 

Microsoft has done a great job at laying out these security best practices and making these available for everyone. However, we feel one key aspect is left out in the SDL process and missing from these security best practices.

 

Likewise Slack talks about how they are able to move fast while securing things at the same time in this blog [7]. The blog essentially covers SDL at Slack. Slack has open sourced goSDL, a tool which helps developers produce secure features at high output with low friction.  goSDL is a web application that guides anyone involved with a new feature, like developers or PMs, through questions and checklists to improve the security posture of whatever they’re working on. The component survey, which we feel is key part of this process, allows the developer to indicate the components like WebApp, API, MessageServer, Mobile App, etc. Once the component survey is completed, goSDL generates checklists for the developer. There is integration with JIRA to allow tracking the checklists to completion and closure.

 

We appreciate that Slack has shared details around their SDL process and open sourced goDSL. We recommend all organizations to adopt goDSL to improve their software development process.

 

We find one critical aspect missing from SDL given how software is developed and the focus on reuse. Continue reading to learn more…

 

What’s missing?

Everyone in the software industry understands the importance of software reuse. Most softwares are written using a bunch of 3rd party softwares and libraries. This approach ensures that everyone is not building everything, especially the building blocks are reused almost always. Note that this reuse significantly accelerates the software development process.

 

What contributes as a building block varies. Let us look at the following examples to better understand it:

 

It is important to realize and note that these 3rd party softwares might have issues/vulnerabilities and these would in turn affect your software. This has been known for sometime now as indicated in this article [10] from 2015.

 

We at ThreatWatch believe that it is necessary for software companies to track and beware of vulnerability creep from such 3rd party software. Currently the Secure Development Lifecycle [SDL] does not explicitly track this vulnerability creep.

ThreatWatch to the rescue

We understand it is difficult for software engineering teams to track vulnerabilities across the multitude of 3rd party softwares used. ThreatWatch can help software engineering teams track these vulnerabilities with ease. Engineering teams simply need to provide a list of 3rd party softwares which they use to ThreatWatch. These are called “assets” in ThreatWatch parlance. Note that depending on the technology stack it might be straightforward to share the dependency (aka asset in ThreatWatch) details, for example – pom.xml for Java projects [11], pipfile (which is a replacement for requirements.txt) for python projects [12], etc.

 

Once these assets are shared with ThreatWatch, it can help provide threat impact information to the engineering teams. Engineering teams can be notified of vulnerabilities via “threat filter” that can be configured in ThreatWatch. Another key aspect is that engineering teams can keep track of the new patches released for 3rd party softwares and update their software to use newer and more secure versions of such 3rd party softwares.

 

Net net ThreatWatch can help strength SDL and take a load of the shoulders of engineering teams.

Closing comments

Most engineering teams deliver their solution as a SaaS service these days and ThreatWatch can help DevOps team represent their cloud instances as ThreatWatch Symbolic Assets by indicating the deployment environment softwares and their versions. This way the DevOps team can keep track of any applicable vulnerabilities to their deployment environment.

 

ThreatWatch tracks over 50+ sources for vulnerabilities reported and hence can effectively help provide engineering teams with a holistic view of things. Also, it will help facilitate more secure software being delivered to end customers by effective patching. It is key to note that DevOps team is responsible for patching all the cloud instances.

 

References

[1] Ponemon Institute – 2017 Cost of Data Breach Security – https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=SEL03130WWEN

[2] IBM System Science Institute – Cost of fixing issues – https://www.researchgate.net/figure/255965523_fig1_Figure-3-IBM-System-Science-Institute-Relative-Cost-of-Fixing-Defects

[3] DarkSide – The cost of fixing an application vulnerability – https://www.darkreading.com/risk/the-cost-of-fixing-an-application-vulnerability/d/d-id/1131049?page_number=1

[4] Tenable – The cost of incidence response – https://www.tenable.com/blog/the-cost-of-incident-response

[5] SDLC – https://www.techopedia.com/definition/22193/software-development-life-cycle-sdlc

[6] Microsoft SDL – https://www.microsoft.com/en-us/sdl

[7] Slack blog – Moving fast and security things – https://slack.engineering/moving-fast-and-securing-things-540e6c5ae58a

[8] Apache HTTP server – https://httpd.apache.org/

[9] Bouncy Castle – https://www.bouncycastle.org/

[10] TechBecon – Third-party libraries are one of the most insecure parts of an application – https://techbeacon.com/third-party-libraries-are-one-most-insecure-parts-application

[11] pom.xml for maven projects – https://maven.apache.org/pom.html

[12] pipfile (a replacement for requirements.txt) for python projects – https://github.com/pypa/pipfile

Leave a Reply

Your email address will not be published. Required fields are marked *