Security Gateway Buyer s Guide

Transcription

1 white paper Security Gateway Buyer s Guide Paper Focus: Common enterprise use cases that can benefit from using a Security Gateway architecture Types of security capabilities that an enterprise can leverage in a Security Gateway model Deployment, cost and complexity tradeoffs Checklist of concerns for prospective buyers A sample detailed RFP template can be downloaded at download/securitygateway_ BuyersGuide Author Gunnar Peterson Industry Security Expert Managing Principal at Arctec Group Abstract If you re currently evaluating Security Gateways, this guide will provide the analysis and decision support that will enable you to make an informed choice. The first two sections describe Security Gateways Security Architecture Capabilities and the common business use cases where they re deployed. The following sections of the guide contain tools you can use to identify the right fit for your security architecture based on business requirements, cost, and complexity.

2 Security Gateway Buyer s Guide Security Gateway Buyer s Guide...1 Abstract...1 Executive Summary...3 Use Cases...3 Use Case 1. Enterprise Integration...4 Use Case 2. ESB Security...5 Use Case 3. B2B Security...6 Use Case 4. Cloud Service Brokerage / API...7 Use Case 5. Mobile Web Services...8 Security Architecture Services Problem Statement...9 Communication Channel Security Services...9 Transport Encryption...9 Transport Authentication and Integrity...11 Message Security Services...11 Identity & Access Management...12 Security Policy Lifecycle...13 Message Processing...14 Systems Management...15 Deployment Options...15 Detection Services...16 Audit Logging...17 Threat Protection...17 Where to Go From Here...19 References & More Information

3 Executive Summary Security is no longer simply an infrastructure concern, it has moved up the stack into the application and data layer. Increasingly the reality of delivering security architecture that will both satisfy auditors and stop attacks, means systems that are integrated to applications, web services, and identity management systems. Security Services This paper is aimed at IT and security professionals who are considering ways to bolster their application and data security architecture with a Security Gateway. These systems offer a number of interesting opportunities for the Security Architect, enabling new ways to deliver security services to the enterprise. Security Gateways offer enterprises a critical margin of safety. Most enterprise software is built to accomplish business functional goals, however Security Gateways are designed to prevent failure, taking failure modes, particularly security failure modes into account throughout the lifecycle. Security Gateways are purpose built, engineered with security in mind as a primary goal. Use Cases As with any technology, Security Gateways should be considered in the context of the business use cases that they enable. A common challenge in Security Architecture is that business use cases describe the functional flows in the system, and what should happen for the business to accomplish its goals. However, use cases must be supplemented by non-functional requirements like security architecture requirements, to synthesize both what should happen (functional flows in use cases) and what should not be allowed to happen (security requirements). From a Security Architecture perspective, the combination of these two viewpoints delivers the business context found in the use cases and aligns that context with security and risk management goals. This enables the security architecture to answer specific questions, including: How do I scale, manage, and broker Cloud APIs to interact with on prem apps and 3rd parties? How do I enforce consistent security policy in a highly distributed system like SOA? How do I deliver security services across organizations, as in B2B integration scenarios? If my business is moving toward Cloud Computing models such as Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS), how does my security architecture need to change to handle this? What special security requirements are required to govern mobile applications and mobile web services? These issues challenge many Information Security, Application Development and Enterprise Architecture teams today. The solutions must be answered in a costeffective way that enables use cases to be realized from a business perspective, and to meet the security policies and risk management decisions that are reflected in the security architecture. In this section, we examine some common business Use Case scenarios and drill down on what role the security gateway can play to deliver security services. 3

4 Use Case 1. Enterprise Integration Most Enterprise Architectures contain a myriad of technologies from the latest and greatest to back-end legacy systems. Heterogeneous systems are not an exception in the enterprise, they are the rule. It s commonplace for Enterprise applications to be layered. These layers often have cutting-edge technologies at the Web layer to provide web presentation and distribute content, legacy back-end data and resources that store and manage data, and sophisticated middleware systems that cache content, provide messaging services and implement business rules. The challenge to security is clear: Deliver security services that enable consistent security policy enforcement across a wide array of runtime constituents. Web Services are the predominant pattern used in Enterprise integration today. Security services for Web services-based integration that connect to disparate technologies like Oracle and Microsoft stacks must be able to: Mediate access to the Web Services message exchange Mediate access without compromising Quality of Service (QOS) and availability Integrate to the specific message exchange patterns used (such as Request-Reply, Publish-Subscribe), through either the Service Endpoint and/or the network layer. Figure 1: Enterprise Integration Requires Integrating Disparate Security Models.Net Container Rich Client Security Weblogic Container Web Service Security WCF Container REST Service Security Centralize Security Policy Enforcement & Managment Tomcat Container JEE App Security 4

