Leon Andrews is the Principal of APIs and Platform Engineering at Terem. Terem is a product development strategy firm that works for enterprises, tech companies, and Government. In this article, Leon discusses API Security.
The Swiss cheese model
The model depicts a system as a stack of slices of Swiss cheese, with each slice representing a barrier or safeguard against failure. James Reason developed it as a metaphor for how complex systems can fail. The holes in the cheese represent weaknesses in the barriers so that things can get through your security layers. The holes are randomly distributed as they should be in a piece of Swiss cheese. But when you line up the cheese, when the holes in the slices align, a hazard can pass through all the barriers and cause a failure. You need multiple layers to improve your success in blocking threats.
Applying the Swiss Cheese Model to API Management
Our layers of Swiss cheese for API Management need to cover many things. We’re protecting against bad actors with specific intent. We also deal with human traits such as skill levels, intelligence, motivation, energy, etc. This is where this model starts to highlight the different factors you must take into consideration with API security. Humans make mistakes. We know that the software we are using isn’t perfect and may have exploitable bugs. These are all unknowns that are to be dealt with.
We can’t focus on the API as being the single place where any weakness will lie. The truth is that these risks manifest themselves differently and affect different parts of the stack.
In the Swiss cheese model for API security, I’ve come up with 11 layers, and I put a bonus layer on the end. We are going to use two types of cheese –
Technology Swiss Cheese
- Hardware and Software systems
- Frameworks that operate on these systems
Human Swiss Cheese
- Business drivers
- Mindset and motivation
We will have multiple slices, each performing a different job or activity.
Technology Swiss Cheese
Network LayerThis is the basic outer layer of security. This layer is relied on a bit too much.
- DNS / IP Configuration
- Web Application Firewall
- Load Balancing
- Cloud-specific environment configuration
- Auth Layer
Many things happen in the auth layer. It is not just authenticating but also authorizing data access.
This layer covers many personas, API consumers, engineers, admins, and business stakeholders involved in your API program. It is an important layer because it affects the access to run APIs and call other APIs, resources, and platforms.
- Protocol Layer
This layer lays down the rules of engagement through things like having your API specs. It can also provide attackers with some information about how your system works. But it’s a layer that’s there and prevents your systems from being wide open.
- Gateway Layer
API requests are processed in the Gateway layer. This is thought of as the layer where the API exists. But that is not the case. An API is more than just a proxy.
- Monitoring Layer
There can be multiple monitoring layers. Technology on its own isn’t sufficient. You can’t just put in a monitoring layer; it requires a lot of planning and hard work to ensure that the right things are being monitored and that you’ve got the right alerts set up. You need a tool that is a help rather than a hindrance.
- CI/CD Layer
This is one of the most critical layers. This is your opportunity to ensure that your security policies, design guidelines, etc., are properly implemented for every API. This is where you use automation to reduce human error and gain consistency.
- API Management Platform Layer
A suite of tools allows you to configure and develop API security. Depending on the API platform or the technique you’re using, you might not even have this layer; you might use a more generic gateway product. You could be missing out on a lot of the security that comes with these features.
- Service Layer
This is the integration piece that holds things together.
Human Swiss Cheese
- Developer Documentation Layer
It’s everything you can do to educate the people responsible for working on your API platform. You need excellent developer guidelines as a way to ensure your team uses them and applies the guidelines. Your CI/CD pipeline should implement checks across everything you have in your guidelines. But it cannot be the most important layer because you may teach your team, but that cannot enforce security.
- Operating Model
The operating model deals with ensuring that the business makes it possible for good API security to happen. It’s about the business being involved in the API lifecycle and having a proper team around it instead of being seen as a function looked after by the IT team. A strong operating model around APIs is critical to ensure that your security best practices are always followed. It’s all about governance.
- Business Mindset Model
This is a subtle layer, but it makes a huge difference. It defines how the business and management promote API security.
- Community Layer (Bonus Layer)
The API community has bloggers, white hats, researchers, and evangelists. It helps build security.
Swiss Cheese in Action
Let us consider a few examples covered in OWASP 10 –
- An attacker trying to gain unauthorized access to run APIs
- An attacker trying to exploit obvious patterns in IDs and codes through an enumeration attack.
- Attacker trying to insert SQL into your API to trick your database into performing an action (SQL Injection Attack)
Attack 1 – Gaining unauthorized access
An attacker is attempting to gain access to information that their identity should not allow them to see. The request may look legitimate as they may already have an account, or the attacker may be trying to brute-force IDs or passwords to try and log in to different accounts.
Our attacker is trying various auth-related attacks, and the auth layer may deal with most of the issues. The protocol layer has defined the tightness of the OAuth requirements to gain access to the system. The Gateway layer blocks unauthorized access. The monitoring layer detects unusual parameters, traffic patterns, and attempts. The CI/CD layer should prevent any auth exploitable code from being deployed. Your API platform layer should have given you many tools to implement your chosen auth model. Your service layer should also allow you to make even deeper auth checks when you’re calling your apps or services in your service layer. Your human layers ensure the developers know the best practices and the business supports them.
Attack 2 – Enumeration attack
An attacker has access to the system and is trying to manipulate API calls by guessing identifiers in the request, or they may be trying to harvest data to look for patterns in identifiers.
We cannot expect the WAF or the auth server to prevent this in the first instance. But from the protocol layer, we can start to secure the code. This is where we can make gaining access to the system harder. The Gateway layer might be servicing these requests and returning negative results based on dodgy ideas, IDs being plugged in, and logging at the monitoring level. HOPEFULLY, the CI/CD layer and API platform layer have developer tools built into it to support security for this.
Attack 3 – SQL Injection attack
The requests look legitimate. But the gateway smells a rat. It filters out the SQL commands and probably blocks the request because you have been able to implement your API with basic checks and filters for this. The gateway alerts the monitoring layer, which alerts the business.
These examples have highlighted how the Swiss cheese method is useful as a way to think about API security.
What we see happening
This was inspired by seeing security implemented at the wrong layers or doing the wrong job at the wrong layer. These issues can be seen even in major organizations –
- Detect everything at the WAF.
- The security team tried to detect and fix everything at their level.
- The auth layer has basic authentication, shared accounts, broad-based permissions, dodgy passwords, etc.
- Your API taxonomy may not be tightly defined in the protocol layer. There may be some very generic off-the-shelf APIs that are easy to exploit.
- The gateway layer may not be configured for security.
- Your monitoring layer may have been a bit of an afterthought. It’s focused on raising system warnings but not dealing with security events.
- Your service layer may have third-party services nothing specific for your application.
- In the human layers, we don’t see solid developer guidelines and a very inconsistent style; maybe some documentation is being run by one team, and another uses a different style.
- The business mindset might be that security is just a technical IT problem, not a business one.
What should be happening
If we think in terms of the Swiss cheese model –
- Think about the layers
- Accept that you cannot detect everything with one tool
- Allow each layer to do its job
- Spend the time to unite your teams to instill security at every layer.
- Make use of everything that your API platform and other tools provide
- Make sure that the engineers and business have the time to focus on each layer.
This is a new way of thinking about API security, perhaps one that will help unite your business or your clients to develop a more holistic way of doing API security.
