un-excogitate.org

Dailies

Photos

Categories

Monthly archives


Search




Some Readings and Why Compliance Does Not Always Mean Security

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.

Posted by Christian 23 June 2007


Post A Comment