Mobile devices – Compliance Guru

02 Oct 2012

Hot Topics Tom Hinkel 0 comment

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:

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.
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.

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.
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.
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

Hot Topics Tom Hinkel 0 comment

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:

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.
Next, a cost-benefit analysis is done, and the results should reinforce the decision to implement.
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.

12 Mar 2012

Hot Topics Tom Hinkel 0 comment

Risk Managing BYOD (bring your own device)

Thanks in part to social media, users today often don’t differentiate between work and non-work activities, and they certainly don’t want to have to carry multiple work/non-work devices to keep them connected. As a result, new multi-function, multi-purpose mobile devices are constantly being added to your secure financial institution network…and often in violation of your policies.

Most institutions have an IT Acquisition Policy, or something similar, that defines exactly how (and why) new technology is requested, acquired, implemented and maintained. The scope of the policy extends to all personnel who are approved to use network resources within the institution, and the IT Committee (or equivalent) is usually tasked with making the final purchasing decision. And although older policies may use language like “microcomputers”, and “PC’s”, the policy effectively covers all network connected devices, including the new generation of devices like smartphones and iPads. And managing risk always begins with the acquisition policy…before the devices are acquired.

Your policy may differ in the specific language, but it should contain the following basic elements required of all requests for new technology:

Description of the specific hardware and software requested, along with an estimate of costs (note what type of vendor support is available).
Description of the intended use or need for the item(s).
Description of the cost vs. benefits of acquiring the requested item(s).
Analysis of information security ramifications of requested item(s).
Time frame required for purchase.

Most of these are pretty straightforward to answer, but what about bullet #4? Are you able to apply the same level of information security standards to these multifunctional devices as you are to your PC’s and laptops? Or does convenience trump security? This is where the provisions of your information security policy take over.

The usefulness of these always-on mobile devices is undeniable, and they have really bent the cost/benefit curve, but they have also re-drawn the security profile in many cases. The old adage is that a chain is only as strong as its weakest link, and in today’s IT infrastructure environment these devices are often the weak links in the security chain. So while your users have their feet on the accelerator of new technology adoption, the ISO (and the committee managing information security) needs to have both feet firmly on the brake unless they are willing to declare these devices as an exception to their security policy…which is definitely not recommended.

So how can you effectively manage these devices within the provisions your existing information security program, without compromising your overall security profile? It might be worth reviewing what the FFIEC has to say about security strategy:

Security strategies include prevention, detection, and response, and all three are needed for a comprehensive and robust security framework. Typically, security strategies focus most resources on prevention. Prevention addresses the likelihood of harm. Detection and response are generally used to limit damage once a security breech has occurred. Weaknesses in prevention may be offset by strengths in detection and response.

Regulators expect you to treat all network devices the same, and clearly preventive risk management controls are preferred, but the fact is that many of the same well-established tools and techniques that are used for servers, PC’s and laptops are either not available, or not as mature in the smartphone/iPad world. Traditional tools such as patch management, anti-virus and remote access event log monitoring, and techniques such as multi-factor authentication and least permissions, are difficult if not impossible to apply to these devices. However there are still preventive controls you can, and should, implement.

First of all, only deploy remote devices to approved users (as required by your remote access policy), and require connectivity via approved, secure connections (i.e. 3G/4G, SSL, secure WiFi, etc.). Require both power-on and wake pass codes. Require approval for all applications and utilize some form of patch management (manual or automated) for the operating system and the applications. Encrypt all sensitive data in storage, and utilize anti-virus/ anti-spyware if available.

Because of the unavailability of preventive controls, maintaining your information security profile will likely rest on your compensating detective and corrective controls. Controls are somewhat limited in these areas as well, but include maintaining an up-to-date device inventory, and having tracking and remote wipe capabilities to limit damage if a security breach does occur.

