PCI File Integrity Monitoring - Five More FAQs for PCI DSS Merchants

PCI DSS File integrity monitoring - What are the best options file integrity monitoring and what else do you need to know? How do you implement file integrity monitoring for Windows servers and Unix servers? How do you provide file integrity monitoring for firewall, routers, EPoS devices and servers? How does file integrity monitoring software work and what are the key features to look for? Should a file integrity monitor be agent-based or agentless?
The following is part two in a two part series listing the Top Ten FAQs for File-Integrity Monitoring that any PCI Merchant should be aware of.

1. For Log Files and Databases
Log files will change constantly on a busy server but it is important that log files are only changed in the manner expected. File integrity monitoring must be used in secure environments to protect important audit trails of system access and privilege usage and changes. The key is to only allow log files to increase in size and to alert if any changes are made to monitor for log file changes that may be an attempt to remove or change audit trail information - clearing log files or changing log files is classic hacker activity and should be monitored. Of course, event logs should be backed up centrally on a secure log server as a mandated requirement of the PCI DSS, PCI Requirement 10.
Similarly database files containing card data and personal information must be protected and an audit trail of all access and changes created. Again, database files will change constantly so the SHA1 approach will not be suitable. When using file integrity monitoring for SQL Server or file integrity monitoring for Oracle databases the best option is to log access and changes to specific tables and backup event logs centrally on your secure PCI DSS log server.

2. For System32 Folder
The most critical system files on a Windows server or EPoS till to monitor for file-integrity are within the WindowsSystem32 folder. All critical operating system programs, dll files and drivers reside within this location and it is therefore an ideal location for Trojans to reside. The threat is that a Trojan could be implanted onto the EPoS device or Card Data Handling Server (evading Anti-Virus detection because AV is only typically 70-90% effective). A file integrity monitor agent will gather a full inventory of all files within the System 32 folders and then make regular comparative checks subsequently to detect any changes made. Trojans are particularly difficult to find ordinarily because they masquerade as regular System32 program files, so they look and appear to act like the genuine program.
Similarly for Linux file integrity and Unix file integrity, all key program file systems such as the /usr/sys and /bin must be checked for integrity using a Linux or Unix file integrity monitor.

3. For Windows Updates
Windows Updates and patches for other applications will almost always involve updating program files, drivers and dll files. It is rarely clear which files will be modified by a patch and therefore any updates may generate numerous file changes across many folders and locations. Therefore it is vital that, while your file integrity monitor may track detailed changes to any one of a wide range of file attributes, you can also get good 'at a glance' summary information regarding whether a file has been added, deleted or changed.

4. Card Data and Card Data Folder File Integrity Monitoring
Where card data or other sensitive financial information is stored on an EPoS device or server the first line of defense is to limit access via folder and file rights and permissions. Even then, any user with Administrator rights will still be able to view the data and potentially copy out card numbers.
Therefore the best line of defense is to implement object access auditing on the file or folder. This will generate a full audit trail logging all access to the folder including the user account used to do so. Processing this audit trail with an intelligent, PCI event log analyzer will then ensure any unexpected access to the card data will generate an alert. For example, defining a rule to automatically distinguish between normal operations e.g. local system account access compared to a named account with administrator access.

5. PCI File Monitoring and Planned Changes/Change Acknowledgment
Of course, changes will need to be made to configuration files and system files every once in a while. It is important to keep security patches up to date and the PCI DSS mandates this should happen every month.
Operating a formal Change Management process is a key element of any IT security policy and therefore it is vital that your file integrity monitoring solution takes account of intended, planned changes. Any file changes detected as part of a planned change should be verified as part of your QA Testing and post implementation review processes to confirm that the right changes happened to the intended files only.
What about unplanned changes that are either emergency changes or those that for some reason bypass the change management process? These will all be detected and alerts raised by the file integrity monitor but there then needs to be an incident management process to investigate and either approve the changes or remediate them. The PCI DSS is not prescriptive as to how these processes should be managed so for some organizations they will use a full Service desk application to document and approve changes, whereas smaller organizations may just need a spreadsheet record of changes - use what works best for your company, not what you think a QSA will expect to see!

See part one of this series for other important file-integrity monitoring FAQs that any Merchant needing to be PCI DSS compliant should know