Security technology and policy go hand-in-hand. Technology is the mechanism by which security can be provided, but without adequate policy guidance and enforcement, you may as well not deploy the technology at all. Users need to understand the enterprise's security policy and understand why it is in place, but voluntary adherence to policy is typically inadequate. Policy enforcement is nearly always required.
Human Factors as Part of Security Policy
Taking human factors into account is an important part of the successful deployment and adoption of a wireless security architecture. Security policies can either drive or impede adoption, depending on the circumstance. The more intrusive a security policy is on users, the more they will attempt to circumvent it, which makes policy enforcement even more important.
Security Policy Elements
This section provides an overview of some of the elements of your organization should consider as part of its security policies.
Passwords and PINs
The first and most basic security measure that an enterprise can take with its wireless solutions is to require users to enter a password or PIN when the device is turned on or after a period of inactivity. (Since many users leave their devices on all the time, AT&T recommends that you implement an inactivity time-out as well.)
Your policy should include how to handle incorrect passwords or PINs. You can either limit the number of attempts before locking or wiping the device or allow the user to keep entering different passwords indefinitely.
- If you allow unlimited attempts, you should also implement a progressively longer waiting period between each entry. This makes it impractical for attackers to use an automated device that rapidly enters a large number of passwords.
- If you limit the number of attempts, you must either kill (lock) the device or wipe (erase) its data.
After entering the correct password, the user will be able to access the device, but you may want to require additional user names and passwords to access certain applications on the device or applications available on the wireless network.
You may also want to require a minimum length for passwords, require numbers or special characters, control how often passwords are changed, and control whether passwords can be reused.
Usability Issues for Passwords and PINs
Long, complex, and frequently changing passwords are more difficult to deal with on a wireless device than on a PC. Entering a difficult user name and password combination on the small keyboard and screen may be difficult, but successfully entering this information using handwriting recognition on a PDA or using the keypad of a cellular phone might be impossible.
Users also become frustrated when they have to traverse many layers of password security. For example, they may have to enter a password to access the device; enter a user name, password, and token to access the VPN; and enter a user name and password for different applications. Passwords become even more frustrating to users when a device time-out or a loss of signal causes the session to end, and the user has to enter them again.
Until better input alternatives become available on mobile devices, you may want to consider supporting users in the following ways as you design your password policies, provided that you adequately protect systems and data in the process:
- Shorten and simplify passwords or use short PlNs, and optimize passwords for the target device's input method.
- Reduce the number of times the user must enter passwords.
- Permit longer idle time before a time-out occurs.
- Allow users to immediately reconnect after a session is interrupted (session persistence, which can be established with a VPN).
When setting and enforcing password policies, be conscious of the fine balance between security and usability.
Perimeter defense is well established in the wired world. Most PCs used in the enterprise employ a firewall and antivirus software, and antispyware has become almost a prevalent at antivirus. With the exception of wireless laptops, these technologies have only recently begun to be available for wireless devices. Intrusion into handheld devices by malicious code or malicious humans is a growing problem. Although there have been few incidents to date, it is only a matter of time until the risk of viruses, spyware, and human attack in the wireless world matches or exceeds that of the wired world. As a result, enterprises need to provide and require firewalls, antivirus software, and antispyware software.
Usability Issues for Perimeter Defense
Ideally, device perimeter defense should be invisible to the user and in the case of PCs, it generally is. On a handheld wireless device with limited memory and processing power, there is the risk that virus scan, firewall, and tools to secure the peripheral ports could consume too much memory and processor power.
Because of these limitations, it is critically important to properly configure virus and spyware scans so that they run during off hours when the user is not trying to use the devices. If device perimeter defense applications are employed and they reduce performance, users will be tempted to disable or remove them. Along with the perimeter defense solution, you may want to deploy policy management tools that prevent users from compromising the device's security.
Beyond securing the most obvious perimeter entry point, the wireless connection, it may also be necessary to secure other points of entry into the wireless device or peripherals on the device that could pose a security risk. Potential entry points include Wi-Fi, Bluetooth, and infrared.
Two possible policies for dealing with these peripheral connectivity ports are to require that these ports be disabled at all times, or that the ports be restricted to access a limited set of "safe" profiles. An example of a safe profile might be the headset profile for Bluetooth. The other peripheral on a device that could pose a security risk is the camera. A growing number of enterprises are setting policies requiring that cell phone cameras be disabled.
Encrypting transport refers to encoding data sent over the wireless network so that it can be read only by the sender and intended recipient. Security policy can range from relying on the encryption provided by the carrier to using an encryption application to requiring a virtual private network.
Usability Issues for Encryption
Encrypting data transport, either with application layer encryption or with an IPSec VPN, can have significant performance implications. Running a standard VPN connection over a wireless connection is problematic even when using a wireless laptop, and it can be even more problematic on a handheld device with limited computing power. Additionally, wireless connections often suffer from high latency, low bandwidth, and instability.
Traditional VPNs optimized for a wired network perform poorly under wireless conditions, which can be very frustrating to the user, especially when he or she is in areas with poor signal coverage. Frequent session drops may occur, requiring the user to reconnect and reauthenticate. Wireless-optimized VPNs with session persistence capability can greatly enhance the user experience. Real-time, transactional, and store-and-forward applications often offer even better perceived performance when they're used with this type of VPN.
An enterprise can also set policies about which applications may be used on the device. Policies can range from having no policy (users can install and use any applications they want) to allowing only a select set of applications that have been authorized by the IT department. Such a policy may also help ensure that the device and service are used only for work activities and prevent user-loaded programs from interfering with mission-critical enterprise applications. Insuring that devices are only used for work purposes is valuable not only as a way of driving productivity but also of avoiding higher wireless data charges. Additionally, wireless devices have limited storage capacity, so it may be necessary to limit applications on the device simply because of space constraints.
Usability Issues for Application Control
In general, restricting which applications are allowed on the device will affect only the most tech-savvy users who have other applications they'd like to install. One solution is to implement application control policies that vary by user group. For example, very strict application controls could be implemented for field service workers, while less strict controls could be implement for executives.
Device disposal is how the enterprise handles a device when it reaches the end of its life. The average useful life of a mobile device is 2—3 years, about the same as a laptop. Make sure to remove any sensitive data that may have been left on the device before disposing of it. The device's local data store presents serious security risks. As a device is taken out of service, it should be completely reset or remotely wiped.
Usability Issues for Device Disposal
Device disposal policies typically do not cause users any inconvenience. However, enforcement mechanisms are still required because the typical user only changes devices every 2—3 years and may not remember to wipe the device. A remote kill technology is an effective enforcement mechanism for this policy.
Removable media is ideal for moving files between devices, such as between a mobile device and a laptop, but it also presents a serious security risk. One possible security policy is to disable removable media, which solves the security problem, but may reduce the utility of the device. The second option is to require all removable media to be encrypted, making it unreadable to anyone except the owner.
Usability Issues for Removable Media
A removable media policy has the potential to inconvenience users, especially if they are accustomed to moving information between devices. A policy that disables the device's removable media functionality might cause dissatisfaction and resistance among the user community. Implementing a removable media encryption policy instead would be a more acceptable alternative to these users, though they still would not be able to use removable media as freely as they had previously.
An often-overlooked security issue is the problem of rogue devices. Rogue devices are any devices that the user connects to the enterprise network without authorization. This is often a greater problem for enterprises that have not yet deployed wireless solutions. For example, it is very easy and inexpensive for users to buy and install a VPN client on a laptop and use their VPN credentials to access the network. These rogue devices present an especially serious threat to security. Rogue devices are not subject to the same security policies and practices as an authorized device, and they are consequently more easily compromised, offering an attacker access to the contents of the device or possibly even the enterprise network. Unsecured rogue devices may also pass viruses and other malicious code to enterprise servers.
Even an enterprise that has no authorized devices on its network needs a security policy and security tools to prevent rogue access. A policy prohibiting and blocking rogue devices does not prevent users from using their own devices to access company data, but it does require that they submit their devices to enterprise security policy before being granted access.
Device Ownership Issues
Proper device security may depend on the enterprise owning all devices and paying for all wireless service. If the user owns the device or pays for service, it is much more difficult for the enterprise to successfully mandate security policies and install applications that subject users to monitoring and enforcement. Users may choose to forgo mobile access rather than submit their personal device to enterprise scrutiny and control.
Mobile Access Control
Mobile Access Control restricts which applications may (or must) be present on the device and what device resources and data stores these applications may access. The policy may differ for laptops and mobile devices. Handheld devices are more easily lost or stolen than a laptop, so the enterprise may want to limit the access of these devices to a subset of enterprise data.
Security certificates are a particularly successful access control mechanism. To reduce the risk of being exposed to malicious code, an enterprise can require that every application have a certification from a recognized certificate authority before the application can access device resources such as the local data store or the transmitter.
Device Kill Policy
Device kill policy governs the circumstances under which a device will be remotely disabled and its contents deleted. The most common policy is to wipe the device if it is lost or stolen. Additional policies could call for wiping the device when an employee leaves the company, or wiping the devices after some predetermined period of inactivity.
Usability Issues for Device Kill Policies
The key to a successful device kill policy is to make sure that devices are wiped before they fall into the wrong hands and to make sure they aren't wiped inadvertently. Accidental wiping is a major inconvenience for the user. Locking the device is less intrusive than wiping and makes recovery easier, but it provides less security. Wiping the device provides high security, but can be very inconvenient for someone who works away from the office. One way to minimize the inconvenience of a device wipe is to provide device-restore capability so that the user can easily move data from the original device to a replacement.