Confessions of an Information Security Manager ?

Posted in /etc/IT_security/news, /opt/risk_management, /root/IT Management on September 10th, 2008 by Rick Zhong

I just read an article “Confessions of a Risk Manager” from economist.com. It is recommended by a featured blog post “Risk Managers Are Just Like Security People” on securityfocus.com.  The article truely and vividly described the kind of difficulties and dilemmas encountered by a Risk Manager, which I can very much relate them the information security folks in the finanical sectors. The situations are amazingly similar between information security folks and the risk managers.

” In their (By Rick: the business people mainly front line traders, bankers, sales) eyes, we were not earning money for the bank. Worse, we had the power to say no and therefore prevent business from being done. Traders saw us as obstructive and a hindrance to their ability to earn higher bonuses. They did not take kindly to this. Sometimes the relationship between the risk department and the business lines ended in arguments. . . .

Tactfully explaining why we said no was not our forte. Traders were often exasperated as much by how they were told as by what they were told.At the root of it all, however, was—and still is—a deeply ingrained flaw in the decision-making process. In contrast to the law, where two sides make an equal-and-opposite argument that is fairly judged, in banks there is always a bias towards one side of the argument. The business line was more focused on getting a transaction approved than on identifying the risks in what it was proposing. The risk factors were a small part of the presentation and always “mitigated”. This made it hard to discourage transactions. If a risk manager said no, he was immediately on a collision course with the business line. The risk thinking therefore leaned towards giving the benefit of the doubt to the risk-takers.

Collective common sense suffered as a result. Often in meetings, our gut reactions as risk managers were negative. But it was difficult to come up with hard-and-fast arguments for why you should decline a transaction, especially when you were sitting opposite a team that had worked for weeks on a proposal, which you had received an hour before the meeting started. In the end, with pressure for earnings and a calm market environment, we reluctantly agreed to marginal transactions.”

Probably I shall replace all the financial terms with information security terms in this articule and come out a new version titled “Confessions of a Information Security Manager”.

Tags: ,

Implementation - The Missing Link

Posted in /opt/risk_management, /var/rant on September 8th, 2008 by Rick Zhong

(This post does not have any answers, just my personal ranting :P )

Recently I have attended a few risk management conferences mainly for financial institutions. The most common question asked was “what’s the risk management framework used by your institute?” Then it was usually followed by a round of discussion on Basel II or COSO ERM (Enterprise Risk Management). For IT folks, the topics will revolve around the risk management in IT govenance, COBIT or ITIL. However when it comes to the point of implementation, it becomes an evasive topic and most of the time I hear people complaining about the difficulties in implementing all these established frameworks etc.

Similar to the RM domain, implementation difficulties were constantly mentioned during my last conversation with a couple of Business Continuity folks.  It brings me to the questions - what’s the use of all these frameworks when they are not properly implemented? Are we spending too much efforts in coming out with these framework and methodology?Is it the time for the industry to channel some attention or resources to the implementation for these established frameworks?

I just read from ISACA’s Information System Control Journal that ITGI (IT Governance Institue ) has identified a gap in the current array of risk management framworks for IT: there is no known framework that includes both a holistic look at risk management and, at the same time,  provides adequate depth and details when covering IT. I just hope this ‘depth’ and ‘details’ are refering to the implementation aspect as well.

References and Resources: CONSTRUCTION OF AN IT RISK FRAMEWORK

Tags: