Integrating SIEM Within Compliance Programs

Often, though, an organization will have separate teams dedicated to carrying out these functions; for example, a security operations center (SOC) to detect, analyze, and respond to cybersecurity incidents, and a compliance team to continuously assess current internal IT processes against industry law and standards, document proof of adherence, and manage risk through control implementation.

This may lead to highly specialized teams that are siloed, causing poor communication and a lack of awareness of the steps each is taking to address the same objective. These results are neither satisfactory for operations nor compliant with many frameworks that require robust governance and aligned strategies.

Creating a culture of understanding and improving cross-functional collaboration is one of the most effective ways to streamline your security, compliance, and risk mitigation efforts. In practice, this means cross-training your workforce to achieve broad technical competency – ensuring your teams collectively buy into the importance of adhering to security laws and regulations and the level of audit trail documentation that is often required. It also means requiring a baseline level of technical and operational awareness to safeguard data and satisfy objectives in the most efficient way possible.

Furthermore, leveraging technology to combine rather than isolate cybersecurity and compliance efforts and integrating them with your risk management and audit programs acts as a force multiplier for the resources that organizations have at their disposal.

For the purposes of this article, I’d like to further explore what this approach to cybersecurity and compliance means in practice and ways to implement it in an organization using SIEM.

 

SIEM stands for “security information and event management.” SIEM software operates as an aggregator, collecting log and event data that is generated by endpoints, applications, and security devices within a network.

Once these analytics are defined, SIEM generates alerts and defines a level of risk based on the predetermined criteria and activity. Using SIEM technology to achieve visibility into network activity helps organizations monitor user activity, better manage company endpoints and assets, as well as address issues before they become a significant financial or other risk. SIEM is often an integral part of an organization’s security operations center along with tools for monitoring network traffic and forensic toolkits.

 

The term “compliance” can cover a broad spectrum of groups and objectives, including IT, legal, finance, and others. For the sake of this blog, when we say compliance, we’re referring to a group within an organization that facilitates audits of IT systems, often acts as liaison between the organization and third-party IT auditors, manages vendors and third-party risk, and provides direction in evaluating security risks and security standard compliance with appropriate policies.

Not all compliance regulations require third-party assessment (or attestation) over your IT infrastructure, but some requirements (e.g., SOX, PCI, and CMMC) necessitate a third-party audit. Other frameworks and regulations require that you self-audit your organization and report that you are adhering to those standards. Some common examples of this include ISO 27001 and the CIS Controls (formerly SANS Top 20).

 

There are three common classifications of controls that you’ll typically hear about when it comes to an IT controls assessment or attestation. These are known as Detective, Preventative, and Corrective controls. An easy way to think about them is as follows:

• Detective: What has occurred
• Preventative: What could occur
• Corrective: What’s our response?

Detective controls are aimed at identifying that a breach or act of compromise has occurred. A detective control suite is focused on providing evidence of events after-the-fact and reducing your identification and response time. These may be real time, or on a scheduled basis depending on the control requirement. Some examples of this would be quarterly access reviews or a real-time door alarm from a physical security perspective. These kinds of controls don’t prevent an event from occurring, but they assist in the timely identification of an event’s occurrence.

Preventative controls are focused on the types of events that haven’t yet taken place but have the potential to occur. These kinds of controls are implemented and initiated before an event happens, which reduces the likelihood and impact of an adverse event within your IT environment. Some examples of preventative controls are firewalls, malware prevention, data encryption, and hardening default configurations, like removing default user accounts and passwords.

Finally, we have corrective controls. Corrective controls are meant to limit the impact of an event after it has already occurred and recover to normal operations as quickly as possible. Software patching so threat actors have difficulty finding vulnerabilities in your systems, malicious code removal, and rebooting a system are all examples of corrective controls.

So, how does SIEM support these control types? At its core, SIEM functions in a detective control space. It assists in detecting security and compliance breakdowns so your organization can effectively identify and respond to incidents. A base-level SIEM does not perform functions of autonomous response to events without a security orchestration, automation, and response (SOAR) solution and thus cannot perform control procedures in a preventative or corrective capacity. However, audit trail and reporting data extracted from SIEM can be used to augment manual review controls. If you’d like further information about controls and requirements, you can do so through the Information Systems Audit and Control Association’s (ISACA) website.

 

