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.

Vulnerabilities / Threats

4/7/2016
10:30 AM
Curtis Dalton
Curtis Dalton
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Context & Awareness: Its All About The Apps

Why data context, application awareness and training are keys to mitigating security risks,

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.

  • An application collects your data
  • An application processes your data
  • An application stores your data
  • An application disposes of your data when you no longer need it

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:

  • Enable compiler warning flags and teach your software developers to pay attention to these warnings
  • Have your software developers perform regular Static Application Security Testing (SAST) during the development cycle; if you do this correctly, they simply press a button to execute the tests and see the results immediately so they can fix them immediately (an inherent learning aid as well!)
  • Perform Dynamic Application Security Testing (DAST) prior to production release
  • Perform system vulnerability testing prior to release to ensure the OS platform your application resides on is sufficiently hardened
  • Perform known malware testing (think how stupid you would feel if your prize app went into production with known malware on it)
  • Request sign-off from stakeholders prior to releasing the app into production (e.g., Engineering, Security, IT, Operations, Legal, Compliance, and the business)

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!

Curtis Dalton is an information security and technology executive with 24 years' experience and a proven track record in management, technology and security. Prior to joining Pactera, Dalton was Chief Information Security Officer for Sapient - a global IT services and digital ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
The Yellow Brick Road to Risk Management
Andrew Lowe, Senior Information Security Consultant, TalaTek,  11/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: He hits the gong anytime he sees someone click on an email link.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-29070
PUBLISHED: 2020-11-25
osCommerce 2.3.4.1 has XSS vulnerability via the authenticated user entering the XSS payload into the title section of newsletters.
CVE-2020-26212
PUBLISHED: 2020-11-25
GLPI stands for Gestionnaire Libre de Parc Informatique and it is a Free Asset and IT Management Software package, that provides ITIL Service Desk features, licenses tracking and software auditing. In GLPI before version 9.5.3, any authenticated user has read-only permissions to the planning of ever...
CVE-2020-26243
PUBLISHED: 2020-11-25
Nanopb is a small code-size Protocol Buffers implementation. In Nanopb before versions 0.4.4 and 0.3.9.7, decoding specifically formed message can leak memory if dynamic allocation is enabled and an oneof field contains a static submessage that contains a dynamic field, and the message being decoded...
CVE-2020-25650
PUBLISHED: 2020-11-25
A flaw was found in the way the spice-vdagentd daemon handled file transfers from the host system to the virtual machine. Any unprivileged local guest user with access to the UNIX domain socket path `/run/spice-vdagentd/spice-vdagent-sock` could use this flaw to perform a memory denial of service fo...
CVE-2020-29071
PUBLISHED: 2020-11-25
An XSS issue was found in the Shares feature of LiquidFiles before 3.3.19. The issue arises from the insecure rendering of HTML files uploaded to the platform as attachments, when the -htmlview URL is directly accessed. The impact ranges from executing commands as root on the server to retrieving se...