Traffic Light Protocol alike Security Reference Architecture for Azure

Introduction

The way how organizations categorize/handle classified information can vary significantly. Where it can go from about 6 categories towards a more “limited” set of 3 to 4 categories. Where you see that some government organizations have even tried to reduce this in an effort to make it more accessible.

 

So for today, we’ll be looking at how we can handle sensitive/classified information in Azure. And to ensure you that you Azure implementations can facilitate sensitive data.

 

Side Story : Security should be like a roundabout

Though I don’t remember which conference talk it was… One visual has always stuck with me when talking about security. Imagine security like road infrastructure. Having a complex situation might be needed at times, though it will increase the risk that the drivers (~users) will make mistakes.

Now imagine a roundabout… There is one simple rule ; “Who is on the roundabout has priority!”.

And there is even an additional feature to this… If someone is unfamiliar with the environment, you’ll notice that they’ll be “less fluent” when manoeuvring on the roundabout. Why does this matter? Let’s consider this an “anomaly”… which suddenly has become very easy to detect. Now imagine the complex roundabout again, and think how you can detect anomalies there? Indeed, security rules need to be simple for both the users to grasp them and for the control mechanisms to easily detect anomalies.

 

 

Personal Take : Traffic Light Model

Now with that in mind, I always like “simple” models where you have 3 (up to a maximum of 5) options. Multiple psychology studies have shown in the past that people cannot process more than 5 options. With this in mind, I do like “Traffic Light” visualizations, like for instance… “The Traffic Light Protocol” in terms of data classification. With that in mind, I created the following “reference architecture”. Though, as a side note, for me… a reference architecture should only be used as “inspiration” for your own designs. Do not use it as something that was set in stone!

 

That being said, the design starts from the concept of having three security zones ;

• Green – “Public” – Basically any information where the is widely circulated. The combination of both the fully public one, as the internal information that it’s not that sensitive by nature.
• Yellow – “Restricted” – All information that is considered sensitive, with a typical “need-to-known”-basis as the rule of thumb behind it.
• Red – “Secret” – The information that would have been locked up in a secured vault when we would be talking about the analog world.

Again, as said, use the above as guidance/inspiration… Your mileage may (most probably) vary. Though this might help you devising your own security zoning strategy!

 

Azure Implementation

Now how might we implement such a thing on Azure? Below you can find a high level architecture that covers several basis ;

• Network Zoning : Network access security
• Data confidentiality : Encryption At Rest, Confidential Compute,
• Identity Driven Security : Authentication, Authorization, RBAC, PAM/PIM, Service Identities, …
• Audit Trails : Logging & Reporting

So let’s take a look at all of those aspects…

 

Part One : Network Zoning

Let’s first start with the concept of security where most people are drawn towards most easily… being the network access security part. So let’s filter out some parts from the overall architecture.

What do we see here? On the left we’re having our “On Premises” part, that will connect to our central “HUB”, where the spokes might have their individual security classification.

And what does that mean per security zone?

• Green (public)
  • Hybrid connectivity ; We’re allowing it to traverse the public internet via a public VPN.
  • Spoke model ; It’ll rely on the HUB to handle the network access layers.
  • Public internet ; We can allow this zone to be published from the outside world (via the HUB).
• Yellow (restricted)
  • Hybrid connectivity ; Here we’ll be leveraging ExpressRoute as our leased (private) line. Though given the nature, we’re not going to encrypt the medium/channel as such. Here we’ll rely on the application layer to encrypt the data in transit (on data level or on package level).
  • Spoke model ; Same as “green”.
  • Public internet ; If needed, can publish it like “green”. Though it might be more sensible to have a proxy layer in between;
• Red (secret)
  • Hybrid connectivity ; In addition to the ExpressRoute we’re leveraging in “yellow”, we’ll also be building a secure channel on top of this private line.
  • Spoke model ; Inside of the spoke, we’ll deploy an additional security gateway/layer that needs to be traversed.
  • Public internet ; Though this could work the same way as “yellow”. The advice here would be to also ensure that the data is encrypted with a Rights Management System. This as the request (to expose the data) as such is already an indication that network security alone does not cover the entire perimeter.

