Tip

Employee-owned handhelds: Security and network policy considerations

BlackBerrys, iPhones, Treos, iPods and other network-enabled handheld gadgets are now an essential part of our lives. Almost everyone carries at least one electronic gizmo in their pocket, and many of these devices now provide quick and easy access to wireless networks.

Organizations have taken various positions regarding personally owned network devices. Some provide wireless Internet access to employees and visitors as a convenience, while other companies restrict their networks to corporate systems. Many enterprises struggle with the threat of data breaches that may be caused by the storage, processing and transmission of corporate data on personally owned devices.

In this tip, we'll discuss the security implications of managing smartphones, handhelds and other end-user devices within the enterprise. First, it's important to decide whether to allow the use of any non-corporate devices on your network. While answering this question with a simple "no" may seem like an easy way to resolve the issue, the question deserves more thorough consideration. Allowing personal devices that access the Internet may be a move that increases employee morale. Also, hard-line policies have a way of changing quickly -- especially when the boss is the one who shows up with a new wireless toy!

Requires Free Membership to View

For more information

Are future smartphone attacks inevitable? Some experts are predicting a rise in mobile malware.

Sandra Kay Miller offers advice about expanding antivirus to the mobile enterprise.

Ask Mike Chapple a network security question.
Isolating personally owned devices
The vast majority of personally owned devices will connect to an organization's wireless (rather than wired) network. Enterprises can react by simply adding a different SSID to access points, which will provide an isolated network for personally owned systems. Once this change is implemented, decisions should be made about giving the network completely open access or instead requiring authentication through the use of a "captive portal." Captive portals, often used by hotels and coffee shops, redirect all HTTP requests from unknown clients to a special Web page until users authenticate with valid credentials; upon doing so, they are then granted access to the Internet.

Devices on isolated networks should not have direct access to corporate resources, especially if authentication is not required. If your policy does allow the use of corporate data on personal devices, users on the guest network should be required to connect to your VPN prior to accessing those resources. The goal is to maintain the "untrusted" state of the guest network.

Posture checking with NAC
Many organizations are struggling to find the proper place for network access control technologies in their enterprise security architectures. A guest network, however, is a clear-cut case where system posture verification provides powerful benefits. In fact, it's a great place to run a NAC pilot if an organization is considering an enterprise-wide NAC deployment and wants to test out this complex technology on a limited scale. Before allowing any device to connect to a guest network, enterprises can use NAC to verify that the endpoint meets minimum security standards, including -- at the very least -- having properly configured antivirus and host firewall software.

Use of corporate data
When employers allow personally owned devices to handle corporate data, the security concern transcends a company's buildings and reaches into employee homes, possibly even affecting a worker's productivity. In today's society, it's commonplace for employees to work from home, either to regularly telecommute or simply catch up on email during evening and weekend hours. If you have remote workers who use their personal mobile devices, take the time to clearly spell out the corporate policy on appropriate behavior: what type(s) of data may users process on non-corporate systems and in what manner? If you haven't clearly stated your requirements in this area, it's almost certain that there's a "gray market" of unofficial use in your organization.

Decisions regarding the use of employee-owned devices in the enterprise require balancing security requirements with practical concerns. This balance will vary greatly from one organization to another and requires a combination of careful thought and appropriate security controls.

About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated. He also answers your questions on network security.

This was first published in April 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.