Pro: CSO Perspectives 1.25.21
Ep 35 | 1.25.21

Microsoft Azure through a first principle lens.

Transcript

Rick Howard: As you all know, the cloud revolution is here. Amazon started it when it rolled out AWS in 2006. Microsoft followed suit with a competing service in 2010 with Azure. And Google started to compete in the space with Google Cloud Platform, or GCP, in 2012. There are other players in the market - Oracle and IBM come to mind - but the big three that most security executives talk about are Amazon, Microsoft and Google.

Rick Howard: The question that I have is, how well can we implement our first principle strategies within each environment? And if we can't, do we need to embrace the security platforms like Fortinet, Palo Alto Networks, Check Point and Cisco within each cloud environment to get it done? 

Rick Howard: My name is Rick Howard. You are listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. Today, we are looking at Microsoft Azure. 

Rick Howard: The network defender community started to get serious about how to secure these cloud environments around the same time that the Cloud Security Alliance came online in 2009. Since then, we've been trying to get our heads around the various cloud architecture ideas, like software-as-a-service, or SaaS, platform-as-a-service, or PaaS, and infrastructure-as-a-service, or IaaS. We have also been struggling with how to get in sync with our IT brothers and sisters around the ideas of DevOps and DevSecOps within those cloud environments. Not only are we trying to understand new coding techniques like containers and serverless computing but also how to secure them in a cloud environment. 

Rick Howard: At the same time, the cybersecurity intelligence community has been bracing for some advanced adversary group to run a campaign directed purely at cloud resources. And as an aside, that really hasn't happened yet. Apart from leveraging some low-hanging fruit, like S3 buckets left open to the internet, the bad guys haven't run a purely cloud-centric campaign. Looking through the MITRE ATT&CK framework Cloud Matrix, you see some cloud data theft and denial-of-service actions. But in general, the way adversary groups break into cloud environments is by stealing credentials from on-prem locations and then using them to log in legitimately to cloud resources. The most recent example is the SolarStorm campaign run by the adversary group UNC2452. 

Rick Howard: What I have noticed is that our entire community has been running heads-down now for years, thinking tactically about the technical widgets required to get these new environments running and then flipping switches and turning dials on those widgets to provide some modicum of security. 

Rick Howard: I figured it was time to take a beat and consider the strategic picture. How do you think about cloud deployments through a first principle lens? How do you implement the four keystone strategies in each environment? And how do you orchestrate those strategies not only in hybrid cloud environments but also in SaaS applications, mobile devices and data centers back at headquarters as a single system of systems? 

Rick Howard: Before we get to Microsoft, let's talk about some cloud basics that apply to all cloud service providers. The first thing to note is that they offer some kind of networking infrastructure designed for their customers' automation workloads. These come in the form of infrastructure or platform subscriptions. The idea is that managing hardware networking and server infrastructure shouldn't have to lie at the core to your business. CIOs benefit from offloading the management burden to a third party so they can concentrate on developing software that will make their business competitive. 

Rick Howard: The second thing to note is that all cloud providers offer software-as-a-service, or SaaS products, to help you manage your workloads in their environments. Sometimes, they provide them as part of the infrastructure service. And sometimes, you have to pay extra for them. 

Rick Howard: I bring this up because it might be useful to consider IaaS, PaaS and SaaS subscriptions as individual products that are managed by different product management teams within a larger company. Depending on how old they are, you could consider some of them to be startup products. In other words, some are more mature than others. 

Rick Howard: For example, AWS has been around for over a decade. That's a mature service. Dell's cloud offering launched in 2019. It's probably not as mature. Google launched Cloud Identity as a SaaS product in 2018. Microsoft launched as Azure Active Directory in 2019. These products may be fantastic, but they're only 3 years old. How mature can they be? Just because they have a big brand name over them doesn't mean that they're ready for prime time. 

Rick Howard: That's especially true for security products. Amazon released their AWS Network Firewall in 2020. You can't expect that product to have the same feature set and maturity that the traditional firewall vendors, like Check Point, Cisco, Palo Alto Networks and Fortinet, have in theirs. The cloud providers have been bolting on IT and security services without any real thought about how they might work together in some form of strategic plan. And all of those services are in various states of maturity. 

Rick Howard: What's interesting is that CIOs and CSOs tend to use the cloud service provider's SaaS services. Mind you, these are the same leaders who probably wouldn't deploy a prevention platform for the bulk of their security services on prem because they don't want to have a single vendor handling everything, and they want to ensure that they have deployed the best of breed security tools. But when they move to the cloud, somehow, those two best practices don't apply anymore. Anyway, with those basics explained, let's look at Microsoft Azure. 

