Mapping Security to a Services Oriented Architecture Mark O’Neill – CTO, Vordel.

Mapping Security to a Services Oriented Architecture

Mark O’Neill – CTO, Vordel

Cassis 2005 2

About the speaker

• CTO of Vordel – vendor of XML security products since 1999.

• Author of “Web Service Security”, published by Osborne/McGraw-Hill. Contributors include Phillip Hallam-Baker (Chief Scientist at VeriSign) and Ed Simon (XMLSec Inc, author of XML Signature specification)

• Contributing author of “Hardening Network Security”, published by Osborne/McGraw-Hill, 2005

• Published in XML Journal, Web Services Journal, PriceWaterhouseCoopers Cryptographic Journal of Excellence

• Background in EDI and in academic cryptography

Cassis 2005 3

A quote which puts the problem into context

"I told them I wanted to make an HTTPS request that would be

encrypted, and the firewall guys were fine with it. Even with

SOAP, because of the uniqueness of the IDs and the cues we

use, it's not easy to just write some random SOAP message and

break in."

http://www.eweek.com/print_article/0,3668,a=27390,00.asp

Cassis 2005 4

What I’ll be speaking about

• What is a Services Oriented Architecture?

• A “Whiteboard” diagram• How important are XML and SOAP to a SOA?

• How does security map to a Services Oriented Architecture?

• Transactional: Embedding security tokens in XML messages• Architectural: Deploying security services• XML-level: New XML-based threats

Cassis 2005 5

First – what is a “Services Oriented Architecture” ?

An SOA uses a Services Layer to hide underlying complexity

Businesses can save money and time by developing against this Services Layer, rather than developing directly against an ERP/legacy layer

Also known as a “Business Interface Layer”, or a “Business Services Layer”

Cassis 2005 6

How do you go about creating a “Services Oriented Architecture”?

Gartner define “SODA” as Services Oriented Development ofApplications

SODA has seven aspects:

1. Design. Focus on process-oriented design rather than component-based design. Process and workflow should be built into the design, not added later.

2. Modeling. Using UML or similar. Includes modeling the structure and flow of business processes, as well as application modeling and technical modeling.

3. Fabrication. The actual creation of service components. Includes not only XML, but also adapters and integration technology

4. Assembly. Connecting service components together. May be achieved using a visual tool.

5. Orchestration. After assembly, workflow defines how information and logic will flow through the process. Introduces state and flow control.

6. Automation. Code generation to map from the model to the implementation. E.g. from scripts, or UML, or XML to EJB or .NET components.

7. Variability and rapid application maintenance. Ensures that changes to composite systems does not break the rest of the system. Services must be able to adapt to multiple purposes or versions.

Gartner predict that application development tools will evolve to

include these seven SODA aspects.

Cassis 2005 7

Just how important are XML and SOAP for a Services Oriented Architecture ?

XML and SOAP are certainly a good excuse to implement a Services

Oriented Architecture now, rather than doing it 5 years ago.

However, the concepts of a Services Oriented Architecture go beyond the

implementation technologies used

• Services should be understandable by non-technical business people

• Implementation technologies can be changed, without breaking the interface

• Asynchronous messaging is preferable to tightly-coupled RPC styles of integration

The most important feature of XML and SOAP is that fact that they are

vendor-neutral and have no competition

Cassis 2005 8

How are Vordel’s customers using Web Services and SOA?

In Vordel’s customer base we see XML and Web Services being used for:

- Transmitting and processing smartcard personalization files- Accessing credit reports- Outputting telecoms account information- Document management in eGovernment

In all cases, XML is used as a data format because it simplifies integration.

Web Services technologies, such as SOAP and WSDL, are being used to create reusable interfaces on top of complex underlying systems

These XML and Web Services projects are enabled by security

Cassis 2005 9

The security risks for an SOA

1. Complexity!• Web Services are designed to reduce complexity, but if you’re not careful,

they can become complex too. Unmanaged complexity breeds insecurity

2. Unauthorized access• Most cross-firewall Web Services are for closed-user-groups of partners.

Therefore, access control is very important.

3. XML-level threats• XML introduces new threats such as “XML Denial of Service”

Cassis 2005 10

Transactional Security – The architectural challenge for SOA security

Who is accessing this system? Can I map their identity to a local store?

How did they authenticate? When did they authenticate?

What are their entitlements?

?

Cassis 2005 11

Thinking in terms of the transaction

An SOA means that users access business systems through multiple layers.

This is why it’s necessary to bind the security context to XML messages.

WS-Security and SAML are important technologies for achieving this.

Then, at each layer, we have control

Cassis 2005 12

The risk of complexity

Managing transactional security can become very complex very fast

How I do control which application can access which Web Service?

• You could code/configure security policies in each Web Services platform and try to sync them up together…

• Do you really want to do this?

Security policies are required here, here, here, here, and here.

( So is auditing, SLA management, reporting, etc)

Cassis 2005 13

Security Services

So, rather than coding the same security functionality in each platform, why not make use of Web Services?Authentication

• Username/Password AuthN (HTTP-Auth, WS-Security)• Certificate Validation• Token issuance (SAML)

Authorization• Integration with Web Access Control• SAML AuthorizationDecisionQuery

Audit• Logging services

Confidentiality and Privacy• Encryption• Digital Rights Management

Content validation• Threat scanning of XML

Integrity• OASIS Digital Signature Services (DSS), Time-stamping

Cassis 2005 14

What is the alternative to deploying reusable Security Services?

The alternatives to deploying reusable security services are:

• Code and configure security rules in your Web Services platforms (.NET, J2EE, etc) and try to get them all to talk to each other

• Use multiple implementations of WS-Security, SAML, etc.

• Keep revisiting decisions on how to implement Web Services Security. Firstly at the XML Gateway, then at the application server, etc.

With reusable Security Services, you get all of the advantages of Web Services, for security functionality.

These Security Services can be used by an XML Gateway, and by code at the application server

Cassis 2005 15

Mapping Security to an XML transaction

Security of the user, data, and transaction is added to the information flow

This is the “deperimeterisation” model

Cassis 2005 16

Defensive security: Blocking new XML-level threats

We’ve looked at transactional security and at security services

Now let’s look at another side of security – blocking content-based threats

Cassis 2005 17

Attacks moving up the stack

Application Layer security has existed long before SOAP.

Application Layer security for Web servers began with securing the Web server itself

• Patches, security updates

Next came “Web Application Security”• A Web application is a CGI-based application with which a user interacts

using a web browser.• Attacks include SQL Injection, Cross-Site Scripting, Cookie “poisoning”,

changing URL parameters (e.g. trying to guess a session ID to get access to an online bank account)

SOAP itself can be seen as a “Web Application”

Cassis 2005 18

New forms of Denial-of-service

Preventing denial-of-service attacks

• XML introduces “asymmetric Denial of Service” • A single XML message can cause damage to a naïve or misconfigured

system

Cassis 2005 19

XML Denial-of-Service using DTD recursion

Scenario: DTDs are vulnerable to recursion attacks

For example, the following DTD contains a recursively defined entity "&x100;" that would be expanded into the huge amount of 2^100 repetitions of the string "hello" by any XML 1.0 standard compliant parser. This would cause excessive memory usage (and subsequent failure) and/or excessive CPU usage:

<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE foobar [ <!ENTITY x0 "hello"> <!ENTITY x1 "&x0;&x0;"> <!ENTITY x2 "&x1;&x1;"> <!ENTITY x3 "&x2;&x2;"> <!ENTITY x4 "&x3;&x3;"> ... <!ENTITY x98 "&x97;&x97;"> <!ENTITY x99 "&x98;&x98;"> <!ENTITY x100 "&x99;&x99;"> ]> <foobar>&x100;</foobar>

Cassis 2005 20

XML Denial-of-Service using DTD recursion

Platforms requiring patches for this attack were:ColdFusion MX, Sybase EAServer, IBM WebSphere, Microsoft .NET.

Impact:Web Services platforms could be disabled by sending them a single SOAP message.

Solution: The SOAP specification states “A SOAP message MUST NOT contain a Document Type Declaration" (http://www.w3.org/TR/SOAP/ Section 3).

However, some SOAP-enabled products were vulnerable because they parsed DTDs. The solution is to not support DTDs in SOAP.

Cassis 2005 21

Replay Attacks

Scenario: A Web Service is being protected by an XML Gateway which scans incoming XML to make sure the messages are encrypted and signed.

This system is vulnerable to a replay attack which simply replays a valid message, gaining unauthorized access.

Impact: Unauthorized access

Solution:The usage of timestamps to block replay attacks. WS-Security includes support for timestamps. A replayed message will include the same timestamp as the original message. This means that both messages must be discarded, because it cannot be established which message was the original, and which is the copy.

Beware of any solution which claims “this is secure because all incoming messages are signed”.

Caution:Don’t confuse replay attacks with “flooding” denial-of-service attacks.

Cassis 2005 22

Anatomy of a SQL Injection Attack

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header></SOAP-ENV:Header>

<SOAP-ENV:Body

<BookLookup:searchByIBSN xmlns:BookLookup="https://www.books.com/Lookup">

<BookLookup:IBSN>' exec master..xp_cmdshell 'net user Joe pass /ADD’<BookLookup:IBSN>

</BookLookup:searchByIBSN>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

VB.NET code:Set myRecordset = myConnection.execute("SELECT * FROM myBooksTable WHERE IBSN ='" & IBSN_Element_Text & "'")

Becomes:SELECT * FROM myTable WHERE IBSN =‘’ exec master..xp_cmdshell 'net user Joe pass /ADD

Cassis 2005 23

Insecure management consoles

Scenario: Oracle 9i. “In this default installation, the ability to deploy/un-deploy SOAP services is unrestricted and thus may pose a security threat especially in situations where the Oracle9iAS v.1.0.2.2 HTTP server might be accessed via the Internet.” http://otn.oracle.com/deploy/security/pdf/ias_soap_alert.pdf

Impact: Web Services can be selectively disabled via the Web Service platform management console

Solution: Ensure that your Web Services platform, or indeed your Web Services security product, does not expose a management interface to untrusted parties.

Caution: Beware of security solutions which expose Web-based management interfaces to untrusted users

Cassis 2005 24

Putting it all together

Services Oriented Architectures present security problems, which are not insurmountable. They require:

• A solution which takes into account the full transaction

- A Security context from the user to the system they ultimately access

• Security Services

- Reusable security services which can be used across the enterprise

- For XML validation, signing, encryption, logging

• XML threat-blocking

- Awareness of new XML-based threats, and blocking these threats

Cassis 2005 25

Security and the Semantic Web

Syntactic Semantic

• Confidentiality • Privacy

• Authentication • Authorization

• Licenses • Permissions

• Confidentiality: XML Encryption, WS-Security• Privacy: What must be protected – not only during transmission but also after

receipt

• Authentication: SSL, WS-Security UsernameToken Profile, WS-Security X.509 profile

• Authorization: Defining roles like “Manager”, defining membership of groups

• Licenses: XRML, and others• Permissions: Defining usage of data, such as disclosure control, retention,

destruction

Cassis 2005 26

Semantics – missing from security

• In any given security context there are at least three primary actors:• 1) the User, 2) the Transaction, 3) The data.

• Security descriptors may be used to convey the security requirements of each actor

• There are some initiatives to annotate Web Services with security descriptors

• Syntactic: WS-SecurityPolicy and WS-PolicyAttachment can be used to define a policy such as “sign all input and include the public key, and I’ll use that public key to encrypt the output I send back to you” [Transaction]

• Semantic: 2004 paper “Authorization and Privacy for Semantic Web Services” – proposes attaching security information to OWL-S input and output parameters. [User]e.g. using FOAF (Friend of a Friend) foaf:Person to specify personal information is transmitted as encrypted data and never appears as output of a Web Service

• Syntactic: XRML can be used to define limits on the ability to “share” a document [Data]

• Semantic: Desktop software enforces this “share” permission – e.g. blocking email forwarding

Cassis 2005 27

Vordel’s products address each stage ofan organization’s XML roadmap: From initial design and testing, through thefirst Web Services deployments, finally todeploying a Services Oriented Architecture

Vordel’s Products

Vordel SOAPbox is a Web Services security testing application which is used by over 3500 registered users worldwide.

VordelSecure is an XML Gateway. Architecturally, it is a reverse proxy, detectingand blocking malicious traffic, and only allowing XML from trusted sources.

VordelDirector is an enterprise XML Security Server. It provides security services which are used by security enforcement points around the enterprise. Policies in VordelDirector are enforced at proxies and at “security agent” plug-ins.

Cassis 2005 28

What are the security requirements an XML Gateway?

Access Control • Authentication at both the transport layer and the XML layer• Per-service authorization, even when multiple services are at the same

URL• Compliance with WS-Security, SAML, and other relevant standards

XML threat-awareness• Ensure that XML messages have valid format and content • Ensure that SOAP attachments are of the appropriate format and size• Block XML denial-of-service attempts

Integration with existing security infrastructure• Link to silos of identity information in LDAP directories and Active

Directory• Send alerts to enterprise monitoring tools

Auditability• Log all XML activity and provide a reporting interface

Administration• Allow policies to be updated without a requirement to edit code or edit

XML

Cassis 2005 29

XML Security Server

VordelDirector is an XML Security Server

• It provides a central point to manage XML security for the entire organisation

• APIs are provided in Java and C, and a SOAP interface is provided (of course!)

• Security services carried out by VordelDirector include signing, encryption/decryption, XML content analysis, SAML processing, and logging

• VordelDirector is available for Windows, Linux, and Solaris

Cassis 2005 30

Thank You !

Mark O’Neill

CTO, Vordel

[email protected]

www.vordel.com