The Secure SDLC

Happy new year everyone!

It feels like the world hasn’t awoken from 2023 yet and are just starting to rub the sleep out of their eyes. Since I’ve not written to you since before the holidays, I decided to start the year with a series of articles covering the topic of coding securely. Throughout last year, there were threads that kept showing up on this topic and these articles will focus on engineering teams secure coding practices.

In speaking with clients about their security programs, the conversation always starts with incident response (IR) and the need to defend against cyber attackers. While this is a clear need for every company, what isn’t clear to most executives is how these cyber criminals take advantage of vulnerabilities that exist within their product platforms.

When it comes to engineering discipline, from this CISOs perspective - if the network isn’t being attacked or the employees haven’t been trained in identifying phishing attacks; then the majority of the cyber-attacks are coming from the organization’s internal engineering code - due to weak controls in engineering practices and the inability to fix known defects and vulnerabilities.

Just ask any engineer, developing software can be fun. Mature shops follow a methodology to develop their products, but what about new companies or the ones that have come together through acquisition where there is an abundance of tech debt and limited integration or processes? These are the companies that cyber criminals love to take advantage of.

The Secure SDLC is commonly called Shift/Left and the term has become a buzzword in the industry. For those that are not familiar with the term, Shift/Left refers to an approach where the engineer considers coding for security during the planning and architecture stages of the SDLC (software development lifecycle) – then follows a lifecycle methodology that focuses on the ability to identify gaps, defects, and vulnerabilities prior to releasing a code library.

When security is factored into the SDLC, it is referred to as a Secure SDLC (SSDLC) and that means that a set of key considerations are made up front in the design phase of the methodology and before coding starts. The term doesn’t mean that prototyping can’t be started or completed, only that security is a forethought throughout the entire lifecycle phases.

Another thread that has appeared is that many understand the term ‘agile’ to mean ‘fast track without any process’. This couldn’t be farther from the truth and if in doubt - just ask any CISO that has to answer SDLC questions from an external auditor. When Agile coding principles are used, they can be combined with an SDLC. These companies are aware that security can easily be inserted into an MVP and sprint – no matter the length of time needed from start to finish.

Software defects and vulnerabilities end up leaving organizations exposed to cyber criminals and a decrease in customer satisfaction. A case in point, this month Uber announced the closure of Drizly, an alcohol delivery service that Uber paid $1.1B to acquire. The business is being closed due to two reasons - a post pandemic decrease in consumer need, as well as the FTC looking into their security practices, stemming from a 2020 breach that impacted 2.5 million customers. When companies experience a breach in their flagship products and don’t fix the issues, it sets a tone with prospective and current customers. There are countless stories such as Drizly and while secure coding practices can’t eliminate a breach, they can minimize the impact when one occurs.

For the remainder of this article, we’ll use the concepts of the NIST Secure Software Development Framework, the NIST DevSecOps and the OWASP Top Ten Vulnerabilities as the backdrop and at a high level[i].

A typical software development lifecycle contains the following phases: Design/Architect, Code, Test, Release, Maintain. Until a time comes when code can be written with zero defects and cyber threats are no longer identified, I’ll continue to promote the last phase of the lifecycle ‘maintain’, as many organizations tend to skip this stage and doing so causes a breakdown in the use of the SDLC and creates future cybersecurity threats, caused by technical debt, defects and vulnerabilities. The maintain phase is where many defects and vulnerabilities that were previously found are readded to the backlog and may not be prioritized for future remediation.

Secure coding principles can be factored into the SDLC to build a secure release by:

• Authentication: Credential management, password policy, attack defense protocols
• Authorization: Role-based access privileges, administrative and secret privileges
• Configuration & Asset Management: Documenting the application packages, libraries, source code and versions
• Data Security: Using encryption, data masking, and data classification to keep data private and secure
• Data Integrity: Meaning that trusted data needs to be accurate and reliable
• Error & Exception Handling: Responding to an issue within the application and determining what to do about it
• User & Session Management: Ending the user’s session after a set amount of time
• Audit & Logging: Creating the files to help in defense purposes
• Coding principles: Using structured coding syntax, the OWASP Top Ten principles as guidelines and engaging in code reviews

Design/Architecture:

In the design/architecture phase, engineers consider security and compliance requirements – such as how the environment is to be configured, where logging is needed, how to authenticate and authorize to gain privileges in an environment. The Engineering, DevOps, and Security teams work on these items and agree on the standards to be constructed for the environment. For privileges, the least amount of privilege in the environment is recommended.

