Chapter 14: Operational Tasks for Microsoft Sentinel

As with any service or solution, an ongoing maintenance routine is a critical process to ensure timely service improvements, maintain operational efficiency, control costs, and—most importantly—ensure the service remains highly effective in detecting and responding to security issues.

In general, Security Operations Center (SOC) operations are performed by two distinct roles: SOC engineers and SOC analysts. In a small organization, this may be a single person carrying out both roles; in larger organizations, these roles will span many teams and will be carried out by dedicated professionals. In this chapter, we will provide details of the daily, weekly, and monthly tasks required for each role, and any ad hoc tasks that should be carried out as required. You can use this list as a starting point for building your own tasks list to ensure optimal SOC operations.

The information in this chapter is meant to provide a starting point for your own planning and ongoing improvement, so you can carry out the necessary processes to produce a high-performing team and ensure a well-managed Microsoft Sentinel solution.

In this chapter, we will cover the following topics:

  • Dividing SOC duties
  • Operational tasks for SOC engineers
  • Operational tasks for SOC analysts

Dividing SOC duties

A well-developed SOC will be made up of multiple roles to divide up responsibilities and ensure that everyone can focus on their specific tasks. Depending on the size of the team, there could be many roles and many layers of management, leadership, and expertise, or it could be a smaller team in which two or three individuals carry out all the roles between them.

At a high level, the operation of an SOC will require experts that know how to install and maintain the technology solutions required to run the SOC (that is, SOC engineers) and another set of experts that are able to use the solutions to hunt for threats and respond to security incidents (that is, SOC analysts). These two roles work together to provide constant feedback on what works well and where improvements are required.

Let's review the primary differences between these two roles to understand the type of operational tasks they carry out. For detailed role guidance and permissions, please see this article: https://docs.microsoft.com/en-us/azure/sentinel/roles.

SOC engineers

SOC engineers are responsible for the initial design and configuration of Microsoft Sentinel. Their role includes the connection of data sources, setting retention policies, and configuring any threat intelligence (TI) feeds. The SOC engineer is responsible for implementing and managing role-based access controls (RBACs) to secure access to the platform and the data it contains (review Azure Active Directory (AD) as an additional research topic).

Once the service is operational, SOC engineers are then responsible for ensuring that data connectors remain healthy, providing ongoing improvements, creating analytic rules for threat detection, and fine-tuning the service to ensure it remains operationally cost-effective and efficient.

The SOC engineers will implement new features made available by Microsoft and develop automation functionalities and other improvements based on feedback from the SOC analysts and recommendations from the wider security community.

SOC analysts

SOC analysts focus on using the tools and data available to respond to alerts and hunt for other threats that may not have been automatically detected.

This role relies on the continuous development of new detection methods, the advancement and integration of machine learning algorithms, and the automation of threat responses to ensure SOC analysts can react quickly to new alerts.

To ensure they can focus on threat detection, SOC analysts offload the tooling and rule configuration to SOC engineers, allowing the engineers to create and maintain their playbooks, and define their standard operating procedures for identifying and responding to suspicious events and behaviors.

Operational tasks for SOC engineers

In this section, we will provide an initial list of tasks that have been identified as engineering tasks. You can use this list as a starting point and then add your own tasks based on what works for your specific requirements. Each component that is added to the SOC architecture will have its own task requirements—for example, if you integrate a cloud access security broker (CASB) solution, you will need to carry out similar tasks within that platform to ensure it is well maintained and sending the appropriate information to Microsoft Sentinel.

Daily tasks

A list of daily tasks for SOC engineers is as follows:

  • Monitor the data connectors for two key performance indicators:

    A. Ensure the data ingestion is consistent with the expected volume; if the volume drops below the average daily rate it could be caused by a configuration error on the source, preventing the data from being sent to Microsoft Sentinel. This should be investigated immediately to ensure no loss of security log data.

    B. Ensure the total ingestion per day does not exceed the expected ingestion rates. There may be multiple reasons for an increased ingestion rate on a single day, such as a spike in the volume of threats or an increase in business activity, such as higher sales or increased remote work. However, if the volume continues to increase day by day, there will be an impact on the expected budget for the costs, and this will need to be reviewed with the management teams.

    There is a workbook available to assist with this monitoring: https://docs.microsoft.com/en-us/azure/sentinel/monitor-data-connector-health.

  • Monitor the service health of all core components:

    Monitor the service health of all core components, for example, the Azure platform, Azure AD for Identity and Access Management (IAM), and any data collection servers (syslog), ensuring dashboards are available and alerts are triggering as expected.

  • Review the planned maintenance, service health, and availability monitoring of the Microsoft Azure platform:

    Do this using the following resources:

    A. Publicly viewable information: https://status.azure.com/en-us/status

    B. Signing in to your Azure portal and viewing specific details: https://portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade/serviceIssues

Weekly tasks

A list of weekly tasks for SOC engineers is as follows:

  • Review the data connectors to ensure each connector that is enabled is still functioning correctly. Check for any new or preview connectors, as well as updates to existing connectors. If a new connector can be used instead of a custom connector (or a syslog server), plan to replace this as soon as possible to benefit from the new capability and reduce the reliance on customizations and server-based solutions.
  • Review the Workbooks page and the News & Guides page for new workbook templates, connector announcements, and any new updates. Ensure that existing workbooks are functioning correctly after the updates.

