EBSOA Best Practices: WS Security

EBSOA Best Practices

Web Services Security

This document was prepared by Integrated Software Specialists, Inc. (“ISS”) and is to be considered confidential and proprietary to ISS and Iowa Department of Administrative Services.

ISS BEST PRACTICE GUIDEWEB SERVICES SECURITY

7/12/06VERSION 0.8

Copyright 2006 by Integrated Software Specialists (“ISS”), Inc. and the State of Iowa Department of Administrative Services (“DAS”). The copyright to these materials and any accompanying software is owned, without reservation, by ISS and The State of Iowa DAS. These materials may not be copied in whole or part without the express written permission of ISS and The State of Iowa DAS.

iOpen™, iOpen ABie™, iOpen ABef™, iOpen ABes™, iOpen ABin™, iInspect™, iDetect™, and SureStart™ are some of the trademarks owned by ISS. Other trademarks and trade names in this documentation are owned by other companies and are used for product and company identification and information only. All rights reserved. ISS is the owner of other registered and unregistered trademarks. The above list is not exhaustive.

Contact Us

Integrated Software Specialists, Inc.1901 N. Roselle RoadSuite 450Schaumburg, IL. 601951-888-477-0001

If you have suggestions for this publication, send an e-mail message to: [email protected]. Your message is answered by our ISS Documentation Group.

Visit our home page at http://www.issintl.com for more information about ISS products and services.

CONFIDENTIAL 2023 INTEGRATED SOFTWARE SPECIALISTS, INC. PAGE 2


7/12/06VERSION 0.8

Table of Contents

1 INTRODUCTION............................................................................................................................5

1.1 Purpose........................................................................................................................................5

1.2 Scope...........................................................................................................................................5

2 SECURITY CHALLENGES........................................................................................................6

2.1 Current it landscape....................................................................................................................6

2.2 security risks...............................................................................................................................6

3 BEST PRACTICES........................................................................................................................8

3.1 define overall security strategy...................................................................................................8

3.2 provide Training to soa team......................................................................................................8

3.2.1 Security Training...................................................................................................................8

3.2.2 Testing Training....................................................................................................................9

3.3 Choose between message layer security and transport layer security........................................9

3.3.1 Transport Layer Security.....................................................................................................10

3.3.2 Message Layer Security.......................................................................................................10

3.4 determine authentication approach...........................................................................................11

3.4.1 Direct Authentication..........................................................................................................11

3.4.2 Brokered Authentication......................................................................................................12

3.5 establish message protection strategy.......................................................................................12

3.5.1 Data Origin Authentication.................................................................................................13

3.5.2 Data Integrity......................................................................................................................13

3.5.3 Data Confidentiality............................................................................................................13

3.6 develop security coding practices.............................................................................................13

3.6.1 Message Validation.............................................................................................................14

3.6.2 Message Replay Detection...................................................................................................15

3.6.3 Exception Shielding.............................................................................................................16

3.7 utilize web services gateways for external access....................................................................17

3.8 improve testing process.............................................................................................................18

3.8.1 Static Analysis......................................................................................................................18



7/12/06VERSION 0.8

3.8.2 Dynamic Software Analysis.................................................................................................19

3.8.3 Runtime Analysis.................................................................................................................19

3.8.4 Create and maintain reusable, regression tests scripts.......................................................19

3.8.5 Putting it all together...........................................................................................................20

3.9 utilize web services security specifications..............................................................................20

3.9.1 WS-Security.........................................................................................................................20

3.9.2 WS-Policy............................................................................................................................21

3.9.3 WS-Trust..............................................................................................................................21

3.9.4 WS-Privacy..........................................................................................................................22

3.9.5 WS-SecureConversation......................................................................................................22

3.9.6 WS-Federation.....................................................................................................................22

3.10 promote increase security interoperability.............................................................................23

3.11 implement secure auditing.....................................................................................................23

3.12 deploy mature web services security infrastructure...............................................................23

3.13 governance – security policy..................................................................................................25

3.14 use xml appliances, if needed.................................................................................................26



7/12/06VERSION 0.8

1 INTRODUCTION

1.1 PURPOSE

This best practice guide provides you with high-level overview information about Web Services Security. This paper is intended for architects and software engineers that are responsible for examining the security aspects of the Web Services currently being designed and/or developed . Information is presented in these sections:

Security challenges that the state government currently faces

Typical security countermeasures used to mitigate most common security threats.

This document assumes that the reader has a basic background in security technologies such as SSL/TLS, message level technologies of SOAP, XML encryption and digital signatures, and Web Services Security.

1.2 SCOPE

Service-orientation represents the next major trend in enterprise computing. Utilizing this technology requires new perspectives, techniques, and tools for implementing technology solutions that meet the needs of business. The best practices described in this document only touch upon Web Services Security.

Other SOA-subject matters such as Data Standards, Service Modeling, Service-Oriented Integration, Web Services Network Infrastructure or Platform Infrastructure are addressed in other EBSOA best practice document.

.



7/12/06VERSION 0.8

2 Security Challenges

Service-Oriented Architecture offers a number of potential benefits: provides new opportunities to connect enterprises with customers, partners, and suppliers; improves efficiency through greater reuse of services across the enterprise; and offers greater flexibility by breaking down IT silos.

These benefits make security more critical for architects, security and operations professionals, and software engineers because services are highly distributed, multi-owner, deployed to heterogeneous platforms, and often accessible across departments and organizations.

2.1 CURRENT IT LANDSCAPE

Security is a pressing issue in SOA because the SOA stresses machine-to-machine interactions, while most IT security is based on human-to-machine interaction.

The security infrastructure in the traditional distributed computing environment resembles islands of security. Each component or network acts as an island, with its own perimeter security, and only users within the network are considered to be trusted. Due to the distributed nature of the current enterprise systems, organizations have difficulty in administering security policies and bridging diverse security models, which leads to increased opportunities for errors and leaves holes within the security system, hence the chance of accidental disclosure and the vulnerability for attack increases.

