Widespread adoption of bring your own device (BYOD) policies has focused attention on mobile security, but all mobile devices present a security challenge. Attackers continually search for ways to access sensitive data and see mobile devices as a vulnerable point in enterprise defenses.
Mobile devices are difficult to protect simply because they are mobile. They can be lost or stolen or carried into insecure environments. Integrating contextual elements; that is, determining access based on criteria such as device type, location, or whether the device is employee- or enterprise-owned, adds an additional layer of security to existing defenses.
For all its capabilities, contextual security is not a one-size-fits-all solution.
Each organization must create its own mobile access policy before designing its defenses. Does it need to allow remote access at all? If so, to what data and applications do employees need access? In some cases, email access is sufficient. In others, employees need remote access to sensitive data. Should access be limited based on contextual elements such as type of device or location?
Contextual security must be integrated into existing defenses. In many cases, employees have been logging in with home systems or laptops for years, so an existing database contains username/password definitions and other criteria such as employee role and security privileges. This database must be updated to reflect any added contextual elements.
BYOD: Multiple decisions required
Choosing what types of device to allow and whether to permit employee-owned devices has become a critical policy choice. Some IT departments have been forced to create a BYOD policy when they discovered that employees had been using their own devices despite any guidelines on their use.
The decision is not simply a matter of allowing employee-owned devices or not. Here are the issues: Will any type of device be permitted or will employees be required to choose from a list of acceptable devices? Will employees who require access to sensitive data be limited to enterprise-owned devices or to specific devices while others can choose any device but be limited to less sensitive data?
Should the IT department insist on installing mobile device management software on employee-owned devices and if so, how much control will be required? Minimal support may mean choosing an antivirus package that supports a variety of popular devices and installing it on employee devices. At the other extreme, IT could require a complete mobile device management package that configures the device, manages remote updates and controls what apps can be installed. Will employees be given a choice?
Decisions on device type and management packages create other options. An employee might be permitted access when logging in from his own phone because a full management package is installed, but blocked when borrowing someone else's phone despite entering the same username and password. Security software would detect device identity, check it against the management database and permit or deny access on that basis.
Allowing or blocking access is not the only possibility. Policy could dictate that the CFO can access financial data when logging in from his or her own phone, but only permitted to read email when using some other mobile device.
Contextual security policies can be as specific as required
Many options are possible. IT may consider some devices more secure than others and require that certain individuals accept an enterprise-owned phone or choose from among phones considered more secure. In the past, BlackBerry has been considered by many as the only choice for highly secure environments, but that perception has changed in the wake of other vendors improving security features on their products.
The growth of
Don't wait, analyst says
Location and network type are other contextual elements that can factor into access. Policy could use the device's GPS or source IP address to limit access to a geographic area. It could permit access to sensitive data from an employee's home Wi-Fi network, but limit access to less sensitive data from other remote locations.
Other choices may include permitting access via the cellular network but blocking logins from public Wi-Fi hotspots. There have been few cases of man-in-the-middle attacks in which someone generates a powerful signal near a hotspot with a service set identifier (SSID) similar to the hotspot SSID, but those attacks can be very successful in capturing usernames and passwords.
Access based on location can limit connectivity to particular areas within a building. Employees whose phones are logged in while they are walking from the office area toward the company cafeteria could abruptly lose access when context-based security software detects the change in access point. Many policy variations are possible based on individual enterprise requirements and the associated context-based security implemented to enforce them.
For all its capabilities, contextual security is not a one-size-fits-all solution. Each organization must analyze its own requirements and develop its own policy. Importantly, contextual security doesn't replace other security techniques, and it isn't foolproof. It is one more layer of defense against constantly increasingly sophisticated hacker attacks.
About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and has provided consulting services to Fortune 500 companies, as well as software startups.
David Jacobs asks:
Are there enough tools available to support contextual security in your organization?
0 ResponsesJoin the Discussion