Context & Awareness: It’s All About The Apps

All of information security is about one thing: Protecting data. To protect data, you need to understand how it is collected, processed, stored, disseminated, and ultimately destroyed when no longer needed. By understanding these things, you will be better equipped to apply focused protections. If you know which systems access your data and what they do with it along the way, you will be better able to make decisions about how to secure it.

But there is another factor that is becoming increasingly important: data context. Understanding your data’s context will tell you who should access it, where it should go, and what should happen to it when it gets there. 

In recent years security solution vendors have been offering a wave of products that leverage context for greater visibility into the data an application inputs and outputs. Solutions with this ability become application-aware, partly manually and partly automated, by using forms of machine learning or heuristics to learn the behavior of applications.

Application-aware solutions such as today’s firewalls, WAF’s (Web application firewalls) and RASP (Runtime Application Self Protection) solutions all compensate for otherwise unsecure applications. A security blogger recently described an unsecure application as akin to "someone taking a walk on a dangerous street at night with no muscles, and no skills." Without external protection, the person is helpless to defend himself. Conversely, when surrounded by a team of bodyguards (i.e., firewalls, WAF’s and RASP), the person is seemingly well-protected. 

Bodyguards can provide protection. However, these bodyguards for your application are all two or more degrees separated from your data. The farther away the protection mechanisms are from your data, the inherently less capable they are at maintaining context which is needed to protect it. In our analogy, the bodyguards here are walking five steps behind the person they are tasked to protect - they could stop some forms of attack but not others.

Throughout its life, data is created and manipulated by applications. This is the closest medium to your data that you have. This is the medium which best understands the data. Until data can protect itself, we need to focus more energy on this medium which has the most data context – the application.

The weak link: application security

Industry analysts report that most data breaches are the result of application security flaws.  Why are applications so often flawed? Applications today are large, complicated, rapidly developed, and contain many unverified third-party components. Software developers are faced with an ever-increasing pace to churn out new features and functionality.

To keep pace with rapid development, software developers often re-use code. Sometimes code samples are brought along from prior jobs, and sometimes they are downloaded from popular code-share sites. Many businesses employ software package managers to allow developers to code-share with third parties. A typical application utilizes hundreds of software packages.  These software packages are designed to be small, re-usable, and to solve a specific problem very well. They are the building blocks of applications, and by sharing packages with other organizations via public registry, businesses extend their capabilities, speed development, and more easily manage code updates.

According to a recent SANS report, 79% of organizations rely on open-source or third-party software libraries in their applications. The fact is, far more of the code in your applications was assembled rather than written by your organization. The economic advantages will not encourage these behaviors to change any time soon. It is simply faster and less expensive to assemble code rather than to write it.

There are obvious security challenges with using third-party code. Since you don’t know who wrote it, you don’t know if a package you wish to use in your application might contain malware, backdoors, or security flaws. Recall that it took nearly two years for the Heartbleed OpenSSL "bug" to be detected. If I were a hacker, I might use a variety of aliases to try to seed popular code share sites with attractive feature-rich code that contains subtle security flaws or backdoors. As my code samples grow in popularity, so might my prospects.

Context & diligence

Context (which is understanding what, how, when, and where) and diligence are the best defenses. Context can be provided by vendors that build a software bill of materials, narrow down the open source and third party packages to those you can better trust, and help you track which of your applications use which packages. According to the Securosis 2014 Open Source Development and Application Security Survey Analysis, the typical application has 106 open source components. With 50 new critical vulnerabilities discovered each day, you need to know which component’s may have vulnerabilities that impact your applications.

Unsafe/untested open source components didn't get into your software on its own. As an industry, we need to spend more energy in training our software developers in secure coding and development practices. An ongoing regimen of secure coding training which combines online CBT’s with classroom and mentoring is capable of delivering a significant ROI for your business.  Also be sure to validate the code in your applications. 

The steps you should follow include:

All of the above goes smoother when security education and awareness, for all involved, is high.  As your software developers increase their secure coding skills, software security tests will find fewer security flaws resulting in less downstream mitigation. By reducing downstream cleanup, your organization will save on mitigation costs, related support expenses, and speed up release time frames...not to mention protection of your company's brand name during the rollout of a new security-hardened application.

Related Content:

Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!