The 4 Easy Steps You Can Take to Assess Your API Security Posture
Many API developers feel outside of their area of expertise when it comes to securing their apps. In fact, according to a Ping Identity survey, 45% of developers who responded weren’t confident in their ability to detect an API breach, and 30% don’t know if their organization has ever experienced a breach involving APIs.
This is a problem. Why? Well, while an API’s owner should be responsible for ensuring security is considered, the developers are the ones that are responsible for implementing that security.
The good news is that there are simple, straightforward steps you can take yourself to assess your API’s basic security level. This article is the starting point for that assessment, and the purpose here is to enable API developers with the means of evaluating their security posture without additional help. If you’ve already developed APIs, but you aren’t sure if they are protected, you’ve come to the right place. Read On!
Of course, having the tools to evaluate your security posture on your own doesn’t mean that you may not need, or want, help to implement your security improvements. Instead, this is about empowering you to determine if your APIs are protected, if your security posture needs improving, and what needs to be done.
To simplify the rating your current API security risk level, we’ve devised a tool that will take you step-by-step through the evaluation process. The assessment uses four levels of security preparedness for your APIs:
- Needs Improvement: Action should be taken immediately to improve your API’s security.
- Potentially vulnerable: Action is needed to improve your API security posture.
- Sufficient: Your API security may be good enough, given its use and implementation; however, there is still room for improvement and to make it Airtight.
- Airtight: You have implemented the best-in-breed and best technology in the industry to protect your API against threats. No further action is needed.
Understand, however, there is more to security than addressing the attacks on the various API security layers. And while an assessment of your API security is useful and important in determining your vulnerabilities, it is not the only tool in your arsenal. Do not replace other useful procedures and analysis - like pen testing - with what is offered here. This is simply a starting point on the road to secure API development and management, not the final destination.
The 4 Steps to Assessing Your API Security Posture
One: API Inventory
Imagine you’re installing a security system on a building. You don’t have blueprints, so you just put sensors on the doors you can see from where you’re standing. Do you think that would make the building secure? Of course not.
You can’t secure what you don’t know about. An inventory is the crucial first step to API security management. If you don’t have an API inventory, you’ll need to start there, and your security rating would be “Needs Improvement.” The rest of the security assessment steps don’t apply until you know what APIs you have, how these APIs are used, and where they are located.
Two: API Gateway Security Policies
The next level of API security is assessing your API gateway and the associated security policies. If you don’t have API gateway security implemented, your API is likely open to the world. This requires immediate action.
If, on the other hand, your API gateway has a security policy or policies implemented, the next step is to assess the protection being provided by those policies.
We recommend combining OAuth with IP whitelisting to start. This will allow only authenticated access to your APIs and provide for Role-Based Access Control (RBAC), and ensure that only clients from known IP addresses can make requests against your APIs.
If this is a private API, this setup may give you a Sufficient rating for this assessment element. However, if you have public-facing APIs, you should continue to the Web Application Firewall (WAF) element.
Three: Web Application Firewall
The next step in your evaluation is to validate that you’ve got a WAF or hardware appliance in place. Without this, you are vulnerable to the OWASP Top 10 attacks, like SQL injection.
Some organizations opt to forgo a WAF because their API is not public-facing. These private APIs may not require extra protection. Any public-facing API endpoint, however, should have a WAF implemented.
The OWASP Top 10 list is a good starting point when assessing the need for a WAF and understand where your endpoints may be vulnerable. Using the OWASP list as a foundation to build out your security test cases can lead you to additional scenarios you should take into consideration. Based on your comparison to these test cases, you can better decide if a WAF is warranted.
With a WAF in place, you have your endpoints protected under what many would consider the best practices for securing your APIs. However, this simply gets you to a Sufficient rating. Like Google and Facebook, even large companies have had breaches that go undetected for years with this level of security. To reach a rating of Airtight, there is one more step.
Four: AI/ML API Security Engine Implementation
Even if you’ve implemented all of the security measures discussed above, you’d be surprised at the number of vulnerabilities your APIs are still open to - threats like stolen tokens that look valid or insider threats.
API security practitioners need to be able to detect, block, and monitor advanced threats. Hackers are now using machine learning (ML) and artificial intelligence (AI) to find holes in applications.
You need to be able to fight fire with fire, which means implementing an ML/AI security engine that can intelligently monitor your APIs' behavior. PingIntelligence is an excellent product for this. They offer excellent reasons why an ML/AI product like theirs is needed in their article, Everything You Need to Know About API Security in 2020. Having this type of product in place, gets your security posture rating is Airtight.
API security is built in layers. The first step to securing your APIs is making sure you have a firm grasp on what you have and how they are used. From there, you can evaluate and build out the security of each layer - the API layer, the WAF layer, and finally, the ML/AI layer. It’s the combination of these elements that gets you to an airtight security posture. Unfortunately, missing one of these layers could leave you open to a breach.
Effectively communicating the importance of your posture to API security and API owners can be challenging without a clear and systematic means of evaluation.
The API Security Self-Assessment and Instructions
The Big Compass API Security Self-Assessment can be found here. The tool can be used to review and evaluate your current API security practices objectively.
If you have questions or would like to dive deeper into your results, send your completed table to Big Compass. We’re here to help.
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
Time since the last version was published
Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents