Monitoring and Logging Requirements for Compliance

Addressing compliance requirements for monitoring and logging can be a challenge for any organization no matter how experienced or skilled the people responsible are. Compliance requirements are often not well understood by technical teams and there is not much instruction on how to comply with a compliance program. In this article, we’ll discuss what some of these new compliance programs mean, why they are important, and how you can comply with your logging and monitoring system.

What is a compliance program?

The goal of compliance is to provide stronger security in a verifiable manner. The way they do this is to create standards or regulations that stipulate where an organization must meet a minimum level of strong security practices. To meet these, it may include technical controls; such as logging/ monitoring software, strong configuration control, or administrative controls; such as policy, procedure, and training.

While compliance sets a minimum level of requirements, it is up to the organization to determine the level of control needed. Most commonly, this is done via an assessment of risk or threat in context with the requirement.  If it can be shown that a compliance control requirement is sufficient, then the control should be at least what is required but can vary based on the assessment.

Who is affected by these regulations?

This next section includes a table of some common compliance programs – often referred to by the regulation or security framework associated with it. A regulation may be very broad and impact any business when it focuses on specific types of data (just as a state privacy law protects any citizen’s data regardless of location) or it may focus on a specific sector of the economy (like healthcare or energy utilities).

Many businesses may find they are within the scope of a regulation to a limited degree, such as when a business self-insures its employees, it falls into some HIPAA regulation requirements even though the business has no health-industry orientation. If you’re wondering if you might be impacted by a regulation, the question is typically determined by your legal or security department.

What do the compliance programs say?

The regulation may be how a program is identified, but often it is also a framework or associated document that provides instruction on how a compliance effort is to be implemented and assessed. It is wise to distribute these framework requirements to staff (sometimes in addition to the regulation) in order to explain what is required.

Compliance types

So how does regulation turn into a compliance program? It requires at least two components: 1) a compliance framework to meet the goals of the regulation, and 2) a penalty mechanism for “encouraging” compliance. When you examine those mechanisms, it makes it easier to understand the initiatives.

Why and when do you have to comply?

The penalty mechanism helps to provide the answers to the “why and when do we have to comply” question. In many instances, a compliance program costs more in fines and fees than if the company were to just comply.

For instance, PCI fines range between $5000–$100,000/month[XVIII].. For US State Privacy breach laws (in 48 states) the average fine is $50–$90 per person included in the breach. This does not exclude any other civil litigation that often follows a breach event. HIPAA fines reach up to $1.5M per incident[XIX], and GDPR fines[XX] are up to 20 million Euros or 4 percent of the annual global business, whichever is highest. These high costs make companies pay attention to key aspects of the compliance program – such as adhering to a compliance schedule. The compliance program, once engaged, typically starts a strict timing for audits, and in many cases, the timeframe for fixing or rectifying non-compliance findings. 

The compliance framework is where compliance programs get challenging, and where technical staff may get involved. You’ll want to start by reading the actual text of the framework. Most compliance frameworks are typically publicly available[XXI] so you can read about the requirements for the organization to follow.

Where is the compliance program applied?

The challenge with a framework is that it is usually somewhat “high level” for most technical staff. This can be a point of frustration – most frameworks are not very prescriptive.

There are a few aspects to keep in mind: first, there is often a question of scope, defining where the compliance program is to be applied. While this may be obvious, it can also be strategic when a company can segregate a high-risk function to limit the costs of security.

Second, it is most common to find that “objectives” or security control requirements are 1) categorized into common business operations and key functions (such as Human Resources, Access Control, Physical Security, Computer Operations, Encryption). Then 2) language is used to describe the outcome or components of a “compliant” environment, but without defining the specific control.

Finally, it is becoming more common for objectives to be couched in language that assumes a critical risk determination to be part of the solution to affect the features of the control. Therefore, these are all areas that can be part of a company compliance approach. Some examples of compliance language may help provide some context for the topic of logging or monitoring.

Examples of compliance language for logging/event monitoring

NERC CIP-007-5 Table R4 – Security Event Monitoring

R4. Each Responsible Entity shall implement, in a manner that identifies, assesses, and corrects deficiencies, one or more documented processes that collectively include each of the applicable requirement parts in CIP-007-5 Table R4 – Security Event Monitoring. [Violation Risk Factor: Medium] [Time Horizon: Same Day Operations and Operations Assessment].

M4. Evidence must include each of the documented processes that collectively include each of the applicable requirement parts in CIP-007-5 Table R4 – Security Event Monitoring and additional evidence to demonstrate implementation as described in the Measures column of the table.

ISO 27001 – A.12.4 – Logging and Monitoring

Objective: To record events and generate evidence.

Control 12.4.1 A.12.4.1 Event logging – Event logs recording user activities, exceptions, faults, and information security events shall be produced, kept and regularly reviewed.

Control A.12.4.2 Protection of log information – Logging facilities and log information shall be protected against tampering and unauthorized access.

Control  A.12.4.3 Administrator and operator logs – System administrator and system operator activities shall be logged, and the logs protected and regularly reviewed.

Control A.12.4.4 Clock synchronization –The clocks of all relevant information processing systems within an organization or security domain shall be synchronized to a single reference time source.

PCI DSS (Requirement 10): Track and monitor all access to network resources and cardholder data logging mechanisms and the ability to track user activities are critical for effective forensics and vulnerability management. The presence of logs in all environments allows for thorough tracking and analysis if something goes wrong. Determining the cause of a compromise is very difficult without system activity logs.

10.1 Establish a process for linking all access to system components to each individual user – especially access done with administrative privileges.

10.2 Implement automated audit trails for all system components for reconstructing these events: all individual user accesses to cardholder data; all actions taken by any individual with root or administrative privileges; access to all audit trails; invalid logical access attempts; use of identification and authentication mechanisms; initialization of the audit logs; creation and deletion of system-level objects.

10.3 Record audit trail entries for all system components for each event, including at a minimum: user identification, type of event, date and time, success or failure indication, the origin of the event, and identity or name of affected data, system component or resource.

10.4 Using time synchronization technology, synchronize all critical system clocks and times and implement controls for acquiring, distributing, and storing time.

10.5 Secure audit trails so they cannot be altered.

10.6 Review logs for all system components related to security functions at least daily.

10.7 Retain audit trail history for at least one year; at least three months of history must be immediately available for analysis.

Takeaways

As you can see from the examples above, the compliance requirements do not specify a specific product or solution – it is up to the organization to choose how to address the requirements to achieve compliance. Such solutions should ideally bring auditable outcomes so that an assessor or auditor could verify that the control in place meets the expectations of the compliance program.

A second takeaway is that the topic – logging and monitoring – is fairly similar across compliance programs. Many controls would be the same between compliance programs because the underlying systems and technology risks are so similar.

Finally, there are typically assessment guides provided with many compliance frameworks. With a little research, you will find multiple guidelines and checklists for deploying or assessing compliance with your program. Many are likely to be instructions to auditors and can give you “insight” as to how you might be assessed and what sort of evidence is expected. Advance planning can save you time and effort while illustrating to compliance auditors that your organization is staying ahead of the goals for the program.

Final Recommendations

We have discussed the who, what, why, when, and where of compliance and want to leave you with a couple final recommendations:

1) Consider the scope of the compliance program to ensure that your controls include the system components, facilities, products, and business processes that are included in the compliance program. Avoid focusing too narrowly on the scope of compliance.

2) Interpretation of control requirements can be challenging. One way to address complex technical control configuration is to work towards standard security best practices with all products, tools, and utilities at your enterprise, and consider performing a risk assessment to help deploy the controls most applicable.

Footnotes: