This is the second in a pair of posts on the most important actions to take to set up and maintain security in your Azure environment. This post picks up where the prior one left off in the list of 10 critical security concepts. (See the first five items here. Also, check out related content in my 10-part series on the top mistakes to avoid when getting started in Azure.)

Before jumping into the second half of the top-10 list, I’d like to note again that each of these ideas are drawn from experience working with hundreds of clients. By implementing these concepts up front, you can save untold hours of work later on when you realize you need to restructure your environment for better security. My goal here is to provide a quick-reference checklist you can use to maximize security benefits from the beginning.

#5 – Use Azure policy and ARM template rules to deploy critical security controls. 

Security policy shouldn’t happen by accident. And it shouldn’t be something you suggest to your application teams. Rather, your goal should be to define corporate policy and then to clearly and declaratively say to your application teams, “this is what a secure environment looks like for us.”

In this way, you give your application teams room to run down the road quickly—while still ensuring they stay on the road. Only by deploying policy in a formal way can you ensure all your application teams, including those you may have less contact with, are subject to consistent operational practices.

Note that nothing about using Azure Policy limits creativity. You’re simply saying that any deployment must be properly classified and tagged—and that those classifications will in turn kick off appropriate measures ranging from Azure security settings to internal audits.

Determine these up front. Don’t set security policies on the fly! This is the new paradigm of IT as enablers in action. IT is no longer delivering devices and services but rather enabling them, subject to appropriate corporate controls. Setting what those controls should be is a primary function of IT in the post-corpnet world.

#4 – Leverage Azure Security Center to assess the environment

Azure Security Center brings together in one place wide-ranging information about the security of your Azure configuration and the virtual machines (VMs), app services and containers that exist inside that configuration.

Not using Azure Security Center is an obvious security miss, because you’d be forgoing straightforward information about current security—including an overall “Azure Secure Score”—as well as practical suggestions for improvement.

In addition to accessing dashboard reporting, you can also use Azure Security Center to:

·       Assess patching status and application of security policies

·       Assess non-VM security contexts, such as web applications, SQL and ASE (App Service Environments)

·       Review analysis generated by third-party security-assessment plug-ins such as Qualys and Rapid7

·       Set actions to take in response to various states (for example, if a patch hasn’t been applied within 10 days of its release); potential actions might include triggering a logic app, creating a job ticket or sending an email

Always keep in mind that your development teams probably aren’t focused first and foremost on assessing security of the apps they create and manage. Assessment and response must happen at the administrative level, as a backstop if nothing else, and to accomplish both you’ll find Azure Security Center a highly practical help.

#3 – Don’t use everyday accounts as admins and use Azure Privileged Identity

You’re probably familiar with the admonition to beware of locking the front door only to leave the back door standing open. Well, using your everyday Azure login as your administrative account is worse than that! It’s leaving the front door open.

The nature of an everyday login makes it more vulnerable to compromise than is acceptable for an administrative login. If someone were to get hold of your credentials—say, through phishing—you do not want that person to be able to login as an administrator and run a script.

You need to protect against this scenario in two main ways. First, by segregating your administrative account from your everyday account. And second, by applying Privileged Identity Management (PIM) to that administrative account.

With PIM, you can designate certain permissions to be enabled only upon request, so that even when logging in with your administrator account, there is still a further gate to pass through. You could set up those requests to be granted automatically, in which case you’ll benefit from a formal log of when such permissions come into play. Or, you could go a step further and require requests to be individually reviewed by a person. This approach takes role-based access to the next level: “just in time” access.

#2 – Implement conditional access for devices accessing Azure administration

You need to think applying conditional access rules as being every bit as basic as washing your hands before coming out of the bathroom.

Remember, the future state of corporate computing isn’t highly interconnected networks. Rather, it’s micro-network segmentation with modern desktop computing, in which client devices aren’t directly joined to a centralized “corpnet” domain at all.

Instead, the new approach is to conditionally permit devices to access only those resources appropriate for them to do so. Intuitively, this is the same mentality as applies to permissions at the user level (e.g., “Should this user be allowed to access this application?”). But here, we are applying the conditions at the device level (e.g., “Should this device, connecting from this location, be allowed access?”) In the new paradigm, these rules are your firewall.

Let’s say someone obtains credentials from an administrative account associated with your domain. But say this person happens to be at an overseas location where you don’t have an office. Conditional access could prevent that person from logging in, if you have set up protections in advance. Those protections might include, for example, that only corporate-managed devices can join, and that all such devices must be healthy, up to date and in use with a set of recognized credentials.

Note that some aspects of conditional access are only possible to implement when administrating in a modern desktop model, with devices not joined to the corporate network. But don’t let that stop you from getting started. You can activate some functions while co-managing your network with SCCM alongside the modern desktop model.

#1 – Implement multi-factor authentication for admin and author users

There’s really no excuse for inaction here. We all have phones in our pockets. Your users are probably already used to MFA in managing their own personal bank accounts or online services. So, if you haven’t done so yet, the time to implement MFA in your corporate environment is now.

Again, identity verification + conditional access rules are your firewall. At bare minimum, implement MFA in Azure AD for administrative functions (and, as above, combine this identity verification with conditional access at the device level).

I’ll keep this entry brief, with a hope that you’ll use the time you might have otherwise taken to read another paragraph and go, right now, to turn on MFA for your administrative accounts. This is the single most important thing you can do today to protect against an administrative breach.

Next steps

That wraps up all 10 in the list of most important security steps to take as you get started with and Azure. As I wrote previously, I recommend you put all 10 together to form a checklist to ensure you get going in the right direction from the start.