Many built-in data connectors are available to connect external sources to Microsoft Sentinel as well.Įxternal security products can monitor your environment and create alerts and incidents for investigation. Of course, not everything is Microsoft, and most organizations will use other security products and tools to cover certain items that Microsoft solutions might not cover. For those customers, they should look into bringing in their mail gateway/EDR and other security logs into Microsoft Sentinel. When working with a Microsoft E3 license, the default logs won’t suffice as this does not have the necessary security features. The set of standard logs creates a great starting point to discover Sentinel while still having decent coverage of your environment. This Microsoft article confirms that most of these connectors listed above are free to ingest. By starting with the Microsoft Cloud logs, we can gain a large amount of visibility for a limited price. Most organizations I work with have standardized on the Microsoft 365 E5 Security stack, which provides a ton of visibility on the on-premises and cloud resources. When choosing the first set, I always work my way down the following list: It allows the SOC to identify which detection gaps they might identify in their environment and helps you prioritize the next set of data connectors.It allows the organization to understand the product with a set of common data, and they can learn how to use Sentinel based on that information.When I onboard a new customer onto Sentinel, I always start small and enable a set of basic data connectors first. For these data types, you can use the archive tier, covered here.Ĭybersecurity Risk Management for Active Directoryĭiscover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions. You can uphold those requirements using a unified platform by sending that data to Sentinel. Some organizations are required to save data for x number of months/years. The last reason – compliance- might not be immediately apparent, but it’s there to cover legal requirements you might have as an organization. By ingesting the logs from your Web Application Firewall, you can create reports showcasing the activity on your web services and what geographic locations are the most active. This data is also used for active alerting, but it’s a great example of a data source that allows for nice visualizations. One example could be logs from a Web Application Firewall. Through KQL queries, we can create interactive reports allowing you to present the data stored in the SIEM in a more user-friendly way. Sentinel includes a feature called ‘Workbooks’ that supports the creation of visualizations from data stored in Log Analytics. Basic logs are much cheaper to ingest, with the downside that they can’t be used for active alerting. These logs can be ingested as basic logs to save on ingestion and retention costs. Using zScaler, you can retrieve the full URL of an HTTP request with all parameters, compared to only the domain name from Microsoft Defender for Endpoint. zScaler logs can be ingested to augment the existing data for an investigation. All my incidents are created based on data from Microsoft Defender for Endpoint, but this data sometimes lacks essential details. A great example is network logs from your proxy, a product such as zScaler. Some common data types are sign-in and process events from endpoints.Įnvironments might have data sources that don’t hold value for alerts and incidents but can be used to investigate incidents and alerts. After ingesting the data, we can create analytic rules to create alerts and incidents, and the security team can investigate the incidents. For me, four reasons exist to send data into Sentinel:Īctive alerting is the most common reason to send data to Sentinel. Reasons to Add Data to Sentinelīefore you add a data source to Sentinel, consider its use case and understand why it’s important to have the data in Sentinel. ![]() Instead, think about what data is valuable, how you can improve efficiency, and keep costs down. This does not mean you can’t add the necessary data. Using a cloud mindset is essential when migrating to Sentinel. Although it is technically feasible to ingest data from multiple sources into Sentinel, monthly bills will increase rapidly, and the cost of Sentinel will be horrendous. Billing for Sentinel is cloud-based, so costs are based on how much data Sentinel receives and stores. While this approach might work well with other SIEMs, this isn’t true for Sentinel. A common mistake when migrating from an on-premises SIEM to Sentinel is to enable every data connector to ingest as much data into Sentinel as possible, including applications logs, firewalls, and NetFlow logs from switches.
0 Comments
Leave a Reply. |