3 Steps DevOps Should Take to Prevent API Attacks
Hackers go where the value is, and right now, the value is traveling through APIs. The problem is no one role is responsible for securing APIs.
When the audience at this week’s TechStrong Con was asked who selects API security products for your business, 64% said security and 36% said development, according to Dan Kirsch, a TechStrong industry analyst and consultant.
“The industry is starting to recognize the idea that this is a really important area — that the data and services that go across APIs are critical,” Kirsch said. “What we’re seeing is that API security is falling in the cracks.”
An API security program should incorporate a new definition for API, contended Noname Labs security engineer Matt Tesauro in 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?” Tesauro told the audience. “It’s like saying Amazon is a website and by the way, those 40 lines of HTML I wrote is also a website. The website becomes meaningless.”
From a security standpoint, he argued, a better definition is that an API is a combination of:
- Method — e.g., GET, POST, PUT
- Hostname, e.g. example.com; and
- Path, such as /v2/users/all
As for API security, DevOps should understand security from three perspectives, he added:
- API security posture
- API runtime security
- API security testing, which is best when continuous
He demonstrated how these three perspectives could be used to identify and stop the OWASP API top 10 risks, which include broken object-level authorizations, excessive data exposure, broken user authentication and injection attacks.
1. API Security Posture
Kirsch queried conference goers about whether they had an inventory of all the APIs used: The majority (55%) said no. Sixteen percent were not sure.
“We’re talking about a little more than a quarter of folks that have an inventory of the APIs in their environment, which is pretty alarming, because how are you supposed to update them?” he 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 Tesauro’s first API security perspective is API security posture, which requires an inventory of every API — with details about method, host name and paths.
For instance, be clear on which APIs are going through the API gateway and whether the API call is coming from the north/south (external) or east/west (internal). Essentially, developers should catalog the who, what and where of an API call, he said, particularly for the data involved.
“What APIs do I have and what data do they consume?” Tesauro asked. “Then, more importantly, mapping the data that’s coming to and from those APIs.”
By monitoring API security posture, it’s possible to identify the following OWASP API risks:
- Excessive data exposure
- Lack of resource and rate limiting
- Security misconfiguration
- Improper asset management
- Insufficient logging and monitoring
2. API Runtime Security
The second perspective is API runtime security, which means understanding what normal looks like at a network level and communication level with the APIs, Tesauro explained. That makes it possible to recognize out-of-line traffic — for instance, 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 instance, if your tool only understands GraphQL but the APIs are also done in REST and GPC, two-thirds of the traffic is being missed, he said. Runtime security is a good place to deploy a tool that leverages machine learning or artificial intelligence to perform anomaly detection.
”Once you have that, and if it’s continually learning, you can do things like set thresholds for abnormal traffic and take actions,” Tesauro said. “If I see a request from a public IP hit this internal-only API, I want to reach out and talk to the API gateway or my firewall or whatever network thing can shut off that public access to that API.”
A runtime security system should include trigger alerts and create a manual, semi-auto or automatic response when abnormal traffic thresholds are reached, he said. DevOps also should be able to block, geo-fence and outright deny external traffic as needed, he added.
API runtime security can help detect all of the OWASP API Top 10 risks, according to Tesauro.
3. API Testing
It’s important to test the security states of APIs, and testing should be continuous, Tesauro said. An API testing program should use DAST (dynamic application security testing) rather than SAST (static application security testing), which isn’t API-specific, he said.
“Tools need to understand how APIs write or talk to other APIs — and this isn’t 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 inform the tool — hey, this is how you talk to my API.”
Generally speaking, there will be a Swagger or OpenAPI spec file that says these are the methods and how the API talks to them. It’s also possible to use the recorded traffic in the HTTP archives, he said.
Also, API testing should incorporate issue tracer integration with tools like Jira, the ability to see vulnerable requests/responses and the ability to re-test specific issues, he added.
Testing can be used to detect most OWASP API Top 10 risks, except improper asset management and insufficient logging and monitoring.
Pulling it Together
Tesauro shared how the three perspectives would work together to identify and stop a DDoS attack on an API.
Understanding API posture can help DevOps understand what resources and services need to be protected during the attack — because using API posture, the most critical services are already identified. Runtime can help identify the HTTP floods, sudden spikes in traffic or a 32 meg request that comes out of nowhere, he said. Testing in pre-production should have incorporated a denial-of-service-type test to determine ahead of time what happens when an API is attacked with this method.
“I need to understand what the APIs have, what data they receive to make any kind of decent security decisions about them, but also I need to watch what they’re doing at runtime, and be able to test them,” he said. “Ideally, if testing is working correctly, I’m not introducing any more security.”