Rick Howard: In its simplest form, clients rent virtual network spaces through subscriptions that are bound to geographical regions. The smallest number of IP addresses you can have for any specific virtual network is three. The largest is almost 17 million. 

Rick Howard: By default, all IP addresses in a virtual network are private, meaning that the internet can't touch them, and any virtual host using that IP address can't get to the internet. You can make them public by using the Source Network Address Translation protocol - SNAT for short; I love that name - and placing them behind the Azure load balancer SaaS product. 

Rick Howard: You can also create multiple subnets within your virtual network. This will be important later when we establish network security groups, or NSGs, for each subnet to enhance our zero trust posture. Think of NSGs like mini stateful inspection firewalls that allow blocking rules between subnets based on IP addresses, ports and tags. 

Rick Howard: To connect two different virtual networks, Microsoft provides an ExpressRoute circuit capability that isn't transitive. That means that if a hub virtual network has an ExpressRoute circuit to two different spoke virtual networks, like Spoke 1 and Spoke 2, the two spoke networks can't talk to each other. They can both talk to the hub virtual network, but they can't pass traffic directly to each other. This hub model is important to understand because if you were going to insert a security stack between the two spoke virtual networks in the Azure model, this is how you would do it. 

Rick Howard: You can also connect the virtual network back to your on-prem networks using a similar ExpressRoute circuit idea. And if you want to get really fancy, you can use the ExpressRoute circuit to connect to your SASE vendor. We talked about why SASE is the future in the very first episode of this podcast. The SASE vendor establishes something called a Meet Me location in their data centers that has multiple peering connections to the Microsoft Regional Network Gateway supporting your virtual networks. 

Rick Howard: One quick note about the Azure Active Directory SaaS product - Azure Active Directory isn't Active Directory. I know. That's confusing. Let me try to explain. Azure Active Directory is an unfortunate marketing name for a product that provides federated identity management services using Active Directory as the authoritative source. We talked about federation in our Identity episodes back in Season 2 - Episode 7 and 8 if you want to get caught up. But what makes this naming convention even more confusing is that you can install an Active Directory service on a virtual host running in the Azure virtual network that, in order to provide federated services, will have to talk to the Azure Active Directory SaaS product. If that doesn't sound like the snake eating its own tail, I don't know what does. 

Rick Howard: Names of things - don't get me started. They are so important, maybe not in the heat of the initial assignment moment perhaps. But later, when things get complicated, having well-thought-out names for things can avoid heaps of confusion down the road - case in point, the way the industry uses the same names to discuss adversary groups, adversary campaigns and malware. Talk about confusion. 

Rick Howard: To accompany this episode, I wrote a longer essay with a bit more detail on the Microsoft Azure cloud offering and the SaaS services that support it. You can find it at the CyberWire Pro website. In it, I provide a list of Microsoft Azure security tools that customers could deploy in their cloud environments - things like CASBY, data classification, DDOS protection, federated identity management services, SIEM and data analytics, web application firewalls and XDR. Presumably, we would use these products to deploy our first principle strategies. 

Rick Howard: So let's start with Resilience. This is where Microsoft and pretty much all cloud providers shine. The gap between the relative simplicity of creating system backups and high availability situations in cloud environments compared to the headache-inducing complexity of doing the same in your own data centers is wide. 

Rick Howard: But for Microsoft Azure, there are a few concepts to understand. Remember; a virtual network sits in a region. A region is a collection of data centers - Microsoft calls them availability zones, or AZs - that can only have two milliseconds of latency between them. If Data Center 1 has more than two milliseconds of latency to Data Center 2, they are not in the same region. 

Rick Howard: To protect your workloads from a single data center failure, spread them across multiple availability zones using the Microsoft load balancer SaaS product between them. Each availability zone contains racks and racks and racks of physical servers. Azure Availability sets, or ASes for short - Microsoft also calls them fault domains - distributes workloads across three server racks at a time and protects customers from a rack level failure. 

Rick Howard: For backups and disaster recovery, there are many options to consider, but probably the simplest model to understand is to distribute the workloads across multiple regions. In this model, there is no concept of a hot and cold site or even a hot and a warm site. Both sides are hot, meaning that each is allowing read/write transactions, and the underlying data bases in both regions are keeping themselves in sync. This is way easier to say than it is to do, and there are cost considerations to examine. But with a Microsoft Azure deployment, resilience through code is possible. 

