{{announcement.body}}
{{announcement.title}}

Getting Started With Modern Application Security Automation

DZone 's Guide to

Getting Started With Modern Application Security Automation

Every company faces a terrible dilemma - either turn the business into a software business and risk the potential catastrophic downside of getting hacked, or...

· Security Zone ·
Free Resource

Every company faces a terrible dilemma — either turn the business into a software business and risk the potential catastrophic downside of getting hacked or refuse to engage in digital transformation and get put out of business by companies that are good at software.

The Dangers of Digital Transformation

Given the choice, most companies choose software. Unfortunately, it's often difficult to see that the cybersecurity risk is exponentially greater than the risk associated with the old real-world process. We are simply not very good at writing secure software.

appsec-trend-predictionsYour web applications and web APIs are the most attractive target for hackers. Over the last 10 years, the hacking game has steadily moved up the stack — from the operating system to your application layer. If you're like most companies, then your applications and APIs are easily accessed by attackers, are full of valuable data and capabilities, and are rife with vulnerabilities. The average web application is millions of lines of custom code, open source libraries, and configuration files, and it suffers from a staggering 26.7 serious vulnerabilities.

These vulnerabilities are primarily well-understood weaknesses, such as SQL injection, path traversal, cross-site scripting, weak access control, and using libraries with known vulnerabilities. The risk isn't limited to your public-facing "external" applications. In an era of cloud, containers, services, and deperimeterization, the distinction between "internal" and "external" is mostly meaningless.

True Automation Is the Key to AppSec

In theory, application security is pretty easy. It's just some rules that you have to be careful about when writing your code. Taken individually, they're pretty simple. For example, "don't use libraries with known vulnerabilities" seems pretty obvious. But assessing your entire application portfolio continuously for even this one issue can be complex. And there are thousands of these rules, and many of them are tricky, if not downright counterintuitive. To make matters worse, almost all of these rules are generic and need considerable interpretation to apply to your particular code in your particular environment.

Imagine if you have a portfolio of 100 applications, you have to verify 1,000 rules, you release code several times a day, and these apps (like all apps) are being attacked in production. Many organizations handle this problem by only assessing and protecting their "critical" applications, limiting the rules they check, and only checking periodically. Shockingly, most organizations leave the majority of their applications totally unchecked and unprotected. The more apps you have and the faster you release code, the worse the situation becomes.

Traditional-AppSec-Program

Traditional AppSec Program

The only viable solution is almost complete automation of application security testing and protection. But unless tools are highly accurate, you'll need to involve experts to deal with false positives and false negatives. In fact, if you require experts to install, tailor, run, triage results, or anything else, then your AppSec isn't really automated, and you won't be able to make much progress against securing your entire application portfolio.

Stop Scanning and Firewalling - Secure From the Inside Out

Historically, static analysis (SAST) code scanners, dynamic analysis (DAST) scanners, open source analysis (SCA) scanners, and web firewalls (WAF) attempt to secure applications from the outside in — parsing code, searching files, trying hacks, and attempting to identify attacks. These tools were designed in a pre-cloud era and haven't kept up with modern software. Like the parable of the blind men investigating an elephant, these tools can only see one "view" of an application, and therefore make a lot of mistakes. These mistakes, both false positives and false negatives, require experts to triage and slow down development dramatically. And automatically starting a scan as part of the CI/CD process does nothing to ameliorate these problems.

Up and down the stack, the modern approach to security works from the inside out. At the application layer, you can add a component to your application that produces continuous, complete, and accurate security without scanning. A single tool can replace all the outside-in tools at once with the following capabilities:

  • Application, API, and OSS inventory.
  • Assess custom code in development with Interactive Application Security Testing (IAST).
  • Assess open source with Open Source Security (OSS).
  • Prevent exploits in production using Runtime Application Self-Protection (RASP).

Inside-out tools work by dynamically instrumenting applications for security — similar to how tools like New Relic and AppDynamics instrument for performance. This instrumentation can continuously monitor an entire application portfolio for all the AppSec rules at once, in parallel. If the behavior of any of your applications or APIs violates a rule representing a vulnerability, weak library, or attack, you'll get an instant notification with all the relevant details, right down to the exact line of code responsible. Direct measurement of the actual application is the key to accuracy and, ultimately, to a scalable AppSec program.

antiquted-vs-new-security-workflow

Old vs. New network security workflow

Achieving DevSecOps at Scale

Working with, not against, development is the key to scaling, as it enables the big machinery of software development to do much of the security work itself.

Organizations seeking to improve their application security should take a hard look at DevSecOps. Unlike heavyweight process models from the past decade, DevSecOps seeks to get security work flowing by breaking it into small pieces, creating tight feedback loops, and creating a security culture. There are many books and articles about DevSecOps, but a few key goals to consider include:

  • Shifting Left - With easy and accurate automation, we can empower developers to find and fix their own vulnerabilities without experts. But beware of "shifting wrong" by pushing inaccurate scanners onto development teams that are ill-equipped to deal with large numbers of false alarms. Instrumentation-based tools can provide instant feedback to development teams through the tools they are already using.
  • Continuous Assurance - While shifting left is great, we still need to generate assurance that what we push into production has been thoroughly tested for security. Neither static nor dynamic scanners cover the entire application, and they don't provide evidence of what was actually tested. Modern security has to be done continuously across development, test, and production.
  • Runtime Protection - Don't forget, DevSecOps has to include "Ops." Every company should know exactly who is attacking them, what specific attack vectors they are using, and which applications and APIs they are targeting. Unfortunately, most organizations are almost completely blind — their only attack visibility is based on very noisy WAF data. Modern applications need both automated security testing and automated runtime protection.

Remember, if you're using the outside-in approach, as your software velocity increases, so does the work for security experts. For every release of every application, you'll have to run SAST, DAST, and SCA scans, correlate the results, triage false positives, create tickets, and retest. This increased work makes achieving DevSecOps virtually impossible.

Looking Forward

In the real world, we carefully instrument almost every complex thing: cars, airplanes, factories, spacecraft, etc. We instrument them for temperature, vibration, sound, and much more. But software, arguably the most complex thing that man has ever created, remains opaque. Our best visibility into software is through log files that almost seem to be intentionally designed to obfuscate what's going on. In the future, all software will be instrumented for security and more. There's simply no other way to monitor what's happening inside the complex code we trust with our lives.

Imagine a world where all software is instrumented for security and continuously monitored from within. There's never any scanning. Your security dashboards are always up to date. You can check compliance at any time, not just once a year. You've worked off your vulnerability backlog and new vulnerabilities are fixed as soon as they are introduced. Your pentesters are used to test new risks, and deliver their results as rules, not reports, so their test can be automated and run continuously from that point forward.

You can enable security instrumentation in your applications and APIs today without changing any code. It's the fastest path to taking control of your software inventory, eliminating your vulnerabilities, and preventing your company from being exploited.

This article was originally published in our Application Security Trend Report. To read more articles like this, download the report today!


Read Today  

Topics:
security ,application security ,appsec ,devsecops ,digital transformation ,automation

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}