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
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
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
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-14
An HTTP Request Smuggling vulnerability in Pulse Secure Virtual Traffic Manager before 21.1 could allow an attacker to smuggle an HTTP request through an HTTP/2 Header. This vulnerability is resolved in 21.1, 20.3R1, 20.2R1, 20.1R2, 19.2R4, and 18.2R3.
PUBLISHED: 2021-05-14
Hexagon G!nius Auskunftsportal before allows SQL injection via the GiPWorkflow/Service/DownloadPublicFile id parameter.
PUBLISHED: 2021-05-13
Piwigo 11.4.0 allows admin/user_list_backend.php order[0][dir] SQL Injection.
PUBLISHED: 2021-05-13
The Flask-Caching extension through 1.10.1 for Flask relies on Pickle for serialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the ca...
PUBLISHED: 2021-05-13
Bitcoin Core 0.12.0 through 0.21.1 does not properly implement the replacement policy specified in BIP125, which makes it easier for attackers to trigger a loss of funds, or a denial of service attack against downstream projects such as Lightning network nodes. An unconfirmed child transaction with ...