Log Analytics design considerations with Azure Sentinel & Azure Security Center

[David Caddick]

Based on this from @Yuri Diogenes what we're trying to do is understand the best way of implmenting Log Analytics to support both functions in the best way possible & ensuring we don't limit the functionality of either - https://techcommunity.microsoft.com/t5/Security-Identity/Integrating-Azure-Security-Center-with-Azur...

With Regards to Azure Sentinel & ASC:

• We know they are two different products for two different areas of focus – no probs
  What we are doing is getting this working for another customer as well...
• IF ASC has it's own Workspace then ALL ASC content/logs goes here and ONLY the Alerts (not the full logs) will be forwarded to Sentinel
• I think we can all agree this is not ideal - Sentinel will be missing the full context of the ASC feed...?
• The reason for clarifying this is that there almost seems to be some form of "Automated" control that means as you enable a Workspace for ASC that it seems to "break" any existing workspace from Seintinel and enforce it's own connection... It certainly seems to be an area that's not very clear?

Should we be considering any of the following:

• Do we potentially look at Multi-homing the agents?
  https://docs.microsoft.com/en-us/azure/security-center/security-center-planning-and-operations-guide...
  
• What is the best practices way of approaching this?
  https://docs.microsoft.com/en-us/azure/security-center/security-center-faq#how-can-i-use-my-existing...
• 

• Use existing Log Analytics...?
  https://docs.microsoft.com/en-us/azure/security-center/security-center-faq#should-i-opt-out-of-the-a...
  
• Quote: 

If you want to avoid creation of multiple workspaces per subscription and you have your own custom workspace within the subscription, then you have two options:

1. You can opt out of automatic provisioning. After migration, set the default workspace settings as described in How can I use my existing Log Analytics workspace?
2. Or, you can allow the migration to complete, the Microsoft Monitoring Agent to be installed on the VMs, and the VMs connected to the created workspace. Then, select your own custom workspace by setting the default workspace setting with opting in to reconfiguring the already installed agents. For more information, see How can I use my existing Log Analytics workspace?

I hope this makes sense?

[#2 · Accepted solution]

@David Caddick 

David,

This topic comes down to preference on the log ingestion you're wanting into Azure Sentinel, you're using your security services to provide alerts and auditing. Azure Sentinel then can connects the alerts and events together showing you a story(Cases) of how the event occurred providing filtered/relevant information. With that information, to eliminate noise or wanting to your own custom alerts to be triggered by joined data, we have the analytics within Azure Sentinel to setup a query to pull specific information that can be put into an playbook for automation. 

To round back on a the question, if i'm wanting all event data within Azure Sentinel and Azure Security Center - Yes it can be ingested into the same workspace. You can have both raw events and alerts within the same workspace. With that being said you can share the same workspace or multi-home the agents.

Another thing missed often is we can query multiple workspaces as long as the user has access to each workspace. Example: https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/cross-workspace-query#identifying-wor... 

If you're sharing the workspace, lets use Azure Security Center as an example, i'd advise setting up your own workspace compared to the default ASC workspace. After the configured workspace, enable Auto-provisioning of the MMA agents. The agents will be pointed to the ASC configured workspace (Example: "WorkSpaceTest"). 

Setting up Azure Sentinel, configure to use the same workspace "WorkSpaceTest", you'll now be getting the MMA collection of events and ASC Security Alerts within the same workspace as Azure Sentinel.

Hope this helped answer your question,

[#3]

@Chris Boehm @David Caddick :

My own take would be to use a single workspace. Not being an ASC expert, I might be missing some advantage to the multiple workspaces, however multi-homing to dual workspaces incurs additional cost. So I would not multi-home unless there is a clear need.

Note that you don't have to opt out of automatic provisioning. The quoted text is somewhat misleading in this respect. You actually set the workspace used for automatic provisioning to an existing rather than automatically created one. The screenshot clarifies that ("automatic provisioning" is on, and"use another workspace" is selected)

[#4]

Thanks @Chris Boehm & @Ofer_Shezaf,

That definately helps, and I guess the ultimate answer (like always) is it depends on what you are trying to achieve & in relation to your existing environment. For now we'll work thru this and see how we go.

I'll be up in Singapore for the RSA conference &catching up with MS folks the day before on a number of topics so will discuss this and the other foundational aspects of the MCRA (ATP's, MCAS, etc...) while up there - thanks for the replies, hopefully this info helps others with the design choices as well?

Dave C

[#5]

Be aware of multi-homing approach with Linux. This is not actually supported. I think there is a big confused on where the log should be flew to when we have both Azure Security Center and Azure Sentinel.

[#6]

best response now...  see link below

https://techcommunity.microsoft.com/t5/Azure-Sentinel/Best-practices-for-designing-an-Azure-Sentinel...

[#7]

@Chris Boehm Don’t forget that Sentinel can not be deployed on the ASC default workspaces. So you have to create your own.