I read this article by Andrew over at ozrisk the other week and I’ve been meaning to comment on it but have only gotten around to doing it today. The main concept that Andrew focuses on is quite simple:

“The more regulation you have in a market the more that regulation will favour the big suppliers – i.e. the larger incumbents – over the smaller incumbents, any potential new players, and, crucially, the individual consumers. So the more that you regulate the worse the situation gets for everyone but ‘Big Businesses’.”

Whilst the article focused on regulatory requirements of Australian financial institutions, after my first read I thought to myself how relevant and aligned these statements were to the information security space as well. This is of course because the relationship is almost one-to-one, a component of having to comply with additional regulations often relates to the protection of your information, and therefore increases the rigour and cost of your security efforts.

Interesting stuff and I’ll have to endeavour to get my hands on Tim Carney’s “The Big Ripoff“

Tonight was the Perth OWASP Chapter’s second meeting (the first being a joint effort back in February with AISA) and I thought the evening turned out to be great. The numbers weren’t massive, primarily due to the late notice for the meeting, but it was probably because of this that there was a lot of great discussion around the table. In particular between the sole-developer in the room (poor guy), and the rest of us security folk.

We were fortunate enough to have Shlomi Cohen (Used to work for Sanctum on AppScan, then Rational on AppScan and AppShield and now within IBM Rational) in town and he presented a fairly high level view on the state of web-based malware and how it’s on the rise. He had some interesting graphs highlighting how pure-browser security is getting better, but all the add-ons and additional components (flash/reader/ActiveX etc) are getting worse. It was also beneficial I thought that we had some of the ISS guys in the room who could elaborate on these issues as they pertain to the real world. Well, as real as the world is when you work for IBM.

What was really highlighted though, and I found this the same with OWASP Australia’s AppSec in 2008, was that we just don’t get enough developers to these events. Security people get it, they understand the vulnerabilities and they understand how they can be prevented, but the security people are NOT the ones building the code. Sure, we can come and bash it at the end, but we all know that there are better ways (*ahem* SDL *ahem*). We touched on David Rice’s Geekonomics (to an extent) and how the incentive just isn’t there for developers to develop without (security) fault. They are not being paid for 0 vulnerabilities. They are getting paid to deliver function x, and that function x runs n fast.

These sorts of gatherings inspire all sorts of energy and passion and I know personally I’m hoping to assist my fellow chapter leads in holding the next meeting sooner rather than later. I just need to figure out what kind of incentives I need to offer to get the developers down!

Issue 22 of the (IN)SECURE magazine came out at the beginning of the month and as always it’s packed full of juicy sec goodies. In particular Alexie Lesnykh’s “Making Clouds Secure” article. As the title suggests it’s taking a look cloud computing and some of the security issues around this technology/paradigm. If you follow Hoff’s Rational Survivability or twitter you’re probably aware of a lot of the risks that pertain to cloud computing, but what I found particularly interesting about Alexie’s article was the breakdown of what the actual issues are, especially in the context of corporate use of cloud computing.

The issues are then split into 3 main categories: security of the provider platform; security of data transmission; and security of the end-point workstations or clients. This last category was something that I had never thought too much about, given that endpoint security is something that IT have been doing for a while, and mostly we seemed to be concerned about the security of the cloud and how to trust that the provider is securing the information and systems as they market. As Alexie highlights though, attackers don’t often target the provider’s platform, knowing that it’s a very well protected fortress, and instead have been focusing on the endpoints. This issue is exasperated because one of the driving characteristics of cloud computing is it’s Broad Network Access (if we’re using NIST’s words) or Dynamism (CSAs) that, because of its ubiquitous nature, means that corporates often allow (nay – encourage) access from outside the organisation in order to leverage the cloud computing model. Why outsource your email to a cloud computing provider yet only allow access from within your secure, internal network?

Trying to get my head around the particular issues of endpoint security in the context of cloud computing started to hurt my head, especially when trying to understand how does an IT function secure the businesses information when it ends up in the cloud and is accessed from non-controlled endpoints? Is it IT’s responsibility to then secure those endpoints as well? Or is it something that the provider should look at? Google look at most of the traffic out there on the Internet, they probably have a pretty good idea of if IP address A has visited malicious site B and therefore perhaps shouldn’t be logging on. Or perhaps we need to see some more integration with things like Checkpoint’s WebCheck.

Solutions aside, corporations, if not already, will start utilising these services soon, so start thinking about these issues sooner rather than later.