3 steps DevOps must take to prevent API attacks: the new stack

3 steps DevOps must take to prevent API attacks: the new stack

Hackers go where the value is, and right now the value travels through the APIs. The problem is that no role is responsible for protecting the APIs.

When this week’s audience TechStrong scam asked who selects API security products for their business, 64% said security and 36% said development, according to Dan Kirschindustry analyst and consultant for TechStrong.

“The industry is starting to embrace the idea that this is a really important area — that the data and services that are in APIs are critical,” Kirsch said. “What we’re seeing is that API security is falling apart.”

An API security program must incorporate a new definition for APIs, the Noname Labs security engineer said. matt thesaurus at a TechStrong Con presentation, “Peeling the Onion: Making Sense of the Layers of API Security.”

“We need a better definition of what an API is, particularly from a security context, right?” Thesaurus told the audience. “It’s like saying that Amazon is a website, and by the way, those 40 lines of HTML that I wrote is also a website. The website stops making sense.”

From a security point of view, he argued, a better definition is that an API is a combination of:

  • Method: For example, GET, POST, PUT
  • Hostname, for example, example.com; Y
  • Path, such as /v2/users/all

When it comes to API security, DevOps needs to understand security from three perspectives, he added:

  1. API security posture
  2. API runtime security
  3. API security testing, which is best when it’s continuous

He demonstrated how these three perspectives could be used to identify and stop OWASP API Top 10 Risksincluding broken object-level authorizations, excessive data exposure, broken user authentication, and injection attacks.

1. API security posture

Kirsch asked conference attendees if they had an inventory of all APIs used: the majority (55%) said no. Sixteen percent were not sure.

“We’re talking about a little over a quarter of the people who have an inventory of the APIs in their environment, which is pretty alarming, because how are you supposed to update them?” she asked. “How do you know if an API is no longer supported if you don’t even know what APIs are in your environment?”

Kirsh’s point helps explain why Thesaurus’s first API security perspective is the API security posture, which requires an inventory of each API, with details about method, hostname, and paths.

For example, be clear about which APIs go through the API gateway and whether the API call is coming from north/south (external) or east/west (internal). Essentially, developers must catalog the who, what and where of an API call, she said, particularly for the data involved.

“What API do I have and what data do they consume?” Thesaurus asked. “Then, more importantly, mapping the data that comes in and out of those APIs.”

By monitoring the security posture of the API, it is possible to identify the following OWASP API risks:

  • Excessive data exposure
  • Lack of resources and speed limitation
  • Misconfigured security
  • Improper asset management
  • Insufficient logging and monitoring

2. API runtime security

The second perspective is API runtime security, which means understanding what the normal looks like at the network and communication level with APIs, Tesauro explained. This makes it possible to recognize offline traffic, for example when someone has launched a Distributed Denial of Service (DDoS) attack against the API.

Not all tools will monitor all APIs, he noted, so part of this is understanding what types of APIs you’re using. For example, if his tool only understands GraphQL but the APIs are also done in REST and GPC, two-thirds of the traffic is lost, he said. Runtime security is a good place to implement a tool that leverages machine learning or artificial intelligence to perform anomaly detection.

“Once you have that, and if you’re continually learning, you can do things like set thresholds for abnormal traffic and take action,” Tesauro said. “If I see a request for a public IP coming into this internal-only API, I want to reach out and talk to the API gateway or my firewall or anything on the network that can shut down that public access to that API.”

A runtime security system should include trigger alerts and create a manual, semi-automatic or automatic response when abnormal traffic thresholds are reached, he said. DevOps should also be able to directly block, geo-fence and deny external traffic as needed, she added.

API runtime security can help detect all of the OWASP Top 10 API risks, according to Thesaurus.

3. API tests

Testing the security states of APIs is important, and testing should be ongoing, Tesauro said. An API testing program should use DAST (Dynamic Application Security Testing) instead of SAST (Static Application Security Testing), which is not API-specific, he said.

“Tools need to understand how APIs write or communicate with other APIs, and this is not like a web app where you can have a crawler,” he said. “You don’t browse an API, so you have to have some way to tell the tool. Hey, that’s how you talk to my API.”

Generally speaking, there will be a Swagger or OpenAPI spec file that says what these are the methods and how the API communicates with them. It’s also possible to use traffic logged in HTTP files, he said.

In addition, API testing should incorporate issue tracker integration with tools like Jira, the ability to view vulnerable requests/responses, and the ability to retest specific issues, he added.

The tests can be used to detect most of the OWASP API Top 10 risks, except for inadequate asset management and insufficient logging and monitoring.

putting it together

Tesauro shared how all three perspectives would work together to identify and stop a DDoS attack on an API.

Understanding API posture can help DevOps understand which resources and services need to be protected during the attack, because by using API posture, the most critical services are already identified. The runtime can help identify HTTP floods, sudden spikes in traffic, or a 32-meg request that comes out of nowhere, she said. The pre-production tests should have built in a denial of service type test to determine in advance what happens when an API is attacked with this method.

“I need to understand what the APIs have, what data they receive in order to make any kind of decent security decision on them, but I also need to see what they’re doing at runtime and be able to test them,” he said. “Ideally, if the tests work correctly, I’m not introducing more security.”

main image via pixabay

Leave a Comment