Nexum Insights
Q1 2024

Each quarter, the managed security team at Nexum shares insights from our first*defense® Security and Network Operations Command Centers (SNOCC). Nexum has been managing and monitoring the security environments of our customers since 2005. Therefore, we’re uniquely positioned to get an overall view of the threat landscape and observe attacks firsthand. Nexum will never publicly disclose specific, sensitive information; however, we can share observations and thoughts that might help your defense.

 __

Almost every day, our technical teams are being asked what we should log, and sometimes, our responses are very environment-specific. No environment is the same, and no risk is the same. We decided to share some general best practices that are likely to benefit every organization.

Enterprise Logging Best Practices

#1 Understand Compliance Requirements

Logging and compliance requirements go hand in hand. Typically, organizations will rely on regulations and requirements to set their policies and procedures that will dictate what must be logged and how long it needs to be retained. It is important to understand that not all logs have the same requirements: firewall logs may have different retention requirements than logs from financial systems or audit logs. It is highly recommended that IT and Security professionals work with corporate governance and legal teams to fully understand their logging requirements when developing policies, procedures, and requirements.

Example Retention Requirements:

• PCI – Retention of 1 Year with Immediate Access of 90 Days
  • Immediate access does not mean it cannot be in warm storage if warm logs can be searched quickly.
• North American Electric Reliability Council (NERC) – Log retention of 6 months – Audit Logs for 3 years
  • Bulk data for things like firewall logs is 6 months, where providing evidence for compliance is 3 years
• Sarbanes-Oxley (SOX) – Audit logs relating to financial records and controls – 7 years
  • This generally is not in scope for IT Systems/Security Systems Logging

We see many organizations choose a 1-Year retention with a 14- to 90-day online requirement.

Many log management tools, Security Information and Event Management (SIEM) or otherwise, can implement more complex retention policies; for example, retaining logs relevant to NERC networks for 3 years and login and account changes for 6 months, but discarding low-value Active Directory (AD) events after 14 days.

 

#2 Build an Organization Policy

After you know your compliance requirements, it is essential that everyone is on the same page in terms of what should be logged, stored, and monitored. NIST 800-92 “Guide to Computer Security Log Management” provides timeless guidance on the establishment of policies and procedures for log management.

Ensure roles and responsibilities are defined and understood from a logging perspective. Proper logging requires the entire IT village to ensure gaps do not develop.

 

#3 Understand Log Sources and Importance

Not all logs are created equally!

Debug logs from an internal application are not as critical as authentication and audit logs from Active Directory. Logs from systems protecting critical assets are likely more important than application logs with little to no security or audit value.

Build a catalog of potential log sources that is mapped by need for security, compliance, or other IT purpose.

SOME THINGS DO NOT HAVE TO BE LOGGED!! Logging at the Debug level is likely not needed.

 

#4  Prioritize Log Sources

Highest Priority

• Firewall/Intrusion Detection Systems (IDS) logs
• Authentication Related Logs (AD/Cloud/Multi-Factor Authentication)
• Virtual Private Network (VPN) and remote access devices
• Advanced Endpoint Security / Endpoint Detection and Response (EDR) Logs
• Proxy/Web filtering logs
• Email servers and their associated security gateways/cloud email security systems
• Wireless RADIUS authentication failures related to security (not association/re-association/roaming, as it could be very chatty)
• Wired Network Access Control (NAC) authentication events
• Other Audit events (configuration changes, system restarts, etc.)

High Priority

• Other security tools – sandboxing, file integrity, honeypot/deception tools
• Network flow information / DHCP / DNS Logs
• Host OS, Applications, Databases

Medium Priority

• Application logs

Do not log forward

• Debug/Dev Logs or other events carrying no actionable intelligence
• Events that are effectively duplicates or subsets of another event; for example, if a firewall generates both “Accept” events and also “Permit” events, which include more details on the traffic being allowed, do not forward the less detailed “Accept” message.

 

#5 Cloud Logs

Just because it is in the cloud does not mean it does not exist. IaaS, SaaS, PaaS, Private, Public… it does not matter the acronym; the logs still matter. Cloud logs are often as important, if not more important, than on-premise logs. The federation and integration of cloud applications can make cloud infrastructure the weakest point.

Cloud logging MUST be part of the puzzle for logging.

Advanced cloud-aware logging technology may include processing nodes deployed in specific cloud regions so that logs generated within a region can be processed without incurring unnecessary data egress charges from pulling back full, unfiltered, and uncompressed logs to centralized logging infrastructure.

 

#6 Smart Centralized Logging

Logging should be consolidated. While logs may have different use cases and retention requirements, ideally logs should be consolidated to a central location or locations, so that they can be fed into tooling for retention and/or analysis. Not all logs may need to be brought into a SIEM system for correlation and analysis; they may need to just be stored. Some logs should be discarded, or better yet, never forwarded from the source.

For larger environments, tools can be used to selectively distribute logs to multiple destinations, perform augmentation, and discard or archive specific events outside of expensive SIEM tools.

 

#7 Device Specific Logging Configuration

It is highly recommended to seek out individual best practices when configuring individual device log configuration. It is important that security and audit needs are being met for each specific log source. It is critical that an appropriate log configuration becomes part of the standard build templates for all devices. Almost every vendor has documentation for recommended logging for their own products.

Nexum can point you to either our product-specific documentation or the vendor’s product-specific documentation.

 

#8 Structured Log Formats

While the log formats may be driven by what is consuming the logs, if possible, use formats that support key-value pair style logging. LEEF, JSON, CEF, and other key-value pair delimited log messages tend to be easier for tools such as SIEMs to support. However, you will find that specific tools expect specific logs from specific types of devices to be in specific formats.

Where possible, try to use the best structured key-value pair log formats your SIEM tools will accept.

 

#9 Internal Application Logging

Many organizations have internally developed applications and inconsistent logging around these applications. Logs should contain important details like user ID, source, timestamps, severity, and type. Internal definition and training of developers on what constitutes an audit log, or a debug log is critical to consistent logging. Where possible, log session identifiers or request identifiers to track user activity and correlate a session across a series of log events. Standardized application-documented log event IDs can be very useful in developing SIEM rules and are highly recommended.

Apply a standard event severity value to all logs, following the Syslog standard priority levels or another framework. All logs should be tagged with the application generating the event and the severity level, greatly simplifying the process of routing (or discarding) logs and setting retention times.

Use structured key-value pair logging formats!

Develop a logging standard for internal apps to allow consistent formats and contents. This ensures that logs with audit and security relevance are sent to centralized logging, which is key to successful internal application logging.

 

#10 Monitor AND Audit the Logs

It is vital to have some sort of logging capability to understand when you are not receiving logs that you expect. Due to misconfiguration, the flow of logs can stop flowing! It is important that tooling or processes identify these situations so that remediation of log sources can happen.

Devices sending logs must also have logging configurations audited as part of other audit processes. As an example, during a firewall rule-base review, ensure all logs have a logging profile enabled.

 

#11 Clock Synchronization

Inconsistent time within an enterprise organization can cause major setbacks while using and correlating logs. It is highly recommended, where possible, to use network time synchronization against a local time source, and pick a time zone for servers, network, and security devices that generate logs to use so that correlation of activities across devices and across regions is easier.

Hint: Standardizing on a time zone like Coordinated Universal Time (UTC) that does not change with Daylight Saving Time is a good thing.

For highly time-sensitive environments, Nexum can assist in selecting and deploying authenticated time servers, atomic clocks, and satellite-synchronized time receivers.

 

#12 Continual Revaluation

Log sources and logging levels should be evaluated on a regular basis. This ensures that logs are appropriate for an audit and protection of critical assets, and sufficient to reveal breaches so that they can be remediated.

New potential log sources pop up all the time; make sure that logging requirements are being met when they do!

Internal controls that force this continual evaluation should be put in place.

 

#13 SIEM / Augmentation / Security Orchestration, Automation, and Response (SOAR)

The best practices for logging flow right into what we are doing with the logs once we have them.   

Organizations should be sending valuable logs to SIEM systems, perform normalization and augmentation on the logs and alerts with their SIEM or Security Orchestration, Automation, and Response (SOAR) tools, and use their SIEM/SOAR for review and response of log events.

Nexum can assist with more specific best practices tailored to your environment on Logging, SIEM, SOAR, and Log Augmentation.

 

Contact Nexum

As always, the team at Nexum is here and ready to discuss these threats with you in more detail. Use our Talk to an Expert form to contact us.