Security a Major Imperative for an Service-Oriented Architecture

Transcription

1 Security a Major Imperative for an Service-Oriented Architecture HP SOA Security Model and Security Assessment Viewpoint Paper

2 Table of contents Introduction SOA security challenges Developing an SOA security policy Data security in an SOA Supporting multiple service consumers and providers How to face these SOA security challenges Security principles Looking through an SOA window Confidentiality Integrity Availability Enabling SOA security Identity and access management XML firewall security brokering Security broker/proxy web service manager and XML gateways Confidentiality support Integrity support Availability support Public key infrastructure services Penetration/intrusion detection and monitoring Federated security The WS-security standard Security assertion markup language XML encryption XML signature Deriving an SOA security logical architecture HP SOA Security Maturity Model HP SOA Security capabilities The HP Security Common Services stack Public key cryptography and infrastructure services The Enterprise Services Management Platform stack Identity and access management Extended security services Penetration testing and intrusion detection testing Enterprise security event management The HP application security development lifecycle framework Regulatory compliance Conclusion

3 Service-oriented architectures (SOAs) deliver a number of recognized advantages, including more open and efficient access to key enterprise services, applications, and information. But the very openness of an SOA also creates unique and significant security challenges for organizations. In this paper, we examine crucial SOA security issues including confidentiality, integrity, and availability and review the technologies, tools, standards, and architectures used to ensure SOA security. This paper also discusses the HP SOA Security Model and HP SOA Security Assessment, including implementation and management capabilities. Introduction Application architecture has evolved over time, from mainframe based systems, to client server architecture, to distributed computing model, to multi-tier loosely coupled architecture, to service-oriented architecture (SOA). SOA approaches an application as a set of independent, but cooperating subsystems or services. SOA is about the consolidation and reuse of software assets, the reduction of infrastructure complexity, and most importantly starting the agility journey by incrementally transforming business processes and IT systems/applications into a set of building blocks called services. The demand for services to help build composite applications in a distributed, heterogeneous environment is greater than ever. The move to adopt an SOA has become key to enterprises that seek competitive market advantages through reusability, agility, and adaptability. Web services are one of the leading enablers of SOA, and have become an integral part of IT systems. Web services can help breakdown technology barriers, and can encourage interoperability with business partners and promote new interaction opportunities with customers. SOA security challenges With the increased reliance on SOAs and their prominent role in critical enterprise systems, organizations need a comprehensive security strategy. Security threats are more prevalent than ever and a security breach can cause serious legal, economic, and corporate reputation issues. SOA security should not be taken lightly, but should be a primary consideration when establishing communications between distributed systems. Developing an SOA security policy Successfully implemented SOA security has to be well-defined, well-planned, and well-implemented. The security model/strategy must be focused around the three basic principles of confidentiality, integrity, and availability. The world of SOA vulnerabilities is a volatile one. There will always be new threats and new ways to combat these threats so a security policy can not remain static. It needs to be agile in its approach to both threats and countermeasures. Another important and often overlooked aspect of SOA security is well defined business agreements, service level agreements (SLAs) and security metrics between service providers and service consumers. They provide a foundation for developing security strategy and governance and can be used as a measuring stick for quality assurance, business monitoring, and SOA management. Data security in an SOA In traditional point to point architectures, data moves from point A to point B, is processed at point B, and the results are returned to point A. Thus, a secured connection between the two end points is adequate to ensure the integrity, confidentiality, and availability of the data. In an SOA environment, data originating at point A may travel through multiple intermediate points before arriving at the ultimate recipient. The subject identity must be provided, and the confidentiality and integrity of the data (in whole or as parts) must be protected and guaranteed from the point of origin to the destination. SOA, therefore, requires additional security components, as well as the adoption of new standards and specifications. 1

4 Figure 1. Confidentiality, integrity, availability and SOA security Locate and prevent rogue services Ensure last mile security in the distributed SOA environment Provide security governance Confidentiality In an unsecured SOA, services containing sensitive data could be exposed without the proper access control mechanisms. Messages sent in clear text could be intercepted and consumed by unauthorized parties for fraudulent or mischievous purposes. An unsecured SOA is also vulnerable to many types of attacks such as denial of service or replay which can adversely affect the availability and/or integrity of the system. Similarly, due to the distributed/loosely coupled nature of SOA, it is virtually impossible to keep track of users and messages in an unsecured SOA. Without a reliable audit trail, organizations cannot investigate security related incidents, diagnose security weaknesses, or meet regulatory compliance requirements. Supporting multiple service consumers and providers In a typical implementation of SOA, service providers may be distributed across security domains, deployed on disparate platforms, and supported by multiple application owners and development teams. The services may also be invoked by multiple consumers across disparate security domains and infrastructures. Thus a successful SOA implementation must isolate service consumers and service providers from the complexities of security in order to: Support multiple authentication providers/methods Keep up with rapidly evolving security standards and regulatory requirements Integrate with multiple authorizations providers/methods Offload developers from security infrastructure coding WSM, XML Gateway, WSS, SMAL, XML Signature, PKI, Federated Security SOA security Consumers Providers Services Data IAM, WSM, XML Gateway, WSS, SAML, XML Encryption, PKI, Federated Security Integrity WSM, XML Firewall, Penetration/Intrusion Detection Availability Ensure consistency of security enforcement across an enterprisewide SOA implementation How to face these SOA security challenges SOA security requires a comprehensive security strategy to address business processes, IT systems, and the transaction and message life cycle. HP recommends an SOA security approach that leverages and enhances an organization s existing security infrastructure components with emerging but proven technologies, standards, and specifications. This allows organizations to centralize the creation and management of security policies, while distributing security policy decision points and enforcement points. A Policy Decision Point (PDP) is the logical entity to control policy decisions using the available security context. A Policy Enforcement Point (PEP) is the logical entity that enforces the policy decision. For example, when an employee swipes their access card at an entry door, the card reader is the PEP, the data on the card is the security context, and the system that determines the access is the PDP. HP leverages our partners and preferred vendors tool sets to address these issues. Without a carefully planned implementation, organizations can easily be overwhelmed by the complexities of SOA security, which can negatively impact deadlines and the applications security. With a solid team of SOA security professionals, HP assesses your security infrastructure using the well defined HP SOA Security Model. This assessment defines a road map to extend your existing security infrastructure, then adds additional components and embraces new standards as necessary. Security principles Looking through an SOA window At a conceptual level, information security is built on three basic principles: confidentiality, integrity, and availability. In an SOA security environment, these basic principles are unchanged, but require a paradigm shift in focus and implementation. The following section describes the HP view on each of these key security principles. 2

5 Figure 2. Encryption and security context Transport Layer Point-to-Point Security Encrypted Data Encrypted Data Consumer Service Intermediary Message Layer End-to-End Security Encrypted Data Consumer Service Intermediary Confidentiality Confidentiality focuses on the protection of the information against unauthorized access. Confidentiality in an SOA is enabled through access control and encryption. Access control is supported by the WS-Security (WSS) standard, and ensures that a properly authenticated subject (representing a user or an application), has the authority to access an object or service operation. Encryption applies a mathematical algorithm key to a block of clear text to produce an unreadable block of text, or cipher text. There are two forms of encryption applicable to a message: Transport Level Encryption (TLE) and Message Level Encryption (MLE). TLE leverages the secure sockets layer protocol provided by application servers, and protects the message as it travels through the network. TLE, however, creates a window of opportunity for unauthorized access, because the data is decrypted into clear text as it travels though application servers. MLE leverages the XML encryption standard to encrypt either the entire message payload or a portion of it. The data is decrypted only by the intended recipient of the message and it is not accessible by intermediaries. This adds an additional level of confidentiality assurance. Figure 2 above illustrates the difference between TLE and MLE. While TLE may continue to be perfectly adequate for many applications, MLE provides additional security. For example, MLE allows a credit card number or other sensitive portion of the message to stay encrypted as it travels through the SOA fabric and until it reaches the authorized recipient, e.g. VISA or Master Card, which has the key to decrypt it. MLE is currently supported by most web service infrastructure vendors, including Agility Alliance partners. Although MLE provides additional protection, it should be used selectively as it adds significant overhead time to the message processing time. 3

6 Integrity Integrity addresses assurance of quality and reliability of information within an SOA. Integrity is enabled by access control mechanisms and the signature generation/verification features enabled by the XML signature specification within the WSS standard. XML-signature uses a mathematical algorithm to generate a fixed length message digest from a clear text message. The message digest is encrypted using the sender s private key. When the message is sent to the recipient, it will use the sender s public key to decrypt the message digest. This process guarantees the sender s authenticity, and thus supports nonrepudiation because only the sender s private key can perform the encryption. The message contains the clear text message and the digest. The recipient will then verify the integrity of the message by running the same hash algorithm to produce another message digest. If the sender-generated and the receivergenerated message digests match, the message integrity is confirmed. Integrity is typically used in conjunction with encryption to preserve message integrity and confidentiality. Using XML-signature, sections of a message (or the entire message) may be signed, and the signature verification steps should be properly recorded in order to support non-repudiation requirements. Availability Availability focuses on minimizing threats and vulnerabilities to maintain normal system operations in an SOA. Without proper intrusion detection/xml filtering controls, an SOA is at significant risk due to the character-based nature of its underlying XML technology. Specialized XML gateways/xml firewalls can boost availability by performing detailed XML message inspections without incurring significant overhead. XML gateways/xml firewalls are equipped with signature patterns that quickly detect and prevent a malformed XML message from reaching its destination. Some signatures prevent multiple denial of service attacks such as buffer overflows, while other signatures prevent unauthorized access to data through techniques such as SQL injections. HP has deployed XML gateways to several of its clients, typically in the perimeter of a trusted network, to prevent external attacks. Due to their distributed nature, SOAs also require a well defined disaster recovery process, business continuity planning, legally binding business agreements, automated tools, and strong governance. Enabling SOA security Reliable SOA security requires appropriate tools, technologies, standards, and specifications. To bridge the gap between traditional application security and SOA security, HP recommends a comprehensive SOA security approach that leverages, extends, and complements your existing security infrastructure. Identity and access management Identity and Access Management (IAM) enables the administration and enforcement of confidentiality, including authentication and authorization access rights and access restrictions. Traditionally, authentication is provided by directory services, while authorization and single sign-on (SSO) are provided by access management suites. Role Based Access Control (RBAC) effectively manages authorization via directory services for defining roles, and the IAM infrastructure is used to define objects or resources and the corresponding role entitlements. Complementary components like Web Service Manager (WSM), XML gateways, and Security Common Services can extend the effectiveness of an IAM to support policy based security, including decision and enforcement, federated security, and other advanced requirements. These components are discussed in detail below. By enabling token-based authentication and authorization, the crucial IAM component helps to avoid maintaining credentials at multiple locations in the SOA. HP can help integrate traditional IAM with WSM, thus extending the trust model beyond security domains, and offloading security related complexities from the service providers and application owners. If a directory service exists within the enterprise, it should be leveraged as one of the authentication providers. HP recommends the deployment of an Lightweight Directory Access Protocol (LDAP)-compliant directory service to streamline integration with other security components. 4

7 XML firewall security brokering Conventional firewalls are not designed to inspect the contents of XML messages to detect and prevent denial of service attacks based on the business activity, replay attacks, buffer overflows, dictionary attacks, intrusions, and other sophisticated security threats. HP recommends the use of XML firewalls at the perimeter (where the additional features of a XML gateway are not required) to protect against such threats. XML firewalls thus support the security principle of availability. In order to protect the SOA service providers from malicious content embedded within the service request /response, the SOAP/XML messages must be parsed. Filtered content is checked for malicious qualities based on the rules defined in the rule base, which is persistent in the database. As part of the filtering process, the structure of the request or XML document can be validated against a set of schema registered with the extended security service. Data output can also be sanitized via Extensible Stylesheet Language Transformation (XSLT) before it reaches the web service consumer. Security broker/proxy web service manager and XML gateways Imagine implementing the security and management within the code of each deployed service, or having multiple implementations of services to support various authentication methods/providers, authorization methods/providers, and protocols. This approach would dramatically increase development and maintenance costs, increase the risk of security vulnerabilities and would thus undermine the native benefits of an SOA. Instead, by abstracting security and management functions out of the service implementation, by delegating those functions to a proxy or intermediary, development and maintenance costs can be dramatically reduced. This approach also isolates the service consumer and service provider from underlying protocols, standards, and technology, and hence increases interoperability and reuse. The security proxy prevents direct access to the service hosting platform, thus addressing the key security issues in a distributed and decoupled environment. A Web Service Manager (WSM) is a specialized software suite that functions as the security intermediary to address policy management, policy enforcement, auditing, monitoring, rules based routing, and other important SOA security and operational issues. WSM supports all three principles of SOA security: confidentiality, integrity, and availability by providing features such as: Authentication and authorization brokering Transport level and message level encryption/ decryption. XML signatures and digital certificates XML inspection/validation, auditing, load balancing, and monitoring Security Assertion Markup Language assertions/ security tokens eliminate the need to query the authentication provider directly. Collection of metrics for SLA tracking and enforcement Service virtualization and load balancing Detection and quarantine of rogue services XML gateways are specialized appliances that provide similar functionality, but as security- and managementoriented extensions of XML firewalls, these gateways provide superior performance for transformations, inspection, filtering, message encryption/decryption, and other XML processes. When compared to software-based WSM, XML gateways are weak in SLA monitoring and tracking functions and do not provide end-to-end visibility. In fact, WSM and XML gateways offer overlapping and complementary capabilities. HP recommends an SOA security approach that deploys XML gateways at the perimeter, and WSMs behind the firewall, thus maximizing the flexibility of the WSM and the performance capabilities of XML gateways. HP has partnerships with the market leaders in these areas, and thus can provide tremendous value in an SOA implementation. 5

8 Figure 3. SOA security brokering Web Service Security Broker/Proxy Consumer-Side Proxy Control/Processing Policies Provider-Side Proxy Rules Consumer Authentication Provider/Broker Authentication Provider/Broker Auditing/Monitoring Alerts/Notifications LDAP Support IAM Support Rogue Service Detection/Prevention Authentication Broker Routing Auditing/Monitoring Service Provider Malicious Attack Protection XML Inspection Schema Validation XML Filtering Load Balancing Failover Figure 3 is a logical representation of WSM and XML gateway and how they enable SOA Security brokering. Below is a description of how these features support the security principles. Confidentiality support The consumer-side broker element of WSM/XML gateway, the broker authentication and authorization, provides authorization and supports transport- and message-level encryption/decryption by leveraging built-in support for Public Key Infrastructure (PKI). The security broker isolates the consumer and provider from the authentication providers/methods and transport/ message encryption methods used at both ends. The control and processing provides security policy enforcement for access control and other features. Policies can be based on one or more reusable rules, which can be based on user profiles, message content and/or consumer context. Lightweight Directory Access Protocol (LDAP)-compliant directory services ensure easy integration with the IAM solution, while supporting multiple authentication and authorizations providers. The provider-side security brokering uses one of the supported authentication mechanisms to authenticate with the service provider. To enable last mile security, HP recommends using an agent-based solution or IPSec security to ensure that the service containers can be reached (for service invocation) only from the known, and approved nodes. Rogue services are the services that are not managed or identified as valid and approved services. Rogue services are silent killers that can make confidential information vulnerable to unauthorized consumers. This can result from maliciously planted code or services unintentionally made available from improper security and governance. HP recommends that SOA implementations use tools like WSM and XML gateways, along with governance procedures to identify and prevent rogue services. Integrity support The security broker and control processing elements support XML signatures. WSM/XML gateway offloads the signature creation and verification work from the service consumers and service providers. The security broker can also ensure the integrity of the data though access control mechanisms. Availability support The built-in XML firewall supports availability by protecting against malicious XML attacks and by enabling XML inspection/filtering/validation. The XSLT engine can be used to sanitize/transform the message before and/or after policy evaluation. The policies can be used to raise alerts for notifications and for auditing. Public key infrastructure services A PKI enables Internet users and other unsecured public networks to securely and privately exchange critical and sensitive data through a public and a private cryptographic key pair, obtained and shared through a trusted authority. Secure keys used for authentication, encryption, and digital signing must be managed and protected from unauthorized access. A key management policy must be established to define the length of time keys are kept, how often they are recycled, and rules for protecting keys. 6

9 A shared or dedicated PKI infrastructure plays a critical role in ensuring confidentiality and integrity in an SOA environment. These public/private key pairs enable strong authentication, and their special mathematical properties support XML message encryption/decryption, transport layer data encryption/decryption, and document signing. Penetration/intrusion detection and monitoring Penetration/intrusion testing involves sanctioned and simulated attacks designed to identify and exploit potential security and operational vulnerabilities/flaws. This helps the business analyze operational impacts of an attack and suggest appropriate solutions. An SOA simplifies the security infrastructure by externalizing security management, but because components are shared and reused by multiple services, an SOA can also magnify security-related flaws and vulnerabilities. SOAs also encourage interoperability, decoupling, and the bridging of organizational, and enterprise boundaries. For these reasons, reliable intrusion detection can help deflect malicious threats and support optimum availability. Both black box (infrastructure-blind) testing and white box (infrastructure-informed) testing can be used to ensure maximum penetration/intrusion detection and monitoring. Federated security Federated Security is a trust mechanism that allows two or more organizations with different identity repositories to exchange messages using pre-defined arrangements for access control. Federated security encompasses the security principles of confidentiality and integrity. In federated security, the security administrations or trust realms are called domains. A typical domain might include a single organization, and a collection of trusted domains is a federation. The level of trust may vary, but typically includes authentication and authorization. A service that issues security tokens is called a token authority, which issues evidencebased assertions that are used to form trust brokering relationships between domains. A WSM or IAM can serve as token authority. This federated approach eliminates the need for consumers to maintain multiple sets of credentials or one set of credentials at multiple service sites. This powerful feature allows implementations across organizational and enterprise boundaries. In order to implement true federated security, HP recommends integrating the WSM/XML gateway solution with the existing IAM solution. The HP Integration and SOA Services offering and the applications portfolio development organization have developed a comprehensive collection of patterns and scenarios for SOA security. The WS-security standard WS-Security is an all-encompassing web services security standard that has been ratified by the Organization for the Advancement of Structured Information Standards (OASIS) consortium. WSS leverages existing security standards and specifications (such as Kerberos, X.509, SAML assertions, XML digital signatures, and XML encryption, etc.) to define a framework to embed the security information within an SOAP message in a transport neutral fashion. WSS defines an XML element called Security inserted in the SOAP header. This security element contains identity, integrity, and confidentiality information, and can be preserved over multiple hops when the message is queued or stored. It gives the receiver the information necessary to decrypt and validate the message. HP recommends WSS as a key standard to support confidentiality and integrity in an SOA security architecture. HP has successfully verified support for the WSS standards through our Agility Alliance partners. The following are key specifications/standards in WSS. Security assertion markup language SAML is a XML-based standard by OASIS that provides a framework for exchanging authentication and authorization data between security domains. In a distributed SOA, users may be authenticated by different authorities, domains, and methods. SAML provides a standard format to express authentication, user attributes, and the protocols to send and receive the information. This plays a key role in identity federation. XML encryption XML encryption is a World Wide Web Consortium (W3C) recommendation for encrypting data into an XML element. The message is in XML format, but the content is not apparent because it is garbled by an encryption algorithm. The benefit is that the system that receives the message can either decrypt it if it has the key, or leave it intact and process it as an XML without relying on custom or proprietary messaging standards. XML encryption allows parts of the message to be encrypted, and different public keys can be used to encrypt different sections of the message. 7

10 Figure 4. SOA security logical architecture Confidentiality Data Integrity Availability Enterprisewide Leveraged Security Services Directory Services Identity and Access Management/SSO PKI Infrastructure Services Penetration, Intrusion Detection and Monitoring Services Security Contract/ Standards Brokering Service Providers Consumers Extended Security Services XML Message Filtering/Validation Security Policy Enforcement Service Containers Application/Data Owners WS Security Legacy/Enterprise Applications, Information Sources, Data Sources Federated Security This enables enhanced message-level security where a certain portion of the message can only be decrypted by the node that has the corresponding private key. This powerful feature allows organizations to meet various regulatory compliance requirements. HP recognizes XML encryption as an effective way to ensure confidentiality in an SOA implementation. XML signature XML signature is a W3C recommendation for digitally signing an XML document using XML syntax. Signatures can support non-repudiation by notifying the sender a particular transaction occurred or that a particular message was received. For example, if a service provider can validate a consumer s signature on the SOAP message when a service was invoked, the consumer cannot repudiate (deny) the transaction. XML digital signatures play a critical part in SOAbased Application Service Provider (ASP) or Business to Business (B2B) services models. Either the entire XML message or a part of the message is processed using a special algorithm that generates a unique message digest. This message digest is then encrypted using the sender s private key and included as a new XML element or a XML signature along with the original XML message element. The receiver then uses the corresponding public key to decrypt the message digest, and compares it with a message digest recreated by running the same algorithm on the original XML message element. If the signed message element was altered in transit, the message digests will not match. Thus, XML signatures support integrity authenticity of the original author, and non repudiation. Deriving an SOA security logical architecture Figure 4 shows a typical SOA security logical architecture infrastructure. HP recommends a phased approach to eventually achieve the desired end state. 8

11 Figure 5. EDS SOA Security Maturity Model SOA Security Maturity Model Level 5 Agile: Standards and processes are very well defined and robustly implemented. Thus, adoption of new technology standards and regulatory requirements are proactively planned activities and not re-actively forced mandates. Level 4 Measured: Centralized mechanisms to create, manage, and deploy security policies across the enterprise. The second feature involves the adoption of the SAML standard for federated identity support. Level 3 Adopted: Wide adoption of the WS-Security standard for encryption, signature, authentication, and authorization support. Service Intermediaries such as XML Gateways and Web Services Management products are also introduced. Level 2 Applied: Commitment from organizations to build and deploy SOAs; however, there is no cohesiveness or consistency on any standardized approach to handle the security aspects of the new applications. Level 1 Explored: Infrastructure in place and is geared toward providing security for applications only. Existing services do not play a role in providing any strategic solutions. Services are responsible for implementing any security requirements. HP SOA Security Maturity Model One of the key components of HP SOA Security Model is the SOA Security Maturity Model (see Figure 5), is that it is used to assess the client s SOA security posture and to move the organization towards a specific, welldefined maturity level. HP performs an SOA Security Assessment to gather detailed security information, create a road map to analyze the maturity model, and then perform an extensive gap analysis. For each of the levels, the Security Model provides guidance on Best practices to improve the security stance at the assessed level Implications and security risks that must be assumed at the assessed level Roadmap to improve the security posture of the enterprise and bring it to the desired level of the SOA Security Maturity. At present, most organizations are using web services for simple point-to-point integration and have simple security requirements. As these organizations move toward a more mature SOA model, they will need a solid and robust Security Model. Because a reliable Security Model is built on an organization s existing security infrastructure, it is not possible to come up with a one size fits all model. All of the security concepts, including standards, tools, and technologies and the relationships between those concepts are defined in a separate but complimentary SOA Security Conceptual Model (CM) document. 9

12 HP SOA Security capabilities HP has established several key capabilities to facilitate the security aspects of an SOA. Listed below is a summary of these capabilities: The HP Security Common Services stack Shared security is currently being addressed through the deployment of third-party point solutions. Most projects include security functionality in their requirements. As there is no standardized way for application developers to satisfy these requirements at design or construction, developers must create vendorspecific logic to interface directly with the point solution. Should the vendor Application Programming Interface (APIs) change, the developers must adjust the API entries in their code. If a new security product is deployed, additional design, development, and regression testing will be required. The HP Security Common Services Stack is a reusable, run-time environment that supports authentication, authorization, administration, and user provisioning. The solution supports a multitenancy environment, where each client application has the ability to orchestrate specific business processes with a number of identity management point solutions. The HP Security Common Services Stack is leveraged through offerings and application development organizations that support HP clients worldwide. Public key cryptography and infrastructure services HP has its own identity assurance system that includes a public key infrastructure. This solution includes processes and tools for the issuance and revocation of digital certificates, and is used to support multiple forms of encryption and to support digital signatures. HP has developed comprehensive processes and procedures to implement PKI for its clients. HP, led by Information Assurance, has acquired exceptional experience in PKI through the Security in Open Systems Technology Demonstrator Program (SOSTDP). Our expertise covers: PKI architecture and design PKI policy PKI system integration Legal aspects of PKI and cryptography The Enterprise Services Management Platform stack The Enterprise Services Management Platform (ESMP) is a leveraged, management platform that controls provisioning, discovery, routing, run-time governance, policy management, business process visibility, monitoring, and security for web services. ESMP provides the infrastructure to support the registry and run-time environment that manage Web services in an SOA fabric. The main components of the architecture are a WSM product and a Universal Description, Discovery, and Integration (UDDI)-compliant registry product. Enterprise systems, such as identity management, can be further leveraged to support the platform. 10

13 The primary capabilities of this architecture are: 1. The ability to effectively manage a network of web services. 2. The ability to provide business and operational visibility into the usage and health of the web services network. 3. The ability to discover and deploy web services in the network. Identity and access management HP offers significant experience in full lifecycle, managed security services for IAM-enabled applications development and deployment. HP is at the forefront of commercial and government IAM implementations, and our experience covers the full range of skills necessary to satisfy the requirements of the program. HP offers managed IAM services to our clients in all industries across the world through our state-of-the-art facility. HP provides the skilled technical expertise to design, implement, and manage the solution through its IAM capability. HP provides hosting services to control, manage, and maintain a client s outsourced IAM environment. Outsourcing the IAM implementation through HP allows clients to focus on their core business. By using HP managed services, clients benefit tremendously from our extensive background in integration services. HP provides these IAM services as part of overall IT projects, and integrates IAM capabilities into business applications. HP has been providing best practice solutions in identity management since the concept s inception. These solutions include authentication, authorization, user access rights, single sign on, administration, and integration, where applicable, incorporating both legacy systems and leading-edge technologies. Extended security services HP personnel are trained and experienced in designing, implementing, integrating, and maintaining WSM/ XML gateways, and other extended services components. HP works closely with our Agility Partner s product specialists and has institutionalized successful SOA security practices across the enterprise and its clients. To maintain its knowledge of emerging SOA Security standards, HP has deployed multiple environments where engineers and partners can test drive the functionality and value these standards bring to the HP portfolio. Penetration testing and intrusion detection testing Compliance assessment and reporting (CA&R) penetration testing uses various tools and techniques to remotely access a system and/or application under controlled conditions. Penetration tests are used to discover weaknesses in a site s security policies and configuration. Once the weaknesses have been identified, they can be remediated before they are exploited by a malicious attack. Intrusion Detection Services (IDS) ensure that an organization s networks and host systems are protected and remain operational. IDS host- and network-based managed solutions include: Design Installation and testing IDS fine-tuning of high alerts 24x7 monitoring of high alerts Alert analysis using Computer Incident Response Team (CIRT) resources Version control of IDS tools Steady state/production support operations Enterprise security event management HP Enterprise Security Event Management (ESEM) is a collection of services that provides near real-time security information management to ensure the highest level of network security. ESEM can be implemented in a leveraged model combined with HP global ESEM infrastructure, or as a non-leveraged customer specific solution. ESEM includes a suite of tools and processes that can be implemented to help your organization comply with certain industry/government security standards (i.e. HIPAA, Sarbanes-Oxley, GLBA, SB1386, and PCI). The HP application security development lifecycle framework The ASDLF is a set of processes, procedures, and tools that enable the development and validation of secure code. ASDLF is built into the lifecycle approach because security is another facet of quality and like quality, security must be built into the application, not tested at the end of the development cycle. As with any bug found earlier in the lifecycle, it is less expensive to address security issues early in the process. 11

14 The ASDLF improves application security by assisting developers in the creation of secure source code, that has only known potential security vulnerabilities based on the information at the time of development. ASDLF also improves application security by using test groups, application scanning, penetration testing tools, and processes to conduct vulnerability testing. Security team reviews also validate the security of the code. Regulatory compliance HP SOA security approach can help clients keep up with rapid changes in technology and with regulatory standards such as VISA PCI and HIPAA. There are typically a number of ways to achieve regulatory compliance, and organizations should select the best approach by working closely with regulatory experts and third-party auditors. Conclusion Given the distributed nature of the SOA infrastructure, distributed policy enforcement decision points, and central policy creation/maintenance points are key to a successful SOA security program. An SOA security infrastructure should also be continuously monitored and measured against established criteria. To realize the benefits of an SOA and avoid any security compromise, the traditional Security Model must be leveraged and integrated with industryaccepted technologies, standards, and tools. In this model, service security should be externalized to IAM and WSM tools whenever possible. To make informed decisions on both message- and transportlevel security issues, organizations must understand both the business and technical requirements of service security. Organizations should also understand that, from a broader perspective, governance is a key to the success of an SOA, and security is a core component of governance. For more information on SOA, please visit 12

15 About the authors Ajay Tipnis Ajay Tipnis is an enterprise consultant in HP Best Shore services delivery & operations organization with more than 17 years of multi-industry experience and a proven track record in implementing service-oriented architecture (SOA) and enterprise portal architectures. He is responsible for providing technical and strategic leadership in implementing SOA Security and Web service management architectures. Being an evangelist and core member of key SOA initiatives, he has received many prestigious excellence awards for his innovative thought leadership. Ivan Lomelli, CISSP Ivan Lomelli is a consultant architect with the HP consulting services organization with more than 20 years of application development experience. For the last few years, he has been engaged with the HP portfolio organization in the area of SOA Security. His work has involved the architecture and certification of Identity and access management stacks, the creation of the HP SOA Security Model, and the security assessment of several HP offerings. 13

16 Technology for better business outcomes To learn more, visit Copyright 2009 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA2-9322ENW, December 2009