In defense of controls

Alex is pretty down on ISO 17799.

I think the reasons are that he sees organizations substituting ISO 17799 for risk management FAIR style. Instead of calculating a realistic, customized risk profile, an organization pulls ISO 17799 (or COBIT, though COBIT is less specific to security) off the shelf. The specific controls in the 10 areas are implemented, and therefore they are secure, and risk-free. However, a focus on these areas may not appropriately address the real risk to the organization, and may result in inefficient and ineffective use of resources. (I hope he'll correct me if I'm wrong.)

I think he's right if that is how the standards are implemented, but it is not necessarily the only way they can be used. I'm thinking that if used properly, ISO 17799 could help in implementing controls to reduce the risk identified. He cites an example of using metrics to manage patches. I see it this way:

Risk analysis identifies areas for control.
High value assets on exposed servers are vulnerable to complete compromise from any weak-ass hax0r wannabe, because of well known problems in the OS. The vendor has issued patches, and continues to issue patches on a routine basis.

The control is implemented.
Defining the control is where ISO and Cobit would come in. Once you have decided that it should be done, it can answer the question of how. If others have discovered a way to control the situation that works reliably, I don't see why you wouldn't want to use it. Engineers and accountants do it all the time. At the same time, it must be optimized to meet not only your specific risks, but also your environment and culture. Striking the balance between the universal and specific is the challenge that standards face.

The effectiveness of the control is measured.
A metric could be used to determine the effectiveness of the control, as well as the appropriateness. If you are unable to tell if a control is functioning, it is hard to tell if it is effective. If the server team does not adequately test the patches, or places lower risk items higher in the work queue, your risk is not being mitigated when you think it should be. An armed guard isn't an effective control if he's asleep all the time.

The way I see it, risk assessment is necessary to prioritize controls. Controls are used to manage risk. And metrics are used measure the effectiveness of controls. There are multiple ways any of these can go wrong, but it's a beautiful evening and my motorcycle needs exercise.