In part one we talked about some of the mistakes that companies make when it comes to risk management.  In this post we will focus on some of the items that a company can do to improve their risk management programs.   What I will lay out are three points/characteristics/aspects that a solid risk management program must have in order to be effective. 

Point One:   A common risk framework must exist throughout the organization, not just within one department.  This framework must:

·         Use a common definition for “risk;”

·         Support appropriate standards, regulations, guidelines;

·         Clearly define the key roles, responsibilities, and authority relating to risk management;

·         Support all of the business units and functions both in the way that these units accomplish their jobs as well as in the performance of their risk responsibilities.    

Many organizations recognize that risk means “the chance of something going wrong, hazard, statistical odds of danger” to quote the Encarta Dictionary.  What they forget is that there are positive aspects to risk.  Risk can be seen as the opportunity to create and preserve value.   

When I think of risk in this way an old saying comes to mind:

“When Life gives you Lemons, make Lemonade.”

In other words you need to create opportunity out of adversity.  Business is about risk.  There is no way to avoid it so why not simply seek to nullify its effects when you can leverage it to gain an advantage.   In my experience, the companies that embrace this concept of managing risk succeed not only in risk management but in the marketplace itself. 

Point Two:  Senior management must have the primary responsibility for the risk management program.  This means its design (it must be appropriate for the whole organization), its implementation (it must not favor one unit or function over another), and its ongoing operation.  Most importantly senior management must have complete visibility into how the organization (and each of its constituent components/units) manages risk. 

This means that risk must be coordinated across the entire organization.  Risk must be everyone’s responsibility; even those people who do not think they have any responsibilities with regard to risk.  True implementing technical security controls may be the primary responsibility of the IT department but in order for that implementation to be successful all departments and functions must share the responsibility.  IT needs to know if a particular control causes too much interference with the way the business is run so that they can make adjustments or implement alternative controls to reduce interference to a minimum.  The other departments and functions must realize that there are valid business reasons that these controls must be implemented. 

Senior Management needs to send the message that risk is a collective concern.  In order to do Senior Management needs to ensure that they communicate clearly and effectively.  They need to nurture a culture focused on risk (how to manage it and overcome it for the organizations benefit).  They need to institute a rewards program to provide positive reinforcement and they need to institute an effective learning program to educate everyone on what parts they play in the grand scheme of things. 

Point Three: Risk is an everyday concern and on every agenda not just on certain scheduled meetings. Each business units/function is responsible for the performance of not only their business and the management of risks they take.  This is important because it speaks to ownership and accountability. 

Not everyone is going to like this.  Honestly they don’t have to but they do have to climb on board and support the effort.  It is analogous to having to abide by the covenants in your homeowners association.  If you move into a neighborhood with a home owners association, then you agree to abide by the rules that the association agrees upon.  If you don’t want to do that then there are other homes that are not part of associations just as there are other companies to work in.  (Of course there are always rules set forth by the local, state, and a national government that we must abide by – that is part of living in an ordered society. )

Now not all business units or functions have the same scope when it comes to risk.  Some departments “own” risk management because they are the profit generating arms of the organization and other departments (such as HR, IT, finance, legal, etc) support these profit generating arms.  These supporting functions own the risk that arises out of their own area of responsibility in addition to sharing in the overall responsibility of supporting the overall organization.  It is very important (to harken back to Point One) that these functions have well defined articulated roles within the overall risk management program.  They must participate in risk discussions even when it is not clear that these discussions are directly related to them. 

I could go on but this post is getting a bit long already.   To sum everything up – risk is everyone’s responsibility.  Companies trade risk for reward daily so it shouldn’t be too large a leap to remind ourselves that the risks we face on a daily basis need not only be seen as a drag on the balance sheet.  They can be seen as opportunities to be leveraged.  Instituting a risk management program that pays attention to the three points that I have made above will do just that. 

What happens when a company experiences a data breach or a security incident?  Well aside from the obvious, someone often tries to figure out what went wrong.  Hopefully this means that they want to fix things so that it doesn’t happen again and not for finger pointing and assigning blame. 

Regardless of the reason, what can we learn from these events?  In this, the first part of a two part post, I’ll review the common mistakes that companies make prior to a security incident.  In part two we’ll discuss how companies should approach risk management in order to minimize their exposure to risk.  (Imagine that – a risk management program that actually manages risk. What a novel idea)

This list is in no way exhaustive or ordered by priority. This list comes from my experience and that of the other information security professionals that I have talked with over the years in my attempts to learn from other’s mistakes and experiences.  If you have other items that you’d like to offer for consideration please post a reply.

1.  Risk Management is diffused across the entire organization. 

Managing risk should be everyone’s responsibility but it should have a focal point and a champion.  One problem that occurs is that risk management activities are carried out my many different people from many different departments with little or no coordination between them.  This causes a repetition of effort and can actually create more risk than it actually addresses. 

2. Overlapping and interacting risk factors are often underestimated or ignored all together.

Much like the diet drug Fen-Phen, the interaction of two risk factors can have an exponential increase in the level of risk exposure.  In companies that experience security incidents the interaction between these factors are often ignored if they are even recognized in the first place.  When the interactions were highlighted by information security professionals, senior management often downplayed the interaction.  We can only speculate as to why.

3.  Warnings about security vulnerabilities and risk agents were ignored and those who gave them were criticized as malcontents or for not being team players.

