API Security for the Data Layer
Tags: security, privacy, devops, architecture
Published: 2020-05-30 05:20:26

Over the past week, there has been an average of at least 1 data breach news story per day around the world. The companies involved include mobile providers in India and Pakistan, a health care system based in St. Louis, law firms in the UK and more. As data privacy and security become front and center it’s time to take a step back and think about how one can successfully secure their data in a cloud-native world.

Cloud-native data endpoints are public facing. As one thinks about securing them perhaps it makes sense to look at another public facing endpoint - an API - and glean lessons from it. 

One increasingly popular approach to API security is to centralize it using an API Gateway. API Gateways simplified the entry points into applications. They allow for dynamic routing based on the requestor. They have also allowed for centralized security standards and policies to be applied. These rules can be auto updated based on learnings. The gateway also logs all accesses to the API. These logs provide an audit trail, the ability to do analytics and can be used for forensics when something bad happens. An API Gateway leverages identities to control authentication and authorization against the API. Ideally, an API gateway provides all of these capabilities in a generic fashion across APIs of all personalities. 

If we are to prevent data layer security breaches then we need something akin to this for the data layer. We need technology that works across any type of data endpoint whether it is SQL, NoSQL, data warehouses, pipelines etc. This technology must be able to log all activity, detect anomalous behavior, and enforce fine grained access control on data. The need for this solution only grows as companies adopt a truly granular microservices architecture, where there is a database per service.

So, how exactly would technology like this have prevented the breaches we’ve recently seen:

* By enforcing policies, it could have prevented access to certain attributes altogether. 
* It could have alerted security teams or blocked certain connections after detecting exfiltration.
* It could have applied masking so that even if data left the system it did so in a fashion that made it useless for an attacker.
* It could have logged all accesses to the data leaving behind a rich trail for forensics.

As with other security solutions, for it to be effective, any such data layer security solution must be able to sprint in a DevOps environment. It must be easily deployed in an Infrastructure as code environment. It should enable automation. It must work in a highly available and scalable environment. To truly enable foundational security, it must be built from the ground up and be central to the architecture from development all the way to production.

Whenever we think about security in a general context, the data exposed is what drives the impact of the breach. Now more than ever, so much of our lives exist online. We are entrusting our data with companies and implicitly trusting that they will keep it secure. For the longest time, I was most excited to work in the intersection of security and finance because of the real and tangible protections that were needed there that impacted our everyday lives. Those protections are still needed, but our online data is worth so much more than just dollars and cents. Our privacy, our memories, our connections, our friends are all impacted. As a new parent, I would be devastated if all of the photos I have of my child were shared without my permission. I still see gaps in the way that companies are protecting our data, and that is why I am excited to be working with Cyral, to focus on building a product that monitors and protects the core of what we all care about, our data.

Image by Abraham Pena via the OpenIDEO Cybersecurity Visuals Challenge under a Creative Commons Attribution 4.0 International License