API Security Tools | Cloud Access Security Brokers


Recently, when I spoke to Sorell Slaymaker, we agreed to the fact that every technology has its own time and place. Often a specific product set is forcefully molded to perform all tasks. Obviously, this carries along its own problems. For example no matter how modified the Next-Gen firewall is, it is unable to provide total security.

As you know, that’s why we need other products, such as, a proxy or a cloud access security broker (CASB) to work alongside the Next-Gen firewall to complete the full picture. Rationally, one size does not fit all when it comes to security.

Introducing API security tools

An application programming interface (API) is a standard way of exchanging data between systems, typically over an HTTP/S connection. An API call is a predefined way of obtaining access to specific types of information kept in the data fields.

However, with the acceleration of API communication in the digital world, API security marks a key moment as the data is literally being passed everywhere. The rapid growth of API communication has resulted in many teams being unprepared.

Although, there is an ease in performing the API integrations but along with that comes the challenging part of ensuring proper authentication, authorization, and accounting (AAA). When you initiate an API, there is a potential to open up calls to over 200 data fields. Certain external partner may need access to some, while others may require access to all.

What that means, is that a clear and concise understanding of data patterns and access is critical for data loss prevention. Essentially, bad actors are more sophisticated than ever before and to simply understand data authorization is not enough to guard the castle of your data.

The challenge

Many enterprise security groups struggle to control the shadow IT, managing all Amazon web services (AWS) accounts is one example, where AWS employs tools, such as, Macie that are used for API management.

However, these tools work well for only AWS accounts that Macie is turned on for. Enterprises can have hundreds of test and development accounts that carry a high risk of data leakage, which the security teams are not aware of.

Also, containers and microservices often use transport layer security (TLS) connections to establish secure connectivity between them, but this falls short in a number of ways. When we examine the world of API security, it poses the biggest challenge that needs to be solved in the years to come. So what’s the solution?

The way forward

Let’s face it! The digital economy is run by APIs which permit exchange of the data that needs to be managed.

With the acceleration of API communication, API security tools have become a top priority. We don’t want private, confidential, and/or regulated data to leave that is not supposed to leave and we need to account for data that does leave.

If you don’t have something in the middle and simply encrypt just the connections, then data can flow in and out without any governance and compliance. Ideally, a turnkey product to manage API security in real-time that is independent of the platform: be it in the cloud, hybrid, or on-premise, is the next technological evolution of API security tool market.

Authentically, having an API platform across the entire environment, enforcing real-time security with analytics, empowers the administrators to control the movements and access of data. Currently, the API security tools fall into three different types of markets.

  1. Cloud Access Security Brokers: The API security is between an enterprise and the cloud-hosted services, such as, O365, SFDC, ADP or another enterprise.
  1. API Management Platforms: They focus on creating, publishing, and protecting an API. Development teams that create APIs, which are consumed both internally and externally rely on these tools as they write applications.
  1. Proxy Management: They focus on decrypting all the enterprise traffic, scanning, and reporting on any anomalies. Different solutions are typically used for different types of traffic – web, email, chat are some of the examples.

Cloud access security brokers

The rise of CASB occurred due to inadequacies of the traditional WAF, Web Security Gateway and Next-Gen Firewalls product ranges. Factually, the challenge with these traditional products is that they work more as a service and not at the data level. They operate at the HTTP/S layer, usually not classifying and parsing the data. Their protection target is different from that of a CASB. Let’s understand it more closely.

If you parse the data you can classify it. Then you have rules to define the policy, access and the ability to carry out analytics. As the CASB solutions mature, they will become more automated. They can automatically do the API discovery, mapping, classifying and intelligent learning.

The CASBs provide a central location for policy and governance. The CASBs sit a boundary between the entities. It is backed by the prerequisite to be able to decrypt the traffic, be it a TLS or IPSec. After decrypting, it reads, parses and then re-encrypts the traffic to send it on its way.

When you are in the middle, you need to decrypt the traffic and then parse it to examine all the data and then classify it. Once it is classified, if there is specific data that is highly sensitive be it private, confidential, or regulated, you have the ability to tokenize it or redact at a field and file level.

Many organizations previously would create a TLS or IPsec connection between themselves and the cloud provider or 3rd party network. However, they didn’t have strict governance or compliance capabilities to control and track the data that is going in and out of the organization.

TLS or IPsec is the only point-to-point encryption and once you get to the end location the traffic is decrypted. As a result, sensitive data is then available which could be in an unsecured network.

Additional security controls are needed so that when the connections are complete, the data has an additional level of encryption on it. TLS or IPSec is for the data in motion and tokenization is for the data at rest.  We have a number of ways to secure data and tokenization is one them. Others include encryption with either provider managed keys or customer BYOK. We also have different application layer encryption.

Tokenization substitutes the sensitive data element with a non-sensitive equivalent. The non-sensitive equivalent is referred to as a token. As a result, the 3rd party needs to have an additional set of credentials to see that data. 

However, when you send the data out to a 3rd party, in fact, you are adding another layer of encryption on it by putting in a token, instead of a specific number like the social security number. Redact means that the data is not allowed to leave the enterprise.

For API security, AAA is at an API layer. This is different for the well-known AAA model used for traditional network access control (NAC). Typically in the network world, you are allowing IP addresses and port numbers. In an API world, we are at the server and service layer.

DLP is a common add-on feature for CSBs. Once you parse and classify the data, you can then govern it. Here, what is of primary concern is what the data is allowed to leave, who is allowed to access and when? The DLP is an entire market in itself, whereas, the CASB will be specific for specific APIs. More than often you need a different DLP solution, for example, to scan your word documents. Some vendors bundle in DLP and CASB.

Presently, the next-generation CASBs are becoming more application specific. They now have the specific capability for Office 365 and SalesForce. The market is constantly evolving and over time it will integrate with the metadata management.

API Management Platforms

API Management platforms are used by DevOp teams when they are creating, publishing and protecting their APIs. DevOps create an API that is consumed internally and externally to enable their application rely on these tools.
In an enterprise, had everyone been using an effective API management tool, you wouldn’t need a CASB. One of the main reasons for introducing CASBs is that you have a lot of development and test environments that lack good security tools. As a result, you need the 3rd tool to ensure governance and compliance.

Finally, Proxy Management

A proxy monitors all the traffic going in and out of the organization. A standard proxy keeps a tab on the traffic moving internally to the site and a reverse proxy is an opposite, i.e. an external organization looking for internal access to systems.

A proxy operates at layer 5 and layer 6. It controls and logs what the site users are doing but it does not go into layer 7 where the all-important data is.

About Matt Conran

Matt Conran has created 176 entries.

Leave a Reply