Taking an architectural approach to BYOD - cisco.com · An architectural approach allows you to be...

Taking an architecturalapproach to BYOD

Featuring research from

2 © 2012 Cisco and/or its affiliates. All rights reserved.

Introduction Taking an architectural approach to BYOD

Contents

2 Introduction from John Newman, Director, Borderless Network Services

4 The challenges of enabling a mobile workspace

6 Architectural approach

8 Architectural vision

9 Developing the technology architecture: conceptual target and current state architectures

11 Conclusion

14 Research from the files of Gartner: “Seven Steps to Planning and Developing a Superior Mobile Device Policy”

The bring-your-own-device (BYOD) trend provokes many reactions from IT and businesspeople. BYOD is often seen as nice to have — as something that allows people to use the corporate network to tweet on their personal smartphone at lunchtime while also allowing them to check their work email over the weekend. The inevitable trend toward device consumerisation has given a lot of people personal computing devices far superior to those now provided by work. People would prefer to have these personal devices for both work and personal use and have the resulting freedom to work more flexibly. This, however, is not generally a justifiable reason to spend a lot of money upgrading corporate infrastructure.

Let’s start by expanding the scope beyond BYOD to secure mobility. By “secure mobility,” I mean enabling employees with smart mobile devices so that they can transparently and securely connect to the corporate network to deliver business value. A real example of this would be an equities salesperson using an iPad when meeting with a high-value client to run through different investment scenarios in real time, when using a laptop would create a physical barrier with the client.

© 2012 Cisco and/or its affiliates. All rights reserved. 3

Introduction Taking an architectural approach to BYOD

For me, this started with multiple requests from customers who had given the senior team iPads, and they simply wanted to connect up reliably to the corporate wireless network. Next, security concerns and worries about allowing smart mobile devices onto the same network as sensitive corporate information and applications started to emerge.

The security concerns were founded on the lack of corporate control over the devices and the likelihood of the leakage of information stored on SD cards or unencrypted internal storage or access to applications from unsecure devices that memorise passwords. These concerns can spread to governance and compliance and can rapidly spiral into a black hole.

Some great technical solutions exist that allow you to transparently control access to individual applications and network resources based on a variety of attributes such as device, connection, and location. Hoorah, I hear you cry, and when you see a vendor demonstrate these systems to you, you will love the control, flexibility, and ease of implementing your new updated information security policies.

This paper from Cisco Services, featuring research from Gartner, presents the importance and benefits of taking an architectural approach when embarking on a BYOD implementation and focuses on the important areas to consider when creating a mobile device policy.

In the first section, “Taking an Architectural Approach to BYOD” Scott Sturgess and John Newman from the Cisco Borderless Network Architecture Practice group present the merits of how taking an architectural approach can significantly reduce the risks and pain involved for a BYOD deployment.

In the second section, Gartner’s “Seven Steps to Planning and Developing a Superior Mobile Device Policy” complements this paper from Cisco Services. It addresses the primary steps and considerations when creating a mobile device policy and provides valuable guidance about strategic planning to illuminate the challenges and risks involved when moving to a BYOD environment.

By taking an architectural approach, combined with a deep understanding of the underlying technology, Cisco Services is uniquely positioned to assist customers in transitioning to a unified workspace environment in which BYOD is a primary component. With end-to-end service offerings and a comprehensive partner ecosystem, Cisco Services has unparalleled experience in transforming an organisation’s infrastructure to meet the very latest mobility requirements and demands, allowing enterprises to maximise the benefits that a well-architected network can bring.


By creating a mobility-conducive environment, companies can optimise mobility experiences in the office, at home, or on the go. Although mobility is now a business imperative, it still remains a massive risk because it affects everything from the device to the data centre. The IT challenges of enabling a truly mobile workspace are significant. For example, how do you:

• Support rich collaboration services on a wide array of mobile devices?

• Rapidly scale virtual desktops without compromising quality of experience?

• Manage the increasing volume, variety, and velocity of data so that the right information can be accessed by the right people?

• Extend access not just to employees, but also to customers, partners, vendors, and suppliers?

• Determine which apps to mobilise?• Effectively manage and secure both personal and

business mobile apps while providing the consumer-like, self-service capabilities that users want?

And for the CIO and senior IT leaders, the challenges extend to showing direct business value as well:

• Align IT with business goals: Assess, plan, and build a unified mobile workspace to make sure of greater IT relevance to the business.

• Mobilise your workforce more quickly: Quickly scale mobility across the enterprise.

• Minimise risk: Reduce risk with a policy-governed unified access infrastructure.

• Maximise the return on your investment: Optimise user experiences and keep operational costs down by improving visibility throughout the architecture.

• Realise significant investment protection: Build on your existing investments to implement architectures that enable rich collaboration on any device, anywhere.

The challenges of enabling a mobile workspace are many, but so are the benefits. By redefining the “traditional workspace” through integrating collaboration, virtualisation, mobility, and video, allowing you to securely open up and expand your network, you can provide transparent, pervasive access to applications and expertise from any device, anywhere (Figure 1).

The challenges of enabling a mobile workspace

Taking an architectural approach to BYODSource: Cisco

Figure 1 Redefining the workspace can deliver integrated mobile access to rich collaboration capabilities


The “cross your fingers and hope for the best” approachThe proliferation of next-generation mobile devices has enterprises scrambling to respond to requests to get these devices onto the wireless LAN (WLAN). Employees want to use their smartphones. Executives are requesting support for tablets. Many enterprises simply have not been able to keep up with these demands, leaving IT departments scrambling to keep things secure while supporting the influx of devices and mobile applications.

Although getting iPads onto the WLAN is not difficult (all you need are a WLAN controller and a security product), this purely tactical approach puts IT in a reactive and defensive mode as one request after another pops up. For users, there are issues with performance, user interface, and access to apps. And for the business, there are challenges with compliance, data security, and management.

Costs and complexity can increase, because the risk of having to redesign and reengineer the network is high if an architectural approach has not been followed.

These challenges undermine the enterprise and personal productivity benefits of BYOD. More importantly, BYOD is really just the tip of the iceberg. Next-generation mobility has the potential to promote new business models, reduce costs, increase agility, and help the business attract and retain top talent.

How to get out of “react” modeAs we know, often enterprises are operating in “react” mode — continually fire-fighting and barely able to get to a situation when they can take a step back to reflect and focus on what is critical for the business to succeed going forward. They just don’t have the time and, more importantly, the resources to plan adequately for the future. This has a huge effect on the infrastructure and also on the business.

This is where architecture plays a primary role. But what exactly do we mean by “architecture” in the BYOD context? Simply put: Architecture is the plan or blueprint that contains all the elements, their relationships, and required capabilities necessary to implement BYOD.

Expanding and enhancing mobility with BYOD in the workplace are complex, but architecture can simplify this by creating structure and order, leading to a complete and compelling vision for the enterprise. It is a vision that does not enforce choice between BYOD and security or settle for virtualised desktops with low-quality voice and video or sacrifice IT visibility and control.

A well-architected network will result in IT benefitting from a simplified infrastructure, one that is easier to support. This allows IT to focus on strategic initiatives and innovation rather than dealing with support requests. The organisation is able to move from “reactive” to “proactive” (Figure 2).

The challenges of enabling a mobile workspace


Figure 2 Strategy and Its relationship to architecture components


Where do you start?Take an architectural approach and architect your entire environment for secure mobility.

According to the 2012 Cisco IBSG Horizons Study of 600 U.S. IT and business leaders, “BYOD is here to stay, and managers are now acknowledging the need for a more holistic approach — one that is scalable and addresses mobility, security, virtualisation, and network policy management — in order to keep management costs in line while simultaneously providing optimal experiences where savings can be realised.”

In its simplest form, an architectural approach is the methodology that contains each required phase that must be executed in a logical sequence in order to transform the infrastructure from its current state to its desired target state. A holistic, architectural approach provides an organising principle, a framework. It gives you a solid foundation on which to build and evolve IT.

An architectural approach allows you to be strategic and helps to ensure that business requirements (rather than technology) promote your mobility initiative. In addition to accelerating time to value, an architectural approach:

• Protects legacy investments• Improves quality of experience• Makes changes to business processes possible• Enhances security, so intellectual property is protected• Allows you to plan for growth and future scalability• Minimises risk

The Cisco Services team has found that without an architectural approach (which includes a strong application strategy), mobility can hinder productivity instead of helping it, negatively affecting TCO.

Architecture is crucial to providing structure and order. BYOD is an enabler for a whole range of services and applications that provide a unified workspace environment, allowing employees or individuals to work in the way that best fits their needs.

The two together are a powerful combination for taking the enterprise to a new level of mobility and productivity.

Because of the complexity of BYOD and its continually evolving landscape, the enterprise is challenged across a wide range of technical, operational, and legal areas. Just as much consideration must be given to the human resources and legal aspects as to the technology aspects. One will not succeed well without the other, even though the nontechnical aspects can be easily overlooked when considering BYOD.

An architectural approach allows the enterprise to consider all elements of a potential BYOD deployment together, not in isolation. When executed correctly, architecture will help ensure that all elements are considered and their interdependencies analysed to understand the overall “cause and effect” — in other words, the effects on BYOD as a whole. This is an iterative, ongoing process to continually refine, improve, and optimise, always making sure of alignment to the business where possible through requirements management.

Architectural approach Taking an architectural approach to BYODSource: Cisco


Architectural methodology: using an aligned enterprise architecture frameworkTo assist in providing solutions to the current IT and CIO challenges that BYOD brings, an architectural approach is essential in developing a “network architectural vision” that aligns the future state target architecture with strategic business goals.

This approach typically follows leading enterprise architecture practices. “Enterprise architecture” is a term used to describe the practice of documenting the elements of business strategy; business case; business model; and supporting technologies, policies, and infrastructures that make up an enterprise.

