SecOps: Go Beyond Application Security Testing With Runtime Protection

The DevSecOps movement has changed how companies develop applications. Long delivery cycles and large monolithic applications are history. We’re now “shifting left” and “sprinting” every which way. We’re delivering applications at breathtaking speed.

Companies are automating application security as much as possible. When we take the “Dev” out and look at SecOps, or security and operations working together to run a production application, is the testing done earlier in the pipeline enough to protect your APIs and services?

Let’s dive into SecOps and why new approaches are necessary to secure production applications and APIs.

What is SecOps?

SecOps refers to the proactive cooperation between security and IT infrastructure teams within an organization. Traditionally, these teams have different goals that may cause conflict and increase a company’s risk. 

SecOps aims to define the securable perimeter (which may consist of various endpoints used by remote workers) and develop a security strategy that meets the business goals while protecting business and customer assets.

What Does SecOps Have to Do With API and Application Security?

There are two main phases when creating software. The development phase includes gathering requirements, developing the code, and testing to ensure that the application works as intended.

Once the application is deployed to a runtime environment, operations teams are assigned to keep things running and resolve issues as they appear. The production environment is where end-users access the application and businesses make money.

DevSecOps melds development, security, and operations together. It’s an excellent ideal to strive for, and it’s vital to frame conversations around applications with a DevSecOps mindset.

But it’s also helpful to review various application-development pieces to make a plan to implement the necessary elements for a running application pipeline. For example, you can put a “DevOps” lens on to understand the CI/CD pipeline and how best to make developers self-sufficient so they can deliver code quickly. You don’t forget about security, but your focus moves to developer productivity and agility.

SecOps looks at the “other end” of the application lifecycle. It focuses on protecting the running application in production and features a different set of tools and competencies. You don’t forget about development, but the focus moves to stability, scalability, and security.

Shifting Left Builds a Strong Foundation

Let’s look at “shifting left” in application security terms, looking at “DevSec” without the “Ops.” Many tools have appeared to give developers what they need to write secure code the first time.

Developers create automated security test cases to help ensure there are no glaring vulnerabilities in the code. For example, you can write an automated test that requests a secure page without authenticating first and make sure a 401 Unauthorized HTTP error comes back. These tests can be run locally on the developer’s computer and then run again during the CI process after the developer checks in the code.

Static Application Security Testing (SAST) programs scan source code to find vulnerabilities. SAST reviews the entire code repository and reports any known vulnerabilities in the code. An example would be looking for SQL statements that aren’t properly formed and could lead to SQL injection vulnerabilities. These tools help find coding errors before they get too far into the pipeline.

Dynamic Application Security Testing (DAST) takes this one step further. DAST actively launches attacks against a test environment to find vulnerabilities. While SAST looks at source code to locate where vulnerabilities could develop, DAST actively exploits vulnerabilities in a live setting. While humans use many DAST tools to perform penetration tests, some, such as OWASP Zed Attack Proxy, can be automated to run in “headless” mode during a CI (continuous integration) build then store the results for review.

Finally, Interactive Application Security Testing (IAST) tools aim to combine SAST and DAST’s best aspects into one solution. These tools have deeper hooks into the runtime environment and code execution stacks to pinpoint vulnerable code. IAST requires a robust automated testing suite because it uses the automated tests to exercise the application and search for vulnerabilities.

These tools have helped developers deliver secure code. But only focusing on pre-production testing isn’t enough to protect modern applications.

SecOps Maintains the Building

A strong foundation is the start of a sturdy building. But even the best-made buildings will deteriorate if proper maintenance is not performed when the building wears down.

A SecOps focus helps applications to remain healthy and build on the foundation that came before them. Application security tools that help developers write secure code are excellent ways to reduce your codebase’s vulnerabilities and risk.

Runtime protection is still needed, however. Blocking and reviewing real attacks that happen to your application is essential to fill any cracks that may develop over time. NG-WAFs and RASP try to accomplish this, but they both fall short in one significant way: business logic attacks.

An example of a severe business logic attack is Broken Object Level Authorization (BOLA), number one on the OWASP API Top 10 list. It occurs when an attacker submits a request using a resource ID that is different from theirs and can view a resource belonging to someone else. 

For example, a logged-in user types their ID into the URL of a system holding medical records that uses sequential IDs and accidentally transposes two numbers. Missing authorization checks allow the user to view someone else’s record. It may not be deliberate, but it could cause a breach of Personal Health Information (PHI) or Personally Identifiable Information (PII). A planned attack could lead to a massive data breach along with fines and sanctions.

These types of attacks are difficult to detect using automated testing. SAST tools look for vulnerabilities in the code without the context of the business logic. Development standards within the organization, such as proper authorization, cannot be tested by SAST.

DAST may be a little better at exercising application functionality in a live environment, but the likelihood of such an API-specific use case existing out of the box is low. Some DAST tools allow for scripting and customizing specific tests, but you’d have to spend effort and resources writing and testing custom scripts. Also, testing authentication and authorization are well known to be difficult using DAST.

It’s challenging to scale the detection of business logic attacks in code. Code reviews by humans can find them, but automated tools are limited. How can modern applications protect themselves in production?

Traceable: Machine Learning for Cloud-Native Architecture

API-driven development is a new world with new risks. This new environment contains threats that most current tools can’t detect.

Traceable AI can detect complex business logic attacks in runtime environments and stop them. This detection is possible by building a comprehensive map of the application’s business logic. We call this your “Application DNA.” It’s a model of your application’s unique characteristics: the data, microservices, and execution flow. 

Machine learning can take this DNA picture and respond to abnormal behavior that could signify an attack. For example, it knows when someone is trying to use BOLA to steal data or change a user’s cart’s contents. It stops these attacks in realtime and reports them.

SecOps keeps the production environment safe. Traceable should be in the arsenal of every SecOps group. It keeps the production environment safe and then shows you exactly which microservices your developers should update to fix the vulnerabilities it sees in the wild. 

Putting these capabilities together further strengthens your DevSecOps program to cover both “left” and “right” sides.

Check out a demo of Traceable in action (we recorded it so you can rewatch it over and over. We know you’ll want to).