Control 6: – A framework for an offense-informed defense

We’ve covered Controls 1 through Control 5 of the 20 Critical Security Controls. This blog will focus on Control 6 and will complete our coverage of the “Basic Controls”, those which represent the most basic of cyber “hygiene”. The 20 Critical Controls use an offense-informs-defense perspective through which an organization can effectively defend against cyberattacks. 

“On average, attackers are active within a company for over 140 days before detection. … on average an attacker is active within an organization for 4.6 hours before creating a detectable anomaly in system logs.”

Critical Control #6

Many organizations must keep records for various compliance and legal reasons. Tax, employment, and financial records are just some of the areas which are under external regulation to keep records. Such records are kept to permit future inspection of the activities within a given period of time. So too should systems audit and log data be kept. Attackers rely on the fact that such organizations rarely look at the audit logs, and they do not know that their systems have been compromised.”

For most organizations the system log is an overlooked and forgotten function. This log is a treasure trove of juicy information that an attacker would love to get their hands on. Every activity that has transpired on not only any given system but also interactions with neighboring systems are recorded. In the hacking community the saying of “first in, last out” often applies to system logs. They are the first place an attacker goes once they gain a foothold and the last place they go (to delete or obfuscate the logs) before acting on their objectives.  Because of this fact alone, organizations should pay close attention to the system logs. Control 6 requires us to focus on these logs and take meaningful action to secure, monitor, and audit them. On average, attackers are “in” a company for over 140 days before detection. How long do you think they were “in” before an anomaly was recorded in a system log? Based on data produced by FBI, Cisco, and Verizon Data Breach Report an attacker is active within an organization on average 4.6 hours before creating a detectable anomaly in system logs.

Control 6 is far-reaching and incredibly comprehensive. Of the foundational controls, this one is by far the most frequently  neglected. In our experience that’s most often due to the seemingly mundane nature of the work required to satisfy this control. Simply, there’s nothing sexy about log analysis; That is until there’s an incident. In that moment all of the effort that went in to satisfying Control 6 immediately pays off. If you get nothing else out of this blog we hope you’ll take this away; Should (when) you need the assistance of Law Enforcement for a cyber-incident that is the one moment that you don’t ever want to have to say “We don’t have those logs”. Consider that outcome as you evaluate implementation of Control 6.

Critical Control 6: Maintenance, Monitoring and Analysis of Audit Logs

Sub-control

Applies to:

Security Function (intention)

Sub-control Title

Description

6.1

Network

Detect

Utilize Three Synchronized Time Sources

Use at least three synchronized time sources from which all servers and network devices retrieve time information on a regular basis so that timestamps in logs are consistent.

6.2

Network

Detect

Activate audit logging

Ensure that local logging has been enabled on all systems and networking devices.

6.3

Network

Detect

Enable Detailed Logging

Enable system logging to include detailed information such as a event source, date, user, timestamp, source addresses, destination addresses, and other useful elements.

6.4

Network

Detect

Ensure adequate storage for logs

Ensure that all systems that store logs have adequate storage space for the logs generated.

6.5

Network

Detect

Central Log Management

Ensure that appropriate logs are being aggregated to a central log management system for analysis and review.

6.6

Network

Detect

Deploy SIEM or Log Analytic tool

Deploy Security Information and Event Management (SIEM) or log analytic tool for log correlation and analysis.

6.7

Network

Detect

Regularly Review Logs

On a regular basis, review logs to identify anomalies or abnormal events.

6.8

Network

Detect

Regularly Tune SIEM

On a regular basis, tune your SIEM system to better identify actionable events and decrease event noise.

Making Application: Control 6

As an organization evaluates Control 6 there are subcontrols which are often very minimally implemented. In our experience those include the requirement to utilize a minimum of three distinct time servers, activate (and require ongoing validation) detailed event logging, and allocating appropriate equipment sufficient to store log data. To try to pass along some hard-learned wisdom, we’re going to enumerate these points in detail.

Hey! Wait a second!

Our network systems are in constant motion. There is always something going on. In general, every system keeps a record of their very busy lives in a local system log. Just like us humans, they use the date and time to keep track of what they did when. Some functions, like authentication, have a very obvious requirement for accurate time between systems while others like switch port up/down activity does not. When the perspective of systems log data shifts from the single monolithic device to the collective sum of all devices the amount of log data is overwhelming. Hundreds to millions of lines of log entries per second can be collected in even a modest network. Tying all of that data together is an exceptionally difficult task. Often the only thread that is common across all of this data is time. Albeit very precise time. Generally precise to the tens of milliseconds. Attackers know this and want to make the cyber-defender’s job of finding them difficult-to-impossible. One way they do this is by ‘fuzzing’ the logs; Intentionally messing-up the timestamps that devices place in their local logs so that once that data is combined with log data from other devices the cause-effect relationships of an attackers actions cannot be found (easily). Consider this. Every windows desktop and server since Windows 7 / Server 2008 uses the same default time server. That time server, time.windows.com, is referenced by the computers using its DNS name. Just by calling that name, the computer systems can get the correct time. If an attacker wanted to exploit this vulnerability they could simply create a host record entry or spoof the DNS name ‘time.windows.com’ and point to a server of their choosing. Perhaps that server would not issue the correct time but rather some altered version – possibly multiple versions. The servers and workstations within that victim network would then have no external reference of the correct time. They would log their activity using the incorrect versions of time which would not align or correlate with other log data, such as that from firewalls or external cloud partners. This very attack is carried out hundreds of times each year.

