Application Security

3/28/2014
09:00 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Flying Naked: Why Most Web Apps Leave You Defenseless

Even the best-funded and "mature" corporate AppSec programs aren't testing all their web applications and services. That leaves many applications with no real security in place.

Imagine for a moment a major airline only checking 10 percent of its fleet for safety problems. Now imagine that when they do check an aircraft, they find 22 safety problems (some major, some minor). That would represent a crazy business risk for any airline. Roughly 90 percent of the fleet wouldn’t be checked for safety and mechanical problems. That would never fly. But yet, I am here to tell you that 90 percent of applications in most organizations are naked -- since they have no application security defenses in place.

When I say "application security" I’m not talking about infrastructure, operating systems, firewalls, intrusion detection systems, etc. I’m talking about the custom code you wrote for your business, internal and external. The defenses we have for these custom applications don’t work. Not surprisingly, this is where 54 percent of the breaches come from. Here’s why they aren’t protecting us:

Network security products work because they know what’s behind them. They know that they’re defending Windows, MacOS, Internet Explorer, and Google Chrome so they know how to identify attacks on those products and stop them. Custom application code is different. Every custom application is a beautiful and unique snowflake; you can’t identify attacks on these snowflakes by looking at network traffic. Period. Only the application knows what defenses are in place and what input will allow an attack to succeed. The trick is knowing how to get this knowledge out.

The image below is an attack on one of those snowflakes that happens to process Morse code.

In fact, this is a Cross Site Scripting (XSS) attack encoded using Morse code. To state the obvious, there is no product on the planet that stops attacks in Morse code. I use this exaggerated example to make a very serious point. The attack could be a number, a short string of any characters, a null byte, anything... There is no way to know what an attack is unless you know the application itself.

Application security programs aren’t working
I’ve been in the application security field for a few decades now, and I’ve worked on AppSec programs at almost a hundred companies and federal agencies. What I see is that most organization have hundreds or thousands of web apps and web services. Yet even the best funded and "mature" programs are only really testing 10 percent of their applications. That leaves 90 percent naked, with no real security. And many of the breaches you read about are against the 90 percent. The 10 percent are in pretty bad shape, too, averaging 22.4 serious vulnerabilities per application.

These stunning numbers come from Aspect Security’s "2013 Global Application Security Risk Report." We used a combination of manual code review, manual penetration testing, and automated tools to analyze thousands of critical applications. The most prevalent vulnerabilities are: Identification and Authentication, Input Validation and Encoding, Session Management, Sensitive Data Protection, and Access Control. Compare these results with similar results from tool vendors, and you’ll see a striking difference -- because tools alone can’t effectively test for at least three of the top five categories.

 Click to continue to page 2: The Way Forward

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Page 1 / 2   >   >>
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/28/2014 | 12:51:23 PM
Continuous application security approach
Curious to know how common -- or uncommon -- it is for organizations to take a "continuous security approach." What are some of the biggest challenges? Who within the Dark Reading community has considered or attempted such a strategy? 
RyanSepe
100%
0%
RyanSepe,
User Rank: Ninja
3/29/2014 | 11:20:43 PM
Re: Continuous application security approach
I know from being in the Healthcare Industry that application security is a large concern. My team has not been able to test app security continuously because for us there are regulations that make it increasingly difficult. This is why continuous network security is the main focal point, but as the article delineates, this does not have much effect on the app vulnerabilities.

For my previous statement regarding regulations making this difficult, take into account the following healthcare scenario that happens quite often. An FDA approved device can perform a medical task. This device needs to be used and functionality is the biggest proponent when creating these devices. This device has a software counterpart that not "speaks" to the device to extract data. The computer software can be locked down via LDAP/ other authentication methods etc but what about any software direclty on the device. Currently, many devices can be considered "smart" devices in which they have their own software directly on the device to handle and transmit data through many mediums. Many FDA devices cannot not handle multiple security safeguards and are initally barely locked down at launch making them increasingly harder to secure. Has anyone had a similar situation in their line of work and how have they handled this situation?
WireHarborSec
50%
50%
WireHarborSec,
User Rank: Apprentice
3/31/2014 | 12:37:25 PM
Large-Scale AppSec Programs
In my previous role I managed the appsec team with a company who's portfolio spanned over 3K applications. The *only* way to scale appsec programs to this size is by using a continuous-type approach. Internal pen-testing teams cannot keep up. 

