Third-party platforms and cloud security.
In this season, I’ve examined each of the big three cloud provider security solutions: Microsoft Azure, Amazon AWS, and Google GCP. After going through that exercise, security orchestration is the idea that emerges for me that is screaming for attention. So much so that I feel compelled to add it to the other four baseline first principle strategies that I have been discussing in essays and podcasts this past year: resilience, zero trust, intrusion kill chain prevention, and risk forecasting. As a security executive, if you can’t orchestrate these four strategies across all of the digital islands where your data resides, cloud networks included, you have no chance to reduce the probability of material impact to your organization due to a cyberattack. In fact, adding security tools from the cloud providers might indeed increase your chances because of the added complexity to your environments.
If that’s the case, the cloud security tools won’t help in this regard even if they’re the best security tools on the planet. Instead, they will add complexity to your system because you have another tool set that you and your team have to master in addition to the tools you’re already running back in the data center and at headquarters. If you’re looking to orchestrate your first principle strategies across everything, then the only viable alternative is to use a third-party toolset that covers all data islands. What I'm talking about here is inserting one of the big security platforms from companies like Fortinet, Cisco, Check Point, and Palo Alto Networks. These companies are known as firewall companies, but over the last decade, they have turned themselves into security orchestration platforms.
Cloud providers do some things well – others, not so much.
All three cloud providers are very good at some first principle things and completely lacking in others. For example, they all are superb at providing a palette of ways to deploy resilient workloads that are probably better than the set of tools you have at your disposal back on-prem and in the data center. Likewise, they all do well offering tools to build zero trust elements into your security posture, again potentially exceeding what is available to you back at headquarters.
If I were just starting my cloud journey today, I would lean toward the GCP implementation of zero trust. BeyondCorp, Google’s marketing name for it, is an implementation of something called a software-defined perimeter or SDP (a concept that emerged from the US military, circa 2007, called “black core”), and it’s lightyears ahead of what Microsoft and Amazon offer. At this point though, there aren’t too many organizations that are just beginning their cloud journey. I'm willing to bet that most of us are committed to one cloud provider or the other by now, the CyberWire included. We use AWS and an entire slate of third-party SaaS services.
On the downside, none of the three cloud providers offered even rudimentary capability for intrusion kill chain prevention nor did they help their customers with any kind of risk forecast. Most provide the means to collect mountains of telemetry from their products, but that’s about it. They leave it to their customer’s own ingenuity to follow these two strategies.
Further, none of the three recognized that most organizations don’t keep their data in one cloud environment. If they have any size at all, they’re quite likely to run different workloads and store different data sets in multiple cloud environments as well as continue to operate within their own data centers and headquarters back on-prem.
And since we’re piling on here, most cloud security services don't include any kind of protection, first principles or otherwise, for all the remote employees working from home during the pandemic or eventually traveling around the world when things get back to normal. The exception is Google’s BeyondCorp since it's doing some preliminary checking of the client before the client is allowed to connect to the cloud workload. Lastly, there is nothing in the way for securing Operational Technology (OT) and Internet of Things (IoT) environments either.
I hear what you’re thinking. Why would they? They provide cloud services, not OT/IoT services. But I want to make a point here.
Cloud security tools add more complexity
The cloud provider security solution sets mostly only work in the cloud provider’s environments. They aren't a set of tools security executives can use to protect all of the data islands they’re responsible for. They’re an additional set designed to secure cloud environments, and they're relatively new compared to the on-prem tools most of us are used to. That means that they aren't mature. They might be in the future, but they aren't right now. I know you're reading this and saying to yourself, “Duh Rick! Isn't that completely obvious?” Well, of course it is. Here’s the thing.
Before we all started to race toward cloud deployments this past decade, we already had too many security tools to manage. In the late 1990s through the 2000s, we had these two overriding best practices that we all followed: only install best-of-breed security tools and never ever use a single vendor for all of your security stack (We called that vendor-in-depth.) That all sounded great back in the 1990s when we only had three security tools to worry about (i.e., firewalls, intrusion detection systems, antivirus.) But in today’s environments, it's not uncommon to see as many as 15 security tools in small to medium-sized organizations and over 300 security tools in some large organizations. That’s a lot of tools. And that says nothing about all of the policies and procedures an organization will need to administer those tools in some coherent manner.
The other 1990s best practice that we all followed was to find ways to reduce complexity. You may have the very best security tools deployed, but the more you have, the more convoluted your environment is. At some point, it becomes so complicated to manage that you can’t keep the tools updated with the latest threat information; the volume of alerts the security stack produces overwhelms your SOC; and you don’t have time to deploy all of the bells and whistles that you wanted when you bought the best-of-breed tool in the first place. By 2010, many of us had crossed that threshold where the complexity risk to the organization was greater than the risk if we didn't have the exact best-of-breed tools.
And then we started deploying cloud services.
This gave us even more tools to manage in our already tangled networks. The cloud providers don’t alleviate that complexity. They add to it. To be fair, all of them say that we can reduce it by automating everything in a devsecops kind of way. That's probably true in the long run, but most of us are a long way from that nirvana vision. And even if we were close, that would still only reduce the complexity of your cloud provider’s network. It says nothing about our other data islands.
Orchestration emerges as a thing
It's tough to pin down exactly when, but sometime around 2015, IT and security practitioners started complaining about how the vendors took no responsibility for the burden of orchestrating their tools with other vendor products. Customers started seeing vendors trying to integrate their tool set with good matches, maybe not from their direct competitors but from competitor adjacent vendors. For example, when I was at Palo Alto Networks, the malware analysis product manager partnered with his Proofpoint peer so that if a mutual customer existed, the intelligence between the two products was automatically shared between the two companies without the customer having to do anything.
In that same vein, the security vendor community established its first ISAC (Information Sharing and Analysis Center) in 2017 called the Cyber Threat Alliance. Paying members volunteered to share threat intelligence with each other automatically so that their mutual customers didn't have to manually put it all together themselves later. Since all of the vendors have means to automatically update their products with the latest prevention and detection controls based on new intelligence, the Cyber Threat Alliance provides the mechanism to deliver protections for any newly discovered threats around the world in minutes to hours. Today, there are over 30 security vendors in the Cyber Threat Alliance, all automatically sharing threat intelligence every day.
As an aside, if one of your security vendors isn’t a member, you should ask them why they’re hesitant. Perhaps you should even tell them that you will seek another vendor if they don’t. By insisting that vendors cooperate in this manner, it makes the entire ecosystem safer and has the added benefit of costing you nothing.
But even these kinds of intelligence sharing programs are only drops in the bucket. They don’t provide a comprehensive orchestration capability across all of your data islands. In 2018, SOAR tools emerged to help SOC analysts sift through the volumes of alerts coming in from all of the IT and security tools, from all of the data islands. SOAR stands for “security orchestration, automation, and response” and provides a means for SOC analysts to automatically remediate low-level alerts that come into all SOCs so that analysts can spend their time on more important matters. In my last CSO gig, we were processing some billion alerts every quarter. With the SOAR tool, we reduced that volume to about 500 that humans actually had to look at. So, that is better, but still not a comprehensive solution.
The one tool that even comes close to providing what we need is the security platform.
Evolution of the firewall into a security and orchestration platform
I have said this in past essays, but the first stateful inspection firewalls in the 1990s were nothing but fancy routers. They allowed us to block network traffic based on IP addresses, ports, and protocols. In other words, they were big digital sledgehammers that we were all trying to use for cyber surgery. When next-generation firewalls emerged in 2007, they allowed us to move up the IP stack to create rules based on applications tied to the authenticated user. This gave security practitioners a way to logically segment their networks at the firewall and became a way to implement some zero trust architecture within existing infrastructure.
You could make rules that allowed the development team to access the software code repository, but the marketing team couldn’t. Zero trust rules like that helped reduce the attack surface and lowered the probability of lateral movement. It had the added benefit that it didn't need any additional hardware. All firewalls had next-generation capabilities at this point. All you had to do was deploy some rules on a device you already owned and operated. This still isn’t surgical, but at least we were using kitchen knives now and not sledgehammers.
But the firewalls were all still big iron boxes that we deployed in our data centers and back at headquarters. The big security executive problem was that they weren't cheap. It was tough to justify the spend for additional firewalls to create protection zones within the same data center. People did it, but it hurt, and that meant other security projects didn't get funded.
Eventually, the firewall vendors started adding SaaS services that their hardware boxes could plug into. Customers would pay for the big iron and then subscribe to services delivered from the cloud like malware detection, intrusion prevention, and anti–command and control. In other words, security vendors started adding the ability to install preventions across the intrusion kill chain.
As a result, all of the firewall vendors became giant adversary intelligence collectors. The firewall, as a boundary enforcer, basically sees all of the customer’s network traffic, and it's specifically looking for malicious behavior or anything that might look malicious: files (potential malware), command and control traffic, lateral movement, phishing – you name it.
For this specific data collection effort (cyber adversary’s tactics, techniques, and behaviors,) each individual firewall vendor’s data lake rivals the NSA’s in terms of volume. Since all of them can automatically update their product sets with the latest preventions based on newly discovered intelligence, their ability to protect their customers is light years ahead of what the Department of Homeland Security can accomplish with their written and manually crafted security alerts.
And by the way, since you're talking to your vendors about joining the Cyber Threat Alliance anyway, if you get the opportunity, you should try to convince DHS to do so too. The best way to get protections deployed to the world for newly discovered threats is to give that intelligence to the security vendors. This shouldn’t be a manual process that takes weeks-to-months-to-never to get new protections in place. It should be automatic. If DHS sends their intelligence to the Cyber Threat Alliance in a devsecops kind of way, then it's just a matter of minutes to hours before the CTA’s members deliver new prevention controls to their customers.
But I digress.
Since the cloud providers don’t really pay attention to intrusion kill chain prevention, their tools don’t even compete here. Given that most firewall vendors are paying members to the Cyber Threat Alliance, that combined intelligence is probably the most comprehensive open source collection in the world. All you have to do to access it is buy a product from one of the members, which you’ve probably already done. You're likely to have more than one.
The firewall vendor’s goal then became to eventually replace all of the individual best-of-breed point products that the security community had been deploying in droves for the past 20 years – those 15 to 300 tools I was talking about before. But they experienced some heavy resistance because of the aforementioned vendor-in-depth best practice. Sales people had trouble convincing customers to replace all of their best-of-breed tools with a single vendor. But that was about to change.
The transition from firewall to security orchestration platform
As soon as a security practitioner deploys more than one firewall, it becomes useful to have a management platform where administrators can configure baseline rules and configuration options in one place, push a button, and then have all of that information passed to the firewalls in the management constellation. You can do it manually, but it's error-prone and soul-crushing work. The more firewalls you have, the more errors your operators are likely to inject too. All the major firewall vendors offer this kind of functionality either in a hardware device designed to live on-prem or in a SaaS application living on the internet somewhere.
Before vendors offered virtual firewalls designed for cloud environments, this option was a time-saving device that might fall just short of being essential. But after they had virtual firewalls that could deploy inside of AWS, Azure, and GCP, this management plane elevated the firewall to a security orchestration platform.
In other words, you could still deploy big iron boxes in your data centers and your remote office spaces around the world. But now you could also deploy the same firewall, this time a virtual firewall, in your cloud environments, and you controlled all of them from the centralized management platform. The genius of the virtual firewalls is that as you spin up additional workloads to meet demand or accommodate some new cloud infrastructure change, the systems would automatically reach back to the management platform to get the latest rule sets and configurations as it boots. The hardware boxes do that too, but in the dynamic environments that cloud platforms provide, this is a game changer.
Security orchestration platforms and first principle strategy
Today’s firewalls (i.e., security orchestration platforms) can do so many things. Because of that versatility, I am making the argument here that they are potentially the most complete toolset available to security executives who are pursuing first principle strategies, not just in cloud environments but everywhere the organization stores and processes data.
- Zero trust: Their next-generation design from over a decade ago facilitates the deployment of logical segmentation of virtual workloads and big iron servers based on identified and authenticated users, devices, and applications.
- Resiliency: They easily plug into the big three cloud provider’s resiliency architecture to protect east-west traffic (between availability zones) and north-south traffic (from availability zones to the internet.) They have already performed that function for on-prem systems since the internet was young.
- Intrusion kill chain prevention: With their subscription model, practitioners can easy install prevention mechanisms for every phase of the attack sequence. If they don’t have the resources to do that themselves, they can rely on the vendor to do it for them, knowing that their intelligence collection is excellent and their ability to automatically craft fresh prevention controls from newly discovered intelligence is really good.
- Risk forecasting: This is their shortfall. That said, they are all able to produce copious amounts of telemetry, similar to the cloud providers, to feed your own risk forecasting models. This isn’t a selling point, but it's also no worse than it has been for years both in cloud environments and on-prem.
- Orchestration: Their management platform allows practitioners to have a single overriding first principle policy dynamically and automatically applied to all of their data islands in real time: endpoints (at home, on the road, or back at headquarters,) cloud environments, data centers, and OT/IoT networks. Security executives can orchestrate a consistent first principle security policy across all of their data islands while reducing the environment's complexity in the process.
Orchestration is a key baseline first principle strategy
When I first started this series on first principle thinking, I knew that orchestration was going to be important. I just didn't have it on the same level as the first four strategies. After going through that thought process and covering new security architectures like SASE (Secure Access Service Edge) though, and discussing security team skill sets like:
- Cyber intelligence
- Security operations centers (SOCs)
- Incident response
- Red team / Blue team operations
and technologies like:
- Data loss protection and prevention (DLP)
- Identity management
- Software-defined wide area networks (SD-WAN)
- Security orchestration, automation, and response (SOAR)
- Software-defined perimeters (SDP)
- Cloud environments
and worrying about how to manage all of it from all of our data islands:
- Data centers
- SaaS applications
- Cloud environments (AWS, GCP, Azure)
- Operational technology (OT) and internet of things (IoT)
it's clear to me that we can’t collect all of that into one bag with any efficiency or consistency, unless we give orchestration the same level of attention that we’re giving the other four strategies:
- Zero trust
- Intrusion kill chain prevention
- Risk forecasting
Orchestration may be the most important of all.
If that is the case, then the tool that we need is the security orchestration platform from the likes of Fortinet, Cisco, Check Point, and Palo Alto Networks.
S1E6: 11 MAY: Cybersecurity First Principles
S1E7: 18 MAY: Cybersecurity first principles: zero trust
S1E8: 26 MAY: Cybersecurity first principles: intrusion kill chains.
S1E9: 01 JUN: Cybersecurity first principles - resilience
S1E11: 15 JUN: Cybersecurity first principles - risk
S4E3: 25 JAN: Microsoft Azure via first principles
S4E5: 08 FEB: AWS via First Principles
S4E6: 15 FEB: AWS security via first principles Hashtable Interviews
“Cyber Threat Alliance Turns 4! - Cyber Threat Alliance,” by Michael Daniel, Cyber Threat Alliance, 25 January 2021.
“Day 13 - How to Set up BeyondCorp Zero Trust Security Model Google Cloud #13DaysOfGCP,” by Priyanka Vergadia, YouTube Video, 3 May 2020.
“Getting Started with BeyondCorp: A Deeper Look into IAP,” Google Cloud Platform, YouTube Video, 15 September 15, 2020.
"No More Chewy Centers: Introducing The Zero Trust Model Of Information Security,” by John Kindervag, Forrester, 14 September 2010, last visited 30 April 2020,
“Software-Defined Perimeters: An Architectural View of SDP - IEEE Software Defined Networks,” by Daniel Conde, IEEE Softwarization, March 2017.
“Software Defined Perimeter.” by the Cloud Security Alliance, December 2013.
“Software Defined Network (SDN) or Software Defined Perimeter (SDP) … What’s the Difference? | Waverley Labs,” by Juanita Koilpillai, Waverleylabs.com, May 25, 2016.