We’ve all heard a lot about GDPR, but if you’re in the Financial Services industry, you’re probably aware of NYDFS compliance. NYDFS is actually the regulatory body (New York State Department of Financial Services) and in particular we’re concerned about the NYDFS Cybersecurity Regulation.
The regulation is “designed to promote the protection of customer information as well as the information technology systems of regulated entities and requires each company to conduct a risk assessment and then implement a program with security controls for detecting and responding to cyber events.”
Unfortunately, financial services often rely on many interrelated systems that have been growing for decades, making it difficult to assess, audit and apply consistent security across all systems.
Cloudentity has a unique combination of Identity Management and MicroPerimeter™ Security which help address some of the key areas for NYDFS compliance. In particular, let’s look at Risk Assessments, Audit Trails, Access Privileges, Incident Response Planning and MFA:
Companies are required to periodically conduct risk assessments that will be used to assess “confidentiality, integrity, security and availability of the IT infrastructure and PII.” (Section 500.09)
Assessing risk requires understanding who, and more importantly, what, is able to interact with APIs, workloads and data. This means assigning an identity to everyone and everything (no general service accounts) and understanding what those people and things are allowed to access with clear security policies.
When there is breach, the regulations require a clear audit of what was accessed and by whom. (Section 500.06)
With the explosion of microservices and the interaction of legacy systems with those services, it’s often difficult to understand what actually happened in a breach, which then leads to organizations having disclose the potential number of records that may have been accessed, even if it’s unclear how much data was actually exposed.
See MicroPerimeter™ Security Visibility for how Cloudentity not only provides end-to-end transaction logging with an immutable audit trail, but how we can detect traffic patterns that were otherwise unknown and un-auditable.
PII access must be restricted and the rules need to be reviewed. (Section 500.07)
Cloudentity’s Permission Service provides one of the most granular sets of access rules available. By creating a user managed set of rules for who gets to see personal information, this service adds consent to access rules, meaning individual records should not be exposed without express permission.
Incident Response Plan
Organizations are required to develop a written plan to document internal processes for responding to cybersecurity events, including communication plans, roles and responsibilities, and necessary remediations of controls as needed. (Section 500.16)
Part of responding to an incident involved understanding the security architecture of your organization. Unfortunately, there are a lot of different security systems with their own architecture, their own rules, and different owners.
Cloudentity helps solve this frankencode nightmare by integrating security into the DevOps pipeline, or DevSecOps. By separating security from code, and at the same time including it as part of the CI/CD pipeline, security systems, access rules, and enforcement become consistent across the enterprise, making it easier to develop an Incident Response plan, and less likely that the 2AM scramble will result in even more breaches.
See Embedding Security in your CI/CD Pipeline for more information.
The regulations require MFA for any individual access the internal network, “to protect against unauthorized access to Nonpublic Information or Information Systems.” (Section 500.12)
Quite often the internal systems are the least protected, assuming VPN or IP whitelisting is sufficient to attest that the access is from an internal employee. APIs in particular often do not require MFA as OAuth doesn’t specifically support it.
Cloudentity integrates MicroPerimeter™ enforcement with CIAM to specifically assess the MFA status of the current token; this can be based on a timeframe since the last MFA activity was executed and can be different for different services, so high-value, Nonpublic Information can be secured with MFA but other systems may not require it, even with OAuth and OIDC.
See CIAM Integration for more details.
While regulations like NYDFS Cybersecurity and GDPR seem to be creating daunting logistical nightmares for companies in the digital age, there is a path out of the wilderness to creating more manageable, cleaner systems without having to completely “rip and replace” existing infrastructure.
Contact us if you have any questions – we’re happy to help you navigate these issues with real-world solutions.