But there is one more very important preventive control you can use, and this one is widely available, mature, and highly effective…employee training. Require your remote device users to undergo initial, and periodic, training on what your policies say they are (and aren’t) allowed to do with their devices. You should still conduct testing of the remote wipe capability, and spot check for unencrypted data and unauthorized applications, but most of all train (and retrain) your employees.

22 Dec 2011

From the Field Tom Hinkel 0 comment

FDIC offers “Insight” on Mobile Banking

Although not considered official supervisory guidance, the most recent FDIC Supervisory Insights newsletter offers an instructive early look into how the agency might examine this emerging electronic banking delivery method in the future. (Before you tune out and decide to wait for the formal guidance, remember it was the Winter 2009 issue that first introduced us to the concept of the Enterprise-wide risk assessment as the preferred replacement for the traditional information security risk assessment. I consider these Supervisory Insight newsletters to be a pretty accurate peek into the regulatory crystal ball.)

The article is titled “Mobile Banking: Rewards and Risks”, and is a fairly deep dive into this relatively new banking service. Mobile banking is defined as the use of a mobile device, commonly a cell phone or tablet computer, to conduct banking activities. The article starts by discussing the current, and estimated future, market for this service, quoting a survey placing the potential adoption of mobile banking at 38 million households by 2015. Clearly, if institutions have not already considered adopting this delivery method, they certainly will in the near future. They separate the mobile service offerings into 3 broad categories based on the delivery method:

Text messaging/short message service (SMS)
Mobile-enabled Internet browser
Mobile applications (apps)

They then discuss the channel-specific mobile banking risks, and this was one of the most interesting parts of the article for me:

A recent study looked at the security of four types of mobile applications – financial services, social networking, productivity, and retail. The study focused on the types of sensitive data that mobile applications store on the device and whether these data were stored securely. Each application was rated “Pass,” “Warn,” or “Fail.” A “Pass” rating means sensitive data are not stored on the device or are encrypted. A “Warning” rating means certain data are stored on the device, but this does not put the user at significant risk of fraud. A “Fail” rating indicates sensitive data, such as account numbers and passwords, are stored on the device in clear text, placing the user at an increased risk of identity theft or other financial fraud.

As you can see, although financial institutions had the highest “pass” rate for mobile applications, they also had uncomfortably high “warn” and “fail” rates. (Also note the extremely high “fail” rates for social networking apps…this only confirms my concerns.) Although they don’t go into great detail on the availability and proper use of controls to mitigate the risks, they do make the point that proper vendor management is key. This is particularly true for community institutions who rely heavily, and almost exclusively, on the built-in controls provided by their product’s vendor.

But they also refer to the updated FFIEC Authentication guidance, stating that it “applies to mobile banking“. This is a bit of a news flash, as the term “mobile banking” is not specifically mentioned anywhere in the updated guidance. In fact this was one of the major criticisms of the update when it was released (although I disagreed). I think it’s clear now that the FFIEC intended for the updated guidance to be broad enough include new and emerging technology, and that we shouldn’t expect a new update every time technology changes. This also means that you should include mobile capabilities in your Electronic Banking risk assessment, as well as the associated controls.

So consider this an early Christmas present from the FDIC, and make sure to incorporate the mobile banking risk management concepts discussed in this article into your electronic banking risk assessment. In summary:

Financial institutions are challenged to ensure their mobile banking service is designed and offered in a secure manner, and customers are made aware of steps they can take to protect the integrity of their mobile banking transactions. (Edit – so does making customers aware mean mobile banking customer training will be a requirement?)

13 Jul 2011

Hot Topics Tom Hinkel 2 Comments

Interpreting The New FFIEC Authentication Guidance – 5 Steps to Compliance

We’ve all now had a couple of weeks to digest the new guidance, and what has emerged is a clearer understanding of what the guidance requires…and what it doesn’t. But before we can begin to formulate the specific compliance requirements, we have to interpret what the guidance is actually saying…and what it isn’t. And along the way I’ll take the liberty of suggesting what it should have required…and what it should have said.

