04-17-2020 05:36 AM
04-17-2020 05:36 AM
I'm in the process of setting up Sentinel with a number of log sources being sent via CEF. It appears that all the logs will go into the CommonSecurityEvents table which I need to separate out. Ideally I'd like to maintain a single Log Analytics workspace and have separate tables for each source (VPN/Firewall,WebGW etc) so I can grant each team access to the tables they need to query.
Is there a way to have the CEF events from a specific on-prem collector write to a specific table? Or is there a better to be separating out these log sources in the same workspace?
04-20-2020 04:10 AM
@Ofer_Shezaf thanks for this, I'd rather not deploy LogStash if I don't have to, the only reason for separate table would be if I couldn't split the logs in any other way, but it looks like resource RBAC might work for us.
Based on what I've read from you link, I'd need a separate collector VM for each access boundary. For example if both the firewall and web proxy logs will only be accessed by the Network team then I'll send them via the same Collector VM.
Is there a way to set the resource ID on an on-prem collector without using Azure Arc? I'd like to get up and running with this and while Arc maybe a long term solution for us if I can test without it that would be great.
04-20-2020 04:42 AM
04-21-2020 07:56 AM
@Ofer_Shezaf Thanks for this, I'm just sorting out Arc now. My plan currently is:
1) Install Arc on Collector1 and grant the NetOps group Log Analytics Reader access to the resource in Azure.
2) Push logs via syslog to Collector1
3) SecOps will be able to query logs via Sentinel along with everything else
4) NetOps will be able to query logs sent by Collector1 using Azure Monitor, but won't see anything else. For example if we created Collector2 for a different team.
With regards to the access would you grant the access directly on the resource or do you think it's better to have a separate resource group for the team so they can add Workbooks they want to create?
04-24-2020 02:55 AM
@Ofer_Shezaf thanks for this, I've decided we should definitely use Resource Groups otherwise I think we are going to end up with a mess to sort out later.
I've created a resource group for this and added the Collector VM to it and granted my test user Log Analytics Reader and Workbook Contributor to the groups.
Now I have what I hope is a really simple issue to resolve. If I use my test user and go to Azure Arc I can see and search logs for that device. However if I go to Monitor with the same account it prompts me to select a scope, but I can't see anything under the subscription. (I would have thought I would see the resource group and the collector VM under that). Am I just missing a permissions somewhere or have I misunderstood how this will all work?
Thanks in advance.
04-26-2020 02:18 PM
@SimonR : Reading your post, I think you are doing thing right and I am not sure why you can't find your VM in the scope selector. Might be worth a support ticket. If they don't help, I can try to have you work with the Azure Arc PM team - this is a new technology and maybe there are some corner cases to understand.
04-26-2020 05:02 PM
@SimonR Do you also have the standard Log Analytics agent installed on the on prem VM, or just Azure Arc for servers?
"This agent does not deliver any other functionality, and it doesn't replace the Azure Log Analytics agent. The Log Analytics agent for Windows and Linux is required when you want to proactively monitor the OS and workloads running on the machine, manage it using Automation runbooks or solutions like Update Management, or use other Azure services like Azure Security Center."
04-27-2020 04:01 AM
@Sonia Cuff I have both the LA agent and the Arc agent installed on both a Windows and Linux box. I've created resource groups to control access to the logs for these servers. When I try and select a scope in Monitor the resource groups do not appear in the selection list, although others do. Each resource group currently only contains the server with the LA and ARC agents on and my (possibly incorrect) assumption what that would allow me to create a boundary for access to the logs each VM is forwarding rather than have everything exposed to the user.