By Deb & Tom Shinder
(This article provides you an inside look into the Network Security chapter in the upcoming book – Azure Security Infrastructure)
In my job as an Azure Security Engineering Program Manager, I spend a lot of time talking to customers about Azure Security. In fact, that’s my main job – to talk to current and potential Microsoft Azure customers about Azure security. It’s something I really love to do and the position provides me a lot of opportunities to hear what questions come up regarding issues and concerns over Azure security.
If there’s one subject that comes up more than any other, it’s the issue of Azure network security. There are a lot of reasons for this, but my guess is that historically the network was the focus point for security efforts in the enterprise. There’s a reason why we laugh when someone asks the question “are we secure” and the answer is “yes, we have a firewall”
We laugh because we know that a firewall is just one part of the entire security equation. But in the minds of many IT organizations and the public at large, the firewall is the icon for security. But as IT professionals of all stripes know, we’re kidding ourselves when we think that a firewall has ever done a whole lot to protect us from the myriad of attacks and exploits out there, just waiting to subvert our best efforts.
I know it’s really hard to imagine, but the primary pivot for security efforts needs to move away from a network-centric approach to security. While the network-centric approach is very near and dear to my heart (I was once called the eminence grise of the now defunct ISA Server, a network firewall created by Microsoft), I realize that times have changed. And what changed the times was the cloud.
Why?
One of the essential characteristics of cloud computing is “broad network access”. There are a lot of interpretations of what this actually means, but in practice in the real world, what it means is that firewalls have, by necessity, become extremely porous. Not only that, but our users’ demand to use any device they want, and to bring those devices into the corporate network (whether managed or not). This makes the edge firewall and other network-based approaches less effective than they used to be.
In fact, is there an “edge” to the corporate network any longer? Sure, from the server and service perspective, you probably have secure subnets where there are tight inbound and outbound access controls and there’s Internet ingress/egress points. What about the client systems? In the past we had network segments defined for internal network clients. But do you have those now?
Maybe. But it looks a lot different now. Maybe you have a subnet for managed corporate clients which is separate from unmanaged client (guest) subnets. But when it comes to network access controls for those segments, it’s pretty much “all open” or “all HTTP/HTTPS open” (which is about the same as “all open”). Corporate client systems just don’t get the attention (from a network perspective) that they used to, and for good reason – there’s little payoff for doing so.
I don’t mention all this as some kind of apologia for why you shouldn’t pay attention to network security any longer. Far from it! My first love is network security. Just because it shouldn’t be the primary focus of your security efforts doesn’t mean that it’s not important. I’d argue that network security is more important than ever, if for no other reason than you can gain a large amount of information regarding initial attacks, attacks in progress, and stealth invaders by being assiduous with network security.
The customers I talk to, even if they don’t consciously realize it, are aware of this too. They are also aware of what they can do in terms of security on their on-premises network, and they understand their network security technologies and processes very well. However, they’d like to take advantage of the sunk costs related to that knowledge and extend, as much as they can, as much of the security architecture they have on-premises into the public cloud.
Is that possible? For the most part, yes. Is that desirable? That’s where personal and professional opinion come in. There are some components and strategies that enterprise IT uses on-premises for network security that are fully supported and recommended in the public cloud. And there are other components that are in widespread use on-premises that aren’t nearly as relevant or effective (or even possible).
You’ll have to decide for yourself. I’ll give you my opinions, but in the end, it’s your opinion that counts. My job here is to give you the information you need so that you can come to best informed opinion possible.
In my chapter on network security in the Azure Security Infrastructure book, my assumption is that you don’t know a lot about Azure in general, or about Azure networking in particular. And if you know about Azure in general and you know something about Azure networking, you might not know about the key security issues and considerations. If you’re already an expert in Azure security, there’s a good chance you won’t learn a lot of new things here, but I recommend you read the chapter as a refresher. Also, you might benefit for my unique perspective on Azure network security. Maybe I’ll say something that will make you re-think your position, or motivate you to send me an email to tell me that I’m crazy.
In order to understand Azure network security, you have to know all the pieces and parts that comprise it. That means we’ll begin with a description and definition of all the features and services related to Azure networking that are relevant to security. For each feature I’ll describe what it is and provide some examples to help you understand what the feature does and why it’s good (or bad) at what it does. There are some capabilities in Azure networking that don’t have a security story to tell, so I’m not going to bring those up.
After we lay the groundwork and have a common understanding of Azure networking, I’ll discuss what I consider to be Azure security best practices. These best practices are a compilation of things that you should do regarding Azure network security if they are appropriate to your deployment. The best practices are based on customer experience, Microsoft field experience, and my experiences as an 18-year veteran of the network security wars. YMMV.
I end the chapter with a description of some useful patterns that you might want to use as reference implementation examples on which you can build your own solutions.
One thing that I won’t spend a lot of time on is providing your step-by-step instructions on “how-to” do things in Azure security. The network security documentation on Azure.com is rife with “how-to” articles and there’s little that I can add in this area. There will be a few examples that I might be able to add some value, but in general, the writers of Azure security content have done a good job at showing you how to do things – what they have done less of a good job at is explaining to you why you should care to do any of the things they show you how to do.
My goal is to help you understand the “what’s” and “why’s” – because if you don’t understand those, you’ll never get to the how’s. And if you implement the “how’s” without understanding the “what’s” and the “why’s”, you’ll end up with the same “it sort of grew that way” network that you may have on-premises today (and if your network isn’t like that, consider yourself exceptionally wise or lucky).
To summarize, I’ll:
- Discuss the components of Azure networking from a security perspective
- Go over a collection of Azure networking best practices
- Describe some Azure network security patterns that you might want to adopt for your own deployments
One more thing before we venture into the inner workings of Azure networking. If you’ve been with Azure for a while, you’re probably aware that Azure started with the Azure Service Management (ASM) model for managing resources. Even if you haven’t been around Azure since the beginning, you’re probably aware of the “old” and “new” portals (the “old” portal is now classed the “classic” portal and the new portal is just called the “Azure portal”). The classic portal uses the old ASM model. The “new” portal uses the new resource management model known as Azure Resource Management (ARM) model. In this chapter I will focus only on the ARM model and the networking capabilities and behavior related to the ARM model. The reason for this is this is that the ASM model is being phased and there is no future in it – so my best advice is to migrate your ASM assets (if you have any) to the new ARM model. For more information on the differences between the ASM and ARM management models, please search for the article “Azure Resource Manager vs. Classic Deployment: Understand Deployment Models and the State of Your Resources” on Azure.com.
I hope that you enjoyed this article and it’s motivated to want to learn more! To read the “rest of the story”, check out Chapter 3 of Azure Security Infrastructure. Thanks! -Tom.
