How should security leaders approach API security today?
Sort by:
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.
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.
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.
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
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'.