In the US, there exist no meaningful national cybersecurity rules, but, as a practical matter, that is likely to change this year. But it's not coming from Congress. The catalyst is new rules slated to start in March from the New York State Department of Financial Services. In financial areas, that New York department is typically mimicked by a wide range of other state regulators, along with federal regulators. Hence, de facto national rules. The rules themselves (you can peruse the full guidelines here) are not especially controversial, primarily being security best practices. The rules insist on regular penetration testing and vulnerability assessments. They also establish strict encryption guidelines and require written access-control policies. Notably, however, the way they approach application security is somewhat novel, and the regulations do contain some language that might cause confusion.
The new rules set a 72-hour deadline for reporting incidents to the state, although when that clock starts is unclear. In addition, the rules define a cybersecurity event as "any act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt or misuse an Information System or information stored on such Information System."
That is what needs to be reported within 72 hours, and that definition seems problematic. Brian Fitzgerald, the chief marketing officer at CA Veracode, argued in a new podcast discussion that this may be difficult to enforce given the nature of today's typical attacks. "Oftentimes, these attacks take weeks or months to execute. The evidence may take weeks or months to put together. Many of the banks in question here are attacked literally thousands of times a day, in terms of people testing the networks or attempting to phish their users or anything like that," Fitzgerald said. "So how do you tell when an attack has gained some traction and how do you know when that traction has actually caused potential risk to the bank, the financial organization or the customer? That spectrum is very blurry," and one possible criteria could be if a company has "clear evidence that files that contained sensitive information were actually exfiltrated from your organization."
The big issue is that they define a reportable act as an "attempt, successful or unsuccessful." How realistic is it for large enterprises to report every unsuccessful attempt? Does that include any unsuccessful attempt at a password? Is that a legitimate user who made a typo or an attack attempt? Given the volume of failed attempts, what is the value in preparing that paperwork?
One area that was reportedly a subject of last-minute negotiations were exemptions for small businesses that employed "fewer than 10 employees including any independent contractors" or had gross annual revenue—in each of the last three fiscal years—of less than $5 million or which had less than $10 million in year-end total assets. Those definitions are key, given that federal guidelines have typically defined a small business as one with fewer than 100 employees. That means that a lot of companies may hear about a small business exemption and think that they are exempt, when they're not. Also, companies have typically considered only salaried employees. Given that these New York rules include any independent contractors in that list of 10, the number of "small businesses" that will be exempt may be tiny indeed.
The new rules also crack down on data retention. In the New York language: "Each Covered Entity shall include policies and procedures for the secure disposal on a periodic basis of any Nonpublic Information that is no longer necessary for business operations or for other legitimate business purposes of the Covered Entity, except where such information is otherwise required to be retained by law or regulation, or where targeted disposal is not reasonably feasible due to the manner in which the information is maintained." The tricky part of this new wording is the phrase "no longer necessary for business operations or for other legitimate business purposes." Like the rules being pursued for global cybersecurity consistency by the European Union, the GDPR, this is going to force strategic conversations that companies should have had years ago.
If regulatory compliance is the reason, that's for the best. But companies today are retaining far more sensitive data than they need, and a healthy part of that is laziness. The data was needed for a project three years ago, for example, and when the project ended and the team was reassigned, no one bothered to go back and delete no longer needed data. Most likely, no one even saw it as their responsibility. Now multiply that by the thousands of such projects that the typical enterprise starts and stops each year, and the problem becomes clear. Even worse, this orphaned data is solely secured by the requirements that existed at the time it was created. No one is going back and upgrading security on forgotten data. These new rules will give IT a reason will keep track of these efforts or face fines.
All in all, though, this New York effort is encouraging, especially in the way that it highlights application security awareness. Fitzgerald argued that this reflects a major improvement in regulatory thinking. "They are showing some real insight into some of the specific areas of security that the regulators are going to identify as important and, in some cases, as required," he said, citing regulations surrounding training on secure coding as a particularly encouraging sign. The New York state rules mandate "education of your developers and making sure that developers know how to actually write good code. They also focused on the testing of applications to ensure that there's some kind of validation for the security-oriented quality of the software that is developed," Fitzgerald said. These regulations, in a move away from past regulations, are considering security at every phase of the development lifecycle – from development to QA to production --- and that is certainly a positive development. Still, he added, it's not perfect and may need even more specificity in the near future. "Although there is an advocacy for testing here, there really isn’t necessarily a bar for how do I know when what I have is actually good enough," Fitzgerald said.
Listen to the AppSec in Review podcast: Making Sense of the New York DFS Cybersecurity Regulations to hear the full discussion and get more details on these upcoming regulations.
View our new guide for continued learning: Navigating the New York Department of Financial Services' Cybersecurity Regulations