Tuesday 12th September 2023
Writer: Gennaro Migliaccio, Contributor: Nicole Chesworth
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 Drivers you want to address.
Determine the scope of the deployment, typically, which data sources you want to monitor.
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 (some servers and solutions may require configuration to enable logging of events, 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) it's worth estimating the cost of Sentinel.
Multiple Azure Subscriptions and Azure AD tenants will impact the architecture.
Geographic requirements can 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
Planning Data Source Onboarding
Identify the sources of data you want to monitor, it's worth tiering these out based on priority/impact.
Detail and plan the onboarding process of the chosen data sources, this could be 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.
Planning Detection/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
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
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.
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 Sentinel will be slightly different based on your requirements, adapting these steps will help you plan and execute a successful deployment of Microsoft Sentinel.
Thank you for reading!
If you have any questions, or would like to learn about any of the content covered in this blog, please email our friendly team via [email protected].
Want to keep informed? Sign up to our Newsletter