Mapping Security to a Services Oriented Architecture

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

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 of • Applications • SODA has seven aspects: • Design. Focus on process-oriented design rather than component-based design. Process and workflow should be built into the design, not added later. • Modeling. Using UML or similar. Includes modeling the structure and flow of business processes, as well as application modeling and technical modeling. • Fabrication. The actual creation of service components. Includes not only XML, but also adapters and integration technology • Assembly. Connecting service components together. May be achieved using a visual tool. • Orchestration. After assembly, workflow defines how information and logic will flow through the process. Introduces state and flow control. • Automation. Code generation to map from the model to the implementation. E.g. from scripts, or UML, or XML to EJB or .NET components. • 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 • Complexity! • Web Services are designed to reduce complexity, but if you’re not careful, they can become complex too. Unmanaged complexity breeds insecurity • Unauthorized access • Most cross-firewall Web Services are for closed-user-groups of partners. Therefore, access control is very important. • 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. 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 What is the alternative to deploying reusable Security Services? 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. We’ve looked at transactional security and at security services Now let’s look at another side of security – blocking content-based threats Defensive security: Blocking new XML-level 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. 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 New forms of Denial-of-service 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 • 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 • 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

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 • mark.oneill@vordel.com • www.vordel.com Cassis 2005