2.2 SECURITY RISKS

Applications exposed as Web Services provide increased flexibility but face a variety of security risks:

Authentication/authorization: Without the appropriate mechanisms in place, it is virtually impossible to block unauthorized use of Web Services.

Tampering: The message information is altered by inserting, removing or otherwise modifying information created by the originator of the information and mistaken by the receiver as being the originator’s intention.

Repudiation: Users (legitimate or otherwise) may deny that they made specific transactions.

Spoofing: A message is sent which appears to be from another principal.

Confidentiality: The unwarranted exposure of private data when on the wire.

Denial of service: Making applications unavailable by sending a huge number of requests or very large XML payloads.

Invalid messages: Certain XML messages can contain malicious code such as SQL statements, viruses, or worms that can compromise or corrupt data, applications, and systems,



7/12/06VERSION 0.8

and potentially leave them exposed. This code can appear in the body of the XML document or in CDATA tags. Hackers tamper with the SOAP messages themselves to disable the service through illegitimate or malformed requests.

Replay attacks: A message is sent which includes portions of another message in an effort to gain access to otherwise unauthorized information or to cause the receiver to take some action (e.g. a security token from another message is added).

XML routing detours/external referencing: XML documents can contain references to external structures.



7/12/06VERSION 0.8

3 Best Practices

Ensuring the integrity, confidentiality and security of services applying a comprehensive security model is critical, both for organizations and their stakeholders. Moreover, when deployed externally for consumption by other organizations or citizens, only secure Web Services can provide a justifiable integration solution, because the benefits they expose should far outweigh the risks. Fortunately, there are methods to protect against potential vulnerabilities. These issues require taking a holistic approach utilizing infrastructures, tools, and software engineering processes. This mindset takes security into consideration during the entire Web Service lifecycle, not just at deployment time.

3.1 DEFINE OVERALL SECURITY STRATEGY

SOA security is a massive subject matter. It is easy to become paralyzed by security. Data loss, electronic snooping, hacker attacks, unauthorized access, stolen password, denial of service, are just a few of the security issues confronted by business.

Because of the advent to access and transmit data via the internet, agencies are now forced to re-examine their security infrastructure. In some cases systems are open to customers, business partners, and suppliers. But, an incomplete and outdated security solution places their information resources at risk; to avert this, their network environment must be secure.

To avoid becoming overwhelmed by security issues, the best approach is to assign a team of security experts that:

Define security solution(s) specific to your business needs

Deliver expert security analysis of the enterprise and network

Develop adaptable security architecture

Identify potential risks and vulnerabilities within your company's policies, process, networks, and systems

3.2 PROVIDE TRAINING TO SOA TEAM

3.2.1 Security Training

As hackers turn their attention to the software that makes up an organization's IT infrastructure, IT professionals are realizing that the best way to protect their infrastructure is building secure software at the onset. While Web Services lifecycle mirrors traditional application lifecycle in many ways, most software engineers are not trained to utilize Web Services Security.

Building secure software requires careful design, development, and deployment processes and a fundamental understanding of available security mechanisms and techniques. By eliminating



7/12/06VERSION 0.8

potential security flaws early in the Software Development Lifecycle (SDLC), organizations reduce significant remediation costs and reduce the risk to their critical digital assets.

A considerable number of options are available regarding Web Service Security, however, to deliver secure Web Services, architects and software engineers must learn new technologies. They also must consider new threats associated with exposing functionality on potentially hostile networks.

Web Services Security training should assist the SOA team at all stages of the software engineering process to:

Help determine the right security solution(s) for the agency’s environment

Assist in making key design choices

Provide in-depth implementation patterns and details for security challenges

Help understand critical challenges in the deployment life cycle

3.2.2 Testing Training

A common problem that organizations encounter is their attempt to use the same human and technological resources of testing for Web Services without implementing the proper training, processes, and technology changes. The aforementioned resources cannot be used for Web Services testing for the following reasons:

Web Services testing requires a different skill set in XML, SOAP, WSDLs, and other WS standards, let alone experience in security issues unique to Web Services.

Web Services testing can effectively implemented with specialized tools rather than tools that are designed for traditional testing. The features of these tools need to support Web Services standards and have the ability to design tests along these standards.

Web Services Security testing requires the facilitation of tools and practices that can exercise the tests for exposing vulnerabilities that are general to Web applications and specific to Web Services alike.

3.3 CHOOSE BETWEEN MESSAGE LAYER SECURITY AND TRANSPORT LAYER SECURITY

An architectural decision to make is whether to implement the security on the transport layer or on the message layer. TLS (Transport Layer Security) is a mature technology so both standards and tools have already been developed. It also provides a good transition path for engineers who are somewhat familiar with transport-level security but are new to Web Services. On the other hand, TLS has inherent limitations that make it inappropriate for some situations. Fortunately, message layer security provides an alternative solution for situations where TLS' limitations are troublesome.



7/12/06VERSION 0.8

3.3.1 Transport Layer Security

The security of the transport that is being used for the Web Service can be used to protect the Web Service. The main benefit of using TLS is that it builds on top of existing Web application experience to implement the security. Many software engineers know SSL and it is easy to enable it in common Web and application servers. SSL can enforce confidentiality, integrity, authentication, and authorization, thus protecting the Web Service from capture and replay attacks, WSDL access, and scanning.

The drawback of SSL is that it is an all-or-nothing protocol. It does not have the granularity to secure certain parts of the message, nor can it use different certificates for different message parts. Moreover, if a message needs to go through multiple points to reach its destination, each intermediate point must forward the message over a new SSL connection. In this model, the original message from the client is not cryptographically protected on each intermediary because it traverses intermediate servers and additional computationally expensive cryptographic operations are performed for every new SSL connection that is established.

3.3.2 Message Layer Security

Message layer security represents an approach where all the information related to security is encapsulated in the message. Securing the message using message layer security instead of using transport layer security has several advantages that include:

