How should security leaders approach API security today?

Question

Answer

Security leaders should approach API security holistically. The first generation of API security tools did a good job of illuminating the core problem and the need to monitor API traffic, but it was limited to a “spotlight approach,” which means it only focused on part of the problem. As a CISO, I want to see sunlight: I want to see everything from code to production, with simulated attacks to validate and prioritize exposures. For the last 18 years as a CISO, I've said to vendors, partners and suppliers, “Whatever the threat model is, I need to see assets; actors, meaning who's involved; interfaces, so I know how they are getting to my assets; and actions, which show me who's doing what to what via what.” Only when you have that visibility can you develop a baseline for what normal behavior looks like. Once you have that baseline and you can get your arms around your space, then you reduce your attack surface and deploy resources to remediation of code and 24/7 monitoring, and use machine learning and automated models to alert you when something deviates from that normative behavior. But you can't monitor or defend what you can't see, and blind spots are prevalent; around 50% of APIs are unmanaged today.

That focus on visibility is one reason I’m a fan of the NIST model here in the US; the first principle is “identify.” You can’t protect what you can’t see. Creating and exposing APIs is very easy, but finding, governing, and securing them all is not. Adoption of APIs and their exposed logic has outpaced security and DevOps teams’ ability to keep up with or even put a lens on how their data's coming in and out.

Answer

One of the first things that you need to do is ensure you have an API inventory! This is often the hardest task to accomplish. There are tools nowadays that will monitor all traffic and give you this inventory.

Once you have the inventory, you'll need to understand the purpose of each, the exposure of each, and whether or not those should be public facing, internal facing, etc. Basically you'll want to clarify them according to your classification policy / standard, so you know what controls to put in place commensurate to the risk.

Once you have that, you'll want to look at ways to protect the APIs and monitor for malicious activity, and ensure controls are in place to deal with specific actions against those APIs. Tools nowadays will monitor all this traffic and you can leverage AI / ML to take action as required.

If you have a large number of APIs, a tool will be your best bet, as manual intervention will not be sustainable.

Good luck!

Answer

Most initial efforts should be focused on the typical “blocking and tackling” such as use of tokens, encryption and signatures and ongoing vulnerability identification. Use your f a gateway technology also helps.

Answer

IMO, initial efforts should be focused on the typical “blocking and tackling” such as use of tokens, encryption and signatures and ongoing vulnerability identification and remediation. Use your of a gateway technology also helps improve posture. (This is the second time I am posting this since the site seems to have some issues with account login continuity and the first time it ended up being posted from an "anonymous user")

Answer

API security should never be taken for granted. There are ways the Security leaders can do it and strategies that they can employ to reap the benefits that APIs offer while keeping all of your data safe. So, it must be go over some API security best practices to avoid security risks and secure your APIs.
1. Encryption
2. Authentication/Multi-factor/Token
3. Monitoring Audit logs and Versions
4. Share as little as possible
5. System Protection with throttling and quotas
6. Data Validations
7. Secured Infrastructure
8. Adopt a Zero-trust Philosophy
9. Identify Vulnerabilities
10. API gateway Firewall

Answer

Every CISO should take a defense in depth approach to any area of technology. Take your security framework, NIST, ISO etc and apply it to API security. Each area will then have challenges you need to understand. Inventory, Access Control, Encryption, Code development and testing, Logging and Monitoring. The issue with API security is organizations are looking at them as an extension of Web Server security which they are not. APIs need their own set of standards and controls.

Answer

I don’t want to repeat what others have already said so I’ll try to focus or expand on a couple of points:
1. With regard to authentication least privilege is important, not just from a tooling perspective but from a process perspective. One you have inventoried your assets processes need to be put in place to determine both the number of gates to implement but under what conditions these should be triggered. This requires a balance between less is more.
2. Understand the costs inherent of your processes and balance these against risks. This includes both tools and processes as per above, including integration with your incident response process. We’ve started to look into API security at our organizations and another key piece is making sure that any tools are taking copies/mirroring the data they would analyze however we need to be conscious there is some duplication of the data being sent which increases costs.
3. Don’t understate the avoidance strategy. Just because something can go on the internet doesn’t mean it should. Anything that goes on the internet should go through a modern NGFW appliance—API security should be considered a part of a broader security program. Also— as is often the case with IoT/IIoT—if a device or application is not secure by design and it’s not business critical consider preventing it from being deployed rather than trying to secure a design that is inherently insecure.

Answer

There are some very good answers already. I think that one of the most important aspects is to take a holistic approach that looks at Cloud, On-premises, and Hybrid Deployments.

Answer

A lot of this depends on the organization, but in general, API security is essentially an additional layer of web security and should be added to the stack of existing web security tools, processes, policies and protections that are hopefully in place.

1. Define policy that requires web application firewall (with API awareness and security monitoring).
2. Require an inventory, but use the WAF to actually implement that control.
3. Develop a relationship between the developers and the security team, and use that to insert security testing that aligns to the needs of the organization. Some will require static testing, some dynamic testing, some penetration testing.
4. Leverage WAF to SIEM integration to stay ahead of the bots, malicious actors, etc. and ensure the WAF is blocking sources that are found to be malicious.

The trickiest part is managing the API risk associated to third parties, apps that expose your organizations data, and increase your organizations overall risk. As a part time bug bounty researcher and having seen the horror show that can be API security, the biggest issue you see over and over again are logic errors in how APIs are used and called...however, having detection tools that find anomalies in requests would detect/prevent a lot of API security 'testing'.

How should security leaders approach API security today?

Content you might like

If you had a magic wand - what's the #1 daily business challenge you'd eliminate?

According to research from Imperva, the median duration of a network DDoS attack was 6.1 minutes in the first half of 2021. If you've experienced DDoS attacks this year, how long did they last for your organization on average?

Did the Russian invasion of Ukraine cause your organization to reevaluate its cybersecurity readiness?

What's your initial reaction to Cisco acquiring Splunk?