Broken, exposed, or hacked APIs have been responsible for some of the biggest data breaches of the past few years. A 2017 Equifax data breach leaked well over a million people’s credit information via a consumer complaint web portal that should have been patched. In 2018, Facebook’s developer API leaked the personal information of around 50 million users through a vulnerability in the “View As” function. That same year, the public learned that an attacker was able to query the USPS website and scrape a database of over 60 million corporate users, addresses, campaign data, and phone numbers due to an authentication issue that allowed improper access to an API service called “Informed Visibility.” A security researcher was able to scrape millions of transactions from the payment processor Venmo by exploiting its API. Vulnerabilities in various Cisco APIs allowed hackers to send malicious requests to the web management interfaces of its switches. The list goes on and treacherously on, to the tune of over 9.5 billion account credentials leaked in breaches in recent years, according to the website Have I Been Pwned.
So, how can organizations ensure they don’t end up being the next big breach?
New API risks
As organizations have transitioned to highly elastic and scalable cloud environments, cloud-based and container native applications have become the new norm, and APIs are one of the most common ways microservices and containers communicate. APIs are boundaries: Think of them as the application edge or software-defined edge, as entry points to the application and its data.
APIs and applications have changed over the past few years, and API security has changed along with them. Specifically, modern microservices-based application architectures have enabled internal application-to-application communication (also known as “east-west” communication), which represents a critical risk surface because of its plethora of API calls and the ability to move laterally with little visibility into the traffic.
When dealing with API security, authorization and improper asset management are top concerns. Authorization mechanisms are not implemented in one place but in many different components, such as configuration files, code, and API gateways. Additionally, modern applications contain many users and roles, which makes implementing safe authorization mechanisms a challenge. These factors add complexity, which introduces security risks.
In terms of asset management, a lack of proper API documentation can lead to security vulnerabilities. Composing proper, up-to-date documentation is especially important for APIs because they tend to expose more endpoints than traditional applications. Keeping a complete inventory of deployed APIs can help mitigate IT security risks such as deprecated API versions and exposed endpoints. This all helps developers prevent shadow APIs and excessive data exposure.
One way to mitigate these risks is to create threat models of API security flaws. Threat modeling is a structured approach to identifying and evaluating threats to an application. It’s best used as a preventative measure for dealing with security issues, and can reduce the time and effort required to deal with issues that may arise later.
Threat modeling provides insight into an attacker’s perspective. By understanding that perspective, organizations can look into potential access points, plan ahead, and secure weak spots attackers could use to exploit the software. In this article, I outline a framework organizations can use to create and maintain successful API threat models.
Identify and define security objectives
The first step in successful threat modeling—whether you’re doing it for APIs or anything else—is to identify and define clear security objectives. This helps organizations focus on the confidentiality, integrity, and availability of data based on the threats and risks that matter most.
To determine these security objectives, teams across the organization should ask themselves the following questions about their applications: What data needs to be protected? Are there compliance requirements, such as those in privacy-related legislation like HIPAA or GDPR, that need to be taken into account? Are there specific quality of service requirements, such as performance requirements, that measure response time or throughput, or are there availability requirements that measure the uptime of a system? Are there other intangible assets, such as trade secrets or intellectual property, that need to be protected?
Characterize and decompose the application
The next step is to outline in detail what the application does, taking into consideration the key functionality, usage scenarios, dependencies, trust boundaries, data flows, and entry and exit points. It’s important to understand the underlying architecture and implementation details of the application and to identify different security zones where data will be in transit or stored. This information can then be used to create detailed diagrams in order to better understand the system, which will ultimately help address a broader range of potential threats.
How you approach your data security needs will depend on what kind of data is being transferred or funneled back to the internet. Establish a framework for classifying data based on its level of sensitivity, value, and criticality as required by your organization’s security policies. It’s critical to track your application’s data flows in detail from entry to exit in order to understand how your application interacts with external systems and clients, as well as how internal components interact. Specifically, pay attention to data flow across trust boundaries and how that data is validated at trust boundary entry points. Pay special attention to sensitive data items such as personally identifiable information (PII) and how they flow through your system, where they are passed over the network, and where they are persisted.
Identify assets and access points
Next, clearly identify your assets and access points. Assets are the components that need to be protected against misuse by an attacker. They can be tangible, such as configuration files or sensitive information, or abstract, like data consistency. Access points are attack surfaces and paths attackers may use to access the targeted endpoints. These can include open ports or protocols or file system read-and-write privileges.
Since APIs are an access point, they need to be reviewed thoroughly, taking into consideration attack scenarios that might leverage API methods. This review should identify data assets—what attackers are looking to steal—as well as the types of data being processed and stored, possible access points, and attacker motivations and goals.
Organizations also need to take steps to understand how information flows to and from these access points, as well as the processes different components of the application provide to clients.
Identify threats
Once youʼve reviewed your assets and access points, itʼs time to identify the threats and attacks that might affect your application or compromise your security objectives. Gather together your development, test, and security teams for an informed brainstorming session. In order to identify top threats to API security, you may find it helpful to reference a comprehensive threat list such as the one published by the Open Web Application Security Project (OWASP). It identifies the top 10 most critical API security risks from 2019, highlighting concerns like broken object-level authorization, broken user authentication, excessive data exposure, lack of resources and rate limiting, broken function-level authorization, mass assignment, security misconfiguration, injection, improper asset management, and insufficient logging and monitoring.
Another way to find weak points is to examine the application layer by layer, considering the vulnerability categories in each. For example, if parameter attacks, identity attacks, and man-in-the-middle attacks are meaningful threats to your API security, which they commonly are, review the ways you can reduce the security risks associated with them.
Rank the risks
Next, calculate the risk of each relevant threat associated with the application. There are a number of ways to calculate this risk. OWASP, for instance, offers a threat modeling methodology you can use for threat prioritization.
Mitigate and control
Once youʼve identified and ranked the risks, consider how to mitigate them. A best practice is to implement the principle of least privilege for all APIs, no matter what method they expose. If you decide to expose a new service to third parties or to the public, use mapping rules to allow only the HTTP verbs and API paths instead of allowing full access, as this might make undocumented or untracked features discoverable.
Other API security mitigation strategies include validating parameters and applying rigorous authentication and authorization. Validating parameters involves sanitizing all incoming data to confirm it’s valid and won’t cause harm, and validating against a strict schema that describes permissible inputs to the system. Applying rigorous authentication and authorization includes basing authorization on a broad identity context, such as incoming IP address, access time windows, device identification, geolocation, and so on. In addition, make sure to implement and manage user and application identity separately.
Security engineers should provide a series of countermeasures to ensure developers address all security aspects of issues during the development process. Be sure to evaluate your organizationʼs individual circumstances and scale so security implementation costs are appropriately matched to the expected business risk.
Commit to maintenance
Investing in API security is part of the bigger picture of more effective application security. While the steps above can help set teams up for successful threat modeling, itʼs a continuous cycle—it doesn’t end when an application is deployed or delivered. Once you’ve completed a model and identified the risks, those risks need to be mitigated. Once you’ve mitigated the risks, you need to regularly validate and maintain the model. Threat models should be reviewed and updated on an ongoing basis, resulting in design, implementation, and configuration updates. This should continue throughout the applicationʼs life cycle. Ideally, youʼll integrate threat modeling into your software development life cycle for continuous delivery using an automated CI/CD pipeline. This will ensure security is enforced at every stage of the application development process in an automated fashion.
You know you’re doing it right when you’ve taken steps to identify and rank risks, secure access points, mitigate threats, and ensure the security costs don’t outweigh the potential risks. This approach should leave organizations feeling confident and secure in their production applications.
This article includes contributions from Bolesław Dawidowicz and Hugo Guerrero Olivares, members of Red Hat’s middleware and application Services team, and from Guy Gutman and Judy Kelly, members of Red Hat’s product security team.