Dominic White

Based on Verisign's response here and here (in the comments), they have prevented future attacks, but seem to find the undermining of their PKI for the next several years an acceptable risk versus revoking thousands of certificates at great expense. However, Tim did mention that if they can find a unique characteristic of the bad certs, that would help, here's my attempt. 

The presentation by Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik and Benne de Weger is done. I am busy reading up on it and will post a summary and my thoughts here a bit later. Those are happening real-time on my twitter feed or on the right panel of my blog.

There's already a lot of coverage on this. I'm going to dig into laying blame, and potential geeky solutions for the end user.

While taking my drugs this evening I noticed something interesting; vs. . Is this rampant plagiarism? If so, somebody at SensePost better sue the arse off those Schering  guys ;)

hdm just posted a graphic on his twitter feed of an OpenVAS client talking to a Metasploit server. This is pretty cool, and the possibility of integrating Nessus OpenVAS at the NASL NVT level (assuming that's what's happening) gives a good reason for greater adoption of the OpenVAS project.

It's Christmas 2008 here in Africa. Hope you all have a blessed Christmas with some quality time with your families. As for the security geeks, I hope the break gives you time to think, and we come back with new ways to combat crime and defend data ala the spaf.

Jock (welcome to the blogging world) and Allen have responded to my last entry on Data Loss/Leak Prevention (DLP) vendors partnering with Digital Right Management (DRM) vendors. Jock had an interesting point about getting users involved via DRM, and Allen had some ideas around maturing DLP processes. I'm not sure I fully agree with Jock's ideas, although they do point to some important points that Allen and I agree on about workflows (but not that DLP is dead ;) ).

First RSA with Microsoft, then McAfee with Liquid Machines. It makes sense, especially for companies wanting to get proactive about preventing data loss. Although, what DRM (Digital Rights Management)/ERM (Enterprise Rights Management) doesn't have that DLP (Data Loss/Leak Prevention) does is the simplicity. It relies on user's pro-actively protecting their data, something we know we aren't good at. Sure, the DLP solution is there for when they don't, but then what's the point of the ERM solution? I'm playing devil's advocate a bit here, and am not committed to that position. It is interesting to note that there hasn't been much partnership between DLP vendors and other 'data focused' security products such as database activity monitoring (DAM) or data backup vendors and only limited partnership with encryption solutions. ERM seems to fit well from a marketing point of view, but I think there are some key integration points between the other solutions that can provide an easier security onion (aka defense in depth).

I needed to get this working, and things didn't work out the box. Here's how to do it.

I've decided I'm sick of Windows. I used to use Linux as my primary OS with no Windows, but since joining the corporate world, especially in South Africa, I've been forced into using Windows against my will.

This is for various reasons, and despite my many attempts over three years. There were lots of little battles along the way, like driver support for the laptop I was using etc. Those have mostly been won. However, there are some big battles left, and I plan on tackling them. This is the first of my 'Corporate OSS' entries, where I will document my solutions to these problems, if they exist.

First on the menu is connecting to the network believe it or not.

I've just installed my first 64bit OS in the form of Ubuntu's Intrepid 8.10. However, I ran into some problems trying to get my SSL VPN up and running (but that's another story). I ended up needing newer versions of libssl and libcrypto. However, OpenSSL's configure scripts didn't want to believe me when I asked it nicely to make 32bit version. After struggling with various arch, target and -m32 settings, but having 64bit headers still included in the resulting Makefile; I eventually found this blog entry, which pointed me to the helpful 'linux32' app, which is part of the util-linux package. It creates a shell which wraps calls to uname to make it look as though you're on a 32bit architecture. Problem solved.