Subscribe
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 Black Duck, noted at RSA Conference in San Francisco in early March, 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.
Meanwhile, the average time it took to detect and contain a breach increased from 206 to 253 days.
2017
$4.03 Million
Lost business
206 days
Average time to identify and contain a breach
Source: 2017 Cost of Data Breach Study (US Data), Ponemon Institute
2018
$7.91 Million
Average cost of data breach
$4.20 Million
Lost business
253 days
Average time to identify and contain a breach
Source: 2018 Cost of Data Breach Study (US Data), Ponemon Institute
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 Black Duck 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.
Solution
All-in-one AppSec platform optimized for DevSecOps
Continue Reading
