Author: Steph Jones, Senior Cyber Security Specialist/Analyst Team Lead – SIEM, Jisc
Security Information and Event Management (SIEM) is one key tool of a wider set of controls that you should employ in seeking to protect and defend your organisation from cyber attack. These controls are sometimes referred to as Defence in Depth.
SIEM collects security logs and data from different systems: servers, end user devices, firewalls and network appliances, and applications, and aggregates and analyses it in order to identify anomalies or malicious activity.
SIEM can come in a variety of forms: on-premise or cloud-hosted, as a standalone platform which then requires the organisation to resource its deployment and operation, or increasingly as a managed/monitored service (sometimes part of a Security Operation Centre, or SOC). SIEM can be licensed in a number of pricing models including per device/per user, workload/processing activity, but most commonly is based upon ingestion (sometimes referred to as consumption) of the log data.
With that in mind, there are two classic starting points for implementing SIEM:
- Log everything – maximum visibility but cost of ingestion is usually prohibitive for this to be realistic.
- Log only what you need – there is a risk you might not catch everything, so prioritise what you are trying to protect/defend.
Unless the organisation has deep pockets, it is advisable to go with the latter. The following recommendations and questions may help you on your way.
- Identify and understand as much of your IT assets and identities/users as possible.
Do you know what systems you have and what they do in terms of your day-to-day operations?
Do you know how many domain admins or highly privileged accounts you have? How are these used day-to-day in your organisation and what controls might be around them?
- Take a risk-based approach
What systems would cause you the biggest impact/downtime to the business if they became unavailable because they were compromised? E.g. Active Directory, backup servers?
What systems could cause you the biggest impact reputationally/financially if they were breached? Student Systems? HR?
Where are you most vulnerable? Is it systems with no MFA which are externally facing? Is it that legacy system with lots of personal data stored in it that is difficult to patch? Is it unsupported operating systems on those you can’t upgrade/segment on your network?
- Consider which entry-points into your network/systems are exploitable
Externally facing web systems? Virtual Private Network? No Multi Factor Authentication?
Too high admin rights on servers and devices (if someone gets phished and gives away credentials, are they limited in what damage can be inflicted?)
Any vulnerable/unsupported operating systems you are struggling to decommission?
Although it varies from organisation to organisation, the most common systems and data sources that are usually brought into SIEM include:
- On-premise Active Directory
Often the most critical asset you will have is your directory services – monitor system and user authentication to spot changes to privileged users and groups, lateral movement using accounts, and brute forcing.
- On-prem backup systems
You want to ensure that backups are secure from breach if the worst happens so something to monitor – this will often include securing service accounts that run backups.
- On-prem key systems
These may include Student Information Systems, HR, Finance and Payroll which store personal/sensitive data.
Exchange and remote desktop services are regularly exploited/attacked. When moving to Microsoft 365, hybrid Exchange servers are often forgotten about.
Bring in as much of your remaining server estate as you can afford.
- Virtual Private Networks
VPNs are both an attack point if they are unpatched, but also a common entry point into your network so make sure you can identify who is using them and when.
- Firewalls
Firewalls should be approached very carefully – ingest is expensive and only a subset of data forwarded from them may be practical and of value. Prioritise Intrusion Detection/Prevention Systems (IDS/IPS), threat logs, and admin events such as changes to policies and rules.
Use SIEM to instigate further investigation using the native admin tools that your firewall provides – especially identifying perimeter or internal traffic activity.
- Endpoint Protection and Anti-malware
You may decide to use the native admin/alert/investigation tools in platforms such as Defender, Sophos or Crowdstrike, but bringing these into SIEM will strengthen your overall visibility of what is happening within your environment.
- AzureAD/Microsoft365
As systems move to Azure AD/ADFS for federated authentication (Single Sign-on, SSO) and Multi Factor Authentication (MFA), often in conjunction with migrating once on-premise systems to the cloud, user authentication shifts outside of your traditional on-premise Active Directory. You may decide to use the native admin tools provided to monitor and investigate AzureAD and Microsoft365 environments, but bringing these logs into SIEM will strengthen your overall visibility of what is happening between your on-premise and cloud infrastructure and its users.
The more relevant and useful security logs you bring into it a SIEM, the greater the potential benefit and the greater the opportunities for correlating events across your environment. This increases the likelihood of detecting and alerting regarding attempted or actual malicious activity and helps to identify the journey that attackers take when compromising systems and services.
Organisations considering implementing SIEM often ask about sizing and it can be difficult to provide a precise answer. If you currently utilise a SIEM platform, then reporting should provide some useful figures for both total ingestion per day/month and how this is broken down by data source and host. Sizing is usually calculated based upon Events Per Second (EPS), however, the size of events themselves vary between vendors and systems, so referring to vendor documentation and examining existing system logs will help to provide some rudimentary figures for both the size of events and the typical number of events that are being produced. SIEM platforms themselves also normalise and store logs in differing ways too, so look for any best practise guidance from the SIEM vendor or work with a partner to assess this in more detail.
For many starting out in SIEM, a practical approach is to bring in the identified key systems piece-by-piece, prioritising them by risk. Use the reporting in the SIEM platform to then understand better the number of events that each system is contributing and daily ingestion size. Filtering logs prior to/or at ingestion can help to ensure that key security events are retained whilst general events and ‘noise’ are dropped in order to save on ingestion, but this should be done with care. Refer to vendor recommendations to identify the minimum event types that are required to identify security activity – such as authentication, threat detection, user/group, and policy change events. Again, seek best practise guidance from the SIEM vendor or work with a partner to get this right.
Like many tools in cyber security, SIEM is neither easy nor a panacea – it has to be implemented as part of your broader security programme which will also likely include endpoint protection, access controls, vulnerability management, user education, and policies. SIEM is a journey and what you bring into it should be reviewed regularly to ensure it reflects your changing environment and its risks, and the constantly evolving nature of threats, so as to provide maximum value.