Azure Sentinel Setup

Wortell uses Azure Sentinel as Cloud SIEM to deliver its security services. Each Azure Sentinel instance gets deployed in the customer tenant. This means that only alert related data is send over to Wortell. Logs stay in the customer tenant. This article describes how Azure Sentinel is setup within the customer tenant.

Regions

Azure operates in multiple geographies around the world. An Azure geography is a defined area of the world that contains at least one Azure Region. An Azure region is an area within a geography, containing one or more datacenters.

Each Azure region is paired with another region within the same geography, together making a regional pair. The exception is Brazil South, which is paired with a region outside its geography. Across the region pairs Azure will serialize platform updates (planned maintenance) so that only one paired region will be updated at a time. In addition, in the event of an outage affecting multiple regions at least one region in each pair will be prioritized for recovery.

Microsoft recommends that you configure business continuity disaster recovery (BCDR) across regional pairs to benefit from Azure’s isolation and availability policies. For applications which support multiple active regions, we recommend using both regions in a region pair where possible. This will ensure optimal availability for applications and minimized recovery time in the event of a disaster.

The initial region where the solution will be deployed is West Europe. Based on customer requirements, a different Azure Region than West Europe can be chosen.

Naming Convention

In order to have a clean and structured solution, the following naming convention has been designed:

Explanation of used abbreviations in naming convention: | Abbreviation | Description | | ———— | —————– | | {org} | Shorthand name of the organization (e.g. ORG). Max 3 characters | | {func} | Shorthand functional name (e.g. SEC). Max 5 characters | | {stage} | Stage to which the resource belongs, possible options: DEV, TEST, ACC, PROD, DEVTEST | | {region} | The region in which the resource is deployed (in 4 characters) | | {description} | Short description of the resource | | {number} | Number (will increase when multiple resources with the same name exist) |

Where possible, names will consist out of capital letters. Special characters will not be used with the exception of the following characters:

• “-“ will be used to connect the parts of the naming convention
• “_” spaces will be replaced with underscores in the description part of a name.

Usage of small and capital letters will lead to a unstructured view of the environment in some tools. Depending on the tool you use, a case sensitive string is displayed, all characters converted to small letters or all characters are converted to capital letters.

Only working with capital letters will lead to clean name in most of the tools.

Azure Subscription and Resource Groups

Subscriptions

In Microsoft Azure, a subscription is where all the work and cloud logic is located. Many organizations look at the following design patterns as their guidance:

• Application/Service: Subscriptions represent an application or a service (portfolio of applications)
• Lifecycle: Subscriptions represent a lifecycle of a service, such as Production or Development.
• Department: Subscriptions represent departments in the organization.

The first two patterns are the most commonly used, and both are highly recommended. The Lifecycle approach is appropriate for most organizations. In this case, the general recommendation is to use two base subscriptions. “Production” and “Non-Production,” and then use resource groups to break out the environments further.

There are certain limits in the Microsoft Azure platform that can influence the need for multiple Azure subscriptions. Over time, these limits can change and may be updated. To verify current limits please refer to the following website: https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits

At least one subscription will be created which holds the production instance of the MDR solution. If for some reasons a testing instance is required, a second staging subscription will be created. An important reason to have a dedicated MDR subscription is the segregation of duty. Wortell access is granted trough Azure Lighthouse. Permissions granted by Azure Lighthouse are subscription wide.

Resource Group Topology

The infrastructure for your application is typically made up of many components – maybe a virtual machine, storage account, and virtual network, or a web app, database, database server, and 3rd party services. You do not see these components as separate entities, instead you see them as related and interdependent parts of a single entity. You want to deploy, manage, and monitor them as a group. Azure Resource Manager enables you to work with the resources in your solution as a group. You can deploy, update, or delete all the resources for your solution in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging, and production. Resource Manager provides security, auditing, and tagging features to help you manage your resources after deployment.

Wortell will create a resource group that holds all SIEM related resources, think of the Log Analytics workspace, Dashboards etc. If connector resources (such as a Syslog server) are required, separated resources groups for them will be created.