Develop the Ratings table/index
The ratings table consists of 3 columns.
Severity Rating
Occurrence Rating
And Detectability Rating
You typically have a scale from 1 to 5, 7 or 10 depending on the level of granularity that is needed in your organization
Anyone who has done a real BIA would get the Severity section almost immediately.
In short the trick here is to tie each escalating level of severity to some specific series of business impacts.
Brand/Reputation - TJX, Hannaford ... what else needs be said
Direct Financial Loss - Fraud, Equipment Damage, Theft, Embezzlement, Lost Sales ...
Indirect Financial Loss - Cost of Data Recreation, Lost FTO time, Lost future sales, Project Delays
Legal Liability - often part of direct and indirect but also includes, Legal costs, Fines, Cost of increased regulatory oversight ...
Compliance - The costs associated with failed compliance
Many more ... when you develop the ranking table do it with the business leads and let them define their concerns
Occurrence, and Detection Continued later
I will stress this one more time this is not a risk assessment it is a risk priority ranking. The risk guru's will definitely get the distinction right away but if you don't get it and you are doing this you will eventually run into the all powerful cost justification argument. It is powerful when dealing with audit and those pesky internal budget decisions.
Because it focuses primarily on priority it is faster, easier and more agile. Think 10 meetings vice 100 with 20 people instead of 200. (obviously adjust those for company size)
Showing posts with label Risks and Metrics. Show all posts
Showing posts with label Risks and Metrics. Show all posts
18 June, 2008
17 June, 2008
FMEA
Failure Mode Effects Analysis
I mentioned it a few weeks ago.
In a nutshell it is a relatively fast and dirty way of weighting and assessing relatively relative priority of risks. It is not a risk assessment and certainly not a ALE but if you combine it with a good series of BIA's linked empirically to the Failure Effects that are assessed against it can close a lot of gaps with not much work. If I were a consultant looking for a quick way to add risk prioritization value to a client I would certainly look into it. If the ratings table is properly developed it also significantly reduces the controversy of the rankings quite a bit.
More later
I mentioned it a few weeks ago.
In a nutshell it is a relatively fast and dirty way of weighting and assessing relatively relative priority of risks. It is not a risk assessment and certainly not a ALE but if you combine it with a good series of BIA's linked empirically to the Failure Effects that are assessed against it can close a lot of gaps with not much work. If I were a consultant looking for a quick way to add risk prioritization value to a client I would certainly look into it. If the ratings table is properly developed it also significantly reduces the controversy of the rankings quite a bit.
More later
16 April, 2008
11 February, 2008
GLB
Anyone want to chime in on what their take is on this quote from GLB?
"was, or is reasonably believed to have been, acquired by an unauthorized person"
What is reasonable?
Any case law people can link to?
How about other State Laws.
Oh yea a good table to have if you are a CISO, Director of Security or a Compliance lead. Not sure how up to date it is. But the current was November of '07.
"was, or is reasonably believed to have been, acquired by an unauthorized person"
What is reasonable?
Any case law people can link to?
How about other State Laws.
Oh yea a good table to have if you are a CISO, Director of Security or a Compliance lead. Not sure how up to date it is. But the current was November of '07.
29 March, 2007
Not quite 12 steps
I have gotten a few emails regarding the "Transforming Negligence to Non-Compliance"
Basically they said what the heck are you talking about.
It was part of a discussion I had with a counterpart and I thought it was a great quote.
Now I am going to say something a bit odd. "Transforming Negligence to Non-Compliance" is not a bad thing. It is a good thing and one of the only ways to get things rolling in an organization that is truly out of touch with its security risk profile.
Think of it as several stages of organizational growth.
Perhaps a counter part to Grossman's 5 stages of security grief.
It is just a nacient thought process for me so if anyone wants to expound or make it better feel free I'll be happy to point to you.
So here are the first few steps.
"Security by Self delusion" where institutional practices and political momentum make it virtually impossible to point out real security risks.
"Lethargic Negligence" - the problem is just too big to address for every fire I put out a dozen pop up. This isn't always intentional negligence (though for some people [mostly comfortable managers] it might be) but it always stands in the way of needed changes.
Transformation from Negligence to True Non-Compliance - This comes from a realization that something must be done and taking the responsibility for acknowledging that fact at a senior organizational level.
Maturing from Compliance to true Security. This stage is necessary if you ever want to prevent slipping all the way back to security by self delusion.
Proactive risk management - The actual practice of identifying true business concerns and risks of impacts and placing true security around them.
Any organization cycles through these at one time or another. Usually they are at slightly different stages for different parts of their security architecture as a whole. Their firewalls might be good but their OS's and Application Security is crap or their OS and App security fine but the linkage between their business controls and their IT SoD is crap. The worst organizations will institutionalize the Self Delusion model and actually swear and sign off that every thing is fine. After all "I have a Policy for that".
So how do you move up. I imagine it is a bit different for every organization. It will always involve some politics. As a matter of fact if you wanted to you might be able to call these the "political layers of info security".
The key to moving beyond "Security by Self Delusion" is visibility. True visibility not the pseudo transparency provided by 20,000 pages of attestation saying "yea we have a policy for that". True visibility is gained by actually identifying what is open in your firewalls. How good or bad is your patching process not just on the "managed" machines but on all of the ones connected to your network. As well as dozens of other specific facts. Get the whole picture then draw conclusions. Lets be honest here FUD might not be totally out of place if things are bad enough and it is based on facts. You achieve this by actually having the guts to run vulnerability scans, pen tests and even things as simple as port scans. If your organization is so resistant to transparency that they won't allow that how about a honey pot and some open sniffers. Outbound IDS's might help as well.
I know there is a lot of talk about how Vuln scans are not of value or IDS's are useless. That might be partially true in a healthy security environment or in one where IPS or even stronger protections are in place but if your organization is mired in the "Security by Self Delusion" mode they serve as one potential way beyond.
So what happens when senior management finally realizes that they have a problem and not just one but an entire systemic failure? Well Denial, Despondence, Anger, blame all of the not so fun reactions. Yes they often shoot the messenger. I am not able to tell anyone how to maneuver around these ones. What I will say is that if you have the facts and avoid placing individual blame (can be really hard if it is justified especially if someone is intentionally obfuscating issues) you can probably survive the series of back flashes. At this point the best bet is a series of tactical solutions that provide strategic benefit. Gain control (indirectly) of the Firewall and IPS rulesets, facilitate cross system visibility, HIPS, Identification of critical data, ... Every organisation will have different tactical needs but pick a few and fix them as best that you can.
Now is the tricky part. The gut reaction of senior management will be to say "Great we're ok. Now let's move on to more important things" That is fine to an extent after all the real business of IT is to facilitate the real business but you also have to put structure in place to maintain and improve the other real issues that didn't seem as painful but might very well carry more risk. You have to put in place a Governance and Policy structure that actually has some teeth but doesn't cripple the company. This is where you start transforming Negligence to Non-Compliance.
I am going to have to try to finish this tomorrow.
Basically they said what the heck are you talking about.
It was part of a discussion I had with a counterpart and I thought it was a great quote.
Now I am going to say something a bit odd. "Transforming Negligence to Non-Compliance" is not a bad thing. It is a good thing and one of the only ways to get things rolling in an organization that is truly out of touch with its security risk profile.
Think of it as several stages of organizational growth.
Perhaps a counter part to Grossman's 5 stages of security grief.
It is just a nacient thought process for me so if anyone wants to expound or make it better feel free I'll be happy to point to you.
So here are the first few steps.
"Security by Self delusion" where institutional practices and political momentum make it virtually impossible to point out real security risks.
"Lethargic Negligence" - the problem is just too big to address for every fire I put out a dozen pop up. This isn't always intentional negligence (though for some people [mostly comfortable managers] it might be) but it always stands in the way of needed changes.
Transformation from Negligence to True Non-Compliance - This comes from a realization that something must be done and taking the responsibility for acknowledging that fact at a senior organizational level.
Maturing from Compliance to true Security. This stage is necessary if you ever want to prevent slipping all the way back to security by self delusion.
Proactive risk management - The actual practice of identifying true business concerns and risks of impacts and placing true security around them.
Any organization cycles through these at one time or another. Usually they are at slightly different stages for different parts of their security architecture as a whole. Their firewalls might be good but their OS's and Application Security is crap or their OS and App security fine but the linkage between their business controls and their IT SoD is crap. The worst organizations will institutionalize the Self Delusion model and actually swear and sign off that every thing is fine. After all "I have a Policy for that".
So how do you move up. I imagine it is a bit different for every organization. It will always involve some politics. As a matter of fact if you wanted to you might be able to call these the "political layers of info security".
The key to moving beyond "Security by Self Delusion" is visibility. True visibility not the pseudo transparency provided by 20,000 pages of attestation saying "yea we have a policy for that". True visibility is gained by actually identifying what is open in your firewalls. How good or bad is your patching process not just on the "managed" machines but on all of the ones connected to your network. As well as dozens of other specific facts. Get the whole picture then draw conclusions. Lets be honest here FUD might not be totally out of place if things are bad enough and it is based on facts. You achieve this by actually having the guts to run vulnerability scans, pen tests and even things as simple as port scans. If your organization is so resistant to transparency that they won't allow that how about a honey pot and some open sniffers. Outbound IDS's might help as well.
I know there is a lot of talk about how Vuln scans are not of value or IDS's are useless. That might be partially true in a healthy security environment or in one where IPS or even stronger protections are in place but if your organization is mired in the "Security by Self Delusion" mode they serve as one potential way beyond.
So what happens when senior management finally realizes that they have a problem and not just one but an entire systemic failure? Well Denial, Despondence, Anger, blame all of the not so fun reactions. Yes they often shoot the messenger. I am not able to tell anyone how to maneuver around these ones. What I will say is that if you have the facts and avoid placing individual blame (can be really hard if it is justified especially if someone is intentionally obfuscating issues) you can probably survive the series of back flashes. At this point the best bet is a series of tactical solutions that provide strategic benefit. Gain control (indirectly) of the Firewall and IPS rulesets, facilitate cross system visibility, HIPS, Identification of critical data, ... Every organisation will have different tactical needs but pick a few and fix them as best that you can.
Now is the tricky part. The gut reaction of senior management will be to say "Great we're ok. Now let's move on to more important things" That is fine to an extent after all the real business of IT is to facilitate the real business but you also have to put structure in place to maintain and improve the other real issues that didn't seem as painful but might very well carry more risk. You have to put in place a Governance and Policy structure that actually has some teeth but doesn't cripple the company. This is where you start transforming Negligence to Non-Compliance.
I am going to have to try to finish this tomorrow.
26 January, 2007
09 January, 2007
22 December, 2006
Moneyball in Academia
Interesting Hiring Practices
I would like to see more of it in the Corporate world
but we seem to have trouble defining what "Win" means to us.
I would like to see more of it in the Corporate world
but we seem to have trouble defining what "Win" means to us.
18 December, 2006
Tenable SCADA webcast
This got delayed last week but is up now.
I haven't had the time to view it yet. If anyone gets to it before I do I'll be happy to move what they say up from comments.
Update:
The link wasn't working earlier but I believe it is now fixed.
I haven't had the time to view it yet. If anyone gets to it before I do I'll be happy to move what they say up from comments.
Update:
The link wasn't working earlier but I believe it is now fixed.
12 December, 2006
Oh how I love Risk Formulas
The Square Root of Terrorism.
I actually do like them usually. Anyone who has heard me drone on will attest that I am always trying to find ways to make them empirical and evangelizing on their use in persuading managment. Still it is important to keep them in context.
I actually do like them usually. Anyone who has heard me drone on will attest that I am always trying to find ways to make them empirical and evangelizing on their use in persuading managment. Still it is important to keep them in context.
11 December, 2006
What are the odds?
I normally rail against "what if" this insanely improbable threat happens in this incredibly unusual way.
I call it the "what if" argument.
When I was in grade school there was a kid that liked to push peoples buttons. He would ask questions like
"What if I threw your math book out the bus window?"
"What if some guy came up and hit you in the face?"
"What if I tore your arm off in hit you with it?"
Clearly he was a bit deranged. It is also pretty transparent that he used it as a means to intimidate and control others.
I pretty regularly run into this kid in the info security world in the form of completely unrealistic risk assessments and audit findings. I am sure that the motive is better hidden from the author of these writings but the goal just might be the same.
Still we should keep in mind that sometimes the wildly improbable happens.
"What if a Thanksgiving parade float almost kills you then a private plane crashes into your house?"
Am I just perpetuating an urban legend here?
I call it the "what if" argument.
When I was in grade school there was a kid that liked to push peoples buttons. He would ask questions like
"What if I threw your math book out the bus window?"
"What if some guy came up and hit you in the face?"
"What if I tore your arm off in hit you with it?"
Clearly he was a bit deranged. It is also pretty transparent that he used it as a means to intimidate and control others.
I pretty regularly run into this kid in the info security world in the form of completely unrealistic risk assessments and audit findings. I am sure that the motive is better hidden from the author of these writings but the goal just might be the same.
Still we should keep in mind that sometimes the wildly improbable happens.
"What if a Thanksgiving parade float almost kills you then a private plane crashes into your house?"
Am I just perpetuating an urban legend here?
10 November, 2006
Risk Structure
Excellent post on Risk Structure at RiskAnalys.is
I've been slacking in terms of good content in my posts this last week. I'll try to pick it up. A particular topic I am going to try to address is context for the business around risk discussion. Another is controls specific to SCADA environments.
I've been slacking in terms of good content in my posts this last week. I'll try to pick it up. A particular topic I am going to try to address is context for the business around risk discussion. Another is controls specific to SCADA environments.
03 November, 2006
31 October, 2006
Threats, Vulnerabilities, and Controls
I would be interested in seeing the security blogsphere's take on the relationship between Threats, Vulnerabilities and Controls.
I know that strictly speaking a vulnerability is not the inverse of a control (obviously it is sort of apples and oranges) but there does seem to be a connection.
One of my earlier posts I talked about threat classifications but fleshing it out to include what the environment is like and how to compensate assesments for theat likelyhood vs existing controls would be valuable.
I know that strictly speaking a vulnerability is not the inverse of a control (obviously it is sort of apples and oranges) but there does seem to be a connection.
One of my earlier posts I talked about threat classifications but fleshing it out to include what the environment is like and how to compensate assesments for theat likelyhood vs existing controls would be valuable.
24 October, 2006
21 October, 2006
Books - Some lighter Weekend Fare
Last years Reading list (well some of it anyway)
Non - Fiction
Freakonomics
Thought provoking and good example on how to look at conventional wisdom. Light touch on being realistic about statistics.
Moneyball
Awesome baseball and awesome business book. Thought provoking on how to look at statistics and what really matters.
The Singularity is Near
If it is right it changes everything. Even if it is only close to right it means that automation security will become one the most significant issues there is. (yes I know that sounds outrageous. You will have to read it and think to understand what I mean by that). Brings "Engines of Creation" into an easier to digest format. (though definitely that should be a read as well. Perhaps I should dig it out again)
Army of Davids
A phenomenal take on the existing trends that already exist and have occurred in the last several years. Written by Instapundit one of my daily reads.
Corporate Confidential
Blunt and Honest a light approach to the "Prince" of our time.
Execution
The title say it all.
Fiction and more later
Non - Fiction
Freakonomics
Thought provoking and good example on how to look at conventional wisdom. Light touch on being realistic about statistics.
Moneyball
Awesome baseball and awesome business book. Thought provoking on how to look at statistics and what really matters.
The Singularity is Near
If it is right it changes everything. Even if it is only close to right it means that automation security will become one the most significant issues there is. (yes I know that sounds outrageous. You will have to read it and think to understand what I mean by that). Brings "Engines of Creation" into an easier to digest format. (though definitely that should be a read as well. Perhaps I should dig it out again)
Army of Davids
A phenomenal take on the existing trends that already exist and have occurred in the last several years. Written by Instapundit one of my daily reads.
Corporate Confidential
Blunt and Honest a light approach to the "Prince" of our time.
Execution
The title say it all.
Fiction and more later
20 October, 2006
Metric Geek
Yet another great post on Riskanalys on risk management.
http://www.riskmanagementinsight.com/riskanalysis/
A lot of people out there have been bashing the risk management model of data security. The essence of the attack generally comes down to "that didn't come from real data." In many cases that is true.
In just as many the fault lies with us looking at the wrong data or worse doing the right thing a the wrong time and just not being "lucky".
http://www.tcsdaily.com/Article.aspx?id=102006A
Moneyball is a great book that I would recommend for anyone.
I got three great peanuts out of it.
1. Make sure you are tracking the right metrics.
2. Even if the metrics correlate with the goals look for better ones for your objectives. (i.e. better batting average does make you a better player but on base percentage is a better indicator of whether you can generate scores)
3. Probability (luck) means that even if you are looking at the right things sometimes you won't see what is right. The trick is to find out why and what the real desired outcome is.
I suppose that I fall to a certain extent into the "metrics geek" camp on the security side.
In defense of the metrics people there is precedent. The insurance and financial industry's have identified that the equations really do work. You just have to be measuring the right stuff.
Nuclear physicist do the same things and the equations are remarkably similar.
18 October, 2006
17 July, 2006
Risk Structure
Risk = Impact * Probability
Probability = Threats – Preventative Controls
Mitigating Controls
So what are the real pieces of this overused and debunked but not disproved equation?
Impact is Significance modified by the different forms of Immediacy
In the entire risk structure the only thing that Digital Security as an organization can reliably affect is the Controls/Management aspect. All other aspects of the process are defined outside of the Security team. We need to identify them and can determine which are in context for us but we cannot change them. Within likelihood the threats are controlled by the originators of the threats. Within Impact immediacy and significance are either inherent or defined by the business needs.
Context
Context – the context is the defined structure that the other portions of risk are compared against and dependant upon.
It defines the scale of review and management of controls.
In short - What are the scope and limitations of the risk management?
•What is being protected/assessed?
–Group, Segment, Business Unit, Project, Plant, Pipeline, …
•What are the applicable impact mechanisms?
–Confidentiality, Integrity, Availability, Environmental, Safety, Liability…
•What are the Applicable threat sources?
–Eve the evil hacker, Joe the employee, Virus, Mafia, Government, Competition…
•What are the acceptable Controls/Management functions?
–How much cost is acceptable?
–How much admin is acceptable?
–Who has Authority?
–Who has Responsibility?
–How does it overlap with other controls? e.g. Failsafes, FC&A, Physical Security
Impact is Significance modified by the different forms of Immediacy
In the entire risk structure the only thing that Digital Security as an organization can reliably affect is the Controls/Management aspect. All other aspects of the process are defined outside of the Security team. We need to identify them and can determine which are in context for us but we cannot change them. Within likelihood the threats are controlled by the originators of the threats. Within Impact immediacy and significance are either inherent or defined by the business needs.
Context
Context – the context is the defined structure that the other portions of risk are compared against and dependant upon.
It defines the scale of review and management of controls.
In short - What are the scope and limitations of the risk management?
•What is being protected/assessed?
–Group, Segment, Business Unit, Project, Plant, Pipeline, …
•What are the applicable impact mechanisms?
–Confidentiality, Integrity, Availability, Environmental, Safety, Liability…
•What are the Applicable threat sources?
–Eve the evil hacker, Joe the employee, Virus, Mafia, Government, Competition…
•What are the acceptable Controls/Management functions?
–How much cost is acceptable?
–How much admin is acceptable?
–Who has Authority?
–Who has Responsibility?
–How does it overlap with other controls? e.g. Failsafes, FC&A, Physical Security
Subscribe to:
Posts (Atom)
