GETTING STARTED WITH IDENTITY AND ACCESS MANAGEMENT

IBM Security Systems Identity and Access Management May 23, 2013 GETTING STARTED WITH IDENTITY AND ACCESS MANAGEMENT FOR CLOUD SECURITY Version 1.0 by Shane Weeden Archit Lohokare

P a g e 2 Table of Contents 1 Executive Summary... 3 2 Introduction to identity and access management for cloud security... 4 3 Business Scenarios and IBM Solutions... 5 3.1 IAM for the Cloud: Adopting Software as a Service (SaaS)... 5 3.1.1 Identity Provisioning to SaaS... 6 3.2 Single sign-on to SaaS... 7 3.3 Identity and access management from the cloud (BC2): The trend toward BYO-identity... 8 3.3.1 Implementing BYO-ID with IBM solutions... 10 3.4 The API-enabled business (B2B, mobile)... 11 3.4.1 A typical delegated access scenario... 11 3.4.2 Implementing an API-enabled business with IBM Security Solutions... 13 3.5 In the cloud: Identity and access management as a service... 13 4 Summary... 15 5 For more information... 15 Notices... 16

P a g e 3 Getting started with IAM for cloud security 1 Executive Summary As cloud adoption becomes more of a business imperative, and security for cloud scenarios is seen as one of the major inhibitors many IT administrators are finding themselves asking the question, "Where do I start with cloud security?" The intent of this document is to outline a few key, simple scenarios for identity and access management in the cloud that provide valuable, non-intrusive user experiences for application authentication and authorization. After reading this document you will understand these simple adoption patterns and appreciate the value they will provide to your business and your users.

P a g e 4 2 Introduction to identity and access management for cloud security Identity and access management (IAM) traditionally was the domain of IT administrators for enterprise systems and internet-facing websites. Whether in a business-to-consumer (B2C) or business-to-employee (B2E) context, systems and processes were established to: On-board users. Provision them to one or more target systems that are controlled by the enterprise. Manage user access to various applications, computers, and networks. The megatrend of cloud computing and online identities changed how companies do business. You can no longer assume that: The enterprise can manage the entire lifecycle of a user account, particularly for B2C. All business partner relationships are statically defined and established with tight contractual boundaries for business-to-business (B2B). There are several cloud adoption models: private cloud in the enterprise, hybrid cloud with a mix of on and off-premise deployment, or public cloud. All these models have a set of common issues that are related to identity and access management. Employees and customers frequently have one or more online identities before they come to your organization. These identities might be associated with Their mobile/telco provider. A large online identity provider that includes social networks. Another employer. Another organization. The issuer of these identities might not be an organization that you know or trust. There is a growing expectation that these identities are usable in the workplace and marketplace. They might be used either directly as a means of authentication or as a way to fast-track selfregistration attribute collection. Making access easy with a familiar, fast, and secure user experience is the key to attaining and retaining new customers. Online companies also changed their outward facing interfaces from purely browser-based websites to completely API-enabled businesses. This trend largely began with social networking and search engine companies, but it is no longer the case. By looking at catalogues of API-enabled sites 1, you can see that loosely coupled API-based business relationships, which incorporate the end user in trust establishment, are more prevalent in several business scenarios. IBM is aware of these trends. It constantly explores new business scenarios and adoption patterns to ensure that products and services align with industry and customer expectations. This whitepaper 1 One example of such a catalogue can be found at www.programmableweb.com

P a g e 5 describes some of the most common business scenarios for identity and access management for cloud security. It also provides specific guidance on how to get started. For information about cloud security, including products and services beyond identity and access management across cloud adoption patterns, visit http://www.ibm.com/security/cloud-security.html. 3 Business Scenarios and IBM Solutions Four common business scenarios relate to cloud deployments in which identity and access management are key considerations. Each scenario includes a high-level overview on how IBM solutions can realize this scenario. It provides references to more details if applicable. 3.1 IAM for the Cloud: Adopting Software as a Service (SaaS) This scenario focuses on enterprise adoption of software offerings that are hosted in the cloud. Typical examples include: IBM SmartCloud for Social Business (formerly Lotus Live) Google Apps for Business Salesforce Workday Office365. The previous list is not exhaustive; however, the general pattern remains the same. Enterprise Federated Provisioning SaaS Enterprise Directory Enterprise Provisioning jboyle jboyle@federativo.com Enterprise Website jboyle@federativo.com Federated Single Sign-on Other SaaS Vendors Jason Boyle

P a g e 6 The identity and access management capabilities for this scenario fall into two categories: Federated identity provisioning. Single Sign-on from enterprise to cloud. Except for just-in-time provisioning, described in section 3.1.1, you can approach these two categories independently with SaaS vendors. That is, you can: Look at automated identity provisioning and single sign-on separately. Adopt none, one, or both of these capabilities in your SaaS subscription. Your choice depends on the size of your employee base, cost of technology adoption, or SaaS vendor capability. 3.1.1 Identity Provisioning to SaaS There is no one clear standard or common way to provision identities to SaaS vendors. Different vendors have different approaches, which include one or more of the following approaches: Out-of-band provisioning Covers circumstances where an administrator at the SaaS vendor must provision users on behalf of the SaaS subscriber after the list of users is communicated out of band. Example: an email to the SaaS support team. Administrative portal As a subscriber of a SaaS vendor s offering, you log in to a self-service portal as the administrator of the subscription. You use a web interface to manually create user accounts for each end user in your organization that you want to use the SaaS offering. Bulk uploads of accounts to provision Often, you, the SaaS subscriber, prepare a text file, such as.csv, with the accounts to provision via an administrative browser-based portal. You upload it to the SaaS vendor for automated bulk provisioning of accounts. Client-side scriptable tools The SaaS vendor might provide a client toolkit or application so you can script user provisioning over the internet either one-by-one or in bulk. Provisioning API The SaaS vendor might provide a web API so that you or an identity and access management vendor can programmatically provision user accounts to the cloud from your enterprise directory or other identity and access management provisioning solution. These APIs might be based on current or proposed standards, such as SPML or SCIM; at other times, they are proprietary. Just-in-time provisioning (JIT-P) This approach is less common. A SaaS vendor can offer automated provisioning of an end user account during the single sign-on process. Provisioning occurs the first time that an end user signs on to the SaaS site. This model can reduce the need for an identity management solution for account provisioning; account creation is part of single sign-on. Automated identity management is still required for reconciliation and deprovisioning. The IBM approach for identity provisioning to the cloud is IBM Security Identity Manager in the enterprise. It provides specific adaptors for the most common and most demanded SaaS vendors if they have a programmatic mechanism for account establishment. You can use IBM Security Identity Manager either out-of-the-box or via an extension with SaaS vendors that offer client-side scriptable tools or a provisioning API.

P a g e 7 Examples of IBM Security Identity Manager out-of-the-box adapters for provisioning SaaS providers include 2 : GoogleApps Salesforce 3.2 Single sign-on to SaaS SaaS vendors typically support two authentication modes: Local authentication at the SaaS website. Federated single sign-on from the enterprise. Sometimes both modes are supported concurrently. This approach is less common; it can lead to password confusion for the end user or a password synchronization problem for the enterprise that subscribes to SaaS. Strong authentication mechanisms that are available only in the enterprise and password policy differences between the enterprise and the SaaS vendor can be issues if local and federated authentication modes are available concurrently. Local authentication is typically used only by small consumers that do not have an identity and access management environment capable of federated single sign-on. The rest of this section focuses on the federated single sign-on mode of authentication. For enterprises with a well-defined mechanism for authenticating employees via an intranet, extranet, or internet website, federated single sign-on is an attractive option. Single sign-on provides a seamless user experience. The enterprise can entirely control the password policy, strength of authentication that is required to access SaaS, and SaaS entitlement. Almost all SaaS vendors provide a mechanism for single sign-on through one of a standard set of protocols for tightly coupled B2B relationships. These protocols include: SAML 1.1 SAML 2.0 WS-Federation passive profile While there are other standards for single sign-on protocols, the previously mentioned standards are the most commonly adopted by SaaS vendors. SAML is a clear favorite. Even the WS-Federation passive profile uses a SAML 1.1 assertion format to carry identity and attribute information. The IBM solution for federated single sign-on is Tivoli Federated Identity Manager. It is a wellestablished and widely adopted solution for enterprises that want to support federated single sign-on standards. It has several specific first-steps plugins for known SaaS providers that rapidly enable an enterprise to establish a federated single sign-on connection to SaaS. 2 For a current list of available IBM Security Identity Manager adaptors see: http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=%2fcom.ibm.itim_pim.doc%2fc_adapt ers_intro.htm

