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.
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.
The changes in the regulation from "Section 500.5 Penetration Testing and Vulnerability Assessments" to "500.5 Vulnerability management" involve several key alterations:
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.
• 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.
The new version adds a requirement for a monitoring process to be in place to promptly inform the entity of new security vulnerabilities.
There is a new emphasis on the timely remediation of vulnerabilities, with priority given to those posing greater risk to the covered entity.
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.
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.
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 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.
The patches are open source and signed to enable easy verification against tampering.
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.
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
Legacy applications remain a persistent reality in production environments, and cybersecurity teams must confront the challenges they pose. Seal Security offers a solution to help businesses easily and effectively mitigate vulnerabilities and protect critical assets.
Open source libraries often depend on specific versions of other libraries, and those dependencies might have changed over time. When a library was built years ago, the environment it depended on no longer exists in its original form. Package managers like npm are designed to handle these kinds of issues by allowing version ranges for dependencies. So, how do we ensure we have the exact versions of every dependency when trying to fix old libraries?
Traditional open source vulnerability remediation is a significant bottleneck in modern security. Organizations often grapple with hundreds or thousands of high and critical vulnerabilities, yet the process of upgrading dependencies is a manual, time-consuming, and error-prone task, heavily reliant on developers.
Organizations are increasingly relying on open source software (OSS) to accelerate development and innovation. However, with great power comes great responsibility – and in this case, significant security risks. Enter the curated OSS catalog, a solution that ensures secure-by-default OSS usage. Let’s explore what a curated OSS catalog are and who stands to benefit from them.
Seal Security is excited to announce it’ll join Snyk’s Technology Alliance Partner Program, to provide a seamless integration and product experience for Snyk customers who want to streamline their open source vulnerability patching efforts using Seal’s solution.
This blog post explores the complexities of dependency management, unveiling why the constant update treadmill might not be the most efficient approach. We'll delve into the challenges developers face and propose alternative strategies for a more balanced and secure open source ecosystem.
Open source software has become an integral part of modern application development, enabling developers to accelerate their projects by leveraging pre-existing libraries and frameworks. Open source offers numerous benefits, yet it's not without its challenges.
As we approach the EOL, it's crucial to understand the current status of vulnerabilities in CentOS 7. The official docker container of CentOS 7 has 1 critical rated vulnerability, 13 high rated vulnerabilities, and 36 medium and low rated vulnerabilities. Even after installing all the available updates, we are still left with 2 highly rated and 17 medium and low vulnerabilities.
In today's interconnected world, software vulnerabilities pose a significant threat to organizations of all sizes. To address these risks, companies typically rely on timely updates and patches for third-party libraries. However, a new challenge has emerged in the form of protestware – software intentionally manipulated to convey messages, potentially causing unintended consequences or harm.