Mapping Security to a Services Oriented Architecture Mark ONeill CTO, Vordel

Open Group, April 2005

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 HallamBaker (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
Open Group, April 2005 2

About Vordel

A vendor of XML security products since 1999. Based in Dublin, London, and Boston Customers include the European Union, the Spanish Government, Telefonica, Fortis, Experian, Ericsson, Bell Canada Standards-based integration with identitymanagement tools Vordel supports a wide range of open standards and specifications and interoperates with many popular Web Services platforms, making it a likely choice for many enterprises looking to protect their Web Services from unauthorized or malicious traffic. Jason Bloomberg - ZapThink

Open Group, April 2005

Vordels User Conference

Speakers from Entrust, RSA Security, Software AG, QA Consulting Enterprise architects from Vordels customer base describe how they have integrated security into their Services Oriented Architectures Tutorial on Web Services Security included in conference fee June 8-10 in Westbury Hotel, Dublin

Open Group, April 2005

What Ill 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

Open Group, April 2005

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

Open Group, April 2005

How do you go about creating a Services Oriented Architecture?

Gartner define SODA as Services Oriented Development of Applications 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. Modelling. Using UML or similar. Includes modelling the structure and flow of business processes, as well as application modelling and technical modelling. 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.

Open Group, April 2005

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

Open Group, April 2005

The security risks for an SOA

1. Complexity!
Web Services are designed to reduce complexity, but if youre 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

Open Group, April 2005

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?

Open Group, April 2005

10

Thinking in terms of the transaction

An SOA means that users access business systems through multiple layers. This is why its 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

Open Group, April 2005

11

Security tokens inside an XML message

In this message, security tokens are highlighted in yellow. We see a SAML Authentication assertion, digitally signed along with the SOAP body.

[ screenshot from Vordel SOAPbox application free download from www.vordel.com ]

Open Group, April 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)
Open Group, April 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
Open Group, April 2005 14

So how is this implemented?

At each point where you must consume or send XML, also apply security Where? At the perimeter (XML Gateway) At the Web Service endpoint (application server)

Security Services simply means deploying security functionality as Web Services that are on tap as part of an SOA.

Open Group, April 2005

15

The Security Bus

When a security context flows with XML messages through an SOA, through the use of security services, it can be thought of as a Security Bus

Open Group, April 2005

16

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

Open Group, April 2005

17

Defensive security: Blocking new XML-level threats

Weve looked at transactional security and at security services Now lets look at another side of security blocking content-based threats

Open Group, April 2005

18

STRIDE Threat model - thinking about security in terms of threats

Developed by Michael Howard and David LeBlanc in Microsoft Documented in Writing Secure Code [Microsoft Press] The first step is to draw the data flow for a system and then identify which threats apply at each system entity, and at each link between entities

STRIDE stands for:

Spoofing Tampering Repudiation Information disclosure Denial of service Elevation of Privilege

Then apply a "DREAD" category to assess each threat from 1 to 10:

Damage potential Reproducibility Exploitability (How much effort and skill is needed to execute attack? Affected users (How many users would be affected?) Discoverability (Assume a vulnerability will be discovered)

Calculate the average to arrive at a DREAD number for each threat

Open Group, April 2005 19

STRIDE and DREAD for Services Oriented Architecture

Spoofing of data between the Web Services Tampering of XML data in transit, or in storage Repudiation of the end user, or the owner of the portal Information disclosure at the Web Service, or from the audit logs Denial Of Service at the Web Service Elevation of Privilege e.g. if the Web Service, or the Web Services platform, includes backdoors The good news is that Web Services attacks tend to be specific to a certain Web Service, so the Reproducibility (the R in DREAD) may be low The bad news is that Web Service are often a Royal Road into back office systems, the Damage potential (the D in DREAD) may be high

Open Group, April 2005

20

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

Open Group, April 2005

21

New forms of Denial-of-service

Preventing denial-of-service attacks

Blocking unwanted message storms Blocking messages which are designed to cause processing problems These can be intentional, as well as unintentional E.g. State of Georgia Web Services case study "We brought down a mainframe, legacy systems usually must undergo some preparation to handle the additional queries. "That's definitely a problem because those systems aren't designed to have that kind of load. Instead of batch processes, we have citizens hitting the same processes or same services." http://www.govtech.net/magazine/story.php?id=66547

Open Group, April 2005

22

SQL Injection

Web Application SQL Injection Attacks Inserting SQL statements into web forms in order to force a database to return inappropriate data, or to produce an error which reveals database access information. Web Services SQL Injection Attacks For Web Services, this category of attack translates into manipulating data in a SOAP message to include SQL statements which will be interpreted by a back-end database.

Open Group, April 2005

23

Anatomy of a SQL Injection Attack

<SOAP-ENV:Envelope xmlns:SOAPENV="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>1234567890<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 myBooksTable WHERE IBSN = 1234567890

Open Group, April 2005

24

Anatomy of a SQL Injection Attack

<SOAP-ENV:Envelope xmlns:SOAPENV="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
Open Group, April 2005 25

Defending against a SQL injection attack Ensure the format of incoming SOAP parameters using an XML Schema <simpleType name=ibsn"> <restriction base="string"> <pattern value="[0-9]{10}"/> </restriction> </simpleType> Validate this Schema against the data isolated by the following XPath expression: /Body/BookLookup:searchByIBSN/BookLookup:IBSN 1234567890 passes ' exec master..xp_cmdshell 'net user Joe pass /ADD' -- fails

Open Group, April 2005

26

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: Dont confuse replay attacks with flooding denial-of-service attacks.

Open Group, April 2005

27

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>

Open Group, April 2005

28

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.

Open Group, April 2005

29

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
- The Security Bus - 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 Authentication, Authorization, XML validation, signing, encryption, logging

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

Open Group, April 2005

30

Real-life examples

Large North American telco: Vordel and Entrust deployed Web Services security and Web Access Control side-byside. Browser traffic and SOAP traffic are managed using the same policy set. European public utility company: Vordel deployed security for a .NET infrastructure, performing access management and XML threat analysis. (controlling who can access the systems, and what they send into the systems). More details at: http://www.vordel.com/customers/case_studies.html Or ask me after this talk!

Open Group, April 2005

31

Thank You !

Mark ONeill CTO, Vordel mark.oneill@vordel.com www.vordel.com

Open Group, April 2005

32