Securing APIs From Threats

Today’s software systems communicate with each other via APIs (application programming interfaces) to exchange data and perform actions without having to build a new connectivity infrastructure.

For example, when a bank’s system contains a consumer’s account data, the banking app on the consumer’s phone talks to this system via APIs to retrieve and display the requested account information. Behind the scenes at the bank’s data center, software from both service and technology providers are also talking to each other via APIs.

However, every connection and transfer of data using APIs can provide an entry point to hackers trying to steal data or act maliciously. Hackers will look for a company’s weakest link to gain access to its systems – which is often APIs. As a technology provider in the highly regulated financial services industry, ICE understands the stakes involved around API security, and we are constantly evaluating how to further enhance the security of APIs.

Any company building APIs should use a multi-layered approach to thwart attacks. Such an approach offers additional protections – if a hacker breaches one layer, there is another layer of defense to stop them. It only takes one successful attack for a hacker to cause serious harm to a company’s systems and reputation, so diligence is critical.

Types of API threats

There is no question that hackers are smart and determined. Some of the nation’s largest mortgage lenders can experience as many as 10 million rogue requests in a single day. There are many different types of attacks, from “Man In the Middle” (MitM) where the bad actor steals or manipulates data to distributed denial-of-service (DDoS) attacks that crash systems.

Brute force and dictionary attack are common techniques where hackers try different combinations of credentials (or data) to gain access. Once hackers get in, they often attempt to steal data in bulk. Rate limiters can be used to restrict the number of calls in a given time period to prevent massive data theft. Hackers also use sudden spikes in traffic to crash systems. Spike arrest security can protect downstream systems and prevent a total outage.

Keeping hackers out

When hackers attempt to breach APIs, companies should be prepared with multi-layered security. The following outlines several best practices.

API keys and basic authorization

The first level of API security is authentication to verify the calling system’s identity. This layer of security begins with requiring a set of credentials, which is typically called an API key. Because hackers work hard to steal passwords and “crack the code,” this authentication layer typically includes a few measures:

Certificate-based authentication

Even when the caller has a valid API Key, the API should continue to verify that those credentials were not stolen, and that the API call is originating from the right source system. Client-side X.509 certificates with mutual-TLS are a common approach used to further secure the communication channel source. This certificate verifies the identity of the caller and whether their request is coming from the right source system.

Network level security

Another layer of protection is network level security to verify that the caller is coming to the API via a secure network channel. This can be accomplished using either IP restrictions or by requiring either a VPN or a private dedicated line (such as MPLS) that runs between the caller’s data center and the API destination data center. For example, a calling system must be physically within the right data center and invoke the API over the dedicated line to be able to access the API.

Internet security – token-based authentication

When APIs are exposed over the internet, threat surface for attacks significantly increases because there is no additional network security available. For example, ICE may have a private MPLS line with one of our banking clients, but when the banking client’s customers use a mobile banking app that needs to access an ICE API, a private line requirement is insufficient. In this case, when accessing an API over the internet, the banking client’s customer’s identity is verified using a JSON Web Encryption (JWE) token and must be provided via a secure HTTPS connection.

Data encryption

APIs transmit data between systems so there is always a risk that a hacker will intercept NPI and PII data while it is in transit. Apart from the network security and certificates discussed earlier, the actual data points in the payload that is going back and forth should be encrypted using either symmetric key encryption (for e.g., AES-256) or asymmetric key encryption. This is called payload level data encryption and provides data protection in-transit between the caller and the destination API.

Internal threats

When preparing for API threats, it’s important to also look on the inside of the organization. A rogue employee can deliberately work with a hacker on the outside or an employee might innocently cause security risks without being aware. Providing security training and having strict code deployment approval processes (such as separation of duties) can mitigate risks from the inside.

API monitoring

How do companies know when a hacker is attempting to penetrate their systems, or if penetration is successful, what damage the hacker may have caused? Sometimes companies might not recognize a security breach until days or months later.

If a hacker made it past security, the next step is to quickly determine the scope of the attack, or the attack surface. Did they access all the data, or was the access limited? One of the goals of securing APIs is to reduce the attack surface. The bigger the attack surface, the greater the need for additional layers of security and proactive monitoring to prevent, detect and deter malicious actors.

Protecting systems after a security breach occurs requires constant API monitoring. Companies need an audit trail to figure out what was stolen and how it was taken. These forensics provide the intelligence to improve API security and thwart future attacks.

Conclusion

API security should be a top priority for all businesses because millions of attacks on financial institutions happen every day. It is vital to have multi-layer security to protect APIs and to maintain constant vigilance in monitoring APIs for malicious activity. Financial service providers and their vendors need to be right 100% of the time – hackers only need to be right once.

A single event which compromises data will negatively impact a company, its customers, and its reputation. When building APIs, every company should be focused on protecting its APIs, systems and confidential information.