1. No category

Mapping Security to a Services Oriented Architecture
Mark O’Neill – CTO, Vordel
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
Cassis 2005
2
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
3
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
4
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
5
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. 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
6
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
7
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
8
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
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
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
20
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
21
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
Cassis 2005
22
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
23
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
24
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
25
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
26
Vordel’s Products
Vordel’s products address each stage of
an organization’s XML roadmap:
From initial design and testing, through the
first Web Services deployments, finally to
deploying a Services Oriented Architecture
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, detecting
and 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
27
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
28
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
29
Thank You !
Mark O’Neill
CTO, Vordel
mark.oneill@vordel.com
www.vordel.com
Cassis 2005
30