Thursday 2 June 2011

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

Wednesday 1 June 2011

PCI File Integrity Monitoring - Five FAQs for PCI DSS Merchants

Requirement 11.5 of the PCI DSS specifies "the use of file-integrity monitoring tools within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities." Additionally, "verify the tools are configured to alert personnel to unauthorized modification of critical files and to perform critical file comparisons at least weekly."
The following is part one in a two part series listing the Top Ten FAQs for File-Integrity Monitoring that any PCI Merchant should be aware of.

1. Agent-based file monitor or Agentless file monitor?
The gut reaction is that an agentless file integrity monitor is preferable - no software deployment required, no agent updates to apply and one less process running on your server. In theory at least, by enabling Object Access auditing via Group Policy or the Local Security Policy on the server or EPoS device it is possible to track file changes via Windows Events. You still need to work out how to get the local Windows Events back to a central log server, but then you will need to do this in order to comply with PCI DS requirement 10 anyway (and by the way, this will definitely need an agent to be deployed to any Windows server or Till).
However, the agent-based file-integrity monitor does have some distinct advantages over the agentless approach. Firstly, by using an agent, a PCI DSS file integrity monitoring template can be provided. This will comprise a blueprint for all folders and files that should be monitored to secure card data. In other words, a windows file monitoring agent is easier to set-up and configure.
Secondly, a windows file integrity monitor can actively inventory the file system. This approach allows the PCI DSS Merchant to demonstrate compliance with PCI DSS Requirement 11.5b by not just performing critical file comparisons weekly, but on a scheduled daily basis, or even in real-time for ultra secure environments.
Finally a file-integrity monitor for Windows that is agent-based can provide a Secure Hash Checksum of a file which is the only infallible means of guaranteeing the identity and integrity of binary system files. See FAQ 2 for more details.

2. Why use a Secure Hash Checksum for File Integrity Monitoring?
A secure hash checksum is generated by applying a hash algorithm to a file. The algorithm used is such that the resulting hash is unique. Even a one bit difference to a file will result in a significant variation to the hash. The most common algorithms used are SHA1 and MD5. SHA1 will generate a 160-bit hash value for a file, MD5 a 128-bit value. Recording and tracking changes to the Secure Hash of a file in conjunction with tracking changes to other file attributes such as permissions, modified date and size provides an infallible means of ensuring file integrity.

3. How to implement File Integrity Monitoring for Firewalls, Switches and Routers
Typically, any Firewall, Switch and Router will have a range of configuration settings which govern the performance, operation and crucially, the security of the device and the network it is protecting.
For instance, tracking changes to the running config and changes to the startup config of a router will reveal if any significant changes have been made that could affect the security of the network, Similarly tracking changes to permissions and rules on a firewall will ensure that perimeter security has not been affected.
Use of file integrity monitoring for firewalls, routers and switches is a key dimension for any change management procedure and essential for a comprehensive IT Security Policy.

4. File Integrity Monitoring for Web Applications
Web site Apps can generate lots of file changes that are not significant with respect to security of card data. For instance, images, page copy and page layouts may change frequently on an active ecommerce website, but none of these file changes will affect the security of the website. Depending on the web environment in use, there may be a mixture of ASP.NET (ascx, aspx, and asmx asdx files), Java (with js and jsp files), PHP, config or cnf files plus the more regular system files, such as dll and exe program files. It is essential to monitor file changes to all system files and config files for a car data application and web applications create more of a challenge due to the highly dynamic nature of the web app file system. A good file integrity monitor for web applications will have built-in intelligence to automatically detect significant file changes only and ignore changes to other files

5. File Integrity Monitoring for Web Applications
Web site Apps can generate lots of file changes that are not significant with respect to security of card data. For instance, images, page copy and page layouts may change frequently on an active ecommerce website, but none of these file changes will affect the security of the website. Depending on the web environment in use, there may be a mixture of ASP.NET (ascx, aspx, and asmx asdx files), Java (with js and jsp files), PHP, config or cnf files plus the more regular system files, such as dll and exe program files. It is essential to monitor file changes to all system files and config files for a car data application and web applications create more of a challenge due to the highly dynamic nature of the web app file system. A good file integrity monitor for web applications will have built-in intelligence to automatically detect significant file changes only and ignore changes to other files.

See part two in this series for more PCI DSS File Integrity Monitoring FAQs.