I liked dave’s analogy of risk perception, but couldn’t leave a comment to say so so I’m leaving the comment here on my blog.

This week has been incredibly hectic at work. A combination of not only the other project guy being on leave, but also our direct manager too. I’ve been keeping track of my online-readings, but only at a superficial level. Some of the things that definitely jumped out at me..

Google Safe Browsing API

The Safe Browsing API is an experimental API that allows client applications to check URLs against Google’s constantly-updated blacklists of suspected phishing and malware pages. Your client application can use the API to download an encrypted table for local, client-side lookups of URLs that you would like to check.

I think this effort is related to the research and hard work that Google have been doing in this space and it’s good to see them giving this sort of functionality back out to the Internet. Apart from the obvious uses that this sort of API provides to developers, it’s all the stuff that you can’t think of that makes it exciting, I mean have you seen how much stuff you can do with Google Maps.

Trinity Rescue Kit

Trinity Rescue Kit or TRK is a free live Linux distribution that aims specifically at recovery and repair operations on Windows machines, but is equally usable for Linux recovery issues.

Found this on a post from Darknet and what I found really interesting was the toolkits ability to read and write to NTFS. Cool stuff.

Why do Security?
Really good post from Andy’s blog on why compliance is not the reason to secure. I couldn’t agree more, and it’s surprising at how many people still tie them together as if one implies the other. I understand that they potentially overlap quite a bit but they can also be separated completely. At work we try and offer solutions to both and often have a distinct line between our approaches, compliance control recommendations and risk-based control recommendations.

This issue relates quite closely to security awareness – another topic that we discuss almost daily – and on most project engagements some of the time is spent on educating non-security team members on the two separate approaches we use, and the difference and importance of the two approaches. The idea is to hopefully push some of this “culture” out to the IT teams to get them to start documenting controls even before we see the documentation and in some cases we are starting to see this happen. We don’t expect non-security people to be experts on compliance and up-to-date vulnerabilities, which is what we’re there for, but the more they start thinking about these issues the more secure the process is from end to end.

Whilst wading through some of the standards at work I stumbled upon this word and naturally I ended up at Wiki (and Answers) to figure out what it meant.

In mathematics the concept of idempotence roughly means that “some operation yields the same result whether it is done only once or several times…”

When looking at this term in computer science it refers to when a function, or RPC call, or web-service call, or any type of operation in a distributed system, “can be safely called repeatedly, since a single call or multiple calls produce the same result and the same side effects to the entire system as a whole.”

Answers has a few examples which explain what this concept means, two of these are:

• C header files, which “are often designed to be idempotent, that is, if the header file is included more than once (as can easily happen with nested #included files), then nothing untoward happens – the effect is the same as if a file had been included only once.“
• and HTTP GET Requests, which “are assumed to be idempotent. The web infrastructure uses this assumption to cache the result of these requests.“

As you can see the computer science meaning of this term does morph the original mathematics semantics just slightly, regardless the concept is quite interesting and does play a part in securing web applications. In particular when designing input/output and using HTTP protocols as they were originally intended, such as submitting changed, non-idempotent data with POST instead of GET.

Where this is potentially vulnerable is where web apps are designed to use GET requests to modify databases, or other state changes. In addition to these requests being cache-able, and therefore recalled, it can also lead to unsuspecting 3rd parties making system changes. A number of sources highlight that the potential source of this problem is that the HTTP RFC leaves the handling of GET calls as inferred to be idempotent, when they may be implemented differently – obviously left up to the programmer.

A good example of this type of exploit is when digg.com allowed users to add friends just by visiting a URL, ie http://digg.com/invitefrom/{username}.

The Google Security Blog has an interesting article on some research they’ve been performing on comparing web server software against web servers distributing malware. The statistic I liked the most of course was that while Apache accounted for approximately 66% of web servers on the internet (IIS at 23%), IIS accounted for 49% of the web servers hosting malware.

The article offers up some suggestions for why this may be the case

We suspect that the causes for IIS featuring more prominently in these countries (China and South Korea) could be due to a combination of factors: first, automatic updates have not been enabled due to software piracy, and second, some security patches are not available for pirated copies of Microsoft operating systems.

It’s seems like a downward spiral where pirated software in turn leads to end-user exploitation. Whether or not Microsoft, for the greater good, should allow their patches to be applied to pirated software I’m unsure. It’s a balancing act I guess, until some critical mass of end-users get owned by these servers it’s probably not worth them changing their policy.

Two separate things I wanted to write about in here today.

Firstly was the article from Infoworld on a Cyber-Ark study into IT employees gaining unauthorised access to company systems. (Thanks Martin for the link to the article). Even though most security people will be open about their concerns of the insider threat, the “nice-guy” in me was still surprised to see the results of the study finding that:

one in three of the roughly 200 IT employees participating in the study admitted to somehow gaining unauthorized access to company systems for the purpose of reading sensitive materials.

And this was from an Information Security event!

Naturally you have to take these sorts of survey results with a grain of salt. So I jumped over to the news release to have more of a look and found even more findings of a “well I knew it was bad but didn’t realise it was that bad” nature:

more than half of people still keep their passwords on a Post-It note, in spite of all the education and reminders to do differently.

This included Administrative level credentials.

These sorts of security problems do make me remember all the hours I spent at university working on technical solutions to this sort of problem (nothing has changed in 3+ years people), and it becomes so apparent, not that it wasn’t already, that this problem has deeper roots than technology, people and policies. There might never be a perfect fix to this problem.

The second thing I wanted to mention was that NIST just released a Draft of the their Guidelines on Securing Public Webservers and after a quick skim read I was quite pleased with it. In particular the section on “Recovering from a Security Compromise”. I know that so many people out there are fantastic at configuring servers and web applications, but you compare that with the number of people who could successfully recover from a security compromise and gather useful forensic evidence and you would be greatly surprised.

And now thanks to Gears I can read my news on the laptop even after it’s disconnected from the (inter)network!

This sort of functionality has been something that I’ve wanted for quite sometime, particular in the field of portable devices. The old adage of wanting to develop applications on PDAs and have them cache data offline whilst out on the field, then re-synchronise with the central database when they get back home.

Trust Google of course to make it all happen within your web-browser. Really good idea and I’m guessing it’s going to help them really start to rope people into the concept of the GoogleOS (which people have been talking about for a while now).

And to ice that cake of theirs they’ve provided a simple, documented API for all your code-monkeys out there.

Of course, the security side of Gears is fairly interesting, and I’m betting right now that forensic experts out there are dissecting the manifest files and all the other funky stuff that’s done in Javascript and Gears. Especially as in the API tutorial they show you that even after clearing firefoxes cache Gears still kicks in and stores that data offline.