Regarding PCI compliance, financial institutions have an advantage. Having complied with GLBA for several years, banks and credit unions have relatively robust and complete information security programs in place. They are audited several times per year by FDIC, NCUA, State, external firms, internal auditors, SOX audits, etc.
The problem is card brands like Visa and MasterCard have been focused on the retail industry as a major trouble area. Compared to most retailers, financial institutions are more mature in their Information Security Management and Audit programs, less likely to cause a breach, and are therefore not the initial priority.
Even with a head start, financial institutions still need to put PCI compliance and PCI Assessments high on the list of projects.
The good news is many PCI controls are in place: firewalls, change management, policy documents, etc. However, there are three areas where GLBA audits and PCI requirements don’t overlap - making it high potential areas where examiners will likely focus their questions.
1. Encrypting Data at Rest. PCI requirement 3.4 requires the primary account number to be rendered unreadable (e.g. encrypted, truncated, tokenized) anywhere it is stored unless it is in non-persistent memory (RAM Volatile Memory. However, it is essential to implement appropriate controls to guarantee that memory remains in a non-persistent state. Once the business objective is fulfilled, (transaction completed) data should be promptly cleared from volatile memory.
FFIEC and other banking guidance reference encryption, but examiners typically do not document exceptions if the data are internal and appropriate access controls are effective.
2. Network Segmentation. While not a direct requirement, limiting the scope of the cardholder data environment (CDE) is desirable to limit the compliance scope and save costs.
Segmentation can be accomplished through various physical or logical means, like appropriately configured internal network security controls, access-restricted routers, or other technologies. For PCI DSS compliance, a system component is deemed out of scope if it's effectively isolated from the Cardholder Data Environment (CDE), ensuring that any compromise of that component wouldn't affect the CDE's security.
In many cases based on traditional network architecture and a business need to see full card numbers, the entire network may be in scope. Not completely horrible by itself, but cybersecurity compliance efforts could get expensive where multiple branches and facilities are involved.
3. File Integrity Monitoring. PCI section 10.3 requires that audit logs are protected from destruction and unauthorized modifications.
This requirement emphasizes the importance of logging mechanisms for tracking user activities, which play a vital role in preventing, detecting, or mitigating the effects of a data breach. Having logs across all system components and within the cardholder data environment (CDE) enables comprehensive tracking, alerting, and analysis in the event of an incident, facilitating the identification of the compromise's root cause.
*Auditing system-level events can be done natively in Windows, but introduces performance issues. Many institutions will be better off with a commercial FIM solution like Bit9 or Verdasys.
If you haven’t yet looked at PCI DSS v4, I highly recommend downloading it from the PCI Security Standards Council website.
If you're seeking guidance on navigating and implementing your own organization, reach out to us for expert guidance on a PCI self-assessment or support with your ongoing cybersecurity compliance.