A good friend of mine, lets call him Mikey G, shared this article via Google Reader the other day and it’s probably the first time I’ve gotten interested in the work going on in the HTML spec, as far as security is concerned. The feature in particular is the “sandbox” attribute for the <iframe> tag.

The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe.
…
When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled.

The article lists these privileges as being reduced for “sandboxed” iframes:

• They cannot access the DOM of the parent page
• They cannot run scripts
• They cannot embed their own forms, or manipulate forms via scripts
• They cannot read or write cookies, local storage or local SQL databases

At first when I read this I imagined a world free of unsuspecting webizens getting their machines compromised due to drive-by-downloads from ads being served out of iframes, or malicious session-injecting javascript within iframes. This imaginary world was no more than a glimmer of hope as a few truths became apparent:

• With the universal acceptance of javascript and web2.0isms in our browsing lives, there will always be a technical means for attackers to make our browsers do something untowards – it’s always just a matter of time
• This functionality will have to be implemented by browser manufacturers (I believe latest dev versions of Chrome already implement this functionality) and people who are falling victim to these attacks today are more than likely running out-of-date version of browsers (*cough* IE6 *cough*) so this won’t help them anyway
• The parent page can provide options to over-ride the controls, in case the 3rd party ad-provider requires scripts, which of course they all will

The blog makes it clear that this attribute, when it finally gets implemented*, is not the only thing your developers will have to do to provide areas for untrusted content. They will have to continue doing all the existing security “stuff” they’re doing now. I’m relieved to know that on top of all the pretty new features they’re putting into the new HTML specs (audio, video, ria, local storage, bling bling) that they are also looking to make inroads into making peoples browsing experience safer too.

*NB: This includes implementing the sandbox attribute, the text/html-sandboxed MIME type, and the srcdoc attribute – which could be quite a long way away.

It’s been one of those weeks. You all know them, too much to do, not enough time. What compounded the week was it kicked off at 42°C which left me with one hell of a headache.

So Alex and Mike have posted a couple of blog entries on certifications. Starting with Alex on ISACA’s CRISC (posts 1 and 2) – he’s pretty clear on why he believes it’s a bad idea, slightly different to what my thoughts were the other day but definitely valid, I won’t do them justice summarising so just visit the posts.

Mike (now over at Securosis – ‘grats) expands on Alex’s posts and looks at info sec certifications in general starting with what would motivate people to acquire a certification, then slowly stripping away those motivations.

I also wanted to highlight another well rounded post from some other local boys. Whilst there have been lots of things posted about the secure way to social network, particularly in this highly connected Twitterised, Facebook life we live, I found this post on how you should look at your behaviour and practices on Facebook nice and succinct. Good work guys, we need more Perth people blogging on information security.

I’m surprised it took ISACA (or ISC^2 or maybe FAIR) this long to create an information risk certification. The first question that we asked when we saw this was “well what about all the other risk certifications, how is this different?” I immediately responded with how those other certifications or qualifications have been around for a long time, the disciplines they are based on are mature, whilst information risk on the other hand is still in its infancy. In addition, most of the existing certifications are based on financial risk.

Current tweets on the topic don’t appear positive, and until ISACA release some more information, or any information, I would tend to agree. Thinking about how such a certification may make an impact within my workplace my mind drew blanks. I mean will it make the people who perform risk assessments any better at it? Probably not. Will it increase their accuracy? I don’t think so. Would it make the people receiving the outputs of these risk assessments trust their output more? Probably not.

It wasn’t until I got home and started thinking about this post and re-reading the material before I realised that the certification appears more control based than risk based. (Emphasis placed by me)

The Certified in Risk and Information Systems Control™ certification (CRISC™, pronounced “see-risk”) is intended to recognize a wide range of professionals for their knowledge of enterprise risk and their ability to design, implement, monitor, and maintain IS controls to mitigate such risk.

I think this highlights some of the core issues with this certification. Knowledge of enterprise risk is something that is refined with time and experience. It’s a complex and almost completely people & process driven exercise. A certification will not help the people side of this exercise, you can’t get experience through a certification.

