Save API Costs With Data-Centric Security

APIs are quickly becoming the front door to modern enterprises. But the API paradigm also comes with various hidden costs around development, management, governance, and security.

A new data-centric security paradigm might be able to leapfrog many of these hidden costs. A side benefit is that this could open new opportunities for data agility while providing a tighter security perimeter in the process.

Digital natives like Facebook, Google, Uber, and Airbnb have demonstrated the value of bringing agility to their data assets. They have grown to prominence on the back of APIs that allow their internal teams and customers to monetize their core data assets in new ways. But smaller companies do not have the same resources. They may benefit from finding ways to protect more data directly, rather than the APIs that sit in front of it.

The Rising Costs of APIs

The rise of APIs as the digital front door has led to new maintenance and data management costs and challenges. Various sources estimate organizations spend an average of $10,000 to $20,000 per API to develop, and about half that to maintain every year.

The travesty of the API is that it also imposes this same cost on each customer, which can also slow adoption and the ability to innovate on top of your API.

Traditional APIs are optimal for situations when there is one producer of data and one app consuming data. But things get trickier when there are many publishers and consumers of data.

Today, data is secured using custom code which is built into the app server. But this model breaks down when there are many who can write and read the data.  In a many-to-many world, developers have to be concerned about ensuring the appropriate read and write rules are built into every application and that those apps are interoperable as updates are made and new apps are added.

This can add up from a cost, time, and resource bandwidth perspective as enterprises develop multiple APIs to provide different kinds of services or to allow applications to connect in new ways. The number of APIs is growing dramatically as more enterprises move to microservice architectures that break applications into smaller components.

Developers also must invest time and effort in organizing the data in the appropriate way for their given use case. This can lead to new kinds of data silos as developers find different ways to organize the data to solve a given task.

Each of these silos creates another attack vector.

Security and Governance Challenges of APIs

Today security is implemented using APIs to provide permissioned data access. Developers must code the APIs to modify database queries to obey security rules. Today this is typically written in JavaScript or Java by a developer rather than a security expert.

As a result, data governance responsibility is pushed to the API layer, meaning that the enterprise ends up imposing responsibility far beyond application management to the API developers.

As new data governance regulations come into effect enterprises are going to need to double down on ensuring appropriate privacy safeguard for the data underpinning their apps.

This can get messy if developers try to do this at the application or API layer since the data can exist across all sorts of systems and servers.

A data-centric approach for traditional companies to be competitive in the new digital economy, data will have to become one of their more important assets. It’s hard to be nimble when the data is organized separately in various systems.

If you have hundreds of app developers each setting up the data structure for their app separately, the data becomes harder to manage. The app developers each must think about what data to use, how to store it, and how to process it. This ends up creating all sorts for different silos.

A much better practice is to set up guardrails across the organization for data access that can be enforced programmatically. This can allow developers to focus on what they are good at around coding logic, while leaving security and privacy decisions to the appropriate specialists. This can also help automate compliance with new privacy regulations like GDPR across development teams.

Once the data is directly protected, it becomes practical to allow developers to retrieve the appropriate data using SQL statements to describe what data they want and the appropriate structure for their needs. This approach can also consolidate data silos and as a result reduce the number of potential attack vectors.

Let the Data Defend Itself

Another benefit of a data-centric approach to security is that teams can start to think about how to create rules that allow the data to defend itself. In the application development world, expressing infrastructure as code allows application teams to programmatically spin up and configure the infrastructure consistently.

Similarly, figuring out how to express data governance rules as data coded into the database will allow teams to bring the same rigor to managing, governing, and securing data at the level of cells, tables, and rows consistently and automatically.

For example, in a privacy-sensitive app, a data privacy officer could configure a rule to allow most users to see the last four digits of a social security number, but not the rest of it. This makes it possible to configure the data privacy preferences of a company’s customers in a way that is stored right inside the data.

There could be generic rules that apply to everyone that has access to their healthcare data if they are connected to the persons as a provider or employer for them. And these rules could be managed in such a way that only the subject can make or amend these rules. While the data might exist openly, this gives the data subject precise control over who can see and access the data about them.

Bringing Security Right to the Data

The Internet security world has been migrating to a new paradigm for protecting enterprise applications and data at a regular cadence. In the 1980s organizations first started implementing packet filter firewalls at the boundaries of networks.

These later morphed into application firewalls that prevented attacks on application logic, and then web application firewalls that focused on some of the specific vulnerabilities in the way web applications ran and the way they accessed legacy databases.

More recently organizations have been replacing web applications with APIs as the front door to the enterprise. This has allowed teams to write an API once, which can be reused across applications running on mobile devices, browsers, or other servers.

This shift has been followed by a massive move in the way hackers seek to attack the enterprise. Until recently, enterprises only had to ensure they were protected against the OWASP Web Application Security Top 10 Vulnerabilities like cross-site scripting and SQL injection.

The group has now added a list of top 10 API vulnerabilities to contend with as well.  A recent survey found that 75% of all credential abuse attacks on financial institutions now target APIs directly.

Perhaps it’s time for the industry to adopt a paradigm around tightening the security perimeter even further to protect data directly rather than out at the level of APIs used to access it. This could also centralize the rules for allowing appropriate access.

Centralized governance, compliance and security teams could set up comprehensive rules for protecting the data in one place, which could automatically be observed across all the applications accessing it.

A data-centric approach to security makes data governance more automated and scalable, which, in turn, allows organizations to open data sets more freely to consumers of that data. By ensuring data security at the data layer, enterprises can be more liberal with data sharing since the security rules will be automatically executed regardless of whether the data is at rest or in motion.

This encourages quicker data decisions and data-driven innovation while mitigating security and compliance risk.

This article is by Brian Platz, Fluree Co-CEO & Co-Founder

About Brian Platz

Brian is the Co-CEO and Co-Chairman of Fluree, PBC, an open-source platform for data ecosystems. Fluree is an immutable, temporal, ledger-backed semantic graph database that has a cloud-native architecture. Prior to starting Fluree, Brian co-founded SilkRoad technology which grew to over 2,000 customers and 500 employees in 12 global offices. Brian serves on the board of directors for Fuel 50, one of the highest growth HR technology startups. He is also the co-founder of A List Apart, a web publication, 22 book series, and global conference for the web development community to expand their knowledge.