When examining the events that lead up to a security incident, it is not uncommon to find that the warning signs were there.  In certain situations it wasn’t uncommon to learn that those who did voice the warning were criticized for what management considered “disruptive behavior.” 

4.  When risk modeling is used too much emphasis was placed on probabilistic modeling. 

Most security studies are highly inaccurate from the standpoint of the quantifiable measurement of security incidents.  (I can go on about this but it is really a separate topic.  If it is one of interest to you let me know and I’ll devote a post to that topic.) Most information security professionals believe that these studies only capture something like ten percent of the actual events that are occurring.  When you use these studies upon which to base probabilistic risk models you are doing so using inaccurate data.  This is fine as long as this fact is acknowledged and the numbers generated from the model are tempered with qualitative analysis. 

5. Senior management was so focused on making their numbers that other programs and initiatives (such as risk management and information security) were cut.

This problem is all about thinking tactically or strategically.  A long term strategic approach includes addressing the needs and requirements that can have the greatest impact over time.  If managements view is too tactical and short term then they run the risk of neglecting the long term concerns such as those having to do with appropriate risk management activities. 

6.  Companies lacked a comprehensive approach to risk management. 

A comprehensive approach takes into account quite a few different aspects and points of view rather than one or two narrow views.   Companies that lacked a comprehensive approach typically viewed risk management as a compliance exercise rather than as a business enabler.  I’ll go into more detail about this in Part Two so stay tuned. 

Again, these are just a few items that came to mind.  If you have your own that you have noticed then please share them.

I was recently involved in a discussion over the different terms used to describe what we do? Information Security (IS), Information Assurance (IA), or Information Risk Management (IRM). Some very interesting points and observations came out of that discussion so I thought I’d echo them here.
The discussion started on the Norwich University MSIA program alumni discussion forum. One of the graduates, Steven Hickey (MSIA ‘06) started the discussion by making the observation:

A colleague of mine, who also works as an Information Assurance (IA) professional (DoD specialty), argues that the CISSP certification has “absolutely nothing to do with IA.” He is of the opinion that Information Security is not Information Assurance and sees “no similarities” at all (ummm… none?). Anyway, from a DoD 8570 perspective, the IAM (managerial) level II and III are required to have the certification while none of the IAT (technical) levels are required to have the CISSP.

This started a discussion that went in two main directions – whether the CISSP certification is useful in both the technical and managerial realms (I won’t touch on this here) and whether or not Information Security (IS) is a subset of or has anything to do with Information Assurance (IA).

There were several great posts to this discussion. One was by John Graham (MSIA ‘04):

Although the DoD has ‘coined’ the phase Information Assurance, in my opinion the concept certainly is broader than information security, and information security is a subset of the information assurance space…knowing and understanding the concepts required for the CISSP only strengthen the Information Assurance professionals tool kit…

And

I have always found it interesting that most organizations tend to initially focus on technical controls, then gain the understanding of the required linkages to process and governance needed to actually implement and maintain the controls.
Information Security certainly does provide the control aspects, and the technical depth. When companies start looking at reasons why they have trouble actually ‘implementing’ information security policies, they begin to see the need for broader discussions more in line with information assurance.

Sharon Mudd (MSIA ‘08) took the concept even further.

I agree with John. To expand on that, in my view the entire space is going through a maturation process. What was once Information Security (focused strictly on IT) evolve into Information Risk Management (allowing it to broaden a bit) and is now heading towards Information Assurance. Each evolution incorporates what was there before and enhances the importance of getting out of the InfoSec silo and into the other areas where it runs into business processes/needs(or government, or whatever other entity you’re working with).

and

What was the original foundation of InfoSec seems to be what we’ve been referring to as Security Operations – or – the day-to-day hands on the firewalls/IPSs/etc. work that must be done even monitoring and incident detection can fall into this category. Where I think it goes over the wall to a risk management activity is when you start trying to understand what the alerts mean in context of your business functions and managing the issues from a cost/benefit or risk/reward perspective.

I believe the term “evolution” in this context is key. One of the things that I have enjoyed about being a consultant over the years is the variety of environments and networks that I’ve been privileged to become acquainted with. Most of the time the issues that I’ve come across had very little to do with the technology. Most technology issues were symptomatic of deeper alignment issues.

Many of the highly specialized (or more tactical) activities that IS “grew up with” have now begun to be relegated back to the network and infrastructure departments. Our role has evolved into a strategic role that bridges business units. IT, and by extension IS/IA/IRM, has been the one department that is typically siloed off from the rest of the company in terms of being fully integrated into business operations. This is most likely do to the fact that IT basically began as a support function not much above the mail room in importance. The companies that have seen the advantage of integrating IT and IS into their strategic planning process have gained a commanding advantage in the workplace.

Once you achieve an alignment with the business objectives, IS/IA/IRM projects are easier to sort out and prioritize in terms of their overall value. As we all know this requires that both the business units and IT cooperate in achieving the common goal. One key aspect of this is the use of a common taxonomy. In the end, whether we call it information security, information assurance, risk management or “skippity do” doesn’t really matter all that much as long as we achieve the ultimate goal of bringing value to our employers. The terminology may be determined by the sector in which were working, such as the DoD example, or it may be something that we can influence.

I believe that we must learn the language of business. Business won’t learn the language of information security – that is what they hire us for. The approach that requires management to learn “our language” is doomed to failure. Whatever the case I’m more of an advocate of using the terms that most clearly conveys the concept to my audience.