Tag: BYOD

02 Oct 2012

BYOD Redux – The Policy Solution (Part 2)

In the previous post, I suggested that because mobile devices (smart phones and PDA’s) were not that functionally different in how they process, transmit, and store information than other mobile computing devices like laptops, a separate policy wasn’t necessary.  Since data security, confidentiality and integrity concerns were the same as other devices, you should be able to simply extend your existing policy to include them.  But in fact the risks are greater, and often more difficult to control, resulting in substantially higher residual risk (risk remaining after the application of controls) than other computing devices.  Because of this, employee-owned mobile devices really represent an exception to your policies as opposed to an extension of them.  And because all policy exceptions must be approved by your Board, perhaps separate policies and procedures are appropriate.

The FFIEC is fairly silent on this topic, but fortunately the NIST is in the process of formulating several pieces of guidance on risk managing BYOD, and it is always useful to see where they are on this issue as very often we’ve seen NIST guidelines make their way into other federal regulations.

NIST Special Publication 800-124 entitled “Guidelines for Managing and Securing Mobile Devices in the Enterprise” is currently in draft status, and is an update to a 2008 document “Guidelines on Cell Phone and PDA Security”.  The updated guidance recognizes the evolution of the technology over the past few years, as well as the unique security challenges inherent in both corporation and employee-owned mobile computing devices.  They advise institutions to implement the following guidelines to improve the security of their mobile devices:

  1. Develop system threat models for mobile devices and the resources that are accessed through the mobile devices.  Recognize that these devices are not the same as your other computing devices.  The threats are not the same and the available controls are not the same, therefore both the probability and the impact of an attack on these devices is likely greater.  Make sure your threat model understands how the device will connect to your network, and what data it will transmit and store.  Data-flow diagrams can be very helpful in this modeling process.
  2. Once the threat is understood, deploy only those devices that offer the minimum threat required given the job requirements of the employee.  This will be one of the biggest challenges for institutions, as many employees will want the latest devices with all the bells and whistles.  Prior to deploying, make sure you have centralized mobile device management that offers the following minimum capabilities:

•  Ability to enforce enterprise security policies, such as user rights and permissions, as well as the ability to report policy violations.
•  Data communication and storage should be encrypted, with the ability to remotely wipe the device.
•  User authentication should be required before the device can access enterprise resources, with incorrect password lockout periods consistent with your other computing devices.
•  Restrict which applications may be installed, and have procedures in place for updating the applications and the operating system.

  1. Have a separate mobile device policy.  The policy should define which types of mobile devices are permitted to access the institution’s resources, the degree of access that mobile devices may have, and how they will be managed.  It should differentiate between institution-owned and employee-owned devices, and be as consistent as possible with your policy for non-mobile devices.
  2. Test the policy initially, and periodically thereafter, to verify management capabilities.  Perform either passive (log review) or active (PEN testing) assessments to confirm that the mobile device policies, procedures and practices are being followed properly.
  3. Secure each device prior to deployment.  This is slightly easier for institution-owned devices, much harder (but arguably more important) for already deployed, employee-owned devices.

I’m sure you can already hear the howls of protest for this last one, but the guidance actually states that for employee-owned (BYOD) devices organizations should recover them, restore them to a known good state, and fully secure them before returning them to their users.

So when it comes to BYOD you basically have two choices; you can properly manage the devices and the risks consistent with your other computing devices, or you can recognize that they represent a deviation from your risk management policies and get Board approval for the exception.  And if you choose to classify them as policy exceptions, you should be prepared to explain the potential impact of the higher risk to the organization, and exactly how the higher risk is justified.

13 Sep 2012

BYOD Redux – The Policy Dilemma (Part 1)

Employee-owned mobile devices are everywhere, and they’re being used for everything from email to document storage and editing.  Proper risk management procedures are defined in your policies, but do you need a separate mobile device policy, or can you simply mention them in the same policy sections that address other portable devices?  Or is there another option you need to consider?  Let’s follow the same risk management process for mobile device deployment as you would to deploy any other new technology:

    1. First, before mobile devices are deployed, a decision is made that they should be considered for implementation because they will somehow further the goals and objectives of the strategic plan.
    2. Next, a cost-benefit analysis is done, and the results should reinforce the decision to implement.
    3. Finally, a risk assessment is conducted that identifies potential risk exposure due to unauthorized disclosure of customer, confidential, or sensitive information.

Since most mobile devices can process, store, and transmit information, this looks very similar to your risk assessment for other portable computing devices like laptops.  (Indeed the FFIEC mentions “…laptops and other mobile devices…” together  in their Information Security Handbook, suggesting the risks are similar.)  Except in this case the risk is magnified by the extreme portability of the devices, the “always-on” and “always-remote” nature of them, and the fact that many more people will use mobile devices than will use laptops.

Once the inherent risk is assessed (most likely higher than your other computing devices), controls are identified to reduce the risk.  Again, since the capabilities are similar, the list of potential administrative and technical controls looks very similar to those on your other computing devices.  Your existing policy probably mandates that there first be a legitimate business reason for the employee to use a portable device.  Once need is established, the employee agrees to a “proper use” policy, i.e.  what is allowed and what isn’t.  Finally, technical controls are applied; 8-10 character complex passwords, encrypted storage, patch management, Anti-virus/Anti-malware software, user rights and permissions restrictions, Active Directory integration, etc.  But even if you’ve followed your risk management procedures to the letter so far, this is where the real challenges begin, because mobile devices simply don’t have the same controls available to them that other portable devices like laptops do.  There are some additional controls available (like remote-wipe capability), but the end result of your risk assessment would most likely be that you have a higher inherent risk and insufficient controls, leading to a higher residual risk.  Under “normal” conditions, this would lead to a decision to NOT deploy mobile devices until risks can be reduced within acceptable levels, right?

And yet they are ubiquitous.

So back to the original question.  I’m not a big believer of writing a new policy to accommodate every new piece of technology you decide to implement unless the technology cannot be accommodated within your existing policy framework.  It is far easier to make a simple policy change by mentioning the new technology, thereby acknowledging that it exists and that it fits within your current policy framework.  But in this case you are not really making a change, you are actually making a policy exception.  You are admitting that the residual risk of BYOD is unacceptably high, but that you are willing to accept the additional risk in return for potential productivity gains.  Since the Board of Directors is responsible for providing “…clear guidance regarding acceptable risk exposure levels…”, and for ensuring that “…appropriate policies, procedures, and practices have been established”, policy exceptions must be approved by the Board as well.   It is your responsibility to make sure they understand exactly what the risks are, and why you feel they are risks worth taking.

Hopefully risk management controls for mobile devices will continue to evolve and mature to the point where they match controls for the other portable devices you currently manage.  But until they do, until they are capable of being risk managed consistent with your existing policies, they (and all policy exceptions) represent an net reduction in your existing security profile.  And you cannot rationalize or justify taking short-cuts just because “everyone else is doing it”…or even worse, “we can’t stop it”.

Next, I’ll discuss possible solutions to this risk management challenge.