Oct 14, 2016 NY State DFS Part 500 Cybersecurity Regulations
The New York State Department of Financial Services (NYS DFS) recently issued proposed regulations for financial services firms in New York State to go into effect in January 2017, with demonstrated compliance required by affected firms (“covered entities”) by January 2018. The regulations are groundbreaking in several respects, in particular in that they include requirements for emerging (or not yet fully emerged) technology categories. There are also significant gaps in the regulations as written, though we anticipate that they will be filled as regulators gain familiarity with the technologies and their operations.
We believe that the ramifications of these regulations will be felt far beyond New York State-based financial services firms: All states, and most industries, will eventually adopt requirements similar to these. Therefore, while these regulations are obviously of greatest urgency to NYS-based financial services firms, enterprise cybersecurity professionals at all types of companies, and cybersecurity vendors and service providers should pay close attention.
On September 13, 2016, the New York State (NYS) Department of Financial Services (DFS) released proposed cybersecurity regulations for financial institutions. We refer to these as the “Part 500 Regulations.”
These regulations will be open for public comment for 45 days and are set to take effect on January 1, 2017, with documented compliance required by January 15, 2018. The proposed regulations apply to all entities that are licensed or registered under New York banking, insurance, or financial services laws, including state-licensed banks, savings banks, insurance companies, private bankers, licensed lenders, mortgage companies, and state-licensed offices of non-U.S. banks.
There are certain exemptions for smaller institutions: specifically, those with fewer than 1,000 customers in each of the last three calendar years, and less than $5,000,000 in gross annual revenue in each of the last three fiscal years, and less than $10,000,000 in year-end total assets, calculated in accordance with generally accepted accounting principles are exempt from certain sections. That is, to be exempt from these sections, an entity needs to meet all of the above requirements.
Under the proposed Part 500 regulations, covered institutions must:
- Appoint a chief information security officer with specific responsibilities;
- Deploy key technologies, including encryption, multifactor authentication, and others;
- Conduct regular assessments, including penetration testing, vulnerability assessments, and risk assessments;
- Ensure that senior management files an annual certification confirming compliance with these regulations; and
- Report to DFS within 72 hours any cybersecurity event “that has a reasonable likelihood of materially affecting the normal operation of the entity or that affects Nonpublic Information.”
Part 500: Details
Part 500 Definitions
- The regulations provide several definitions. We won’t repeat the entire lineup here, but we do highlight definitions that are particularly relevant, ambiguous, or nonstandard. Part 500 specifically defines: Affiliate
- Authorized user
- Covered entity
- Cybersecurity event (“any act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt or misuse an Information System or information stored on such Information System”) •
- Information system (“a discrete set of electronic information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of electronic information…”) •
- Multi-factor authentication
- Nonpublic information (which is defined, significantly, as “information that is not publicly available”—see definition below–and in practice, appears to be an umbrella term encompassing various types of PII, as well as “information that the tampering with which, or unauthorized disclosure, access or use of which, would cause a material adverse impact to the business, operations or security of the Covered Entity”)
- Person (“any individual, partnership, corporation, association or any other entity”)
- Penetration testing
- Publicly available information (“…any information that a Covered Entity has a reasonable basis to believe is lawfully made available to the general public from: federal, state or local government records; widely distributed media; or disclosures to the general public that are required to be made by federal, state or local law”)
- Risk-based authentication (“…any risk-based system of authentication that detects anomalies or changes in the normal use patterns of a Person and requires additional verification of the Person’s identity when such deviations or changes are detected, such as through the use of challenge questions”)
- Senior officer
- Cybersecurity program
- Cybersecurity policy
As we’ll discuss, some critical components of the regulations are not clearly defined, or defined in non-standard fashion.
Technology and Assessment Definitions
For example, as noted, while the regulations define “penetration testing,” they do not define “vulnerability testing.” This is significant because the regulations call for annual penetration testing and (in section 500.05) quarterly “vulnerability assessments.”
There are multiple definitions of “vulnerability assessments,” ranging from on-paper assessments of an organization’s vulnerability (typically provided by consulting companies) to automated vulnerability scanning and management from companies like Redseal, Skybox security, and many others. Part 500 doesn’t clarify which version of “vulnerability” assessment it is requiring. It is therefore unclear what is required as part of a vulnerability test, and what tools or services might meet that requirement.
The definition of “risk-based authentication” is also quite interesting and nonstandard. The regulations define it as, “any risk-based system of authentication that detects anomalies or changes in the normal use patterns of a Person and requires additional verification of the Person’s identity when such deviations or changes are detected, such as through the use of challenge questions.”
This is significant because there are currently no single technologies that deliver on this requirement; there are authentication tools, behavioral-threat analysis tools (such as products from BalaBit, CyberArk, Exabeam, Gurucul and many others) and risk-assessment tools (such as RiskSense). There are even tools that combine BTA and risk assessment (such as Bay Dynamics) but nothing (yet) that combines all three. Vendors in these areas have contacted Nemertes requesting introductions to enable partnering to deliver compliance to Part 500. It is also worth noting that, the expansive definition of “Person” (including not just users but “partnership(s), corporation(s)… or any other entity), the required “risk-based authentication” actually could cover the entire technology area of third-party risk assessment. Again, the key point is that there is no single tool, or tool suite, that addresses all the requirements.
The regulations also require the use of “defensive infrastructure,” again not defined, but which is implied to be “tools and technologies that… protect Information Systems and Nonpublic Information stored on those Information Systems.” Yet there’s no meaningful definition of this “defensive infrastructure”—so no way to tell whether a company’s technology architecture complies. As we note below, without requiring a technical architecture, this requirement becomes challenging for companies to meet.
Public and Nonpublic Data Definitions
There is also the “everything that is not expressly permitted is prohibited” definition of public versus nonpublic data, which has significant implications for the technical elements of any security architecture.
In stark contrast to most security regulations to date, the NYS DFS regulations explicitly state that unless information is provably in the hands of third parties (i.e. disclosed to the media, government, etc.) it is “nonpublic”.
Practically speaking, then, the Part 500 regulations require covered entities to treat all information as though it were nonpublic—with defined requirements for access control, authorization, and auditing of this information. (Please see next section).
Part 500 Requirements
The regulations require the establishment of:
- A Chief Information Security Officer (CISO), with the responsibility of overseeing and implementing the cybersecurity program and generating a biannual report to be presented to the board
- A cybersecurity program that includes the following:
- A documented cybersecurity policy, addressing 14 specific areas defined in the regulations, that is reviewed at least annually.
- The use of “defensive infrastructure,” as noted.
- Annual penetration testing, as noted.
- Quarterly vulnerability testing, as noted (with no clear definition regarding what qualifies as vulnerability testing).
- Annual risk assessment that includes documented policies and procedures and identifies risks, provides a mitigation or acceptance strategy for these risks, justifying the decision to accept risk, and assigning accountability for these risks.
- Appropriate cybersecurity staffing (where “appropriate” is described as “sufficient to manage the entity’s risk”).
- Appropriate cybersecurity staff training (where “appropriate” is defined as “sufficient to stay abreast of changing cybersecurity threats and countermeasures”).
- Implementing and maintaining an audit trail system (with detailed requirements further defined in the regulations). The regulations require retaining audit trail records for a minimum of six years.
- Access privilege limitations for “nonpublic information” (again, note that effectively all information, under Part 500, is “nonpublic”). These access privileges are documented and reviewed annually.
- Third-party information security policy, which is effectively a policy that extends documentation and risk assessment to third parties, and is reviewed annually.
- The use of multifactor authentication to protect access to nonpublic information (again, see previous caveats to this definition).
- Encryption of all nonpublic information in situ and at rest.
- Policies and procedures for identifying and destroying nonpublic information that is “no longer necessary for the provision of the products or services for which such information was provided.”
- Requiring all personnel to attend regular cybersecurity awareness training, with training updated at least annually.
- A written incident response plan that includes (among other items defined in the regulation) notification to DFS within a minimum of 72 hours of any event.
- A written statement, filed annually by January 15 of each year certifying that the Covered Entity is in compliance with the requirements set forth in this Part (Part 500). This statement should include all documentation (defined as “records, schedules, and data supporting this certificate”).
Part 500 Timeframe
As noted, the requirements are slated to become final on January 1, 2017. The initial date for compliance with Part 500 is January 15, 2018, assuming the regulation is finalized January 15, 2017.
Alignment With Nemertes Maturity Model
Philosophically, these regulations align quite well at the high level with the Nemertes Security and Risk Management Security and Maturity Model. (Please see Figure 1). Key areas of alignment include:
- Clear documentation of critical processes and policies;
- Regular review, at least once a year, of critical processes, policies, and technologies;
- Deployment of key bellwether technologies (including risk assessment and behavioral threat analytics tools); and
- Taking a risk-based approach to vulnerability assessment.
In essence, Part 500 documents much of the thinking that has gone into Nemertes’ own maturity model and frameworks. We have not been surprised to see many of the key concepts articulated here, particularly since we have worked with NIST to develop an effective cybersecurity risk assessment framework.
At a high level, then, we believe that compliance with Part 500 will actively serve to enhance the cybersecurity stance of many, if not most, companies. To the extent that companies are not doing what Part 500 requires already, the emergence of these regulations will provide a much-needed “kick in the seat of the pants” to move up the maturity curve. We are therefore heartened to see the regulations, and believe overall that they will assist companies in making the transition towards more mature cybersecurity practices.
Part 500 Challenges and Gaps
That said, Nemertes has some concerns with the regulations as currently structured. In particular, there are areas in which the absence or ambiguity of definitions can make it difficult or impossible for companies to comply with Part 500.
As noted, the regulations call for deploying technologies that don’t yet exist, or aren’t well defined (“risk-based authentication”… “defensive infrastructure”). This opens up a can of worms in which a company could conceivably end up making claims on behalf of its technology vendors that they deliver the capabilities required by Part 500. The obvious approach is for a CISO to require of all its vendors to validate that their products meet the Part 500 definitions, but since the company (not the vendors) is held responsible, even this approach carries risks and overhead. And since some of the technologies that are required don’t actually exist at present, it is actually impossible to directly comply with the letter of Part 500, although it is possible (and may be acceptable) to comply with the spirit of the regulations.
Public and Nonpublic Information
We are also concerned with the definition of “nonpublic information” as “information that hasn’t been explicitly been made public.” It’s not too much of a stretch to say that Part 500 considers any information that hasn’t appeared on the front page of the Wall St. Journal to be “nonpublic.” And it requires not only on-paper policies and processes, but also the configuration of specific technologies (multifactor authentication and access) to protect against the accidental or malicious disclosure of such information.
In practice, most companies have separate policies for “sensitive” (PII, HIPAA-protected, etc.) and “non-sensitive” information, with the assumption that “sensitive” information is a small-ish subset of all information. Inverting that assumption by classifying only a small subset of information as “public” means potentially making significant changes in business processes and technology investment. Companies that treat “sensitive” information as the exception rather than the rule will find these changes rather wrenching.
The regulations could also do better at clarifying exactly what types of scanning and assessments are required, and at what frequency. The only assessment that is 100% clear is the required annual penetration test (which is defined). In addition to penetration testing, however, Part 500 requires (in two separate places), a quarterly “vulnerability assessment” (section 500.05), which is not defined; and an annual “risk assessment” (section 500.09), which is also not defined, although it is described extensively in the section in which it is referenced.
This represents, by our count, a minimum of 5 (five) additional assessments per year if a company has been relying exclusively on penetration testing. Moreover, the additional assessments aren’t clearly defined, so it may be difficult to prove compliance with the intent of Part 500. (How can one prove that a particular set of tests deliver a compliant “vulnerability test”?)
Architecture and Roadmap
We are also concerned by the lack of a requirement for architecture and roadmap documentation. We understand that Part 500 is focused primarily on security operations, rather than architecture and planning, but the adage holds true: You can’t get where you’re going if you don’t know where you’re headed. An architecture and roadmap serves as a logical approach for structuring investment in security technology and staffing, and provides good insight into a company’s view towards future improvement.
There are good reasons that IT professionals often ask to see a vendor’s strategic plans. Knowing what’s coming can provide insight into the caliber of a company’s thinking today. And the ability to execute against a documented roadmap, meeting milestones effectively year after year, is a solid mark of execution and operational capability.
This same analysis applies to end users of technology, and in fact in our research we’ve found a strong correlation between having and architecture and roadmap—and revisiting both on a regular basis—and having mature security operations. We would therefore prefer to see Part 500 require a technology architecture and roadmap, with relatively high-level requirements as to what components (advanced security analytics, application security testing, etc.) each should comprise.
Although this is not the place to go into an architecture in depth, Nemertes has developed a reference next-generation cybersecurity reference architecture; we believe something like this should be included in the Part 500 requirements. (Please see Figure 2).
Another surprising absence is the lack of discussion of the role of cybersecurity insurance. Although Nemertes does not necessarily believe that cybersecurity insurance should be a required component of a cybersecurity program, procuring such insurance represents a potential strategy for risk mitigation. It’s worth noting that over half of the companies benchmarked in our 2016/2017 Security and Risk Management Benchmark and Maturity Model have purchased cybersecurity insurance, and many of the covered entities are actually developing such offerings. (Please see Figure 3). Therefore, it would be of more than passing interest for Part 500 to provide some guidance on the DFS’s views on the effectiveness of cybersecurity insurance in mitigating risk to covered entities.
In several places Part 500 mandates “appropriate” staffing without defining what staffing comprises “appropriate”. Nemertes has extensively benchmarked the size, roles, and responsibilities of effective cybersecurity organizations; overall, we find that most enterprise organizations, including financial services firms, are moderately-to-severely understaffed.
That said, determining the “right” staff size is nontrivial, as staffing depends heavily on the degree of automation (more automation means fewer humans are required), degree and type of outsourcing (again, more outsourcing means fewer FTEs are required), and precise roles and responsibilities (if application and network cybersecurity functions are handled well by the application and network infrastructure teams, the cybersecurity team need not be as large.
Still, it would be helpful for DFS to provide guidance, at least at a high level, on “appropriate” staffing level, given that “maintain appropriate staff count” is, in fact, a defined requirement.
The move to cloud is one of the most defining trends in IT today, including among financial services firms. Virtually every organization is deploying some form of cloud services—including financial services firms that have historically limited themselves to deploying technologies on premises. And the trend is towards a relentless increase in the number and types of resources (computing workloads and storage) moving to the cloud. (Please see Figure 4).
It is striking in this context that Part 500 fails to mention the word “cloud” even once. Think about that: The term “cloud” fails to appear in the entire document. There are only two possible explanations: Either the document’s authors believed that the existing requirements and definitions (including vague references to third parties, etc.) were sufficient to guide protection of cloud-based resources; or the authors believed that financial services firms are not moving to cloud-based services, and therefore require no guidance when it comes to cloud cybersecurity.
With all due respect to Part 500’s authors, both assumptions are deeply incorrect. The move towards cloud services represents a fundamental paradigm shift, more significant than even the emergence of the Internet in the early 1990s, and as such it requires explicit focus from regulators. And many Nemertes clients—including name-brand covered entities under the DFS’s definition—are moving aggressively towards the cloud, and will have significant resources there by the time Part 500 goes into force.
We believe that Part 500 should therefore explicitly focus on the protection of cloud resources, and compliance required of cloud services providers.
What Does It All Mean? Anticipated Ramifications
For New York State Financial Firms
For New York State financial firms whose operations are relatively mature, compliance with Part 500 should not represent an extreme effort over current operations. A mature cybersecurity operation includes, at the very least, the basics as described in Part 500: having a CISO, a cybersecurity program, solid documentation, regular reporting to the board, a defined incident response plan, etc.
Challenges that companies may face include the following:
- Deployment of not-yet-existent technologies, such as “risk-based authentication”. The first step lies in determining what, exactly, DFS means by these terms. Very mature organizations will likely find that a combination of their existing technology deployments will fit the requirement, particularly if they are already investing in behavioral threat analytics (BTA). However, even companies that are already deploying these technologies will likely need to implement some degree of integration to ensure they comply with Part 500.
- Appropriate access to, auditing of, and retention/destruction of nonpublic information and associated audit records. Again, very mature companies likely have a conservative policy towards these definitions. Less-mature companies may need to dramatically expand use of technologies like multifactor authentication now that most information is classified as “nonpublic.”
- Additional “vulnerability assessments” and “risk assessments”. Depending on what the DFS actually intends with these terms, this may be an area in which New York State companies may need to invest additional resources. Specifically, the DFS-acceptable definitions of these may be on-paper assessments; or they may require the use of automated tool suites.
Regardless of how mature a New York State financial services firm believes its cybersecurity operations to be, we recommend that New York State financial firms that meet Part 500’s definition of “covered entities” act immediately to launch a Part 500 compliance program. Depending on the size and maturity of the organization, this program might include:
- Reaching out to DFS to obtain clarification on the more ambiguous components of the proposed regulation
- Building out documentation and communications strategies
- Planning for, and carrying out, required assessments
- Investing in additional technologies
- Where needed, applying pressure to vendors and providers to enhance their offerings to enable Part 500 compliance
For Other Enterprises
Financial firms that operate outside of New York, or companies other than financial services firms, obviously need not take immediate action. However, there’s a strong possibility that other states and industries will begin adopting versions of their own Part 500s, so it’s well worth for these companies to launch a “Part 500 Awareness Program” with the twin goals of:
- Monitoring Part 500 adoption in New York State, particularly when it comes to challenges and pitfalls; and
- Carefully monitoring their own state governments and industry regulatory bodies to gain early warning of incipient regulations
For Vendors and Service Providers
For vendors and service providers, Part 500 represents a potential gold mine. Any time a government agency requires technology that does not yet exist (but is relatively easy to create given the current state of technology) it creates the ability to generate, in effect a new market—providing vendors and service providers with an opportunity to gain first-mover advantage.
We recommend that vendors and service providers seek to meet the Part 500 requirements via partnerships, rather than organic technology development. Downstream, as the regulations come into sharper focus, it may be possible to develop more capabilities in-house, but for now the right move would seem to be to work collaboratively with vendors in synergistic spaces, and with key customers, to deliver solutions that comply with Part 500.
Conclusion and Recommendations
Part 500 represents a major milestone in cybersecurity regulation. Enterprises and cybersecurity vendors alike should take immediate action to ensure that their organizations are appropriately informed (for all cybersecurity organizations); en route to compliance (for New York State financial firms); and engaged in developing solutions (for NYS financial firms and vendors). Large organizations should also contact the NYS DFS to obtain clarity on some of the more ambiguous definitions.