Vulnerabilities / Threats
9/25/2017
06:30 AM
Connect Directly
LinkedIn
Twitter
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 1 / 2   >   >>
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
9/30/2017 | 12:25:38 PM
Commercial
> 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.

This may be one of the fundamental disadvantages of open source compared with proprietary.

Commercial developers of software do have an economic incentive to do a lot of this with their systems. Open-source contributors? Not so much necessarily. Therefore, open-source systems may thus put this onus on the enterprise customer...who generally almost certainly doesn't have the resources to invest in this stuff.

(To be fair, companies like Red Hat and Mirantis, which provide support for their builds/"flavors" of open-source software, also have this incentive to an extent because of their support contracts/business model. Commerce makes the world go round.)
rrwillsher1974
50%
50%
rrwillsher1974,
User Rank: Apprentice
9/29/2017 | 7:00:34 AM
Re: internet sercruits
Lol lol lol audit is gd it tells u if the basics are done but u can still see irregular file names in script http they just found a new way
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
9/29/2017 | 4:40:11 AM
Re: Software development
I'm not so sure it's off topic considering this is pretty much the same thing I thought of at first too.

Consumer IoT security flaws proliferate because of the lack of economic incentive to go the extra mile to prevent/fix them. If your fridge gets hacked for use in a botnet, it still works as a fridge just fine.

This is why many have called for legislation/regulation in this area. Meanwhile, some enterprises/professionals are trying to get industry to unite around standards so that they can avoid government stepping in.
Joe Stanganelli
100%
0%
Joe Stanganelli,
User Rank: Ninja
9/29/2017 | 4:37:10 AM
Re: internet sercruits
At the same time, a good audit score isn't the same thing as having good security practices. I can't tell you the number I've times I've observed enterprise environments/scenarios where people "check the box" when they aren't actually doing the thing that they're checking the box for.
moberdacker152
50%
50%
moberdacker152,
User Rank: Strategist
9/28/2017 | 12:49:35 PM
Re: Software development

This may be slightly off topic, but this kind of thing is exactly why I don't yet own a thermostat, or refrigerator with internet connectivity.  I love the idea of them, but as far as I've been able to tell so far, not one IoT device has much, if any built, in security.  Unfortunately, this doesn't stop enough people from buying them though to force the manufacturers to produce secure IoT appliances.

 

The way it is now the companies developing the software seem to feel features trump security.  I don't know of a software developer that produces software that is very secure but with fewer features than their competitors'.  They're afraid to try, because if it doesn't work, they could end up not being able to recover financially.  Personally if I had the choice between a secure software product with the basic features I need and an insecure one with nice to have features I'd choose the secure software every time, assuming similar costs.

jacekmaterna
100%
0%
jacekmaterna,
User Rank: Apprentice
9/27/2017 | 11:27:04 AM
moving security to the "left" in SDLC will never occur without $ incentives-
Security in the SDLC has long be an after-thought. Why would it be any different? Business owners are rewarded for KPis on speed and releases over quality. Few firms today operate in reverse. Why? Because the marketplace demands more speed and more features faster than the day before. Impossible to change that macro environment. Best that could happen is that some combo of regulation comes in to move risk management and security to the "left" - its 10x cheaper to find issues in the source code than when to do it after the products are deployed globally, etc. Human nature will always take least resistent path. I am no fan of regulation but in this case there needs to be some to create value in security in the SDLC - incentive via $$ impact will get business owmners attention. GDPR is a great step- it has real teeth (albeit being super vague).
rrwillsher1974
50%
50%
rrwillsher1974,
User Rank: Apprentice
9/26/2017 | 3:06:49 PM
Re: internet sercruits
It's simple just ask there will be a nominal cost, overheads and expenses
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.
Page 1 / 2   >   >>
Printers: The Weak Link in Enterprise Security
Kelly Sheridan, Associate Editor, Dark Reading,  10/16/2017
20 Questions to Ask Yourself before Giving a Security Conference Talk
Joshua Goldfarb, Co-founder & Chief Product Officer, IDDRA,  10/16/2017
Why Security Leaders Can't Afford to Be Just 'Left-Brained'
Bill Bradley, SVP, Cyber Engineering and Technical Services, CenturyLink,  10/17/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
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
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
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.