Sunday, 7 April 2013

300Gbps DDoS Attack

I was in Cyprus recently and noticed on several occasions that Internet performance was a bit flakey. It was often very fast, but every 15 minutes or so would grind to a halt for a couple of minutes. I was about to complain to the hotel when I noticed a report on the BBC website about a large DDoS attack. It seems that the attacker was mainly trying to take down DNS, but I think I was affected by the collateral damage:

Now corporations are using the Internet much more for business critical applications, I do wonder just how robust the Internet actually is and how long before there's a really serious Internet outage that makes them rethink their Cloud strategies.

Saturday, 30 March 2013

Certificate in Cloud Security Knowledge (CCSK)

I took and passed the Cloud Security Alliance Certificate in Cloud Security Knowledge (CCSK) version 3 a couple of weeks ago.

My company were keen for us to do it. In general it was quite interesting and made me think about a few aspects of Cloud security I hadn't considered previously. I've always been quite nervous about how Cloud could meet compliance in areas such as Payment Card Industry (PCI) and Health Insurance and Portability Accountability Act (HIPAA) in the Cloud. However, the literature did make some very good points about how the economies of scale gained from Cloud make it easier to meet these compliance and regulatory requirements, definitely changing my thoughts on the subject.

If you're interested in CCSK, take a look at the following site where you can download the literature and also take the test online:

There's a few blogs on passing CCSK, I found Jean-Francois Audenard's '7 tips for getting CCSK certified' useful:

My main criticism of the CCSK is why the exam has to be taken online, as it's impossible to take a certification seriously if it hasn't been tested in proper exam conditions. $345 USD is a lot of money for an online test.

Saturday, 2 February 2013

Technical Debt

I came across this post on the BBC website, discussing 'Technical Debt'.

The term, coined by programmer Ward Cunningham, defines Technical Debt broadly as "During the planning or execution of a software project, decisions are made to defer necessary work." Basically, over time and under pressure to employ new features, the debt grows and it becomes more difficult to see where faults lie or to remediate issues, increasing the risk to systems.

I think this is something that applies much more generally within IT. It's something I realised I'd known for a while, but I now have a term to use for it.

As we do more and more with less and less people, we inevitably cut corners. This could mean not taking the time to tidy up a configuration after a change or removing it when it's defunct. Or not spending as long as we should creating documentation, ignoring the possible impact on the people who may need to pick up the pieces in the middle of the night after we're long gone from the organisation.

Unfortunately the effects of Technical Debt are often not immediately noticeable, but often come back to haunt us, our precedessors and our organisations at a later date.