The release consists of 12 pages total, but only a couple of pages are directly relevant to your compliance efforts. Pages 1 and 2 talk about the “why”, and pages 6 through 12 discuss the effectiveness (or ineffectiveness) of various authentication techniques and controls. But beginning on page 3 (“Specific Supervisory Expectations”), through the top of page 6, is where the FFIEC details exactly what they expect from you once compliance is required in January of next year. Since this is the real “meat” of the guidance, let’s take a closer look at what it says, and try to interpret what that means to you and your compliance efforts.

Here are the requirements:

Risk Assessments, conducted…
- …prior to implementing new electronic services
- …anytime “new” information becomes available, defined as:
  - Changes in the internal and external threat environment, i.e. if you become aware of any new threats
  - If your customer base changes, i.e. you take on a higher risk class of customer
  - Changes in the functionality of your electronic banking product, i.e. your vendor increases the capabilities of the product
  - Your fraud experience, i.e. you experience an account takeover or security breach
- …at least every 12 months, if none of the preceding occurs

According to the guidance, your risk assessment must distinguish “high-risk” transactions from “low-risk” transactions. This is not as simple as saying that all retail customers are low-risk, and all commercial customers are high-risk. In fact, the FFIEC defines a “high-risk” transaction as “involving access to customer information or the movement of funds to other parties.” By this definition almost ALL electronic transactions are high-risk! A retail customer with bill-pay would qualify as high-risk because they access customer information (their own), and make payments (move funds) to other parties. So perhaps the way to interpret this is that your risk assessment process should distinguish between “high-risk” and “higher-risk”. This actually makes sense, because the frequency and dollar amounts of the transactions are what should really define risk levels and drive your specific layered controls, which is the next requirement.

Layered Security Programs (also known as “defense-in-depth”)

This concept means that controls should be layered so that gaps or weaknesses in one control (or layer of controls) are compensated for by other controls. Controls are grouped by timing (where they fit into a hierarchy of layers), and also by type. So taken from the top layer down:

Preventive- This is the first layer, the top of the hierarchy, and for good reason…it’s alwaysbest to prevent the problem in the first place. These are by far the most important, and should comprise the majority of your controls. Some examples drawn from the guidance are:
1. Fraud detection and monitoring (automated and manual)
2. Dual customer authorization and control
3. Out-of-Band (OOB) verification of transactions
4. Multi-factor authentication
5. “Positive Pay”, or payee white-lists
6. Transaction restrictions such as time-of-day, dollar volume, and daily volume
7. IP restrictions, or black lists
8. Restricting account administrative activity by the customer
9. Customer education (this was actually listed as a requirement, but it’s really a preventive control)
Detective – Positioned directly below preventive in the hierarchy because detecting a problem is not as optimal as preventing it. However they provide a safety net in the event preventive controls fail. Often a preventive control can also have a detective component to it. For example, control # 2 above can both require dual control, and also report if authentication fails on either login. Same with #4…if payment is blocked because the payee is not “white-listed (or is blocked by IP restrictions as in control #6), the institution can be automatically notified. In fact, most preventive controls also have a detective element to them.
Corrective / Responsive – An important step to make sure the event doesn’t re-occur. This typically involves analyzing the incident and trying to determine what control failed, and at what level of the hierarchy. However, just as many preventive controls can detect, the best controls have the ability to self-respond as well. For example, the same control that requires dual control, and reports on failed login, can also lock the account. In fact, just as before, many preventive controls also have a responsive capability.

To properly demonstrate compliance with the layered security program requirement, you should have controls at each of the three layers. Simply put, higher risk transactions require more controls at each layer.

OK, now that you’ve classified your controls as preventive, detective and corrective (preferably a combination of all three!), you’ll need to determine the control type; overlapping, compensating, or complimentary.

