Forum Discussion
Sentinel How to Questions
Hi everybody
Totally new in Sentinel and read several docs. Nevertheless, a few questions are not totally clear. That's why I decided to summarize all my questions in one messageand hope there are some answers.
1. Is it ok to use the same workspace for Azure Security Center and Sentinel or are they any considerations to pay attention to?
2. What is actually the benefit of having the ASC Workbook in Sentinel except the visual dashboard? I mean, it cannot really replace the handling of alerts and recommendations within the actual ASC interface?
3. Are there any best practices or examples of how parallely work with 3rd party SIEM solutions and Azure Sentinel and profit ?
4. Here they say "You'll only be able to investigate the incident if you used the entity mapping fields when you set up your analytic rule. The investigation graph requires that your original incident includes entities."
Does that mean that e.g. all that Microsoft Security rule types or fusion rules cannot be investigated in "Investigation graph" and only scheduled ones can? Isn't that gap?
5. How to get the Sentinel workbooks to the Dashboard? When I pin a workbook i only see a white box with the workbook's name, the workspace name and a blue icon on the dashboard.
6. What i did not get is the workflow. Is investigation something that happen in combination with threat response, or before threat response??
And about threat response: Is it true that the only thing i can do for respond to threats is to have pre-defined playbooks which i have to run manually or let automatically be triggered? Is there no option for ad-hoc response?
7. When i have investigated an incident and go to remediate - Where is the difference when i remediate with a üre-defined playbook and when I go and look within Azure Security Center to remediate in order to prevent from future similar alerts?
Many thanks in advance
GlavniArhivator Answers inline...
1. Is it ok to use the same workspace for Azure Security Center and Sentinel or are they any considerations to pay attention to?
--Yes. That way you have access to all the data you need.
2. What is actually the benefit of having the ASC Workbook in Sentinel except the visual dashboard? I mean, it cannot really replace the handling of alerts and recommendations within the actual ASC interface?
---That is correct. It is only used a visual report although it can show some issues that need to be investigated.
3. Are there any best practices or examples of how parallely work with 3rd party SIEM solutions and Azure Sentinel and profit ?---Yes, there are various Azure Sentinel blog posts that discuss it: https://techcommunity.microsoft.com/t5/azure-sentinel/bg-p/AzureSentinelBlog
4. -ERR:REF-NOT-FOUND-Here they say "You'll only be able to investigate the incident if you used the entity mapping fields when you set up your analytic rule. The investigation graph requires that your original incident includes entities."
Does that mean that e.g. all that Microsoft Security rule types or fusion rules cannot be investigated in "Investigation graph" and only scheduled ones can? Isn't that gap?
---That is not correct. They automatically populate as many of the entities as they can.
5. How to get the Sentinel workbooks to the Dashboard? When I pin a workbook i only see a white box with the workbook's name, the workspace name and a blue icon on the dashboard.
---In that example you need to click on the box to see the workbook. You can also pin individual parts of the workbook and those should show up in the dashboard.
6. What i did not get is the workflow. Is investigation something that happen in combination with threat response, or before threat response??
And about threat response: Is it true that the only thing i can do for respond to threats is to have pre-defined playbooks which i have to run manually or let automatically be triggered? Is there no option for ad-hoc response?--Investigations and Threat hunting are two different entities. Investigations are done on incidents that were created from a rule. Threat hunting is more of looking for issues that are not covered by the analytic rules. Mind you this is only a basic description as the differences could be a book unto itself. 😉
7. When i have investigated an incident and go to remediate - Where is the difference when i remediate with a üre-defined playbook and when I go and look within Azure Security Center to remediate in order to prevent from future similar alerts?
---If you have an incident that is created from a different Azure security product it is best to use the creating product to do the investigation. Sadly, there is no connection between the Azure Sentinel incident and the one created in the product (so if you close the one in Azure Sentinel you still need to close the one in the other product). The main purpose of having the alerts/incidents show up in Azure Sentinel is to have a single pane of glass view.
Thank you for you answers. I have some follow-up questions to some of them.
To Q1: So it is recommended to take the same workspace for both ASC and Sentinel?
To Q4: Maybe i asked in a wrong way. I mean, Microsoft security rules and Fusion rules e.g. (when i want to add them from templates) have no entities shown there. Does that mean that they cant be investigated within investigation graph? Whats the alternative?
To Q7: So that means if i have the same Security Alert in ASC which was feeded into Sentinel, and if i remediate/investigate/respond and then close it in Sentinel, i have to close it also in Security Alert (or vice versa) and there are no recognition that it is the same alert?
So is that correct that the co-working of Sentinel and ASC is less a technical thing but more organizational, so that if I have an investigation of an incident I use ASC separately but as a successor step after investigatnig in Sentinel to maybe prevent for future threats by remediating the recommendations? Or is that not correct?
Best regards,
To Q1: So it is recommended to take the same workspace for both ASC and Sentinel?
---According to the best practices document (link below), it is recommended to have as few workspaces as possible. As mentioned before, it will be charged like any other data coming into Azure Sentinel so there is always going to be a trade-off between the amount of data being ingested and the cost of said data. https://techcommunity.microsoft.com/t5/azure-sentinel/best-practices-for-designing-an-azure-sentinel-or-azure-security/ba-p/832574#:~:text=Best%20practices%20for%20designing%20an%20Azure%20Sentinel%20or,Consider%20%E2%80%9CTable%20Level%E2%80%9D%20retention.%20...%20More%20items...%20
To Q4: Maybe i asked in a wrong way. I mean, Microsoft security rules and Fusion rules e.g. (when i want to add them from templates) have no entities shown there. Does that mean that they cant be investigated within investigation graph? Whats the alternative?
---No, the rules will create the Entities themselves. You will not see the entities or be able to select them since you do not actually see the query like you do with scheduled analytic rules. I personally have a bunch of incidents from MCAS that I can perform investigations on.
To Q7: So that means if i have the same Security Alert in ASC which was feeded into Sentinel, and if i remediate/investigate/respond and then close it in Sentinel, i have to close it also in Security Alert (or vice versa) and there are no recognition that it is the same alert?
---That is correct as it stands right now. Hopefully this will change in the future.
So is that correct that the co-working of Sentinel and ASC is less a technical thing but more organizational, so that if I have an investigation of an incident I use ASC separately but as a successor step after investigatnig in Sentinel to maybe prevent for future threats by remediating the recommendations? Or is that not correct?
---Not quite sure what you mean here. It is true that even though you see an ASC incident in Azure Sentinel, you will most like perform the investigation in ASC since it is setup to investigate its own alerts. You may also need to run queries against data in Azure Sentinel that ASC may not have access to.
Hope this helps.
