Third party cloud platforms around the Hash Table.
Rick Howard: In the last episode, I made some pretty bold claims regarding the security tools that the big three cloud providers offer, namely that compared to the pure play security vendors, in other words, those vendors who only do security and nothing else, the cloud provider security tools are practically beta versions. In that regard, they definitely don't meet the standard best practice of only deploying best-in-breed tools. More importantly, I also made the claim that as we all move to the cloud with great speed, adopting the cloud provider's security tools adds more complexity to your already tangled security infrastructure.
Rick Howard: I made the case that your security landscape was already too complex to manage in any coherent manner before you went to the cloud. Adding more tools from the cloud provider now would just make things worse. I came to the conclusion that what we needed was a single orchestration tool that could perform all of the required tasks for our first principle strategies - intrusion kill chain prevention, resilience, zero trust and risk forecasting - wherever our data is stored and processed - cloud networks, data centers, SaaS applications and roaming endpoints from mobile users.
Rick Howard: The impact of that realization was that I needed to add security orchestration as one of the baseline first principle strategies, along with the first four. And the place where we would find these tools is with the big firewall vendors - Checkpoint, Fortinet, Cisco, Palo Alto Networks and maybe others. The reason this is a compelling argument is the transformation of the firewall from the early 1990s from being simply a blunt boundary device between our headquarters and the internet designed to stop obvious bad-guy activity into a security orchestration platform in the 2010s designed to operate in multiple digital environments with a consistent security policy.
Rick Howard: These newly transformed security orchestration platforms fit into the resilience architectures of cloud providers, provide kill chain prevention and detection services with subscription services and offer innate zero-trust capability from their next generation roots in the early 2000s. To me, the obvious way to implement our first principle security strategies is to deploy these security orchestration platforms everywhere. But alas, I could be wrong.
Unidentified Singer: (Singing) But I could be wrong...
Rick Howard: Clearly, I needed to talk to some smart people about it, and that's just what I did.
Rick Howard: My name is Rick Howard. You're listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. Today, I invited three guests to the CyberWire hash table to shed some light on this security orchestration idea. The first was an old friend of mine, Ram Boreda. He is currently a Palo Alto Networks field CTO. But he and I started working together years ago when he was a product manager for iDefense. The second guest is Joakim Lialias, a director of product marketing at Cisco. And this is his first appearance at the hash table. And last but not least is Ashish Rajan, host of another security podcast - a really good one - called a "Cloud Security" podcast. You should absolutely put that into your listening rotation. And by the way, he has the best podcast voice on the air right now.
Rick Howard: So let's begin with him. He has the same notion that I have regarding the big three cloud provider security tool sets, that all three were following the basic startup blueprint, where they roll out a no-frills service, convince customers to give it a try and then use the feedback to improve the product over time until it turns out to be something that everybody needs and wants. At least that's the plan.
Ashish Rajan: Security is going to be so easy because they have all these security products. And then you started using it. And you actually realize most of the products that are released by these cloud service providers are actually in beta, like, beta in the context of, hey, I think this is GA ready. You should go and do - use it, and give me all the data points so I can make it better for all the other million people out there who are going to use it.
Rick Howard: Cisco takes the view that even though the cloud providers have developed some security tools, most of the cloud provider's customers have data in lots of different places other than the cloud provider's networks.
Rick Howard: Here's Joakim Lialias, one of Cisco's product marketing directors.
Joakim Lialias: One of the things that we have seen is that, yes, over the last several years, cloud providers have developed numerous ways where they can provide their organic ways of providing security. We're hearing from more and more customers, cloud providers are bringing more capabilities to the fold, but it's not enough. When applications and data move to the cloud, it's not just one destination, it's multiple destinations. Policies set the tone for your security.
Joakim Lialias: Now, you want to be able to do that across your on-prem environment, might be private cloud. You might have multiple infrastructure as a service providers that help support your business. You even have, you know, your SaaS applications in the mix, right? Being able to uniformly set and deploy policies across these multiple environment is going to help you navigate this complex world because no matter how much we read day in and day out about everything is going to the cloud, there's still a lot that is not in the cloud.
Rick Howard: Palo Alto Networks comes at it from a slightly different angle. Their leadership has recognized the mistakes the security community has made over the past decades by incrementally improving the security infrastructure over time. They suggest that the cloud is a new opportunity to make everything better. We don't have to continue doing things the way we used to, take what we have done back on prem and duplicate it in the cloud. In fact, the idea of we have always done it this way goes against a quote from one of my all-time favorite computer science heroes, Admiral Grace Hopper. She said that the most damaging phrase in the language is we've always done it that way. Here's Ram Boreda, the field CTO for Palo Alto Networks.
Ram Boreda: In the on-premise world, we definitely have proliferation of security tools. But in the cloud, let's not make that same mistake again. Every cloud service provider is probably launching a thousand to 1,500 new services or, you know, feature releases a year. How can a customer with limited staff and limited expertise in the cloud, how can they keep track of all these new services being launched, their attack surface, the (unintelligible) that's impacting each of these. Let's try to consolidate what a security practitioner or a CISO team needs to do by giving them a single place where they can manage all things security-related so that, ultimately, customers don't have to contend with 20 different tools, 10 different consoles. They can do all of it in one place.
Rick Howard: One of my biggest complaints about all three cloud providers' security solutions is that they have nothing to say for intrusion kill chain prevention. Amazon, in a previous discussion at this very hash table, even went so far as to say that it's not needed in the cloud because of the dynamic nature of the environment and the advancements in machine-learning techniques. They made some good arguments and told me later that they are working on a white paper that will flesh out those ideas with even more detail. So stay tuned for that. But I remain skeptical, and I find that I'm not alone in that unconvinced idea. Here's Ashish again, the host of the "Cloud Security" podcast.
Ashish Rajan: I do want to say cloud is secure, but it's only secure if you do it right. It's harder to do DDoS on them. But intrusion kill chains have not gone away as a concept. If you just do AWS reference architecture, they have a lot of reference architecture for getting people started quickly in cloud. What I find hilarious is that a lot of those reference architecture put resources in public. Now, imagine you're an enterprise who's trying to move in the cloud. You tell one of your staff members, hey, we need to move into cloud because that seems to be a thing. Maybe you should go to Amazon 'cause they said there's no intrusion kill chain possible. Oh - and why don't you check out some of those reference architectures? So they go in, and they pick one of these reference architectures. It just happens to be one of those ones where the server is hosted on the internet with Port 22 open to the world. And guess what? You just basically put a critical resource on the internet because Amazon said kill chain is not possible.
Rick Howard: Cisco and Palo Alto networks both think that their cloud virtual products easily provide intrusion kill chain prevention because they've been doing that for years with the hardware versions back on prem using intelligence from the Mitre ATT&CK framework. Here's Ram and Joakim again.
Ram Boreda: For the cloud workloads, we offer some help along the intrusion kill chain. The way we are doing that is by providing controls that cover 90% of attacks defined in the Mitre ATT&CK frameworks. Definitely are - addresses, like, the prevention part of the kill chain, where you are limiting the adversary's ability to poke and assess your network because you are building them in a more secure and more, you know, rigid manner.
Joakim Lialias: Across all of our products, we have extensive mapping to the Mitre framework - across Endpoint, across cloud analytics, across our malware analytics to our network, we have that built-in intrusion prevention as part of our next-generation firewall technology, anti-malware as part of our next-generation firewall. We do have that built in. And of course, you can block and you can, of course, respond to these attacks before they can exfiltrate the data.
Rick Howard: Both Cisco and Palo Alto networks already have embedded zero-trust capabilities for both hardware and virtual firewalls that they started working on as far back as the late 2000s, where administrators can make access rules based on applications tied to the authenticated user. But now they extend those ideas to cloud workloads. Cisco's product name is Cisco Secure Workload, formerly Tetration. And Palo Alto Networks' is called Aporeto. Here's Ram and Joakim again.
Ram Boreda: What Aporeto does is it assumes that applications that you're running, the microservices, the container applications or the Lambda functions in AWS or Google functions in GCP - they may have IP addresses, which may live for only 10 seconds or which may live for only a couple of minutes. And then you could take the same container apart and deploy it in all of the different clouds or on Plymouth, which means you cannot define these - who can access what based on IP addresses. You have to do the authentication and authorization using some other data and reuse identity data. We do the authentication and authorization based on the identity metadata like DPC ID in the case of AWS or Kubernetes namespace, application tags. All of these are long-lived, and they are static in the sense that even if you deploy the same application in three different cloud environments, any application level tag that you define stays. That container gets spun up and spun down 10,000 times. The tag always remains the same. And we use that tag to, you know, determine who can access what. It is actually like a demon that gets embedded in every application that it is protecting.
Joakim Lialias: One of the things that we have is Cisco workload protection, also known as Tetration, which kind of goes in the concept of microsegmentation. You get information around network slow and process information. You're able to specify segments within your workload environment, if you want to call it that, or application environment where you can specify what type of workloads happens in certain kind of sections, specifying who gets control based on their role within the organization, what geography he or she may be from.
Rick Howard: But according to Ashish, most security professionals recognize zero trust as a thing that might bring some goodness to the world. But he questions how many of us are actually doing something about it in the cloud or back on prem, especially since zero trust as a concept is definitely thrown around in every security vendor's marketing department.
Ashish Rajan: I believe practitioners understand zero trust. They want to do it. But it's like talking about AI and machine learning. I think it's one of those ones where it sounds like a great idea. But how many people have actually successfully done it? It's definitely a great model that cloud enables us to do quite quickly. We're quite new in this conversation when it comes to cloud or even on premise for that matter, right? You and I understand it. We hear it. Yeah, that makes sense. Why would I not do that? I love the principle, but there's a lot of buzzword thrown around that as well. Like, I feel it's two things for me. One is continuous authentication and authorization, and the other one is building trust. Like, those two define zero trust for me. I think someone mentioned this, and I love what they said - trust is the new gold. And I totally believe this because now, in a pandemic world where companies have employees working remotely and we don't know if it's really Rick logging in from his home or his - I don't know, your dog logging in from your home.
(SOUNDBITE OF DOG BARKING)
Rick Howard: But not everything is bad. Both Ashish and I agree that Google's BeyondCorp, the GCP zero-trust implementation of software-defined perimeter, or SDP, is really good.
Ashish Rajan: It's not just the fact that it should be raked from IP number 10.12.T.4 - really bad IP, but, you know, we kind of no longer believe in that kind of model where the cloud is dynamically scaling. So is the flexibility required from the network as well. You just can't rely on an IP-based model where everything that we used to do in security products, which was based on IP, now it's based on identity. Now it's based on Rick's device and whether Rick has the authority for doing an action. And then even if he does have the authority, is he coming from the right source?
Rick Howard: That said, Ashish warns that if you are trying to do anything that doesn't fit exactly into the cloud provider's framework, they have an automatic out that I like to call the shared responsibility model gotcha.
Ashish Rajan: We seem to understand the basics of it. But because we use these suppliers like AWS, Azure and Google Cloud, security by default hasn't been a thing for them. Anyone who may be considering zero trust, yep, there are foundational pieces for that in the cloud provider. But they assume that you know what you're doing when you're setting it up.
Ashish Rajan: The responsibility is still on us. That's why the cloud service providers love the whole shared responsibility model. Every time you say anything - oh, you know the shared responsibility model? That's your responsibility. I love the fact when cloud service providers give you architecture. And when it's not something that suits you, they will try and make you write custom code. And then you go, well, if you already have a service that I'm paying for and you're trying to make me go "cloud native," quote-unquote, which basically means any product that you have, I should be able to use it and it should be integrated across the entire cloud service provider. But you want me to write custom code on top of it so that I can start using this for my business. Great. So it's custom code which you won't maintain. I have to maintain because, hey, shared responsibility. So thanks for that. So I don't know, man, I definitely don't think I can trust them enough for this yet.
Rick Howard: The one thing that everybody agreed on during the hash table discussion was that the biggest advantage of cloud deployments is how resilient they are. That is the reason that all orchestration platforms so easily plug into the virtual infrastructure. By doing that, they don't have to build the resilience into their own products. They just take advantage of the cloud provider's functionality and then layer on all of the other orchestration platform capabilities, like intrusion kill chain detection and zero trust.
Ram Boreda: It actually doesn't even cost that much money for them because they're already running a global footprint. I mean, it's maybe more expensive than running a one data center. But for us to get a highly available resource, it's not that much more expensive compared to if you're trying to do it on premise or on your own. It's way more expensive to get highly available infrastructure going then leveraging these cloud service providers.
Ashish Rajan: Talking about resiliency, 100% we are much better in cloud because now when I need an extra server, I'm not waiting for six months. I don't have to plan ahead. I don't order extra servers so that I can plan for a unexpected performance workload that I would not have seen maybe during Black Friday or whatever. I don't know if you remember waterfall methodology, where we used to define functional requirements and define non-functional requirements. What am I going to get at the end of the one-year period? Oh, you would get X, Y and Z. Would I ever need it at that point? Don't know, but we should work on it.
Ashish Rajan: So you spend a whole year planning for buying a hardware, planning for this future that would be bright and your product would be amazing. Now in the world of Facebook and Zoom and all that where people are basically moving out, releasing products in a matter of months, imagine waiting for hardware for six months. I believe still people are doing, I guess. Now I just dynamically scale a machine based on my demand.
Rick Howard: I guess it's no surprise that the people behind the security orchestration platforms, formerly called next-generation firewalls, from the likes of Palo Alto Networks and Cisco think that they offer a better security solution than the cloud providers do. OK, I get that. Oh, and by the way, I did invite the other two big platforms to join the discussion - Ordina and Check Point - but they couldn't arrange for anybody to come to the hash table in time to meet the deadline. So maybe next time.
Rick Howard: But from a neutral corner, the host of the "Cloud Security" podcast Ashish Rajan, who doesn't have a dog in the security vendor competition fight, also agrees with me that the cloud providers' security solutions are practically beta versions of what the big orchestration platforms have been offering for years, that the orchestration platforms have also been doing intrusion prevention for over a decade and that cloud providers don't even acknowledge that the kill chain prevention idea is the thing, that zero trust can be done with cloud provider services, but they only work in those environments. If you want a comprehensive solution across all of your data islands, then you're going to need more tools that will add complexity to your overall plan.
Rick Howard: And finally, resilience is the thing that cloud providers do best. To take advantage of that remarkable capability and also get the other services that we need for our cybersecurity first principle plan, what we need is a third-party orchestration tool that can easily plug into those cloud environments.
Rick Howard: And that's a wrap, not only for this episode, but for the entire season. For those of you not paying attention, we dedicated everything for Season 4 to all things cloud security, and I had a blast. I hope you did, too. And maybe you learned a thing or two in the process. As always, if you agreed or disagreed with anything that we talked about this season - or any season, for that matter - hit me up on LinkedIn, and we can continue the conversation there.
Rick Howard: The CyberWire's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, and the mix of the episode and the remix of the theme song was done by the insanely talented Elliott Peltzman. And I'm Rick Howard. Thanks for listening.
