How to avoid security blind spots when logging and monitoring

Cybersecurity involves a balancing act between risk aversion and risk tolerance. Going too far to either extreme may increase cost and complexity, or worse: cause the inevitable business and compliance consequences of a successful cyberattack. The decisions that need to be made around logging and monitoring are no exception.

Capturing all data from every device on the network can create bottlenecks, overwhelm log management, and obfuscate signs of network penetration, or malicious activity. Not capturing all the critical log data can result in monitoring that fails to identify attacks before they do damage or assist in forensics after the incident.

Getting logging and monitoring right is so important that it is listed among the Center for Internet Security’s critical security controls.

Failing to log creates blind spots

Failing to activate logging creates security blind spots in your network that will only become apparent after the fact (i.e., when an attack is successful). Every component of your extended infrastructure — on premises and remote — should be configured to generate appropriate audit events. These components include operating systems, system utilities, servers, workstations, networking equipment, and security systems (which include anti-malware, firewalls, intrusion detection and prevention systems, and VPNs).

This applies whether you run your own security information and event management (SIEM) solution for log management or use a managed SIEM with SOC-as-a-Service for 24/7 monitoring, alerting, and reporting. The SIEM relies on log data feeds to provide protection. It can’t see alerts on what’s not being logged. Responsibility for making devices and apps visible often falls outside of the security organization.

For example, failure to activate logging can happen if there is a “set it and forget it” mindset. The reality is that networks are always changing. New endpoint devices are continually being added and removed due to personnel changes, addition of new locations, flexible work programs that let employees work from home, new mobility solutions, and the like.

Assuming that new apps and devices — including new cloud infrastructure — come with logging set to “on” is another way organizations can fail to send data to the SIEM. “Always check logging settings” should be standard procedure across the IT organization. A third possibility is failing to understand that logs from an IoT device — in one real example, the badge reader on the entrance to the server room — should be monitored.

Establish a log management and monitoring policy

The best way to avoid logging and monitoring failure — as well as failure to capture the right data — is a log management and monitoring policy, and a culture of policy awareness and adherence. The challenge is determining what log data to capture and monitor with a SIEM, and properly store for auditing purposes.

Compliance mandates such as PCI DSS initially drove those decisions. US federal legislation and regulatory requirements such as HIPAA and FISMA also come into play. While compliance and audit reporting remain table stakes, today’s SIEM solutions have an increased focus on threat detection and forensics.

It takes a blend of art, science, and experience to determine what should be codified in an organization’s logging policy. You want to take risk appetite, security relevance, and volume into consideration while finding the balance for logging. This means just enough to satisfy your organization’s specific use case and not so much that you’re bogged down in data.

The good news is you don’t have to start from scratch. For one thing, many network device manufacturers, software vendors, and cloud providers offer suggestions of what event data should be logged for their product or service. You can also get guidance from industry-standard frameworks like NIST SP800-92, MITRE ATT&CK, or the Open Web Application Security Project (OWASP).

The key takeaway is that you should be making an informed decision about event data from every network component. The list below is a starting point of events to consider:

• Successful and unsuccessful authentication and access control events
• Account management activities, such as account creation, modification, and deletion
• Session activities
• Starting and stopping processes
• Changes in authorization, user privileges, and configurations
• Devices and software added or removed
• Access, modifications, downloads, and deletion of critical data sets
• Alerts from security systems, including firewalls, IDS/IDP, and anti-malware

For forensic purposes, every log entry should contain at least an actor (username, IP address), an action, a timestamp, and a location (geolocation, browser, code script name).

Proper log management is key for protection and compliance

Also consider how your log files are managed. If you handle personal health or identity information (PHI/PII), consider anonymizing that data to prevent sensitive information from being stored in plain text. You also want to ensure that log files cannot be tampered with. Cyber criminals often change log files to disguise their malicious activities. Encryption at rest and in motion, along with log integrity checks and least-privilege access, can protect log data. To prevent data loss, make sure you back up log data frequently so it will be available for a compliance audit or any needed forensic investigations.

Depending on the regulations or mandates that apply to your business, you will need to store logs for a specified length of time. For example, PCI DSS requires that logs are stored for at least one year, with three months available on demand. The remaining months can reside in long-term storage such as tape stored offsite.

Monitoring considerations: A well-tuned SIEM with a skilled SOC

Log monitoring systems, typically SIEM solutions, oversee network activity, analyze system events, and issue alerts when anomalous behavior is detected. They are optimized for different use cases and one size never fits all. The wrong selection can have a long-lasting impact, be costly to maintain and support, and time-consuming to tune, which is why many SIEM deployments end up abandoned.

Organizations need a well-tuned SIEM to provide the foundational visibility into events in the network environment. Automation produces significant efficiencies when applied to the massive amounts of data that must be correlated and filtered to uncover cyber threats. With automation and artificial intelligence, the SIEM surfaces only those artifacts that need to be further reviewed by a security analyst to determine if the event is a false positive or an actual security event. Threat intelligence then provides context specific to your organization’s goals and risk posture. A SIEM should also provide reporting to meet compliance requirements.

It is often unrealistic for most small-to-medium-sized businesses (SMBs) to hire, train, and retain in-house security operations staff and implement the state-of-the-art threat intelligence. For example, in our experience, it takes a minimum of eight to 10 analysts to provide around-the-clock monitoring coverage. Attempting to implement DIY cybersecurity can result in underutilized security software that becomes shelfware and leads to gaping vulnerabilities. For these organizations, a managed SIEM with SOC-as-a-Service for 24/7 monitoring, event analysis, threat intelligence, and log management can be a viable option to speed time to detect security threats and improve resilience.