Threat modeling can and should occur throughout the lifecycle. The model works to expose potential threat areas within an application, environment, or network, then diagnoses the reasons for the exposure and defines remediation steps. There are threat modelling tools to help automate the process and can be included as a security measure within the SSDLC.

Code:

In the coding phase, the engineer develops with the OWASP Top Ten practices to remove security vulnerabilities in the code base and tests their code against the secure coding principles to ensure that they are not creating an exposure to industry threats.

The OWASP Top Ten vulnerabilities include:

Broken Access Control: Access controls are not implemented correctly, providing access to unauthorized resources

Cryptographic Failures: Data is exposed, or systems compromised when cryptographic functionality is not implemented correctly

Injection: Untrusted data is sent to an interpreter as a part of a command or query and allows attackers to execute malicious code

Insecure Design: Software not properly designed for security and creates avenues for vulnerabilities

Security Misconfiguration: Security settings are not configured correctly and lead to exploitable vulnerabilities

Vulnerable and Outdated Components: Attackers identify, and exploits known vulnerabilities in older code

Identification and Authentication Failures: Allows the attacker to bypass authentication and gain unauthorized access to systems

Software and Data Integrity Failures: Unvalidated software is subject to data corruption and system compromise

Security Logging and Monitoring Failures: Without proper logging and monitoring, detection and response to security events is difficult

Server-Side Request Forgery: A web application vulnerability allowing the attacker to interact with internal systems

During the coding phase, the engineer utilizes code review principles, where a peer group reviews the requirements of the design phase with the results from the coding phase. In addition to the OWASP Top 10 vulnerabilities, the review considers standards for syntax, naming conventions, languages, open source and configuration standards, security considerations and upon agreement from the peer group, the release moves into the testing phase.

Testing:

In the test phase, automated tools can and should be used to create valid use cases to test for inconsistencies in the code base, including security based on the OWASP Top Ten vulnerabilities. Performance testing is also considered and can identify the threshold of when a DDoS attack can begin impacting the environment. There are many tools in the industry to provide SAST (static) and DAST (dynamic) testing to further test the application.

The outcome of the tests is a number of identified defects in the code and/or security vulnerabilities. An industry scoring method, called CVSS (The Common Vulnerability Scoring System2), where the scoring ranges from 0 (low) to 10 (high) to determine how severe an identified defect is.

Based on the severity of the defect and impact on the service branch, a decision is made regarding the next steps. The options in this step include:

• Fix the issue and return it to the service branch
• Remove the issue from the branch and return it to be fixed in the next release
• Remove the entire release and fix the issue
• Add the issue to the backlog for future prioritization and remediation

Keep in mind that not all high CVSS scored items can be fixed immediately. This is especially true when the highly scored item is too large and impactful to the organization. Vulnerabilities and industry exploits that cannot be remediated quickly and are considered large, impactful or customer facing should be added to the risk registry for monitoring or management review purposes. An example of a large and impactful vulnerability is a software company that finds an exploit in a code library that impacts a large number of customers and needs to be disclosed and fixed quickly (i.e.: Log4J, Spring4Shell, MoveIT).

Release:

In a service branch, code libraries are released frequently. In this type of release process, regression testing isn’t an option as it is in a monolithic application. In a mature engineering team, code libraries are staged in a pre-production environment, tested and the severity of defects and vulnerabilities are captured, in order to make decisions about moving to a production release. Also, in this phase penetration testing is included by a set of skilled security resources, either employed internally to the organization or with external consultants. This one test catches gaps in the code base that could cause an opening for an external threat actor to take advantage of the vulnerabilities within the release. There are tools available that provide continuous penetration testing and these tools are worth looking into subscribing to.

Maintain:

While we all strive to create code with zero defects, this is not normally the case. In the maintenance phase, backlogged roadmap items are introduced to the service branch, as well as remediated defects. When a vendor announces a vulnerability in their software, an assessment is completed to see if/where the vulnerability resides and then changes to your company’s code base should be made - and includes open-source libraries and operating environments – either in the cloud, containers, or physical environments. In general, maintenance involves the ongoing upkeep of the code libraries and their environments and follows the principles set in the SSDLC.

Secure coding practices can be implemented within any engineering team without causing a hardship with existing processes or adding exponential time for delivery. While delivering new features is a fundamental goal for every product company, executives need to ask themselves if their customers would react differently if they knew that the engineering practices were unsecure. Ultimately, your customers will decide what matters to them.

For more information, read my new book: https://a.co/d/cEbRLlI

1 Secure Software Development Framework | CSRC (nist.gov), DevSecOps | CSRC (nist.gov), OWASP Top 10:2021

2 NVD - Vulnerability Metrics (nist.gov)

?