Data security is becoming even more difficult
Data security includes securing the data itself, and also ensuring the data pathways are secure. For example, ensuring that the data pathways can’t be hijacked to be used to plant malware or ransomware, or to steal IP addresses for botnets, or to launch DDoS attacks. So data security has always been difficult. And now it is getting to be far, far more difficult due to this trio of factors:
Factor one: Big Data is multiplying
Big Data is, well, getting even bigger. By 2025, it’s estimated that 463 exabytes of new data will be created each day – that is about equal to creating 200 million new Netflix shows per day, and means there will be 40 times more bytes of data than known stars in the universe! Lots of data means lots of files, blobs, databases and data lakes…across lots of attack surfaces (and often attractive ones for cyber criminals to attack).
Factor two: eyeballs and machines are growing and becoming more distributed
While the data continues to multiply at astronomical rates (pun intended), the number of data consumers is also dramatically increasing. People such as data scientists, supply chain partners, and customers, as well as APIs and machines (like the Machine Learning (ML) and Artificial Intelligence (AI) systems which are helping to derive insights from this data). Importantly, many of these eyes and machines are often outside of our organization, creating a data topology which is difficult to defend.
Factor three: both the data and the pathways are becoming more sensitive
Consider the privacy aspects of personal health data and genetic data. For example, the mRNA advances during the C-19 pandemic response have been phenomenal – they set the stage for extremely promising and exciting genome-specific treatments – and will mean research and analysis of petabytes of generic data. Similarly, consider the data flowing back and forth to autonomous cars or robots in automated warehouses – the data pathways become possible conduits for the types of attacks which can redirect cars or robots, potentially endangering many lives. These pathways become particularly problematic when they can potentially stop an entire supply chain.
Those three factors mean the cost and complexity of securing the data in going through the roof. We’ll spend over $300 billion on cybersecurity in 2025. Spoiler alert: much of that money will be wasted on what amounts to a false sense of security. Second spoiler alert (is that allowed?): there is a better way; we can replace bolted-on infrastructure based security with built-in security (Security as Code) to get stronger security and better business velocity…in fact, we’ll show a live demo of it in the video below.
Data security: addressing the new challenge by evolving from bolted-on to built-in
Bolted-on data security is alphabet soup: ALGs, WAF, VPNs, firewalls, proxies, MPLS, SD-WAN, proxies, bastions, IPS, IDS, SWG. You may win a lot of Scrabble games playing with bolted-on security, but it slows down your business, and costs you an awful lot of dough.
In the past, we stomached that pain, because we needed security. Now, due to the three factors described above, this bolted-on approach is no longer secure – and in fact it is a vulnerability (e.g. just about every VPN, SD-WAN and firewall vendor has caused businesses to be breached due to their bolted-on infrastructure itself being vulnerable in the past 12 months alone – here is a list which includes Cisco, Citrix, Fortinet and Palo Alto. Let’s take a deeper look at the inherent problem in bolted-on infrastructure based security:
Here we see that firewalls are not aptly named – they are more like sieves than walls. All those red holes are created to enable the data path between your “private data” and its consumers. In fact, if you can find a firewall that does not have those holes (open ports and ACLs), then you probably found a firewall with dust on it in a lab (you can find a detailed explanation of these problems in this post in the context of supply chain security). It actually gets far worse – the data flows which go through those open holes are not identified, authenticated and authorized before they flow. So, yeah, this is a beautiful diagram…if you are a cyberattacker.
So, if your private data is behind an expensive set of firewalls, VPNs, MPLS, etc…please know that the path from the Internet to your data is still there (check the recent slew of ransomware attacks if you want some painful proof). If that path is still there, then how effective can the bolted-on infrastructure possibly be? Why constrain your business innovation, agility, velocity and automation, and spend ridiculous amounts of money, if the data is still exposed? The answer used to be because there was not a better alternative (and, to be fair, the legacy bolted-on infrastructure worked back in the day when the app topology and business challenges were different). Now there is a better alternative. Security as Code. Built-in replaces bolted-on. Code replaces configuration. Software replaces hardware. Agility and security become allies, helping each other, instead of enemies in a tug of war. We all get new Teslas. Ok, maybe not, but you get the idea. Better yet, check out the video below for a live demonstration.
Security as Code
If a picture is worth a thousand words, then videos may be worth 10k. In the video below, Clint shows us Security as Code in action. Here are the cliff notes:
The Postgres data is actually fully private and dark to the networks
No open ports. No link listeners waiting for unidentified data. No leaky firewalls.
The user just uses the data client (e.g. Tableau, PowerBI or IBM Cognos). The data client itself has added zero trust security into its code. This both improves user experience and eliminates bolted-on vulnerabilities (such as VPNs).
Identity, authentication, authorization
The application session is identified, authenticated and authorized by a bootstrapped secure identity system, with bi-directional x.509 certificate validation. After authorization, an ephemeral overlay ‘network of one’ is created by the software for this specific authorized session, including a zero trust data plane for the session (using the zero trust software routers shown in Clint’s diagram). There is only one data rule on the data plane: deny all other data.
Open source software
All the components which make this work are software (Ziti – NetFoundry’s open source Zero Trust software). In fact, Clint spins them up, as code, in about 15 minutes. This enables the zero trust app connection to be embedded in the app (eliminating the need to delegate the connection security to insecure networks, firewalls and VPNs), and enables app connection security to be fully programmable, extensible and scalable (critical – zero trust is a journey). Security as Code.
Yeah, it all sounds too good to be true…but fortunately you can pick up the open source and try it yourself, building zero trust into your app. Start with zero trust Mattermost, your data analytics apps (like this Postgres example), or enable zero trust SSH and zero trust SCP and zero trust apps in Kubernetes by making them into zero trust services, as code.
Building the third leg of the Security as Code stool
Security as Code puts security into the nucleus of your application development and delivery lifecycle. This enables us to codify security policies, test them, monitor them and find bugs during the development lifecycle. This proactive approach to security is the only way to get security in a modern application topology in an economical and extensible manner. It is similar to the value we get from a mature DevOps culture, and is sometimes in fact labeled as DevSecOps.
Security as Code is a three-legged stool, standing on three different legs: security testing, vulnerability scanning and access control. There is an abundance of great tools for security testing and vulnerability scanning. However, access control was the elephant in the room – the missing leg of the stool – how can an app developer, ISV or MSP possibly use code to control networks, firewalls and VPNs when often there is not even a single party which owns all that bolted-on infrastructure for a given data flow? Now, there is an answer for this critical third leg of Security as Code – stop delegating app session security to bolted-on infrastructure and instead ISVs can build it into the app, and MSPs can enable zero trust.
So, this third leg of Security as Code is to take the app (and its users, devices and data stores) off of the networks, and enable the app to make its own zero trust overlay connections with proper identification, authentication and authorization. Not only does this evolve your security to respond to the three Big Data trends outlined above, but it will result in better business velocity, innovation, automation and agility (end the tug of war between security and velocity by inserting security, as code, into your app development and delivery lifecycle).