In my The Credit - Er, IT Crisis post I talked about some of the forces influencing security in community banking. One of the forces I mentioned was that the audit process has remained largely the same, while at the same time, the IT environments of modern banks are rapidly evolving. But what does that mean? Given the evolving environment, how does the audit process have to evolve to ensure the information security of a community bank? What does a community bank need to do to complement the audit process?
In community banking, the process of validating the adequacy of information security has traditionally been completed through Audit. Audit is an important information security control in that it validates the proper working of other controls in an organization. When auditors come into your bank, they look at things such as training plans, incident response plans, disaster recovery and business continuity plans, risk assessments, business impact analysis studies, proper governance, and a host of other things. Now, all of the controls the auditors examine are important in mitigating IT risk. However, there is a fundamental weakness in relying solely on the audit function to validate information security.
What do most of the controls your auditors examine have in common? Many are reactionary in nature. They're designed to mitigate exposure after something happens. Not all, but many of them. They provide procedures to follow in reaction to an event.
For example, think about your incident response plan. What is the purpose of that document? It describes the procedures to follow in the event an actionable incident occurs within an organization. It describes what constitutes an actionable incident, who the people are who are tasked with dealing with it, what they need to do, the escalation process, how it should be documented, and how it should be ultimately reported. An incident response plan is designed to minimize the damage from an incident after it occurs and ensure that sufficient documentation exists so that additional controls can be developed in the future.
The same thing can be said about disaster recovery and business continuity plans. They are designed to ensure that the business can survive an otherwise catastrophic event, that is, survive after an event occurs. Even risk assessments, business impact analysis, mandatory vacation policies, and reporting are only going to plan for, detect, or deal with events after they have happened.
Even audit itself is a detective control. The audit process detects control weaknesses by looking for failures after they have happened.
Don't get me wrong; all of the controls discussed so far are critically important to a bank. Auditors will rightly get their underwear in a bunch if they are missing. However, the information security weakness arises when IT audits focuses too heavily on these reactionary controls. The highly technical infrastructure of modern organizations and highly technical attacks (both internal and external) requires us to consider more. IT audit programs need to be expanded to include the examination of controls that outright prevent or allow for pro-active responses to incidents. They need to balance the emphasis on reactionary controls, like incident response, disaster recovery, etc., and the controls that allow for preventive, or real-time responses.
To be clear, your auditors are already examining controls that fall under this preventive category. They examine things like dual controls, segregation of duties, system password policies, access control lists, training, physical access controls (e.g., how access to the vault or server room is controlled), and other authorization and approval processes. All of which are designed to prevent incidents from happening in the first place.
I know what your thinking, "If my auditors are already looking at reactive and preventive controls, then what's the problem?" The problem is twofold. First, many IT audit programs are skewed towards the reactionary controls. In my opinion, that is largely due to regulatory emphasis. Regulators spend a lot of time looking at the adequacy of your policies. Therefore, auditors spend a lot of time there as well. Auditors hate it when an issue is identified in a regulatory audit that was not identified as part of an internal audit. Where the regulators go, the auditors will follow. Secondly, we must be careful to consider the highly technical risks associated with modern information systems. As I explained in Keeping the Balance: IT Security and the Org Chart, dual control and segregation of duties work marvelously in preventing internal fraud, but they potentially do very little to prevent a laptop compromised with the latest malware from opening a tunnel that can be used by an attacker to siphon data out of the bank.
Given that, what should the audit process be looking for? What are some additional preventive controls that can be implemented by a bank to improve its information security posture?
At the top of the list are Intrusion Detection Systems ("IDS"). Now, before you say anything, I know that a service provider might manage your network. I know that your network might be part of your service provider's larger network. I'm still going to tell you to consider the deployment of IDS across your Bank. At the very least consider the deployment on critical servers and critical network segments.
Let's describe Intrusion detection systems as coming in two basic flavors, Host-based and Network-based. In reality there are other categories such as anomaly and signature based systems, but they are beyond the scope of this post. I'll cover intrusion detection in detail in a subsequent article. For our purposes today, let's say that Host-based systems are capable of detecting and stopping attacks against an individual machine and Network-based systems are capable of detecting and stopping network based information gathering techniques, like port scanning, and network based attacks like the spread of a worm across the network. The point I want to make is that these systems are preventive. They can detect, report, and prevent anomalous events in real-time.
Right behind IDS is the need for centralized patch management. Here is the mistake many organizations make: patch management must include all critical software installed in the bank, not just operating system updates. You cannot rely on the auto-update feature of non-operating system software programs. First of all, you have probably configured your systems such that end users do not have permission to install software. And secondly, we train our users over and over to not click the malware spreading pop-up boxes they encounter on the Internet. What is the first thing a software program does when it wants to download an update? It displays a pop-up box. How can we expect our users to decipher a good pop-up from a bad pop-up? Don't even try. Look for a centralized system that allows you to push the critical patches. It is unlikely that an external attacker will compromise the bank through the external interface managed by the firewall. It is far more likely that malware will compromise a machine on your network and open a tunnel out of the bank. Consistent and robust patch manage is a preventive control to mitigate that threat.
Another control you can consider is the incorporation of a Syslog Server into the network infrastructure. Syslog servers allow for consolidated logging across the Bank. Just about all modern networking devices and operating systems support Syslog or have software programs available that provide the functionality. The use of consolidated logging in coordination with a backup strategy is especially important in outsourced network management arrangements in order for a Bank to have the ability to enlist the services of different service providers for the purpose of forensic investigation in the event of a system breach. Additionally, when you combine it with a reporting solution you have real-time access to reports that include the state of all systems in the bank. While not strictly preventive in nature, the fact that it allows for real-time monitoring, reporting, and alerting blurs the line between a detective and preventive control by allowing an admin to very quickly become aware and respond to events.
Website monitoring is a system that watches the bank's website and reports if content on the site has changed. It alerts in real-time if the site is exploited or if the domain name server has been compromised. It doesn't matter if you have no customer data on you site. You still carry significant reputation risk with your customers, potential customers, and the regulators if your public image is attacked.
Network monitoring provides real-time load monitoring to detect network anomalies. Network anomalies can result from virus and worm infections. If the admin at the Bank notices an anomalous spike in traffic across the Bank it may indicate a worm at work.
What all of these controls are doing is bringing us closer to a technique know as Continuous Auditing. "Continuous" refers to the near real-time validation that internal controls are functioning correctly. Think about it. We have website monitoring that alerts us the instant the content on our website is changed. We additionally have controls in place that dictate the procedures that allow for access to the website to make changes. If the website monitoring software detects that a page has been changed improperly, it is not only detecting an attack on the site, it is also detecting a failure in the internal controls that govern access to the site. You can think about intrusion detection, network monitoring, and Syslog in the same way. These controls not only prevent attacks, they act as sentries that continually monitor your control environment. Continuous auditing is your future. We have a tendency to think about technology from the point of view of the operational efficiencies it can provide. One thing we can also do is to think about using technology to provide us real-time monitoring capability.
Up until this point I've focused on controls that a bank can employ to bolster its information security profile. But what should the auditors be doing? Well, the first and obvious thing for an auditor to do is to expand the scope of work to also evaluate the need for preventive controls like those I describe above. In cases where preventive controls have been deployed, the auditor can validate that they are operating effectively. In high-risk environments, like a bank, its not enough to rely purely on a detective control audits to validate information security. Auditors should be suggesting the use of preventive controls that provide a continuous monitoring capability. Technology is not slowing down. It will continue to become more and more prevalent in all of the things we do. The control environment must evolve with the systems it is designed to protect.
Auditors should also be using Computer Assisted Auditing Techniques ("CAAT"). CAAT tools allow an auditor to audit more efficiently, more thoroughly, and more accurately than a manual audit alone. Tools can be as simple as using spreadsheets to validate financial data to using network-scanning devices to validate the topology and system configurations of devices on the network. From an information security point of view, using automated tools allows the auditor to get away from sampling. Modern network infrastructures, of even small community banks, are very complicated and evolve very quickly. Picking a few machines at random and checking things like password policies, patch status, and anti-virus may or may not be reflective of the environment as a whole. There are too many variables to consider. Things like the physical topology, over-riding domain policies, the management culture, other mitigating controls, and a host of other things all contribute the security profile of an organization. For auditors to come in, take a sample of a few machines, and then extrapolate the findings as being representative of the overall environment is just not correct. However, if the auditor is using tools that allow for an assessment of all devices on the network, and even an assessment of the topology itself, then the subjectivity goes away. The auditor can render a much more informed and objective opinion.
I'm just scratching the surface here. Hopefully I've got you thinking about additional controls you can consider implementing and the techniques your auditors should be using. Modern IT audit programs should be looking for, evaluating, and assessing the need for these types of real-time preventive controls. Does your current audit process look for them? If you don't have these types of controls, has your audit function recommended them to you?
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