By Jake Reynolds, Product Manager at NetSPI and Nabil Hannan, Managing Director at NetSPI
With Continuous Integration/Continuous Deployment (CI/CD) increasingly becoming the backbone of the modern DevOps environment, it’s more important than ever for engineering and security teams to detect and address vulnerabilities early in the fast-paced software development life cycle (SDLC) process. This is particularly true at a time where the rate of deployment for telehealth software is growing exponentially, the usage of cloud-based software and solutions is high due to the shift to remote work, contact tracing software programs bring up privacy and security concerns, and software and applications are being used in nearly everything we do today. As such, there is an ever-increasing need for organizations to take another look at their application security (AppSec) strategies to ensure applications are not left vulnerable to cyberattacks. Here are three steps to get started:
Step 1: Identify Existing Barriers to AppSec Success
Even now there remain outdated and immature AppSec programs. Many organizations tend to perform vulnerability testing in an ad-hoc, reactive manner, typically driven by some type of security incident, by compliance requirements or a client’s request. Add to that, with the plethora of vulnerability testing and discovery tools available from multiple vendors, almost every organization struggles with content overload and tool management which ultimately leads to inefficiencies and ineffective AppSec programs. In many cases, vulnerabilities aren’t tracked or managed anywhere centrally, but instead lengthy reports are emailed back and forth amongst development teams to digest and consequently, there’s no easy way to measure an organization’s risk posture. The overarching barrier to AppSec success? A lack of using data properly to make informed decisions.
To effectively adopt a reimagined, proactive AppSec program, there needs to be a formalized, data-driven program that defines and guides how an organization implements application security. As a starting point, engineering and security teams will benefit from an understanding of traditional and emerging application vulnerability discovery tools and techniques.
Step 2: Expand and Understand Your Options for Vulnerability Discovery
To catch security flaws early in the SDLC process, the traditional application vulnerability discovery techniques most commonly used are Static Analysis Security Testing (SAST) with Manual Secure Code Review or Dynamic Application Security Testing (DAST) with Manual Penetration Testing. Most organizations use these techniques to some extent, and when it comes to managing open source software risk, many organizations just manually manage and inventory a list of their open source usage. New and emerging technologies like Interactive Application Security Testing (IAST), Real-time Application Self Protection (RASP) and Software Composition Analysis (SCA) are quickly gaining popularity and changing how organizations look for security vulnerabilities in their applications.
There are many different vulnerability discovery tool options to consider, with pros and cons to each. Here’s a guide to better understanding your options:
|Technology Considerations in Vulnerability Discovery|
SAST & DAST
Even though the technique of analysis is vastly different when deploying SAST (for source code error) and DAST (for running applications) technologies, a lot of the challenges that they pose to organizations to adopt and deploy are similar. Additionally, they both require manual setup and configuration to start yielding valuable results. Both DAST and SAST aid in finding the vulnerabilities that matter – DAST gives quick and thorough coverage of the most common vulnerabilites such as OWASP Top 10 and SAST does a deeper analysis and looks for vulnerabilities at the source code level.
IAST is gaining popularity quickly and is a rising star amongst security discovery techniques. Because it is instrumented into running the application on the server side, it can report issues that are truly exploitable, which results in the IAST tool reporting little to no false positives vulnerabilities.
RASP is a technique, as the name suggests, that isn’t really intended for vulnerability discovery, but more for attack prevention. Ultimately, RASP is an additional layer of protection to protect an application from common attacks similar to how Web Application Firewalls protect an application from attacks.
When identifying and managing open source risk, SCA techniques have evolved and are being adopted widely. SCA tools allow organizations to create a bill of materials and inventory all open source software components and their corresponding versions that are being used in applications as a means to notify developers if known vulnerabilities are reported.
A final note on the tools: SAST, DAST and IAST all detect new vulnerabilities; SCA only reports on known threats.
Step 3: Focus on Infrastructure to Improve Efficiency
A critical component of an organization’s AppSec program is the infrastructure built around vulnerability management, tracking, reporting, and remediation. Consideration should be given to implementing the most efficient and effective infrastructure to manage AppSec programs holistically, for many beneficial reasons including faster remediation and better reporting.
When analyzing vulnerability discovery techniques, it quickly becomes apparent that they are not all created equal in terms of integration and reporting. Some have a consolidated system (DAST running through Jira, for example), but unfortunately, there are still many other components and data sources in an AppSec program that can result in inefficiencies, lack of automation, and unmanageable amounts of noise. And when it comes to the vulnerability reports? Many times, the results across testing platforms are supplied in hundreds of pages-long PDFs, are not deduplicated or consolidated, and there is no system of record for the organization. This results in inefficiencies, no master plan, more staff time, and lost context related to the vulnerabilities. Ideally, an AppSec program should deliver all data behind a single infrastructure platform that foregoes the reams of paper and allows for immediate remediation and access to historical data to track the progress of the AppSec program over time.
To further build a solid AppSec infrastructure, consider these strategic pillars:
- Adopt a centralized vulnerability infrastructure management system to record and manage all AppSec activities, one that can house vulnerabilities in a manner that provides insights into trends and analyzes for better security initiatives
- Integrate technology into the process, as appropriate, that ingests disparate data sources for noise reduction and provides more global context and intelligence around the vulnerabilities
- Manage the entire secure SDLC, centered around engagements for project management focus; Enable automation to assign people to strategic tasks/activities
It’s a reality that many organizations struggle with the breadth of their testing coverage. Engineering and security teams lack the time or financial resources to adequately test all of the applications and systems in their environment – and they can’t remediate all the vulnerabilities from each test. According to Gartner, once a company discloses a vulnerability and releases a patch, it takes 15 days before an exploit appears in the wild. And clearly a lot can happen in 15 days in the world of cyber defense.
An effective, reimagined AppSec program includes being able to manage manual penetration testing and secure code review augmented with automated vulnerability discovery tools that are deployed at various phases of the SDLC process. Penetration Testing as a Service (PTaaS) provides our customers with tests when they need them. Release-based testing is gaining popularity and PTaaS allows organizations to consume the appropriate level of testing at the appropriate time.
Ultimately, a reimagined AppSec program will improve vulnerability ingestion, correlation, and enrichment, and will bring increased speed to remediation to organizations. These program improvements will undoubtedly enhance reporting around vulnerabilities (and the positive results in thwarting an attack) to leadership to optimize AppSec programs even further.
About the Authors
Jake Reynolds is a Product Manager at NetSPI. He is responsible for leading the product strategy for Resolve, NetSPI’s vulnerability management and orchestration platform. Previous to his current role, Jake was a Principal Security Consultant helping lead internal R&D and application penetration testing services at NetSPI. Jake can be reached at email@example.com, on Twitter and LinkedIn (@JReynoldsDev) and via the NetSPI website https://www.netspi.com/contact-us/.
Nabil Hannan is a Managing Director at NetSPI. He leads the company’s consulting practice, focusing on helping clients solve their cybersecurity assessment, and threat & vulnerability management needs. His background is around the building and improving effective software security initiatives, with deep expertise in the financial services sector. He has over 13 years of experience in cybersecurity consulting from his tenure at Cigital/Synopsys Software Integrity Group, where he has identified, scoped, and delivered on software security projects. Nabil has also worked as a Product Manager at Research In Motion/BlackBerry and has managed several flagship initiatives and projects through the full software development life cycle. Nabil can be reached at firstname.lastname@example.org, on Twitter (@NabilHannan), on LinkedIn (@nhannan), and via the NetSPI website https://www.netspi.com/contact-us/.
Alternative graphic for discovery techniques: