Well OK, "not my problem" is perhaps a little harsh. But not my responsibility could be more accurate.
I think it is definitely time to rethink 'Availability' (as in the classic security 'CIA' triangle of Confidentiality, Integrity, and Availability) as being the responsibility of the Security area.
Availability, and it's bigger, uglier cousin Disaster Recovery, have long been a part of the Information Security mantra, from entry level CompTIA Security+ level up to CISSP or CISM level. Why is this so?

While you could argue that availability is a security responsibility in the case of a DoS attack, does it remain a responsibility if, for example, a lack of disk space causes a server to come crashing down? Does that mean capacity planning is now Security's responsibility? Or if the single power supply dies and a server or router is unavailable - should Security have ensured that the critical system has sufficient redundancy to avoid an outage due to hardware failure?

I think in the dim dark past that Availability fell under security so it would be 'somewhere' and someone would be thinking about it - even if the 'security guys' weren't the most appropriate people.

I don't think the CIA triangle is going anywhere soon, but in my opinion you're better off concentrating on Confidentiality and Integrity and leaving Availability and DR to the IT department...

Well, that's the CISSP exam out of the way... On to CEH?

So it appears that First State Super have decided not to prosecute the customer that informed them of a (possibly longstanding?) vulnerability in their website - how kind of them. Of course it did take being lambasted in the media to cause the about face and has resulted in unwanted attention from the privacy commissioner...
And the fallout doesn't end there, as it appears that the company responsible for the (in)security of First State is also responsible for other superannuation websites - including recently being awarded a contact for looking after the security of a Government employee superannuation fund...uh-oh!

In not entirely unrelated news, the SEC in the US has released new guidelines requiring disclosure of InfoSec incidents. While only guidelines at the moment, I think this is a step in the right direction. Even if little else changes, it might give us some better data on the rates of intrusions/incidents in these big companies.

Two posts in two days, I'm not sure I can keep this pace up!

I came across the following article this morning and since it keeps up the theme of building architecture it makes a nice follow on to my previous post. While I agree that developers should have a good grasp of secure coding techniques, I think security is still seen as something of an infrastructure problem i.e. firewalls, ACLs, disk encryption etc rather than something that developers need to worry about. Technologies like web application firewalls do nothing to help dissuade developers of this. The only way to ensure that security is 'built in' to applications is to ensure that there is consultation at the design phase between the development team or architect and the security team or architect. Application design needs to be viewed more like the design of a military installation rather than a sky scraper. In the same way that security specialists lay out the security of the base the security guys should be laying out the security of the app and reviewing the developers implementation of the security design.

Yesterday, while attending a presentation at the VMware vForum event in Sydney, the presenter offered a view on architecture from 1st century Roman architect Vitruvius which struck a chord with me from a security perspective. Rather than wait for the slide deck to get emailed to me (no, I didn't think to write it down verbatim at the time) I visited the great oracle Wikipedia, et voila:

According to Vitruvius, a good building should satisfy the three principles of firmitas, utilitas, venustas, which translate roughly as –

Durability – it should stand up robustly and remain in good condition.
Utility – it should be useful and function well for the people using it
Beauty – it should delight people and raise their spirits.

According to Vitruvius, the architect should strive to fulfill each of these three attributes as well as possible.

While I think these concepts are pertinent to all aspects of IT architecture, be it application, infrastructure or enterprise architecture, this is a security blog.

Durability, well that's obvious enough, if your design doesn't stand up to the threats it will encounter throughout it's lifespan then it's not much of a security solution. Easier said than done I know, people have been trying to build secure systems for as long as there has been something to protect and, by and large attackers have found a way around these defences. That doesn't mean it's not a worthy quality to strive for in a solution however.

Something which is too often forgotten when developing security solutions is usability, security measures can be obstructive to the end user experience which ensures that people will either find a way around them or, where they have an option, not use the system at all. Balancing the utility of the system with security helps ensure that security is not seen as a burden and is included by default in systems rather than as an afterthought

Beauty... That doesn't seem to fit with security, your average security guy generally isn't the prettiest and no, this isn't referring to the subtle shading on your Visio diagram. For me, beauty in this context infers an elegance and simplicity of design. Too often designs are overly complex and, as a result, prone to errors or they are clunky, inelegant and not fit for purpose. Complexity creeps in to design for a number of reasons, from poor initial planning to integrating with legacy systems. While the architecture of IT systems is an inherently complex topic, beauty (simplicity and elegance) is an important aspect to keep in mind when developing your solution.

While it won't always be possible to achieve 100% success including all these aspects in the design, I do think they represent a worthy set of goals to keep in mind when deciding on which hue of pink would be the best background for your next Visio diagram.

Here's one for the shame file. An Australian security researcher, while accessing his superannuation fund's website, noticed a security flaw - a direct object vulnerability when the website displayed customer statements.

He notified the company, provided them his personal details and the details of the vulnerability. He even notified the ex-colleague whose records he accidentally viewed. The companies reaction? Call the cops, engage the lawyers and even threaten that he may be held liable for the cost of fixing the vulnerability!


Seriously? What planet are these guys living on? Would the outcome have been better if he had sold or disclosed the vulnerability to some less ethical party? Or done nothing and waited for someone else to exploit it in future? Maybe it's time to implement some kind of whistleblower-style laws to protect researchers in these circumstances.

I guess no good deed really does go unpunished. This kind of URL manipulation (ie: changing a single digit) hardly constitutes hacking in my mind. It'll be interesting to see the outcome here, and how our judicial system handles this case (if it gets that far).

Just when you thought it was safe to go back in the water Playstation Network, it appears that "Sownage II: Son of Sownage" may be beginning as Sony gets hit with another big Data breach. Or where they? This article (and the message from the Sony CISO) makes it sound more like someone who has compromised data from other sites (perhaps gaming related?) is running their stolen credentials against the Sony Network.

I feel pretty sorry for Sony at this stage. Even the most hardworking and talented Security guys can only do so much at once and this sort of attack - which they may legitimately have been able to do nothing about (other than tell people to not use the same password for Sony as other sites) is still going to be publicized as a "Sony Breach".

Of course I feel less sorry for them after their TOS upgrade that requires end users to mail a letter to opt out of the new terms.