Chapter 6 – End-user device security [updated 2019]

This is Chapter 6 in Tom Olzak's book, "Enterprise Security: A practitioner’s guide."

Chapter 5 is available here: VLAN Network Segmentation and Security- Chapter 5

Chapter 4 is available here:Attack Surface Reduction – Chapter 4

Chapter 3 is available here: Building the Foundation: Architecture Design – Chapter 3

Chapter 2 is available here: Risk Management – Chapter 2

Chapter 1 is available here: Enterprise Security: A practitioner’s guide – Chapter 1

We do not protect just desktops or laptops anymore. End-user device (EUD) security is increasing in scope as user behavior and organizational requirements change. With these changes, our challenges as security practitioners grow exponentially.

In this chapter, I touch on traditional device security, but I focus on protecting smartphones, tablets, and other methods employees use to spread data far and wide.

Today's challenges

Emerging technology, such as smartphones and tablets, is changing the way people interact with each other. It is changing our culture and the way we expect to access information and each other. Employees bring those expectations to the workplace, whether we want them to or not. Mobile devices are "… more than extensions of the computing structure, they are extensions of the user. The way the user intersects with their personal data mirrors the way they want to interact with corporate data" (McAfee & Carnegie Mellon, 2011, para. 1).

While the traditional desktop is still used for homework, home budgets, and other tasks still not widely acceptable on the smaller mobile devices, most communication, surfing, etc. is moving to phones and tablets. This shift is affecting the way employees want to access data, customers, and each other in the workplace. According to an Information Week Analytics survey analysis (Feldman, 2011), organizations are allowing an employee shift from desktops to laptops (45% of respondents) as the primary work computer. Only 47% of respondents continue to see a desktop computer as primary. In addition, 40% of employees responding to the survey use personal mobile devices for business over which their employers have no control. Data is increasingly mobile, and risk management often does not extend outside the organization's network.

Mobile device behavior deviates from management's view of acceptable risk, as managers themselves tend to ignore the smartphone, tablet, and laptop groundswell. They tend to remain stuck in the past, slow to understand how and where sensitive data is used. The results of a recent mobility and security survey indicate five trends (Power, 2011, p. 3):

1. Reliance on mobile devices is already significant and accelerating rapidly
2. Information Technology (IT) is becoming increasingly consumerized as evidenced by the 63% of devices on business networks that are also used for personal activities
3. There is a serious disconnect between policy and reality in the mobile computing environment, making both IT directors and users unhappy
4. Lost and stolen mobile devices are seen as the greatest mobile security concern among consumers and IT professionals
5. Although the need for mitigating mobile security risks and threats is acknowledged, risky behaviors and weak security postures are commonplace

Policy disconnect also includes lack of clear standards controlling what users can do with mobile devices, who decides what data can be mobile and how, and how to protect sensitive information stored on mobile devices. My personal experience in a large organization opened my eyes to how powerful the personal wishes of employees, especially managers, are when trying to secure phones and tablets. Those personal wishes often contradict risk management policies that cover traditional devices and data use.

Finally, desktop users are not immune to societal shifts in technology use. If not closely managed, desktop computers provide platforms for remote intrusion and dispersion of sensitive data to mobile devices. Consequently, they are still an important element of end-user security that is often not properly regulated by policy and process.

Layers of end-user device security

End-user device security (EUDS) consists of several layers, including

• Management Support
• Training and Awareness
• Physical Security
• Logical Access Controls
• Device Configuration
• Physical Port Control
• Patch Management
• Wireless Network Security

Management support

All security begins with management's intent to protect the company's resources and its appetite for risk. However, managing data moving along with myriad mobile devices tends to defy the standards set and accepted by managers and users for desktops, servers, etc. Consequently, our job as security professionals includes demonstrating the elevated risk and unique controls associated with data removed from within the safety of the organization's walls.

Policy

In order to ensure employees behave in expected ways, management must document what is and is not acceptable behavior. This begins with development of reasonable, appropriate, and applicable policies. For example, many organizations have not yet updated their acceptable use policies to reflect use of phones and tablets as mobile storage and computing devices. Remote access and wireless policies might omit the increasing use of employee-owned devices in the workplace and at customer locations. So both writing new policies and making necessary changes to existing policies are necessary.

The basic components of a policy include:

• Purpose… a short statement explaining management's objectives and outcomes. In many cases, purpose includes requirements imposed by local, state, or federal regulations. The policy should also clearly state why it is needed.
• Scope… describes policy application. There are two types of policies: program-level and issue-specific. Program-level policies apply to all activities, systems, and devices across the organization. An organization can apply issue-specific polices to aspects of an activity, system, or device that require different policy constraints than those provided by an applicable program policy.
• Responsibility… describes the point of contact for questions or requests for change, who is responsible for compliance oversight, and who can approve changes.
• Compliance… provides management with recourse when an employee or manager does not comply with the policy. Often, the human resources department (HR) already has disciplinary policies in place that apply to non-compliance with any company policy.

Because you write something down does not mean it is effective. Policy development and ongoing policy maintenance requires participation from both IT and business management. Further, both business and IT subject matter experts (SMEs) should review each policy or policy change to ensure it

• can be implemented,
• can be enforced,
• does not create unreasonable constraints on productivity, and
• is concise and easy to understand.

Security policies form the foundation for your organization's security program.

Security Program

Policies specify expected outcomes; they do not define how to achieve them. That is the role of standards, guidelines, and procedures. A set of policies and its supporting "how" documents comprise an organization's security program. The program is supported with oversight processes, such as testing, auditing, and change management. See Figure 1.

Figure 1: Security Program

Standards

Standards are mandatory actions or rules designed to ensure policy outcomes make it into actual people, process, and technology elements of business operations. For example, a policy might state that all data classified as restricted must be protected as it moves between facilities. A supporting standard could require IPSec encryption across all facility-to-facility network links. Implementing a connection without IPSec would be a policy violation.

Guidelines

Guidelines are more flexible measures to achieve policy compliance. Instead of explicitly requiring IPSec in our example above, a guideline might simply require encryption using acceptable and industry standard tools and techniques. This provides a framework upon which to achieve an outcome while providing IT with the flexibility of selecting the best solution for each connection. Further, guidelines adapt better to business changes, allowing adjustments within the framework provided.

Procedures

Procedures, or processes, are documented step-by-step instructions for achieving a specific outcome. For example, if we want to create a laptop system in compliance with all applicable policies, we build a prototype. During the initial build, test cycle, and application of necessary configuration adjustments, we record all changes to the default operating system and application installs. When the prototype meets our compliance requirements, we use our notes to create a build document used for all future laptop implementations.

Another approach is making a gold image, using the completed prototype, and developing a laptop build process document that includes installation of the image. This takes less time and reduces the risk of human error inherent in following a manual, multi-step process.

Testing

Testing occurs at various points in a EUD's lifecycle: post build, during vulnerability and penetration tests, and as part of a formal change management process. Post-build and change management testing are closely related. Include both in a quality assurance (QA) program that tests all device and software configurations prior to moving them into a production environment. Require sign-off by security, IT engineering teams, and other relevant stakeholders.

Vulnerability and penetration tests, as discussed in Chapters 3 and 4, provide periodic testing of both static and mobile technologies. Further, implementing data loss and data leakage prevention solutions alert an organization when data is moving or being used in unexpected ways. Remember: inspect what you expect.

Audits

Testing provides information about vulnerabilities and anomalous behavior. Audits provide information that measures our success in reaching policy outcomes. For example, we might implement a policy-driven procedure that we believe compels tablet users to use a passcode adhering to specific requirements. An audit of a sample of the tablet population might indicate that 25% of tablet users had circumvented, or ignored, the policy.

Training and awareness

If employees are unaware of them, manager expectations and supporting policies mean little. Security training and ongoing awareness activities help shape and maintain user behavior. See Chapter 4.

Physical security

We dig deep into physical security in Chapter 15. Briefly, lack of effective mobile device physical security is one of biggest EUD risks. Leaving laptops on the backseat of a parked car and leaving a tablet in a taxi are two examples of risks that can cause a security manager significant anxiety. Once a criminal has physical access to a device, only your proactive diligence (see below) can protect your organization.

Logical access controls

EUD logical access controls limit what a user, or someone with the user's credentials, can do with a device or with the organization's data. However, mobile access controls design differs from that of desktops; mobile EUD access should be minimally intrusive and conform to the way mobile users access information and interact with customers.

Local administrator access

The first step when securing EUDs is removal of local administrator access from all business users and most IT staff. Users with local administrator access can reconfigure their systems and turn off unprotected security controls. Further, local administrator access provides attackers and their software agents with a rich security context in which to operate. This is an unnecessary risk.

Some applications require privileged access to run. In cases where the business must have this type of application, investigate what is exactly needed. For example, does the application simply need registry admin access? If so, this is a simple configuration for a EUD image used in a specific department or team. The important guideline to take away is to remove broad local administrator rights by default and give them back sparingly and upon management approval.

Shared accounts

Shared workstations exist in many organizations. On the manufacturing floor, for example, multiple shifts might use a single desktop to enable and track production. However, only approve sharing once a risk assessment is complete.

The biggest problem with sharing usually involves a shared user account and password, but this is not always a problem. In our manufacturing example, the shared computer might only control production and have limited access to a production-tracking database. On the other hand, allowing two accounts payable (AP) clerks to share a single account and password prevents accountability.

Accountability allows us to track who-did-what-and-when. It is critical for audits and forensic reconstruction of events before, during, and after an incident. Accountability relies on each individual having a unique account ID and password. Only under special circumstances should employees share a common account and never allow shared account access to EUDs processing or storing highly sensitive data.