Increased flexibility: parts of the message, instead of the entire message, can be signed or encrypted. This means that intermediaries can view the parts of the message that are intended for them.

Support for auditing: Intermediaries can add their own headers to the message and sign them for the purpose of audit logging.

Support for multiple protocols: it is possible to send secured messages over many different protocols such as Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and Transmission Control Protocol (TCP) without having to rely on the protocol for security.

However, it is fair to say that message-level security is not nearly as mature as TLS. Listed below are the message layer security technologies that address some of the same concerns as TLS (privacy, authentication, and message integrity) at the message level instead of the transport level:

The XML Signature provides a mechanism for digitally signing XML documents or portions of XML documents. Due to the fact that the signature does not have to be in the document that is being signed, it is possible to use XML Signature to sign non-XML documents.

XML Encryption provides a mechanism for encrypting portions of the XML documents.

WS-Security is a specification that defines a standard way of securing a single message by applying authentication tokens, XML Signature, and XML Encryption to a SOAP envelope.



7/12/06VERSION 0.8

3.4 DETERMINE AUTHENTICATION APPROACH

Authentication determines the identity or role of a party attempting to perform some action such as accessing a resource or participating in a transaction. The recipient of the message must be able to confirm message sender identity. Authentication is considered to be a primary security feature because mechanisms used for authentication often influence mechanisms used for enabling other security features, such as data confidentiality and data origin authentication.

As computer systems have increased in complexity, the challenge of authenticating users has also increased. As a result, two models of authentication for Web Services interactions are utilized: a) Direct Authentication; and, b) Brokered Authentication.

3.4.1 Direct Authentication

When both the client and service participate in a trust relationship that allows them to exchange and validate credentials including passwords, direct authentication can be performed. The Web Service acts as an authentication service to validate credentials from the client. These credentials, which include proof-of-possession that is based on shared secrets (e.g. passwords), are verified against an identity store. The benefits of using Direct Authentication include the following:

It represents an uncomplicated model for authenticating clients without the need for an authentication broker.

If the shared secret between a requester and service is compromised, only the relationship between those two parties is compromised and not the entire model.

The disadvantages associated with Direct Authentication include the following:

Direct Authentication does not provide single sign on capabilities. Without single sign on, the client may be forced to authenticate prior to every Web Service call or to cache the user's credentials within the application. If the user's credentials include a password, caching the password is not recommended because it may pose a security risk.

The decentralized nature of Direct Authentication requires that the trust relationship be managed between each point in the communication.

As the number of discreet relationships between clients and services increases, each with potentially different identity stores, the challenges of managing and distributing secrets becomes more complicated.

If a client calls a Web Service frequently, the use of Direct Authentication can increase latency, because the Web Service typically authenticates against a remote identity store.

Data ownership and synchronization issues can occur if each of several services has its own identity store to authenticate the same client. This is because the client's credentials may need to be duplicated across multiple identity stores.



7/12/06VERSION 0.8

3.4.2 Brokered Authentication

In a Brokered Authentication, a Web Service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the Web Service.

The benefits of using Brokered Authentication include the following:

The authentication broker manages trust centrally. This eliminates the need for each client and service to independently manage their own trust relationships.

Solutions built around Brokered Authentication with a centralized identity provider are often easier to maintain than Direct Authentication solutions. When new users who require access to any of the clients or Web Services are added to the identity store, their credentials are maintained in one central point.

Two parties participating in Brokered Authentication do not require prior knowledge of one another to communicate. If a client is modified to call a Web Service it has never used before, the Web Service requires no changes to its configuration or data to authenticate credentials presented by the client.

Trust relationships can be established between different authentication brokers. This means that an authentication broker can issue security tokens that are used across organizational boundaries and autonomous security domains.

The liabilities associated with the Brokered Authentication pattern include the following:

The centralized trust model that is used by Brokered Authentication can sometimes create a single point of failure. Some types of authentication brokers, such as the Kerberos Key Distribution Center (KDC), must be online and available to issue a security token to a client. If the authentication broker somehow becomes unavailable, none of the parties that rely on the authentication broker to issue security tokens can communicate with each other. This problem of a single point of failure can be mitigated by implementing redundant or back-up authentication brokers, although this increases the complexity of the solution.

Any compromise of an authentication broker results in the integrity of the trust that is provided by the broker also being compromised. If an attacker does successfully compromise the authentication broker, it can use the authentication broker to issue security tokens, and conduct malicious activity against parties that trust the authentication broker.

3.4.3 Recommended Authentication Approach

Direct authentication is the best way to go, if you do not plan to have a big SOA implementation. If you are only going to deploy only a few Web Services or SOA components, then the direct authentication approach might suffice because it’s easier to implement and the amount of SOA services that need to be maintained and controlled do not justify the need of having a centralized component to enforce security across all the state agencies.



7/12/06VERSION 0.8

A Brokered Authentication is better for organizations that plan to have an SOA environment and plan to adopt SOA widely across the enterprise. Brokered Authentication is usually the need for the enterprise, because of its centralized nature, all services are enforced to authenticate to a centralized security component. This centralized component enables easier maintainability and manageability of your security infrastructure across your SOA services, it holds the keys to all services, and it is in charge of enforcing security across the enterprise. For a federated environment like the state of Iowa, and because of its interest in adopting SOA, it is recommended to have Brokered Authentication in mind.

3.5 ESTABLISH MESSAGE PROTECTION STRATEGY

Web Services send and receive plaintext messages over standard Internet protocols such as HTTP. Such plaintext messages can be intercepted by an attacker and potentially viewed or even modified for malicious purposes. By using message protection, you can protect sensitive data against threats such as eavesdropping and data tampering.

Message protection can be divided into three main categories:

Data integrity is the verification that a message has not changed in transit

Data origin authentication takes data integrity a step further and supports the ability to identify and validate the origin of a message

Data confidentiality is the encrypting of message data so that unauthorized entities cannot view the contents of the message

