# Presentation: 750361

## Hardware Based XML Security Components 

- Forum Systems, Inc.
- 95 Sawyer Road
- Waltham, MA 02453
- 781-788-4200
- http://www.forumsys.com

- DataPower Technology, Inc.
- One Alewife Center
- Cambridge, MA 02140
- 617-864-0455
- http://www.datapower.com

## Topics

- XML webServices Security
- Enterprise Deployments for XML Security
- Hardware-Based XML Security
- Interoperability
- XML Security and FEA

## Need for XML Security

- Securing channels vs. Securing content

**Direct connection between client and server must be established**
- Multiple intermediaries require multiple HTTPS connections piped together
- Opens potential security holes at connecting nodes, but also creates a public key certificate management nightmare
**Can not provide granular content security**
- Scenarios such as multi-level approval require parts of information to be open
- Connection-based security are insufficient
- Verify the authenticity of approval signatures
- Unnecessarily encrypting all content also introduces more processing overhead

**Field Agent**
- Sign and send an
-  order. The order
- contains
- an encrypted
- account
- number

**Manager**
- Verify the order
- Signature; attach
- an approval
- signature

**Payment Center**
- Verify the approval
- Signature; decrypt
- account number;
- Attach a payment
- status signature;
- remove the
- account number

**Factory**
- Verify the payment
- status signature;
- Verify agent
- address, send
- product

**Notes:**
SSL Designed by Netscape in 1994 for B-to-C market to secure transport between client machine and backend web server.

Advent of XML and machine-to-machine transactions, multi-hop data exchange, across secure and non-secure transport protocols, and across varying security domains, changed the problem from protocol-centric security to document/content/data-centric security.

Vulnerabilities are greater before and after transport, compared to during transport.  Comprehensive security model provides security at both protocol and data level.

## Technology and Specifications Landscape

- Most already familiar to the XML WG & FEA
- Foundation
- XML
- DTD / XML Schema
- XPath/XSLT
- SOAP

**TRM: **_[Component Framework](http://www.feapmo.gov/featrm_service_representation.asp?@serviceareaid=101982)__: _
- _[Security ](http://www.feapmo.gov/featrm_service_category.asp?@serviceareaid=101982&@servicecategoryid=102033)__: Certificates / Digital Signature_

**TRM: **_[Component Framework](http://www.feapmo.gov/featrm_service_representation.asp?@serviceareaid=101982)__:_
**  **_[Security ](http://www.feapmo.gov/featrm_service_category.asp?@serviceareaid=101982&@servicecategoryid=102033)__:_ **Supporting Security Services**

**TRM: **_[Component Framework](http://www.feapmo.gov/featrm_service_representation.asp?@serviceareaid=101982)__: _
- _[Data Interchange ](http://www.feapmo.gov/featrm_service_category.asp?@serviceareaid=101982&@servicecategoryid=101996)__: Data Exchange_

**TRM: **_[Service Interface and Integration ](http://www.feapmo.gov/featrm_service_representation.asp?@serviceareaid=102103)__:_
** **_[Interoperability](http://www.feapmo.gov/featrm_service_category.asp?@serviceareaid=102103&@servicecategoryid=102121)__: Data Types / Validation_

**TRM: **_[Service Interface and Integration ](http://www.feapmo.gov/featrm_service_representation.asp?@serviceareaid=102103)__:_
- _[Interoperability](http://www.feapmo.gov/featrm_service_category.asp?@serviceareaid=102103&@servicecategoryid=102121)__: Data Transformation_

**TRM: **_[Service Interface and Integration ](http://www.feapmo.gov/featrm_service_representation.asp?@serviceareaid=102103)__:_
- _[Interoperability](http://www.feapmo.gov/featrm_service_category.asp?@serviceareaid=102103&@servicecategoryid=102121)__: Data Format/Classification_

**TRM: **_[Service Interface and Integration ](http://www.feapmo.gov/featrm_service_representation.asp?@serviceareaid=102103)__: _
- _[Interface](http://www.feapmo.gov/featrm_service_category.asp?@serviceareaid=102103&@servicecategoryid=102115)__: Service Discovery_

- Security Building Blocks
- XML Digital Signature
- XML Encryption

- Upper-Layer Protocols/Standards
- WS-Security
- SAML
- XKMS
- XACML
- UDDI

## Sampling of XML Security Threats

- Snooping
- old problem made worse by human-readable formats
- Tampering
- alter invoice or PO
- examples in semi-trusted environment
- Unauthorized action via valid interface
- Breach of memory space
- buffer overwrite, HTTP overrun
- Unintentionally exposed interface
- methods not in public spec
- automatic object marshalling to/from XML
- XML Denial-of-Service (XDoS)
- attack at XML level
- asymmetry of XML processing

## XML Security Deployment Ecosystem

- External PKI infrastructure: CA servers, services
- Application Infrastructure: web servers, application servers, integration servers
- Management Infrastructure: systems, network, security and logging
- Network Infrastructure: next slide

**Validated **
**Data Elements**

**Certificate Authority**

**Log Server**

**Access Control Policy Server**

**syslog**

**LDAP, OCSP**
**XKMS**

**LDAP**
**SAML, XACML**

**XKMS**

**Managed**
**PKI**

**Network / System / Security**
**Management Server**

**SNMP**
**XML**

**WSC**
**App Server**

**WSC**
**App Server**

**Mgmt. Console**

**WSS**
**App Server**

**WSS**
**App Server**

**Non-Repudiation Audit Server**

**Service Registry**

**HTTP**
**UDDI**

**WSS**
**Integration Server**

## Deployment Modes

- Firewall

- Sentry
- XS40

- Web
- Service

- Firewall

- Web
- Service

- XS40
- Sentry

- Firewall

- Web
- Service

- XS40
- Sentry

- Gateway-Mode

- Proxy-Mode

- Service-Mode

- Load
- Balancer

## XML Security Gateway Deployment

**Notes:**
XML Security Gateway hardware is core infrastructure deployment in the DMZ
Fits within the Component Framework and security layers
Uses XML-based service interface

## Digital Signatures

**Partner**

- User

- WSC

**Public DMZ**

**Integration/**
**Internet-Pass **
**Thru**

- Internet

**SSL/TLS**

*External *
*Firewall*

*Intermediary *
*Firewall*

**Private Network**

- Application
- Sever

- WSC

- WSC

- Digital signing service for
- SOAP formatted XML documents
- Digital verification service for
- SOAP formatted XML documents

**Signature/**
**Verification**
**Server**

**Signature/**
**Verification**
**Server**

## Sign all outgoing messages

- Protect against
- Undetected message tempering
- Liability of fake requests
- Recipient doesn’t have to be XML DSIG enabled
- Audit/verify transactions as originating from within own network
- Recipients can (but don’t have to) verify signatures for authentication
- Easy way to improve security – no reason not to start doing it today (except for maybe performance)

## XML Filtering

**Partner**

- User

- WSC

**Public DMZ**

**XML/SOAP**
**Proxy**

- Internet

**SSL/TLS**

*External *
*Firewall*

*Intermediary *
*Firewall*

**Private DMZ**

- Single-Sign
- On

- WSP

- WSP

**OPERATIONS**
-  Traffic Filtering
-  Message Schema Validation & XPATH Filtering
- Of the request
- Of the response
-  Authentication of WSC (Transport Level)
- Strong SSL Client Certificate
- Certificate Path Validation
- Certificate Revocation List
-  Credentials Mapping of WSC (Message Level)
- Translate Protocol Auth To Document Auth
- Inject SAML within SOAP Request

- Authentication of WSC (Message Level)
- Access Control to Remote Resources

## The Need for Hardware Based XML Security

- Hardware XML Security Reduces Complexity
- Hardware XML Provides Hardened Security
- Hardware XML Security Delivers superior Performance
- Hardware XML Security Encourages Interoperability

## Hardware XML Security Reduces Complexity

**Update application**
**servers individually**

- Secure multiple applications without code changes
- Dramatically reduce cost and complexity
- Enable new business with unmatched performance

## Hardware provides Hardened Security

- Accountability:
- OS upgrades
- Security software upgrades
- Hardware upgrades
- Hardened OS
- Eliminate generic processes, daemons or listeners.
- Hardware-based crypto Algorithms
- Prevent application developers from using weak crypto implementations
- Separation of Security Policies from Applications

## XML Cryptography & Security Performance

- Crypto operations are resource-intensive
- Public-key crypto operations are very expensive
- Familiar example SSL
- A couple RSA ops per connection, bulk encryption
- Today, SSL hardware acceleration is well-accepted practice
- XML example: WS-Security based XML message
- Signed header(s)
- Public-key encrypted symmetric key
- Encrypted payload sections
- Signed payload sections
- 10+ public-key ops per message is quite likely
- Multiple messages per connection
- XML processing also significant

## XML hardware encourages interoperability 

- Coupled to the other systems by Ethernet jack, not custom code
- Separation of concerns
- Network gear business model based on “out-of-the-box” interop
- Large software vendors focused on creating XML-enabled platforms
- Functionality and development tools benefit
- Interop is necessarily secondary, standards wars looming
- Network vendors architecturally unable to achieve “lock-in”
- Focused on a concrete set of challenges
- XML security performance
- Interoperability.

## Overview of Hardware XML Security Market

- A lot of vendors, large and small, claim to provide “XML security” or “secure web services”
- This is natural, but can make selection confusing
- Web services management vs. web services security
- Most relatively small companies
- Hardware model gaining traction
- Recent inrush of pure-software vendors with “server appliances”
- Standards support key to value

## Interoperability promoted through Standards Bodies 

- Interoperability is hard work, but much more likely
- WSI promotes webServices Interoperability.
- The WS-I testing tools are designed to help developers determine whether their Web services are conformant with Profile Guidelines.
- “SOAP Specifications Assertions and Test Collection”
- A SOAP 1.2 implementation that passes all of the tests specified in this document may claim to conform to the SOAP 1.2
- Baseline Standards have matured, for example:
- SOAP 1.1 – May 2000
- XML DSIG – Feb 2002
- SAML 1.0 – November 2002
- WS-Security – April 2002
- Integration with CA’s, policy stores, schema repositories, service repository registries
- Interoperability in a heterogeneous environment with application servers, in-house software, hardware devices from other vendors

## XML Security Hardware and FEA

-   The FEA is being constructed through a collection of interrelated "reference models"

- Hardware approach provides
- price/performance & manageability

- Hardware approach fits well
- within the Component Framework

- Hardware security gateway for
- cross-agency exchange

**Notes:**
How does the hardware-based XML webServices Security Fit into FEA?

What is FEA?
To facilitate efforts to transform the Federal Government to one that is citizen-centered, results-oriented, and market-based, the Office of Management and Budget (OMB) is developing the Federal Enterprise Architecture (FEA), a business-based framework for Government-wide improvement. 

The FEA is being constructed through a collection of interrelated "reference models" designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies. These models are defined as: 

-----------------------
PRM
To align and leverage existing federal guidance and application/architecture recommendations. It facilitates resource allocation decisions based on comparative determinations of which programs/organizations are more efficient and effective.
Save time and money by leveraging reusable business processes, data, and IT-components in other agencies
Application Architecture recommendations will be determined by “efficiency & effectiveness.”   Hardware-based  infrastructure will fit within this guidance based on XML security functionality with superior price/performance delivered through a hardware-based approach....save time & money.  Such core infrastructure components used and shared across agencies over variety of business processes.
--------------------
DRM
The Data and Information Reference Model (DRM) will describe, at an aggregate level, the data and information that support program and business line operations. The model will aid in describing the types of interaction and exchanges that occur between the Federal Government and its various customers, constituencies, and business partners.
Cross-agency communication and exchange should be easy and fluid using standard such as SOAP (request/response, notification, etc.) with security, routing trust considerations provided by standards such as WS-Routing, WS-Security, etc.
--------------------
TRM
The TRM is a component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities.
Details on next slide.

## XML Security Hardware & TRM

**TECHNICAL REFERENCE MODEL (TRM) **
*"The TRM is a component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities." *

**Notes:**
Hardware-based XML Gateway fits within the TRM model

FEA captures:

Essential transport protocols
Essential standards for information exchange
Mechanisms for transport and data level security, privacy, integrity and Authentication.

------------------------------------------------
TECHNICAL REFERENCE MODEL (TRM) 
"The TRM is a component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities."  

The Technical Reference Model (TRM) provides a foundation to describe the standards, specifications, and technologies to support the construction, delivery, and exchange of business and application components (Service Components) that may be used and leveraged in a Component-Based or Service-Orientated Architecture. The TRM unifies existing Agency TRMs and electronic Government (e-Gov) guidance by providing a foundation to advance the re-use of technology and component services from a Government-wide perspective. 

Service Access and Delivery AreaRefers to the collection standard and specifications to support external access, exchange, and delivery of Service Components or capabilities. This area also includes the Legislative and Regulator requirements governing the access and usage of the specific Service Component.

Service Platform and Infrastructure The Service Platform and Infrastructure Area defines the collection of platforms, hardware and infrastructure specifications that enable Component-Based Architectures and Service Component re-use. 

Component FrameworkThe Component Framework Area defines the underlying foundation and technical elements by which Service Components are built, integrated and deployed across Component-Based and Distributed Architectures. The Component Framework consists of the design of application or system software that incorporates interfaces for interacting with other programs and for future flexibility and expandability. This includes, but is not limited to, modules that are designed to interoperate with each other at runtime. Components can be large or small, written by different programmers using different development environments and may be platform independent. Components can be executed on stand-alone machines, a LAN, Intranet or on the Internet. 

Service Interface and Integration The Service Interface and Integration Area defines the discovery, interaction and communication technologies joining disparate systems and information providers. Component-based architectures leverage and incorporate Service Interface and Integration specifications to provide interoperability and scalability.

## XML Security Gateway within the FEA TRM framework 

- XML Security Gateway within the FEA TRM framework

## XML Security Gateway within the FEA TRM Framework 

## XML Security Gateway within the FEA TRM Framework 

## Q&A 

- Mamoon Yunus
- Forum Systems, Inc.
- 95 Sawyer Road
- Waltham, MA 02453
- 781-788-4200
- http://www.forumsys.com

- Eugene Kuznetsov
- DataPower Technology, Inc.
- One Alewife Center
- Cambridge, MA 02140
- (617)864-0455
- http://www.datapower.com