Category: Blogs

Traditionally, security threats have taken the form of intentional acts by remote attackers: somebody on the outside working covertly to get to the inside. This is the classic scenario that most people associate with IT security, and it’s what most network operators are best prepared for. But these classic threats are eroding rapidly in the era of ubiquitous mobile devices and users who’ve become accustomed to always-on network access. BYOD is the weakest security link today.

The surge in mobile wireless devices has blurred the line between what is inside and outside the network. Mobile devices such as smartphones and tablets are legitimate, and increasingly indispensable, business tools. Immersed in social media and digital technology, many Millennials treat their mobile devices as extensions of themselves, making it very difficult to separate one from the other. The obvious cost of a policy that prevents users from bringing personal devices to work is impacting the recruitment of new staff, and sometimes depriving existing staff of the tools they need to stay competitive, but the risks are also substantial.

The Technical User

While many fear the untrained user, the worst threats may come from the technically literate user, such as a developer or engineer, who feels he or she simply cannot work without their mobile device and unfettered access to the network. Such a user may not take no for an answer when it comes to bringing in their mobile device, and may even go so far as to employ their own personal hotspot hardware or software to bridge the gap between the protected work network and their unauthorized devices.

No ill will is intended by this act; the user simply thinks s/he knows better. S/he wants to be able to use the devices that make work life easier and knows how to set up an access point to do just that. They don’t realize or just ignore the fact that an access point outside the purview of IT security or ops poses a significant risk to the network as a whole. Without being able to verify the integrity of the hotspot or its configuration, ops can’t be sure if it’s being held to the same security standards as the rest of the network.

While these technical users know how to bypass the system, they may not know how they are leaving their network open and vulnerable. A developer with access to sensitive information, perhaps even branches of source code, may be restricted by the security team from accessing certain portions of the Internet while on the developer network. A technically adept but perhaps not security-conscious developer could attempt to bypass these restrictions by setting up an access point of his or her own – though this may give him or her access, it also gives attackers access to his or her machine. Developers have sensitive information on their laptops that needs to be protected, and connecting to unsecure networks can put this IP at risk. A developer bridging the network using a 4G adapter or access point not only exposes the information on his or her laptop; it also creates a hole that could expose the entire network to infection. Being alerted to these access points is an important step in validating your security controls.

Best Practices: Finding a Balance

The most important steps for creating and implementing a security policy that works both from a security and an efficiency perspective are elaborated below: assess your developers’ needs, set reasonable controls, and validate those controls. Together, they represent a balanced approach to addressing the often conflicting needs of an organization.

1. Assess Your Developers’ Needs 

Preventing developers and technical users from connecting devices to the network, or placing overly restrictive limits on their devices, can inadvertently lead to more security issues than otherwise. With overly restrictive policies, users are more likely to take matters into their own hands and bypass security controls. The best course of action is to engage these users to determine what their work motivations are, and meet them as closely as the overall security and operation of the network will allow. Ideally make the users allies to ops, not adversaries. These developers are knowledge workers, often well compensated, with some degree of entitlement, and cultivating an environment of trust and cooperation is in the best interests of all involved.

2. Set Robust – But Reasonable – Security Controls

This may be stating the obvious, but the most important part of empowering your developers is to mutually set expectations. Properly established security controls are really just agreed-to expectations, laid out in a manner that allows developers to understand what is expected of them and how to appropriately bring up concerns or exceptions. These expectations should be both reasonable and attainable. The most important part of adopting a “bring your own device” (BYOD) policy is to adopt one that meets the needs of the developers while maintaining security and validation. An inappropriately onerous process will encourage users to bypass the process, leading back to an insecure environment with gaping holes in network security. There is a range of tools to consider that can support controls. For example deciding if managed device management (MDM) tools are to be used or not is a major consideration that will drive controls and network access.

3. Validate Controls with Visibility

Security controls are frequently talked about, but less often mentioned is the validation side of the process. You can establish as many controls as you feel necessary, but without visibility into the network, controls are more words than reality. While seeing access points is important to evaluating the risk at your offices, it is only half the battle. The most important thing is finding devices operating on the access point and understanding what access they have to the internal network. With a list of which devices have been attached to the access point in question, it’s a simple process to identify where an offending device is located, and who is responsible for its existence.

Once you’ve found the rogue access point and its operator, it’s time to perform triage. Was the access point connected directly to the business network, or did it get Internet connectivity over the cellular network? If it was on the business network, what kind of access did it have? Was it behind a firewall, or did it expose critical network components such as servers to the outside?

These types of questions will help steer the subsequent investigation and save valuable time. It may end up that the access point posed no direct threat to the business network itself; such as the case of a personal hotspot tied to a cellular modem. In that sort of best-case scenario, the network operations team may simply need to reinforce the rules and regulations of the network, and explain the importance of keeping the network isolated from the outside world.

What Does a Rogue Access Point Make Vulnerable?

While these rising risks have grown with the erosion of classic IT boundaries, your information is still both valuable and vulnerable. Data and Intellectual Property are two of an organization’s most valuable assets; without good security processes, quick development cycles are futile.

About the Author/Paul Paget 

Paul Paget is the Chief Executive Officer of Pwnie Express, provider of end-to-end security assessment solutions. He brings more than 30 years of of leadership experience in technology companies and information security to the company. Follow Paul on Twitter: @pgp2