I recently participated in the Mobility Seminar series "Enabling the Wireless Enterprise" hosted by Empowered Networks, along with my co-presenters I spoke about the change to an organization's attack surface when they allow mobile devices to access corporate resources. The series was very well attended and the conversations that I had with attendees in the social period following the presentations was very valuable. Living and breathing security everyday I assume that organizations appreciate the risks of mobile devices and are implementing plans to mitigate the risk and testing those plans (and the underlying assumptions the plans make) to ensure the actual resulting security is adequate.

Few people would argue that mobile devices are a passing fad; in fact most people expect the usage of mobile devices to increase. Faced with the choice of either a desktop or heavy laptop vs. a light weight tablet or phone most people would choose the mobile option.  This reality is being proven in the average home – the number of PCs per home is not increasing where as the number of smart devices are.

In fact it is this home usage that is pushing (or dragging?) the corporate adoption rate up. All IT/Security professionals have had experiences with a senior executive who received a tablet as a present turn around and request the ability to access corporate email and other resources on that device. As the number of people requesting the ability to perform part or all of their technical business functions on these devices, businesses have seen a way to offer a benefit that in turn saves the business money. Just like the concept of "hot desking," designed to allow more employees to work from home and reduce the costs of providing desks and other office services to employees, was promoted as allowing an employee to work from home and eliminate the effort of commuting, so BYOD offers a benefit to employees and a savings to the company.

However from a security point of view, BYOD will turn your hair grey pretty quickly. A basic principle of security is to minimize your attack surface and to control everything on your attack surface (or as much as you can). Your attack surface is everything that is accessible from the Internet (where the traditional attacks/danger is), historically that used to be systems directly connected to the Internet (attackers could target your web servers, email servers and the like). Fast forward to email and internet browsers on every user’s machine and suddenly attackers were able to target every user in your organization through phishing attacks and drive-by downloads etc. So we had to secure those machines (Anti-Virus and other end point security suites) and move them to their own network and control the access they had to critical assets- this was easy to do because the business owned the machines and the machines were static – they did not move around and remained connected to a single point on the corporate network. However if you (the business) don’t own these new devices that connect to your network (and any other network they can find) what steps can you take to ensure the risk they expose is acceptable? What rights do you have to enforce a minimal level of security? And when a vulnerability in the mobile OS on an application on the OS is disclosed, how do you enforce that these devices either turn off the vulnerable portion of the phone or apply the patch/upgrade in a timely manner (let alone test that the patch was applied effectively?

But, who is a target? Well, it depends on who you think is targeting you. To simplify things I consider two types of attacks and attackers; scripts and people. Scripts are just that - an automated script that is poking for known issues or weaknesses (missing patches, default passwords or easily-guessable passwords etc.). The key to remember about the script is that they require no effort from the point of view of an attacker, so it requires no effort for them to target you or your employees. However, the scripts are automated, if they don’t find anything they move on until the cycle back around. We should always assume the scripts are probing. A human targeting you is the next level; a human is able to take tiny pieces of information from various tests they do and piece them together to perform the type of multiple-vector attack that can lead to a compromise.

So knowing that, how do you determine how much security is enough? And how do you show you have done enough to be secure? Well, you have to determine two things; what would the cost of a breach be (reporting, cleaning/rebuilding systems, reputation etc.) and what is the likelihood of a human targeting you or your users? You have to assume that automated scripts are being run against your users and systems and you have to ensure that not only do you have defenses but you are testing those defenses – it is only through the exercise of trying to breach your defenses can you truly demonstrate that they are effective (and learn exactly where they are not and improve them).

At this point people often talk to me about the remote wipe capabilities that the phone OS provides them. However remote-wipe is a reactive defense – some trigger has to occur before you issue a remote-wipe. Essentially the owner of the phone has to notify the business that a security event has occurred in order for the remote wipe to be issued. An owner, knowing the remote wipe could destroy their personal data/information/photos, will make every effort to find the device before reporting it lost. Giving an attacker/thief a good 12 hours (conservatively) before the remote-wipe command is issued. And of course, the remote command is only effective if the command reaches the phone. Using a basic Faraday cage,  the attacker has all the time they need.

Given that reactive defenses are the technical equivalent of deciding you will close the barn door whenever you see a horse running away, what are the alternatives? As a security professional I am responsible to measure the risk that the different elements in my organization expose the business to and report that risk to my business. I should report it in a way that the business can understand, and make a business decision on accepting the risk vs. adding more controls to reduce/mitigate the risk to an acceptable level.

I determine the security risk not simply through a paper exercise of comparing the different devices that make up my attack surface to the defensive technologies I have bought (or to the marketing information about the capabilities of the defensive technologies) but through controlled exercises. As Sun Tze said “To know your Enemy, you must become your Enemy” – it is be viewing your systems and the way they are connected to the mobile devices your employees are using that you can best understand how to create a secure infrastructure for those devices. Adding a VPN to mobile devices to access internal networks provides another layer of defense to prevent a stolen or compromised phone from instantly providing an attacker with a channel into your network. Whether you call it self-assessment, red team exercises, risk audit or a good old-fashioned penetration testing, the only way to know if your defenses work is to try and beat them.   A technology is only as good as they way it has been implemented, and to understand how well it will reduce risk in my organization I need to attempt to expose the elements of my network it is defending to risk and measure its response.

We should also never forget the human factor when considering these mobile devices. Few organizations would declare that their employees would never click on a malicious link or open a web site opened (or compromised attacker) – in fact those that would say that probably have fewer employees than I have fingers on my hand. However, I would like to know the percentage of employees that would click and expose me to risk. That would allow me to better calculate the amount of effort I should put into protecting my data on that employees device and how closely I should monitor the access that device has to data/resources inside my network.

Which brings up end user security awareness; users can either be part of the problem and a burden or part of the solution and an asset. When I raise the idea of end users as part of a defensive solution as futile, talk of “you can’t patch stupid” is raised. Well, let’s consider it – I can try and use my user population as an early warning system (my canaries if you will) but also build my defenses in layers and invest in the same alarms that the person who does not believe in my user layer builds. Worst case, I have to wait for those alarms to go off, but best case, a user will report a suspicious email to IT/security and we get a head start on detecting and removing the email borne threat before it is viewed by other users. Providing users a means to help (and expressing gratitude for that help) ensures you are on the same team. At the same time monitoring user behavior to spot deviations from normal behavior can also provide an early alarm that a user’s device may have been compromised.

With BYOD an area of concern is the wide variety of devices that my employees could be using, not just of devices but the versions of software/operating systems running on those devices. Ideally, I would want to restrict that variety to a manageable group – but often explaining the risk to a non-technical executive is not effective. Demonstrating that same risk is – if I hand the executive an iPhone or iPad and have them click on a link in a text or email and show the entire contents of the device being copied to my laptop, I have their attention and proven this is real risk. Once they see that my request that we require BYOD participants to agree to have the latest version to the phone software installed becomes understandable and an easy way to avoid the risk.

In the end, it is all about allowing our organizations to do the work they need to do to stay in business, but in a way that doesn’t expose them to unnecessary risk. By communicating and demonstrating the risk in a way the business can understand, we partner with the business in addressing the risk – and not become the "no" department always trying to turn things off.

Alex Horan

Product Manager - Impact