Sunday, July 31, 2011

FAIR Risk Management Taxonomy

The FAIR Risk Management methodology is impressive work. Even if you never are going to use it, I suggest you read it as it broadens your understanding of risk management.
A while back FAIR was handed over to the Open Group, I hope that will have positive effects and it will spread and develop further.


You can find it here.


I've mapped the taxonomy into a full map. It comes handy every now and then, just to remind my self of all the aspects that I need to consider when analyzing risks.


Wednesday, June 8, 2011

Focus on the situation not the control types

We all know the three security control types: preventive, detective, corrective. When you are analyzing how to mitigate a risk you typically think about these three control types.

I find it more inutiative to focus on the stage of the event: pre-event, event, post-event. This way of addressing the problem creates context and leads faster to the identification of suitable controls.

Wikipedia maps the control types to the event stages like this:
  • Before the event, preventive controls are intended to prevent an incident from occurring e.g. by locking out unauthorized intruders;

  • During the event, detective controls are intended to identify and characterize an incident in progress e.g. by sounding the intruder alarm and alerting the security guards or police;

  • After the event, corrective controls are intended to limit the extent of any damage caused by the incident e.g. by recovering the organization to normal working status as efficiently as possible.


  • The only problem I have with that is the mapping of "During event, detective controls". When an event is occurring your only option of action is not just detective controls, you could also have additional "preventive" controls for example a worm is spreading in your network (event) and you are shaping your network traffic to slow it down or prevent it from spreading further. I suppose one could argue that you are preventing it from creating a new event, but that would be looking at the event as a series of isolated incidents which I believe would be countrproductive to looking it as one single event.

    This approach has been known in the injury prevention field as the Haddon Matrix, which basically addresses the three stages but investigates them through different factors.


    Interesting are also the possible ways to react in the three stages (reproduced below from Wikipedia), which is easily applicable to Information Security problems if you replace "agent" with "threat agent" and "host" with "asset".

    Pre-event
    1. Prevent the existence of the agent.
    2. Prevent the release of the agent.
    3. Separate the agent from the host.
    4. Provide protection for the host.

    Event

    1. Minimize the amount of agent present.
    2. Control the pattern of release of the agent to minimize damage.
    3. Control the interaction between the agent and host to minimize damage.
    4. Increase the resilience of the host.

    Post-event

    1. Provide a rapid treatment response for host.
    2. Provide treatment and rehabilitation for the host.
    If anyone has some good ideas how to apply the Haddon Matrix to information security and can suggest some factors to use, please share.

    Wednesday, April 13, 2011

    What's in a name?

    Every now and then I hear that we are supposed to speak in the language of the business. In principle I agree to that, after all it's about communication and since we are the service provider and the business is the customer we have to fall back on the taxonomy they are using. But that's about it, don't exaggerate.


    Take for example the service catalog, why would you refer to "E-Mail" as "Messaging Service" or "SAP" as "Enterprise Resource Planning" when for the past decade the customer has gotten used to these terms and is more confused by us trying to impose a perceived business language on them. My guess is that the user is perfectly OK with "Primavera" and probably confused if you suddenly start referring to it as "Enterprise Project Management". Maybe you can use those business terms in categorization, grouping etc. or in the service description but not necessarily in the service name if it's deviating from what business is really using on daily basis. 


    The point is that we are not on a crusade to stomp out technical jargon if it's perfectly well understood and used by the business. IT is no longer alien and it's an integral part of everyday life. OMG and LOL are to be included in the the Oxford English Dictionary, the times have changed.


    Don't loose focus of what the services are offering but don't necessarily brand them forcefully with supposedly business friendly terms.


    And while we are talking about names, what were they smoking when they came up with "IT Infrastructure Library"? It's such a lousy name, it has no meaning at all. Every now and then I catch myself talking and referring to ITIL as if it were something self contained (that's the best word I could come up with to describe it). The goal of improved Service Management becomes an after thought and that stupid (forgive my 5 year old choice of words) ITIL moniker abstracts it and doesn't help.

    Wednesday, March 23, 2011

    Some thoughts about good metrics...

    If you are like me then you must be facing some measurement challenges every now and then at work. There are some general rules that one needs to be aware of. Below is a short summary of some of those measurement rules, they mainly come from three sources that I highly recommend:
    Let's start with defining "Measurement". Doug Hubbard offers a simple definition for measurement "A set of observations that reduce uncertainty where the results is expressed as a quantity." (he looks at it as an information issue, read the book if that sounds interesting to you).
    So basically if your observation is expressed as a quantity and you know after it more than you did before then we can call this observation a measurement.  The additional point here is that the benefit of the measurement should be higher than the cost of making the measurement; else it's not of much value. 

    So what are the characteristics of good metrics?
    • Complete and Relevant: Good metrics are connected to important goals. Good metrics are the translation of goals expressed in English to math. The measure must accurately cover your needs to be useful. In some cases you might need multiple measurements to support your business needs. One metric alone might not be sufficient for drawing conclusions and decision making. Also remember that everything changes; your once relevant metrics might not be as relevant in the future.  
    • Consistent: Good metrics always go into on direction if things improve and the other if they deteriorate. The measure will always be the same no matter who carries out the measurement and records it. You can always count on the numbers. It's not a subjective exercise. If feasible the measurement should be automated.
    • Expressed as a cardinal number or percentage, not with qualitative labels like “High”, “medium”, and “low”
    • Expressed using at least one unit of measure, such as “defects”, “hours”, or “dollars”
    • Communication: The results need to be communicated. Measurements are typically shared with others. It should be easily recognizable what the metric means. When the metric drops/rises to unexpected levels the source of the problem and the necessary actions are clear to your audience.
    • Presentation: The presentation of measurements can be as important as the measurement itself. Spend some time on data visualization and always keep it simple.

    One last tip, question conventional wisdom and metrics that are suggested by others to you. Validate them using the above rules. Every now and then you will come across a metric mentioned in a reputable source that just doesn’t stand the validation test.

    Friday, March 18, 2011

    Security Firm RSA got hacked...what does that mean to the rest of us?

    By now anyone following information security must have heard about the RSA hack. If not go and google it for details. What exactly happened is not clear, RSA is talking about some sophisticated attack, but I guess they would say that no matter what. It doesn't really matter.

    So what does that mean to the rest of us:
    • If you are going to get hacked or not seems to be only a function of wether you are an attractive target or not. All other variables (attack vectors, risk, vulnerability...) seem to be just noise. It comes down to incentives and economics.
    • I still meet too many people whose eyes sparkle when they get the chance to talk about the latest security tools they implemented. Typically those start to fall apart a few months after the implementation. But the lesson here is that as much as you depend on security tools they are only as good as the people that designed them, the implementation and maintenance. Additionally they also can be your Achilles heel. Besides the complexity that they add, every now an then we find security tools that can somehow be exploited.
    • Instead of running after the latest security hypes, make sure you cover the basics:  least privilege, segregation of duties, change management, zoning, incident response, risk management, recovery, patch management, awareness, social engineering, default deny, defense in depth.....
    And this concludes my first post.