It would seem simpler just to make apps secure by design. In reality, it’s complicated due to two factors: complexity and time.

Complexity

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.

Time

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.

• Static application security testing (SAST) is a tool for evaluating source code looks for conditions that indicate a security vulnerability might be present. It comes into play at the design and build phases. It does not look at the app running in the actual environment.
• Dynamic application security testing (DAST) is a tool for scanning an application in the running environment. It is used during the build and test phases and can carry on into delivery and production phases.
• Interactive application security testing (IAST) is a combination of SAST and DAST that works through software instrumentation. It is typically used during the test phase.

Two additional technologies are specifically designed for running applications:

• A web application firewall (WAF) sits in front of a running web application and filters out attacks based on preset rules.
• Runtime application self-protection (RASP) operates from inside the application itself. RASP identifies and blocks attacks in real time by monitoring the applications behavior, helping to mitigate the effects of vulnerabilities left in the code.

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:

• DAST comes into play as early as the building phase of the SDLC. This is where you can actually see how the app behaves in the HTTP environment and simulate attacker behavior without resorting to lengthy pen testing. While SAST takes place earlier in the SDLC, it only finds errors in the code itself and doesn’t show how the app behaves in a runtime environment.
• DAST brings to light risks that occur because of the complex interplay of modern frameworks, microservices, APIs, and the like. While each of these might be secure in and of itself, working together in the web environment can cause unexpected problems.
• DAST shows issues that represent real risks rather than simply showing vulnerabilities that may or may not pose a risk; with SAST it can be difficult to determine if a finding relates to a real risk.
• DAST can easily be integrated into the CI/CD process as early as the build. In agile shops where apps can be functional just hours after a new software dev cycle begins, DAST can test for critical security risks early on so developers can address high-risk vulnerabilities sooner.
• DAST demonstrates the attack and provides a proof of exploit for every risk uncovered. This gives developers context, validating that the vulnerabilities really exist and making it easy to test patches without running another scan.
• DAST in comparison to SAST, is less likely to report false positives. The last point is crucial. It takes on average 38 days to fix a web app vulnerability, regardless of severity. This could be 38 costly days of needless delay if the vulnerability doesn’t pose a significant risk.
  

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:

• Integrate with CI platforms such as Jenkins. APIs should be integrated into the build process to automatically run scans of web apps and determine the pass/fail status of the build, i.e. quality gates for based on security risk. Ideally, you can configure the pass/fail decision criteria.
• Integrate with ticketing tools such as Jira, to allow vulnerabilities to be exported directly to Jira for immediate developer visibility. The best solutions allow you to customize ticketing templates to include context such as issue type and severity.
• Provide a variety of deployment options to meet your needs: on-premises, in the cloud, or as a managed service.
• Produce reports that are easy to navigate, show context and provide drill-down capabilities; they should allow developers to reproduce the attack with a few clicks.
• Provide compliance-specific reports tailored to important regulations such as PCI-DSS, HIPAA, SOX, GDPR, and OWASP Top Ten. Management reports should show statistics and metrics regarding the security of apps in an easy-to-read summary.

For a DAST solution to be effective, it should provide you the ability to:

• Crawl modern application frameworks and complex authentications
• Fast-track and prioritize fixes with reporting, Attack Replay, and remediation guidance
• Integrate seamlessly into the SDLC and the DevOps CI/CD process
• Scale with ease as your application portfolio expands and becomes more complex
• Automate tedious and manual tasks
• Increase visibility to better manage application risk

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:

1. SPA Frameworks (e.g. Knockout, Angular, React, Vue) that aim to provide customers with responsive experiences, without slow and annoying page reloads. Many legacy app scanners have trouble crawling these type of web apps because they don’t use a traditional HTML sitemap.
2. API definitions (e.g. Swagger) are used by both mobile and web apps, but often contain weaknesses in authentication and session management
3. Complex, manual authentication like CAPTCHAs or MFA (e.g. Bootstrap, Selenium)
4. Shopping carts and other sequential workflows
5. Mobile applications

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, our industry-leading DAST solution, provides comprehensive coverage for emerging technologies such as single page applications (SPAs), modern Javascript frameworks, APIs, and microservices. It provides thorough security testing even when custom parameters, non-traditional authentication processes, and complex workflows are used.

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.

Ready to see InsightAppSec in action? Check out our on-demand demo, or start a free trial below.