IBM. IBM i2 Analyze Security White Paper. Version 4 Release 1

Transcription

1 IBM IBM i2 Analyze Security White Paper Version 4 Release 1

2 Note Before using this information and the product it supports, read the information in Notices on page 19. This edition applies to version 4, release 1, modification 1 of IBM i2 Analyze and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2012, US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

3 Chapter 1. IBM i2 Analyze security model The i2 Analyze security model enables the platform to determine the rights of users to manipulate the items that they are working with. The security model is safe, reliable, and configurable. It provides the following functionality: v User rights are split into two discrete categories: "Access" rights govern the ability of a user to see and change the contents of an item. "Grant" rights govern the ability of a user to control which users can see and change the contents of an item. v Both categories of rights can be controlled for every item in the platform, on a user group basis. Each item maintains information that categorizes it against a configurable set of criteria. Each user group carries a list that defines what access rights its users receive for items in different categories. v Rights are enforced at the item level. A user who is able to see the contents of an item can see all the contents of that item. i2 Analyze does not enforce security independently on the cards, property groups, or properties of an item. v Rights are calculated for the latest version of an item, but affect all versions of an item in the same way. A user who is able to see the contents of an item can see the contents of every version of that item. v The security model can integrate with existing authorization mechanisms. For example, i2 Analyze can use the directory services of an organization to determine which groups a user is in. Note: The ability of a user to change the contents of an item is also governed by the type of data source in which the item is stored. Users cannot change the contents of an item in an external data source or an ELP stage through the platform, regardless of the rights that the security model awards them. Three key concepts enable these characteristics of the i2 Analyze security model: dimensions, levels, and permissions. IBM i2 Analyze security dimensions A security dimension is a way to categorize an i2 Analyze item, with the aim of using its categorization to determine what rights users receive. The security dimensions for any deployment of the platform are defined in the security schema for that deployment. For a particular deployment of i2 Analyze, there might be several different ways of categorizing items, resulting in multiple dimensions. For example: v Items might be categorized by their security classifications v Items might be categorized by the type of intelligence that produced them v Items might be categorized by the roles of the users who are allowed to access them Copyright IBM Corp. 2012,

4 Each security dimension contains a set of values that items can have in order to classify them within that dimension. To continue the example, the dimensions might have values as follows: Security classification Top Secret, Secret, Confidential, Restricted Intelligence type Human Informant, Open Source Job role Clerk, Analyst, Manager In some dimensions (such as security classification), the values form a sequence from which each item takes a single value. In such cases, the values are considered to be levels, where each value supersedes all the values below it. In dimensions where the values do not form a sequence, items can take one or more values. Every item in an i2 Analyze deployment must be assigned at least one value for each of the dimensions in that deployment. There is no such thing as an "optional" security dimension. For example: An i2 Analyze deployment provides access to its security schema through the standard info service. The security schema contains the security dimensions and their values. Dimensions and values vary between deployments, and there are no restrictions on the numbers of dimensions or values that a security schema can define. 2 Security White Paper

5 IBM i2 Analyze security levels A security level is a description of what a user is allowed to do to an item in i2 Analyze. User group membership determines what security level a user receives for any particular item. i2 Analyze security levels break down into two distinct categories: access levels and grant levels. Access levels The security access level of a user relates to their rights to view or edit an item in i2 Analyze. i2 Analyze defines four security access levels. At any moment in time, a user has one of these levels for each item. None The user has no access to the item. The user cannot examine the item data, or even know that the item exists. Cloaked The user has access to the fact that the item exists, but cannot examine the item data. An i2 Analyze service can read cloaked item data on behalf of a user, but must not return that data to the user. Read only The user has read-only access to the item and its data. Update The user can read, modify, and delete the item and its data. If a user needs a different access level from the cloaked or read-only level that they have, they can interrogate an item for its signpost. The signpost contains an indication of the person or team in their organization that is able to give them such access. Grant levels The security grant level of a user relates to their rights to change the dimension values of an item. The dimension values that they set affect what security access levels and grant levels they and other users receive for an item. i2 Analyze defines two security grant levels. At any moment in time, a user has one of these levels for each item. None Update The user is not able to evaluate or change the security dimension values of the item. The user can evaluate and change the security dimension values of the item. The interaction between access levels and grant levels means that on a particular item, having the "update" grant level effectively overrides the "none" access level. A user with the "update" grant level on an item is allowed to know that the item exists so that they can change its dimension values. Chapter 1. Security model 3

6 IBM i2 Analyze security permissions In i2 Analyze, security permissions provide the link between the security dimension values that an item has, and the security levels that users receive. The platform calculates the access and grant rights of users according to the permissions of the user groups to which they belong. In an i2 Analyze security schema, the set of security permissions for a user group defines mappings from dimension values to access or grant levels. For any particular item, a user receives the security levels that their user group indicates for the dimension values of that item. When a user is a member of several user groups, or an item has multiple dimension values, it is possible for a user to receive several security levels from different security permissions. In these circumstances, i2 Analyze computes a single security level from all the contributors. 4 Security White Paper It is not compulsory for a set of permissions for a user group to provide a security level for every value of every dimension. Any dimension value that does not appear in a set of permissions receives a default security level, according to a set of rules: v For an unordered dimension, a dimension value that does not appear in the permissions receives the "none" security level. v For an ordered dimension: If the unspecified value is below a dimension value that does appear, then the unspecified value receives the same security level as the specified value. If the unspecified value is above a dimension value that does appear, then the unspecified value receives the "none" security level.

7 For example, if a particular set of permissions associates the "read only" access level with "restricted" items (and makes no other setting), then the default access level for "confidential" items is "none". However, if the permissions associate the "read only" access level with "confidential" items instead, then "restricted" items also receive that access level for users in the same group. An i2 Analyze system administrator must arrange the security schema so that all users can receive a security access level that is not "none" for at least one value in every dimension. The same requirement does not apply to security grant levels. Note: IBM recommends that you do not specify access and grant permissions for the same user group. Instead, you can assign the "update" security grant level to users through membership of a group that is reserved for that purpose. IBM i2 Analyze security scope Security model example i2 Analyze does not enforce its security model on a deployment-wide basis. Instead, because each service in a deployment can maintain its own data store, the services are responsible for enforcing security on the items that they control. There are a number of advantages to enforcing the security model at the scope of the services, rather than the scope of the deployment: v The services can use item caching. Security is applied after retrieving objects from the cache, so cached objects can be reused on behalf of all users. This arrangement makes the cache more effective. v Security is independent of the underlying storage system. It is not necessary to reimplement security for new storage technologies, and there is no need for new storage technologies to provide security support. v The code that implements the security model is modular, and used by all the standard services. The code is also available for use by custom services so that they can use the same security model. Note: None of these details has any bearing on the use of encryption as a security measure. The encryption of all stored data can be enabled by appropriate configuration of the underlying storage system. At any moment, a user has one security access level and one security grant level for each item in i2 Analyze. The platform calculates these levels according to a consistent set of rules. The process for determining a security level involves examining security permissions within and across dimensions. The platform does the job in three steps: 1. Bring together the permissions for all the user groups of which the user is a member. 2. Use the permissions to determine all the security levels that the user receives for each dimension value that the item has. Take the least restrictive level in each case. 3. Examine all of these "least restrictive" dimension-specific security levels, and take the most restrictive. Chapter 1. Security model 5

8 For example, consider the following item, which has one value for each of two security dimensions, and two values for a third. Then, consider a user in a group that has the following security permissions. (It does not matter whether the permissions are due to one user group or several.) The following diagram then represents the process for determining the security access level of the user for this item. This item has two values in the "Job Role" dimension that map to different access levels for this user. At this stage in the calculation, the less restrictive access level ("update") is taken. However, the values from the "Security Classification" and "Intelligence Type" dimensions both map to the "read only" access level. The final part of the calculation takes the most restrictive level, and the user therefore has the "read only" access level on this item. In general, a similar calculation is necessary to determine the grant security level for the same user on the same item. What often happens in practice is that either the user is a member of a group that confers grant access on all items, or they are not. 6 Security White Paper

9 Chapter 2. IBM i2 Analyze security schemas An i2 Analyze security schema defines the security dimensions that exist in a deployment, and the dimension values that can be assigned to items. A security schema also defines the permissions that i2 Analyze users receive. Every deployment of i2 Analyze has a security schema whose contents reflect local requirements. It is the responsibility of the deployer to ensure that the security schema is appropriate for the environment where it is used. Often, the security dimensions map to item classifications that exist in the organization. Security dimensions A security schema defines access security dimensions and grant security dimensions separately. Although they have the same structure, access and grant security dimensions are distinct from each other. In a security schema, dimensions and dimension values must have identifiers that are unique across the whole schema. Security permissions A security schema defines security permissions by user group, and then by dimension. For a particular user group, the schema identifies one or more dimensions for which membership of that group affects access rights. For each identified dimension, the schema contains a list of security permissions. It is not necessary for the security schema to define permissions for every user group in the organization. Similarly, it is not necessary for the permissions within any particular dimension or group to set a security level for every possible dimension value. The completeness of the schema is judged at run time when the security level of a particular user for a particular item is calculated. Copyright IBM Corp. 2012,

10 IBM i2 Analyze security schema definitions An i2 Analyze security schema is an XML file with a relatively simple structure. Security dimensions and security permissions are defined in separate sections of the file. In outline, the <SecuritySchema> root element of a security schema contains child elements for the dimension and permission definitions: <SecuritySchema> <SecurityDimensions Id="" Version=""> <AccessSecurityDimensions> <Dimension...> <DimensionValue... />... </Dimension>... </AccessSecurityDimensions> <GrantSecurityDimensions> <Dimension...> <DimensionValue... />... </Dimension>... </GrantSecurityDimensions> </SecurityDimensions> <SecurityPermissions> <GroupPermissions...> <Permissions...> <Permission... />... </Permissions>... </GroupPermissions>... </SecurityPermissions> </SecuritySchema> The <SecurityDimensions> element has attributes for the Id and Version of that part of the schema. If you modify the element to add dimension values, you must increment the version number and retain the identifier. In a valid security schema, the <AccessSecurityDimensions> and <GrantSecurityDimensions> elements must be present, and there must be at least one <GroupPermissions> element inside <SecurityPermissions>. 8 Security White Paper

11 Security dimension definitions Security dimensions are defined in an i2 Analyze security schema file, as children of the mandatory <AccessSecurityDimensions> and <GrantSecurityDimensions> elements. A valid security schema defines at least one access and one grant security dimension. The syntax for defining a security dimension does not depend on whether it is an access or a grant dimension. The structure of the XML is always the same. The following example shows a simple, complete <Dimension> element: <Dimension Id="SD-SC" DisplayName="Security Classification" Description="The security classification of this information" Ordered="true"> <DimensionValue Id="TOP" DisplayName="Top Secret" Description="Top Secret" /> <DimensionValue Id="RES" DisplayName="Restricted" Description="Restricted" /> </Dimension> The attributes of the <Dimension> element affect how the values in the security dimension are interpreted. Attribute Id DisplayName Description Ordered Description A unique identifier that is used to distinguish this security dimension throughout the system. A name that identifies this dimension to the user in the Intelligence Portal, for example. A more detailed description of this security dimension that provides more information to the user. In the Intelligence Portal, the description is used as a tooltip. Indicates whether the values in this dimension form a descending sequence in which each value supersedes the values below it. Marking this dimension as Ordered="true" means that a user who has access rights to "Top Secret" items implicitly has the same access rights to "Restricted" items as well. For a dimension in which Ordered="false", there is no such implication, and access rights must be assigned explicitly for each dimension value. The Id, DisplayName, and Description attributes of <DimensionValue> elements have the same purpose and meaning as the <Dimension> attributes with the same names. The identifiers of dimension values only have to be unique within the dimension that defines them. Important: After you deploy i2 Analyze, the changes that you can make to security dimensions are limited. You cannot add or remove dimensions, or remove dimension values. You can only add values to existing dimensions. For this reason, you must understand the requirements of your organization before you deploy i2 Analyze in a production environment. Chapter 2. Security schemas 9

