Security Considerations in the
Web Services System
Development Life Cycle
OWASP
AppSec
June 2004 NYC
George Capehart
Capehart Associates LLC
gwc@capehassoc.us
704-678-1660
Copyright © 2004 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License.
The OWASP Foundation
http://www.owasp.org
Toto, We’re not in Kansas any more . . .
 What does this mean and what is its impact on the SDLC of Web
Services-based systems?
 Web Services is a paradigm shift. The Web Services milieu is/will be a much
different animal from even today’s Web applications. This has/will impact all
aspects of the SDLC . . . Especially the security aspects.
 The goal of this presentation is to begin focusing some attention on
these issues which have not yet been addressed. To get there, we
will:
 Look at how Web Services have been defined.
 Look at how Web Services-based systems are different from traditional systems.
 Identify some of the meta-issues that impact security in the Web Services
paradigm.
 Step through the phases of the System Development Life Cycle and talk about
the security-related issues in each phase.
OWASP AppSec 2004
2
What is a Web Service?
The Web Services paradigm is still very young and our
ideas are still evolving. Having said that, some of the
basic characteristics of Web Services seem to be:
 Use HTTP/HTTPS as the transport protocol . . . Though the WSA also supports other
protocols and IPC mechanisms like FTP, SMTP, JMS, IIOP, etc.
 “XML-based RPC”
 Will eventually be implemented using a Service-Oriented Architecture (SOA)
 Asynchronous communication mechanism
 Stateless protocol(s)
 The use of a messaging protocol that supports extension
 “Web Services us a loosely coupled integration model to allow flexible integration of
heterogeneous systems in a variety of domains including business-to-consumer,
business-to-business and enterprise application application”
(ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf)
 Not “done” yet
OWASP AppSec 2004
3
Web Services: A Paradigm Shift
 At one level, Web Services are yet another distributed computing
environment, similar to the DCE/DCOM, CORBA and DTP. Uses WSDL as
the IDL and marshals to XML rather than binary data.
 Multi-tier architectures that expose services in the middle tier(s) have been
around in one shape or another for fifteen years or so.
 Asynchronous, business-to-business message-based communication has
been around for a long time (EDI).
 However, there are some ways in which systems built using Web Services
are significantly different from traditional systems.
 Web Services systems are systems that are collections of loosely coupled component
endpoint systems - i.e. the endpoint systems have no direct knowledge of each other, nor
do they have any relationship with each other.
 The endpoint systems were not originally designed as pieces of an integrated system.
 Then endpoint systems were not originally designed to participate in the provision of a
service to “strangers.”
 Web Services transactions can span significant distance and can take a considerable amount
of time, involving loosely coupled systems communicating using an asynchronous protocol.
 Web Services “externalize everything.”
 Web Services systems cross trust boundaries.
OWASP AppSec 2004
4
System-level Aspects of Web Services Systems That
Have Security Implications
 Emergent risks
 Crossing trust boundaries
 Identity Management (including Federation) - “Identity federation must be predicated upon prior
agreement between the identity and service providers.”
 Identification, Authentication, Authorization
 Trust Management - “. . . formulating security policies and security credentials, determining
whether particular sets of credentials satisfy the relevant policies, and deferring trust to third
parties.”
 Privacy
 On the communication channel
 Of confidential information
 Audit trails that document:
 Who initiated the transaction
 When it originated
 From where it originated
 Through what processes (services) it passed and when
 What transformations if any were done on the data while it was in transit
 Non-repudiation
 Of origin - the sender cannot falsely deny having been the originator of the message
 Of receipt - the receiver cannot falsely deny having received the message
 Provisioning
OWASP AppSec 2004
5
System-level Aspects of Web Services Systems That
Have Security Implications, Cont’d.
 Federation
 Service Choreography - (workflow) integration
 Persistence
 Of the message
 Of the data
 Integrity






Of
Of
Of
Of
Of
Of
the
the
the
the
the
the
communication channel
data in flight
semantic and referential integrity of the data
transaction (some of which can be very long-running)
session
network and the systems
 Message Reliability
 Assertions (SAML, XACML, etc.) “Trust me” . . . But now there are several levels of trust . . . trust
the validity of the assertion and trust that the assertion hasn’t been tampered with in flight.
 Asynchrony and (distributed, long-running) session management
 Transaction management
 End-to-end controls
 Single Sign-on
 Not mature . . . many different bodies - W3C, OASIS, the Liberty Alliance, WS-I
 Policy, policy policy
OWASP AppSec 2004
6
The Web Services Architecture - Meta Model
(from
http://www.w3c.org/TR/2004/NOTE-ws-arch-20040211/)
OWASP AppSec 2004
7
The Web Services Architecture - The Message
Oriented Model (from http://www.w3c.org/TR/2004/NOTE-ws-arch-20040211/)
OWASP AppSec 2004
8
The Web Services Architecture - The Service
Oriented Model (from http://www.w3c.org/TR/2004/NOTE-ws-arch-20040211/)
OWASP AppSec 2004
9
The Web Services Architecture - The Resource
Oriented Model (from http://www.w3c.org/TR/2004/NOTE-ws-arch-20040211/)
OWASP AppSec 2004
10
The Web Services Architecture - The Policy Model
(from http://www.w3c.org/TR/2004/NOTE-ws-arch-20040211/)
OWASP AppSec 2004
11
The Risk Management Process

In The Best of All Possible Worlds ™ an
organization has a risk management process that
looks like this:








A central body (preferably a corporate risk
management group which reports to the Board’s Risk
Committee) is responsible for and oversees the
process. This group is also responsible for the
enforcement of the policies and implementation of
controls.
Policies and (other) controls are selected based on
results of risk assessments.
Information on the policies and appropriate use of
controls is published and advertised.
Monitoring processes are in place to determine the
degree to which the policies and controls are effective.
The results of the evaluation is fed back into the risk
assessment process.
Policies and the selection of controls reflect the
organizations tolerance for risk.
Any risk that is not explicitly covered by policies and
controls, or which is incurred because policy is
ignored or controls were not put in place should be
explicitly acknowledged and formally accepted.
This is normally accomplished through the
Certification and Accreditation process.
The above is especially important with respect to
Web Services-based systems because they
introduce many risks which are not addressed in
legacy policies and controls.
The shaded blocks are where the Risk Management
process interfaces with the System Development
Life Cycle.
OWASP AppSec 2004
12
The Relationship Between the Risk Management
Process and the System Development Life Cycle
 At a high level, the relationship
between an organization’s risk
management process and the IT
SDLCs is very straightforward:
 The controls and policies that are
published by the risk management
process are requirements for and
define trust assumptions to the SDLC.
 In turn, changes in system
configuration, design and functionality
induce changes in the organization’s
risk and trust profiles.
 This relationship holds no matter how
formal the risk management process
and the system life cycle management
processes are.
 With the coming of Web Services,
rigorous risk management processes
and system life cycle management
processes become very important.
OWASP AppSec 2004
13
Policy!
 “Policy” has appeared frequently in this presentation. That’s because it is a very
important aspect of Web Services, Web Services security and information security in
general. Depending upon the context, it has different (but related) meanings. No
matter the context, though, policies are the formal statement of the organization’s
rules of engagement.
 When it comes to Web Services, policy is recursive. Organizations need (enterprise
business and security) policies that define Web Services policies.
 For example: An organization has a policy that requires dual-factor authentication for
all access from locations that are not on the organization’s internal network. That
policy would then show up in the organization’s Web Services access control policies
which would, in turn, show up the services’ policy database.
 The important point to take away from this is that an organization’s Web Services
policies must not be afterthoughts or “bolt-ons.” They should follow from the
organization’s overall policy structure and should result from the same risk
assessment process from which all other policies follow.
 The implication for the Web Services System Development Life Cycle is this: The risk
management process should be involved before any work starts on designing and
building Web Services-based systems.
OWASP AppSec 2004
14
Security Considerations in the System Development
Life Cycle - NIST Special Publication 800-64


There are many different ways to characterize the System
Development Life Cycle. For this discussion we will use the one
found in NIST SP 800-64 as a starting point.
There are two reasons for using it as a framework:
 It is a relatively simple model, and
 It specifically addresses security considerations in the SDLC.

SP 800-64 breaks the SDLC into five phases:
1.
2.
3.
4.
5.
Initiation
Acquisition/Development
Implementation
Operations/Maintenance
Disposition
OWASP AppSec 2004
15
NIST SP 800-64 - Security Considerations in the
Initiation Phase
 Needs Determination - is an analytical activity that evaluates the
capacity of an organization’s assets to satisfy existing and emerging
demands. The security part of needs determination will result in a highlevel description of the security controls in the proposed system and the
assurance requirements.
 Security Categorization - defines three levels (i.e. of potential impact on
organizations or individuals should there be a breach of security (a loss of
confidentiality, integrity, or availability). Security categorization standards
assist organizations in making the appropriate selection of security controls
for their information systems.
 Preliminary Risk Assessment - results in an initial description of the
basic security needs of the system. A preliminary risk assessment should
define the threat environment in which the system will operate. This
assessment is followed by an initial identification of required security
controls that must be met to protect the product/system in the intended
operational environment.
OWASP AppSec 2004
16
NIST SP 800-64 - Security Considerations in the
Acquisition / Development Phase
 Risk Assessment - analysis that identifies the protection requirements for the system through a
formal risk assessment process. This analysis builds on the initial risk assessment performed
during the Initiation phase, but will be more in-depth and specific. In addition to considering the
security perspective of the system being acquired, organizations should also consider the the
system might affect other systems to which it will be directly or indirectly connected.
 Security Functional Requirements Analysis - analysis of requirements that may include the
following components: (1) system security environment, (i.e., enterprise information security
policy and enterprise security architecture) and (2) security functional requirements. Because
most systems have at least minimal integrity and availability requirements, care should be taken
to clearly address those areas. . . . Even systems with low confidentiality requirements need
security to meet integrity and availability requirements.
 Security Assurance Requirements Analysis - analysis of requirements that address the
developmental activities required and assurance evidence needed to produce the desired level of
confidence that the information security will work correctly and effectively. The analysis, based
on legal and functional security requirements, will be used the basis for determining how much
and what kinds of assurance are required.
 Cost Considerations and Reporting - determines how much of the development cost can be
attributed to information security over the life cycle of the system. These costs include hardware,
software, personnel and training.
OWASP AppSec 2004
17
NIST SP 800-64 - Security Considerations in the
Acquisition / Development Phase, Cont’d
 Security Planning - ensures that agreed upon security controls, planned or in place, are fully
documented. The security plan provides a complete characterization or description of the
information system as well as attachments or references to key documents supporting the
agency’s information security program (e.g., configuration, management plan, contingency plan,
incident response plan, security awareness and training plan, rules of behavior, risk assessment,
security test and evaluation results, system interconnection agreements, security
authorization/accreditations, and plan of action and milestones).
 Security Control Development - ensures that security controls described in the respective
security plans are designed, developed and implemented. For information systems currently in
operation, the security plans for those systems may call for the development of additional security
controls to supplement the controls already in place or the modification of selected controls that
are deemed to be less than effective.
 Developmental Security Test and Evaluation - ensures that security controls developed for
a new information system are working properly and are effective. Some types of security controls
(primarily those controls of a non-technical nature) cannot be tested and evaluated until the
information system is deployed - these controls are typically management and operational
controls.
 Other planning components - ensures that all necessary components of the development
process are considered when incorporating security into the life cycle. These components include
selection of the appropriate contract type, participation by all necessary functional groups within
an organization, participation by the certifier and accreditor, and development and execution of
necessary contracting and processes.
OWASP AppSec 2004
18
NIST SP 800-64 - Security Considerations of the
Operations / Maintenance Phase
 Configuration Management and Control - ensures adequate
consideration of the potential security impacts due to specific
changes to an information system or its surrounding environment.
Configuration management and configuration control procedures are
critical to establishing an initial baseline of hardware, software, and
firmware components for the information system and subsequently
controlling and maintaining an accurate inventory of any changes to
the system.
 Continuous Monitoring - ensures that controls continue to be
effective in their application through periodic testing and evaluation.
Security control monitoring (i.e., verifying the continued
effectiveness of those controls over time) and reporting the security
status of the information system to appropriate agency officials is an
essential activity of a comprehensive information security program.
OWASP AppSec 2004
19
NIST SP 800-64 - Security Considerations of the
Disposition Phase
 Information Preservation - ensures that information is retained,
as necessary, to conform to current legal requirements and to
accommodate future technology changes that may render the
retrieval method obsolete.
 Media Sanitization - ensures that data is deleted, erased, and
written over as necessary.
 Hardware and Software Disposal - ensures that hardware and
software is disposed of as directed by the information security
officer.
OWASP AppSec 2004
20
Policy, Again
 Before an organization starts to design and build Web Services-based systems, it should have
policies in place that will provide the context in which security-related decisions can be made.
 In the best of all possible worlds, the organization would already have addressed the kinds of
topics outlined on slides 5 and 6, and there would be policies that state the organization’s position
on the system-level aspects of Web Services systems that impact security. Things like:
 What kinds of authentication mechanisms to use when the requestor is in a different trust domain than the
service.
 What authorization mechanisms to employ given the nature of a service and the authentication mechanism
used.
 What data should be present in audit trails and what data should be logged, how frequently, where, etc.
 Under what circumstances to require non-repudiation.
 How to provision users.
 How identity management is to be handled, registration requirements, etc.
 When to use persistent messages, how to enforce the requirement, etc.
 The “Rules of Federation,” with whom the organization will enter into “federations,” what assertions it will
accept from whom, etc.
 How, and under what circumstances to participate in SSO “federations,” what levels of access the
organization will tolerate given successful authentication, etc.
 What messages and what parts of messages should be encrypted, etc.
 The bottom line is this: Web Services is a whole new universe that is being laid on top of existing
systems. The organization has few policies that are applicable to the Web Services paradigm,
and it really needs some before it starts building them.
OWASP AppSec 2004
21
System-level Security Considerations in the Web
Services System Development Life Cycle
 In these final few slides, we will look at some of the
system-level security considerations that we discussed in
the context of the System Development Life Cycle.
 This will not be an exhaustive look . . . that would take
days. The purpose is point out where Web Servicesbased systems bring unique considerations to the SDLC.
 Nor will we be covering things like Java or .NET security,
XSS, SQL injection, etc. There are many other venues
for that.
OWASP AppSec 2004
22
Initiation Phase
 Preliminary Risk Assessment - The main thrust at this stage is to:
 Understand the
 Understand the
will be crossed.
 Understand the
 Understand the
requirements.
 Understand the
 Understand the
 Understand the
emergent risks.
risks associated with crossing the trust boundaries that
identity and trust management constraints.
basic confidentiality, integrity and availability
basic privacy requirements.
transaction management requirements.
audit requirements.
 Go through the security categorization process.
 Then, based on the results of the risk assessment and the
categorization process, produce a high-level description of the
 Controls that the system will need and
 The assurance requirements for the system.
OWASP AppSec 2004
23
Acquisition / Development - Risk Assessment

Actually, this step has three parts:
1.
2.
3.


An assessment of threats with which the system will have to deal when it goes online in
order to identify the protection requirements for the new system.
An assessment of the threat that this new system will pose to the legacy systems with
which it will interact. The purpose of this assessment is to identify the emergent risks and
determine what controls need to be implemented in order to protect legacy systems from
threats to which they will be exposed by interacting with the new system.
An assessment of the development environment, tools and suites that could be used in the
development process. Of particular importance is understanding the holes that are left by
the “drag-n-drop” EAI and XML/Web Services framework tools like those from BEA,
WebMethods, WebSphere, Tibco, etc. It is very important to understand how they do
what they do, as well as what they don’t do.
This assessment should cover all of the items listed on slides 5 and 6 along with all
of their brothers, sisters, aunts, uncles, cousins, etc.
The objective of this assessment is to determine a set of policies and controls that:





Understand and manage the trust relationships that it has with endpoint entities and local
legacy systems.
Does not create vulnerabilities or unintended interdependencies in systems with which it
interacts.
Does not decrease the availability of the legacy systems with which it interacts.
Does not decrease the security posture of the other systems in the enterprise.
Is capable of withstanding assault from “the other side of the Net.”
OWASP AppSec 2004
24
Acquisition / Development - Security Functional
Requirements Analysis
 The purpose of this step is to insure that system requirements
include controls that may be required by law, such as HIPAA,
Sarbanes-Oxley, etc.
 This is particularly important in Web Services systems because this
may affect:
 The kind of authorization mechanism a system uses.
 The policies that are published.
 How and where data are stored.
 The impact of a loss of:
 Confidentiality
 Integrity
 Availability
 Choice of identification, authentication and authorization mechanisms.
 Etc.
OWASP AppSec 2004
25
Acquisition / Development - Assurance Requirements
and Review by the Certifier and the Accreditor
 The sole reason for implementing security policies and other controls is to
manage risk. It does not make sense to implement a policy or control if
there is sufficient question about whether or not the control will actually
accomplish the purpose to which it was intended. Therefore, it is important
to:
 Define assurance levels that must be met by the controls.
 Establish that the controls can provide the required levels.
 One of the major functions provided by the Certification and Accreditation
process is to clearly describe the residual (uncontrolled) risk faced by the
system and to have the business owner of the system formally acknowledge
and either accept or reject it.
 This is particularly important for Web Services-based systems because the
risks are typically greater than those in conventional systems, but
traditionally there has been considerable reluctance to fully confront and
address them. This process insures that the risks are officially
acknowledged and that the owner of the risk has formally accepted them.
 This step gives the system certifier and accreditor an opportunity to
evaluate the controls that are being installed into the system while the
system is a “work in process.”
OWASP AppSec 2004
26
Acquisition / Development - Security Control
Development and Security Test and Evaluation
 Due to the nature of Web Services (remember the WSA), this is much more likely to
be a separate effort than is the case with more traditional systems. Especially in the
beginning, bringing up a Web Services-based system will entail designing and
building explicitly security-related services like:






Identification services
Authentication services
Authorization services
Policy management services
Audit and logging services
Etc.
 In addition to the construction of controls that are intended to protect the new
system, it will be necessary to design and develop controls that are necessary to
manage the “emergent risks” . . . the risks that will be introduced into the risk profile
of the systems with which the new system will connect. These controls could either
be shims or may require doing surgery on the legacy systems themselves.
 Given the complexity of the security architecture that must be present in a Web
Services-based system, the testing and evaluation of the security components is very
important. Therefore, having a robust testing plan is critical. The plan should
provide for iterative testing - beginning to test as soon as there is something to test.
“Getting security right” is hard enough as it is. Doing so with Web Services requires
more rigor and discipline than ever. Plan, test, evaluate . . .
OWASP AppSec 2004
27
Acquisition / Development - Contracts!
 In the discussion about Web Services being a paradigm shift, it was noted that Web
Services “externalize everything.” One of the effects of this is that it neutralizes some
of the enterprise policies and controls or creates monsters out of problems that might
be only nightmares for an enterprise. Take identity management and provisioning for
instance. Organizations respond to these problems with policies, procedures and
technical solutions to manage the problem internally. It’s hard enough to get right
within an organization. Now think about the problems of identity management,
provisioning and access control in a Web Services environment in which the identity
provider is in a completely different trust domain than is the requestor . . . and over
which the requestor has no a priori control. In the absence of some kind of out-ofband control, the risk profile of the requestor is that no assumption at all can be
made about the validity of the identity that is being presented. Hence, the
importance of contracts among interacting parties.
 The WS-Policy position is that a service’s published policy is the contract. At one
level, that may be true, but there are still a couple of things missing:
 Policy can only state conditions of acceptance.
 There is no enforcement mechanism.
 Thus, the need for a contract that, if nothing else, promises to honor the policy and
which provides for a penalty for not doing so.
 Basically, contracts become part of the enforcement mechanism of the risk
management process.
OWASP AppSec 2004
28
Acquisition / Development - Implementation
 Security Control Integration - It’s complex.
 Security Certification - This is another part of the enforcement and evaluation
function of the risk management process. The function of this step is:
 To verify that the controls that were supposed to be implemented actually were, and
 That they are effective. That is, that they work as they were intended.
 Security Accreditation - This is “the authorization step.” In this step, the business
owner (or whomever owns the risk for operating the system) has three options:
 Accept the system (and the residual risks) as is and authorizes it to go into production.
 Conditionally accepts the system (and the residual risks) and authorizes it to go into
production under the condition that certain problems are fixed within a certain amount of
time.
 Withholds approval until such time as the critical problems are fixed.
 Because the security context of Web Services-based systems are so complex, not
doing the Certification and Accreditation effectively means that the organization has
no concept of the risks to which the system is exposing it. And it deserves whatever
happens to it.
OWASP AppSec 2004
29
Operations and Maintenance
 Configuration Management and Control - In a full-blown system, this
will give the people wearing the beepers nightmares. Take another look at
the Web Services Architecture, the Services Model and the Resource Model.
So what has to be maintained?







Services
Policies
Identity Servers
Authentication Servers (including things like PKIs, KDCs, SSO systems)
Authorization Servers
Monitoring Processes
Etc.
 Continuous Monitoring - See above, plus
 Audit logs
 System logs
 Etc.
 And the above is in addition to the “standard” monitoring of firewall logs,
IDS logs, etc.
OWASP AppSec 2004
30
Disposition
 Information Preservation - Preservation requirements will vary
greatly depending upon many things. Some of them are:
 The nature of the information
 Where the information “lives.”
 Is an interesting problem for Web Services-based systems since it’s a
new paradigm . . .
 Media Sanitization - see above.
OWASP AppSec 2004
31
In Conclusion
We’re not in Kansas any more.
The interesting times are here.
We’re going to get a lot of it wrong before we
figure out how to do it right.
:-}
OWASP AppSec 2004
32
Some Good Sources of Information
 Organization for the Advancement of Structured Information
Standards (OASIS) - http://www.oasis-open.org
 The World Wide Web Consortium (W3C) - http://www.w3c.org
 XML.org - http://www.xml.org
 Cover Pages - http://xml.coverpages.org
 The Liberty Alliance Project - http://www.projectliberty.org
 Web Services Interoperability Organization - http://www.ws-i.org
 The Usual Suspects - IBM, Microsoft, BEA, Verisign, Sun, etc.
 Google
OWASP AppSec 2004
33