Overlapping controls are simply different controls designed to address the same risk. Sort of a belt-and-suspenders approach, where if one controls misses something, a second (or third, or forth) will catch it. Again, higher risk transactions should have multiple overlapping controls and they should exist at each layer. So you should have overlapping preventive controls, as well as overlapping detective and even corrective controls. The idea is that no single failure of any control at any layer will cause a vulnerability.

Compensating controls are those where one control makes up for a known gap in another control (belt-or-suspenders). This gap may exist either because it is impossible or impractical to implement the preferred control, or because of a known shortcoming in the control. An example might be that you feel transaction restrictions (#5 above) are appropriate for a particular account, but the customer requires 24/7 transaction capability. To compensate for this, you might require that positive pay and IP restrictions be implemented instead.

Complimentary controls are often overlooked (indeed they aren’t mentioned at all in the guidance), but in my experience they are the one of the most effective controls…and the most common control to fail. Complimentary controls (sometimes called “complimentary user controls”) are those that requires action on the part of the customer. For example, the dual authentication control (#2 above) can be very effective IF the customer doesn’t share passwords internally. Similarly, customer education (#8) requires cooperation from the customer to be effective. Given the partnership between the institution and the customer (and recent litigation), I’m surprised there isn’t more discussion about the importance of complimentary controls. (I addressed some of these issues here.)

In summary, demonstrating compliance to the spirit and letter of the guidance is simply a matter of following these 5 steps:

Risk rank your on-line banking activities from higher to lower based on account type (consumer or commercial), and by frequency and dollar amount.
Apply overlapping, compensating and complimentary controls (# 1 – #9 above) in…
…preventive, corrective, and detective layers,…
…commensurate with the risk of the transaction. Higher risk = more controls.
Periodically repeat the process.

Nothing to it, right?! Well not exactly, but hopefully this makes the guidance a bit clearer and easier to follow.

By the way, although I have been somewhat critical of the updated guidance, I don’t share the same criticism of others that the guidance should have gone further and addressed mobile banking, or other emerging technology. Frankly if new guidance was issued every time technology progressed we’d have a couple of updates every year. Instead, focus on the fundamentals of good risk management. After all, there is a good reason why the FFIEC hasn’t had to update their guidance on information security since 2006 (even though the threat landscape has changed dramatically since then)….they got it right the first time!

02 Nov 2010

Hot Topics Tom Hinkel 0 comment

Mobile devices and information security

The key to addressing the risk of mobile devices is to think of them as functionally equivalent to a PC (with all the information security risks therein), PLUS the added risk of mobility. In fact, the FFIEC combines workstations, laptops and hand-held devices together in their Information Security Examination Procedures for the purposes of determining compliance with user equipment security guidelines.

SO if we consider that all these devices should have equivalent security considerations, the information security risk assessment should determine the institutions’ risk exposure regardless of the location of the data:

Processing (in-house or at a third party)
Transit and Transmission
Handling and Storage
Destruction / Disposal

Mobile devices have issues in each of these categories and the institution must identify them, and apply layered controls designed to reduce or eliminate them. For example, processing includes email applications as well as third party apps. Do any of these third-party apps process or have access to customer information? Is the application approval process the same as for in-house applications? What about social networking issues? These are easy to control through the internal network, but almost impossible in a mobile device. How will the device handle authentication, and is a reduced password/PIN acceptable?

Transmission presents a particular challenge for mobile devices, as data can traverse multiple platforms such as cellular and Internet in addition to the local area network. The FFIEC requires that “…policies and procedures address the protections for data that is sent outside the institution.” Encryption is the most common control here.

Handling and storage presents the biggest challenge to mobile devices, and again encryption plus remote wipe capability is key to addressing these risks.

Finally, how are mobile device taken out of service at end-of-life?

These are only a few considerations, but at the end of the process the institution must assess the residual risk and decide if it is acceptable. That shouldn’t mean accepting a higher level of residual risk just because of the difficulty of controlling it, but perhaps a slightly higher level is acceptable if the added productivity of mobile devices justifies it.