MS Sentinel: Deploy

Azure Service vs. Azure Resource

Before we proceed, it is important to underline an important difference between the concepts involved in the Microsoft Sentinel architecture: the difference between an Azure Resource and an Azure Service.

Given the above definitions, let's try to think of Log Analytics workspace as the baked part of a cupcake and Microsoft Sentinel as the icing and sprinkles on top of it.

The joyful experience of eating a delicious cupcake comes from combining both parts. Similarly, Microsoft Sentinel is like that. Without the icing, it is never a complete experience.

Microsoft Sentinel Architecture

The core component of MS Sentinel architecture is Log Analytics workspaces (LAWs). Essentially, a LAW is an Azure resource where the logs are stored. We will further look into LAW details in the following tasks; however, for now, we can say that the number of LAWs and how they are structured will determine the architecture of the Microsoft Sentinel environment.

When it comes to implementing Microsoft Sentinel, there are mainly three options:

• Single Tenant - Single Log Analytics workspace
  
  • Central repo for all logs across all resources
    • Central pane of glass
    • Consolidated logs
      
  • Potential concerns: Logs will travel across Azure regions. As a result of this:
    
    • Bandwidth costs due to logs travelling across regions
      
    • Data governance issues due to data residency requirements
      
• Single Tenant - Multiple Log Analytics workspaces (Regional)
  
  • In order to address the logs travelling across regions, regional LAWs can be created in different regions.
  • Although this might address bandwidth costs and data governance concerns, on the other hand, it will bring other concerns, such as:
    • No central pane of glass
    • Granular access control
    • Granular retention settings
      
• Multi-Tenant
  • If LAWs are not home tenants, then a multi-tenant architecture will be needed.
  • An example of this architecture would be cloud service providers.
    • I.e., when a security organization needs to monitor other organizations' Microsoft Sentinel deployments.
      

To recap, on a high level, the following considerations will shape your Microsoft Sentinel architecture and deployment options:

• Tenancy
  
• Compliance
• Region
• Access