P a g e 8 For more information about using Tivoli Federated Identity Manager to connect to SaaS see: Demonstration videos of the end user experience with single sign-on to SaaS. Demonstration videos of administrative setup of SaaS federations with the Tivoli Federated Identity Manager first steps console. Blog articles on detailed federation SSO configuration from Tivoli Federated Identity Manager to SaaS vendors: o GoogleApps: o Salesforce with SAML 2.0 o Salesforce with Tivoli Federated Identity Manager o Office365 o IBM SmartCloud for Social Business: 3.3 Identity and access management from the cloud (BC2): The trend toward BYO-identity This scenario focuses on customers who access a company s internet-facing website and must authenticate and/or self-register to complete a business transaction. A typical self-registration process requires a customer to enter a set of relevant personal and account data. Some of this data is verified by automated or manual mechanisms before the account is fully provisioned and enabled. Example mechanisms include: Sending a link to the specified email address that contains a number or bit string that is used only once. SMS ing a one-time-password to a phone number. Better customer establishment and retention results when the self-registration and authentication process is easy, painless, secure, and as repeatable as possible. One way to streamline the on-boarding process is if a customer can provide a set of identity attributes that are already recorded with another identity provider with which the customer has a relationship. Examples include major online services companies and social networks.

P a g e 9 Enterprise Directory jboyle@federativo.com Linked Identities Other Online Identities jboyle@google.com jboyle73 Jason Boyle Such online identities can be used for several purposes. At the most basic level, the online identity might populate fields in a self-registration form or in another form that collects personal information for a transaction. The customer: Retains the option to edit those fields. Must complete self-registration by some form of data verification. Establishes a password or other authentication method for subsequent authentication with the website. Beyond streamlining self-registration form data, a customer might authenticate to your site with an online identity. There are several pros and cons for this method of authentication. Pros: Customers have one less password to remember or write down: Customers have a streamlined authentication experience. Customers using their own desktop, tablet, or mobile browser often have long-lived authentication sessions with their online identity provider. Therefore, authentication to your site is no more complicated than clicking a link on your authentication page. Cons: The enterprise relinquishes control over strength of authentication and session lifetime management. Even if the enterprise implements a session timeout (idle or maximum lifetime), a new authentication is only a click away. Many enterprises adopt a hybrid approach. For most low-risk transactions, a lower level of authentication security might be acceptable. BYO-ID provides a convenient user experience. For higher risk transactions, this level of authentication is not appropriate. High risk transactions benefit

P a g e 10 from a step-up authentication approach where the user must either enter a password that is preestablished at self-registration or provide a second factor authentication. Regardless of the level of integration your enterprise adopts, the public has a growing expectation that they can bring their own online identity to new sites and use it consistently and seamlessly. Enterprises that fail to recognize and adapt to this trend miss opportunities to establish and retain customer relationships. 3.3.1 Implementing BYO-ID with IBM solutions The premier IBM solution for BYO-ID is Tivoli Federated Identity Manager. Use it to: Implement service provider capability for user-centric, single sign-on protocols such as OpenID. Integrate with a web access management system such as IBM Security Access Manager for Web. Via configuration and some supplemental JSP/page processing, you can combine federated single sign-on capabilities with the Tivoli Federated Identity Manager user self-care and self-registration functions. These functions provide self-registration pages that are populated with identity information from an online identity. To permit authentication with an online identity, Tivoli Federated Identity Manager also provides an alias service. With this service, you can map unique online identity identifiers, such as an OpenID claimed identifier, to a user account. The alias service is populated during the first authentication and self-registration process. On subsequent authentications, the alias service maps the online identity s unique identifier to the same user account to complete the authentication. You can link multiple online identities to the same account; they can be linked or unlinked by the end user. Self registration and account recovery using information cards and OpenID provides a detailed description of how to implement this scenario. For an example implementation with which you can interact, IBM has an online demonstration environment see https://tfim01.demos.ibm.com. Federation Demonstration Environment provides more details about this environment. Some protocols like OAuth are not interoperable single sign-on protocosl. For online identity providers that use these other protocols, you can author your own client code to support authentication or bootstrap self-registration to your website. Facebook and Twitter are examples of online identity providers that use OAuth. You can integrate this code with web access management solutions such as IBM Security Access Manager for Web or with a web application server such as WebSphere. Facebook Authentication to WebSEAL provides an example of implementing Facebook authentication to IBM Security Access Manager for Web. Combinations of technologies that are used by different online identity providers are supported concurrently to provide the same seamless user experience in all cases. Implementing BYO-ID provides a great user experience and a streamlined on-boarding mechanism for new accounts. Carefully balance this approach with security considerations for higher-valued transactions and step-up to an enterprise controlled mechanism employed for those cases.

