search.noResults

search.searching

dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
The NYDFS Regulations will likely play an increasingly prominent role in the definition of “reasonable” security and all financial institutions will be well-served by looking to the NYDFS Regulations as standard practices.


Four crucial questions for your cybersecurity team: 1. Do we have a Cybersecurity Program?


The NYDFS Regulations require that financial institutions maintain a “cybersecurity program.”2


This program should


be: (a) written, (b) based upon the entity’s risk assessment, and (c) address detection, response, recovery, and reporting obligations. Your security team, in consultation with your outside cybersecurity counsel and consultants, should be able to provide both a comprehensive program document and the written risk assessment that supports it.


2. Do we have a robust group of Cybersecurity Policies & Procedures?


Historically, an entity’s “Cybersecurity Policy” was often solely its two-page “Acceptable Use Policy.” This approach is not acceptable under the NYDFS Regulations,3


and likely will


not satisfy most definitions of “reasonable security.” Rather, a financial institution’s Cybersecurity Policy should include robust components (or separately-denominated policies) for:


• Information security; • Data classification; • Asset and device inventory (verify that it is up-to-date); • Business continuity and disaster recovery (this is separate from “Incident Response”);


• Systems & network security and monitoring; • Systems & application quality assurance; • Vendor & third party management; • Risk assessment; and • Incident Response


This is by no means an exhaustive list. But, if your policies do not meaningfully address each of these points, then you should seriously consider updating and expanding your manual to address these items.


3. Do we do both penetration testing and vulnerability assessments?


The NYDFS Regulations require annual “penetration testing” and bi-annual vulnerability assessments.4


Penetration testing


involves a trained tester actually attempting to gain entry into your systems.5


2 Id. At § 500.02 3 Vulnerability assessments, also known as


vulnerability scans, are an automated sweep of your system listing 1 23 NYCRR § 500, et seq.


See id. at § 500.03 4


possible problems. The combination of the two tests is the best way to determine whether all of your expensive cybersecurity measures actually work as intended (the less desirable way is to wait for hackers to break into your system). Some cybersecurity teams, unfortunately, tend to confuse


or ignore the distinction between these two types of tests. Unscrupulous testing vendors, for example, will mislabel a cheap vulnerability scan as a “Penetration Test,” and charge higher prices. Team members may go along with this, perhaps because it saves the financial institution a few dollars, or because it poses less risk of exposing critical vulnerabilities. You should verify that your cybersecurity testing involves both vulnerability assessments and true penetration testing to ensure the bank is adequately testing its systems.


4. Do we have an Incident Response Plan?


An incident response plan provides overall guidance to the organization on managing a cybersecurity event, including chain of command, authorized communications, employee management, and a myriad of other key crisis-management processes and functions.6


An “IT playbook,” on the other hand,


specifies your IT team’s specific technical responses to potential events. But, in some organizations, that IT Playbook is designated as an Incident Response Plan, leaving the organization blind in a crisis as to many critical non-IT functions and processes. It is often not hard to spot the difference. If your “Incident


Response Plan” was developed by your IT team without meaningful input from senior management, HR, customer relations, and other significant stakeholders, it is likely not an “Incident Response Plan.” If the “Plan” does not include key provisions such as a designated member of senior management and processes for internal and external communications, it is not an “Incident Response Plan.”


Conclusion


A good answer to these four questions does not end the discussion a financial institution should have regarding cybersecurity, but it does provide a measure of confidence that your security team is on the right track. Negative or evasive answers to any of these questions could be a warning sign that your team has room to improve your cybersecurity position to help avoid significant risks to your business and customer relationships.


Id. at § 500.05 5 Id. at § 500.01(h) 6 See id. at § 500.16


MIB Community BANKING 9


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16