This problem is compounded because decision makers are unaware of all the actions available to them to mitigate risk, if they are aware of the risk at all. For proof, we only need to look at the high degree of breaches even though security tools and practices are more prevalent than ever.
There are two policy models that are widely used today; risk-based and rule-based. Traditionally, rule-based policies were developed to control computing assets at a time when regulatory compliance and security risk weren't even merit a passing thought.
The premise of rule-based approaches was simple enough in that the rules outlined what could or could not be done in a given environment or system. As time passed, complexities in distributed systems, such as pervasive computing environments and the internet, chipped away at the effectiveness of rule-based policies. Regulatory compliance advanced the situation rapidly, and before long, gaps formed which led to serious security risk, process control problems and access control problems.
In attempts to give managers the ability to identify and manage security risks, a new approach to security policies began to emerge. This approach to policy doesn't focus on static rules but rather degrees of risk at any given time.
For example, you'll find a statement like this in a rule-based policy, "No person shall access data that is classified at a level higher than their current role." Whereas a risk-based policy may state something like this, "Risks associated with data availability, confidentiality and integrity shall be classified by the business process owner and mitigated by adhering to templates, forms and documents that support the security process."
The objective of a risk-based security program is not to provide remedies for every security breach or gap, but to delineate a comprehensive, systematic approach to risk mitigation and management.
The security program can be viewed by a system owner or department head as a certification and accreditation process. It allows for a comprehensive risk assessment, management and cost benefit analysis to facilitate the implementation of security budgets that make good business sense.
While this may sound all well and good, many organizations may not have the ability, culture or resources to implement a risk-based security policy.
Regardless of how well the model fits today's environments, there are always obstacles in your path. To begin with, several things have to happen first, starting with classifying all data in the enterprise against a pre-determined standard. For example, data owners would classify the value of their data as low, medium, or high, for confidentiality, integrity, and availability.
This task sounds like an easy thing to accomplish but as you deal with large enterprise environments, this task can end up taking years to complete.
Moving along, you still will need to assist in the development of a system security plan. Tasks will include system description and scope, roles and responsibilities, and security controls. Again, this task is nothing to laugh at and can take you a very long time to implement.
Next you'll need to develop security assessment reports. Things like contingency planning, configuration management and incident response are just a few things that need to be addressed here.
Keep in mind that after all of this, the program still needs to be certified and delivered to the approving authority, and most importantly, it has to be approved.
By now you should understand that risk-based approaches are very time consuming to implement, inherently costly to develop and highly dependent on the talent of those who are in key positions within the organization. Because of this, many organizations have remained with the traditional rule-based approach to security.
While this may seem like a good idea, at the end of the day, the CSO is the one left holding the bag should something go wrong. If you take nothing else away from this article, be sure to understand that the primary responsibility of the CSO is not to own the full burden of organizational risk. Unfortunately, this is exactly the situation that a rule-based policy creates for CSOs.
That said, risk-based policies are not without political and organizational issues.
With a risk-based policy, risk is transferred to the business process owner. Risk-based models also assume that there will always be risk, and as such, security gaps. Add these two and you may find it difficult to sell the idea of accountability and ownership because in many cases people resist owning the responsibility. More times than not, you will find this resistance in government agencies that have elected positions rather than private industry.
We've run through two of the most popular approaches to security policy implementation. Each has strong points and appropriate applications and of course each has its complications and downsides.
It is important to understand how your business operates before selecting an approach, as there are some outside instances where a rule-based policy may still be viable. At the end of the day, I would recommend that you give serious consideration to the risk-based model as it will be much more conducive to managing risk, adhering to compliance and for supporting business functions in an ever changing environment.
For more information on security policy design, visit http://csrc.nist.gov/ for a variety of templates and designs that can be used to create a risk-based policy.
This article was first published on InternetNews.com. To read the full article, click here.
Loading Comments...