Wow. Where did Q1 go? Not on blogging obviously :-)
Well, after four years on one assignment I finally get to try something new from the end of next week. It's been a primarily fun and worthwhile four years and I've met some good people in that time (just in case any of my current colleagues are reading!) but it's been tough and I'm looking forward to a new challenge. I'm also looking forward to an assignment that will give me a bit more time to concentrate on this blog and posting a little more regularly than once a quarter.
So, what prompted me to come out of blogging hibernation? High profile hacks! By which I'm thinking HBGary Federal, RSA and Comodo. I can't remember a time when three such hacks happened in such a short space of time and received this amount of publicity. Which is the most interesting? Hard to say. HBGary Federal was interesting because of the contents of the email spool that Anonymous released and the somewhat embarrassing implications for the likes of Bank of America and Morgan Stanley.
Is RSA interesting? Hard to tell as they've been very quiet about what was actually accessed during their compromise and so their customers are in limbo. So, it's interesting in so far as a high profile security firm got 0wned; likely to be more interesting once it becomes apparent what was purloined by the attackers. C'mon RSA, help us all out here!
But the Comodo hack; now that is certainly interesting. See http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html for details. Almost certainly laying the foundations of a larger hack and demonstrating why the core security measure for most Internet users (SSL) should not be relied upon as strongly as it currently is - it certainly shows that certificate authentication is worthless without strong registration processes and capable registration authorities. To be fair however, and in direct contrast to RSA, Comodo have at least been forthright in explaining the implications of the hack and the certificates issued.
Anyone can get hacked, including those we trust to secure the Internet, so here's hoping that more organisations follow the Comodo approach to notification than the RSA approach.
See you in Q3 :-)
Friday, 25 March 2011
Friday, 21 January 2011
ENISA's latest paper on cloud
I don't usually like to criticise the efforts of others to provide useful (or at least informative) guidance however the latest paper from ENISA on Security and Resilience in Governmental Clouds has provoked me into something of a reaction. And that reaction is meh.
To expand further...
If you're not familiar with cloud computing, it's probably a good document to pick up and have a read through in order to get an idea of what the whole cloud thing is about. But there's nothing startlingly new or original in here - the decision framework is new but I wouldn't say startling. I think some of the flows are troublesome as well as it happens. I'm really not confident that the order of risk assessment, choose deployment model (or "IT Architecture" in ENISA parlance) and then identifying threats is particularly applicable in the real world. I'd have preferred something more along the lines of identify business requirements, identify threats, identify potential solutions, narrow down choice based on trade-off between risk and business benefits, prepare RfP etc... I guess I'm a little uncomfortable with attempting to put security as a blocker right at the start of the process; perhaps I'm just a bit too heretical to work in security these days.
My other problem with the paper is that it suffers from the usual naivety in terms of clumping together all IaaS, PaaS and SaaS providers into the 3 buckets and assuming that you have the same risks regardless of service provider. They fall into the same trap as most of the material in this space by practically treating IaaS, PaaS and SaaS as specifications rather than broad categories. As an example of the problem - if you look at the PaaS offerings of Microsoft Azure, Force.com, Heroku, Google's AppEngine and Terracotta and tell me that you can apply the same risk profiles to platforms offering Ruby, Apex, Java, Python and .NET and administered in a variety of ways using differing authentication and authorisation mechanisms then I'm not playing with you anymore and I'm going to tell your mum. Don't even get me started on the diversity you'll find with SaaS - how can you apply the same risk profiles to services that range from accounting through to collaboration through to authentication or whatever?
But as I say, if you're not familiar with the subject and want to get a grounding then it's not a bad document. But if you are familiar with this space, I'd say read it so that you're not left out in cloud conversation* but overall... meh.
* yes, there is such a beast as cloud conversation, unfortunately it does tend to go pretty much as summarised by Dilbert http://www.dilbert.com/strips/comic/2011-01-07/
To expand further...
If you're not familiar with cloud computing, it's probably a good document to pick up and have a read through in order to get an idea of what the whole cloud thing is about. But there's nothing startlingly new or original in here - the decision framework is new but I wouldn't say startling. I think some of the flows are troublesome as well as it happens. I'm really not confident that the order of risk assessment, choose deployment model (or "IT Architecture" in ENISA parlance) and then identifying threats is particularly applicable in the real world. I'd have preferred something more along the lines of identify business requirements, identify threats, identify potential solutions, narrow down choice based on trade-off between risk and business benefits, prepare RfP etc... I guess I'm a little uncomfortable with attempting to put security as a blocker right at the start of the process; perhaps I'm just a bit too heretical to work in security these days.
My other problem with the paper is that it suffers from the usual naivety in terms of clumping together all IaaS, PaaS and SaaS providers into the 3 buckets and assuming that you have the same risks regardless of service provider. They fall into the same trap as most of the material in this space by practically treating IaaS, PaaS and SaaS as specifications rather than broad categories. As an example of the problem - if you look at the PaaS offerings of Microsoft Azure, Force.com, Heroku, Google's AppEngine and Terracotta and tell me that you can apply the same risk profiles to platforms offering Ruby, Apex, Java, Python and .NET and administered in a variety of ways using differing authentication and authorisation mechanisms then I'm not playing with you anymore and I'm going to tell your mum. Don't even get me started on the diversity you'll find with SaaS - how can you apply the same risk profiles to services that range from accounting through to collaboration through to authentication or whatever?
But as I say, if you're not familiar with the subject and want to get a grounding then it's not a bad document. But if you are familiar with this space, I'd say read it so that you're not left out in cloud conversation* but overall... meh.
* yes, there is such a beast as cloud conversation, unfortunately it does tend to go pretty much as summarised by Dilbert http://www.dilbert.com/strips/comic/2011-01-07/
Monday, 29 November 2010
Security architecture. And cloud computing.
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.
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.
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?
Subscribe to:
Posts (Atom)
