Musings of a geeky mind
Random thoughts and ideas…
WikiLeaks DDoS: Don’t jump to conclusions
Nov 28th
So, the WikiLeaks Twitter account is claiming that their website is suffering “a mass distributed denial of service attack”. Given the sensitivity of the documents they are apparently planning to release, many will believe that this is action by the US Government to prevent the documents’ release.
While that might not be an invalid assumption, several facts need to be considered:
- The only people claiming that their website is under attack is WikiLeaks themselves — there has not (as of the time of writing, 5pm GMT on Sunday) been any independent verification of this from other parties such as network or hosting providers. Remember, /etc/init.d/apache stop is the ultimate way to deny service to your website…
- There may have been a legal takedown. WikiLeaks have been shuffling IP hosting quite a bit recently. If the jurisdiction your infrastructure is in believes there is a legal reason for you not to be able to serve your content, then all bets are off. Undue censorship? Possibly — but that’s not a discussion for this blog.
- There might actually be a DDoS, but not initiated by who you believe it would be. It would certain serve certain constituencies of people Very Nicely, Thank You for USGov to be “framed” for this; and note that this would indeed include WikiLeaks themselves. Given the recent comprehensive analysis of the Stuxnet malware by Symantec (you should also read the full report. which is an incredibly well-prepared piece of work) — we may well be into the days of state-sponsored cyber-warfare, although this is currently very much at the “targetted” end of the spectrum, rather than indiscriminate.
One of the things that Ed Skoudis taught me about monitoring systems and security on my SANS Incident Handling course several years ago, and which I’ve never forgotten, is: “Never assume that everything is ok!” I would venture to add to that: “Never assume that the most obvious cause is the actual cause.”
Evidence, evidence, evidence! Make sure you can prove your theories before betting the ranch (or your job!) on them!
In all likelihood, we will never actually know what has gone on with WikiLeaks today — mainly because it serves WikiLeaks not to tell anyone. But, this is definitely a case, as I watch Twitter jumping to conclusions as it is wont to do, where, I suspect, the most obvious cause is not in fact what is going on here.
Step away from the bleeding edge
Aug 24th
Us developers, code monkeys, or call us whatever you will, get a really bad press on occasion. Managers, who don’t understand what we do or why we do it; customers, who think we never do what we’re asked to do; the media, when some of us slip up in slightly more unfortunate and public ways. It’s not always a fun job.
We often try to temper this by consoling ourselves with having fun with the latest technologies, languages and modules, and delivering “cool” solutions which do what needs to be done in the best and shiniest way. A fair dose of this you can get away with — and particularly more so in academia than in business. In my last job — in academia – we were quite some way ahead of the commercial curve with a few of the things we were trying to do and the methods we chose to achieve them. In my current job — working in the financial industry — we’re still ahead of the commercial (well, common-off-the-shelf) curve, but there’s understandably more importance on writing code which is supportable, rather than just plain cool.
Pragmatically, this means that sometimes, even though there might well be a best tool for the job which has come onto the scene relatively recently, it’s not always the right tool for the job.
I’m going to choose an example I’m very familiar with: Perl. Yes, I can already see some of you recoiling in horror. I code Perl for a living. I write thousands of lines of Perl with a song in my heart and a $_ on my fingertips.
One thing Perl does really, really badly is object-oriented programming. If you thought C++ was bad from an OO perspective, Perl will send you running, screaming, for the hills. Recently, various folks have tried to do something about this, and come up with Moose, which is an object-oriented framework which implements “real objects” in Perl. Moose is very, very cool technology. It also does its job very well. If you are writing code which is OO-based in Perl, I think there’s very little question that Moose — or one of its derivatives: Mouse, or Badger — is the best tool for the job.
Leaving aside the question of whether an OO-based design is the appropriate pattern for the job at hand though, at the moment, I don’t think Moose and friends are the right tool for the job. Not just yet, anyway.
Why? The primary reason is maintainability — effected through the simple and good old numbers game. Ok, there is definitely a reasonable community of Moose programmers out there. However, within my company, there are very few Moose programmers. If I’m writing code that I expect to live a long time, there are two key criteria — which sound like they should be mutually exclusive, but most certainly aren’t.
- Your code should be robust, defensive and error-free.
- Your code should be maintainable by someone else of similar knowledge to you in the language in which it is programmed, to allow them to fix it when it blows up and you’re no longer there to tend it.
Now — several years down the line, there are two probable cases. Either: Moose has taken off (or even been absorbed into the Perl core), pretty much any serious Perl coder does Moose, and everything is hunky-dory. Or: Moose is a flop, everyone’s forgotten it… your code crashes at a business critical moment, the unlucky maintenance programmer comes along, reads the first few lines of your application and knows they are going to be having a very long night unravelling your code.
Rule 1 is important in the short to medium term — you want as little trouble caused by your own code as possible, and so robustness and defensive programming wins you that. Rule 2 is the medium to long term game though — mainly because something will change. It might be the platform the code is running on, solar flares or whatever; but your code must be maintainable. Comments, literate programming, inline documentation all help lots — but if the code is written in what turns out to be the bitwise equivalent of Attic Greek, then you still have a bigger problem on your hands.
In short, my message is that we must not be afraid to step away from the bleeding edge at times. Even when the bleeding edge might well hold the best available tools for the job, do you really want to put all your money on that particular foal having a long and fruitful career, or would you rather go for the proven thoroughbred?
The information security brick wall
Jul 27th
The UK Government launched the Cyber Security Challenge yesterday, which offers various prizes including SANS training, places at the Detica Academy, Masters-level university scholarships and more. Their opening gambit is a rather fun cipher challenge which should exercise your braincells for a few hours!
The dearth of information security professionals is becoming an acute issue. Part of the problem is that IT has become so approachable and so powerful — the amount of knowledge required to “get stuff done” has reduced dramatically.
When I was at university 10 years ago, studying computer science, the top third or so of the class were serious Linux/Unix command line junkies. They knew the power of a shell pipeline, their xargs from their elbow, and their TCP three-way handshake from their ICMP Network Unreachable. We produced some serious coders and network gurus, and a large proportion of that particular cohort went on to work for Google, IBM, Symbian and the serious tech companies — because they had the in-depth knowledge of how the belly of the beast worked and weren’t afraid to dive in.
Nowadays, the same university churns out very able students, who are able to program. That’s about it… primarily because now, to get stuff done in Unix, you just have to do the pointy-clicky thing in KDE, Gnome, or whatever cute and friendly desktop environment you want to use today. The understanding of what goes on “under the hood” isn’t achieved, because it’s no longer necessary to get the job done — welcome to the double-edged sword of UX improvements. One of my colleagues, working at the university as a research associate and sometime lab assistant, bemoaned the fact that several students did not even know how to produce the ‘|’ symbol, let alone how it could be used in a Unix shell!
As electronic devices reach the stage of pervasive technology — everywhere, all the time — the risk factor of exploitation increases exponentially. You’d think that we as an industry would have learned our lesson with the legacy our forebears are already leaving us — rapidly obsolescent embedded, SCADA and safety-critical platforms which are having to be retrofitted with security now that everything is online. Sadly, this doesn’t seem to be the case.
In five years or so, information security is going to hit a fairly large and solid brick wall, simply because there are fewer and fewer new people entering the sector… because the universities aren’t producing them. With very few exceptions (I think particularly of Royal Holloway’s various courses on the subject here), academics in computer science departments don’t get practical information security. The importance of being able to code securely (i.e. don’t write commonly exploitable code), detect intrusions, deal with them, and handle the aftermath, is something that universities don’t touch.
It is incumbent on the universities today to not only teach coding, but to teach secure coding practices and nurture the next generation of information security experts. Whether they are willing — or able — to fulfill that task is another question.
The UK Cyber Security Challenge and its various worldwide counterparts are laudable, and play an important role in increasing the public awareness of the importance of information security. However, they are not going to bring nearly enough people into the infosec sector to fill the needs of the coming years.
For now, all we can do is watch and wait — and fix the vulnerabilities when they come along, and hope we don’t make too many mistakes.
Welcome!
Jul 26th
This blog will be the home of my (probably infrequent!) musings and thoughts. The range of topics will be fairly broad.
The shortest available description of who I am is: London-based geek, primarily of IT but also of music, winterguard, and slowly filtering into the world of games — three-space, not necessarily computer-based.