New York State DFS Delays Cyber Security Regulation Until March 1, 2017 After Industry Groups Expres
In September 2016, the New York Department of Financial Services (DFS) proposed a cyber security regulation (23 NYCRR 500) that would require banks, insurance companies and other financially regulated entities to adhere to broad cyber security regulations effective January 1, 2017. The proposed regulation provided a comment period through mid-November in which several industry groups responded with expressed concerns over the broad requirements the regulation imposes. (For detailed information regarding the proposed regulation, please visit our blog)
Several financial industry groups expressed concern that the regulation would introduce standards and requirements that are already covered by by existing cyber security requirements and that the proposal should be consistent with existing standards, such as the NIST Cyber Security Framework.
The NIST Framework is already widely used by financial firms (among other industries as well) and is a step in the right direction for standardized cyber security requirements and regulations between each state.
In fact, the following industry groups filed a joint letter on November 14, 2016 with the DFS expressing their concerns:
The Securities Industry and Financial Markets Association (“SIFMA”)
The American Bankers Association (“ABA”)
The Financial Services Roundtable (“FSR/BITS”)
The Financial Services Sector Coordinating Council (“FSSCC”)
The Mortgage Bankers Association (“MBA”)
The American Financial Services Association (“AFSA”)
The American Land Title Association (“ALTA”)
The New York Mortgage Bankers Association (“NYMBA”).
The letter submitted by these industry groups outline a variety of either overlapping requirements or those that are so broad that they cover almost anything maintained by a financially regulated firm. A recurring theme throughout the letter, and one that I personally believe is more sensible, is the recommendation that the regulation take an approach based on assessments of the level of risk instead of a "one size fits all" requirement. This would allow firms of different sizes performing different functions to target resources and controls on a variety of factors. A 3rd Party Loan Servicing Institution servicing $50M in Outstanding Loans is a much different risk than a 5 person Insurance Brokerage with $6M in Total Revenue.
Of the recommendations proposed by the
industry groups, they noted the following:
Notification to the DFS within 72 hours of any Cybersecurity Event that has a reasonable likelihood of affecting the “normal operations” of a Covered Entity or “affects” Nonpublic Information is unreasonable and may cause more harm than anything else -There may be millions of daily unsuccessful attacks against a firm which would need to be reported to the DFS. Imposing a requirement to provide notice to the DFS within 72 hours could both prevent a firm from devoting its resources fully to responding to a threat while also require firms to provide notice based on unconfirmed information about the incident.
The notification requirement also lacks a provision allowing for a delay in notification if a law enforcement agency determines that the notification would impede a criminal investigation, which appears in many states’ security breach notification laws, including New York’s General Business Law § 899-aa.
One of the proposal requirements calls for encryption of all nonpublic data that is linked or linkable to a person or otherwise constitutes Nonpublic Information, both in transit and at rest: Implementation of this requirement would require a great deal of resources, personnel time and technical expertise while ultimately yielding enormous delays in data processing and increasing the likelihood of data corruption. Implementing this requirement would also make it harder for a firm to adopt new technologies that could protect systems and data more effectively than encryption (such as tokenization). I will write a follow up post on the difference between encryption and tokenization and the advantages that can be gained through tokenization.
In addition to the above, the requirement to encrypt nearly all data at rest or in transit may ultimately weaken security controls by requiring broad distribution of encryption keys to allow applications to access such data. This increases the access points and vulnerability through which information could be hacked and accessed by cyber criminals. Secondarily, imposing the regulation would prevent institutions from performing adequate surveillance of such data to detect intruders. Lastly, as part of the 3rd Party Vendor Requirements, requiring all vendors to encrypt almost all data would be extremely impractical to administer and cause processing delays.
The regulation's requirement to maintain audit trails and log all activity for nearly every financial transaction would result in cluttered, unorganized data. Instead, the audit trails should be established by the level of risk posed by a financial transaction.
The requirement to perform annual risk assessments that cover nearly all technologies used by a firm would make it difficult for cybersecurity to prioritize sensitive or vulnerable information systems and threats therein. These assessments should explicitly be based on risk, meaning that a firm should be able to determine whether a given technology poses a threat and warrants an assessment.
Third-party monitoring requirements that apply to nearly every vendor and service provider do not prioritize higher-risk entities.
Luckily our tool at Cyberfense allows firms to simultaneously deploy third party assessments in mass quantities and continuously monitor the vendor's level of cyber maturity within each established risk domain at minimal costs.
The Multi-factor authentication requirement proposed that multi-factor be used for virtually every information system and access to nearly all types of data maintained by s firm. This is unrealistic and would create huge operational inefficiencies, ultimately leading to workarounds and noncompliance.
The proposal calls for annual penetration testing for nearly all technologies used by a firm, including low-risk systems. This again is inefficient and comes at a large cost.
The proposals limitation of access rights privileges might require firms to limit access privileges to every system, regardless of its use or risk profile. Setting this up and maintaining an information systems architecture of this degree would be an administrative nightmare.
The industry groups also detailed unintended consequences and impracticalities of implementing the regulatory requirements as they exist today:
As noted above, the requirement to conduct penetration testing annually and vulnerability assessments quarterly could extend to nearly every piece of technology operated by a firm. As the level of testing and assessment is not based on a firm’s assessment of risks and vulnerabilities, it would be excessively expensive and an administrative burden that most firms are not equipped to handle.
Starting with a cyber security risk assessment is at the business level focuses on the value of information and the costs involved if that information gets destroyed, stolen, or otherwise damaged. The value of information or a trade secret is established at a strategic level. Likewise, costs typically are defined in strategic terms like lost revenue, public relations efforts needed to restore brand image, and defending against lawsuits. When the potential losses are known for various types of attack they can be managed like any other typical business decision regarding risk. Then it becomes much easier to bridge the gap between business leaders at the strategy level and those at the technical level who would perform and/or manage the vulnerability assessment.
The regulation's six-year retention period for audit trail data is burdensome and does not materially improve cybersecurity. In fact, a weak security audit trail imposes a cyber threat for organizations.
Data deletion requirements apply to commingled data (where data of one kind is mixed with data of another kind) and cannot be implemented without significant resources, changes and new technologies to appropriately parse the data and seperate the data that should be deleted;
Since the annual certification form required to be submitted to the DFS by the Covered Entity lacks a mechanism to report areas that are not in complete compliance at the time of certification (but will be prioritized for compliance going forward), the required certification could result in a paper exercise of downstream certifications to shield senior management from liability, and even result in criminal liability if the program is found to be noncompliant;
Requiring Covered Entities to obtain representations and warranties from vendors that the service or product provided is free of vulnerabilities is in conflict with many third-party engagements where firms face liability waivers with respect to these issues. New vulnerabilities surface everyday and the use of Open Source Software is only growing, especially for smaller firms development firms, which can provide new vulnerabilities that are not detected and in breach of their warranty when a new vulnerability comes to surface. For smaller Covered Entities, requiring that contractual language be revised to include such representations and warranties (as well as audit rights) may not be possible when negotiating with larger third parties due to unmanageable liability concerns and the cost ti implement solutions that continiously monitor their product or IT infrastructure. This may force Covered Entities to use less reputable vendors as a result. Moreover, some third parties that engage in penetration testing force firms to disclaim liabilities associated with such tests.
The requirement that a Covered Entity designate a CISO (a) does not accommodate other titles that might already exist within a firm that fulfill the same functions as a CISO and (b) does not recognize how certain firms have information systems governed by the CISO of an affiliate or a subsidiary. Additionally, the requirement that the CISO present a report bi-annually to the Covered Entity’s board (and if no such board exists, to a senior officer responsible for the Covered Entity’s cybersecurity program), and to the DFS superintendent upon request, may necessitate creation of a new team to comply with this requirement and impose new job requirements that a Covered Entity's personnel is not equipped to appropriately manage. Now a Covered Entity is not only subject to cyber threats and managing this increasing exposure, but the increased liability imposed on the CISO and Covered Entity for not appropriately fulfilling the regulatory requirements.
The Takeaway:
In my opinion, this push back was needed for regulated entities to appropriately comply and maintain the security of their network as the main priority. Creating security regulations that apply to all firms regardless of size and risk creates an administrative burden that most are not equipped to handle from both a monetary and staffing perspective, while also subjecting those firms to increased liabilities. Security measure that are created to maintain regulatory compliance are not as effective as security measures a firm takes to ensure it's network is as protected and safe as possible. Although I do agree that state regulated entities dealing with financial data and PII do need to comply with some level of regulatory requirements, a framework that is established based on the firm's risk, size and scope of operations would be much more effective and at a much lower cost and administrative nightmare.
We will wait and see how the NY DFS respond
