Nearly all security experts agree that event log data gives you visibility into and documentation over threats facing your environment. Even knowing this, many security professionals don’t have the time to collect, manage, and correlate log data because they don’t have the right solution. The key to security log management is to collect the correct data so your security team can get better alerts to detect, investigate, and respond to threats faster.
WHY IMPLEMENT CENTRALIZED LOG MANAGEMENT?
Collecting the correct data only provides meaningful forensic insights when you can use that data purposefully. However, since a critical system can generate dozens of events per second, centralized log management can help reduce noise and make it easier to find the most important information.
ESTABLISH A SINGLE SOURCE OF DOCUMENTATION FOR BETTER CORRELATION
Bringing together all log data into a single source of documentation makes correlation between events faster.
For example, when researching a data security event, you need visibility into various activities and anomalies such as user ID, application, geolocation, and time of day. However, you also need to bring this information together meaningfully to correlate multiple data events, trace anomalies, and find the data security event source more rapidly.
As you add more cloud services, you increase the number of endpoints, making forensics across different vendor-supplied tools more time-consuming. Centralized log management gives you the scalability, speed, and flexibility you need to see and document activities happening in your virtual and physical infrastructure.
ENRICH DATA ACROSS DIVERGENT SOURCES
More data enables you to respond more rapidly only if you have the right “everything” in one place.
With centralized log management, you get the data enrichment you need for better security analytics. When starting, you should make sure that you’re at least collecting:
- Geolocation
- Threat intelligence
- User ID
- User access level
- Employment status
- Internal IP address
- External IP address
- Time
- Date
During threat hunting or a forensic investigation, you need to trace all events contributing to the data security event.
For example, if a service account with privileged access was the attack vector, you need to follow the right data. This means connecting a user ID to the time it usually accesses the IT environment and the location from which it typically accesses your stack. When you can identify the abnormal activity using centralized logging, your threat hunters can move directly into researching from one place to find the malicious backdoor actors used.
PROTECT LOG DATA TO ENSURE DATA INTEGRITY
Finally, centralized log management ensures that your valuable forensic data maintains its integrity. By moving the event log data into a centralized log management system, you protect the log data’s integrity. This keeps threat actors from changing information that can hide how they infiltrated your environment, like changing log time, deleting sections of the log, removing types of logs, or erasing all logs.
Several recent ransomware varieties target event logs to prevent detection and stymie the investigation. For example, WastedLocker ransomware uses the “wevutil.exe” utility and clears local security event log contents and disabling endpoint security software. To investigate an attack that includes this type of activity, you need to ensure that you have protected your event log data by moving it off the compromised endpoint.
Centralized log management solutions give you all the security analytics you need for detection while also making threat hunting and forensic research easier. They offer the same visibility into your environment that a security information and event management (SIEM) or Security Orchestration, Automation, and Response (SOAR) would but do it for a fraction of the cost.
HOW TO ASK THE QUESTIONS TO OPTIMIZE SECURITY LOG MANAGEMENT
To trace a data security event, you need to collect the right data. Too little data and you have no visibility. Too much data and you overload your system. To choose the right information, you should start by defining how you want to use the data and then derive the sources.
For example, some common use cases are Security, Operations, and DevOps. When determining the security use case, you want to consider your organization’s data security risk assessment and align collection with the systems and resources deemed high risk.
WHAT SYSTEMS WERE IMPACTED?
Before collecting data, you need to define your critical systems and locations. As a best practice, some suggestions include:
- Operating systems
- Database software
- Application software
- Intrusion Detection Systems/Intrusion Prevention Systems (IDS/IPS)
WHAT RESOURCES WERE IMPACTED?
Next, you need to think about the different types of resources your organization uses and how malicious actors can use them. As a best practice, some suggestions include:
- Network Devices
- Servers
- Workstations
- DNS
- Web proxies/gateways
- LDAP/Active Directory
DO WE HAVE THE LOGS WE NEED?
Once you determine the systems and sources from which you’re collecting data, you need to make sure that you have the right information in the logs. Some suggestions include:
- User ID
- Date
- Time
- Account Logon events
- Geolocation
- Account management
- Object Access
- Privilege use
- Policy change
- Process tracking
- System events
WERE THE LOGS TAMPERED WITH?
Since new ransomware varieties now tamper with or disable endpoint logging, you need to collect data to determine whether this has happened within your environment. To do this, you should think about collecting the following:
- Events that indicate audit logs were cleared or changed
- Events indicating a system restart
- Event Log Service crashes
- Privileged access use
WHEN DID THE BREACH START / HOW LONG HAS THIS BEEN GOING ON?
Most organizations struggle to trace when a malicious actor gained access to their ecosystem to gain insight into how long their IT stack has been compromised. Some of the primary user and endpoint logs that help determine the start date include:
- Successful login attempts
- Unsuccessful login attempts
- User credentials updated
- File scans
- Software compatibility
- Disc access
- Kernel drivers
- Live terminal sessions
- File quarantine
- Server message handling
GRAYLOG: SECURITY LOG MANAGEMENT DONE RIGHT
With Graylog, you can develop a set of repeatable processes for using the security log data effectively. Our solution collects, aggregates, normalizes, correlates, and analyzes the data you need. This way your security team can reduce mean time to detect (MTTD), mean time to investigate (MTTI), and mean time to remediate (MTTR). Using Graylog Extended Log Format (GELF), you can normalize your event logs to better correlate events across divergent technologies, ultimately getting the answers you need and want faster.
