Many organisations are focused on increasing their ability to detect and alert potential security incidents within their environment. This often means aggregating and analysing large volumes of log data in an attempt to identify important events.
Aggregating all log data to one place is often the preferred model to allow a centralised capability for insights and alerting. However, attempting to capture and ingest all event logs becomes a costly exercise for any organisation of any size. Almost all Security Event Monitoring (SIEM) vendors will structure their license model against data volumes ingested.
In this article, we'll examine the design principles that can help minimise those costs and strike a balance between 'what is needed' and 'what is nice to have'.
We won't look to address all of the challenges in capturing security event logs at scale but instead focus on the key principles that are adaptable for many organisations.
Here is a list of design principles when considering security event logging and monitoring
Begin with a specific set of metrics
This is a difficult one, but it's important to begin with a set of target metrics for what type of event logs you want to gather insights and alerts from.
Create a list to the main security threats to the organisation. What are the critical and sensitive assets that an attacker may focus on. How would they potentially attempt to gain access to those assets.
Equally, consider the threats to collecting and monitoring security events. These could include threats to disabling event logging, misconfiguration, or preventing the timely capture of event logs.
From that analysis, build a set of target metrics for the type of events you ideally want to gather. Don't make this an exhaustive exercise. Start with a target you can work against and prioritise what to collect.
Aimlessly collecting event logs and hoping to work out their value later on will quickly lead to expensive costs and little to show for them.
Focus on monitoring of existing security controls
This is the easiest one to start with. Use any existing security services enabled in the environment and the event logs generated natively from those products.
In particular, security services that focus on detecting security threats will provide a rich set of security event logs that are worth capturing.
Focus on any logs that provide predefined metrics or insights to specific security events. For example, cloud providers such as AWS and Azure, offer services such as Amazon GuardDuty and Microsoft Defender for Cloud to provide those insights.
Understand available logs from critical and sensitive assets
Evaluate what security event logs are available from various information assets and the underlying technology platforms or cloud providers.
Consider the constraints on streaming event logs or gaining programmatic access to that log data. SaaS providers, for example, are often limited to only providing access via a management portal or a point-in-time support request.
Capture event logs from identity and access management
Enabling single sign-on across your environment creates a centralised source of authentication and authorisation logs. These event logs won't be as context-rich as collecting them directly from that technology platform, but they will offer insights into access.
At a minimum, capture the event logs associated with identity and access management. If you've enabled single sign-on using Azure AD and/or Google, you can capture event logs directly from those providers.
Prioritise what event logs to capture and aggregate
Costs can quickly increase based on the ingress and egress of log data. Ensure you've understood what log sources are most important for capturing rather than attempting to collect everything.
It's key to prioritise the capture and aggregation of event logs based on the criticality and sensitivity of information assets. Don't spend time focussing on information assets that aren't as important or offer low value insights. If you're working within a regulated industry, then make sure you've also considered any requirements to capture specific events.
Keep in mind capturing all log data from all assets won’t be practical and in some cases, not possible (such as SaaS Providers).
Establish decoys within internal environments
Using decoys can be an effective technique to identify suspicious activity within your environment.
Consider the original threats used to determine the target metrics. The use of deceptive technologies helps identify those threats. If established correctly, they provide early detection of threats with (relatively) low rates of false positives.
Deploying deceptive technologies within your environment requires a separate set of considerations that aren't covered in this article. Spend time evaluating how decoys can increase visibility for potential attackers targeting critical and sensitive assets.
Build insights for security events across environments
The biggest challenge once collecting these event logs is extracting meaningful insights for the vast amounts of log data collected.
It is important to filter through the ‘noise’ of logs that don’t add value or false positive events. Map and analyse the event logs against the original baseline of metrics. Use this mapping to underpin the need for specific dashboards to provide insights.
Quickly archive logs that aren’t adding value or high rates of false positives. Evaluate whether low value event logs can be captured and archived, rather than having it ingested into SIEM. Archiving that log data into cloud object storage (and only retrieving it if needed) will be a lot cheaper than ingesting all of that data.
As a final note, ensure you consider the process and people surrounding this capability. There's no point in building insights if no one will examine them.
For those insights you build, consider how this will be continually maintained and tuned against the target metrics. Otherwise, you’ll build fatigue across operational teams by reviewing endless alerts, dashboards and reports (without a clear view of what they are looking for or measuring against).
Want to learn more ?
Reach out to us at Patterned Security Consulting to understand how we can help you build security architecture and design that matters.
Comments