Detective (or detection) controls look for any out-of-limits conditions, such as signatures associated with an intrusion attempt, and then take two fundamental and important actions. First, the detection controls notify operations personnel or higher- level supervisory systems that a problem exists; this is absolutely critical if you are to have any command and control over your systems or any ability to manage an effective response to incidents as and when they occur. Second, the detection controls can (if desired) signal an attacker that you've noticed what they're doing, which leads them to believe you'll be responding to their attack. This may deter them from continuing their efforts.
All intrusion or incident detection systems are subject to error rates. Getting the crossover point set so that your risk of harm or loss due to false acceptance errors is balanced by your ongoing costs of investigating and resolving false rejections (and their concomitant “sky is falling” feeling) is a never-ending process. In fact, the smarter these controls get—and the more that they employ machine learning and predictive analytic capabilities—the more time you'll have to invest in understanding their behavior and tuning it to fit your constantly changing threat landscape and the dynamic nature of your routine business activities.
Physical detection systems can include motion detectors, motion switches on doors and windows, and continuity circuits embedded or built into walls, fences, and other landscaping features. Many such systems can support change detection as well, which can highlight suspicious portions of the systems they surveil to human security monitors for analysis and possible action. Physical systems such as power conditioning, air and environmental conditioning systems, and other aspects of your data center or network operations facilities should be primary sources of alarms that indicate a potential disruption, possibly due to an intrusion, is underway.
Don't forget the end-user element! Properly motivated and trained, having a cadre of end users who can spot something that's not quite right and appreciate that management wants to hear about it sooner rather than later can often stymie an attack before it gets too far.
Corrective Controls
Corrective controls provide for the containment, isolation, or restoration of services that have been disrupted for any reason. Uninterruptible power supplies (UPSs) are a good example of this: They isolate or buffer your IT and communications systems from external commercial electrical power providers and in doing so can correct for temporary undervoltage, overvoltage, spikes, noise, or other problems with power before those problems pop circuit breakers or damage equipment. Power problems, incidentally, can also cause equipment to operate in degraded ways that are oftentimes hard to diagnose. Consumer and small business-grade routers, switches, and servers, for example, are prone to odd and intermittent outages for this reason, and the simple expedient of putting them onto an inexpensive battery backup power conditioner or UPS can save hours of fruitless troubleshooting.
Another example of a corrective control in action is when your access control system or a web page design remediates or quarantines a subject's access request when information about that subject and that access request indicates that something is not quite right. Systems can interrogate the subject's endpoint device, for example, to determine whether its operating system, applications, antimalware, or other functions are all properly updated, and if not, route the connection to a remediation server or page that only allows for repair actions to be taken. User subjects can also be challenged to provide further authentication credentials, if something about the time of day, the user's geographic position, or other criteria dictate the need for enhanced vigilance.
Compensating Controls
Compensating controls are put in place when the normal, recommended, or required “best choice” of a risk mitigation control is not available or is unworkable or not affordable or when another approach has been chosen for valid reasons. Depending upon the source of the original requirement for that control, this may or may not be an issue. NIST documents, for example, tend to focus on the risk or threat to protect against, rather than attempting to specify a specific approach. (Best practices, though, often rule out approaches that are no longer useful to consider.) Another example of this can be seen in the Payment Card Industry Data Security Standard (PCI DSS), which specifies stringent security functional or performance standards by which controls must operate, as well as a formalized process for justifying the use of an alternative approach.
PCI DSS gives a good working definition of a compensating control, which can easily apply to other information risk control situations. A compensating control must do the following:
Meet or exceed the intended level of protection as specified in the original control requirement
Provide a level of protection that sufficiently offsets or covers the risk that the original control requirement should address
Must provide greater levels of protection, against the total risk set that the originating or reference standard addresses, than would be achieved by the original control requirement
Must provide a degree of overall safety and security that is commensurate with the risk of not using the recommended or required original standard in whole or in part
This can seem a bit wordy, if not confusing. An example might help. Consider PCI DSS Requirement 3.6.4, as illustrated in a white paper by Robert Schwirtz and Jeff Hall, both at RSM McGladrey. (This paper, which can be found at https://rsmus.com/pdf/understanding_pci_comp_controls.pdf, provides good insight into the thinking about compensating controls and how to ensure that a soundly reasoned, well-supported argument is made to justify their use.) This particular requirement specifies that encryption keys must be kept secure. Suppose your system is implemented using a public key cryptography approach such as pretty good privacy (PGP), in which there also is not a centralized certificate authority; there are no keys to keep secure! So, your compensating control is the use of a PKI system and the details by which you protect and manage certificates. (Yes, that process involves the use of both parties' private keys, and yes, those have to be kept secure, but these are not the keys used to encrypt a PCI DSS transaction. And, yes, it's arguable that the requirement would then apply to keeping the resultant session keys secure.)
Another example might be a requirement (in PCI DSS or many other systems requirements specifications) that requires passwords to be of a minimum length and complexity. Using a multifactor authentication system, common sense will tell us, obviates the need for attempts to constrain or dictate user choices of passwords since they are not the sole means of gaining access and privileges.
In common use, we talk about compensating for something as a way to imply that the original would have been better, but for whatever reason, we are settling for less. You compensate for the absence of a key team member by letting others substitute for them, knowing that your team just won't be as strong or the results as good. That's not what compensating means when talking about security and risk controls!
For a control to be a compensating control, there is no additional residual risk just because you've replaced the originally required control approach with something different. And if there is a residual risk, then your compensating control is not the right choice.
The Lifecycle of a Control
As with any systems element and the systems themselves, risk mitigation and security controls have a lifecycle that they progress through, from initial observation and expression of a need through implementation, use, and replacement or retirement. More specifically, that lifecycle might include the following:
Risk identification and characterization
Vulnerability assessments, with links to specific risks
Risk management planning decisions, on a