Microsoft Sentinel – Planning & Architecture
Last Updated: 29/10/2024
So, you have decided on Microsoft Sentinel. Great! Whilst the switching on of Microsoft Sentinel is straight forward (being a cloud service), the planning aspect is something that typically has more complexity and should not be overlooked.
Below I have detailed a few steps to consider when planning for Microsoft Sentinel.
- Define Objective, Scope, Business Drivers and Compliance Requirements
- Clearly outline the goal and objective of Sentinel.
- Detail the business & technical drivers you want to address.
- Determine use cases, what are we trying to project
- Define any compliance requirements, such as data location/residency and retention.
- Assess Your Environment
- Evaluate your existing infrastructure and security solutions, remember that Sentinel takes feeds from existing sources.
- Identify any configurations needed for logging. Servers and solutions may require configuration to enable logging of events i.e. Windows servers may need advanced audit configuration enabled.
- Identify critical assets and potential use cases (i.e. Suspicious activity we want to detect against).
- Based on your asset list (of what will be ingested into Sentinel) estimate the cost of Microsoft Sentinel.
- Design Architecture
- Multiple Entra ID tenants will impact the architecture.
- Geographic requirements will also impact the design and architecture.
- You are not limited to just one Sentinel instance, in fact in certain deployments you may need multiple Sentinel instances depending on where your data is and how you have structured your Azure Subscriptions. In this instance, consider using Lighthouse.
- Planning Data Source Onboarding
- Identify the sources of data you want to monitor, it’s worth tiering these out based on priority, impact and value.
- Detail and plan the onboarding process of the chosen data sources, including the configuration (for change management) and the pre-requisites (such as permissions).
- Depending on the data sources (mainly for those that are NOT out of the box), be sure to detail how you plan to normalise the data so Sentinel can understand the data.
- User Access (RBAC)
- Plan user access and role assignments for the Sentinel Instance.
- Define roles and permissions to ensure that different teams have the appropriate level of access.
- RBAC in Azure can be very granular, so take your time to plan this out. There are out of the box role assignments specific to Sentinel. For automation using Playbooks (Azure Logic Apps) these have separate permissions.
- Planning Detection with Analytical Rules
- This is arguably where we should spend the bulk of our time and effort…getting logs in is fairly easy, creating advanced detections is where the real value is.
- The goal is to develop rules that define how Sentinel will identify security threats, based on your defined use cases and the data sources you are ingesting.
- Leverage the out of the box rules that come with Microsoft Sentinel.
- Ensure you test and tune your rules.
- Incident Management
- When rules are triggered in Sentinel they will create an incident, from here you can investigate the activity and entities related to that incident.
- Having the correct process in place to deal with incidents is key, it may be the case to update your incident response plan with how to investigate and qualify security incidents with Sentinel.
- Planning of out of hours monitoring and incident management is also a must.
- Use of automation should also be considered at this stage, anything that can help with the notification and actions of an incident will help greatly.
- Testing and Validation
- Having a test and validation plan is crucial to ensuring your detection/analytical rules function as expected.
- There are numerous ways of testing and triggering alerts.
- Training Requirements
- Whilst Sentinel is a powerful SIEM solution, it still needs to be managed and maintained.
- Having a suitable training plan with your staff members is key to ensuring you get the desired result from Sentinel.
- Continuous Improvement
- Whilst this may not be in your first draft of your plan, it’s worth noting that as things change and as incidents are responded to, you will need to adapt your Sentinel instance.
- Include regular reviews of analytical rules, workbooks, playbooks, and overall architecture.
- Ad-hoc reviews and testing should be conducted when adding additional data sources.
- Utilise the reporting and workbook functionality of Sentinel for insights into your environment.
Whilst not an exhaustive list, this should help in detailing out some of the key points to consider when planning an implementation of Microsoft Sentinel.
Every organisations deployment of Microsoft Sentinel will be slightly different based on your requirements, adapting these steps will help you plan and execute a successful deployment of Microsoft Sentinel.
If you are interested in understanding how far SIEM solutions have come, please check out my post on the history of SIEM.
good post đź‘Ť
Thank you Ajak!