At this point, you’ve all heard of – and probably read – the FFIEC’s Cybersecurity Guidance. In the FFIEC Cybersecurity Assessment General Observations, one of the items the FFIEC wants you to consider is the, “process for determining and implementing preventative, detective, and corrective controls.” I must admit, at first glance, I did not see the value in classifying controls. My opinion was that a control is a control, and all are good to have. I argued that classifying controls was a waste of time. After a few discussions, however, I began to see the error of my ways. I am now on Team Classify. Why? Well, I’m glad you asked! First let’s look at the differences in these controls:
Preventative controls are proactive and designed to discourage a threat from happening. Examples are restricting access, employee training, and segregation of duties.
Detective controls are designed to find a problem or incident. Depending on the control, they may lower the damage potential a threat could cause. Some examples are audits, log reviews, and intrusion detection systems.
Corrective controls are reactive and restore a system or process back to its state prior to the attack or incident. These will also lower the damage a threat could cause. One example is restoring a system from backup after unauthorized changes were made.
One important aspect of security is the notion of layering your controls. The premise here is that you must assume that any one of your controls will fail. It might seem pessimistic, but unfortunately, there are no infallible controls. Now that you’re assuming any control could fail, you would begin to layer other controls on the system/network in question. This way when one fails, the others can thwart – or at least slow down – an attacker. Most of us are going to emphasize the use of preventative controls since we want to prevent an attack or incident. If you have layered your network with multiple preventative controls, that is great! You are lowering the likelihood that a threat could compromise the network. The problem, though, is that when a control or multiple controls fail, you may not discover it in a timely manner if you don’t also have detective controls in place. In the same manner, if you are only implementing detective controls on a particular system or process, you are doing nothing to prevent a malicious event from occurring. It’s important to examine your network and your systems or processes on the network to ensure that while you are layering on controls, you aren’t relying on only one type of control.
From an auditing perspective, I think the area most of us need improvement on our detective controls. Implementing adequate event logging on all systems is a great start, but more often than not, those logs sit on a system without anyone seeing them. In many cases, the logs are overwritten prior to being backed up or reviewed. An intrusion detection/prevention system (IDS/IPS) is also a very effective tool, but remember that no control is infallible. Having an IDS/IPS on the network does not negate the need for the human element of security. Someone needs to be reviewing the output and receiving notifications from these systems, so the bank will know when a breach is suspected. Having a solid Incident Response Plan and an Incident Response Team who are very familiar with the plan is crucial to your layered security model. It’s important to know what you will do when, not if, you encounter a security incident.