P a g e 11 3.4 The API-enabled business (B2B, mobile) This scenario focuses on online businesses that want to expose a web API, typically REST, for both business partners (strongly and loosely coupled) and other thick, native, or hybrid client applications, including mobile. Some of these applications might be developed with platforms such as IBM Worklight. The use of IT in the enterprise evolved from back-of-house to point-of-sale, to websites with HTML/forms, and now to rich online experiences with Web 2.0 technologies and mobile applications. In parallel, many web companies expose resources and services via APIs. They permit access to both their own web 2.0 and mobile applications and to loosely coupled business partners that run third party websites and applications. Traditional B2B relationships signed a formal contract and shared security metadata, such as XML signature validation certificates. Many of the relationships between business partners today are loosely coupled. Trust is not established between the involved businesses. Instead, the end user must consent to access for the requesting party to access the APIs at a site where that end user has an account. This loosely coupled trust model led to the development of security protocols such as OAuth for delegated, scoped authorization of access to a set of APIs by an end user to a third party application. The OAuth protocol is different from a federated single sign-on protocol. It solves a different problem. Federated single sign-on protocols address the issue of sharing identity information and establishing web browser sessions across partners. OAuth allows a programmatic client application at a third party site to call business APIs on behalf of an account holder at that business. 3.4.1 A typical delegated access scenario The message flow of a typical scenario that leverages OAuth involves three entities: A website hosting protected APIs (the service provider). A user with an account at the service provider and having data protected by those APIs (the resource owner). Another website that programmatically wants access to the APIs on behalf of the resource owner (the client). Before commencement of the runtime message flow that is shown in the following diagram, the client registered their client website with the service provider and received client credentials. However, this registration does not mean the service provider trusts the client. It means that the service provider can inform the resource owner, whom the client claims to be when the client requests access. The resource owner ultimately decides whether to grant access to the client. Note: This simplified flow does not include a description of optional parts of the OAuth protocol such as refresh tokens.

P a g e 12 1. The client, via interaction with the resource owner, decides that access is required to APIs at the service provider on behalf of the resource owner. The API might be: get my postal address, add to my address book, or send an SMS billed to my account. 2. The client redirects the user to the authorization server to authorize access. The resource owner must authenticate to the service provider. The service provider displays a consent form that indicates which client is requesting access and what level of access is being requested. The resource owner makes this trust decision. In classical B2B relationships, the client is formally trusted by the service provider, and the resource owner has little or no say. 3. The service provider generates a one-time authorization code that is sent via redirect to the client. 4. The client exchanges an authorization code for an authorized access token. Note: The access token effectively encapsulates the identity of the resource owner and the level of access that is granted by the resource owner to the client. 5. The client can use the access token to call the APIs at the service provider s resource server. The resource server knows the following information from the access token: The resource owner that granted access. The client to whom access was granted. The level of access granted by the resource owner/ With this knowledge, the resource server can fulfill API requests that are scoped to the level of access that is granted by the resource owner for that client.

