Risk

5/16/2017
02:00 PM
Mark Sangster
Mark Sangster
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

The Wide-Ranging Impact of New York's Cybersecurity Regulations

New York's toughest regulations yet are now in effect. Here's what that means for your company.

One of the harshest cybersecurity regulations to hit companies in the US recently went into effect in New York. The state regulator, the New York Department of Financial Services, introduced its Cybersecurity Requirements for Financial Services Companies (23 NYCRR Part 500), a regulation designed to tighten cybersecurity practices across a wide selection of companies, which became effective on March 1, 2017.

Part 500 covers anyone "operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law." In practice, this includes banks, investment firms, insurers and licensed lenders, holding companies, charities, and service contractors. They should all be watching this regulation and preparing themselves for compliance.

The rules are highly prescriptive, going into substantial detail about the cybersecurity requirements for covered entities and imposing significant reporting requirements on those companies.

Covered entities must assess internal and external cybersecurity risks, and then use technology and policy to mitigate them. They must also detect and recover from cybersecurity events. All of this must be overseen by a designated senior official (effectively, a chief information security officer or CISO). This official is not only responsible for the cybersecurity program but also for submitting annual reports to the regulator. Under section 17, the CISO must also report a cybersecurity event within 72 hours.

This increase in cybersecurity reporting requirements removes any chance of plausible deniability for companies covered by the rule. It defines a cybersecurity event as any event that another regulator would deem reportable. The blanket coverage means that a company cannot claim ignorance of reporting standards as an excuse for not reporting an event.

These reporting rules are already in place now, with the first section 17 reports due in February 2018. In February 2019, the burden on covered companies will increase further when reporting on several other sections comes due.

These reports include:

  • Penetration testing: Companies must provide annual proof of penetration tests, which use specialists to test weaknesses in company infrastructure.
  • Audit trails: The regulation requires covered entities to prove audit systems showing how they detect cybersecurity events.
  • Secure development: Under section 8, regulated companies will have to prove that they use secure software development processes for in-house applications and that they test the cybersecurity of external software.
  • Periodic risk assessments: Cybersecurity assessment is not a one-shot deal. February 2019 will also see companies submit their first reports under section 9, which demands periodic risk assessments to show that they are still compliant.
  • Multifactor authentication: Under section 12, they will need to use stringent multifactor authentication (for example, the use of hardware tokens or risk-based access controls).
  • Encryption: Section 15 will also need companies to report on the adequate encryption of sensitive data by this date.

Third-Party Assessments
In February 2020, the reporting requirements ramp up again, when companies will have to extend some of these security considerations outside their own walls. They will be forced to file reports about their third-party service providers' cybersecurity, too. This involves assessing the cybersecurity risks at companies processing their data, and explaining how they did it. The regulations require periodic risk assessments, and measures such as encryption, access controls, and cybersecurity event reporting must also be built into service provider contracts.

In practice, this means that should a service provider managing a company's data suffer a security breach, the company itself will come under scrutiny, and must prove that it conducted proper due diligence on the service provider.

While companies must file reports by various dates, Part 500 requires them to be compliant well before those reporting deadlines. The 180-day transition period for NYCRR began on March 1, meaning that they must prove by the end of August that they have a compliance program, effective policies, and a CISO in place, even though the first reports aren't due until the following February.

Other compliance deadlines loom one year after Part 500's effective date, which requires compliance around March 2018, and there are more in September that year. In practice, companies must be able to prove that they are able to scrutinize cybersecurity practices at their third-party providers a full year before they are due to report on them.

What this means is that companies must be working now to assess their sensitive data and how they are protecting it. They must then conduct a gap analysis to see what measures are necessary to meet Part 500's many requirements.

NYCRR is one of the strictest cybersecurity regulations at a federal or state level, and each of the requirements discussed here could take months of work. Take it seriously, and bring in a third-party advisor where necessary, because the regulator will not take kindly to those companies that violate its new rules.

Related Content:

Mark Sangster is a cybersecurity evangelist who has spent significant time researching and speaking to peripheral factors influencing the way that legal firms integrate cybersecurity into their day-to-day operations. In addition to Mark's role as VP and industry security ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
New Bluetooth Hack Affects Millions of Vehicles
Dark Reading Staff 11/16/2018
Understanding Evil Twin AP Attacks and How to Prevent Them
Ryan Orsi, Director of Product Management for Wi-Fi at WatchGuard Technologies,  11/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19406
PUBLISHED: 2018-11-21
kvm_pv_send_ipi in arch/x86/kvm/lapic.c in the Linux kernel through 4.19.2 allows local users to cause a denial of service (NULL pointer dereference and BUG) via crafted system calls that reach a situation where the apic map is uninitialized.
CVE-2018-19407
PUBLISHED: 2018-11-21
The vcpu_scan_ioapic function in arch/x86/kvm/x86.c in the Linux kernel through 4.19.2 allows local users to cause a denial of service (NULL pointer dereference and BUG) via crafted system calls that reach a situation where ioapic is uninitialized.
CVE-2018-19404
PUBLISHED: 2018-11-21
In YXcms 1.4.7, protected/apps/appmanage/controller/indexController.php allow remote authenticated Administrators to execute any PHP code by creating a ZIP archive containing a config.php file, hosting the .zip file at an external URL, and visiting index.php?r=appmanage/index/onlineinstall&url= ...
CVE-2018-19387
PUBLISHED: 2018-11-20
format_cb_pane_tabs in format.c in tmux 2.7 through 2.8 might allow attackers to cause a denial of service (NULL Pointer Dereference and application crash) by arranging for a malloc failure.
CVE-2018-19388
PUBLISHED: 2018-11-20
FoxitReader.exe in Foxit Reader 9.3.0.10826 allows remote attackers to cause a denial of service (out-of-bounds read, access violation, and application crash) via TIFF data because of a ConvertToPDF_x86!ReleaseFXURLToHtml issue.