12 10 Security White Paper Security group permission definitions In an i2 Analyze security schema, the mandatory <SecurityPermissions> element contains one or more <GroupPermissions> elements. Each <GroupPermissions> element defines the security levels that users in a particular group receive for items with particular dimension values in an i2 Analyze deployment. The syntax for defining the security permissions for user groups enables membership of one group to convey permissions across several dimensions, and allows different groups to convey different permissions for the same dimensions. The following example shows how to structure <GroupPermissions> elements inside the <SecurityPermissions> element: <SecurityPermissions> <GroupPermissions UserGroup="Clerk"> <Permissions Dimension="SD-SC"> <Permission... /> </Permissions>... </GroupPermissions> <GroupPermissions UserGroup="Manager"> <Permissions Dimension="SD-SC"> <Permission... />... </Permissions> <Permissions Dimension="SD-IT"> <Permission... />... </Permissions>... </GroupPermissions> <GroupPermissions UserGroup="Security Controller"> <Permissions Dimension="SD-GA"> <Permission... /> </Permissions> </GroupPermissions> </SecurityPermissions> The value of the UserGroup attribute of each <GroupPermissions> element must match the name of a group of i2 Analyze users. The value of the Dimension attribute of each <Permissions> element must match the identifier of one of the dimensions that is defined in the first part of the schema. It is normal for <Permissions> elements for the same dimension to appear in more than one <GroupPermissions> element: v Users who are members of one group but not the other can receive different access levels on items that have the same dimension values. v When users are members of more than one group, <Permissions> elements for the same dimension are combined before any access level calculation takes place. In many deployments of i2 Analyze, there is one grant security dimension that contains one dimension value. By referring to the grant security dimension from a single <GroupPermissions> element, you can arrange for grant access to be in the hands of users who are members of a dedicated group. Important: You can add and remove <GroupPermissions> elements from a deployed security schema, provided that the resulting system continues to obey the rules of i2 Analyze. In particular, it must remain possible for all users to get an access level that is not "none" for at least one value in every access dimension.

13 Security permission definitions The security permission definitions in an i2 Analyze security schema each associate a single dimension value with a single security level. The definitions can be simple because of the additional context that their location in the security schema file provides. Creating a security schema The <Permission> elements that define security permissions always appear inside <Permissions> elements, which in turn always appear inside <GroupPermissions> elements. <GroupPermissions UserGroup="Manager"> <Permissions Dimension="SD-SC"> <Permission DimensionValue="TOP" Level="READ_CLOAKED" /> <Permission DimensionValue="RES" Level="UPDATE" /> </Permissions> <Permissions Dimension="SD-IT"> <Permission DimensionValue="HUMINT" Level="READ_ONLY" /> </Permissions> </GroupPermissions> It is quite possible, and often desirable, for identical <Permission> elements to appear in different locations in an i2 Analyze security schema. The effect of a security permission definition depends entirely on its position in the file. Important: Like the <GroupPermissions> elements that contain them, you can add and remove <Permissions> and <Permission> elements from a deployed security schema, provided that the resulting system does not break the rules of i2 Analyze. Every deployment of i2 Analyze requires a custom security schema that encapsulates the security model for that deployment. The easiest way to create a security schema is to start from one of the examples that are supplied with the platform. Before you begin Before you create the XML security schema file, you must design the security model for your deployment of i2 Analyze. In particular, you must identify or create the user groups to which security permissions will be assigned. About this task An i2 Analyze security schema contains definitions of security dimensions and security permissions. When you create a security schema, you define the dimensions and dimension values first, and then define the security permissions that refer to them. Procedure 1. Using an XML editor, open the example security schema from the deployment toolkit: toolkit\configuration\examples\security-schema\example-dynamicsecurity-schema.xml 2. Edit the contents of the <AccessSecurityDimensions> element so that it contains a <Dimension> element for each category that your deployment uses to determine access rights to platform items. 3. Edit the contents of the <GrantSecurityDimensions> element so that it contains a <Dimension> element whose value you can use to convey grant access rights. Chapter 2. Security schemas 11

14 4. Edit the contents of the <SecurityPermissions> element: a. Add or modify the <GroupPermissions> elements so that they reflect all the user groups to which you will assign security permissions. b. Within each <GroupPermissions> element, add or modify <Permissions> elements to indicate which dimensions are affected by membership of each user group. c. Within each <Permissions> element, add or modify <Permission> elements to assign security levels to items that have particular dimension values. 5. Save the completed security schema to its final location in the deployment toolkit: toolkit\configuration\fragments\common\web-inf\classes\ The name that you give to the completed security schema is not important. You specify the name of the security schema in a properties file, later in the deployment process. For more information about deploying a security schema during deployment of the platform, see the IBM i2 Analyze Deployment Guide. IBM i2 Analyze security schema modifications The security schema that is deployed with i2 Analyze can be modified to incorporate changes to local requirements. Security permissions can be changed completely, and dimension values can be added to security dimensions. To complete the following security schema modifications, your deployment must use the WebSphereDynamicAccessRoleBasedPrincipalProvider supplied security implementation. Additions can be made within the <SecurityDimensions> element. However, you cannot remove elements or modify any Id values because items might exist that are associated with those values. In the <SecurityPermissions> element, the mapping of dimensions and dimension values to security groups is more dynamic. The following table shows the changes that are, and are not, allowed to a deployed security schema, and whether a reindex is required: Table 1. Allowed changes to i2 Analyze security schema Change XML elements or attributes Allowed Reindex required Add a security dimension <Dimension> No N/A Modify an existing security dimension DisplayName, Description Remove an existing security dimension <Dimension> No N/A Add a dimension value to a security dimension Modify an existing dimension value Remove an existing dimension value from a security dimension Yes No <DimensionValue> Yes Yes DisplayName, Description Yes No <DimensionValue> No N/A Add a security group <GroupPermissions> Yes No Modify an existing security group UserGroup Yes No Remove an existing security group <GroupPermissions> Yes No 12 Security White Paper

15 Table 1. Allowed changes to i2 Analyze security schema (continued) Change Add security dimensions to a security group Remove security dimension from a security group Add security permissions from a security dimension for a security group Modify existing security from a security dimension permissions for a security group Remove existing security from a security dimension permissions for a security group XML elements or attributes Allowed <Permissions> Yes No <Permissions> Yes No <Permission> Yes No DimensionValue, Level Yes No <Permission> Yes No Reindex required Dimension values If the requirements for dimension values change, you can add dimension values to a security dimension by adding a <DimensionValue> element as a child of an existing <Dimension> element. To modify the display name or description of a dimension value, change the values for the DisplayName and Description attributes of the <DimensionValue> element. You must not change the value of the Id attribute. For more information about security dimension definitions, see Security dimension definitions on page 9. Security groups If the requirements for security groups change, you can modify the <GroupPermissions> element, and child elements. v To add a group, insert a complete <GroupPermissions> element. To use the new group, you must ensure that the user repository contains a group that matches the value of the UserGroup attribute. v To modify the name that is associated with a group, change the value of the UserGroup attribute. v To remove a group, remove the <GroupPermissions> element for that group. For more information about security group definitions, see Security group permission definitions on page 10. Permissions If the requirements for a security group's permissions change, you can add or remove <Permissions> elements and add, modify, and remove child <Permission> elements. To change dimensions that a group has permissions for, you can add or remove the <Permissions> element as follows: v To add a dimension that the group has permissions for, insert a <Permissions> element where the value of the Id attribute matches the value of the Id attribute of the dimension. Chapter 2. Security schemas 13

16 v To remove a dimension that the group has permissions for, remove the <Permissions> elements where the value of the Id attribute matches the value of the Id attribute of the dimension. To change the security permissions that a group has within a dimension, you can add, modify, and remove <Permission> elements as follows: v To add a permission to a group, insert a <Permission> element. The DimensionValue attribute must match to a dimension value that is in the same dimension that is defined in the Dimension attribute of the parent <Permissions> element. v To modify the current permission that a group has in a dimension value, set the Level attribute to a different value. v To modify the dimension value that a permission is for, set the DimensionValue attribute to a different value. v To remove the current permission that a group has in dimension value, remove the <Permission> element in which the DimensionValue attribute matches that dimension value. For more information about security permission definitions, see Security permission definitions on page 11. Modifying security dimensions Add or modify security dimension values in the security schema without clearing data from the system. Before you begin v You must understand the structure of the security schema, including the element definitions and their attributes. v Design the changes to the security model for your deployment of i2 Analyze, and ensure that they are valid. For more information, see IBM i2 Analyze security schema modifications on page 12. v Make a copy of the deployed security schema file as a backup. In an example deployment, the file is in the following directory: i2analyze\deploy\wlp\usr\ servers\i2analyze\apps\core.war\web-inf\classes. The name of the security schema is specified in the DynamicSecuritySchemaResource property of the ApolloServerSettingsMandatory.properties file in the same directory. About this task Modify the security dimensions in the security schema to incorporate changes to local requirements. After you complete the changes to the security schema, clear the search index and redeploy i2 Analyze. Important: If the security schema contains access dimensions which users do not have any access levels, the system prevents all access to the system. Procedure 1. Using an XML editor, open the security schema for the deployment. The security schema is in the folder toolkit\configuration\fragments\common\ WEB-INF\classes\. The name of the security schema is specified in the DynamicSecuritySchemaResource property of the ApolloServerSettingsMandatory.properties file in the same directory. 14 Security White Paper

17 2. Modify the security dimensions in the security schema according to your requirements. 3. Increment the version number stated in the Version attribute of the <SecurityDimensions> element in the security schema. 4. Check your updated schema to ensure that it remains possible for all users to get an access level that is not "none" for at least one value in every access dimension. 5. Save and close the file. 6. Clear the search index. To clear the search index, open a command prompt and navigate to the toolkit\scripts directory, then run the following command: setup -t clearsearchindex 7. Redeploy i2 Analyze. Open a command prompt and navigate to the toolkit\scripts directory, then run the following command: setup -t deploy Restart the application server by running the following command: setup -t startliberty The following message is displayed: # Security Schema amended (core) Modifying security permissions Change the mapping between user group permissions and the security schema without clearing the search index from the system. Before you begin v You must understand the structure of the security schema, including the element definitions and their attributes. v Design the changes to the security model for your deployment of i2 Analyze, and ensure that they are valid. For more information, see IBM i2 Analyze security schema modifications on page 12. v Make a copy of the deployed security schema file as a backup. In an example deployment, the file is in the following directory: i2analyze\deploy\wlp\usr\ servers\i2analyze\apps\core.war\web-inf\classes. The name of the security schema is specified in the DynamicSecuritySchemaResource property of the ApolloServerSettingsMandatory.properties file in the same directory. About this task Modify the security permissions in the security schema to incorporate changes to local requirements. After you complete the changes to the security schema, redeploy i2 Analyze. Important: If the security schema contains access dimensions which users do not have any access levels, the system prevents all access to the system. Procedure 1. Using an XML editor, open the security schema for the deployment. The security schema is in the folder toolkit\configuration\fragments\common\ WEB-INF\classes\. The name of the security schema is specified in the DynamicSecuritySchemaResource property of the ApolloServerSettingsMandatory.properties file in the same directory. Chapter 2. Security schemas 15

18 2. Modify the security dimensions in the security schema according to your requirements. 3. Check your updated schema to ensure that it remains possible for all users to get an access level that is not "none" for at least one value in every access dimension. 4. Save and close the file. 5. Redeploy i2 Analyze, and start the application server. Open a command prompt and navigate to the toolkit\scripts directory, then run the following commands: setup -t deploy setup -t startliberty 16 Security White Paper

19 Chapter 3. Supplied security implementation One of the requirements for a deployment of i2 Analyze is a principal provider, which is the mechanism through which the users in an organization are mapped to the user groups in the security schema. When a deployment environment uses WebSphere for user authentication, the i2 Analyze Deployment Toolkit contains a production-quality class that might be an appropriate solution. The WebSphereDynamicAccessRoleBasedPrincipalProvider class from the deployment toolkit performs a direct mapping from the names of user groups in WebSphere to the names of user groups in the security schema. When the user is a member of a WebSphere group, they receive access and grant rights in accordance with the contents of corresponding <GroupPermissions> elements in the i2 Analyze security schema. The i2 Analyze deployment toolkit also includes an example security schema and WebSphere users file that contain correlating group names and dimension values. These files are suitable for use in test deployments, but not for live systems. Copyright IBM Corp. 2012,

20 18 Security White Paper

21 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 grant 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 U.S.A. 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 may 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: IBM United Kingdom Limited Hursley House Copyright IBM Corp. 2012,

22 Hursley Park Winchester, Hants, SO21 2JN UK 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. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. If you are viewing this information softcopy, the photographs and color illustrations may not appear. Trademarks IBM, the IBM logo, i2, 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 Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Other company, product, and service names may be trademarks or service marks of others. 20 Security White Paper