Seal Security Blog

NYDFS Finalizes Amendments to Cybersecurity Regulations: Adapting to New Requirements for Financial Services Companies

on November 1st, 2023 the DFS released the 2nd amendment to 23 NYCRR 500. Financial organizations operating in New York are required to update their vulnerability management programs in order to comply with the updated regulation.

NYDFS Finalizes Amendments to Cybersecurity Regulations: Adapting to New Requirements for Financial Services Companies

On March 1, 2017 the Department of Financial Services (DFS) introduced a regulation, known as 23 NYCRR 500, establishing cybersecurity requirements for financial services companies. This regulation, enacted by the New York State Department of Financial Services, specifically Part 500 of Title 23 of the Official Compilation of Codes, Rules and Regulations of the State of New York (NYCRR) is commonly known as the "Cybersecurity Requirements for Financial Services Companies". Since the implementation of the regulation, the cybersecurity environment has evolved significantly. The sophistication and prevalence of threat actors have increased, making cyberattacks more accessible and costlier to resolve. 

In response to these evolving challenges, on November 1st, 2023 the DFS released the 2nd amendment to 23 NYCRR 500. Financial organizations operating in New York are required to update their vulnerability management programs in order to comply with the updated regulation.

Key changes in the regulation:

The changes in the regulation from "Section 500.5 Penetration Testing and Vulnerability Assessments" to "500.5 Vulnerability management" involve several key alterations:

General Requirements: 

The new version emphasizes the development and implementation of written policies and procedures for vulnerability management in accordance with the entity's risk assessment. The focus is broader, covering not just testing and assessments but the entire management of vulnerabilities.

Specific Requirements:

• Penetration testing:

      • Before: Required annual penetration testing based on risks identified in the risk assessment.

      • After: Specifies penetration testing from both inside and outside the information systems’ boundaries by a qualified party at least annually.

• Vulnerability assessments:

      • Before: Bi-annual vulnerability assessments based on the risk assessment were required.

      • After: The new regulation requires automated scans and manual reviews for systems not covered by scans at a frequency determined by the risk assessment and after any material system changes.

Monitoring for new vulnerabilities: 

The new version adds a requirement for a monitoring process to be in place to promptly inform the entity of new security vulnerabilities.

Timely remediation of vulnerabilities: 

There is a new emphasis on the timely remediation of vulnerabilities, with priority given to those posing greater risk to the covered entity.

Overall focus shift: 

The original regulation focuses on specific testing intervals and methods (annual and bi-annual), while the updated version broadens the scope to include ongoing vulnerability management practices, like timely remediation and continuous monitoring.

Operational challenges

These changes mark the regulatory shift from reactive to proactive vulnerability management programs. Some of them can be implemented quickly; however, the new requirement for timely remediation of vulnerabilities is forcing organizations to modernize their security patching programs - as legacy ones will struggle to enable timely remediation of vulnerabilities.

Remediation of open source software (OSS) supply-chain

The challenge of timely remediation of vulnerabilities in OSS is twofold:

• Alert fatigue: there are over 20,000 new vulnerabilities discovered in OSS every year, and prioritizing their risk to the organization takes significant manual effort.

• Patch impact: when considering whether to apply a security patch, understanding its impact is very costly for larger organizations, mainly due to two factors  

      • Hundreds of instances of the same vulnerability necessitate finding the right owners to delegate the patching.

      • Security patches are not isolated from other code changes, each application owner needs to assess the patch individually.

Given these challenges, a significant investment in engineering and security resources is essential for effective remediation.

Seal Security - a practical approach for OSS vulnerability patch management

Seal Security is leading the charge in establishing an open source initiative to provide our users and the community with standalone security patches - that are guaranteed to not break compatibility when applied. Our sealed libraries provide organizations with an added security layer against malicious code changes and security vulnerabilities.

Verification against tampering

The patches are open source and signed to enable easy verification against tampering.

Test once, deploy everywhere 

Due to the patches being isolated from other code changes, our users can verify and test the security patch once - and then deploy it throughout the organization, without requiring each team to spend time on its verification.

Patching over prioritization: 

Many organizations are spending more time prioritizing patches over applying them, using Seal Security security teams can lead a “patch first” mindset for their organization, boosting the patching capacity of critical and high severity vulnerabilities to over 90%.

If you wish to learn more about how Seal Security already helps Fortune-100 companies modernize their OSS patch management, please book a demo

Related articles: