FIVE EASY STEPS TOWARD MEETING THE NEW YORK STATE CYBERSECURITY REQUIREMENTS

Frederick W. Scholl

The New York State Cybersecurity Requirements (23 NYCRR 500) for financial services companies went into effect on March 6, 2017.  The 43 requirements in this regulation may seem daunting, especially considering the numerous other state and federal cybersecurity regulations that are applicable to covered entities.  Rather than running out to implement them before the August 28, 2017 deadline, a better approach is to build out a security framework, through which 23 NYCRR 500 and other regulations can be simultaneously satisfied and tracked.  Use of a security framework has the added benefit that you will be following best security practice to protect your organization’s information and customers.  The NIST Cybersecurity Framework (CSF) is just such a framework for this purpose (Draft Version 1.1 is available on the NIST website here).

The new cybersecurity regulation is a requirement for all but the smallest financial institutions in New York State.  These include:  banks, insurance companies, agents and brokers, trusts, mortgage brokers, private banks and 20 other business categories listed on the DFS website.  Many firms may not be familiar with cybersecurity regulations, although headlines constantly report on security breaches.  According to the NYS Attorney General, data breaches in New York State were up 40% in 2016; hence the new law.

The most important thing to note about 23 NYCRR 500 is that it is based on the NIST CSF.  NIST CSF is built around the five functions of:  Identify, Protect, Detect, Respond and Recover.  This table shows the five security functions called out by the CSF and the principle functions called out by 23 NYCRR 500. 

You can therefore use the CSF as a basis for meeting the new regulations.  The big benefit of this approach is that you can then use CSF to support other compliance regulations you may need to meet.  The diagram below illustrates this.  By following the CSF security framework, you will be able to effectively report on a range of compliance requirements.  If you accept credit cards, you will need to be PCI DSS 3.2 compliant.  If you are a NYS registered HMO, then you also need to be HIPAA compliant.

There are some differences to be aware of between the individual compliance regulations and the CSF.  For example, let’s compare the 23 NYCRR 500 and NIST CSF.  Generally, CSF is broader in scope.  It has 23 categories of security activities and 98 subcategories.  23 NYCRR 500 has 43 activities.  On the other hand, some of the state regulations are spelled out in detail, whereas the CSF leaves the details to the “implementer”.  You need to be aware of these details to meet the regulation’s requirements.  For example:

  1. NYS requires designation of a CISO (Chief Information Security Officer) role, either internal or outsourced.  CSF requires that senior executives and all staff understand their roles in security, but does not require a CISO designation.
  2. NYS requires organizations adopt a cyber security program.  NIST CSF is voluntary.
  3. NYS requires the CISO provide an annual written report to the board.  CSF requires only that risk management processes are established.
  4. NYS requires annual pen testing.  CSF says asset vulnerabilities must be identified and documented.
  5. NYS requires risk based vulnerability testing every six months.  CSF requires a vulnerability management plan.
  6. NYS requires saving cybersecurity related records for five years.  CSF requires proper data lifecycle management and following legal and regulatory requirements.
  7. NYS requires regular review of application security programs.  CSF recommends risk management processes be established and a systems development lifecycle be established.
  8. 500.17 requires annual certification and notation of remediation efforts, submitted to the Superintendent of Financial Services.  These types of details are regulation specific and not in the CSF.

A detailed crosswalk between CSF and 23 NYCRR 500 is attached to the end of this post.

A big plus in the CSF is that it recognizes maturity levels for security.  An effective security program cannot be built in a few months.  It should be planned around attainment of defined maturity levels.  NIST recognizes four such levels, or tiers in the NIST jargon.  23 NYCRR 500 also implicitly recognizes a maturity path for organizations.  This is described in Section 500.22, Transitional Periods.  A number of the requirements are extended out two years.  This is actually a good idea, because it gives businesses time to plan a cost effective, repeatable method for meeting the regulation.

All in all, 23 NYCRR 500 appears to be an effective regulation:  only 14 pages long; based on the latest cybersecurity thinking (NIST CSF); and implementable in stages. 


CROSSWALK BETWEEN CSF 1.1 AND 23 NYCRR 500

 

 

 

 

Banking on Cyber Security:  How Financial Institutions Can Protect Their Assets

