For the banking industry, IT Security is an ever changing concern that must be addressed with the most recent threats in mind. For many institutions, security is handled by policy based IT audits and annual penetration tests performed by external vendors.
To truly prevent a fox from getting into your "hen house," so to speak, you must go above and beyond penetration tests and policy based IT audits. Below is a recent conversation I had with "Joe Management" where I discuss one way to go above and beyond - the vulnerability assessment.
What is it and why do I need it?
A Vulnerability Assessment is an identification of control issues through an exhaustive technical process. In other words, we can't just sample anymore. Computers are used to examine every piece of hardware connected to the Bank's LAN. Think of them as mini risk assessments. They look at all of the settings, the software installed, the vulnerabilities in the software installed. It's just not practical to audit all of that manually.
Is it just a high tech audit report?
No, a vulnerability assessment is not an audit report. Where audit reports are exception based, vulnerability assessments should present as much information as possible in order to ensure that the Bank, at the very least, is aware of the issues. The report should not be considered a critique, but rather a vehicle to deliver information.
The reality of IT in community banking is that outsourcing is here to stay. Many community banks do not possess the resources and/or in house expertise to adequately implement and then manage IT solutions. Using vendors allows them to get the expertise at a reasonable cost. But how do those in positions of oversight know that the solutions are secured sufficiently? How does management know that their vendors are doing what they are supposed to do?
So, this is something I can use to help manage my vendors?
Absolutely. A vulnerability assessment provides management with a tool to open a dialog with the vendor to gain comfort that the controls implemented are sufficient. The vendor can then explain the compensating controls to management. Management can then document the process and express their comfort to the audit committee. In this way, all parties can gain comfort that for the issues that are identified, risks are assessed, and controls are implemented, from the perspective of, and as they apply to, the specific needs of the Bank.
In cases where controls do not exists, management becomes aware of the issues and implements new controls. The idea is that you, as management, can research the issues in the context of your other mitigating controls and derive a final risk that is representative of the Bank. In other words, a vulnerability assessment defines inherent risks associated with findings - you then can research and determine your residual risk.
A vulnerability assessment is a tool that you can use to effectively manage your vendors and at the same time use with the board to get funding and buy-ins for the work that you think needs to be done.
Who performs the assessment? The internal auditors? Another security company?
Ideally, your internal audit staff should perform the assessment as a standard part of the IT audit. That will allow them to opine on the overall IT posture of the organization.
In community Banks, the process of validating the adequacy of IT security has traditionally been completed through Audit. Audit is a control that validates the adequacy of other controls. A typical IT audit focuses on controls as they relate to policy and procedures. The complexity of modern IT infrastructures requires more.
The days of auditors coming into your bank and taking screenshots of the password policy on the domain controllers are done. The IT infrastructure - of even a small community bank - is too complicated, too fluid, and vulnerabilities emerge too quickly to effectively audit manually.
If your auditors don't have the technical expertise to perform the assessment themselves, then you should hire someone else to do it for you. Your auditors can attest as to the results and the remediation.
We had an internal penetration test done, why do I need an assessment as well?
A vulnerability assessment should not be confused with a penetration test. You don't know where the vulnerability lies on the network. Vulnerability assessments are designed to be a comprehensive identification of issues so that you can fix the issues you might have missed. In order to perform a comprehensive assessment the auditor will require elevated permissions on the network.
On the other hand, the FFIEC defines a penetration test as follows:
A penetration test subjects a system to the real-world attacks selected and conducted by the testing personnel. The benefit of a penetration test is that it identifies the extent to which a system can be compromised before the attack is identified and assesses the response mechanism's effectiveness. Because a penetration test seldom is a comprehensive test of the system's security, it should be combined with other monitoring to validate the effectiveness of the security process.
Did you read the last line of the definition? "Because a penetration test seldom is a comprehensive test of the system's security, it should be combined with other monitoring to validate the effectiveness of the security process".
The reality is that audit is unable to comprehensively identify issues due to the complexity of modern infrastructures. Penetration tests are not designed to identify issues. You need a vulnerability assessment as well.
Wait; did you say "elevated privileges"? We are very, very concerned about customer data and don't want to give the level of access required for the assessment.
Great, but let's take moment for introspection. Ask yourself if other factors are contributing to your hesitation. Is the culture of the bank such that any issue identified results in a rebuke from those above? Are other things happening at the Bank that can't afford to be interrupted? Does the comprehensiveness of the assessment scare the IT department? Are you concerned about how the report will be interpreted by the regulators or by the audit committee?
Be honest with your answers. Ask yourself if your resistance to the process is actually an indicator of a larger problem. It usually is. Now talk to your auditor and resolve the issue in a way that makes everyone comfortable. The security of the Bank is too important to let cultural and personal issues get in the way.
Nope, we're just prudent.
Excellent, it's good to be prudent. In fact, the FFIEC guidance lists a number of key factors for management to consider before IT testing is performed (FFIEC IS Examination Handbook pages 88-90). They include understanding the personnel, scope, notifications, and the potential impact on data integrity, confidentiality, and availability. However, the FFIEC guidance does not state that you shouldn't have a review performed, only that you consider the key factors prior to starting.
You already have a trusted relationship with your internal auditors. If they have the expertise to perform the assessment then you have probably already addressed all of the key factors that the FFIEC suggests you consider.
Great, I have this comprehensive report. Now how do I present it without scaring the audit committee?
Vulnerability assessments are large reports. They are intentionally designed to provide as much information as possible.
The presentation to the audit committee should emphasis the availability and sharing of knowledge so that they can understand the risks you have to deal with and are responsible for mitigating. Your auditors should explain that a vulnerability assessment is not an exception based internal audit report. Instead, it is a tool for management to ensure the security of the organization
The audit committee has to understand that the next steps involve assessing the issues and implementing a plan for remediation. Very rarely will an audit committee be concerned about individual issues. They need to know what the risk is to the Bank (the assessment) and what's being done to fix them (the remediation).
In most cases they are genuinely pleased as they get a high level of comfort that the IT security controls have been comprehensively evaluated. The same goes for the regulators.
Is there anything else to know?
As management, you should understand that the report allows you to highlight your efforts to the board and to the regulators.
IT security is a moving target. Vulnerabilities evolve very quickly and you do nothing but deceive yourself if you think a policy based IT audit is enough to protect your Bank. As far as assessing the adequacy of your IT controls, don't judge yourself on the number of issues identified. Judge yourself on the adequacy of your process. When you identify issues be pleased and then fix them. Say to yourself, "There is no way I can know everything, but my process makes me stronger". That's the reality of IT. Accept it and you'll be doing more for the security of your Bank than any other single thing you could do. The strength of your process is what's going to ultimately determine the security of the bank.
Peter Viglucci, CISA, CRISC
Director of Information Technology
Peter Viglucci, Director of Information Technology, has over 17 years of experience in all aspects of Financial Industry IT