My Journey Beyond the Perimeter: Why Firewalls Alone Can’t Protect Your DataDownload Case Study
My first interaction with a firewall was with a TIS Gauntlet that I compiled on a Sun workstation in 1994. Since then, I have worked with firewalls from Checkpoint (back when configuration files were clear text flat files and they only had support out of their headquarters in Israel), Raptor, Pix (when they booted from a 3 ¼” floppy), and finally the Cisco ASAs, FortiGates, and Palo Alto firewalls of today.
As different use cases arose, we started hanging additional gear off the firewall, such as IDS, email gateways, and URL inspection filters. Over time, the firewall started resembling a Christmas tree with troubleshooting traffic flows requiring skills similar to untangling tree lights.
As cloud adoption took off, I moved to cloud models for security: Illumio's central configuration for OS firewalls, and NSX from VMware, which was firewalling in the hypervisor. Suffice it to say: I've done firewalling in just about every way imaginable. After decades of firewalling in dozens of different ways, the underlying grumble persisted. Firewalls, while critically important, fall short in addressing problems like the insider threats, phishing and malware.
Over the last few months, I learned a few paradigm-shifting revelations that resulted in a career shift.
Firewalls don’t have the full picture
Perimeter security has one fundamental flaw in its approach — a perimeter firewall treats traffic in a binary manner. A traffic flow is either allowed or it’s not. But the world has a lot of nuance to it. The very same resource I can access from home may not be a resource I should access from a coffee shop with shared Wi-Fi, for example, even if I’m using my corporate user login on a corporate laptop. In other words: source IP, destination IP, and port make up an incomplete dataset and an access decision needs to take into account context such as previous user behavior.
A comprehensive product like ZeroTrust Network Access (ZTNA) makes decisions based on an access equation that takes into account user behavior and device risk level. With continuous conditional access, Lookout adapts and responds to changes in circumstances during the session.
But access alone is insufficient. This brings me to my next point:
It’s all about the data
The security question shouldn't be limited to my laptop accessing an application because, at the end of the day, the app is not the concern. Protected health information (PHI) and personally identifiable information (PII), which are subject to HIPAA and PCI fines when leaked, are data, not apps. Customer lists, patent designs, secret sauce recipes and even the software source code itself are all data.
Apps are there to manipulate data
All of the protecting servers or IP addresses running apps will not solve the fundamental problem of the data residing there. Access is required to these things to get the job done, but it is only some of the data that is sensitive. At the end of the day, enterprise apps are a means to manipulate data: they collect the data, they massage the data, or they display the data.
Further, there is a false sense of security that comes from securing only the apps. Just because the app has controlled access, it doesn’t mean that the data itself is secured. This binary thinking will result in either restricted access due to the presence of some sensitive data, which will limit business, or overly generous access, which introduces risk. Moreover, unless app data contents are reviewed at every release, assumptions of app access is a very poor proxy for data security.
Data comes in all forms
Finally, we have to recognize that data exists in all kinds of forms, not just databases. There are spreadsheets with revenue numbers and many more forms of data that need protection because... it’s all about the data! Thus, having data loss prevention (DLP) native to your security stack is essential.
Protecting data does not have to inhibit collaboration
In my early years, I thought that data protection inhibited collaboration. I viewed data protection through my binary perimeter lens of allow/disallow. I thought data was an amorphous blob to which one allowed or disallowed access as a whole. It blew my mind when I finally saw that content could be shared with the sensitive bits redacted.
This is a whole new ballgame: documents with sensitive data can be shared, as long as the sensitive data is automatically redacted. When the concern about sensitivity is removed from the user and placed on tooling, collaboration becomes easier and security posture increases. The actual social security number or credit card number is important for record identification, but it doesn’t matter as much as the data associated with that identifier.
The binary allow/disallow world has fostered the shadow IT movement, but, by using modern digital rights tools, such as enterprise digital rights management (EDRM), there can be intelligent controls such as removing external users from a share when sensitive data is presented or proactive encryption that ensures the data can only be accessed by authorized users.
Data leakage is not just a server problem
One recent revelation was the idea that data leakage often happens at mobile endpoints. Lost or stolen devices result in more than two-thirds of electronic protected health information (ePHI) breaches. This makes sense, given that mobile apps often pull data from other apps. But something I haven’t thought about is the idea that data can leak laterally. From a consumer perspective, it’s only my data being swapped by apps, and I presumably consented to share the data. From the enterprise perspective, however, this means that employees who download a work email attachment, or text it to a contractor, could now be another point of data leakage.
Performance concerns do not apply in the cloud-native world
As a longtime firewall jockey, I cut my teeth on the security inspection and performance tradeoff that defined appliances. As such, we lived in a world of sufficient security due to performance limitations. With services born in the cloud, these traditional performance concerns have dissipated. Cloud-native security products can now supplement appliances to perform security inspection at a level that was previously impossible.
I now believe that, while firewalls are necessary, they aren’t sufficient. We need to evolve our security thinking from a perimeter, access control-centric view to a distributed data-centric one. It’s less about guarding access to the castle and more about guarding the jewels.