Want to secure your apps? Build security in with the right toolchain

by Taylor Armerding on March 21, 2019

Having the right application security toolchain is the most effective way to build security in, which is critical to securing modern apps against attacks.

Is it worth making more than a minimal effort to avoid data breaches? The answer ought to be obvious by now.

As Tim Mackey, technical evangelist at Synopsys, noted at RSA Conference in San Francisco in early April, data breaches are “serious business.” The price that breached companies pay continues to grow; statistics compiled by the Ponemon Institute for the annual IBM Cost of a Data Breach Study showed the cost of the average breach in the U.S. went from $7.35 million in 2017 to $7.91 million in 2018, and lost business jumped from $4.03 million to $4.2 million during the same period.

“And that didn’t include Equifax or other breaches that were more than $100 million,” he said.

Sponsorships Available

Meanwhile, the average time it took to detect and contain a breach increased from 206 to 253 days.

How to create a modern application security toolchain

So, in a presentation titled “Creating a Modern AppSec Toolchain to Quantify Service Risks,” Mackey said that to create a modern app that is secure enough to withstand inevitable attacks, “I have to take the entire process into consideration.”

“I need to look at it through the lens of DevSecOps. Security must be an integral part of the entire pipeline.”

Which is not as simple as it used to be, given that a modern application includes proprietary code, open source components, API usage, and application behavior and configuration.

The application security toolchain has to start with a process that has quality and security checks “baked in,” he said, quoting the Gartner definition of DevSecOps: “Information security architects must integrate security at multiple points into DevOps workflows in a collaborative way that is largely transparent to developers, and preserves the teamwork, agility and speed of DevOps and agile development environments.”

That, as he noted, means there are “a lot of pieces to the puzzle.”

The “pipeline,” as he put it, involves multiple quality and security checks, including these:

Developer IDE: risk assessment, threat modeling, lightweight static application security testing (SAST), local unit tests
Build: SAST, software composition analysis (SCA), unit tests
Testing: functional tests, load tests, performance tests, interactive application security testing (IAST), dynamic application security testing (DAST), pen testing
Deploy: configuration tests, hardening tests
Production ops: network scanning, continuous monitoring
Feedback: threat intelligence, CVE reports, regulatory changes

All this, he said, will help avoid the parade of horrors that awaits insecure products, including compliance violations of the EU’s GDPR or the new California Consumer Privacy Act, passed last year, although its requirements will not take effect until Jan. 1, 2020.

“It has a direct impact on the success of your product,” he said.

A quick application security toolchain checklist

Mackey broke down the process into goals and tasks, which vary depending on the product you’re building. But they all include identifying security targets, for the obvious reason: “When we deploy, it’s going to be under attack,” he said.

In short, security assessments have to continue through development, build, and deployment. And that can now be done with the Polaris Software Integrity Platform™ with Code Sight™, which Synopsys unveiled at RSA. As Mackey noted, the Code Sight IDE plugin supports most popular IDEs while Polaris enables centralized reporting and analysis with a simple, unified user experience that includes multiple integrated analysis engines—SAST, SCA, IAST, DAST, pen testing, and network testing.

So, to build the dream app that will withstand inevitable attacks, he offered this quick checklist:

Define security targets when selecting components and toolchains. Ensuring that ops, development, and procurement understand the criteria. Train DevOps teams to identify changes in risk. Document decisions that impact risk acceptance at all points in the SDLC.
Measure progress against targets and changes in direction. Identify opportunities to reduce business risk with new technologies. Design update mechanisms for resiliency against man-in-the-middle (MITM) attacks. Realize that legacy best practices become obsolete—they may increase risk when applied to new paradigms.
Reduce risks of noncompliance. Continuously monitor all deployed apps, complete with dependency inventory. Reassess the impact of new regulations. Compare running infrastructure against configured infrastructure for deltas.

“When you plan your next big idea, don’t start with features. Define security targets with a clear understanding of how your features might be attacked,” Mackey said.

Integrate security into my development pipeline