There are multiple architecture frameworks that describe enterprise architecture. One of the most commonly used is The Open Group Architecture Framework Architecture Development Method (TOGAF ADM), which provides a comprehensive approach to the design, planning, implementation, and governance of an enterprise.

A more “lightweight” approach that is commonly used is a model that is aligned to TOGAF ADM but takes a more

pragmatic view, focusing on the practical phases and elements of the TOGAF ADM.

This lightweight approach predominantly focuses on the following three phases (Figure 3):

1 Creating an architectural vision for BYOD to truly align the network infrastructure with the enterprise’s business requirements.

2 Developing a future state target architecture based on architecture principles combined with the desired future network capabilities. Understanding the current state of the network and the subsequent procedure of analysing the gaps between the current and future state as well as considering the effects on the current operating model and governance required to make sure of a tightly controlled and successful transformation.

3 Sequencing the activities to close the gaps into a prioritised transformation roadmap that considers interdependencies, ease of deployment, and business effects.

Successfully executing each of these phases will make sure that an enterprise is transformed in a structured way, with the end result being an agile, secure, and mobile infrastructure that is fully aligned to the business.

Architectural approach Taking an architectural approach to BYODSource: Cisco

Figure 3 Architectural methodology


Creating the architectural vision: gathering requirements and understanding both the business and IT

The first step is to understand and capture the requirements by identifying the relevant domain stakeholders within the organisation to interview.

Because of the nature of BYOD, the important stakeholders range from staff on the business and IT side who can articulate the business requirements and IT strategy that BYOD hopes to address, or to be part of HR and the legal department in terms of understanding nontechnical policies and corporate compliance. Of course, stakeholders will also include staff from technical subdomains such as infrastructure, applications, security, and end-user devices.

It is always good to try to obtain a viewpoint from an executive stakeholder who has a view of the big picture in terms of the overall company objectives and IT strategy, both critical elements to be considered when deriving a strategy for BYOD. It is equally important at this stage to understand the current and future operating requirements and governance models, because these might well need to change to accommodate a new BYOD deployment.

After the stakeholders have been identified, an interview schedule can be generated and agreed on. Each of the stakeholders can be interviewed independently, or you can

interview them collectively through an interactive workshop. The method you use depends upon the nature of the interview and the availability of the stakeholders.

The goal of the interview process is to gather the information you need for a well-rounded and representative view of the enterprise in relation to the desired future capabilities that will satisfy the business requirements in terms of BYOD objectives. The main BYOD use cases should be identified here. The use cases might range from the basic in terms of guest access to the enhanced, with fully virtualised collaboration services on smartphone devices.

The information you gather at this stage might also make it possible to formulate business cases as input to the architectural vision and to identify target architecture capabilities. Business cases are also invaluable as a way to add weight to and justify the BYOD deployment, showing business value such as reducing costs and increasing productivity.

After the business use cases have been identified and finalised, they can be mapped to best practice technology use cases, if these are available. Typically, the technology use cases would cover (at a high level) the various required layers and technology building blocks for BYOD. In an ideal scenario, the best practice technology use cases map to real solutions that have been validated through end-to-end solution testing, providing a fully working solution that is fit for the purpose and fully aligned with the business.

Architectural vision Taking an architectural approach to BYODSource: Cisco


There might be many different interpretations of conceptual architecture depending on the organisation and model used. Some interpretations might be perceived as a logical architecture, and some might be perceived as a combination of the two. As with BYOD itself, this can mean different things to different people depending on the context and use. However, as long as the overall goal is met, then the conceptual architecture has achieved its purpose.

This is a “living target architecture” that should be periodically reviewed and updated as business requirements evolve and should be maintained in line with network architecture governance practices.

The current state architecture is essentially developing a baseline description of the existing network architecture in relation to supporting the target BYOD architecture. Based on the stakeholder interviews and information gathered, the current state of the existing environment is documented and mapped to a similar architectural format as the conceptual architecture.

The capability gaps can then be identified, quantified, and understood in terms of their interdependencies to each other and overall effects on the business. The resulting initiatives can then be prioritised and sequenced into a roadmap that will be used to transform the infrastructure from its current state to its desired future state.

The purpose of the conceptual target architecture (Figure 4) is to provide a broad-based view of the primary building blocks and component responsibilities to satisfy the business requirements. The conceptual target architecture is used to develop further architectural views at increasing levels of detail.

Figure 4 Example future state target architecture

© 2012 Cisco and/or its affiliates. All rights reserved. Patent pending

Developing the technology architecture: conceptual target and current state architectures



Architectural considerations: more than just the network infrastructureFor an organisation to embrace BYOD, it becomes more than just a matter of adding IT-owned or employee-owned devices to the network. One must also consider the different applications (corporate or personal) that might run on these devices.

For example, will corporate applications be delivered in a native or virtual workspace, which might lead to building a Virtual Desktop Infrastructure (VDI) environment? How will the endpoints and the underlying infrastructure components be managed? How will users and devices be onboarded, and what kind of policies should be applied to them?

These are just some of the considerations that are aligned under the various building blocks of the conceptual architecture.

The architecture draws out the necessary components required to successfully plan, design, and manage a BYOD solution and beyond.

Transformational planning: a prioritised roadmap with technical interdependenciesTransformational planning is concerned with producing a prioritised roadmap that, when executed, will transform the network infrastructure to the desired target state.

The resulting activities from analysing the gaps between the current and future states will form the basis for the transformational roadmap. This analysis will identify the primary activities to be performed and their technical interdependencies in order to migrate to the target state.

The activities will then be grouped into initiatives that are prioritised in terms of business effects and complexity of implementation that become real projects for IT to execute.

The roadmap also provides high-level timelines showing major milestones and, in conjunction with the business requirements and conceptual architecture, builds the basis for strategic decision making.

Developing the technology architecture: conceptual target and current state architectures



It is abundantly clear that the BYOD trend is here to stay, whether enterprises like it or not. Resistance is only delaying the inevitable, although the rate of adoption will almost certainly be governed by an organisation’s individual circumstances.

Taking an architectural approach is essential for success. Enterprises that do not pursue such an approach might well find themselves going through a painful and expensive transition that is fraught with difficulties.

Where the situation dictates, selecting the right partner to assist with the BYOD transformation is an important consideration, drawing on that partner’s invaluable experience to make sure of a smooth implementation.

Cisco Services has the architectural expertise to transform enterprises for BYOD. No other solution provider has such comprehensive skills or depth and breadth of experience across such a wide and varied customer base.

Cisco’s holistic architectural approach maximises value to the business while minimising risk to IT, enabling a truly secure mobility experience for the enterprise.

Conclusion Taking an architectural approach to BYODSource: Cisco


Given the rapid changes in the mobile device market, every organization needs to have a policy in place for use of mobile devices, and must periodically review and update this policy.

OverviewMobile device policies, addressing both business and technical requirements, are essential to define and apply administrative and security practices to the ever-growing assortment of auxiliary IT devices in the hands of users. Historically, many companies took their mobile device policies for granted for four obsolete reasons. First, it was not long ago that a mobile phone was just a phone; but now, they are advanced devices with a wide array of uses and form factors. Second, if employees had BlackBerry devices, then much of their management needs could be satisfied by BlackBerry Enterprise Server. Third, in the past, when the only major mobile request was email, Exchange ActiveSync provided “good enough” basic controls. Fourth, many companies still regard mobile devices as accessories, rather than significant IT systems. Failure to bring the organization’s mobile device policies and security objectives up to date and into alignment poses immediate and serious risks to information security and can jeopardize a company’s ability to meet compliance requirements. Mobile devices are a cost of doing business, and the only way to get superior results is to have a superior mobile device policy.

Key Findings• Legacy remote access policies, often based on PCs, are

obsolete and do not take into account the potential need to administrate and secure business information accessed through contemporary smartphones and tablets.

• In many companies, existing policies are fragmented across different functional groups, organizational entities and business units, making coordination and updating difficult.

• Management and security can be streamlined, but cannot be transparent.

Given the rapid changes in the mobile device market, every organization needs to have a policy in place for use of mobile devices, and must periodically review and update this policy.

Seven Steps to Planning and Developing a Superior Mobile Device Policy

Source: Gartner Research, G00225405, John Girard, 5 October 2011

Recommendations• Gather and assess legacy mobile policies, and personal and

business mobile technology use cases before composing new procedures or selecting new management frameworks.

• Treat company-owned mobile devices as IT assets, affording due care in the manner given to workstations.

• Provide for at least basic monitoring of mobile devices, using Gartner’s Managed Diversity Framework as a guide.

Strategic Planning AssumptionBy 2014, 80% of mobile professionals will use at least two mobile devices to access corporate systems and data, up from 40% today.

AnalysisDevelopment of a superior mobile device policy is described herein by a seven-step exercise in fact-based research to be conducted by end users within their own organizations. This research is written for the mobile policy architect, a person or team responsible for setting mobile device policies. The mobile policy architect is on a mission to quantify the benefit of managing mobile devices as critical company assets.

For the purpose of this research, a mobile device is a smartphone or tablet (see Figure 1) that does not run a workstation OS.

Step 1 — Clear Up MisconceptionsIn many companies, preconceptions and prejudgments about the role of IT in supporting new devices inhibit attempts to update old or create new mobile device policies. Users, as well as legacy stakeholders, become embroiled in arguments over turf and precedent. The following discussion points are frequently raised in Gartner inquiries and need to be aired among stakeholders if progress is to be made on both contemporary and future mobile device policies. The mobile policy architect must take the lead to create understanding on foundational perceptions:




• The legacy workstation policy is rarely suited to mobile devices.

• There is no universal mobile policy template that serves every organization.

• Corporate support for personal mobile devices is unavoidable.

• The liability spotlight is swinging toward mobile devices.

The Legacy Workstation Policy Is Rarely Suited to Mobile DevicesIn many companies, the workstation security and management policy is out of date and needs an overhaul. This should not be seen as an excuse to be sloppy with mobile devices. In many companies, workstation administration functions may be spread across IT operations, security, telecommunications and other teams, and as a result, no one organizational entity is prepared to take full responsibility for life cycle management decisions on completely new classes of devices.

The challenge of managing mobile devices is exacerbated by the speed at which users are demanding mobile device access to mission-critical applications and data. The job of the mobile policy architect is to help the company to have controls in place that anticipate new application and data scenarios. Failure to do this leaves the organization in a hypocritical state that is not auditable.

There Is No Universal Mobile Policy Template That Serves Every OrganizationInterpretations of processes and issues, risks, and obligations are specific to a company’s business context. External reports that promote policy exercises termed as “lightweight, medium, heavyweight,” “trusted versus untrusted,” and so on are valuable, but they must be adapted to contextual needs. Mobile policy architects should review policy examples from multiple sources, make up their own minds when selecting the controls that make sense for their business, and then prepare their own relevant justifications. Real-life policy examples are available from Gartner, from mobile management and security vendors, and from business partners. Examples may also be found through Internet searches.

Corporate Support for Personal Mobile Devices Is UnavoidablePersonal mobile devices are inherently riskier than fully managed company devices. However, Companies with rules against personal devices will eventually be forced to relent, at least under special circumstances, based on our perceptions of user wants and needs. However, risk and management of personal devices can be minimized. Where applications and data will reside on personal devices, companies should set limits on which personal platforms are supported and should be prepared to limit the types of information made

Figure 1. Mobile Device Scope Used in This Research

E ndpoint Devic es

Works tation-C las s Devic e Mobile Devic e

Des ktop S ys tem P ortable S ys tem Tablet P C S martphone Tablet

Examples: iMac, Mac Pro

Desk PC

various makers

Examples: MacBook

Notebook and netbook PCs various makers*

Examples: Acer Iconia

HP Slate

Motion Tablet PC and others*

Examples: BlackBerry

iPhone

Android Phone

Windows Phone Symbian Phone

Examples: Playbook

iPad

Android Tablet various makers

*Includes ruggedized models.Source: Gartner (October 2011)


available to personal devices. They should resolve to require management opt-in as a condition of getting access to sensitive information. Less expensive and less comprehensive management solutions could be selected for personal devices, depending on the amount of access to be granted. If personal devices will not host local applications and data, then simpler and lower-risk access could be offered, such as a Web portals or viewers like Citrix Receiver, and the requirements for management and control could be further relaxed.

The Liability Spotlight Is Swinging Toward Mobile DevicesBreach lists are filled with stories involving laptop/notebook computers, but, through client interaction, Gartner is aware of many unreported or unrecognized security breaches on mobile devices. Companies that do not anticipate the need for management integrity for mobile devices will be first in line for the next wave of embarrassing and costly disclosures and e-discovery orders.

Except for BlackBerry, which is a highly secure mobile device design, these systems are consumer-grade products that emphasize user experience over enterprise-class security, privacy, maintainability and manageability. Models have expired quickly, and older systems may be difficult or impossible to upgrade and inconvenient to erase. Applications are provisioned differently, through methods like mobile device management (MDM) tools, mobile enterprise application platform (MEAP) tools and app stores. Compromises must be made to allow mobile devices to participate as peers in company operations. User expectations drive mobile devices quickly into situations involving data and job functions that were assumed to be the realm of workstations. Companies are challenged not only to manage access from mobile devices, but also to reconcile the use of new, often unsupported applications. Features that may have been considered essential on workstations may not be available on mobile devices, and embedded features are also not standardized across different mobile platforms.

The output of Step 1 will be a moment of enlightenment among business stakeholders regarding mobile device myths, facts and realities. The mobile policy architect can seize the moment to lead frank and open discussions across management levels about the impact of new devices. At the conclusion of this step, the mobile policy architect could be perceived as the leader in possession of factual business concerns, and an important participant in debates regarding the future of mobile devices at the company.



Step 2 — Establish a BaselineTake a Census of Current Policies and PracticesBefore setting off on a new mobile device policy, all previous policies should be located and evaluated to determine points of overlap and conditions requiring updates. A thorough search may turn up all of the following and more:

• Older mobile device policies still in use but possibly out of date

• Workstation policies that make reference to mobile devices• Workgroup-level policies not known to the IT department• HR policies not linked to IT policies• Telecommunication policies that affect the mobile device life

cycle• B2B access and data sharing policies: partners, contractors

and so on• Legacy stakeholders involved in parts of the management

life cycle

While reviewing past and present policies, make note of the following attributes to assist in planning a new mobile device policy:

• The prevailing attitudes toward security and management (supportive, antagonistic or indifferent)

• Which departments/groups/individuals have been most active in developing policies

• Instances of cooperation between policies and authors, and potential champions to back the new policy

• Commonly implemented controls and practices• Instances of agreement about policies• Supporting and related documents and policies that are or

should be cited in mobile device policies

Take an Inventory of Mobile Devices in UseThe scope for a mobile device policy cannot be developed without knowing the initial landscape and the prevailing user expectations. Data required to be gathered at this phase includes:

• Counts of devices in use by platform, OS version, company-owned, personally owned or in the hands of noncompany personnel, such as contractors

• Assessment of data currently passing onto and through mobile devices

• Mobile device applications in use, app ownership and app security profiles

• Mobile device authentication and registration, steps in place to control passwords, lockdown/wipe, and deny access

• All entry paths used by mobile devices, such as cellular, Wi-Fi, bridge to workstation or VPN


Source: Gartner Research, G00225405, John Girard, 5 October 2011Seven Steps to Planning

and Developing a Superior Mobile Device Policy

This inventory information may be difficult to impossible to gather if companies do not have mobile device tools or other reporting methods in place. In a worst-case scenario, the IT department may need to announce cutoff dates for certain types of access and rely on employees to disclose their mobile usage. For example, if a company has allowed Exchange ActiveSync to be used without active enrollment and certificate controls, then a date can be set and publicized, after which, no device gains email access without a certificate. A date can also be set, after which, the email system and the administrator will reset all central and client-level autoforwarding rules by which employees may have been transferring company email to personal accounts.

The output of Step 2 will be a description of mobile devices in use, providing sufficient detail to allow for analysis of IT support costs, legacy security exposures and a complete understanding of the ways that mobile devices have directly and indirectly contributed to, or detracted from, business processes.

Step 3 — Identify and Prioritize Use Cases via Workforce AnalysisTo be effective, mobile device policies must be context-oriented to match the reality of a company’s use cases, not simply built on technological taxonomies. Without context analysis, mobile device policies will solve the wrong problems, if they solve any at all. With context, the mobile policy architect will have the support of the user base. Therefore, the mobile policy architect must talk to the users and document their real and perceived wants and needs. Questions to ask include:

• Where can mobile devices be used? This question must address everything from workspaces to geographies.

• How will mobile devices be used?• What do the users perceive to be necessary for

authentication?• Will mobile devices be assigned to one person or shared

among many?• Which mobile applications would be used online versus

offline?• What information will be accessible through mobile devices?• What information will be stored on the mobile devices?• Will information be shared or copied to, from and between

mobile devices?• Who will own the mobile devices?• Who will be responsible for the mobile devices?• Will personal activities on company devices be permitted?• What levels of support are expected?

• What can the users predict or suggest about the risk of misuse, loss or theft of mobile devices in the context of the use cases discovered?

The output of Step 3 will be a factual account of user wants and needs. These use cases are strongly defensible and will become a foundational point of negotiation when the mobile policy architect ultimately reports the cost/risk/benefit requirements to upper management. By listening to the users and presenting their wants and needs as a step in the policy planning process, the mobile policy architect gains credibility and grassroots support.

Step 4 — Classify Platform Support Using Managed Diversity CriteriaManaged diversity analysis provides the mobile policy architect with a definition of the amount of commitment and support that the company will provide to end users based on job function and mobile device platform. Each commitment relies on what IT can realistically guarantee for service, and plays a direct role in the development of mobile policies. For example, if IT is permitted to select, own and manage a device, then it can be 100% responsible for the highest quality of service, since it knows the profile against which it will deliver applications. If IT is asked to support any device that is presented, without due preparation, commitment or planning, it is highly unlikely that service, quality and security can be guaranteed. IT must indicate to end users that decisions have privileges and consequences; if users cross certain boundaries, these privileges and consequences change, and the mobile policy must reflect those changes.

A key goal of managed diversity is to make consistent the security profile, costs and responsibility for functions like repair and application support. By breaking up the user groups and support level, the mobile policy architect can avoid littering company standards with exceptions and can focus all decisions on a straightforward matrix that enables audits.

The output of Step 4 will be a completed decision matrix that shows which mobile device platforms, in terms of hardware models and OS versions, will be supported in different job roles. Each decision point may be further documented with details about the type of support, as well as the risk factors that contributed to the decision, and the types of applications and data that will be allowed for use (see Figure 2).


Figure 2. Managed Diversity Framework

S upport L evel

Us er G roups

P latform

F ull s upport, 100% IT res pons ibility

A pplianc e

P artial s upport, us er s hares res pons ibility

C onc ierge

100% us er res pons ibility

E xec utive

S ales s taff

Offic e worker

Warehous e worker

… and s o on

*Includes ruggedized models.Source: Gartner (October 2011)



Step 5 — Mobile Technology Assessments, Tool and Service SelectionsMobile management and security product and service vendors can standardize and mitigate a wide range of policy controls across different mobile devices. But the decision as to how far to trust a family of mobile devices (Step 4) should be made first, based on the inherent weaknesses of each platform crossed with information value, user groups and job descriptions. The three most important questions to answer in this step are: (1) How much management investment is enough; (2) how will investments measure up to new platforms, as well as emerging security threats; and (3) what will be the minimum acceptable mobile device policy?

