Securing Web Services Using XML Security Gateways

2. Securing Web Services UsingXML Security Gateways Session Number H2 Tim Bond Mon, 3/19/2007 1:30 PM - 3:00 PM

3. Key Points • Brief intro to SOA & Web services • What are the Web services threats? • What is an XML firewall/gateway? • Advanced features of XML gateways • Why XML gateways are useful • What can’t an XML gateway do? • An overview of vendors

4. Service Oriented Architecture • An IT strategy to enable Business Transformation • A way of designing loosely coupled systems • About building IT systems out of parts • ROI predicated on the concept ofre-use • Not a new concept (CORBA, RPC) • Wide acceptance due to XML, web services ubiquity, and standardization

5. Loosely coupled applications Reuse Agility Advantages of SOA

6. Web apps vs. web services A Web portalis the UI to an enterprise SOA. Web Servicesare designed to be initiated on behalf of a user. 1 2 3

7. WS standards SOAP WSDL UDDI WS-* Security standards TLS S/MIME WS-Security XML Signature XML Encryption SAML WS-SX Brief intro to Web services(the alphabet soup ) SOAP

8. Threats on the Conventional Web Consider: • Attack vectors focused on exploitation of utilizing a limited API • Few verbs (largely GET and POST) • Indirect access to app. server via web server view • Very simple security model • Limited authentication, automatic confidentiality and integrity, simple authorization, etc Insider attacks Native API Man-in-the-middle with DNS attacks DNS Internal Network DMZ HTTP/HTML veneer provides limited view of app server API Identity Web server attacks Browser attacks (spyware, etc)

9. Web Services are More Complicated Sophistication Brings Greater Threats: • Richer API model, often published directly by application server • An API of infinite verbs and nouns • XML base brings great complexity • E.g. External entities, as well as tons of referencing mechanisms • Very complex message security model • Multi-hop messaging, asynchronous messaging Web Services Application Server Intermediaries Web Services Client Internal Network DMZ WS Security-compliant secure SOAP message Human Identity Perhaps most important: Higher value transactions App Identity

10. Web service threats • Web services with active interfaces allow usage of applications that were previously restricted to using conventional/custom authentication & authorization • SOAP enables function calls and XML data to be tunneled over HTTP and bypass network/application firewalls – no physical perimeter • Services and directories may create holes for sensitive information to leak out of the enterprise, and for erroneous or fraudulent info to be delivered

11. Why SSL (HTTPS) isn’t enough • SSL is only for point to point connections • Data unprotected upon reaching the server • Authentication of origin lost if more than one service is involved • Only usable for a few protocols (mainly HTTP) • Only transport of wholedocument is encrypted vs. partial for collaborative exchanges • Header information no longer readable SSL SSL XML Encryption/DSig

12. Taxonomy of XML Threats (1)

13. Taxonomy of XML Threats (2)

14. Risks of Distributed Security Enforcement 1. Can application developersimplement security on XML/WS? 2. How do you ensure complianceacross applications & processes? 3. How do you monitor and audit transactionsthat are app-to-app? Svc Svc Svc SOA Security “Parallel Processing” Needs to be abstracted Svc Svc Svc Svc Svc Svc Svc Svc Svc

15. WSDL Scanning • WSDL Files are commonly auto generated • May expose the internal structure of the server where the web service resides • Careful study of the WSDL may allow attacker to guess operations not exposed through WSDL

16. WSDL scanning (2) Server may support other operations besides those listed in WSDL!

17. Data Validation • Inbound and outbound • XML well-formedness checks • SOAP protocol checks • XDoS checks • XML Schema validation • Filtering

18. Data validation (2) Are these types enforced? What happens if you pass in a string?

19. Threat summary • Many threats in the Web Services environment • Some old • Some new

20. What is a Firewall? A point of policy enforcement between two organizations with different levels of trust • Mostly filter/block at TCP/UDP/IP layer • You probably have one at home:

21. Properties of Firewalls • Denies access by default • Keeps track of network session state (FTP) • Robust blocking mechanisms • Can handle large amount of traffic at wire speed • Can inspect traffic, but ability generally limited • Audit mechanisms • DoS protection • FIPS/other certifications • Load balance / scalability

22. What is an XML Firewall/Gateway? Same concept as firewalls but . . . • Focus on application layer (SOAP, HTTP) • Functions as intermediary rather than inspector

23. XML gateway/firewall properties • Hardware form factor (often) • Complex policy enforcement • Common vulnerability protection • SQL injection • JavaScript • Ajax

24. Key Features of anXML Firewall/Gateway • Support latest WS-* standards • Advanced threat management • Trust management • Can decrypt & inspect inbound traffic • Can verify signatures on inbound traffic • Can encrypt/sign outbound traffic • Configuration needs to be customized for each deployment • System needs to be easy to administer and manage

25. Network Firewall Focused on blocking inbound and/or outbound TCP ports Knows rudiments of network protocols (HTTP, FTP, SMTP) Doesn’t (usually) do standards enforcement Frequently integrated with intrusion detection XML Firewall Focused on application level protocols Will enforce different application-level policies at every site Generally enforces WS security standards Doesn’t know about any network protocols except HTTP/HTTPS Key Differences: XML Firewall vs. Network Firewall

26. Advanced Features • Some have SSL accelerators • Offloads SSL overhead to hardware • Most helpful when many small SOAP requests • Some have XML processing accelerators • Offload XSLT and other processing to hardware • Most helpful when complex XSLT processing • Application level load balancing • Client side implementation to enables advanced features in non-security-aware clients

27. Why XML Gateways are Useful • Centralized security in DMZ • Separates policy from web service implementation • Standardizes security across web service implementation platforms • Don’t have to train web service developers (as much) • Insulates web service implementation from standards churn • Insulates partner from standards churn • Hardened platform

28. Service policy editing

29. Custom message routing, authentication, load balancing

30. What can’t an XML gateway do? • Protect against flaws in web service implementations • Unless policy defined to prevent usage • If a WS allows reformatting the disk, XML gateway can filter input but can’t stop things it doesn’t know about • Operate without understanding the web services provided in an environment • Provide a 100% guarantee of security

31. Who are the vendors • IBM/DataPower (acquisition completed 2005) • Forum • Cisco/Reactivity (announced Feb 21 2007) • Layer 7 • Vordel • probably others…

32. Some Differences Among XML Firewall Vendors • Appliance vs. software (or both) • Ability to manage multiple units for scalability • Richness of policy specifications • Level of standards support

33. Summary • XML Gateways can: • Enforce security policies • Protect web services from many types of attacks • Allow central security management • XML Gateways cannot: • Be deployed without knowledge of the web services • Entirely eliminate the risks of web services

34. Acknowledgements Thanks to Forum Systems and Layer 7 Technologies who provided many of the slides used in this presentation!

35. Contact Information Tim Bond Principal Security Architect webMethods, Inc. tbond@webMethods.com 703-251-7144