1. Herndon, VA October 12, 2006 Navigating Web Services Standards NIST Special Publication 800-95

2. 1 NIST SP 800-95  Draft released August 30, 2006 –http://csrc.nist.gov/publications/drafts.html#sp800-95http://csrc.nist.gov/publications/drafts.html#sp800-95  Public comment period ends October 30, 2006 –E-mail 800-95comments@nist.gov800-95comments@nist.gov –“Comments SP800-95” in the subject line  No NIST guidance for Web services prior to 800-95

3. 2 Table Of Contents  NIST SP 800-95 Structure  Web Service Security Functions and Technologies  Web Portals  Secure Web Service-Enabling of Legacy Applications  Secure Implementation  Secure Development Scenarios

4. 3 Table Of Contents  NIST SP 800-95 Structure  Web Service Security Functions and Technologies  Web Portals  Secure Web Service-Enabling of Legacy Applications  Secure Implementation  Secure Development Scenarios

5. 4 NIST SP 800-95 Structure  Introduction –Introduction to Web services –Overview of security challenges facing Web services –Overview of how those challenges can be met  Web Service Security Standards and Technologies –Authentication –Authorization and Access Management –Confidentiality and Integrity –Accountability –Availability –Securing Discovery

6. 5 NIST SP 800-95 Structure, cont’d…  Web Portals –Portals acting on behalf of users –User authorization and access to Web services –Portal interaction with discovery services  Web service-enabling of legacy applications –Authentication –Authorization and Access Control –Public Key-Enabling –Accountability –Database Security Challenges –Integrity

7. 6 NIST SP 800-95 Structure, cont’d…  Secure Implementation Tools and Technologies –General discussion of Web services developer toolkits –How XML parsers affect security –Languages for secure Web services development: Java,.NET, C, and C++ –Security Testing  Secure Development Scenarios –Implementing Web services from scratch –Implementing heterogeneous Web services –Enabling a legacy system using Net-Centric Enterprise Services –Using XML Gateways to “security enable” existing Web services

8. 7  NIST SP 800-95 Structure  Web Service Security Functions and Technologies  Web Portals  Secure Web Service-Enabling of Legacy Applications  Secure Implementation  Secure Development Scenarios Table Of Contents

9. 8 Web Services Standards Related To Security These dimensions are based on those defined in the paper Securing Service-Based Interactions: Issues and Directions by Hamid Nezhad, et al [1] [1] SP 800-92, Guide to Computer Security Log Management, is available at http://csrc.nist.gov/publications/nistpubs/http://csrc.nist.gov/publications/nistpubs/ DimensionRequirementSpecifications Messaging Confidentiality and Integrity WS-Security (XML Enc.) SSL/TLS (HTTPS) Authentication WS-Security (SAML, X.509) SSL/TLS (X.509) Resource Authorization XACML XrML RBAC, ABAC Privacy EPAL XACML AccountabilityAuditing tools, NIST SP 800-92 Negotiation Registries UDDI ebXML Semantic Discovery SWSA OWL-S Business ContractsebXML

10. 9 Web Services Standards Related To Security These dimensions are based on those defined in the paper Securing Service-Based Interactions: Issues and Directions by Hamid Nezhad, et al [1] [1] SP 800-92, Guide to Computer Security Log Management, is available at http://csrc.nist.gov/publications/nistpubs/http://csrc.nist.gov/publications/nistpubs/ Trust Establishment WS-Trust XKMS X.509 Proxying SAML WS-Trust Federation WS-Federation Liberty IDFF Shibboleth Security Properties PolicyWS-Policy Security PolicyWS-SecurityPolicy Availability WS-ReliableMessaging WS-Reliability

11. 10 Identification, Authentication and Authorization  SSL-certificates –SSL between two Web services can provide identification and authentication of the host machines –This does not authenticate individual Web services –This is only a point-to-point solution  WS-Security –Message-level authentication –Supports a variety of authentication Tokens: X.509, SAML, username/password

