One of the latest buzzwords in IT is BYOD (Bring Your Own Device). The topic has been covered in many different places, but this article will focus on how an IT department can attack the issue, even without budget or a top-down mandate.
BYOD is inevitable, given that consumer-grade technology is better, faster, and cheaper than business-grade. Consumers don’t have to wait 3 years for the equipment to depreciate before it can be replaced, so employees can often purchase a personal laptop that’s at least as powerful as their work equipment. Additionally, the latest technological status symbols are highly mobile, highly connected, and highly addictive. Even if current security policy forbids it, users will bring to the office their smartphones, tablets, and occasionally laptops.
What doesn’t work in BYOD
I’ve seen several reactions by businesses to the idea of BYOD. The most common case has been denial: IT simply does not support non-standard equipment. IT engineers can identify if their site fits this pattern by the number of times any given person will ask for iPhone support. If it’s only once, it means that the user found someone else to help them. iPhone users are social by nature, and once one person figures out how to get online, that information will spread virally.
Another method of dealing with the issue is to “stop it before it starts” by locking down the network to allow only company-owned equipment. These environments usually have spent money on NAC (Network Access Control) to prevent unknown devices from connecting, even when plugged into a live port. IT engineers will recognize these companies by one of the following criteria: weekly reports on the number of “foreign” devices on the network, frequent pleading from employees to use their iPhones for email, or the occasional VP declaring that the rules don’t apply to VPs.
Both of these methods share the basic problem of BYOD: employees without access are essentially attackers. They are motivated to get online, and will often spend extra time at work to accomplish this goal. It takes active effort to keep employee-owned devices off the network, and if those devices get on, there is no visibility, control, or remediation if employee devices get hacked. Just like any gray-market solution, options are very limited for support.
Making BYOD work by making BYOD easy
The key to a successful BYOD policy is to enforce user compliance by making it the least painful option. In Robert Louis Stevenson’s book Kidnapped, there is a scene where the heroes are in a room with two doors, about to be attacked by pirates. They lock one door, but leave the other open: “that door, being open, is the best part of my defenses… so long as that door is open and my face to it… my enemies will be in front of me.” (Chapter IX) The basic concept is that, if it is easy for the pirates to attack through the open door, they will congregate there, and be easy for a defender to manage. In BYOD, if there is an easy process for users to get online, they will typically agree to conditions that make it easier for IT to include those employee-owned devices as part of the network defense.
BYOD problems are similar to those of VPN deployment. Employee-owned equipment is used to connect to the corporate network, but only sometimes – meaning that any company data might be beyond the protective reach of corporate security measures. In fact, it’s becoming a best practice to start addressing the BYOD problem by using a VPN. Create a new WiFi SSID, or re-use a “guest” SSID, which is in a subnet in an outbound DMZ.
Access to the internal network is only available via VPN, which leverages the security lessons learned from VPN deployment, as well as any monitoring on inbound VPN connections. That subnet should also have Internet access – assuming that the corporate network does too – so that employees will be willing to use it, rather than trying to bypass what will be seen as an arbitrary restriction. If there is easy access from within the walled garden, users won’t feel the need to break out of it. This creates a single location where all of the BYOD devices will willingly congregate, and where network security and monitoring can be applied. You can extend the protections of the corporate network to these devices, while simultaneously protecting the core network from them.
Detecting existing BYOD
There is still a migration problem with the BYOD DMZ approach: employees who already have their own BYOD solution – who are on the corporate network against policy – are unlikely to change their system settings to use the new “official” method. They likely remember the difficulties of getting online in the first place, and don’t want to go through similar pain, despite assurances that it will be easier this time. That means you’ll have to find those devices and individually ask the users to comply.
The best tool I’ve found for finding rogue BYOD is to use packet-level analysis or network forensics. Remember that BYOD-type devices are built to be highly connected. They perform active discovery of the network, which makes them easy to find. Here are some examples:
- Windows networking uses NetBIOS Name Service, but there is a big difference between Domain (enterprise networks) and Workgroup traffic (SOHO). In a Workgroup environment, PCs are b-nodes and perform NBNS resolution via IP broadcast to the local subnet (e.g. 10.0.255.255, not 255.255.255.255). In a Domain environment, PCs are h-nodes and perform NBNS resolution primarily through the Domain Controller, with fallback to broadcast. Therefore, any device which is acting like a b-node is not part of the Domain.
- Apple devices use Bonjour for zero configuration networking, based around mDNS sent to 224.0.0.251. Bonjour also uses DNS-SD extensions to DNS, which will show up as relatively uncommon DNS record types, such as SRV, TXT, and PTR.
- Linux devices use Avahi for mDNS, with packets that look similar to Bonjour. It’s possible to differentiate between the two by looking at services advertised. HINT: iTunes doesn’t run on Linux.
- Rogue BYOD users may already be using tools designed for access remotely, such as Outlook Web Access and Exchange ActiveSync. If connections to those servers come from internal IP addresses, it’s coming from inside the building.
Further BYOD options
By no means is this a sufficient or comprehensive list of what can be done to address BYOD. NAC can be used to perform a health check before letting devices online, requiring such things as up-to-date antivirus. Exchange ActiveSync has policy settings that can be pushed to mobile clients, such as requiring a PIN or password after idle time. Given enough bandwidth, it may even make sense to re-invent Citrix by rolling out VDI.
Final thoughts on the future of BYOD
The most interesting idea I’ve heard to address BYOD came from one of my customers in January 2011. They viewed BYOD not from a technology perspective, but from a business perspective: if employees own laptops which they prefer to the equipment the company could provide them, it makes financial sense to encourage employees to opt in to BYOD, and opt out of having a company-provided PC.
The cost savings of not maintaining hardware for a significant number of users would then be directed to a network security upgrade, using DPI to identify users regardless of IP address, and apply specific user role network security restrictions even when roaming between different buildings on their campus. Like deperimeterization, it’s an idea which many businesses may not be willing to embrace, but it serves as an interesting example of what can be done by fully embracing BYOD.
Author Profile - Jim MacLeod is a Product Manager at WildPackets. He has been in the networking industry since 1994, and started doing protocol analysis in 1996. His experience includes positions in firewall and VPN setup and policy analysis, log management, Internet filtering, anti-spam, intrusion detection, network monitoring and control, and of course packet sniffing.
Recent Comments