On March 18th, our very own API Security Expert Pieter Van de Broeck and Security Architect at Colruyt Tom Pieters were guest speakers at the 12th Lunch Session of the API Community.

A summary:

API Security, there is no getting away from it. It is already the hottest topic of 2021 in the fascinating world of APIs. However, it is of major importance to find an approach that fits the requirements and ambitions of your organisation.

APIs establish an important channel to your enterprise’s systems, data, and services. Therefore, it is crucial to keep highly focused on API security to prevent business/reputation loss, competitor’s gains and so much more. We all remember the Facebook saga, where the personal information of 50,000,000 (million) of their members was made publicly available by accident. You do not want to be the next in line!

Why API Security is on a rise

A lot of organisations have already been working with APIs for the last couple of years. Nevertheless, API Security became a hot topic only recently. You might wonder, why just now? One of the main reasons why API Security has become so important can be found in the digitalisation of our society. As a customer, we expect that our preferred brands and companies create digital products and services. As a result, more information and functionalities are getting exposed outside the boundaries of the organisation, which requires an additional focus on security.

To get the most out of your digitisation process, it is highly important to introduce these digital products and services to the right stakeholders. In doing so, many organisations choose an omnichannel approach to extend their market reach. These channels can be their own channels, but also partner or third-party channels. In addition, depending on your business, you might be required to do some authorisation as this is being monitored by the government.

API Security, more than you might expect

The API landscape will continue to grow as we are becoming more and more digital. As a result, organisations will create more and more APIs, which means that the attack surface will continue to expand. This means, also API attacks are on the rise. Gartner predicts that APIs will become the number one attack vector by 2022. The industry is reacting to this with a new API Security guidance based on the OWASP API Security Top 10 for example

When we start thinking of API security, we think about authentication and authorisation aspects. But if we look at the OWASP top 10, we see that only half of the risks are related to authentication and authorisation topics. Therefore, API security - end-to-end- could be more than you might first expect!

Authentication and authorization are just a few aspects of API Security, so don't forget to keep in mind Traffic Management and Information Management.

Pillar 1: Authentication and Authorisation

You might think: “Let’s apply OAuth2.0 and we’re done!” However, it is very unlikely that your API landscape matches a one-size-fits-all approach. We advise you to categorise your APIs in terms of security levels. When you define the characteristics of your APIs, the right security level can be determined. For example, you can link it to the CIA model, which is based on the confidentiality, integrity, and availability of the information that you expose to your APIs. However, this can be hard to determine as you need frameworks to identify these aspects. Conclusion: you must find a way that is applicable for your organisation and its API maturity level.

Do not jump into determining your technical mechanisms yet. It is not because you decided to start securing your APIs, that you already know what technical mechanisms suit you best. You must determine this based on your requirements and ambitions. Not all APIs require a bullet proof solution as this brings a lot of added complexity to your IT landscape.

Three security requitements and ambitions that are often used are:

  • Level 1: do nothing vs identification of your APIs?
  • Level 2: Client + end-user authentication and authorisation using 1-factor
  • Level 3: Client + end-user authentication and authorisation using 2-factors

When all of this is clear, you are totally set to start defining your actual mechanisms. Keep in mind the security patterns: it is not because you defined your levels and requirements, that it is clear for everyone which mechanisms need to be used!

Pillar 2: Traffic Management

It is not because you added authentication and authorisation to your APIs, that they are all protected. Some of your APIs will have nothing to apply to in an authentication and authorisation level. Even though they are secured in that fashion and you highly trust your partners, things can go wrong unintentionally. Think about a programming error in your partners' application with thousands of API calls as a result, or even worse, the hack of a partners' application. Conclusion: to have an end-to-end secure API, it is not only about authentication and authorisation.

When we take a closer look to Traffic Management on an Application & Transport Layer, we can identify two levels of Traffic Management:

  • Application level (API): controls that can be defined and controlled on each individual API.
  • Transport level: applying controls that are spanning multiple or all APIs. Protection is typically handled by components like web application firewalls or other security layer components.

During client discussions about Traffic Management, we often hear: “we want to have guaranteed availability of our APIs and our back-end services.” This is where rate limiting & throttling comes into the picture, one of the traffic management capabilities an API gateway can offer. Or “our APIs need to be protected against malicious attacks from our API consumers.” Enter threat detection & prevention. This can be done on a Network Gateway (F5) or an API Gateway. But what if, despite all possible security measures, a malicious API consumer is still able to break through your API security line of defense? This is where logging & monitoring kicks in by providing insights into the usage of your API - like how many times APIs have been used during a specific time period - but it also offers you an audit trail on who has been accessing your APIs and when they have been accessing them.

Pillar 3: Information management

If you do not classify your information in a sufficient way, it is possible that you leak some unwanted pieces of information to your API. The moment you expose information to your API, it is accessible for whoever uses it. You cannot rely on the consumers to perform data filtering on their side. When you expose it, it is accessible!

Apisecpieer

But how do we bring all these security aspects together? We have the actual API implementation, on top of that an API Gateway and a Network Gateway. Discussions will rise on which of the gateways these aspects need to be applied to when it comes down to security. However, we have global restrictionsthat relate to the Network Gateway. When we link this to the Traffic Management pillar, we see that Network Gateways handle everything related to the traffic management transport layer. Conclusion: the API Gateway also does a lot of things when it comes down to Traffic Management, but it is more linked to the application.

Key Advice

When you are going to define your API security approach, do not forget to tackle all aspects of the program below. “The road towards a secure API landscape - The Colruyt Group Story!” is a perfect example on how to approach this the correct way.

Schermafbeelding 2019 08 12 om 13 32 14

Talk about your API Security needs? We would be happy to get in touch!

WE ARE LOOKING FOR AN INTEGRATION ARCHITECT OR API ANALYST! ANY INTEREST?