Enabling Microsoft Sentinel After a Large Security Breach

Oxford Computer Group helped a higher education customer remedy their deployment of Microsoft Defender for Cloud (previously Azure Security Center) and Microsoft Sentinel after they were part of a large global security breach.

Like most education institutions in 2020, a large Midwestern public university’s students and staff were learning and working remotely, resulting in hundreds of logons to multiple applications by the minute. Then, the university was part of a large global security breach.

The customer urgently needed a Security Information and Event Management (SIEM) solution, which is a software solution that aggregates and analyzes activity from many different resources across the entire IT infrastructure. The large volume of log-ons increased the university’s need for true log correlation and machine learning. They also needed technical assistance to help them architect a solution that met their data governance requirements.

Challenge

Before the security breach, the university was looking to purchase Microsoft Defender for Cloud and migrate their Splunk SIEM to Microsoft Sentinel. But the global security breach sped up their timeline and they quickly purchased and deployed Defender, deployed Log Analytics agents, enabled Microsoft Sentinel, and enabled Data Connectors.

  • New Log Analytics workspace was created (Workspace A) and hundreds of Log Analytics agents were deployed to all on-premises servers from Defender.
  • Another new Log Analytics workspace was created (Workspace B), and Log Analytics agents were deployed to Active Directory Domain Controllers and Active Directory Federated Services (ADFS) servers from Microsoft Sentinel in a separate subscription. Microsoft Sentinel Data Connectors were connected on Workspace B.

The quick deployment was initiated without a detailed data governance plan and created issues with architecture and log ingestion. Oxford Computer Group was engaged to review the university’s Microsoft Sentinel setup and give recommendations and guidance.

After their initial deployment the university needed help with several issues, including:

  • The university was not able to see servers or logs from either the Microsoft Sentinel dashboard or queries and was having to manually query Workspace A.
  • Data retention was set differently on each workspace.
  • Data ingestion concerns:
    • Customer was seeing greater than 200 GB ingestion daily on Workspace B and over 50 GB daily on Workspace A.
    • Workspace A subscription is set to Pay-as-you-go and Workspace B subscription is set to 100 GB day/Capacity Reservation.
    • Customer would like to set a cap on their data ingestion to reduce costs.
    • Syslog logs were causing higher than desired billable ingestion that was not benefiting from Defender 500 MB per Node discounts.

Solution

During workspace architecture reviews OCG gained a complete view of the university’s Sentinel deployment and recommended several key remediation strategies. Actions included:

  • The university’s Firewall syslogs were the largest syslog ingestion on Workspace B, and they were able to lower ingestion by using Syslog Log Analytic Agent configurations and modifying Firewall settings. This helped eliminate key data ingestion concerns and started a data governance discovery process that examined what logs are truly necessary.
  • Log Analytic agent configuration settings had to be set to match both workspaces.
  • In order to see the full benefits of Sentinel Machine Learning and AI, the university needed to get all logs and data connectors in a single workspace instead of the two. This would result in much easier event queries.
  • Enable custom alerting by reconfiguring custom Playbooks
  • CEF Log Forwarders that were pointing to Workspace B agents required the Linux Log Analytics Agent to be uninstalled and reinstalled pointing to Workspace A, the CEF and Syslog Sentinel connectors needed to be enabled on Workspace A allowing the Firewall logs to begin populating.
  • Remove caps on data ingestion. Ingestion caps can lead to log loss and missing log correlation during security breaches when log ingestion is at its peak. Instead, fine tuning logs to collect only data that is essential and increasing their reservation capacity would reduce their ingestion costs.
  • Set Workspace B to cold storage. When the data governance policy is determined, have it ingested into Workspace A.

Microsoft sales was able to recommend pricing tiers based on the ingestion we were seeing at the time of engagement in order to help the university reduce subscription costs.

Benefits and Outcomes

After recommendations and advice from Oxford Computer Group and Microsoft, the university was able to revise deployment errors and reduce unnecessary subscription billing.

Some of the benefits the university has seen include:

  • The university can now can see their logs within a single workspace
  • Sentinel and Defender dashboards provide a single pane view
  • They are able to use built-in alerts and orchestration
  • Their re-directed custom playbooks now function properly
  • Decreased subscription costs by adjusting ingestion settings and subscription types

Next Steps

The university continues to configure and fine tune their logs and data connectors and are on the path to a complete Sentinel deployment.

The university is in the process of building a data governance plan that includes retention policies, understanding their data uses and logging needs, and understanding who needs access to what data. Their ability to monitor their alerts, use built-in queries, and build queries via Sentinel and Security Center will ultimately help in their data governance discoveries.

Key Learnings

Having a strong data governance policy that includes a full understanding of infrastructure, logging, and access needs should be included at the planning stage of any SIEM deployment. Having an IT Infrastructure Library (ITIL) structure that includes regular Change Requests and Approvals will enable a full picture of current and future projects and workloads.

Prior to a SIEM deployment, organizations need a strong foundation in place so their IT teams can work together to help eliminate deployment errors and reduce billable ingestion concerns from the beginning.