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
ref 7
Locking the windows
Browser-based applications are usually considered the easiest to secure since there has been longstanding support for SSL/TLS in most web servers. Going beyond the browser, you need to look at your mobile users' needs and determine what remote services they require access to in order to function on the go. This usually includes access to their e-mail, the ability to transfer files to/from the internal network, send instant messages to co-workers and/or clients and use various corporate applications, some of which may not be browser-based. You need to evaluate each of these components and see whether they support SSL/TLS natively. Many popular e-mail, IM and file transfer applications have inherent support for SSL/TLS. If they do not, you need to determine the cost/benefits of using tools, such as stunnel, to wrap encryption around the application, if that is even possible. Implementing SSL/TLS security requires the use of digital certificates. You need to obtain a digital certificate from a certificate authority (CA) and there are numerous public ones to choose from (rather than single one company out in this article, you can Google for "certificate authority" and research the plethora of CAs available to find the one that best suits your needs). Certain countries have various laws that govern what level of encryption you can and/or must use to secure your communications. Furthermore, the US government also has additional regulations on what level of encryption can be exported to various countries and also dictates what can be used internally. You should choose a CA that allows the creation of multiple types of certificates to ensure compatibility with these regulations and you should also keep abreast of the national and international requirements. A good starting point is Dorothy Denning's Cryptography Project [] page. With SSL/TLS, you may feel safe because you locked the doors, but you need to verify that the insecure back-channels that most of these applications have are turned off. This means testing that https://confidential.example.org/ works but that http://confidential.example.org/ does not. Similarly, you should check that e-mail, instant messaging and other servers also have their non-encrypted channels closed, turned off or blocked by firewalls. You should also monitor your web-based applications and validate they all links and resources are delivered via encrypted, trusted channels.
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.
Evaluating VPNs
When looking at a VPN solution, there are some key factors to consider: can you centrally manage all of the VPN devices? How easy is it to authorize/deauthorize clients, can the VPN devices be deployed in an HA or fault-tolerant configuration? Does the VPN solution support alternative root CAs and an internal PKI solution? Does the VPN client integrate with your ISP software, firewall and virus programs? Can the VPN devices interoperate with other, third-party VPN clients? Is there a mechanism to validate client configurations before allowing access to the internal network? How flexible and robust is the reporting component? How well does it integrate with existing LDAP or Active Directory infrastructures? Does the VPN device allow the creation of policies to restrict access based on the client/user? What is the total number of active connections the VPN device supports? What is the performance hit on the client side from the VPN client? Will the VPN solution work with either side is behind a NAT gateway or a firewall? Is it possible to ensure all other network adapters are disabled while the VPN session is in place? Does the VPN client/server support split-tunneling on a per-application basis to reduce bandwidth consumption on your perimeter network(s)?
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.
Mobile diligence
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:
- Remain vigilant with patching both the operating systems and your layered security products
- Keep your virus software signatures and binaries up-to-date
- Maintain and regularly re-evaluate your firewall rules and apply IDS/IPS updates as they are released
- Ensure your applications are patched against any vulnerabilities found in their encryption components
- Create good policies for digital certificate usage and passphrase selection and choose technologies that enable enforcement and auditing of those policies
- Review logs and alerts from all of your security tools, and
- Continually reinforce the concepts of proper mobile security procedures and practices in your users
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.
|