Depending on the size and business needs of the enterprise, a WLAN can be used in a few different ways:

Basic Mobility – the most common use of WLAN is simply to extend the existing wired LAN to wireless users.  This can have a very positive impact on productivity, allowing users more flexibility throughout the workspace.

Segmented Mobile Data - this type of WLAN is one where the network is dedicated to use of a specific type of data that is segmented from the main enterprise network.  Typical use cases here are in hospitals or retail stores, where compliance regulations provide strict guidance on data protection and segmentation.

Guest Internet Access – common in cafes and large businesses, this type of WLAN typically provides only internet access and is entirely segmented from the enterprise wired LAN.

Wired LAN Replacement - this type of network is becoming a feasible alternative to the hassle of running cable, and will likely continue to grow in popularity as time goes by

These use cases can blend together in any number of ways.  A well thought-out design at the beginning, along with the right hardware planning, can accomidate these uses and even more.

General Strategy

Like other networking strategies, the use of proper segmentation at the Layer 2 level is critical when designing a WLAN.  Your most critical data flows should have their own segment, protected by methods like VLAN segmentation, firewalling, private IP spaces, and routing tables.  Regardless of the authentication and encryption method used for the WLAN itself, properly designing its location within the enterprise wired LAN is critical.

Data encryption in 802.11 is accomplished by a combination of the authentication type with an underlying encryption method.  Use of WPA2-AES encryption should be considered mandatory in any new WLAN deployment.  This encryption technology has no documented vulnerabilities and widespread hardware and software support.  If your enterprise has devices that do not support WPA2-AES, strongly consider replacing them.  When designing a network, its security should not be determined by the weakest link.  Unless there is a business case for doing something otherwise, use the strongest encryption and authentication methods available.

My next post will get into some specifics about these different use cases!

Some History

I will not go into the history of the 802.11 standard in too much detail here, although there are a couple of important points to recognize when thinking about how to deploy a WLAN in your business.  The most important thing to know is this – many of the WLAN security technologies that were being used in deployment until three or four years ago are vulnerable to several well-known attacks.  If your business has a WLAN that has “just been working” for a while – it should probably get some attention.

To elaborate on this a bit further, the most common Wireless LAN encryption method used until late 2003, WEP, has been subject to some very public weaknesses, almost since its inception.  Its temporary replacement, WPA-TKIP, has similar (although not as dramatic) weaknesses, that have been public since at least 2008.

Adding insult to these platform-common weaknesses, some of the alternate, “more secure” based authentication methods advised by vendors have also been picked apart and had their vulnerabilities shown to the world.  I’m looking at you, LEAP.

To sum it up briefly – many networks that people thought were secure in 2003 or 2004 are definitely not secure today.  And unfortunately, WLAN sometimes is treated like a part of the physical infrastructure – if it ain’t broke, don’t fix it!

Current Tech

Fortunately, 802.11 is really starting to come into its own lately, and can be an extremely secure – in some ways more secure – piece of critical infrastructure.  The extremely solid (and so far unbroken) WPA2-AES encryption standard defined by 802.11i has had widespread vendor support since 2007.  And certificate-based authentication methods such as EAP-TLS, PEAP, and EAP-TTLS have similarly experienced a growth in support, among not just desktop OS platforms, but mobile operating systems as well.  And Wireless Intrusion Detection Systems are hitting their stride, ranging from several robust and effective professional solutions from vendors like AirTight, Cisco, and Motorola, to fantastic open-source applications like Kismet.  And robust infrastructure management software is now making the administration of Wireless LANs more simple and effective.

In short, today it is possible to deploy a WLAN that will meet all the use cases an enterprise can throw at it, and that is as secure as a typical wired LAN infrastructure.

In the next post, I’ll cover typical enterprise WLAN use cases, and the strategies for designing and securing them.

Feel free to drop us a line here and we can have a beer!

