Application security starts with thoughtful design and development

Key takeaways

 

• ISO 27001/27002 updates provide a roadmap to incorporate security testing early on in the development workflow.
• Regular security testing throughout the pipeline – both static code analysis and dynamic application testing – can minimize the number of vulnerabilities that make it into production.
• Collaboration among developers, security teams, and project management is vital to integrate security features effectively into applications and treat security as a core aspect of development rather than an add-on.

When the International Organization for Standardization updated its ISO 27001 and 27002 documents last fall to address the full software development life cycle (SDLC), it specified “security in the software development methodology” and “security requirements in the specification and design phase” as key components of software security. While all organizations should follow these requirements, exactly how development teams go about providing the necessary security is far more complex than a one-size-fits-all series of workflows and goals. Incorporating security best practices all through design and implementation is crucial to prevent vulnerabilities that leave web applications open to attack.

A security-first approach

Infusing security into application specifications and development workflows requires a deliberate plan since bolting on security at a later stage will likely lead to an insecure final product. From the initial design phase, the security workflow should be well-documented to track progress, flag issues, and document improvements. The workflow may start with asking basic risk assessment questions: How will user accounts be protected and encrypted? Will the user require a password and, if so, what kinds of passwords are acceptable? Does accessing accounts require multifactor authentication? Software engineers can answer those questions by defining security requirements that, for example, require strong passwords during account creation or enable two-factor authentication by default. 

But as development goes on, those answers may become more complex and need to factor in vulnerabilities specific to the type of application and how it’s deployed, like paying special attention to testing application program interfaces (APIs) for cloud-based applications. Vague security goals or poor threat assessment can lead to extra work and delays as teams struggle to address unclear security concerns or deal with the results of testing that is done as an afterthought.

A security-first approach is also important during code reviews so that new or modified code nearing completion or implementation doesn’t add new vulnerabilities or issues, such as authentication flaws. Code reviews that emphasize security also create opportunities for application developers to share knowledge and best practices with the rest of the team, which can strengthen the security of future designs.

Finding and addressing vulnerabilities

Vulnerabilities can appear at any point in the SDLC, so how teams record them – and the way they are resolved – is crucial to ensure nothing is overlooked. Projects should have a specific change control process to approve requested changes and serve as a record for the future.

For more thorough and reliable security testing, modern security workflows often use a hybrid of automation and manual tasks to identify and fix vulnerabilities, creating a more secure end product without impacting release deadlines. Many teams use a combination of static application security testing (SAST) with dynamic application security testing (DAST). SAST tools scour source code in search of vulnerabilities, whereas DAST tools explore the entire attack surface of a running web application and scan it for vulnerabilities. To be most effective – and in alignment with ISO’s updated guidance – both types of tools should be integrated from the beginning of an SDLC to automatically scan for vulnerabilities at every stage of development. 

Many development teams use a rapid continuous integration and continuous delivery (CI/CD) workflow by automating many of the steps needed to test, upload, and deploy new code to a live application. Integrating security testing into the CI/CD cycle is critical to resolve newly identified threats because it allows developers to quickly add new code to a live application and streamlines release cycles.

Security for agile development workflows

The most common development workflow used today is agile and incremental, replacing the traditional waterfall methods that typically relied on an isolated testing phase performed after development work was complete. Agile workflows are especially conducive to collaboration among developers, security teams, and stakeholders to ensure that security is a core part of the project from day one. Coupled with DAST, an agile workflow enables web apps to be developed and updated continuously without compromising security. It also gives developers the time to discover vulnerabilities early in the SDLC – before they become bigger, more expensive problems – as well as the ability to prioritize vulnerabilities based on severity.  

The bottom line

Even without the updated ISO standards putting it in writing, developers can’t wait until the end of the development process to test their web apps for vulnerabilities. Rather, security must be “designed and implemented within the secure development life cycle of software and systems,” as the standard puts it. By following this guidance and implementing strategies like automated DAST testing, secure design choices, and security-first code reviews, developers can feel confident that their web apps are secure as well as functional when they go into production.