Why Security & DevOps Can’t Be Friends

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:

Find 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.