decision tree draft 1

Author: batamig

articles/sentinel/design-your-workspace-architecture.md

@@ -0,0 +1,138 @@
+---
+title: Design your Azure Sentinel workspace architecture | Microsoft Docs
+description: Use a decision tree to understand how you might want to design your Azure Sentinel workspace architecture.
+services: sentinel
+author: batamig
+ms.author: bagol
+ms.service: azure-sentinel
+ms.subservice: azure-sentinel
+ms.topic: conceptual
+ms.date: 07/13/2021
+---
+
+# Design your Azure Sentinel workspace architecture
+
+This article provides a decision tree to help you make key decisions about how to design your Azure Sentinel workspace architecture. For more information, see [Azure Sentinel workspace architecture best practices](workspace-architecture-best-practices.md).
+
+## Prerequisites
+
+Before working through the decision tree, make sure you have the following information:
+
+|Prerequisite  |  |
+|---------|---------|
+|**Regulatory requirements related to Azure data residency**     |  Azure Sentinel can run on workspaces in most, but not all regions [supported in GA for Log Analytics](https://azure.microsoft.com/global-infrastructure/services/?products=monitor). Newly supported Log Analytics regions may take some time to onboard the Azure Sentinel service. <br><br> Data generated by Azure Sentinel, such as incidents, bookmarks, and analytics rules, may contain some customer data sourced from the customer's Log Analytics workspaces.<br><br> For more information, see [Geographical availability and data residency](quickstart-onboard.md#geographical-availability-and-data-residency).|
+|**Data sources**     |   Find out which [data sources](connect-data-sources.md) you need to connect, including built-in connectors to both Microsoft and non-Microsoft solutions. You can also use Common Event Format (CEF), Syslog or REST-API to connect your data sources with Azure Sentinel. <br><br>If you have Azure VMs in multiple Azure locations that you need to collect the logs from and the saving on data egress cost is important to you, you need to calculate the data egress cost using [Bandwidth pricing calculator](https://azure.microsoft.com/en-us/pricing/details/bandwidth/#overview) for each Azure location.      |
+|**User roles and data access levels/permissions**     |    Azure Sentinel uses [Azure role-based access control (Azure RBAC)](/azure/role-based-access-control/role-assignments-portal) to provide [built-in roles](/azure/role-based-access-control/built-in-roles) that can be assigned to users, groups, and services in Azure. <br><br>All Azure Sentinel built-in roles grant read access to the data in your Azure Sentinel workspace. Therefore, you need to find out whether there is a need to control data access per data source or row-level as that will impact the workspace design decision. For more information, see [Custom roles and advanced Azure RBAC](roles.md#custom-roles-and-advanced-azure-rbac).     |
+|**Daily ingestion rate**     |  The daily ingestion rate,usually in GB/day, is one of the key factors in cost management and planning considerations and workspace design for Azure Sentinel. <br><br>In most cloud and hybrid environments, networking devices, such as firewalls or proxies,and Windows and Linux servers produce the most ingested data. To obtain the most accurate results, Microsoft recommends an exhaustive inventory of data sources. <br><br>Alternatively, the Azure Sentinel [cost calculator](https://cloudpartners.transform.microsoft.com/download?assetname=assets%2FAzure_Sentinel_Calculator.xlsx&download=1) includes tables useful in estimating footprints of data sources. <br><br>**Important**: These estimates are a starting point, and log verbosity settings and workload will produce variances. We recommend that you monitor your system regularly to track any changes. Regular monitoring is recommended based on your scenario. <br><br>For more information, see [Manage usage and costs with Azure Monitor Logs](/azure/azure-monitor/logs/manage-cost-storage).       |
+|     |         |
+
+## Decision tree
+
+The following image shows a full decision tree flow chart to help you understand how to best design your workspace.
+
+[ ![Azure Sentinel workspace design decision tree.](media/best-practices/workspace-decision-tree.png) ](media/best-practices/workspace-decision-tree.png#lightbox)
+
+The following sections provide a full-text version of this decision tree.
+
+### Step 1: New or existing workspace?
+
+Are you planning to enable Azure Sentinel on an existing workspace? 
+
+- **If you'll be creating a new workspace**, continue directly with [step 2](#step-2-keeping-data-in-different-azure-geographies).
+
+- **If you'll be using an existing workspace**, and will be consuming more than 100 GB/day of non-SOC data, we do *not* recommend using an existing workspace for Azure Sentinel for the sake of cost efficiency.
+
+    If the amount of non-SOC data you'll be ingesting is less than 100 GB/day, continue evaluating with [step 2](#step-2-keeping-data-in-different-azure-geographies), but consider you selection in step 6 when this question arises again.
+
+### Step 2: Keeping data in different Azure geographies?
+
+Do you have regulatory requirements to keep data in different Azure geographies?
+
+If so, use a separate Azure Sentinel workspace for each Azure region that has compliance requirements.
+
+For more information, see [Region considerations](workspace-architecture-best-practices.md#region-considerations).
+
+### Step 3: Do you have multiple Azure tenants?
+
+- **If you have only a single tenant**, continue directly with step 4.
+
+- **If you have multiple Azure tenants**, consider whether you're collecting logs that are specific to a tenant boundary, such as Office 365 or Microsoft 365 Defender.
+
+    If not, continue directly with step 5. However, if you're collecting logs that are specific to a tenant boundary, use a separate Azure Sentinel tenant for each Azure AD tenant.
+
+    <a name="ref1"></a>Logs specific to tenant boundaries, such as from Office 365 and Microsoft Defender, can only be stored in the workspace within the same tenant. Although you could use a custom connector to collect tenant-specific logs from a workspace in another tenant, doing so would have the following disadvantages:
+
+    - Data collected by custom connectors will be ingested into custom tables, and therefore can’t leverage all the built-in rules and workbooks.
+    - Custom tables are not supported by some of the built-in features, such as UEBA and machine learning rules.
+    - Additional cost and effort required for the custom connectors, such as using Azure Functions and Logic Apps.
+
+    If any of these disadvantages are not a concern for your organization, continue with step 4. 
+
+### Step 4:
+
+### Decision tree notes
+
+
+Decision Tree References:
+1.	Logs specific to tenant boundaries, such as Office 365 and Microsoft Defender, can only be stored in the workspace within the same tenant.
+
+Although it is possible to collect tenant specific logs from a workspace in another tenant using custom connectors, it is not recommended due to the following disadvantages:
+
+•	Data collected by custom connectors will be ingested into custom tables and therefore can’t leverage all the OOTB rules and Workbooks.
+•	Custom tables are not considered by some of the built-in features, such as UEBA and machine learning rules.
+•	Additional cost and effort required for the custom connectors (e.g., using Azure Functions and Logic Apps).
+
+If the above points are not a major concern, proceed to step 4 of the decision tree.
+
+2.	Refer to this article for ways to analyze data ingestion and costs.
+
+3.	In general, we recommend that customers have a separate workspace for their non-SOC data so that non-SOC data will not be subject to Azure Sentinel costs.
+However, there can be scenarios in which combining both SOC and non-SOC data is cheaper than separating them. Assume we have Security logs ingesting at 50GB per day, Operations logs ingesting at 50GB per day, and a workspace in the East US region:
+Use case 1:
+SOC team has a workspace with Azure Sentinel enabled and the Ops team has a separate workspace without Azure Sentinel enabled.
+SOC team:
+•	Azure Sentinel cost for 50GB/day is $6,438.50 per month.
+•	First three months of retention are free.
+Ops team:
+•	Cost of Log Analytics at 50GB/day is around $3,553.50 per month.
+•	First 31 days of retention are free.
+The total cost for both equals $9,992 per month.
+
+Use case 2:
+Both SOC and Ops teams share the same workspace with Azure Sentinel enabled.
+By combining both logs, ingestion will be 100GB per day, qualifying for eligibility for Commitment Tier (55% for Sentinel and 15% for LA).
+SOC and Ops team:
+•	Cost of Azure Sentinel for 100GB/day equals $8,880 per month.
+
+In the above example, there is a cost savings of $1,112 per month by combining both workspaces, and the Ops team will also enjoy 3 months of free retention instead of only 31 days. Note that this is only applicable when each SOC and non-SOC data has an ingestion size of >=50GB/day and <100GB/day.
+Note that the above example considers the scenario purely from a cost perspective and, to clearly illustrate potential cost savings, ignores other key design factors that are usually examined to determine whether to use a single or multiple separate workspaces. Kindly go through the remaining steps in the decision tree to determine a complete recommendation.
+
+4.	Data egress refers to the bandwidth cost for moving data out of Azure datacenters.
+
+5.	There are several ways to reduce egress costs. Calculate data egress cost with the Azure pricing calculator to estimate the cost and determine which region(s) you actually need. It is recommended to have as few workspaces as possible. Consider combining workspace(s) with low egress costs. Remember, bandwidth costs are usually only a small portion of the Azure bill compared with Azure Sentinel and Log Analytics ingestion costs.
+
+For example, 1,000 VMs each generating 1GB/day, sending data from US to EU, and accounting for a 2:1 compression ratio in the agent is estimated as follows:
+		1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost
+This is much cheaper when compared with Azure Sentinel + Log Analytics ingestion costs of ~$75,000/month
+
+6.	In order to use the Azure Sentinel portal, a user needs to have at least Azure Sentinel Reader role and the role must have reader permission on all the tables in the workspace. Therefore, it is not possible to segregate data unless access to the Azure Sentinel portal is not required (i.e., a user can still perform log search with Log Analytics).
+
+7.	There are a few options to configure resource-context RBAC for non-Azure resources. The task consists mainly of associating a Resource ID to the data when sending to Azure Sentinel so that the permission can be scoped using resource-context RBAC. 
+
+8.	Resource permissions or resource-context allows users to view logs for resources that they have access to. The workspace access mode must be set to “User resource or workspace permissions” and only tables relevant to the resources you have permission to will be visible when you perform a search in the Logs page.
+
+9.	Table level Azure RBAC allows you to define more granular control to data in a Log Analytics workspace, in addition to the other permissions. This control allows you to define specific data types that are accessible only to a specific set of users. Refer to this blog for a sample use case.
+
+10.	In general, it is not recommended to use the same workspace for both SOC and non-SOC data, so that non-SOC data won’t be subject to Azure Sentinel costs.  However, there can be scenarios in which combining both SOC and non-SOC data is cheaper than separating them. Refer to Reference 3 for a sample use case.
+However, this recommendation is made purely from a cost perspective and there are other key design factors that are customarily examined to determine whether to use a single or multiple separate workspaces. Kindly go through the remaining steps in the decision tree to determine a complete recommendation.
+In addition, to avoid double ingestion costs, consider collecting overlapped data on a single workspace only with Table level Azure RBAC .
+11.	It is not recommended to use the same workspace for non-SOC data because that data will be subject to Azure Sentinel costs. In addition, to avoid double ingestion costs, consider collecting overlapped data on a single workspace only with Table level Azure RBAC.
+
+
+## Next steps
+
+For more information, see:
+
+- [Pre-deployment activities and prerequisites for deploying Azure Sentinel](sample-workspace-designs.md)
+- [Azure Sentinel workspace architecture best practices](workspace-architecture-best-practices.md)
+- [Best practices for Azure Sentinel](best-practices.md)

articles/sentinel/media/best-practices/workspace-decision-tree.png

@@ -148,6 +148,7 @@ When collecting using the [Log Analytics data collector API](../azure-monitor/lo
 If you are using resource-context RBAC and want the events collected by API to be available to specific users, use the resource ID of the resource group you [created for your users](#explicitly-configure-resource-context-rbac).
 
 
+
 ## Next steps
 
 For more information, see [Permissions in Azure Sentinel](roles.md).

articles/sentinel/media/resource-context-rbac/resource-context-rbac-sample.png

@@ -21,7 +21,7 @@ When planning your Azure Sentinel workspace deployment, you must also design you
 
 For more information, see [Sample workspace designs](sample-workspace-designs.md) for common scenarios, and [Pre-deployment activities and prerequisites for deploying Azure Sentinel](prerequisites.md).
 
-## Tenancy and workspace considerations
+## Tenancy considerations
 
 While fewer workspaces are simpler to manage, you may have specific needs for multiple tenants and workspaces. For example, many organizations have a cloud environment that contains multiple [Azure Active Directory (Azure AD) tenants](/azure/active-directory/develop/quickstart-create-new-tenant), resulting from mergers and acquisitions or due to identity separation requirements.
 
@@ -98,95 +98,83 @@ To start validating your compliance, assess your data sources, and how and where
 > If you are sending data to a geography or region that is different from your Azure Sentinel workspace, regardless of whether or not the sending resource resides in Azure, consider using a workspace in the same geography or region.
 >
 
-## Technical considerations when creating your workspace
+## Region considerations
 
-Use the following best practice guidance when creating the Log Analytics workspace you'll use for Azure Sentinel:
+Use separate Azure Sentinel instances for each region. While Azure Sentinel can be used in multiple regions, you may have requirements to separate data by team, region, or site, or regulations and controls that make multi-region models impossible or more complex than needed. Using separate instances and workspaces for each region helps to avoid bandwidth / egress costs for moving data across regions.
 
-- **When naming your workspace**, include *Azure Sentinel* or some other indicator in the name, so that it's easily identified among your other workspaces.
+Consider the following when working with multiple regions:
 
-- **Use the same workspace for both Azure Sentinel and Azure Security Center**, so that all logs collected by Azure Security Center can also be ingested and used by Azure Sentinel. The default workspace created by Azure Security Center will not appear as an available workspace for Azure Sentinel.
+- Egress costs generally apply when the [Log Analytics or Azure Monitor agent](connect-windows-security-events.md) is required to collect logs, such as on virtual machines.
 
-- **Use a dedicated workspace cluster if your projected data ingestion is around or more than 1 TB per day**. A [dedicated cluster](/azure/azure-monitor/logs/logs-dedicated-clusters) enables you to secure resources for your Azure Sentinel data, which enables better query performance for large data sets. Dedicated clusters also provide the option for more encryption and control of your organization's keys.
+- Internet egress is also charged, which may not affect you unless you export data outside your Log Analytics workspace. For example, you may incur internet egress charges if you export your Log Analytics data to an on-premises server.
 
+- Bandwidth costs vary depending on the source and destination region and collection method. For more information, see:
 
+    - [Bandwidth pricing](https://azure.microsoft.com/en-us/pricing/details/bandwidth/)
+    - [Data transfers charges using Log Analytics ](/azure/azure-monitor/logs/manage-cost-storage).
 
+- Use templates for your analytics rules, custom queries, workbooks, and other resources to make your deployments more efficient. Deploy the templates instead of manually deploying each resource in each region.
 
-### Working with multiple regions
+For example, if you decide to collect logs from Virtual Machines in East US and send them to an Azure Sentinel workspace in West US, you'll be charged ingress costs for the data transfer. Since the Log Analytics agent compresses the data in transit, the size charged for the bandwidth may be lower than the size of the logs in Azure Sentinel.
 
-If you need to send data from an Azure resource that resides in a different region that your Azure Sentinel workspace, you'll need to consider bandwidth costs incurred for data moving in and out of Azure datacenters, or between datacenters.
+If you're collecting Syslog and CEF logs from multiple sources around the world, you may want to set up a Syslog collector in the same region as your Azure Sentinel workspace to avoid bandwidth costs, provided that compliance is not a concern.
 
-While transferring data into Azure (ingress) doesn't incur costs, transferring data from (egress) an Azure datacenter to another datacenter does incur bandwidth costs.
+Understanding whether bandwidth costs justify separate Azure Sentinel workspaces depend on the volume of data you need to transfer between regions. Use the [Azure Pricing Calculator](https://azure.microsoft.com/en-us/pricing/details/bandwidth/) to estimate your costs.
 
-Consider the following when working with multiple regions:
+For more information, see [Data residency in Azure](https://azure.microsoft.com/en-us/global-infrastructure/data-residency/).
 
-- Egress costs generally apply when the [Log Analytics or Azure Monitor agent](connect-windows-security-events.md) is required to collect logs, such as on virtual machines.
+<!--	-	There are no bandwidth costs when the logs are collected using Diagnostics settings, like Azure AD, Azure Activity, Azure SQL, or Azure Firewall as stated here. At the time of writing this article, where bandwidth costs apply, the first 5GB/month are free. Summary of Connectors-->
 
-- Internet egress is also charged, which may not affect you unless you export data outside your Log Analytics workspace. For example, you may incur internet egress charges if you export your Log Analytics data to an on-premises server.
+## Access considerations
 
-- Bandwidth costs vary depending on the source and destination region and collection method. For more information, see:
+You may have situations planned where different teams will need access to the same data. For example, your SOC team must have access to all Azure Sentinel data, while operations and applications teams will need access to only specific parts. Independent security teams may also need to access Azure Sentinel features, but with varying sets of data.
 
-    - [Bandwidth pricing](https://azure.microsoft.com/en-us/pricing/details/bandwidth/)
-    - [Data transfers charges using Log Analytics ](/azure/azure-monitor/logs/manage-cost-storage).
+Combine [resource-context RBAC](resource-context-rbac.md) and [table-level RBAC](/azure/azure-monitor/logs/manage-access#table-level-azure-rbac) to provide your teams with a wide range of access options that should support most use cases.
+
+### Resource-context RBAC
+
+The following image shows a simplified version of a workspace architecture where security and operations teams need access to different sets of data, and resource-context RBAC is used to provide the required permissions.
+
+:::image type="content" source="media/resource-context-rbac/resource-context-rbac-sample.png" alt-text="Sample architecture for resource-context RBAC.":::
+
+In this image, the Azure Sentinel workspace is placed in a separate subscription to better isolate permissions.
+
+> [!NOTE]
+> Another option would be to place Azure Sentinel under a separate management group that's dedicated to security, which would ensure that only minimal permission assignments are inherited. Within the security team, several groups are assigned permissions according to their functions. Because these teams have access to the entire workspace, they'll have access to the full Azure Sentinel experience, restricted only by the Azure Sentinel roles they're assigned. For more information, see [Permissions in Azure Sentinel](roles.md).
+>
+
+In addition to the security subscription, a separate subscription is used for the applications teams to host their workloads. The applications teams are granted access to their respective resource groups, where they can manage their resources. This separate subscription and resource-context RBAC allows these teams to view logs generated by any resources they have access to, even when the logs are stored in an workspace where they *don't* have direct access. The applications teams can access their logs via the **Logs** area of the Azure portal, to show logs for a specific resource, or via Azure Monitor, to show all of the logs they can access at the same time.
+
+Azure resources have built-in support for resource-context RBAC, but may require additional fine-tuning when working with non-Azure resources. For more information, see [Explicitly configure resource-context RBAC](resource-context-rbac.md#explicitly-configure-resource-context-rbac).
+
+### Table-level RBAC
+
+Table-level RBAC enables you to define specific data types (tables) to be accessible only to a specified set of users.
+
+For example, consider if the organization whose architecture is described in the image above must also grant access to Office 365 logs to an internal audit team. In this case, they might use table-level RBAC to grant the audit team with access to the entire **OfficeActivity** table, without granting permissions to any other table.
+
+### Access considerations with multiple workspaces
+
+If you have different entities, subsidiaries, or geographies within your organization, each with their own security teams that need access to Azure Sentinel, use separate workspaces for each entity or subsidiary. Implement the separate workspaces within a single Azure AD tenant, or across multiple tenants using Azure Lighthouse. 
+
+Your central SOC team may also use an additional, optional Azure Sentinel workspace to manage centralized artifacts such as analytics rules or workbooks.
+
+For more information, see [Working with multiple workspaces](#working-with-multiple-workspaces).
+
+## Technical best practices for creating your workspace
+
+Use the following best practice guidance when creating the Log Analytics workspace you'll use for Azure Sentinel:
+
+- **When naming your workspace**, include *Azure Sentinel* or some other indicator in the name, so that it's easily identified among your other workspaces.
+
+- **Use the same workspace for both Azure Sentinel and Azure Security Center**, so that all logs collected by Azure Security Center can also be ingested and used by Azure Sentinel. The default workspace created by Azure Security Center will not appear as an available workspace for Azure Sentinel.
+
+- **Use a dedicated workspace cluster if your projected data ingestion is around or more than 1 TB per day**. A [dedicated cluster](/azure/azure-monitor/logs/logs-dedicated-clusters) enables you to secure resources for your Azure Sentinel data, which enables better query performance for large data sets. Dedicated clusters also provide the option for more encryption and control of your organization's keys.
 
-<!--	-	There are no bandwidth costs when the logs are collected using Diagnostics settings, like Azure AD, Azure Activity, Azure SQL, or Azure Firewall as stated here. At the time of writing this article, where bandwidth costs apply, the first 5GB/month are free.-->
-
-
-This effectively means that, if you decide to collect logs from Virtual Machines in one region (e.g., East US) and send them to an Azure Sentinel workspace in a different region (West US), you will be charged ingress costs for the data transfer. Keep in mind that the Log Analytics agent compresses the data in transit, so the size charged for bandwidth will be somewhat lower than the size of the logs in Azure Sentinel.
-
-Also, if you are collecting Syslog and CEF logs from multiple sources around the world, you could setup a Syslog collector in the same region as your Azure Sentinel workspace to avoid bandwidth costs, provided that compliance is not a concern.
-
-Whether bandwidth costs justify creating a separate Azure Sentinel workspace or not will depend on the volume of data you transfer between regions. We recommend using the Azure Pricing Calculator to estimate these costs. Here are a couple of examples:
-
--	Transferring a total of 1TB of data per month from East US to West US would cost $20.38, whereas transferring 1TB of data per month from East US to West Europe would cost $50.95.
--	Transferring a total 50TB of data per month would cost $1,023.90 and $2,559.75, respectively.
-As you can see, creating a separate workspace could make sense in cases of very large volumes of data. 
-
-Summary of Connectors
-Connectors where Bandwidth costs apply when the source is in a different region from the Azure Sentinel Workspace:
-•	Windows Security Events (for Azure Windows VMs)
-•	CEF (Azure Linux VM)
-•	Syslog (Azure Linux VM)
-•	DNS
-•	Windows Event Forwarding
-•	Windows Firewall
-•	3rd party connectors based on a Syslog or CEF collector VM located on Azure*
-•	Any other potential connector that relies on the Log Analytics agent or Azure Monitor agent
-Connectors where Bandwidth costs do not apply:
-•	Azure Active Directory
-•	Azure Active Directory Identity Protection
-•	Azure Activity
-•	Azure DDoS Protection
-•	Azure Defender
-•	Azure Defender for IoT
-•	Azure Firewall
-•	Azure Information Protection
-•	Azure Key Vault
-•	Azure Kubernetes Service (AKS)
-•	Azure SQL Databases
-•	Azure Storage Account
-•	Azure Web Application Firewall (WAF)
-•	Dynamics 365
-•	Microsoft 365 Defender, as well as Microsoft Defender for Endpoint, Microsoft Defender for Identity, Microsoft Defender for Office 365
-•	Microsoft Cloud App Security
-•	Microsoft Threat Intelligence
-•	Office 365
-•	Threat Intelligence TAXII (unless you connect a TAXII server located in Azure)
-•	Threat Intelligence Platforms 
-•	3rd party connectors based on API connections, or based on a Syslog or CEF on-premises collector 
-•	Any other potential connector that relies on Azure Monitor Diagnostics settings
-*Create your Azure collector VMs in the same region as the Azure Sentinel workspace
-
-
-
-If you are deploying Azure Sentinel in multiple regions, consider the following best practice recommendations:
 
-- Use templates for your analytics rules, custom queries, workbooks, and other resources to make your deployments more efficient. Deploy the templates instead of manually deploying each resource in each region.
 
-- Use separate Azure Sentinel instances for each region. While Azure Sentinel can be used in multiple regions, you may have requirements to separate data by team, region, or site, or regulations and controls that make multi-region models impossible or more complex than needed.
 
-    Using separate instances and workspaces for each region helps to avoid bandwidth / egress costs for moving data across regions.
 
-For more information, see [Data residency in Azure](https://azure.microsoft.com/en-us/global-infrastructure/data-residency/).
 
 
 <!-- make sure this info is in roles>