One of the best parts about writing, speaking, and teaching about security is when I get emails or messages from readers. I am thankful to the many people over the years who have made suggestions on how to get better at what I do, especially the ones who have pointed out mistakes or errors in thinking. In that vein, I recently got a reader email that inspired this particular column. The reader, who is the chief information officer for a large multinational insurance company, had a simple question:
… we’re starting to think more about our change and release management for conditional access policies. Do you know of any guidance on the subject? We need to flesh out an enterprise-grade approach for versioning, piloting, naming conventions, etc.
That’s a good question, but a broad one. After all, “change and release management” is just about as broad a topic as “gardening” or “pet care.” The answer to any question like that inevitably involves asking a bunch of other questions (what kind of pets? Where do they live? How’s their health?) before you can arrive at anything useful.
Four Practical CAP Management Tools
Before I could arrive at any useful response, I was delighted to see a Practical 365 article on the topic pop up: Jasper Baes’ “Four Practical Tools and Strategies for Success with Conditional Access Policies.” I won’t recap the content of his excellent article other than to say he discusses four tools you can use as part of a conditional access policy (CAP) management strategy.
- Flow diagrams to identify which user roles should have which types of access; Baes refers to these role definitions as personas.
- A template to help you identify which personas need which levels of access
- The Conditional Access Impact Matrix tool, which connects to your Entra tenant and reads user and policy information and produces an Excel file showing which existing policies will be applied to each user in your Entra ID tenant.
- Simulation tools such as Maester or the (paid) Toreon scanner. These tools help you validate your policies to ensure that they work the way you intend, but also that they don’t contain any surprises.
These four tools are all useful when you think about managing CAPs but there’s more to consider.
Microsoft’s Framework: Heavyweight CAP Management
From the days of the gigantic printed BackOffice Resource Kit to today’s Azure Architecture Center, one thing Microsoft does pretty well is write documentation to tell people how to manage their products. However, this documentation is often dense, overcomplicated, and hard to apply for anyone other than the largest and best-staffed enterprises. From that viewpoint, consider the Conditional Access framework and policies section of the Azure architecture center. Like the Baes framework, Microsoft’s framework depends on you defining personas, but then they also recommend a specific set of policies to use as a starter, then a set of deployment rings, monitoring controls, and more. While the Microsoft framework is comprehensive, it’s also complicated.
A Practical Approach to CA Policy Management
To answer the original question, I wanted to combine some elements of both the Baes and Microsoft frameworks (especially since there is some overlap between them). I’m going to assume that, like this reader, you already have some type of CA policy deployment, and that your goal is to have a useful and productive way to control and manage changes to that deployment.
Let’s start with a common touchpoint between the frameworks: the personas. I like Microsoft’s namespace for personas (Global, Admins, Internals, Externals, GuestUsers, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts) but you may choose to modify that depending on what your environment looks like; at a minimum you need a default CAP that applies everywhere, and you probably need specific CAPs that cover internal and external users, and service accounts. It’s easy enough to take the list of suggested personas, remove any that you don’t need or want, and customize the names to match your environment.
Once that’s done, you can rename your existing policies to bring them to a common standard. I think Microsoft’s scheme (which combines the persona, policy type, a number, and a bunch of other stuff) is too complex for most organizations. Instead, think about what you want to know when creating or editing a policy: who does it apply to (the persona), where does it apply (platform and application), and what does it do (block, grant, require compliance, etc). Depending on how complex your existing policies are you, you might also want to add a device type.
This next part is important—before you jump into the Azure portal and start renaming stuff, make a list of the proposed new names for your existing policies. Look for gaps. Do you have a policy that applies some kind of control to Android but not a corresponding one for iOS? Do you have a global policy to apply risk-based sign-in detection? If you find gaps, pencil in names for the needed new policies. Again, the goal isn’t to immediately start making changes, it’s to start the process of managing these policies instead of just having them.
Armed with the list of policies you should have, you can next assess what those policies should do. Merril Fernando’s Conditional Access PowerToys make it easy to generate documentation of the settings of the policies you have, which you should verify by eye and hand to ensure that they do what you think they will. After desk-checking those policies, run them through Baes’ Impact Matrix tool to spot check that the effect of the policies on selected users matches what you would expect.
At this point, you have a lot of information about the current state of your policies. That information equips you to modify the policies as needed to close any gaps: add new policies where needed and adjust the coverage or conditions of existing policies… then go back and check the changes, both by hand but also with the Impact Matrix tool. Repeat as necessary until you’re confident that the policies you have do what you want, and only what you want.
Think of this phase like pulling the weeds from a neglected garden. It’s a lot of work, and it’s not much fun while you’re doing it, but it’s necessary, and once you do it, it’s much less work to maintain weed-free life going forward.
Forward-looking Policy Management
Once the metaphorical weeds are removed from your policies, you are in a good position to apply change management to them. Change management for CAPs is really no different than any other type of IT policy change management: you must define who is allowed to make changes, who must approve them, how they will be made, how they will be tested (before and after), how they will be documented, and how they will be reversed if they turn out to be bad. Most organizations have done the “who is allowed to make changes” part already, but if you can define these other process elements, you’ll be better positioned for control of what changes and when.
Of course, you also need to remember that Microsoft makes changes to the CAP feature set from time to time; your process needs to be flexible enough to incorporate these where it makes sense to do so.
Note that my steps above don’t cover every possible aspect of managing CAPs; for example, my reader asked about piloting policy changes, a topic covered in the Microsoft framework’s concept of deployment rings. However, if you take the time to go through the basic steps above to get your CAPs into a basically-managed state, you’ll be in a much better place to move towards a more advanced state when it’s appropriate.
