Introducing Azure Magma

How to manage security groups at scale in hundreds of Cloud subscriptions? The answer will be mostly steered by the Zero Trust model adopted by your corporation:

• if the main driver is identity based, ZT segmentation is used for grouping assets according to a business semantics and to limit lateral motion between groups hence alleviating complexity on network policies used in ZT Policy Decision and Enforcement;
• if it is network based, ZT segmentation is used for permitting pinpoint connections between individual (or small groups of) assets and to limit lateral motion between authorization scopes hence alleviating complexity on identity policies used in ZT Policy Decision and Enforcement.

The solution I propose to describe today is called Azure Magma: it is particularly fit for an identity-based Zero Trust environment managed in a devSecOps, Big-Five like organization.

Azure Magma in a nutshell

First, let me make it clear that Magma is not part of Azure services catalogue :)

Even if it is ideally suited for Azure, it could be implemented in GCP or AWS without difficulty because the underlying scheme is based on security groups which as you know are very similar across Cloud providers.

The base idea is this: following Azure NSG evaluation logic, for a given direction (inbound or outbound) we adopt a deny overrides evaluation policy: a flow is admitted only if an allow-rule applies and no deny-rule applies. Important note: we do not manage denies as part of Azure Magma, assuming a default rule is blocking all that is not allowed.

We then simplify all allow-rules in order to keep only source IP ranges (or Azure tags like VirtualNetwork), source CIDRs, destination port ranges and destination CIDRs (or Azure tags).

A simplified rule can have three possible states: good, bad or unknown. A rule begins its life in the unknown state and becomes good or bad after manual evaluation.

The hope, which might not work in your corporation if your ZT model is network-based as already stated, is to obtain a limited set of simplified rules which are being reused across all your NSGs.

This way we can achieve a scalable management of NSG lifecycles:

When a new NSG is created or when an existing NSG is modified, Azure Magma auto-validates the change based on a truth table if all underlying simplified rules are known.

Rules simplification

The first step is to collect all the rules of all your NSGs, using for example an Azure Resource Graph query:

The second step is to simplify all rules to make them readily comparable or merge-able, as explained above.

In theory, this simplification process should go so far as to interpret CIDR blocks like "10.0.0.0/8" or "10.1.0.0/16" in order to detect among other things that the latter is included in the former. It should also interpret Azure tags correctly. I will explain how to do that in a future article, however from my experience it is still possible to get decent results with CIDR blocks treated as-is, like uninterpreted symbols .

Let's call a simplified rule "canonical" if its CIDR blocks and port ranges are interpreted.

To give you an idea of what rules simplification looks like, imagine you must simplify the following NSG made of 5 rules (3 inbound + 2 outbound):

We remove all the outbound rules and the deny inbound rules :

To get the simplified rules, all we have left to do is remove the direction, order ID, protocol and action:

Note:

• If we interpret CIDR blocks, port ranges and Azure tags, both rules become canonical and it's an easy task for an automaton to detect that the bottom rule is "absorbed" by the red fields of the top one, so the bottom rule can be safely ignored.
• If we don't interpret the CIDR blocks and port ranges, we end up with two overlapping simplified rules: not a big deal for today!

Once the simplified rules are evaluated as either good or bad, they can be used again and again to auto-classify similar rules in many NSGs.

Truth table

The main question that remains to address is : how to tag a NSG with a status (good/bad/unknown) based on the state of all its underlying simplified rules?

For that we refer to the following table:

It's easy to see that this truth table defines a partition of the space of all possible NSGs.

Conclusion

Based on massive real-life production environments, I have been able to confirm that unless a rule is unknown, auto-classification may alleviate the operational duty of NSGs maintenance considerably.

Still, a last step for achieving stellar levels of automation is to resort to a solver able to digest CIDR blocks as well as port ranges and Azure tags (or AWS security group names) in a comprehensive way. I will explain how to do this in the most efficient way in another article.

Appendix: what is a "magma"?

In math, a magma is any space with an internal operation. In our case, we consider the space of all NSGs built on top of simplified rules. The internal operation, denoted '+', is the union of simplified rules.

For example, we can "add" NSGs a and b to form a new NSG c. We write it like this: a + b = c.

You will notice that a + a = a by virtue of the union operator acting on simplified rules.

Magma-quotient

Our truth table defines an equivalence relationship: the equality of NSG tags. We will denote it 'R'.

Two NSGs a and b are equivalent if their tags are equal. This is how we write it: a R b.

Now if we consider both operations '+' and 'R', we have the following crucial property for automated classification:

if (a R b) and (c R d), then (a+c) R (b+d) .

It means that when we combine two NSGs (possibly not sharing the same tag), we will always end up not only with a well-defined tag, but with a tag which is fully deterministic: its construction doesn't depend on the NSGs, it only depends on the two source tags.

Put it another way: our NSG space is not only a magma, but a magma-quotient .

Stability of NSG combinations

Finally, let's consider the following situation with any two NSGs a and b:

(a R a) and (a R b)

From the crucial property mentioned above, we know that (a+a) R (a+b) is true.

Now recall the special feature attached to '+': a + a = a, so we have:

for all (a R b): a R (a+b).

It means that if we add two NSGs a and b sharing the same tag, we're not going to run a wild goose chase: we will obtain a new NSG a+b with this exact same tag. The '+' operation is said to be stable in the equivalent classes of our magma-quotient.

Final word

Magma is definitely a cool name, but not only! It confirms what Boolean logic has told us about our auto-classification process:

• it is not going to miss any NSG tag. It captures the three of them: good, bad and unknown, and they are stable with regards NSG combinations
• it assigns tags according to a consistent process ("quotienting").