A journey through the secure software development life cycle phases

Most organizations follow common development processes when creating software. Unfortunately, these processes offer little support to construct secure software as they typically identify security defects in the verification (i.e., testing) phase. Fixing defects that late in the software development life cycle (SDLC) is often quite expensive. A better practice is to integrate security activities across the SDLC–from the planning phase to release. This helps discover (and fix!) defects close to the time they're introduced.

Join us on a journey throughout the different phases of the SDLC where we’ll introduce common security activities to employ in each stage.

Start your journey with a strong plan

During the planning stage, analysts work closely with stakeholders to determine functional and non-functional application characteristics (such as performance). For instance, clients using a mobile banking application must be able to perform wire transfers.

Security activities during this stage evoke security requirements. First, let’s distinguish between functional and non-functional security requirements:

• Functional security requirements document security functionality (i.e., behavior) that the application should include. For example, "the application shall lock the user out after five failed login attempts."
• Non-functional security requirements describe something that the application must be. For example, "server audit logs shall be verbose enough to support forensics and must include a server time stamp, action performed, the identifier of the person invoking the action, system state before and after the operation, etc."

Analysts elicit security requirements from four different sources:

• Laws and regulations
• Commercial considerations
• Contractual obligations
• The application itself

Laws and regulations prescribe how to process personal information. Contracts with payment processors prescribe how to store financial data.

The application itself is a rich source of requirements as well. Analysts evaluate how the application functionality can be abused and document these areas as abuse cases (the security equivalent of use cases). An example of this might be a customer using the file upload functionality to upload malware.

This leads into an important point. Writing effective security requirements is not straightforward.

Security requirements must be:

1. Testable
2. Unambiguous
3. Measurable
4. Complete
5. Consistent

Design

During the design stage, architects make high-level design choices that meet the accepted requirements. They break down the application into various components and prescribe the technology stack. For instance, the architect may establish that the application is a mobile app that communicates with a REST back-end developed in Java and deployed in the cloud.

Years of experience have taught us that half (yep, you read that correctly) of the software defects that create security problems are introduced in this stage. Security activities in this stage review designs to uncover these security flaws. An example of such a weakness is a mobile banking application that does not communicate with its REST API over a secure channel, such as TLS. Different activities execute design reviews at different levels of rigor:

• Security Control Design Analysis (SCDA) determines if security controls align with or violate industry best practices. For instance, it may detect that a password is stored in plain-text (e.g., Password01) rather than in a salted hashed format (e.g., 45918C9ABC755E3958DE66CC7B0EE446276CEAE9836CB457C8C71FB28F970F26).
• Threat Modeling represents the ways different types of threat agents might interact with the attack surface of the application to help bring vulnerabilities to light. For instance, it may detect that a malicious insider at the bank can access financial information as the internal back-end does not perform access control checks.
• Architecture Risk Analysis adds dependency analysis and known attack analysis to threat modeling, looking for flaws which could allow attacks to succeed. For instance, it may discover that the banking test systems use production data as test input. Architecture Risk Analysis ranks technical risks per severity.

Implementation

During the implementation stage, developers complete the application per established specifications. Security activities in this stage focus on technology-specific secure coding guidelines as well (automated) code reviews.

Technology-specific guidance is typically in the form of checklists that help developers implement things securely. Checklists may also contain things to avoid along with secure alternatives. The guidelines should be actionable (i.e., how do I implement this securely?) and language- or framework-specific (e.g., in Node.js). For instance, PHP developers should use libsodium’s crypto_aead_aes256gcm_encrypt function to encrypt data (rather than the outdated mcrypt’s encrypt function).

Code reviews verify whether developers made such security mistakes. Tools that automate such code reviews are called static application security testing (SAST) tools. These tools can offer comprehensive and preventative solutions depending on your needs. These tools also integrate into standard development environments (such as Eclipse) so that developers are informed about security mistakes as soon as they create them. It works similarly to a spellchecker that detects misspelled words as soon as they’re typed.

These tools also integrate into a CI/CD pipeline so that developers cannot merge newly created insecure code with production code (as they do not pass the automated security tests).

Verification

During the verification stage of the SDLC, developers and/or testers examine their applications for defects. An example defect is that the transfer button of the mobile banking app doesn't function when someone enters an amount smaller than 1.

Security activities in this stage look for security defects in the application while it runs. Examples of security defects include:

• The mobile banking application allows transfers of negative amounts (i.e., the money is moved from someone else’s account to yours)
• The mobile application stores the user’s password in plaintext on the SD card
• The rendered webpage is vulnerable to cross-site scripting

The software testing life cycle of the overall SDLC includes:

• Penetration Testing (pen testing). The tester examines a computer system, network, or (web) application to find vulnerabilities that an attacker could exploit. For instance, a tester of the banking application could verify whether the application locks the user out after a certain number of failed password attempts. If that is not the case, an attacker may be able to brute-force passwords. The tester can use dynamic application security testing (DAST) tools that help automate these tests. As such, tools produce false positives (results that are not exploitable) and testers then need to verify each of the discovered findings.
• Fuzz Testing. The tester finds vulnerabilities by sending intentionally malformed input to the application. For instance, a tester could send malformed TLS packets to TLS endpoint of the banking server (i.e., the other side of HTTPS). Fuzzing tools automate this process by creating malformed inputs, delivering that input to the target software, and detecting application failures.
• Interactive Application Security Testing (IAST). Combines DAST with a runtime component to lower false positives. The runtime component is interwoven into the application's runtime (e.g., into the server-side JVM). Thus, it has insight into the code path taken by the application as a result of the attack performed by the DAST tool. This helps the IAST tool to reject attacks that are likely to be false positives.

Naturally, testers specialize in different architectures and technology stacks so that they can perform tests effectively and efficiently. Mobile, web, embedded applications, thick clients, and Internet of Things (IoT) all require a specialized skill set.