Posts Tagged ‘encryption’

SQL Server Backup Compression vs. Quest Litespeed Engine

As more and more functionality is built into products like SQL Server it’s always worthwhile reviewing third-party tools and utilities when you’re considering an upgrade to see (a) if they’re still required and (b) if the tools themselves need to be upgraded.  With the introduction of Backup Compression in SQL Server 2008 R2 Standard Edition you could begin to think that the future is grim for Quest’s backup compression software LiteSpeed so I thought I’d do some testing to see exactly how it stacks up against the native compression.

LiteSpeed Engine

I’ve been using LiteSpeed on and off for a few years now and it has always been a great tool but I’ve always found it a bit of a drag to have to use the GUI to administer and setup jobs however in January 2010 Quest launched the LiteSpeed Engine for SQL Server which allows you to administer jobs using the native SQL Server tools.  The LiteSpeed Engine acts as a driver and the configuration tool allows you to define a variety of configuration profiles based on file extension and from that point onwards you can use the Management Studio to setup backup jobs, maintenance plans, etc. and all you have to do is specify the file extension of the profile you wish to use.

The configuration tool allows you specify the compression level from 1 to 8, encryption level including various bit-length versions of RC2, RC4, 3DES and AES though as you’ll see later the overhead of adding the highest level (256-bit AES) isn’t that great so I’d always shoot for the maximum.

Benchmark Structure

The test is relatively unscientific since I used only one database but it was carried out systematically, the data comes from a transactional billing system which I chose as it has a mix of strucured tables and raw transactions and comes in at about 6.5GB so it wouldn’t take too long to test.  I used the following configurations…

Benchmark Results

On my test database the baseline SQL Server native compression reduced the 6.2GB database to 765MB (12.2% of the original size) and took less than half the time (43%), to achieve the same level of compression using LiteSpeed I had to use Level 2 which gave me 12.2% of the original size and 40% of the original duration.

At first this doesn’t look great for the third-party tool but the benefit of using a mature backup compression engine is the flexibility and LiteSpeed’s configurations allow you to tweak the performance to solve whatever problem you have in your environment whether that be the absolute size of the backup, the backup window time or a mixture of the two.

If it’s size you’re after then Level 8 really did seem to work wonders on my test DB bringing the size down to 5.6% of the original at only 352MB though it did take 2.6 times the original duration, if it’s the backup window you’re looking to reduce then the basic Level 1 did manage to improve on the native compression by taking 0nly 37% of the original duration whilst still compressing to 13% of the original size.  If like most people you’re looking to have your cake and eat it (i.e. reducing size and backup window) I’d suggest that Level 3 is the best compromise giving 10.9% of the original size at 77% of the original duration so you get some benefit in both areas, though Level 4 takes compression a bit further and still gave a slight time reduction.

Clearly, the real answer is testing and since I’m at the beginning of data warehousing project I’m not in the position to make any firm decisions but I think that even if you don’t run out and purchase it now LiteSpeed is a very valuable tool to have in your mental arsenal so that if you come up against backup size/window issues or you’re faced with older versions of SQL Server you’ve got a solution in mind already.  Quest have an odd policy of keeping pricing quite opaque but I believe that the full Enterprise version (including the LiteSpeed Engine) retails for around £1,800 ($2,800) which isn’t too bad if you need that level of flexibility.

SQL Server Native Compression

LiteSpeed Compression (No Encryption)

LiteSpeed Compression (With Encryption)

Boot Kit Renders Windows + Truecrypt Entirely Vulnerable

Having been using PCs for at least twenty years and having been an IT Professional for the last eight it’s a rare occasion for me to be blown-away by a piece of technology but the Stoned Bootkit, presented by the author Peter Kleissner at HAR 2009, literally blows my mind.  You can find the video here or the presentation here.

Essentially a bootkit is a small piece of code that can be inserted into the Master Boot Record of a PC’s main boot drive, this code is then executed every time the PC is switched on and executes before the operating system loads.  This is effectively a variant of more traditional rootkits which tend to install themselves as low-level drivers as part of the operating system and they are both equally dangerous in that once a system has been compromised the writer of the rootkit/bootkit can effectively do whatever they like.  This may range from logging and transmitting keystrokes and capturing bank details to bypassing product activation or enabling law enforcement to gain access to allow forensic analysis.

The Stoned Bootkit is effectively a technical demo and whilst it is entirely effective I am not aware that it has been put to any nefarious purpose, in fact it was released by Peter Kleissner at the Black Hat security conference in 2009 to an audience of security professionals and I believe intended by the author as an ‘eye opener’ for the industry.  Notably, Stoned is the first bootkit that has been tested an verified on Windows 2000, Windows XP, Server 2003, Server 2008 and Windows 7.

So why does this blow my mind?  It’s not that the technology is brand new – MBR viruses have been around for decades which is something which Kleissner acknowledges himself by naming his boot-kit after one of the earliest examples: the Stoned Virus from 1987 (I remember encountering the variants Manitoba and Zapper in the early nineties).  The reason that I was so awed by Kleissner’s presentation is the comprehensive list of attack scenarios he presents, the ease with which this is possible and the fact that it can be used to entirely bypass whole-disk encryption (tested against Truecrypt and DiskCryptor).  The bootkit is available for download as an ‘infected PDF’ or even as Live CD that can be used to boot and infect any PC to which you can gain physical access.

There has been some debate between Kleissner and Truecrypt about whether this constitutes a ‘valid’ attack, the debate is fairly academic since Truecrypt themselves acknowledge that the attack is effective provided that the attacker has administrator privileges (most non-technical users run this this way), that administrator privileges can be gained (most likely by other exploits) or through physical access to the machine.  I’ll concede that Stoned isn’t a valid attack against Truecrypt itself but it is a valid attack against the PC and a such can still be used to entirely bypass Truecrypt which still allows an attacker to achieve the same aim.

As a footnote, it appears that Peter Kleissner is being sued by his former employer, Ikarus Security Software GmbH, for an alleged intellectual property violation (source code theft), given that he is only 18 years old I sincerely hope that this does not harm or curtail Peter’s future career and potential.  Alarmingly there are reports (English here) that Ikarus and Kaspersky are attempting to build a criminal case agains Kleissner on charges including “distributing malicious code”, if this sticks it could be worrisome for all security researchers (particularly hobbyist hackers with no money for a good legal defence) who often write code that could be classified as malicious whether they intended it or not – all security flaws could be exploited, does that make it wrong to point them out?