5 Use Case 2. ESB Security Enterprise Service Bus (ESB) and SOA provide enterprises an architecture that allows for highly distributed systems. The business goal in many ESB and SOA use cases is to segment work and deliver that work from where it s most cost-effective. This development manifests itself in today s global supply chain and support through networked applications that publish and subscribe to data and events on an ESB. ESBs deliver three main architectural benefits: Virtualization: The ESB s message layer using message exchange patterns like Publish-Subscribe, the service endpoints that implement the publish and subscribe methods must only implement an interface to the ESB. This virtualized interface implementation gives the system the access that s required without the overhead of directly coupling the systems. Interoperability: ESBs are often used to enable more robust interoperability across technology stacks using asynchronous messaging and caching. Reusability: To facilitate consistent business logic, rules, and policies, ESBs route messages to the authoritative source. In terms of security architecture, ESBs pose similar challenges to standard Enterprise Integration use cases. At a minimum, securing an ESB means factoring in three distinct security models the publisher security model, the subscriber security model and the ESB s security model. In practice, more than three security models may be utilized. The specific security challenges in ESB Security include: Location of the security service Deliver with ESB, Publisher, Subscriber or as a separate interface Consistent access control, and security policy enforcement point for SOA and ESB across a minimum of three security models Publisher, Subscriber, and ESB Separation of Routing Security and Message Payload Security Ability to mediate & transform from SOAP to emerging WOA services such as REST or JSON. Figure 2: Security Gateway Enforces and Manages Security Policy for ESB Messaging Architecture Client Client Client Client Messaging Publish Subscribe Routing Transformation Management Resource Resource Resource 5

6 Use Case 3. B2B Security B2B integration has evolved significantly from the early days of EDI; now there are complex XML-based trading partner networks and hub exchanges, to accompany traditional B2B file transfers and reporting. To drive down cost and reduce errors, businesses have found it convenient to use B2B systems that create deeper linkages across companies. B2B integration adds another dimension to security challenges. With B2B deployments, there are a minimum of two security policies that must be factored in. Even when two companies agree upon messaging protocols, the systems that implement web services, FTP and other protocols for B2B integration must consider how to manage several specific issues for security architecture: Due to infrastructure and operational issues, availability goals and capabilities are not likely to align across B2B exchanges. Failover and retry requirements are implicitly required in the architecture to mitigate this. No matter whether the system runs on passwords, Kerberos, X.509 or SAML, if the systems Key Management is weak it can bring down the latest and greatest access control protocol. Monitoring capabilities are required to manage current state, trouble-shoot errors and respond in the event of security incidents. Figure 3: Security Gateway Enables Secure Business Integration Company A Company B Company C B2B Gateway Services Enterprise Resources 6

7 Use Case 4. Cloud Services Brokerage Cloud architectures like SaaS, IaaS and PaaS all present unique challenges to security architecture. Cloud Service Brokerage is a new term given to the Cloud API control point that manages how your apps are exposed and accessed by internal developers, partners, and other cloud service providers. Specifically, a Service Gateway Cloud Broker scales, secures, governs, and integrates your APIs as they are hosted in or to the cloud. The NIST Cloud Computing Reference Architecture shows these three Service Models (SaaS, PaaS, and IaaS) layered across the Cloud s essential services and a separate role for the Cloud Broker that can work across cloud models. The SaaS, PaaS and IaaS service models offer an important distinction in terms of Security Architecture. In general, the SaaS model offers the security architect the least control of security policy and management of security services, because the SaaS vendor delivers its own model for access control. As such, the SaaS vendor will already have chosen what Figure 4: NIST Cloud Definition Framework security token(s) they will support for authentication and authorization. Then, it s up to the Security Architect to meet the vendor s requirements. In the PaaS and IaaS Service models, the Enterprise Security Architect has more control over security mechanisms and policies, but it s important to remember that the PaaS and IaaS models will always represent some shared responsibility for security architecture, design, deployment and operations. There are several areas where a Security Gateway adds critical security functionality to Cloud models: Attack surface reduction: Opening up Enterprise to Cloud architectures can result in exposing more sensitive data than is in scope. A Security Gateway mitigates some of these risks by mediating access to communication channels, application services and data. A Security Gateway can be used onpremise within a private cloud or in a public cloud deployment as a security gateway at the cloud provider. Cloud Service Brokerages that manage APIs represents the single biggest revenue growth opportunity in cloud computing - Darryl Plummer, Gartner Monitoring and Logging: With SaaS, IaaS, and PaaS, centers of gravity from applications to infrastructure are moved off-site, but the need for visibility is still essential to security event management, risk management and compliance activities. The Cloud enables applications functionality and data to execute in the Cloud, but it s important to be able to report on the five W s who did what where when and how. This level of reporting, even at a summary level, requires a monitoring system that has visibility into the Cloud s on ramp and off ramps. Security Token Services: Enterprise directories like Active Directory and LDAP have proven very effective at fine-grained provisioning access for enterprise users and resources, but your company s Cloud providers likely require different data that may rely on different attributes. Security Token Services (STS) validate enterprise security tokens like Kerberos tickets from Active Directory and issue tokens that are consumed by Cloud providers. Cloud Consumer Cloud Auditor Security Audit Privacy Impact Audit Performance Audit Service Layer IaaS PaaS SaaS Resource Abstraction and Control Layer Physical Resource Layer Hardware Facility Cloud Provider Cloud Service Management Business Support Provisioning/ Configuration Portability/ Interoperability Security Privacy Cloud Broker Service Intermediation Service Aggregation Service Arbitrage 7

8 Cloud API Management: The mantra of reusing existing application assets as services has become established as part of the lingua franca, or common language, associated with Cloud based infrastructure sharing. The key to exposing application functionality is through APIs and this is well understood by developers. While, at first glance, API management might be an old concept, cloud based API management presents a new discipline with added security, visibility, integration, and scale requirements. As applications are shared outside the protective firewall to/from the cloud and among cloud providers, traditional firewalls do not provide the mediation or XML threat protection required to expose these applications safely. Features that manage cloud APIs provide a new means to meter, throttle, and audit how services are consumed. A cloud service broker can provide the backbone for a cloud provider or an enterprise to create an API monetization program that bills back departments or charges other entities for API usage. See Figure 4.5 Figure 4.5: Cloud API Management API Management Key to Cloud Service Broker model API throttling, metering, rate limits API monetization, usage, SLA charge back API versionsing and policy lifecycle Use Case 5. Mobile Web Services What web applications were to the 1990s, mobile applications are to today. They started out as a cool front-end with brochureware that moved rapidly to processing real customer transactions. Companies now report billions of dollars in sales over their mobile channels. Early mobile applications were simply web applications served up through a mobile GUI. But as user demand, mobile platforms, and competition have become more sophisticated, mobile web services have evolved. Typically, mobile web services are different from traditional web services. Many companies implement a special mobile middle tier to mediate communications with back-end services. The mobile middle tier is responsible for performing caching, optimization, and other techniques that deliver content to mobile environments. API Receive API Management Invoke Reply Mobile delivers the following distinct challenges to security architecture: Security Token size: Sending large security tokens to Mobile devices is a non-starter in most use cases. Mobile devices and the networks they operate on aren t typically designed to handle large security tokens. However, the sensitive data and operations required to support mobile devices make it necessary to send security tokens over the air in mobile applications. This issue is often solved by utilizing token references, where a short reference to the security token is passed to the device. The mobile middle tier or other server-side service then resolves the reference when it s sent back. States Stored on Devices: Occasionally connected mobile platforms can pose issues because some state is likely to be stored on the device. This leads to concurrency and conversational challenges, where network latency and connectivity or power issues can disrupt operations. Platform Integration: Some mobile platforms have complex and powerful security models. The mobile web services model must integrate with devices OS security models in order to handle sessions, passwords, and user integration. Mobile platforms also need to incorporate a security model that works locally on the device and over the air to back-end Web Services. Figure 5: Security Gateway Manages Mobile Security Policy 8 Mobile Clients Mobile Middle Tier Enterprise Services

9 Security Architecture Services Problem Statement Security architecture services are used at Design time, Deployment time and Run time. Design time activities include ensuring that the enterprise security policy and risk management decisions are factored into the enterprise security posture. Deployment time activities include integration, testing and vulnerability management. Run time activities are focused on operations, key management, security incident response, and monitoring. Given the depth and breadth of these responsibilities, achieving any degree of consistency across these layers is a daunting task. This section examines the set of core concerns for Security Gateways and what type of services they can deliver in enterprise security architectures. The Problem Statement we examine for this section of the document is: Due to threats on networks, there are three different types of scenarios where Transport Encryption adds valuable security capabilities: 1. When the request or response contains sensitive information 2. When the request or response contains information that can be used to access services, applications or data 3. When the request or response contains information that can be replayed Web Services messages often contain important data otherwise why would companies bother with integration layers in the first place? When data are sent in the clear ( e.g. in an unencrypted communications channel), it s vulnerable to being disclosed to anyone listening on the network. A message such as this can disclose the user s password. How can enterprises leverage the capabilities of Security Gateways to address elements of their security architecture requirements? Communication Channel Security Services Communication Channel security services provide security to the network communications protocols that systems use. Typical examples include HTTP, TCP, and RMI-IIOP. Transport Encryption Encrypting network communications has been an important security component since the early days of the World Wide Web, when SSL was used to encrypt the communications channel between Web browser and Web server. Since then, SSL has evolved into TLS and has been used in a wide variety ways to provide confidential communications. The main role for Transport Encryption is to keep sensitive data from being disclosed to network eavesdroppers, Man in the Middle attacks and other nodes. It s obvious that transport encryption should be used when sensitive data like credit cards 1 and Social Security Numbers are traversing communications channels, but it s important to remember that many other cases warrant keeping the communications channel closed to prying eyes and packet sniffers. Industry compliance and regulatory concerns may also mandate high assurance cryptography security certifications for a gateway such as FIPS Level 3 in Financial and Federal verticals. <wsse:usernametoken> <wsse:username>scott</wsse:username> <wsse:password Type= wsse:passwordtext >tiger</ wsse:password> </wsse:usernametoken> The developer may think that simply using WS-Security tokens in a Web services message means that he/she has solved for security. But, in this case the lack of an encrypted channel means the developer could have weakened overall security, because the token is effectively disclosing the user s password to any network listeners. The information sent over the communication channel could contain data that an attacker may use to access the system. In web applications, session management is often implemented by utilizing session cookies. However, when the session cookie is sent in the clear, it provides an eavesdropper with the ability to send the sniffed session cookie to the server and impersonate the user in a so-called Spoofing attack. Cookie: JSESSIONID=RQFMnQLVrRXgwyWpW7SJ8 vtw10de6jacgdypkmn3sa A valid security token such as a SAML assertion 2 could be sniffed off of a network and then replayed if the receiving application does not check the time stamp and the assertion it is not bound to the message with a digital signature. 1 In fact, it s required by standards like PCI DSS. 9

10 < aml:assertion Version= 2.0 IssueInstant= T09:22:05Z > <saml:issuer> <ds:signature xmlns:ds= >...</ds:signature> <saml:subject> <saml:nameid Format= urn:oasis:names:tc:saml:2.0:nameid-format:transient > 3f7b3dcf ecd-92c8-1544f346baf8 </saml:nameid> </saml:subject> <saml:authnstatement AuthnInstant= T09:22:00Z SessionIndex= b07b804c-7c29-ea f3d6f7928ac > <saml:authncontext> <saml:authncontextclassref> urn:oasis:names:tc:saml:2.0:ac:classes:passwordprotectedtransport </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute xmlns:x500= urn:oasis:names:tc:saml:2.0:profiles:attribute:x500 x500:encoding= LDAP NameFormat= urn:oasis:names:tc:saml:2.0:attrname-format:uri Name= urn:oid: FriendlyName= edupersonaffiliation > <saml:attributevalue xsi:type= xs:string >member</saml:attributevalue> <saml:attributevalue xsi:type= xs:string >staff</saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> The token contains information used for authentication and attribute exchange, but it does not implement other replay protections like a nonce. So, if it s disclosed on the network, the attacker could re-submit the token and fool the service into accepting it

11 Transport Authentication and Integrity The Security Gateway may offer authentication support at the communications channel level for inbound and outbound communication to the resources that the Security Gateway protects. When this is bound to the communication protocol, it generally requires credential exchange. In the case of TLS, this can be certificate exchange so the client can verify the authenticity of the server or mutual certificate exchange for mutual authentication, so that both the client and server can verify the authenticity of the sender and receiver. Transport integrity can be verified through TLS as well. Weaker authentication is possible through HTTP Basic and HTTP Digest protocols, but these must be tunneled over TLS to be useful for authentication. Message Security Services Transport level security is a necessary foundational element of security architecture; however, in most cases it s not a sufficient stand-alone security protocol for most use cases. Security decisions and architecture particularly for integrity, encryption, authorization, and origin authentication are most effective when implemented at the message level. Authentication sign and verify messages, e.g. XML Signature. The Security gateway performs authentication checks to augment the communications channel level. In addition, the message level checks provide origin authentication, which can be important for multi-hop messages. Integrity verification the message has not been tampered with. Encryption keeping sensitive information confidential, across multiple hops. The combination of these Security architecture elements enables what is sometimes referred to as Claims-based access control (by Microsoft) or as Attribute-based Access Control (by the US DoD). No matter what you call it (for simplicity s sake, we ll refer to it as Claims-based access control), the claim is in the message, so it must be protected by a security token. These tokens could be Kerberos tickets such as those from Active Directory, X.509 certificates from a PKI, SAML assertions or other customized security tokens. The security tokens role is to protect and vouch for the Claim. This enables dynamic and flexible access control decisions on the endpoints. Key considerations for Message Security Services include: WS-Security token support: Kerberos, X.509, SAML token support SAML support authentication assertion, attribute assertion, authorization decision assertion WS-Trust support WS-Security Policy support How does the Security Gateway implement Message Integrity what hash and verification protocols are supported? How does the Security Gateway implement Encryption at the message level, for example XML Encryption? How does the Security Gateway implement message Authorization? How does the Security Gateway support standards-based authorization, such as XACML? Describe how Policy Enforcement Point (PEP) and Policy Decision Point (PDP) implement authorization workflow rules for messages. Describe how outbound messages are marked as authorized so that service providers and service consumers can verify that policy has been applied to the message. Does Security Gateway support binary, non-xml or custom message formats for high assurance verticals, e.g. sftp, ftps, SWIFT, EDI? The Enterprise Integration and ESB Security use cases are directly in the sweet spot for Security Gateway and Message level security. In both cases, there are messages traversing multiple hops. If sensitive data are involved or different token types, dynamic attributes, and origin authentication are required, then the message is the only way to accomplish this. Security gateways often represent the most cost-effective way to implement these policy checks, since they re purpose-built to handle message security. In B2B use cases, messages are used for exchanging value across enterprises, and so authentication and integrity are important elements to fulfill business requirements. Some B2B use cases include exchanging sensitive information, so message encryption is also required. In Cloud use cases, the message can be expected to traverse infrastructure outside an enterprise s direct control and interact with different security token types. The Security Gateway can offer the ability to generate and consume Cloud vendor tokens. The Security gateway can encrypt sensitive data that may be required for use in the Cloud, but requires additional protection from Man in the Middle attacks. 11

12 In Mobile use cases, the Web services that Mobile applications use to communicate with the server implement specific Mobile security tokens. These message level checks can be performed in the Security Gateway against the declarative security policy. As with other use cases, the Security gateway can offer a purpose-built service with robust policy workflow and protocol support. Finally, lightweight WOA (Web Oriented Architectures) are in demand by Developers but non-standard interfaces such as REST are lacking in Enterprise class security. A Security Gateway can be used to abstract & virtualize RESTful web services to apply strong authentication, STS credential mapping, message level security, and critical REST to SOAP mediation. Identity & Access Management Identity and Access Management tooling is an increasingly important element in Security Architecture. For Security gateways, there are several factors to consider: How does the Security Gateway interface with Access management tools? What capabilities does the Access Manager use to define and enforce access control policies? How does the Security Gateway implement Federation? Does the Security gateway support SAML and other federated standards? What profiles, protocols and bindings are supported? How does the Security Gateway support Web authorization? Are oauth, oauth 2.0, oauth WRAP supported? How does the Security Gateway integrate with Identity Management suites? What Access Management tools, e.g. Siteminder, Oracle Access Management does the Security gateway support? How does the Security Gateway implement Security Token Services? Of the token services listed below, which ones are supported? Token issuance Token validation Token exchange For Enterprise Integration and ESB Security use cases, the Security Gateway often plays two roles. First the Security Gateway is used to interface where necessary with the enterprise Access Management tool. Second, the Security Gateway can be used to validate and issue security tokens. In the case of a typical enterprise application, the Use Case could traverse a Unix system with accounts in LDAP or backend servers that use PKI or Active Directory credentials. The Security Gateway s Security Token Services (STS) can be utilized to validate and issue the proper credential at each message exchange. In B2B, Cloud and Mobile use cases, STS ensures the right security protocol is in place at the right location, when it needs to be consumed to make an access control decision. Figure 6: Using a STS in Cloud Architecture Exchange AD Kerb ticket for your Sales Forest for SForce token Your System Exchange AD Kerb ticket from your CSR Forest for Google token Exchange LDAP attributes for Rackspace token Your Users Your Use Cases Exchange X.509 cert from your PKI for Amazon token 12

13 For example, an enterprise could have Customer Relationship data stored in a Sforce Cloud, Customer Service applications hosted at Google, infrastructure hosted at Rackspace, and messaging applications running in an Amazon Cloud. Add to this requirements associated with the Enterprise s own security protocols and internal directories. The STS plays the role of token exchanger to validate the inbound token and issue an outbound token. For example: The enterprise s Sales agents could be stored in the Enterprise Active Directory forest called Sales; only those agents are able to access the Salesforce Cloud. In this case, the Security gateway verifies the agent has a current session, authenticated to the Sales Forest in Active Directory and issues a SForce token. The Security Gateway verifies another set of users against the Active Directory to ensure they are Customer Service Representatives and issues them a SAML assertion token to access Google Apps. Security Gateway STS verifies attributes stored in LDAP and issues a Rackspace token for infrastructure administrators. Security Gateway STS verifies developers against internal PKI with X.509 and issues an Amazon token. The Security Gateway STS is flexible to enable integration across a variety of protocols, token types and use cases. As enterprises become more distributed, mobile and tightlyintegrated, the STS is increasingly an important component of the security architecture foundation that s required to make sound access control decisions. Security Policy Lifecycle The Security Policy Lifecycle begins with defining the security policy that describes what is and what is not permitted. The security policy is used to guide the design and implementation of the security mechanisms (such as access control mechanisms) that fulfill the policy s intent. Ongoing operational policy management is then required for versioning and assurance. Developers and security architects are typically involved more on Design time tasks, such as security policy and security mechanism design. Security operations and system/network administrators are typically involved in implementing the security mechanism and executing security processes. Figure 7: Security Policy Lifecycle Design Time Run Time Operations Security Policy Security Mechanism Security Process Create Security Policy Enforce Security Policy Execute Security Policy 13

14 To ensure a smooth transition across the lifecycle a shared view of security policy is required, including: Policy Creation: Ability to define security policy and rules that enumerate the subjects, objects, conditions and actions. Policy Enforcement: Ability to consume and implement. Policy Management: Ability to query, version and update security policy, once it s in production. Policy Assurance Ability to conduct testing and verification of security policy. The Security Gateway plays a role across the Security Policy Lifecycle. At Design time, policy creation tools are used by developers and security architects to define security workflows. Where systems rely on registry and repository tools, the design time tools that define policy for the Security Gateway should integrate with the registry and repository. The next step is to build and implement security mechanisms. This is generally a shared responsibility of the development team, security architects and operations staff. Policy management and assurance processes are typically the responsibility of the security operations team. Since there are a number of moving parts, well-understood artifacts and processes are important aspects of the security policy lifecycle. Key Security Policy Lifecycle management considerations for evaluating Security Gateways include: What types of policy management registries and repositories are supported? Does Gateway support centralized policy externalization for routing, schemas, attack prevention, and stylesheets? This allows policies to easily be changed once on a central server without impacting production applications and distributed dynamically to gateway enforcement points. Do the Policy creation tools and languages address the key policies for your enterprise? What support does the tool offer for transition steps between Policy Creation, Enforcement and Management? Does the control enforcement meet security policy requirements? What types of services and resources can leverage the enforcement mechanisms? How does the Security Gateway manage versioning, to ensure consistency across the lifecycle? How are assurance activities specified? What type of assurance and security testing activities are supported? Does the Security Gateway have testing and certification modes for load, throughput and vulnerability assessments? There are several Use Case specific considerations for Security Policy Lifecycle management. For Enterprise Integration, ESB, and B2B use cases, it s important that the policies are created in a format like XML that can be consumed by a variety of technologies. These use cases will be expected to support Java, Microsoft, IBM, Open Source and other stacks. The Security Policy must be able to be consumed by the runtime engine. WS- SecurityPolicy and XACML provide standards to express security policy in a way that the policy assertions can be consumed across platforms. Message Processing Message processing and transformation is not a typical information security responsibility; however, many enterprises find it convenient to process, validate, transform and enrich messages on a Security Gateway. There are very few times when security architects can deliver both performance and security gains: Security Gateway message processing delivers an added benefit to throttle & meter services to address Quality of Service or SLA agreements with partners or providers. Major performance gains and lower latency mean that security properties can be added cost free to the overall system performance. For companies looking to leverage the Security Gateway in this manner, there are several points to examine. The language and framework that are used in the development practice should be supported on the Security Gateway either natively in hardware, or through an API. Common XML tools and frameworks that include: XPath 2.0 XSLT XQuery How is the XML acceleration handled? Though open source, OEM of third party hardware cards, or has the vendor delivered core, machine level XML processing IP that can be readily upgraded without dependency or purchase from third parties? Have independent performance benchmarks been published? Note that this is not meant to serve as a comprehensive list; you should consult your development teams to understand what processing frameworks they employ to ensure your evaluation targets frameworks that are most strategic in your enterprise architecture. For example, many enterprises use Java or C# to perform message enrichment. 14

15 Extensibility through message processing techniques allows the enterprise to take advantage of the Security Gateway s security capabilities and extend them to offer additional functionality. To obtain these benefits, the Security Gateway s extensibility must use a language that your organization s development team has demonstrated expertise in. For example, XSLT is useful in certain cases, but there are orders of magnitude more Java and.net developers. For Enterprise Integration and ESB use cases, the Security Gateway is often used to offload access control and other security services, so that the service endpoint does not need to implement all of the complex and highly customized requirements associated with security protocols. In this model, the Security Gateway is positioned to deliver message processing functionality that can perform content validation, schema validation, and business logic and rule enforcement. Every security architect has experienced pushback at some point in their career that adding cryptography or access control will kill system performance. Security Gateways dual role of latency reduction and security policy enforcement point, enable the security architect an effective strategy to deal with this age old problem. Systems Management Security Gateway Systems Management includes a variety of administrative tasks. Typical processes relate to system administration, system resiliency (incident response), and testing (vulnerability assessment). Key considerations include: How does the Security Gateway implement systems logging for management? What administrative interfaces does the Security gateway implement? How does the Security Gateway support testing for Quality Assurance, Production testing, and Pre-Production testing? What management tools are available for the Security gateway? What System metrics and reporting are available for the Security gateway? What level of diagnostics, alerts, and warnings (e.g. SNMP, and Syslog) are implemented? How does the Security Gateway manage necessary upgrades for hardware, OS, and software? How does the Security Gateway manage, version, and store security policy? How does the Security Gateway implement Key management processes for Key distribution, revocation, and storage? What security testing tools are available that work in conjunction with the Security gateway? What client and development tools are available that work in conjunction with the Security gateway? Deployment Options Security Gateways can be deployed in a number of different ways. The type of resource that the Security gateway is providing access to and how the enterprise will manage it will determine what options are most effective. The first consideration is the deployment delivery type: Hardware: Can offer performance improvements and attack surface reduction Software: Can offer tighter integration with software resources. Depending on architecture, software integration may perform faster than hardware. To address the trend for data center virtualization, it is critical the gateway can be deployed as virtualized software on-premise or hosted in the cloud. Hardware/Software: Hybrid approach that enables the enterprise to use a hardware appliance in production and a lower-cost, easier to manage software-based Security gateway in development, testing, and production. Access Control and Detection services are insufficient by themselves if they do not also offer Availability services to mitigate Denial of Service and other persistent attacks. Key considerations for Security Gateway Deployment include: How does the Security Gateway implement failover? Does the product have self-contained cluster management through a web interface and not require procurement of an additional product? How does the Security Gateway scale? Does it scale vertically, horizontally or both? Does the Security Gateway require additional hardware to scale? How does the Security Gateway scale across geographically diverse environments? How does the Security Gateway offer high availability? How does the Security Gateway support guaranteed delivery? How does the Security Gateway support enterprise class messaging at least once, at most once and in order messaging? 15

16 Does Security Gateway offer offline management for monitoring or policy creation? What messaging protocols does the Security Gateway support? Does the Security Gateway support JMS, and MQ Series? How does the Security Gateway implement protocol bridging? How does the Security Gateway implement proxy services? How are security policy changes deployed at runtime? Does the Security Gateway need to be re-started for changes? What types of changes can be added on the fly without requiring a restart? For Enterprise Integration and ESB Security use cases, there are concrete advantages associated with implementing the Security Gateway in a software format. There are many ways that security services on the Security Gateway can be consumed; for example, the software model can be used to implement security policy enforcement on the ESB s publisher and subscribers in a protocol-specific fashion. Detection Services Network monitoring systems like Network IDS and wire taps have been widely deployed in IT Network architectures for many years. These tools are effective at generating mountains of information, but what they often lack is context. Security Gateways are able to generate context because they are closer to the application, Web services, data handling and identity information. Detection services like Monitoring and Audit Logging provide a backstop to traditional access control services like authentication and authorization. Where access control services rely on knowing at design time the complete set of subjects and objects the system will use, Detection services simply report on how the system is used at runtime. This passive approach does not eliminate the possibility of an attack succeeding but it delivers the opportunity for the system to respond and recover in the event of a security incident. Security Gateways are an ideal location to deploy Detection Services, since they are located at chokepoints and architecture boundary crossing areas. Audit Logging Security gateways are ideal candidates to enable Audit logging services, because they are not merely high level SIEM tools. SIEM tools provide excellent capabilities to respond to security events, but lack the application domain context to report on what constitutes an incident, this is where Audit Logging comes in. Audit Loggers have Audit Log Listeners that monitor systems events to report on. The Security Gateway is located in a strategic position to see and report on message inflows and outflows. Network monitoring services can observe IP addresses, senders, receivers and header level details, but application-specific message exchanges are out of scope for network monitors. Detailed Audit Logging is a requirement of PCI DSS and other standards, which many enterprises are subject to. The ability to build visibility into the system is an important component of the detection service in the security architecture. The core elements in the Audit Loggers are: Audit Log Event Model Defines the type of security and business events that the Audit Log observer is monitoring for. Audit Record Formats Defines the format of the Audit Record message that the Audit Logger writes to the Audit Log repository. Figure 8: Security Gateway Enables Audit Logging Security gateway Security gateway Initiator Audit Log Event Observer Events Audit Log Event Observer Target Audit Record Audit Record Audit Log Event Analyzer Auditor Browse Audit Log 16

17 Audit Log Publishing Defines the Audit Log messaging type(s) supported by the Audit Logger. These could include JMS, syslog, and other protocols. Audit Log Management Identifies the target location where Audit Log messages are to be written. This is typically a secure, stand-alone system that incident responders use to review what s happened on the system. Note that Audit Log Event Model, Audit Record Formats and Audit Log Publishing are responsibilities of a Security Gateway. The Audit Log Management responsibility is a stand-alone, specialized system, so the Security Gateway s job is to identify auditable events, write them out in a consistent format and send them to the Audit Log Management system. Key Audit Logging considerations for evaluating Security Gateways include: What types of Auditable Events does the Security Gateway observe? What format is the Audit Record written in? Does the Audit Record include the action taken, the initiator of the action, the target of the action, and the status of the action? What attack patterns can the Audit Logger observe? Can the observer report on attacks like attacks against access control, XSS, and SQL Injection? What protocols can the Audit Logger use to publish messages? Can the Audit Logger use guaranteed delivery? How are the message queues managed for the Audit Logger? What logging policies are included? How are the Audit Log messages secured? Does the Audit Logger implement timestamping? How is Audit Record integrity ensured? How are the Audit Records authenticated? How does the Security Gateway support correlation for endto-end transaction logging? Does the Security Gateway have functionality to filter or sanitize data before it s written to the Audit Log? For example, removing confidential data like a password so that it s not persisted? The location and Use Case of the Audit Logger will drive refinements associated with which capabilities should be considered the highest priorities. For Enterprise Integration and ESB Security use cases, the Audit Log is often used to provide a consistent set of auditable reports and events. In these use cases, it s normal for the Enterprise Architecture to include Java, Oracle, Microsoft.Net, Open Source and technology stacks. Each of these systems likely has the ability to write an Audit Log, but there is no simple way to correlate security events and information. When a security event occurs, incident response can result in a wild goose chase that involves reviewing event logs in many systems and in many different formats. To address these issues, the Security gateway acts as a chokepoint and can write standard audit log messages using a consistent event model. For B2B use cases, there are often requirements for reporting in conjunction with SLAs and other business agreements. The Security Gateway Audit Logger can write events that can be utilized to report on usage activity, as well as act as an early warning system, if there are security issues that originate from external B2B partners. In Cloud Architectures like SaaS, PaaS, and IaaS, some security controls have effectively been outsourced to the Cloud vendor. But, this does not mean that it s in the enterprise s best interest to outsource visibility. In many cases, use of the Cloud means the enterprise wants more visibility in return for giving up some control. Audit Logs are one primary way to deliver visibility in Cloudbased architectures. In a SaaS model, SaaS vendors expose functionality and APIs that can be used for Audit Log event modeling that s implemented in the Security gateway. In the PaaS scenario, the Platform may provide an API for Audit logging that can be implemented and correlated with the Security Gateway. In the IaaS scenario, the enterprise implementation will likely determine the Audit Logging event model that s implemented in the Security Gateway. Mobile use cases must manage occasionally connected devices through conversational patterns that resolve some information on the server side. The result of this architecture is that many times data is passed by reference, but not by value. In these cases, Audit Log correlation can be quite challenging, because the payload the Audit Log Observer sees is a set of reference codes that have no semantic meaning- only pointers. These pointers must be standardized in a way that enable them to be re-hydrated and resolved on the server side, either when they re written to the audit Log on when they re browsed in the Audit Log. Threat Protection Most software is written to handle functional use cases the set of requirements that should take place from a business perspective. But these functional requirements do not specify the non-functional requirements of what should not be allowed to happen. For example, a functional requirement might specify a Web service that permits a user to interact with a database 17

18 through a set of queries. However, this does not preclude an attacker from subverting the Web service and sending his/her own malicious commands and SQL to the database. Since Application Security groups time, resources and expertise are frequently at a premium, it makes business sense to centralize and deploy security through Security Gateways. Security Gateways can enforce and manage security controls that effectively maximize the scarce Application Security resources, giving you the power to enforce security policies through the Gateway, without the need to rewrite thousands of applications. Security Gateways maximize Application Security resources by enforcing and managing Security Policy through Security gateway configuration rather than through application code. How does the Security Gateway protect against Injection attacks, such as XPath Injection, and SQL Injection? How does the Security Gateway protect against external reference and external entity attacks? How does the Security Gateway protect against buffer overflow attacks? How does the Security Gateway protect against parser attacks like XSLT transformation attacks? How does the Security Architect configure the analysis workflow for message and request/response security? How does the Security Gateway protect against Cross Site scripting attacks? How does the Security Gateway protect against replay attacks? How does the Security Gateway protect against communication protocol attacks such as HTTP-based attacks? Key considerations for Threat Protection include: How does the Security Gateway perform Input Validation? Does the Security Gateway support whitelist (default deny), blacklist (default allow) rules? How does the Security Gateway perform data escaping and data sanitization? How does the Security Gateway protect against Network Denial of Service (DOS) attacks? How does the Security Gateway protect against XML Denial of Service attacks, including the following types of attacks: Against DOM parsers Against SAX parsers Large document attachments Jumbo messages In memory replication and recursion Numerous small files How does the Security Gateway perform output encoding? What encoding types are supported? How does the Security Gateway protect against viruses? Are security models based on signatures, rules and/or patterns? For Threat Protection services- in all use cases- the Security Gateway is the main line of defense. Like horseless carriages and buggy whips, the days of systems inside the firewall systems don t need to care about security threats have come to an end. For Enterprise Integration and ESB security use cases, the Security gateway serves to implement security checks against malicious threats. Threat protection against the threats enumerated above are not available in general purpose enterprise systems like Java,.Net, Oracle and JEE. It s costprohibitive for the enterprise to build them in. It s even more expensive to ignore them. This makes the Security Gateway a do not go production without it part of Enterprise Integration and ESB security. For B2B, Cloud and Mobile use cases, there s remote access that s not under the direct control of the enterprise, which raises the likelihood of threat activity. Security Gateways enforce checks against the input from remote systems, to verify that the information received from third parties will not harm the enterprise. 18

19 Detailed RFP Template A sample detailed RFP template can be downloaded here. About the Author Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and insurance systems, as well as emerging start ups Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. Paper Sponsorship The Intel Application Security & Identity Products Group sponsored the production of this Buyer s Guide in order to facilitate broader understanding of Security Gateway usage models. Intel has brought to market the Intel Expressway Service Gateway - a new type of security gateway used to abstract, secure, and simplify services delivery. More than an ESB, XML Gateway or an XML firewall, a Service Gateway delivers a unique set of features tailor made to integrate, mediate, secure, and scale services in a dynamically changing Enterprise application perimeter. For more on Intel Expressway Service Gateway or to view Gunnar Peterson s Technical Web Service Security Tutorial series visit: He blogs at 19

20 Part of the McAfee Cloud Security Platform Available Direct From Intel as Intel Expressway Service Gateway Available as Part of the McAfee* Cloud Security Platform as McAfee Services Gateway More Information Resource Site: Americas: INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling , or by visiting Intel s Web site at Copyright 2011 Intel Corporation. All rights reserved. Intel, the Intel logo, and Xeon are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Printed in USA Please Recycle US