Control 6 requires that we first define no fewer than three discrete servers as our trusted time sources. Only then can we take the action to ensure that these servers are uniquely specified to internal network systems. Through this action we can ensure that every system clock and subsequent log entry are time-aligned.

Did you see that?

Not all event logging is created equally. Network devices are generally able to create log events at one of eight detail levels. To illustrate this, let’s use this image. At log level 1 can you make out what the image depicts?  At log level 7 it’s pretty clear. The same is true for systems logs. By default most network systems come with system logging disabled or set to such a low level that no meaningful information can be gathered from them. Consider what we covered in Control 5 pertaining to default system configurations. Most often new systems are intended to ease their use rather than emphasize security. Subcontrol 6.2 requires that we configure all devices to log with sufficient granularity to permit meaningful interpretation of events within a given period of interest at a later time. In general, we recommend log level of 5 or greater for syslog-equipped devices. For Windows servers, we recommend using the logging requirements of the NIST checklist “Windows, III – Administrative Sensitive” as a starting point.

I just can’t take it any more

If we follow the requirements of Control 6, there’s going to be a lot of systems log data that needs to be stored. How it’s stored and where it’s stored can pose a challenge. First, let’s just get out of the way they typical response that’s typical when we mention “log data”. That’s the immediate desire to use the oldest and slowest computer system in the entire company to be used as the “new” logging system. We get it. System event logging isn’t sexy. It’s outright boring. Is it really the best idea to use the 8 year old computer that has the original 5400 RPM spinning disk as a repository for critical data? We’re sorry if that offended you. If it did, then these guys may be able to help with your business technology. When you’re ready to take your information seriously, we’ll be here and ready to talk.

With that out of the way, let’s focus on two commonly overlooked aspects of log retention; Space and Integrity. Today, storage space is generally inexpensive. At least the kind we need to store log data. Consider and calculate how much log data is going to be generated across the entire organization. With this figure, determine how long you should and must retain this data. These are generally two different numbers. Solicit input from your legal counsel, the executive team, and compliance officer(s) for this question. In general, most organizations outside of the federally regulated space, should consider 6-12 months as a starting place. For those within the federally regulated space, you likely already know the laundry list of acronym soup that you must comply with in this area. If you don’t, contact us and we can help point you in the right direction.

Once you know how long you must store this data, we encourage adding some additional time into your retention calculations. Ensure that whatever device(s) are selected as log repositories provide RAID-protected storage which is sufficient to store the amount of data that these calculations have shown.

Many network administrators make an effort to implement log retention by driving up the maximum log file size on each of their servers. While this provides excellent log retention on the local system so-long as nothing goes wrong, it doesn’t provide the same when a server crashes or an attacker gains a foothold and deletes logs. Storing some level of logs locally and in a centralized manner is what Control 6 requires.

Conclusion

Control 6 requires organizations and network administrators alike take care to centralize, continuously systematically evaluate, and manage the logs of computer systems. This control is one of the easiest to overlook because of the seemingly mundane nature of system logs. It does however ensure that organizations are able to provide some of the most critical forensic information in both pre-breach and post-breach situations. Implementing Control 6 ensures that organizations are able to answer internal and external stakeholder questions in the instance of a breach. Most importantly, it serves as the best leading Indications of Attack and Indications of Compromise available.

Who is Corporate Information Technology (CIT):

Corporate Information Technologies provides small to mid-market organizations with expert I.T. services including Critical Control centric Managed and Co-Managed technology services, information security policy creation & assessment, cybersecurity services, penetration tests, and comprehensive business continuity planning services. Corporate Information Technologies can help organizations maximize and optimize their technology systems while identifying and mitigating cybersecurity risks presented by those very systems.

Contact us to learn more and let us show you how good I.T. can be!

All references to tools or other products in this document are provided for informational purposes only, and do not represent the endorsement by CIT of any particular company, product, or technology.
This material has been compiled using material licensed for public use under the Creative Commons Attribution-Non Commercial-No Derivatives 4.0 International Public License. The link to the license terms can be found at Creative Commons

Comments are closed

Learn More
error: Alert: This Content is protected!