Introduction

Financial institutions are under attack by all manner of cyber thieves.  And why not”?  As Willie Sutton said, when asked why he robbed banks:  “because that’s where the money is”.  More important today is the fact that only about 10% of the world’s population has more than $65,000 in assets.  That leaves 6+ billion people with fewer assets, some of whom may decide to participate in criminal activities.  While such activities were once confined to local targets, the rise of cyber arms dealers enables almost anyone to join a global cyber hacker gang.

To combat these threats State and Federal financial regulatory agencies have issued new cyber security standards and guidelines.  Unfortunately, these regulations do not suffice to protect your institution from cyber-attacks.  Instead organizations need to add continuous risk management to baseline compliance requirements.  In this note, we look at evidence based risk analysis as one technique to build a better cyber defense.

Regulations Multiply

Banks today complain that they are over-regulated.  The cluttered landscape of cyber security regulations supports this claim.  Here is a short list of applicable regulations that require a cybersecurity program.

It’s difficult to build an effective security program around all of these compliance requirements.  For one thing, they are updated only infrequently, while hackers are changing tactics on a monthly basis.  Secondly, there are simply too many masters to develop a comprehensive security program, without significant holes or overspending.

Focus on Security, Not Just Compliance

Nevertheless, many organizations try to build a good cyber security program around compliance.  This is understandable, since compliance regulations are traditionally top of mind in the financial industry.  The resulting program looks like this: 

The challenge is that compliance needs do not make a good security foundation.  Gaps may exist, and compliance requirements may not be keeping up with threats.  A better approach is to turn this diagram upside down to give: 

A strong and comprehensive security program can support any compliance requirement.  The security program itself is built on a strong risk management effort based on best practices.  One such “best practice” is the NIST Cybersecurity Framework (CSF).  A key part of the CSF is to identify threats to the organization.  An important component to facilitate threat identification is “evidence based risk assessment”.

Using Evidence Based Risk Management

Cyber risk management is the process of minimizing information security risks across the organization.  Risk itself is:

Risk = Likelihood X Impact

Risks are best enumerated around business assets and processes.  These might include:  risk of ATM machines being hacked; risk of insider wire fraud; risk of third party being breached, etc.  The difficult part of this equation is determining the likelihood of an attack.  I am a big believer in evidence based risk analysis to help answer this question.  This is the process of figuring out how many similar events have occurred in your industry, or location.  This information, in turn, can be obtained from news reports, databases or court cases.  You wouldn’t think of opening a new branch without obtaining crime reports for the area.  You can’t prevent crimes, but you can implement appropriate and necessary security controls for your location.  It’s the same thing for defending your digital assets.  You need to evaluate the relevant “cybercrime” reports.  You cannot defend all types of cyber-attacks equally well.  Evidence based analysis helps prioritize security investment plans.

Example:  Financial Institution Privacy Breaches

The Privacy Rights Clearinghouse maintains a public database of breaches across industries.  The total number of records breached is 907,453,926 since they started record keeping in 2005.  I looked at the financial industry results for two time periods, 2010 and 2016-2017 to try to see any trends in the data.  The results are shown in the chart.

It’s pretty obvious that hacking attacks have been increasing and that financial institutions’ defenses in this area need to improve. 

This type of thought process should be used in your risk management process.  You need to look at not only privacy breaches but also data integrity breaches (wire fraud) and denial of service attacks.  You should have external industry data and data regarding security events and incidents that have occurred in your own organization.  In this way, you can prevent surprises and be best prepared to deal with the inevitable cyber-attack.

 

Third-Party Vendors: 6 Tips to Manage IT Security Risk

Third-Party Vendors: 6 Tips to Manage IT Security Risk

How well do you know your third-party vendors? Recent cyber attacks on well-known entities via third-party vendors should make all companies cautious about who they're doing business with. Here's how you can avoid security risks from third-party vendors.

PCI Compliance: How to Develop a Remediation Plan

PCI Compliance: How to Develop a Remediation Plan

If a QSA identifies compliance issues during the readiness assessment, you may be able to address some of those issues by reviewing and minimizing your scope of compliance, but existing issues will have to be properly remediated to comply with PCI DSS Standards.