Information Security Risk Management Programs

Friday, April 15, 2011

kapil assudani

67a9d83011f3fbb2cf8503aff453cc24

Information Security Risk Management Program – Part I : Identifying “What works and what doesn’t”

In this article, I would like to present some typical high-level observations/issues that are experienced when executing an Information Security Risk Management Program in an enterprise.

In many organizations, the CISO reports to the CTO – which usually results in a conflict of interest.  The goals of IT groups are performance and speedy implementation of their IT Infrastructure, which usually takes precedence over security considerations.

As a result, security takes a back seat and a constant political environment ensues between the two groups with the balance of power in favor of IT. 

The following are usually the only way security groups are able to get through their recommendations successfully is partly due to the above alignment:

- when a security recommendation is directly tied to complying with a regulation or   corporate information security policy

- when a security recommendation is directly tied to a problem which is plainly dumb and cannot be argued for

- when a project is sponsored by Information Security group themselves

- when security recommendations are not resulting in any extra efforts on the part of the IT group or if the security recommendation actually eases the job of IT

- when there is a security incident and the response process requires remediation

- purely for goodwill relations between individual members of the two groups

Considering a corporate environment culture, there is really no incentive for an IT group individual to go the extra mile of implementing security recommendations, since it would neither be recognized by their management nor tied to their performance evaluation. 

As shallow as it sounds, this is a fact and a true story of every enterprise, although it could be argued that it is a corporate ethics problem in many if not all cases. 

On the flip side, sometimes the IT group does not understand a given security risk to be as critical as it is being communicated, and for this we the members of the information security group should take the accountability, since that indicates we are not doing a great job of communicating risks or marketing an identified risk in an appropriate manner.

E.g. we are communicating a given problem as having a risk classification of HIGH and not able to communicate effectively the reason “why” to our genuine audience or the classification of the risk is not backed by a solid methodology that has been accepted at an enterprise level.

An IT Project lifecycle typically involves IT requirements, design, testing, and implementation.

Likewise, as recommended to engage security as early as possible in the project lifecycle, a typical security consulting service gets engaged at the IT requirements stage to provide security requirements, then security design, followed by security test cases and finally facilitate secure implementation all aligned to a project lifecycle.

Ideally this should work like a charm, but in most cases if not all, it doesn’t. The issues encountered are:

1)   The project did not have planned budget for engaging security

2)   The project lifecycle is shortened – e.g. requirements phase is skipped and the project jumps to design or sometimes requirements/design are skipped and project goes straight to implementation with vendor support resulting in not being able to engage security as required.

3)   The security team does not have enough resources to provide consulting services to each and every project, resulting in multiple projects escaping any security oversight.

4)   The security is able to deliver requirements, design and test cases as expected but there is no enforcement process and hence security is adopted sporadically a.k.a. a security considerations that feels lucky get implemented.

Another area where security is ignored is when new IT products are procured with 3rd party vendors, and the security group is not involved due to a missing representation/invitation in a business case or procurement process.

Finally, what I have observed in organizations where IS is part of IT,the risk communication is only done to the IT group, and the business owner who should actually know the risk is kept out of loop.

The decision to take steps towards mitigating a risk, or transferring the risk or accepting the risk does not involve the business owner, which seems like flawed logic.  The business owner is the actuall owner of the data processed by an IT system, and hence must hold the right and accountability to make an informed decision w.r.t determining how to deal with a given risk.

The business is a client for both IT and IS, so IT must not take the decision on behalf of business. in my next article I would like to elaborate more on risk communication and also what are the responsibilities of IS and IT when it comes to determining the action to be taken for a given risk.

These are some really high level observations for your typical enterprise. The idea here is to take an approach of problem solving than problem ranting . Hence, the objective is not to change the enterprise issues, but to tailor our Information Security Risk Management Program to be able to withstand these issues and be able to execute successfully.

Given these observations of what works and what does not for your information security risk management program, I will expand on “what works” aspect and try to provide remediation for what does not in Part 2 of this series.

Possibly Related Articles:
14778
Enterprise Security
Information Security
Risk Management Information Technology Chief Information Officer Information Security Enterprise
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.