Monthly tasks

A list of monthly tasks for SOC engineers is as follows:

  • Review the trends for data ingestion to carry out projected cost analysis; adjust the pricing tier to reflect the most cost-effective option (see the Service pricing for Microsoft Sentinel section in Chapter 1, Getting Started with Microsoft Sentinel, for more details).
  • Validate the quality of the logs ingested and carry out noise-reduction tuning, especially after the introduction of new data sources.
  • Validate the current retention period set for each data type and confirm it is suitable for investigation requirements and budgeting guidelines.
  • Carry out a scenario-mapping exercise with the SOC analysts to identify additional detection and response requirements (see the Scenario mapping section in Chapter 1, Getting Started with Microsoft Sentinel, for more details). Transfer this knowledge to key stakeholders across the business and technology teams.
  • Review the roles and access permissions granted, ensuring minimum permissions are assigned and only active team members retain roles as required.

Ad hoc tasks

A list of ad hoc tasks for SOC engineers is as follows:

  • Review any changes made to the IT infrastructure; look for opportunities to integrate additional log data to gain key insights and configure automated responses based on attack scenarios.
  • Review any new data resources that may be suitable to assist in threat hunting scenarios.
  • Review announcements from Microsoft via their website, blogs, technical community, or events (such as Microsoft Ignite and Microsoft Build) for potential changes to the Microsoft Sentinel platform or changes to any integrated services and solutions. If you have non-Microsoft solutions deployed, also check the appropriate announcements for supported product updates.
  • Update the Microsoft Sentinel architecture documentation to reflect any changes made.
  • Engage with external services that offer advanced security practices to further test and train your SOC capabilities, including penetration testing, social engineering, and defining advanced SOC activities.

Operational tasks for SOC analysts

In this section, we will provide an initial list of tasks that have been identified as operational requirements for SOC analysts. These tasks focus on the work required to create, maintain, and organize Microsoft Sentinel components to ensure operational efficiency.

Daily tasks

A list of daily tasks for SOC analysts is as follows:

  • Check the Incidents page to ensure any new incidents are assigned to an owner and all open or in-progress incidents are actively investigated to completion.
  • Go to the Hunting page and select Run all queries:

    A. Review the results for each query that returns at least one result.

    B. If any queries return a result of N/A, then investigate why the results are not available (you should at least receive a return of 0 as a result).

  • Review TI sources for current activities and new findings and apply any findings to your threat hunting procedures.

Weekly tasks

A list of weekly tasks for SOC analysts is as follows:

  • Go to the Hunting page and review all bookmarks that have been created, ensuring they are still associated with an active incident. Aim to keep this list short by deleting those that are no longer relevant.
  • Review TI feeds to ensure they are still active; look for any recommended new TI feeds relevant to your specific industry and region.
  • Review all existing analytics queries; check those that are disabled and decide whether they should be removed or enabled. For all active queries, review the following:

    A. When possible, each analytic rule should be associated with an appropriate automated task to ensure notifications are sent, a case is raised in the ticketing system, or other runbooks are triggered to carry out remediation activities.

    B. Work with SOC engineers to implement any changes to further automate detection and response capabilities.

    C. Review tuning metrics to ensure analytic rules are not overly suppressed, which may cause important events to be missed. These metrics are as follows: rule period and frequency, rule threshold, and suppression.

Monthly tasks

A list of monthly tasks for SOC analysts is as follows:

  • Carry out a scenario-mapping exercise with SOC engineers to identify additional detection and response requirements (see the Scenario mapping section in Chapter 1, Getting Started with Microsoft Sentinel, for more details). Transfer this knowledge to key stakeholders across the business and technology teams.
  • Review all Microsoft Sentinel workbooks to ensure they are relevant and run correctly (execute them using test cases).
  • Review the tag taxonomy. A good resource for more details on resource tagging can be found here: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/resource-tagging/.

Ad hoc tasks

A list of ad hoc tasks for SOC analysts is as follows:

  • Check the naming conventions that are being used for various components that are created manually. Keeping strict governance over naming conventions and other standards ensures easier communication across the team when handing over incidents for review.
  • Engage with external services that offer advanced security practices to further test and train your SOC capabilities, including penetration testing, social engineering, and purple team activities.

Summary

While this is one of the shorter chapters in this book, it has covered the importance of the ongoing maintenance that will ensure SOC teams remain vigilant with respect to ongoing changes in the threat landscape and will also keep Microsoft Sentinel tuned for efficient and effective security operations.

In the final chapter of this book, we will introduce some resources you can use to continue gaining the knowledge required to implement and operate Microsoft Sentinel and its related solutions.

Questions

Review the following questions to test your knowledge of this subject:

  1. What are the two main types of roles within an SOC?
  2. Which role carries out the scenario-mapping exercise?
  3. How frequently should you check the log ingestion rate and pricing tier?
  4. How often should an SOC analyst check the Incidents page?
  5. If you, as an SOC engineer, are told that a new project using an Azure SQL instance is just starting, when should you start ingesting its logs?
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.238.195.81