Security Information & Event Management (SIEM) systems provide an organisation with visibility in to the activity that is taking place on their network in a central location. A SIEM system collects and aggregates events that are generated by devices that are connected to a network (laptops, desktops, servers, mobile devices, network equipment etc) and performs analysis against a set of known behaviours to detect malicious activity.
Whether an organisation chooses to install and maintain their own SIEM or entrust a Managed Security Service Provider (MSSP) to deliver the SIEM as a service depends mostly on the maturity of the organisations security program. The ability to “teach” the SIEM to spot malicious activity requires an enormous amount of time and effort to achieve even a basic level of detection.
A SIEM system is designed to support the collection, indexing (sorting) and pattern matching of events generated by network connected devices. The majority of SIEM vendors provide built-in content packs (a collection of known behavioural patterns) to aid the user in getting a basic level of detection capability deployed as quickly as possible, but some of these content packs can be far too generic. To draw as much value from a SIEM as required by most organisations, custom content must be created that is more closely aligned to their network, user base and business processes.
In this blog post, we will discover the common phases of deploying detection logic (also known as “Use Case”, “Signature” and “Correlation Logic”. These phases are used by the DigitalXRAID SIEM experts to ensure that client organisations are protected using bleeding edge detection logic that is effective, timely and efficient.
Stage 1 – Scoping
The scoping phase is conducted to gather information regarding the type of activity that should be detected. The trigger for the creation of a new detection rule could be after a security incident, risk assessment or based on a new attack type that has been discovered in the wild. For this stage to be effective, the following information must be gathered:
- What do you wish to detect.?
- What technology has the capability of detecting this activity?
- Does the logging device create an event for this type of activity?
Stage 2 – Detection Rule Design
The design phase is conducted by a highly-skilled employee that is experienced with SIEM products, detection logic and common attack techniques. During this phase, the SIEM expert will design the detection rule from the ground up, creating content that teaches the SIEM how to detect this specific pattern of activity based on known-bad artefacts (indicators).
Stage 3 – Detection Rule Testing
Once the detection rule has been created, the SIEM expert will conduct extensive testing to ensure that the rule is accurate and would not suffer from a high false-positive rate when deployed on a real-world SIEM deployment. Testing can be conducted either in a sandbox environment, where the expert can simulate the conditions required to trigger the rule or the logic can be deployed to a live environment in a TEST state.
Stage 4 – Detection Rule Deployed to Production
The detection rule is ready for deployment in the real world so that Security Analysts can begin to triage, respond and remediate attacks that match the newly introduced detection rule. The client can now benefit from the increased level of protective monitoring.
Stage 5 – Enrichment / Tuning
So not to let the detection rule go stale over time, the SIEM experts will frequently review, enrich and tune the detection rule to ensure that it is as effective as possible. It is very common for detection rules to trigger on benign (non-malicious) activities that are part of normal business operations, the tuning of detection rules reduces false-positive rate and subsequently allows the Security Analysts to focus on more pressing matters.
Example Detection Rules
|High Number of Failed Authentication Attempts||This detection logic is a very common way of detecting password guessing or brute force attacks against user credentials.|
|Cloud Storage Detection||This detection logic is a common way of detecting the unauthorised use of cloud storage services by users. Many organisations employ a policy to restrict the use of these type of services in an effort to reduce the chances of data-loss or theft of intellectual property.|
|Logon From Suspicious Location||This detection logic is designed to detect suspicious logon activity from regions or locations in which the organisation does not operate. This activity is commonly seen during theft of credentials and unauthorised access to an organisations network.|