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

www.dynamicperimeter.com/

download/SecurityGateway_

BuyersGuide

Author

Gunnar PetersonIndustry Security Expert

Managing Principal at Arctec Group

white PAPer

AbstractIf you’re currently evaluating Security Gateways, this guide will provide the analysis anddecisionsupportthatwillenableyoutomakeaninformedchoice.Thefirsttwosections describe Security Gateways’ Security Architecture Capabilities and the common business use cases where they’re deployed. The following sections of the guidecontaintoolsyoucanusetoidentifytherightfitforyoursecurityarchitecturebased on business requirements, cost, and complexity.

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 ........................................................................................19

2

Use CasesAs 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 casesdescribethefunctionalflowsinthesystem, 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 flowsinusecases)andwhatshouldnot 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 answerspecificquestions,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 integra-tion scenarios?

� If my business is moving toward Cloud Computing models such as Software as aService(SaaS),PlatformasaService(PaaS)orInfrastructureasaService(IaaS),howdoesmysecurityarchitec-ture 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 cost-effective way that enables use cases to be realized from a business perspective, and to meet the security policies and risk managementdecisionsthatarereflectedin 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.

Executive SummarySecurity 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.

3

Security Gateways are purpose built, engineered with security in mind as a primary goal.

.NetContainer

RichClient

Security

WeblogicContainer

WebService

Security

WCFContainer

CentralizeSecurity PolicyEnforcement &

ManagmentRESTService

Security

TomcatContainer

JEEApp

Security

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.

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 stacksmustbeableto:

•MediateaccesstotheWebServicesmessage exchange

•MediateaccesswithoutcompromisingQualityofService(QOS)andavailability

•Integratetothespecificmessageexchange patterns used (such as Request-Reply,Publish-Subscribe),through either the Service Endpoint and/or the network layer.

Figure1:EnterpriseIntegrationRequiresIntegratingDisparateSecurityModels

4

the challenge to security is clear: Deliver security services that enable consistent security policy enforcement across a wide array of runtime constituents.

Client

ResourceResource

Client

ClientClient

Messaging

PublishSubscribe Routing Transformation Management

Resource

Use Case 2. eSB Security EnterpriseServiceBus(ESB)andSOAprovide 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 architecturalbenefits:

• 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.

ThespecificsecuritychallengesinESBSecurityinclude:

•Locationofthesecurityservice–Deliver with ESB, Publisher, Subscriber or as a separate interface

•Consistentaccesscontrol,andsecuritypolicy enforcement point for SOA and ESB across a minimum of three security models – Publisher, Subscriber, and ESB

•SeparationofRoutingSecurityandMessage Payload Security

•Abilitytomediate&transformfromSOAP to emerging WOA services such as REST or JSON.

Figure2:SecurityGatewayEnforcesandManagesSecurityPolicyforESBMessagingArchitecture

5

Use Case 3. B2B Security B2Bintegrationhasevolvedsignificantlyfrom the early days of EDI; now there are complex XML-based trading partner networks and hub exchanges, to accompanytraditionalB2Bfiletransfersand 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 considerhowtomanageseveralspecificissuesforsecurityarchitecture:

•Duetoinfrastructureandoperationalissues, 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.

•Nomatterwhetherthesystemrunsonpasswords, Kerberos, X.509 or SAML, if the systems’ Key Management is weak it can bring down the latest and greatest access control protocol.

•Monitoringcapabilitiesarerequiredtomanage current state, trouble-shoot errors and respond in the event of security incidents.

Figure3:SecurityGatewayEnablesSecureBusinessIntegration

Company B

B2B GatewayServices

EnterpriseResources

Company A Company C

6

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 cloudserviceproviders.Specifically,aService 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,andIaaS)layeredacross 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

securitytoken(s)theywillsupportforauthentication 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 functionalitytoCloudmodels:

•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 on-premise within a private cloud or in a public cloud deployment as a security gateway at the cloud provider.

•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)validateenterprisesecurity tokens like Kerberos tickets from Active Directory and issue tokens that are consumed by Cloud providers.

Figure4:NISTCloudDefinitionFramework

Cloud Provider

Cloud Service Management

Cloud Auditor

Cloud Consumer

Provisioning/ Configuration

Portability/ Interoperability

Security Audit

Privacy Impact Audit

Performance Audit

Business Support

Secu

rity

Priv

acy

Cloud Broker

Service Intermediation

Service Aggregation

Service Arbitrage Physical Resource Layer

Hardware

Facility

Resource Abstraction and Control Layer

Service Layer

IaaS

SaaS

PaaS

7

Cloud Service Brokerages that manage APis represents the single biggest revenue growth opportunity in cloud computing

- Darryl Plummer, Gartner

• 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

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.

Figure5:SecurityGatewayManagesMobileSecurityPolicy

Figure4.5:CloudAPIManagement

MobileClients

MobileMiddle Tier

EnterpriseServices

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.

Receive

API Management

Invoke

Reply

API Management • Key to Cloud Service Broker model • API throttling, metering, rate limits • API monetization, usage, SLA charge back • API versionsing and policy lifecycle

API

8

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 documentis:

Communication Channel Security ServicesCommunication Channel security services provide security to the network communications protocols that systems use. Typical examples include HTTP, TCP, and RMI-IIOP.

transport encryptionEncrypting 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 provideconfidentialcommunications.

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 cards1 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 mandatehighassurancecryptographysecuritycertifications for a gateway such as FIPS 140-2 Level 3 in Financial and Federal verticals.

Security Architecture Services Problem Statement

1 In fact, it’s required by standards like PCI DSS.

Due to threats on networks, there are three different types of scenarios where Transport Encryption adds valuable securitycapabilities:

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 inthefirstplace?Whendataaresent“intheclear”(e.g.inanunencryptedcommunicationschannel),it’svulnerabletobeingdisclosed to anyone listening on the network. A message such as this can disclose the user’s password.

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 theuserinaso-called“Spoofingattack.”

A valid security token such as a SAML assertion2 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.

9

how can enterprises leverage the capabilities of Security Gateways to address elements of their security architecture requirements?

<wsse:UsernameToken>

<wsse:Username>scott</wsse:Username>

<wsse:Password Type=”wsse:PasswordText”>tiger</wsse:Password>

</wsse:UsernameToken>

Cookie: JSESSIONID=RQFMnQLVrRXgwyWpW7SJ8vtW10De6JACGdyPkmn3SA

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.

2 http://en.wikipedia.org/wiki/SAML_2.010

< aml:Assertion

Version=”2.0”

IssueInstant=”2004-12-05T09:22:05Z”>

<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>

<ds:Signature

xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>...</ds:Signature>

<saml:Subject>

<saml:NameID

Format=”urn:oasis:names:tc:SAML:2.0:nameid-format:transient”>

3f7b3dcf-1674-4ecd-92c8-1544f346baf8

</saml:NameID>

</saml:Subject>

<saml:AuthnStatement

AuthnInstant=”2004-12-05T09:22:00Z”

SessionIndex=”b07b804c-7c29-ea16-7300-4f3d6f7928ac”>

<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:1.3.6.1.4.1.5923.1.1.1.1”

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>

transport Authentication and integrityThe 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, thiscanbecertificateexchangesotheclientcanverifytheauthenticityoftheserverormutualcertificateexchangeformutual authentication, so that both the client and server can verify the authenticity of the sender and receiver. Transport integritycanbeverifiedthroughTLSaswell.Weakerauthentication is possible through HTTP Basic and HTTP Digest protocols, but these must be tunneled over TLS to be useful for authentication.

Message Security ServicesTransport level security is a necessary foundational element of securityarchitecture;however,inmostcasesit’snotasufficientstand-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(byMicrosoft)orasAttribute-basedAccessControl(bytheUSDoD).Nomatterwhatyoucallit(forsimplicity’ssake,we’llrefertoitasClaims-basedaccesscontrol),theclaimisinthe message, so it must be protected by a security token. These tokens could be Kerberos tickets such as those from Active Directory,X.509certificatesfromaPKI,SAMLassertionsorother customized security tokens. The security tokens’ role is to protect and vouch for the Claim. This enables dynamic and flexibleaccesscontroldecisionsontheendpoints.

KeyconsiderationsforMessageSecurityServicesinclude:

� WS-Securitytokensupport:Kerberos,X.509,SAMLtokensupport

� 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 au-thorization, such as XACML?

� DescribehowPolicyEnforcementPoint(PEP)andPolicyDecisionPoint(PDP)implementauthorizationworkflowrulesfor 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 importantelementstofulfillbusinessrequirements.SomeB2Buse 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

In Mobile use cases, the Web services that Mobile applications usetocommunicatewiththeserverimplementspecificMobilesecurity 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 apurpose-builtservicewithrobustpolicyworkflowand protocol support.

Finally,lightweightWOA(WebOrientedArchitectures)areindemand 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,thereareseveralfactorstoconsider:

� How does the Security Gateway interface with Access man-agement 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 stan-dards? What profiles, protocols and bindings are supported?

� How does the Security Gateway support Web authorization? Are oauth, oauth 2.0, oauth WRAP supported?

Figure6:UsingaSTSinCloudArchitecture

� 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?

•Tokenissuance

•Tokenvalidation

•Tokenexchange

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 back-end servers that use PKI or Active Directory credentials. The SecurityGateway’sSecurityTokenServices(STS)canbeutilizedto 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.

Exchange AD Kerb ticketfrom your CSR Forest for

Google token

Exchange X.509 certfrom your PKI

for Amazon tokenExchange LDAP attributesfor Rackspace token

YourUsers

Your System

Exchange AD Kerb ticketfor your Sales Forest for

SForce token

Your UseCases

™

12

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 outboundtoken.Forexample:

•Theenterprise’sSalesagentscouldbestoredintheEnterprise 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.

•TheSecurityGatewayverifiesanothersetofusersagainstthe Active Directory to ensure they are Customer Service Representatives and issues them a SAML assertion token to access Google Apps.

•SecurityGatewaySTSverifiesattributesstoredinLDAP and issues a Rackspace token for infrastructure administrators.

•SecurityGatewaySTSverifiesdevelopersagainstinternalPKI with X.509 and issues an Amazon token.

TheSecurityGatewaySTSisflexibletoenableintegrationacross a variety of protocols, token types and use cases. As enterprises become more distributed, mobile and tightly-integrated, the STS is increasingly an important component of the security architecture foundation that’s required to make sound access control decisions.

Security Policy LifecycleTheSecurityPolicyLifecyclebeginswithdefiningthesecurity 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 controlmechanisms)thatfulfillthepolicy’sintent.Ongoingoperational 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.

Figure7:SecurityPolicyLifecycle

SecurityPolicy

Design Time Run Time Operations

CreateSecurity Policy

EnforceSecurity Policy

ExecuteSecurity Policy

SecurityMechanism

SecurityProcess

13

To ensure a smooth transition across the lifecycle a shared view ofsecuritypolicyisrequired,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 developersandsecurityarchitectstodefinesecurityworkflows.Where systems rely on registry and repository tools, the designtimetoolsthatdefinepolicyfortheSecurityGatewayshould 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 evaluatingSecurityGatewaysinclude:

� What types of policy management registries and repositories are supported?

� Does Gateway support centralized policy externalization for routing, schemas, attack prevention, and stylesheets? This al-lows policies to easily be changed once on a central server without impacting production applications and distributed dy-namically 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 en-forcement 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?

ThereareseveralUseCasespecificconsiderationsforSecurityPolicy 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 ProcessingMessage processing and transformation is not a typical information security responsibility; however, many enterprises finditconvenienttoprocess,validate,transformandenrichmessages on a Security Gateway. There are very few times when security architects can deliver both performance and securitygains:SecurityGatewaymessageprocessingdeliversanaddedbenefittothrottle&meterservicestoaddressQualityofService or SLA agreements with partners or providers.

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 frameworksthatinclude:

•XPath2.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

Major performance gains and lower latency mean that security properties can be added cost free to the overall system performance.

Toobtainthesebenefits,theSecurityGateway’sextensibilitymust 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 Gatewayisoftenusedtooffloadaccesscontrolandothersecurity 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 ManagementSecurity Gateway Systems Management includes a variety of administrative tasks. Typical processes relate to system administration,systemresiliency(incidentresponse),andtesting(vulnerabilityassessment).Keyconsiderationsinclude:

� 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,emailandSyslog)areimplemented?

� 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 OptionsSecurity 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.

Thefirstconsiderationisthedeploymentdeliverytype:

•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.

AccessControlandDetectionservicesareinsufficientbythemselves if they do not also offer Availability services to mitigate Denial of Service and other persistent attacks. Key considerationsforSecurityGatewayDeploymentinclude:

� 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

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.

� 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-specificfashion.

Detection ServicesNetwork 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 LoggingSecurity 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 inastrategicpositionto“see”andreportonmessageinflowsandoutflows.NetworkmonitoringservicescanobserveIPaddresses, senders, receivers and header level details, but application-specificmessageexchangesareoutofscopefornetwork 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 intheAuditLoggersare:

•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.

Figure8:SecurityGatewayEnablesAuditLogging

Audit LogAuditor

Security gateway Security gateway

InitiatorAudit Log

EventObserver

Audit LogEvent Analyzer

AuditRecord

AuditRecord

Audit LogEvent

ObserverTargetEvents

Browse

16

•Audit Log Publishing – Defines the Audit Log messaging type(s)supportedbytheAuditLogger.ThesecouldincludeJMS, 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 Gatewaysinclude:

� 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 end-to-end transaction logging?

� Does the Security Gateway have functionality to filter or sani-tize 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 refinementsassociatedwithwhichcapabilitiesshouldbeconsidered 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.

Audit Logs are one primary way to deliver visibility in Cloud-based 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 ProtectionMost 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

in many cases, use of the Cloud means the enterprise wants more visibility in return for giving up some control.

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.

KeyconsiderationsforThreatProtectioninclude:

� How does the Security Gateway perform Input Validation? DoestheSecurityGatewaysupportwhitelist(defaultdeny),blacklist(defaultallow)rules?

� How does the Security Gateway perform data escaping and data sanitization?

� How does the Security Gateway protect against Network DenialofService(DOS)attacks?

� How does the Security Gateway protect against XML Denial of Serviceattacks,includingthefollowingtypesofattacks:

•AgainstDOMparsers

•AgainstSAXparsers

•Largedocumentattachments

•Jumbomessages

•Inmemoryreplicationandrecursion

•Numeroussmallfiles

� 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?

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 communica-tion protocol attacks such as HTTP-based attacks?

For Threat Protection services- in all use cases- the Security Gateway is the main line of defense. Like horseless carriages andbuggywhips,thedaysof“systemsinsidethefirewallsystems 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 cost-prohibitive 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

Detailed rFP template A sample detailed RFP template can be downloaded here.

About the AuthorGunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial,financialexchanges,healthcare,manufacturer,andinsurance 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.

He blogs at http://1raindrop.typepad.com

http://info.intel.com/registration.html?as=53&partnerref=null

19

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 anESB,XMLGatewayoranXMLfirewall,aServiceGatewaydelivers 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 ServiceSecurityTutorialseriesvisit: www.intel.com/go/identity

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: www.intel.com/go/identity www.mcafee.com/cloudsecurity

Americas: 978-948-2585

E-mail: intelsoainfo@intel.com

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.

Intelmaymakechangestospecificationsandproductdescriptionsatanytime,withoutnotice.Designersmustnotrelyontheabsenceorcharacteristicsofanyfeaturesorinstructionsmarked“reserved”or“undefined.”Intelreservestheseforfuturedefinitionandshallhavenoresponsibilitywhatsoeverforconflictsorincompatibilitiesarisingfromfuturechangestothem.Theinformationhereissubjecttochangewithoutnotice.Donotfinalizeadesignwiththisinformation.

Theproductsdescribedinthisdocumentmaycontaindesigndefectsorerrorsknownaserratawhichmaycausetheproducttodeviatefrompublishedspecifications.Currentcharacterizederrataareavailableonrequest.ContactyourlocalIntelsalesofficeoryourdistributortoobtainthelatestspecificationsandbeforeplacingyourproductorder.Copiesofdocumentswhichhaveanordernumberandarereferencedinthisdocument,orotherIntelliterature,maybeobtainedbycalling1-800-548-4725,orbyvisitingIntel’sWebsiteatwww.intel.com.

Copyright©2011IntelCorporation.Allrightsreserved.Intel,theIntellogo,andXeonaretrademarksofIntelCorporationintheU.S.andothercountries. *Other names and brands may be claimed as the property of others. Printed in USA Please Recycle 324360-003US