mapping security to a services oriented architecture mark o’neill – cto, vordel
Post on 19-Dec-2015
213 views
TRANSCRIPT
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