Therefore an IS risk certification’s strength relies on its ability to bolster the process not the person, but most of the current wordings appear to indicate that the certification is about designing, implementing, monitoring controls. This to me sounds like a mashup of a security architecture certification (SABSA perhaps?) and security operational certifications (with a splash of GIAC).

Regardless of all this, I think there will be a flurry of activity within the industry around April when ISACA open up the certification to the grandfathering program. I mean if you already do this in your job why not acquire this cert without having to sit an exam? We all have the experience, we’ve been doing risk assessments since we started to walk, followed swiftly by advising the business of why they shouldn’t do stupid thing X. If we can’t actually get more objective with our assessments, at least the certification will give the appearance of being more objective. Win win!

If the decision of whether or not to place your information in the “cloud” comes down to a simple matter of trust, trust in whether the cloud provider can deliver the availability they market, trust in the protection of your information in a multi-tenancy environment, trust in their staff (including all the staff they outsource to) to not damage or impact on the service. And this trust is all we have because we aren’t able to view their premises, their procedures, their audit statements and we aren’t able to assess their systems, their applications or environment. Who is it that stands up and says “Yes, we trust them. Lets do it“?

At first I used to think this was the business, I mean they’re the ones fronting the cash to move their important information into the cloud. They’re they ones who will see all the benefits of not having to rely on IT. Then I realised that they wouldn’t know whether or not to trust the cloud provider, surely more often than not they would ask someone within IT “Hey, can we trust these guys?“.

So can IT really dictate back to the business that “Yes, we trust them. Lets do it“? Can the CIO put his hand on his chest and declare yes? How does IT even come up with that answer? Do they even know? Is it the architecture teams perhaps that look at the service being offered and reviewing what the business is trying to do and going “Yes, we trust them. Lets do it“? At this point I would imagine those architects turning to the risk/security/governance people within their organisation and once again asking the question “Hey, can we trust these guys?“.

Hopefully this is where the line of questioning comes around full circle. Hopefully this is where the downwards questions stop. Hopefully this is where the security people ask the business people “What’s the value of your information? What would happen if it was unavailable, or disclosed, or modified?” While this is an important question, and one that will have to be answered at some point, it doesn’t really help anyone with whether or not they can trust the provider. It’s often here that things get difficult and the incessant pushing and probing of the provider starts to weigh heavy on the heads of the business. The costs are piling up and time has run out.

The next thing you know you’re in the cloud. But who gave the definitive answer to the question of trust? Probably no-one.

Well ‘10 has started off with a bang and already I’m trying to clear my head and set a vision for what I’d like to personally and professionally accomplish in the next 12 months. Looking back over what I was hoping to achieve in 2009 I can safely say that in the past 12 months within my info sec sphere of fun (mostly work – but also elsewhere such as the Perth OWASP Chapter) I’ve achieved what I’ve hoped to, primarily that of raising awareness of security issues, in particular those found due to issues within the software development lifecycle.

Personally 2010 will bring the following (this is not a wish list, this is a todo list):

• Purchase a house (Ten and I are got an offer accepted on the 30th of Dec so this is done and dusted – I can’t really explain how exciting this is, but it’s definitely the biggest thing to happen in my life and I’m so thrilled that Ten and I are doing this!)
• Spend more time honing my music skills (This is drumming skills, not SingStar skills. I’m already excited with what’s happening in Grenade Baby Lemonade, what with our 3 track EP on the way. In addition I’m going to also get started on another project *wink*)
• Cycle to work more

Professionally I’ll be focusing on working even more closely with development teams to truly embed security within the SDLC. This has already started with some fantastic engagements towards the tail of ‘09. The trick will be to not let up, not lose focus, to continue to make myself available to those who have queries and to package information that’s useful and not too bloated. It’s helpful that there is so much great information out there, including but certainly not exhaustively:

• Security Ninja’s Checklist Approach to Security Code Reviews
• Jeff Jones’ Post on Expanding SDL for Cloud and Agile Development
• Nick Coblentz’ material, including Observed Secure Software Development Stages
• And of course the Security Maturity Models, including OpenSAMM

Here’s to 2010! Hope everyone else started it as well as I have!

Cheers!