Date: 19/11/2019
Name:
Email: Keep my email address private
Reply:
**Your comments must be approved before they appear on the site.
Authentication:  
7 + 0 = ?: (Required)
Enter the correct answer to the math question.

  
clear
You are posting a comment about...
Compliance v. Security

An essay in a recent Wall Street Journal (December 3, 2011) caught my attention on the subject of compliance v. security.  The article, “Starting Over With Regulation” by Philip K. Howard (also available at www.commongood.org), makes the case that government regulation in general is too complex to work.  Recent failures by Congress to simplify Sarbox 404 illustrate where we are.  According to Howard, the current approach is “deliberately designed to avoid human discretion”; but is this not the approach of many information security regulations?  They are great at specifying detailed auditable controls, but short on helping to make sure the enterprise is meeting an overall security goal.  This is the compliance approach to security, which makes the assumption that if all the individual controls are OK, then the organization is OK.  The many reported security breaches over the past 24 months casts some doubt on this assumption.

Recent regulatory efforts have begun to require monitoring of the overall security health of the organization.  For example, the language in Massachusetts’ 201 CMR 17 requires:  “Regular monitoring to ensure that the comprehensive information security program is operating in a manner reasonable calculated to prevent unauthorized access to or unauthorized use of personal information”.  The word comprehensive is key to me; it says that metrics must be set up keep track of the overall security program, not just individual controls. 

But how to do this?  One way is by use of maturity levels.  The maturity level approach acknowledges that continuous improvement of security is critical.  Continuous improvement must be managed on a monthly basis, not annually, driven by audit.  If your security process maturity level is not improving then your program is broken somewhere, no matter what the individual control metrics say.  Maturity levels can be developed around your control framework of choice.  I prefer ISO 27001.  Another choice is COBIT; see the new Process Assessment Framework for COBIT.  Another choice is the Open Group’s O-ISM3 process maturity framework for security.  Whatever method you use, you must be sure to watch the security forest as well as the individual trees.