3.5.1 Data Origin Authentication

Data passes between a client and a Web Service, sometimes through one or more intermediaries. The data contained in the request message from the client influences the Web Service's behavior. There is a risk that an attacker could manipulate messages in transit between the client and the Web Service to maliciously alter the behavior of the Web Service. Message manipulation can take the form of data modification within the message, or even substitution of credentials, to change the apparent source of the request message.

3.5.2 Data Integrity

Ensure that information is not changed, either due to malicious intent or by accident. The recipient of a message must be able to guarantee that a message has not been tampered with in transit. In an SOA environment, there may be multiple endpoints and intermediaries before the intended recipient gets the message. Digitally signing the message ensures the data integrity of the message as any data modifications during the message transit are detected in signature verification at the receiving end.

3.5.3 Data Confidentiality

Data passes between a client and a Web Service, sometimes through one or more intermediaries. Messages may also be kept in repositories, such as message queues or databases. Some of the data



7/12/06VERSION 0.8

within the messages is considered to be sensitive in nature. There is a risk that an attacker can gain access to sensitive data, either by eavesdropping on the network or accessing a repository

3.6 DEVELOP SECURITY CODING PRACTICES

Securing applications from the outside is not enough to protect your application. Web Services security solutions cannot confidently check the content of XML messages since they do not have the application context. Hackers use this knowledge to embed malicious content in the XML documents that pass straight through the security software to the service interface of the application.

The method to secure applications from inside and protect against security attacks is to perform input cleansing within the application code. Software engineers will need to provide additional protection at the service's boundary to:

Protect Web Services against malformed or malicious content

Ensure that when a Web Service operation fails, one does not accidentally reveal confidential information in the SOAP Fault that is returned

Prevent an attacker from intercepting a message and replaying it to force a Web Service operation to execute multiple times

3.6.1 Message Validation

A Web Service interfaces with other applications over a network. Incoming data may be malformed and may have been transmitted for malicious purposes. There is also a risk of injection attacks, where data from incoming messages is tampered with to include additional syntax.

With message validation, software engineers assume that all input data is malicious until proven otherwise, and use message validation to protect against input attacks, such as SQL injection, buffer overflows, and other types of attacks. The message validation logic enforces a well-defined policy that specifies which parts of a request message are required for the Web Service to successfully process it. It validates the XML message payloads against an XML schema (XSD) to ensure that they are well-formed and consistent with what the Web Service expects to process. The validation logic also measures the messages against certain criteria by examining the message size, the message content, and the character sets that are used. Any message that does not meet the criteria is rejected.

Security considerations associated with the Message Validation technique include the following:

Message validation can help protect against denial of service attacks, but the message validation logic must be very efficient when it conducts its validation checks. Otherwise, the message validation logic may be a system bottleneck and may itself become the target of a denial of service attack. Malformed content can include very large messages, in some cases for the purposes of launching a denial of service attack. Software engineers should make the maximum message size large enough to allow legitimate messages to be accepted but small enough to prevent attacks.



7/12/06VERSION 0.8

Using a validating parser and verifying the input message against its XML Schema (XSD) result in a significant increase in CPU processing. And, even though XML Schema (XSD) has the capability to specify data range validations and it supports the use of regular expressions, many schemas use data types, such as string, which do not prevent many forms of injection attacks.

Instead of building the message validation logic into the Web Service itself, engineers can place it in an intermediary. This allows several Web Services to use the same intermediary, and it enables each Web Service to dedicate its resources to processing legitimate messages. It also ensures that invalid messages never reach the Web Service. However, using an intermediary in this way can create a single point of failure, which may become a target of attack.

XML message payloads that contain a CDATA field can be used to inject illegal characters that are ignored by the XML parser. If CDATA fields are necessary, engineers must inspect them for malicious content.

The Web Service may obtain data for response messages from external sources. There is no guarantee that external data sources properly validate data. Passing responses without message validation makes the Web Service a potential "carrier" of malicious input from external data sources. Engineers should consider filtering Web Service response messages that are returned to the client.

3.6.2 Message Replay Detection

A client calls a Web Service by sending messages across a public network. When the Web Service processes the messages, data is updated or business processes are initiated. If a message that is intended for one of these Web Services is intercepted and replayed, there is a risk that the same operation might be performed multiple times.

Software engineers should cache an identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache.

Message replay detection requires that individual messages can be uniquely identified. This ensures that a legitimate message is not rejected because of a match in the replay detection cache. Message replay detection also requires that messages have not been tampered with in transit. This ensures that the replay detection cache does not accept messages that have been captured and modified by an attacker.

Messages signed using a WS-Security XML signature must include a SignatureValue element, which can be cached as an identifier for the message. The SignatureValue is computed from hash values of the message parts that are being signed, including the message body and the timestamp.

However, a SignatureValue is not truly unique because it runs the theoretical risk of collision (where the same value can be unintentionally reproduced). In most cases, the risk is very low, so SignatureValue is an appropriate choice for a message identifier.

The SignatureValue element is added to the cache, along with a timestamp from the server, indicating the time it processed the message. This allows entries to be cleared from the cache at



7/12/06VERSION 0.8

regular intervals and to not accumulate indefinitely. The service can be designed to automatically reject incoming messages that arrive on or after a defined acceptable time delay.

Security considerations associated with the Message Replay Detection technique include the following:

The unique identifier for the message must be saved in the replay cache prior to processing the request. This prevents concurrency issues if a second message arrives before the first message has finished executing.

Some of the steps performed while attempting to detect replayed messages can adversely affect system response time. Verifying the signature on the identifier and timestamp is computationally intensive. Reading or updating the replay cache can also impact response time if the cache is on a different computer than the recipient.

Preventing message replay can help stop a denial of service attack from accessing resources, but it is also possible for an attacker to launch a denial of service attack on the computer that is using message replay detection. The attacker does this by replaying a large number of messages to exploit high resource consumption. To minimize the impact of the attack on system availability and response time, it is important to ensure that the service implements replay detection as efficiently as possible.

A Time To Live (TTL) in seconds is set on the server to determine the acceptable clock skew between the client and the service. If a message is received outside the acceptable time range, the message will be rejected, even if it is not already present in the cache. Therefore, it is important to ensure that clocks are closely synchronized between the sender and the recipient. This is best achieved by using time synchronization services, with the sender and recipient synchronizing their local clocks to a centralized source. The clock skew must always be less than the time that the messages are held in the cache; if it is not, a replayed message may be accepted because it will already have been deleted from the cache.

The length of time that messages should be held in the cache varies, depending on the specifics of the recipient. If an application receives a very large number of messages per second, the cache lifetime may be very small, perhaps only a few minutes. In other cases, the cache lifetime may be significantly longer, perhaps hours or days.

3.6.3 Exception Shielding

A client is accessing a Web Service. The Web Service is designed according to the principals of service orientation, which ensures that the boundaries of the service are explicit, and requires that exception information related to the internal implementation of the service is managed within the service.

Use the Exception Shielding technique to return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web Service's inner workings.



7/12/06VERSION 0.8

In addition to processing exceptions, the exception shielding logic can also log the full details of the exception to an event log. This allows maintenance staff to identify and troubleshoot the exceptions. The information also assists with intrusion detection and incident response.

The exception shielding logic can also generate an exception identifier for each exception and pass it back to the client in a message, so that it can be presented to the user in the form of an error message. This allows the exception that is returned to the client to be directly traced to detailed exception information located in the event log, which can assist in dealing with helpdesk calls.

Security considerations associated with the Exception Shielding technique include the following:

Unhandled exceptions may be wrapped by another exception. Engineers should ensure that the outer exception and all wrapped exceptions are checked by the exception shield logic before they are returned to a Web Service client.

Engineers should use exception handling throughout the entire application's code base. This prevents internal implementation details of the service from being revealed to the client.

3.7 UTILIZE WEB SERVICES GATEWAYS FOR EXTERNAL ACCESS

Web Services need to communicate with other resources, such as database servers, and in some cases, other servers that contain data for the Web Service to process. As organizations consider externally exposing Web Services, there is often a reluctance to deploy the server hosting the Web Service in the perimeter network (a.k.a. DMZ) that external applications can access. However, Web Service standards are designed for this scenario through the use of message layer security and intermediaries that can inspect message content and perform message validation and routing capabilities. Intermediaries can be used to supplement existing firewall devices, which are often used to protect an organization's perimeter network.

A Web Services Gateway acts as an intermediary that can be deployed in your perimeter network and route messages to a Web Service endpoint that resides on an internal network that is invisible to the client.

The benefits of using the Web Services Gateway include the following:

Security can be maintained at the gateway, which provides an extra layer of security to protect the Web Services.

Servers that host internal Web Services can be taken offline for maintenance without affecting the external interface. This can be accomplished by configuring the gateway to start routing messages to a backup server while the maintenance is being performed.

The gateway represents a single point of entry for external clients. This allows it to be extended to support additional operations that external clients require. These requirements could include protocol transition (from X.509 mechanism to Kerberos protocol), message validation, exception shielding, replay detection, message transformation and auditing.



7/12/06VERSION 0.8

In some cases, there is a need to provide some or all of these additional requirements for internal clients as well. In these cases, it is necessary to place the logic that provides these functions on the internal network, or ensure that the internal clients also pass through the perimeter service router.

Disadvantages associated with the Web Services Gateway include the following:

Many platforms make exposing the application functionality simple. However, this can lead to a poor decision in terms of granularity. If the service interface is overly fine-grained, a consumer can end up making too many calls to perform a specific action. Engineers need to design service interfaces to be appropriate for network or out-of-process communication.

Each additional service interface that a service provides increases the amount of work required to make changes to the functionality that is exposed by a service.

The gateway adds complexity and performance overhead that may not be justified for very simple Service-Oriented applications.

The gateway may become a bottleneck when routing large numbers of messages. To avoid this problem, the gateway should be designed with good performance as a high priority.

Security considerations associated with the Web Services gateway include the following:

The gateway is often the only point of entry to the internal network for external clients. This can make it a prime target for attackers. To guard against an attack, organizations must harden the platform on which the gateway is deployed.

Although the gateway can provide an extra layer of security between external clients and internal Web Services on a private network, organizations should still design secure Web Services on the internal network as well as should ensure that communications between the gateway and internal Web Services are secured.

3.8 IMPROVE TESTING PROCESS

Security has the inherent nature of spanning many different layers of a Web Services system. Web Services vulnerabilities can be present in the operating system, the network, the database, the Web server, the application server, the XML parser, the Web Services implementation stack, the application code, the XML firewall, the Web Service monitoring or management appliance, or just about any other component in your Web Services system.

Therefore security testing, which is important for any software application, is even more crucial for Web Services. It is necessary to have a mature engineering process that makes security vulnerability detection and testing an indivisible part of the Web Services development lifecycle so the threats are mitigated to the maximum extent. Thinking about security as early as possible throughout the Web Service lifecycle is the key to achieving the best results in the most efficient manner.

To detect and prevent security vulnerabilities in Web Services, several engineering activities must be done on multiple fronts:



7/12/06VERSION 0.8

3.8.1 Static Analysis

Static analysis tools are evolving to provide an automated way to check large amounts of code and data flows to find common software security vulnerabilities related to malicious input during the software development phase. They can help organizations easily catch and fix common mistakes. Using proper threat analysis and abuse-case modeling during the software requirements and design phases to identify security flaws architecturally can also mitigate potential security risks during deployment as well as in the future.

Static analysis tools are proving to be very effective in exposing concerning method calls, insufficient validations, or poor code quality. Although manual code inspections can expose some of these problems, such problems can be subtle and difficult to find manually. Static analysis does not eliminate the need for code inspections completely, but it can significantly reduce the time and effort required to do them since static analysis tools can scan the entire source code to identify unsafe coding patterns then the code reviewer can analyze these instances to verify their severity. Without such automation, much more time would be spent in finding the unsafe coding patterns in the first place.

3.8.2 Dynamic Software Analysis

A suggested approach to deploy in combination with those mentioned above is dynamic software analysis, which analyzes software at runtime. The dynamic analyzer simulates attacks against the application and tries to exploit it. When successful, it provides the results and identifies which areas of the application are vulnerable to the simulated attacks.

Dynamic analysis tools target a different class of exploits that static analysis tools cannot catch since they are runtime attacks. Attack examples include probing, forceful browsing, and time-based attacks such as click fraud. In the latter case, the number of times a page is hit in a given amount of time is of interest. This metric cannot be extracted during static analysis. In fact, organizations must add checks in source code to detect them or use a solution that discovers such behavior at runtime.

Ideally organizations should use both dynamic and static analysis tools. Aside from increased security, these techniques pinpoint the root cause of the vulnerabilities caught during dynamic analysis and correlate them back to the exact sector in the code that is vulnerable.

Replay attacks can be simulated by sending multiple requests with the same message identifier that determines its uniqueness. To test a Web Service's vulnerability to Denial of Service (DoS) attacks caused by heavy loads, organizations cannot tell if a service can sustain a certain load scenario unless such a scenario has been tested. However, it is important to execute such load tests in a manner that is effective.

3.8.3 Runtime Analysis

Dynamic analysis can find security vulnerabilities that can result from the integration of otherwise secure components because it takes data flow analysis into consideration, whereas static analysis provides large code coverage with a narrower scope on data flows.



7/12/06VERSION 0.8

Runtime analysis of the state of Web application code is needed to detect certain security problems that cannot be detected with the previous two testing approaches. For instance, in C/C++ applications that are exposed as Web Services, memory corruption (especially memory corruption on the stack) indicates a potential for buffer overflows that could cause serious security problems, and memory leaks make the application more vulnerable to denial of service attacks.

3.8.4 Create and maintain reusable, regression tests scripts

The above testing practices are potentially too expensive to perform unless proper automation is applied to the testing process. Organizations do not have the resources to do these tests if they were to be done manually and repeated for each project milestone.

Modern software development processes are iterative. Software engineering activities should be done on a recurring, iterative basis rather than following a rigid, one-directional development model that test only at the end. Testing only at the end of the development cycle is one of the main reasons for late deliveries and exceeded project costs and Web Services are no exception to this fact.

However, such an iterative development model can only be effective if the engineering activities are backed with proper automation. Therefore, it is necessary to establish a Web Services testing environment that is driven by automation that can help create the tests, maintain them, manage them, and execute them on a regular basis; typically every night as part of the existing "nightly" build and test process for the product. The alternative would be to run the various Web Services tests manually, each one at a time, by modifying a client's request, which is a tedious, non-efficient process. Therefore, it is better to keep and maintain all the Web Service tests that are created so they can be re-run quickly, easily, and so the team can run them all automatically as regression tests whenever a Web Service is updated.

After running security tests along with the abovementioned testing types, teams can find problems that require fixes that ripple through Web Service at a time when they are too risky or expensive to fix, which is why such tests are better executed early and regularly.

When a problem is discovered then the test that exposed the problem should ideally be added to the existing test pool and re-run on a recurring basis with all the other tests so it prevents that error from occurring again.

3.8.5 Putting it all together

Since each security testing type provides a methodology exposing vulnerabilities from a unique aspect, combining most or all types could provide a powerful approach to security testing.

3.9 UTILIZE WEB SERVICES SECURITY SPECIFICATIONS

As in other security fields, adherence to standards is a necessary practice for Web Services. There is a consensus among security professionals that publicly available, commonly used, well-analyzed cryptographic algorithms are the best choice, simply because they have already undergone a great deal of research and scrutiny since they were adopted by the industry. The same principle applies to



7/12/06VERSION 0.8

Web Services security. The most important Web Services Security standards are: WS-Security, WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation and WS-Authorization.

3.9.1 WS-Security

WS-Security is the basic building block for securing Web Services. HTTP-S and BASIC-Auth authentication are often used to secure Web Service communications. While this simple transport-level security is sufficient for simple, point-to-point Web Services, their use is vulnerable to security breaches in multi-hop networked interactions. Further, there are underlying performance issues inherent in HTTP-S. HTTP-S supports only a one user credential per connection, so a highly-scaled server-to-server communication might require hundreds or thousands of connections, a huge scalability challenge.

By contrast, WS-Security works by specifying security policy at the SOAP message level, thereby protecting message integrity and confidentiality wherever the message may travel, as well as providing a mechanism to accommodate single message authentication.

WS-Security provides a general-purpose and extensible mechanism that can support multiple encryption technologies, trust domains, and security tokens used for authentication or authorization. Because WS-Security per-message encryption and signing support messages from many users on a single connection, WS-Security solves the scalability issue inherent in transport-level security mechanisms such as HTTP-S. In addition, WS-Security specifies how to encode X.509 certificates and Kerberos tickets, making it simple to integrate with widely-used security infrastructures.

Compliance with the WS-Security specification will likely be safer than developing agency’s own custom security implementation because it has been developed by experts in the field with threat protection in mind. Furthermore, agencies can reduce development time by using a readily available implementation of the specification and services would be able to interoperate with other implementations of the same standard.

3.9.2 WS-Policy

Whereas WSDL defines the functionality of a service, WS-Policy defines the conditions, such as security, reliability and transactional atomicity, under which that functionality may be used or be made available. For example, WS-Policy allows a service consumer to avoid selecting service providers that do not adhere to a specific privacy policy. WS-Policy and WSDL combine to define the contract of communications between a service consumer and provider. As long as the consumer obeys this contract, its requests will not be rejected by the infrastructure.

Without WS-Policy, software engineers must define application-specific schemes to outline the conditions under which a service is provided, and these requirements must be manually configured. By contrast, by providing a standard means to express all aspects of the communication contract, WS-Policy supports automation with tools and infrastructure. Because these communications contracts can and do change over time (in response to new regulatory requirements, for example), these benefits are not one-time events, so use of WS-Policy reduces on-going workload as well. In



7/12/06VERSION 0.8

sum, WS-Policy enhances the flexibility of SOA implemented using Web Services, and it does so in an open and interoperable way.

3.9.3 WS-Trust

In order to secure communication between two parties, they must exchange security credential, either directly or indirectly. However, each party needs to determine if they can trust the asserted credentials of the other party. The WS-Trust specification describes the model for establishing both direct and brokered trust relationships (including third parties and intermediaries). It provides a framework to support methods for issuing and exchanging security tokens, and, to support ways to establish and access the presence of trust relationships.

Typically, WS-Trust allows a client to send a request (using a X.509 certificate or other security token supported by WS-Security) to a Security Token Service (STS) via a gateway. The STS maps the security token expected by the receiving party (e.g.: a SAML assertion), and returns the trusted security token (e.g.: a signed SAML assertion) to the client. The client can now use the security token expected by the receiving party.

3.9.4 WS-Privacy

WS-Privacy allows organizations to state their privacy policies and require that incoming requests make claims about the initiator’s adherence to these policies. The specification describes a model for how a privacy language may be embedded into WS-Policy descriptions and how WS-Security may be used to associate privacy claims with a message. WS-Privacy also describes how WS-Trust can be used to evaluate privacy claims for organizational practice as well as user preference.

As governments pass laws to protect sharing of personal information, this specification will grow in importance.

3.9.5 WS-SecureConversation

The WS-SecureConversation specification is built on top of the WS-Security and WS-Policy models to provide secure communication between services. WS-Security focuses on the message authentication model but not a security context, and thus is subject several forms of security attacks. This specification defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable a secure conversation.

WS-SecureConversation is the SOAP layer equivalent of SSL at the transport layer. By using the SOAP extensibility model, modular SOAP-based specifications are designed to be composed with each other to provide a rich messaging environment. As such, WS-SecureConversation by itself does not provide a complete security solution. WS-SecureConversation is a building block that is used in conjunction with other Web Service and application-specific protocols (for example, WS-Security) to accommodate a wide variety of security models and technologies.



7/12/06VERSION 0.8

3.9.6 WS-Federation

The WS-Federation specification is another component of the Web Services Security model that defines mechanisms to allow different security realms to federate by allowing and brokering trust of identities, attributes, authentication between participating Web Services.

WS-Federation addresses the issue where the requestor in one trust domain interacts with a service in another trust domain using different security models. For instance, how does a consumer service using Kerberos invoke a producer service based on X.509 in a trusted fashion?. WS-Federation is working towards providing a standard, generic approach to handle identity federation. Liberty Alliance and Microsoft are attempting to solve the same issue.

3.10 PROMOTE INCREASE SECURITY INTEROPERABILITY

According to industry analysts, the successful deployment of standards-based security technologies will be a key determinant in the widespread adoption of Web Services. Therefore, it is important to comply with the Basic Security Profile (BSP) from Web Services Interoperability Organization (WS-I).

The BSP consists of a set of non-proprietary Web Services specifications, along with clarifications and amendments to those specifications which promote interoperability. It addresses Transport Layer Security, SOAP Message Security, Username Token Profile, X.509 Certificate Token Profile, Kerberos Token Profile, Security Assertion Markup Language (SAML) Token Profile, Rights Expression Language (REL) Token Profile, XML-Signature, XML Encryption, Algorithms, Relationship of Basic Security Extension Profile to Basic Profile, and Attachment Security.

The BSP is intended to address interoperability, but in some cases it restricts the W3C and OASIS specifications in a manner that favors stronger security practices. The BSP provides a number of security scenarios, which makes it an important resource for Web Services engineers and security architects concerned with security and interoperability.

Although it is impossible to completely guarantee the security interoperability of a particular service, the BSP attempts to increase interoperability by addressing the most common problems that implementation experience has revealed to date.

3.11 IMPLEMENT SECURE AUDITING

Network administrators and system operators rely on application or syslogs for creating audit trails, however, neither approach is reliable or secure. Web Services provide several new features for enabling secure auditing.

By using a combination of XML Digital Signatures and time stamping, a manager can quickly and easily create secure e-business transaction logs that can be used for non-repudiation. These audit



7/12/06VERSION 0.8

trails are key to identify hackers or holding partners accountable for business transactions. In many instances legal requirements demand that the logging technology used is secure and verifiable.

3.12 DEPLOY MATURE WEB SERVICES SECURITY INFRASTRUCTURE

Leverage existing security assets. The agency probably has a robust security system(s) but the challenge with SOA is to discover how to extend those existing security measures to those Web Services that comprise your SOA. Many SOA solutions are designed to interconnect effectively with existing security functionality.

A good Web Services security infrastructure depends on the required security measures, services scope and scale of deployment. For instance, security can either be enforced in the application server itself, or as a separate security appliance (such as XML Firewalls) that can virtualize the service by sitting in the middle between the service and its consumers.

Most Web Service architects recommend decoupling the security layer from the application server to achieve better maintainability, flexibility, and scalability. However, using a security appliance as an intermediary may not be necessary for simple end-to-end Web Service deployments.

Most Web Services are based on the same technology as the Web, namely HTTP. As a result, all common technologies used to secure the Web, such as Web authentication and SSL, work equally well with Web Services - for point-to-point security. With SSL alone, you can do:

Authentication: The communication is established between two trusted parties.

Confidentiality: The data exchanged is encrypted.

Message integrity: The data is checked for possible corruption.

However, solutions such as SSL are heavy-handed since they secure the entire channel. Furthermore, for many message-based interactions, intermediary steps are required before the messages arrive at their target endpoint. This leaves XML messages unsecured at each intermediary checkpoint - exposed to tampering, information disclosure, and message altering.

To get a finer level of control and avoid intermediary security issues, it is best to secure the message rather than the complete transport. The idea is to replace SSL capabilities with message-level security, where the security information is carried in the message itself. This way, unless the intermediary or endpoints have the correct security infrastructure in place and are trusted, the message will remain secure and unreadable and can be forwarded to the next endpoint.

So how do you secure the message rather than the transport? WS-Security defines a mechanism for adding three levels of security to SOAP messages:

Authentication tokens: WS-Security authentication tokens let the client provide a user name and password or X509 certificate for the purpose of authentication headers.

XML encryption: WS-Security's use of W3C's XML encryption standard enables the XML body or portion of it to be encrypted to ensure message confidentiality.



7/12/06VERSION 0.8

XML digital signatures: WS-Security's use of W3C's XML digital signatures lets the message be digitally signed to ensure message integrity. The signature is based on the content of the message itself (by applying the hash function and public key), so if the message is altered en route, the signature becomes invalid.

A final thought on this—remember, you can use transport and message-level security together, e.g., use a WS-Security Username token without encryption and use SSL to encrypt the transaction.

There are two ways to implement this: you can embed the logic for processing tokens, handling encryption, and applying hash functions and digital signatures in the service implementation itself, or you can use a Web Services Management (WSM) solution.

WSM solutions intercept incoming and outgoing service communications and apply a set of policies in a pipeline fashion, including authentication, authorization, decryption, signature validation, and XML schema validation. They move the active enforcement of the policies and agreements to the boundaries of an application, letting the application engineer concentrate on the business logic. These solutions typically provide a policy management tool for building new security and operations policies, storing policies, and managing distribution and updates to runtime policy enforcement points. In this particular solution, policies are defined and changed centrally but enforced locally. If you have to authenticate to an Identity Management System that is not supported by the out-of-the box WSM solution, such as a JAAS login module, Oracle Web Services Manager, as well as many WSM products, you must provide an SDK for developing policy steps. You must be able to provide operational dashboards for monitoring policies as they execute to ensure service levels, incorporating alerts so corrective actions can be taken in a timely fashion.

WSM solutions typically provide two types of enforcement components and policy enforcement points: Gateway and Agents. Gateways are deployed in front of a group of applications or services. They can intercept inbound requests to these applications to enforce policy steps, adding application security and other operation rules to applications that are already deployed. They also allow (or deny) inside users access to predetermined outside services. Agents provide an additional fine-grained level of security by plugging directly into an application or service.

Service virtualization is also a key capability. Typically an Internet user makes a service request using a username and password combination, but the service may be expecting a SAML assertion. With a WSM solution, you can have a gateway on the requester side that intercepts the request, authenticates the user with the username/ password combination, and inserts a SAML assertion that can be validated at the service by a WSM agent. In effect, the user calls a service in a virtual way through the credentials that he knows, not the credentials that the Web Service is expecting.

XML firewalls or security appliances are typically good at applying macro policies and protecting against attacks such as buffer overflow attacks, which don't require application context.

3.13 GOVERNANCE – SECURITY POLICY

Web Services development doesn’t impose a technical implementation problem. Project teams start designing the architecture, infrastructure, modeling, go through construction, deployment, etc. At



7/12/06VERSION 0.8

some point during this process they start thinking about security implications, the issue here is that Web Service developers are not security experts, although they end up being responsible for this activity. Usually the security group in the agency or agencies considers this a threat.

Responsibility is required for watching the deployed Web Services. As agencies start embracing Web Services, opening back-office processes to other agencies, programs or states, and the Internet, someone needs to be in charge of security.

Usually nobody is accountable for security best practices or to enforce such practices. Too often engineers, development teams and agencies have a different definition of what “accountable for security” really means. While Web Services development mirrors application development in many ways, most developers are not trained in Web Services security. Likewise, overseeing secure code development isn't part of a security-manager's duties.

The agency should create an ethical hacking group. Another option is to create an ethical hacking group that oversees all agencies. It is recommended that the ethical hackers are certified.

A Certified Ethical Hacker (CEH) is a skilled professional who understands and knows how to look for the weaknesses and vulnerabilities in target systems and uses the same knowledge and tools as a malicious hacker. The CEH Program uses a vendor-neutral approach to ensure training on tools across the board.

The CEH is trained to learn to scan, test, and secure your own systems, they should also have in-depth knowledge and practical experience with the current essential security systems.

The CEH understands how perimeter defenses work. CEH scans and attacks your own network. They understand how intruders escalate privileges, and what steps can be taken to secure a system. They also know about intrusion detection, policy creation, social engineering, open source intelligence, incident handling, and log interpretation.

3.14 USE XML APPLIANCES, IF NEEDED

Why use an XML Gateway if your network infrastructure already has firewalls in place? It is true that firewalls can provide user-based authentication and authorization to services, although they are rarely configured to do so. Firewalls are generally control access to services and their packet processing mechanisms are not part of the data that is going through the pipe.

On the other hand, XML firewalls can be data-aware and are able to keep unwanted content and users from accessing sensitive services. They can also stop network attacks.

When looking to deploy a XML Gateway in your network, you should look for these four basic features:

1. Message integrity: Ability to encrypt portions of a message (sensitive data), verify digital signatures from incoming requests and SSL capabilities

2. DoS defense: Ability to act as a shield and protect back-end services from network attacks, specially DoS attacks



7/12/06VERSION 0.8

3. Content-based defense: Defense against the most common content-based attack is SQL injection (attacker’s ability to inject SQL statements that can execute malicious commands in the database without the application or service’s knowledge)

4. Authentication & Authorization: Support for Security Assertion Markup Language (SAML) and Web Services-specific protocols like WS-Security. Integration with A&A related components like LDAP, RADIUS, Single Sign-On (SSO), etc


EBSOA Best Practices: WS Security

Documents

Transcript of EBSOA Best Practices: WS Security