Threat Modeling For Building Secure APIs
Primer to understand basics of threat modeling and things to keep in mind while building a threat model for an API
Introduction
APIs have become one of the most common ways of communication and provide an entry point to any application and their data. Along with the flexibility and ease of integration, APIs also bring with them potential risks, vulnerabilities and threats to their systems. It becomes important to secure APIs during their development phase and threat modeling helps in achieving it.
Threat Modeling is the approach to design risk tolerant and secure systems by identifying threats to the API and building mechanisms to mitigate those. There can be several factors contributing to the exposed risks of any API and as per Open Web Application Security Project (OWASP) some of the top 10 risks of 2019 included broken object level authorization, broken user authentication, data exposure, lack of resources & rate limiting, broken function-level authorization, mass assignment, security mis-configuration, injection, improper asset management, and insufficient logging and monitoring.
With new threats and vulnerabilities getting exposed everyday, it becomes extremely important to lay focus on an APIs threat model during the early phases of development because a threat model continues to evolve before and after the APIs release. This article will focus on steps to get started with a threat model for building a secure API.
Getting Started with Threat Modeling
Understand your API
With increased complexity of any service, it becomes important to keep a strong documentation of every API that is interacting within a system. Security risks such as old/deprecated API versions exposing information are kept in check with this and helps in preventing data exposure due to shadow APIs.
Set security goals for your API
It’s important to identify security goals for your system for eg: If your API should be GDPR compliant or not? What kind of data does your API serve and how much of it needs to be protected? What kind of user data does your API fetches and does that need to be protected?
Identify the data
You should break down your API interaction and understand how data flows into your system. Identify what interactions happen over internet versus your internal system. You should also find out the kind of data your API handles and does it include user credentials and/or PII (Personally Identifiable Information) data. You should clearly understand what are your APIs assets (data/components that needs to be protected such as configuration files, exposed ports, etc.) and access points to define a good threat model.
Identification of Threats
This is the core component of any threat model as it requires brainstorming ideas on how an attacker or some vulnerability can expose your system.
One of the key steps is to look out for the list of top security threats for any API as published by OWASP.
Another step will be to understand the application thoroughly and see which out of the six security concepts can be applied for your API. The six popular security concepts to consider are: Spoofed Identity, Tampering with Input, Repudiation of Action, Information Disclosure, Denial of Service and Elevation of Privilege.
Another way to think about the above security concepts is by identifying the potential vulnerabilities such as man in the middle attacks, ARP spoofing, keylogger, computer worms, SQL injection, rootkit and spyware.
Prioritization and Mitigation of Threats
Identify the top and the most riskiest threats and prioritize their mitigation. In order to rank the top threats, OWASP has highlighted two methodologies: DREAD (Damage, Reproducibility, Exploitability, Affected users and Discoverability) and PASTA (Attack Simulation & Threat Analysis) to help mathematically identify the risk of a potential threat and helps in ranking them accordingly with the help of a risk rank matrix from most severe to least severe.
After ranking the threats, majority of the time is spent in understanding their mitigation strategies and deploying the fixes. For example: applying stringent authentication and authorization techniques, validating API parameters etc.
Usually the risk mitigation strategy should consider the following:
- Reduce the risk to your API by building mechanisms in place that will control the API upgrades, design changes, configuration changes etc. during the deployment phase.
- Transfer the risk to a third party that can help guarantee the development and deployment of a specific component of our API.
- Avoid the risk by completely disabling the component of the API that’s most vulnerable.
- Accept the risk if it’s within the acceptance criteria and continuously monitor the component.
Conclusion
Threat Modeling is an ongoing journey in the API life cycle and doesn’t end after creating a threat model. It’s a step towards securing your APIs for longer term but it needs to be iteratively maintained to identify newer risks associated with it. Threat model continuously evolves with the API and should be part of the continuous deployment strategy of your APIs so that it can do a rain check on every step of your API development.