What Is SASE? Part One: Zero Trust

Before I go any further, I’ve got to walk the walk. To the right is my authentication; my business card. Conveniently my card has my phone number. You’ve got my name, employer, and phone number (MFA) so give me a call (not SMS) and let’s catch up for a beer or coffee while we share security horror stories.

On to SASE. What is SASE (Secure Access Service Edge)? Don’t feel bad if you don’t know. If you search for SASE using duckduckgo.com you will see some major security companies, like two shown below, are asking the same question 😊

The acronym SASE, pronounced “sassy”, was coined by The Gartner Group and is a multi-technology framework that describes an approach to address evolving security requirements associated with cloud adoption. Simplification of the management of security technologies is also fundamental to the SASE model.

Although the perimeter was already under assault from the burgeoning adoption of cloud services, the proliferation of the BYOD model assured the traditional enterprise perimeter would go by the way of the Berlin wall. The perimeter isn’t actually gone, it’s just that for the most part it has morphed and migrated to the cloud. As such, security solutions must be adapted and created to address unique aspects of this environment.

The Zero Trust (ZT) model is foundational to SASE. ZT finds its origins in the Russian proverb “доверяй, но проверяй” which, of course, you know means “Trust but verify.” It sounds a lot like whitelisting. You trust no file before whitelisting it, and then you regularly scan the file to ensure you haven’t missed something. Zero Trust extends the concept… to everything. Multi-factor authentication (MFA) is one aspect of ZT. However, devices must be properly authenticated as well. This means having a device compliance policy and technology. Are the security products that belong on the device present, functioning, and current? In memory processes need continuous validation as well. Comprehensive vulnerability assessments are essential, not just for applications listed in a CVE database, but components of applications, such as DLLs. Not to worry, you can skip vulnerability scanning and outsource it to the bad guys – no up-front investment required.

Upon granting authenticated users and devices network access, access control policies should only allow access to resources on a “need to know” basis. Micro-segmentation is part of the Zero Trust Architecture (ZTA). Raise your hand if you can tell me how the compromise of the CEO’s computer allowed lateral movement to the source code repository? How did that allow access to the accounting department? Never grant any device, application, person, or meme access to resources that are not required. Network segmentation means that when user access controls fail, the IT department doesn’t need a new hire.

Data must have a zero-trust relationship with, well everything. Data is human, device, and network agnostic. Nothing should be granted implicit trust to data at rest, in motion, or at compute time. That smells a bit like digital rights management (DRM). Does the requester have a need to access the data, and is the data protected if authorized access is bypassed?  Just for a moment let’s say that despite an outstanding implementation of a ZTA, a human mistake was made. There was a catastrophic meltdown of authentication policy. Somebody accidentally left an Amazon S3 bucket with 50 million healthcare records unsecured. How bad is it? I said the bucket was unsecured, but I didn’t say the data wasn’t AES 256 encrypted with RSA 4096 encryption protecting the AES keys. Did I mention that the passwords inside of the encrypted blob were strongly encrypted as well? What if you were the one who failed to secure the bucket? Here’s what. Breathe a sigh of relief that the data itself is secure and then go change your underwear. That mistake should scare something out of you. Still, you did your job. You protected the data.

SASE is about protecting the crown jewels by building security from the inside out.

The theft of trade secrets costs US companies $300 Billion USD per year. Breaches of healthcare data cost companies $13 billion in 2020. The theft of the NSA’s CodeBlue and EternalRomance exploits lead to billions of dollars in losses to companies affected by WannaCry and NotPetya. Security for the data and critical resources come first. From there evaluate the remaining attack surface and secure that. Wash, rinse, repeat. In the unsecured S3 example, MFA, device compliance and monitoring, access control, micro-segmentation, coffee, and Red Bull failed to prevent data access, but the data is what had the most robust security.

The application of ZT to cloud services such as Office365 means that authentication must be performed for individual, or limited groups of services. The need for access to email is not the same as the need for OneDrive, Google Drive, or any of those discreet services or functions of services. This isn’t to say that groups of resources cannot be grouped into a trusted set; that depends on individual requirements and risk tolerance. It isn’t all or nothing. The architecture that builds security from the inside out is still foundational. Zero Trust is just one of the tools in the SASE toolbox that is used to accomplish this. In future blogs we’ll dig deeper into other components of a SASE deployment.

Before I conclude this blog, I want to emphasize the need for Zero Trust, and the SASE security from the inside out model by relating NotPetya’s impact on shipping giant Maersk. Maersk didn’t have a comprehensive ZT model, if one at all. As such Maersk my poster child for the saying “If I can’t be a good example at least let me be a good cautionary tale.”

As related by the Wired story “The Untold Story of NotPetya, The Most Devastating Cyberattack In History, Andy Greenberg’s investigation revealed that when NotPetya infiltrated shipping giant Maersk’s network it decimated much of the company’s infrastructure. When I say decimated, I mean there were approximately 150 domain controllers that were configured to sync with each other all succumbed to the ransomware. The DCs were also being used to serve as backups for each other. If one goes down another restores it. Elegant in its simplicity, not so much in its security. There was no redundancy in the backup scheme. Conceptually they were using hard drives to back up hard drives on the same computer. You could hear NotPetya giggling all the way to the International Space Station. There was insufficient network segmentation, access control, authentication, and Tums; things that Maersk’s security team had requested funding for. Now Maersk’s security team gets almost every resource they ask for. In case you are wondering how they managed to recover the DCs, it turns out that NotPetya’s Achilles heel is electricity. A lone DC in Ghana had been knocked offline by a blackout and had not since been reconnected to the network. Blackouts are not typically the way offline backup strategies are designed, but if it works, fix it this time.

For a deeper dive into ZTA I will refer you to NIST Special Publication 800-207. For a look at how ZT, ZTA, and more generally SASE can be tailored to your environment, give us a call and let’s have a discussion. Our phone number is the business card I authenticated with at the start!

Randy Abrams
Señor Security Analyst
SecureIQLab