Operations
3/9/2016
11:30 AM
Kunal Anand
Kunal Anand
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
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.

 

Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Five Emerging Security Threats - And What You Can Learn From Them
At Black Hat USA, researchers unveiled some nasty vulnerabilities. Is your organization ready?
Flash Poll
10 Recommendations for Outsourcing Security
10 Recommendations for Outsourcing Security
Enterprises today have a wide range of third-party options to help improve their defenses, including MSSPs, auditing and penetration testing, and DDoS protection. But are there situations in which a service provider might actually increase risk?
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
Join Dark Reading community editor Marilyn Cohodas and her guest, David Shearer, (ISC)2 Chief Executive Officer, as they discuss issues that keep IT security professionals up at night, including results from the recent 2016 Black Hat Attendee Survey.