Has anyone found any good resources on cloud computing and security?
I recently found this site:
http://cloudsecurity.org/
But I'm keen to find any other good security resources in this space. Finding stuff and over and beyond what I consider "common sense security" is actually quite hard to find.
- J.
Thursday, September 10, 2009
Security Exemptions
Originally I was going to write a post on business enablement but somehow in my mind this was a nice segway into security exemptions. So I'm going to blow off my original post and instead, blather about exemptions.
I am a firm believer that IT exists to support the business and that IT should always be about finding ways for business to operate quicker, more efficiently, cost effectively, etc. To that end, security should always be an enabler. But the reality is that this isn't as easy as it sounds and this is the difference between a pragmatic and lateral thinking security advisor vs an overly restrictive one - and the reason pragmatics are more widely desired.
I suppose when firewall changes, policy exemptions, risk statements are your daily bread and butter it is a bit hard not to be perceived as the "bouncher" or "naysayer". I've had more than my fair share of this. I've also seen people who are much harder to deal with than myself. I've seen people actively try and avoid going through me because I've been perceived as difficult to deal with. I've also experienced the reverse - situations where I've been approached because I've been perceived as the "lesser" evil. I've also seen some security staff really abuse their position and block work activity for a variety of random reasons (i.e. "we weren't formally engaged!", "it isn't documented!", "not enough time to review").
It is one of the most annoying parts of being in security because it typically results in one or more of the following:
a) someone ticked off (either the security guy approving an exemption or the person whose request is rejected)
b) more work for the security advisor
c) an interruption to his daily workflow.
This is as at a minimum.
I'm not going to proclaim loudly I get these right all the time. Far from it. Infact I probably would be the first to admit I make more than my fair share of mistakes - largely from the sheer volume of requests I receive and constraints on my time that render it impossible for me to attend to these as thoroughly as I'd like. But I strive to be always conscious of my contribution when I receive these requests (see my 'checklist' below). Whats more, I've learned a lot from both my own mistakes and those of my peers on how to handle these. I also believe in the "Law of Reciprocity". Thankfully I receive so many of these types of requests in my current role that I get plenty of opportunities to practise!
And without a doubt, I would say it is the hardest part of my job.
We never win friends when we say "no" - and sometimes looking at how you can enable the business takes some very, very positive thinking. Particularly when the request seems insane and/or delusional upon first glance (I.e. "Please allow 10.0.0.0/16 through the external firewall and disable our VPN. Kthxbai"). We're often given minimal information to work with and in many cases we are given the appropriate documentation, we often have zero time to review it adequately. Then we're expected to make snap decisions on that basis.
To make matters worse, if we get any of these wrong, a litany of "bad things" can occur -
- new security "holes" are introduced that could be exploited
- risks are vastly underestimated exposing the business to higher levels of risk
- "undocumented features" appear in your network, applications and systems
- spectacular audit and compliance failures with further consequential business impacts
- hostility in the workplace
- staff actively avoiding you or approaching higher level managers to supercede you
etc.
Guess who is typically the target when any of the above occures? If you said "security" you would be spot on.
Anyway, whenever we are approached for an exemption this is my 'checklist' of things that should be going through the security advisor's mind. It is probably not complete as this is all off the top of my head, as are most of these posts:
What is the business criticality of the request? Will the business be crippled through inaction by adhering to the policy or best practise? How much pain can the business take? Sometimes it is necessary to block requests but a good advisor must really look at the request on its own merit, evaluate it against the business unit, the work involved and the company as a whole. It isn't easy to do when you're under the pump.
Has a risk assessment been performed? Can the advisor do a risk assessment - formally or informally? What is the risk appetite of the organisation? Are they willing to wear a potentially high level of risk in future vs the immediate pain of a request not going ahead? Have they signed off on the risk? Is it captured in the right register?
Are the right stakeholders across this? Are they aware of the impact - both immediate and potential? Sometimes the right people are simply not involved. Are they aware of the risk assessment? Do they agree with it? Are they willing to accept the risk? Are there other business units (Finance, Privacy, Legal) who may take a dimmer view of things than Information Security?
What is the security maturity of the business unit? Do they have a history of repeatedly trying to put security off to "another day"? Are they constantly looking for the tactical, spot solution and never the strategic response? Sometimes dragging these units through the formal process is a necessity to call them to task. Othertimes, you may need to be more agile in your thinking and look for quick wins but formalise a long term action plan, balancing strategic requirements with tactical demands.
What are the policy, legal, regulatory demands? These requirements will vary based on organisation type, industry, size, country of operation, etc. etc. Their risk appetites will vary from organisation to organisation. As such, certain requirements can be more flexible than others. Businesses vary in their regard to maintaining security. A good security advisor knows the business, knows their risk appetite, what is necessary and most importantly, knows what battles to fight.
I don't have an solutions here unfortunately. I think this battle will be going on long after I've passed from this life. But here's some strategies I've found that help:
- Focus on building solid rapport with your business stakeholders. At least then when you reject their request they don't hate you in the morning and hopefully respect remains for your position on the matter, even if they disagree.
- Look for win/win outcomes . Look for ways to say "yes" rather than "no" (I have mentioned this before). Even just thinking "how can I say yes to this request?" can have a vast impact on your approach and how solutions are found.
- Try to understand the business requirement. The whole "walk a mile in someone else's shoes" thing. Beyond understanding the simple requirement, try to understand the other person's position and what they need.
- Look for tactical as well as strategic outcomes. Security comes in all shades of grey.
- Ensure you capture the risks appropriately. Even an email articulating the risk to the right stakeholder is better than not raising a risk at all. If you can raise it in a formal risk statement and risk register, good on you.
- Don't block a request out of spite. If you block a request, be clear on your reasons why.
I'd love to hear thoughts or tales from other security professionals on their approach to exemption requests - good, bad and ugly.
Cheers
- J.
I am a firm believer that IT exists to support the business and that IT should always be about finding ways for business to operate quicker, more efficiently, cost effectively, etc. To that end, security should always be an enabler. But the reality is that this isn't as easy as it sounds and this is the difference between a pragmatic and lateral thinking security advisor vs an overly restrictive one - and the reason pragmatics are more widely desired.
I suppose when firewall changes, policy exemptions, risk statements are your daily bread and butter it is a bit hard not to be perceived as the "bouncher" or "naysayer". I've had more than my fair share of this. I've also seen people who are much harder to deal with than myself. I've seen people actively try and avoid going through me because I've been perceived as difficult to deal with. I've also experienced the reverse - situations where I've been approached because I've been perceived as the "lesser" evil. I've also seen some security staff really abuse their position and block work activity for a variety of random reasons (i.e. "we weren't formally engaged!", "it isn't documented!", "not enough time to review").
It is one of the most annoying parts of being in security because it typically results in one or more of the following:
a) someone ticked off (either the security guy approving an exemption or the person whose request is rejected)
b) more work for the security advisor
c) an interruption to his daily workflow.
This is as at a minimum.
I'm not going to proclaim loudly I get these right all the time. Far from it. Infact I probably would be the first to admit I make more than my fair share of mistakes - largely from the sheer volume of requests I receive and constraints on my time that render it impossible for me to attend to these as thoroughly as I'd like. But I strive to be always conscious of my contribution when I receive these requests (see my 'checklist' below). Whats more, I've learned a lot from both my own mistakes and those of my peers on how to handle these. I also believe in the "Law of Reciprocity". Thankfully I receive so many of these types of requests in my current role that I get plenty of opportunities to practise!
And without a doubt, I would say it is the hardest part of my job.
We never win friends when we say "no" - and sometimes looking at how you can enable the business takes some very, very positive thinking. Particularly when the request seems insane and/or delusional upon first glance (I.e. "Please allow 10.0.0.0/16 through the external firewall and disable our VPN. Kthxbai"). We're often given minimal information to work with and in many cases we are given the appropriate documentation, we often have zero time to review it adequately. Then we're expected to make snap decisions on that basis.
To make matters worse, if we get any of these wrong, a litany of "bad things" can occur -
- new security "holes" are introduced that could be exploited
- risks are vastly underestimated exposing the business to higher levels of risk
- "undocumented features" appear in your network, applications and systems
- spectacular audit and compliance failures with further consequential business impacts
- hostility in the workplace
- staff actively avoiding you or approaching higher level managers to supercede you
etc.
Guess who is typically the target when any of the above occures? If you said "security" you would be spot on.
Anyway, whenever we are approached for an exemption this is my 'checklist' of things that should be going through the security advisor's mind. It is probably not complete as this is all off the top of my head, as are most of these posts:
What is the business criticality of the request? Will the business be crippled through inaction by adhering to the policy or best practise? How much pain can the business take? Sometimes it is necessary to block requests but a good advisor must really look at the request on its own merit, evaluate it against the business unit, the work involved and the company as a whole. It isn't easy to do when you're under the pump.
Has a risk assessment been performed? Can the advisor do a risk assessment - formally or informally? What is the risk appetite of the organisation? Are they willing to wear a potentially high level of risk in future vs the immediate pain of a request not going ahead? Have they signed off on the risk? Is it captured in the right register?
Are the right stakeholders across this? Are they aware of the impact - both immediate and potential? Sometimes the right people are simply not involved. Are they aware of the risk assessment? Do they agree with it? Are they willing to accept the risk? Are there other business units (Finance, Privacy, Legal) who may take a dimmer view of things than Information Security?
What is the security maturity of the business unit? Do they have a history of repeatedly trying to put security off to "another day"? Are they constantly looking for the tactical, spot solution and never the strategic response? Sometimes dragging these units through the formal process is a necessity to call them to task. Othertimes, you may need to be more agile in your thinking and look for quick wins but formalise a long term action plan, balancing strategic requirements with tactical demands.
What are the policy, legal, regulatory demands? These requirements will vary based on organisation type, industry, size, country of operation, etc. etc. Their risk appetites will vary from organisation to organisation. As such, certain requirements can be more flexible than others. Businesses vary in their regard to maintaining security. A good security advisor knows the business, knows their risk appetite, what is necessary and most importantly, knows what battles to fight.
I don't have an solutions here unfortunately. I think this battle will be going on long after I've passed from this life. But here's some strategies I've found that help:
- Focus on building solid rapport with your business stakeholders. At least then when you reject their request they don't hate you in the morning and hopefully respect remains for your position on the matter, even if they disagree.
- Look for win/win outcomes . Look for ways to say "yes" rather than "no" (I have mentioned this before). Even just thinking "how can I say yes to this request?" can have a vast impact on your approach and how solutions are found.
- Try to understand the business requirement. The whole "walk a mile in someone else's shoes" thing. Beyond understanding the simple requirement, try to understand the other person's position and what they need.
- Look for tactical as well as strategic outcomes. Security comes in all shades of grey.
- Ensure you capture the risks appropriately. Even an email articulating the risk to the right stakeholder is better than not raising a risk at all. If you can raise it in a formal risk statement and risk register, good on you.
- Don't block a request out of spite. If you block a request, be clear on your reasons why.
I'd love to hear thoughts or tales from other security professionals on their approach to exemption requests - good, bad and ugly.
Cheers
- J.
Subscribe to:
Posts (Atom)