Just a quick plug for my latest article over at Computer Weekly:
http://www.computerweekly.com/Articles/2010/11/25/244113/Security-Zone-Cloud-computing-puts-the-spotlight-on-security.htm
To be honest, I started off with every intention of writing a generic article about the value of security architecture within which there would be no mention of cloud computing at all. But I couldn't help myself. The fit was too natural. So I prattle on about why security architecture is so valuable (e.g. demonstrable traceability from risk and/or requirement through to deployed solution) and then why this is particularly relevant to cloud deployments in terms of ensuring consistency across delivery models: solutions should share business requirements and business risks regardless of IT delivery model, you just tweak around the logical and physical elements once you know which model you're going for...
Go on, take a look. Feel free to leave comments here if you're so inclined.
Monday, 29 November 2010
Friday, 22 October 2010
Cyber security, national security and the CSR
Well, it's certainly been an interesting week. Firstly we discover that cyberattack ranks right up at the top of the risk list for the UK alongside more familiar terrorist activities. We also discover that there's an extra £650m worth of public funds being set aside to improve our cyberdefences. Setting aside some fairly natural cynicism that pushing the (relatively) cheaper option of boosting our cyberdefences (compared to a fully functional aircraft carrier for example) is nothing more that a nifty political sidestep, I must admit to some interest in seeing where this extra cash is going to go. I can't help feeling a little fear that this money could be wasted in a couple of ways:
i) Supporting the numerous organisations that we already have dealing with cybersecurity in the UK, e.g. CESG (and CSOC), the Cabinet Office (and the OCS), etc and increasing the overall bureaucracy
ii) Purchasing more firewalls and intrusion prevention systems and other easily packaged and easily procured technologies.
The core problems facing HMG and the wider CNI relate to a lack of understanding of the true threats and likely attack vectors together with an unfortunate lack of effective governance for cybersecurity issues. I'm fairly sure that the risk appetites of any number of organisations would shrink dramatically should individuals of the correct seniority be held personally accountable for any security incidents. Of course, in order to get to this position there needs to be the appropriate will and desire to enforce such individuals to take on this responsibility and then money spent on the education of these newly willing volunteers to ensure that they can actually make informed decisions. In the interests of fairness, I think there's also a case to be made for educating many security professionals so that they can discuss threats, vulnerabilities and risks in a manner that can be understood by senior business types - technologies don't really matter so much as the potential business impact. We need to understand the technologies to minimise risk, they need to understand the business impacts so that they can tell us which risks we should be concentrating upon. None of this is news to most of you, and it's been tried before (particularly post Hannigan), but there's still a lot more to be done.
Fingers crossed that this money finds it's way to those who know what needs to be done and not simply thrown at technology - I know it's lot easier to procure a firewall than it is to procure a well-informed Senior Information Risk Owner but I also know which has the most beneficial effect in the long term...
i) Supporting the numerous organisations that we already have dealing with cybersecurity in the UK, e.g. CESG (and CSOC), the Cabinet Office (and the OCS), etc and increasing the overall bureaucracy
ii) Purchasing more firewalls and intrusion prevention systems and other easily packaged and easily procured technologies.
The core problems facing HMG and the wider CNI relate to a lack of understanding of the true threats and likely attack vectors together with an unfortunate lack of effective governance for cybersecurity issues. I'm fairly sure that the risk appetites of any number of organisations would shrink dramatically should individuals of the correct seniority be held personally accountable for any security incidents. Of course, in order to get to this position there needs to be the appropriate will and desire to enforce such individuals to take on this responsibility and then money spent on the education of these newly willing volunteers to ensure that they can actually make informed decisions. In the interests of fairness, I think there's also a case to be made for educating many security professionals so that they can discuss threats, vulnerabilities and risks in a manner that can be understood by senior business types - technologies don't really matter so much as the potential business impact. We need to understand the technologies to minimise risk, they need to understand the business impacts so that they can tell us which risks we should be concentrating upon. None of this is news to most of you, and it's been tried before (particularly post Hannigan), but there's still a lot more to be done.
Fingers crossed that this money finds it's way to those who know what needs to be done and not simply thrown at technology - I know it's lot easier to procure a firewall than it is to procure a well-informed Senior Information Risk Owner but I also know which has the most beneficial effect in the long term...
Monday, 20 September 2010
Authentication in the cloud
One of the more common criticisms of cloud computing is that the available authentication mechanisms are weaker than those available to more traditional deployments. Today's announcement by Google that it will now support a form of two-factor authentication for it's Google Apps service is a welcome rebuttal to such criticisms:
http://googleenterprise.blogspot.com/2010/09/more-secure-cloud-for-millions-of.html
Whilst I'm on this topic I should also point out that Amazon Web Services have been offering multi-factor authentication functionality since late 2009 via the use of Gemalto tokens which generate one-time codes - details available here:
http://aws.amazon.com/mfa/
Of course, what you don't want to end up with is a scenario where you have to carry multiple devices (phones, tokens etc) capable of generating security tokens for each cloud service you deploy. One way around this would be to consider the use of SAML and a single authentication provider for all of your cloud services. Take a look at the CRYPTOCard Managed Authentication Service - you may like what you see!
https://www.cryptocard.com/mas/index.php?option=com_content&view=article&id=39&Itemid=2
And as none of my blog posts seem to be complete without a link out to more of my ramblings, you may be interested in what a number of luminaries (and me) have to say about value added cloud services over at:
http://www.computerweekly.com/Articles/2010/09/06/242626/Security-think-tank-Value-added-cloud-security-services.htm
http://googleenterprise.blogspot.com/2010/09/more-secure-cloud-for-millions-of.html
Whilst I'm on this topic I should also point out that Amazon Web Services have been offering multi-factor authentication functionality since late 2009 via the use of Gemalto tokens which generate one-time codes - details available here:
http://aws.amazon.com/mfa/
Of course, what you don't want to end up with is a scenario where you have to carry multiple devices (phones, tokens etc) capable of generating security tokens for each cloud service you deploy. One way around this would be to consider the use of SAML and a single authentication provider for all of your cloud services. Take a look at the CRYPTOCard Managed Authentication Service - you may like what you see!
https://www.cryptocard.com/mas/index.php?option=com_content&view=article&id=39&Itemid=2
And as none of my blog posts seem to be complete without a link out to more of my ramblings, you may be interested in what a number of luminaries (and me) have to say about value added cloud services over at:
http://www.computerweekly.com/Articles/2010/09/06/242626/Security-think-tank-Value-added-cloud-security-services.htm
Thursday, 29 July 2010
Bits n Pieces
First things first. If you're interested in cloud security, you may want to download the whitepaper now available from Capgemini over at:
http://www.capgemini.com/insights-and-resources/by-publication/putting-cloud-security-in-perspective/
Now I'll admit to writing that piece and so this is really just a blatant plug. Happy to take comments on the paper though.
Other things... still frustrated by a variety of different attitudes to security, maybe I should try and catalogue them....
Best Intentioned (but ill-informed)
Those who do what they do with the best of intentions, e.g. "well we did that to improve the security", but have no real expertise in the subject area and were too busy to ask anyone else and so end up going down a sub-optimal path.
Rationale Reverse Engineers
"Well, it's too late now and we can't possibly implement that solution. It wasn't really that important anyway was it? Not if you think about it like this..." Nuff said.
The Optimist
"Well, who'd do a thing like that? Nobody's interested in attacking us" Eeek. The Optimist has always been around and I daresay will always be around. I always feel guilty pointing out the realities and tarnishing such naive innocence.
The Robot
Blind obedience to policy or procedure. Even if that policy or procedure is not directly relevant to the problem at hand.
The Pessimist
"Well, if this were to be happen we'd be dead in the water. So we can't do anything." All risk is bad. Possibly even more dangerous from a business perspective than the optimist. If you tend to believe in Darwinism and any applicability to the business environment then it's the organisations that are most able to change that thrive. Change and Pessimists do not mix well.
The Perfectionist
You're only secure if there is no way in. Lock down everything. Ensure that every line of code in your organisation is perfect. Often find work as penetration testers.
The Policy Monkey
A bizarre breed who produce policies with blatant disregard for the organisation concerned, the applicability, technical relevance or feasibility of their output. Often expensive but very good at producing materials for balancing wonky tables.
Have to point out that the categories in the above list are not directly correlated to individuals in my current day job and are generic charicatures. Just in case anyone's reading. :-)
http://www.capgemini.com/insights-and-resources/by-publication/putting-cloud-security-in-perspective/
Now I'll admit to writing that piece and so this is really just a blatant plug. Happy to take comments on the paper though.
Other things... still frustrated by a variety of different attitudes to security, maybe I should try and catalogue them....
Best Intentioned (but ill-informed)
Those who do what they do with the best of intentions, e.g. "well we did that to improve the security", but have no real expertise in the subject area and were too busy to ask anyone else and so end up going down a sub-optimal path.
Rationale Reverse Engineers
"Well, it's too late now and we can't possibly implement that solution. It wasn't really that important anyway was it? Not if you think about it like this..." Nuff said.
The Optimist
"Well, who'd do a thing like that? Nobody's interested in attacking us" Eeek. The Optimist has always been around and I daresay will always be around. I always feel guilty pointing out the realities and tarnishing such naive innocence.
The Robot
Blind obedience to policy or procedure. Even if that policy or procedure is not directly relevant to the problem at hand.
The Pessimist
"Well, if this were to be happen we'd be dead in the water. So we can't do anything." All risk is bad. Possibly even more dangerous from a business perspective than the optimist. If you tend to believe in Darwinism and any applicability to the business environment then it's the organisations that are most able to change that thrive. Change and Pessimists do not mix well.
The Perfectionist
You're only secure if there is no way in. Lock down everything. Ensure that every line of code in your organisation is perfect. Often find work as penetration testers.
The Policy Monkey
A bizarre breed who produce policies with blatant disregard for the organisation concerned, the applicability, technical relevance or feasibility of their output. Often expensive but very good at producing materials for balancing wonky tables.
Have to point out that the categories in the above list are not directly correlated to individuals in my current day job and are generic charicatures. Just in case anyone's reading. :-)
Wednesday, 12 May 2010
Innovation
After a hectic couple of months I've finally found a little time to put up a new post...
One of the tasks I've had to complete recently was that of acting as a judge in a competition to find innovative solutions to a certain security problem. This has caused me to consider the entire concept of innovation and it's relationship with security; primarily because a couple of the entries I had to judge presented me with something of a conundrum. The conundrum being: were these entries truly innovative or nothing more than snake oil? Was my lack of confidence in these proposals due to poor presentation, poor content or my own inability to understand something truly innovative? How do we distinguish between true innovation and snake oil? If something is truly innovative, what realistic metrics do we have at hand to justify any kind of value judgement? And, if something is truly innovative, that means that it's also going to be new and unproven and therefore scary to security types. Like me.
So, what do we do about innovation and security? We can't ignore it. We always have new problems, or battlegrounds (e.g. the cloud which tends to be a new battleground for old fights), that are crying out for new solutions. What I don't think we have are particularly pragmatic ways of adopting new solutions with any degree of confidence - existing assurance schemes (think Common Criteria) are just not appropriate for adaptable solutions to fast-moving problems. Anyone out there got anything useful around managing innovation in a security context?
One of the tasks I've had to complete recently was that of acting as a judge in a competition to find innovative solutions to a certain security problem. This has caused me to consider the entire concept of innovation and it's relationship with security; primarily because a couple of the entries I had to judge presented me with something of a conundrum. The conundrum being: were these entries truly innovative or nothing more than snake oil? Was my lack of confidence in these proposals due to poor presentation, poor content or my own inability to understand something truly innovative? How do we distinguish between true innovation and snake oil? If something is truly innovative, what realistic metrics do we have at hand to justify any kind of value judgement? And, if something is truly innovative, that means that it's also going to be new and unproven and therefore scary to security types. Like me.
So, what do we do about innovation and security? We can't ignore it. We always have new problems, or battlegrounds (e.g. the cloud which tends to be a new battleground for old fights), that are crying out for new solutions. What I don't think we have are particularly pragmatic ways of adopting new solutions with any degree of confidence - existing assurance schemes (think Common Criteria) are just not appropriate for adaptable solutions to fast-moving problems. Anyone out there got anything useful around managing innovation in a security context?
Thursday, 18 March 2010
Musings on security architecture
Time for something a little more intellectual than usual. Here's a list of Do's and Don'ts when it comes to Security Architecture. Purely personal opinion. Feel free to argue. Feel free to agree. Feel free to ignore.
Do collect all of your security requirements from your business stakeholders, your regulatory environment, your wider enterprise and industry standards
Don't present me with an endless list of requirements saying the same thing but in slightly different ways. Consolidate your requirements set but maintain traceability by stating where your consolidated requirements originated
Do obtain sign-off from the relevant business stakeholders that the requirements are correct
Don't tell me that the Head of Security has approved the requirements and so we're good to go...
Do perform a comprehensive risk assessment of the system/service in question
Don't come back with a set of risks so abstract as to be useless - "An attacker may gain unauthorised access to my data" - well yes, but what's the business impact? What's the data? Who is the attacker? And are you talking physical or logical access? And are there any relevant attack vectors available to the threat actors you're worried about?
Do obtain business sign-off that the risk assessment is valid and caters for the risks that they care about
Don't tell me that the Head of Security has approved the risk assessment and so we're good to go...
Do define a set of security services based on your requirements and your risk assessment
Don't give me any services that cannot be traced back to a requirement or a risk. We're not doing this for the sake of it... It may be 'best practice' but do you need 'best practice' or is what you have good enough?
Do consider how your security services interact and how they are used by the relevant actors
Don't get bogged down with fully elaborating a security architecture - mental masturbation may be fun, but it's not productive. Do what you need to do to validate that your architecture is appropriate and is as complete as it needs to be.
Do consider any wider enterprise architectures that you are operating within. Your work may just be a view on a wider architecture
Don't simply assume re-use of existing services defined in a wider architecture without validating that they meet your requirements and are available for your use
Do tell other people about your work - an architecture is worthless unless it's used to influence design, build and run. Don't lock yourself away in an ivory tower and then complain that you're being ignored.
Don't exaggerate the importance of your work - architecture is a tool, sometimes a piece of art as well, but most importantly a tool.
Do remember that you're working in the real world. Whatever you're working on most likely has to be deliverable and affordable.
Don't be precious. This is just a general comment :-).
Well, that's my quick brain dump of do's and don'ts typed up as I sit here on a train heading home. I've probably missed lots of really important stuff - I may even have got some stuff wrong. In your opinion. Let me know.
Do collect all of your security requirements from your business stakeholders, your regulatory environment, your wider enterprise and industry standards
Don't present me with an endless list of requirements saying the same thing but in slightly different ways. Consolidate your requirements set but maintain traceability by stating where your consolidated requirements originated
Do obtain sign-off from the relevant business stakeholders that the requirements are correct
Don't tell me that the Head of Security has approved the requirements and so we're good to go...
Do perform a comprehensive risk assessment of the system/service in question
Don't come back with a set of risks so abstract as to be useless - "An attacker may gain unauthorised access to my data" - well yes, but what's the business impact? What's the data? Who is the attacker? And are you talking physical or logical access? And are there any relevant attack vectors available to the threat actors you're worried about?
Do obtain business sign-off that the risk assessment is valid and caters for the risks that they care about
Don't tell me that the Head of Security has approved the risk assessment and so we're good to go...
Do define a set of security services based on your requirements and your risk assessment
Don't give me any services that cannot be traced back to a requirement or a risk. We're not doing this for the sake of it... It may be 'best practice' but do you need 'best practice' or is what you have good enough?
Do consider how your security services interact and how they are used by the relevant actors
Don't get bogged down with fully elaborating a security architecture - mental masturbation may be fun, but it's not productive. Do what you need to do to validate that your architecture is appropriate and is as complete as it needs to be.
Do consider any wider enterprise architectures that you are operating within. Your work may just be a view on a wider architecture
Don't simply assume re-use of existing services defined in a wider architecture without validating that they meet your requirements and are available for your use
Do tell other people about your work - an architecture is worthless unless it's used to influence design, build and run. Don't lock yourself away in an ivory tower and then complain that you're being ignored.
Don't exaggerate the importance of your work - architecture is a tool, sometimes a piece of art as well, but most importantly a tool.
Do remember that you're working in the real world. Whatever you're working on most likely has to be deliverable and affordable.
Don't be precious. This is just a general comment :-).
Well, that's my quick brain dump of do's and don'ts typed up as I sit here on a train heading home. I've probably missed lots of really important stuff - I may even have got some stuff wrong. In your opinion. Let me know.
Friday, 12 March 2010
Web-cast musings
Was it great? No.
Was it utterly cringe inducing? No.
Better than expected? Probably.
What am I wittering on about? I did my second BrightTALK web-cast yesterday which was all about trying to show how cloud security need not sit (and indeed should not) apart from wider enterprise security frameworks. Given the topic I was expecting half of my audience to 'get it' and the other half to absolutely hate it; as it turned out the feedback was mostly positive albeit there was one member of the audience who only gave the presentation 1 star out of 5. But as I say, I was probably expecting more mixed ratings than I received and a number of 5 star ratings means it's currently standing at a 4.2/5 rating - which I'd certainly have taken before the gig! Main lesson for me is to try and not fit a 60 minute presentation into 40 minutes as I was aware that I was rushing through the content...
The really nice thing about BrightTALK is the ability to ask the audience to vote on questions of your choice. One of my questions gave a really interesting outcome - the question was around which service model the audience viewed as the most complex to secure. Both IaaS and SaaS scored 44% with PaaS only scoring 12%. I found this particularly interesting being as I was about to go on and say how I felt that PaaS was actually the most complex model to secure! Perhaps I should have run the vote again after the webcast... Now, I believe the low score for PaaS is probably because it's the model that's the least well understood - it's not as straightforward to understand as either IaaS or SaaS - rather than my audience believing it to be intrinsically more secure. But I could be wrong. Any comments out there? Do we need to expand more on what PaaS actually is?
Was it utterly cringe inducing? No.
Better than expected? Probably.
What am I wittering on about? I did my second BrightTALK web-cast yesterday which was all about trying to show how cloud security need not sit (and indeed should not) apart from wider enterprise security frameworks. Given the topic I was expecting half of my audience to 'get it' and the other half to absolutely hate it; as it turned out the feedback was mostly positive albeit there was one member of the audience who only gave the presentation 1 star out of 5. But as I say, I was probably expecting more mixed ratings than I received and a number of 5 star ratings means it's currently standing at a 4.2/5 rating - which I'd certainly have taken before the gig! Main lesson for me is to try and not fit a 60 minute presentation into 40 minutes as I was aware that I was rushing through the content...
The really nice thing about BrightTALK is the ability to ask the audience to vote on questions of your choice. One of my questions gave a really interesting outcome - the question was around which service model the audience viewed as the most complex to secure. Both IaaS and SaaS scored 44% with PaaS only scoring 12%. I found this particularly interesting being as I was about to go on and say how I felt that PaaS was actually the most complex model to secure! Perhaps I should have run the vote again after the webcast... Now, I believe the low score for PaaS is probably because it's the model that's the least well understood - it's not as straightforward to understand as either IaaS or SaaS - rather than my audience believing it to be intrinsically more secure. But I could be wrong. Any comments out there? Do we need to expand more on what PaaS actually is?
Monday, 8 February 2010
Cloud and Enterprise Security Architecture
So, I let myself get volunteered to do another web-cast for BrightTALK.
I'm giving the first presentation at their 3rd Cloud Security Summit on the 11th of May. My last web-cast was a fairly generic overview of the security risks associated with cloud computing. My next presentation is a bit more ambitious... I'm aiming to try and bring cloud computing security within the context of wider enterprise architecture. It's either going to be great or one of the more cringe-inducing web-casts on the Interweb :-)
I would like to take a little time to explain the philosophy behind this upcoming presentation. I’ve been thinking for a while now that those of us working in the cloud space need to work harder to bring the technologies into the mainstream – whilst the hype around cloud computing was really useful in bringing it to the forefront, I fear it is now counterproductive to mainstream adoption. By treating cloud as somehow different, or apart from traditional IT delivery, all we are doing is making it appear scarier than it need be to potential consumers. After all, it
is human nature to be wary of things that are different or unknown. What I aim to do is to show that we can bring cloud computing into the wider architecture context of an enterprise – yes cloud brings some unique opportunities and unique challenges, just not necessarily more so than other means of IT delivery. In-house, traditional out-sourcing, cloud – all have their own quirks and are all unique in their own special ways…
So please, tune in to http://www.brighttalk.com/webcasts/8490/attend on the 11th and see whether I manage to pull it off or fall flat on my face!
I'm giving the first presentation at their 3rd Cloud Security Summit on the 11th of May. My last web-cast was a fairly generic overview of the security risks associated with cloud computing. My next presentation is a bit more ambitious... I'm aiming to try and bring cloud computing security within the context of wider enterprise architecture. It's either going to be great or one of the more cringe-inducing web-casts on the Interweb :-)
I would like to take a little time to explain the philosophy behind this upcoming presentation. I’ve been thinking for a while now that those of us working in the cloud space need to work harder to bring the technologies into the mainstream – whilst the hype around cloud computing was really useful in bringing it to the forefront, I fear it is now counterproductive to mainstream adoption. By treating cloud as somehow different, or apart from traditional IT delivery, all we are doing is making it appear scarier than it need be to potential consumers. After all, it
is human nature to be wary of things that are different or unknown. What I aim to do is to show that we can bring cloud computing into the wider architecture context of an enterprise – yes cloud brings some unique opportunities and unique challenges, just not necessarily more so than other means of IT delivery. In-house, traditional out-sourcing, cloud – all have their own quirks and are all unique in their own special ways…
So please, tune in to http://www.brighttalk.com/webcasts/8490/attend on the 11th and see whether I manage to pull it off or fall flat on my face!
Friday, 22 January 2010
It really is true!
After years of saying that security is a genuine enabler to business and not just a blocker (or speedbump) on the way, I was fortunate enough to get some proof of my statements recently.
I'm currently working on an information sharing solution between various disparate organisations - most of these organisations have now agreed to share more, particularly sensitive, information (of immense business value) based on their confidence in the security model. Result!
Only a short post today but I thought I ought to have something a bit more positive up here than my last post - especially if it's going to be a while til the next one :-)
I'm currently working on an information sharing solution between various disparate organisations - most of these organisations have now agreed to share more, particularly sensitive, information (of immense business value) based on their confidence in the security model. Result!
Only a short post today but I thought I ought to have something a bit more positive up here than my last post - especially if it's going to be a while til the next one :-)
Thursday, 7 January 2010
Is it just me?
As much as I would have liked to start 2010 with a nice positive post, I'm going to have to start with a bit of a whinge. What is it about the subject of security that means that everybody working in IT believes that they know how to do it? I rarely see non-DBAs telling their DBAs how their databases should be partitioned but I'll regularly see non-security types discussing security with great authority but little in the way of informed opinion!
So, I'm happy to accept the charge that part of the brief of the security professional is to educate the masses - but I do find it incredibly frustrating that the masses seem pre-programmed with the belief that they already understand security and risk management...
Is it just me?
So, I'm happy to accept the charge that part of the brief of the security professional is to educate the masses - but I do find it incredibly frustrating that the masses seem pre-programmed with the belief that they already understand security and risk management...
Is it just me?
Subscribe to:
Posts (Atom)
