by Bob Rudis
Part one of Protecting the Road Warriors focused on the virus protection and firewall/IDS/IPS layers of mobile security. Part two completes the discussion and presents ways of providing additional layers of defense to help protect the valuable, mobile data.
Securing the lines of communication
In 1808, the Peninsula War [ref 1] broke out in Europe between France and the combined forces of Britain and Spain. In his book, The Man Who Broke Napolean's Codes [ref 2], Mark Urban relates how the French were concerned about the number of couriers being intercepted and how they used, amongst other strategies, ciphers to encode the messages to prevent their enemies from learning the content of the messages.
When your users are on the road, you also need to take steps to ensure the privacy of the communication since it is extremely easy for someone to capture the network packets as they make their way to and from your internal network. The only way to safeguard this exchange is via some form of data encryption. Fortunately, you have many options to choose from, each with their own challenges and benefits.
SSL/TLS: Application-oriented encryption
If users think of anything when they see the acronym "SSL", it's usually the tiny lock symbol in their browsers, combined with the extra "s" in the "http" URL protocol identifier. Secure Sockets Layer or Transport Layer Security (TLS) [ref 3] provides for encryption of a session, authentication of a server, and optionally client and message authentication. This means that you can encrypt the data transmission and validate that the server and/or client is who each claims to be. SSL/TLS is not limited to browser-based applications, so virtually any application can be secured with SSL, either explicitly or via the use of helper applications such as stunnel [ref 4] or with the use of SSL/TLS helper network appliances.
When considering the use of SSL/TLS for your mobile transmission security, you must take into account a few factors to ensure that you are truly safeguarding the information channel:
Complete application coverage
Fit to be certified
Your organization may already be using digital certificates from your own, internal CA. Starting with Windows 2000, Microsoft has made it fairly easy to setup and maintain your own CA. Other companies also provide tools and services to enable the development of your own internal CA, and there are even open source tools - OpenSSL [ref 5] and SSL Certificates HOWTO [ref 6] - to help you create one (the latter is also an excellent resource on how to secure various common applications such as e-mail).
No matter which route you go, you must make sure that your applications (servers and clients) have the ability to use the certificates you are using. Ask the application vendors which CAs they support inherently and whether they provide a mechanism to include support for internal or new public root CAs. You should also ask if the application supports certificate revocation checks.
Security across the datelines
Locking the windows
SSL/TLS security can be challenging, especially if you do plan on using client certificates to ensure that the user is who he/she says they are. This usually entails using a full-blown public key infrastructure (PKI) [ref 8] implementation and the use (preferably) of hardware tokens to hold the certificates - a daunting task to say the least. One downside to the use of SSL is the extra computing burden placed on both the clients and servers since every transaction has to be encrypted and decrypted. Add-on cards and the use of SSL helper appliances can reduce the overhead of this burden, but at an additional cost.
VPNs: End-to-end security
SSL/TLS security works well if you only have a few applications to secure. If your users require more robust access to your internal resources (i.e. mounting network shares or using applications that cannot be easily SSL/TLS-encrypted) you will most likely need to look at using a Virtual Private Network (VPN). VPNs secure all network traffic between the mobile device and your internal network and can work with the digital certificates in much the same was as the SLL/TLS solution. Users first establish their Internet connections in the traditional ways they are used to then launch a VPN client that facilitates the connection to the VPN gateway(s) on your perimeter. After an authorizing the user, the VPN session is established and the mobile workstation is now virtually on your network.
Microsoft and other operating systems provide native VPN support, but you may discover that your needs are more diverse or demanding, especially if you have multiple perimeter locations and a large number of users. In these circumstances, you may find that VPN appliances are a better fit.
Securing the containers
With the communication lines secured, the last layer to consider is place where the mobile user's data physically resides. This can include (but may not be limited to) laptop hard drives, floppy disks, Zip-drives, CDs and USB-flash memory devices. Most mobile users utilize two or more of these mechanisms to store data, and any one of them has the potential to fall into the wrong hands, if only for a brief period of time. How can you help the user safeguard this stored information?
There are many approaches to mobile storage security, and you may discover that you need multiple tools depending on the situation. Microsoft (along with other OS vendors) has a built-in solution called the Encrypting File System or EFS [ref 9]. EFS is based on public-key encryption (i.e. certificates), can integrate into a PKI-environment and requires the use of NTFS file systems. Individual files can be marked for encryption and folders can be set to have their contents encrypted (i.e. whenever a file is moved to a folder marked for encryption, that file will be encrypted). There are two major benefits of EFS. First, since it is native to the operating system, you do not have to do anything special to the files to access them from applications such as Microsoft Word or Excel. The contents are decrypted and encrypted on-the-fly as they are accessed. Second, there is built-in recovery support in the event that the primary encryption key is unavailable --this may not be a "benefit" depending on your security perspective, but from an administrative viewpoint, this is an invaluable feature.
To make it easy for users to keep their system secure it is recommended that their "My Documents" folder be set for encryption along with whatever folder is pointed to by the TEMP environment variable. The fundamental principle is to set any frequently used storage folder for encryption. It is also highly recommended that print spooling and hibernation files are disabled and that the paging file be marked for deletion upon startup or shutdown so that no information is leaked via these sometimes overlooked avenues.
EFS is not a panacea and does not work in all circumstances. Most popular forms of mobile, removable storage prefer the use of one of the FAT file system types for cross-platform compatibility and storage-medium-friendliness (which is one reason most USB flash drives come FAT formatted). Encrypting files in these situations requires a different tool and there are many standalone and tools that can be used to safeguard data on these types of devices. It is important to find a tool that has integration with your internal CA or PKI environment, has the ability to recover data in the event of personnel loss or failing memory and is easy for your users to work with. You should do a serious evaluation, whether it be a complete request for proposal process or just getting trial software into a lab environment, before committing to the use of any of these tools since it will be a potentially expensive and difficult exercise to switch packages. If you require cross-platform support, then you might want to check out alternatives to EFS as well, since it is a Microsoft-only solution.
Turing our attention back to the Peninsula War, we find that the French commanders were both a tad arrogant and contented in their message exchanges. They continued to rely on the same ciphers and used multiple distribution channels, just in case vital messages were blocked via one of the routes. They were fully convinced that the British would not be able to decode the contents of the messages even if they were captured.
Along comes a nondescript gentleman by the name of George Scovell who, it turns out, had a knack for deciphering codes. It was his work that gave Wellington a huge and decisive victory at the battle of Salamanca, which destroyed the French Army of Portugal.
The moral of that story is to never be complacent with any of the layers of security for your mobile users. No matter what products and vendors you choose, you must:
Creating and managing a mobile security environment will not be easy, but researching your needs, choosing the best solutions for your organization and following solid best practices will reduce the overall risks associated with opening up your borders and help maintain the best security profile possible for both your road warriors and your internal networks.
[ref 2] Urban, Mark. The Man Who Broke Napoleon's Codes. New York: HarperCollins, 2001. 348 pages. ISBN: 006018891X
[ref 3] IETF TLS Working Group, http://www.ietf.org/html.charters/tls-charter.html
[ref 9] EFS Step-by-step, http://www.microsoft.com/windows2000/techinfo/planning/security/efssteps.asp
About the author
View more articles by Bob Rudis on SecurityFocus.
Comments or reprint requests for this article can be sent to the editor.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.