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.

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
Oldest First  |  Newest First  |  Threaded View
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.

 

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.

 

 
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.

 

 
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Active Directory Needs an Update: Here's Why
Raz Rafaeli, CEO and Co-Founder at Secret Double Octopus,  1/16/2020
Google Lets iPhone Users Turn Device into Security Key
Kelly Sheridan, Staff Editor, Dark Reading,  1/15/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-16270
PUBLISHED: 2020-01-22
Samsung Galaxy Gear series before build RE2 includes the hcidump utility with no privilege or permission restriction. This allows an unprivileged process to dump Bluetooth HCI packets to an arbitrary file path.
CVE-2018-16271
PUBLISHED: 2020-01-22
The wemail_consumer_service (from the built-in application wemail) in Samsung Galaxy Gear series allows an unprivileged process to manipulate a user's mailbox, due to improper D-Bus security policy configurations. An arbitrary email can also be sent from the mailbox via the paired smartphone. This a...
CVE-2018-16272
PUBLISHED: 2020-01-22
The wpa_supplicant system service in Samsung Galaxy Gear series allows an unprivileged process to fully control the Wi-Fi interface, due to the lack of its D-Bus security policy configurations. This affects Tizen-based firmwares including Samsung Galaxy Gear series before build RE2.
CVE-2019-10780
PUBLISHED: 2020-01-22
BibTeX-ruby before 5.1.0 allows shell command injection due to unsanitized user input being passed directly to the built-in Ruby Kernel.open method through BibTeX.open.
CVE-2019-10781
PUBLISHED: 2020-01-22
In schema-inspector before 1.6.9, a maliciously crafted JavaScript object can bypass the `sanitize()` and the `validate()` function used within schema-inspector.