In the modern enterprise, APIs are both the keys that unlockdata and the glue that makes system integration possible. But how steep are the associated security concerns APIs create?
As it turns out, they are quite high. As associate Ericka Chickowski covered in her post, 2018 Sees API Breaches Surge with No Relief in Sight, API-related breaches included those from Strava, Venmo, Salesforce, and others.
At the recent Qualys Security Conference, Gartner security analyst Mark O'Neill, in his presentation API Security: Enabling Innovation Without Enabling Attacks and Data Breaches, provided insight into how enterprises can better secure their APIs.
API use is growing. According to O’Neill, the number one reason enterprises use APIs is for integration—to simply connect apps. That, of course, is an essential aspect of APIs. Other important reasons include the move toward digital business and digital transformation. Moreover, digital transformation means integrating cloud services. "It also means delivering new types of experiences to clients, like mobile and conversational interfaces, and a lot of that work relies on the use of APIs,” he said.
O’Neill predicted that by 2020, API breaches would become the top attack vector that results in data loss for enterprise web applications.
What can organizations do to better secure their APIs and the resources and information they expose? Here are the key takeaways from O’Neill’s presentation on API security:
First, realize you have an API security problem. And you do. Step one is to recognize that APIs are in the environment, that they pose a risk to data, and that they need to be discovered, classified, monitored, and secured. There are tools available to help identify APIs in the environment and the security team or the CIO’s office can survey developers and application owners to identify APIs.
Of course, APIs need to be monitored so that it's understood what regular use looks like.
Don’t forget that APIs are about a data security strategy. When I talk to clients about their API strategy, they'll often use words like "we want to unlock our data" or "we have data locked away in these core systems, and we want to unlock that data," O’Neill said.
That’s a red flag. “Of course, from a security point of view, that's when alarm bells start to ring. Okay, they’re going to unlock data, but then we also want them to think about how that [process] can actually be secured,” he said.
Service provider APIs.
When it comes to API security, it’s essential to consider how the organization is using third-party APIs. “Many organizations depend on APIs provided by third parties,” said O’Neill. “If you are a hotel chain, an airline, or a truck rental provider you may be using the Google Maps APIs to deliver services to clients. You depend on that API. We see these types of API dependencies with background check APIs, credit scoring, currency checking, and many similar API use cases,” he said.
If these APIs have their access denied, how would that affect business and what is the recovery plan? How are the API keys being managed and secured? “What would happen if an API provider had a security breach?” he asked.
Don’t forget your internal APIs
While there are a lot of public and third-party APIs, many organizations also have many more APIs they have developed internally. Organizations still need to secure these APIs. They need to understand the risk they pose, how they are being used, and how they are being secured. “People call these APIs dark APIs, like dark matter in the universe. It's where organizations are connecting to each other with APIs. You don’t see them, but it's all around you. These have to be secured and managed,” he said.
How attackers target APIs
How do attackers target APIs? Most people don’t use APIs directly, O’Neill explained. Instead, they use the API indirectly as they use an app, or they’ll use a web interface that is calling the API. This adds complexity to API security because it brings in identity management and trust between apps. "If you're then an attacker trying to attack someone's API and you see that they have a mobile app, that they have a website, and they have a smartwatch app, and that's pulling the API. The attacker is going to think how the app and API can be reverse engineered.”
If an attacker wants to get ahold of your data, and they decide the way to do it is to attack an API, what will they do? O’Neill considered an attacker who was targeting a major bank’s API. When they strike, they’re not going to go first to the bank’s API portal or go to developer.bank.com site. Instead, what they’re going to do is look at a website that uses the API and then they’re going to see how exactly that API is used. How the API is being called and where are the API keys are being stored?
Moreover, they are going to identify what type of tokens are needed. “These types of hidden APIs are the ones that get breached. It's found often to be the APIs people didn't even realize that they had,” he said.
Skill up on API security
According to O'Neill, the biggest challenge enterprises face to their API strategy is, in fact, a lack of skills. A deficiency in skills on how to monitor APIs, how to connect APIs, how to key up secure API key authentication. "Those are all lack-of-skills issues that impact API security,” he said.
Perhaps the most important takeaway from his talk is to be aware of how many APIs are in use around the typical enterprise and the risks they create that need to be managed. And to, as he said, know to discover the APIs you've been building, the APIs you're developing, and the APIs that you're using.” “Once you understand what APIs are in the enterprise, monitor for anomalies. You can't secure what you don't know about. The first time some breached organizations even realize they had an API is when that is breached. Then create security policies that include authentication and authorization, but also attack prevention and data support,” he said.
If you don’t, sometime soon, the odds are increasing that an attacker is going to use an unsecured API implementation to steal your data.