In the words of Noddy Holder of Slade fame: “It’s Chriiiiiiist-maaaaaaaaaaas!””. Well, not quite, but it will be soon. And you know what that means: plenty of food, drink, partying, more food, more drink, more partying, presents galore (hopefully) and panto – okay, I am a fan of panto and my secret is out.
Hornbill celebrated Christmas early, receiving one of the best presents it could have hoped for this year: achieving ISO 27001 certification for its cloud operation. “Oh no you didn’t”, I hear you cry – “that’s not possible in such a short timeframe”. Oh yes we did, and we’re very proud of the achievement. In just 9 months, under the guidance of an external consultant and the watchful eye of our Information Security Manager (ISM), the cloud team successfully put in place a number of processes, covering areas such as business continuity, physical security, destruction of old equipment, encryption of data, classification of information, that met the requirements of the ISO 27001 standard. That’s some achievement.
These processes were independently reviewed by an external auditor from the British Standards Institution. That in itself was a daunting experience, particularly for our ISM who sat in a room for two days with the auditor explaining the implementation of the Information Security Management System in place and demonstrating that it was being followed to the letter. In addition, selected members of staff were interviewed and the security perimeters assessed. It was a very thorough examination of our operation.
During the run up to ISO 27001 certification, the ISM was both friend and foe: he helped us put in the processes and kicked our butts – no need to check the ISO 27001 glossary for a definition of what that means! – when we inadvertently failed to apply the processes. Seriously, though, it’s a tough role: he had to follow the Standard whilst being pragmatic and above all do whatever was necessary to protect customers’ data. Not a popular chap at times, ruffling a few feathers as he went about his work.
So now that we have achieved ISO 27001, you’re probably thinking “It’s behind you”. Oh no it’s not! – far from it. We will continue to improve our Information Security Management System (continuous improvement is a key part of ISO 27001) and in due course roll out ISO 27001 to other parts of Hornbill. The first Continuing Assessment Visit has been scheduled for the summer.
Right, I must go and wrap presents as well as work on my next blog post entitled Social Engineering on Tap. Happy Holidays!
Paddy’s back after a period of incarceration due to over-exuberant ethical hacking. I thought I’d mark my return with a blog post on security musings. I browsed to trust.hornbill.net and to my delight found that while I had been offline, the guys at Hornbill have installed a certificate on the trust web server.
This is not any old certificate – you can buy certificates very easily and cheaply online with little or no checking – but the one on trust.hornbill.net displays a pretty little green bar in the browser.
You’re probably thinking “nice, but so what?”. You may even be saying “I see one of those every time I visit my bank’s website”. Some of you may not have noticed this at all – outrageous!!
The type of certificate we have is called an Extended Validation (EV) SSL Certificate. The process of purchasing such a certificate is rather involved – you can read about it here http://www.geotrust.com/support/true-businessid/ev-validation-requirements/ – and quite rightly so, as it demonstrates a level of trust and security that you cannot achieve with ordinary SSL certificates. For us, it was worth the wait: we’re not a bank of course, but security is still paramount to us in everything we do. We wanted to demonstrate this to you, which is why we decided to go the extra mile and go EV.
So the next time you are browsing the web, do look out for SSL certificates. And should you look at other cloud-vendor sites, see whether they have an EV certificate. Bet they haven’t!
How many times have you set up an account on line and had to think of a password? Your bank needs one, your email needs one, your Facebook account needs one. Passwords are everywhere: your bicycle D-Lock (no relation) requires a four-digit password. How many of you reuse the same password across different services to avoid having to remember too many passwords? Of course you never write these down, SMS them to yourself, email them to yourself, write them down on a scrap piece of paper, or share them with a parrot, do you? I’ll blog about password storage another time, just think on in the meantime about how vulnerable your passwords are.
For now, though, I want to focus on how secure your password is by looking at password strength. Password strength is an indication of how easy your password is to hack. You’re probably thinking it’ll never happen to you. Can you be that sure? Really? There are people out there just waiting to get their hands on you account details, to steal your money, to send loads of spam email originating from your actual account, to post embarrassing status updates and pictures on your Facebook account, to lock you out of your account. By way of confirmation of how easy it is to hack a password, have a look at the site http://howsecureismypassword.net/ (I wouldn’t recommend typing your actual password in, just in case) The site also tells you many people choose particular words as passwords. Yes, I was surprised that particular word was among the 300 most common ones chosen as a password!
Back to the serious matter of securing your password, it is important that you choose a password that is strong. Some companies have a password policy — a topic of a future blog post — that forces you to choose a strong password. If your company does not have a policy, or the policy is not adequate, then you can strengthen your password by:
- avoiding the use of words
- using a mixture of upper case and lower case letters
- using special characters and numbers
- ensuring the length is at least 8 characters
We have come full circle, in that the more complicated your password is, the harder it will be to remember. Paddy can’t solve all your problems in one post 😉
The takeaway message from this blog is: don’t make it easy for the hackers — choose a strong password….Please!!
Today I felt like a real celebrity: I tried to set up a twitter account and found that my identity had been stolen. There is another Paddy Lock? Surely not. Who is this @PaddyLock?? It’s not me. I did a bit of digging and found that this is the Face of The Total Security Summit at Forum Events Ltd. How dare they?! I have a face, two arms, two legs and am anatomically complete! I am a real person, so in true “celebrity” style have set up @RealPaddyLock. Do follow me.
Beware of imitations!!
P.S. http://www.facebook.com/people/Paddy-Lock/701154141 isn’t me either
This week I was experimenting with locking down Apache to avoid a particular vulnerability that a hacker may want to have some fun with. With a bit of research, I found a very cool third-party firewall for Apache that can be used to close this vulnerability — I’ll blog about this firewall another time. We built the module from source, installed it and then applied the lock down…I couldn’t wait to try it out….I tried a very simple example of the vulnerability, the simplest I could think of. IT DIDN’T WORK!!! What did I do wrong? I checked, double-checked and triple-checked the configuration applied to prevent the vulnerability: there were no errors my side. With a bit more research, I found out that there was a problem: the latest release of the third-party component did not prevent the vulnerability, although previous releases did. The latest version had regressed 🙁
Oh well, these things happen. The third-party component is great and really useful, so I can live with reverting back to a previous release to achieve my goal. The whole episode did prompt me to write this blog post and provide some words of wisdom that others may benefit from:
- always conduct your own tests to make sure that a third-party component does what it says on the tin
- create a regression test suite to make sure that old problems are not re-introduced when you upgrade a component
- don’t assume that security experts will not make mistakes!!
The other day I was browsing the web looking for some specific information on php security. I came across a great site (which I cannot name for the reasons below), containing just the information I was looking for. I was about to leave the office for the day and wanted to download the PDF version of the document to my phone to read on the way home — yes, I know that’s sad! I clicked on the PDF link. You know what happened next? To my surprise, I saw the following:
Putting user friendliness to one side, the site revealed vital information about key components on the web server. It amused me that a website focussing on security would have a security vulnerability, and an easy one at that to resolve. A hacker coming across the site could look up the documented vulnerabilities in these components and launch an attack. I have tried emailing the website owners alerting them to my discovery, but all my emails are bouncing. I’m assuming that this is not an elaborate scam – I guess I’ll know soon if I have been fooled!
Back to Apache. If your server is reporting its version number, then you can resolve the problem very easily by adding the following to your httpd.conf file:
After you save the changes, restart your Apache server and wave goodbye to this vulnerability.
Hornbill’s cloud instances are secured and do not experience the vulnerability described above.
On Tuesday 13 March 2012 we received an advisory from Microsoft regarding a vulnerability in Remote Desktop Protocol (RDP), alerting us to a bug that allows a remote hacker to execute code on a system, without any intervention on the part of the user. As some of our servers our windows based, we pounced on this notification and took immediate steps to close the vulnerability. We confirmed the patch provided by Microsoft had no impact on our staging servers, so it was good to go. We scheduled our systems to deploy the patch that very same day, notifying our customers of our intent.
We patched all affected servers on three continents within 24 hours of being alerted to the vulnerability. Some providers, not mentioning any names, took a little longer to respond. I couldn’t believe it when I found out that a provider had scheduled their patch deployment for Saturday….5 days after the patch was made available by Microsoft.
I can’t speak for other providers, but here at Hornbill we take security very seriously and will respond as rapidly as possible to close vulnerabilities.
We’ll see if we can beat 24 hours next time!! 🙂
For more information on the specific vulnerability, see: