Change Management with Microsoft Sentinel

blog-featured-image-change-management-with-azure-sentinel

Stay on top of a SIEM that is constantly evolving.

Microsoft Sentinel is constantly being updated by Microsoft security engineers. This is great for security analysts because they are constantly getting new features to work with. It is also good for admins, but the constant updates also create challenges because there is no formal change management system in Microsoft Sentinel.

In this blog, we will go over the change management process that CyberMSI uses to track the changes in Microsoft Sentinel. We will also discuss how the step helps with the broader goals of change management when it is being used for security within an organization.

Routinely Search for New Features

There is not a formal location where the developers working on Microsoft Sentinel announce all their updates. There are also many useful community features that are being released in a decentralized manner.

To get around this issue, someone on the security team should routinely look through common sources of information about updates to Microsoft Sentinel features. This way the security team can be more certain that their SIEM has all options they can implement available to them.

Here are some of the places CyberMSI regularly checks for updates:

Evaluate New Features

Once the changes are found, it is important to sort through them to make sure that they are worth the time it would take to test and implement them. Have a member of the security team go through the changes and evaluate them based on criteria that are important to your organization’s security strategy.

Analysts at CyberMSI use some quick metrics like “Volume” and “Impact” to see if the changes they have found are going to be worth the time. Volume is the number of changes that would need to be made, and the Impact is how much value the changes can give us in return for the effort we put into implementing them.

Discuss Implementation

When the most valuable changes are identifed, security management and potentially some other members of the security team need to discuss implementation. The security team member that is presenting the changes needs to effectively communicate what the change does and why it is important to the organization.

At CyberMSI, analysts take the changes that they determine are useful and present them to their team lead for review. Unless the change is massive and will impact the whole company, the team lead’s judgement can be trusted for evaluating the costs and benefits of the new feature.

Test New Features

Once a certain Microsoft Sentinel feature receives the green light, the new feature is tested. An Microsoft Sentinel test environment/instance is useful for vetting new features. If a feature isn’t quite ready for prime time,it will only affect the test environment instead of production.

CyberMSI has multiple test subscriptions that are used for different types of feature testing. A workbook that gathers data from across subscriptions has different needs than an analytic rule that only looks for alerts in a specific 3rd party technology.

Implement New Features in Production

When the testing is finished, and the features are confirmed to be working as intended they can be deployed to production environments. An organization should have well documented procedures for deploying to production that the security team can follow for rolling out a new feature without any adverse impacts.

Since CyberMSI is a cybersecurity services provider, we need to deploy to many different subscriptions with different rules based on the requirements of each customer’s specifications. Luckily, we have automated tools that can help with these deployments like the Sentinel CI/CD pipeline and the recently released Sentinel Solutions offers.

Update All Parties Involved

The feature is implemented, now it is time to tell the people impacted by the change about what happened. Organization members that are involved can be informed either through formal communication channels like email or by updating shared change management documentation.

Most changes are logged in one of the shared change management spreadsheets, but for major changes email updates or a meeting would be needed to notify all parties involved with the change. For some tools there may even need to be training sessions because of how much the new feature affects incident management.

We will continue to share best practices and lessons learned in future posts on managing Microsoft Sentinel. Formal change management processes like these will help keep your cloud security tools organized and secure.

In closing, consider these three questions when using change management in your organization:

  1. Are we tracking any of the changes happening in Microsoft or are we discovering new features at random?
  2. When we discover a change, do we have any processes for implementing the changes or is it tacked on without consideration?
  3. Do we have a good way of framing the importance of change management so that others will go along with the procedures?

How Can We Help?

Main Contact Form