Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

9/25/2017
06:30 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Security's #1 Problem: Economic Incentives

The industry rewards cutting corners rather than making software safe. Case in point: the Equifax breach.

There is plenty of blame to go around after the Equifax incident, and I'm not trying to be an apologist for the credit rating company. The problem is that the wrong incentives are driving software development. Unless we change the incentives, security will continue to be a problem. The question remains, what can we do to avoid the "next Equifax"?

The Economics of Software
Let's consider the situation from the perspective of a software organization or a developer. When was the last time that a developer got a bonus or a promotion for taking longer to complete a project because he or she wanted to improve security? When was the last time that a product manager got rewarded for stopping a software release because of a software vulnerability or because of lack of proper security reviews? When was the last time that a software vendor took responsibility for bad code rather than blaming the end users? When was the last time that a venture capitalist upped an investment's valuation because of the company's security processes?

If software were a car, we would be knowingly shipping it with faulty seatbelts or airbags with the hope that there wouldn't be an accident and making the driver sign an end-user agreement that releases all of our liability.

Fast feature delivery is the core incentive in software design. Our mantra is "prototype fast, fail fast." The subtext is "cut corners to test business models faster." The practice is to worry about security when the product is mature and has customers. In reality, this rarely happens because when a product becomes more successful other customer issues and business priorities then eclipse security concerns.

The Equifax Vulnerability
Take, for example, the now infamous Struts vulnerability, via which an attacker can create a special message in the Content-Type HTTP header and achieve remote execution of arbitrary code.

When one looks carefully at the code, it is evident that a parser didn't follow the formal specification. Section 14.17 of the IETF RFC 2616 precisely defines the language and format allowed in the Content-Type field of an HTTP header. Essentially, Content-Type can have a value of one of several media types. (Media types are well-defined here). 

Could we have designed the parser the right way? Could we have predicted all malformed content in this field and avoided the debacle? Could it have been tested ahead of time?

Applying rigorous engineering to the problem would require a formal and mathematically correct parser that would implement the exact definition of the complete standard. It would require fuzzing in unit testing that would catch all violations. We know how to do that, but there are many pages of specifications requiring several days of work that produces no "new feature." In other words, there is no value in this activity for the business. As a result, software developers don't have the time or incentive for such rigor.

Bending Standards, Breaking Security
I am speculating, but it appears that several WAF or firewall vendors had a parser that followed the RFC to the letter. In several incident responses, firewalls enforced this check immediately. I would not be surprised, though, if they were earlier forced to disable it or remove certain security precautions because some applications violated some part of the standard, such as a custom media type that would help in some application feature. Even library or framework developers often don't enforce all parts of standards because some user requires the "customization flexibility" to deliver faster.

Bending the standards or cutting corners to achieve fast software delivery is commonplace. Businesses frequently ask security engineers to remove controls because they "break" the application. Feature delivery takes precedence over security posture because it generates revenue 

Economics Is Killing the "Engineering" in Software Engineering
The behavioral and economic models of software operations provide incentives for fast delivery rather than quality and security. Security does not to add to the top line. Software engineering rigor is often considered an impediment because it would fundamentally change the profitability dynamics of the software industry. This is the fundamental underlying cause of most security vulnerabilities.

But there is hope. The fact that Equifax lost 35% of its market cap in five days, destroying several billion dollars of wealth in the process, could be the trigger to change this equation. Security expert Bruce Schneier, for one, argues for government intervention.

If the economic or regulatory incentives reward applying strict engineering rigor to software design, we will address a significant fraction of our accelerating security breaches. Until then, we will all continue to cut corners to pay the bills or risk getting a bad credit score by Equifax.

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Dimitri Stiliadis is the CEO and co-founder of Aporeto, where he is leading the technology and company vision. Prior to Aporeto, he was the co-founder and CTO of Nuage Networks and CTO of the Non-Stop Laptop Guardian at Alcatel-Lucent. Before that, he has held several leading ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
9/26/2017 | 2:41:09 PM
Re: New Problem same discussion
This article brings back memories of numerous discussions from 15-20 years ago about how to adhere to the SDLC in the fast paced world of the Internet I would agree. It is an old question without a proper answer yet.
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
9/26/2017 | 2:39:30 PM
Re: Great post
Yes, it is a great article pointing out major loop in whole software development process.
Dr.T
0%
100%
Dr.T,
User Rank: Ninja
9/26/2017 | 2:38:42 PM
Re: internet sercruits
you all are lasy devs and programers just because a program says it ok doesnt mean ur dont ur job. That might be true, mostly less about laziness more about not having enough time to check and re-check.
Dr.T
0%
100%
Dr.T,
User Rank: Ninja
9/26/2017 | 2:37:09 PM
Re: internet sercruits
its very smimple to fix all you have to do is get an audit done and emprove on the ave score 200/400 It makes sense however most audit would not catch most vulnerabilities. It needs to be intensive pen test.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
9/26/2017 | 2:34:42 PM
Software development
I would agree with the article. There has to be a better way to develop application so there is incentive to develop secure applications.
xanthan99
100%
0%
xanthan99,
User Rank: Strategist
9/25/2017 | 3:41:11 PM
New Problem same discussion
This article brings back memories of numerous discussions from 15-20 years ago about how to adhere to the SDLC in the fast paced world of the Internet.  I'm not truely sure we ever came up with a solution for that either, reference the iOS 11 update over the weekend.  Security can't be something we leave to the whim of happenstance theory.
martin.george
50%
50%
martin.george,
User Rank: Apprentice
9/25/2017 | 11:17:12 AM
Great post
That is totaly great est post I have seen here) 
rrwillsher1974
50%
50%
rrwillsher1974,
User Rank: Apprentice
9/25/2017 | 10:27:44 AM
internet sercruits
its very smimple to fix all you have to do is get an audit done and emprove on the ave score 200/400. to do this to a score off 400 would stop alot off pppl useing the cracks in programs to do whot ever thay do.

also ppl are not useing a direct attack on ppl but rather useing other ppls web sites we vist as a point off entry ie cookies,poor audit scores, paying for ur padlock form digigroup and not doing your job properly.

you all are lasy devs and programers just because a program says it ok doesnt mean ur dont ur job.
<<   <   Page 2 / 2
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "I feel safe, but I can't understand a word he's saying."
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-10374
PUBLISHED: 2020-03-30
A webserver component in Paessler PRTG Network Monitor 19.2.50 to PRTG 20.1.56 allows unauthenticated remote command execution via a crafted POST request or the what parameter of the screenshot function in the Contact Support form.
CVE-2020-11104
PUBLISHED: 2020-03-30
An issue was discovered in USC iLab cereal through 1.3.0. Serialization of an (initialized) C/C++ long double variable into a BinaryArchive or PortableBinaryArchive leaks several bytes of stack or heap memory, from which sensitive information (such as memory layout or private keys) can be gleaned if...
CVE-2020-11105
PUBLISHED: 2020-03-30
An issue was discovered in USC iLab cereal through 1.3.0. It employs caching of std::shared_ptr values, using the raw pointer address as a unique identifier. This becomes problematic if an std::shared_ptr variable goes out of scope and is freed, and a new std::shared_ptr is allocated at the same add...
CVE-2020-11106
PUBLISHED: 2020-03-30
An issue was discovered in Responsive Filemanager through 9.14.0. In the dialog.php page, the session variable $_SESSION['RF'][&quot;view_type&quot;] wasn't sanitized if it was already set. This made stored XSS possible if one opens ajax_calls.php and uses the &quot;view&quot; action and places a pa...
CVE-2020-5284
PUBLISHED: 2020-03-30
Next.js versions before 9.3.2 have a directory traversal vulnerability. Attackers could craft special requests to access files in the dist directory (.next). This does not affect files outside of the dist directory (.next). In general, the dist directory only holds build assets unless your applicati...