Add in agile development methodology and it gets even more chaotic. 
Randy Naramore
50%
50%
Randy Naramore,
User Rank: Ninja
3/31/2014 | 3:05:39 PM
Re: Continuous application security approach
I work in the banking/finance industry and we test "all" web apps prior to being deployed, it is a necessity and any findings that are in the high or medium categories have to be fixed before going live. We test and code according to the OWASP secure coding practices which takes to time for developers to adhere to. This approach helps us.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/31/2014 | 3:09:48 PM
Re: Continuous application security approach
Thanks, Randy. How long have you been folloowing these practices? What has been your biggest challenges and successes?
Randy Naramore
50%
50%
Randy Naramore,
User Rank: Ninja
3/31/2014 | 3:18:22 PM
Re: Continuous application security approach
We have been doing this for the last 10 years at least, one challenge is to make sure developers use secure coding techniques it helps the security testers to develop a best practices approach to their whole web app program. This approach must have buy in from management because when vulnerabilities are found the decision must be made to not go live until remediation is complete. The business reputation depends on it.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/31/2014 | 3:25:10 PM
Re: Continuous application security approach
thanks. I can see how important app security must be in the financial sector! How often in the last couple of years have you actually put a web app on the back burner until insecure coding is fixed. 
Randy Naramore
50%
50%
Randy Naramore,
User Rank: Ninja
3/31/2014 | 3:32:37 PM
Re: Continuous application security approach
Not really on the back burner but the decision has been made to push back "go live" date until app is fixed and retested. This makes all involved with deployment pay attention to details. 
planetlevel
100%
0%
planetlevel,
User Rank: Author
4/1/2014 | 3:38:06 PM
Re: Large-Scale AppSec Programs
@wire - I'd love to find out more about how you scaled up your appsec program continuously.  I think there are many organizations that could benefit from your experiences.  Would you be willing to discuss with me for a few minutes? If so, please reach out at [email protected] and we can set something up.  I'm gathering data for a future blog.  Thanks --Jeff
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
4/1/2014 | 4:05:14 PM
Re: Large-Scale AppSec Programs
@wire and @planetlevel - The Dark Reading community would also be interested in hearing about your appsec scaling experience, so please share your experience on the message boards if you can!
Page 1 / 2   >   >>
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-8023
PUBLISHED: 2018-09-21
Apache Mesos can be configured to require authentication to call the Executor HTTP API using JSON Web Token (JWT). In Apache Mesos versions pre-1.4.2, 1.5.0, 1.5.1, 1.6.0 the comparison of the generated HMAC value against the provided signature in the JWT implementation used is vulnerable to a timin...
CVE-2018-14643
PUBLISHED: 2018-09-21
An authentication bypass flaw was found in the smart_proxy_dynflow component used by Foreman. A malicious attacker can use this flaw to remotely execute arbitrary commands on machines managed by vulnerable Foreman instances, in a highly privileged context.
CVE-2018-14645
PUBLISHED: 2018-09-21
A flaw was discovered in the HPACK decoder of HAProxy, before 1.8.14, that is used for HTTP/2. An out-of-bounds read access in hpack_valid_idx() resulted in a remote crash and denial of service.
CVE-2018-1685
PUBLISHED: 2018-09-21
IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, and 11.1 contains a vulnerability in db2cacpy that could allow a local user to read any file on the system. IBM X-Force ID: 145502.
CVE-2018-1710
PUBLISHED: 2018-09-21
IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 10.1, 10.5, and 11.1 tool db2licm is affected by buffer overflow vulnerability that can potentially result in arbitrary code execution. IBM X-Force ID: 146364.