Sensitive Data Exfiltration: The New Nemesis of API Security

Sensitive Data Exfiltration: The New Nemesis of API Security

This past year has brought many different industries some of the worst data breaches in history, and API data breaches have topped that list. Large companies such as T-Mobile, Optus, and several automotive companies have unfortunately been on the receiving end of disastrous (and preventable) breaches – all at the API layer.

While those breaches were disruptive to the companies’ operations, the biggest issue (again) is that consumers ultimately pay the price. After all, it’s their data that gets sold across the dark web. 

The most recent trend we’re seeing is that APIs, since they are closest to the data layer, are now being abused in ways that access and reveal sensitive data.

What is Sensitive Data Exfiltration?

Sensitive data exfiltration is the unauthorized access and transfer of sensitive data from a secure network to an external destination. This can be done through a variety of methods, such as email attachments, file-sharing websites, or removable media.

And now, sensitive data exfiltration is happening more frequently via API.

Why is it a concern?

The exfiltration of sensitive data can have serious consequences for individuals and organizations. For individuals, the loss of personal data can lead to identity theft, financial fraud, and other types of cybercrime. For organizations, the exfiltration of sensitive data can result in regulatory fines, legal action, and damage to reputation.

And it often happens when non-sensitive data is breached. In fact, this is one of the biggest concerns about the recent T-Mobile API data breach. 

This unauthorized API access exposed data including names, emails, phone numbers and birthdates as the source of the breach. T-Mobile stated that the bad actor did not obtain all data from every one of the 37 million customers affected. It was specifically prepaid and subscription customers who were impacted; hackers apparently also obtained data including the number of lines on the account and service plan features.

T-Mobile said no social security numbers, credit card information, government ID numbers, passwords, PINs or financial information were exposed in the hack.

However, that doesn’t matter. 

While the data stolen at T-Mobile is certainly different from more sensitive data such as PII, PHI or account information that is often found in financial services or healthcare organizations, stolen data such as phone numbers and email addresses still pose a threat to consumers, especially if the hacker knows that the information is recent and therefore, likely to be valid, and lead them to more sensitive types of data. 

For example, the increased risk of identity theft, social engineering and phishing, typically increases as a direct result of data breaches, even if the hacker lacks specifics like passwords or other information that could help them gain additional access. 

The exfiltrated data typically ends up on the dark web, and will be used on other web applications and APIs for months – maybe years – to come.

How can it be prevented?

Preventing sensitive data exfiltration is a multi-faceted effort, and requires coverage across several areas across an organization. These are typically the basic steps that organizations have focused on, to prevent sensitive data exfiltration:

1. Implement strong security measures: This includes things like strong passwords, two-factor authentication, and regular security updates.
2. Educate employees: Make sure that employees are aware of the risks of exfiltration and how to prevent it. This can include training on how to spot phishing emails and how to handle sensitive data.
3. Use encryption: Encrypting sensitive data makes it much more difficult for attackers to access and steal it.
4. Monitor networks: Use monitoring tools to detect and prevent exfiltration attempts. This can include network intrusion detection systems and data loss prevention tools.
5. Implement access controls: Restrict access to sensitive data to only those who need it, and use tools like access control lists to manage and monitor access. 

Before APIs started to become the primary means of data exfiltration, there were many methods used to exfiltrate sensitive data. Some common methods include:

1. Email attachments: Sensitive data can be sent via email attachment, either intentionally or accidentally.
2. File-sharing websites: Sensitive data can be uploaded to file-sharing websites, where it can be accessed by unauthorized users.
3. Removable media: Sensitive data can be copied onto removable media, such as USB drives or DVDs, and then physically removed from the secure network.
4. Cloud storage: Sensitive data can be uploaded to cloud storage accounts, where it may not be adequately protected.
5. Network transfers: Sensitive data can be transferred over the network to an external destination, such as a personal email account or a remote server.
6. Social engineering: Sensitive data can be obtained through social engineering techniques, such as phishing or pretexting.
7. Malware: Malware, such as viruses and trojans, can be used to steal sensitive data and exfiltrate it to an external destination.

What is Now the Biggest Vector for Data Breaches? The API Layer.

“But I Have a WAF”

We have heard many senior executives say, “I don’t have an API security problem because I have a gateway and a WAF.” To which we say, “Are you a hybrid organization? Do you have on-premises still and large business applications that you were unable to refactor to cloud in your cloud journey?”

Newsflash: API Security and the Protection of Sensitive Data is Not Achieved Through WAFs and API Gateways

API Gateways and WAFs do NOT provide API Security, because they cannot detect truly malicious behavior, keep bad actors out, or protect data from exfiltration via APIs.

And worse, if your current API security solution is simply looking at the edge, what you have isn’t API security, but a glorified WAF.

Furthermore, solutions providing visibility only at the edge can’t claim they are context-based or context-aware in any meaningful way.

 

We are now at Layer 7 security. That security is needed as applications are now becoming the prime intersection for all data, all transactions and the passing of information back and forth. And yet that layer has historically had the worst track record in terms of security, which is not the fault of developers. Developers are in business to create value based upon business needs. They are the translation layer to make technology do cool things.

Our expectation that developers should provide heightened cybersecurity awareness is just kidding ourselves, because history clearly shows that human beings really stink at personal risk and security management, and developers are people. 

The API security layer is laboring with a huge misperception that I don’t have a security problem – and that assumption is wrong. The traffic that looks like it’s supposed to be good can actually be malicious and not be caught by API gateways and WAFs. That’s the predominant way that these breaches happen. And a lot of leaders are shocked when they realize that their statements about being protected in this space were grossly exaggerated.

About Traceable

Traceable is the industry’s leading API security platform that identifies APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. With visual depictions of API paths at the core of its technology, its platform applies the power of distributed tracing and machine learning models for API security across the entire development lifecycle. Visual depictions provide insight into user and API behaviors to understand anomalies and block API attacks, enabling organizations to be more secure and resilient. Learn more at traceable.ai.