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

02:00 PM
Kevin E. Greene
Kevin E. Greene
Connect Directly
E-Mail vvv

Software Assurance: Thinking Back, Looking Forward

Ten personal observations that aim to bolster state-of-the-art and state-of-practice in application security.

For the last five years or so, I have been actively engaging with the security community in academia, industry, and government to better understand the gaps that exist in software assurance. Working within the Department of Homeland Security's Science and Technology Directorate, I've discovered some interesting things about the community's drive to increase the adoption rate of both state-of-the-art and state-of-practice tools and capabilities. Here are my top 10 observations:

Observation 1: The state of practice is lagging.

  • There is no standard way to measure and baseline how well software assurance tools perform. We don't know what tools can and cannot do ... with some certainty.
  • The OWASP Top 10 lack the foundational science to advance AppSec practices in organizations, specifically in relation to the methodology for data collection and data analytics in formulating the OWASP Top 10. As Brian Glas from nVisium points out in his blog post "Musing on the OWASP Top 10 2017 RC1:" “The metrics collected for the Top 10 2017 represent what was found by either tools or time-boxed humans. It's a subset of vulnerabilities that are typically found, but are probably not representative of what is actually out there or the bigger risks that are faced." There is a lot of room for improvement, and I believe with RC2 and more involvement from the community, we can advance the OWASP Top 10 beyond its intended purpose to have a greater impact on advancing AppSec practices. 
  • NIST 800-53 is too network- and system-focused. There are security controls with software assurance applicability not included in any of the baselines (high, moderate, low), which means these security controls are not being tested as part of the certification and accreditation process.  
  • Secure coding practices are missing in action and are not being enforced religiously in AppSec programs. 

Observation 2: Threat modeling, when automated, is very powerful.

  • There is great potential in leveraging machine learning with threat modeling. This can be used to take a more proactive approach to software development which would help improve security designs and reduce overall security risks. 
  • In the future, I believe threat modeling will become the core engine for all security testing.

Observation 3: There are residual risks in using static analysis and security testing tools.

  • We don't know what the tools did not find.
  • We don't know what parts of the code and attack surface the tools were able to cover.
  • Static analysis struggles with opaque code. These are parts of the code not analyzable by static analysis. 
  • Static analysis tends to be shallow and oversimplified.
  • Heartbleed won against all static and many dynamic analysis tools.

Observation 4: False-positives — the proverbial pain in the rear end.

  • Many vendors would rather err on the side of caution by building products that tell you something is there versus tell you something is not there but actually is.
  • Tools lack context.
  • To be sound (low false-negative rate), there's a trade-off that will generate a considerable amount of noise (a lot of false-positives). This is the interesting trade-off with static analysis.

Observation 5: Patching does not scale  software assurance/secure coding is our first line of defense for protecting software.

  • The window of exposure is constantly sliding to the right.
  • Poor design and architectural decisions increases the need to patch (as seen with the Equifax Apache Struts breach). Some third-party software (i.e., frameworks) vulnerabilities are difficult to patch.
  • Human and social behaviors play a part because people resist change; we become the Achilles' heel of the software engineering process. Cybersecurity expert Dr. Diana Burley, a professor of human and organizational learning at George Washington University, credits, in part, "the rise of cyber attacks to the failure of the average computer user to take preventative measures — like patching."
  • The Internet of Things and Internet of Everything are proving that patching is becoming a lot harder for many different reasons, such as safety. I think we have more than 465,000 reasons

Observation 6: Poor tool performance creates barriers for tool adoption early in the software development process.

  • I often wonder why commercial and open source static analysis tools struggle with Juliet test cases.
  • An NSA tool study suggests that a given static analysis tool can find around 14% to 17% of weaknesses in Juliet test cases.
  • Some open source static analysis tools did just as good as, and in some cases better than, commercial ones on certain weakness classes and programming languages with Juliet.  

Observation 7: There is no uber tool  the sum of many is better than the sum of one...

  • Each tool has a sweet spot.
  • There are too many programming languages and weakness classes for one tool to be a jack of all trades.
  • Different testing methods find different things. 
  • I'm seeing a movement that is encouraging the use of multiple tools for security testing. For example, I'm member of a technical committee (Static Analysis Results Interchange Format) initiated by developers at Microsoft to push for a standard format to incorporate multiple tool outputs. 

Observation 8: More code equals more problems.

  • New cars today have at least 100 million lines of code — an increased attack surface. Often, more features mean more code, and more code leads to more complexity, which tends to lead to more problems. This is what software engineer Brian Knapp refers to as "software gravity" — the force that pulls features, complexity, and resources toward a software system over time.
  • Software is the new hardware.
  • With the explosion of IoT, software truly has become ubiquitous.

Observation 9: Technical debt increases software maintenance costs; organizations have no clue about the volume of technical debt they've accumulated.

  • Many take shortcuts, leading to poor design decisions that ultimately will create vulnerabilities.
  • Design debt, defect debt, and testing debt all contribute to the cost to maintain software. 
  • Frameworks like Struts require code changes and a considerable amount of testing, which increases the mean time to remediate, which increases the likelihood of technical debt. 

Observation 10: Foundational science is a key to forward-leaning capabilities

  • If we are not exploring, we are not advancing the state of art.

In the upcoming installment of this two-part series, Kevin Greene will share innovations that advance the state-of-art and the state-of-practice in application security. 

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Kevin Greene is a thought leader in the area of software security assurance. He currently serves on the advisory board for New Jersey Institute of Technology (NJIT) Cybersecurity Research Center, and Bowie State University's Computer Science department. Kevin has been very ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-22
The FileImporter extension in MediaWiki through 1.35.0 was not properly attributing various user actions to a specific user's IP address. Instead, for various actions, it would report the IP address of an internal Wikimedia Foundation server by omitting X-Forwarded-For data. This resulted in an inab...
PUBLISHED: 2020-10-22
The Cosmos Skin for MediaWiki through 1.35.0 has stored XSS because MediaWiki messages were not being properly escaped. This is related to wfMessage and Html::rawElement, as demonstrated by CosmosSocialProfile::getUserGroups.
PUBLISHED: 2020-10-22
In Python 3 through 3.9.0, the Lib/test/multibytecodec_support.py CJK codec tests call eval() on content retrieved via HTTP.
PUBLISHED: 2020-10-21
WSO2 API Manager 3.1.0 and earlier has reflected XSS on the "publisher" component's admin interface. More precisely, it is possible to inject an XSS payload into the owner POST parameter, which does not filter user inputs. By putting an XSS payload in place of a valid Owner Name, a modal b...
PUBLISHED: 2020-10-21
Adobe InDesign version 15.1.2 (and earlier) is affected by a memory corruption vulnerability due to insecure handling of a malicious .indd file, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.