A Simplified Regulatory Checklist for Financial Institutions
When it comes to information security, few industries face the regulatory burden placed on financial institutions.
Banks, credit unions, insurance companies and organizations such as retailers that process cardholder data are in hackers’ crosshairs, as demonstrated by some of the most devastating cyberattacks in recent history, including last year’s Equifax breach. In fact, financial organizations represented the most heavily targeted industry in 2017, and retail wasn’t too far behind.
Granted, regulations help create and enforce security standards that reduce the likelihood of harmful cyberattacks. Nevertheless, maintaining compliance with the long and growing list of security regulations is complicated and can overwhelm some financial institutions. On the federal level, financial organizations must rigidly adhere to the following:
- The Sarbanes-Oxley Act (SOX): Establishes requirements for the secure storage and management of corporate-facing, electronic financial records.
- Gramm-Leach-Bliley Act (GLBA): Regulates the collection, safekeeping and use of private financial information.
- Payment Card Industry Data Security Standard (PCI DSS): Sets requirements for any organizations “that store, process or transmit cardholder data.”
Compliance alone doesn’t shield an organization from legal liability in the event of a data breach. However, strict adherence to all of the above—as well as conformance to extensive guidelines and recommendations outlined by the Federal Financial Institutions Examination Council (FFIEC)—abates cybersecurity risks.
To help organizations cover their bases, we’ve identified a few core security operations center (SOC) resources, processes and technologies that fundamentally improve compliance management.
Administrative and Access Controls
PCI DSS, SOX and GLBA all set requirements for the tracking of user access logins to computers or systems that contain sensitive data. Broadly speaking, financial institutions and other organizations that must abide by PCI DSS, are required to limit cardholder data access to as few employees as possible and implement administrative controls that track account activity.
Similarly, FFIEC has recommendations in place for the use of authentication (two-factor or multifactor being the preference) to help verify the identity of authorized users.
As a general rule, PCI DSS prohibits the storage of the “full contents of any track from the card’s magnetic stripe or chip.”
Otherwise, any cardholder data, and any stored personally identifiable information (PII), should be protected with strong cryptography both when in storage and when in transit over public networks.
Firewall and Web Gateways
All organizations that process cardholder data are expected to install and maintain a firewall under PCI DSS guidelines. They must also be able to demonstrate, “a clearly defined, enforceable change process for firewall policies,” according to CSO. Auditors will also check to make sure that any allowable connections are absolutely necessary for business purposes and that any insecure connections are supplemented with additional security controls.
Likewise, banks and other financial institutions are accountable under GLBA mandates for the deployment and ongoing maintenance of a firewall or anti-virus equivalent.
Financial institutions are also expected to implement intrusion detection systems (IDS) in “cases where a high degree of GLBA data exists,” according to Rutgers University. The deployment and ongoing maintenance of IDS can help assess the types of connections your firewall is blocking, and which types it finds permissible.
Under PCI DSS, retailers are similarly obligated to use intrusion prevention and/or intrusion detection systems. This helps ensure that personnel are notified quickly in the event of an indicator of compromise (IOC). This is especially critical in states such as New York, where rules exist that mandate the disclosure of an unauthorized access attempt to the Department of Financial Services within 72 hours of an incident.
Logging and Data Collection
Under GLBA, all security event information must be logged and reviewed on a daily basis, and stored for at least 90 days. FFIEC also has guidelines in place for identifying specific log sources (e.g., firewalls, IDS, anti-spam, etc.) and then analyzing them for potentially threatening network activity, as well as related procedures for incident response and reporting of IOCs.
PCI DSS also includes rules for continuous tracking and monitoring of access to network resources and payment data.
Policies and Procedures; Systems Maintenance
Financial institutions, in accordance with GLBA, must establish and uphold security policies for incident reporting and responding. Simultaneously, any staff that process and/or store GLBA data are expected to undergo annual security awareness training. These rules also apply to any third-party service provider handling GLBA data on behalf of another organization.
GLBA also requires timely patching for security updates. Similarly PCI DSS requires the use of up-to-date security controls (e.g. firewall). And, finally, FFIEC has guidelines that cover everything from end-of-life management for applications, to version control and more.
Lastly, the onus of due diligence in vendor management (for GLBA, PCI DSS, SOX, FFIEC where applicable, the Bank Secrecy Act and more) is on the financial institution or retailer being provided the service.
How to Centralize Compliance Management
Without a formal security operations center (SOC), centralizing compliance management and optimizing threat detection and response is extremely difficult. Not to worry—this doesn’t mean you need to go out and built a multi-million-dollar SOC from the ground up.
SOC-as-a-service includes a SIEM, security expertise, managed detection and response (MDR), ongoing risk management and vulnerability scans, and other core services that affordably streamline compliance management.
To learn more about SOC-as-a-service, click on the banner below.