Mike Wills - The Official (ISC)2 SSCP CBK Reference

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 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.

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 per-risk basis, in terms of what to accept, transfer, treat, or avoid

Risk mitigation decisions, including specifics as to the chosen controls and the anticipated residual risk after the controls are put into practice

Success criteria, in operational terms, which indicate whether the control is successfully performing its functions

Anticipated ongoing costs and efforts to use and maintain a set of controls

End-user and support team training, including any requalification training, needed to keep the controls operating effectively

Continuous, ongoing monitoring of operational use of the controls

Ongoing periodic or random assessment, including penetration testing, aimed at assessing the controls

Decisions to upgrade, replace, or completely retire a set of controls

As you'll see in Chapter 3, there are a number of information products generated by risk management and risk mitigation planning. Although they may be known by various names or be produced in many different formats, the core set of information includes the business impact analysis, risk assessment, risk mitigation plan, and the change management and baseline documentation for the chosen and implemented controls. These could include vendor-supplied manuals as well as your organization's own functional performance requirements allocated to a particular control.

Effective information systems management must achieve three distinctly different goals:

Are we spending what we need to (and no more) to achieve the right business priorities and objectives?

Are we using our information systems effectively in ways that help us achieve our objectives?

Are we maintaining, changing, or upgrading our information systems in effective ways to meet changing conditions and needs?

Those three questions all focus on our information systems architecture, the elements we've brought together to create those systems with, and the business logic by which we use those systems. As we'll see in Chapter 3, having a solid baseline that captures and describes our organization's information systems and IT architecture is the foundation of how we manage those information systems. It's also worthwhile to consider that well-managed systems are often more reliable, resilient, safe and secure; unmanaged systems may be just as trustworthy, but if they are, it's more by luck than by design.

Information systems asset management comprises all of the activities to identify each asset, know and control its location and use, and track modifications, changes, or repairs done to it. Asset management also includes keeping track of any damages or losses that an asset incurs through accident, failures of other systems or business functions, misuse, abuse, or attacks of any kind. Due care and due diligence require asset management to be effective, thorough, and accountable, which in turn require that proper inventory and tracking records be kept and that standards be set for proper usage, routine maintenance and repair, safety, and security. Asset management and configuration management and control go hand in hand as the main processes you should use to keep these important, value-producing assets working well and working for you; they're also crucial to keeping those assets being used by someone else!