I heard this term for the first time the other day, and while I think there are several analogies from the Titanic that can be drawn upon for describing concepts in information security, perhaps few are as apt as this. It implies, of course, the futility of rushing around making minor adjustments in the face of impending disaster. Counteracting this requires you to have a broad picture of the security issues in your area of responsibility so you can focus on avoiding the iceberg toward which you are currrently heading at full steam. It means focussing on the highest risk issues first and letting the minutiae go for another day.  If you are a network operations guy this means doing away with unencrypted protocols for administration before changing the enable secret on the router, if you are a developer it means fixing the SQL Injection vulnerability on the login form of your app before fixing the difficult to exploit XSS bug on a page only accessible post authentication.

The US State Department has a very effective model for this which they use for vulnerability management in their unclassified network, it is described in some detail here. There are three main components to this system, continuous monitoring, a weighted scoring system and continuous feedback to both those responsible for making changes and those reponsible for overseeing the security of the organisation.  Interestingly it lists as one of it's objectives 'inspiring competition' which I think could be a very useful way of incentivising security initiatives, but that's a topic for another post. The key component as it relates to this post is the continuous nature of the feedback, administrators are sent one task (the highest priority for the systems which they are responsible for) to remediate on a daily basis. The scoring system operates at a operates at a host, site and enterprise level, allowing the feedback to occur at all levels safely guiding the ship around the icebergs.

While the scheme described above does its best to objectify the security changes to be made, situations will vary and what is critical in one context will be less so in another, the important thing is that you do the assessment and make the changes in a sensible order. Sometimes business pressures or regulatory compliance will mean that these priorities will be changed but at least the trade off is understood. If you are placed in a position where you need to meet a compliance requirement perhaps use it as an opportunity to make material gains in your security posture i.e. comply with spirit of the law and the letter.

So it seems I will be lecturing 'Mobile Computing and Security' for Northern Sydney Institute of TAFE's Bachelor of Network Security this semester.  It should be an interesting challenge and I'm quite looking forward to it.  It seems like a pretty good program they run, with a mix of industry certifications and a good broad range of more traditional university type subjects.

Now this is really interesting, especially if you're using onscreen virtual keyboards to prevent MITM capture of keystrokes.

And according to Spider.io: "The vulnerability is already being exploited by at least two display ad analytics companies across billions of page impressions per month".

Interesting look at some of the security architecture in the new Mega site

http://fail0verflow.com/blog/2013/megafail.html

I think the key message here is that if you are going to implement cryptographic systems, even standards based ones, you need to understand the limitations of that particular implementation and it's correct uses.

This is just plain funny
http://securityblog.verizonbusiness.com/2013/01/14/case-study-pro-active-log-review-might-be-a-good-idea/

Nice description of why regex based blacklists are bad

http://deadliestwebattacks.com/2013/01/14/a-lesser-xss-attack-greater-than-your-regex-security/

First post for 2013. The plan is to hopefully be a bit more active after a slow 2012!

I came across this interesting article that has the details of an interview with Bruce Schneier.

While I pretty much agree with Bruce and especially like Bruce's last comment: "Is my data more secure with you than it is with me?", I think the problems begin with the follow-up to that question - which is "prove it".

Now 'proving security' is fraught with danger (and is most likely an impossible task), but while you may have a good understanding of what you do - or don't do - from a security perspective, it's the lack of details that cloud providers will supply on their security practices (other than to say "we use military-grade encryption" or "we follow industry best practices") that always concerns me.

"Trust us" seems to be the mantra from a number of cloud or SaaS providers and trust them we have, sometimes with less than stellar results.

Before signing over the keys to the kingdom to cloud providers, I think it's important to get a good understanding of exactly how they protect your data, what will happen if they do suffer a breach (at what point do they notify you? When they suspect something happened or 2 weeks later when they've confirmed the breach?) and what you can can do to protect your data (such as encrypt everything and keep the keys to yourself).