When’s the last time someone made an unauthorized change to your system files?
To answer this and other important security questions, as well as to meet many compliance requirements, you first need to have file integrity monitoring. In case you aren’t familiar with the term, file integrity monitoring (sometimes abbreviated to FIM) is the method for knowing exactly when and how your files are being changed at any moment in time. This includes critical system files, configuration files, and content files.
Both PCI DSS and HIPAA, two major compliance frameworks, require that companies employ file integrity monitoring to ensure complete visibility into their systems. Here we’ll explain what you need to know about file integrity monitoring to meet compliance for each of these frameworks.
The Basics of File Integrity Monitoring
In the cloud, file integrity monitoring can and should alert you about three types of events:
- When new files are added to or deleted from a directory
- When specific files are modified or any files in a directory are modified
- When specific files or any files in a directory are opened
The overall goal of file integrity monitoring is to catch a potential security breach as early as possible. Since changes on critical pieces of infrastructure are often harbingers of a security breach, file integrity monitoring is the best way to catch those signals early.
Most importantly, and for the purpose of this discussion, both PCI DSS and HIPAA compliance frameworks mandate file integrity monitoring. Of course, they each do so in a slightly different way, using varying terminology and a range of specificity. Below, we explain what you need to know about FIM for each framework.
File Integrity Monitoring for PCI DSS
Two specific areas of PCI DSS reference file integrity monitoring: 10.5.5 and 11.5. These aspects of PCI DSS say that you must install file integrity monitoring software in order to meet compliance. Let’s take a look at these rules in depth. (Bold is my emphasis.)
|PCI DSS Requirements||Testing Procedures||Guidance|
|10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).||10.5.5 Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring or change-detection software on logs.||File-integrity monitoring or change-detection systems check for changes to critical files, and notify when such changes are noted. For file-integrity monitoring purposes, an entity usually monitors files that don’t regularly change, but when changed indicate a possible compromise.|
|11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.||11.5.a Verify the use of a change-detection mechanism by observing system settings and monitored files, as well as reviewing results from monitoring activities. Examples of files that should be monitored: System executables, Application executables, Configuration and parameter files, Centrally stored, historical or archived, log and audit files, Additional critical files determined by entity (for example, through risk assessment or other means).
11.5.b Verify the mechanism is configured to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files, and to perform critical file comparisons at least weekly.
|Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected. If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.|
As you can see, PCI DSS recommends focusing on changes to files that already exist (vs. new ones being added). You may want to do both, depending on the nature of your business and the types of threats that may be leveled against you. Additionally, PCI DSS recommends that you focus on key files that are generally static. A good file integrity monitoring system will let you quickly write rules that focus on key files (such as those described in 11.5.a) that, when modified, are a solid indicator of compromise.
Now, a quick note: One tricky aspect of securing personally identifiable information, or PII (which is vital to both PCI DSS and HIPAA), is that while this information must be protected from the “bad guys,” security solutions can’t look at the data either. This means companies need a FIM solution that does not need direct access to the data to monitor changes. Threat Stack’s unique platform is designed to do just this. Because Threat Stack’s agent leverages existing Linux kernel subsystems, it does not create file hashes, run commands, open files, or look at network traffic.
To wrap up, as the PCI DSS guidance here points out, the reason FIM is so important when it comes to payment card information is that, if it is in place, attackers cannot steal files with financial details in them without any change in “business as usual.”
File Integrity Monitoring for HIPAA
Unlike PCI DSS, the HIPAA compliance framework is fairly vague about file integrity monitoring. Here is the important text (bold is my emphasis):
3. Integrity (§ 164.312(c)(1)) We proposed under the ‘‘Data authentication’’ requirement, that each organization be required to corroborate that data in its possession have not been altered or destroyed in an unauthorized manner and provided examples of mechanisms that could be used to accomplish this task.
Later in the document, integrity is defined in this way:
Integrity means the property that data or information have not been altered or destroyed in an unauthorized manner.
Under “§ 164.306 Security standards: General rules,” HIPAA also specifies that covered entities must:
(2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.
When it comes to specifics about how this should be accomplished, HIPAA is quite vague:
Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
At the end of the day, the “electronic mechanism” (a.k.a. software) you choose is up to you, but we recommend that you follow similar guidelines to those in PCI DSS, by putting into place a file integrity monitoring system that focuses on change management for key files. In the case of HIPAA, files you will want to pay particularly close attention to include:
- Electronic protected health information (ePHI)
- Personally identifiable information (PII)
- System executables
- Application executables
- Configuration and parameter files
- Log and audit files
While HIPAA is not nearly as specific as PCI DSS (and while both leave room for interpretation), the bottom line is that you want to have a comprehensive method for tracking changes to key files across your system to protect payment card data, protected health information, personally identifiable information, and any other sensitive or protected data from unlawful and unwanted access.
Building Audit Trails for File Changes
Of course, you can’t just monitor and alert for file changes in real time. You also need the ability to look backward and investigate incidents in depth. To do this, you must have comprehensive audit trails. Audit trails record historical data and allow you to review past activities in your system. The good news is that a strong file integrity monitoring solution can give you the audit trail you need to meet compliance regulations.
How Threat Stack Helps With File Integrity Monitoring
Wondering how file integrity monitoring works on the Threat Stack Cloud Security Platform™?
Threat Stack helps companies meet a broad range of PCI DSS and HIPAA compliance requirements, even taking them a step further to ensure complete security of your files. For example, Threat Stack not only detects when a file with PII gets accessed, but will also pinpoint which process has accessed it. Threat Stack also identifies when PII content is opened, copied, or moved off the system, what its destination IP address is, and who is responsible.
In addition, Threat Stack audits and uniquely identifies indicators such as:
- User access to servers
- Logins, logoffs, and login failures
- Commands that a user has run after login
- Processes that the user has left on the servers to run
Threat Stack also alerts you when insecure protocols are used on the servers where the data is located. This combination of real-time visibility and the ability to reconstruct events enables you to not just meet stringent (and sometimes murky) compliance requirements, but to achieve peace of mind when it comes to the security of your company’s most valuable data.
If you’d like to know more about the ins and outs of meeting PCI DSS and HIPAA Compliance in the cloud, download our newly released Compliance Playbook for Cloud Infrastructure.