To meet these requirements, I use a combination of Dropbox (http://www.dropbox.com), Keepass (http://keepass.info/), and Truecrypt (http://www.truecrypt.org/). I use Dropbox as a portable ‘Program Files’ directory where I install portable versions of Keepass and Truecrypt. This allows me to have my ‘Program Files’ directory replicated on all systems where the Dropbox client is installed (for backup purposes, I usually have my Dropbox account synchronized to 2 different systems).

I use Truecrypt to create an encrypted partition on the USB drive (using AES for encryption and HMAC-SHA-512 as a hash algorithm). The volume key used to encrypt/decrypt the partition is then stored as a password in my Keepass database (which is also stored in my Dropbox).

As long as the Dropbox is synchronized between my test systems, switching from one system to the other is as simple as plugging the USB drive in and launching Truecrypt/Keepass from my Dropbox.

Here’s my step by step instructions to replicating this setup on a Windows XP/Vista/7 system (I assume you already have Dropbox installed on your system):

1. Create a ‘Programs’ directory in your Dropbox folder. In this folder, create 2 subdirectories, ‘Keepass’ and ‘Truecrypt’.
2. Copy the portable versions of these programs into their respective folders (Truecrypt does not have an explicit ‘portable’ distribution, rather download the setup file here and choose the ‘Extract’ option when running the setup, Keepass on the other hand provides a portable version that can be downloaded here).
3. Launch Keepass and create a new password entry for the portable drive. I suggest using the Password generator function to generate the password. Note that since this password is used as an encryption key, I recommend selecting all available characters for generating the password and using the maximum key length (64 characters).
4. Plug in the portable USB drive that will contain the encrypted partition (note: this has only been tested with USB hard drives; I have not tested this with smaller USB flash drives).
5. Launch TrueCrypt and use the ‘Create Volume’ button to launch the new volume creation wizard. I recommend writing down the path to the volume being created to make it easier to mount later. For my personal setup, I chose to create a regular (non-hidden) partition using AES and SHA-512 for encryption and as a hash algorithm. When prompted for the volume password, use the password entry created in Keepass.
6. The volume is now created!

To actually mount the encrypted partition, start Truecrypt and select an available drive entry. Select the encrypted volume from the Volume list then click ‘Mount’. When prompted, enter the password from the Keepass password entry.

Note that regardless of which system was used to create the encrypted partition, you can mount it on any other system as long as you have access to Truecrypt and your volume password.

Ben and I both attended the SANS 2009 conference in early March, in Orlando.  He was in the advanced penetration testing class, and I was taking the wireless security class.  Verdict on both of those: AWESOME.

Walter also went to a SANS conference in Phoenix to attend a class on secure network design.

I also just finished the EC-Council Certified Ethical Hacker program, which is a good overview certification class.  Don’t underestimate that exam – it’s a tricky one!

Beyond the gobs of training, we’ve also been working on some great stuff at work, getting well up to our necks in the world of PCI.

So, dear readers, don’t fret.  We’re still here, and will be back shortly!

I was contacted by Nathan Liddle, one of the senior support engineers from PGP and we spoke about my experiences.  I was first off, very impressed to see PGP proactively addressing concerns by contacting me here and it was great to be able to share my feedback.

Nathan graciously listened to my story and got the takeaway of that PGP is going to try and improve their recovery disk tools, to hopefully take some of the guesswork out of the process that I had to go through.  They appreciate that I was a pretty ‘techie’ person and was able to figure it out myself, but the average user of PGP WDE may not be able to do so, and that their tools could use some improvement.

So, I’m extending a shoutout to PGP for listening to customer feedback!  Thanks!!

These two fellows were approached with a great offer – $100,000(!) – to grab some files wirelessly and discreetly.  The FBI got the idea of approaching them after they mentioned in an article in Crain’s Cleveland Business that they had broken into several networks wirelessly, and that companies should hire them to protect their networks.  Whoops!

This brings up a tricky question about infosec in general – in a business environment that is only slowly becoming aware to the issue of security, how does one generate new business?  It can seem tempting to ‘demonstrate’ the cost of bad security to a client – and cold-calling a business with information about their vulnerabilities is a sure way to wreck that relationship.  The responsibilities of a security professional are to clearly communicate the importance of a strong security posture and to let that information speak for itself.

These two guys took the exactly wrong approach to selling computer security – becoming the ‘bad guys’ that they’re supposed to be protecting clients against!  In the security field, more than many others, the line between ‘good guy’ and ‘bad guy’ can be blurry.  An infosec professional who is only using commercial tools isn’t really getting in the head of a ‘bad guy’ – because the bad guys are using open source tools, not the expensive Foundstone package.  We’ve got to get in the minds of the threats in order to defend against the them.

This is where professional programs like CEH have value.  This program teaches security professionals both the tools of the ‘bad guys’, and the ethics required to use them properly.  The temptation of a quick payday may be lurking for some people, but it’s good to see that the FBI and other government organizations are actively watching out for these type of people.

As Spiderman said – “With great power, comes great responsibility”.  Security professionals need to keep this at the forefront of their mind at all times.  We’d probably be better off by not wearing tights and a mask, though!

The initial problem was caused by one of my least-favorite pieces of software in the world – the Ubuntu graphical installer.  I was installing Ubuntu onto an external hard disk while using a Ubuntu LiveCD, and in the process of installing the OS, it overwrote the MBR on my laptop’s hard disk.  This seems to be a common pitfall affecting Ubuntu users.  Installing GRUB to the first hard disk is apparently the default behavior, according to several posts on the Ubuntu forums.  I must have missed the “Advanced” menu option to specify the bootloader location.

Installing GRUB to the MBR wouldn’t be terrible, if not for the fact that PGP Whole Disk Encryption (WDE) also uses a non-standard Windows bootloader – a piece of software called BootGuard that prompts the user for the decryption key to the drive.  Because GRUB took over the MBR on my hard drive, BootGuard would no longer execute – and thus the contents of my two partitions were stuck as encrypted with no decryption mechanism on the disk.

Adding further frustration to this issue was the fact that Ubuntu (loaded onto the external HD) wouldn’t even boot up without the laptop’s HD – because the GRUB boot loader was on the internal, encrypted HD, rather than the external HD that held the rest of the operating system.

So, I was stuck with an encrypted Windows installation and a halfway-usable fresh Ubuntu install.  What’s a guy to do?

Fortunately, if there’s one thing that our office has, it’s a lot of computers.  I was able to use a backup laptop to begin doing some research into recovery options.

PGP has recovery boot disks that can be used to decrypt a drive, so this was the first thing I tried.  With my encrypted (and inaccessible) disk in the bay of my laptop, I booted with the PGP recovery CD.  Unfortunately, this returned an error – “Internal error accessing disk, 0×80″.  A common error, if you do a little googling.  Something was wrong in the disk’s partition table or boot record – I would need to try another method.

The first method I found in the PGP Knowledge Base was in Tech Note 807 , which suggests creating a Windows PE recovery disk that supports PGP disk recovery.  I followed this path for a while, but had some issues slipstreaming the PGP software into the disk.  I gave up eventually after seeing a few other simpler methods suggested.

The simpler recovery method recommended by the members of the PGP forum and the PGP Knowledge Base was to install PGP Desktop on another PC, slave the encrypted drive to that machine, and decrypt the drive using the second PC.  I was able to get the PGP Desktop software from our administrator and install it temporarily on a new computer, then cable in my encrypted drive with a IDE to USB adapter.  This looked promising at first, with the machine able to recognize the drive and see its (unreadable due to encryption) partitions, but PGP wasn’t able to identify the drive as holding encrypted data on it.  After a few tries (and a few hours), I decided to move 0n and try a different vector.

I had seen a post on the support forum suggesting using a Windows disk to rebuild the MBR to a normal Windows state.  After doing this, the PGP recovery disc may work, since PGP is prepared to deal with a situation like this (somehow!).  By doing this, I realized I would lose the GRUB bootloader info for my Ubuntu installation, so I first pulled that off the drive from within Ubuntu (cat /boot/grub/menu.lst > /home/menu.lst).  This would give the UUID of the Linux installation if I ever want to try and get it working and bootable.

After doing that, I decided to just go for it.  After installing the encrypted drive into a spare laptop chassis, I put the Windows disc into the CD drive, booted to the recovery console (type R when prompted), and then ran the fixmbr command for the drive.  Rebooted, and…. unable to find operating system.  This was progress!  No more GRUB bootloader!

Finally, I put in the PGP recovery disk again, booted off it, and instead of the error I saw before, it continued on to the recovery console – and it recognized my PGP-encrypted disk!.  I typed in my passphrase, and then, very cautiously, chose “D” to decrypt the drive.  It very slowly started to decrypt.

The entire decryption process when running from the recovery disk takes quite a long time – on this disk (60GB), it was only about 15% along after 90 minutes.  I left the computer plugged in overnight and let it run.  When returning to the office this morning – it was done!  I put it back into my original laptop chassis (I was using a temporary one while I rebuilt a new installation of Windows on a spare HD in the main chassis), and it booted up as if nothing had ever happened.  The whole thing was pretty funny, actually – to see the little guy churning along as if it hadn’t been on the brink of death just 24 hours before.

This entire experience has left a bad taste in my mouth regarding whole disk encryption.  It’s very secure, and my experience with PGP prior to this incident had been pretty drama-free, but when it fails, it fails very dramatically.  PGP has very sparse documentation about the recovery process, and seems to take the opinion that their software is so reliable that they don’t need to spend much time making recovery a little bit easier.  For a user who’s done nothing wrong, they make the barriers to recovery too high – I had the decryption passphrase, and a simple mistake was enough to ruin all my data.  I was on the verge of scrapping the drive, suffering an unexpected data loss (which even regular backups can’t protect against perfectly).

I’ll probably avoid PGP WDE in the future, but whole disk encryption as a concept isn’t going away anytime soon.  It would be good for developers to keep disaster recovery methods in mind when creating their software!

A few months ago I saw a good blog post by Joel Spolsky, where he suggested using a combination of Dropbox and Password Safe as a secure password management tool.  For those unfamiliar with it, Dropbox is an Amazon Cloud-based service that essentially acts as a network-based hard disk that can be synced across multiple machines.  Local copies of files are retained on the user’s machine and changes are synced with the main file server and distributed to the user’s other machines with the Dropbox client installed.

It’s a great tool and I would recommend it to anyone – and when used with Password Safe (install your encrypted password file on the dropbox-synced folder), it’s an effortless and secure method for an individual user to manage their passwords.

In an enterprise level IT environment, however, it’s probably not the best choice.  I can’t think of any responsible administrator who’d consider turning over a password list to an untrusted 3rd party, as anonymous or as encrypted as it may be.  It’s just not worth the risk.

The alternative, then, is to leverage a similar method using more secure means.  Our team uses a NAS device, which is an ideal and cost-effective candidate for similar functionality.  If your IT organization has large-scale production file servers which are regularly backed up and maintaned, that would be an even better candidate.

The missing piece in this suggestion is file synchronization – a killer feature of Dropbox.  There are a few different ways to take handle this – either using one of the many file synchronization tools, or a versioning system such as CVS or Subversion.  The choice is yours, but allowing the user to maintain a local copy of the folder is a critical component – because what happens if the file server goes down and the user forgets a shared password?

A careful security administrator will keep these circumstances in mind and plan for them accordingly.  Don’t be “that guy” who assumes his file servers will be up 100% of the time!  That’s what security is all about – hoping for the best, yet planning for the worst.

On one hand, there are fairly well-established best practices regarding password policies.  Non-dictionary words, 8-15 characters, etc.  SANS has a great (if a little strict) password policy document here which is a great starting point for any security administrator.

On the other hand, users have a hard time remembering complicated passwords, especially ones that are frequently rotated.  A well-enforced password policy won’t let users choose their name, dictionary-based words, or any other ‘easy’ passwords, so the user is stuck with having to remember a complicated acrostic, or a random string of characters.  And what do users tend to do in this situation?  Write down the password.

So, what’s wrong with this practice?  Nothing!  It’s even been advocated by various security gurus for years.  But you need adequate physical controls around the password list.  That’s the rub – in a large IT organization,  how does one protect from users carrying around scraps of paper?  Adding a further layer of complication, what about the case of shared logins and passwords?  The problem can become overwhelming quickly.

In an IT environment where Role-Based Access Controls (RBAC) are implemented, I would be inclined to not explicitly discourage users from writing down their individual passwords – because we’re all pretty good at physically controlling pieces of paper (money, anyone?).  I may encourage the use of a tool such as Password Safe,  but there’s only so much that you can do to control the behavior of the users.

Where common usernames and passwords are shared between many people (a tragic case!), the problem of password management becomes much trickier.  I’ve seen systems with multiple versions of a common password list, with each user having their own copy.  I’ve seen password lists distributed betweeen a dozen users via unencrypted email.  I’ve seen printed sheets of passwords “hidden” underneath the keyboard of a common workstation.  I’ve seen post-it-notes on monitors.  All of these situations are terrible, but in reality, they’re also unavoidable.  The best an administrator control for is to provide adequate physical controls; limiting access to the password lists.  It would take a very highly-motivated attacker to get past a security guard, keycarded doors, and a staff that’s advised to pay attention to unrecognized people in the building – and your security response policy should take into account the situation of a password breach and have plans for rapidly shutting down access and rotating shared passwords.

In summary, there’s only so much that you can do to control the behavior of users, especially when asking them to remember complicated passwords.  I would advocate RBAC authenticating against a common directory server in all possible circumstances, so that a breached username and password can be compartmentalized, protecting against damage.  If that’s not possible, educating the users about controlling access to their passwords, and providing for adequate physical controls is about the best you can do.  And as always, having a response policy that takes into account the circumstances of a password breach is critical.  IT has evolved to the point where users are getting comfortable with the strictness of password policies, but as an administrator or security professional, it’s important to consider the vulnerabilities and to keep in mind the careful balance of usability and security.