Now that we’ve identified SIEM’s primary role in a compliance function, let’s look at a few control examples from an industry leading framework, NIST-800-53, to further illustrate security software’s role in a compliance function. NIST has several “Control Families” made up of controls that encompass various IT security domains, such as Access Control, Configuration Management, Incident Response, and System and Information Integrity.

The “Access Control” control family consists of security requirements detailing system logging. This includes who has access to what assets and reporting capabilities like account management, system privileges, and remote access logging to determine when users have access to the system and their level of access. In a similar vein, the “System and Information Integrity” control family correlates to controls that protect system and information integrity. These include flaw remediation, malicious code correction information systems monitoring, and security alerts. These types of detective controls are where SIEM can augment your compliance team and their objectives. SIEM can be used to configure analytics and alarms based on malware detection, missing patches, modified configurations, backup failures, and more. Specifically related to Access Control, SIEM can help you augment compliance controls through analytics that can alert on admin account password modification, privilege escalation, excessive attempts to access a given account, and the deletion, disablement, or enablement of an account. Outside of analytics, SIEM reporting capabilities can provide a thorough audit trail of activity that can be used in management review controls. Reports can provide easy-to-access, automated evidence that can be used to augment those controls in a more efficient manner.

 

As mentioned, most compliance frameworks place special emphasis on identity and access management controls. NIST 800-53, for example, has several controls within its Access Control control family related to privileged account management; this includes employing the principle of least privilege, authorizing access to said accounts on a strict case-by-case basis for only security functions, and preventing non-privileged users from executing privileged functions.

If your organization has goals to be compliant with NIST 800-53, your compliance program will be interested in how these privileged accounts are identified and monitored within your environment. Using SIEM analytics (like the example below) can provide you various monitoring capabilities depending on the audit trail you’d like developed.

Let’s say your organization has made the decision to unify your security and compliance teams and integrate SIEM within your compliance and audit programs. What’s the next step? To effectively rely on SIEM within the perspectives of an audit, there are some things to consider.

When scoping a compliance audit, your organization will be tasked with working with an independent auditor to determine what security domains and infrastructure need to be evaluated, which will vary depending on the objectives of the audit. In a CMMC audit, you would start evaluating where your Federal Contract Information and Controlled Unclassified Information are housed. For the purposes of a SOX audit, in-scope systems and applications are determined depending on the systems and application in which financially significant data is housed and circulated. In any case, if you’re using SIEM as a tool to augment your security controls, it’s likely that the SIEM itself will need to be considered “in-scope” for the purposes of the audit. Whenever you’re using a third-party tool to perform controls, or use data in the operations of those controls, your third-party auditor may want to know more about the tool and what evaluation you’ve performed to ensure that it operates in a secure and reliable way.

For a system to be considered in-scope, some level of assessment of the vendor in question will be expected. Often, this step is handled by your vendor management group; additional consideration should be paid to whether the vendor provides a Service Organization Control report (SOC report) as it’s likely an auditor will expect your organization to have complementary controls in place related to your SIEM and other third-party systems. Attention should be paid to Access Control: which accounts have access to various systems, which accounts have access to make changes (i.e., privileged users) and methods controlling user authentication. An auditor will be concerned with assessing these configurations within the SIEM, to ensure that the data being extracted is complete, accurate, and reliable. Along that same vein, your auditor may ask about deprovisioning procedures for expired and stale accounts, which are vectors of compromise.

None of these are guarantees and may not apply to every SIEM depending on the flexibility the tool or service gives you, but they are nonetheless important considerations to assess prior to conversations with your auditor about in-scope systems. Anticipating auditor inquiry, in general, will help to expedite a smooth audit process and allow your organization to successfully rely on system data throughout the duration of the audit.

The following is a non-exhaustive list, but includes common audit topics to keep in mind when planning to rely on data from your SIEM, or any third-party system, for the purposes of your audit:

• Appropriate segregation of duties
• Access to privileged user accounts
• Accounts with ability to migrate changes
• Completeness and accuracy of data
• Appropriate testing and review of changes prior to production
• Principle of Least Privilege

 

Using your security tools cross-functionally is just one way of unifying your organization’s security and compliance objectives. That being said, integrating your SIEM solution within your audit, risk, and compliance programs can encourage a consistent tone between both groups, expedite audit functions, and structurally streamline your security and incident response procedures to set your organization up for technical competency, certification success, and effective, timely risk mitigation.

 

This blog was written by our partner, LogRhythm