herndon, va october 12, 2006 navigating web services standards nist special publication 800-95

Herndon, VAOctober 12, 2006

Navigating Web Services StandardsNIST Special Publication 800-95

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 [email protected]

– “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



Web Portals




5


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


– 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



Web Portals




Table Of Contents

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/

Dimension Requirement Specifications

Messaging

Confidentiality and IntegrityWS-Security (XML Enc.)

SSL/TLS (HTTPS)

AuthenticationWS-Security (SAML, X.509)

SSL/TLS (X.509)

Resource

Authorization

XACML

XrML

RBAC, ABAC

PrivacyEPAL

XACML

Accountability Auditing tools, NIST SP 800-92

Negotiation

RegistriesUDDI

ebXML

Semantic DiscoverySWSA

OWL-S

Business Contracts ebXML

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/

Trust

Establishment

WS-Trust

XKMS

X.509

Proxying

SAML

WS-Trust

Federation

WS-Federation

Liberty IDFF

Shibboleth

Security Properties

Policy WS-Policy

Security Policy WS-SecurityPolicy

Availability

WS-ReliableMessaging

WS-Reliability

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



Web Portals




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



Web Portals




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



Web Portals




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



Web Portals




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

XKMS Identity Provider

UDDI Registry

ProducerWeb Service Consumer

Web Service

Developing a Web service from scratch

30

XKMS Identity Provider

UDDI Registry

1

Requester discoversProvider using UDDI2Provider registers

with UDDI

Requester receivesSAML Assertion priorto requesting

3

Requester sends SOAPrequest using WS-Security4

Provider sends SOAPresponse using WS-Security6

Provider verifies requester IDand message

5

Provider verifies provider IDand message

7 RequesterWeb ServiceProvider

Web Service

31

WSDL

PKI Identity Provider

.NETWeb Service

JavaWeb Service

Heterogeneous Web services

32

1

WSDL is used to Implement the Java service

2

WSDL is createdprior to implementation

Requester receivesSAML Assertion priorto requesting

Web services exchange SOAPmessages using WS-Security4

Provider verifies requester IDand message

5

Provider verifies provider IDand message

5

WSDL


.NETWeb Service

JavaWeb Service

WS-IBasic Profile

WS-IBasic Profile

WSDL is used to Implement the .NET service

2

The .NET service isImplemented on a WS-IBasic Profile 1.0-compliantframework

3

The Java service isImplemented on a WS-IBasic Profile 1.0-compliantframework

3

33

PKI

Legacy Application

Identity, Authentication,and Authorization Services

RequesterWeb Service

ProviderWeb Service

Discovery Service

Legacy system

34

PKI

Legacy Application

1

Requester discoversprovider throughdiscovery service

2

Provider registers with discovery service

Requester registerswith core services

3

Identity, Authentication,and Authorization Services

Web services exchange SOAPmessages using WS-Security

4

Provider offloads verificationto core services

5Provider converts SOAPmessages to legacy requestsand responses

6

Legacy app verifies provider idUsing legacy authentication

7Requester

Web Service

ProviderWeb Service

Discovery Service

35


ProviderWeb Service


XML Gateway XML Gateway

XML Gateways

36


ProviderWeb Service


XML Gateway XML Gateway

Requester sends SOAPmessage to the XMLGateway with a specific URIand will receive a response

1

XML Gateway receivesa SAML assertion

2

XML Gateway signs, encrypts, and addsSAML assertion to the SOAP message

3

SOAP message sentto the requester URI

4

XML Gateway verifiesSAML assertion andSOAP message and forwardsInsecure version to provider

5

Provider receives theSOAP message andsends a response

6

37

Questions?

herndon, va october 12, 2006 navigating web services standards nist special publication 800-95

Documents