As a blogger following data security laws and regulations, I’m occasionally rewarded with an “I told you this law would be important” moment. Earlier this month with the news that the FTC plans to update its dusty Gramm-Leach-Bliley Act regulations for data security. To refresh memories, GLBA covers data security and privacy practices of the US financial industry — banks, investment firms, mortgage lenders, financial advisors, consumer lenders, and more.
The GLBA’s data security regulations can be found in its Safeguards Rule, which in its current form provides very general requirements for security practices. To get a taste of the language, here’s what it has to say, “You shall develop, implement, and maintain a comprehensive information security program … contains administrative, technical, and physical safeguards that are appropriate to your size and complexity”.
Get the Free Essential Guide to US Data Protection Compliance and Regulations
And that’s as specific as it gets!
In explaining why it’s proposing to update the old Safeguards Rule, the FTC said in its official Notice of Proposed Rulemaking (NPRM) — you can read the full text here — that it wanted to consider “more detailed guidance as to what an appropriate information security program entails.”
NYDFS Cyber Regulation Directly Influences Safeguards Rule
This led the FTC to say that its amendments to the Safeguards Rule in the NPRM — drumroll, please — are based on New York State Department of Financial Services (NYDFS) groundbreaking cybersecurity regulations!
Once upon a time, we made a big deal about these regulations, calling it “GDPR-like” rules at the state level. And we’ve been pointing out that the states, particularly New York and California with its CCPA, are where data and privacy security innovation is happening.
With the FTC’s decision to model the revamped Safeguards Rule on New York State’s own data regulations for banks and insurers, our laboratories of democracy are doing their job at shaping laws on a national level. I told you so!
In the remainder of this post, I’ll cover the most important changes to the Safeguards Rule as discussed in the NPRM. Keep in mind we’ll have to wait for the FTC to officially to publish the proposed amendments to the Safeguards Rule, comments from stakeholders to flow in, and then for a final version of the rule to be approved by the FTC commissioners.
It will take a few months at least for all this to happen. But if all goes according to schedule, we could be seeing new data security rule for US financial institutions by the end of 2019.
Definition of Security Events
In defining a security event, the FTC directly quotes NYDFS’s definition and proposes that it is
an event resulting in unauthorized access to, or disruption or misuse of, an information system or information stored on such information system
This definition is important because it will encompass unauthorized access alone, with appropriate exclusions, as the threshold. Under the new Safeguards Rule, ransomware or DoS attacks would considered a cyber event (along with standard data theft, of course), which will then have to be monitored and appropriate actions taken to resolve.
The FTC regulators are well aware that financial companies have likely implemented controls on access rights. But they decided to add explicit language for access controls in the proposed update:
would require financial institutions to place access controls on information systems, designed to authenticate users and permit access only to authorized individuals in order to protect customer information from unauthorized acquisition
Note the language for only permitting access to authorized individuals.
Audit trails! What a great idea. The regulator’s proposal in the NPRM
would require information systems under the Rule to include audit trails designed to detect and respond to security events.
They define an audit trail as a time-stamped log of user access and activities. A point made by the regulators in the NPRM is that the log should help to detect when a system has been compromised, or when there’s been an attempt to compromise.
In other words, the audit log must have some practical value in reducing risk. And that leads nicely to the next safeguard, monitoring.
Monitor User Activity
The regulators understand that financial companies will need more than just an audit trail to detect attackers. They’re also proposing to add language that covers policies and procedures
to monitor the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information by such users
In the regulator’s discussion about this point, they say financial organizations should be able to use the technology to “identify inappropriate use of customer information by authorized users”, giving as an example the transfer of large amounts information for which has no legitimate use. By the way, they emphasize that this requirement is separate from an audit trail.
In other words, they are talking about monitoring technology that discovers unusual or abnormal activities from legitimate users. Varonis Inside Out Blog readers know this ain’t easy to do, and you’ll need some help.
Limits on Data Retention
The regulators want to force companies to eliminate data that no longer has “a business purpose.” Their NPRM proposal would
require financial institutions to develop procedures for the secure disposal of customer information in any format that is no longer necessary for their business operations or other legitimate business purposes
This is straight from the NYDFS Cyber Regulation, and similar to GDPR’s requirements to minimize data. However, unlike the GDPR, there’s no requirements for setting explicit time limits or duration. Maybe that will change?
Testing Effectiveness of Controls and Penetration Testing
Another great idea: test the controls you have in place. This is standard practice in any data security compliance standard. But the FTC regulators went further and proposed that you should
Regularly test or otherwise monitor the effectiveness of the safeguards’ key controls, systems, and procedures, including those to detect actual and attempted attacks … The monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments
Penetration testing! They’ve added the option of directly testing the controls through penetration testing, which is straight out of the NYDFS cyber regulation.
The NYDFS rules call for a minimum yearly pen testing schedule, but the FTC regulators will ultimately decide the frequency of pen testing, as with all the other proposals in the NPRM, after weighing stakeholder comments once the proposal is published.
In any case, the FTC explicitly referring to penetration testing is a major validation of this technique for finding IT security risks. As it happens, we have lots of information about penetration testing.
Risk Assessments and Data Categorization
Risk assessments are the cornerstone of any data security program. The original Safeguards Rule mentions risk assessments (see CFR 314.4 (b)), but says little more.
In the proposed updates, the regulators expand on the risk assessments process. In plain English, financial institutions are to have a plan that identifies threats, works out criteria for evaluating the risks in their information systems and data, and then explain how these risks will be mitigated. You perform these risk assessment periodically and adjust your controls accordingly.
Tightly coupled with this is a new control wherein you “identify and manage the data, personnel, devices, systems, and facilities that enable you to achieve business purposes.”
What does that mean?
It turns out that you’ll need to inventory the data in your system — that is find and classify the data— to help evaluate risks. It’s an important point, which is found in the discussion of the changes. I’ve taken a screenshot of the section of the NPRM wherein this is explained. Please gaze upon it and appreciate the implications.
The proposed update to the Safeguards Rule effectively requires financial organizations to scan and classify data. Just as a reminder, GLBA refers to nonpublic personal information (NPI), which is personally identifiable information that is not publicly available. So social security, credit card, bank account, etc. are all NPI. Financial information that is available on-line for legal reasons— housing transaction, say — are not NPI.
Incident and Risk Reporting
The FTC regulators proposed that financial organizations have an incident response plan. At this point, the regulators have stopped short of requiring security events to be reported externally. This, of course, diverges from the NYDFS rules, which does have a requirement for reporting “material” security incident to the state regulators.
Based on their discussion in the NPRM, the FTC regulators are open to the possibility of a notification requirement, and they will decide this based on feedback from the public comments. We’ll have to wait and see on this one.
However, like the NYDFS rules, there is a proposal that financial institutions to produce an annual report
to [the financial institution’s] board of directors or equivalent governing body” regarding the following information: 1) the overall status of the information security program and financial institution’s compliance with the Safeguards Rule; and 2) material matters related to the information security program, addressing issues such as risk assessment, risk management … results of testing, security events or violations and management’s response.
The report is to be prepared by a Chief Information Security Officer, who is a qualified individual that’s been designated for overseeing “the financial institution’s security program and enforcing its information security program.”
Under the news Safeguards Rule, a financial institution’s CISO will have serious legal responsibilities: she will have to document yearly their compliance efforts, their current risk profile based on risk assessment, and any security events that occurred.
The changes to the Safeguards Rule will move data security requirements for institutions far closer to the GDPR model. And this obviously will be a gigantic shift for US financial companies.
I should add there are also proposed requirements for multi-factor authentication and encryption of data at rest and in transit. Regarding encryption, the regulators realize it may not be feasible in many situations, so they allow other “effective alternative compensating controls” that will need to be approved by your CISO. These compensatory controls can include, for example, tighter authentication, access and monitoring controls.
So how can Varonis help?
Varonis has deep experience in helping companies meet not only the NYDFS cyber regulation but many other data security laws and compliance standards. We have solutions to help set up file access permissions to keep data from unauthorized users, capture file events for detailed audit logging and reporting, monitor user activity to detect abnormal usage, find and delete or archive data that’s no longer needed for business purposes, find, classify and check current permissions of PII to assess risks, and processes to insure that you maintain your data permission compliance.
To learn more, ask for a demo today!