P a g e 13 Many online websites already support this model of delegated API access with OAuth, versions 1.0 and 2.0. Examples include LinkedIn, Twitter, Google, Facebook, and many others. There also are other methods for obtaining access tokens for non-web scenarios such as mobile. Ultimately, regardless of the client type, the purpose of a protocol, such as OAuth, is to allow a client application to access APIs in a scoped capacity on behalf of an end user without the end user giving that client their own personal credentials. The client might have varying levels of trust according to the resource owner based on where the client is deployed and what the resource owner knows about the client. As an online company, consider yourself a service provider. Exposing a rich API set along with flexible yet secure access models that permit business partners to dynamically engage with you and your customers opens new business opportunities and billing models. 3.4.2 Implementing an API-enabled business with IBM Security Solutions Tivoli Federated Identity Manager: Includes OAuth version 1.0 and 2.0 service provider capabilities so you can rapidly expose your own set of secure delegated access business APIs. Manages the Authorization Server component of your OAuth solution. Provides a rich and extensible set of out-of-the-box OAuth web access enforcement points to work with your resource server implementation of business APIs. Examples of web access enforcement points supported by the IBM OAuth solution in Tivoli Federated Identity Manager include: IBM Security Access Manager WebSEAL and the Web Gateway Appliance. Datapower SOA Appliances. WebSphere via servlet filter and trust association interceptor technology. The IBM online demonstration environment includes an implementation of an OAuth server with which you can interact. Tivoli Federated Identity Manager OAuth Demonstrations provides more details about the OAuth capabilities in this environment. Mobile OAuth Application Demonstration provides a video of OAuth applied to the native mobile application environment. Mobile Demonstration - Under the Hood provides a detailed technical explanation of the protocol messages that underpin the mobile demonstration video. 3.5 In the cloud: Identity and access management as a service This scenario focuses on a new trend where enterprises adopt identity and access management services that are hosted in the cloud. Key drivers for enterprises that migrate to this model include: Reduced operational costs for managing the increasing number of digital identities of users. The advent of mobile devices and bring-your-own-device (BYOD) in enterprises.

P a g e 14 These factors require businesses to make their services available in the cloud. Hybrid cloudenterprise models are also becoming prevalent in the enterprise. The following diagram illustrates the topology of a typical identity and access management cloud service. This service provides a cloud gateway or a hub that provides user provisioning, single signon, web access management, and federation services for enterprise users. The cloud service interfaces with the on-premise enterprise directory through a connector/bridge. The directory connector is instrumental in providing identity mediation between the cloud service and the onpremises enterprise directory. As clients look to invest in an identity and access management in the cloud service, a key consideration is a cloud service that provides both: Identity and access management services for applications that support standards-based authentication and federation. On-premises enterprise applications. Another consideration is the extent of out-of-the-box support for SaaS or Cloud applications (application connectors) and for mobile scenarios.

P a g e 15 IBM offers identity and access management in the cloud through its business partners. IBM Security Solutions are used by business partners to offer a range of hosted identity and access management services. For an identity and access in the cloud solution, consider offerings from IBM business partners: Lighthouse Gateway Ilantus Technologies 4 Summary The trend toward cloud adoption across various patterns leads to fundamental changes in how companies do business. Interacting with employees, customers, and business partners in an online world changes the approach to identity and access management. Identity and access management is no longer purely the realm of the company IT department and systems administrators. The enterprise no longer solely controls the full user lifecycle of identities and business partners. 5 For more information To learn more about IBM Security solutions, contact your IBM representative, IBM Business Partner, or Visit ibm.com/security.

P a g e 16 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 19-21, Nihonbashi-Hakozakicho, Chuo-ku Tokyo 103-8510, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law : INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

P a g e 17 IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights reserved. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed.

P a g e 18 Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at ibm.com/legal/copytrade.shtml. Microsoft, Windows, Windows NT, Office365, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Google and the Google Logo are registered trademarks of Google Inc. Salesforce is a registered trademark of salesforce.com Inc. Workday and the Workday logo are registered trademarks of Workday, Inc. Facebook is a registered trademark of Facebook Inc. The Twitter name, logo, Twitter T, Tweet, and Twitter blue bird are registered trademarks of Twitter, Inc. Statement of Good Security Practices IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANY SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY.

P a g e 19 International Business Machines Corporation [year] International Business Machines Corporation New Orchard Road Armonk, NY 10504 Produced in Australia 02-2013 All Rights Reserved References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates.