Account for multiple personas and work streams in the organization: non-security and security teams don’t need to see all API event data, which
stresses the importance of role-based access control within an API security
offering itself. Some data may be privileged or be bound by regulatory
restriction. In other cases, providing too much data can lead to information
overload and slow down regular work. Provide teams the appropriate
API-related data that they need to do their job, and provide it within the
tooling they use as part of their daily routine to avoid disruption. As an
example, infrastructure teams may only care about event data related to
load balancer misconfigurations, product teams may be concerned with
APIM policy misconfigurations, and development teams may only be
concerned with code-level vulnerabilities.
2.
Create API-centric incident response playbooks: ensure that you
document digital forensics and incident response DFIR processes for how
to respond to the inevitable API attack patterns. If you’ve already matured
your SecOps strategy to include the use of security orchestration,
automation and response SOAR , then also automate some of the workflow
items as part of IR. Shutting down an API that is the target of malicious
activity is rarely a prudent business decision, not to mention it reduces your
ability to gain additional intelligence about an attacker and their techniques.
Rather than blocking traffic wholesale, you will likely want to employ more
precision such as throttling just the suspicious API caller, challenging them
with additional authenticator factors, or monitoring their behavior more
heavily. Create IR playbooks for common API attack patterns including
application-layer DoS, brute forcing, credential stuffing, enumeration, and
scraping.
3.
