What are APIs?
Application Programming Interfaces (APIs) provide a vehicle for resources--irrespective of vendor, cloud technology, or even legacy on-premise solution—to exchange information and initiate tasks and workflows. Today, APIs are a powerful force behind the automation, integration, continuous development (CD), and secure development operations (DevSecOps) that is powering the next wave of technology innovation.
The actual functions, features, information, tasks, and automation capabilities can vary greatly between different APIs—even if the APIs are within the same discipline. While core functions may be the same, the ability to perform other tasks may be proprietary, and even patented, by individual vendors. This creates an interesting dilemma. APIs are not created equal. The security to prevent malicious abuse of the API can also vary wildly between vendors.
What is API Security?
To start, lets define API Security and then explain its relationship to Privileged Access Management (PAM). API security entails ensuring the protection and integrity of APIs. This encompasses both:
1. APIs you create as a solution provider (vendor), or end user, in custom applications
2. APIs you use when integrating with third party solutions
API risk for an organization may increase in rough proportion to the number of systems and resources that connect APIs together. Generally speaking, the more connected systems and resources, the higher the API security risk and potential for security fallout. This is simply a function of an expanding risk surface. If you consider peer-to-peer networks, Internet of things (IoT), DevOps, and other modern technologies, the amount of APIs implemented to integrate and provide interconnectivity—when not sufficiently secured, tested, and protected—creates an enormous risk surface.
When an API is broken, exposed, or hacked, any data protected by the application is potentially fair game to a threat actor. If you take into account all the automation currently in place for medical, financial, and personal data, the API risk can become obscene, if not properly mitigated and monitored.
API security entails a number of complexities. For instance, different data requires differing levels of protection when at-rest or in-transit, and in ways that might not always be immediately obvious. For example, an API call to retrieve the local outdoor temperature from a device is not as sensitive as pulling the temperature from a hospital device used to monitor a patient’s vitals. Both API calls return a temperature in standard units (Fahrenheit, Celsius, or Kelvin), but the source of the temperature warrants more API protection for one device over another. The results from both are temperature readings, but when linked to a patient, the data privacy and regulatory concerns become a substantial interest for security.
The Implications of APIs & Privileges/Privileged Access
Now, let us consider privileged access management since this blog was written by a market and technology leader in the space. By definition, PAM contains three disciplines and solution areas: Privileged Password Management, Endpoint Privilege Management, and Secure Remote Access.
Each one of those three areas encompasses use cases for protecting, removing, storing, retrieving, randomizing, and, ultimately, using administrative or root credentials within an environment. While the traditional use case of human interaction remains relevant, the necessity of interacting with various parts of the PAM solutions via an API has increased substantially over the last few years. This is due to technology like IoT, SecDevOps, and automation.
The integration of devices to retrieve, rotate, and configure privileged credentials, applications, and sessions allows for resources to interoperate with privileges when the most sensitive data is accessed, configured, or stored. While these use cases are fairly obvious to security professionals engaged in privileged access management, the protection of the API itself from privilege abuse or security flaws (vulnerabilities) has become a focal point for threat actors to conduct their nefarious missions. A poor API security implementation, the lack of an API credential model, or the lack of basic access control lists could leave an API exposed to perform automated tasks that are explicitly forbidden by the business and could adversely affect the security and data of resources.
A basic level of API security would at minimum include:
1. Awareness of the source IP address
2. Geolocation of the API request
3. Using valid credentials (username / password or certificate) to properly perform the request.
Just because the API request is being done by a program, does not mean it should forgo security best practices. On the contrary, threat actors typically use hacking automation tools to find these flaws, and those are just another program.
Now, enter PAM. Based on the previous description, the vast majority of API calls will contain sensitive data. After all, they are interfacing with your organization’s privileged accounts. The data can be anything from setting up a new asset or account, to the forced randomization of a password and automated launch of a privileged remote session with credential injection.
If a threat actor had unrestricted access to the privileged access management API, it is “game over”. The outcome could be worse than if the threat actor had access to a Domain Administrator Account because, with API access, the attacker can effectively interact with any asset, including those not in Active Directory, like IoT or network devices. Therefore, protecting the privileged access management API is of paramount importance to every organization. Access and the data should always be classified as sensitive.
The Most Important API Controls for PAM Solutions
So, what are the best API controls that should be deployed with every privileged access management solution?
- Access Control List (ACL): Control which IPv4 and IPv6 devices can make an API call
- Tokens / Credentials: The resource performing the API request should be using credentials (username / password or certificate (preferred)) or Tokens for authentication
- Role-Based Access Control (RBAC): The credentials should be locked down by role to ensure no inappropriate API calls or data can be retrieved. This creates accountability for an organization’s authorization model
- Just-in-Time (JIT) Access: The API call and credentials should honor just-in-time, ephemeral principles to restrict access based on the appropriate workflow and change control
- Encryption: All API calls should be encrypted using industry standards like TLS or proprietary techniques when warranted
- Throttling: The number of API calls should be monitored and throttled to detect if a threat actor is trying to siphon off information or a denial of service attack is in progress
- API Gateway: Utilize an API gateway to operate as a “traffic cop” and inspect requests for malicious behavior. A good API gateway will not only analyze API behavior patterns, but also indicate when abnormal or unexpected calls are being made in violation of any of the aforementioned security controls
You should apply a combination of the above recommendations to achieve an effective defense-in-depth approach to API security.
Finally, API security for any technology should not forgo vulnerability and penetration testing. While we have been focusing on inappropriate access to API calls, mistakes in the coding of an API can lead to a vulnerability. And, if the flaw is critical enough, an exploitable vulnerability can be leveraged by a threat actor, just like having privileged access to the API itself.
Next Steps for Improving Your API Security
Organizations that create their own APIs should consider testing their applications with a third-party vendor or solution. For vendor solutions that you license, inquire about their security practices regarding hardening and testing of the APIs they have implemented. After all, these APIs will operate with some of the most sensitive data in your organization, your privileged accounts, and should not have security flaws that may be exploited by cyber threat actors.
As we automate more resources in our world, the explosion of privileged accounts represents a challenge for resources to securely interoperate. Devices cannot remember passwords like human beings. We rely on privileged access management solutions to store privilege credentials, remove them from operations, when possible, and even initiate remote sessions with privileges to automate access. All of these tasks can be done by people, but the integration and automation can also be elegantly enabled using APIs between multiple vendors and resources. This provides the modern benefits of automation for our next-generation technologies and should be properly implemented to avoid many of the potential faults we have covered.
The protection of APIs is critical. The security of APIs used in privileged access management classifies as some of the most sensitive that may be present within an organization. Therefore, it is imperative that you not only secure APIs for your PAM implementation, but more importantly, verify that your PAM provider has implemented them securely in the first place.
Morey J. Haber, Chief Security Officer, BeyondTrust
Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored three books: Privileged Attack Vectors, Asset Attack Vectors, and Identity Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.