60% of all breaches involved web applications as the attack vector. according to the 2019 Verizon Data Breach Investigations Report.
Your website is the face of your company—the first impression customers have of your identity and brand—and it should be exciting and rewarding. As your products and services are accessed through that virtual front door, behind the scenes your DevOps team is focused on quality, time-to-market, and staying ahead of trends. Speed is the name of the game.
But your web presence has a huge target on its back. In fact, according to the 2019 Verizon Data Breach Incident Report, 60% of all breaches involved web applications as the attack vector. The very speed that you need to respond to changing market needs can spell trouble when it comes to security and compliance, because traditional approaches take time to assess vulnerabilities and risk. To maximize speedy delivery of new functionality, some businesses shortchange security without appreciating the full extent of the risk: If an application or the website goes down, it costs an average of $500K per hour in direct costs, lost revenue, and damage to the brand.
The problem: Each group has different requirements.
In this guide, we discuss these seemingly conflicting needs and shows how dynamic application security testing (DAST) can unleash the power of DevSecOps and help you maintain a competitive edge.
It would seem simpler just to make apps secure by design. In reality, it’s complicated due to two factors: complexity and time.
In years past, the environment was controlled, variables were few, and release cycles were long. However, as the web became central to our lives, we saw a headlong rush to develop applications. With limited knowledge about how older, simpler applications ran, developers and security experts today struggle to keep tabs on all of the factors that play a role in the runtime environment: CSS on the client, web servers, web application frameworks, languages, databases, second-tier servers, and more. Any of these could have vulnerabilities that impact a web app; other issues crop up due to the interaction of these components. To compound the issue, application frameworks and technologies are evolving at a much faster rate than app security testing solutions.
Further complicating the situation is the rapid pace at which apps are being created and launched. Short release cycles leave little time for testing, so many shops have adopted static application security testing (SAST) which allows the code to be analyzed as written. That’s a good start—it doesn’t impede the pace of agile development—but it leaves many blind spots later in the process. Simply looking at the code won’t uncover all the types of unexpected and unwanted behavior that occurs when the app is actually run in a complex runtime environment. Penetration testing is another option, but it can introduce lots of delays; vulnerabilities found take on average 38 days to remediate. This is far too long in the DevSecOps world.
Simply looking at the code won’t uncover all the unexpected, unwanted behavior that occurs when an app is run in a complex runtime environment.
The friction between development teams and security teams is legendary. Developers, focused on agility and speed, can see security as a stumbling block. To them security often means “slow.” But to security analysts, agile often means “vulnerable” or “risky.” DevOps is a culture of speed, agility, and responsiveness, whereas security is a culture of control.
Time-to-market pressure means that developers frequently re-use code from open source libraries (often unaware of the vulnerabilities that may lurk therein). But in the push to launch applications multiple times a day, there’s simply no way to wait days or weeks for the security team to search for vulnerabilities. The scarcity of security analysts only compounds the problem: it’s common to see one security analyst for every 100 developers... No wonder bottlenecks happen.
One area of commonality between security and DevOps teams is that web application security is a newer, less universally understood subject matter. While network and even endpoint security are well established, the complex interplay of all the elements that go into supporting and running web apps is less well known. This can cause teams to take an overly simplistic approach to ensuring web app security.
Case in point: although the OWASP Top Ten vulnerabilities list is well-known, each of these vulnerabilities can manifest itself in multiple ways. It is often difficult to understand the nuances. A simplistic view of app security can lead to a false sense of security. There are many ways to go about ensuring the security of applications, and it’s important to understand where each one fits.
There are many technologies that can be used to ensure secure applications. Each has its own role and comes into play during a specific phase of the software development lifecycle.
Two additional technologies are specifically designed for running applications:
As shown below, the further along in the SDLC, the higher the cost to remediate a security issue. Although there are some caveats, when it comes to testing, the earlier in the process the better.
Given that security should be addressed in pre-production, which of the tools should you start with? For web applications, DAST is ideal because:
Start implementing DAST by defining the strategic value you expect to get from it. As mentioned above, DAST aligns directly to the risk to the business. It helps show where security is making strides to mitigate risks, and can help to set baseline standard that can be used to create KPIs and measurable goals to aspire to. And it can help security processionals show management, through actual data, that more security investment may be needed. With this in mind, determine what business objectives you want to achieve, and what types of testing you will be doing: looking for low-hanging fruit like the OWASP Top Ten, examining critical apps first, or taking another approach?
Because DAST lets development teams take on a greater share of the security burden, it can free up the security team to focus on oversight and specialized testing. Done right, this can build stronger relationships between development and security, reducing conflict and increasing mutual understanding. As with any important technology, education and integration are key to implementing DAST successfully.
Education helps development teams understand the security challenges with web apps, and why it’s necessary to change the SDLC to include dynamic testing. It’s an important complement to existing vulnerability management programs that lets developers validate the impact and risk posed by vulnerabilities. They can quickly understand why extended scanning coverage is important, review actionable test results, and quickly remediate with automated capabilities before apps hit production. Integration is equally important, especially in fast-paced agile shops. Any DAST solution should be tightly integrated and become a frictionless part of developers' daily workflows. Make sure the tools align with their job and do not create too much disruption.
How DAST and RASP can work together: DAST should be used for testing to find and remediate bugs earlier in the SDLC. The vast majority of weaknesses can be found and remediated sooner, which is much less costly than remediating them later.
RASP should be used for monitoring and protecting in-production applications, to deal with bugs that may have been missed during testing, as well as with zero-day attacks. Consider using both DAST and RASP to complement each other.
The term “shifting left” has become commonplace today: remediating defects as early as possible in the SDLC. According to the IBM System Science Institute it costs 100x more to remediate a defect in production than in the design phase. Shifting left means that teams focus on quality and work on problem prevention rather than detection, shortening test cycles and reducing the occurrence of serious defects found in production.
In practice, this means introducing holistic testing much earlier in the process. Unlike older development methods such as waterfall, today’s rapid development cycles enable developers to integrate DAST very early in the SDLC and automate the process. This means solutions must integrate with the developers’ existing tools and processes, so security teams can work in parallel with dev teams and more completely understand each other’s priorities. Integration into the SDLC calls for DAST solutions that:
For a DAST solution to be effective, it should provide you the ability to:
Web technologies are constantly evolving, and your DAST solution needs to keep pace. Traditional DAST tools were built to handle classic HTML, PHP, or Perl applications, but it’s often a chore to get reliable results for dynamic HTML, AMF, single page applications (SPAs), and more. Your DAST solution needs to be able to handle many formats, protocols, and technologies, without laborious updates or tuning.
A Universal Translator function can make the process more intuitive, normalizing traffic and attacking the app to uncover vulnerabilities other solutions may have overlooked. To operate effectively in any environment, make sure the DAST solution covers:
To ensure your DAST will continue to evolve, choose a solution that logically separates the crawl and attack engines used in the DAST scan. This allows each to be updated for new attacks and new input types without impacting the other engine’s functionality.
We all want to break down the barriers between development and security teams. DAST is not a panacea but can go a long way toward reducing friction, baking security into the workflow of developers, and improving your organization’s overall security posture.
Shifting left in the SDLC means that real issues will surface more quickly. Automation can significantly reduce the need for manual testing, further shortening time-to-market and removing the bottleneck created by the lopsided ratio of one security analyst to 100 developers. DAST empowers developers to kick off scans and remediate on their own, while giving the security team the visibility to ensure that testing and remediation have been completed successfully—without the need to always be hands-on. With DAST, security teams have a holistic view of, and more control over, how to test, when to test, and what to test.
For developers, DAST delivers results that make sense. Interactive, actionable reports show prioritized lists of the highest risks, and developers can easily access and analyze the most important data. The right DAST solution gives them the ability to see full context, look at the details in different ways, and ultimately streamline their remediation efforts. When the DAST solution gives them the ability to replay attacks in real time, they can verify that the vulnerabilities exists, assess the risk, and validate fixes on their own.
It’s too much to hope that security and development teams will always be on the same page. After all, they have different cultures, differing timescales, and diverse motivations. But with DAST you can go a long way toward bridging the gap and creating a shared sense of security ownership. Security can move faster, and development can deliver more secure apps.
InsightAppSec can be integrated into the early phases of the SDLC, helping security teams adopt a true DevSecOps approach and keep pace with rapid application development cycles. With cloud and on-premises scan engine deployment options, InsightAppSec is highly scalable and provides you the ability to test both external and internal applications within the same management console. Best of all, you can be up and running in just minutes, avoiding the steep learning curve common with other products.
A Universal Translator normalizes traffic in different formats, protocols, and technologies, then attacks the application to uncover vulnerabilities other solutions may miss.
The InsightAppSec REST API integrates seamlessly into the CI/CD process to automatically run scans of web apps and determine the configurable pass/fail status, helping security teams work in parallel with application development teams and adopt a DevSecOps mindset. Similarly, it integrates with Atlassian Jira to allow app vulnerabilities to be exported directly for immediate developer visibility.
Built upon Rapid7’s Insight cloud platform, InsightAppSec combines ease-of-use with powerful crawling and attack capabilities so you get unparalleled visibility into your application vulnerabilities within minutes.
Whether you’re just getting started and need to assess and report on risks, have DevOps practices and aspirations and want to do more, or see app security as critical to the business and want to take it to the next level, DAST scanning and reporting has a place in your organization.