Approaches to EUD access control

What it means to ensure strong access control for desktops and laptops is always a lively discussion between the business and IT. The business overall wants minimum impact on productivity, and management is always looking for the ROI. IT needs a reliable and auditable mechanism that prevents the unauthorized from reaching information assets. The only sure path to success is finding middle ground.

Passwords

Passwords, whether strong or weak, are usually the first control implemented. However, an organization's password policy often requires cyclical password changes and moderately strong passwords. Passwords and password changes are not very good protection when used without enforcing rules like account lockout after three unsuccessful login attempts. Further, requiring password changes results in high help desk costs, which can account for 30% of all calls at a per call cost of $25 or more (Kabay, 2007). There has to be a better way.

First, consider requiring strong passwords that do not change. Users can usually remember a strong password if they do not have to create a new one every 60 days. This should reduce password related help desk calls and improve user productivity. Combine this with a supporting secure EUD configuration, a second authentication factor (if necessary), and physical security.

Two-factor authentication (2FA/TFA) adds an extra layer of security that can help fend off attackers and also make changing one's password frequently less of a priority. However, it is not infallible, and policies need to be in place at an organization in order to confirm that the 2FA policies are secure and consistent across all channels. Click here for some tips and tricks for using two-factor authentication technology.

Multi-factor authentication

For systems needing stronger access methods, use multi-factor authentication (MFA). MFA requires users to use two of the following:

Something they know (password, PIN, etc.)

Something they have (smartcard, RF proximity device, certificate, etc.)

Something they are (fingerprint, face, iris, etc.)

Something users are is measured by biometrics. Chapter 13 describes the various approaches to biometrics and their practical application.

Using two of the three exponentially decreases the probability that an attacker can masquerade as an authorized user. The key term here is probability. No combination of factors can prove with 100% certainty that you are who you say you are. For this reason, secure EUD configurations, physical security, least privilege, separation of duties, and need-to-know are critical mitigating controls.

 

Device configuration

Device configuration should reduce the device's attack surface (Chapter 4), strengthen password protection, enable mobile device tracking, and allow for remote denial of access when a device is lost or stolen.

Strengthen password protection

The best configuration support for password use on desktops and laptops is adhering to the following guidelines:

• Make sure the password is long enough. Use no less than 10 truly random alphanumeric characters (see https://www.grc.com/passwords.htm) for general use and 20 or more for protecting highly sensitive systems and data. A basic user password should have as much entropy as possible but still be remembered, such as a two-factor passphrase (Olzak, 2009).
• Each character set you include in a password increases password strength. The most common character sets are lowercase and uppercase letters, numbers, and symbols.
• Do not allow users to use words found in a dictionary of any language.
• Do not allow use of the account ID as a password.
• Do not allow use of names.
• If your organization requires password changes,
  • Do not allow reuse of the last five passwords
  • Do not allow users to change a password more than once every 24 hours
• Lock an account after three failed login attempts. Create a process to quickly identify accounts that frequently lock. In the case of an ongoing and automated attack, an account might lock within seconds of the help desk unlocking it.
• Strictly enforce policies against account and password sharing.
• For tablets and smartphones, cause the devices to lock or clear all content after a number of incorrect login attempts.
• When possible, use a second authentication factor.

While this list might work well for desk-bound use, mobile users will simply storm your office if you try this with their phones and tablets. Consequently, additional controls must support mobile user demands for easy authentication.

Mobile policy management

The biggest challenge I have encountered with mobile devices is user resistance to strong security. Resistance is usually centered on passcode requirements. In any case, if users can disable security constraints on a phone, tablet, or laptop, they will. Without remotely enforceable policy management, mobile device security is not effective.

The capabilities of mobile device policy management solutions have increased significantly and provide many controls to reduce mobile data risk. An administrator works with business and IT management to define reasonable and appropriate controls. She then uses a policy management solution to translate them into a distributable set of mandatory configurations.

• Passcode enforcement. Almost every mobile policy manager enforces passcode use with administrator-defined strength requirements.
• Certificate requirement. Many mobile devices support device authentication via certificate.
• Maximum failed login attempts. Unlike desktops, attackers usually have physical access to a phone or tablet because of theft or loss. So administrators can cause a device to lock or erase all its data after a certain number of failed login attempts.
• Inactivity timer. Every phone and tablet should require login if not used for 10 to 15 minutes.
• Encrypted configuration files. Some mobile devices encrypt their configuration files by default.
• Reasonable policy refresh interval. Because users will try to circumvent your policies, periodic refresh of security configurations is important.
• Ability to track lost or stolen devices. Tracking devices is optional. Knowing the location of a device is a long way from retrieving it. It might be better to focus on remotely turning lost or stolen devices into bricks.
• Mandatory code signing. If you want to control what software is installed, consider mandatory code signing. As mobile devices become bigger malware targets, this is a good first line of defense.
• Anti-malware and firewalls. Solutions similar to those used on desktops and laptops are available for phones and tablets. They often provide other capabilities, such as data encryption
• Data encryption in native storage or on storage cards.
• Backup. Data loss is a risk if users create and store data on mobile devices. If you do not plan to backup the devices, be sure the business and the users understand it is their responsibility.

An increasing number of products ensure distributed mobile policy enforcement. However, not all devices work with all solutions. If you have no restrictions on personal devices you connect to your network, there will likely be a collection of devices without your policy configured. Consider selecting a policy management solution compatible with a set of devices acceptable to business and IT decision makers. Let the workforce know what devices you support and deny access for all other devices.

Desktop and laptop configuration management

Desktop and laptop risk is managed in much the same way as server risk. It begins by establishing a foundation of trust and reducing the attack surface (see Chapter 4). EUD and server risk begins to diverge when we add the end-user to risk reduction.

Desktops

The best approach to desktop configuration is to create a desktop image for each role in the organization. The image should reflect separation of duties, least privilege, and need-to-know. It should result in a device finding itself on the right VLAN when network-connected. Finally, the image should include all attack surface reduction configurations deemed reasonable and appropriate. For computers running Windows, begin with the recommended security baseline and confirm your attack surface expectations by running the Microsoft Baseline Security Analyzer. For non-windows systems, use a vulnerability scanning solution, such as Nessus (http://mcaf.ee/fa3gj).

Administrators can manage device and user constraints through client policy management solutions (e.g., see http://mcaf.ee/0526f), and in the case of Active Directory environments, group policy objects (Tulloch, 2011). Again, ensuring configurations remain as you set them requires denying users local administrator access. Desktop configuration considerations include

• Requiring that all data storage, including user home folders, remain on the network. This places sensitive files within the trust boundaries set by IT and ensures backup of critical information.

• For desktops where the user must have local admin access, setting the User Account Control (UAC) slider to maximum protection. Review the use of each desktop, and set the strength slider appropriately. See Figure 2.

Figure 2: UAC Slider

• Disabling unwanted third-party cookies, as shown in Figure 3.

Figure 3: Blocking Third-Party Cookies in IE

• Implementing a Web filtering solution or, at the very least, preventing users from disabling browser-based phishing and malicious site protection (e.g., http://mcaf.ee/hu7jb). An example of this functionality is Internet Explorer's SmartScreen Filter.
• Centrally deploying and updating antivirus and host-based firewalls. In addition, consider using host-based IPS when a computer processes, displays, or stores highly sensitive information. Host-based IPS capability often ships with enterprise antivirus solutions.
• Locating computers on appropriate network segments (see Chapter 5) to control access and to prevent potentially compromised desktops from reaching other information resources.
• Using hardware (e.g., certificate) authentication before establishing sessions with internal resources.
• Whitelisting applications. Blacklisting is not very efficient, requiring IT to continuously chase use of new applications. Whitelisting, however, allows only business-defined or known good applications to run on EUDs. Application constraints are possible with third party applications or by using Microsoft's AppLocker, included in some versions of Windows 7 and Windows 8 (Grimes, 2009).

Laptops

Laptop configurations include everything listed for desktops, with two significant differences. The first addition is encryption. When sensitive data is stored on a laptop—including temporary files, swap files, etc.—it is never reasonable to leave local drives unencrypted. In most cases, full disk encryption is the only way to ensure all sensitive data is protected. We take a deeper look at this and other encryption challenges in Chapter 7.

Laptop access control begins with encryption, but requires strong authentication controls. For example, using full disk encryption protected by only a weak password is not usually a good plan. Many laptops today come with a fingerprint scanner or facial recognition software. While not perfect, they can increase the probability that the user sitting at the keyboard is who he says he is. When strong MFA is needed, consider centrally managed biometrics- or smartcard-based MFA.

Physical port control

For our discussion of EUDs, I define port control as managing use of EUD universal serial bus (USB) and other removable storage capabilities. Whether in the office or on the road, sensitive data movement outside of defined trust boundaries is often caused by employees connecting to laptops or desktops. Eliminating use of physical ports or controlling what passes through them is an important part of EUDS.

Physical port control in a Microsoft Windows and Active Directory environment requires no additional products. Group policy objects (GPOs) provide settings that work for many organizations, as shown in Figure 4. For example, you can configure desktop systems to allow USB keyboard use but not USB storage. This is a simple approach that does not make decisions based on the data involved.

Figure 4: GPO Settings for Removable Storage Access, Windows Server 2008

Third-party solutions expand simple allow/disallow settings to include preventing or allowing data copying based on the data's classification. If a user's attempted copy violates rules set by the organization, the copy is blocked, an alert is sent, or both. The cost of implementation is higher for this approach, but data copying is often necessary for mobile users or users working at home. In these cases, simply blocking use of removable storage is not an option. Solutions like Symantec's Enterprise DLP solution help manage this challenge and include data filtering and controls for tablets (Symantec, 2012).

Patch management

How many times can we beat this drum? …as many times as it takes. Patching is the best EUDS defense. Attackers cannot take advantage of vulnerabilities that do not exist. The arguments for not having an aggressive patch management process, including the argument that IT does not have time for testing, are simply attempts to follow bad security practice in order to save resources. In reality, not all patches are critical and not most critical patches do not break systems or networks configured according to best practices.

When is a patch critical?

A patch is critical when a quick risk assessment of the related vulnerability and the path through the organization to reach it shows affected resources at high risk. If the vulnerability exists, and no controls exist to sufficiently mitigate the risk, patching the vulnerability is critical. Otherwise, an existing policy should exist that dictates timelines for applying patches that fall into less risky categories. For example, an organization might rate patch importance on a scale of High, Medium, and Low based on the results of a patch-focused risk assessment. If High, apply the patch to a minimum of 90% of vulnerable systems within 30 days. If Medium, apply the patch to 80 percent of vulnerable systems within 90 days. If low, apply the patch if and when time permits.

The time needed to apply patches is typically filled with testing and change management documentation sign-off. Further, if the vulnerability was discovered before the patch release, temporary compensating controls should already be in place. If not, vulnerabilities with patches in the High category require your immediate attention. Patching is often a permanent solution that replaces temporary compensating controls.

In addition to a patch policy and process, ensure systems are actually patched: including mobile devices. Solutions such as eEye's Retina CS Management product (http://www.eeye.com/products/retina) apply patches to both operating systems and applications. It also reports on the effectiveness of patch rollouts. Work with other IT teams to arrive at an agreement about what level of patching achieves acceptable network protection.

How much patching is enough?

Another common argument against patching I have encountered is that not all systems are patchable, so why try? This mindset assumes that if all systems are not patched, then risk is not mitigated: an untrue belief. For example, risk from automated malware infestations (i.e., worms) significantly drops as the percentage of systems patched increases. This is a concept I relate to herd immunity.

Herd immunity is the point at which a herd of cattle, for example, is essentially immune from infection. The concept also applies to human populations (Edmonds, 2012). The point of group immunity is reached by immunizing a high enough percentage of the target population, 80 to 90 percent, to prevent a widespread outbreak. This concept can also apply to network-attached systems.

Case study

I supported a large organization with 12,000 workstations. It had experienced several widespread business continuity events because of malware infections. The biggest reason was the absence of a patch management process. Patching was done sporadically and subject to the excuses above. When any computer on the network became infected with self-propagating malware, the entire network segment to which it was connected was "diseased" in minutes. In most cases, an entire department or facility was on the same VLAN, causing complete failure of related business processes.

After implementing an aggressive patch management program—based on the High, Medium, and Low policy described in When is a Patch Critical—everything changed. If a worm found its way to an unpatched computer, it was unable to spread beyond one or two other unpatched systems on the same segment. The organization's SIEM quickly identified the infected systems, and IT reimaged them. The event was small, contained, and did not result in business process interruption.

Herd immunity worked well in this organization for two reasons. First, the network was segmented. Segmentation is the best way to contain an attack agent to a small system population. Second, their automated patch management solution, supported by priority testing of critical patches, provided quick patch distribution and daily reporting of patching success. The control population also included laptops. When automated patching failed to reach a high enough percentage of systems, management required IT staff to manually patch affected systems.

There are exceptions to the herd immunity rule. EUDs processing highly sensitive information might require 100% patch compliance. Each organization is unique, and only risk assessments can define what patching success means.

Mobile device patching challenges

Mobile devices are not easily patched. In most cases, we rely on carriers or device vendors to apply patches. This is made worse by the lack of antimalware solutions installed on user-owned technology. Security vendors are beginning to see a market for network access control extended to phones and tablets, but progress is slow. Although Apple iOS and Google Android devices are typically not affected by Windows malware, they might carry user files that present a risk to your network. Finally, risk levels increase when you fail to control who and what connect to EUD physical ports.

You cannot stop the increasing number of these devices connecting to your network, but consider special access constraints. For example, design your network so phones and tablets access VLANs with limited access to the network while providing access to information needed by mobile users. This should be an important consideration during architecture design and while performing periodic risk assessments.

Wireless network security

Mobile user devices usually use one of two methods to connect: Bluetooth or Wi-Fi. Both of these wireless connection technologies are secure enough when properly understood and managed.

Bluetooth

Ericsson first developed Bluetooth technology in 1994. This short-range RF communication solution was standardized under IEEE 802.15.1-2002 (Padgette & Scarfone, 2011). The standard has passed through several updates:

• BT 1.0 (Do not use)
• BT 1.1
• BT 1.2 (Nov 2003)
• BT 2.0+Enhanced Data Rate (EDR) (Nov 2004)
• BT 2.1+EDR (July 2009): According to Padgette and Scarfone, this is quickly becoming the most popular Bluetooth implementation. One of the reasons is its support of simple secure pairing (SSP).
• BT 3.0+HS (April 2009)
• BT 4 Low Energy (LE) (June 2010)

Table 2 lists the key differences between EDR, basic rate (BR), and LE implementations. Because most issues with end-user devices relate to EDR, the rest of this section focuses on BT 2.1.

Table 1: Standards Comparison

Operation

"Bluetooth is an open standard for short-range radio-frequency communication" (Padgette & Scarfone, 2011, p. ES-1). It operates at 2.4835 MHz and uses frequency hopping spread spectrum (FHSS) across 79, 1 MHz channels. In an attempt to hinder eavesdropping and interference from other wireless devices, traffic between devices hops 1600 times per second in a pseudo-random sequence. All this hopping should not make you feel secure; inexpensive devices are available that aggregate the hopping packets and create useful data streams for an eavesdropper.

Piconets and scatternets

Two or more devices connected via Bluetooth form a piconet, an ad hoc network with at least one master and one-to-many slaves. Figure 5 depicts three piconets connected into multiple scatternets. A scatternet results when a slave in one piconet also becomes a master of another. In this example, five laptops are members of Piconet 1 with User A's device as the master. When users B and C connect phones and a PDA to their laptops via Bluetooth, their laptops remain as slaves in Piconet 1 and become masters for Piconets 2 and 3.

Because Bluetooth does not support multi-hop technology, devices on one piconet cannot communicate with devices in other piconets of a common scatternet. EDR piconets support up to seven active slaves and up to 255 inactive slaves.

Figure 5: Piconets in Scatternets (Padgette & Scarfone, 2011, p. 2-7)

Discoverable vs. connectable

A Bluetooth device presents itself to other Bluetooth devices in one of two ways: as discoverable or connectable. A discoverable device monitors for inquiry scans on the physical channel. When another device wishes to connect, it broadcasts an inquiry. Discoverable devices send back their device address, local clock, and other useful characteristics. Without the target device's address and local clock data, an inquiring device cannot establish a physical connection. Devices are connectable when remote devices already have their address and local clock information. The requesting device simply pages the target. Depending on the application, it might be best to force authentication for every connection attempt. However, your users might revolt. Reasonable and appropriate are always good guidelines.

Bluetooth threats

Threat objectives usually fall into one of the following categories:

• Denial of service
• Eavesdropping
• Message modification
• Resource misappropriation

Threats often use common attack vectors, including (Padgette & Scarfone, 2011),

• Bluesnarfing. This attack uses a firmware flaw that should not exist in newer devices. It overcomes any access control efforts and forces a connection.
• Bluejacking. Similar to phishing, the attacker sends unsolicited messages to a Bluetooth-enabled device. Although the messages themselves might not be malicious, the action the victim takes upon receiving the message allows the attacker to move to the next phase of an attack.
• Bluebugging. A flaw in older Bluetooth implementations allows remote devices to gain control of a target and eavesdrop on calls.
• Car whisperer. Researchers have developed a software tool that cracks hands-free Bluetooth car systems. When successful, the attacker can send and receive audio. (If you invent it, they will crack it…)
• Fuzzing. Fuzzing is common across target devices. It consists of throwing malformed packets and other non-standard data at a target to see how it reacts.
• Pairing eavesdropping. Versions of Bluetooth (BT 2 and earlier) using a PIN for pairing, as well as BT 4 LE pairing, are susceptible to eavesdropping attacks. This is another reason to ensure power levels remain low, forcing the attacker to get close and detectable.
• SSP attacks. SSP, or secure simple pairing, uses public key cryptography to establish a connection. It is typically used by BT 2.1 to pair with BT 2.0 or earlier devices. SSP provides no man-in-the-middle defense.

Implementation

We cannot completely prevent the use of Bluetooth in our organizations. It is not reasonable to expect business users and their managers to forego such a useful and convenient technology. However, we can build policies and processes that mitigate the risk. A few basic principles useful when designing Bluetooth policies and controls include

1. Always use the most secure implementation of Bluetooth compatible with the devices involved.
2. Use implementations configured for security mode 3 whenever possible. Security mode 3 enforces authentication during physical link negotiation (underlying RF transport) and before logical link initiation (allows use of services on connected devices). Security mode 3 is supported by both BT 2.1 and BT 3.0; it requires authentication and encryption.
3. If security mode 3 is configured on a device, consider keeping discovery enabled for user convenience. Otherwise, disable it.
4. Be sure all devices are configured to negotiate the lowest operational power level with other devices on a piconet. As power levels decrease, so does the distance at which transmissions are readable. This reduces eavesdropping distance, forcing an attacker to gain close proximity to target devices.

Wi-Fi

In addition to Bluetooth connectivity, ever-present Wi-Fi hotspots provide connectivity to both company and public resources. As the workforce becomes more mobile, connections to hotel, airport, restaurant, and coffee shop wireless networks become more frequent. If not properly managed, public wireless might be the weakest point in your security controls. The next weakest point is likely your internal wireless network.

Public Wi-Fi

Public Wi-Fi is wide-open. Assume everything placed on a hotel network, for example, is available to anyone with the most elementary hacking skills. Further, connected devices without proper attack surface reduction are soft targets: soft targets that can eventually become attack portals into your internal network. Prevention begins with policy; ensure your acceptable use policy includes restrictions on public access, including use of a VPN and host-based firewall.

VPN (Virtual Private Network)

Even if a device is not remotely connected to your network, it should still use a VPN (http://mcaf.ee/c9om7) solution if any sensitive data passes through a public network. Simple VPN solutions exist for many types of devices, encrypting data from the EUD to a remote VPN endpoint. For example, Figure 6 depicts the VPN Express set up instructions for iOS on my iPad. I installed and configured it using the auto setup feature. Regardless of what you implement today, you might continue to rely on the user to turn on VPN on tablets and iPhones when connecting to public wireless: unless you prohibit the practice.

Yes, you can prohibit by company policy users connecting to the Internet with tablets and phones unless they first connect to your network via VPN. With an iPad, for example, installing a certificate for SSL authentication provides the user with transparent VPN initialization when connecting to your network. Further, any Web filtering solutions in place offer protection. With laptops, this approach relies less on human behavior and more on technology.

When configuring laptops, use internally developed or third party applications and policies to force connection to your network via VPN whenever the browser is launched or on startup. Of course, this means removing local admin access and forcing users to use the configuration installed with the laptop image. For more information, see http://mcaf.ee/xm8p7 for one approach using Windows 7 firewall configurations.

Figure 6: VPN Express Setup for iOS

Firewall

Firewalls exist for many popular devices, including Android and iOS tablets and phones. The firewall is the last line of defense between your EUD's attack surface and the hacker in the hotel room down the hall. At least consider firewalls for tablets. It will not be long before they take the place of a large number of laptops for mobile work. I can already bring up a Windows desktop on my iPad and run Microsoft Office applications. Other Windows apps will soon be available. (See http://desktop.onlive.com/.) Again, laptops are easier to protect.

When connecting to a public network, firewall settings should always increase protection. This is something easy to do with my Windows 7 laptop. When my computer connects to a network it has not seen before, Windows asks me if this is a home, work, or public connection. I always choose public in these situations. This helps prevent unwanted guests. However, I am aware of the consequences of not choosing wisely. Users are often in a hurry or just do not care. So you must help them by configuring their computers to always use public firewall settings when not at the office. For Windows 7 devices, consider using group policy to enforce firewall configuration (see http://mcaf.ee/7wngb).

Internal wireless networks

When configuring wireless access in your facilities, there are several approaches to protect your network. However, two of them should not be MAC address filtering and SSID hiding. MAC address filtering is difficult to manage if you have more than a handful of wireless users. More importantly, it is incredibly easy for an attacker to detect authorized addresses and spoof one or all of them to gain access. Further, hiding the network does not help. Turning off the SSID (service set identifier) for your wireless network might delay an attacker for a minute or two, but it will continuously annoy authorized users. Only access controls and encryption protect your data and network.

Access controls

The best access control for wireless local area networks (WLANs) is implementation of the IEEE Std. 802.1x. 802.1x is not just for wireless. It is port-based network access control that requires authentication prior to network access. It consists of a supplicant, an authenticator, and an authentication server. Figure 7 depicts how these components enable network authentication.

Figure 7: 802.1x Operation ("IEEE 802.1x," 2012)

In Step 1, the supplicant (user device) attempts to connect to the network. (In some cases, the supplicant may be specialized software running on the user device to identify it to the network.) Using extensible authentication protocol (EAP) over LAN (EAPOL), an encrypted session is established with the authenticator. All other traffic (e.g., DHCP and HTTP) is blocked. For our purposes, the authenticator is the wireless access point. A certificate may or may not be required, depending on the vendor's implementation of 802.1x. During Step 2, the authenticator relays authentication information from the EUD to a RADIUS server for policy review and user authentication. If authenticated, the device is allowed on the network in Step 3.

802.1x helps prevent unauthorized connections, but it does nothing to protect data passing between the user device and the access point. Once authentication is complete, all data is sent in the clear unless wireless encryption is used.

Encryption

For wireless encryption, there are few choices other than WPA2 (Wi-Fi Protected Access II). All previous encryption methods, such as WEP and WPA, are cracked or inefficient. With WPA2, all data between the access point and the user device is encrypted using AES. WPA2 support requires compliance with IEEE Std. 802.11i. However, human behavior can weaken even WPA2 protection.

One of the requirements for WPA2 use is the initial entry of a passkey by the user. However, a weak passkey is easily cracked and unauthorized access gained. Tools and instructions are easy to find on the Internet (e.g., http://mcaf.ee/h9508). Solution? Build passkeys with the same care you build network passwords. Start by not using dictionary words.

Finally, consider not using WPS (Wi-Fi Protected Setup) on your access points. A serious flaw was discovered and demonstrated in December 2011 (Chauhan, 2012). Since WPS is often on by default, turning it off requires a step in your access point build documentation. If you use access points that do not allow you to turn off WPS, consider replacing them.

Rogue access points

I will close our discussion of wireless security with a quick look at a common user solution to restricted network or wireless access: the rogue access point. Access points are inexpensive and easy to carry in to the office. If you leave unused switch ports connected to production VLANs, it is easy for an employee to plug in and establish unfettered wireless access. However, it just bypassed all your carefully crafted WLAN security controls.

Finding and dealing with rogue access points requires discovery software (e.g., http://mcaf.ee/73bvs) and testing for two conditions:

• Are all discovered access points in the managed access point list?
• Are unlisted access points connected to a secured (non-public) network?

If connected to a public/guest network segment, and the segment is fully isolated from sensitive segments, there is likely no harm done. If connected to a secured segment, remove it immediately. In my opinion, all use of employee network appliance should be strongly discouraged. First, it is an access point, then…

Conclusion

By the time you reach this point, you might start thinking that managing end-user device security is more difficult than managing data center security… and you might be right. The variations in end-user devices, the ways they are used, and the increasing ease with which they are connected, lost, or stolen should be enough to add a few additional gray hairs to the head of any security manager. However, we must persevere.

Ensure a strong acceptable use policy exists. It must clearly state what is and is not allowed practice. Further, it must have management support from the C-level offices to the front-line managers. A good start for your policy is available from the SANS Institute (http://mcaf.ee/ly1mi).

Support the policy with processes and documentation to ensure acceptable attack surface size, data mobility control, policy enforcement on devices, and network access controls. Your employees play a large role in helping augment the still sparse technical controls for tablets and smartphones. Implement mobile device security training and awareness activities. Ensure every mobile device user attends, understands acceptable use, and is aware of sanctions for non-compliance.

Finally, monitor and control the movement of data from the network to mobile devices. Manage desktop ports and allow data storage use only when business requirements prevail. Know where your data is going and where it has been. Again, inspect what you expect.

Sources

Chauhan, S. (2012, January 24). Wi-Fi Security: The Rise and Fall of WPS. Retrieved April 23, 2012, from InfoSec Institute: /wi-fi-security-wps/

Edmonds, M. (2012). What is herd immunity: Vaccination and Herd Immunity. Retrieved April 8, 2012, from Discovery Fit & Health: http://mcaf.ee/u3jrn

Feldman, J. (2011). Trifecta of Change: 2011 End User Device Survey. Survey Results, InformationWeek.

Grimes, R. A. (2009, November 4). Application Whitelisting in Windows 7 and Windows Server 2008 R2. Retrieved April 6, 2012, from InfoWorld: http://mcaf.ee/rqoj7

IEEE 802.1x. (2012). In Wikipedia.org. Retrieved from http://en.wikipedia.org/wiki/IEEE_802.1X

Kabay, M. E. (2007, October 2007). Hidden costs of passwords. Retrieved April 3, 2012, from Network World: http://mcaf.ee/g6tl3

McAfee & Carnegie Mellon. (2011, May 24). McAfee and Carnegie Mellon Report Finds Serious Disconnect Between Businesses and Mobile Users. Retrieved March 28, 2012, from McAfee: http://www.mcafee.com/us/about/news/2011/q2/20110523-01.aspx

Olzak, T. (2009, November 4). Building a Better Mousetrap: Two Factor Passphrases. Retrieved April 4, 2012, from Tom Olzak on Security: http://mcaf.ee/jo6p5

Padgette, J., & Scarfone, K. (2011, September). Guide to Bluetooth Security (Draft), NIST SP 800-121 (Rev. 1). Retrieved April 19, 2012, from National Institute of Standards and Technology: http://csrc.nist.gov/publications/drafts/800-121r1/Draft-SP800-121_Rev1.pdf

Power, R. (2011). Mobility and Security: Dazzling Opportunities, Profound Challenges. Survey Analysis, Carnegie Mellon CyLab & McAfee.

Symantec. (2012). Symantec Data Loss Prevention (DLP) Product Family. Retrieved April 7, 2012, from Symantec Corporation: http://mcaf.ee/0ot2g

Tulloch, M. (2011, September 29). Advanced Group Policy Management (Part 1) - Introduction. Retrieved April 5, 2012, from WindowsNetworking. om: http://mcaf.ee/cgdsw