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.

Application Security

1/15/2014
11:06 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
100%
0%

What Healthcare Can Teach Us About App Security

The Centers for Disease Control protects people from health threats and increases the health security of our nation. It's a mission that's not so different from InfoSec.

Here’s our challenge: our increasing reliance on software is occurring exactly when two other trends are making security more difficult. First, software size, complexity, interconnection, and even development speed are increasing rapidly. Second, advances in software technology are rapidly making traditional security scanners and code analyzers obsolete. Seriously… this won’t end well.

Poor visibility is poor security
Most organizations, even those with "mature" application security programs, have terrible visibility into the security of their application portfolios. They might be tracking some risks from penetration tests or automated scans. They might have a spotty application and component inventory. But when you get right down to it, they probably have very little real evidence that their defenses are correct and properly used across their application portfolios. And the information that they have gathered is so far out of date that it is of little use to development projects.

Ironically, the biggest risk in a risk assessment report isn’t even captured in its pages: the risk that the assessment itself has missed something important. Typical risk assessments don’t capture all the details about what code was covered, which defenses were checked, and what tests were performed. So, for example, if an assessment doesn’t cover authentication or access control (most don’t), the report reveals nothing, and the development team is left with a very dangerous false sense of security.

With a little tweaking and some perspective, we can transform techniques like dynamic scanning, static analysis, penetration testing, code review, architecture review, and threat modeling to generate a lot of assurance.

Battling the flu with instrumentation
We can learn a lot from the world of healthcare. Did you know the mission of the Centers for Disease Control (CDC) is to protect people from “health threats” and increase the “health security” of our nation? Its mission is not as different from information technology security as you might think.

The CDC fights disease, but they’re not your typical doctors. The size and complexity of their problem forces them to use very different techniques -- techniques that scale. The CDC is using sensors and instrumentation to gather data from people, doctors, hospitals, and labs at scale. It's now monitoring more than 700,000 flu patients every week.

The CDC uses this sensor data to combat influenza. The chart below shows that this year’s flu is peaking at a similar time but is less intense than in last years. Researchers are using this data to identify strains with more accuracy and create better defenses (flu shots) to protect people.

As application security challenges continue to mount, we can take advantage of sensors and instrumentation to increase visibility and create assurance. Imagine new sensors that track security-critical information across your entire application portfolio in real time. Below is a snapshot of a real-time software assurance dashboard generated from a small organization’s application portfolio:

Using Sensors & Instrumentation for Application Security Visibility

Each of the expected defenses represents one part of a more detailed security story. The dashboard illustrates the level of assurance for each of the expected security defenses in each application. Sampling and circumstantial evidence can be used at the lower levels, but the higher levels require more rigorous verification.

New sensor technology can gather this information directly from applications in development, test, integration, and even production. Traditional application security tools, both static and dynamic, can be retooled to generate this kind of evidence. For example, tools like OWASP’s ZAP proxy can be used to identify vulnerabilities, but can also be set up as a passive sensor. A simple ZEST script can generate continuous evidence that Cross-Site Request Forgery (CSRF) token defenses are working across an entire application portfolio.

Focusing your application security program on generating portfolio assurance has many benefits. You can learn more about this approach in my recent OWASP talk, Application Security at DevOps Speed and Portfolio Scale. This approach is far more compatible with Agile and DevOps style development than the traditional annual security test. But more importantly, it actually produces security and increases the health of your application security program.

Jeff Williams has more than 20 years of experience in software development and security. He is the founder and CEO of Aspect Security and served as the Global Chairman of the OWASP Foundation for eight years.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/21/2014 | 9:02:01 AM
Re: Wow! Check out this dashboard that tracks critical application security info in real time
Thanks for the great detail, Jeff. One last question from me (Others -- feel free to add yours to the thread!). What were some of the gotchas in the project that you would have done differently, or that didn't work out as well as you expected. 
planetlevel
50%
50%
planetlevel,
User Rank: Author
1/17/2014 | 11:24:08 AM
Re: Wow! Check out this dashboard that tracks critical application security info in real time
In this case, we worked with security team to put in place some tools to monitor application security continuously. One was ZAP proxy, which we put in place in their CI/CD environment to *passively* look for security practices. We have been adding some custom ZEST scripts to verify *their* security defenses.  There are a lot of tools -- some static, some dynamic, and some using instrumentation -- that can all help generate assurance continuously. Their initial investment was very low.  They started small just looking to verify SQL Injection defenses across their entire application inventory.  They use *positive* static analysis to verify that only parameterized queries are used across all their apps.  Now if any developer introduced a potential SQL injection problem it would show up on the dashboard immediately.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/17/2014 | 10:05:36 AM
Re: Wow! Check out this dashboard that tracks critical application security info in real time
Sounds very promising. Who's idea was it or was it a project initiated by management. Sounds like it is already showing an ROI, but what was the initial investment (ball park) in terms of h/w, s/w and other related costs?
planetlevel
50%
50%
planetlevel,
User Rank: Author
1/17/2014 | 8:54:23 AM
Re: Wow! Check out this dashboard that tracks critical application security info in real time
Sure!  They have set up a variety of tools to report to a central server.  It's not as clean as they would like.  Some of the tools report via files, others by REST services, etc...   And their reporting engine doesn't generate a beautiful heatmap yet.  But they've got a great set of sensors started and they are adding more every day.  Their penetration testing costs are plummeting, because they no longer need to test for the items they are monitoring.  And (I believe) their assurance is going up, because the sensor they are deploying get better coverage and have more accuracy than the traditional ways of doing application security.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/16/2014 | 3:49:26 PM
Wow! Check out this dashboard that tracks critical application security info in real time
Jeff, Can you expand a little bit more on how the company that developed this dashboard came up with the idea, some examples of how they are using it and some of their big sucess stories! Very cool stuff!
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
NetCAT Vulnerability Is Out of the Bag
Dark Reading Staff 9/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16413
PUBLISHED: 2019-09-19
An issue was discovered in the Linux kernel before 5.0.4. The 9p filesystem did not protect i_size_write() properly, which causes an i_size_read() infinite loop and denial of service on SMP systems.
CVE-2019-3738
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.
CVE-2019-3739
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to Information Exposure Through Timing Discrepancy vulnerabilities during ECDSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover ECDSA keys.
CVE-2019-3740
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Information Exposure Through Timing Discrepancy vulnerabilities during DSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover DSA keys.
CVE-2019-3756
PUBLISHED: 2019-09-18
RSA Archer, versions prior to 6.6 P3 (6.6.0.3), contain an information disclosure vulnerability. Information relating to the backend database gets disclosed to low-privileged RSA Archer users' UI under certain error conditions.