Operations

3/9/2016
11:30 AM
Kunal Anand
Kunal Anand
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Why Security & DevOps Cant Be Friends

Legacy applications are a brush fire waiting to happen. But retrofitting custom code built in the early 2000's is just a small part of the application security problem.

Security hasn’t changed much in the last 10 years. Companies still use pattern matching and pattern-based defenses which aren’t enough to protect websites and company data from the bad guys.

Hackers continuously find unique ways to create fuzzing techniques or to perform fuzzing to create new exploits, and a lot of companies can’t run regular expressions, and most can’t use pattern matching to defeat that. The great inequality in security is that the good guys have to be right every single time. The bad guys just have to be right once.

In order to protect against cross-site scripting (XSS) or SQL injection (SQLi), why not look at application security through the lens of a web browser or a database engine? What if there was a unique way to solve these problems instead of just solving it at the perimeter? Why don't companies protect from within the application where they have access to contacts and important contextual information? Most say it's lag time, or performance issues that inhibit this kind of solution. But I’m not so sure.

Built-in AppSec

Perimeter-based defenses look at basic content and their prior knowledge to make judgment calls. However when security is built inside the application itself, context (Who, what, when, where, why) is used to make decisions and is much more powerful and accurate.

Today, we have to make remediation easier and cheaper. Otherwise, the web is going to continue to become more and more insecure, partially because companies are not fixing known vulnerabilities. So perhaps a more important question to ask is: Why aren’t companies fixing known vulnerabilities?

Most of the time, it comes down to the raw development environment. This is not the environment of  CVE vulnerabilities where you can just patch Windows, patch Oracle or whatever the case may be. This is custom web application code written by developers, likely in-house or outsourced, who may or may not still be working at the company.

Legacy applications are a brush fire waiting to happen. Cross-site request forgery (CSRF) didn't exist 10 years ago. It didn't have a name or terminology. It wasn't in the lexicon. A lot of applications that were developed in the early 2000’s, are still being used today. In many industries, such as finance or oil and petroleum, there are legacy applications still running in production, running on the web. Those legacy applications have lots of problems and the developers are no longer available. There are no budgets associated with them. No one knows, in some cases, where that code even is. It's just this “thing” that's running in a production environment.

ROI of fixing vulnerabilities 

There's a huge use case to go back and retrofit security into an application by putting it within the application that can instrument the app to try and protect against cross scripting, CSRF, SQL injections. And it can be done through LANGSEC-based solutions. LANGSEC, a university research topic that is now being brought to market, is an emerging field of digital security that treats code patterns and data formats as languages and their grammars for the purpose of preventing the introduction of malicious code into software.

LANGSEC is like understanding the meaning of the “sentence” versus simply knowing the “words” (unlike a parrot that can repeat words when trained, but fails to understand). LANGSEC removes obfuscation/fuzzing on data input so that security protections can be accurately applied at the “moment of truth”, otherwise known as code execution. Think of it as a real-time compiler for data input that is built from the grammars of web browsers, databases, and operating systems and helps neutralize application attacks like XSS and SQLi.

But here is another important question: Do companies create revenue-generating features that, if they don't ship, will for a fact, cost the company money? Or do they decide to use the limited development resources they have to fix vulnerabilities that might get exploited and might cost the company money? When faced with this choice between the certainty of features and the uncertainty of vulnerabilities, companies go with the sure thing: features. Hence, the problem continues. If we can make the process easier for remediation, it becomes that much more attractive to do so.

There's a huge question about whether companies are willing to go back into the application and build security in from the ground up. Are organizations ready to embrace something brand new? Companies straddle the line all the time. The security teams love it, but when you talk to developers, they're very curious but unsure.  They ask, "This is going into the application? What does that mean?"

What it means, simply, is that to secure companies today, we have to think and work differently.

Related Content:

 

Interop 2016 Las VegasFind out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Register today and receive an early bird discount of $200.

Kunal Anand is the co-founder and CTO of Prevoty, a next-generation application security platform. Prior to that, he was the Director of Technology at the BBC Worldwide, overseeing engineering and operations across the company's global Digital Entertainment and Gaming ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
weekstweets
50%
50%
weekstweets,
User Rank: Author
4/9/2016 | 11:15:41 AM
Not about DevOps
I agree, the column really focuses on legacy applications and not DevOps related practices.  Rugged DevOps practices are being established in many organizations to embed automated security analysis very, very early and often in the development lifecycle.  

 

The position in this article that security has changed in the past few years is absolutley spot on.  One reality of this is that the velocity requirements for Dev and Ops has accelerated over the past few years.  The other thing that changes the game is that Rugged DevOps embeds security practices in: a built in vs. bolt-on approach.  Built in approaches establish better understanding, empathy, and performance.  Bolt on approaches are typically challenged with siloed thinking.

 

 
weekstweets
50%
50%
weekstweets,
User Rank: Author
4/9/2016 | 11:14:50 AM
Re: Click bait?
I agree, the column really focuses on legacy applications and not DevOps related practices.  Rugged DevOps practices are being established in many organizations to embed automated security analysis very, very early and often in the development lifecycle.  

 

The position in this article that security has changed in the past few years is absolutley spot on.  One reality of this is that the velocity requirements for Dev and Ops has accelerated over the past few years.  The other thing that changes the game is that Rugged DevOps embeds security practices in: a built in vs. bolt-on approach.  Built in approaches establish better understanding, empathy, and performance.  Bolt on approaches are typically challenged with siloed thinking.

 

 
schwartzathon
50%
50%
schwartzathon,
User Rank: Apprentice
3/29/2016 | 4:13:48 PM
Click bait?
Interesting article with some good points, but it never addresses the DevOps approach to integrating security throughout the SDLC, and fails to consider the Defense in Depth practices espoused by SANS, OWASP, and government entities. Instead, the article proposes LANGSEC as something of a silver bullet for retrofitting security.

 

6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/2018
6 Reasons Why Employees Violate Security Policies
Ericka Chickowski, Contributing Writer, Dark Reading,  10/16/2018
Getting Up to Speed with "Always-On SSL"
Tim Callan, Senior Fellow, Comodo CA,  10/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Latest Comment: Too funny!
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10839
PUBLISHED: 2018-10-16
Qemu emulator <= 3.0.0 built with the NE2000 NIC emulation support is vulnerable to an integer overflow, which could lead to buffer overflow issue. It could occur when receiving packets over the network. A user inside guest could use this flaw to crash the Qemu process resulting in DoS.
CVE-2018-13399
PUBLISHED: 2018-10-16
The Microsoft Windows Installer for Atlassian Fisheye and Crucible before version 4.6.1 allows local attackers to escalate privileges because of weak permissions on the installation directory.
CVE-2018-18381
PUBLISHED: 2018-10-16
Z-BlogPHP 1.5.2.1935 (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments.
CVE-2018-18382
PUBLISHED: 2018-10-16
Advanced HRM 1.6 allows Remote Code Execution via PHP code in a .php file to the user/update-user-avatar URI, which can be accessed through an "Update Profile" "Change Picture" (aka user/edit-profile) action.
CVE-2018-18374
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.