What about the HUB? As it’s colored entirely in red? The HUB is the “weakest link” as the central point. It’ll take the most restrictive level of the security zones. If there is no “red” zone, then it can be seen as a “yellow”-zone instead.

 

Part Two : Data Confidentiality

For the next part, let’s take a look at the data confidentiality part. A lot can be said in terms of security on the data pane. Where a lot of focus is typically drawn to the “Encryption at Rest” aspect. In regards to the architecture ;

• Green (public) : Here you can leverage the server-side encryption (SSE) of the Azure services itself. In the backend it’ll be powered by “Microsoft managed keys”.
• Yellow (restricted) : When you want to up it a notch. Then you can “Bring your own key” to the party, which will be backed by an HSM (of Azure Key Vault).
• Red (secret) : In the highest level you can leverage a dedicated HSM and/or even use client side encryption / disk encryption.

Next to that, know that services like Rights Management Protection work agnostic of the location (network zone) of the data. In addition to the Identity Driven Security (discussed later on), it provides the suitable layer for mobile users (anyone outside of your controllable perimeter) to also consume sensitive information!

In addition, there is also the concept of Confidential Compute. If you are unfamiliar with it, then I would highly recommend taking a look at this demo (as it only takes a few minutes).

 

Part Three : Identity Driven Security

When looking towards security, it’s sometimes overlooked, that the identity part is the most essential part of the puzzle. How can you grant people rights to sensitive information (authorization) if you cannot identify them (authentication) on an individual basis!

Where this part is actually zone agnostic. What can you do in your Azure implementation to help in this area?

• Cloud Identity : Azure Active Directory (AD) is a key part of the cloud solutions of Azure. It’s where you will keep your single identity per user.
• Hybrid Identity : Most enterprises have a hybrid identity. Where you link you On Premises Active Directory (AD) with AAD by leveraging Active Directory Federation Services (ADFS). With this setup you can ensure that you only synchronize the bare minimum of AD objects, and even avoid syncing the password (hash) towards AAD. Every time a user needs to authenticate, they’ll be redirected to your On Premises systems for verification.
• MFA : Enable MFA. Period. Really… no discussion about this.
• (Managed) Services Identities : Ensure that your systems have their own identity. The managed services identity (MSI) will help you on the operational side of this…
• JIT/JEA : These acronyms stand for “Just In Time” & “Just Enough Administration”, or basically… You get the minimum amount of rights needed to do the job, and only for the time you actually need to do the job. There are various ways how you can implement this, going from security center’s JIT towards PAM implementations like (AAD’s Priviledged Identity Management, or something like Cyberark’s PAM).
• RBAC : Working with role based access control will also already limit the attack vector by a great amount.

 

Part Four : Auditing & Reporting

Despite being a small chapter in the end, it still packs a powerful punch. EVERY administrative action you do on Azure is being logged in the audit logs. ALL ACTIONS on AAD are also logged. You can leverage these logs to use as audit trails & run reporting upon them. You can even feed them into your SIEM system. Though in it’s most minimalistic form, do implement the PowerBI solutions that come free of charge.

Closing Thoughts

For those who have heard me speak about security, I often talk about a city like Dubrovnik, or medieval one like Carcassonne. The classical thought of security was to build a bigger moat or higher wall. This was quite succesful until the invention of gunpowder… Then these walls could be blasted to pieces.

In our modern times, the analogy of gunpowder is the roaming behaviour of our users. At least 15% of any organization’s users will be working at a given time outside of the office perimeter. So the concept of solely relying on network security as such is pretty flawed. Here I’m not saying that network security is not needed! Though, as seen above, do take Data & Identity Driven Security into account for your security strategy.

 

A lot of organizations out there are looking to digitally transform themselves. From a security point-of-view, know that they are looking for a fast time to market here. Here I know that this is very contra-intuitive for any security implementation. This as you want to be 200% sure that every hole has been closed. In light of this… I would like to leave you with a thought in this area ; “Use zones that allow them with the needed flexibility, where you can safeguard them by guiding rails”. Usability & security typically don’t go hand in hand. Only enforce the most strict things when needed. An MVP (minimal viable product) test case might be more suited towards the “green”-zone (or even “white”) during the genesis phase. Where you can move it towards “yellow” (or even “red”) once it matures more. Always thing in terms of risk bases security assessments.