Tom Olzak

Compliance requires people supported technical solutions

In Business Continuity, Cybercrime, Data Security, Hacking, Risk Management on March 28, 2009 at 11:19

Although I agree that reliance on human behavior is not a good way to ensure information security policy compliance, it will always be a factor.

Technology is not the panacea for fraud or executive-level “cooking the books.”  A certain amount of human oversight is necessary to verify that application controls work properly, enterprising employees haven’t found a way around them, and the layered security infrastructure is working as expected.  Further, relying on a 100 percent technical response to an external attack is too costly and prone to being hacked.  So I don’t completely agree with comments recently attributed to Charles Cresson Wood, in which he appears to assert people must be completely removed from the compliance process.

During last week’s SecureWorld Boston, Charles Cresson Wood discussed the need to go beyond development of policy when implementing information security.  In his keynote address, he describes the need for systems which ensure compliance.

A huge problem is that security policies are still too reliant on people, Cresson Wood said.

“If you want a high level of compliance do not rely on humans to get the job done,” he said.

“Things are going too fast in information security. A manual response to distributed denial-of-attacks, for example, is inconceivable,” he added.

Scripted and automated compliance enforcement needs to be put in place, supported by intrusion detection, intrusion prevention and other tools, Cresson Wood said. Security appliances will be documenting and vouching for policies, producing admissible evidence that can be used if disaster strikes and legal issues ensue. “Something like a black box when an airplane goes down,” he said.

Source: Expert Cites Big Problem with Security Policy Compliance, Bob Brown, Network World, 25 March 2009

I agree that writing policies and training employees on what is and is not acceptable behavior is not enough.  I also agree that layered technical controls are absolutely necessary to achieve business objectives defined in the policies.  However, relying completely on technology to safeguard information assets  is a poor business decision.

A layered technical defense uses a variety of approaches to detect and prevent likely attacks.  Each safeguard is also configured to support other layers in case they are breached.  But note the key word here is likely.  It’s financially infeasible to attempt a prevention-only defense against all possible attack methods.  Instead, preventing probable attacks while detecting network or system anomalies makes the most business sense.

The success of  technical detection controls requires human monitoring of events and implementation of a documented and tested incident response process.  There must be a balance between human and technical controls.

So how does a security manager help executive management decide where the fulcrum lies when balancing human and technical controls when an unlimited security budget does not exist?  Easy.  Risk management.

Risk management assumes that the risk of a breach can not be feasibly reduced to zero.  So an assessment of probability of occurrence (derived from analysis of possible threats and known vulnerabilities) and business impact should be used to determine if sufficient controls–administrative, technical, and physical–exist.  In other words, has business risk been reduced to an acceptable level.  If it has, then the right balance has probably been reached.

Using this approach, is there a chance a breach will occur?  Yes, but enough detection controls should be in place to identify and react to it before serious damage is done.  We cannot expect organizations to completely lock down their networks with attack-prevention solutions.  The cost in both hard dollars as well as lost productivity is too high.

For more information on this topic, see Risk Mitigation Drives Breach Prevention Costs.

%d bloggers like this: