1 / 16

Web Services Security

Web Services Security. Enterprise Architect Summit – 2004 Mark O’Neill CEO. XML Security requirements. Protect XML systems by ensuring that only the right users using the right applications sending the right data can connect. What are examples of XML systems?

mayfielda
Download Presentation

Web Services Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Services Security Enterprise Architect Summit – 2004 Mark O’Neill CEO

  2. XML Security requirements • Protect XML systems by ensuring that only the right users using the right applications sending the right data can connect. • What are examples of XML systems? • New XML interfaces into established database and CRM products • Service Delivery Platforms (e.g. for mobile telecoms) • Service Oriented Architectures • EDI exchanges using XML documents • Collaborative systems which use XML, e.g. instant messaging • Web Services Enterprise Architect 2004

  3. Insecurity Complex • It’s well known that Web Services have provoked security concerns.However, there is a lot of confusion in the area – leading to a common belief that Web Services are “just plain insecure”. • The vast number of new specifications and standards for Web Services security may seem to indicate a security nightmare for Web ServicesHowever, many of the initiatives for Web Services security – such as WS-Security and the Liberty Alliance – are about bridging security domains and solving security interoperability problems – not about “plugging holes”. • They are enabling security, not protective security Enterprise Architect 2004

  4. What is the problem? • Web Services have three distinct security issues: • Authorize the end-user, even if the end-user has authenticated in a different security domain from the Web Service, using a different authentication method, under a different profile. • Block new application layer threats that make use of XML and SOAP. • Block unauthorized clients from accessing Web Services. 1 2 3 Enterprise Architect 2004

  5. Use or Misuse? • Ironically: • An attacker who can break through the access control layer can cause more damage using a valid SOAP message than using an invalid SOAP message… because the valid SOAP message will work. • In other words, use of a Web Service by an intruder is often more dangerous than misuse of a Web Service by the same intruder. • Think about it – if an attacker can get past the access control for a bank’s inter-bank money transfer Web Services, what represents the greatest threat: • (a) use it to transfer money to their bank account, or; • (b) pass it enormous parameters to probe for a buffer-overflow attack? Enterprise Architect 2004

  6. The solution: • There are two architectural options for applying security to XML/Web Services: • Network-level filtering of traffic targeted at the XML System (i.e. an “XML Firewall”) • Deploy XML security as a shared service for an entire XML network (an enterprise-wide “security server”) Enterprise Architect 2004

  7. Two product requirements • “XML gateway” (hardware or software). • Filters XML traffic in-line • Deployed as software, or as an appliance with HSM and crypto-acceleration • “XML security server” • Centralize the security management for an entire XML network, across network boundaries and tiers • Provide enforcement plug-ins (“security agents”) for common Web Service platforms and with proxies (“traffic cops”) to filter traffic in-line. • An API is essential [Java and C++] to create custom agents. • Suitable for securing a Service Oriented Architecture Enterprise Architect 2004

  8. Suitable for organizations which have a network chokepoint suitable to act as a logical XML gateway: XML traffic is authenticated and validated, then routed to its destination Messages may be signed, encrypted, or transformed by the gateway Multiple XML systems be protected by one XML Gateway A single XML Gateway may consist of multiple copies, distributed using a Load balancer (e.g. Cisco Local Director) Hardware options: 1U appliance [SafeNet], Intel Itanium 2, cryptographic acceleration cards (SafeNet, nCipher) XML Firewall Enterprise Architect 2004

  9. An XML Security Server is a server dedicated to XML security processing It performs encryption, signing, SAML issuance and validation, WS-Security processing, as well as connecting to identity-management infrastructure. It avoids the need to program security into each XML System. Enforcement points – agents, API, and proxies are distributed around the network. An XML Security Server is particularly suitable to secure a Service Oriented Architecture, where there is no logical “choke point” in which to put an XML Firewall. It provides a central point for management and reporting of XML traffic. XML Security Server Enterprise Architect 2004

  10. In this diagram, an XML Gateway is in place as a “perimeter”, while some internal Web Services have begun to appear also. Typical Web Services rollout Enterprise Architect 2004

  11. Perimeter security does not prevent attacks which make use of points of access such as VPNs or Wireless LANs, which are launched internally. Security is required to be pervasive, rather than perimeter-based. Points of attack in a Web Services rollout Enterprise Architect 2004

  12. The XML Security Server allows XML security rules to be enforced across the organization. Security is a Service. It’s pervasive security, not perimeter security. XML Security Server Enterprise Deployment Enterprise Architect 2004

  13. VordelSecure – XML gateway • XML gateway • Proxy for XML and SOAP traffic • Filters XML according to security rules, based on the sender and the content • Supports SSL, WS-Security, SAML • “Service virtualization” means that Web Services names and implementation details are hidden behind the XML gateway • Web Services systems are protected from direct contact by untrusted entities • Real time monitoring and security transaction reporting • XML security appliance • Safenet and Vordel • Cryptographic acceleration • Secure key storage, for digital signing and encryption Enterprise Architect 2004

  14. VordelDirector – XML security server • XML Security Server with Agents • Agents embedded in application endpoints (e.g. SOAP, TIBCO, MQ etc.) • Meta-policy management • Coordinating policies from Single Sign-On, WSDL, Alerting systems • Agent API for creation of agents to enforce VordelDirector functionality • Real time monitoring and security transaction reporting • VordelConnect • Single Sign-On • RSA ClearTrust, Entrust GetAccess, IBM Tivoli Access Manager, Oblix NetPoint • Firewalls • OPSEC • Digital Certificate Management • Entrust PKI, RSA Keon, VeriSign • LDAP Directories • SunOne Directory Server, Microsoft Active Directory Server, IBM Directory Server Enterprise Architect 2004

  15. Summary • Security for XML/Web Services means controlling: • Who runs your Web Services, • What XML data they send • Standards exist which are useful • WS-Security, WS-* • SAML • Products exist • VordelSecure • VordelDirector Enterprise Architect 2004

  16. Enterprise Architect 2004 Vic Morris CEO vic.morris@vordel.com

More Related