Mobile policy architects should study five categories of mobile management technologies to make their choices:

• MDM software tools. MDM tools are desirable in any situation where mobile device access should be verified and reported for compliance purposes. MDM tools combine a profile and/or agent to be installed on the mobile device with a supervisory server that can be installed and operated in-house or can be provided as cloud-based services. Some companies may choose two tools: one for company systems and full management, and another, typically a cloud service, to provide an enhanced baseline, but with a lower company commitment to keep track of personal devices. MDM has indisputably become the battleground for all efforts to define new and better ways to control policies,

configurations, and security parameters for smartphones and tablets. If a company’s administrative needs and compliance obligations are minimal, email platforms such as Microsoft Exchange ActiveSync or Notes Traveler may provide sufficient minimum controls. Gartner recommends some level of mobile device management investment for any situation where users are given more than minimal kiosk-level access.

• User authentication tools. User authentication is the first line of defense for deciding to grant identity-based access to IT resources. The conditions on which mobile users gain access involve many new task-related and environmental factors. User authentication must be addressed in at least two use cases: login to the device itself, and login to services on the corporate network and in the cloud (“gateway” authentication). Device login authentication is still limited to basic passcode checks, except for BlackBerry, which supports smartcards. However, more-sophisticated choices are available for login to applications and portals. Companies should consider the value of secondary strong authentication for access to the most sensitive data sources.

• Secure Web gateways (SWGs). The SWG is the cloud battleground to defend wireless devices from fraud, malware and leakage. A growing SWG market has emerged to help organizations protect their users, endpoints and information from the risks of the Web. Rather than attempting to run resource-hungry intrusion prevention


systems and signature scans on the mobile devices, SWG vendors can redirect device traffic and perform all scans from a cloud service. Depending on the use cases and dominant requirements, solutions can be found in three market segments: enterprise SWGs, network firewalls and filters, and low-end or specialized mobile device URL-filtering products.

• Application delivery via enterprise app stores. Consumer-based smartphones allow users to install applications at any time. Companies may be unable to reconcile this situation in the near term; however, it is possible to create custom app portals or subscriptions to ensure that users can run applications that are officially endorsed and supported. Depending on use cases and administrative goals, companies may elect to use app distribution tools supplied by the platform vendors, or they may elect to use MDM tools to aggregate the app distribution process for several mobile device platforms.

• MEAP. MEAP vendors trade off application needs, including security and manageability. Mobile policy architects need to coordinate with app developers to ensure that MEAP-based solutions coexist with MDM constraints.

The output of Step 5 will be a formal choice of which and how many management and security tools and services will be needed by the company. Multiple selections may be made depending on the requirements to support categories of users identified in Step 4. The choices in Step 5 will determine how policy statements and underlying procedures are described in Step 6.

Step 6 — Sample Policy Discussion PointsThis outline provides a series of recommended discussion points grouped according to their role in a mobile policy. Sample wording is not provided, because the choice of wording must be specific to a company and its use cases, and should be approved by legal counsel, auditors and regulators as needed.

Tier of Risk: HR and IT Are Responsible

• Device segmentation (platform, appliance and concierge)• Allowed business functions• User authentication requirements:• Local to device• Remote to company portals

• How applications and data will be delivered and app store controls



Boundary of Liability: HR and Legal Are Responsible• Compliance requirements: government, industrial, business

partner, supply chain and customer• Employee signs a code of conduct in exchange for access• External media access and encryption

All Devices: IT Operations, App Developers and Security Are Responsible• Minimum/maximum device level (hardware, firmware and

OS)• Opt-in to company-administered device management• PIN length, retry and time-out rules• Zero-tolerance “no hacking” rule• Certificates for any and all access: email, apps and

networks• Application encryption and cleanup for sensitive data• Loss/theft reporting responsibilities and response

escalations• Acceptance for variations in application fidelity across the

spectrum of devices in use

Personal Devices: IT and Legal Are Responsible• Company may choose to filter sensitive data• Employee must accept company lock/wipe decisions• Company may ask to verify that business data has been

removed, especially if the device is being disposed or exchanged

• Where possible, limit sensitive system access to server sources:• Secure Sockets Layer (SSL) Web portals, Citrix Receiver,

VMware and so on• Require strong authentication to access sensitive data

• Encrypted containers required for local storage of business data

• Kiosk-level or concierge-style “ad hoc” access alternatives

Support/Help Desk: Operations Is Responsible• Self-help wiki, audited by tech support• Limits on supported devices/models• Personal device assistance• Certificate installation and revocation for VPN, email

and Wi-Fi• Lock, wipe and restoration processes• Exceptions — especially for C-level executives

Administrative: IT Operations Is Responsible• Company control of all device enrollments• Reporting requirements for lost, stolen or discarded devices• Network connection control (including Bluetooth and Wi-Fi)


