Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 66

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.