Five Ways for Banks to Stay Ahead of Cybercrime
One of the misconceptions I hear about cybercrime is that it’s a worry for the IT department. As seen in this facilities intrusion video, that concept is simply not true. It might be your employees who are inadvertently letting a would-be hacker walk in the door.
Information security is not the just the job of a single department — or your employees. It’s a complete team effort among banking leaders, the board, internal audit, and yes, the IT department and your people.
Knowing where you are most vulnerable is a good way to prioritize your defensive strategy, manage resources, and stay ahead of a breach. Here are five ways to identify your risks and evaluate IT controls at your financial institution.
1. Determine your greatest risk area
Step one is knowing where your bank is at risk — right now. An IT risk assessment can give you that baseline understanding. While management is responsible for performing the assessment, internal audit should evaluate the risk assessment to verify that it is performed in a thorough and accurate manner. After all, risk assessments are only as good as the effort put into them.
There are many risk assessments in the Federal Financial Institutions Examination Council (FFIEC) guidance, but the two most important to cybersecurity are the ones found within the Graham Leach Bliley Act (GLBA) and the FFIEC Cybersecurity Assessment Tool.
GLBA information security risk assessment
The GLBA assessment has been required by 12CFR Part 748 Appendix A since 2001. But many financial institutions that I come across do not have this risk assessment or have not updated it in the past 12 to 24 months. The GLBA risk assessment must:
- Consider reasonably foreseeable internal and external threats via documentation
- Document the controls that mitigate each threat
- Document the impact and likelihood of the threat given control implementation
- Conclude on the overall sufficiency of the controls
Examiners and vendors can misstate the GLBA risk assessment. Examiners may add requirements to risk assessments based upon IT assets or they may add requirements to conclude on inherent or residual risks. While these additional requirements may be relevant, they are not addressed in 12CFR Part 748 and should not be required elements in a GLBA Risk Assessment. While guidance clearly distinguishes between risk assessment and tests of key controls, vendors can also misstate the differences and will refer to their controls testing as a risk assessment. In either case, internal auditors need to master the requirements of risk assessment and controls testing guidance so they are not erroneously advised.
FFIEC cybersecurity Assessment
The FFIEC Cybersecurity Risk Assessment guidance was released in June 2015 to help banks consistently evaluate cybersecurity controls and practices. The guidance includes a tool to help the effort, which can also be used as an examination aide. While not officially mandatory, banks are encouraged to use the tool (or one very similar) to assess the inherent risks and maturity of their cybersecurity program.
The maturity model component of the tool features nearly 500 independent statements about a cybersecurity program. These statements are grouped by domains and sub-domains. Each of these statements is either true or false. The statements are also grouped by maturity levels ranging from baseline to innovative. A bank’s maturity is measured as the most advanced maturity level for which all statements are true. The most significant weaknesses of the FFIEC assessment tool are inconsistency in how it is completed and a missing validation component to verify that statements are accurate.
2. Scan your network for system vulnerabilities
Bank management is responsible for keeping systems free from known vulnerabilities and insecure configurations. The best tool for this is the vulnerability scanner. Three scanners are routinely rated as best, Nessus, Nexpose, and Qualys.
Internal audit should regularly evaluate management’s use of vulnerability scanners through the following two activities:
- Verify that scanning is performed using domain administrator credentials. This method reduces scanning time and the impact of scans on the network, and greatly improves the accuracy of the scan results.
- Evaluate the process and practices used by management to ensure that identified vulnerabilities are either addressed in a timely manner (within 15 to 45 days of discovery) or accepted through written documentation and approval.
3. Test your systems by simulating an actual breach
The primary purposes of a penetration test are to demonstrate the potential impact of a targeted attack and to evaluate incident detection and response. To be most beneficial, a test should closely simulate an actual attempted breach. That means the simulated breach is a surprise even to those responsible for detecting and responding to it.
Penetration testing most closely simulates an actual breach when it is initiated through social engineering or when it starts from an employee’s workstation that is assumed to be compromised by social engineering.
Internal audit should be onsite during a penetration test to monitor incident detection and response activities so they do not impact member service or excessively waste limited IT resources. Internal audit should also verify that penetration testing truly simulates a breach and that management receives a report on the penetration testing performed. With the frequency of breaches on the rise, many financial institutions are now contracting for penetration testing one to four times per year.
4. Identify your weaknesses
A vulnerability assessment complements penetration testing and vulnerability scanning by identifying weaknesses in your network. Unlike penetration testing, effective vulnerability assessments require IT participation. For the most comprehensive assessment, IT will need to allow the tester access to the network, provide configuration and practice documentation, and show the consoles used to manage patching, anti-virus, and more.
Do not be concerned if your security testing partner requests that some controls be disabled to facilitate testing. Because effective security is the composite of multiple layers of controls, some “outer” layers need to be disabled in order to evaluate “inner” layers.
Like looking for a needle in a haystack, vulnerability assessments are less accurate when sampling is used and testing is limited to a subset of systems. So make sure your internal audit group evaluates the depth and breadth of the testing provided by potential testing partners. It is critically important that all systems are evaluated and all key stakeholders are present for the assessment.
The good news is that given sufficient training and experience, internal auditors can evaluate many GCR controls.
5. Perform a general controls review
The final area of testing is often referred to as a general controls review (GCR). A GCR evaluates many non-technical controls that contribute to security. For example, a GCR evaluates physical security (including building access as seen in the video above) vendor management, board oversight of security, core and network access administration, and information security policies.
The good news is that, given sufficient training and experience, internal auditors can evaluate many GCR controls, either as a dedicated audit or as a part of regular branch and departmental audits. Internal audit leaders should provide training so auditors can, at a minimum, follow up on GCR findings. A staff training might also be suggested in your GCR outcomes, to help prevent tailgating and other social engineering methods seen in the video.
How we can help
These five methods for identifying risks and evaluating IT controls will not provide a guarantee that a cybersecurity event will be avoided, but, if performed with rigor, they will greatly reduce the likely impact should an event occur. Contact your advisor to understand how vulnerable you are to a breach.