Enterprises need to protect the integrity, confidentiality, authorization, and availability of business data and computing resources. Further, protecting the integrity, confidentiality, and privacy of business applications running in the cloud environment has become a key customer requirement. IBM PureApplication System is a pre-integrated platform built for cloud, integrating networking, computing, storage, physical, and virtual resource management software, IBM and partner business application workload patterns, and a well-designed and -planned security and trust infrastructure. (See Security in Development: The IBM Secure Engineering Framework for more information.)
PureApplication System provides resource isolation and protection at multiple levels to address these security and trust requirements. Built-in security controls provide computing node isolation, disk storage isolation, OS and virtual machine isolation, networking isolation, trust domain isolation, communication integrity and confidentiality protection, and fine-grained resource access control. Every virtual application and every shared service run in separate trust domains that are isolated from one another and from the system management trust domain.
PureApplication System is an integral building block of your enterprise computing environment and IT infrastructure. The built-in security infrastructure complements your IT security controls and should integrate with your enterprise IT infrastructure to provide end-to-end security protection and risk management.
This article reviews the multiple levels of resource isolation and the trust infrastructure that support policy-based control of resource isolation and trust domains. Through examining various usage scenarios, best practices are suggested with the goal of helping you plan and integrate PureApplication System security and trust infrastructure into your IT architecture to reduce your overall attack surface.
Security engineering and design principles
PureApplication System management software, like other IBM software products such as IBM WebSphere® Application Server and IBM WebSphere DataPower® SOA Appliances, builds security into the development process following IBM Secure Engineering Framework recommended guidelines and best practices (see Security in Development: The IBM Secure Engineering Framework). The goal is to design and develop products to meet or exceed IBM’s security requirements and industry best practices. PureApplication System is designed with security in mind through threat analysis and risk mitigation to minimize your overall attack surface. PureApplication System employs IBM Security AppScan to routinely test for security vulnerabilities as an integral part of product development and maintenance.
The architecture of PureApplication System security and trust infrastructure follow good security design principles, described below.
Secure by default principle
Data integrity and confidentiality during data transmission are protected by default by the Secure Socket Layer (SSL) protocol. The integrity of server request messages is protected by using public key technology. Integrity and confidentiality of persistent data storage, both configuration data and application images, are encrypted. Fine-grained access control is enforced by default. All user login, logout, and management activities are audited by default. Moreover, there is no user configurable option to deactivate the default security protections.
Defense in depth principle
As is standard security practice, PureApplication System employs multiple layers of security protection in front and around your business application and data:
- Network protection: PureApplication System is equipped with both physical network isolation and virtual network isolation. Management subsystems and application subsystems are on separate external physical networks. Application deployments are placed on separated virtual networks. By default, the virtual application pattern firewall plugin locks down unused ports.
- Communication protection: SSL transport protection is configured and enforced by default.
- OS protection: OS images are hardened in that all unused ports are closed. Virtual application deployment virtual machines disable root account login and require secure shell (SSH) with Rivest, Shamir, and Adleman (RSA) key-based authentication with a 2048 bit key size.
- Authentication: Resource access requires authentication. Strong authentication — for example, public key and symmetric key based authentication — is required when accessing sensitive resources.
- Trust domain: Trust domains define trust boundaries and limit resource visibility across trust boundaries.
- Authorization: Resource access requires security role-based authorization and resource instance-based access control.
Least privileged principle
PureApplication System authorization supports fine-grained access control and follows the security principle that a user is granted the least amount of privileges required to perform his or her tasks. In general, resources, whether physical or virtual, are not visible to users unless explicit access rights have been granted.
- Separation of duty policy
PureApplication System categorizes administrative user responsibilities into five functional areas (Figure 1):
- Hardware administration
- Cloud group administration
- Workload resources administration
- Security administration
Figure 1. Five areas of management responsibilities.
Users can be granted management responsibility of one or more of these functional areas. Within each area, an administrator can be granted either a read-only security role or a full permission security role. An administrator with a full permission security role can perform all administrative actions of that area, while an administrator with a read-only security role can monitor the configuration and status, but cannot make changes.
No single administrator needs to have all the five area of administrative authorities. The best practice recommendation is to divide the management responsibilities among administrators so that no single administrator has all the administrator roles. For example, a user who has the Auditing role is responsible for managing security auditing configuration, archiving security auditing records, monitoring, and analyzing any abnormality in system operations. An auditing administrator ideally should not have other areas of administrative responsibility, both to avoid any conflicts of interest and to be able to effectively hold users accountable for their actions.
- Delegation policy
An administrator with any one of the full permission security roles can delegate his own security roles to other users provided that the administrator has also been permitted a delegation security role. In Figure 2, this Workload resource administrator has been granted a delegation security role and so can grant security roles to other users and user groups.
Figure 2. Delegation policy - Requiring a full permission administrative role and the delegation role
An administrator can only grant other users security roles that he or she has been granted. The delegation rule is designed to prevent administrators and users from gaining illegitimate additional privileges. The only way a user or user group can gain an additional privilege is if another administrator who has the privilege explicitly grants the privilege.
- Minimal visibility policy
Following the least privilege principle, the PureApplication System user console and command line interface expose management functions and resources to users on a need-to-know basis. A user or administrator who does not have a security role cannot see the corresponding management function and panels on the console. A user or administrator can only see resources to which they have access.
To help enterprises address security compliance requirements, such as the Sarbanes-Oxley Act (SOX), the Health Insurance Portability and Accountability Act (HIPPA), and European privacy laws, PureApplication System captures comprehensive auditing records. PureApplication System users and administrators are held accountable for their deployment and administrative actions. PureApplication System captures and keeps auditing records of all user security and administrative actions. Every auditing record contains information to describe who attempted what action on which resource(s) when, from where, and whether the result was successful or not. An event log entry contains a unique sequence number and is digitally signed by the audit service to protect integrity and to support non-repudiation. Security auditing is enabled by default and cannot be disabled.
While keeping comprehensive event auditing of all state changes, PureApplication System adds minimal overhead to request response times. Security auditing logs can be configured to be pushed to external storage to help in automating the event log archiving process and to satisfy security compliance requirements. Communication with external storage servers is protected using SSH. Users are encouraged to set up RSA key-based client authentication in SSH configuration.
The PureApplication System system security and trust infrastructure provides protection in multiple layers to provide end-to-end security (Figure 3). The next sections describe these security mechanisms in the infrastructure, platform, and application layers.
Figure 3. PureApplication System system manages three cloud computing layers
Infrastructure layer security
The PureApplication System IaaS (Infrastructure as a Service) layer manages physical resources (including computer nodes, networks, disk storage) and virtual resources (including cloud groups, virtual machines, disk storage volumes, IP addresses, OS images). IaaS system management software consists of a system manager, workload manager, and hypervisor components. These three components are connected internally via a management network to compute nodes. This network is used for management request flow and is separated from the external physical network that connects computer nodes to service application requests. When connecting external networks to PureApplication System, a best practice is to connect the management network and application network to separate, external networks.
While virtualization and resource sharing offer major cost benefits to business, the ability to isolate resources to protect confidentiality, integrity, and privacy is a main concern of enterprise customers. PureApplication System provides resource isolation and data segregation via networking, communication, trust domain, and access control (discussed later). PureApplication System provides two types of deployment patterns:
- Virtual system (vSys) patterns take a topology-centric approach that lets users specify the topology of the system to deploy.
- Virtual application (vApp) patterns take an application-centric approach that lets users specify application artifacts and policy driven quality of service characteristics, such as scaling and logging levels.
vSys and vApp adopt two distinct application life cycle management approaches with different security mechanisms and resource isolation characteristics:
- Virtual system deployments take a push approach, in the sense that PureApplication System management software configures a per deployment 2048-bit SSH key to access the OS root account to execute management scripts, and to push application code and software patches to the deployed VM's.
- Virtual application deployments take a pull approach, in the sense that PureApplication System management software configures a per deployment trust domain and sets up an agent process on every deployed VM that can interact with the management software to access management services, and to retrieve application code and software patches.
Resource isolation via networking
PureApplication System isolates management traffic and application workload traffic using separate external physical networks. An additional level of resource isolation among deployments is supported via the construct of cloud groups, IP groups, and environment profiles. An IP group essentially is a collection of IP addresses on a specified subnet and virtual local area network (VLAN). Cloud groups are physical groupings of compute nodes, management VLANs, and application IP groups. A cloud group can contain one or more compute nodes. On the other hand, each compute node can be in, at most, one cloud group, which provides physical isolation in terms of compute nodes between cloud groups. Virtual network isolation can be configured on a management network. More specifically, each cloud group has a unique management VLAN, such that VMs in a cloud group cannot access VMs in a different cloud group through the management VLAN. Virtual network isolation can be configured on application network via IP groups. Two IP groups are virtually isolated from each other if they are on different VLANs. VMs in two separate cloud groups can access each other if their VLANs are bridged in the customer network outside of the system.
An environment profile defines an operational environment for deploying workload patterns. An environment profile contains one or more cloud groups, one or more IP groups of the selected cloud groups, as well as resource allocation limitations on computer resources, including virtual CPU and memory, number of software licenses, deployment priority, and user access rights. Environment profiles can be used to set up resource isolation through a grouping of cloud groups and IP groups. More specifically, an environment profile can have an exclusive set of physical compute nodes via its cloud groups. Through a combination of cloud groups and IP groups, an environment profile can have virtual network isolation from other environment profiles, both management networks and application networks.
Figure 4 shows an example of two virtually isolated environment profiles: Environment profile 1 contains cloud group 1, management VLAN 1, IP group 1 and application VLAN 3; Environment profile 2 contains cloud group 2, management VLAN 2, IP group 2, and application VLAN 4.
Figure 4. Two environment profiles with physical compute node isolation and virtual network isolation.
You can configure separate environment profiles for different users and user groups to address different business needs. You can setup an access control policy leveraging the environment profile Access Rights attribute. To deploy workload resources to an environment profile, a user must either have the privileged Workload administration security role or have read access rights to the environment profile. Typically, users and groups are explicitly granted read or more access rights to a specific environment profile. Granting access rights enables Workload administrators to setup need-to-know access control policy at the environment profile level. Typically, users are not granted access to system resources such as cloud groups, IP groups, compute nodes, and software licenses. Granting users access rights to an environment profile enables users to deploy workload to the environment profile and to use the contained cloud groups, IP groups, compute nodes, and software licenses under the policy and resource limits imposed by the environment profile.
Consider a use case in which a PureApplication System in an enterprise is shared by four departments: accounting, development, testing, and services. The enterprise wants to divide the computing resources into three sets for resource isolation consideration:
- One set assigned to the accounting department
- One set shared between the development department and the testing department
- One set allocated to the services department.
The corporate security policy requires physical and virtual isolation among the three set of resources, and the enforcement of need-to-know based user access control aligned with the four departments. Development and testing users share one set of physical computing nodes. At different points in the product development cycle there is typically a different level of cloud resource demand between the development and testing departments. It is desirable to be able to flexibly allocate the resources between development and testing to accommodate the changes in resource allocation requirements.
To address the computing resource isolation and access control requirements, the enterprise creates three cloud groups and four environment profiles, as shown in Figure 5. Each department is granted access to its own separate environment profile. The development environment profile and the testing environment profile share a common cloud group so that allocation of computing nodes can be adjusted between the two departments. The three cloud groups provide physical isolation of the computing nodes among the four departments. IP groups with distinct VLANs are used to provide virtual network isolation among the four departments. Specifically, one IP group each is configured in the Accounting Cloud Group and in the Services Cloud Group. Two IP groups, the Development IP Group and the Testing IP Group, are configured in the Development and Testing Cloud Group. The four environment profiles are shown in the figure. Computing resource allocation can be adjusted between the development environment profile and the testing environment profile using the Environment limits and Deployment priority environment profile attributes.
Figure 5: An example of resource isolation using environment profiles
The four environment profiles provide virtual network isolation and user access control among the four departments. The development department environment profile and the testing department environment profile provide resource sharing and, at the same time, provide application VLAN isolation and user access control between the two departments. Remember that the development profile and the testing profile share a common management VLAN because they are sharing a common cloud group. If sharing a common management VLAN is a concern, you might want to split the development and testing cloud groups into two separate cloud groups.
Both software firewall and external firewall components can be used to filter network traffic either within a cloud group or between two cloud groups. Virtual application patterns can configure a firewall plug-in which, by default, locks down all unused ports. Virtual system patterns can use a custom scripting package to configure firewall policy. An example of a multiple-tier workload pattern that uses a firewall to filter traffic from WebSphere Application Server to a DB2 database is shown in Figure 6.
Figure 6. An example of multiple-tier workload pattern with firewall configuration.
Environment profiles can contain more than one cloud group. Deploying vSys patterns across multiple cloud groups can leverage firewalls for increasing the level of network traffic isolation. Figure 7 shows an example of deploying a single virtual system workload pattern across multiple cloud groups using an external network switch.
Figure 7. Deploy a single virtual system workload pattern across multiple cloud groups
Virtual application patterns can only be deployed to one cloud group in the current version of PureApplication System. Deploying virtual application workload patterns across multiple cloud groups requires deploying multiple workload patterns.
In addition to using separate networks to control resource visibility, PureApplication System uses trust domains to create trust boundaries and isolate resources at the REST programming interface level.
Resource isolation via trust domain
The PureApplication System vApp deployment model organizes resources into trust domains to provide management and infrastructure isolation. PureApplication System management software contains a trust service (TS) that issues verifiable security tokens to each trust domain. PureApplication System management software is in a management trust domain.
In the vApp deployment model, resources can only communicate with other resources in the same trust domain. Resources communicate across the trust domain boundary only if a trust relationship is established explicitly between the two trust domains. Trust domains are formed and protected using public key technology.
Figure 8. PureApplication System management trust domain
Every virtual application deployment is in a separate deployment trust domain. Each deployment trust domain has a unique set of deployment security tokens and owner keys. This complete isolation of deployment security tokens and owner keys helps prevent security attacks from spreading to other deployments and to the system management trust domain in the event of a deployment compromise.
As an example, Figure 9 shows a cloud group containing three virtual application deployments. Every deployment is in its own trust domain, which provides isolation from other virtual application deployments in the same cloud group.
Figure 9. Management and deployments isolation by trust domains
PureApplication System provisions a mutual trust relationship with a virtual application deployment trust domain during deployment. The mutual trust relationship is formed by:
- Management software holding a deployment public key so that it can verify REST requests from a deployment, and
- A virtual application deployment holding the management software public key so that it can verify REST messages from the management trust domain.
Trust relationships can be established between two deployment trust domains. This is how a shared services deployment (which is a special case of virtual application deployment) establishes a trust relationship with other virtual application deployments in order to enable those virtual application deployments to use the shared services.
In summary, isolation via trust domain provides the next level of resource isolation above the network-based isolation in virtual application pattern deployment. Even though all vApp deployments in the same cloud group have networking visibility — meaning they can see other deployments on the network in the same cloud group — they cannot communicate with one another unless a trust relationship is explicitly established between the two trust domains.
Resource isolation via access control
In addition to resource isolation via networking, virtual networking, and trust domains, PureApplication System also supports resource isolation via access control.
Workload resource management isolation
PureApplication System management provides workload resource and cloud resource isolation, such that users can only deploy workload patterns to cloud resources to which they are explicitly granted access rights . The fine-grained resource access control enables you to set up environment profiles and isolate cloud resources so that different groups of users are permitted to use a different set of cloud resources.
User access to cloud resources is managed using the environment profiles. Environment profiles specify the set of cloud group resources, including IP groups, resource allocations, and license limitations that authorized users can use for deployment. Users must be explicitly granted read access rights to an environment profile in order to deploy virtual application patterns and virtual system patterns to that environment profile. Workload administrators with full permission roles must have read access rights to cloud resources in order to:
- Create an environment using those cloud resources.
- Grant other users access rights to the environment profile.
- Deploy shared services to the environment profile.
Deployment access isolation
In the vApp deployment model, a deployment agent process runs on each virtual application deployment virtual machine. The deployment agent is a PureApplication System component that performs management functions such as recovery and auto scaling. To perform its work, the agent process must retrieve deployment configuration data and binary code from the PureApplication System management data store. In general, the deployment agent processes have limited authorization permissions, compared to human users' permissions. PureApplication System permits agent processes read access to deployment data belonging to the specific deployment, but not other deployments. In general, a deployment agent is not permitted to modify any deployment data.
PureApplication System user management supports centralized user authentication using an enterprise LDAP user directory server. LDAP users do not automatically become PureApplication Systems users. LDAP users need to register with PureApplication System first. An LDAP user can be registered either explicitly or implicitly. When an LDAP user group is registered, users in that user group are implicitly registered. When LDAP users and user groups are registered, neither LDAP user password nor LDAP user group membership are copied to PureApplication Systems. The user and user group data continue to be managed and maintained in the LDAP directory server.
PureApplication System user management also provides a built-in user repository which enables PureApplication System security to be self-contained. A default user account is automatically created in the user repository, enabling customers to configure and manage the system and to integrate with the LDAP directory server. Additional users and user groups can be created and added into the built-in user repository. A best practice is to leverage the enterprise LDAP directory server for users to keep the number of local user accounts to a minimum. The default account is granted all the security roles. It is a best practice to change the default account name using the CLI command and to change the default password to a secure password as soon as possible to protect from attacks on this well known account.
PureApplication System organizes security roles into five areas of management responsibility:
- Workload administration: Essentially managing and monitoring all management function on the Workload console. Users are automatically granted four sub roles:
- Create new patterns
- Create new environment profiles
- Create new catalog content
- IBM License Metric Tool (ILMT)
- Cloud group administration: Managing and monitoring cloud resources such as cloud groups, IP groups, virtual machines, storage volumes.
- Hardware administration: Managing and monitoring hardware resources, system configuration, events, job queues, and system activities.
- Security administration: Managing security configuration, users and user groups. If a user is also granted the delegation authorization with the full permission role, the user can grant and revoke access rights of cloud group, IP group, virtual appliances, and virtual machines.
- Auditing administration: Managing and monitoring auditing resources.
Most users do not need to have Workload resources or other administrative authority to deploy virtual application patterns or to deploy virtual system patterns. Users are automatically granted resource access rights to the virtual applications and virtual systems they deploy. A best practice is to follow the separation of duties and least privilege security principles, which means granting users, user groups, and administrators the least amount of security access needed to perform their tasks.
Every area of responsibility typically has two roles: a full permission security role that enables users to manage and monitor resources, and a read-only view security role that enables users to only monitor resources. Table 1 describes the authorization granted to the full permission security role of each area. The read-only view role is similar but without any capability to make changes.
|Area of management responsibilities||Full permission security role authorizations|
|Cloud group administration|
Users who have a full permission security role for one of the five responsibility areas and also have the delegation security role can grant and revoke their own security roles to and from other users and user groups. You have the flexibility to designate selected administrators to have the delegation role. The responsibility of security auditing administrators is to monitor abnormalities in user and system activities to detect potential threats, and also to hold users accountable for their actions. Separating auditing administrators from administrators of the other four areas is highly recommended to avoid any conflicts of interest.
Shared services provider security integration
Shared services provide a pre-defined virtual application pattern that is deployed and shared by multiple application deployments, such as virtual applications, virtual systems, and virtual appliances in the cloud. Let's look at security integration with a couple of shared services in PureApplication System, namely the hardware and database monitoring shared services.
A deployer is authorized to view the status of his own deployment using the Monitoring shared services role. Workload administrators are authorized to view status of all deployments, also using Monitoring shared services. The Monitoring shared services roles are special in that they share a common user population with PureApplication System itself. PureApplication System security includes a client programming utility library that provides utility functions for validating authenticity and the integrity of requesters while shielding programmer from security protocol details. Shared service providers can easily leverage the security and trust infrastructure to build single sign-on solutions with seamless security role-based authorization integration.
Shared services provider security integration is entire policy driven and requires administrative role authorization. PureApplication System will provision the trust relationship during the deployment of shared services. Deploying a shared service requires the privileged Workload administration full permission security role. Shared services providers can request additional security roles via policy assertions. For example, if a monitoring shared service needs to monitor hardware status, it can specify a policy assertion to request a Hardware administration read-only view security role. In this case, the deployer of this shared service will need to have the Hardware administration read-only view role and the delegation role, in addition to the Workload administration full permission role in order to deploy the shared service.
In summary, the shared services security mechanism demonstrates the design philosophy that using the security infrastructure must be simple, and that:
- Shared service security integration is built upon the security and trust infrastructure.
- Shared services security role provisioning is consistent with the security role delegation policy.
- The security client utility library completely shields the shared services developer from the underlying security and trust infrastructure.
PureApplication System supports three deployment patterns: virtual appliance, virtual systems, and virtual applications, ranging from the simplest to the most sophisticated in terms of management infrastructure involvement. Deploying a virtual appliance is essentially deploying a virtual machine image. The deployer bears all the responsibility to secure the application run time environment on the virtual machine. The virtual system pattern puts the responsibility for topology management on the deployer. In terms of security, vSys patterns are essentially the same as virtual appliances, where the deployer bears the responsibility to secure the application run time environment. A virtual application pattern is expertise in the form of a predefined collection of software applications, application platforms (such as WebSphere Application Server), software component dependencies (such as DB2, LDAP), and a set of Quality of Service policies that govern the run time behavior of the application once it is deployed. In terms of security, the virtual application plug-in framework provides a secure execution run time environment that can be further customized.
A virtual application deployment execution environment has these security controls to minimize the attack surface:
- A deployment runs in its own separate trust domain.
- Virtual machines of a deployment communicate among themselves within the deployment boundary.
- By default, the virtual application firewall plug-in locks down all ports, except the SSH port and the PureApplication System management ports.
- SSH requires RSA key-based authentication and data encryption with 2048 bit key size.
- OS root account login is disabled.
- Deployer SSH login to a non-root user account.
- WebSphere Application Server remote management interfaces are disabled.
- WebSphere Application Server security is enabled with a software generated admin account password.
- WebSphere Application Server LTPA keys, key store, and trust store are stored in PureApplication System storage for use by all instances of a deployment.
- WebSphere Application Server is configured to use a built-in file-based user repository and will use the LDAP user repository if a link to an LDAP server is in the pattern.
Applications can use vendor and custom security solutions. PureApplication System provides a virtual systems scripting package and a virtual application plug-in framework to enable users to create new patterns (or to modify existing patterns) to integrate custom security solutions. WebSphere Application Server provides standard authentication service extension points (such as the User Registry adapter, Trust Association Interceptor, and JAAS login module), and authorization service extension points, such as Java Authorization Contracts with Containers (JACC).
Managing security fixes
Emergency fixes address OS, middleware, and application product issues and vulnerabilities that can be exploited by users, either accidentally or intentionally, to cause damage to system resources. The PureApplication System Emergency Fixes panel provides utilities that helps manage and apply emergency fixes to deployments. An emergency fix contains a service.xml file, which specifies the virtual image versions that this emergency fix is eligible to be applied to, and a severity level field that provides a quantitative description to represent the urgency for applying this emergency fix.
Emergency fixes are provided by IBM or by other vendors and can be download from IBM Fix Central. You can also create your own emergency fix. Emergency fixes are loaded into PureApplication System using the Workload console. Emergency fixes are uploaded by the management software to RAID disk storage via the management network. The process of applying emergency fixes to deployed VM is automated.
- In the case of vApp, the agent process on each deployed VM transfers the images via the fibre channel disk network to a VM and then applies fixes.
- In the case of vSys, management software transfers images to VMs via the disk network, stops all the servers, applies the fixes, and then restarts all servers.
Management system protection
To help protect the integrity and confidentiality of the management system, PureApplication System compute nodes encrypt the data and binary images on the hard disk and solid state disk using the Advanced Encryption Standard (AES) encryption algorithm with 256 bit key size. Encryption keys are not stored on the disk, but are stored instead in the Trusted Platform Module (TPM) on the system management computer circuit board. Configuration data and binary images are not visible to OS users. OS users login to a restricted shell which does not support shell scripts. OS users cannot start or stop OS processes, and the do not have access to file systems.
Service and recovery
The PureApplication System system backup utility supports both complete backups and incremental backups for system recovery use in case of system failure. Backup images are encrypted using the AES algorithm with 128 bit key size to protect data confidentiality. The symmetric key is encrypted using an RSA public key and stored separately from the backup image. You can either import an RSA private key and certificate pair, or you can generate a self-signed certificate and private key of 2048 bit key size. Communications with the external backup image storage server uses SSH to protect confidentiality.
PureApplication System has a built-in system service account that can be used by authorized IBM service personnel to diagnose system issues and to perform low level recovery actions. The built-in system service account is disabled by default and must be activated by users who have the Hardware administration full permission authorization. Once activated, IBM service personnel must request a service account password from the IBM Service Center. This password is valid for a limited amount of time, only up to 36 hours, and can only be used on one specific PureApplication System. This will permit IBM service personnel full access to hardware resources and low level configuration data, and read-only access to cloud group administration information (for example, cloud group, IP group, and virtual machine configuration and status), but will not provide either the ability to change virtual resource configuration, or, more importantly, access to workload resources and data.
IBM PureApplication System significantly improves application deployment time and resource utilization with integrated system, software, load balancing policy, and built-in solution expert knowledge. PureApplication System employs security engineering framework guidelines and industry best practice security principles to help secure the system with multiple levels of resource isolation and security defense. In addition to addressing integrity, confidentiality, availability, and access control, PureApplication System captures comprehensive audit records of user actions, which serve two purposes: to hold users accountable for their actions, and to provide input to forensic analysis to detect security attacks and evaluate the extent of damages.
This article provided an overview of security and resource isolation features in IBM PureApplication System, and reviewed usage scenarios integrating enterprise user management with the networking infrastructure. Hopefully, this information provided will help you address your risk management and security compliance requirements.
Many people contributed to the design, development, and testing of PureApplication System Security and Trust infrastructure. In particular, the author would like to thank John Y Chang, Leo Uzcategui, Ki Park, Yuhsuke Kaneyasu, Douglas Shue, Marcos Lohmann , Bertrand Chiu , Ajay Apte , Mark Li Yi , Rohith Ashok , Roy F. Bradson , Xi Wang , Kin Ueng, Lewis Lo, Patrick Davis, Kristin R. Whetstone , Nico Hao R Li , Ankit Patel, Barbara Vander Weele, Nick Hill , Jose Ortiz, Lin Sun, Marco Ling Lan, Los Liang Wang , Matthew J. Sheard , Matthew K. Vaughton, Mickael Madson, Jay W Warfield, Donald R. Wood , James K. Kochuba , Aaron J Quirk , Iqbal Umair, Christopher M. Laffoon, Tamiko D Watts, Vishwanath Venkataramappa, Wendy Wen Hsu, James Mullineux for their contributions. The author also thanks Ajay Apte, Rohith Ashok, Mark Li Yi, Joe (J.P.) Wigglesworth, Andrew Grohman , Scott J. Tunley and Rama Vykunta for their review comments.
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 to attack others. No IT system or product should be considered completely secure and no single product or security measure can be completely effective in preventing improper use or access. IBM systems and products 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 systems and products are immune from the malicious or illegal conduct of any party.
- Redbook: Implementing Systems Management of IBM PureFlex System
- Redbook: IBM PureFlex System and IBM Flex System Products and Technology
- Redbook: IBM Flex System Networking in an Enterprise Data Center
- IBM PureSystems Centre
- Redbook: Security in Development: The IBM Secure Engineering Framework
- IBM Security AppScan Family: Application Security and Compliance Solutions for Web and Mobile product information
- Information Security Illuminated, Michael G. Solomon and Mike Chapple, Jones and Bartlett Publishers © 2005
- Security Architecture: Design Deployment and Operations, Christopher M. King, Curtis E. Dalton and T. Ertem Osmanoglu, McGraw-Hill/Osborne © 2001
- Security Engineering: A Guide to Building Dependable Distributed Systems, Ross Anderson, John Wiley & Sons © 2001
- Computer security, Dieter Gollmann, edition 3, Wiley © 2011
- HIPAA Security Implementation Version 2.0, SAS Institute, SANS Institute © 2004
- Protect your IT systems with next generation security – How trusted computing from IBM PureFlex System secures your systems against emerging threat profiles, IBM PureFlex, November 2012
- Managing application runtime environments in IBM PureApplication System
- IBM developerWorks Cloud computing
- IBM developerWorks WebSphere