1 / 37

Herndon, VA October 12, 2006

Navigating Web Services Standards NIST Special Publication 800-95. Herndon, VA October 12, 2006. NIST SP 800-95. Draft released August 30, 2006 http://csrc.nist.gov/publications/drafts.html#sp800-95 Public comment period ends October 30, 2006 E-mail 800-95comments@nist.gov

kieve
Download Presentation

Herndon, VA October 12, 2006

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. Navigating Web Services Standards NIST Special Publication 800-95 Herndon, VA October 12, 2006

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

  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

  4. 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. 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. 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. 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. 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

  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] SP 800-92, Guide to Computer Security Log Management, is available at http://csrc.nist.gov/publications/nistpubs/

  10. 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] SP 800-92, Guide to Computer Security Log Management, is available at http://csrc.nist.gov/publications/nistpubs/

  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Developing a Web service from scratch

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

  31. Heterogeneous Web services WSDL

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

  33. Legacy system

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

  35. XML Gateways

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

  37. Questions?

More Related