Rick Howard: You can see why DevOps teams love cloud deployments. They can build robust, high-availability solutions, disaster recovery operations and backup procedures, and their infrastructure is all code. 

Rick Howard: In terms of zero trust, Microsoft doesn't have a product per se, but they do have a substantial collection of written advice around the topic that incorporates their product set. How can I say this politely? It's a lot. The potential combinations of services is exponential. They have tools to monitor and manage identity, devices, SaaS applications, data and networks. In 2017, they rolled out a SaaS application called Microsoft Secure Score. That is a security dashboard that tracks things like virtual inventories, security alerts, compliance and other things and attempts to prioritize the security to-do list. 

Rick Howard: Microsoft recommends you start with complete visibility by registering all of your users, endpoints and applications with Azure Active Directory. I admit, that's a really good first step. 

Rick Howard: Then you use Microsoft Secure Score to help prioritize the workload and lock everything down. It will still be a bit of a black box to get a precise sense of your zero trust posture by reviewing this telemetry yourself, but it's a start. I don't recommend throwing this task into the SOC is an additional duty for the already overwhelmed SOC analyst either. In order to get this done, you would need a small team to only focus on this zero trust task and who could also automate the steps as they go. By the way, I think that is the correct path anyway. If zero trust is a foundational stone in our first principle wall, then we might want to have some dedicated resources implementing it, not just people but people who can code. 

Rick Howard: The one capability that Microsoft offers that has a one-to-one connection to zero trust is its network security groups, or NSGs. In every virtual network that you deploy, you can also establish one or more subnets and use NSGs to prevent the subnets from talking to each other. So in one simple model, you can have subnets for marketing, finance and the development team, just to name three. You would then deploy rules on each NSG to prevent communication outside of those subnets. In that way, you could reduce the attack surface for each of those business groups and limit the potential damage from lateral movement if attackers somehow compromised any one of them. 

Rick Howard: One note about the SolarStorm supply chain attack campaign that became public in December 2020 and the zero trust strategy - the consensus from the security community is that a strong zero trust deployment might have prevented the success of the campaign. According to Microsoft's director of identity security, Alex Weinert, quote, "even in the worst case of SAML token forgery, excessive user permissions and missing device and network policy restrictions allowed the attacks to progress," end quote. 

Rick Howard: From my understanding of how the Microsoft Azure Active Directory SaaS product works, SolarStorm victims could have configured their virtual networks to prevent the Golden SAML attack, and that's a good thing. 

Rick Howard: Microsoft is silent on how to install prevention and detection controls for all known cyber adversaries with Azure. Other than the Microsoft Threat Prevention Team periodically publishing threat reports on various actors and associated campaigns, the kill chain strategy is absent. Again, this is not to single Microsoft out. No security vendor that I know of does this. 

Rick Howard: The bottom line is that if you want to pursue this strategy, you'll have to do that yourself, either with the collection of Microsoft SaaS products or with third-party security products. The same goes for risk assessment. And again, this is not a hit on Microsoft. If you are running a mature risk assessment program, you're not doing it with any security vendor product that I know. 

Rick Howard: So here's the bottom line - if you're trying to implement the four pillar strategies for my first-principle vision, you aren't doing that with Microsoft Azure alone. Intrusion kill chain prevention and risk assessment notwithstanding, zero trust and resilience inside the Microsoft Azure are not fully formed products either. They remain just a collection of tactical tools that the customer has to manage in order to accomplish a larger strategy. And they are incomplete solutions with respect to how strategies might be orchestrated in hybrid cloud environments and in other key places where our data might reside, like in our own data centers and employee devices. 

Rick Howard: That said, this is no different from the current situation with on-prem security solutions either. No one single vendor can do it all. Security platforms can do a lot of it, but they will have to rely on the cloud service providers to supplement them, too. 

Rick Howard: One final note - the YouTube videos produced by John Savill regarding the inner workings of Microsoft Azure are well done. He not only understands how everything works, but he also understands what IT and security executives are trying to accomplish. There are links to this material in the reading list for this episode, and I would recommend anything that he publishes. His videos are very good. 

Rick Howard: And that's a wrap. If you agree or disagree with anything I've said, hit me up on LinkedIn or Twitter, and we can continue the conversation there. Next week, I have invited the CyberWire's pool of experts to the Hash Table to discuss first principles in Microsoft Azure so they can tell me what I got wrong. You don't want to miss that. 

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, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design and original score. And I am Rick Howard. Thanks for listening.