This guest blog was contributed by Doug Ennis, CEO of Waratek.
We live in a world where 84 percent of software exploits happen at the application layer. Yet we continue to rely on vintage security techniques at the network layer to protect enterprise applications. Whether your organization uses a WAF, RASP, or a combination of SAST, DAST, or IAST, the only reliable approach to address these vulnerabilities is to patch the codebase.
Still, we make assumptions about risk in the form of heuristics that require a significant amount of manual investigation. Today’s enterprises deploy code multiple times a day, and security teams must keep pace with each deployment. This pace is simply unsustainable for security teams, leading to vulnerability regressions.
If you need proof that the status quo is no longer adequate, look no further:
A record-breaking number of 1,862 data breaches occurred in 2021.
Gartner predicts that 99 percent of successful cyberattacks will continue to result from known but unpatched software vulnerabilities.
NIST adds a new software vulnerability to the National Vulnerability Database every 30 minutes on average.
If traditional cybersecurity approaches aren’t decreasing the frequency of attacks or the time it takes to patch the vulnerabilities, how do we, as a community, improve our approach?
Introducing Security-as-Code
Security-as-Code (SaC) is the practice of leveraging machine- readable definition files that use high-level descriptive coding language to apply immutable and continuous security behavior. This approach drastically reduces reliance on human intervention and grants security teams autonomy while allowing engineers to focus on development rather than vulnerability remediation. There are three key pillars that any SaC solution needs to exemplify:
Immutability: The rules you define should remain accurate to prevent vulnerability regressions with each deployment. Security must be continuous to achieve immutability - not at a single instance like in the CI/CD pipeline.
Scalability: Cost and human capital are the reasons current security solutions don’t scale. WAFs and RASPs, for example, are essentially massive data pipelines that ingest, analyze, and make assumptions on HTTP payloads to determine risk. The only way to improve security scalability is to automate the process of patching code.
Performance: Most security solutions recommend running in sample mode, where only a handful of requests are protected. Companies shouldn’t have to choose between being protected and remaining competitive. Companies no longer have to make this choice when your security solution has proximity to the application and APIs
How Does Security-as-Code Work?
Security-as-Code solutions do not require direct interaction with the application code or prior knowledge of the application. When executing a method on your application for the first time and attempting to exploit a vulnerability, the JVM or CLR replaces the execution in milliseconds by performing a checksum check without downtime, source code changes, or tuning. On any additional calls to that same method, only the protected version of your code is available, resulting in even faster execution. Compared to the complex nature of a WAF or RASP and the overhead of managing large numbers of rules, the business benefits are clear: unprecedented accuracy, low maintenance, virtually zero performance overhead, and no disruption of service once deployed.
In declarative approaches to SaC, you specify the desired final state of the security you want to apply without dictating how to get it. This behavior is ideal for Common Weakness Enumerations (CWEs), which act as dictionaries of vulnerabilities and refer to software weaknesses rather than specific instances of vulnerabilities. Declarative programming minimizes the factors that could affect the behavior of a piece of code to ensure that only a function’s input should affect the output, not what’s happening elsewhere in the program.
In the imperative approach, the SaC solution helps you prepare automation scripts that apply your security one specific step at a time. Imperative rules require a higher level of domain experience with your applications. Still, the reward is more control over how you accomplish vulnerability remediation.
In brief, prior to the introduction of Security-as-Code, it’s never been economically feasible to secure every application and significantly lower your risk profile. However, Security-as-Code enables you to fix the executing code rather than make assumptions on a lagging indicator like network data, and the following happens:
False positives and negatives are non-existent
The human capital needed to secure applications decreases
The economics of securing every app becomes possible
About the Author
Doug Ennis, CEO of Waratek has over 20 years of experience ranging from internal IT, consulting and sales. He has developed a deep understanding and appreciation of Cybersecurity and the Networking landscape. Doug has held Sales Leadership Roles in companies focused on Data Privacy, Network Security, Application Performance Management and Mobile Device Security & Management. He received his Master’s of Science, Information Technology and Security from Capella University and his Bachelor’s in Computer Science from John Carroll University.
###