(As Published in Law360)
If you have complied with the New York Department of Financial Services requirements to date, your cybersecurity program is already in place and the foundations are laid for compliance with the September obligations. On or before Sept. 1, 2018, DFS covered entities subject to Part 500 must be in compliance with Sections 500.06, 500.08, 500.13, 500.14(a), and 500.15. This article provides interpretation and analysis of what these requirements mean in practice.
Section 500.06 — Audit Trails
Audit trails are important because they create a record of transactions for continuity of business in the event of an incident, and allow entities to effectively monitor activity on their network. Without an effective monitoring solution, it is virtually impossible to know if malicious actors, internal or external, are present and taking actions affecting the entity’s network or the transaction data stored thereon. While 500.06(a) does not go as far as to expressly require monitoring of audit trails, a fair reading of 500.06(a)(2) certainly implies monitoring by including the language “audit trails designed to detect and respond to Cybersecurity Events.” Commercial tools are available to monitor audit trail logs and identify aberrations and suspicious activity.
It is important to note that not all systems need to employ audit trails pursuant to 500.06; only those that “are designed to reconstruct material financial transactions sufficient to support normal operations and obligations of the Covered Entity.” Furthermore, this requirement is limited to only those systems deemed material in the risk assessment conducted in advance of the March 1, 2018, deadline. The risk assessment may have determined that the impact of compromise on integrity and availability of certain systems is sufficiently low that the risk was accepted. The first step in preparing to deploy audit trails should be a thorough assessment to determine to which systems the rule applies, including a review (and perhaps reconsideration) of your risk assessment. What is considered a material system is not entirely clear, but a safe position would be that any system containing records of financial transactions critical to your business should include audit trails, particularly where records of those transactions cannot be found elsewhere.
Section 500.08 — Application Security
Section 500.08(a) requires the cybersecurity program include steps to ensure security of applications both commercially available and developed in-house. As with many of the DFS requirements, the scope of 500.08 is limited in that the cybersecurity program is based on the entity’s risk assessment. This limitation means that entities have the latitude to limit the scope of 500.08 to those applications posing a risk to the entity’s operations or nonpublic information. An application developed in-house to track vacation time, for example, would not pose a high risk to the organization if compromised, and it is therefore suitable for the entity to accept the risk of taking a less thorough approach to development. Applications critical to the entity’s operations or otherwise containing nonpublic information, however, are certainly subject to the requirements of 500.08.
In short, if you are developing applications that will host nonpublic or otherwise critical information, you need a very robust and documented development process. Even more so if the application will be externally-facing. The Open Web Application Security Project is a good place to start. OWASP is an online community providing open source information, articles, and guides designed to improve application security. The OWASP development, testing and code review guides provide an excellent and industry-accepted framework for ensuring the security of applications developed in-house. Incorporating the OWASP framework and controls into your development policies and procedures will provide defensibility and streamline this requirement for your CISO during the annual review required under 500.08(b).
Section 500.08’s requirement for assessment of commercially available applications used to house nonpublic or critical data is effectively just change management. Change management is an essential tenet of any information security program and means that, before any change is made to an entity’s environment, be it downloading new software onto one individual’s machine or migrating the whole company to a new document management system, that change is thoroughly tested, reviewed, and approved by persons with the appropriate skill set. Most large information technology departments will have a change management committee to evaluate alterations to the environment. The reason for change management is simple — you cannot know the effects a new application may have on your environment until it goes live. An appropriate change management procedure should include deploying the new application in a secure test environment separate from the live production environment. This step provides a safe sandbox for evaluation of the up- and down-stream effects on other applications and network configurations, as well as evaluation of the application’s potential vulnerabilities. The application testing and approval process should be thoroughly documented.
Section 500.13 — Limitations on Data Retention
Data retention should only be a matter of following the data governance policy created as part of the overall cybersecurity policy in compliance with the first DFS deadline in August, 2017. Data retention is an integral part of data governance, and can be summed up in five words: delete what you don’t need. The concept is intuitive; data grows exponentially in today’s digital world, and the more you have stored in disparate locations, the greater your risk. Data governance and retention policies should clearly identify the types of data you maintain, and the risks and required retention periods of each. Section 500.13 requires only policies addressing nonpublic information, but, from a best practices standpoint, your governance and retention policies should include all types of data you possess. Unfettered creation, storage, and retention of data will invariably result in an expensive headache in the future when the volume becomes too great and necessitates cleaning up. A data map outlining the various locations in your environment where data is stored, including what types of data live where, is essential to effectively destroying unnecessary information pursuant to a retention policy.
Section 500.13 requires periodic disposal of any nonpublic information “that is no longer necessary for business operations or for other legitimate business purposes.” Exceptions are made for data required to be maintained by law or regulation, as well as data whose destruction is infeasible due to the manner in which it is stored. Your data governance and retention policies should classify and identify these different types of data and their retention periods. A broker-dealer, for example, is required to maintain trade blotters for six years, but email and other communications only three years. Understanding these retention periods and actually destroying the data at the end of the period is key. Quite often companies know their retention periods and have a destruction policy, but fail to follow through on the destruction. This oversight leads to an unnecessary accumulation of data that is a liability from an information security and litigation standpoint, and, after Sept. 1, 2018, could result in an enforcement action from the DFS.
Section 500.14(a) — Training and Monitoring
The deadlines for compliance with 500.14 are divided between the March and September 2018 targets. Section 500.14(b), which requires regular information security training, is one of the controls subject to the March 1, 2018, deadline. Section 500.14(a), which requires monitoring the activities of authorized users in systems containing nonpublic information, is subject to the Sept. 1, 2018, deadline. So why the split? The deadlines for these requirements were likely divided because the monitoring required by 500.14(a) dovetails nicely with the audit trail requirement in 500.06. Indeed, one could read 500.14(a) to be the audit trail monitoring not expressly required by 500.06(a)(2). But 500.14(a) does not stop with the systems logging financial transactions contemplated by 500.06(a)(1). Rather, it includes, again on risk-based grounds, any systems containing nonpublic information. Do not read the risk-based limitation on this requirement to mean that some systems containing nonpublic information do not need to be monitored. Risk analysis factors into the extent to which monitoring should take place. Systems determined to be of lower risk, but still containing nonpublic information, may require less frequent or less in-depth monitoring.
Monitoring the activities of authorized users is as it sounds — a requirement to review audit and access logs in certain systems to maintain an awareness of what users are doing. More importantly, to make sure that nonpublic information is not being altered, deleted or otherwise accessed without authorization. As mentioned in the discussion of Section 500.06, a wide variety of commercial tools are available to assist in these monitoring efforts. Absent a tool, monitoring takes the form of periodic audits of access records and audit trails, meaning that a sampling of these records are reviewed to identify inappropriate activity. Not every action by every user needs to be analyzed; just a sampling sufficient to unearth unauthorized behavior. Commercial tools are extremely helpful, however, because they identify suspicious and anomalous activity in your log files.
Section 500.15 — Encryption of Nonpublic Information
Section 500.15 requires encryption of nonpublic information both at rest in your environment and in transit over external networks. The DFS reduced the burden of compliance with 500.15 during the comment phase by limiting the requirements for encryption in transit to external networks only, rather than internal and external networks. This concession means that email traversing internal networks behind a company’s firewall does not need to be encrypted. Despite the appearance of further concessions in the form of permissible “alternative compensating controls,” the latitude effectively ends with the limitation to external transmissions.
To begin with, what does encryption at rest and in transit over external networks mean in practice? Data at rest is any data not in transmission via email or otherwise. Data in transit, as it sounds, is data being transmitted, usually, but not always, via email. Data at rest includes data sitting on servers, individuals’ hard drives, thumb drives, DVDs or any other structured storage method. Full disk encryption is the preferred method of encrypting data at rest, since the storage medium itself is encrypted rather than the individual files. Which is not to say that the data cannot be encrypted at the file level, but doing so may be more cumbersome from an administrative perspective. Encrypting data at rest on a file level may be an effective solution for data residing on existing unencrypted servers, since deploying full disk encryption on a server already containing data can be extremely slow and negatively impact user experience during the encryption process.
Encrypting data in transit over external networks, as applied to email, generally means using forced Transport Layer Security, using file encryption for email attachments, or encrypting emails with Pretty Good Privacy or the encryption tools built into Office 365. TLS provides encryption between two communicating networks. There are two types of TLS — forced and opportunistic. Forced TLS requires correct configurations on both ends of the communication, so may not be a viable alternative for communications with parties with whom you seldom communicate and have not configured forced TLS. Opportunistic TLS does not require coordination with the other party, but your communications will be encrypted only if the recipient also has TLS enabled. It is quite possible that the DFS would not find opportunistic TLS to be in compliance with 500.15 because it does not guarantee encryption in transit. When transmitting nonpublic information via email without forced TLS, the best solution may be to encrypt the email itself using public key encryption or the encryption options built into Office 365.
How about the alternative compensating control option? Section 500.15 permits alternative compensating controls for both encryption at rest and in transmission. Using alternative compensating controls is not a shortcut to compliance with 500.15. Effectively and defensibly employing a compensating control will likely require as much work, if not more, as complying with the letter of the regulation. Use of a compensating control will require a thorough and documented risk analysis, including an analysis of why the required control is really infeasible. It better be really infeasible, not just inconvenient. Generally, a compensating control should be as secure as the required control, in addition to taking into account any additional risk posed by not employing the required control. Reaching that level of security with controls alternative to encrypting at rest and while in transit, given the wide availability of compliant controls, would take some very creative thinking and likely a monumental effort.
While the controls required to be in place by Sept. 1, 2018, may pose a significant hurdle for some covered entities, the foundation laid in 2017 with the genesis of your cybersecurity program should streamline compliance. A prudent chief information security officer already has efforts to comply with the September 2018 controls well underway, if not already in place. If you are not among them, start immediately.