• Synchronization/roaming control• Expense rules and controls for company-paid access plans• Logical and physical device disposal

Contractors and Partners: Business Unit, IT, HR and Legal Are Responsible• Opt-in to company device management may be impossible• Where possible, limit sensitive system access to server

sources:• SSL Web portals, Citrix Receiver and VMware• Require strong authentication

• Encrypted containers required for local storage of business data

• Where possible, local apps must be self-secured• Require code of conduct agreement in the business/partner

contract, and monitor for configuration violations

High-Risk Usage Scenarios: IT Operations, Security and Legal Are Responsible• Examples include travel to high-risk international countries

and mobile devices used in situations that have already been subject to problems involving management and security

• Backup, wipe, reload the device and omitting sensitive information:• Potential data recovery must be considered in the risk

assessment• Invoke stringent email/data loss prevention policies• Limit sensitive system access to servers via VPN• Wipe and rebuild when returning from trips to high-risk

countries

Policy Administration and Updates: IT Operations Are Responsible• Departments/entities responsible for ownership and updates

to mobile device policies• Update and revision schedule/periodicity• Method of notification to employees

Compliance: IT Operations, Security, HR and Legal Are Responsible• Mobile policy monitoring and assessment roles and

responsibilities• Consequences of intentional violation of agreement• Methods of redress in the event that a violation was

unintentional (for example, an employee is not necessarily at fault if the phone was “jailbroken” by a website, rather than by a deliberate action of the employee)

The output of Step 6 will be a defensible and understandable statement of work that lists and justifies the important points to place in the mobile policy, based on factual understanding of business processes. At the conclusion of Step 6, the mobile policy architect has all of the information needed to justify policies even to a skeptical audience, as well as strongly validated business justifications to plan funding for management and security tools and services.

Step 7 — Mobile Policy StructureThis final step provides an outline for the order in which information should be placed in the final policy document. The outline emphasizes readability and is intended to show immediate relevance to the reader.






The order of contents of the document should include, but are not limited to:

• Definitions of mobile device, mobile device policy, mobile device management, affected people and departments

• Responsibilities of the company, employees, contractors and partners

• Scope of control for company and noncompany devices• Specific rules and controls that will be implemented and

tracked, as suggested in Step 6• Consequences of violating rules and controls• Supported use cases and policies that apply to business

process contexts• Reference materials

Recommended style guidelines include:

• Keep the policy document short, ideally no more than a few pages.

• Be careful to use directive words appropriately, such as “must,” “should” and “may.” Standards provide instructions that must be followed. Guidelines provide suggestions that should be considered. Check questions and decision criteria show when a standard or guideline may or may not be applicable.

• Put detailed process discussions and tutorial explanations in appendices or external documents, rather than clutter the body of the document.

• Never duplicate material that belongs in another document, especially involving documents under someone else’s control. Provide clear citations to external documents. Establish a line of communication with all such document owners.

• Avoid ambiguous conditional statements, such as “always this way, except when that way,” and statements based on nested negative tests, such as “if not this way, then not that way.” Lead with positive conditions that are clearly qualified.

• Make absolute statements (“always”) only when the condition is truly absolute.

• Expand acronyms only once, on first use.• Provide a glossary of terms, including a repetition of

acronyms, as the last entry at the end of the document.

Approvals• Require a supervisor to sign the document, along with the

affected employee. This act makes the agreement more substantial in the mind of the employee and affirms the oversight role of the supervisor.

The output of Step 7 will be an easy-to-read and unambiguous policy document using the findings of Step 6. All points raised in the document will be completely documented, with a trail back to the original user’s wants and needs, combined with assessments of the suitability of mobile platforms. Preconceptions, assumptions and other barriers to understanding will have been anticipated and answered in the final policy.


Americas HeadquartersCisco Systems, Inc.San Jose, CA

Asia Pacific HeadquartersCisco Systems (USA) Pte. Ltd.Singapore

Europe HeadquartersCisco Systems International BV Amsterdam,The Netherlands

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco’s trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership

relationship between Cisco and any other company. (1005R)

Taking an architectural approach to BYOD is published by Cisco. Editorial content supplied by Cisco is independent of Gartner analysis. All Gartner research is used with Gartner’s permission, and was originally published as part of Gartner’s syndicated research service available to all entitled Gartner clients. © 2012 Gartner, Inc. and/or its affiliates. All rights reserved. The use of Gartner research in this publication does not indicate Gartner’s endorsement of Client Name’s products and/or strategies. Reproduction or distribution of this publication in any form without Gartner’s prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see “Guiding Principles on Independence and Objectivity” on its website, http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp.

http://www.cisco.com/go/offices

http://www.cisco.com/go/trademarks

http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp

Taking an architectural approach to BYOD - cisco.com · An architectural approach allows you to be...

Documents

Transcript of Taking an architectural approach to BYOD - cisco.com · An architectural approach allows you to be...