Who Watches the SOC Team? Enabling Audit/Risk Teams to Monitor the SOC
Published May 25 2021 04:11 PM 7,366 Views
Microsoft

Big thanks to my colleagues @Sarah_Young and @Jeremy Tan for helping me with this post.

 

This blog is going to be discussing methods to monitor the actions of the SOC team from a risk and auditing standpoint. There is a need in the field for monitoring actions performed by the SOC engineers in an environment. Currently, the Log Analytics workspace saves queries performed by users within the environment. As an auditor or risk assessment user, the queries performed for reporting should not be seen by the SOC team and need to be masked or hidden. Log Analytics does not allow for that type of functionality.

 

However, as a work-around solution, cross-workspace queries can be used to run reports and queries on the actions that the SOC team is performing. The overall solution is going to rely on a separate workspace that is used by the audit/risk team that resides within an isolated resource group that only they have access to. Additionally, workbooks can be used within the resource group in order to have a monitoring dashboard for the team.

 

Matt_Lowe_0-1621956202145.png

Provide SOC Workspace Access to the Audit Team:

The audit team will need reader access to the workspace that the SOC team that is using. This will allow them to run queries without issue. To assign the permissions, follow these steps:

  1. Navigate to the resource group that the SOC team is using for Microsoft Sentinel.
  2. Find the Log Analytics workspace that the SOC team is using for Microsoft Sentinel and go into the resource.
  3. Go to IAM.
  4. Click “Add” > "Add role assignment".

Matt_Lowe_0-1621014357385.png

  1. Grant the Log Analytics Reader permission to either each engineer or the group that the engineers that are part of the audit/risk team.
  2. Click “Assign”.

Deploy a New Resource Group for the Audit Team:

  1. Navigate to the subscription for the environment and go into resource groups.
  2. Click “Add”.
  3. Give the resource group a name that will indicate what it is being used for.

Matt_Lowe_0-1621288087567.png

  1. Set the location.
  2. Click “Create”.
  3. Assign the engineers Log Analytics Contributor permissions on this resource group by repeating the process from above.

Deploy a New Workspace for the Audit Team:

  1. Navigate to Log Analytics workspaces.
  2. Click “New”.
  3. Give the workspace a name that indicates what the workspace is being used for.

Matt_Lowe_2-1621289042042.png

  1. Select a location.
  2. Leave the pay-as-you-go tier in place.
  3. Add any tags if needed.
  4. Click “Create”.

Deploy Workbooks in the Resource Group for the Audit Group:

Without Microsoft Sentinel deployed, it will be tougher to deploy Workbooks of interest as the gallery will not be as easily available. Despite this, it is still possible by following these steps:

  1. Go to the Microsoft Sentinel GitHub repository.
  2. Go to Workbooks.
  3. Based on the names or previews of the workbooks, choose which ones that are of interest to the audit team.
  4. Go into the JSON file for the workbook.
  5. In the top right of the code area, click “Raw” and copy the JSON.

Matt_Lowe_3-1621014357489.png

  1. Within the Azure Portal, go to Azure Monitor.
  2. Go to Workbooks and click new.
  3. Click “edit” and go to the Advanced Editor.

Matt_Lowe_4-1621014357502.png

  1. Paste the copied JSON from GitHub.
  2. Click “Apply”.
  3. The workbook will populate with the configuration that has been pasted.

There are many valuable workbooks that can be deployed. For auditing purposes, these workbooks are recommended:

  • Azure Activity
  • Security Operations Efficiency
  • Azure AD Sign-in Activity
  • Workspace Auditing
  • Zero Trust (TIC 3.0)
  • And more.

Running the Audit Queries:

Now that all of the resources have been deployed in the new audit/risk resource group, it is time to construct and run the queries that will be used for auditing and monitoring. This will be done by utilizing cross-workspace queries. An example of what that would look like from within the Watchers workspace would be:

 

workspace('TARGETWORKSPACENAME').SecurityEvent

| where EventID == 4624

| summarize count() by Account

 

The list goes on with queries that can be run but just to show some samples of what can be done:

 

User Logging in Outside Work Hours

workspace(‘TARGETWORKSPACENAME’).SigninLogs

where TimeGenerated !between(datetime(08:00:00).. datetime(18:00:00))

or dayofweek(TimeGenerated) == time(0.00:00:00) or dayofweek(TimeGenerated) == time(6.00:00:00)

| summarize count() by UserPrincipalName

 

workspace(‘TARGETWORKSPACENAME’).SecurityEvent

| where TimeGenerated !between(datetime(08:00:00).. datetime(18:00:00))

or dayofweek(TimeGenerated) == time(0.00:00:00) or dayofweek(TimeGenerated) == time(6.00:00:00)

| summarize count() by Account

 

Azure Create/Delete Actions by Users

workspace(‘TARGETWORKSPACENAME’).AzureActivity

| where has 'create' or OperationNameValue has 'delete'

| where ActivityStatusValue has 'succeeded' or ActivityStatusValue has 'failed'

| summarize count() by Caller, OperationNameValue, ActivityStatusValue

 

//Just looking at the SOC team

workspace(‘TARGETWORKSPACENAME’).AzureActivity

| where has 'create' or OperationNameValue has 'delete'

| where ActivityStatusValue has 'succeeded' or ActivityStatusValue has 'failed'

join _GetWatchlist(‘SOC’) on $left.Caller == $right.Caller 

| summarize count() by Caller, OperationNameValue, ActivityStatusValue

 

Audit That Users are Consistently Updating Passwords

workspace(‘TARGETWORKSPACENAME’).AuditLogs

| where TimeGenerated >= ago(90d)

| where OperationName has 'change user password'

| extend Caller = todynamic(InitiatedBy.user)

| extend Account = Caller.userPrincipalName

| summarize count() by tostring(Account), OperationName

| where count_ < 2

 

//Just looking for the SOC team

workspace(‘TARGETWORKSPACENAME’).AuditLogs

| where TimeGenerated >= ago(90d) 

| where OperationName has 'change user password' 

| extend Caller = todynamic(InitiatedBy.user) 

| extend Account = tostring(Caller.userPrincipalName) 

join _GetWatchlist(‘SOC’) on $left.Account == $right.Account 

summarize count() by Account, OperationName 

| where count_ < 2 

 

For more information on cross-workspace queries, please refer to: Query across resources with Azure Monitor - Azure Monitor | Microsoft Docs

 

Despite the Watchers workspace not having any information, the query will still run as if there was data. This allows for the data within the other workspace to be referenced. The real value here is that the query will not be visible to the SOC team.

 

With this concept, monitoring and auditing actions of the SOC team can be done without leaving a paper trail. This opens a door into different scenarios where this will be useful such as insider threat monitoring, zero trust, compliance tracking, SOC engineer monitoring, and more. Go ahead and begin watching the SOC team today!

Co-Authors
Version history
Last update:
‎Nov 02 2021 08:12 AM
Updated by: