Security logging and monitoring are critical security controls, but they can be effective only if you follow these six security logging best practices.
Continuous security logging and monitoring of security events are crucial to detecting and responding to any malicious cyberattack against your business. However, security logging and monitoring can be effective only when you follow some best practices. Otherwise, they can lull you into a false sense of security.
In this article, we’ll explore six security logging best practices that will help protect your business against cyberthreats. We’ve grouped the practices under four aspects of log management, in order of their importance.
Log Analysis and Log Monitoring
We’ll start with log analysis and log monitoring since they’re the most important tasks in security logging.
1. Use Security Automation Tools
Your security teams should be able to detect, analyze, and mitigate security incidents rapidly in real time. But trying to understand what’s happening by reading raw logs is nearly impossible, given the high rate and volume of incoming log data.
That’s why our top recommendation is to extensively use security automation tools like:
Security information and event management (SIEM)
Security orchestration, automation, and response (SOAR)
Extended detection and response (XDR)
Cloud security posture management
SIEM tools augment log events with security information from vulnerability and threat databases. They help your security analysts understand the significance of events, collect metrics to model a baseline security state, detect deviations from that baseline, and search logs.
However, SIEM tools are known to cause alert fatigue due to a large number of false alarms. SOAR tools can help by using automated response workflows. XDR tools reduce the number of false alarms and missed incidents by using pattern recognition. These tools do most of the raw log analysis and send notifications to let your security teams focus on troubleshooting and debugging the core security issues.
Governance refers to the security policies — business, organizational, and technical — that guide your company’s security decisions. Log governance refers to policies that guide your log management.
2. Implement Security Logging Based on Your Security Risks
Your security teams may feel tempted to log everything all the time. But that’s inefficient for two reasons: Too much log data makes analysis difficult and increases your expenses, since you need to ensure the security, availability, and storage capacity of all that data.
Instead, security guidelines like the cybersecurity framework from the National Institute of Standards and Technology (NIST) recommend that your logging policies be commensurate with the severity of security threats you face. Robust cyber risk management and regular security assessments help you understand the cyber risks your company is likely to experience and allow you to configure your logging policies accordingly.
For example, malware may not be a priority threat if you can keep endpoint devices (like employee smartphones) out of your network perimeter. If you’re involved in cutting-edge defense or biotechnology research, your biggest threats are probably insider theft, unauthorized access, and security breaches by hostile nations.
Your security log management and security monitoring policies — what to log, how often to collect data, and level of detection sensitivity — should differ for each threat. The policies should enable your security teams to provide robust and proportional incident responses.
Information security expects robust protection for all data stored on any type of media. Because security logs are also a type of data, follow these best practices for your log storage.
3. Ensure Information Security for Your Logs
Your security logs have information about your IT infrastructure that may be valuable to malicious parties. Keep in mind the following security concepts for storing your logs:
Integrity: Attackers or malicious insiders are likely to tamper with logs and hide their traces. Your log storage shouldn’t allow anybody to tamper with an event after it’s generated. This implies your raw security log files should be stored on read-only and tamper-proof disks, tapes, or infrequently accessed long-term cloud storage.
Confidentiality: Enforce authentication, permissions, roles, and access control to limit who can view or analyze security logs. The log analysis tasks themselves should produce an audit trail that tells you which log was opened, when, and by whom.
Availability: Ensure sufficient storage capacity and redundancy for your event log storage.
One more aspect of ensuring integrity is storing the raw logs in addition to the transformed logs. Most SIEM and automation tools transform raw log data into structured data in databases for querying. But that step is vulnerable to insider tampering. To reduce that risk, restrict the permissions for SIEM configuration and database modification to a small set of employees. However, if you are still concerned, make sure to retain your raw logs.
These information security precautions also help your company to comply with regulatory standards and reduce your legal liabilities.
4. Design Log Retention and Deletion Policies
Regulatory standards like the Health Insurance Portability and Accountability Act (HIPAA) and industry standards like the Payment Card Industry Data Security Standard (PCI DSS) have compliance requirements on retention periods for audit logs.
Other standards like the General Data Protection Regulation (GDPR) require the deletion of customer data that, in some cases, may also require the deletion of security logs.
Although log generation and collection are the first steps in security logging, these practices are more relevant to software vendors than to the average software customer. In situations where you have some control over these steps, follow these best practices:
5. Enable Security Logging on All Important Sources
Your governance and security assessments should guide you on which assets to enable logging for and what security events to log. You should include them as software requirements when evaluating your software vendors.
Typical log sources on which security logging should be enabled include:
System logs from operating systems like Windows and Linux
Servers, including database and web servers
Security software like firewalls and intrusion detection systems
Network devices like routers and load balancers
Workstations and endpoint devices (like employee laptops and smartphones)
Application logs from desktop, mobile, and web applications
Make sure that nobody can completely disable security logging on these sources.
Typical security events that should be logged include:
User session events like logon and logoff
Security configuration changes like permission modifications
System events like start and shutdown
Software-specific events like detected intrusions
Application-specific events like configuration changes
6. Design Your Log Formats and Event Details
Reluctance of software vendors to standardize security log formats leads to failures while processing some logs and possibly missing important event details.
Design your policies to use a single log format. Although no official standards exist, it might be a good idea to start by looking at some of the more popular formats, like Syslog, JSON, and XML.
Choose a simple text format over a binary format so that SIEM and other security tools can easily parse and extract all information from logs.
All log entries should contain the following details at a minimum:
Event timestamps are critical for correlating multiple events and inferring their association with a cyberattack. Ensure that all your assets and devices have their clocks synchronized (using network time protocol servers, for example).
IP addresses associated with any request or action should be included.
The user ID (the username or email address) associated with the user account that initiated a request or action should be documented.
The event category, severity, and any other attribute that’ll help a security analyst or tool to query efficiently should all be recorded.
Event-specific details as key-value pairs that are easy to parse will also prove useful.
At the same time, ensure that logs don’t contain sensitive information — like credit card numbers — unless necessary for security analysis.
How ThreatKey Supports Your Security Logging Best Practices
The security logging best practices above can help make sure that your security logging and monitoring will provide strong support for your business’ cybersecurity and risk management goals.
ThreatKey is a security automation SaaS that analyzes logs and configurations from the cloud and third-party services you use every day — Google Workspace, Microsoft 365, Slack, Box, GitHub, Salesforce, Zoom, and more — to find and fix security issues in real time.