Perimeter

6/8/2017
10:00 AM
Jim Routh
Jim Routh
Commentary
Connect Directly
LinkedIn
Twitter
RSS
E-Mail vvv
50%
50%

The Economics of Software Security: What Car Makers Can Teach Enterprises

Embedding security controls early in the application development process will go a long way towards driving down the total cost of software ownership.

Meg McCarthy and Gary McGraw, Ph.D. also contributed to this article.

For enterprise executives, perhaps the best way to think of software development is as a specific kind of manufacturing process, like building cars. If a car assembly line process produced dents in the passenger side door in 10 out of every 100 cars, the defect rate would be flagged by the quality control manager. Manufacturers could address the problem by hiring staff to bang-out the dents, paint and buff the doors, and then ship the cars to the dealers as planned. This post facto correction would all cost money, but the assembly line could keep rolling uninterrupted and the only impact would be a higher unit cost to fix the dented cars.

An alternative approach would be to research the root cause of the dents in the car doors and adjust the process driving the robotics that assemble the doors to avoid making the dents. This approach would likely involve stopping the assembly line to correct the problems but the unit cost of this change may well be lower than the unit cost of the “banging out the dents” approach.  Put in terms of economics—the total cost of manufacturing in the corrected assembly method will be lower than with the “banging out the dents” method, despite temporary stoppage.

Now back to software security. When it comes to embedding software security controls in the software development lifecycle, we may have to stop the car assembly line and incur some up-front cost in terms of changing the way we build software, but over time this cost will be properly amortized into the total cost of development. 

Consider that there are two types of security controls available: controls that prevent defects before release and controls that detect defects after release. A good example of a preventive control is secure code review with an automated tool that helps to identify bugs in the source code well before software ships or is put into production. Detective controls identify defects as well, but only after release.

From an economic standpoint, preventing a defect eliminates the need to “fix” the defect reactively after the software has been shipped.  For example, if we put in a control aimed to find security defects in an input/output validation routine during coding, there is no need for an engineer to spend time fixing a defect after release since that kind of defect will never exist. As it turns out, not all defects can be prevented in advance of release.  In general, data show that the earlier in the lifecycle security controls are added, the better things look economically.  Controls that identify the defects in the development process are, in fact, essential to a software security initiative in addition to detective controls. And the factor of time in this case equates to money measured by the cost of the developer that has to fix detected defects.

Bang out the Dents = Penetration Testing
When it comes to securing web and mobile applications today, the most common detective security control is known as application penetration testing. A penetration test is run after the application is developed—meaning the design is done, the code is implemented, standard QA testing is finished, and the application is ready for use.  Fixing defects at this stage of the game is expensive. 

In economic terms, penetration testing looks an awful lot like banging out the manufacturing dents in a car door. For example, performing secure code review with a static analysis tool allows developers to identify defects as they are writing code, which we have established is far cheaper than finding a bug during penetration testing.

We have measured developer time savings relative to software security at a large health insurer.  We compare a software development process with no controls (or with penetration testing only) to a software development process with the preventative controls applied early in the process. 

In our case study, a large health insurer had a limited set of detective controls in place for a subset of web applications in 2013. The organization then implemented preventative controls applied early in the development lifecycle. Using the 2013 case as the baseline, we subsequently measured the required developer time to fix defects assuming all high- and medium-risk defects discovered eventually need to be fixed for all applications.

We measure software defects using a relatively simple measure of software defect density: the number of medium and high risk software defects for every 10,000 lines of code written. In the first case, we track the number of high- and medium- risk defects prevented with security controls embedded in the software development lifecycle. Defects prevented are measured against the baseline. The cost of fixing the prevented defects represents a clear productivity savings since no developer fix time is necessary if no defect exists. This measurement uses a static analysis tool to identify the defects by risk during development.

Image Source: Jim Routh
Image Source: Jim Routh

In the second case, we identify all defects detected early in the lifecycle using preventive controls for developers and compare the actual time to fix medium- and high-risk defects with the baseline case. The difference according to this analysis also represents a clear productivity gain. We use defect density counts from both development and the quality assurance/testing phase to determine productivity gain. The second measure uses a dynamic scanning tool typically used by software quality testers that automatically scans run-time versions of applications, and applies a risk criteria to separate defects into high- and medium-risk classifications.

Embedded Security Controls Boost Developer Productivity
The data demonstrate a significant gain in productivity with the security controls embedded in the development process over the baseline. In our case study under analysis one, the productivity delta is just under $21M annual gain in productivity (developer time reinvested in additive functionality) on a base of approximately $1.5 billion spent on development.Enterprise software security initiatives can easily develop a business case of higher productivity to justify investment in software security controls just as we have done. 

Image Source: Jim Routh
Image Source: Jim Routh

Finally, we want to state for the record that we believe our economic model applies for software-based commercial products as well as enterprise software.  Businesses focused on commercial products can and should encourage the same type of preventive controls we applied in our enterprise development situation.  The underlying economics are no different, and, perhaps surprisingly, the tech stacks are exactly the same.

Ultimately, this approach provides benefit to both the manufacturer and the customer. Building a car with hundreds of millions of lines of code?  Integrate software security.  Creating the next great Internet thing?  Integrate software security. The economic best interest of every firm developing software is to follow this lead.

Find out more about which activities, practices, and controls work for software security by visiting http://bsimm.com.

Check out the all-star panels at the 'Understanding Cyber Attackers & Cyber Threats' event June 21 and get an in-depth look at your cyber adversaries. Click here to register. 

Related Content:

 

 

Jim Routh is the chief security officer and leads the global security function for Aetna. He is the chairman of the NH-ISAC Board. He serves on the board of the National Cyber Security Alliance and is a member of the Advisory Board of the ClearSky Security Fund. He was ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, no, no! Have a Unix CRON do the pop-up reminders!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.