How IBM i Answers PCI DSS Requirements to Regularly Monitor & Test Networks
PCI DSS regulations can be daunting for companies to understand how to comply with. Like most compliance regulations, there are a lot of things you need to do, and no instructions on how to accomplish them. This leaves it up to the IT department to figure out how to comply with the regulations without adding too much cost for the business and too many restrictions for the users.
This post is part of an ongoing series describing how an IBM i partition can meet PCI DSS requirements, with each post covering one set of requirements. This week, let’s look at PCI DSS requirement 10, the requirement to Regularly Monitor and Test Networks in a cardholder data environment.
What the PCI DSS standard says about monitoring and testing networks
PCI DSS requirement 10 specifies that organizations must “Track and Monitor all access to network resources and card holder data.” Essentially, this means that you must log all user activity (create an audit trail) in order to prevent, detect, or minimize the impact of data breaches on cardholder data. Without a log of user activity, it is difficult to determine what happened when something goes wrong.
For IBM i specifically, if credit card data is stored on the system then it must be monitored to prevent unauthorized access. Let’s look at the specific requirements for this point in more detail.
What data do I need to log and track?
PCI DSS requirements 10 specifies that you must “Implement audit trails to link all access to system components to each individual user” (requirement 10.1), and that you must implement “automated audit trails for all system components” that can be used to reconstruct several specific events listed in requirement 10.2.
PCI DSS requirement 10.3 states that you must log specific information (system activity logs) about your logged events including: the user, the type of event, date and time it occurred, whether or not it was a successful transaction, where the event originated from, and the name of the affected data, component or resource. The idea behind this requirement is to identity the who, what, when, where and why of a transaction, in order to be able to quickly identify a potential breach of sensitive data.
For organizations with IBM i partitions within scope of requirement 10, several vendors offer security auditing modules such as SEA Software’s iSecurity Audit. Auditing modules can activate audit trails and record security events in a log file, which can help you satisfy requirements 10.1 through 10.3.
Securing and centralizing access to audit logs
PCI requirement 10.5 specifies you must “Secure audit trails so they cannot be altered.” This means you must limit who has access to the activity log data and have a way to prevent that data from being changed.
If someone with the right authorities is able to alter log data, you won’t be PCI compliant. There must be a mechanism to track changes to the log data (who did it and when). Being able to detail why there was a change to log data is also helpful.
For the IBM i, third-party products such as SEA’s iSecurity Change Tracker can collect and report on QAUDJRN information regarding any changes to the library containing your system activity logs.
It’s also important to limit the log data access to only those users who should be authorized to view it. Many IBM i security vendors provide products that make it easy for you to limit access to sensitive logs.
Requirement 10 also requires you to implement, record, and analyze log data for all system components within scope, not just the IBM i. This implies that your IBM I data should be included with log data from other components on a centralized Security Information Enterprise Management (SIEM) server. There are several vendors who offer products such as SEA’s iSecurity Syslog, which provide real-time transmission of IBM i security event information to a centralized SIEM server where it can be analyzed in conjunction with other network data.
Review Log Data Regularly
PCI DSS does not require that you review your logs in real time, PCI requirement 10.6 only says that you must “Review logs and security events for all system components to identify anomalies or suspicious activity. Perform critical log reviews at least daily.”
Third-party IBM i auditing products such as SEA’s iSecurity Audit can automatically analyze system audit log information and send out alerts when anomalies or suspicious activity are detected. Logs can have 1,000 of records and humans can easily miss something, if they are searching through the file looking for the proverbial needle in the haystack. Having an automated monitoring solution that can alert you in real time to a potential threat can help prevent breaches and protect your customer’s sensitive information. IBM i auditing products also offer exception reports that makes it easy for your team to identify where the issues are and give them insight on how to resolve them.
Auditor Requirements
The auditor’s job is to ensure that you have this audit trail data stored somewhere. They are just looking for you to be able to produce the information. As long as you have it, they are happy. Again, there are no instructions for how you do it. Just that you must do it.
PCI DSS requirement 10.7 specifies that you must keep your audit trail data for at least one year, which can be archived to tape or other media. However, 90 days of data must be kept online and available immediately. The auditor will want to see that you can produce the data for the past 90 days and that you have access to the rest of the information.
Other items relating to PCI DSS requirement 10
There are two other items related to PCI DSS requirement 10, that I haven’t reviewed yet.
Requirement 10.4 specifies that you must use “time synchronization technology” to synchronize all critical system time clocks and for ”…acquiring, distributing, and storing time”. For the IBM i, this can easily be done by configuring the System Network Time Protocol (SNTP) settings on your partition to synchronize your IBM i time clock with an external time server. Click here for information on how to configure SNTP on IBM i 7.1.
The final two PCI DSS 10 requirements deal with specifications for reporting critical failures for service providers (10.8) and with documenting and distributing security policies and operational procedures to all affected parties (10.9). Review the PCI DSS standard for more information on implementing these policies.
Needing a security solution
Being able to produce PCI DSS requirement 10 data without a security solution can be extremely difficult. However, working with an IBM i security vendor like SEA can make it easy for you to generate reports and consolidate information and meet the PCI DSS standard. Feel free to contact us at SEA if you need more information on meeting the PCI DSS standard with your IBM i partitions.
