Products + All Products + Software Integrity + Semiconductor IP + Verification + Design + Silicon Engineering
Posted by Koen Buyens on September 6, 2017
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.
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:
Analysts elicit security requirements from four different sources:
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:
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:
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).
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 software testing life cycle of the overall SDLC includes:
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.
During the release stage, the application is deployed together with its different dependencies to production so that users can work with it. For instance, a TLS-enabled application may be deployed together with the OpenSSL 1.0.1 library.
Security activities in this stage determine whether an application’s dependencies contain known vulnerabilities (and presents ways to prevent these vulnerabilities or minimize their risk). For instance, it detects that an application uses OpenSSL 1.0.1 which is vulnerable to Heartbleed. Software composition analysis tools automate the discovery of these (vulnerable) dependencies.
After application deployment, testers should also perform a red team assessment. During this activity, testers model how a real-world adversary might attack a system. They also verify how well that system would hold up under attack by combining vulnerabilities that may seem small on their own, but when tied together in an attack path can cause severe damage. Just like real attackers, these testers do not only consider weaknesses of the application, but also weaknesses in the environment in which the application is deployed (e.g., network, firewalls, operating system), as well as weaknesses in operating procedures and people (e.g., role-based social engineering).
Education is a fundamental part of any secure software development life cycle (SSDLC). Every team member requires a baseline software security education to increase the awareness of the importance of security and to increase the knowledge of security engineering basics. Groups of engineers may receive advanced education to keep up-to-date with new threats.
The security activities outlined here are only a subset of the activities that different companies implement. You should create a software security roadmap that helps your firm define and build (or mature) a software security initiative (SSI).
Your plan should define a software security strategy as well as select the security activities that make sense for your organization. Initiatives exist to verify how your company stacks up against the rest of your industry peers. It is important that you show with measurements that your SSI improves the security posture of your applications.
Above all, remember that bringing security testing into the SDLC earlier lowers the cost to fix security defects.