The New York Cyber Security Regulation: An Application Security Perspective

cyber security regulation

I was reading through the New York City Department of Financial Services Cybersecurity Regulation – because what do you read when you’re in a hotel room in Las Vegas? Per usual, application security didn’t get a very long mention. I’m increasingly certain this is because most of the writers of regulations understand network security, but applications are all about DevOps and programmers and other people who don’t show up (or aren’t invited) to the IT Security table.

In this article, I’m going to help you interpret how the different parts of this cybersecurity regulation touch on AppSec – that is, your websites, your mobile applications, your internal payment systems and networked third-party services.

Let’s get started…

 

Section 500.02 Cybersecurity Program: Quick Overview

On a basic level, the regulation states that a company’s cybersecurity program needs to be based on risk assessment. Given that 30+ percent of the attacks on an enterprise come against the applications[1], application security needs to be a big component of your risk assessment exercise. So how do you assess the risks of your applications? Find all applications in use and score the current status of those applications in terms of number of open vulnerabilities, how long these vulnerabilities have been open, your remediation rate, and your window of exposure.

Policies and procedures are also important to have in place to address those risks. Because developers are ultimately the people who need to fix application vulnerabilities, this means sharing with them an idea of the business flow of vulnerability management; in other words, show DevOps how security fits into their software development lifecycle. This includes looking in both directions of the business process – Dev and Ops. It means adding developers’ ticketing systems and documenting stages of vulnerability into your policies and procedures, and integrating security testing wherever possible in the developer environment.

Then of course, you need to report and measure improvement. Measuring is usually where a vendor can help, and improvement is all about KPIs. Statistically, our customers tend to improve their risk posture 20-25% year over year by letting us help them manage their AppSec program, measured by closed vulnerabilities.[2].

Finally, you need to be able to detect events – such as those events that your firewall can’t see due to the fact that they’re legitimate traffic. If an authorized user is logged in, like a malicious insider or someone with stolen credentials, those events may need additional help to be detected as malicious. Providing that visibility is why runtime application self-protection (RASP) and web application firewalls (WAF) exist. If you don’t have these types of security solutions, you might not be seeing the attacks on your website.

 

Section 500.03 Cybersecurity Policy – How are you going to protect assets? 

According to the regulation, organizations must implement and maintain written policies for the protection of its information systems and nonpublic information stored on those systems. This includes  a large spectrum of policies, from basic information security, to data governance and classification, application development and quality assurance, among many others.

Data governance and classification is hugely important. Security metadata can be managed by third parties. Personally Indentifiable Information (PII) and Payment Card Information (PCI) data need to be identified where they flow into and out of applications. Is any of the data stored? This includes passwords and login information. Access controls are also important. Insecure configurations and identity management can lead to compromised systems.

 

Section 500.04: Get a CISO – AKA “Someone in Charge of Information Security”

This is the same as the Data Protection Officer requirement brought up by the GDPR. I already wrote a blog on this, so let’s just say you need to appoint “Someone in Charge of Information Security” and give them the tools to do their job.

They need to be able to communicate the security policies to all internal and external interested parties. They need to add AppSec into their Risk Identification methodology and planning. Logically, they need to then measure overall effectiveness of their plans via reporting and KPIs. Finally, they need to be able to document events of note or interest. For AppSec, WAF/RASP reports are brilliant for this, and they can be monitored by a SOC or SIEM.

 

Section 500.05: Penetration Testing and Vulnerability Assessments – It’s all about preventative care

The section calls for monitoring and testing, to be developed in conjunction with the company’s risk assessment. Monitoring and testing should include continuous monitoring or regular penetration testing and vulnerability assessments. Any systems with PII and PCI data need annual penetration testing. Any changes that are identified (IT Security is often left out of the loop on changes to the website or their applications) must be reported.

While it’s true that companies need bi-annual vulnerability assessments, why stop there? For websites and internal systems, dynamic scanning can be done on a constant basis. I think this fits in beautifully with continuous assessments, as the regulation dictates.

 

Section 500.08: Application Security  – Finally we address AppSec directly, right?

I’ll quote the entire section:

“Each Covered Entity’s cybersecurity program shall include written procedures, guidelines and standards designed to ensure the use of secure development practices for in-house developed applications utilized by the Covered Entity, and procedures for evaluating, assessing or testing the security of externally developed applications utilized by the Covered Entity within the context of the Covered Entity’s technology environment.”

Simply put, test the source code, or binaries if third-party coders won’t show you their code. The further left you move security into the software development lifecycle, the cheaper it is to fix problems you find.

 

Section 500.09 Risk Assessment – Know what to fix, when

You have many applications, and many vulnerabilities. You need to be able to assess where the most risk lies and how to prioritize remediation. This information, combined with threat scores and vulnerability severity, gives you Risk Assessment for AppSec. It’s important to give the right reports to the right people. Your development team needs to know what to fix in their applications, while the CISO needs an overall picture. Make sure the right reports and information get to the right people.

 

Section 500.10 Cybersecurity Personnel and Intelligence – Don’t go at it alone 

Obtain help from experts when you need it. Work with vendors that act as extensions of your security teams. If you are a DevOps person, you need to know best practices and work on constant improvement. If you are on the security side, make nice with your developers and help them understand security. Computer-based training specific to teaching OWASP Top 10 and other secure coding methodologies and resources are available.

 

The Bottom Line

Remember that regulations often serve as minimum guidelines. Many organizations that suffered a breach were “in compliance”, yet their information and applications were still compromised.

To read New York’s new rules for yourself, here is the regulation in its entirety. According to the opening notes, the official reporting starts February 2018.

 

Are you ready? Need some help? Give us a call.

[1] Verizon 2017 Data Breach Report

[2] WhiteHat Security 2017 Application Security Statistics Report, The Case for DevSecOps, Vol. 12.

 

 

The post The New York Cyber Security Regulation: An Application Security Perspective appeared first on WhiteHat Security.

*** This is a Security Bloggers Network syndicated blog from Blog – WhiteHat Security authored by Jeannie Warner. Read the original post at: http://feedproxy.google.com/~r/WhitehatSecurityBlog/~3/F2b1AnCadhE/