12. 11 Distributed Authorization  SAML –SAML Assertions allow a trusted third party to digitally sign a user’s attributes that can be passed to other Web services –SAML protocol allows Web services to send authorization queries and/or request attributes from the identity store –SAML 2.0 provides an XACML mapping  XACML –Distributed security policy based on XML –Mechanism for querying the policy  Using XACML and SAML together provides a distributed authorization mechanism using interoperable XML technologies

13. 12 Trust Federation  Web services are limited to being able to trust the identity of the service. –Just because a Web service’s identity can be established does not mean that the service itself is inherently trustworthy.  Trust federation allows organizations to share resources without merging their authentication and authorization facilities  WS-Federation –Based off WS-Security and WS-Trust –Can use any WS-Security token  Liberty Alliance and Shibboleth –Use SAML assertions and extend the SAML specification

14. 13 Confidentiality, Integrity, and Availability  Confidentiality and Integrity –SSL provides transport-layer confidentiality and integrity –WS-Security uses XML Encryption and XML Digital Signature to provide message-layer confidentiality and integrity –No support for QoP in Web services. –OASIS refers all QoP questions to the WS-Security standard  Availability –WS-ReliableMessaging and WS-Reliability introduce reliable messaging to Web services –Currently, there is no support for QoS in Web services –Service deadlocks and recursion

15. 14 Accountability and Securing Discovery  Accountability remains a hard problem –No logging standards –Web services may be outside of organizational control –Need for distributed logging –SP 800-92 is a step forward  Securing Discovery –Discovery integrity is essential –Discovery services open Web services to reconnaissance attacks. –UDDI v3.0.2 supports authentication and digital signatures –WSDL has yet to provide similar support, but out-of-band digital signatures can be used

16. 15 Table Of Contents  NIST SP 800-95 Structure  Web Service Security Functions and Technologies  Web Portals  Secure Web Service-Enabling of Legacy Applications  Secure Implementation  Secure Development Scenarios

17. 16 Web Portals  Must satisfy security requirements of both Web applications and Web services  Proxy Agents –Web portals act on behalf of a user –They may perform actions with the user’s privileges –They may perform actions with their own privileges  SAML –Web portals use SAML assertions to provide information about the user  Discovery –Portals can offer a discovery interface –Portals can control what services a user can or cannot discover

18. 17 Table Of Contents  NIST SP 800-95 Structure  Web Service Security Functions and Technologies  Web Portals  Secure Web Service-Enabling of Legacy Applications  Secure Implementation  Secure Development Scenarios

19. 18 Web Service-Enabling Web Applications  Threats: –All threats facing Web services now face the legacy application –Flaws in the application may be exploited remotely  Legacy Web Applications –Web applications can securely authenticate with a Web service front-end using mutual SSL/TLS authentication –Some Web applications can be modified to support SAML in addition to SSL/TLS –SSL/TLS provides confidentiality and integrity protection as well  Authorization and Access Control –Legacy apps may rely on their own authorization and access control scheme and not an SSO server –SSL/TLS should be used to secure any remote directory access –The Web service front-end may need to translate SAML assertions into legacy authentication requests

20. 19 Web Service-Enabling Non-Web Applications  Non Web applications that are Web service-enabled are usually databases or directory services  Many of the same techniques can be used –SSL for communicating between the Web service front-end and the legacy application –Modification for SAML support if possible –Mapping for legacy authentication and authorization system if necessary

21. 20 Accountability and Integrity  Auditing is necessary to provide accountability in the SOA  There are no auditing standards for Web services and there are no guarantees the legacy application has auditing support –If the application supports auditing, it should be stored security –If the application does not support auditing, it should be modified or the Web service front- end should perform additional auditing –NIST SP 800-92 provides some guidelines for managing auditing  Security must not stop at the Web service interface –End-to-end user authentication from requester to the legacy application –End-to-end encrypted channel using IPSec or SSL tunneling between the Web service interface and legacy application if necessary –PKE’d security end-to-end and integrate it with legacy security systems

22. 21 Table Of Contents  NIST SP 800-95 Structure  Web Service Security Functions and Technologies  Web Portals  Secure Web Service-Enabling of Legacy Applications  Secure Implementation  Secure Development Scenarios

23. 22 Developer Toolkit Requirements  Web service language requirements? –Java,.NET, C, or C++ –Toolkits available for each language  Interoperability support? –WS-Interoperability Organization Basic Profile –(Upcoming) Basic Security Profile  Does it generate stubs? –Code that performs the necessary SOAP message parsing and generation –Allows developers to focus on functional requirements  How difficult is it to add WS-Security and SAML support?

24. 23 XML Parsers  XML Parsers are the first component to process input to Web services –They must be robust –Large or specially formed XML documents can lead to DoS –Specially formed XML documents may be able to retrieve information about the system through parsing errors –Specially formed XML documents may be able to use external references to custom XML schemas to bypass validation requirements

25. 24 Programming Languages: C, C++, Java,.NET  C and C++ –Less overhead, which is useful for embedded systems: J2EE and.NET frameworks take up hundreds of megabytes of hard disk space –Can directly interface with legacy applications developed in C or C++ –Support for WS-Security and SAML –Susceptibility to programming errors may require addition protections like XML Gateways or OS level restrictions  Java and.NET –Widely considered to be more secure languages –Two of the most popular languages for developing Web services –Provide robust sandboxes (JVM and.NET Code Access Security) –Provide code obfuscation techniques –Large number of third-party libraries available for Java and.NET Web services

26. 25 Security Testing  Developers are not perfect. Many defects are not found until testing is performed.  Conformance testing of security protocol implementation –Third-party testing to prove standards compliance  Functional testing of Web service security mechanisms –Ensure that Web service security mechanisms function as required  Security-focused unit testing –Performing security testing on individual components of the Web service, such as classes  Vulnerability assessments –Attempting to attack the Web service using known attack types  Web service code security reviews and testing –Check the source code for vulnerabilities or security errors –Perform testing with unexpected or random input to find susceptibility to unknown attacks

27. 26 Table Of Contents  NIST SP 800-95 Structure  Web Service Security Functions and Technologies  Web Portals  Secure Web Service-Enabling of Legacy Applications  Secure Implementation  Secure Development Scenarios

28. 27 Development Scenarios  Provide rough guides for how to use Web service standards appropriately  Six goals: –Confidentiality – Provided by WS-Security’s encryption functionality –Integrity – Provided by WS-Security’s signature functionality –Availability – Remains difficult –Privilege – Provided partially by SAML and XACML –Non-repudiation – Provided partially by WS-Security’s signature functionality –Accountability – Remains difficult

29. 28 Developing a Web service from scratch

30. 29 1Requester discovers Provider using UDDI 2 Provider registers with UDDI Requester receives SAML Assertion prior to requesting 3 Requester sends SOAP request using WS-Security 4 Provider sends SOAP response using WS-Security 6 Provider verifies requester ID and message 5 Provider verifies provider ID and message 7

31. 30 WSDL Heterogeneous Web services

32. 31 1 WSDL is used to Implement the Java service 2 WSDL is created prior to implementation Requester receives SAML Assertion prior to requesting Web services exchange SOAP messages using WS-Security 4 Provider verifies requester ID and message 5 Provider verifies provider ID and message 5 WSDL WS-I Basic Profile WS-I Basic Profile WSDL is used to Implement the.NET service 2 The.NET service is Implemented on a WS-I Basic Profile 1.0-compliant framework 3 The Java service is Implemented on a WS-I Basic Profile 1.0-compliant framework 3

33. 32 Legacy system

34. 33 1 Requester discovers provider through discovery service 2 Provider registers with discovery service Requester registers with core services 3 Web services exchange SOAP messages using WS-Security 4 Provider offloads verification to core services 5 Provider converts SOAP messages to legacy requests and responses 6 Legacy app verifies provider id Using legacy authentication 7

35. 34 XML Gateways

36. 35 Requester sends SOAP message to the XML Gateway with a specific URI and will receive a response 1 XML Gateway receives a SAML assertion 2 XML Gateway signs, encrypts, and adds SAML assertion to the SOAP message 3 SOAP message sent to the requester URI 4 XML Gateway verifies SAML assertion and SOAP message and forwards Insecure version to provider 5 Provider receives the SOAP message and sends a response 6

37. 36 Questions?