ENTERPRISE WEB SERVICES SECURITY
LIMITED WARRANTY AND DISCLAIMER OF LIABILITY THE CD-ROM THAT ACCOMPANIES THE BOOK MAY BE USED ON A SINGLE PC ONLY. THE LICENSE DOES NOT PERMIT THE USE ON A NETWORK (OF ANY KIND). YOU FURTHER AGREE THAT THIS LICENSE GRANTS PERMISSION TO USE THE PRODUCTS CONTAINED HEREIN, BUT DOES NOT GIVE YOU RIGHT OF OWNERSHIP TO ANY OF THE CONTENT OR PRODUCT CONTAINED ON THIS CD-ROM. USE OF THIRD-PARTY SOFTWARE CONTAINED ON THIS CD-ROM IS LIMITED TO AND SUBJECT TO LICENSING TERMS FOR THE RESPECTIVE PRODUCTS. CHARLES RIVER MEDIA, INC. (“CRM”) AND/OR ANYONE WHO HAS BEEN INVOLVED IN THE WRITING, CREATION, OR PRODUCTION OF THE ACCOMPANYING CODE (“THE SOFTWARE”) OR THE THIRD-PARTY PRODUCTS CONTAINED ON THE CD-ROM OR TEXTUAL MATERIAL IN THE BOOK, CANNOT AND DO NOT WARRANT THE PERFORMANCE OR RESULTS THAT MAY BE OBTAINED BY USING THE SOFTWARE OR CONTENTS OF THE BOOK. THE AUTHOR AND PUBLISHER HAVE USED THEIR BEST EFFORTS TO ENSURE THE ACCURACY AND FUNCTIONALITY OF THE TEXTUAL MATERIAL AND PROGRAMS CONTAINED HEREIN. WE HOWEVER, MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, REGARDING THE PERFORMANCE OF THESE PROGRAMS OR CONTENTS. THE SOFTWARE IS SOLD “AS IS” WITHOUT WARRANTY (EXCEPT FOR DEFECTIVE MATERIALS USED IN MANUFACTURING THE DISK OR DUE TO FAULTY WORKMANSHIP). THE AUTHOR, THE PUBLISHER, DEVELOPERS OF THIRD-PARTY SOFTWARE, AND ANYONE INVOLVED IN THE PRODUCTION AND MANUFACTURING OF THIS WORK SHALL NOT BE LIABLE FOR DAMAGES OF ANY KIND ARISING OUT OF THE USE OF (OR THE INABILITY TO USE) THE PROGRAMS, SOURCE CODE, OR TEXTUAL MATERIAL CONTAINED IN THIS PUBLICATION. THIS INCLUDES, BUT IS NOT LIMITED TO, LOSS OF REVENUE OR PROFIT, OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THE PRODUCT. THE SOLE REMEDY IN THE EVENT OF A CLAIM OF ANY KIND IS EXPRESSLY LIMITED TO REPLACEMENT OF THE BOOK AND/OR CD-ROM, AND ONLY AT THE DISCRETION OF CRM. THE USE OF “IMPLIED WARRANTY” AND CERTAIN “EXCLUSIONS” VARIES FROM STATE TO STATE, AND MAY NOT APPLY TO THE PURCHASER OF THIS PRODUCT.
ENTERPRISE WEB SERVICES SECURITY
RICKLAND HOLLAR RICHARD MURPHY
CHARLES RIVER MEDIA, INC. Hingham, Massachusetts
Copyright 2006 by THOMSON/DELMAR LEARNING. Published by CHARLES RIVER MEDIA, INC. All rights reserved. No part of this publication may be reproduced in any way, stored in a retrieval system of any type, or transmitted by any means or media, electronic or mechanical, including, but not limited to, photocopy, recording, or scanning, without prior permission in writing from the publisher. Acquisitions Editor: James Walsh Cover Design: Tyler Creative CHARLES RIVER MEDIA, INC. 10 Downer Avenue Hingham, Massachusetts 02043 781-740-0400 781-740-8816 (FAX)
[email protected] www.charlesriver.com This book is printed on acid-free paper. Rickland Hollar and Richard Murphy. Enterprise Web Services Security. ISBN: 1-58450-413-7 eISBN: 1-58450-657-1 All brand names and product names mentioned in this book are trademarks or service marks of their respective companies. Any omission or misuse (of any kind) of service marks or trademarks should not be regarded as intent to infringe on the property of others. The publisher recognizes and respects all marks used by companies, manufacturers, and developers as a means to distinguish their products. Hollar, Rickland, 1954Enterprise Web services security / Rickland Hollar, Richard Murphy.-- 1st ed. p. cm. Includes bibliographical references and index. ISBN 1-58450-413-7 (pbk. with CD-ROM) 1. Computer networks--Security measures. 2. Web sites--Security measures. 3. Web services. I. Murphy, Richard, 1954- II. Title. TK5105.59.H66 2005 005.8--dc22 2005018419 Printed in the United States of America 05 7 6 5 4 3 2 First Edition CHARLES RIVER MEDIA titles are available for site license or bulk purchase by institutions, user groups, corporations, etc. For additional information, please contact the Special Sales Department at 781-740-0400. Requests for replacement of a defective CD-ROM must be accompanied by the original disc, your mailing address, telephone number, date of purchase, and purchase price. Please state the nature of the problem, and send the information to CHARLES RIVER MEDIA, INC., 10 Downer Avenue, Hingham, Massachusetts 02043. CRM’s sole obligation to the purchaser is to replace the disc, based on defective materials or faulty workmanship, but not on the operation or functionality of the product.
To our wives and children, with thanks for their love and support.
This page intentionally left blank
Contents Introduction 1
xxi
Security in the Networked World Business on the Internet
1 3
B2B
3
B2C
4
Evolving Business Models
4
Information Protection
5
Privacy
5
Corporate Confidentiality
6
Legal Obligations
6
Web Services
7
XML
8
SOAP
8
The Messaging Model
9
Security Challenges
10
Threats and Risks
10
Policy
10
Internet
11
Intranet
11
Extranet
12
Wireless
12
Countermeasures
13
WS-* Family of Standards
14
vii
viii
Contents
Virtual Domain Model for Web Services Security
2
3
15
Security Domains
15
Enclaves
15
Trust Relationships
16
The Model
16
Summary
16
References
17
Threats and Attacks
19
Threats, Vulnerabilities, and Countermeasures
20
Ensuring Reliability
21
Vandalism and Sabotage
24
Denial of Service
26
Privacy and Confidentiality Breaches
27
Data Integrity Violations
29
Man-in-the-Middle Attacks
30
Spoofing Attacks
31
Mobile-Code Threats
32
Fraud
34
Special Considerations for Web Services Environments
35
Summary
38
References
39
Security Goals
41
Protecting Your Assets
42
Common Security Terms
42
Reducing Vulnerabilities
43
Realistically Assessing Threats
47
Choosing the Right Countermeasures
51
Recognizing and Accepting Residual Risk
52
Contents
Classic Security Goals
53
Confidentiality
54
Integrity
54
Availability
55
Transaction Security Goals
4
ix
56
Authentication
57
Scalability
58
Nonrepudiation
59
The Role of Security Policy in Web Services Security Enforcement
60
Summary
61
References
61
The Internet and World Wide Web Infrastructure
63
Internet 101
64
TCP/IP
65
HTTP
67
Security Domains
71
Client System Vulnerabilities
73
Browser Vulnerabilities
74
Java Virtual Machine Vulnerabilities
76
Networks
77
TCP/IP Vulnerabilities
77
HTTP Vulnerabilities
79
SMTP Vulnerabilities
79
Server Vulnerabilities
81
Web Server Vulnerabilities
82
Other Vulnerabilities
82
Summary
83
References
83
x
Contents
5
Web Services Web Services Standards
86
XML
88
Elements and Attributes
88
Namespaces
90
Schemas
92
Transformations
96
SOAP
6
85
99
Document Style Messages
100
RPC Style Messages
103
Binding
105
WSDL
105
UDDI
109
Web Services Toolkits
115
Summary
116
References
116
Security Policy Basics
119
The Importance of Security Policy
120
Steps in Developing a Security Policy
122
Identify the Assets You Are Trying to Protect
123
Identify the Threats You Are Protecting Against
123
Map Threats to Probability of Loss and Cost
125
Implement Cost-Effective Measures
126
Continuously Review and Improve Security Policies
126
The Security Policy Document
127
Summary
127
References
128
Contents
7
Communicating Policy
129
Expressing Security Policy in Web Services
130
WS-Policy
131
Normal Form
132
Compact Form
133
Merging Policies and Resolving Conflicts
135
WS-SecurityPolicy SecurityToken
Integrity
135
Assertion
Confidentiality
Assertion
Assertion
Visibility
Assertion
SecurityHeader
Assertions
136 138 139 142 143
Assertions
144
Putting It Together: An Example
144
MessageAge
WS-PolicyAttachment
8
xi
146
Tying Policies to Subjects
146
Making Policies Discoverable
148
Effective Policy
152
Summary
153
References
153
Protecting the System Components
155
Security Controls for the System Components
156
The Client
156
Workstation Vulnerabilities
157
Operating System Security
158
Browser Security
159
Downloading Components
164
ActiveX Security
167
xii
Contents
9
Java Security
169
Scripting
171
Plug-Ins
172
The Network
173
Network Vulnerabilities
173
Wireless Communications
174
Firewalls
175
Gateways, Guards, and Routers
176
Virtual Private Networks
177
Servers
177
Web Server Vulnerabilities
179
Operating System Security
181
Summary
183
References
184
Protecting Messages, Transactions, and Data
187
Protecting a Web Services Exchange
188
Securing the Communications Channel
190
Link, Network, and Applications Layer Encryption
191
Point-to-Point Encryption
191
End-to-End Encryption
192
Using SSL to Establish Secure Sessions
192
Identity Management and Trust
192
Trust Relationships
193
Identity Management
193
Passwords and Pass-Phrases
195
Smart Cards
196
Third-Party Brokers
196
Certificate Authorities
197
Kerberos Authentication Servers
197
Contents
Policy Decision Points
197
Microsoft .NET Passport
197
Liberty Alliance
198
Authentication
198
User IDs and Passwords
199
X.509 Public Key Authentication
200
LDAP (The Role of Directory Services)
201
Kerberos
202
Authorization
205
Basic Web Servers
208
J2EE Applications Servers
210
ASP.NET Servers
211
Access Control
10
xiii
213
Choosing the Identity Mapping Scheme
217
Mandatory Access Controls
219
Choosing the Access Control Decision Point
220
Summary
221
References
221
Implementing the Information Security Triad Confidentiality
225 226
Encryption
226
Steganography
242
SSL and TLS
243
Integrity
247
Digital Signatures
247
Nonrepudiation
250
Summary
251
References
251
xiv 11
12
Contents
Communicating Security Credentials
253
Client-Server Credential Communication
254
WS-Security
255
Message Security Model
255
Security Header Element
256
XML Encryption
265
XML Signature
271
Message Protection
276
Putting It Together: An Example
277
Summary
279
References
280
Audit
283
Goal of Audit
284
What to Audit
284
Auditable Events
285
Audit Information
286
Levels of Audit
286
Network
287
Server
288
Components
288
Application
289
Active versus Passive Auditing
292
Audit Data Processing
293
Intrusion Detection and Prevention Systems
294
Intrusion Detection System Basics
295
Intrusion Prevention Systems
295
Summary
296
References
296
Contents
13
Virtual Domain Model for Web Services Security
299
Trust Relationships
300
General Security Context Model
301
Types of Trust Relationships
302
Trust Relationships Between Principals
303
Trust Domains
304
Trust Relationships Between Domains
306
Creating Physical and Logical Trust Domains
308
Where Should Trust Relationships Be Created?
308
What Credentials Will Be Used?
309
What Are the Integrity and Confidentiality Considerations?
310
How Will Credentials Be Provisioned?
311
What Principals Will a Given Principal Trust?
312
Creating Virtual Trust Domains
14
xv
314
Experience Based
314
Reference Based
315
Reputation Based
318
Summary
319
References
320
Establishing and Communicating Trust
321
Types of Trust Relationships
322
WS-Trust
324
The Web Services Trust Model
324
Requesting and Returning Tokens: The STS Framework
324
Negotiation and Challenge Extensions
328
Key and Token Extensions
329
WS-Federation
330
Basic Concepts
331
Federation Metadata
333
Attribute and Pseudonym Services
333
xvi
Contents
WS-SecureConversation Security Context
334
Context Binding
334
XKMS
15
334
335
XML Key Registration Service
335
XML Key Information Service
336
XML Key Management Service Bulk Operations
337
SAML
337
XACML
340
Summary
344
References
344
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
347
Enterprise Web Services
348
Step 1: Identify the Parties Involved
349
Who Are the Clients?
350
How Will Clients Access the Service?
350
How Will Clients Discover the Service?
350
What Intermediaries Are Involved in the Transaction?
351
Does the Web Service use Other Services?
351
Step 2: Identify Relevant Domain Infrastructure and Capabilities
351
How Many Security Domains are Involved in Supporting the Service?
352
What Security Services are Provided in the Domains Involved?
352
What Token Services are Involved in Providing those Services?
352
What Supporting Services are Provided in the Domains Involved?
353
Step 3: Identify Necessary Security Services Based on Local Policies
353
Are Authentication Services Needed?
353
What Resource or Information Needs To Be Protected?
354
Are Authorization and Access Control Services Needed?
354
Are Confidentiality Services Needed?
355
Contents
Are Integrity Services Needed? Step 4: Identify Gaps and Project a Virtual Trust Domain
356 356
Missing Services
358
Differences in Services
359
Security-Relevant Differences in Levels
360
New Boundaries and Boundary Services
362
Step 5: Allocate New Infrastructure Services across Physical and Logical Domains
362
Security Services
364
Support Services
364
Service Distribution Strategy
364
Step 6: Allocate Security Services across Actors
16
xvii
364
J2EE Environment
365
.NET Environment
367
Crossing a Technology Boundary
368
Step 7: Create and Distribute Discovery and Policy Artifacts
371
Summary
371
FutureScape
373
Going Mobile
374
What Is Self-Protecting Data?
374
Protecting Data In Transit
375
Protecting Data At Rest
377
Protecting Data In Use
378
Digital Rights Management
379
Rights Expression Languages
380
Web Services’ Role
381
Summary
381
References
381
xviii
Contents
Appendix A The Security Policy Document
383
Introduction
384
Responsible Organizations
385
Physical Security
385
Personnel Security
386
Security Standards
386
Defending the Computing Environment
387
Workstation Security
388
Server Security
388
HTTP Services
389
Database Management System (DBMS) Services
389
Applications Services
390
Network Security
390
Secure Messaging
390
Mobile Code
390
Defending the Enclave Boundary
391
Firewalls
391
Virtual Private Networks (VPNs)
392
Remote Access
392
Guards
393
Content Filtering
393
Virus Protection
393
Gateway Spam Filtering and Virus Protection
393
Defending the Network and Infrastructure
394
Supporting Infrastructure
394
Key Management
394
Intrusion Protection
395
Audit
396
Backups and Retention
396
Disaster Recovery
396
Contents
xix
Web Services
397
Security Incident Handling and Response
398
Notification
398
Points of Contact
398
Containment
399
Assess Damage, Perform Triage
399
Recovery
399
References Appendix B About the CD-ROM
399 401
System Requirements
401
CD-ROM Contents
402
Web Site
402
Index
403
This page intentionally left blank
Introduction
eb Services are ushering in a new era in applications and applications development. When coupled with the Internet, Web Services are moving us toward a truly frictionless economy where traditional barriers to entry such as location, geography, and “perfect knowledge” are not only being removed, but are being utterly destroyed. Web Services are fueling the revolution because they are based on open standards, which are firewall friendly and vendor and platform agonistic. Building on object-oriented programming’s and distributed computing architecture’s (such as COM and CORBA®) legacies, they are the next big thing in computing and represent the potential for revolutionizing how we interact with business, with academia, and with government. Web Services provide the programmability that brings Sun Microsystems®’ Scott McNealy’s prediction of “the network is the computer” within reach. As with most things, progress brings not only opportunity but risk. The opportunity is the ability to develop new ways of interacting with customers, suppliers, and business partners. Web Services take the concept of disintermediation to a whole new level by enabling agent-based business-to-business and business-tocustomer applications. Web Services running across the Internet make it possible for even small businesses to have a global reach. Businesses are no longer confined to a local corner, the idiosyncrasies of the local traffic pattern, or the market potential defined by advertising budgets and word-of-mouth marketing. Even small businesses can now market globally and can develop value chains with suppliers and business partners from around the globe. Time zones and geographic and political boundaries become almost meaningless. The revolution is not confined to external interactions; it applies to internal interactions as well. When applied to an organization’s internal systems, Web Services provide a way to develop horizontally and vertically scalable applications that are always available. They also provide new ways of thinking about back office integration of these services.
W
xxi
xxii
Introduction
That is the upside. What is the downside? The downside is increased risk. People and organizations out there are willing to steal identities and corporate secrets or disrupt a site’s ability to support its customers, either as a game, to make a political statement, or for profit. Protecting yourself or your organization against these threats is what this book is about. Since Caesar’s day there has been a need for people to be able to interact and communicate securely. The earliest encryption techniques were introduced to help Caesar’s legions communicate. Traditional security techniques have evolved around the issue of protecting systems and networks in ways that allow people to rely on others being who they say they are and on being able to maintain the privacy and integrity of their communications. Web Service ride on top of these traditional systems and networks and build on the countermeasures and methods developed over the past half-century for maintaining confidentiality, integrity, and availability. Isaac Newton said, “If I have seen further [than certain other men] it is by standing upon the shoulders of giants” [Newton]. Web Services security in effect stands on the shoulders of giants. This book is designed to help you understand not only the evolving Web Services security standards and their use, but the underlying principles, concepts, and infrastructure on which they are built.
HOW THIS BOOK IS ORGANIZED This book is organized into major sections that you can use to familiarize yourself with the subject or in constructing either a one- or two-semester course, depending on the background and experience of your students. Chapter 1 begins with a brief introduction to conducting business on the Internet and the role Web Services play. It also introduces some of the security challenges and the virtual domain model we have developed based on the existing and emerging Web Services standards to help address those challenges. Chapters 2 and 3 discuss security threats and attacks and the classic security goals of protecting against those threats and attacks. Chapters 4 and 5 introduce the basic technologies Web services build upon. Chapter 4 discusses the Internet and the World Wide Web; Chapter 5 provides an overview of the extensible markup language (XML) and Web Services.
Introduction
xxiii
Chapter 6 discusses basic security policy and why security policy is important to an organization. Chapter 7 covers the Web Services standards in place for communicating policy. Chapters 8, 9, and 10 take a bottom-up look at implementing security measures. Chapter 8 looks at protecting networks and servers; Chapter 9 looks at protecting messages, transactions, and data; and Chapter 10 completes the information security triad by looking at confidentiality and integrity. Chapter 11 discusses the Web Services standards for communicating the security tokens and credentials between parties introduced in Chapters 8–10. The chapter goes into detail concerning the WS-Security, XML Encryption, and XML Signature standards. Chapter 12 looks at auditing and its role in the overall security architecture. Chapters 13 and 14 go into detail concerning the concepts of trust and communicating trust both between parties and across domains. Chapter 13 goes into depth concerning the types of trust and physical, logical, and virtual trust domains. Chapter 14 looks at the standards such as WS-Trust, WS-Federation, XKMS, SAML, and XACML for communicating trust and establishing trust relationships. Chapter 15 concludes the book with the development of a seven-step process for addressing enterprise Web Services security within a multiple domain context. You can customize how you approach this book depending on your background or that of your audience. If you are already familiar with basic Web Services technologies and are looking for a better grounding in security techniques and the supporting Web Services standards, you may want to skip Chapters 4 and 5. If you are already familiar with traditional security concepts and how they are applied and are just looking for how to use the Web Services standards, you may want to concentrate on Chapters 4, 5, 7, 11, 14, and 15.
WHO THIS BOOK IS FOR This book is intended for business, security, and technology professionals and students wanting to increase their understanding and knowledge of basic security principles, Web Services security standards and techniques, or both. We try to provide even coverage in suitable depth for teaching these concepts at an introductory level at either the undergraduate or graduate level. Our goal is to demystify many
xxiv
Introduction
of the basic security concepts and to illustrate how they can be applied using the Web Services standards as part of a comprehensive enterprise security strategy. The book is also for the professional. Regardless of whether you are a manager wanting to know about Web Services and security, a security professional wanting to better understand Web Services, or a Web Services architect or developer wanting to better understand security, you will find the foundation you need in this book.
REFERENCES [Newton] The Columbia World of Quotations, Columbia University Press, 1996. Available online at http://www.bartleby.com/66/18/41418.html.
1
Security in the Networked World
In This Chapter Business on the Internet Information Protection Web Services Security Challenges Countermeasures WS-* Family of Standards Virtual Domain Model for Web Services Security Summary References
he wide reach of the Internet and the World Wide Web have changed the way we do things in many ways that would not have been thought possible just 20 years ago. Consumers now interact directly with sellers, students now attend class online, businesses now interoperate with suppliers and partners through back office applications and electronic data exchange, and governments now provide direct online services to their constituents. We now have a generation that may never have had to use a library for basic research or snail-mail to file a tax return. More and more of us are using the Internet for comparing prices and making purchases. This helps reduce prices by increasing competitive pressures that in turn cause businesses to look for more efficient and effective ways of providing services that in turn drive down costs and prices in a continuing cycle that is driving a global economy. Consumers are no longer limited to local merchants when comparing prices, and merchants are no longer restricted to local customers when selling. The Internet is
T
1
2
Enterprise Web Services Security
creating a truly global marketplace where from an economic standpoint, there is near perfect knowledge, almost frictionless selling, and low barriers to entry. While these changes in the way we live are significant, they still cannot be called revolutionary, as we’ve basically moved our brick-and-mortar ways of doing business and interacting onto the Web. For example, rather than send out paper catalogs and depend on mail and telephone orders, companies now put their catalogs onto the Web and accept direct credit card orders from customers. This isn’t really all that different from the way companies did business before, as only the paper catalog and the intermediaries to the transaction have been eliminated. The revolution is about to begin. We are now seeing the beginnings of something that can be called truly revolutionary as the Internet enters its third generation. The first generation Internet was about connectivity and providing basic capabilities. It was defined by basic standards-based protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP) and Simple Mail Transport Protocol (SMTP), and services such as File Transfer Protocol (FTP) and email. The World Wide Web defined the second generation of the Internet through the HyperText Transport Protocol (HTTP) and HyperText Markup Language (HTML). The second generation was about browsing (discoverability) and presentation. The eXtensible Markup Language (XML) and the Web Services standards are defining the third generation of the Internet and are setting the stage for a semantic Web that many believe will be even more revolutionary. Web Services are often confused with more general services that may be available over the Web. We will clearly distinguish between Web Services and more general services by capitalizing both terms when referring to a Web Service. XML and Web Services are combining to provide programmability, which opens a whole new way of thinking about business models and interacting. These standards have the potential to drastically alter how individuals and companies work together and interact, allowing things that couldn’t be done or even conceived of before. New ways of doing things come with benefits and risks. As Metcalf’s law points out, the value of a network is proportional to the square of the number of connected nodes [Gilder93]. That means there is a potentially incredible upside to making services available on a highly interconnected network such as the Internet where there are millions of connected users, a population that is growing everyday. The downside is the accompanying potential for damage or loss. All the nodes out there are not necessarily friendly ones. Some are competitors, some may be adversaries, some may be criminals intent on stealing valuable information, and some may be hackers intent on disrupting or destroying information or capabilities as a game, a challenge, or to further their own motives.
Security in the Networked World
3
This book provides guidance for organizations that are ready to take that next step, that are considering moving onto more open networks such as the Internet and transforming their business processes using Web Services. We describe the capabilities of Web Services and how they can be safely used to augment or replace current business process and information exchange models. We do this from an enterprise perspective, as we realize one of the challenges an organization must face is in moving from wholly owned and controlled private networks to highly interconnected intranets and extranets, with some even having the Internet as their backbone. One of the concerns enterprises have with moving toward the use of Web Services is the security pitfalls that companies risk when converting to automated, online transactions and back office operations. Part of the purpose of this book is to explain the ways in which such a conversion can be effected while addressing the potential underlying security concerns. We describe security concerns not to frighten people away from moving online, but to help demystify the threats and risks and remove the hype and hysteria surrounding attacks and their potential impacts and to thereby hasten the transition.
BUSINESS ON THE INTERNET Several things are driving movement toward the Web Services way of doing business. Some of these drivers are caused by the current movement of more and more companies onto the Internet. The Internet offers low-cost, high-speed, highly reliable backbone networks that can give a company global reach. The Internet provides new ways for the business entities (buyers, sellers, end users, etc.) to work together by allowing new ways for business relationships to be built. The way these relationships have formed is driven partially by modeling and extending preexisting business models. The Internet has demonstrated additional flexibility in how business partners can interact. These include Internet-centered versions of traditional business operations (B2B and B2C, as will be described next) and new types of interactions made possible by Web Services. B2B The term business to business (B2B) refers to a business transaction that takes place between two companies. While the definition doesn’t require that the Internet be involved in the transaction, the term usually implies some networking involvement. B2B isn’t just a replacement for commodity sales between companies. There are many other types of Internet-centric B2B portals (Web sites that support business operations). These include:
4
Enterprise Web Services Security
Supply and procurement portals that allow companies to request products and suppliers to bid for those needs Brokering portals that act as intermediaries between buyers and sellers Vertical industry portals dedicated to a particular industry segment In the past, some B2B transactions were supported by proprietary electronic data interchange (EDI) transaction systems that routed and translated EDI forms between trading partners. The EDI forms themselves were standards based, there being industry standards (ANSI® X.12 series) for traditional business forms such as orders, invoices, manifests, etc., yet the internal forms and the networks connecting trading partners frequently remained closed or proprietary. Web Services systems are replacing these with systems built on open, standardized interfaces and open networks such as the Internet. Portals act like an equalizer because participation is available to companies of any size. Small companies selling products compete with larger suppliers on a level playing field. B2C Business to consumer (B2C) refers to a business transaction between a consumer and a business. This is the retail side of the business that drives other online transactions and is generally limited to online purchasing. Unlike B2B, there is no significant Web Services penetration in the B2C space, but Web Services plays a large part in the fulfillment systems that handle processing of customer orders. Evolving Business Models Don Tapscott, in his book Digital Capital [Tapscott00], discusses the effect highly connected networks, such as the Internet, are having on traditional business models. He discusses five types of business webs: Agora (Greek for “marketplace”): A real or virtual marketplace where buyers and sellers can come together to discover the price of a good or service, that is, a global flea market. Aggregators: Bring producers and consumers together, helping consumers select, organize, and purchase goods. Alliances: Each player, motivated by self-interest, contributes something to the product or service. Value Chains: A conductor designs, produces, and delivers products or services to meet a specific set of needs, possibly through B2B. Distributive Network: Facilitates the discovery and exchange of information or goods between providers and users.
Security in the Networked World
5
Web Services are a key enabler in each. As we will discuss in the next two sections, Web Services provide the information protection mechanisms necessary to operate in such a diverse, dynamically connected environment and the distributed transaction computing model needed to fuel multiorganization alliances, value chains, and distributive networks.
INFORMATION PROTECTION A second major driver behind the Web Services way of doing things is the increasing need for information security solutions that can span network and organizational boundaries. One of the primary purposes of an information security program is to protect the information (transaction records, customer data, etc.) generated or gathered by a company in support of their business operation. Sometimes the need to protect this information is obvious; for example, it’s easy to convince a company to protect information that would help a competitor gain a business advantage. Protecting the privacy of customer records may not be as easy to justify from a business standpoint; in this case, there may be laws that require a company to extend protection to records that may not have a direct business impact. Examples of these laws for the United States are the Health Insurance Portability and Accountability Act of 1996 (HIPAA) [CMS05] and the Sarbanes-Oxley Act of 2002 [SEC05] regulations. Europe has similar regulations such as the 2002 EC Directive on Privacy and Communications. (In most ways, European governments have stricter privacy regulations than the regulations in the U.S.) We can categorize some of these drivers for security regulations under the broad headings of privacy, corporate confidentiality, and legal obligation. Privacy Employers have fiduciary responsibilities to their employees and need to respect both their privacy and desire to keep confidential information confidential. The surreptitious interception of an employee’s computer communications, such as email or chat room sessions, or release of their personnel records can expose an employer to one set of issues; the compromise of employee medical, legal, financial, and grievance information can expose them to another. The Children’s Online Privacy Protection Act creates a responsibility relationship between a Web site sponsor and both underage users and their parents [FTC99]. The act gives parents control over the information a Web site can collect from and about their children when those children are under 13 years of age and provides provisions for parents to be able to “opt-out” of having that information collected for their children.
6
Enterprise Web Services Security
Consumers also have the right to obtain information businesses may collect and maintain about them or their transactions. The Federal Trade Commission (FTC) maintains a Web site providing guidance for businesses on the information they need to collect and protect and for consumers on how to obtain that information [FTC04]. Companies must be concerned with theft. When they collect information from their customers to help with order processing, those customers assume that the information they supply will be protected. The organization that accepts this data must take steps to protect the privacy of their customer’s information. Customer bank and credit card information that is a necessary part of transactions is a prime target for identity theft. As this is being written, there have been several cases of companies receiving negative publicity because of inadvertent loss of customer or employee information [Daurat05]. The problems in the cited article are examples of privacy violations that American consumers are just beginning to understand. Corporate Confidentiality Just as individuals have a right to privacy, businesses have the right to conduct business without being subjected to unfair methods of competition and of deceptive acts and practices within the marketplace. The FTC is the enforcement authority in this area. In today’s global marketplace and competitive environment, businesses must be concerned with a number of issues including trademark and copyright protection, piracy of digital content, and competitive intelligence. Competitive intelligence is information about a business that may give others insight into future plans, customers, products, or technologies and therefore a competitive advantage. The information you need to protect to avoid exposure is often less obvious than in the areas of trademarks, copyrights, or piracy protection. Competition can come in many forms. For example, recruiters working for a competitor may be interested in internal phone lists and payroll information in order to launch a raid on a firm’s employees. A competitor may be interested in customer lists, product development plans, or contract pricing strategy to aid them in planning and executing a counterstrategy or new sales promotion. Alarm codes, computer security codes, and application source code are also of interest to those wanting to obtain access or steal information from a company. Web applications should be written to carefully protect access to such information, allowing only authorized information to be exposed to Web users. Legal Obligations In addition to privacy and business reasons for protecting information, there may be a legal requirement to do so based on the particular type of organization or business area served and the type of information involved.
Security in the Networked World
7
Several legislative acts govern the use of information by executive branch agencies of the U.S. government. The Privacy Act of 1974 [DOJ04] regulates the collection, maintenance, use, and dissemination of personal information by these agencies. The Computer Matching and Privacy Protection Act of 1988 [DOJ04a] establishes further requirements for providing individuals notice and an opportunity to refute adverse or derogatory information collected about them. The Freedom of Information Act (FOIA) [DOJ04b] governs the release of information to individuals and organizations by the government. Sarbanes-Oxley requires public companies to appropriately manage, maintain, and control corporate information in order to ensure accountability, minimize risks, and increase corporate integrity as reported to stockholders and the public. Microsoft’s antitrust trial and Enron are two high-profile examples where the type of information covered in this act can come into play. There is also targeted legislation affecting major industries such as health care, education, and banking. The HIPAA regulations directed the U.S. Department of Health and Human Services (HHS) to establish a set of standards for health-care transactions. The purpose of these standards is to help improve the efficiency of the health-care industry by moving toward electronic transactions. In response, HHS has delivered a set of regulations and standards regarding privacy, security, and transaction details. HIPAA includes provisions ensuring the privacy of individual health records. Firms within the industry must follow strict rules in handling, transmitting, and releasing patient information contained within these records. Web Services can play a vital role in the implementation of HIPAA-compliant transaction processing systems. Educational institutions receiving funds from the U.S. Department of Education are subject to the Family Educational Rights and Privacy Act (FERPA) [ED05]. FERPA protects a student’s educational records and establishes the guidelines for the proper handling and release of that information. The Financial Modernization Act of 1999 (also known as the Gramm-LeachBliley Act) [FTC99a] requires banks to implement security programs protecting customer information and confidentiality. The Fair Credit Reporting Act [FTC02] protects the release of consumer information collected by consumer reporting agencies.
WEB SERVICES A service is a function or capability that is well-defined, self-contained, and does not depend on the context or state of other services [SOAdef04]. The World Wide Web Consortium (W3C) defines a Web Service as “a software system identified by a URI [RFC2396], whose public interfaces and bindings are defined and described
8
Enterprise Web Services Security
using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web Service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols” [W3Cdef04]. Web Services builds on open, standards-based architectures such as XML [XML00] and Simple Object Access Protocol (SOAP) [SOAP002] to assist architects and developers with the construction of loosely coupled distributed transaction systems. Web Services add protocol standards for service definition, service discovery, service invocation, and security that are grounded on a common XML base. Chapter 5 will introduce how XML and SOAP enable Web Services applications, and later chapters will expand on specific Web Services security standards. Web Services build on the Internet’s core protocols: TCP/IP and HTTP. This makes them ideal for organizations implementing new business models and ways of interacting with their customers and partners where either the Internet or an extranet built on Internet technologies is a key part of their enterprise network. B2B and health-care applications are part of a growing list of examples of places where Web Services are put to use today. Web Services security is used when it comes to protecting these new business models and to protecting the enterprise’s boundaries and assets. Defining how secure Web Services systems are designed, built, and used is the main thrust of this book. This book describes how enterprise applications can be moved to Web Services while limiting the security risks. XML XML is a standard data format for encapsulating data in both a human-readable and machine-readable text form. Normally, XML-encapsulated data is transported over the Internet using TCP/IP networking, but it can be stored in databases and transmitted by other means (such as via email). When a Web Services client wants to locate or communicate with a Web Services server (the component providing the service), it encodes its request in XML. After processing the request, the server returns its response to the client as XML as well. In addition to being useful for Web Services messages, XML is now a widely available encoding format for native database storage and query processing. SOAP Requests between Web Services components (clients and servers) use what are called remote procedure calls (RPCs). An RPC is used by one part of an application to make a request to another part that is generally running on a remote system (thus the remote part of the name). RPCs have been around for a long time and have helped distributed applications work across the Internet. One problem with the use of RPCs in the past was that they required a complex, technology-specific infrastructure that limited their use to a small number of systems. The problem
Security in the Networked World
9
with these systems was that a change to one side of the interface required changes to both sides and that changes to the infrastructure involved changes in all of the systems involved in the transaction. In other words, all of the systems needed to be “infrastructure aware” and on a common infrastructure. An example of this was the common object request broker architecture (CORBA) [OMG05] system. Each of the systems using a CORBA application had to install software and use a special interface definition language (IDL) to allow it to interact with the broker in the CORBA system. The object broker provided the glue allowing objects to transparently make requests and receive responses across an object bus. The need for this specialized middleware and client code limited the usefulness of the system when users did not have the prerequisite components. SOAP defines a means of encapsulating RPCs into XML format, making possible a distributed application that combines several types of systems. SOAP’s standards heritage allows it to overcome many of the problems earlier technologies faced: SOAP does not require special middleware or definition languages for interoperability or common infrastructure. SOAP uses the same network transport protocol that the World Wide Web uses (HTTP over TCP/IP). This means there are fewer barriers to SOAP-supported traffic as a transport mechanism because no special software components need to be installed on client systems. Since SOAP uses the same transport that Web pages use (HTTP) and is text (XML) based, it can easily pass through firewalls since those firewalls usually allow HTTP requests and do not require special filters. The Messaging Model A SOAP transaction is used in a peer-to-peer mode following a request-response model. Peer-to-peer means that two cooperating parties work together in a transaction where both agree (neither is in control or superior to the other) to the exchange. The party making the request is generally called the client and the one responding to the request is generally called the server in this model. The client builds a request by encoding their request for service into an XML form that the service provider can understand. This request usually indicates what the server is being asked to do and includes whatever parameters are necessary for the server to process the request (for example, customer ID, part numbers, and so forth). The request message is sent to the server over a SOAP TCP/IP connection. The server processes the request and sends a response with either an answer or an error message. (In some cases no immediate response is provided, but these are unusual.) This request-response model is simple and efficient, while handling a wide variety of possible service requests. Much more detail on how SOAP handles Web Services transactions will be provided in Chapter 5.
10
Enterprise Web Services Security
SECURITY CHALLENGES An enterprise can configure and use a Web Services environment in many ways. Each of them has unique security challenges that this book will address. Note that these environments are not mutually exclusive, as an organization may use one or all of them simultaneously. Threats and Risks The Web Services Interoperability Organization™ (WS-I™) identifies a number of specific types of security attacks that Web Service providers must take into consideration [WSIScenarios04]. These include: Key Attack: Weak algorithm or key length subjects message keys or algorithm to attack. Traffic Analysis: Contents may be derivable by an analysis of source, destination, size, or frequency. Host Penetration: Attack compromises host computing system. Network Penetration: Attack compromises host network. Timing: An action is derivable from the time it takes to perform the action. Covert Channels: Secret communication paths provide a route to sensitive information. Message Archives: Attacking SOAP queue compromises message traffic. Network Spoofing: Bad guy sends messages, pretending to be a good guy. Trojan Horse: Unauthorized information is hidden within a message. Virus: Message plants a virus in Web Services client or server. Tunneling: Planted software passes information along with messages. Denial of Service: Specific messages, sequence of messages, or quantity of messages cause failure or severe degradation. Repudiation: Sender denies sending a message. Details on each of these attacks are available in the referenced WS-I documentation. Most of these will be discussed in detail later in this book. Policy WS-I scenarios identify the security challenges in addressing each of these types of threats [WSIScenarios04]. Some of the challenges include
Security in the Networked World
11
Peer Identification and Authentication: The entities involved are who they claim to be. Data Origin and Authentication: The source of data received is as claimed. Data Integrity: Ability to determine data has not been changed, destroyed, or lost. Data Confidentiality: Ability to ensure data is not disclosed to unauthorized parties. Message Uniqueness: Ability to ensure a message is processed only once. An organization must weigh the risks posed by these challenges and the costs of protecting against the risks in developing its security policy. Security policy may divide infrastructure and capabilities across domains and enclaves, where each domain or enclave represents a set of owned and operated equipment and capabilities operating under a common or mutually agreed upon security policy. Unfortunately, there is no simple means of measuring such risks, as the threats depend on too many variables. For example, the value of the information, the size of the company, the nature of the users involved, the consequences of information tampering, and the cost of information disclosure all matter when deciding what risks to consider and how much protecting against those risks will cost. Internet Using the public Internet to support your business transactions clearly has serious security challenges. Because you are using a public network, you cannot control how your information travels between client and server. This leads to privacy exposure and the potential for confidential information to be exposed or tampered with. We will discuss ways the Internet can be used while minimizing the chances of these problems by using things like encryption technology. (Encryption is used to scramble information so unauthorized persons cannot understand it.) Another threat from the Internet is from hackers who attempt to compromise your systems by attacking them over your Internet connection. Most organizations restrict access to their internal systems so that attacks from the Internet do not compromise their servers or employee’s systems. Intranet An intranet is an internal network that is isolated from the Internet. Transactions over an internal network are usually assumed to be protected from access by outsiders. There still should be some attention paid to protecting transactions in these environments, as there are instances of insider attacks. Just because people are employees does not mean that they are always trustworthy. They may be deliberately
12
Enterprise Web Services Security
attacking the network or inadvertently used as part of an attack (as in viruses or network worms) The intranet provides a means of isolating such users, defending against some forms of internal attacks. Extranet An extranet is a network connection between trading partners. Usually, these are used between two unrelated companies or organizations that wish to share backend business information. For example, a company might make raw materials inventory information available to a supplier so they can replenish the supply when necessary. An extranet extends an organization’s local area network (LAN) or intranet across the Internet to interconnect with the partner’s systems. The extranet allows limited traffic to pass from the Internet to internal servers that are normally not exposed to the Internet. The unique security concern here is to allow this limited access without allowing that access to be used to compromise other internal systems. Wireless Wireless technology allows a client system to connect to a network using a radio transmitter and receiver set to replace the wires that would have carried the client’s traffic. The two distinct classes of wireless networks in use today are those used with mobile phones and those used with general-purpose computer systems. Both are used in Web Services environments and both have security concerns. A mobile phone can be a Web Services client. Usually this requires the use of a gateway, which is a system that translates a traditional Web page into a format the phone can accept. The gateway system communicates with the mobile phone using the Wireless Application Protocol (WAP) [OMA02]. The gateway extracts the important information from the Web site and translates it into a form that can be displayed on the phone (this translation is necessary if the application is going to accommodate the limited screen area on the typical mobile phone). Communications between the phone and the gateway are carried over a private network operated by the user’s mobile telephone carrier. The communications between the mobile phone and the WAP gateway are protected from exposure using methods similar to a “secure” Web site [WAPFAQ04]. The gateway connects to the ultimate server using secure Web protocols as well. These methods mean that a mobile user’s information is not easily intercepted by an attacker. However, there is a weak point because the WAP gateway system itself might be compromised. Since all application requests and responses pass through the gateway, there must be special attention paid to the gateway to ensure that it does not become a point of compromise.
Security in the Networked World
13
The other way in which wireless technology is used is for network connectivity for general purpose PCs or other computer systems. Today, most of these connections use Institute of Electrical and Electronics Engineers (IEEE) 802.11®, also known as Wi-Fi® [WiFi04]. Wi-Fi networking hardware is now available inexpensively, allowing easy mobility for laptop computers within a small area (such as inside a building). Unfortunately, there are a limited number of channels available for Wi-Fi traffic, and tools are available (such as Kismet [Kismet05]) that allow an attacker to receive wireless transmissions that are intended for another user. Unlike a wired connection that would require a physical connection to be “wiretapped,” Wi-Fi allows someone with most Wi-Fi networking cards to capture any Wi-Fi traffic in their local area without being detected. While security features are available for Wi-Fi systems, often these are not enabled. Even if they are being used, they may not provide real privacy because of flaws in their implementation. Much more information on the wireless flaws is available in a Network World Fusion article at [NW02]. Wired Equivalent Privacy (WEP) encryption does not provide real privacy and should be replaced with WPA® (Wireless Protected Access) where possible as described in the aforementioned article. Wi-Fi wireless networks have the characteristics of the Internet: they are public networks with a potential for hostile outsiders who may attempt to attack you with traffic floods or theft of information. Wireless networks have additional problems in that they are hosted on public airwaves. Attackers can use widely available software to watch all the packets that travel over a wireless LAN, compromising the privacy of the network users. We will discuss some of the ways in which wireless LANs can be secured in Chapter 8.
COUNTERMEASURES Each risk comes with one or more countermeasures to help mitigate or eliminate that risk. Many of these countermeasures have evolved through traditional network and systems security techniques. Web Services builds on and extends many of the traditional techniques for: Authentication: Determining that users and services are who they claim to be Authorization and Access Control: Determining users only have access to the services and data they are permitted to have Confidentiality: Keeping message exchanges private
14
Enterprise Web Services Security
Integrity: Ensuring that what was received was actually what was sent
WS-* FAMILY OF STANDARDS The WS-* family of standards provides a set of XML and Web Services standard formats, grammars, and message sequences for communicating policy information and addressing the various security challenges across different types of networks. This family of standards was introduced in 2002 by IBM and Microsoft as part of their overall Web Services roadmap [Roadmap02]. The roadmap introduced WSSecurity, which built on XML encryption and XML signature to create a foundation layer. It also introduced several higher-level standards including: WS-Policy: Defines the syntax and grammar for communicating policies as a set of assertions WS-Security: Defines the syntax and grammar for communicating security tokens, digital signatures, and message encryption information WS-Trust: Defines the syntax and grammar for establishing trust relationships and communicating with third-party trust brokers WS-SecureConversation: Improves the efficiency of exchanges by defining a way to exchange multiple messages within a single context or session WS-Federation: Lays the foundation for creating federated trust relationships across multiple domains and enclaves Since the initial roadmap was introduced, a number of supporting standards and standards proposals have been introduced. These include: WS-SecurityPolicy: Builds on WS-Policy, adding security-specific assertion elements for communicating security token, integrity, and confidentiality constraints. WS-PolicyAttachment: Defines the mechanisms for associating policies with a subject inherently, as part of its intrinsic definition, or through either its associated Web Services Description Language (WSDL) or Universal Description, Discovery, and Integration (UDDI) description. XKMS: The XML key management specification (XKMS) builds on XML signature and XML encryption, providing a service for registering and distributing public keys for those standards.
Security in the Networked World
15
SAML: The Security Assertion Markup Language (SAML) defines a framework for exchanging authentication and authorization information across domains in the form of assertions rather than identities or traditional security tokens. XACML: The eXtensible Access Control Markup Language (XACML) defines a hierarchical model for defining and evaluating policies.
VIRTUAL DOMAIN MODEL FOR WEB SERVICES SECURITY The WS-* standards each address a particular aspect of the overall security problem. Most build on traditional security methods and techniques, while others introduce new ways of approaching some of security’s more daunting challenges. Viewing them in isolation or in a piecemeal manner can leave you overwhelmed or with a false sense of security. One of the major purposes of this book is to explain a set of methods for building flexible networks and Web Services based on the aforementioned standards for enterprise entities to use while cooperating in a business relationship. These networks are called virtual domains and are built on the concepts of trust and trust relationships, where trust is the assured reliance the parties can have on one another and each other’s ability to perform a specific function. Security Domains The virtual domain model is a key concept discussed in this book. The model is built on the concept of a security domain, which is a collection of systems that have a single security policy and a single set of security controls. The domain may be physical, where the infrastructure and all of its components belong to a single organization, or logical, where the infrastructures are interconnected through bilateral agreement. Often a security domain is a single enterprise, but smaller or larger domains may exist. For example, an accounting department in a company may be a domain unto itself when working with accounting or payroll systems, but part of a second, larger security domain that covers the entire enterprise when dealing with any other systems. The virtual part of the model comes from its dynamics. A domain is referred to as “virtual” because it is organized around a particular business need, comes into existence when necessary, and then disappears when it is no longer needed.
16
Enterprise Web Services Security
Enclaves An enclave is an isolated component of a larger network or domain. The enclave is generally isolated either to more strictly protect the data it contains or to protect the larger network from users accessing it or attacks against the enclave. The enclave will frequently use different protection mechanisms than those enforced on the larger network. Trust Relationships When they wish to share information, a set of security domains mutually agree to enter into trust relationships with each other. In these relationships the domains agree to trust the security mechanisms, services, and data each provides to the extent necessary to do business together. Several types of trust relationships exist to allow flexible arrangements between domains. We will describe many examples of different types of trust domains and trust relationships in Chapter 13. The Model Different models can be used to define the trust relationships between security domains. Hierarchical relationships are traditionally used, but the virtual domain model allows for far more flexibility in how trust relationships are used. The virtual domain model projects the security policy for the domain or enclave hosting a Web Service across the physical and logical domains and enclaves supporting its clients and supporting services in order to determine The policy that must be met The capabilities that are currently available to meet that policy The capabilities that can be made available The equivalents that can be found We will look at how this model can be used in Microsoft’s .NET environment, Sun’s J2EE™ (Java 2 Enterprise Edition) environment, and wireless environments. We will build on the virtual domain model to develop a seven-step process for working through the deployment and security questions that frequently arise in developing and deploying enterprise Web Services in a highly interconnected environment.
Security in the Networked World
17
SUMMARY In this chapter we introduced the scope and purpose of this book and some of the business drivers that are fueling the move to the Internet and to Web Services. We looked at the rationale for moving to standards-based, XML-compliant Web Services, the benefits and risks this move introduces, and the Web Services standards to help address these risks. We will explore these topics in far greater detail in later sections of the book. We also briefly introduced the concepts of security domains and the concept of a virtual domain model for Web Services that will help us introduce a coherent, systematic approach to addressing information security within a Web Services context that we will discuss in detail later in this book.
REFERENCES [CMS05] Centers for Medicare and Medicaid Services, “Health Insurance Portability and Accountability Act of 1996.” Available online at http://www. cms.hhs.gov/hipaa/. [Daurat05] Daurat, Cecile, “Time Warner Reports Loss of Personal Data on 600,000 Employees,” Washington Post Online, May 3, 2005. Available online at http://www.washingtonpost.com/wp-dyn/content/article/2005/05/02/ AR2005050201528.html. [DOJ04] U.S. Department of Justice, “The Privacy Act of 1974.” Available online at http://www.usdoj.gov/foia/privstat.htm. [DOJ04a] U.S. Department of Justice, “Overview of the Privacy Act of 1974, 2004 Edition.” Available online at http://www.usdoj.gov/04foia/1974compmatch.htm. [DOJ04b] U.S. Department of Justice, “Freedom of Information Act (FOIA).” Available online at http://www.usdoj.gov/04foia/index.html. [ED05] U.S. Department of Education, “Family Educational Rights and Privacy Act (FERPA).” Available online at http://www.ed.gov/policy/gen/guid/fpco/ferpa/ index.html. [FTC02] Federal Trade Commission, “The Fair Credit Reporting Act.” Available online at http://www.ftc.gov/os/statutes/fcra.htm. [FTC04] Federal Trade Commission, “Federal Trade Commission Facts for Businesses and Consumers.” Available online at http://www.ftc.gov/ftc/business. htm. and http://www.ftc.gov/ftc/consumer.htm. [FTC99] Federal Trade Commission, “Federal Trade Commission Facts for Businesses, The Children’s Online Privacy Protection Rule.” Available online at http://www.ftc.gov/bcp/conline/pubs/buspubs/coppa.htm, November 1999. [FTC99a] Federal Trade Commission, “Financial Privacy: The Gramm-LeachBliley Act.” Available online at http://www.ftc.gov/privacy/glbact/.
18
Enterprise Web Services Security
[Gilder93] Gilder, George, “Metcalf’s Law and Legacy,” Forbes ASAP, September 13, 1993. Available online at http://www.seas.upenn.edu/~gaj1/metgg.html. [Kismet05] Kismet Forum, “What is Kismet?” Available online at http://www. kismetwireless.net/. [NW02] Network World, “What’s Wrong With WEP.” Available online at http:// www.networkworld.com/research/2002/0909wepprimer.html. September 9, 2002. [OMA02] Open Mobile Alliance, “WAP Forum Specifications.” Available online at http://www.wapforum.org/what/technical.htm. [OMG05] Object Management Group, “CORBA FAQ.” Available online at http://www.omg.org/gettingstarted/corbafaq.htm. [RFC2396] Berners-Lee, T., et al.,“Uniform Resource Identifiers (URI): Generic Syntax.” Available online at http://www.ietf.org/rfc/rfc2396.txt, August 1998. [Roadmap02] IBM Corporation and Microsoft Corporation, “Security in a Web Services World: A Proposed Architecture and Roadmap, A Joint White Paper from IBM Corporation and Microsoft Corporation,” Version 1.0. Available online at http://www-106.ibm.com/developerworks/webservices/library/wssecmap, April 7, 2002. [SEC05] U.S. Securities and Exchange Commission, “Spotlight on Sarbanes-Oxley Rulemaking and Reports.” Available online at http://www.sec.gov/spotlight/ sarbanes-oxley.htm. [SOAdef04] “Service Oriented Architecture (SOA) Definition.” Available online at http://www.service-architecture.com/web-services/articles/service-oriented_ architecture_soa_definition.html. [SOAP002] Mitra, Nilo, “SOAP Version 1.2 Part 0: Primer.” Available online at http://www.w3.org/tr/SOAP12-part0, June 26, 2002. [Tapscott00] Tapscott, Don, et al., Digital Capital: Harnessing the Power of Business Webs, Harvard Business School Press, 2000. [W3Cdef04] Austin, Daniel, et al., “Web Services Architecture Requirements W3C Working Group Note 11 February 2004.” Available online at http://www. w3.org/TR/2004/NOTE-wsa-reqs-20040211. [WAPFAQ04] The Wireless FAQ, “How Secure is WAP with SSL and WTLS?” Available online at http://www.thewirelessfaq.com/9.4.asp. [WiFi04] Wi-Fi Alliance, “Wi-Fi Overview.” Available online at http://www. wi-fi.com/OpenSection/why_Wi-Fi.asp?TID=2. [WSIScenarios04] Schwarz, Jerry, et al., “WS-I Security Scenarios, Working Group Draft, 2004/04/16.” Available online at: http://www.ws-i.org/Profiles/ BasicSecurity/SecurityScenarios-1.0.pdf. [XML00] Internet Engineering Task Force, “Extensible Markup Language (XML) 1.0 (Second Edition).” Available online at http://www.w3.org/tr/rec-xml, October 6, 2000.
2
Threats and Attacks
In This Chapter Threats, Vulnerabilities, and Countermeasures Ensuring Reliability Vandalism and Sabotage Denial of Service Privacy and Confidentiality Breaches Data Integrity Violations Man-in-the-Middle Attacks Spoofing Attacks Mobile-Code Threats Fraud Special Considerations for Web Services Environments Summary References
o begin to understand the need for information security, you first need to understand the ways in which your systems can be attacked. Threats and attacks are not new to Web Services. Many of them predate networks and computers, some going back to even before Caesar’s time. There are well-understood terms used to describe these attacks and the defenses that you can mount against them. We often confuse the newness of the technology, in this case Web Services, with the newness of the concepts, in this case security, and fail to leverage the history of the thinking and capabilities that can be brought to bear. In this chapter, we will begin to introduce the lexicon of information security terms to help form the basis for later material as we begin to look at how to provide secure Web Services.
T
19
20
Enterprise Web Services Security
THREATS, VULNERABILITIES, AND COUNTERMEASURES To define computer security, we first need to define what it is we mean by secure. One definition of a secure system is a system that always does just what you want and nothing more. To meet this security goal, the system must be reliable and remain reliable while resisting attempts by attackers to compromise its reliability. In one sense, we haven’t really defined secure well because the definition above simply replaced the term secure with the term reliable. We emphasize reliability because that term has a better-understood meaning: the system can’t be exploited by attackers to do things that we don’t want because it only does what we expect. A secure system has no unintended side effects that an attacker can attempt to exploit. That’s the reason for building a secure system: it is reliable and dependable, only doing what we want it to do. Unfortunately, building a system that reliably only does what we want it to do and nothing else has proven to be difficult. (Within security circles there is the concept of an unconditionally secure system—one that remains secure even when the attacker has unlimited time and computing resources for use in the attack. As we will discuss in Chapter 10, when we turn our attention to encryption algorithms, some perfectly secure mechanisms today will become vulnerable in the future because of Moore’s law—processing speed doubles roughly every 18 months [Moore65].) We need, therefore, to describe how we can secure a system by ensuring its reliability. To make a system reliable, we consider the system that we are trying to protect as a whole (the hardware, software, network, etc.) and try to determine ways that the system can be protected against attacks. In Chapter 3 we will describe the goals of that process. In this chapter we will be defining the ways in which systems can be attacked and how we can protect against those attacks. Compromise occurs when the efforts to ensure the reliability of a system fail. The consequence of the compromise is that our ability to trust the system is lost. The compromise may be the result of an attack or the exploitation of a vulnerability within the system or one of its underlying components. The result of the compromise is some degree of loss of reliability resulting from the loss of system integrity. The system no longer does exactly what it is expected to do. A threat is the possibility of a set of circumstances that may lead to compromise, that is, damage, loss, or harm to a system or its users. (We use the term loss in a generalized sense. A loss could be diminished value, restricted availability including theft, or reduced usability.) It’s easy to describe a threat that everyone understands: a schoolyard bully poses a threat to all the students in the playground (or at least the ones weaker than the bully). An attack occurs when the threat agent decides to attempt to damage a system or its users. To continue the analogy above, the attack happens when the bully
Threats and Attacks
21
chooses a victim and pursues him. Put another way, a threat expresses the potential for harm, and an attack actually causes the harm. You can’t have an attack without some threat existing that enables that attack. A vulnerability is a characteristic of or a weakness in a system that makes it subject to loss when an attack is mounted. The children on the schoolyard above are clearly vulnerable to injury from the bully’s attacks. The distinction between threats and vulnerabilities is that the vulnerability is an inherent characteristic of the system (the vulnerability is always there), while a threat is only realized if someone takes action. You can have undiscovered vulnerabilities; there is no threat until the vulnerability is discovered. One protects a system by use of countermeasures. A countermeasure puts controls in place to protect vulnerable components from attacks. Countermeasures are combinations of user actions, devices, procedures, or other methods that reduce or eliminate vulnerabilities. A schoolyard monitor could be hired as a countermeasure against our bully. Countermeasures can be technical (firewalls, intrusion detection systems, access control badges, etc.). Countermeasures can also be physical (or part of the system environment). For example, you can protect a site from intruders by the use of guards. We will continue to develop these definitions in Chapter 3, where we will explain how secure system designs help minimize the risk of successful attacks. For now, we concentrate on the source of threats and attacks. We continue by discussing the concept of ensuring reliability and some of the ways in which threats and attacks can be mounted against a system that you would like to secure.
ENSURING RELIABILITY Before we begin discussing the ways systems can be attacked, we need to define a model that describes how the systems are built and interconnected and how we can ensure reliability within those systems. Our model assumes that we have a client who wishes to perform some operation that requires them to communicate with a server somewhere in order to execute a business transaction. Figure 2.1 shows the basic layout of our model. In our model, software running on the client’s computer communicates with a partner system that implements the transaction. A client may need to communicate with multiple servers (server 1 through server n in Figure 2.1) in order to perform a transaction. The clients communicate with the servers over an unprotected Internet connection. In this model, we need to ensure the reliability of three components—the network, the client, and the server—for the overall system to be considered secure.
22
Enterprise Web Services Security
Server System 1
Client System
Internet or Private Network
Server System 2
Server System n
FIGURE 2.1 Networked client-server system model.
Ensuring the reliability of the client and servers means ensuring they are configured correctly, that they only contain the software they are supposed to contain and that that software is also configured correctly, and that they only expose the hardware connections and services they need. In effect, you must ensure that both the client and the server are appropriately “locked down.” We will get into the details of what it means to lock down a system in Chapter 8. As we will discuss throughout this book, locking down the components only at the network or system level is insufficient in a Web Services environment. Subcomponents such as the HyperText Transport Protocol (HTTP) server, applications server, and database server must also be appropriately locked down. In a Web Services environment where you are operating across the Internet, one caveat to this is that you will generally have far more control over the servers than you will over the clients in either business to business or business to comsumer types of implementations. Given that you have taken appropriate steps to ensure that the client and servers are reliable, or secure, the next question is the network. While the Internet provides the wide-area connectivity that allows for distributed transactions, it is important to remember that the network is not “run” by any one individual, company, or organization. It is a loosely connected collection of cooperating networks. The problem with this is that a client’s requests are carried over a network that the client and their servers do not control. Most companies assume that the companies supporting the Internet backbone are trustworthy (that is, that they’re not trying to watch what clients are doing in hopes of some financial gain).
Threats and Attacks
23
Another problem with our model is that the Internet provides a communications pipe that has no service-level guarantees. This means the client and server need to work together to add whatever reliability is necessary for them to use the Internet for their transaction. This means extra work for the application developers. For example, the client may send a message to a server and not expect a response. This is called fire-and-forget. In this scenario, the client has no guarantee the server actually received the message. In order to have such a guarantee, the client must expect and receive some sort of acknowledgement from the server that it at least received the message. This two-way model is the foundation of the basic request-response model that Web Services builds upon. Another aspect of Internet-based transaction systems is that the Internet provides only very basic services. The Internet provides TCP/IP, which is a simple packet transmission service Internet Protocol (IP) with a layered Transmission Control Protocol, (TCP), which provides reliable data transmission. The IP layer provides a simple unreliable packet transmission system for what are called datagrams. IP datagrams are collections of bits that are routed across the network by IP (and lower layers) until they eventually reach their destination. It’s important to understand that there is no guarantee that the packets will ever reach their destination. IP provides a best-effort service only and does not guarantee that datagrams will arrive at all or that they will arrive in the order in which they are transmitted. The TCP layer builds a reliable layer on top of IP. TCP data is guaranteed to arrive in the order in which the data was sent. TCP also provides error detection and correction for packets damaged or lost in transmission. While TCP provides a reliable transmission method, all that it does is move byte streams from end to end. TCP doesn’t care what the underlying data means to the client and server. Before the client and server can communicate in some useful, application-specific means, they must agree on a protocol for that communication. A protocol is an agreed-upon interpretation of the meaning of messages sent over the communication path created by TCP. A real-world example of this is a poker game. There is a set of well-defined steps that take place in the game, where the cards are dealt and then each player in turn decides what to bet and announces that decision. A game would not work if players bet out of order or declared their bets. The rules that dictate how the game will be played define the protocol. Before the client and servers in Figure 2.1 can communicate, some protocol must be designed to allow those systems to communicate. Protocols are generally application specific. One advantage of a Web Services environment is that it allows the protocol design details to be performed once and reused. This is the advantage of the Web Services protocols that we will explain later in this book: the Web Services layers allow systems to take advantage of the Internet without having to be designed specifically for networked communications.
24
Enterprise Web Services Security
The protocol for a particular service also defines the semantics (or meaning) of the messages transferred between the client and the server. Most Web Services applications follow a request-response protocol where a client sends a request and the server sends back a response. More complex protocols are also used; for example, where reliable transactions must occur over multiple systems, the protocol is required to implement some form of transaction reliability. This may entail very complex transactional semantics. One advantage of Web Services is that the environment can provide some of these reliability guarantees without adding complexity to the application software. The problem with widely available communications is that the network is very large. The fact that Web Services makes it easier to communicate between clients and servers over the Internet does not eliminate the threats that arise when a system uses the Internet for connectivity. Connecting to the Internet brings a greatly increased level of exposure to potential security breaches in the form of threats and attacks, as described below.
VANDALISM AND SABOTAGE Vandalism and sabotage are both instances where an individual or a group attempts to make unauthorized modifications to a system being attacked. Host penetration, network penetration, and viruses are all forms of vandalism and sabotage attacks under the WS-I scenarios introduced in Chapter 1. These attacks are designed to erode user confidence in the integrity of the systems being attacked. Often these involve modification of the content of a Web server in order to embarrass the owner of the Web site. Some very widely publicized attacks against Web sites include large commercial enterprises and government Web sites. At one point, over 100 Web site defacements were being tracked every day on sites such as the mirror at www.attrition.org. The distinction between vandalism and sabotage is imprecise, but one often speaks of attacks against competitors as being sabotage; most Web site defacements are simple acts of vandalism against weakly protected targets. The threat of vandalism is possibly higher (especially for Web sites) because there are so many more threat agents out on the Internet that deface Web sites just so they can brag about the systems they have successfully attacked. You can sometimes identify who the potential saboteurs are but you can’t identify potential vandals. Vandalism and sabotage usually involve exploitation of weaknesses of the sites being attacked. The weaknesses may appear at the network, system, or component level. These weaknesses may be due to flaws (bugs) in the Web server application or its underlying operating system or due to weak administrative controls. A control is something in a system (a countermeasure of some kind) that attempts to resist
Threats and Attacks
25
attacks. Administrative controls are configuration settings or environmental mechanisms (such as locks) that allow systems to resist attacks. An easily guessed administrative password is an example of a weak control. Unfortunately, systems are frequently penetrated because someone uses a trivial password or the default created by the vendor for the administrative account. Software bugs are frequently exploited during system intrusions. These bugs may be in your Web Services components or in the underlying systems components. Once programs are written to exploit software flaws, it is often trivially easy for an unsophisticated attacker to run the attack against a large number of systems until a system is found that does not have the patch installed that fixes the flaw. These unsophisticated attackers are called script-kiddies because they use a defined set of operations (a script) that allows them to break into a system without having any real understanding of what the script does. Because of this, the people who actually create the original exploits deride them as children. The kiddie is like any other vandal, as it takes no real skill to attack systems because it’s easier to destroy than it is to create, and it’s easier to attack than it is to defend. The ease of use of some attack programs means there are potentially a large number of attackers. Fortunately, some exploits are deliberately broken when released. In these cases, the author of the exploit program changes it so it no longer works properly, hoping to frustrate the kiddies. It takes some knowledge to turn these nonfunctional exploits into something that works. This tends to discourage the more unsophisticated attackers, but not for very long, as eventually someone will release a working exploit script. Again, bragging rights in the community of users that share exploit programs encourages people to share their tools with others, which encourages the faster spread of the exploit tool. There are some distinctions made regarding so-called hackers within the community of researchers that look for vulnerabilities. For example, legitimate companies look for security vulnerabilities and report them to the vendors to be corrected, waiting for a patch to be released before they publicize the flaw. These are often called “white-hat” hackers. On the other hand, so-called “black-hat” hackers look for vulnerabilities and keep their existence secret for as long as they can so they can build an exploit and attack as many systems as possible. The reality, however, is that both white-hat and black-hat hackers still concentrate on breaking into systems and thereby contribute to the maintenance headache that system administrators must bear. Even if administrators try to keep their systems patched, the math works in the attacker’s favor. If, for example, 99.9% of a widely used system are patched and 500,000 of them are deployed, 500 systems are open to attack. The fast spread of network worms (which often are written to exploit unpatched systems) demonstrates that some percentage of systems receive almost no maintenance; otherwise, these worms could not spread because patched systems are not vulnerable.
26
Enterprise Web Services Security
Vandalism is more common than sabotage, as there are more potential attackers, particularly given the widespread availability of automated attack tools. Sabotage is much less frequent, as any organization has a limited number of people who are interested in attacking it. Unfortunately, attackers bent on sabotage may have more resources available to them when mounting their attacks. A system’s defenders must take into account both forms of attacks, including those attacking simply for ego gratification as well as attackers bent on disrupting a company’s ability to do business.
DENIAL OF SERVICE Denial of service (DoS) attacks target the availability of a service. These too can occur at many different levels. It really doesn’t matter to attackers whether they are tying up the network interface to a service, the underlying operating system supporting the service, or the service itself. The result is the same. The service cannot get the resources it needs to support requests from legitimate clients. Web sites are frequent targets of DoS attacks against the site’s Web server that aim to make the site unavailable. DoS attacks can be implemented by several different means. One type of DoS attack exploits a flaw that causes the service or server to crash, making it unable to service user requests. Another form of DoS involves generating service requests to a Web server at such a high rate that the server is unable to respond to legitimate user requests. The standard TCP stack used on several systems can be tied up by handling even a low volume of pending service requests. This allows even an attacker using a low-bandwidth Internet connection to disrupt a site. DoS attacks can also be physical attacks such as disabling power to a site or stealing the servers hosting the site (surprisingly, companies often do not consider this threat when making contingency plans). Most of these attacks use technical means rather than physical attacks. One form of DoS attack is a distributed denial of service (DDoS) attack. In a DDoS, an attacker controls an army of compromised systems spread across the Internet. The attacker uses software installed on user computers that does nothing until it is awakened. The attacker then sends commands to those systems to attack a target. These systems are called “zombies” because the attack software is dormant until “raised from the dead” by the attacker’s command. The zombie machines direct a stream of legitimate-looking requests to the system under attack, keeping it so busy responding to zombie requests that it cannot respond to legitimate user requests. While a single system attempting a DoS attack can be easily blocked at a network level, zombie armies are not so easily blocked, as thousands of hosts may be involved. Often systems are taken over and become zombies through the use of software that is distributed with email-borne network worms or viruses that install zombie controller software unknown to the system’s legitimate owner.
Threats and Attacks
27
Zombies are now being used to flood Internet-based discussion boards and Web logs (blogs) by flooding them with postings of advertisements. Just a few hundred ad-posting spam zombies are enough to completely overwhelm a discussion board with spam [MLabs04]. Tracking down the owners to stop their systems from participating in future attacks is a very time consuming task; consequently, most compromised systems remain undetected and available for future attacks. Zombie masters turn other people’s systems into money-making ventures by gathering armies of systems under their control and selling those resources for use in attacks against their customers’ competitors or as resources to be used in spam floods. As described in [MLabs04], these systems are being sold for the purposes of spamming. Apparently there is a market for zombies; one article describes people selling “armies” of zombied PCs for a reasonable price [Achohido04]. Physical DoS attacks against networks, servers, and mains poweries are far less frequent than network DoS attacks. In many cases these failures are unintended side effects when the thief is just stealing an asset he plans to sell, not trying to bring down the Web site. A large percentage of these attacks are not deliberately targeted against the organization per se: they are attacks against the organization’s assets by theft of those assets.
PRIVACY AND CONFIDENTIALITY BREACHES Another threat against servers involves attempts to bypass protections for information stored on those servers. Covert channels, message archive attacks, and Trojan horses are all attacks under the WS-I scenarios where the objective is to stealthily remove data through a surreptitious channel. These attacks attempt to expose information that the server is expected to protect from such accesses (for example, credit card information, customer-identifying information such as name and address databases, and so forth). These confidentiality breaches may provide information that an attacker can use to place unauthorized credit card orders, mount identity theft attacks, and so forth. Other less damaging (but still significant) attacks include exposure of user email addresses to spammers. Some privacy breaches have been caused by errors in the Web site software allowing users to see data intended for other users. [EPIC97, CNET97]. In one instance, the agency responsible for this security breach was forced to withdraw the site from the Internet after negative publicity made the site unusable. Confidentiality and privacy threats have become more effective as companies move more and more of their operations onto the Web. In some cases, the rush to automate business processes leads to incomplete consideration of the privacy aspects. Also, marketers see value in the information being collected online and want to take advantage of this to improve their targeting of potential customers. So much
28
Enterprise Web Services Security
information is gathered about us online that marketers find valuable (purchasing habits, address details, phone numbers, etc.) that it is becoming an increasingly attractive target. The reach of the Internet makes it easier for the databases containing this information to be combined to discover even more about us. Not only are companies collecting more information, but people are increasingly willing to supply that information. People willingly give up information on themselves for reasons that in hindsight makes little sense. A common example of this is the “warranty registration” cards shipped with many products. People fill these in with little consideration of the value of the information they are disclosing. Some cards ask for the number of people in a household, their ages, family income levels, education levels, and so forth—information that has no bearing on the warranty for the newly purchased toaster. Marketers love to get this information, as it lets them build detailed databases of information on individuals, which is then sold for reasons having nothing to do with the original product. Some companies sell products at a loss simply because it allows them to collect current, accurate address information. Simson Garfinkel’s Database Nation: The Death of Privacy in the 21st Century [Garfinkel00] gives one view of just how far the concern for user privacy extends. Some information must be kept secret from others. Your credit card numbers are an obvious example of this. Another easily understood example is medical information. Allowing this information to be divulged unnecessarily would be a clear case of a privacy breach. Information protection does not exist just to ensure user privacy, however. Confidentiality concerns extend to information that may not be personally identifying. For example, a company may wish to keep the names of its customers secret to avoid competition. Exposure of this information isn’t really a privacy violation, but it does expose information that you expect the system to keep confidential. Businesses have a great deal of information that they consider to be confidential: pricing and cost information, profit levels, and so forth. It is easy to convince a company to protect their confidential data because there are clear benefits. Confidentiality protections can take many different forms. Table 2.1 shows some of these forms. TABLE 2.1 Confidentiality Protection Mechanisms Mechanism
Purpose
System Isolation
Restrict physical and network access to the system hosting confidential data
Transport Data Protection
Protect data in transit over untrusted networks (e.g., the Internet)
Storage Data Protection
Protect saved database records
Threats and Attacks
29
System isolation is a very effective mechanism for protecting information. The sensitive system is isolated (for example, by using a firewall) so that that system cannot be accessed by attackers. The only access permitted to the isolated system is from the service that answers user queries. While this form of protection can be very effective, any temptation to allow even limited connectivity to the system thus protected must be carefully considered, as such connectivity may lead to someone being able to bypass the assumed protections. Information in transit across untrusted networks (such as the Internet) is often protected by the use of encrypted protocols, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). SSL and TLS encryption, which will be discussed in Chapter 10, protect the information from disclosure while it is in transit over the Internet. Web Services protocols can take advantage of SSL and TLS by using them to provide easily implemented privacy and integrity protections. SSL and TLS also can provide user authentication using public key infrastructure (PKI) certificates, as will be discussed later. Bulk data encryption may be used for sensitive systems to avoid disclosure of corporate data. One example of this is the use of hard-drive encryption software for laptop computers. This software limits the exposure when a corporate officer’s laptop is lost or stolen.
DATA INTEGRITY VIOLATIONS The integrity of a set of data refers to how well it is protected against unauthorized modifications. In other words, we ensure that the information has not been tampered with by using integrity protections. High-integrity information or data comes from a trustworthy source and is known to be unmodified after it was delivered from the trustworthy source. Key attack is one form of data integrity attack under the WS-I scenarios because if the attacker can steal the encryption key protecting the data, they can mask their changes to the data. Integrity checks are used to validate transactions. A business ensures the integrity of its business records by double-checking calculations. If an accurate starting balance is known, the ending balance can be verified by adding income and subtracting payments. As long as the balance calculated this way agrees with the running balance, the balance is verified. In a Web Services environment, these types of checks often become the responsibility of the Web Service supporting the transaction. For electronic commerce systems, we usually try to protect the transaction information from unauthorized changes rather than simply detect the changes. This is done to minimize the chance that invalid data can spread, corrupting other parts of the business database. However, there are cases where all we can do is to detect and report a tampering incident.
30
Enterprise Web Services Security
Web Services systems are usually concerned with the integrity of user-supplied data; is it the same information that the user or the system generated, or has it been changed at some point? An example of such an attack involves the use of online shopping carts. Some systems use cookies (data items stored by the user’s browser) to maintain order information. This allows an attacker to modify the cookie values to alter prices of items before placing an order, potentially allowing them to buy a product at well below the normal price. Protection of user details should incorporate both confidentiality protections (as discussed earlier in this chapter) as well as integrity protections. The SSL and TLS protocols used for secure Web connections (https: uniform resource identifiers) provide both confidentiality and integrity protection for data transferred over the SSL connection. Integrity attacks can be detected in many ways. Cryptographic checksums, which will be described in Chapter 10, can be stored with data to detect tampering. Alternatively, information can be stored in multiple places and then compared to verify that it is correct. Independent verification checks or multiple verification checks as used in business general ledger systems also provide a degree of integrity protection.
MAN-IN-THE-MIDDLE ATTACKS A man-in-the-middle attack is mounted against a communications path between partners involved in some form of transaction. Figure 2.2 shows how these attacks are performed. Two cooperating parties, Alice and Bob, are attempting to share information of some sort. For the purposes of this discussion, let’s assume that Alice is buying something from Bob’s Web site. Charlie manages to interpose himself between Alice and Bob so that all the messages between them go through him. Charlie is thus able to modify Alice’s order so it is delivered to Charlie’s address, not Alice’s.
Expected Communications Path Alice
Alice
Bob
Charlie Actual Communications Path
FIGURE 2.2 Man-in-the-middle attacks.
Bob
Threats and Attacks
31
Neither Alice nor Bob are able to detect Charlie is intercepting their communications unless they discover that the package was misdirected and delivered to Charlie. Charlie can manipulate the transaction to his benefit in other ways that are less likely to be detected. He can double Bob’s price and tell Alice to pay him rather than Bob. Charlie skims half the money off the top and sends the remainder to Bob. Unless Alice and Bob communicate the price outside Charlie’s control, they’ll never know they’ve been defrauded. Charlie may also attempt to expose confidential information rather than execute a fraudulent transaction. Alice and Bob may never know how their confidential information is being made public unless someone detects and exposes Charlie’s actions. A more serious example of man-in-the-middle attacks is the case of communications between military commanders. If a general sends an order to a major to have troops move to some position, the man-in-the-middle can send that unit to some other location. The enemy then knows where there is a hole in the defenses, making it more likely that they can break through the defensive line. Simply knowing the details of troop deployments without tampering with them is still a serious breach. Using protocols that are designed to resist such attacks mitigates man-in-themiddle attacks. Often this resistance uses cryptographic protocols that involve a secret known only to the parties that wish to communicate. Another way is by use of trusted third parties that can vouch for the identity of someone you wish to communicate with. SSL uses trusted third parties who sign PKI certificates that provide some level of proof of the identity of the site you are connected to or communicating with. Physically secured networks can also be used to limit the chance of a successful man-in-the-middle attack.
SPOOFING ATTACKS Attacks where an entity (a person or a networked computer system) masquerades as someone or something else are called spoofing attacks in the WS-I scenarios. Spoofing attacks are successful when one entity in a transaction trusts another entity. If an attacker knows about the trust, they can exploit it by masquerading as the trusted party. Spoofing over network services is possible because systems rely upon information for authenticating their users. If that authentication information is weakly protected, an attacker can steal a copy and generate traffic that uses the stolen identity information from an authorized user. Some spoofing attacks use replays, where the attacker records a valid transaction and retransmits it (sends it again). Note that this kind of attack is successful even if the transaction details are encrypted since the attacker does not need to understand the message format or
32
Enterprise Web Services Security
contents to be able to retransmit the transaction. A common form of spoofing attacks is to spoof the Internet IP address of another host. It is very easy for a system to generate traffic that appears to come from another IP address. If part of the protections for a network or a service depends upon IP addresses for making security decisions, an attacker can generate traffic that appears to come from a trusted IP address, thus potentially bypassing firewall or application protections. Systems must be designed to recognize that IP address information is of limited reliability. This means some other form of authentication method must be used to identify network systems (hosts). Replay-based spoofing attacks can be mitigated by use of message sequence numbers. In this case, each message has a unique sequence number that is increased for each message sent. The receiver discards any message that is out of sequence, disallowing replays. It is possible for an attacker to simply change the sequence number in a message to make the replayed copy appear to be in correct sequence. Protocols can protect against this by use of signatures or encryption to detect the tampered message. Authentication spoofing attacks may be mitigated by the use of trustworthy identity credentials. IP addresses are not trustworthy and should be replaced with other identity assertions. Examples of these will be described in Chapter 10. The most common form of user authentication is the reusable password. If passwords must be used, it is important that users be educated to use passwords that are difficult to guess and to change their passwords frequently. The use of one-time passwords or tokens should be considered as a replacement for weak passwords, as users historically have been shown to not be willing to use strong password controls. Unfortunately, users resist the introduction of one-time password systems and token systems. Helping users accept their responsibility to help protect their information can assist in the introduction of strong authentication systems. The attacks against LexisNexis where hackers took information on over 310,000 U.S. citizens using stolen passwords is an example of a spoofing attack [Enouf05]. In this case, hackers were able to fraudulently bypass LexisNexis’ security mechanisms to steal addresses and Social Security numbers. These types of attacks can be very difficult to detect because the attacker may, for all intents and purposes, appear as an authorized user.
MOBILE-CODE THREATS Mobile code is software that is delivered from one system on the network and is installed on a target system. Many types of benign mobile code are in use today. Java™ applets and ActiveX® controls used on Web pages are forms of mobile code. Java
Threats and Attacks
33
code can also be downloaded to mobile phones, often in the form of game programs to run on the phone. Web Services add an interesting twist to this issue because mobile code can be downloaded in encoded form (as we will discuss in Chapter 7, Web Services uses something called Base-64 encoding to transform binary data into text). In a simple Web site, the user’s browser displays text and graphics downloaded from a Web server. That Web server is responsible for executing software to generate the content of those pages. In contrast, a mobile code agent is downloaded from the target Web server and installed onto the user’s system. Because this code runs on the target user’s machine, usually with the rights and permissions granted to that user, rather than running on some remote server, the user’s system is not protected from hostile intent on the part of the mobile code author. In other words, anything that user is permitted to do, the mobile code can do. While Java attempts to limit what the applet can do (by use of a restricted environment called a sandbox, which will be discussed in detail in Chapter 8), there have been flaws in those restrictions. If users aren’t careful about what they do, they can unintentionally allow hostile mobile code to install itself on their machines. Such dangerous actions include anything that allows a hostile application to execute. A common example of this is double-clicking on unknown attachments or following Web links to hostile sites. A spyware program that asks the user for permission to install itself is still a spyware application. Several commonly recognized forms of hostile mobile code are: Trojan Horse: A program that appears to perform some useful function that includes some hidden code that performs some unexpected function. Virus: A piece of program code that attaches itself to other programs and propagates with the file it is attached to. Worm: A program that propagates by copying itself across a network. Spyware: A form of Trojan horse that allows an attacker to control what Web sites users see. It may also gather information on user habits and report them to its controller Zombie: A system infected with a control program that an attacker can later use in DoS and other attacks. While viruses and worms are still frequently seen, spyware is quickly becoming the most frequent cause of user disruption that uses mobile code. Spyware tries to hide its presence so it will not be deleted from the user’s machine while attempting to control the user’s system. Badly written spyware is frequently a cause of system instability. One particularly hostile form of spyware is the zombies that are being used by spammers to bypass spam blocking by allowing the spammers use of tens of thousands of compromised systems spread all around the world.
34
Enterprise Web Services Security
Mitigation of mobile code attacks relies on several precautions. Some of those are precautions are: Educating users to not run software from untrusted sources Maintaining system patches to avoid worm propagation Running anitvirus products and keep them up to date Running spyware detection programs Unfortunately, the user is the weakest link in this chain. Almost all spyware is installed because a user goes to a Web site that installs the program on his machine, often after asking the user for permission. Of course, mobile code is not always hostile. However, a system that is designed to use mobile code must be prepared to accept user resistance because of the reputation that Java and ActiveX have gained.
FRAUD Fraud occurs when an individual makes a false or exaggerated statement or claim with the expectation of financial gain. The definition of fraud requires that it be perpetrated with the intent to deceive someone into giving up something, specifically something of value or some right that they hold. This means a simple deception that does not cause a loss does not rise to the level of fraud, as fraud requires that the deception cause harm to another. The LexisNexis example cited earlier is an example of fraud. While at the time of this writing, LexisNexis had not found cases where the stolen information was being used to commit fraud, the perpetrators had certainly cost LexisNexis the expense of contacting all of its potentially affected customers [Enouf05]. Many different types of fraud exist, including online and offline fraud. Confidence schemes are a common source of fraud, particularly online. In a confidence scheme, the perpetrator (called a confidence man (con man for short) tries to defraud a victim by using a scheme that convinces the victim that he will profit if he goes along with the con man. Many of us have seen a common example of these: the so-called 419 scam mails and emails offering the victim a percentage of a very large sum (commonly over 10 million dollars) in return for assistance with getting the money out of the country where it’s being held, usually Nigeria. (The “419” terminology derives from the section number of the Nigerian code violated by these con men). The user becomes a willing coconspirator in the attempt to smuggle the money into the U.S.; because he is a conspirator, he is less likely to involve the authorities when things start to go badly, as they always do. The victim in these cases
Threats and Attacks
35
is convinced to pay “fees” to help move the money out of the country. Of course, the money never existed, and the victim loses all his “investment.” In some cases, the thieves have managed to empty the bank accounts of their victims; companies and even prominent political figures have been suckered into participating into these advance-fee scams. Lottery scams are another form of confidence scheme where the victims receives emails announcing that they have large winnings in a lottery they’ve never entered; all they need do is pay some fees to get their winnings. Even if only a small percentage of the potential victims respond to these solicitations, the con men win, as their investment (the cost to send a large number of email messages) is close to zero. Unfortunately, online fraud appears easier than in-person fraud. Perhaps this is because it’s easier to mislead people when you aren’t seeing them face to face. Perhaps it’s because most people don’t understand computers very well and consequently trust things they see online more than they would under other circumstances. This willing suspension of disbelief leaves many people in a state where they can be taken advantage of by what are very simple and obvious attacks (or at least obvious to those who know about them). In any case, victims continue to be taken in by simple means. System owners, Internet service providers, and educators must work to sensitize users to be wary of these threats.
SPECIAL CONSIDERATIONS FOR WEB SERVICES ENVIRONMENTS As we have discussed, many of the threats described in this chapter have significance in the Web Services environment. Some of these are quite similar to threats outside the Web Services environment, but some of the threats take somewhat different forms. Vandalism and sabotage attacks against Web Services sites result in changes to the site content. This can lead to modifications or deletions of files that are critical to proper service operation. However, this form of attack is not all that common within a Web Services context because the goal of a Web site defacement attack is to publicly deface the site. Breaking a Web service by deleting or modifying files used by the service does not provide a public demonstration of the break-in. DoS attacks against a server hosting a Web service are also possible. Like vandalism, it is likely that the primary target is not the Web service itself. The service just happens to be hosted on a system that also hosts a Web site that is under attack. DoS attacks against Web Services can be mitigated by replicating the service across several geographically and logically distributed systems. Colocation arrangements with your service provider should contain contract language obligating your Internet service provider to react to and attempt to recover from DoS attacks. Often
36
Enterprise Web Services Security
service level agreements (SLAs) are used to express user expectations of how ISPs will react to DoS attacks, including physical attacks. Privacy and confidentiality breaches are mitigated by proper site design. Information processed by the Web service must be properly isolated so that attackers cannot breach user confidentiality. This requires that the developer of the Web service function understand the sensitivity of the information the service is processing so that appropriate controls can be put in place. Service information must be protected while stored on the server and while in transit in order to protect user privacy. Integrity attacks against a Web service system will attempt to corrupt data managed by the service. Just like other forms of network service, a Web service is subject to attacks from users who fabricate user input hoping to exploit weaknesses in the service. Attention must be paid to buffer overflow attacks, input data format attacks, and so forth when a Web service is designed. Buffer overflows occur when an input string is delivered to a program that is larger than the program is designed to accept. These attacks can be used to manipulate the program stack, allowing the attacker to manipulate the program flow to allow them to take over a system by introducing hostile code in the buffer. Format attacks manipulate the C language string formatting services to allow an attacker to overwrite application data, again for the purpose of executing operations dictated by the attacker. Service interfaces may work properly when presented with proper input data but fail if input is manipulated. Unfortunately, security is not often considered in the design of service endpoints, and testing is superficial at best. If the service works properly when used with correct input, it is not likely that anyone is responsible for testing the service in the face of a hostile user. Developers must be educated to treat all user input as tainted and to verify that the format is as expected. Web Services designers must also consider man-in-the-middle attacks. Protocols must be designed to be skeptical about the credentials presented to them because it is possible for an attacker to redirect client requests so they pass through a system that they control. For example, domain name service (DNS) poisoning attacks can be used to redirect connections to a server controlled by the attacker. One must also consider a hostile insider such as a system administrator who controls the internal DNS servers. Insiders can redirect user requests (even to outside servers) to systems they control. While these are currently rare, combating these attacks requires that the client and server implement measures to detect the man-inthe-middle and other attacks so that only trustworthy or verified clients are permitted to connect. Clients must also be skeptical about the server’s identity until it is proven by some reliable means. Cryptographic techniques such as the use of public key authentication can be used to ensure that the connection between the client and server is a direct connection with no interloper.
Threats and Attacks
37
Spoofing in a Web Services context can occur in at least two forms: forged IP addresses and forged user credentials. IP forgery attacks against a Web service are effective against a service that uses IP addresses as part of an access control decision. IP addresses are easily forged; it does not make sense to build an access control system that makes decisions based on unreliable information. Replacing IP address authentication with other forms of authorization such as PKI certificates (described in Chapter 9) is strongly recommended. Spoofing using forgery of user credentials is another potential problem. Credential spoofing may be the result of weak authentication (for example, easily guessed passwords) or simply replay attacks. Service designers must take into account the possibility of authentication brute-force attacks (try every password until one works), sniffing of user passwords (listening over the network for user logins and capturing the passwords), and replay of user login sessions (capturing the login traffic and playing it back to fake a legitimate login). Often we find complex systems with only user-selected passwords being used to protect high-value transactions. Unfortunately, a Web Services system may not be able to dictate how users are identified because the system has to work with the existing means of authenticating clients, and those are frequently very weak, password-based systems. Mobile code threats to Web Services systems usually occur when hostile code compromises a user system. Spyware, keystroke loggers, and other hostile code can be used to record user account access for later analysis and replay. A keystroke logger may be the worst case, as it can be used to capture user login sessions. Since users only change their passwords when they are forced to change them, this allows the attacker a potentially very long window of opportunity to attack the system using the captured passwords. Unfortunately, it is difficult for a Web Services client to detect that the client system it is running on is compromised. Antivirus systems provide some level of protection against hostile mobile code, but these are after-the-fact methods of detection. They only detect malicious mobile code (malware) that the antivirus developers know about, meaning there is always a window between first release of malware and detection of that malware. This is why several damaging Internet worms (such as Slammer) were so successful in spreading. Many instances of spyware are not detected by common virus scanning products. Users think they are protected but often find that they are not when they use a spyware scanner to evaluate their system. One serious problem is the end-user license agreements that ship with some software that is widely considered to be spyware. For example, Gator’s license agreement has been analyzed to look for reasons why users are frequently induced into installing the products that bundle Gator. (One example of software that may come bundled with Gator is the Kazaa peer-to-peer file-sharing system.) Users clearly do not read the license agreements, as evidenced by the details. The
38
Enterprise Web Services Security
Kazaa license agreement that bundles Gator spans 63 pages of legalese, including an agreement by the user that he will not use automated means (such as spyware removal tools) for removing Gator [Edelman04]. From Gator’s point of view, this is quite reasonable because the user is given access to the software they want (Kazaa) as long as they agree to allow Gator to function; disabling the adware is a violation of the terms they agree to when they install Kazaa. (Of course, how many people really read all 63 pages of terms?) Also, Gator is actually only adware; that is, it delivers advertisements to the user that they agree to receive in return for running the software that’s bundled with Kazaa. There are other far less honest adware installers that do not tell their users what they’re really agreeing to. Of particular concern for Web Services client software is the case of Trojan horse programs that carry a hostile payload that records user sessions and transmits the user session to a central host. User education may be the most effective solution for malware attacks, but the spread of worms, viruses, and zombies seen today demonstrates that users are still easily duped. A Web service must be aware of the potential for attempts at fraud. Many of the possible reasons have been given above, but there are other considerations as well. Any time something of value is transferred or otherwise exposed to the Internet, there’s a chance that someone will try to exploit the system for benefit. Defense against these attacks requires attention to policy, education, and technology.
SUMMARY In this chapter we have discussed information security threats and the associated attacks in the context of Web servers, but they can be generalized to any network server or network service. We started by defining what we mean when we say that a system is “secure.” We mean it is reliable and does just what we want it to do. We also defined threats and vulnerabilities, threats being a set of circumstances that may lead to damage, loss, or harm and vulnerabilities being a characteristic of or a weakness in a system that makes it subject to loss when an attack is mounted. We defined an attack as a circumstance where a threat agent decides to attempt to damage a system or its users and acts on that decision. A countermeasure is a control put into place to protect vulnerable components from attacks. We discussed in detail some of the more prevalent attacks on the Internet including vandalism and sabotage, denial-of-service, privacy and confidentiality breaches, integrity violations, man-in-the-middle attacks, spoofing, mobile code threats, and fraud. We also briefly discussed how these threats impact the Web Services environment.
Threats and Attacks
39
REFERENCES [Achohido04] Achohido, B. and J. Swartz, “Going Price for Network of Zombie PCs: $2000-$3000.” USA Today, December 5, 2004. [CNET97] C|Net Tech News, “Social Security Site Closed.” Available online at http://news.com.com/2100-1017-278711.html?legacy=cnet. [Edelman04] Edelman, B., “Gator’s EULA Gone Bad.” Available online at http:// www.benedelman.org/news/112904-1.html. [Enouf05] Enouf, Thad, “Lexis Nexis Adds to Number of People Affected by Hacking Breach.” Dirty Tricks, April 12, 2005. Available online at http:// dirtytrix.blogspot.com/2005/04/lexis-nexus-adds-to-number-of-people.html. [EPIC97] The Electronic Privacy Information Center, “The Social Security Agency and Online Privacy.” Available online at http://www.epic.org/privacy/ databases/ssa/. [Garfinkel00] Garfinkel, Simson, Database Nation: The Death of Privacy in the 21st Century. O’Reilly and Associates, 2000. [MLabs04] Message Labs, “Monthly Report: October 2004: The Rise of the Zombie Botnets.” Available online at http://www.messagelabs.com/emailthreats/ intelligence/reports/monthlies/October04/. [Moore65] Moore, Gordon, “Cramming More Components Onto Integrated Circuits.” Electronics, April 19, 1965. Available online at http://www.intel. com/research/silicon/mooreslaw.htm.
This page intentionally left blank
3
Security Goals
In This Chapter Protecting Your Assets Common Security Terms Classic Security Goals Transaction Security Goals The Role of Security Policy in Web Services Security Enforcement Summary References
n information security program is created to meet a set of goals. Many of these goals are to protect against some of the specific threats and types of attacks we discussed in the previous chapter. While some of these goals may be nearly universal, others may not be so obvious. Achieving these goals also comes at a cost. Some of the costs are real (the costs of implementing or supporting various security mechanisms, for example), and some come in the form of opportunity costs—users who cannot be supported or the customers who cannot be reached. An enterprise has to weigh these costs in terms of the risks it is willing to take, the risks themselves representing a potential cost of loss, to develop a coherent security policy. Without such a policy, an enterprise may find itself gold-plating in one area while leaving the door standing wide open in another. In this chapter we will provide a rationale for having a strong security program and well-documented security policy by pointing out the important business elements that help justify those
A
41
42
Enterprise Web Services Security
security goals. We will look at threats, vulnerabilities, countermeasures, and risks in a broad context that will set the stage for the detailed policy implementation discussion in Chapter 6.
PROTECTING YOUR ASSETS The primary goal of a security program is to protect your assets, which are the things that you value or consider to be important to your business. Assets include your computers, networks, buildings, and employees. Assets don’t need to be tangible objects; trade secrets that allow you to build a unique product are also important (for example, you can be sure that Coca-Cola considers the formula they use to make Coke® to be an asset). The Web Services an organization offers may be among its most important intangible assets. They may represent key components of its business process or act as a gateway to extremely important or valuable business information or capabilities. While it concentrates on the assets you own, your security policy should also consider protections for the assets owned by your customers or business partners that may come into your possession. If you share data with customers, you do not want that data sharing to be the cause of an attack against their systems. That primary goal of providing protection for identified assets is just a part of the justification for a good security policy. Other goals include business continuity, privacy protection, and accountability for the company’s operations. While these are of course admirable goals, there are good, practical reasons for having a strong security policy above and beyond those goals. For example, to write down your security policy, you must think about the assets that are under your control and how those assets may be taken from you. You must also consider the protections you can put in place to keep those assets from being lost. The analysis necessary to help you decide what assets are important enough to protect is the first step toward improving the security of your enterprise. Exercise of due diligence requires you to understand what threats and vulnerabilities affect you and what countermeasures you can use to avoid security breaches. Another practical reason for having a strong security policy is that it helps you to judge the costs associated with protecting your assets, making it easier to justify the security budget. The following sections of this chapter list the steps you should take to define your security policy.
COMMON SECURITY TERMS Several terms are commonly used within the security community to help clarify the goals of a security policy. While these have meanings that are consistent with the
Security Goals
43
common use of the terms, the information security usage of these terms is somewhat more precise. This precision helps us understand the rationale for steps that are taken in implementation of a security policy. We will also show the relationship between threats, vulnerabilities, countermeasures, and risks. Reducing Vulnerabilities Vulnerabilities are weaknesses in a system that can be exploited, leading to loss or damage. As we discussed in the previous chapter, while they cannot be totally eliminated, they can certainly be reduced. The designers of a system are responsible for avoiding known attack methods when building their system. They should consider common causes of vulnerabilities such as: Buffer Overflows: The application is sent more data than the program allocated for an input value, leading to call stack corruption and exploited code execution. Heap Corruption: Similar to buffer overflows, these are attacks against memory that are not stack based. Replay Attacks: The attacker stores a transaction or a response and reuses it later. Integrity Violations: A system is attacked by tampering with the data being processed, leading to invalid results. Privacy Violations: Attackers obtain access to information they should not be able to view—for example, access to a user’s salary. This is not an exhaustive list. New attack methodologies are occasionally found, meaning that an application that currently appears to be secure may be successfully attacked in the future when new attacks are found or even when libraries that the application uses are found to be subject to some exploitable bug. Unfortunately, software developers often fail to consider well-known flaws when building systems, resulting in the same errors appearing in new software systems. Since imperfect humans build the systems using components that they may not fully control, it is very difficult to build a system that has no vulnerabilities. That lack of control is an unfortunate side effect of the object- and component-oriented design methodologies used today. The developers of a product are encouraged to use components that they may not completely understand or that may not be well designed or tested. Even in the absence of untrusted components there is still a problem because most applications rely upon an operating system (Windows, UNIX, Linux, etc.) that may have flaws that expose even the most carefully designed application.
44
Enterprise Web Services Security
As explained in Chapter 2, a “secure” system is one that does what it is expected to and nothing more. Side effects, random behavior, and crashes are clearly all violations of the security expectation. When we try to secure a system, we attempt to control the number of vulnerabilities in the system. Proper design discipline, code reviews, and simplicity of design all contribute to improving the vulnerability posture of a system. Unfortunately, some software developers are openly hostile toward any attempts to better organize the development process. Code reviews are an effective means of finding bugs before software is complete, but developers treat them as being too critical of their development style or code quality. The hostility toward such techniques reflects upon how they are used by management; rather than use them to encourage improved software quality, they are used to try to measure programmer performance. It’s only natural for a developer to resist methodologies when they’re used to make disciplinary decisions. The techniques necessary for making high-quality software with a low number of bugs are well known (processes such as extreme programming, white box design, process improvement methodologies, formal methods, and continuous testing), but software continues to be developed as an art rather than as a science. We will always have bugs because nothing is perfect, but there are many real improvements available if companies had the will to force better development discipline (assuming that they’re even aware of the results of the research in process improvement). Fixing a bug during development costs less than fixing it in the field after the product ships; worse, maintenance of a program to fix one bug often introduces a new bug. This is apparent from simply performing a web search for “new bug introduced with bug fix.” At the time of writing this, there are over one million results for this simple search. Classic information assurance practice is meant to avoid vulnerabilities by minimizing the amount of software that enforces security policy. High-assurance systems are built with a small, self-contained kernel that enforces security policy. This kernel, called the trusted computing base (TCB), is small enough to be analyzed methodologically to search for flaws. For high-assurance systems, this TCB is formally verified to prove that it works correctly and cannot be bypassed. This verification process is time consuming, but it provides a great deal of confidence in the correctness of the software. Having to perform a high-assurance analysis of a large, complex program would be cost prohibitive because of the complexity of the resulting analysis. Keeping software small and self-contained makes it easier to analyze for flaws because more complexity means there are more paths to verify for correctness. Each additional pathway multiplies the complexity of the system being designed, increasing the chance that the system will have an undetected flaw. It is easier to prove that a simple system that does only the essential tasks and nothing more is trustworthy.
Security Goals
45
This desire to simplify the system to improve security leads to a conflict between security and functionality because adding capability makes the system more complex, making it more difficult to analyze and secure. Unfortunately, security usually loses the battle against marketing’s desire to add features to products. Some customers (primarily national defense organizations) require products to be evaluated to prove that their design is correct, that the development process helps avoid flaws, and that the vendor has a reasonable flaw mediation process. These products are evaluated using the Common Criteria Evaluation and Validation Scheme (the Common Criteria) [NIAP04], a joint activity between the National Institute of Standards and Technologies (NIST) and the National Security Agency (NSA) (niap.nist.gov/cc-scheme/). Products evaluated under the Common Criteria scheme are verified for functionality and development quality. Purchases by members of the U.S. Department of Defense (DoD) are required to consider Common Criteria validated products in preference to those that have not been validated. This is a laudable practice. We hope this means that the quality of security-enforcing products will improve for all users, not just the defense agencies. Unfortunately, there are many products not purchased by the DoD that do not meet the evaluation criteria. The older Orange Book (DOD’s 5200.28 Standard for Trusted Computer System Evaluation) defined seven levels of operating systems security, D1-A1, as shown in Table 3.1, based on specific characteristics built into the operating system. The Common Criteria also defines a seven-level rating system (also shown in Table 3.1) for operating systems and other computer and network components that is based on evaluations of component functionality and security features. Most commercial systems you will encounter are at the C2 or EAL 3 level at best. Up to this point, we have concentrated on vulnerabilities in the software components of the system. It should also be mentioned that vulnerabilities might exist outside of the software being used. All of the components of the system such as the hardware, the software, and the data itself are subject to some forms of attack. Even if the software is 100% reliable and effective, it cannot enforce the security policy if an attacker can simply bypass it by taking another path through or around the system. Vulnerabilities can exist in many ways in the hardware components of a system. For example, hardware (such as networking components) can be overloaded in denial of service attacks. Network worms have also demonstrated the ability to bring down networks based on overloads. One example of this was the SQL Slammer worm. This worm was small (376 bytes of payload) and it spread very quickly (55 million systems per second were being probed at its peak.) [CAIDA03]. Slammer spread so quickly and infected such a large percentage of the potentially infection-prone systems that it overloaded much of the Internet, leading to widespread failures such as the failure of a major bank’s ATM system.
46
Enterprise Web Services Security
TABLE 3.1 Security Assurance Levels Orange Book
Meaning
Common Criteria
Meaning
D1
Untrusted
EAL 1
Product is functional
C1
Directory and file controls, authentication through login, root considered unsecured
EAL 2
Security mechanisms moderately checked
C2
Auditing plus additional security
EAL 3
Checking is more strict, but no reengineering
B1
Support for multilevel security and mandatory access control
EAL 4
Vendor is willing to fix problems in the development process
B2
Supports object level labeling
EAL 5
Very strict process
B3
Extends protections into hardware
EAL 6
System development is based on security
A1
Uses a mathematically verified design
EAL 7
Limited to very specific systems with very specific security requirements
Hardware may have other vulnerabilities beyond overload attacks. The system may have design weaknesses that can be exploited. For example, the Intel x86 architecture allows code to execute on the procedure call stack, allowing easy buffer overflows. Recent versions of the x86 correct this flaw. Some hardware bugs have allowed attack software to cause the system to lock up, requiring the system to be reset before it can be used. One case of this was the Intel Pentium® “f00f” bug (named for the hex encoding of an illegal instruction sequence). Encoding a particular sequence of bits in the instruction stream allows an unprivileged user to lock the system up; luckily, workarounds are available for most operating systems [Collins97]. Another vulnerable system component is the data stored on or processed by the system. Data can be attacked by modifying it, by intercepting it during transmission, by replay attacks, or by attempting to generate fraudulent copies of legitimate transaction data. Modification attacks seek to change the agreement between the transaction parties. For example, an attacker can change the “ship-to” address in an
Security Goals
47
order to his address so he receives the product rather than the person paying for it. Interception attacks expose data to unauthorized parties and may lead to privacy loss. Another problem with interception attacks is that passwords may be intercepted and later used to spoof a legitimate user’s identity. Replay attacks are used to retransmit a request; these may be used to flood a system with duplicate copies of a single legitimate order or cause a payee to be credited multiple times for a single product delivery. Replays may also be used to take advantage of intercepted authentication information. Once private data is exposed in some way, it may be used to perpetrate a fraudulent transaction. Another class of vulnerabilities is those caused by attacks against the environment. Power interruptions are one source of such problems. Fire, water, and weather-related damage (floods, thunderstorms, hurricanes, and blizzards) are also possible. Physical protection of the system components must also be considered because access to the console on most computers allows an attacker nearly unlimited access. For example, the attacker can reboot the system using an operating system CD that he brings with him, using that operating system to make copies of the system data. The legitimate users will not be aware of the exposure, as all they see is some amount of system down time; choosing the time for the attack allows it to be undetected. More extreme (or at least more unusual) physical attacks against computer systems include those by angry employees bent on destroying systems. Theft of critical systems is another problem that must be considered. Your organization should have a complete continuity-of-operations plan that defines all the systems that play critical roles in the operations of your organization. One source of guidance for forming such a plan is the U.S. Department of Homeland Security site at http://www.ready.gov/business/st1-planning.html. Each of the critical systems should have backups in place such as systems at other physical locations that can be placed into service to continue normal business operations. The effort necessary to write a complete plan is helpful in building your security policy as well. Realistically Assessing Threats As defined in Chapter 2, a threat is the possibility of a set of circumstances that may lead to damage, loss, or harm to a system or its users. Threats define the potential for loss or damage. All threats are not equal, nor are they equally probable. A threat potential captures the possibility that the threat may never be realized. If nobody tries to implement the threat, no loss occurs. In this case, the threat potential is zero. If a vulnerability exists to a widely available exploit method that is known to an attacker, the threat potential is very high. The security policy must consider all of the attack agents and what means they may use to attack the system. Each of the threats that those attackers pose should be covered in some way by security policy.
48
Enterprise Web Services Security
Ideally, a complete security policy would identify all the existing threats to the system. Of course, identifying all threats is difficult since new threats arise all the time from new attackers, not to mention any threats you are unaware of. Another reason you cannot identify all threats is because new vulnerabilities are found each day. All you can hope to do is find as many of the threats as possible while remaining vigilant for new threats so you can adapt your policy to accommodate them when they become known. An example of a system that tries to express threat levels is the U.S. Department of Homeland Security’s color-coded threat level scale. In general, several things determine what the threat level is for a given system. The threat level depends on several factors: The value of the resource being protected The expertise of the attacker The length of time the attacker has to probe before they are detected How well equipped the attacker is Whether an exploit is widely available or not Higher value resources are more likely to be attacked than those with low value. This depends on the attacker’s perception of the value of the asset, of course. Attackers will pose a higher level of threat when they see more benefit to them from attacking a particular asset. If your threats are primarily from competitors, you have an easier job identifying and protecting high-value assets: anything that gives away competitive advantage needs to be protected. This could include pricing information, supplier contract details, internal cost information, labor agreements, and so forth. However, “value” may be more subjective depending on how high profile your site is. Some people will attack a Web site (or any other type of service node) purely to enhance their reputations as hackers, attacking well-known Web sites simply so they can brag about the attacks. This is why several denial of service attacks were mounted against sites like eBay: primarily so the attackers can brag about making the newspapers. Threats based on the visibility or reputation of a Web site cannot be easily controlled. The system owner’s idea of value must also be considered because it is easier to justify protection for a system that is a critical part of your business processes. Just as assets have a range of values, attackers have a range of expertise. Some crackers have a great deal of experience in finding system flaws and in finding ways to exploit those flaws. Knowledgeable attackers who understand the internal details of the systems they attack are the worst case because they know how the systems will react to input and may be able to devise ways to exploit any vulnerabilities that exist. The more internal information the attackers have, the higher the threat they
Security Goals
49
pose because they are more likely to be able to pinpoint flaws in the system when they are familiar with the internal details. Highly experienced attackers find most system vulnerabilities because random searches or probes may find known problems, but new vulnerabilities are usually found by people who understand how to methodologically probe systems for vulnerabilities. Of course, random probes can still be effective. The Sapphire worm mentioned earlier was very successful in locating vulnerable systems, spreading quickly to a large percentage of the population using a simple random probe. However, that probe used a known flaw to spread; once this flaw was patched, the spread rate decreased quickly. Experienced system crackers start without a known flaw and probe the system until a flaw is uncovered. Once they find a problem, it’s characterized in the attacker community as a “zero-day” attack since the exploit is known to an attacker but no defense is known. Zero-day attacks are valued by the attacker community because discovery of a new, previously unknown problem is the way crackers enhance their reputation. Once their attack is leaked to the public, it is usually shared by unsophisticated attackers (“script kiddies”). While there are many more unsophisticated attackers, their effectiveness is limited once the vulnerability is made public. Usually a patch is issued to close the original vulnerability, limiting the kiddies to attacking systems that remain unpatched. Unfortunately, very often, once systems are set up and running they have very little subsequent administrative attention, leaving victims for the kiddies. As this was written, systems were still on the Internet that were infected with the Sapphire worm, still trying to spread the worm to systems that had been patched for nearly five years. Even if a system administrator does maintain systems up-to-date with patches, there is some exposure if they allow a newly installed system to be exposed to the Internet before it is patched. Recent measurements of the time it takes for an unpatched Windows 2000 system to be infected if connected to the Internet average around 20 minutes (or less), which is not nearly enough time to get the critical patches installed [ZDNet04]. Attackers range in expertise from unsophisticated attackers with limited knowledge of the systems they are attacking, to hackers who have a great deal of experience in locating flaws, to high-profile computer criminals who have unlimited resources available to them. Clearly, the unsophisticated attackers cannot develop new exploits, but they can have high impact on a system because there are so many of them. Few highly trained attackers exist, but there are a limited number of systems with sufficient value to be able to attract their attention. Another variable in determining threat level is the length of time it takes for the attack to be noticed. Attacks may be more profitable if they are undetected because allowing attackers more time may improve their chances of successfully breaching the system. One of the simple examples of this is a brute-force password attack. If you allow an attacker to guess the password for an account an unlimited number of
50
Enterprise Web Services Security
times, eventually a weak password will be detected and exploited. Lack of vigilance provides attackers with an avenue they can use to exploit widely publicized flaws. Allowing attackers a long time to use an exploited system also means they can use that system to attack others, decreasing the chances that they will be caught. Any attention that they gather will be directed toward your machines. You will eventually know that something is going wrong when one of their other victims accuses your company of mounting an attack. One measure of the level of the threat is the impact the threat poses. Impact is a way to measure the potential loss from an attack. We consider attacks against higher value assets to have higher impact than attacks against lower valued ones. Another way to look at impact is that it is a judgment about how effective an attacker is. A high-impact attack will do a nearly complete job of disabling a company’s ability to do business. A low-impact attack will have very little effect. One of the purposes of asset analysis is to determine where your critical resources are located, as attacks against those are likely to have high-impact. Clearly, it is easier to justify spending resources to protect against high-impact attacks. However, you should not concentrate on only the high-impact threats, as even small threats can be significant if attackers are persistent. Eventually they will be able to inflict enough cumulative damage to have a significant combined impact. Another way to determine the impact of an attack is what kind of resources, such as system tools, the threat agent possesses. Attackers with specialized tools will pose a higher threat. A simple example of this is an attacker with safecracking tools; that attacker will pose a higher threat than someone who is reduced to trying every possible combination. Tools in this context include debugging software, testing tools, and so forth. The developers don’t expect these tools to be distributed outside their development shop and be used against the product they are building. One must plan for the possibility that such tools may fall into the hands of an attacker with enough motivation. Threats at this level are considered reasonable for systems protecting secret or top secret information. The Common Criteria threat evaluation allows for attackers who are able to build their own tools if necessary for very high-assurance products. The rationale for this is that the attacker may have access to nearly unlimited financial resources when attacking an enemy system. Exploit availability is another way in which threat level varies. An undiscovered vulnerability has a negligible threat until it is discovered. Once the latent flaw is found and an exploit program is written, the threat is then dependent on how well the discoverers protects their knowledge of the exploit. Experience has shown that most exploits eventually become public as their developers spread them around because eventually someone receives a copy and releases it to the public. If a widely available exploit exists for a particular vulnerability, the threat level is very high. An example of this is the Microsoft SQL Server bug exploited by the Slammer/Sapphire
Security Goals
51
worm. The vulnerability was known for some time before the worm was released; before the worm, the bug was largely academic, but after release, those operating vulnerable systems were threatened, compelling them to patch immediately to close the hole. Widely available exploit programs dramatically increase the threat level, as it is easy to mount the attack with just a copy of the exploit program. Choosing the Right Countermeasures The discussion above may lead readers to despair. There are a virtually unlimited number of vulnerabilities and widely available exploits; there are crackers armed with automated exploits, and there is no hope. It’s not as bad as it first appears, because while there may appear to be an unlimited number of vulnerabilities that attackers can exploit, you are not required to sit still and accept the attacks. The defense side of the vulnerability equation is the ability to implement countermeasures. A countermeasure is a defensive action that a system defender can take to reduce or eliminate the effectiveness of an attack. The concept is easily understood, as there are analogies outside the world of information security. If the threat is a car collision, you install seat belts as a countermeasure to help eliminate injury during the accident. From the information security perspective, you take similar action. If the threat is against your database server, where an attacker is trying to read unauthorized data, you install a firewall to limit access to the database server so only users authorized by the Web server can read that information. Countermeasures can take many forms. Some countermeasures are technical controls, such as features added to a system to help it resist attacks. Others may be environmental controls such as physical protection of a system to help protect it from theft. Technical countermeasures may be easier to associate with information security concerns, but physical countermeasures are still very important. Some examples of physical security countermeasures are guards and access control systems such as badges, guard dogs, and keyed locks. Countermeasures can reduce the impact of an attack. To some extent, this can be treated as a reduction in the level of impact. However, you should remember that a countermeasure must be reliable if it is going to be expected to eliminate a threat. If the attacker is able to bypass the countermeasure, the threat still exists and may be exploited. Indeed, a countermeasure may lead you to not consider other protections for a vulnerable system. If the countermeasure ever fails, all the original vulnerabilities are exposed and may be exploited. Unfortunately, common cases like this exist where organizations rely upon firewalls to protect their networks. Because the countermeasure is in place, the administrators do not work to keep internal systems patched. If an employee brings a worm- or virus-infected system into the company, the worm is then unleashed inside the firewall, bypassing it
52
Enterprise Web Services Security
entirely. All too often companies build such systems with single levels of countermeasures that leave them entirely exposed if the countermeasure fails. A countermeasure should be designed to fail “closed” (that is, deny all traffic when the system fails); unfortunately, some systems do not implement this and fail in a permissive manner, allowing all traffic to flow unprotected when something fails. Recognizing and Accepting Residual Risk Some threats have no effective countermeasures. For example, if your threat agent has access to nuclear weapons, you cannot protect your data center from attack for any reasonable price. While this is an extreme example, there are other much more common instances where the countermeasure cost is so high that it is not reasonable to use. Another problem with countermeasures is that they may make the service you are trying to protect too costly. For example, you could have a Web site that allows customers to look up their bank balance. Such a system suffers from the threat of an attacker guessing a user’s password and being able to access their account information. One countermeasure for this attack is to strengthen the user verification by distributing one-time password tokens to all users. However, the cost to do this, given the low frequency of successful attacks, means the countermeasure is not cost effective. In such cases, the owner of the system can choose to accept the risk involved and not spend the money necessary to defend against the specified threat. A residual risk is a threat that the system owners decide they are willing to accept. Some threat exists, but the cost to defend against that threat is more than they are willing to bear. Put another way, they accept the risk as one of the costs of doing business; insurance may be used to help control the cost of that accepted risk. The formal definition of risk incorporates all of the security factors given earlier in this chapter. One formulation for combining the threat, vulnerability, countermeasures, and impact was proposed by Ira Winkler [Winkler97]. A lot of information is expressed in Winkler’s threat-level equation. Increasing the threat or vulnerability quantity increases the threat level; better countermeasures decrease it. Impact multiplies threat because each increment in system value increases threat level significantly. It seems from this equation that the goal of the security policy is a complete set of countermeasures to eliminate the threat. However, as we shall see, that cannot be done because of cost. All the other terms in the equation are aspects of the system or the environment that the owner of the system cannot control. For each of the factors, several influences may change how high the factor is rated. Table 3.2 gives examples of ways in which the measurement of the threat may be influenced. Identifying the influence factors helps concentrate attention on the items or individuals that can most directly reduce the threat level.
Security Goals
53
TABLE 3.2 Threat Level Equation Factors Factor
Influenced by
Threat
The number and expertise of the attackers
Vulnerability
The designer of the software used to build the system
Impact
The value of the system
Countermeasures
The system owner’s commitment to protect the system
In other words, you cannot influence the magnitude of the threat because you have no control over the existence of hackers. Also, you cannot change the number of vulnerabilities without replacing the product. You cannot lower the impact without devaluing your system and processes. All you can control is the number and type of countermeasures you install. This is the basis of risk assessment: deciding what threat levels are acceptable and what risks the owner is willing to accept given the cost to counteract those threats. The goal of a risk assessment is not to minimize or to eliminate risk. If you are trying to eliminate all risk during an assessment, your countermeasures will become prohibitively expensive. You cannot protect a system from an attacker who has millions of dollars to spend on an attack (which may be a reasonable threat magnitude for a system like Fort Knox) unless you can afford to spend even more on a defending your system. Spending the money necessary to protect a system against all possible threats is not likely to be acceptable to business managers. Similarly, attempting to minimize risk (by making it as small as possible) will usually run into a cost barrier. An organization must accept certain levels of risk. For example, you might have a backup “hot site” to which you can transfer your business operations if your main site is attacked. What about an attack against both your main site and your backup site? Do you need a backup for the backup? How many levels of backup do you need to be sure nothing will ever happen? The additional cost for each layer of protection in this case is very high and eliminates a very unlikely risk. The goal of the risk assessment should be to choose countermeasures that are cost effective in eliminating significant risk while identifying residual risks that the system owner chooses to accept.
CLASSIC SECURITY GOALS Several models have been proposed for describing the goals of a security policy. The first such goals articulated what is referenced as the “CIA triad” or “CIA triangle”
54
Enterprise Web Services Security
[Vincent05]. The term CIA is an acronym built from the initials of the three goals: confidentiality, integrity, and availability. More recent guidance has come from the National Security Telecommunications and Information Systems Security Committee (NSTISSC) [NSTISSC02]. The NSTISSC guidance calls confidentiality, integrity, and availability the “Critical Information Characteristics” that define a secure information system. This more recent guidance demonstrates that the CIA triad is still effective in articulating a means to secure a system. These three aspects define the heart of any secure system. Not all systems enforce all three aspects, but most do cover all of them. Confidentiality Confidentiality controls are responsible for ensuring that information is kept from being accessed by anyone not authorized to access it. Confidentiality is the primary concern of many of the contributors to the NSTISSC guidance, as they are largely from the DoD or other organizations in the U.S. government that are responsible for protecting national security secrets. A business is concerned about confidentiality because of secrecy concerns (for pricing information they would like to keep from being seen by their competitors) or privacy concerns (information on their customers that the customer expects them to keep private, such as their medical records). While confidentiality, secrecy, and privacy are very much related, confidentiality has a broader goal. Privacy seeks to protect others from reading information, but confidentiality considers all forms of access such as reading, copying, printing, and so forth. A confidentiality policy applies to all objects controlled by the system and requires the system to mediate all attempts to manipulate the object, even to the extent that the system must keep unauthorized individuals from even knowing that the object exists. Integrity Confidentiality of information is easily understood because it relates to easily understood concepts like privacy. Integrity is a bit less obvious, as integrity controls are not based on who has access to information. Integrity controls determine who is allowed to modify the content of data so that it is no longer correct. That “correctness” protection is the critical feature of an integrity protection system where the information is protected against attempts to tamper with it in order to ensure that it is always correct. It’s easy to understand why integrity is important if you consider the records of your bank, for example. You want the bank to have operations in place to prevent attackers from modifying your bank balance, and of course the bank has integrity controls in place that allow them to detect and correct unauthorized or inadvertent changes to account information.
Security Goals
55
Notice the conflict between confidentiality and integrity: a confidentiality control seeks to keep any access from happening, but an integrity control doesn’t care if the information is seen, as long as it remains correct. Availability Information that is not available when a user needs it has limited value. Availability controls try to ensure that when a valid request is made to access some piece of information, that access will succeed. It is important to notice that availability controls are only concerned with authorized, valid requests for the data. One reason for this is that availability failures are often caused by unauthorized parties flooding a server with requests so that it cannot serve legitimate user requests. This is a denial of service attack that attempts to prevent users from performing their authorized transactions. Again, there is a conflict between availability, confidentiality, and integrity. Availability controls want to make sure information is always available, whereas confidentiality tries to make it unavailable, at least to those who are not authorized. This goal conflict is shown in Figure 3.1, which shows that there are places where the goals conflict (the parts of the graphs that do not overlap), but that some forms of protections coincide (where the graphs overlap). The area in the center is the “holy grail” of a system, where the confidentiality, integrity, and availability goals work together to protect the system.
Confidentiality
Security
Integrity
Availability
FIGURE 3.1 The conflict between security goals.
56
Enterprise Web Services Security
The NSTISSC guidance is based on the classical confidentiality, integrity, and availability controls but considers the CIA triad to be incomplete. NSTISSC identifies additional concerns for a security program: where information is held (in storage, during processing, and in transmission) along with security measures (policy, education, and technology) to make a three-dimensional matrix such as that shown in Figure 3.2 that denotes the controls that are necessary for a security model to be considered complete.
Storage Processing Transmission
Policy
Education
Technology
Confidentiality
Integrity
Availability
FIGURE 3.2 The NSTISSC security model.
Each of the components of the cube in Figure 3.2 need to be considered at some level when you develop your policy. For example, you should consider confidentiality of information in transit in your security policy and you should consider education to help users enforce integrity of information in storage. The additional details in the NSTISSC model help identify assets and goals that might not be included if all the details are not considered when making decisions about what assets need protection.
TRANSACTION SECURITY GOALS Even with the additional considerations provided by the NSTISSC model, some additional aspects of transaction-oriented systems (such as Web Services) deserve
Security Goals
57
attention in a security policy. These are the authentication, scalability, and nonrepudiation goals, which will be defined in the following sections. Authentication An authentication system provides proof of user identity. For the purposes of securing a system, authentication usually provides the user’s identity in the form appropriate for use in making policy decisions. Typical implementations provide a user identifier as some unique binary value that the system can efficiently use in access control decisions. Authentication is needed so that a system that enforces user controls on data can identify the users making requests for information. This allows the system to enforce adequate (only allowing access to objects the user needs access to) and appropriate (only controlling what is necessary while controlling all system objects) confidentiality and integrity controls. The authentication system must interact with the user in some way to decide that the user really is who he is claiming to be. A common means of user identification is a username and password, but this is difficult to use in a transaction-oriented client-server-based system such as Web Services. Sending the user’s username and password over the network from the client to the server means the password can be captured as it passes across the network, allowing replay and other attacks. Transaction authentication also introduces the possibility of a rogue client who allows an attacker to masquerade as an arbitrary user. The design of the client software must protect information that an attacker could use to masquerade as the client. Distributed authentication schemes must take into account the insecurity of the communications network, the insecurity of the client-side software, and the possibility of replay attacks, among other problems. Protocols must be chosen (or designed) to ensure confidentiality of user authentication data and to use sequence numbers or other means to avoid replay attacks. Untrusted clients can be resisted by use of cryptographic controls (such as public key authentication, to be discussed in Chapter 9) to avoid forged user credentials. Allowing delegation of user authentication (so an intermediate system can act on behalf of the client) is difficult for Web Services authentication to do correctly. We will discuss the ways in which distributed authentication can be safely done in Chapter 9. Basic Web site authentication [RFC2617] uses a simple reversible encoding of the user’s username and password and transmits that information with every request sent to the Web site. If an attacker is able to capture a request from the user to the Web server, it can be used to determine the user’s username and password. Web basic authentication should therefore be avoided where possible. Another way a Web site can authenticate a user is by use of client public key infrastructure certificates in conjunction with a Secure Sockets Layer (SSL). As long as the users can be trusted to protect their certificates, this is a reasonably secure
58
Enterprise Web Services Security
system. Since it works in conjunction with SSL, it also adds confidentiality protections while ensuring the identity of users. This identity assurance is only available if users protect their certificates since anyone who has a copy of that certificate can claim to be that user. The user’s certificate should be protected with a strong, unguessable password or stored in a database with very restrictive access. The Windows operating systems offer a protected storage subsystem that stores user private keys in ways that restrict access by unauthorized applications [MSGloss05]. Authentication can be difficult to implement in a Web Services environment when the user does not directly interact with the system offering the service. In this case, there must be an intermediate system that is trusted to accept an authentication token of some kind from the original user and send that to the service endpoint. Getting this sort of system right (where a third party is allowed to proxy authentication to the endpoint) is a difficult design problem. Aspects of this problem will be covered in Chapter 14. Scalability Another transaction goal is to allow the system to grow or adapt as demand increases. If you consider the possibility that everyone on the Internet is a potential customer, you can understand the desire for scalability. The potential growth of the system must be considered when it is initially designed. For example, the growth of a system that requires all transactions to take place on a single computer will be limited by how fast a computer you can buy at any given time. One of the most common criticisms of proposed Internet protocols is that “it won’t scale” because most people are not accustomed to having to consider the exponential growth in demand that happens when a product or service becomes popular. Popular electronic commerce sites such as eBay and Amazon are built on clusters of multiple servers. These clusters are designed to allow more computing resources to be added so the system can handle higher load; a side effect of this is that the system becomes more reliable since there is usually a working system available to handle a user’s request. Content distribution services such as Akamai™ also allow a system to scale by placing resources close to clients. Scalability plans should consider both sides of this argument such as multiple machines dispersed over a wide geographical area in order to minimize the chance of a single attack bringing the system down. When an operation processes all transactions through a single service (a socalled chokepoint), the performance of the system is determined by how fast that chokepoint allows transactions to complete. If the capacity is too low, the chokepoint may become a bottleneck. Those bottlenecks will keep the system from being scalable, as you can only be as fast as you can make that single system. It’s very easy to double the speed of a system by adding another CPU, but you can’t do that for
Security Goals
59
a chokepoint where you must wait for the CPU family to double in speed. Unfortunately, many organizations don’t realize that their systems do not scale until they become popular, leading to unhappy customers and attempts at quick fixes that fail, leading to more unhappy customers. Scalability should be considered as part of the system’s design, not bolted on as a quick fix after a problem is noted. The protocols that underlie the Internet provide a case study in how to build scalable systems. While some say these designs are part of the Internet’s design to survive military attacks, scalability and resilience are really part of the culture. The ARPAnet designers [Griffiths02] and the Internet Engineering Task Force (http://www.ietf.org) have a history of taking scalability and reliability very seriously. Internet services are designed to avoid single points of failure; doing this helps make them scalable. The best example of this is the Domain Name System (DNS), which relies upon a set of root name servers for converting host names to IP addresses; those root servers are replicated with copies spread across multiple continents. Those systems are spread such that one of them is topologically close to any Internet user anywhere in the world. The protocol detects which server provides the best service and preferentially sends requests to that machine, but it also occasionally probes other servers to ensure that changes in network connectivity are detected. All of this design effort leads to systems that can easily be expanded to respond to changes in demand. Nonrepudiation The third transaction-related security goal is that online transactions should mimic the forms of interaction that businesses are accustomed to. For example, when two parties negotiate and sign a contract, that contract is enforceable because it can be proven that both parties agreed to the contract as proven by the fact that each of them signed and dated it. Any attempt to deny the fact that the contract is valid would require denying, or repudiating, the signature affixed to the contract document. An online transaction has similar requirements. When two parties agree to an electronic contract, there must be some way to prove that both of the participants in the transaction truly did agree to the terms. That’s where nonrepudiation comes in. When a system requires a binding contract, some means must be provided for the client to sign the contract to demonstrate their agreement. Such a signature should be date-stamped to demonstrate when the contract was negotiated. It should also provide strong integrity controls so that one of the parties can’t change the contract terms after an agreement is completed. Digital signatures can provide the necessary technology to allow enforcement of the contract because the parties cannot deny that they signed the contract; such mechanisms are necessary to enforce nonrepudiation. Without some form of nonrepudiation, an electronic contract is unenforceable.
60
Enterprise Web Services Security
Some consider the major difference between the terms information security and information assurance to be the addition of nonrepudiation to the assurance goals. There is no clear consensus, and the terms are used more or less interchangeably. However, nonrepudiation is not really a security goal, as it is largely a business goal.
THE ROLE OF SECURITY POLICY IN WEB SERVICES SECURITY ENFORCEMENT Web Services has security goals that are not very different from the goals mentioned already in this chapter. A Web service provides a platform-independent, scalable, distributed method for processing user requests. The service has user authentication needs, processes data that must be protected against confidentiality, integrity, and availability attacks, and must scale to handle user demand. Policy must dictate how information is to be protected for a Web service. The policy must consider all aspects of service data and how that data must be protected. The policy helps articulate the requirements for data protection and for how users are to be identified. The policy must also consider how trusted systems are to be controlled so that a distributed system cannot be attacked by concentrating on one poorly managed component or service. A distributed system such as one built on Web Services must consider a more complex environment than one built on a single system; not only must the policy cover the security concerns raised by the communications network, but it must also consider how systems will be approved to run components of the Web Services system. Of particular concern is a system that outsources service components where the policy must define how the systems to run those components will be vetted. The policy must also consider the spectrum of potential attackers. Anyone from untrained amateurs using downloaded exploit tools to attacks raised by nation-states with potentially unlimited resources must be considered. A Web Service policy also must be designed to incorporate the security requirements based on the business goals of the service. The business needs may dictate what security enforcement is necessary and appropriate for the service environment. The WS-Security standard from OASIS [WSSecurity04] provides a framework for the SOAP protocol that supports many Web Services implementations. WSSecurity defines a set of standard eXtensible Markup Language (XML) formats that allow a Web Service to implement encryption for confidentiality of transaction data. WS-Security also allows the use of digital signatures for transaction data, allowing integrity protection, user authentication, and nonrepudiation protections.
Security Goals
61
WS-Security is an important part of the security policy for a Web Services system. The WS-Security mechanisms will be covered in detail in Chapter 11.
SUMMARY In this chapter we introduced the reasons for having a security policy, defined several goals of security policy, and defined terms to be used to describe those security goals. We related those goals to their use in a distributed environment and expanded the requirements to incorporate business security goals. We started with a discussion of the assets that many enterprises need to protect including both tangible assets such as computers, networks, buildings, and employees and intangible assets such as trade secrets and intellectual property. We then introduced a model for looking at vulnerabilities, threats, and countermeasures and their impacts on overall risks. We next introduced the classic CIA triad, or CIA triangle, and how the three security goals it represents (confidentiality, integrity, and availability) contribute to an overall security strategy. The unique requirements of transaction-based systems such as authentication, scalability, and nonrepudiation were discussed along with the relationship of those requirements to the classical security goals. These were explained in the context of normal business relationships and business operations. The security expectations of the Web Services environment were also described to help understand how a Web Services system can provide assistance with meeting stated security goals as an integrated part of an enterprise’s overall security strategy.
REFERENCES [CAIDA03] Moore, D., V. Paxson, S. Savage, C. Shannon, S. Staniford, and N. Weaver, “The Spread of the Sapphire/Slammer Worm.” Available online at http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html. [Collins97] Collins, R., “The Intel Pentium F00F Bug Description and Workarounds.” Available online at http://www.x86.org/errata/dec97/f00fbug. htm. [Griffiths02] Griffiths, Richard T., “History of the Internet, Internet for Historians (and just about everyone else).” Available online at http://www.let.leidenuniv.nl/history/ivh/frame_theorie.html. [MSGloss05] Microsoft Corporation, “Glossary of Windows 2000 Services.” Available online at http://www.microsoft.com/windows2000/techinfo/howitworks/ management/w2kservices.asp#p.
62
Enterprise Web Services Security
[NIAP04] National Information Assurance Partnership, CCEVS Website, Available online at http://niap.nist.gov/cc-scheme/index.html. [NSTISSC02] National Security Telecommunications and Information Security Committee, “National Training Standard for Information Systems Security (Infosec) Professionals.” Available online at http://security.isu.edu/pdf/4011. pdf, June 20, 1994. [RFC2617] Franks, J., et al., “HTTP Authentication: Basic and Digest Access Authentication.” Available online from http://www.ietf.org/rfc/rfc2617.txt, June 1999. [Vincent05] Vincent, Thomas, “OSXFAQ – Mac OS X Security.” Available online at http://www.osxfaq.com/Editorial/security/index2.ws. [Winkler97] Winkler, Ira, Corporate Espionage. Prima Publishing, 1997, p. 13. [WSSecurity04] Nadalin, Anthony, et al., “Web Services Security: SOAP Message Security 1.0 (WS-Security 2004).” Available online at http://docs.oasis-open. org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf, March 15, 2004. [ZDNet04] ZD Net, “Study: Unpatched PCs compromised in 20 minutes.” Available online at http://news.zdnet.com/2100-1009_22-5313402.html.
4
The Internet and World Wide Web Infrastructure
In This Chapter Internet 101 TCP/IP HTTP Security Domains Client System Vulnerabilities Java Virtual Machine Vulnerabilities Networks Summary References
he Internet and the World Wide Web are creating the materials from which our global economy is being built. The Internet provides the basic plumbing or wiring that creates the underlying infrastructure. The Internet has evolved since its inception in 1969 [Griffiths02] and comes with a well-defined set of technologies and nomenclature. The World Wide Web, or Web, provides some of the protocols that ride on top of this infrastructure that enable communications among the various nodes and the basic building blocks for Web Services. The Web provides both the universal addressing scheme, comparable to the Dewey decimal system at the local library, in the form of uniform resource identifiers (URIs) and the basic protocol, or handshake, for services to interact, or “talk,” with each other across this infrastructure in the form of Transmission Control Protocol/Internet Protocol (TCP/IP). If you think of the Internet as the pipe or wire, the Web is the
T
63
64
Enterprise Web Services Security
water or electricity flowing through it. In this chapter we describe the security-significant characteristics of the Internet and the World Wide Web and explain how security can be enforced in this environment.
INTERNET 101 The Internet is built on TCP/IP [RFC791, RFC793]. TCP/IP is a layered protocol, developed by the Department of Defense (DOD) in the late 1960s to interconnect a large number of independent networks connected by gateways. The idea behind TCP/IP was to develop a robust, automatically recoverable, survivable network that could sustain the failure of any single node. Protocols such as the HyperText Transport Protocol (HTTP) and the File Transport Protocol (FTP) run on top of TCP/IP. The Internet is made up of a series of networks, interconnected by high-speed lines, many consisting of regional subnetworks, or subnets, which in turn are constructed from a combination of local area networks (LANs) and host systems as depicted in Figure 4.1. IP is designed for communicating across these networks and is responsible for routing packets between the nodes of the network. TCP is responsible for breaking larger communications into packets, feeding these to IP, and verifying their correct delivery. Given its error correction responsibilities, TCP is responsible for error detection and correction and the initiation of any retransmission requests. Any given request may pass through dozens of networks between the originating node and its final destination.
Network B
Networks
Network C
Network A
Subnetworks SubNet 1
Host
SubNet 2
SubNet 1
Local Area Network
FIGURE 4.1 Internet address hierarchy.
The Internet and World Wide Web Infrastructure
65
The IP address is the key to communications across this network. Each IP address is a 4-byte (32-bit) number. By convention, each byte, or octet, of the number is expressed by converting it to a number between 0 and 255 and separating the numbers by periods. A typical IP address looks similar to the following: 192.168.1.123
The IP address is quasi-hierarchical: there is a scheme for representing networks, subnetworks, and hosts, but it is not a straight translation. To make the translation, one must understand the class structure used in creating IP addresses. An IP address has two parts: a network part and a host part. A network mask is used as a bit mask to determine what bits of the IP address make up the network part; the remaining bits are the host number on that network. The mask can be specified in a classful manner or in a classless manner. When classful addressing is being used, the first few bits of the address specify what class the address falls into, which specifies the size of the network mask. Class A addresses contain values between 1 and 126 in the first position, or octet. The first octet represents the network address; the remaining three are available for representing subnetworks or hosts. Class B addresses use the first two octets to represent the network address, and these addresses can range between 128.1 and 191.254. Class B addresses have only two octets, which they can use to represent subnetworks and hosts. Class C addresses use three octets for the network address. These addresses range from 192.1.1 to 223.254.254, leaving a single octet for representing subnetworks and hosts. With classless addressing, some number of bits are used as a network mask. For example, the network 192.168.1.0/24 specifies network number 192.168.1 with a 24-bit network mask, which is equivalent to a Class C network. There are 253 possible host numbers in that network. Network 10.0.0.0/8 uses an eight-bit (one octet) network mask. All the systems on a local network must be configured to know the local network number and network mask. Packets are routed through the network by checking to see if they are destined for the local network and if not, routing them to a gateway for the destination network. IP uses routing tables to maintain instructions about how information is to be routed. To make addressing more understandable to humans, a Domain Name System, or Service, (DNS) is used to translate names into IP addresses. For example, DNS might translate www.example.com into 192.168.1.123.
TCP/IP IP is a connectionless protocol. Packets are simply routed from node to node without any sense of sequence or content. TCP is a connection-oriented protocol (there
66
Enterprise Web Services Security
is a connectionless transport level protocol, the User Datagram Protocol (UDP), used on the Internet, but it is beyond the scope of this book). TCP senders and receivers create endpoints, called sockets. Each socket is identified by an IP address and a port number. The process creating the socket binds this information to the socket using a BIND primitive. A socket may have multiple connections open at any given time. Once a socket is established, a process willing to receive connections uses the LISTEN and ACCEPT primitives to passively listen for and connect to connection partners. When two endpoints need to exchange information, the sending endpoint creates a full-duplex connection to the socket on the receiving machine. The sender uses the CONNECT primitive to identify the address it needs to connect to, and the connection process begins. A three-way handshake is used to create the connection: the sender sends a SYN request, and the receiver acknowledges with a SYN response, which the sender acknowledges. Once the connection is established, information is exchanged using SEND and RECEIVE primitives. Each endpoint terminates its side of the connection independently of the other. When an endpoint is finished sending information, it sets the FIN (finish) bit in a final packet using the CLOSE primitive. When the FIN is acknowledged, that direction of the connection is shut down. The connection is released when both directions have been shut down. The overall sequence of events, from start to finish, is shown in the diagram in Figure 4.2.
SOCKET BIND CONNECT
SOCKET BIND LISTEN ACCEPT
SEND
RECEIVE
RECEIVE
SEND
CLOSE ACK CLOSE ACK
FIGURE 4.2 Transmission state diagram.
Now that we understand addressing, routing, and connections, we can look at how information is packaged and sent across the network. Higher level protocols, such as HTTP, do not deal directly with IP. Instead, they communicate through TCP. A transaction begins by a higher level protocol passing a payload for trans-
The Internet and World Wide Web Infrastructure
67
mission, along with the destination address, to TCP. TCP breaks the payload into packets, the size of which is determined by a configurable parameter, but is normally around 1500 bytes. TCP appends a header to the beginning of each packet containing the port addresses for both the source and destination, information needed to reassemble the original payload on the other end of the transmission, and information needed to recover it if a transmission error occurs. TCP passes this information, along with the destination address, to IP. IP, in turn, appends an IP header to the packet. The IP address contains both the source and destination IP addresses. The final payload, illustrated in Figure 4.3, is sent across the physical network, winding its way from node to node from the source to the destination. Once the payload arrives at its destination, the process is reversed, headers are stripped as the payload is passed from IP to TCP to the target protocol, and packets are reassembled into the original payload, be it a message, a file, or some other form of content.
IP Header
TCP Header
Data
FIGURE 4.3 Layout of a TCP/IP packet.
HTTP HTTP [RFC2616] is to the World Wide Web what TCP/IP is to the Internet. HTTP is the protocol on which the Web is built. HTTP is an application-level, TCP/IPbased protocol built around a very simple request-response model. Its primary purpose is for serving Web pages, written in HyperText Markup Language
68
Enterprise Web Services Security
(HTML), between HTTP clients and servers as shown in Figure 4.4. Since most Web Services applications today ride on this protocol, much of the discussion applies equally to both HTTP clients and servers and Web Services clients and servers. The HTTP client initiates a sequence by issuing a request to the server. The HTTP server completes the sequence by processing the request and returning an appropriate response to the client. The standard HTTP client is a Web browser, such as Netscape’s Navigator or Microsoft’s Internet Explorer; the standard server is a Web, or HTTP, server such as iPlanet’s Enterprise Server (now Sun One’s Web Server), Microsoft’s Internet Information Server (IIS), or Apache’s HTTP Server. HTTP is a sessionless protocol, meaning a session is maintained only for the duration of a single request and the corresponding response.
Request
Server
Client
Response
FIGURE 4.4 HTTP client-server model.
HTTP clients and servers communicate via messages in standard formats as shown in Figure 4.5. HTTP requests are ASCII formatted text; HTTP responses are in multimedia Internet mail extension (MIME) format.
method url version
version code phrase
Request_Header 1 . . Request_Header n
Response_Header 1 . . Response_Header n
Response_Body Request_Body Response Format Request Format
FIGURE 4.5 HTTP message formats.
The Internet and World Wide Web Infrastructure
69
HTTP request messages take the form [method] [request_URL] [HTTP_version] [header1_fieldname]:[field1_value] ... [headerN_fieldname]:[fieldN_value] [blank line to indicate end of request headers] [data]
The first word of the request is the method, or function, to be executed. The most common methods are: GET: The GET method is used to retrieve files and data from the server. The request_URL identifies the file to be retrieved or the program to be executed by its URL. POST: The POST method is used to send data to the server for further action. The request_URL identifies the URL of the program or process that is used to assist in performing this action. PUT: The PUT method sends information to the server for storage. The request_URL specifies the filename to which the data is to be written. HEAD: The HEAD method is a way to request the headers for an entity without the data itself. The server returns the response header information associated with the request, but not the data. If the method is viewed as the action, or verb, in the request, the request_URL is the corresponding object of that action. The request_URL designates the file or program requested. The request message can contain one or more headers. Each request header entry contains a name followed by header-specific information, the two presented as a field:value pair. The number of fields and whether they are mandatory or optional depends on the type of request header. Some frequently used request headers include: From: contains the name of the requesting user Accept: lists types of input the client will accept Accept-Encoding: lists content-encoding types supported Accept-Language: lists the languages preferrable User-Agent: the HTTP client Referer: the URL of the Web page referring to this site
70
Enterprise Web Services Security
Authorization: information such as user name and password Charge-To: the account to which costs are to be charged If-Modified-Since: contains a date, requesting the server to only return the document if it has been modified since that date Pragma: used to specify extensions to the header list The HTTP server processes each request and returns a response. HTTP response messages take the form [HTTP_version] [status_code] [reason_phrase] [header1_fieldname]:[field1_value] ... [headerN_fieldname]:[fieldN_value] [blank line indicating end of response headers] [data]
The first line contains a status_code providing information about the response. The reason_phrase that follows is a human-readable explanation of the code. Status_codes are grouped as follows: 1xx: 2xx: 3xx: 4xx: 5xx:
Informational Success Redirection Client error Server error
Two common status_codes illustrating this concept are: HHTP/1.1 200 OK HHTP/1.1 404 NOT FOUND The HTTP protocol defines a number of response headers. These include: Allow: provides a list of supported methods Content-Encoding: contains information on the encoding used for an entity Content-Language: indicates the language used Content-Length: the length of the data
The Internet and World Wide Web Infrastructure
71
Content-Type: specifies the MIME encoding Content-Version: contains version information for the data Derived-From: for conveying information about previous data versions Expires: expiration date MIME-Version: multipurpose Internet mail extension version Location: to support redirection Proxy-Authenticate: to support challenge and response Public: specifies the nonstandard methods the server supports Retry-After: to specify when a service might again be available Server: contains identifying information about the server Set-Cookie: sends data to the browser for retention Title: any title associated with the information Transfer-Encoding Header: encoding used in creating a response URL: identifies other possible locations for the data WWW-Authenticate: part of challenge and response As you can see from this list, HTTP natively contains several of the header formats necessary for first-level application authentication.
SECURITY DOMAINS Our purpose for this book is to help explain how you can protect the systems and infrastructure that support Web Services applications from attack. Defending a system of any type requires that you predict the ways it can be attacked and install countermeasures for all of those attacks. If you’re responsible for protecting a large network, this is a nearly impossible job. You must keep every machine on the network up-to-date with patches, educate all the users to ensure they don’t install untrustworthy software, and react rapidly to new attacks when they are released. The problem is that this is a never-ending job since new vulnerabilities are being discovered almost on a daily basis. There’s also a window of opportunity between discovery of a new vulnerability, release of a patch to fix the vulnerability, and the subsequent installation of the patches. Until the patch is installed, your systems are exposed. Worse yet, you must protect all your systems against all potential attacks if you are going to defend them. An attacker need only find one vulnerability that has not been corrected to be able to breach your systems. Once a system is
72
Enterprise Web Services Security
breached, attackers can use trust relationships between that system and others to extend their reach. Unfortunately, most consumer- and business-grade operating systems are “target-rich” environments with many opportunities for an attacker to exploit given even restricted access. Being connected to the Internet increases the seriousness of this problem. Worms such as the Blaster worm [CERT03] were able to spread quickly by exploiting a vulnerable network service on the target system. Once the worm is able to infect a new system, it uses that system to scan random network addresses for additional victims. Some organizations have reported that an unpatched system connected to the Internet will be infected with worms within 20 minutes of being connected to the network [ZDNet04]. The problem is that patches are not effective until they are installed and that they do not solve the problem on systems where they are not installed. Also, a patch provides a hint to exploit creators about the cause of the problem being patched. Frequently, patches result in quick reverse engineering of the original bug (where the attacker determines what has changed and uses that information to design an exploit). One example of this was the Sasser worm, which was created by reverse-engineering a patch to the Microsoft Windows Operating System [Achohido04a]. All too often the work by vendors to help their users fix problems just leads to providing assistance to the people trying to compromise those systems. Something must be done to permit systems to be used without their being quickly compromised by the latest attacks. The way around this problem is to separate your systems into compartments that contain either trustworthy or untrusted systems. These compartments are called domains. It is important to note that a security domain is different from an Internet or network domain. A given domain contains a set of systems that are all subject to the same security policy. All of your internal systems (employee desktops, systems that should not be accessed by outsiders, internal servers, and so forth) would be in one internal domain. Any public access Web servers would be in a separate domain and so forth. The division into trusted, untrusted, or other domains allows the administrator to build a boundary around the trusted domain and restrict access to those systems from anything in the untrusted domains. A common way to enforce domain separation is by use of a network firewall. A simple firewall policy might deny any access inward toward the trusted domain but allow outbound access from the trusted domain to the untrusted systems. Some organizations build domains for each division, each office location, or for other logical divisions of the company. This is reasonable as long as your domains are reasonably large. The advantage of this approach is that it allows the administrator to aggregate many systems into a single policy enforcement point with a consistent set of rules. If you divide the domains so there are too many of them with few members, the advantage of the aggregation is lost.
The Internet and World Wide Web Infrastructure
73
Domain separation is used in the construction of highly trustworthy computing systems. The software is divided into a small part that enforces the security (called the trusted computing base [TCB]), and a larger part that is outside the TCB. The software within the TCB is verified to be correct, while the non-TCB software does not need detailed analysis. This domain separation allows limiting the search for flaws when the system is designed and built. Domain separation in a Web Services environment requires that you decide what systems to place in your trusted network and what systems are untrusted. The fact that all the systems that you depend upon may not be on a single physical network may complicate this task. It’s no longer a simple network firewall that separates two networks and a simple policy. With a Web Services network, you must extend your trust domain to incorporate systems that may be outside your physical control. This can be done in several ways. One way this is frequently done is to build a separate services domain and assign remote service systems to that domain. You can then apply a different security policy to the service domain, perhaps allowing limited inbound communication from those systems. This is similar to the intranet-extranet-Internet concepts that have been widely used to permit limited interactions between business partners. Another way in which security domains are used is by the Internet Explorer Web browser. A user is allowed to create a set of zones and assign systems to those zones. For example, all internal systems may be assigned to a trusted zone, and all other systems to the untrusted zone. These zones serve the same purpose as a network domain: separating systems into groups so different policies can be enforced. Again, the purpose of the domain scheme is to allow enforcement to be implemented for a large number of systems with a single security description, allowing the policy to be simplified. This example only shows two domains, which is a common configuration with trusted and untrusted systems. The possible applications of the domain model can be much more expressive and flexible; having three, four, or more defined domains allows much more precise access controls.
CLIENT SYSTEM VULNERABILITIES Many of the potential security problems in a Web Services environment result from the client systems, partly because the configuration of the client systems may be something the Web Services system cannot control. The clients may be infected with worms, spyware, or any of the other threat agents discussed already. In this section we will concentrate on the sources of client-side vulnerabilities and how they may be addressed.
74
Enterprise Web Services Security
One unfortunate problem with most service-oriented systems is that client systems are less dependable and less reliable than server systems. Servers are maintained by a dedicated system administration staff; client systems are often not maintained at all. These are critical systems when they participate in a transaction, but because they are not kept up-to-date with software updates, they are inherently untrustworthy. Browser Vulnerabilities Web Services systems are accessed by clients using their chosen Web browser. The Web browsers have grown from a simple product that renders Web pages and images to full-featured multimedia centers. The browsers have become integral parts of the host operating systems (at least on Windows systems). They have added ways for attackers to run code on the client by means of scripting languages, ActiveX controls, and Java Applets. All of this capability comes with a price as the browser becomes more complicated and therefore harder to secure. Several different Web browsers are available for client systems. The Microsoft Internet Explorer browser runs on Windows and Macintosh® systems. Netscape®derived browsers (including the Open-Source Mozilla™ browser project) operate on a wide range of systems, including Windows and UNIX® variants. Other alternatives, such as the Opera™ Web browser, are also widely used. Unfortunately, some browsers have quirks in their behavior. Web site designers that only test their sites using one browser risk having the site appear badly if an alternative browser is used. In some cases, failure to test with multiple browsers may lead to problems that keep the Web site from working at all. (One example of this was a quirk in Internet Explorer with HTML tables. Badly formed tables would display correctly in Internet Explorer but display completely blank pages in Netscape.) That’s why many sites test using different browsers to ensure that their site works correctly regardless of the browser being used. While many of the reported problems with Web browsers have concentrated on Microsoft’s Internet Explorer, a search for vulnerabilities for any of the widely used Web browsers will find several reported problems. Cross-site permission problems (which allow malicious sites to cross domains) have been reported in Mozilla-derived browsers as well as Internet Explorer. Several alternative browsers (Netscape and Opera, for example) have had similar problems. Using a different browser isn’t a panacea. Browser builders live with conflicting goals, as they would like to improve the capabilities of the browsers, thus allowing richer Web site content, but those additional capabilities can sometimes be misused. For example, the JavaScript™ language supported by most browsers can be used to pop up advertising windows on user workstations. Several suppliers of pop-up blockers released utilities to help
The Internet and World Wide Web Infrastructure
75
correct for this by disabling the scripts that popped up the windows. Now the browsers are coming with pop-up blockers built in, thereby becoming both the source of the problem and the source of the solution. Browsers have a history of vulnerabilities that an attacker can use to execute code on the client’s system. This history means there is a good chance that we will continue to find problems that can lead to client system threats. Some of these attacks do not require the user to click “OK” to permit the malicious software (malware) to run, but even so, there are clearly a large number of users who simply click “OK” without reading warnings, allowing attackers wide use of their systems. The wide spread of email-borne worms demonstrates that the operator of a browser cannot be trusted to avoid installing malicious code. Browsers also add complexity to Web sites since not all browsers interpret page content the same way. The requirement to support different browser implementations (Netscape or Mozilla, Internet Explorer, Opera, and text-only browsers) adds complexity to the Web site content. Careful adherence to World Wide Web Consortium (W3C) standards in your Web site design may limit such incompatibilities, but important parts of a Web Service’s site content could be automatically generated code that may not strictly conform to W3C standards. Any extra coding necessary for compatibility makes the site more complex and therefore more difficult to maintain. As we have pointed out, complexity often leads to insecurity. More complex Web site content means there is more chance that something is going to work incorrectly with some obscure browser configuration. Microsoft’s Internet Explorer browser supports ActiveX controls. (There are also plug-in programs for Mozilla to support ActiveX.) ActiveX is a component support system that allows the browser to be extended in many different ways. Effectively, any application that can be run locally on a client’s machine can be converted into an ActiveX control and downloaded to the user’s PC. ActiveX depends upon the user to control access to their PC by approving ActiveX controls before they are allowed to execute. The control comes with a digital signature that is expected to demonstrate who created the control. The user is presented a signature from some company and decides whether or not they trust that company to install software on their PC. The user is expected to verify that the certificate attached to the ActiveX control is connected to an author that they expect; if they are at the amazon.com Web site, any controls should be signed by Amazon. One hopes the user will detect a mismatch and reject a control that appears to come from an unexpected source. While this seems like a reasonable set of controls, they have been found to be inadequate. Users click “OK” without reading the warning messages, allowing malware onto their PCs. Worse, the widely used public key infrastructure vendor Verisign has been duped into issuing a Microsoft Corporation signing key [Securiteam01], allowing attackers to create malicious ActiveX controls that look like they come from Microsoft. Users are conditioned to
76
Enterprise Web Services Security
approve any installs from Microsoft, as they trust Microsoft to not deliver malicious software. With a fraudulent site certificate, users can be convinced to install software that they would not have permitted otherwise. The biggest problem with the browser client is that given the number of users, it is very likely that a user can be found who will be taken in by any fraudulent attempt to convince him to install a piece of malware. Web Services designers should consider the user’s browser to be an untrustworthy component because it is highly likely to be compromised by the user.
JAVA VIRTUAL MACHINE VULNERABILITIES A Java virtual machine (JVM) provides an execution environment for Java applets. A Java program is compiled into an intermediate form that is not native to any particular processor architecture. Because of this, any system can execute a Java program if it has a virtual machine available to execute the Java compiled code (also called bytecode). The compiled bytecode module depends upon the virtual machine to interpret the compiled program and to control what the applet is allowed to do. An applet may contain a user interface to communicate with the user, can create network connections to approved hosts, and can perform other operations if the user permits. A Java applet can execute on any system that provides an appropriate execution environment in the form of a JVM; the bytecode output of the Java compiler does not target any specific hardware architecture. This allows Java programs to be easily moved between different types of systems without having to be recompiled. This portability is one of the frequently expressed goals of Web Services systems: portable, meaning it can be run on multiple host environments, ubiquitous, as it is available independent of the user’s location, and extensible by allowing it to scale across multiple systems. Java also allows coding for small, embedded environments as well as complex client-server systems. The Java language is similar to ActiveX in some respects. Java applets are program modules that extend the capability of the user’s browser. Like ActiveX, they can extend the user interface to provide additional display and user interaction features. Java uses a very different security model than ActiveX. Rather than depend upon users to limit what applets are allowed to execute, Java limits what an applet is allowed to do by running the applet in a limited capability environment called a sandbox. Theoretically, an applet cannot reach outside of the constrained sandbox. The problem with this model is that it is complex. The Java environment must provide an interface to the user’s system that limits what the Java control can do. The sandbox cannot completely isolate the applet from the user’s system; if it did, the applet could not interact with the user at all. The sandbox must analyze all applet activity, looking for patterns that indicate hostile activity. The problem with this
The Internet and World Wide Web Infrastructure
77
approach is that some threats may not appear to be hostile to the sandbox. In fact, fundamental security theory has demonstrated that a sandbox cannot be implemented to always detect attempts to bypass enforcement, as the expected security enforcement is undecidable [Venners05]. Undecidable means that regardless of the effort made to enforce the separation of the Java program from the user’s environment, it cannot be proved that the system always restricts the applet to the sandbox environment. Given the desire to build provable security systems, this is an unfortunate limitation. Some Java applets are digitally signed. This mechanism attempts to add some level of assurance to a Java applet by demonstrating the origin of the applet. The same issues surrounding ActiveX also apply to signed Java. If the authors of a hostile applet manages to compromise the signature system, they can convince a user to permit a hostile applet to execute. Once a hostile applet is allowed to execute, there is no limit to the damage that applet can cause. Another issue with Java is the disagreement between Sun and Microsoft over the JVM included with Windows. Other companies supply their own JVM implementations as well. There are subtle differences in the way these virtual machines operate, meaning applets must be coded to work properly in both. This adds complexity that leads to more potential for vulnerabilities.
NETWORKS Web Services depends entirely on a network infrastructure to provide a means for clients and services to communicate. The network provides the necessary communication mechanisms but also provides attackers with an avenue to attack your services. TCP/IP Vulnerabilities The Internet is built upon the TCP/IP protocol suite. The Internet was built using funding from the DoD that built the ARPANET. Even though the funding for the development of the Internet came from the DoD, a number of security flaws are inherent in the design of the TCP/IP protocol. One flaw in the TCP/IP design is that it does not provide assurance for addresses in IP packets. It is easy for an attacker to spoof a source address of a trusted system in hopes of exploiting permissions provided to trusted domains. Once attackers have privileged access to a system (administrator on Windows systems, root on UNIX systems), they can spoof traffic from their host using the source address of any other system on the Internet.
78
Enterprise Web Services Security
Another flaw with TCP/IP is that it has weak replay protections. A TCP connection between two hosts detects replayed packets using a simple sequence number. Some operating systems use highly predictable initial sequence numbers for new connections, which allows an attacker to easily hijack new user connections and take advantage of user authentication. TCP/IP allows manipulation of the route that packets take between hosts. The use of “source routing” allows an attacker to inject traffic into the network and make it route through a trusted host. This allows the attacker to exploit the trust applied to the source-routed host. The other routing protocols used on the Internet (Routing Information Protocol (RIP), open shortest path first (OSPF), and Border Gateway Protocol (BGP)) all allow spoofed routing updates. This vulnerability in the underlying routing protocols makes it easy for attackers to reroute traffic to a host that they control. Cryptographic controls on BGP are now being implemented to help reduce the severity of these attacks. These controls (the routing protocol used between Internet service providers) demonstrate an interesting side effect of security controls. While signed BGP updates help validate the source of routing data, signed BGP allows an attacker to launch a denial of service attack against a router by sending continuous forged routing updates with bad signatures. The router ends up consumed by the CPU load caused by the bogus packets. This is a case where a security mechanism leads to an additional security flaw. The Internet Control Message Protocol (ICMP) is used to return IP traffic errors to the originating system. For example, ICMP messages are used to report unreachable systems and unreachable ports. ICMP messages are not authenticated and can be easily spoofed; this allows an attacker to close connections by transmitting falsified ICMP messages. Many protocols rely upon domain names to protect connections. The underlying DNS system that translates domain names (www.foo.com) into IP addresses and IP addresses back into domain names is also subject to spoofing attacks. If a server depends upon domain names to control access attempts, that server can be spoofed if the DNS can be spoofed. Many TCP/IP systems rely upon the Dynamic Host Control Protocol (DHCP) to configure host IP addresses and routes and name server addresses. If attackers are able to compromise a DHCP server, they are able to manipulate the configuration of most of the systems on a LAN, allowing the use of DNS spoofing and other attacks. Most of the many other flaws in TCP/IP result from the TCP/IP suite and the supporting protocols having been designed in a largely academic, benign environment. The wide adoption of these systems that were designed without hostile users being considered has resulted in many of the vulnerabilities experienced in today’s Internet. While the replacement Internet protocol (IP version 6 [IPV6]) has added some cryptographic protections against spoofing attacks, those protections are not widely used. In addition, IPV6 itself has experienced little acceptance at this time.
The Internet and World Wide Web Infrastructure
79
HTTP Vulnerabilities Probably the most widely used protocol on the Internet is HTTP. HTTP is defined by the Internet Engineering Task Force (IETF) request for comments (RFC) document RFC 2616 [RFC2616]. HTTP is a simple request-response protocol in which a client system requests a Web page using a GET, POST, HEAD, or other request that specifies the directory and file on the Web server that contains the content to be displayed. HTTP delivers content in several different formats, encoded according to MIME format. MIME was originally designed to allow delivery of rich format (multimedia) content for email; HTTP uses the same encodings and content types to leverage the email efforts. HTTP requests can also allow a user (usually through a browser) to upload transaction data in response to a server query. This is the basis for many of the consumer interaction Web sites; users select products to purchase and upload their requests to the Web server for processing. Another feature of HTTP is the use of cookies. An HTTP cookie is a piece of data that a Web server page transmits to the user’s browser. The cookie is tagged with a domain name; any time the user’s browser requests information from a Web page in that DNS domain, the cookie value is transmitted with that page request. This allows a site to maintain context with a user, which is a critical function for order processing. (The cookie provides a temporary context value that points to the user’s shopping cart, for example.) A cookie can also be used by a Web site to track user activity on that site. This may lead to invasion of the users’ privacy. Once users do anything on the site that gives the site their identity, the site may always be able to track who they are on subsequent visits. Cookie blockers (which act like pop-up blockers) can help eliminate these privacy violations but may cause some sites to malfunction. HTTP uses TCP connections. This means it is fairly reliable in delivering content to the requesting user. TCP provides error recovery, sequencing to ensure that data is delivered in order, and detection of connection losses. HTTP is used for a number of transaction-oriented protocols that depend upon those characteristics to provide reliable transactions. HTTP can use an encrypted Secure Sockets Layer (SSL) connection (referred to as an https:// URL) to provide privacy for user communications. The use of SSL is a browser artifact and is not part of the HTTP specification. SMTP Vulnerabilities Email is transferred using the Simple Mail Transfer Protocol (SMTP). SMTP is a simpler protocol than HTTP because email is effectively unidirectional. SMTP relies upon the same MIME specifications to allow email to contain nontextual content that a Web page uses. Most mail user agents now support HTML content,
80
Enterprise Web Services Security
allowing email messages to be richly formatted like a Web page with embedded graphics, text effects, and so forth. One side effect of this is that a spammer can detect when victims read their spam message (thereby confirming their address) by using an image tag with a query string that identifies the user. In other words, something like
This tracking scheme, called a Web bug, displays an image, but the query string (the email= part) can be tracked by the source so that the spammer knows when a message has been read. Web bugs are used by the service at DidTheyReadIt (http://www.didtheyreadit.com) to allow someone to track when an email that they send is read. Message Tag (http://www.msgtag.com) and Re@dNotify (http://www. readnotify.com) sell similar systems that allow email read receipts without the recipient’s knowledge. Companies have responded to user’s privacy concerns by creating products that block these notification systems. An example is the EmailTracking Blocker at http://www.wizard-industries.com/trackingblocker.html. The SMTP protocol is a simple one and very easily forged. An attacker is able to send a falsified email message by connecting to an SMTP server using a Telnet program. They then send commands to create the email message. The simple protocol allows someone with no special tools to spoof the email system. The commands used by a spoofer to send a message are simple, as shown below: HELO sender.example.com (or EHLO for ESMTP) MAIL FROM: RCPT TO:
[email protected] DATA
The HELO command introduces the sender to the SMTP server. EHLO is used with an extended SMTP (ESMTP) session. ESMTP adds features to SMTP such as pipelining and extended error status codes; if a client sends EHLO and the server responds with an error, they fall back to standard SMTP and send HELO. The MAIL FROM command specifies the sender’s from address. The RCPT TO command specifies who the mail is being sent to. The DATA command introduces the body, which follows the DATA command. The headers for the message body (the From, To, Subject, CC, and so forth) are sent first, followed by a blank line. Then the body of the message is transmitted. The end of the message is signified by a single period on a line by itself.
The Internet and World Wide Web Infrastructure
81
The simplicity of the SMTP protocol allows easy spoofing. The MAIL FROM from address is usually not verified in any way, so it is easy to spoof mail that appears to come from the boss. One possible means of tracking the sender of the spoofed mail uses the sender’s IP address, which is logged by the SMTP server. However, the protocol itself provides no assurance that mail really did come from who it says it came from. Another problem is that SMTP is a store-and-forward protocol. When an email is stored on an intermediate system, it can be read by the administrator of that system. The protocol provides no privacy protection for the mail being transferred or stored. Proof of origin for email can be obtained by using software that adds digital signatures to the email body. The two most common email security packages are Pretty Good Privacy (PGP®) and Secure MIME (S/MIME). A free version of PGP exists, called GNU Privacy Guard (GPG). PGP, GPG, and S/MIME can also provide privacy protection for email by encrypting it using the recipient’s public key. PGP and GPG are designed to be infrastructure free; anyone can use them without having to register their identity. S/MIME uses a public key infrastructure system to register users and issue them keys. PGP and S/MIME are very different in detail, but they share the common goal of adding security to the SMTP protocol without requiring changes to the protocol. This allows the existing email infrastructure to be used for important business communications while avoiding spoofing and tampering. Server Vulnerabilities The Internet is built using a client-server architecture. Many of the basic protocols that make the Internet work were designed before the idea of client-server systems took hold. Servers have access to information that clients need and present an interface to allow the clients to download the information. Prior to the creation of the Web each protocol had its own client-side program: an FTP client to access FTP servers, a Telnet client for terminal services, a mail client for email, and so forth. The primary uses of the early Internet were for email, file transfer, and net news (Usenet). The Gopher system (developed at the University of Minnesota) and the World Wide Web sprung from the early file-oriented systems. Gopher was an early textonly menu-driven system for organizing a library of documents with links; the Web is much more familiar to Internet users today. (However, there still are a few Gopher servers running.) Both the Gopher and the Web were designed to solve the same problem: it’s easy to download something you’re interested in if you know where it is, but finding it is the hard part. Allowing an organization to display its library of information on a page that users can easily traverse makes it easier for
82
Enterprise Web Services Security
users to find what they’re looking for. Because of online business and search engines, the Web has become an important part of our lives. Web Server Vulnerabilities The move from individual protocol-specific services to the Web did not eliminate the need for Web servers. The early attempts at a Web infrastructure were similar to the Gopher system: a document with links to other documents. While this was useful, it was quickly recognized that something needed to be added to allow Web content to be specific to a particular user or customer. The need to make page content more dynamic was first met with the use of common gateway interface (CGI) programs. A CGI program executes in response to a user’s query and returns a resulting HTML page. This allows almost unlimited flexibility in how a Web site responds to a user’s request. Anything that the system can do locally can be reformatted into HTML output. Another feature added to Web servers was the ability to serve dynamic HTML (or active server pages). A dynamic page has an embedded script program that executes on the server to prepare the HTML output transmitted to the user. Database queries can be executed and inserted into the body of the HTML page, for example. Security concerns for Web servers depend on how complex the site is and how sensitive the data is that the site manipulates. The popular Web server programs (Apache, Microsoft IIS) have had multiple vulnerabilities discovered that have exploits available. The first concern is to ensure that the software on your Web server is up-to-date with patches. The next concern is for the content of your Web site. Files should be protected so that they cannot be modified by a remote user. On Apache, the Web server usually runs as user nobody. You can protect your Web site by ensuring that the user nobody does not have write access to any site content. Similar configuration is available for Microsoft IIS, where a user IUSR_servername is created to run the Web server processes; access control lists can be applied to Web content to deny that user write access. Failure to do this opens your site to being defaced by someone who can exploit a Web server flaw. Sensitive content on your Web server should be placed outside the directory tree used by the Web server. If possible, it should be stored on a separate machine with restricted access. For example, if you are collecting credit card records for processing orders, you should ensure that those records are protected. Many times sites have been subject to extortion when an attacker manages to expose customer credit card information [News00]. Other Vulnerabilities There are other commonly used servers on Internet-facing systems. For example, many Web sites use database systems to provide information for dynamic HTML
The Internet and World Wide Web Infrastructure
83
pages. Often the database servers are colocated with the Web server. Many of the concerns expressed above apply in this case as well. You should ensure that the software is kept up-to-date and limit access when possible. It isn’t necessary, for example, to allow any arbitrary host on the Internet to send queries to your database server. You can usually limit access so that only the local host is permitted database access. Any other service running on your Internet-facing hosts should be given the same treatment. You should consider whether it makes sense to expose your services to the Internet at all. Providing a Web interface may allow you to move the servers inside where they can be protected by your firewall.
SUMMARY In this chapter we introduced the Internet and covered the basic building blocks of a Web-centric Internet application, including protocols used for common transaction types such as Web and email. We discussed the aspects of these building blocks that cause security problems in order to introduce the ways in which these problems can be solved. We started with a discussion of the overall Internet architecture and its domain-based concepts. We then explored some of the specific security challenges posed to Internet clients, networks, and servers. We went into detail regarding client-based vulnerabilities introduced by Web browsers and the Java virtual machine. We similarly explored some of the issues concerning TCP/IP, HTTP, and SMTP, three key protocols within the Internet environment. We concluded with a discussion of server vulnerabilities, concentrating on those for Web servers and other types of servers, such as applications and database servers that are frequently found in Web Services applications.
REFERENCES [Achohido04a] Achohido, B., “Sasser Inspires Raiders to Jump In.” USA Today, June 10, 2004, p. B.03. [CERT03] CERT Coordination Center, “CERT Advisory CA-2003-20 W32/Blaster Worm.” Available online at http://www.cert.org/advisories/CA-2003-20.html. [Griffiths02] Griffiths, Richard T., “History of the Internet, Internet for Historians (and just about everyone else).” Available online at http://www.let.leidenuniv. nl/history/ivh/frame_theorie.html. [News00] C|Net News.com, “Company Says Extortion Try Exposes Thousands of Card Numbers.” Available online at http://news.com.com/2100-1017-249772. html.
84
Enterprise Web Services Security
[RFC791] Internet Protocol, DARPA Internet Program, Protocol Specification. Available online at http://www.faqs.org/rfcs/rfc791.html, September 1981. [RFC793] RFC 793, Transmission Control Protocol, DARPA Internet Program, Protocol Specification. Available online at http://www.faqs.org/rfcs/rfc793.html, September 1981. [RFC2616] Fielding, R. et al., “Hypertext Transfer Protocol—HTTP/1.1.” Available online at http://www.w3.org/Protocols/rfc2616/rfc2616.html. [Securiteam01] Beyond Security, “Attackers Managed to Obtain Microsoft Digital Signing Keys.” Available online at http://www.securiteam.com/windowsntfocus/ 5VP0P0K3PY.html. [Venners05] Venners, Bill, “Why Security.” Available online at http://www. artima.com/insidejvm/ed2/securityP.html, April 6, 2005. [ZDNet04] ZD Net, “Study: Unpatched PCs Compromised in 20 Minutes.” Available online at http://news.zdnet.com/2100-1009_22-5313402.html.
5
Web Services
In This Chapter Web Services Standards XML SOAP WSDL UDDI Web Services Toolkits Summary References
hile the Internet and the Web provide the basic plumbing and protocols for enabling global communications, Web Services provide the lingua franca that transforms the Web from islands of disparate, disconnected components into a common marketplace. Web Services is in some ways returning us to a pre–Tower of Babel age where language barriers disappear. When coupled with the Internet’s global reach, geographic and political boundaries begin to disappear as well. Web Services refers to a set of system interfaces that are being built on two predominant underlying standards: eXtensible Markup Language (XML) and Simple Object Access Protocol (SOAP). You can think of XML as the basic grammatical elements for constructing a letter (words, sentences, paragraphs, etc.) and SOAP as the standard way of, or form for, constructing the letter itself and its envelope (heading, body, salutation, etc.) in a way that allows the post office to
W
85
86
Enterprise Web Services Security
route and deliver the letter. The standards give Web Services its language and platform independence and fuel part of the excitement about the technology. The standards are also extensible, allowing organizations to independently build on the core standards to extend Web Services for various capabilities, such as security.
WEB SERVICES STANDARDS Four key standards bodies coordinate and promote the technologies underpinning Web Services. The Internet Engineering Task Force (IETF, www.ietf.org) is an open international community concerned with the evolution of key Internet technologies such as the Internet Protocol (IP), the Transmission Control Protocol (TCP), and the HyperText Transport Protocol (HTTP). The World Wide Web Consortium (W3C, www.w3c.org) is the home of many key XML standards and of two key Web Services standards: Simple Object Access Protocol (SOAP) and the Web Services Description Language (WSDL). The Organization for the Advancement of Structured Information Systems (OASIS, www.oasis-open.org) is the home of the Universal Description, Discovery, and Integration (UDDI) specifications. OASIS is focused on the continued evolution of UDDI and is also the home of many of the Web Services security standards such as WS-Security. The Web Services Interoperability Organization (WS-I, www.ws-i.org) is working with industry to promote interoperability among vendors across languages, platforms, and applications. Web Services builds on five key protocols: HTTP, XML, UDDI, WSDL, and SOAP. Web Services use HTTP and HTTPS (secure HTTP) as the standard transport protocols and XML as the standard data format for implementing both underlying service interfaces and data exchange formats. Web Services expose services using standard protocols for discovering, describing, and invoking those services (UDDI, WSDL, and SOAP, respectively). Figure 5.1 illustrates the three standard protocol stacks relating to these functions: HTTP forms the foundation for each, and XML forms the next layer, with the discovery, description, and invocation protocols forming the uppermost level in each stack.
Function
UDDI
WSDL
SOAP
Data Format
XML
XML
XML
Transport
HTTP
HTTP
HTTP
Discovery
Description
Invocation
FIGURE 5.1 Web Services standard protocol stacks.
Web Services
87
Web Services implements a services-oriented architecture (SOA), as illustrated in Figure 5.2, consisting of providers, brokers, and requestors. Service providers register the locations and descriptions of their services using UDDI and WSDL. Service requestors use these same protocols to discover the services and obtain the location and description information they need for binding to and using the services using SOAP.
r ip De sc i ce sh Se rv 1. P ub li
ce n o r vi S e ip ti v er escr sco d D n Di 2. on a i cat
Lo
tio n
Broker
3. Bind to Service Provider
4. Invoke and Utilize Service
Requestor
FIGURE 5.2 Web Services’ SOA.
SOAP uses a simple request-response model, as shown in Figure 5.3, where the requestor, acting as the SOAP client, requests services from a provider, acting as a SOAP server, and the provider provides the requested services across a SOAP interface.
Request
SOAP Client (requestor)
XML Messages
Response FIGURE 5.3 SOAP’s basic request-response model.
SOAP Server (provider)
88
Enterprise Web Services Security
In the last chapter, we discussed HTTP and the key role it plays in the Internet and in Internet-based technologies. In this chapter, we will delve deeper into the other four foundational standards underpinning Web Services (XML, SOAP, WSDL, and UDDI) and introduce much of the terminology and concepts we will use in later chapters when we turn our attention to the specific Web Services standards addressing security.
XML XML [XML00] is the standard language for Web Services. It lays the foundation that other standards build upon. At its heart, XML is a markup language for describing document content. It is based on the Standard Generalized Markup Language (SGML), which is a standard for describing electronic documents. The extensible part of XML’s name comes from the language not being based on a set of predefined tags, but being based on the concept that you can customize the tags to meet the needs of any particular Web Service or application. Elements and Attributes Listing 5.1 presents a simple XML document. The XML content is made up of one or more elements, where each element is encapsulated between start and end tags. The start tag is a word, the name of the tag, enclosed by angle brackets, that is, . The end tag is the same tag name enclosed by an open angle bracket followed by a slash and closed by a close angle bracket, that is, . The content, or data value, is whatever information appears between the start and end tags including other XML structures. In the example, the father’s name “Richard” and mother’s name “Kim” are represented as data. Elements that do not contain any content can use a simplified form where a slash and close angle bracket terminate the element as part of the open tag, that is, . You would use this tag format to indicate null values or in instances where only attributes are associated with an element. LISTING 5.1
A Simple XML Document
Richard Kim
Web Services
89
george mary
Attributes add noncontent information to a tag and appear between the tag name and the closing angle bracket on an element’s start tag. Attributes are name/value pairs where the left side is the attribute name and the right side its value, the two being separated by an equal sign. Attribute values must be quoted using either double (“”) or single (‘’) quotation marks. Attributes are limited in several ways: they cannot contain multiple values (making them difficult to expand) and they cannot be used to describe structures. The tag in the example contains an age attribute. Whether you should represent something as content or as an attribute value depends on whether it needs to be visible, as part of the document’s content, or simply available for some other reason, processing within your Web Service, for example. As a general rule, you should store data as content and use attributes for information that is not relevant to the data itself, but is necessary for the data’s interpretation or processing. XML documents normally begin with a prolog section. The prolog includes everything up to the root element. The first statement in the prolog is the XML declaration that begins with the literal string of characters “ Richard Kim george mary
You will sometimes hear someone describe an XML document as being well formed and valid. Valid documents are well formed, but well-formed documents are not necessarily valid. Being well formed is the minimum requirement for any XML document. Being well formed simply means the document conforms to the basic syntactical rules laid down in the defining W3C reference for the XML version being used [XML00]. At a minimum, the document Begins with an XML declaration statement Contains one or more elements
92
Enterprise Web Services Security
Has a single root element encompassing the entire document Has each element properly opened and closed (have both a start and end tag) Is properly nested (elements cannot overlap) Has attribute values in quotes and has the standalone attribute in the profile statement set to “yes” (it is not necessary to have any of the elements or attributes declared in an XML schema or to have the elements or attributes be in any order). In addition to the minimum rules for being well formed, valid XML documents must also follow the structural rules defined by an XML schema; this includes adhering to element and attribute names, relationships, and values where appropriate. To be valid, the document must follow all of the rules in the structural description plus have the standalone attribute in the profile statement set to “no,” —indicating that a description is required. Schemas XML schemas are XML documents that describe an XML namespace [Schema001, Schema101, Schema201]. XML schemas are generally created as separate files and saved with dot XSD (.xsd) file extensions. Being XML documents, XML schemas must follow the same rules as any other XML document in order to be considered well formed and valid. Like all XML documents, an XML schema begins with a profile statement identifying the document as an XML document and the XML version in which it is written. The root element for an XML schema document is a element. The element can contain an optional namespace reference, which causes the schema itself to be validated against that reference (you will normally use the W3C XML schema definition for this purpose). The typical namespace reference in an XML schema includes the following:
This namespace reference tells whatever XML validation software you may be using three things: schema elements will be prefixed with the characters “xs,” they are to be validated against the W3C schema definition standard, and all elements appearing in the schema are to be qualified with a namespace prefix. Including W3C’s XML schema definition in this way causes the schema validation software to validate the basic schema format against the schema standard, thus avoiding issues with document conformance caused by invalid schema structures. Requiring elements to be namespace qualified reduces the potential for errors caused by misspellings or ambiguities in element or attribute names.
Web Services
93
The schema element’s contents are a series of rules describing the structure and content of valid, conforming documents. The rules are written in terms of and elements defined in XML schema. The elements and attributes making up the document are defined as and rules, which must accurately reflect the number, order, and relationships among elements and attributes appearing in conforming documents. The content of those elements and attributes are described through and rules that define constraints in terms of the data types and values to which associated elements and attributes must adhere. Listing 5.3 illustrates the overall structure of an XML schema document. Each rule corresponds to an element in a conforming document. Elements are either simple or complex depending on their content: simple elements are ones whose content can be described in terms of simple data types; complex elements are ones that can contain other elements or attributes. Each rule corresponds to an attribute in a conforming document. Attributes can only contain simple data types; attribute definitions, therefore, must follow many of the same rules as those for simple elements. LISTING 5.3
Sample XML Schema Format
simple_element_rules = ... + ... + attribute_rules = ... + ... + complex_element_rules = ... + ... + ...
Listing 5.4 repeats our earlier example, this time with a schema reference appearing on the root element. The schema reference includes two basic pieces of information: the default namespace to use, if any, and the schema file’s location. The schema validation program uses the default namespace for validating element, attribute, and data type names that do not include a prefix or namespace qualifier. A default namespace is not needed if all the items in a document are namespace qualified.
94
Enterprise Web Services Security
LISTING 5.4
Sample XML Document with Schema Reference
Richard Kim george mary
The first statement in the schema reference in Listing 5.4 sets the default namespace to the schema’s target namespace: xmlns="http://www.xyz.com"
This is accomplished using an xmlns attribute without a prefix, which tells the validation software that any references that are not prefixed belong to this namespace. While the namespace name looks like a URI, it really isn’t; it is basically a name, or label, that identifies the namespace. The second statement identifies the XMLSchema-instance namespace, which is necessary for the schema reference to use the schemaLocation attribute: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
The final statement in the schema reference maps the namespace to a schema document: xsi:schemaLocation="http://www.xyz.com
family.xsd"
The first half of the schemaLocation attribute’s value contains the namespace name; the second half contains the schema file name. Listing 5.5 displays the schema document contained in family.xsd. The schema definition identifies , , , and as complex elements, meaning that they can contain attributes, other elements, or both. The element in the element’s definition indicates the element can contain unspecified attributes (this entry is necessary if the example
Web Services
95
document in Listing 5.4 is to validate successfully, because the schema does not include a definition for the age attribute, which is included on the element in the example). The element included as part of the element’s definition permits that element to include unspecified elements that can occur zero or more times (this flexibility is needed if our example document is to validate, to handle the elements that are included as part of the node in the example document, but are not defined in the schema). Both the and elements are defined to simply contain xs:string type data. LISTING 5.5
Schema for Sample Document
A number of validating XML processors are available for testing whether documents are well formed and valid. Several attainable by downloading them from the Web include Apache’s Xerces2, Altova’s XMLSpy™, and Microsoft’s MSXML [XERCES2, XMLSPY, MSXML].
96
Enterprise Web Services Security
Transformations One of XML’s major benefits is that it separates content from format. Thus, different Web Services applications can use the same XML document even though one wants to display it in a Web browser, one wants to print it, and another wants to render it on a handheld device. Each can customize the presentation or format to fit their needs using style sheets. The eXtensible Stylesheet Language (XSL) is the presentation side of XML [XSL01]. XSL is a language for developing style sheets that describe the presentation characteristics for a family of XML documents. The term style sheet comes from XSL style sheets containing stylistic formatting information, such as fonts, colors, character sizes, character emphasis (bold, italic, etc.), and effects (underline, strikethrough, etc.) and from this stylistic information being collected into aggregates, or sheets, that are normally stored as separate files. XSL style sheets are XML documents. Three technologies make up XSL: XSL Transformation (XSLT), XML Path Language (XPath), and XSL Formatting Objects (XSL-FO). XPath provides capabilities for referring to parts of an XML document. XSLT and XSL-FO use XPath and deal more directly with the presentation of the document. XSL breaks presentation into two parts, as illustrated in Figure 5.4: transformation and formatting. The XSLT transformation process takes an XML document and a set of transformation rules in an XSLT document and processes the XML document against those transformation rules, producing a result tree [XSLT99]. The result tree may be significantly different than the tree that would be created directly from the original document: elements may be deleted, added, renamed, or rearranged, or additional text may be added.
XML Document
Result Tree XSL Transform
XSLT
FIGURE 5.4 XSL processing.
XSL Formatter
Rendered Document
Web Services
97
XSLT provides the language for writing transformation rules for translating a source document into a result tree. Each rule is made up of two parts: a pattern that is matched against the source document and a template that maps the matching source to the result tree. XSL processing involves a five-step process: 1. Convert the source document into a source tree. 2. Convert the XSLT style sheet into an XSL tree. 3. Step through the source tree processing each node by: Searching the XSL tree performing a pattern match against the template rules. Reflecting the results from the action specified by the matching templates in the result tree. 4. Process node lists in the source tree by processing each node individually. 5. Process unmatched nodes by copying them to the result tree. The XSLT processor performs steps 3 and 4 recursively. When finished, the XSLT processor may write the result tree to a file, display it, or pass it to another process depending on the processor and the options selected. The XSLT processor’s default behavior is to “walk” the source tree, outputting text nodes to the result tree. XSL-FO adds the formatting elements necessary to transform result trees into a form suitable for rendering on a specific device. The XSL-FO formatting process combines cascading style sheets (CSSs) and formatting object classes to create areas that possess specific formatting and rendering traits mapped to the geometry of the output device [CSS298]. CSS is a rule-based language for writing style sheets that describe presentation information. It is called cascading because it uses a parentchild hierarchy for passing information from higher to lower levels within the document and in resolving collisions where more than one statement specifies style information for a given element. XSL-FO allows you to tie these rules to specific areas within the target document or to particular types of output devices. XSL-FO defines each node in the result tree as a formatting object. SL-FO provides a set of typographic classes (page, table, and paragraph) for mapping these objects to a presentation. Each class represents a particular formatting behavior. XSL-FO classes include block (which is used for paragraphs, titles, and captions), externalgraphic, footnote, list-block, simple-page-master, static-content, table, title, and region. XPath provides the syntactical elements for addressing (referencing) and selecting parts of an XML document [XPATH99]. The syntax is similar to that used for URIs and for DOS and UNIX filesystem references including slashes to separate parent and child nodes, single and double dot operators for relative references, and
98
Enterprise Web Services Security
a double slash operator for selecting all the elements of a particular type. The language also includes wildcard characters to assist navigation and operators to aid element selection. The XML Pointer Language (XPointer) complements XPath by providing a grammar for pointing to a specific, marked anchor point within a document [XPointer02]. Using XPointer, your Web Service can identify fragments within an XML document and then point to those fragments. Fragments may be either points, where a point is a position within a document, or ranges, where a range is a document segment defined by two end points. XPointer includes the functions necessary for navigating and manipulating points within a document. Listing 5.6 illustrates a very simple XSLT style sheet for the sample document we presented earlier. The XSLT begins with an XML prolog statement that identifies it as an XML document. The element is the root element. The element includes the XSLT transform namespace to reference the XSLT language constructs throughout the remainder of the style sheet. The first element within the element is the element. Each template element defines a section of output in the response tree. A style sheet can contain however many elements are needed. The element contains a match attribute, indicating it is to be matched against the root node of the document; the "/" is an XPath expression signifying the root node. The element contains XSL statements indicating the actions to be performed when a matching node is encountered. In the example, a looping construct is used to walk through however many “family/parents” nodes might appear in the document. This again is written as an XPath expression. The value-of statements output the contents of the and elements to the result tree. XML tags encapsulate the value-of elements: and . These are output directly to the result tree. So, if this XSLT were processed against the sample XML document presented earlier, it would output Richard and Kim to the result tree. LISTING 5.6
Sample XSLT Style Sheet
Web Services
99
SOAP XML provides the syntactical foundations for Web Services. SOAP fleshes out this foundation, expanding the vocabulary and adding the semantics for basic message exchange between Web Services clients and servers. SOAP is a simple, text-based protocol for exchanging information between two endpoints [SOAP002, SOAP102, SOAP202]. SOAP is based on a stateless, oneway message exchange protocol where one endpoint sends a message and the other receives it. You can easily build more complex, two-way message exchange protocols from this foundation. Two-way exchanges can be either synchronous, where one party waits on the other, or asynchronous, where the party sending the message continues on with other processing while waiting for a response. SOAP uses XML for its messaging format and supports two messaging styles: self-describing, document-style messages, and encoded, SOAP remote procedure calls (RPCs). The client-server, request-response model shown earlier in Figure 5.3 is the standard framework for the two-way Web Services client and Web Services server interactions we are most interested in when it comes to Web Services security. In this framework, the SOAP client initiates a request by packaging information describing the request into an XML document, following whatever encoding rules have been agreed upon by the two parties, and sends this request to the SOAP server. The SOAP server decodes the message, interprets the request, and formulates a response. The SOAP server packages the response as an XML document, again following whatever encoding rules have been agreed upon, and returns the response to the SOAP client. The Web Services client and server can interchangeably interact in the SOAP client and server roles, where one is the client and the other the server and vice versa, in different message exchanges. SOAP messages adhere to a standard format and carry text/xml as their multimedia Internet mail extensions (MIME) type. Figure 5.5 illustrates the four components of a standard SOAP message. The outermost component is the SOAP envelope, which is mandatory. The can contain a header, which is optional, and a body. A SOAP entry can contain one or more header entries. Each SOAP entry can include a "mustUnderstand" attribute to indicate whether the final recipient, or any of the actors between the originator and the final recipient, must be able to process that information in order to process the message. The element is also a mandatory element. The SOAP of a message
100
Enterprise Web Services Security
carries the primary information, or payload, being communicated between the SOAP client and SOAP server. Information is encoded in the depending on the message exchange protocol being used: document-style or RPC. With document-style messages, the conforms to an application-defined schema, which may be identified as a namespace in the message itself. With SOAP-RPC style, the is encoded following an agreed upon encoding scheme. Errors that occur during the transmission or processing of a message are called faults. The SOAP carries details about how to handle various types of faults, in addition to the basic payload, in a special element.
Envelope
Header
Body
Payload
Fault
FIGURE 5.5 SOAP message structure.
Document Style Messages Document-style SOAP messages leverage the full power of XML for describing, encoding, and validating messages. Document-style message formatting is ideal for implementing messaging interfaces between Web Services components where message content and format can vary and for asynchronous exchanges. Web Services applications normally choose to serialize document-style messages using XML Schema and literal encoding. XML schema is more powerful than RPC for representing complex messages, and XML document format is more natural for business documents such as invoices, receipts, orders, shipping manifests, etc. One draw-
Web Services
101
back of document-style messaging is the difficulty in identifying the specific process or service being requested. SOAP header entries are one option for clarifying and exchanging process information as part of the message; a top-level element, named for the process being requested, wrapping the XML payload is another. Listing 5.7 illustrates the SOAP document-style message exchange format. The message follows standard SOAP formatting rules: it is an XML document, it has an element as its root, and it contains the mandatory element. The message content is included as a child element directly under the element and carries with it namespaces for validating the message structure and content. LISTING 5.7
SOAP Document-style Format
Richard Kim
Web Services using SOAP document-style messages, at some point, must deal with parsing the XML documents into data structures the Web Service can understand. Two application programming interfaces (APIs) are available to support this translation process: the Simple API for XML (SAX) [SAX01] and the Document Object Model (DOM) [DOM198, DOM200, DOM302]. SAX is an event-based parser where the Web Service passes the XML document it wants to process to the SAX parser, and the SAX parser reports parsing events back to the service by calling service-specified callback routines. You can think of the callback routines in the same vein as event handlers. DOM is a tree-based parser where the Web Service passes the XML document it wants to process to the DOM parser, and the DOM parser reads the document, in its entirety, and creates an in-storage tree representing the document. The service can then navigate, read, modify, and update the tree nodes through DOM functions. Which parser is better? It depends. SAX is generally faster and better for situations where you simply need to extract a few elements from a document. DOM is more appropriate when more complex processing and navigation is needed.
102
Enterprise Web Services Security
XML Events provides language extensions for integrating event listeners and handlers with DOM event interfaces [XMLEvents02, DOMEvents200, DOMEvents302]. DOM Level 1 defined high-level interfaces including Document, Node, Attr, and Element. DOM Level 2 added the concepts of event capture and flow, methods for attaching event handlers, and mouse events. DOM Level 3 adds keyboard events. Event handlers are critical in asynchronous message exchanges where the sender continues on with some other processing while the receiver formulates a response, as is the concept of message correlation. Message correlation involves tying one message to another, tying a request to a response, for example. The Web Services Routing Protocol (WS-Routing) defines the SOAP header syntactical elements for correlating and routing messages in both one-way and twoway exchanges [WSRouting01]. Figure 5.6 illustrates a SOAP document-style message exchange between a SOAP client and server. The SOAP client uses its internal variables, an XSLT, and a DOM parser to create an XML document that it sends to the SOAP server. The SOAP server reverses the process to extract and validate the data items from the XML document and populate its internal variables. The SOAP server and client reverse roles to exchange return values.
Variables
XSLT
XML Document
... ... ...
... ... ...
XML Document
XSLT
... ... ...
... ... ...
Variables
Request
XML Messages
SOAP Client (requestor)
SOAP Server (provider)
Response Variables
XSLT
XML Document
... ... ...
... ... ...
XML Document
XSLT
... ... ...
... ... ...
FIGURE 5.6 SOAP document-style message exchange.
Variables
Web Services
103
RPC-Style Messages SOAP-RPC provides a standard way to serialize objects, data structures, and content to XML. SOAP-RPC provides a platform, language-independent protocol for RPC-style messaging in multiplatform environments (think Java and .Net). SOAP-RPC is a lightweight protocol for implementing RPC capabilities and can be considered an alternative to other RPC capabilities such as distributed component object model (DCOM) and common object request broker architecture (CORBA). SOAP-RPC is generally, though not necessarily, synchronous—the client makes the call to the server and normally waits until the server returns a response. Figure 5.7 illustrates the major components and steps involved in a SOAPRPC call. The process begins with the client calling a remote procedure belonging to the server. A proxy stub running in the client’s process space marshals the parameters, gathering them into a standard form, and serializes them for transport across the transport layer to the server. The server receives the call and reverses the process. A proxy stub running in the server’s process space deserializes the transport stream, unmarshals the parameters, and invokes the called process or service on the server. The reverse process returns the server’s response to the client.
8. Generate Response
7. Program Executes
1. Call Procedure SOAP Client
2. Marshall Parameters
SOAP
SOAP-RPC
Stub
Server
Stub
6. Unmarshall
SOAP 3. Serialize
5. Deserialize 4. Transport
FIGURE 5.7 The SOAP-RPC model.
SOAP supports several ways of encoding the RPC parameters. You use the attribute on an element to control the encoding scheme for data within that element’s scope. One option is to use XML schema and a schema of the application’s choice for encoding the data; another option is to use SOAP’s builtin types (called Section 5 encoding because valid values were originally defined in
encodingStyle
104
Enterprise Web Services Security
Section 5 of the SOAP specification) in combination with XML schema. This has become a popular technique and is the approach illustrated in Listings 5.8 and 5.9. Listing 5.8 illustrates a SOAP-RPC-style request message. The first thing to note is the namespace declarations for using both XML schema and XML built-in types. The second is the element in the . The element identifies a namespace for validating header entries. The encodes the call to the remote procedure. The first child element in the element contains the remote procedure’s name (the remote procedure could be a program, a method within a dynamic link library, or some other programming unit the remote server can understand). In the example, the remote procedure has a single input parameter, a 1 × 2-integer array. The array type comes from the SOAP built-in types, the item types from XML schema. LISTING 5.8
SOAP-RPC-style Request Message
... 100 20 ...
Listing 5.9 illustrates the corresponding SOAP-RPC-style response message. In this case, the method response is returning two elements, both containing integer values.
Web Services
LISTING 5.9
105
SOAP-RPC-style Response Message
... 100 20 ...
Binding SOAP supports HTTP and email binding. Binding involves mapping the SOAP document onto the underlying transport protocol. SOAP supports both HTTP GET and POST. With HTTP GET, the SOAP message is returned in the body of the HTTP response message. With HTTP POST, SOAP messages may be conveyed in the bodies of both the HTTP POST and the associated response. SOAP email binding is not part of the basic SOAP specification. SOAP messages may be exchanged via Internet email using the Internet message format (RFC 2822) [SOAPEmail02, RFC2822]. The SOAP message may be part of the email message text or included as an attachment.
WSDL In order for Web Services components to communicate, they must first agree on the interface they will use for the communication. The interface specification includes the protocols they will use, the messages they will exchange, the order in
106
Enterprise Web Services Security
which the messages will be exchanged, and the general semantics of those messages. WSDL is a standard language for describing interfaces between Web Services components [WSDL01]. WSDL describes Web Services applications as a set of endpoints that exchange information in order to use each other’s capabilities. The endpoints may operate on either document or RPC-style messages. WSDL defines Web Service applications as collections of endpoints that are called ports. WSDL abstracts the endpoint definitions from their implementation by separating the messages that can be exchanged and the operations that can be performed from the specific protocols and specifications being used. Figure 5.8 illustrates the WSDL abstraction model. Examining this model from the inside out, WSDL messages are abstract definitions of the data being exchanged; WSDL operations group messages together to represent an interaction; WSDL port types are abstract operations performed using these messages; WSDL bindings are the protocol and format specification for a given implementation; and WSDL ports map the service to the implementation. The combination of these elements describes a Web Service interface. Service
Port
Port
Binding
Binding
portType operation
message part1...partn
message part1...partn
message part1...partn
Abstract Interface
FIGURE 5.8 WSDL abstract description of services.
The WSDL description for a service is made up of eight elements, as illustrated in Listing 5.10, which map back to the abstraction model. The element encapsulates the definition for a Web Service. The element encloses
Web Services
107
associated data type definitions. Data type definitions are encoded using XML schema and can include both simple and complex types. The element defines both the input and output messages for the service. The messages are defined in terms of message parts that can be separately represented and bound. The element defines the operations that can be performed and the directions of those operations through an element. The element defines message exchange through three primitives: input, output, and fault. The element defines the data formats and protocols for a port and maps the operations to a set of bindings; SOAP is used in the example. WSDL supports SOAP, HTTP GET and POST, and MIME binding operations. The defines each operation in terms of a sequence of input, output, and fault messages. Finally, the element binds the port and operations together into an endpoint using a element. LISTING 5.10
Sample WSDL Service Description
108
Enterprise Web Services Security
Simple service
Communication between the Web Services client and server may be either unidirectional or bidirectional. The element in the Web Services’ WSDL document describes the direction of the communications and the messages to be exchanged. Each message is described in terms of an abstract message that must be defined in a element in the WSDL document. W3C defines four primitive types of operations from the WSDL owner’s point of view. Assuming the Web Services server is the WSDL owner, the four types are: One-Way: Another endpoint sends an unsolicited message to the server. Request-Response: An endpoint sends a request to the server, and the server returns a response. Solicit-Response: The server solicits a response from another endpoint, and that endpoint responds. Notification: The server sends an unsolicited message to another endpoint. In each instance, the other endpoint may be another Web Services server or a client, depending on the application.
Web Services
109
UDDI If two Web Services components want to engage in an exchange, the question becomes, how does the requestor discover the interface for using the provider’s services? Universal Description, Discovery, and Integration (UDDI) provides a standard way of registering and discovering Web Services [UDDI02]. UDDI is built on the concept of a distributed, XML registry, or directory, where service providers can register their services along with descriptions of and pointers to those services. Requestors can then use the UDDI directory to discover information about a Web Service and how to invoke it. The UDDI Business Registry (UBR) is a global UDDI repository hosted by IBM, Microsoft, SAP, and NTT Communications to create a central repository for registering, publishing, and finding business services. You can find more information about gaining access to and using the UBR at UDDI.org (http://www.uddi.org/find.html). You can compare the contents of a UDDI repository to a telephone book where: White pages contain simple contact and descriptive information about a business. Yellow pages describe the business in terms of standard taxonomies such as business area, product group, geographic region served, and industry. Green pages describe the services a business offers and provides URIs for obtaining service description information and invoking those services. Information in a UDDI repository is arranged hierarchically as shown in Figure 5.9. A business entity element occurs once for each business in the repository. These elements hold descriptive information about each business and form the white and yellow page sections of the repository. One or more business service elements exist for each business entity. At least one business service element exists for each service the business offers. The business service element contains the name and description of the service and contains at least one binding template that points to the service and the corresponding technical detail. The binding template for a service includes a description of the service and a pointer to the service in the form of an access point. The access point is normally a URI pointing to the service’s interface description, for example, a WSDL file. The binding template also points to technical models (tModels) that contain technical specifications for the service that requestors use to determine how to invoke the service. UDDI provides a publisher assertion element to tie together business entity structures belonging to an organization, thereby making it possible to describe complex relationships such as a corporation and its subsidiaries.
110
Enterprise Web Services Security
FIGURE 5.9 UDDI directory hierarchy.
UDDI provides two APIs for accessing and manipulating information in a UDDI repository. The Publish API provides the interfaces you need for registering services, and the Inquiry API provides the interfaces you need for searching (discovering) and retrieving information from the repository. The Publish API includes interfaces for creating, editing, and deleting each of the five major structures. The Inquiry API exposes a Browse method for browsing each of the five major structures and a Direct Access method for retrieving each type of structure given a corresponding key. Listing 5.11 illustrates the structure. The element begins with basic identifying, locating, and description information about the organization providing the service; in this case, XYZ Corporation. The businessKey attribute contains the unique identifier, or key, for locating the business entity using the UDDI Inquiry API and for creating references to the organization from other UDDI structures. The organization description includes telephone and email contact information, in human-readable form, that potential clients can use to contact XYZ Corporation to learn more about their services. The and elements contain information both services and humans can use in making decisions about whether or not they want to use the services being offered. In the example, the element identifies the
Web Services
111
company by its Dun and Bradstreet number; the element contains entries tying the company to medical supplies and the U.S. by way of a Universal Standard Products and Services Classification (UNSPSC) code and an ISO 3166 country code, respectively. LISTING 5.11
Sample Element
operator="www.xyz.corp/uddi" businessKey="A3B41200-1891-43A4-4798-0000EC51231E"> "http://www.xyz.com/uddi/base_service.html" XYZ Corporation Import and Export All Calls Here J. Smith 123-456-7890
[email protected] Order Vitamin Supplements Order Vitamins Based on Type Input Order Quantity http://www.xyz.com/input_quantity ... ...
The structure provides information about one of the services XYZ Corporation offers, in this case, a service for ordering vitamins. The structure captures basic, descriptive information about the service and encapsulates a binding template collection that describes the technical details for using that service. The element provides a unique identifier for the business service, and the element ties the service back to the business entity providing the service. As shown in the example, you can set the element to an identifier different than that of the owning business (a concept called service projection). Service projection allows a business entity to offer another’s service. You use elements to capture the technical characteristics for a service including the service’s access point and pointers to technical model entries describing the standards needed to invoke the service. The contains the unique identifier for the binding template, and the ties it back to the business service structure associated with the . The element provides a URI to the service. The URI may be either a direct or indirect link to the service; the useType attribute specifies how to interpret the value:
Web Services
113
endpoint: URI points to a Web Services endpoint. bindingTemplate: bindingKey points to another binding template that can be accessed for technical details. hostingRedirector: UDDI repository address; the referenced repository must be queried to determine the access point. wsdlDeployment: URI points to a remotely hosted WSDL document for the service. The element links the service to the tModels describing the standards used when invoking the service. The entries describing services in a UDDI repository create taxonomies requestors can use for finding business entities and services by tying services to standards, specifications, constructs, and technical concepts. The UDDI technical model fills two important needs for the discovery process. The entries provide a way of mapping services to technologies (similar services tend to use similar technologies) and determining compatibility between services. Unlike the other UDDI structures we have discussed, entries exist outside the normal parent-child containment hierarchy used to capture information about business entities, business services, and binding templates. The associated with a Web Service points to the appropriate technical model entries through tModelKeys. Listing 5.12 illustrates the tModel structure corresponding to the service shown. The element contains pointers to relevant standards (WSDL, SOAP, and XML) requestors use to access the service. The tModelKey provides the unique identifier for the technical model and corresponds to the link in the . LISTING 5.12
Sample Element
XYZ Corporation Standard Service Standard Interface for XYZ's Web Services http://www.xyz.com/wsdl/web_service_standard_ binding.wsdl
UDDI provides publisher assertion structures as a way to create relationships between business entities in a UDDI repository. You use publisher assertion entries in situations where a single element cannot adequately describe a business entity. For example, it may be important to know whether two business entities are in partnership, one is the parent of the other, or one is synonymous with the other. The business entities in question could be multinational corporations, conglomerates, or departments within a single organization. The publisher assertion framework is flexible enough to support any of these types of relationships. The only requirement is that both entities assert the relationship with the other for it to be valid and visible to other organizations accessing the UDDI repository. Listing 5.13 shows an example where the business entity identified by the is identified as a holding company that owns the entity identified by the in a parent-child relationship. The UDDI specification defines three types of relationships: peer-peer, parent-child, and identity. The peer-peer relationship is used to create relationships between two equals, for example, two departments within a larger company. The parent-child relationship is used to create relationships in hierarchical organizations where one entity is owned by or reports to the other, for example, a parent organization and one of its subsidiaries, as in our holding company example. The identity relationship is used to show that two organizations are in fact one, for example, sales and marketing both operating out of the same department within a company, but represented as separate entities within the UDDI repository. LISTING 5.13
Sample Example
A3B41200-1891-43A4-4798-0000EC51231E 4B236890-2134-1219-3672-12468A342191
Web Services
115
Dynamic, runtime discovery is both one of Web Services’ fundamental goals and promises. UDDI and UBR are enablers for realizing those promises. As more businesses register and list their services in UDDI directories such as UBR, these goals become more of a reality. In addition to its use for the Internet, UDDI repositories are also an option for registering, querying, and finding services within both intranet and extranet environments. Novell and Apache offer open source UDDI 2.0 implementations that can be used for these purposes [jUDDI04, NsureUDDI].
WEB SERVICES TOOLKITS If you had to write all of the XML and Web Services elements we have discussed in this chapter from scratch using a simple text editor, the task would be overwhelming. Fortunately, toolkits are available that greatly reduce the complexity of this task. Unfortunately, the toolkits are technology, and sometimes platform, specific and the standards evolve so quickly that there is often a lag between the time a given version of a standard is released and the time the new features represented in that standard universally appear within the toolkits. The vendors participating in the development of a given standard frequently anticipate a new version of the standard’s content and include many of its elements into their own toolkits while the standard is undergoing final public review and comment prior to adoption. Knowing this can help if you are using a toolkit from such a vendor, but even this doesn’t always hold true. This means you have to check the toolkit and its version against the standards and features you need and be prepared to either defer some features or write code to insert some statements. Given this situation, a good starting point for .NET developers is Microsoft’s Web Services Developer Center (http://msdn.microsoft.com/webservices/). This Web site provides links to development and architectural overviews, downloads for Microsoft’s SOAP Toolkit, as well as for tools and code examples, tutorials on various components, and white papers for developing Web Services security applications in a .NET environment. Toolkits for J2EE (Java 2 Enterprise Edition) developers are also widely available. J2EE developers, however, frequently want to marry-up the toolkit they use with the applications sever they use. Most applications server providers also provide
116
Enterprise Web Services Security
a toolkit that includes the Web Services security features. For example, Apache’s WSS4J toolkit is available at http://ws.apache.org/ws-fx/wss4j/package.html; IBM’s Web Services Toolkit is available at http://www.alphaworks.ibm.com/tech/ webservicestoolkit; and http://dev.bea.com/codelibrary/code/examples_webservices.jsp points to the WebLogic platform from BEA Systems.
SUMMARY In this chapter we looked at the bedrock standards upon which Web Services builds; XML, HTTP, SOAP, WSDL, and UDDI provide the foundation on which other more advanced standards such as WS-Policy and WS-Security are built. XML provides the common language for creating and communicating information, and SOAP provides the standard message format. HTTP supplies the standard transport enabling any Web server to become a potential Web Services platform. WSDL adds the description syntax for describing and discovering the service interfaces necessary for Web Services clients and servers to communicate. UDDI brings discoverability through the concept of a standards-based, globally accessible XML repository. We looked at each of these key standards in terms of their basic concepts and capabilities including enough of the syntax and grammar to set the stage for the more advanced XML documents presented in subsequent chapters. For XML, we looked at document structure and introduced the concepts of tags, elements, attributes, and namespaces. We also briefly introduced XML schemas, which play a key role in validating XML documents, and stylesheets, which are instrumental for transforming, or “styling,” XML documents. For SOAP, we discussed its key header, its body format, and its two major messaging formats: RPC based and document style. We went into some detail regarding WSDL’s key role as the binding mechanism for Web Services and its elements for defining service and messaging interfaces. We concluded with a discussion of UDDI’s major components, white, yellow, and green pages, and the role they play in making services truly discoverable. IETF, W3C, OASIS, and WS-I are four key standards organizations involved in overseeing the development, continued evolution, and integration of these standards.
REFERENCES [CSS298] Bos, Bert, et al., “Cascading Style Sheet, Level 2: CSS2 Specification.” Available online at http://www.w3.org/tr/rec-css2, May 12, 1998. [DOM198] Apparo, Vidur, et al., “Document Object Model (DOM) Level 1 Specification Version 1.0.” Available online at http://www.w3.org/tr/REC-DOMLevel-1, October 1, 1998.
Web Services
117
[DOM200] Le Hors, Arnaud, et al., “Document Object Model (DOM) Level 2 Core Specification Version 1.0.” Available online at http://www.w3.org/tr/DOMLevel-2-Core, November 13, 2000. [DOM302] Le Hors, Arnaud, et al., “Document Object Model (DOM) Level 3 Core Specification Version 1.0.” Available online at http://www.w3.org/tr/DOMLevel-3-Core, April 9, 2002. [DOMEvents200] Pixley, Tom, editor, “Document Object Model (DOM) Level 2 Events Specification, Version 1.0.” Available online at http://www.w3.org/ tr/dom-level-2-events/, November 13, 2000. [DOMEvents302] Le Hegaret, Philippe and Pixley, Tom, editors, “Document Object Model (DOM) Level 3 Events Specification, Version 1.0.” Available online at http://www.w3.org/tr/dom-level-3-events, July 12, 2002. [jUDDI04] Apache Open Source Java UDDI Directory. Available online at http://ws.apache.org/juddi/. [MSXML] Microsoft Corporation, “XML Downloads.” Available online at http://msdn.microsoft.com/xml/xmldownloads/default.aspx. [NsureUDDI] Novell’s Open Source UDDI 2.0 Solution. Available online at http://www.novell.com/coolsolutions/feature/5699.html. [RFC2396] Berners-Lee, T., et al., “Uniform Resource Identifier (URI): Generic Syntax.” Available online at http://www.ietf.org/rfc/rfc2396.txt, August 1998. [RFC2822] Resnick, T., “Internet Message Format.” Available online at http:// www.ietf.org/rfc/rfc2822.txt, April 2001. [SAX01] About SAX. Available online at http://www.saxproject.org/, 2001. [Schema001] XML Schema Part 0: Primer. Available online at http://www.w3.org/ TR/xmlschema-0, May 2, 2001. [Schema101] XML Schema Part 1: Structures. Available online at http://www. w3.org/tr/xmlschema-1, May 2, 2001. [Schema201] XML Schema Part 2: Datatypes. Available online at http://www. w3.org/tr/xmlschema-2, May 2, 2001. [SOAP002] Mitra, Nilo, “SOAP Version 1.2 Part 0: Primer.” Available online at http://www.w3.org/tr/SOAP12-part0, June 26, 2002. [SOAP102] Gudgin, Martin, et al., “SOAP Version 1.2 Part 1: Messaging Framework.” Available online at http://www.w3.org/tr/SOAP12-part1, June 26, 2002. [SOAP202] Gudgin, Martin, et al., “SOAP Version 1.2 Part 2: Adjuncts.” Available online at http://www.w3.org/tr/SOAP12-part2, June 26, 2002. [SOAPEmail02] Highland, Mary M., et al., “SOAP Version 1.2 Email Binding.”Available online at http://www.w3.org/tr/SOAP12-email.html, July 3, 2002. [UDDI02] Bellwood, Tom, et al., “UDDI Version 3.0.” Available online at http://www.uddi.org/pubs/uddi_v3.htm, July 19, 2002. [WSDL01] Christensen, Eric, et al., “Web Services Description Language (WSDL) 1.1.”Available online at http://www.w3.org/tr/wsdl, March 15, 2001.
118
Enterprise Web Services Security
[WSRouting01] Nielsen, Henrik F. and Thatte, Satish, “Web Services Routing Protocol (WS-Routing).” Available online at http://msdn.microsoft.com/ ws/2001/10/Routing/, October 23, 2001. [XERCES2] Available online at http://xml.apache.org/xerces2-j/. [XML00] Internet Engineering Task Force, “Extensible Markup Language (XML) 1.0 (Second Edition).” Available online at http://www.w3.org/tr/rec-xml, October 6, 2000. [XMLEvents02] McCarron, Shane, et al., “XML Events: An Events Syntax for XML.” Available online at http://www.w3.org/tr/xml-events/, August 12, 2002. [XMLNS99] Namespaces in XML. Available online at http://www.w3.org/tr/RECxml-names, January 14, 1999. [XMLSpy] Available online at http://www.altova.com/xmlspy. [XPATH99] Clark, James and Steve DeRose, “XML Path Language (XPATH) Version 1.0.”. Available online at http://www.w3.org/tr/xpath, 16 November 1999. [XPointer02] DeRose, Steve, et al., “XML Pointer Language (XPointer).” Available online at http://www.w3.org/tr/xptr, August 16, 2002. [XSL01] Adler, Sharon, et al., “Extensible Stylesheet Language (XSL) Version 1.0.” Available online at http://www.w3.org/tr/xsl, October 15, 2001. [XSLT99] Clark, James, “XSL Transformations (XSLT) Version 1.0.” Available online at http://www.w3.org/tr/xslt, November 16, 1999.
6
Security Policy Basics
In This Chapter The Importance of Security Policy Steps in Developing a Security Policy The Security Policy Document Summary References
p to this point, we have been laying the foundations for much of the discussion to follow. We will now shift our focus from the why and wherefore of good security practice and the basic building blocks of Web Services to the details of translating risk mitigation strategies into security policies and those policies into implementations. We begin our “deep dive” in this chapter with a discussion of security policy and how it relates to an enterprise’s overall Web Services security strategy. Security mechanisms are only valuable if they are part of an overall security fabric that provides the level of protection both desired and thought to be in place. It is important that an enterprise’s security policy be comprehensive and thorough. Gold plating in one area while not protecting another more vulnerable area can be worse than no security at all since it can engender a false sense of security. What you should take away from this chapter is that security policy is important, that there really are methods available for developing good policies, and that policy must provide the underpinnings for an enterprise’s security strategy.
U
119
120
Enterprise Web Services Security
THE IMPORTANCE OF SECURITY POLICY Whenever you deploy a new Web Service, you are potentially creating a gateway into your organization’s information technology (IT) infrastructure. For customers, business partners, suppliers, and employees, the Web Service represents a new way to obtain information or services. For an intruder or hacker, the Web Service represents a potential path to the heart of your IT systems and networks and the sensitive information they may contain, such as client lists, customer credit card information, employee data, or health records. Each Web Service, therefore, represents exposure to a set of threats and a corresponding set of risks of loss or damage as a result of those threats. In this chapter we explain how a well-documented security policy can help deal with the real-world risks that almost all systems face. How do you eliminate the risks? You can’t. The complexity of the software and networking systems involved in today’s internetworked environments, especially for services you deploy across the Internet, make that an impossible objective to achieve. However, that doesn’t mean you can’t significantly reduce or even minimize your risks. You do that through risk management and the application of clear, consistent, well-defined security policies and procedures that identify your organization’s sensitive information and prescribe appropriate countermeasures for its protection. Minimizing your risks begins with security, and security begins with security policy. In Chapter 3, we discussed how security goals must map into security policies. These security policies in turn must map into implementations. An enterprise security policy establishes the rules for implementing applications, including Web Services, within an organization and is therefore the embodiment of that organization’s overall security goals. Your enterprise security policy needs to encompass your entire computing environment including people, technology, and operations. Defense-in-depth provides a comprehensive strategy where intruders must defeat multiple interlocking countermeasures before gaining access to critical assets. Defense-in-depth recognizes the need to trade off the risks that vulnerabilities represent against the costs of protecting against those risks. The National Security Agency (NSA) has created the Information Assurance Technical Framework Forum (IATFF) to promote the use of the defensein-depth approach throughout government and industry [IATF02]. Defense-in-depth advocates a three-step (protect, detect, and react) approach to creating a secure environment. The first step is to incorporate security services, such as authentication, authorization, access control, and auditing, into the security infrastructure in order to protect from attack. Recognizing that attacks are an unavoidable consequence of doing business in certain environments, the next step is to incorporate attack detection capabilities that allow you to detect attacks when they occur. The final step is to build in appropriate reaction and response capabilities to counter those attacks.
Security Policy Basics
121
Defense-in-depth also recognizes the need for different security strategies within different parts of the security infrastructure as a function of the degree of trust placed in the underlying components. For example, you may use different strategies and protection mechanisms in different parts of the security infrastructure depending on whether you are dealing with clients accessing services across the Internet, business partners accessing resources through a shared extranet, or employees accessing resources through an internal intranet. One of Web Services’ challenges within an enterprise is devising protection mechanisms that can simultaneously work across diverse environments. The number of defensive layers and the strength of the protection mechanisms you need within each layer depend on the sensitivity or value of the assets you are trying to protect and the trust you place in the internetworking infrastructure between those assets and the users trying to obtain access. The more you trust the infrastructure, the more willing you are to expose resources or data with fewer protection mechanisms as part of the outer layers. Figure 6.1 shows the different perspectives you must take in developing a security policy that includes Web Services. Web Services have an outside-in view of security. Web Services execute at the highest level of the applications stack. They assume adequate protections are already in place at lower levels. For example, Web Services clients accessing a service may be in the same or different network domains. The Web Service assumes adequate perimeter defenses are in place, as part of network security policies, to protect the underlying systems and infrastructure, regardless of whether clients are in the same or a different domain. In order to ensure consistency and completeness of coverage, an enterprise security policy must take the opposite approach and view the security problem from the inside out. It must address security from the perspective of the assets or information that need to be protected and then work its way outward to the perimeters that include Web Services. Web Service's Point of View Applications Network Systems Physical
Information Resources
Access Protection Protection Protection
FIGURE 6.1 Security from different perspectives.
Security Policy's Point of View
122
Enterprise Web Services Security
STEPS IN DEVELOPING A SECURITY POLICY An enterprise security policy specifies the rules for protecting the assets belonging to the enterprise. The enterprise security policy includes the individual policies and procedures for protecting various components of the IT infrastructure, ranging from the physical security of systems and networks to personnel security for users, operators, and administrators. Implementing adequate security policies requires commitment from upper management and communicating to everyone throughout the organization their roles and responsibilities with regards to the policy. You should not add security as an afterthought. To be successful, security policy must be a well thought out, planned part of your IT and Web Services infrastructure. How does an organization approach developing a security policy? Table 6.1 summarizes two approaches. The Internet Engineering Task Force (IETF) recommends the five-step approach depicted in the first column in its Site Security Handbook for developing site security plans [RFC2196]. The IATF recommends the six-step information systems security-engineering process shown in the second column [IATF02]. The processes are similar, but the IATF process is geared toward systems engineers and marries the process to the systems engineering discipline. We will use the IETF structure to outline the security policy development process because we believe it is clearer for those who are writing an organization’s security policy who may not be systems engineers nor be familiar with that discipline. Given that the aims of the two approaches are the same, you could choose to follow whichever you are most comfortable with. We will use the IATF framework as well to help clarify components of the IETF approach and to lay out the policy outline.
TABLE 6.1 Steps in Developing a Security Plan IETF Approach
IATF Approach
Identify assets you’re trying to protect
Discover needs
Determine threats you’re protecting them from
Define system requirements
Determine likelihood and loss potential
Design systems architecture
Implement cost-effective measures
Develop detailed design
Continuously review and improve
Implement system Assess effectiveness
Security Policy Basics
123
Identify the Assets You Are Trying to Protect The first question you must answer is, what information or assets are you trying to protect and why? The answer begins with your systems, networks, and workstations. At a minimum, you must provide availability and integrity throughout the IT infrastructure. Systems and networks must be available and accessible to whoever you define your user community to be. The systems must also ensure that only authorized users can create, modify, and delete the information the systems contain. Depending on the sensitivity of the information within your systems, you may also need to ensure confidentiality of either the information, its communication, or both. A secondary question is, what makes the sensitive information in your systems sensitive? It may be classified, it may be a matter of privacy, it may be a matter of organization or corporate confidentiality, or it may be due to legal obligation. Classified Information
The U.S. government uses a classification system and the need-to-know principle for managing its sensitive information [Orange85, CCIS04]. The basic classifications (unclassified, confidential, secret, and top secret) correspond to the damage the loss of the information would cause to the security of the U.S. In order to access information, individuals must possess security clearances authorizing them access to information at the level being requested and have an official need-to-know the specific information in question. While the complexity of such an information classification system is overkill for a nongovernmental organization, there is value in understanding the methodologies used by organizations that take information protection very seriously. Privacy
While we do not have a comparable system measuring the levels of sensitivity we have regarding personal information, most of us assume a basic right to privacy and the ability to control the information that is collected about us and how that information is used. Different kinds of organizations have varying degrees of legal and ethical responsibilities for protecting those rights. As described in Chapter 1, there are also expectations that businesses have in how their confidential information will be handled, as well as employee privacy expectations. A well-designed security plan recognizes the need to meet those expectations. Identify the Threats You Are Protecting Against Once you have an understanding of the information you are trying to protect, the next question is, what threats you are trying to protect it against? As we discussed
124
Enterprise Web Services Security
in Chapter 2, threats come in many different forms. The IATF framework identifies five types of threats of attack: Passive Active Close-in Insider Distribution Passive attacks include eavesdropping, where an opponent listens in on communications, and traffic analysis, where an opponent tries to determine the location and the identities of the parties to a communication. Passive attacks do not try to disrupt or modify communications or content. Active attacks take the opposite tack. Active attacks include: Masquerade: An opponent pretends to be someone else. Replay: An opponent retransmits previously captured transactions. Message Modification: An opponent alters parts of otherwise legitimate messages. Denial of Service: An opponent tries to disrupt a system’s operation. In today’s internetworked environment, attacks can come from any number of locations and can be aimed either directly at an organization or at a business partner or service provider connecting to its network or utilizing its services. Close-in threats can be characterized as being either internal or external and as intentional or unintentional. Internal threats come from employees and others with unfettered access to your IT system and its infrastructure. Intentional internal threats frequently come from disgruntled employees seeking revenge. Unintentional threats are simply people making mistakes, as explained by Hanlon’s Razor: Never attribute to malice that which can be adequately explained by stupidity. External threats come from outside your infrastructure and can be either intentional, such as a hacker trying to get into your systems, or unintentional, such as a failing network component on a business partner’s segment of a shared extranet flooding your firewall with extraneous packets. Trusted insiders pose one of the greatest threats because they already have access to at least the basic infrastructure you are trying to protect and they may have privileged accesses that increases the potential loss of any attack they launch. An intruder may also mount an effective close-in attack, but generally with less success than the trusted insider; it is easier for intruders to go after unprotected assets they can more readily steal. You should remember Houdini gained widespread fame and
Security Policy Basics
125
made a very comfortable living breaking out of safes because they were generally designed to keep people out rather than in. Remote access attacks generally look to either steal unprotected assets or to mount denial-of-service types of attacks. Distribution attacks occur during the manufacture or transport of hardware, software, or encryption key materials. In addition to the threats outlined in the IATF framework, there are also threats from man-made and natural disasters such as acts of war, terrorist attacks, floods, hurricanes, and tornadoes. These types of threats can be devastating to an organization, as demonstrated by the events of September 11, 2001. Map Threats to Probability of Loss and Cost All threats are not equal. Each threat carries with it a probability, or likelihood, that it will occur and an associated cost. The probability of occurrence is a function of the specific business and IT environment and the sensitivity of the information involved or attractiveness of mounting an attack. If your organization has a large Internet presence, a large number of traveling users connecting to its systems via laptops and modems, and is in a business where a successful attack could produce large gains, the potential threats and vulnerabilities could be high. If you are in a closed environment with little or no sensitive or valuable information to be had, the probability of an attack is likely to be low. Associated with each threat is a loss potential. The loss may be in terms of money, credibility, business goodwill, prestige, or competitive advantage. Whatever the form, you should be able to assign a monetary value to the loss. The result of this exercise is a set of rough guesses for the likelihood of and cost of a given threat. A set of ballpark estimates are more than adequate, as it’s not possible to accurately estimate either cost or threat level. Given the set of estimates for the likelihood of occurrence and the cost associated with each threat, you can create a threat-to-loss chart similar to the one shown in Figure 6.2. The threat-to-loss chart maps each threat to a likelihood of occurrence and a cost of loss. In the hypothetical mapping shown, denial-of-service and replay attacks are likely to occur and have a relatively high associated cost of loss. A message modification attack also has a relatively high cost of loss, but a relatively low probability of occurrence. The threat-to-loss chart can help you decide which threats to protect against and which to accept as a cost of doing business because associated with each cost of loss is a cost to protect. The Computer Security Institute (CSI) and the Federal Bureau of Investigation (FBI) annually publish a “Computer Crime and Security Survey” that lists the number of security incidents and the costs in terms of the associated losses based on information they collect through an industry survey [CCSS04]. In the absence of any other information, this survey is a good source for developing the relative likelihood and cost factors.
126
Enterprise Web Services Security
Cost to Protect
Denial of Service
Message Modification Replay Masquerade
Eavesdropping Traffic Analysis
Likelihood of Loss
FIGURE 6.2 Mapping threats to loss.
Implement Cost-Effective Measures There is a tradeoff between the potential losses associated with a given threat and the costs of protecting against it. You can’t protect against everything, and it may turn out costing more to protect against a particular threat than it is worth. An organization has to balance the costs against the associated risks. Continuously Review and Improve Security Policies Once you have determined the threats your organization faces, the costs of those threats, and the threats you are willing to protect against, you are in a position to develop effective security policies. RFC 2196 defines a security policy as a formal statement of the rules governing those managing and using an organization’s IT infrastructure. The policies can either be permissive or restrictive. Permissive policies say that anything not explicitly prohibited is permitted. Restrictive policies take the opposite tack, saying that anything not explicitly permitted is prohibited [SUN04]. Defense-in-depth advocates a layered security strategy that brings people, technology, and operations together in an overlapping approach as shown in Figure 6.3. The IATF defense-in-depth framework provides a comprehensive method for developing security policies and procedures that highlights the importance of comprehensive security policies. Incomplete, unimplemented, misunderstood, or mismanaged security policies are worse than no security policy at all because they can engender a false sense of security.
Security Policy Basics
127
People • • • • •
Training Awareness Physical Security Personnel Security System Security Administration
Technology • • • • •
Technology Layers Security Criteria IT/IA Acquisition Risk Assessment Certification and Accreditation
Operations • • • • • •
Assessments Monitoring Intrusion Detection Warning Response Reconstitution
FIGURE 6.3 IATFF defense-in-depth strategy.
THE SECURITY POLICY DOCUMENT Most organizations document their security policies in a security policy manual, document, or Web site. If you are new to an organization or to implementing Web Services within an enterprise, you should find this document and determine the security infrastructure in place and the policies affecting the services you develop and the security mechanisms your services are responsible for using or implementing. Appendix A offers guidelines that you can use if you are responsible for developing, reviewing, or updating an enterprise’s security policy.
SUMMARY Security begins with a good security policy. The security policy clearly communicates the roles and responsibility managers, users, and administrators have in protecting information and technology assets. To ensure consistency and completeness, the security policy must take an inside-out approach to building interlocking layers of security mechanisms matching the sensitivity and value of the
128
Enterprise Web Services Security
information and assets it must protect while weighing the costs of the countermeasures against the risks. Both the IETF and IATF recommend a defense-in-depth strategy that advocates a three-step (protect, detect, and react) approach. An enterprise security policy identifies responsible organizations for physical, personnel, and IT security and the standards and countermeasures the organization will use for defending the computing environment, enclave boundaries, and the network and computing infrastructure. The security policy also lays out incident reporting and response procedures. Web Services must also be a key part of the security policy. Web Services countermeasures must be consistent with and leverage the protection mechanisms at lower levels in the protocol stack in order to create a well-formulated overall protection strategy.
REFERENCES [CCIS04] “Common Criteria for Information Security Evaluation January 2004, Version 2.2, Revision 256, 2004.” Available online at http://niap.nist.gov/ cc-scheme/cc_docs/cc_v22_part1.pdf. [CCSS04] Computer Security Institute, “Computer Crime and Security Survey.” Available online at http://www.gocsi.com/, 2004. [IATF02] Information Assurance Solutions Technical Directors, “Information Assurance Technical Framework Release 3.1.” Available online at http://www. iatf.net/framework_docs/version-3_1/index.cfm, September 2002. [Orange85] Brand, S., et al., “Department of Defense Trusted Computer System Evaluation Criteria.” Available online at http://www.fas.org/irp/nsa/rainbow/ std001.htm, December 1985. [RFC2196] Fraser, B., editor, RFC-2196 Site Security Handbook. Available online at http://www.ietf.org/rfc/rfc2196.txt. [SUN04] Sun Microsystems, “How to Develop a Network Security Policy: An Overview of Internetworking Site Security.” Available online at http:// itpapers.zdnet.com/whitepaper.aspx?scid=285&kw=&dtid=0&sortby=dated& docid=984.
7
Communicating Policy
In This Chapter Expressing Security Policy in Web Services WS-Policy WS-SecurityPolicy WS-PolicyAttachment Summary References
n enterprise security policy that isn’t written down or communicated is in some ways like not having a policy at all. Under such circumstances, the policy being evenly and consistently implemented is highly unlikely. Historically, communicating policy has involved writing it down and making sure the right people read it, understood it, and reflected it in their designs and implementations. Given Web Services’ goals of loose coupling and discoverability, the Web Services community and standards organizations have included policy and policy discoverability as key components of the overall Web Services architecture. This is a revolutionary step, as components can now not only discover interface requirements at runtime, but also the “expectations” behind those requirements and make runtime decisions about whether or not they can meet those expectations. You could equate this to identifying two merchants, each offering the same item at the
A
129
130
Enterprise Web Services Security
same price, yet one accepts only MasterCard® and the other only Visa®, and you happen to only have one of the cards in your pocket. Your decision would be obvious. So, too could be a Web Services client’s decision when choosing between two equivalent services when the client can only meet one of the service’s claims requirements. For example, both services may require some form of identification. If one requires an X.509 certificate and the other requires a Kerberos ticket and the client only understands X.509 certificates, its choice is obvious. In this chapter we discuss the eXtensible Markup Language (XML)–based standards that help communicate security policy in a Web Services environment and can help Web Services clients make these types of decisions. The organization owning a Web Service can use these standards to publish the policies surrounding the use of its service. These mechanisms allow clients to discover the policies as part of the service discovery process and to decide whether or not they can trust the services that they are relying upon and to gauge their ability to partner in establishing the necessary trust relationship.
EXPRESSING SECURITY POLICY IN WEB SERVICES To be effective, policies must be communicated and enforced. In a Web Services environment, this means Web Services servers must have mechanisms for telling potential clients about the policy elements they require and enforce, and those clients must have mechanisms for discovering that information and responding. Three evolving Web Services standards create the foundation for this communication. IBM and Microsoft laid out the original Web Services security framework in their Web Services roadmap [Roadmap02]. WS-Policy provides the basic grammar and framework for describing policies as a set of expressions made up of individual policy assertions, where an assertion is a specific constraint or requirement. WSSecurityPolicy adds security-specific assertion elements to WS-Policy for communicating security token, integrity, and confidentiality constraints. WS-PolicyAttachment completes the picture by defining mechanisms for inherently associating policies with a subject, as part of its intrinsic definition or through either its associated Web Services Description Language (WSDL) or Universal Description, Discovery, and Integration (UDDI) description. In this chapter, we focus on these three policy-related standards that come into play for communicating policy information between two parties. In Chapter 11, we will look at the standards clients and servers can use for communicating the corresponding security elements in complying with the policies.
Communicating Policy
131
WS-POLICY Figure 7.1 illustrates the basic Web Services policy model. A Web Services server acting in the role of a service provider conveys a set of conditions to potential clients acting as service requestors who make use decisions based on their ability to satisfy conditions and send satisfying claims to the provider as part of their requests. The Web Services Policy Framework (WS-Policy) provides the model and XML syntax for the first half of this exchange [WSPolicy04].
Policy Conditions (WS-Policy)
Web Services Client (requestor)
Web Services Server (provider)
Satisfying Claims FIGURE 7.1 The WS-Policy Model.
WS-Policy defines a policy, at the abstract level, as a set of policy alternatives that are in turn made up of a set of policy assertions. Listing 7.1 illustrates this relationship in Backus-Naur-Form (BNF). BNF is a simple language for expressing syntax and is used throughout the XML and Web Services standards. A BNF rule, or production, is made up of nonterminal and terminal (constant) symbols and four metasymbols: , ::=, and |. The angle bracket metasymbols enclose nonterminal symbol names. Each nonterminal symbol equates to a production rule. The ::= metasymbol is read as “is definedas.” The | metasymbol is read as “or.” The lefthand side of the rule is the symbol being defined and the right-hand its definition. In our example, the assertion is the lowest level construct in the grammar. An assertion equates to an individual requirement or condition that must be satisfied. An alternative is a collection of one or more assertions. WS-Policy leaves the definition of the assertion grammar to other standards such as WS-SecurityPolicy.
132
Enterprise Web Services Security
LISTING 7.1
BNF of WS-Policy Grammar (Abstract)
::= empty | | ::= | ::= requirement (or condition)
Normal Form At a concrete level, WS-Policy defines a policy expression as an XML Infoset representation of a policy. The policy expression can be in either normal or compact form. Listing 7.2 illustrates the outline for a policy expression in normal form. WSPolicy defines three syntactical elements, , , and , that create the basic grammar for writing policy expressions in this form. The element encapsulates the overall policy expression. The and elements are optional operators that can encapsulate a set of zero or more assertions. The element is conceptually an exclusive OR operator. It encapsulates a set of alternative assertions where exactly one of the child elements must be true. If this element is included but left empty, it indicates that there are no policy alternatives. The element is conceptually an AND operator. It encapsulates a set of assertions that must all be met. If this element is included but left empty, then there are no requirements or conditions in the area specified. LISTING 7.2
WS-Policy in Normal Form
... ... ... ...
Communicating Policy
133
Compact Form Normal-form policy expressions can become very verbose because of the limited operator and structure capabilities within the grammar. WS-Policy extends the grammar in three ways to support a more compact form for writing policy expressions: It adds the wsp:Optional attribute for use on assertion elements. It defines the semantics for recursively nesting policy operators. It adds an element for including other policy expressions to enable a more compact form for writing policy expressions. WS-Policy adds the wsp:Optional attribute in order to reduce the number of statements needed to express rules containing optional assertions; in normal form, you would have to write the rule twice, once with the optional assertion and once without. The wsp:Optional attribute can be used on any assertion element. It uses a Boolean value to indicate whether an assertion is either optional (True) or required (False). An assertion element that does not contain a wsp:Optional attribute is equivalent to one including the attribute with its value set to False. Compact-form policy expressions can recursively nest , , and operators. WS-Policy defines the transformation rules summarized in Table 7.1 for converting compact-form policy expressions into their normal form equivalents. The transformation rules provide the semantic guidelines for understanding how to expand and collapse statements into equivalent form without changing meaning. Compact-form policy expressions can also include a element anywhere an assertion can appear. The element provides a mechanism for one policy to include another through a uniform resource identifier (URI) reference. As a general rule, you can think of the policy expression pointed to by the as simply replacing the element. The exception is when the points to a element. In that case, the inclusion rule is to replace the element with an operator encapsulating the statement’s child elements. Listing 7.3 illustrates the syntax of this element. The URI attribute points to the policy expression for inclusion. The optional digest attribute contains the digest in Base-64 format (Base-64 is an encoding format for transforming binary data into printable text for transmission over character-based mechanisms such as those used for XML). The digest attribute provides a way of ensuring the right policy expression is included. The optional DigestAlgorithm attribute identifies the digest algorithm used to calculate the digest. The default is the secure hash algorithm (SHA1) using exclusive XML canonicalization to standardize the XML structure
134
Enterprise Web Services Security
TABLE 7.1 Compact Form to Normal Form Transformation Rules Rule
Meaning
Equivalence
is semantically equivalent to
Empty
is another way to express zero policy assertions is another way to express zero options
Commutative
Is equivalent to
Associative
Is equivalent to
Idempotent
Is equivalent to
Distributive
distributes across for example,
Is equivalent to
prior to creating the digest (we will discuss canonicalization in greater detail in Chapter 11) [EXCC14N]. The element is a placeholder for a valid operator and can be replaced by either or in the statements above.
Communicating Policy
LISTING 7.3
135
The PolicyReference Element Syntax
Merging Policies and Resolving Conflicts Figure 7.1 presents the simplest usage scenario—one where the Web Services provider sets the policy and requestors simply comply. How does this work in more complex situations where multiple policy setting providers are involved or the provider and requestor each have a set of policies and the requestor wants to limit the alternatives to mutually compatible ones? WS-Policy defines policy intersection as a first approximation for addressing these more complex scenarios. Policy intersection says that given two policies, P1 and P2, the intersection is the set of policy assertions, Ai, where for each assertion Ax in P1 and Ay in P2 where the vocabulary of Ax in P1 is equal to the vocabulary of Ay in P2, the set of policy assertion instances in Ai is all the assertion instances in Ax plus all the assertion instances in Ay. The vocabulary is the set of all assertion types used in the policy.
WS-SECURITYPOLICY WS-Policy provides the basic syntax and semantics for writing policy expressions. WS-Policy does not define the syntax or grammar for any particular type of assertions; it treats assertions in a generic way, leaving it to other standards to define appropriate assertions. The Web Services Security Policy Language (WS-SecurityPolicy) extends WS-Policy for the security-specific elements necessary for writing security policy assertions [WSSP02]. As we discussed in the last chapter, the Web Services section of an organization’s Security Policy should address questions of authentication, authorization, access control, confidentiality, and integrity. It should also cover the rules for traversing routers and firewalls and any other intermediaries involved in a message exchange. WS-SecurityPolicy defines assertion syntax for addressing these specific questions as well as for communicating where within the message (within the security header or message body) security-related information can be included and the requirements for and treatment of message time stamps.
136
Enterprise Web Services Security
SecurityToken Assertion
The element provides a means for a Web Services provider to tell a requestor the security tokens the provider requires or supports within its authentication, authorization, and access control services (we discuss the various types of tokens in detail in Chapter 9 under Identity Management). Listing 7.4 illustrates the syntax for this element. The subelement identifies the type of security token (see Table 7.2 for valid types) supported or required, and the optional subelement identifies the token issuer by name. The optional subelement contains type-specific information pertaining to the security claim. LISTING 7.4
The SecurityToken Element Syntax
... ... ...Token type specific claims... ... Token type specific details ... ... ... ... ...
Communicating Policy
137
TABLE 7.2 Valid TokenType Values Qname
Description
X509v3
X.509 Version 3 Certificate
Kerberosv5TGT
Kerberos V5 Ticket Granting Ticket
Kerberosv5ST
Kerberos V5 Service Ticket
UsernameToken
User name token
SAMLAssertion
SAML Assertion
XrMLLicense
XrML License
X.509 Claims
When the subelement is X.509v3, the optional subelement contains the name of either the issuing certificate authority (CA) or the corresponding root CA. The subelement can contain optional and subelements. If present, the subelement contains any restrictions on the certificate subject name. The optional MatchType attribute indicates whether an Exact or Prefix (the default) match is required. The optional subelement contains any restrictions on the extension identified by the OID attribute. The optional Critical attribute indicates whether the specified extension is critical (True) or not (False), and the optional MatchType attribute indicates whether an Exact or Prefix (the default) match is required. Kerberos Claims
When the
subelement contains a Kerberos QName, the optional subelement identifies the Kerberos realm. The subelement can contain an optional subelement and a mandatory subelement. If present, the subelement contains any restrictions on the client’s PrincipleName field in the Kerberos ticket, and the optional MatchType attribute indicates whether an Exact or Prefix (the default) match is required. The subelement contains the service’s PrincipleName.
Username Claims
The subelement is not used with username claims. The subelement can contain an optional subelement and a mandatory
138
Enterprise Web Services Security
subelement. If present, the subelement contains any restrictions on the contents of the subelement. The optional MatchType attribute indicates whether an Exact, Prefix (the default), or Regexp (regular expression) match is required. The subelement contains any restrictions on the contents of the subelement. The optional Type attribute indicates whether the password value should be sent in PasswordText plaintext (default) or PasswordDigest format.
Confidentiality Assertion
The element provides a way for a Web Services provider to tell a requestor its encryption requirements or convey information about the encryption capabilities that it supports. The provider may want the requestor to encrypt all or specific parts of the message and may require the use of a particular encryption algorithm. Listing 7.5 illustrates the syntax for this element. The optional subelement identifies the encryption algorithm to be used in encrypting related message parts. The optional Type attribute confirms that an encryption algorithm is being specified (its value is set to the AlgEncryption QName), and the optional URI attribute points to the XML encryption algorithm to use. Table 7.3 lists the algorithms by category along with the identifying URI (we will discuss the algorithms, their uses, and their strengths and weaknesses in Chapter 10). The optional subelement identifies any required key formats. The optional subelement identifies the token format or authority to use, and the optional subelement identifies the token to be used for the encryption itself. LISTING 7.5
The Confidentiality Element Syntax
... ...
Communicating Policy
139
The subelement identifies the parts of the message that requestors must encrypt. The optional Dialect attribute is a URI reference identifying how to interpret contents—as XPATH 1.0 statements (the default) or as WS-PolicyAssertions-defined functions (see Table 7.4) [XPATHF02, WSPAssert02]. (Chapter 5 contains a discussion of XPATH.)
TABLE 7.3 XML Encryption Algorithms Category
Name
URI
Block
Triple DES
http://www.w3.org/2001/04/xmlenc#tripledes-cbc
AES-128
http://www.w3.org/2001/04/xmlenc#aes128-cbc
AES-256
http://www.w3.org/2001/04/xmlenc#aes256-cbc
AES-192
http://www.w3.org/2001/04/xmlenc#aes192-cbc
Stream
None
Key Transport
RSA v1.5
http://www.w3.org/2001/04/xmlenc#rsa-1_5
RSA OAEP
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgflp
Key Agreement
Diffie-Hellman
http://www.w3.org/2001/04/xmlenc#dh
Key Wrap
Triple DES
http://www.w3.org/2001/04/xmlenc#kw-tripledes
AES-128
http://www.w3.org/2001/04/xmlenc#kw-aes128
AES-256
http://www.w3.org/2001/04/xmlenc#kw-aes256
AES-192
http://www.w3.org/2001/04/xmlenc#kw-aes192
TABLE 7.4 MessageParts Dialect Values URI
Meaning
http://www.w3.org/TR/1999/REC-xpath-19991116
XPATH 1.0
http://schemas.xmlsoap.org/2002/12/wsse#part
WS-PolicyAssertion Functions
Integrity Assertion
The element provides a way for a Web Services provider to tell a requestor the parts of a message that the provider wants to validate to ensure they
140
Enterprise Web Services Security
have not been changed and to convey information about the digital signature algorithms and capabilities that it supports. The provider may want the requestor to digitally sign the entire message or just specific parts and may require the use of particular signature, method digest, canonicalization, or transformation algorithms [EXCC14N, XMLC14N, Hughes02, SOAPSE01]. WS-Security builds on XML Signature for signature capabilities [WSSecurity02, XMLSig02]. The significance of the subelements in the element comes from the two-step process used in creating digital signatures. The first step processes the document to be signed through a standard serialization algorithm and secure hash function, such as SHA1, to create a message digest that creates a digital fingerprint for the message. The second step encrypts the message digest, using the required encryption algorithm, to create a digital signature. Listing 7.6 illustrates the syntax for the element. The optional subelement identifies the algorithms to be used in transforming and signing related message parts. The optional Type attribute identifies the type of algorithm being addressed (see Table 7.5), and the optional URI attribute points to the corresponding algorithm to use as shown in Table 7.6 by category along with the identifying URI. The optional subelement identifies any required token formats and includes one or more optional subelements identifying the token format or authority to use. The optional subelement describes any claims that must be expressed in the token. The subelement identifies the parts of the message that requestors must sign, with the optional Dialect attribute being a URI reference identifying how to interpret contents—as XPATH 1.0 statements (the default) or as WS-PolicyAssertions-defined functions (see Table 7.4). The optional Signer attribute lists a set of URIs indicating who must sign each of the nodes. The predefined URI for the original sender of the message is http://schemas. xmlsoap.org/2002/12/secext/originalSender. LISTING 7.6
The Integrity Element Syntax
... ...
Communicating Policy
141
TABLE 7.5 Algorithm Type QNames QName
Description
AlgDigest
Digest method
AlgCanonicalization
Canonicalization
AlgSignature
Signature method
AlgTransform
Transformation
TABLE 7.6 XML Signature Algorithms Category
Name
URI
Message Digest
SHA 1
http://www.w3.org/2001/04/xmlenc#sha1
SHA 256
http://www.w3.org/2001/04/xmlenc#sha256
SHA 512
http://www.w3.org/2001/04/xmlenc#sha512
RIPEMD
http://www.w3.org/2001/04/xmlenc#ripemd160
Canonical XML
http://www.w3.org/2001/ REC-xml-cl4n-20010315
With Comments
http://www.w3.org/2001/ REC-xml-cl4n20010315#WithComments
Exclusive XML
http://www.w3.org/2001/10/xml-exc-c14n
With Comments
http://www.w3.org/2001/10/xml-excc14n#WithComments
MAC
HMAC/SHA1
http://www.w3.org/TR/2001/09/ xmldsig#hmac-sha1
Reference type
Object
http://www.w3.org/TR/2001/09/xmldsig#Object
Manifest
http://www.w3.org/TR/2001/09/xmldsig#Manifest
Properties
http://www.w3.org/TR/2001/09/ xmldsig#SignatureProperties
DSA
http://www.w3.org/TR/2001/09/ xmldsig#DSAKeyValue
RSA
http://www.w3.org/TR/2001/09/ xmldsig#RSAKeyValue
X509
http://www.w3.org/TR/2001/09/ xmldsig#X509Data
Canonicalization
Retrieval method
142
Enterprise Web Services Security
Category
Signature
Transformation
Encoding
Name
URI
PGP
http://www.w3.org/TR/2001/09/ xmldsig#PGPData
PKI
http://www.w3.org/TR/2001/09/x mldsig#SPKIData
Mgmt
http://www.w3.org/TR/2001/09/ xmldsig#MgmtData
DSA/SHA1
http://www.w3.org/TR/2001/09/ xmldsig#dsa-sha1
RSA/SHA1
http://www.w3.org/TR/2001/09/ xmldsig#rsa-sha1
XPath Filter
http://www.w3.org/2002/06/ xmldsig-filter2
XSL Transform
http://www.w3.org/1999/XSL/Transform
Decrypt XML
http://www.w3.org/2002/07/ decrypt#XML
Decrypt Binary
http://www.w3.org/2002/07/ decrypt#binary
Env Signature
http://www.w3.org/2000/09/ xmldsig#enveloped-signature
Normalization
http://www.w3.org/TR/2003/NOTE-soap12-n11n-20030328/
Dereference
http://www.docs.oasis-open.org/wss/ 2004/01/oasis-200401-wss-soapmessage-security-1.0#STR-Transform
Base64
http://www.w3.org/2000/09/ xmldsig#base64
Visibility Assertion
Intermediate services such as Web Services referral or router services may need to access parts of a message—particularly the header. In choreographed services, different services may need to process different parts of the message. In some cases the service provider will want requestors to transmit the information in plaintext; in others, the service provider will want to set up separate encryption schemes for each
Communicating Policy
143
actor. The element provides a way for a Web Services provider to tell a requestor the parts of a message that must be visible to intermediaries or subsidiary processes. Listing 7.7 illustrates the syntax for this element. The subelement identifies the parts of the message that must be visible, with the optional Dialect attribute being a URI reference identifying how to interpret contents—as XPATH 1.0 statements (the default) or as WSPolicyAssertions-defined functions (see Table 7.4). LISTING 7.7
The Visibility Element Syntax
SecurityHeader Assertions
WS-Security defines the header and sets out the rules for creating header blocks within the SOAP message header. One of these rules is that intermediaries can extend a header block by prepending new elements to the existing header block. Prepending means to attach the new elements to the beginning of the header before any elements that might already exist. The prepending rule is designed to eliminate any forward dependencies for receiving services because they can process elements in the order in which they appear. The element allows a service provider to modify this rule. Listing 7.8 illustrates the syntax for this element. The optional MustPrepend attribute tells requestors whether they need to follow the WS-Security rule. When the attribute’s value is set to True, the requestor must prepend any additional entries; when it is set to False (the default), the requestor need not follow the rule. LISTING 7.8
The SecurityHeader element syntax
WS-Security builds on XML Encryption for its encryption capabilities [XMLEncrypt02]. Since WS-Security defines the header, this means encryption information can be defined in either the header or within the document itself. The optional MustManifestEncryption attribute on the element gives providers a way to tell requestors whether the provider supports inline encryption information or whether it requires that information to be
144
Enterprise Web Services Security
solely contained within the header. When the MustManifestEncryption attribute is set to True, the provider will only process encryption information contained within the header; when it is set to False (the default), the provider will search the message for applicable encryption information. MessageAge Assertions
Some authentication and authorization schemes use timestamps to help reduce the risk of replay attacks. The element gives Web Services providers a way to tell requestors the time period during which they will accept a message. The time period is based on the message creation time reflected in the message’s header element. If the time period has elapsed or the message does not include a header element, the provider can optionally discard the message. Listing 7.9 illustrates the element’s syntax. The Age attribute reflects the maximum time period in seconds. LISTING 7.9
The MessageAge Element Syntax
Putting It Together: An Example Now that we have described both the policy framework and assertion grammars, let’s look at an example. Let’s suppose a Web Services provider wants requestors to optionally provide either an X.509 certificate or Kerberos service ticket, to optionally encrypt the message body using AES, and to sign the message using SHA1 to create the message digest and RSA to encrypt the result. The example policy specification in Listing 7.10 shows one way of stating this policy. LISTING 7.10
Security Policy Example
X509v3 Kerberosv5ST
Communicating Policy
145
wsp:Body wsp:GetInfosetForNode(wsp:GetBody(.))
The policy begins by stating that the provider will accept an X.509 certificate, a Kerberos service ticket, or no security token at all. The combination of the and subelements give us this last result. The assertion says requestors can optionally encrypt the message body using the AES algorithm and a 128-bit key. The Optional attribute on the opening tag being set to True specifies that encryption is optional. The subelement uses the Body function from Appendix II of WS-PolicyAssertions to identify the message elements to encrypt. The subelement has its Optional attribute set to false, indicating that requestors must sign the message body. The Algorithm subelement specifies that requestors are to use XML Canonicalization to serialize the
146
Enterprise Web Services Security
message body before using SHA1 to create the digest and RSA to encrypt the digest value. The subelement uses an XPATH 1.0 expression and a GetBody function from Appendix I of WS-PolicyAssertions to identify the Body element. The Signer attribute designates the original message sender as the party that must sign the message.
WS-POLICYATTACHMENT Web Services PolicyAttachment (WS-PolicyAttachment) defines the grammatical elements necessary for tying policies to policy subjects [WSPAttach04]. WSPolicyAttachment also describes how to use these mechanisms with WSDL and UDDI, making policy discovery part of service discovery. Finally, given the variety of ways policies can be tied to subjects, WS-PolicyAttachment discusses how multiple policies translate into effective policies. Tying Policies to Subjects A policy subject is a provider, a service, an endpoint, a message, or an interaction that a Web Services provider wants to constrain, influence, or control through policy. WS-PolicyAttachment extends WS-Policy to the attributes and elements for tying policy expressions to policy subjects. XML resources and resource descriptions can make the tie either intrinsically as part of the XML itself or externally through a separate document. XML resources can intrinsically tie policy expressions to policy subjects in any of three ways. WS-PolicyAttachment defines the PolicyURIs attribute for tying a policy expression directly to an XML element through an attribute reference as shown in the first example in Listing 7.11. A second option is to include the policy expression as a child element of the affected element as shown in the second example in Listing 7.11. A third option is to include references to the policy expression as shown in the third example in Listing 7.11. LISTING 7.11
Tying Policy Expressions to Policy Subjects
...
Communicating Policy
147
... ... ... ... ...
WS-PolicyAttachment also provides for externally tying policy expressions to policy subjects. WS-PolicyAttachment defines the element shown in Listing 7.12 for this purpose. The subelement identifies the policy subjects to whom the policy applies and establishes the policy’s scope. The policies described in subsequent elements apply to all the policy subjects within the policy’s scope. The example uses WS-Addressing to define an end point reference for this purpose. The optional subelement attaches the policy expression. Alternatively, you could have used a element to link to an external policy expression. The optional subelement allows you to attach any additional security information to the policy. WS-Security, which we will discuss in detail in Chapter 11, defines the syntax for this element.
148
Enterprise Web Services Security
LISTING 7.12
The PolicyAttachment Element Syntax
http://www.xyz.com/addr http://www.xyz.com/PT http://www.xyz.com/SN ... ...
Making Policies Discoverable WS-PolicyAttachment defines two ways to make policies discoverable. One way is to attach policy references to the WSDL elements corresponding to the policy subjects, and the other is to attach the policies through entries in a UDDI registry. Attaching Policies Using WSDL
Web Services providers communicate service interface descriptions to service requestors through WSDL documents. The WSDL service description is made up of a combination of abstract and concrete elements describing the service and how it ties to the underlying physical network. From a security policy perspective, a WSDL document provides attachment points for associating security policies with four types of policy subjects: service, endpoint, operation, and message, through the related set of WSDL elements corresponding to these subjects. You attach policies to these elements using either the policyURIs attribute or the subelement described earlier. You must also include a subelement, which includes the wsdl:required=”true” attribute, as part of the WSDL document’s element to alert requestors that they must be able to process the security attachments. If you want to include the element within the WSDL document, you should include it in the element and reference it from other WSDL elements.
Communicating Policy
149
Service Policy Subject
Attaching security policies to the element allows you to specify policies that affect the service as a whole. Endpoint Policy Subject
Attaching security polices to the , , or elements defining an endpoint allows you to specify policies that affect a particular implementation of a service. You should only attach binding independent assertions to shared elements to avoid unintended side affects. Operation Policy Subject
Attaching security policies to the subelement belonging to either a or element allows you to specify policies that affect a particular message sequence. Again, you should only attach binding independent assertions to shared subelements to avoid unintended side affects. Message Policy Subject
Attaching security policies to the , , , or subelements pertaining to a message or a message exchange allows you to specify policies affecting that message or exchange. Again, you should only attach binding independent assertions to shared subelements to avoid unintended side affects and you should also exercise care in attaching policies to outbound messages or message sequences unless you are sure or have provided a way for requestors to handle or negotiate the sequence. Attaching Policies Using UDDI
Web Services providers have two options for attaching security policies to service provider, service, and endpoint policy subjects through UDDI. One option is to directly reference remote policy expressions in the UDDI entities corresponding to the different types of policy subjects; the other option is to register the policy expression as a technical model in the UDDI registry and to then reference that tModel entry from other UDDI entities. Table 7.7 maps policy subjects to their corresponding UDDI structures. TABLE 7.7 Mapping Policy Subjects to UDDI Structures Policy Subject
UDDI Structure
Service provider
businessEntity
Service
businessService
Endpoint
tModel and bindingTemplate
150
Enterprise Web Services Security
Direct Reference Model
If a security policy only applies to a single service or endpoint, or if you have a universal policy that applies across your organization, then directly referencing the policy expression within the UDDI entities describing your organization, service, or endpoint is an option. WS-PolicyAttachment defines a new UDDI tModel entry, called the Remote Policy Reference category system, to support this type of reference. UDDI entities that have elements (, , and ) take advantage of this capability through subelements to the element. The tModelKey attribute on the element is set to the Remote Policy Reference tModel key (see Table 7.8 for a list of tModel types and their UDDI V2 and V3 keys), and the keyValue attribute is set to the URI of the remote policy expression. UDDI entities, such as the structure, that do not have subelements take advantage of this capability through their child element. To use this approach, you set the tModelKey attribute on the element to the Remote Policy Reference tModel key and put the URI reference to the remote policy expression into the subelement of a child element.
TABLE 7.8
tModel Types and Keys
tModel Type
UDDI V2
UDDI V3
Remote reference
uuid:a27078e4-fd38-320a-806f6749e84f8005
uddi:schemas.xmlsoap.org: remotepolicyreference:2003-03
WS-Policy type
uuid:fa1d77dc-edf0-3a84-a99a5972e434e993
uddi:schemas.xmlsoap.org: policytypes:2003-03
Local reference
uuid:a27f7d45-ec90-31f7-a655efe91433527c
uddi:schemas.xmlsoap.org: localpolicyreference:2003-03
Registration Model
What if you want to share the policy expression across service providers, services, or endpoints? In that case, you need to be able to register the policy expression within the UDDI registry and then create references to the registration rather than to the policy expression itself. WS-PolicyAttachment defines two new UDDI tModel entries to support registering and referencing policy expressions in this way. One entry is for creating tModel entries registering the policy expression itself; the other
Communicating Policy
151
supports other UDDI entities, such as , , , and elements, referencing the registered policy using tModelKeys by providing an appropriate interpretation of the reference meaning. The tModel entry that defines the category for registering remote policy expressions is called the WS-Policy Types category system. Listing 7.13 illustrates a tModel that uses this category system to create a registered policy expression. The subelement contains two child elements. The first uses the WS-Policy Types category tModelKey to identify the tModel as belonging to the “policy” category. The second child element’s keyValue attribute contains the URI of the policy expression; its tModelKey attribute uses the Remote Policy Reference tModelKey to indicate that it is a remote policy reference. Once created, the tModelKey for the tModel structure becomes the key for referencing the registered policy. WS-PolicyAttachment defines the Local Policy Reference category system to allow UDDI entities such as , , , and elements to reference and properly interpret registered policies. Entities with entries set the tModelKey attribute on the element to the Local Policy Reference tModelKey (see Table 7.8) and the keyValue attribute to the tModelKey of the registered policy expression. Entities that use entries set the tModelKey attribute on the element to the Local Policy Reference tModel key and the subelement of a child element to the tModelKey of the registered policy expression. LISTING 7.13
Policy Expression Reference
... Sample Policy tModel A WS-Policy Policy Description http://www.xyz.com/wspolicy
Effective Policy Web Services providers have a number of different options for attaching policy expressions to policy subjects. As we discussed above, policy subjects include the provider, the service, the endpoint, the operations making up a transaction, and the messages constituting a transaction. The provider can attach policy expressions affecting some policy subjects via both WDSL and UDDI attachment points. A question you would naturally have is, “how do service requestors properly interpret multiple policy expressions when they overlap?” WS-PolicyAttachment defines a merge process for creating an effective policy for a policy subject. A policy subject’s effective policy is the combination of relevant policies from all the policy scopes that contain the policy subject. You create the effective policy for a policy subject by first determining the policy scopes that include the policy subject and then serializing the policy expressions within those scopes. The serialization process involves changing each policy expression’s element into a element, combining it with other expressions affecting the policy subject, and wrapping the final result with a tag. How do you determine the policy scopes that contain a policy subject? The policy scope is the set of policy subjects to which policy expressions within that scope apply. As we have discussed, the policy scope for any given policy expression is determined by its attachment point. Policy expressions attached to UDDI structures have provider scope; those attached to UDDI structures or WSDL elements have service scope, and those attached to UDDI or structures or to WSDL , , or elements have endpoint scope, etc. As a general rule, a policy expression attached to an element has an element scope that is an intrinsic part of the element’s definition and applies to all uses of that element. In situations where multiple elements create a policy subject, the effective policy must merge the element policies of the constituent elements. For example, the effective policy for an endpoint merges any policy expressions attached to WSDL , , and descriptions forming the endpoint. In cases where both
Communicating Policy
153
UDDI and WSDL descriptions of a policy subject contain policy expression attachments, the effective policy must merge both sets of descriptions. When attaching policy expressions to Web Services elements, it is important to keep scope in mind to avoid unintended consequences.
SUMMARY WS-Policy creates a basic framework for describing and communicating policies made up of sets of rules or assertions. We discussed WS-Policy’s normal and compact forms for writing policy documents and presented a simple and a more complex scenario illustrating these forms. WS-SecurityPolicy adds the security-specific assertion elements Web Services providers need to communicate security token, integrity, and confidentiality requirements and constraints to requestors. We went into detail regarding the elements available for representing SecurityToken, Confidentiality, Integrity, Visibility, SecurityHeader, and MessageAge assertions. WS-PolicyAttachment completes the picture, enabling providers to make their policy requirements discoverable either intrinsically through their service’s interface or through the service’s associated WSDL or UDDI description.
REFERENCES [EXCC14N] Boyer, John, et al., “Exclusive XML Canonicalization Version 1.0.” Available online at http://www.w3.org/tr/xml-exc-c14n/, July 18, 2002. [Hughes02] Hughes, Merlin, et al., “Decryption Transform for XML Signature.” Available online at http://www.w3.org/tr/xmlenc-decrypt, August 2, 2002. [Roadmap02] Microsoft Corporation and IBM Corporation. “Security in a Web Services World: A Proposed Architecture and Roadmap, A Joint White Paper from IBM Corporation and Microsoft Corporation.” Version 1.0. Available online at http://www-106.ibm.com/developerworks/webservices/library/wssecmap, April 7, 2002. [SOAPSE01] Brown, Allen, et al., “SOAP Security Extensions: Digital Signature” Available online at http://www.w3.org/tr/soap-dsig, February 6, 2001. [WSPAssert02] Box, Don, et al., “Web Services Policy Assertions Language (WSPolicyAssertions) Version 1.1.” Available online at http://www.verisign.com/ wss/WS-PolicyAssertions.pdf, May 28, 2002. [WSPAttach04] Siddharth, Bajaj, et al., “Web Services Policy Attachment (WSPolicyAttachment).” Available online at http://ifr.sap.com/ws-policy/ws-policyattachment.pdf, September 2004.
154
Enterprise Web Services Security
[WSPolicy04] Siddharth, Bajaj, et al., “Web Services Policy Framework (WSPolicy).” Available online at http://ifr.sap.com/ws-policy/ws-policy.pdf, September 2004. [WSSecurity02] Atkinson, Bob, et al., “Web Services Security (WS-Security) Version 1.0.” Available online at http://www-106.ibm.com/developerworks/ webservices/library/ws-secure/, April 5, 2002. [WSSP02] Della-Libera, Giovanni, et al., “Web Services Security Policy Language (WS-SecurityPolicy) Version 1.0.” Available online at http://www.verisign. com/wss/WS-SecurityPolicy.pdf, December 18, 2002. [XMLC14N] Boyer, John, et al., “Canonical XML Version 1.0, W3C Recommendation.” Available online at http://www.w3.org/TR/xml-c14n, March 15, 2001. [XMLEncrypt02] Eastlake, Donald, et al., “XML Encryption Syntax and Processing.” Available online at http://www.w3.org/tr/xmlenc-core, August 2, 2002. [XMLSig02] Eastlake, Donald, et al., “XML Signature Syntax and Processing.” Available online at http://www.w3.org/tr/xmldsig-core, February 12, 2002. [XPATHF02] Boyer, John, et al., “XML-Signature XPATH Filter 2.0.” Available online at http://www.w3.org/tr/xmldsig-filter2, July 18, 2002.
8
Protecting the System Components
In This Chapter Security Controls for the System Components The Client Workstation Vulnerabilities Operating System Security Browser Security Downloading Components ActiveX Security Java Security Scripting Plug-ins The Network Network Vulnerabilities Wireless Communications Firewalls Gateways, Guards, and Routers Virtual Private Networks Servers Web Server Vulnerabilities Operating System Security Summary References
n Chapter 6 we talked about two ways of looking at enterprise security: from the inside out (which is the way the security policy must view it) and from the outside in (which is the way any given Web Service views it). We also discussed the importance of a layered approach to implementing policy where services can build on lower layers to maintain consistency while minimizing redundancies and the
I
155
156
Enterprise Web Services Security
potential for conflicts across layers. We begin our discussion of what it really means to implement a security policy with a discussion of what it means to implement security protection mechanisms at the network and systems levels. While deciding on what measures to take to protect your system, you must consider the protections for the components that make up that system, including the hardware, the software, and the network. Concentrating on security measures for the software alone may not be enough. In this chapter we discuss the security concerns for the system itself. This chapter concentrates on the physical components of the Web Services system and identifies the weaknesses in those components that should be considered when implementing security controls.
SECURITY CONTROLS FOR THE SYSTEM COMPONENTS Deciding what security measures to implement to help protect a system can be daunting. A complex distributed system may pose a difficult problem for the people responsible for securing that system simply because the system as a whole is too large to understand. Distributed control of the system components also makes securing that system difficult, as you may need to interact with several people to enforce good security controls. A common way of dealing with such complex problems is to divide them into smaller pieces and decide on appropriate controls for each of those subcomponents. While the components aren’t used in isolation because they are part of the overall system, protections for each of those components can be combined to help protect the system as a whole. The component-level view is particularly appropriate for a Web Services system, as will be seen. For a Web Services system, the obvious components are the user’s Web browser, the servers that support the Web Services application, and the network that allows those components to communicate. For each of these components, we will describe threats and countermeasures that can be used to protect them.
THE CLIENT The client is possibly the most important component to consider because there are so many more clients than there are servers. Also, the client is something that the Web Service designer cannot choose or control. While a system could be designed to work with a limited number of client configurations (only one client operating system or one type of Web browser), that’s not practical or reasonable. A key advantage of Web Services is their dependence upon open systems standards, which makes them platform and vendor independent. Restricting the system to a small
Protecting the System Components
157
number of client types gives up much of the advantage of a Web-based system. A Web Service application must work properly with different host systems (Windows 9x, Windows 2000, Linux, and UNIX) and with different revisions of the software running on the client. A Web Service system should not fail just because a client installs a browser patch or an operating system patch. Unfortunately, the client is the one component that the Web Services designer cannot control. The client can choose different operating systems (Windows, UNIX, or Mac), different Web browsers, and so forth. The possible combinations of client configurations may make the Web Services system more complex as it attempts to adapt to the client base. This additional complexity increases the chances of there being an undiscovered flaw in the system.
WORKSTATION VULNERABILITIES The Web Service user interacts with the system using a Web browser running on his computer system. We refer to this as a workstation, where this includes whatever type of computer system the user is using, be it a desktop, a laptop, or possibly even a mobile phone running a wireless application protocol (WAP)–enabled browser. The Internet Engineering Task Force’s RFC 2504, User’s Security Handbook [RFC2504], provides a basis for understanding the risks that users are exposed to simply being connected to the Internet. This RFC provides helpful guidance for network end users and system administrators in a very approachable form. This document can form the basis of a useful security awareness program with little additional effort. Physical protections for the user’s workstation are the responsibility of the system owner and operator. This means the responsibility for properly operating a PC falls upon the user of that PC. Unfortunately, history has shown that users are not particularly careful about what software they allow on their systems. For example, this lack of caution causes the wide spread of the Bagel (or Bagle) worm [Keizer04]. Bagel spreads from host to host through the use of email messages and leaves a remote-control zombie on the infected system. The zombie is a piece of software that waits for commands from a control host over the Internet. Anyone who has the remote control program for that particular zombie program can use it to manipulate the infected system. Once a system is compromised with a zombie, it’s available for outsiders to use to spread spam, attack other systems, or act as part of a distributed denial-of-service attack. These infected machines are referred to as bots (short for robots). Networks of bots are called botnets. The wide spread of zombies is demonstrated by the fact that botnets are available for sale to be used in network attacks and spam floods [Kapersky04].
158
Enterprise Web Services Security
The possibility that the user’s workstation is infected by a worm or bot becomes a problem for Web Service designers because their service interacts with the user via a Web browser running on the user’s workstation. Text is in plaintext format; authentication, confidentiality, and integrity services may run locally; local cache and keystores are accessible from the workstation, which all makes workstation vulnerabilities difficult to defend. If a zombie is installed, it may record the user’s input (such as passwords) or spoof user input to trick the service into performing some illicit operation. The service designer must be careful to not depend too heavily on the security of the user’s workstation. Some simple steps can be taken to ensure that there really is a human at the workstation and not a bot. For example, CAPTCHA (completely automated public Turing tests to tell computers and humans apart) tests are used to verify that a human is driving the application, not a bot [vonAhn04]. Similar schemes should be used to verify that the workstation really is operating on the user’s behalf. Another problem with trusting the user’s workstation concerns the integrity of data stored on that system. It may be exposed if left in the clear (stored in unprotected disk files). Cookies, files, and other content stored on the user’s workstation should be protected using cryptographic methods. Sensitive information should be processed in a way that minimizes exposure to other software operating on that workstation, as that software may or may not be benign.
OPERATING SYSTEM SECURITY Responsibility for much of the security enforcement for a Web Services system falls upon the operating system that controls the client and the server systems. The operating system is expected to enforce process isolation to keep programs from interfering with each other and to provide memory access controls to keep one program from tampering with the contents of memory owned by another process. Enforcement of confidentiality and integrity protections for service data relies upon the operating system. If the operating system doesn’t work correctly or doesn’t include the necessary fundamental constructs, applications no longer have the protections they expect. For example, the absence of task and address space constructs and the shared memory concepts in early operating systems such as DOS and Windows 3.x made them notoriously difficult to secure. These flaws have been corrected in modern operating systems. Fortunately, the operating system features that support these isolation requirements are generally well-tested, low-level features of the operating systems. In most cases, the protections are dependable and work as expected. However, any operating system must be maintained to ensure that any detected flaws are corrected in a
Protecting the System Components
159
reasonable length of time. The critical systems that comprise the Web Service system must have patch processes in place so that any detected flaws are corrected before they can be exploited. Commercial operating systems, such as UNIX and Windows, are certified at the C2 level under the Orange Book scheme and at the EAL 4 level under the Common Criteria scheme and therefore represent some degree of risk in highly restricted environments. (See Chapter 3 for details on these evaluation schemes.) Policies should, at a minimum, require disabling features such as guest and administrator accounts and locking down key systems directories and files such as root, the systems registry, and configuration and password files. Operating system security checklists are available to help secure the systems being used to host your Web site. The National Security Agency (NSA) security guides at http://www.nsa.gov/snac/ [NSA05] cover Windows, Sun Solaris, and Mac OS and are very well respected. A Web server configuration guide provides detailed guidance on how one should protect a Microsoft Web server from attack. The Microsoft checklist at http://msdn.microsoft.com/library/en-us/dnnetsec/html/CL_ SecWebs.asp provides a simple checklist that helps ensure that your servers are not misconfigured. Another good source for lockdown information is the Center for Internet Security (http://www.cisecurity.org).
BROWSER SECURITY A Web Service designer needs to interact with the service user to receive requests and respond with results. Usually this interaction with the user occurs using the user’s Web browser. One problem with this is that browsers are fairly limited in how they can accept input and provide responses. The form-based methodology that is part of the native HTML standard is a simple fill-in-the-blank form scheme that does not allow the browser to verify the user’s input. The user fills in the form and submits it to the server, and the server verifies the input. If anything is wrong, the server must ask the user to try again. Effectively, the user’s browser is used like a dumb terminal even though there’s usually a PC with a full-featured graphical user interface (GUI) that could easily be used to offload the verification process. Complex GUI operations such as click-based selections are difficult to do with a standard Web browser. Two technologies were created to solve this problem by allowing the browser to execute software on the user’s system that can be used to extend the browser’s capability while working with the user. Microsoft’s offering is ActiveX. Sun’s Java language is the second major option. In order to better understand some of the security challenges these technologies pose, let’s look at the overall browser architecture and how it operates.
160
Enterprise Web Services Security
Figure 8.1 illustrates a notional Web browser architecture. While both Microsoft Internet Explorer and Netscape Navigator support most of the same capabilities, Internet Explorer has componentized more of its architecture (that is, breaking the monolithic browser code into smaller components that can be reused for other purposes) making the corresponding components’ dynamic link libraries (DLLs) available to other applications. Much of the controversy that has surrounded Microsoft has concerned their making these components integral components of the operating system. Some of the components shown in our notional architecture provide similar functions but are necessary to support the two major technologies driving Web Services applications development today: Microsoft’s .NET and Sun’s J2EE (Java 2 Enterprise Edition). We will briefly discuss each component in our notional architecture below and in greater detail in subsequent sections as we turn to specific security concerns.
Cache
Javascript/ VBScript Interpreter
Display Engine
JAVA Virtual Machine
HTML Interpreter
Common Language Runtime
Browser Operating System
FIGURE 8.1 Web browser architecture.
First and foremost, the Web browser is a requester. Given a URL, the Web browser requests the Web page and whatever other application elements are necessary to satisfy the request from a Web server. The Web browser determines the pro-
Protecting the System Components
161
tocol to use in making its request from the URL. In most cases, the requests are made using HTTP. The Web browser communicates with the Web server over a direct, TCP/IP connection or via a dial-up SLIP or PPP connection. In both cases, a sessionless protocol is used (this is a protocol that does not use a persistent connection; the Web browser connects to the server and makes a request, the server honors the request, and the Web browser disconnects). If a request is made up of multiple components, each represents a separate request to the server, as there is no connection or session that allows the server to connect them together. To improve performance over slow or congested networks, the Web browser provides a cache for previously downloaded pages and objects. Before requesting that a page or object be downloaded, the browser checks to see if the needed item is already available in its cache. If it is, the browser uses it, thus saving the overhead of downloading another copy. As the Web browser downloads inputs, it makes a determination of how that input is to be handled: by one of the Web browser’s built-in components, by helper or plug-in applications, by one of the browser’s runtime execution engines, or by launching another application. These decisions are made on an element-by-element basis based on content type. The Web browser makes its determination of content type based on either the response header returned from the server or the file extension associated with the content. For example, a file extension of either .htm or .html denotes content in HTML format. The Web browser uses its HTML interpreter to interpret and process HTML input. Since most Web pages are written in HTML, the HTML interpreter is generally the first component invoked on a new input stream. The HTML interpreter governs the invocation of other elements, calling them into service as dictated by the input stream. As the Web browser receives HTML documents from the server, The HTML interpreter parses the HTML content, formats it for display, passes displayable content to the display engine for presentation, and resolves linkages to other documents, objects, or content. During this interpretation process, the HTML interpreter may encounter inputs that it cannot handle directly. When that happens, the HTML interpreter invokes the necessary component based on the type of input in question. The determination of which component to invoke is made based on information provided as an attribute on the HTML statement referencing the input or on the file type of the content. The three most common types of contained content are applets, multimedia internet mail extension (MIME) types, and objects. Once launched, the component is either given or pointed to a file containing the content in question and interacts with the Web browser throughout the display and navigation of that content. The Web browser’s display engine may begin displaying content before all the elements of a page are downloaded. This feature provides the illusion of quicker response in a low bandwidth environment. The display engine will normally
162
Enterprise Web Services Security
maintain a wait cursor until all the elements of a page are fully downloaded and resolved. The display engine displays the interpreted document in its main window. While the document is being displayed, the Web browser is responsible for processing keyboard and mouse events and implementing basic display features such as scrolling. The display engine also creates the runtime environment and is responsible for communicating events across components, interacting with components to refresh and signal focus changes, launching components in response to user events, and detecting and initiating requests for new Web pages through inputs to the Web browser’s location window, selections from the history list, or actions on the Web page, such as the user clicking on a submit button, that request a new page be loaded. In addition to controlling the display and navigation of the document, the Web browser’s display engine also acts as a hypertext linker. The display engine detects when the user clicks on a link, takes the URL corresponding to that link, and communicates with the Web server to transfer and display the information represented by that URL. The link may be displayed in the Web browser’s main window, in a frame within that window, or in another instance of the Web browser. A major architectural component that can come into play during both the interpretation and display process is the Web browser’s scripting language interpreter. The Web browser first detects scripting language programs in its inputs during the HTML interpretation process. Some scripting language directives may be aimed at controlling initial appearance or default values of some content, in which case the script is interpreted prior to display; others are conditionally invoked in response to the user clicking a button, selecting a value, or entering an input, in which case the scripting language is executed in response to those events. Modern Web browsers at a minimum support JavaScript and VBScript, either directly or through third-party extensions, and implement basic scripting events for communicating with and controlling other browser elements. The scripting languages can generally be used interchangeably, letting you mix and match as you choose. The Web browser loads, initializes, and passes content it cannot process itself to other components. The content may either be encapsulated within tags or passed through a file, with a .JAR, .EXE, or .DLL extension, on an , , or tag. Many of your Web Services will be invoked through this mechanism. When the Web browser detects JAVA applets or applications, it launches the Java Virtual Machine (JVM) and passes the applet or application to the JVM for execution. The Web browser in conjunction with the JVM creates and maintains a Java environment. Once initialized, the environment is maintained for the remain-
Protecting the System Components
163
der of the session. JavaScript can be used to control browser events and to communicate among Java applets and Java-based objects, for example, JavaBeans. When the Internet Explorer Web browser detects managed code, it launches the Common Language Runtime (CLR) and passes the code to the CLR for execution. Managed code is in the form of either an .EXE or .DLL file containing executable content in the form of Microsoft’s Intermediate Language (MSIL). As with JVM, the Web browser and CLR operate together to create and maintain an environment to support these components, and that environment is maintained for the duration of the user’s session. JavaScript or VBScript can be used to control browser events and to communicate among managed components. Instead of trying to anticipate every possible type of content and providing a “universal display engine” capable of recognizing and displaying that content, the Web browser framework implements an extensible way for Web browsers to be aware of, yet not directly responsible for, displaying that content: helper applications and plug-ins. Helper applications and plug-ins are generally responsible for understanding and displaying one or more MIME types. MIME types include formats for sound, graphics, and video. When this type of information is encountered, the Web browser launches either a helper application or plug-in to aid in its presentation. Figure 8.2 illustrates the relationship between the browser and these elements. Plug-ins can be implemented in either of two ways: internal or external. Internal plug-ins execute in the context of the browser, usually as a separate thread. External plug-ins and helper applications execute as separate applications in their own address space. The Web browser determines the MIME type associated with an element of content from its file extension. JPEG, GIF, and AVI are common MIME types detected in this manner. The Web browser uses associations to map either a helper application or plug-in to a given MIME type. Once an association is created, the Web browser launches the appropriate application when that MIME type is detected. Originally, helper applications and plug-ins were the only way to extend the browser to handle special inputs. Microsoft found this too limiting and decided to make the Web browser an object linking and embedding (OLE) container and introduced the idea of being able to extend the browser through ActiveX objects. This was more in keeping with Microsoft’s Active Desktop® concept at the time. The Web browser detects the presence of ActiveX objects as part of an tag reference. The object may already be present and registered on the client, in which case it is used. If it is not, the Web browser downloads the object and provides it with the associated content for processing or display. ActiveX objects can be implemented as either in-process or out-of-process servers as illustrated in Figure 8.2. In-process servers are similar to plug-ins executing within the context of the browser. Out-of-process servers execute as separate applications.
164
Enterprise Web Services Security
ActiveX In-Proc Server
ActiveX Out-of-Proc Server
Internal Plug-Ins
External Plug-Ins
Helper Applications
Browser Operating System
FIGURE 8.2 Plug-in and ActiveX environments.
DOWNLOADING COMPONENTS Helper applications, plug-ins, and ActiveX controls generally aren’t installed with the browser. Instead, they are downloaded either at the direction of the user or on demand. They are needed when the browser encounters a MIME type that it cannot render without the assistance of one of these components. The URL associated with the content specifies the server from which the component should be downloaded. The tag provides PLUGINURL and PLUGINPAGE attributes for this purpose; the tag provides a CODEBASE attribute. Helper applications and plug-ins are normally downloaded using the Java Archive (JAR) facility. This facility is invoked whenever an unregistered MIME type is encountered. The Web browser checks the PLUGINS directory on startup and registers all the helper applications and plug-ins found. The Web browser uses
Protecting the System Components
165
these applications to render the associated MIME type when that MIME type is encountered in a Web page. If the plug-in, or helper application, is not registered, the browser will download it from the specified server location via the JAR Manager. The steps involved in downloading a plug-in, or helper application, include: Determining the IP address of the server specified in the , or , tag’s PLUGINURL, PLUGINPAGE, or CODEBASE attribute from the domain name service (DNS) server Sending a POST or GET request specifying the name of the file to be retrieved Receiving the file from the server Saving the file in the PLUGINS directory Exploding (decompressing) the files Registering the file for the associated MIME type JAR files are compressed archives that use the same structure as ZIP files [Sun99]. This means the file may contain several files and directories. The JAR file should contain a special directory, META-INF, which contains instructions for registering and authenticating the contents. The META-INF directory will normally contain a manifest file, signature instruction files, and signature files. The manifest file contains a list of all the signed files. ActiveX controls follow a similar process. The steps involved in downloading ActiveX controls include: Determining if the correct version of the component is already resident Determining the IP address of each server specified in the Internet search path from the DNS server Sending a POST request specifying the name of the file to be retrieved Receiving the file from the server, if it is available Saving the file in the \windows\system\occcache directory Checking to ensure the file is safe to install Installing the file on the machine Registering the file Some of the differences in Microsoft’s approach to downloading ActiveX controls include the approach to locating the file to download, the approach to verifying the file, and the approach to registering the control. The Internet search path is specified in the registry and consists of three elements: URLs to be searched prior to CODEBASE, CODEBASE, and those to be searched following CODEBASE. The URLs before CODEBASE in the search sequence provide the means to specify cache, or more trusted, servers. Those following can be used to specify standard distribution points to be used if CODEBASE is not available. The
166
Enterprise Web Services Security
Internet search path is specified in the registry under the CodeBaseSearchPath key. The key is located under the InternetExplorer section of HKEY_CURRENT_USER\ Software\Microsoft. The CodeBaseSeachPath is specified in the form CodeBaseSearchPath=;;...;CODEBASE; ;...
To verify that the file is safe to install, call Windows Trust Provider Service function. WinVerifyTrust ensures that the component has been properly signed. Windows Trust Provider Service uses a hierarchical certificate structure to verify the signature. As previously mentioned, files are installed in the \windows\system\occcache directory. The files installed here may have been packaged in any of three ways: as a portable executable (PE) image file, a digitally signed cabinet (CAB) file, or as an information (INF) or setup script file. PE files are single files that are downloaded in uncompressed format from the server to the browser. CAB files are downloaded as a single file, but they can contain any number of files. CAB files are compressed using the Lempel-Ziv-Welch compression algorithm and normally contain an INF file to control their installation. INF files contain directions for downloading and installing a set of files. The INF file can point to files on multiple servers. When INF files are used to package an application, the INF file is not compressed. After the control is downloaded, the final step before activation is registration. The control is used to register the component. For DLLs, the browser calls the DLL’s DllRegisterServer method to complete the registration process. For EXEs, the browser launches the EXE with a /RegServer command line parameter. Microsoft introduced managed code components as part of its .NET architecture. In many respects, managed code objects are similar to ActiveX objects. The biggest advantage of managed code objects is that they do not have to be registered before they can be used. Managed code components are ones that have been compiled into MSIL and packaged as part of an assembly. An assembly may span files, so one or more files may have to be downloaded as part of the process. The assembly forms a complete package containing the code in the form of executables or DLLs, resources, such as bitmaps, and metadata. Each assembly contains a manifest describing its contents. The manifest includes versioning information composed of a four-part compatibility version (major version number, minor version number, build number, and revision number) and a human-readable informational version. The manifest also includes a hash of its contents, which is encrypted. The Web browser decrypts this number, recomputes the hash, and compares the results to ensure the code has not been changed. Finally, the assembly also contains the publisher’s public key and Rivest, Shamir, and Adleman (RSA) digital signature, which can be used to identify WinVerifyTrust
Protecting the System Components
167
the assembly with its publisher. Microsoft’s Authenticode® can be used to associate the publisher with the assembly as will be explained later.
ACTIVEX SECURITY ActiveX is built on Microsoft’s OLE technology. Microsoft developed OLE as a model for integrating applications based on its Component Object Model (COM). COM is an object model that enables two applications to communicate without either having to know how the other is implemented. OLE uses lightweight remote procedure calls (LRPC) to marshal requests between objects executing on the same machine and the Distributed Component Object Model (DCOM) to implement distributed objects. DCOM is implemented on top of the distributed computing environment (DCE) RPC specification. Microsoft introduced managed code with its .Net framework to overcome many of the disadvantages associated with ActiveX. When ActiveX was first introduced, executing components on the client meant downloading compiled, executable code onto the workstation and giving control to that code. With .Net, Microsoft has introduced the idea of an “intermediate language” and managed code, which is very similar in concept to Sun’s Java, and a just-in-time compiler as part of its CLR to solve some of the problems with downloading and executing raw executables. Managed code is written using any .Net-enabled language—C++, Visual Basic®, or C#—and executes within a CLR environment. CLR creates a standard set of base capabilities every component can draw upon. Additional services are layered on this base to create a rich runtime environment that is available to a component regardless of whether it is simply derived from a base class or built as a complex custom control. Much of the power of managed code components, like that of their ActiveX counterparts, comes from their ability to draw upon all the resources available from the underlying operating system and network. Given the large number of ActiveX components available and in use, you will likely find yourself in a situation where you are using managed code components to call ActiveX controls or vice versa. The call cannot be made directly because ActiveX controls are unmanaged code components and are based on Microsoft’s COM. Microsoft .NET Interop services provide the proxy capabilities needed to support the call across the managed code–unmanaged code boundary. Controls
An ActiveX object is an example of a COM control. A control is an object that encapsulates a user interface and associated control software in a form that allows the
168
Enterprise Web Services Security
control to be dynamically invoked as part of a user interface. This means the control has a user interface (for example, an image that the user can click on to cause the image to rotate) and software for managing that user interface. The control is packaged in a form that allows it to be installed in memory and activated by the user’s Web browser, using the same window as the user’s browser to display its interface. This allows seamless extension of the capabilities of the user’s browser. ActiveX controls allow extension of the browser’s user interface to include almost anything a local user interface program can do. Complex GUIs are possible that allow a Web Service to extend the user’s browser in nearly arbitrary ways [Act05]. Downloadable ActiveX controls exist for database processing, graphics processing, and multimedia display. ActiveX controls can be built and tested using standard Microsoft application development environments and can be written in several different programming languages. The Microsoft Visual Studio® programming environment makes implementation of a new ActiveX control a relatively easy job. While ActiveX allows very complex extension of the user’s browser, it has some disadvantages. ActiveX is a Microsoft proprietary technology that uses Windows operating system calls to set up and operate the control’s user interface. Native support for ActiveX is available in the Microsoft Internet Explorer browser; use of ActiveX with other Web browsers requires additional software to allow the control to execute. Some browsers do not have the ability to use ActiveX at all. Use of ActiveX thus limits the use of a Web Service to those users running an acceptable browser and to those running a Windows operating system on an Intel x86 family CPU. A more serious concern when ActiveX is in use is that the code incorporated in the ActiveX control executes in the user’s browser, using the user’s permissions and rights. Anything that user is permitted to do can be done by the control. Worse, the control contains native Windows application code, meaning the control is not restricted to only safe operations within a well-defined context. (In the next section we will discuss how Java attempts to correct this problem using its virtual machine and sandbox concepts.) This was demonstrated by an example ActiveX control that shut down the user’s PC when it was invoked [McLean97]]. Authenticode
It would be very unsafe to allow people to put controls on their Web sites that get downloaded and executed in a user’s Web browser with no limitations on what gets executed. Allowing this would make ActiveX a perfect mechanism for executing malicious code, also known as malware. Malicious code is software written to inflict some harm on the targeted system. This harm may take several forms. For example, malware could erase system files, expose user data to unauthorized individuals,
Protecting the System Components
169
and use the victim’s machine to assist in spreading copies of itself (a network worm). To help solve this problem, Microsoft uses a system called Authenticode [TechNet05] to protect against malicious code. Authenticode uses a code signing technique to validate the source of an ActiveX control. A digital signature for the control is created using the author’s private key (which only the author is able to use). ActiveX packages the control with the author’s signature and a copy of their public key certificate. That certificate must be signed by a trusted certificate authority. When a control is referenced in a Web page, it is downloaded and the signature is verified. If the public key certificate does not verify or if the signature is invalid, the control does not execute. The certificate is displayed to the user to allow him to permit or deny execution of the ActiveX control. The user is allowed to accept all content from a particular author if he wishes. (This is generally a bad idea, but unfortunately the ActiveX permission prompt leads many people to trust all content from Microsoft Corporation, potentially allowing things they weren’t aware of to execute on their systems with no further requests for permission.) The Authenticode system allows the user’s operating system to verify the source of a control. While this does not fix any problems a malicious control may cause, it is easy to track down the authors of the malware and take action against them. This is usually adequate to limit the risk, as people aren’t going to distribute malicious software that can be proven to be theirs, thus exposing them to liability. Another way in which Internet Explorer attempts to restrict ActiveX is by the use of defined security zones [TechNet05]. Only controls signed by trusted sites are allowed to execute in the trusted sites zone. Controls downloaded from the Internet are not allowed to execute without user verification. The user can also define untrusted sites and deny all active content that comes from those sites. In addition, Internet Explorer allows a user to deny all active content, including denial of all ActiveX controls. Unfortunately, the default “Medium Security” configuration allows ActiveX controls to execute if the user gives permission.
JAVA SECURITY The second form of active content for extending Web browsers uses Java. The Java programming language was originally written by a group at Sun Microsystems that was tasked with designing a language for controlling small, dedicated appliances [Byous98]. They designed a system for set-top cable television control boxes that was processor independent, allowing the resulting system to run on different CPU types without being rebuilt. While the cable TV project did not succeed, the authors saw an opportunity to marry their language with the newly emerging world of the Web. They created a demonstration Web browser called HotJava, which eventually
170
Enterprise Web Services Security
led to an agreement with Netscape to incorporate the Java technology as part of the Netscape Web browser [Byous98]. Java provides capabilities that are competitive with ActiveX. A Java program, called an applet, is downloaded to the user’s computer and executed in the context of the user’s Web browser. Like ActiveX, the applet can interact with the user using a GUI to accept user input, process that input, and send it to a server after verification. Both Java and ActiveX provide a highly interactive user interface that displays within the browser window, making the applet or control appear to be an integrated part of the browser itself. While Java is similar in capability to ActiveX, there are several ways in which the two platforms differ. One important way is that Java is processor and platform independent. While an ActiveX control is targeted for a Windows platform on an Intel x86 CPU, Java can execute on multiple platforms (for example, Windows, Mac, UNIX, and OpenVMS) and on several different processor types. The Java Virtual Machine
Java operates on multiple platforms and operating systems because the Java compiler does not generate native code that executes on a single platform. The compiler generates code for an abstract machine that does not exist in a compact encoded form called bytecode. The platform that executes the resulting bytecode program has an emulator that simulates that abstract machine. This simulator is called a virtual machine emulator. The emulator that enables Java programs to run is called a Java virtual machine (JVM). A Java program can operate on any system that has an associated JVM available. Normally the vendor that writes the operating system builds a JVM for its system to allow Java programs to execute. The JVM translates Java GUI requests to platform-specific GUI operations, allowing the program to operate across multiple platforms. This portability across platforms does not come without a cost. Since the Java program is not native code, it is significantly slower than an equivalent ActiveX control. While this is a disadvantage of Java, the performance gap is made smaller by optimizations to the JVM, including software that recompiles the Java code into native code just prior to executing it. A Java applet can approach native speed using such technology. Java does have some functional limitations that ActiveX does not share. While ActiveX controls can perform any operation permitted by the Windows operating system, Java programs are restricted to a common set of operations shared by multiple platforms. Some more complex operations (or operating system–specific operations) may be unavailable to the Java programmer. There are also multiple suppliers of JVMs, and quirks may be exposed by complex code that leads to compatibility problems when different JVMs are in use. (Simple code is, however, generally quite portable between VMs.)
Protecting the System Components
171
The Sandbox
The Java environment for the Web was designed to limit the security concerns posed by code that may potentially be malicious. Like most programming languages, Java has the potential to perform dangerous operations that the Web browser’s user may not want to allow. To combat this, the browser’s JVM executes the applet in a constrained environment called the sandbox [McGraw97]. The sandbox restricts what the applet’s JVM is permitted to do, restricting it so that it can only play in the sandbox. Several operations are denied when an applet attempts them. First, local file access is denied. This restriction ensures that the applet is not permitted to reveal the contents of the user’s files. Second, network connections from the applet are only permitted to the system that the applet came from. This allows the applet to download configuration data from its source but does not allow it to make arbitrary network connections. This restriction ensures that the applet cannot be used as a traffic flood generator, as the only system it could attack is the one the applet came from. Other operations, such as displaying arbitrary message windows and reading system configuration details are also denied by the sandbox mechanism. These keep the applet from spoofing a valid dialog (to, for example, capture a user’s password) or from sending user information to the applet’s source. The JVM also provides additional security checks to confirm that the compiled Java code is properly formed. The sandbox concept attempts to restrict an applet by defining actions that could be damaging and ensuring that the applet is not able to perform those operations. Other than those constraints, Java applets are usually permitted to execute without requesting permission from the user. This is very different from the ActiveX methodology, which asks for permission first. Signing Code
Java applets can also contain a digital signature to verify the source. As with ActiveX, the applet developer is issued a digital certificate that verifies their identity. A digital signature is attached to the applet along with a copy of the developer’s certificate. When the applet is loaded, the signature is verified to ensure that the code has not been tampered with prior to execution. Signed applets can request additional privileges that are normally denied by the sandbox [Mage99, McGraw97].
SCRIPTING Scripting languages are embedded in the downloaded Web page and are executed by the user’s Web browser. The scripting language elements can perform rudimentary tasks and help tie ActiveX and Java components together.
172
Enterprise Web Services Security
Scripting was originally introduced for coordinating interactions between Web browsers and components executing in peer relationships, that is, plug-ins, Java applets, and ActiveX controls. Prior to scripting, the only choices you had were static Web pages and external components. Highly dynamic content and high degrees of interaction required the use of external controls and external applications to support them. If you wanted to change the HTML on the current page, a round trip between the client and the server was required to communicate an event to the server and download an updated page. This implied a tradeoff between the degree of interactivity and performance and made the Internet far more useful as a reference tool than as a medium for business transactions. Scripting changed this by providing a way of communicating user and browser events between the browser and its peer components without involving the server; all the interactions could occur solely on the client. Once dynamic HTML (DHTML) was introduced, scripting in conjunction with DHTML carried this interaction a step further to include HTML itself. The script language understood by most Web browsers is called JavaScript or ECMAScript. JavaScript bears a passing resemblance to Java, but they are very different things. The only real commonality is the “Java” portion of the name, which was apparently chosen by Netscape for marketing reasons [Harold97]. A Java program is compiled into a component, but a JavaScript program is not compiled. It is interpreted “on the fly” by the browser in response to user activity. JavaScript programs can be incorporated into Web pages to allow verification of user input (allowing only numbers to be placed into a telephone number field, for example) to help vet the user’s submission before it is sent off to the Web server. Unfortunately, JavaScript can also be used to pop up advertising windows and other annoyances, so it is frequently disabled. A Web site should carefully consider why it chooses to use JavaScript, given that a number of users refuse (quite correctly) to allow JavaScript to run. Alternative means of performing the same operations when scripts are disabled should be considered.
PLUG-INS Web browsers can also be extended by the use of plug-ins. A plug-in is a program that extends the capability of a Web browser by allowing it to handle a new document type. Plug-ins are similar to ActiveX controls, as they are native platform code that executes in the browser context with the rights and permissions of the user [NSTISSC00]. Unfortunately, plug-in technology has been embraced by spyware vendors. These are companies that install software into users’ Web browser in order to direct
Protecting the System Components
173
them to advertising sites or to track their actions. Spyware often reports user activity to some home base, invading user privacy [Cexx05]. Plug-ins cause the same security concerns that bots cause: a compromised system is often unstable, and the spyware may reveal sensitive user information. Several packages exist that assist users with removing spyware plug-ins. Examples of these are Spybot Search and Destroy (http://www.safer-networking.org/en/index. html) and Ad-Aware (http://www.lavasoftusa.com).
THE NETWORK The second system component that Web Service designers must consider is the network. The network ties the components of the system together; without a functioning network there is no Web and no Web Service. Dependence on the network leads to vulnerabilities that the service designer must keep in mind when designing the system.
NETWORK VULNERABILITIES The network is a source of threats to all of the basic aspects of system security. Confidentiality, integrity, and availability of service information are all subject to attack when traveling over the network because the systems that make the network operate may not be under the Web Service designer’s control. The path between the user’s browser and the Web server that provides access to the Web Service application may pass through dozens of systems controlled by parties that are outside the Web Service provider’s control. At any point along the path someone may attempt to compromise the security of the system’s information with any of the following attacks: Confidentiality: Exposure of service data by snooping the traffic and making local copies Integrity: Tampering with service data by modifying the content Availability: Blocking Web Service data flow or flooding a server to deny legitimate users There is very little the Web Service can do to control threats mounted from the network. If you can’t control the network routers and network links, you are at the mercy of the owners of those components. Fortunately, there are things you can do to mitigate some of the risks. Confidentiality and integrity of network traffic can be
174
Enterprise Web Services Security
protected using cryptographic means such as Secure Sockets Layer (SSL) as will be discussed in Chapter 10. Availability risks are more difficult to mitigate. One possible solution for availability concerns is to configure redundant network links to help recover from connection failures. Redundant network hardware can be configured at server sites to help resist availability attacks. Other network protections may come from firewalls, redundant gateways, and guards, which will be discussed later. Cryptographic protections are not a panacea for all network security problems. Waving “crypto fairy dust” [Smith03] over a problem doesn’t make it go away; it simply moves the problem somewhere else (key management, for example). The problems with cryptographic quick fixes will be discussed further in Chapter 10.
WIRELESS COMMUNICATIONS As discussed in Chapter 1, two forms of wireless networking are used to support Web Services. These are used to support wireless mobile telephones and mobile workstations. The mobile telephone user makes Web Service requests via a Wireless Application Protocol (WAP) gateway. The communications between the telephone and the gateway and between the gateway and the Web server that supports the wireless application are protected using protocols similar to those used by normal Web browsers for secured communications. The primary concern for these types of wireless applications is the gateway system itself. User credentials are sent via the gateway; if that system is compromised, the attacker can steal user authentication information and spoof legitimate transactions that appear to come from a valid user. Another way in which wireless communication is used is in a wireless network system such as Wi-Fi. This raises a significant concern for confidentiality of the Web Service communications that are transported over the wireless LAN. The problem with wireless links is that they use public airwaves to carry network traffic. This means it is very easy for someone to “tap” the network since it only requires that the attacker be physically close to the wireless infrastructure. This is much more difficult than tapping wired networks. You wouldn’t allow someone into your building with a network sniffer and allow them to connect to your LAN and start capturing traffic, but a wireless network can be attacked from your company’s parking lot. Like wired networks, wireless networks can be protected using cryptographic techniques (details on how these techniques work will be covered in Chapter 10).
Protecting the System Components
175
One must be careful how these are implemented, however. The first set of cryptographic protections for 802.11 wireless networks was called Wired Equivalent Privacy (WEP). WEP had several implementation flaws that allowed an attacker to bypass it and read network traffic simply by capturing enough encrypted traffic [SIR01]. The replacement protocol, Wireless Protected Access (WPA) is being rolled out in current products [WiFi03] and is highly recommended as a replacement for WEP. If WPA is unavailable and WEP must be used, then a policy must be implemented to force frequent WEP key changes. This will not stop wireless attackers from sniffing your traffic, but it will limit how much information they can obtain. Unfortunately, for a heavily utilized network, key changes may need to be done on a daily basis.
FIREWALLS Another way of protecting Web Service components is to isolate them from the Internet. Frequently, companies have a policy stating that access to their internal systems should not be accessed by anyone other than authorized employees. Connecting a company to the Internet places the internal servers and workstations at risk from attack from the Internet. A firewall is a gateway between two networks that implements a particular security policy. A common policy is that trusted insiders are allowed to access the Internet but untrusted outsiders are banned from connecting to internal systems. Placing a firewall between a company’s LAN and the Internet is a common means of protecting those assets that are protected by the firewall. (The firewall term is used because the firewall is similar to the metal shield that isolates the engine compartments from the passenger compartments of automobiles and airplanes. This firewall protects the passengers from engine fires. The network firewall provides similar protection for the internal network systems; this means those internal systems do not need to be hardened to resist Internet-borne attacks. These attacks may attempt to compromise any of the security goals [confidentiality, integrity, and availability]). A well-designed firewall will resist attacks of all kinds while allowing the traffic necessary for normal system operations to pass. From a Web Services standpoint, firewalls can be a barrier that will need to be overcome. This may require that the policy be changed to permit the Web Service to pass traffic that it needs in order to get the job done or that the Web Service encapsulate it’s traffic in forms that are permitted by the firewall. The SOAP scheme (which will be discussed in Chapter 5) is one way of allowing Web Service traffic to pass through a firewall.
176
Enterprise Web Services Security
GATEWAYS, GUARDS, AND ROUTERS A gateway is a system that connects two networks, allowing specified types of traffic to pass. For example, an email gateway would only allow email traffic to pass between the networks. These are more specialized than a firewall system, as they permit only a restricted type of traffic to flow. A gateway is usually a simple system with limited capabilities and is usually used in a situation where its proper operation must be certified and accredited. A single-function gateway simplifies documenting that gateway’s operation for certification. Gateways are also used to bridge between mobile telephone networks and the Internet, as previously discussed. A guard is a form of gateway that implements an information-flow control policy. They are used on networks that handle classified information and are responsible for ensuring that information that passes through the guard does not violate the confidentiality of the information flow. A guard connected between the Internet and a network processing classified information would not allow classified documents to leak onto the Internet. It enforces this policy by inspecting the contents of the information being passed through the guard to determine how the information should be classified. A guard may pose a problem for a Web Service system if it is blocking traffic that the service needs. A router connects networks and allows network traffic to flow between those networks. A router can have simple filtering operations enabled that allow it to act as a rudimentary firewall system. Often routers are used in combination with a firewall in a “belt and braces” (or “belt and suspenders”) system. If one protection fails, the other protection is still in place and able to resist some forms of attack. The only concern from a Web Services point of view is similar to those with a guard. A router may need to be configured to permit the Web Service traffic to pass. Routers and firewalls act at the network layer (layer 3) of the Open Systems Interconnection (OSI) stack [OSI94] (discussed in Chapter 6). For completeness, we should also mention hubs and switches. These are network components that operate at layer 2 (data link), providing LAN connectivity to multiple hosts. A hub is a simple system that connects several systems, allowing all of the connected hosts to “hear” all of the traffic flowing through the hub. A switch improves upon this by adding traffic management, which isolates traffic between machines A and B that are connected to a particular switch so that other hosts do not see that traffic. While this provides some security advantage (attackers can’t sniff the traffic between A and B if they don’t see it), that advantage is not guaranteed.
Protecting the System Components
177
VIRTUAL PRIVATE NETWORKS A virtual private network (VPN) provides a way for traffic to flow between systems over a public network (such as the Internet) while remaining private. An IP Security (IPSec) VPN provides both integrity and confidentiality protection for network data, allowing the Internet to be a low-cost alternative to a private network circuit. If properly used, an IPSec VPN is secure as a dedicated, protected private network link. The primary issue with secure VPN usage is key management. Public key–based encryption and integrity keys are preferred over statically defined session keys. If static keys are used, the key values should be changed frequently. From a Web Services standpoint, VPNs are most likely used to allow private connections between service nodes that support a Web Service. For example, a pair of database servers that are protected by a set of firewalls may replicate their database contents over a VPN connection instead of going over the public Internet. These behind-the-firewall, back-end connections should use a VPN or some other means of connectivity that does not expose the data to sniffers or data recording and replay attacks.
SERVERS The final Web Service environment components are the servers that provide responses to user requests. There are usually a small number of servers compared to the number of client systems, making the job of securing them more reasonable. It is expected that more effort will be expended in securing the service systems, as they house more of the sensitive information. A single client system compromise may expose that user’s information, while a server compromise might expose the data for all users, making the extra effort spent securing the server systems more than worthwhile. When considering how to secure the servers that support your applications, the first perspective should be physical access. As a general rule, policies should stipulate that servers be located in secure areas with as few individuals as possible permitted access to servers containing sensitive information. This is an obvious point that’s easily understood, but for some reason systems continue to be exposed to attack because they are not properly protected (or the protections are allowed to lapse). For this reason, it’s important to state the need for physical security even if it’s obvious. The next level is logical access. Policies should clearly identify processes and services that have logical access to servers. The most common ones are centralized
178
Enterprise Web Services Security
backup and monitoring systems. Centralized services generally have two requirements. One requirement is for some service-specific software to be present and enabled on each server. The second requirement is for some degree of access and privilege to each server from the central service. The security policy should clearly define procedures for installing, configuring, and maintaining any local software and should specify the level of access to the server from the central service. The central service should not be given more than the minimum privileges necessary to perform its function. Systems administration is the third perspective. Systems administrators normally have root or super user privileges on the servers they support. Policies should clearly delineate roles and responsibilities and the separation of duties required. A key question an organization should ask concerning systems administration is whether Web server administrators should also be database administrators and should also be certificate authority administrators and should also be network administrators. The greater the responsibility, the greater the risk from errors or inaction. A fourth perspective is from the server itself and its lockdown. Attacks can be launched through unneeded open services or protocols running on the servers. An organization should configure servers with the minimum privileges and services they need to perform their function. Since larger organizations rarely have just one instance of any particular server type (HTTP, applications, database, and print), policies should include standard lockdown procedures for each type of server owned by the organization. While the operating system lockdown may be the same, the ports and services will be unique depending on the type of server. Server policy should also include guidelines concerning: Auditing: Specifying auditable events, audit retention periods, etc. Passwords: Specifying length, composition, frequency of change, etc. Key Files: Specific guidelines for locking down critical files such as registry and configuration files Patch Level: Specifying that servers should be upgraded within some time period following vendor release of security-relevant patches and releases The Center for Internet Security and NSA sites mentioned earlier are good sources of the latest lockdown information for many different types of operating systems and servers.
Protecting the System Components
179
WEB SERVER VULNERABILITIES The Web server is the most exposed component of the Web Service system. It must allow at least Web (HTTP) traffic inbound from the Internet. This exposes Web servers to attack from anywhere in the world. The history of Web server vulnerabilities means the Web Service designers and administrators must understand the potential problems and their solutions. CGI Flaws
A Web browser accepts user input into a form and returns the resulting data to the target Web server by sending the result to a processing program on the server. The Common Gateway Interface (CGI) defines how the browser transmits the user input to the server, how the Web server processes that input, and how the Web server returns an appropriate response. Figure 8.3 shows how a Web server invokes a CGI program for processing form input.
Web Browser
Encoded Data Web Server
Encoded Data
User Output
CGI Application Process Form Data Output Response
FIGURE 8.3 CGI processing information flow.
The flow depicted in Figure 8.3 shows how form data is processed. It is collected from the user, sent to the Web server over the Internet, and then transmitted to the CGI program that is responsible for verifying the user input and performing the appropriate operation for the user. This might entail storing a record in a database or updating a database record.
180
Enterprise Web Services Security
CGI programs are unfortunately subject to the same programmatic flaws as other types of programs. They fail to check user input and are therefore subject to buffer overflows and other problems. One common cause of problems with CGI programs is a failure to check user input before using it. For example, let’s say a form accepts a username for input and uses it as part of a Structured Query Language (SQL) query. The query might be constructed like the following: SELECT * FROM users WHERE username=’$USER’
where the $USER string is a variable reference that is set to some value based on what the user provides. If that input is not checked for validity, a hostile user can enter the following as his username: admin’;UPDATE users SET password=’admin’ WHERE username=’admin
When the user’s input is stored in the original command, the resulting command sent to the database is a series of SQL commands separated by semicolons: SELECT * FROM users where username=’admin’; UPDATE users SET password=’admin’ WHERE username=’admin’;
This is an example of a well-known type of exploit that allows the attacker to modify the password of the administrative user. It can be thwarted by strict checking of user input, as single quotes are not normally valid in usernames. The CGI program is responsible for checking that no quotes appear in the user input before using the values. Just as important are checks for length violations. Attempts to put very long values into a fixed-length buffer can lead to buffer overflows that can allow an attacker to compromise the Web server. Denial of Service
Another form of threat for a Web server is a denial-of-service (DoS) attack. These attacks are mounted by people trying to disrupt operations of the Web site. They can do this by flooding the server with requests so it is unable to handle legitimate user requests. The zombie networks described earlier are often used in distributed DoS (DDoS) attacks. These attacks coordinate a group of zombie systems to generate an overwhelming traffic level. DDoS attacks are much more difficult to bypass because they do not originate from a single source and thus cannot be blocked at the network level. There isn’t much that a Web Service system can do to avoid DoS attacks. You can escalate these to the Internet service provider (ISP) providing connectivity to
Protecting the System Components
181
the Web server, but this may not help in all cases. Having multiple sites that are physically separated can assist in resisting such attacks. Weak Authentication
Web Services typically process data on behalf of a particular user. Most sites identify their users by use of simple reusable passwords. Human nature leads people to choose passwords badly. They use bad passwords (their pet’s name, their own name, dictionary words, etc.) and reuse those bad passwords across multiple sites. Given this, there is little assurance that users really are who they say they are. Weak authentication is subject to simple brute-force attacks, where passwords are guessed until the correct one is found. Very often, Web-based systems do not keep track of login failures, allowing an attacker an unlimited number of guesses. Eventually, a valid username/password combination will be found. Another problem with Web authentication is that the standard authentication method, Basic Authentication, sends the user’s username/password pair to the Web server as part of the headers sent with every request to that Web server. The username and password are encoded in Base-64, but this is done to ensure that special characters are allowed in passwords, not to obscure the password content. Anyone sniffing traffic from the client end or the server end is able to easily recover the user’s password. Several alternatives exist that allow stronger user authentication. These include user public key certificates and the use of one-time password devices such as the SecurID® token. Unfortunately, these are infrequently used. All that a Web Service can do is test for weak passwords and reject them. Auditing failed logins and keeping a count of failed logins are also recommended.
OPERATING SYSTEM SECURITY A Web server requires an operating system to run. The operating system provides the Web server with necessary services such as a network stack and a filesystem for storing Web pages. Particular security concerns for Web servers should be considered when operating the service. Some of those are discussed below. User Accounts
A Web server should be a dedicated system in almost all cases. This implies that there are few user accounts on the system and in particular that there are no user accounts other than those used by the server administrators. This policy is enforced to ensure that users are not able to compromise the security of the Web server
182
Enterprise Web Services Security
configuration. The basis of this policy is that many of the compromises against operating systems require local login access to the server system. Since users have historically not been able to maintain adequate passwords, their user accounts may be subject to brute-force attacks, allowing an attacker an opportunity to use a local exploit to increase their privileges and thereby compromise the underlying operating system. A single administrative account is adequate. More than one may be used to help provide an audit trail of which administrator was responsible for a particular action on or change to a system’s configuration. A periodic audit of the system should be performed to ensure that unexpected user accounts have not been added to the system. Server Hardening
Many default installations of Web server systems leave many unnecessary files and applications installed. Any unnecessary files or applications complicate the server configuration and may eventually lead to compromise. The rationale for this is simple: if an application is not installed on your server, it does not matter if that application has an exploitable flaw. The server should be configured with conservative settings that minimize the chance of compromise. The process of eliminating unnecessary software and locking down the settings is called hardening the server, as it makes the server harder to attack. Frequently Web server installations come with sample or demonstration pages designed to help Web developers build their sites. Unfortunately, several of these have been found to be improperly coded, allowing compromise of server contents. This is true of several types of Web server software. Just like unnecessary software applications, unnecessary sample files should be removed from the Web server before it goes into production. Full details of the hardening process are outside the scope of this book, but there are several very good guides to help lock down Web server configurations. The NSA has guidance for several systems [NSA05]. Another source of guidance is the server configuration benchmarks available from the Center for Internet Security [CIS04]. Both of these guides can help improve the attack resistance of your Web server system. File Access/Permissions
Even if one of the previously mentioned hardening documents is used, other things should be done to help keep the Web server secure. Normally, Web server software runs as a nonprivileged user (nobody on UNIX and IUSR_hostname on Windows). The directories that contain Web site content should be protected so that the Web server user is not allowed to write to them. Some administrators protect their entire
Protecting the System Components
183
system so the Web server user has no write access anywhere. This can be a simple way of protecting Web site content from tampering as long as the site’s service programs do not need to write to disk (this might be necessary for a service program that temporarily stores a large amount of information). Any operating system files, including programs that comprise the Web server, should be protected so that the Web user cannot access them unless necessary for normal server operation. Disallowing access to these programs may contain a compromise if one happens, allowing a form of “defense in depth,” where multiple layers of protection need to be breached for an attacker to be successful. Some operating systems have more flexible access controls than others, but you should take advantage of whatever abilities your system provides to help contain the Web user in order to limit the chance of compromise. File Content
A final consideration for the Web server is the content of the files and databases stored on the server. Any file that has sensitive content should have particular attention paid to ensure that the contents are not compromised. A frequently seen and easily understood example of this is a file containing user order information, including credit card numbers. Every possible effort should be put forth to protect such data files against disclosure. One scheme for doing this involves removing such content from the Web server as quickly as possible. For example, an order’s content can be gathered, written to a temporary file, and then deleted after the transaction is saved onto a separate database server system. Encrypting the data while it is in transit could also be considered.
SUMMARY In this chapter we have pointed out some of the possible security problems that arise from the environment that supports your Web Service system. These security problems should be considered and addressed while designing your system. While some do not have simple “silver bullet” fixes, service designers can take steps to limit the chances of successful compromise of their systems. System components in a Web Services environment include client workstations, servers, the underlying network, and the operating systems supporting these systems. We looked at some of the major vulnerabilities of each of these components and techniques for “locking them down.” We explored in detail the issues mobile code and downloaded components present to clients and how Authenticode and signed Java components can help mitigate these risks. At the network
184
Enterprise Web Services Security
level, we looked at the role firewalls, gateways, guards, routers, and VPNs can play in increasing network-level security. For servers, we looked at the vulnerabilities CGI scripts and weak authentication represent and how user and file administration in conjunction with proper server lock down can help mitigate these and other risks.
REFERENCES [Act05] Active-X.com, “What is Active X?” Available online at http://www.activex.com/articles/whatis.htm. [Byous98] Byous, Jon, “Java Technology: The Early Years.” Available online at http://java.sun.com/features/1998/05/birthday.html. [Cexx05] cexx.org, “The Trouble with Spyware and Advertising-Supported Software.” Available online at http://www.cexx.org/problem.htm. [CIS04] The Center for Internet Security, “CIS Level-1 Benchmark and Scoring Tool for Solaris.” Available online at http://www.cisecurity.org/bench_ solaris.html. [Harold97] Harold, Elliotte, “The comp.lang.java FAQ List.” Available online at http://www.ibiblio.org/javafaq/javafaq.html#xtocid90007. [Kapersky04] Kapersky Labs, “Malware Trends in 2004.” Available online at http://www.kaspersky.com/news?id=156802893. [Keizer04] Keizer, Gregg, “New Bagel Worm Slows After Fast Start.” Information Week (July 16, 2004). [Mage99] MageLang Institute, “Security.” Available online at http://java.sun. com/developer/onlineTraining/Security/Fundamentals/Security.html#secAppletSecurityManager. [McGraw97] McGraw, Gary and Edward Felten, “Understanding the Keys to Java Security—the Sandbox and Authentication.” Available online at http://www. javaworld.com/javaworld/jw-05-1997/jw-05-security.html. [McLean97] McLean, Fred, “The Exploder Control Frequently Asked Questions (FAQ).” Available online at http://dslweb.nwnexus.com/mclain/ActiveX/ Exploder/FAQ.htm. [NSA05] National Security Agency, “Security Configuration Guides.” Available online at http://www.nsa.gov/snac/. [NSTISSC00] NSTISSC, “Advisory Memorandum on Web Browser Security Vulnerabilities.” Available online at http://csrc.nist.gov/publications/secpubs/ web-secvul.pdf.
Protecting the System Components
185
[OSI94] International Standards Organization, “ISO 7498-1 Information Processing Systems—Open Systems Interconnection—Basic Reference Model: The Basic Model, Technical Report.” International Standards Organization, 1994. [RFC2504] Guthman, E., et al., “RFC-2504 User’s Security Handbook.” Available online at http://www.ietf.org/rfc/rfc2504.txt, February 1999. [SIR01] Stubblefield, Adam, John Ioannidis, and Avriel D. Rubin, “Using the Fluhrer, Mantin, and Shamir Attack to Break WEP.” Available online at http://www.workingwireless.net/wireless/Documents/wireless_extreme/wep_ attack.html. [Smith03] Smith, Sean, “Fairy Dust, Secrets, and the Real World.”January 2003. [Sun99] Sun Microsystems, “JAR File Specification.” Available online at http:// java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html. [TechNet05] Microsoft Corporation, “Microsoft Authenticode Reference Guide.” Available online at http://www.microsoft.com/technet/archive/security/topics/ secaps/authcode.mspx. [vonAhn04] von Ahn, Luis et al., “CAPTCHA: Using Hard AI Problems for Security.” Eurocrypt 2000 conference. Available online at http://www-2.cs.cmu.edu/ ~biglou/captcha_crypt.pdf. [WiFi03] WiFi Alliance, “Overview: WiFi Protected Access.” Available online at http://www.wi-fi.org/OpenSection/pdf/Wi-Fi_Protected_Access_Overview.pdf.
This page intentionally left blank
9
Protecting Messages, Transactions, and Data
In This Chapter Protecting a Web Services Exchange Securing the Communications Channel Identity Management and Trust Authentication Authorization Access Control Summary References
n the last chapter, we looked at implementing security mechanisms at the system and network level. Web Services is about communicating messages between Web Services clients and Web Services servers that ride on top of this infrastructure. The client may be a person, a process, or another Web Service. The service is by definition a Web Service and as such is implemented either in software or by a hardware component capable of exposing a Web Services’ interface. It is loosely coupled, discoverable, and Simple Object Access Protocol (SOAP) based. The message may be a document, one side of a remote procedure call (RPC) exchange, or a transaction, and in the latter instance, either a business or atomic type transaction. Depending on the purpose of the communication and the sensitivity of the information being exchanged, the parties may require various degrees of trust and
I
187
188
Enterprise Web Services Security
privacy. In some instances, the system and network mechanisms may be enough to protect the traffic. In others, additional protection mechanisms must be applied either in the software components underpinning the Web Service or in the Web Service itself. There are tradeoffs involved in choosing the security mechanisms themselves and in placing those mechanisms within the hardware, software, and network stack. In this chapter we explain the ways that Web Services help in securing the information used by the clients and servers in a transaction. Our focus is on the availability part of the confidentiality, integrity, and availability information security triad [FIPS199 03, NIST800-33]. (We will discuss the other two parts in detail in the next chapter.) Availability controls are meant to ensure that when a valid request is made to access some piece of information, that access will succeed. Availability is concerned with making sure users are who they say they are, only have access to the information they are authorized to access, and can only perform the functions they are authorized to perform. Identity management and the ability to create trust relationships between parties are key when it comes to assuring availability.
PROTECTING A WEB SERVICES EXCHANGE Figure 9.1 shows the primary actors in a Web Services exchange, as defined in the WS-Trust model, and their relationships [WSTrust04]. In this model, the Web Services client wants to communicate one or more messages with a Web Services server through a secure channel that traverses a communications environment of varying degrees of trust. The parties to the communication may independently trust one another in a direct trust relationship or may need to depend on a mutually trusted third party in a brokered relationship. In establishing their trust relationship, the parties may exchange credentials in-band, as part of the communication itself, or out-of-band either directly or through a third party. Similarly, each party to the exchange may have originally received its credential through an in-band or out-ofband exchange. The degree to which the parties trust the underlying communications environment normally depends on the nature of the environment and the degree of control the parties have over its components. Parties communicating across an intranet where they control the network can place greater trust in the communications environment than those communicating across an extranet or the Internet. Three factors can complicate the simple exchange scenario shown in Figure 9.1. One complicating factor can be the number of different actors involved and the parts they play in the exchange. The Web Services client and server are the minimum set of actors. A third-party trust broker comes into play in brokered trust re-
Protecting Messages, Transactions, and Data
als nti de e r C
Trusted Third Party
189
Cre de nti als
Trust Domain Clients
Servers
Me
ssa
ge
Me
ssa
ge
Communications Environment
FIGURE 9.1 Basic security model.
lationships. At a minimum, a Web Services Description Language (WSDL) server comes into the picture with runtime discovery, and a Universal Description, Discovery, and Integration (UDDI) server may enter the picture at this juncture as well. When is the list of actors complete? When it includes all of the services relevant to the transaction. Since Web Services are choreographable, the list can become quite large—especially in coarse-grained message sequences where one Web Service calls upon another to perform some part of the processing. Each interface potentially represents a pair of actors, where that pair may need to secure their part of the message exchange, using the techniques we discuss later in this chapter, and to involve a third party in establishing their trust relationship. A second complicating factor can be the communications environment between the Web Services client and server. In complex environments, intermediaries may need to route or refer messages among various communications nodes in order to guarantee message delivery between the two principal endpoints [WSRouting01, WSReferal01]. These intermediaries may need to access different parts of the message, especially the SOAP header, and may require the ability to modify the message content in order to fulfill their role. The ability to apply end-to-end, as opposed to point-to-point, mechanisms becomes important in these types of scenarios. The third complicating factor, particularly in the Internet environment, is the number and variety of potential security domains, policies, and mechanisms that can come into play. The ability to create virtual trust domains and trust relationships, to bridge domains, and to proxy credentials between domains is important in nonhomogeneous environments.
190
Enterprise Web Services Security
In this chapter and the next, we will look at the basic security services and mechanisms available for establishing trust relationships and securing Web Services communications. The basic services are authentication, authorization, confidentiality, and integrity [WSSecurity04, IATF02]. We will primarily look at these services from the Web Services server’s perspective, but both parties to a communication may have similar concerns and may use similar underlying mechanisms. For example, parties to a communication will generally want to mutually authenticate before beginning any secure type of message exchange. Mutual authentication assumes that both parties are able to challenge for, produce, and verify credentials as part of establishing their trust relationship. The security services we discuss assume the endpoints to the communication are secure. Unauthorized parties with unrestricted access to the hardware or software at an endpoint can subvert any security mechanisms you might put into place. In such an environment, your safest option is to assume any services provided by or communications with the endpoint are compromised.
SECURING THE COMMUNICATIONS CHANNEL The first step in securing a Web Services message exchange is to create a secure channel between the Web Services client and server. The secure channel provides a secure communications path between the two parties that enables them to share sensitive information without fear of compromise. Open Systems Interconnection (OSI) defines a seven-layer model for describing communications-based applications [OSI94]. These seven layers form the communications channel. Assuming you have already decided that you need a secure channel, the question becomes, at what level within this model do you secure it? The amount of trust you have in the underlying network and how much control you have over its components are two key factors in making this decision. Performance is a third. Given that you will use encryption services to secure the channel, where you secure the channel within the protocol stack can play a major role in how well your application performs; performance normally degrades, the higher you go in the stack as you move from hardware to software encryption. A countering paradox is that overall security increases as you move up the stack. While you potentially encrypt less information at each layer, the information you do encrypt is more secure because you can selectively control what information is encrypted and how much of it is accessible to any given recipient or intermediary. In addition to the question of where in the stack to perform the encryption, with today’s technologies and the performance available, especially at the lowest levels of the protocol stack, there is also a question of how many times you want to
Protecting Messages, Transactions, and Data
191
encrypt the traffic. For example, in some situations, you could choose to use secure HTTP (HTTPS) over IP Security (IPSEC) to effectively create a secure channel, or encrypted tunnel, within a secure channel. This is obvious overkill in most scenarios but could be quite appropriate in others. So, how much encryption is enough? We’ll refer back to the discussion in Chapter 6 on security tradeoffs and implementing cost-effective measures. Link, Network, and Applications Layer Encryption Link encryption places data link-level encryption devices on both the client and the server sides of the channel [CNSS03]. The client and server can communicate securely because the encryption device encrypts all traffic across the link. Linklevel encryption devices turn the entire link into an encrypted tunnel. Network encryption places network layer encryption devices on both the client and the server sides of the channel. The difference between data link layer and network layer encryption lies in what is encrypted. With link encryption, everything but the data link header is encrypted, whereas with network encryption, the data link and network headers are transmitted in the clear. IPSec is an example of a network-layer encryption protocol. Applications-layer encryption occurs at the applications level within the OSI model. Application-layer encryption is software based and by necessity leaves headers and routing information in the clear so that lower-level network infrastructure devices such as routers and switches are unaware of the encryption. Secure Socket Layer (SSL) and XML encryption are both examples of applications-layer encryption. Web Services ride on (or are carried by) TCP/IP. Applications-layer encryption is generally sufficient for securing Web Services transactions unless you are trying to hide either the fact of the communication or the route being used (for example, to prevent traffic analysis). Where applications-layer encryption is insufficient, you can use either network- or data-layer encryption techniques to counter specific types of attacks. An advantage of network-layer encryption over link encryption when it comes to Web Services is that with network-layer encryption, the encryption devices do not need to be placed at each switching device and intermediate node. The tradeoff is in the amount of header information that is transmitted in the clear. Stallings describes techniques for using a combination of link-level and network encryption devices to secure both the headers and the payload [Stallings95]. Point-to-Point Encryption Point-to-point encryption techniques secure the communications channel between any two nodes by creating an encrypted tunnel within the communications link running between the nodes. The information is generally in the clear at both endpoints. SSL is a common point-to-point encryption technique on the Web.
192
Enterprise Web Services Security
End-to-End Encryption End-to-end encryption techniques selectively encrypt either parts of or the entire payload in such a way that the parts are only decipherable by their intended recipients [CNSS03]. In a Web Services exchange the intended recipient may be the Web Services server, a subservient process to the Web Services server, or an intermediate process. The Web Services client can choose to encrypt part of the payload for the message’s final recipient and leave other parts unencrypted or encrypt them using different keys or algorithms to support processing by intermediaries or subservient processes. Using SSL to Establish Secure Sessions Netscape originally developed SSL, releasing version 3 in 1996. SSL was the basis for the Internet Engineering Task Force’s (IETF) Transport Level Security Protocol (TLS) standard [RFC2246]. SSL runs between the HTTP service and the TCP/IP stack. Given that you will probably use SSL in at least some of your Web Services applications, let’s look at how it works to create a secure channel [RFC2246, RFC2818]. As a first step, the Web Services client needs to send a message across a secure connection to a Web Services server. The client begins this process by sending a “Hello” message to port 443 of the server hosting the Web Service. The client then chooses the algorithms it wants to use for authentication, message encryption, and message integrity (SSL supports RSA®, Diffie-Hellman, and Fortezza for authentication; Digital Encryption Standard (DES), International Data Encryption Algorithm (IDEA), RC2 (40-bit encryption; RC is an acronym for Rivest Cipher), and RC4 (128-bit encryption) for message encryption; and Secure Hash Algorithm (SHA) and Message Digest, Version 5 (MD5) for message integrity) and negotiates the ones it wants to use with the server. Once this negotiation is complete, the server sends its certificate to the client, who verifies the certificate authority’s (CA’s) signature on the certificate, using the CA’s public key. The client then generates a session key, which it sends (encrypted using the server’s public key) to the server. The server decrypts the session key using its private key and generates a random message that it encrypts using the session key and sends that to the client. The client and server can now securely exchange messages using the mutually agreed upon session key.
IDENTITY MANAGEMENT AND TRUST In the SSL example above, the client created a trust relationship with the server in a three-step process. First, the client used the CA’s signature on the server’s certifi-
Protecting Messages, Transactions, and Data
193
cate to verify that the certificate was issued by someone the client trusted (the CA) and that it had not been changed. The second step was for the client to send a session key to the server encrypted using the server’s public key. The client was able to do this because it knew that only the server (the certificate owner) should have the private key needed to decrypt the message. The process was complete when the client was able to understand the message the server returned, which was encrypted using the session key. That returned message told the client that the server had been able to decrypt and use the session key, thus establishing the server’s identity. Trust Relationships Webster’s defines trust as the assured reliance on the truth of someone or something or their ability to perform a specific function [Websters04]. A trust relationship between two parties therefore simply means both parties know and trust in the other’s identity. Such a relationship must exist before the parties can securely communicate. WS-Trust and WS-Federation define several types of trust relationships: direct, direct brokered, indirect brokered, and delegated as illustrated in Figure 9.2 [WSTrust04, WSFederation03]. In direct trust relationships, the two parties exchange credentials and create the trust relationship on the basis of the claims represented by those credentials. In brokered relationships, the parties exchange credentials and form their trust relationship on the basis of a trusted third party. In a direct brokered trust relationship the first party trusts the second party because the third party trusts the second party as evidenced by the second party’s possession of a token or credential issued by the third party. In an indirect brokered trust relationship the first party trusts the second party because it trusts the third party and the third party has negotiated with the second party in order to verify its credentials. In delegated trust relationships, one party impersonates another’s identity in order to access a service. In Figure 9.2, the client and Server A mutually authenticate. Server A then impersonates the client when it accesses Server B. Web Services servers use the delegation model when they want to use another service using their client’s access privileges rather than their own. Identity management deals with managing the identity information necessary for creating these trust relationships. We will cover each of these types of trust relationships and how they are established in greater detail in Chapter 13. Identity Management The basic identity question is, how do you uniquely identify a person or process [NIST800-63]? A person’s identity is what makes him unique. In Web Services environments there are real identities, representing real people, and pseudoidentities associated with processes, systems, and services operating within the environment. Each must have a unique digital identity that distinguishes him from everyone and
194
Enterprise Web Services Security
Broker Client
Server
a) Direct
Server
Client
b) Brokered
Client
Server A
Server B
c) Delegated
FIGURE 9.2 Types of trust relationships.
everything else. Identity management includes the processes involved in administering, storing, and communicating identities [NECCC02]. Identity management is an important part of the security infrastructure because identities form the basis for key security services such as authentication, authorization, access control, and auditing. Identity management in a Web Services environment is an increasingly important component because many businesses must now concern themselves with identity management not only within the organization but also across organizational boundaries in support of customers and business partners. Figure 9.3 illustrates three leading identity management approaches. In the direct model, each business maintains control over its own user community and potentially creates a unique identify management interface for clients, partners, and suppliers. In such an arrangement, it is possible that any two nodes will use different types of credentials in any particular connection graph. This makes administration and provisioning difficult, as each pair-wise node may require a unique set of security mechanisms. In the common broker model, a central authority defines and brokers identities among the members of some group. The common infrastructure simplifies administration, provisioning, and control, as all nodes intersect
Protecting Messages, Transactions, and Data
195
at a common point. In the federated model, each member maintains control over its own user community but has agreed to trust those identities its partners trust. WSFederation defines models for creating trust relationships in a federated environment and introduces the concept of identity providers being a special function of token services that can make security claims in issued tokens [WSFederation03].
a) Direct Model
b) Common Broker Model
c) Federated Model
FIGURE 9.3 Identity management approaches.
In the digital world, an identity equates to some type of digital credential where the credential uniquely maps to the person or entity it represents. Passwords and Pass-Phrases Password and pass-phrase services rely on something the client knows (either a password or pass-phrase) to establish identity [NIST800-12]. The password or passphrase must be something the user can easily remember yet be something difficult
196
Enterprise Web Services Security
for others to guess. Strong passwords mix upper and lowercase letters, numbers, and special characters to create passwords that are difficult to guess or to discover through exhaustive trial and error. Guidelines for creating strong passwords include: Being at least eight characters in length Not containing your name or email address or your spouse’s or child’s name Being regularly changed Not being repeated over some time period (at least a year) Being memorable Pass-phrases are sentences that are used to remember complex passwords. For example, a pass-phrase of “I wish I could catch 1 fish” would yield a password of “IwIcc1f” if one uses the first letter of each word of the pass-phrase. Smart Cards Smart cards rely on something the client possesses to establish identity where the possession is the smart card itself [NIST800-12]. Smart cards are credit card-size devices with embedded memory and microprocessor chips. Smart cards can carry personal account, credit, or preference information. They can also store certificates, encryption keys, or other information, such as roles or attributes, that you may want to use as part of the authentication, authorization, or access control process. The use of smart cards requires a reader at the client end. Readers normally plug into the RS232 serial port, a USB port, PCMCIA, or infrared IRDA port on a clients PC. The International Standards Organization (ISO) 7816 family of standards governs the size and location of card contacts and the interface commands and protocols for the cards. A smart card is usually unlocked by the user entering a PIN code, which allows the system connected to the reader to send requests to the card on the user’s behalf. Once the smart card is unlocked, it can be used to sign or encrypt information using the card owner’s private key. (More detail on private key operations will be given in Chapter 10.) Third-Party Brokers Third-party brokers come into play in both the common broker and federated models. Third-party brokers allow the parties to an exchange to depend on a mutually agreed upon third party to endorse each other’s identity. Different types of thirdparty brokers come into play depending on the technologies and services being used.
Protecting Messages, Transactions, and Data
197
Certificate Authorities X.509 is built around the concept of digital certificates [RFC2459]. Digital certificates are stored in either a directory service directory or a local certificate cache or wallet. The parties using a certificate assume a trusted CA created the certificate. The certificate includes the CA’s identity and signature for verifying the certificate’s bona fides using the CA’s public key. The certificate also includes the identity of its owner and the owner’s public encryption key along with a designator identifying the algorithm to which the key belongs. Parties in an X.509 scheme assume that only the certificate’s owner possesses the private encryption key corresponding to the public key in the certificate. Kerberos Authentication Servers In Greek mythology, Kerberos was a three-headed dog guarding the gates of Hades. MIT developed the Kerberos service as part of Project Athena [RFC1510]. Kerberos was originally intended to include authentication, authorization, and auditing as part of a three-headed security approach; thus the name. Kerberos replaces user identities with tickets: ticket-granting tickets and service tickets [RFC1510]. The Kerberos Key Distribution Center (KDC) in a domain (or realm) authenticates users to servers and servers to users. The KDC maintains a list of users and servers and their respective passwords. The KDC also maintains a unique secret encryption key for each server. The KDC becomes the trusted third party for both parties, which grants clients ticket-granting tickets that include authentication information servers can use, encrypted using the server-specific secret key, to verify the client’s identity and authentication by the KDC. More detail on how Kerberos works will be provided later in this chapter. Policy Decision Points Newer standards, such as Security Assertion Markup Language (SAML) and eXtensible Access Control Markup Language (XACML), replace identities with assertions [SAML04, XACML03]. Policy decision points (PDPs) act as the third-party brokers for these services. The standards provide for separate PDPs for authentication, authorization, and attributes. In these schemes, parties negotiate their identity with an authentication PDP and then pass claims, in the form of assertions, to others. Services receiving the claims can verify them with the PDP. Microsoft .NET Passport Microsoft’s Passport service uses a central login server that assigns each user a unique Passport identifier [Passport04]. When a Web Service needs to authenticate
198
Enterprise Web Services Security
a client using their passport, it redirects the client’s request to a well-known Passport server. The Passport server establishes an SSL connection with the client and presents a login page. Following login and successful authentication, the Passport server encrypts the authentication information, using triple-DES (and an out-ofband established key), and redirects the client back to the original Web Service, including the authentication information as part of the redirection message. Browser-based services normally set the authentication information as a cookie to avoid having to reauthenticate the client for subsequent requests. The Passport server also sets an encrypted cookie to avoid having to reauthenticate clients visiting multiple Passport-supported sites. Liberty Alliance The Liberty Alliance Project™ is a consortium of over 150 companies working on an open, federated network identity management architecture [Liberty04]. Liberty Alliance defines an identity as a set of traits, attributes, and preferences belonging to an individual. Traits are government- or company-issued identities and biometrics; attributes and preferences are a combination of sharable user characteristics and individual preferences. Liberty Alliance is building its authentication scheme around the SAML standard.
AUTHENTICATION An authentication service’s primary role is to establish a client’s, or a server’s, identity [NIST800-12, NIST800-63]. The service may be internal or external to using Web Services, and its complexity depends on the number and types of authentication schemes it must support. If the service must support a number of different authentication schemes or services, we recommend that you develop a choreographable authentication service that you can build your other Web Services around. Authentication Services follow two basic patterns, as shown in Table 9.1, depending on the type of security credentials involved: secure channel and secure format. The difference lies in whether or not the client must create a secure channel before sending its security credentials to the server. Some credentials are already in a secure format because of their use of encryption, allowing clients to send them through an unsecured channel under most circumstances. Depending on the sensitivity of the information, the encryption algorithms being used, the algorithm’s strength, and the key lengths involved, you may want to create a secure channel in some environments even if you are using secure format credentials.
Protecting Messages, Transactions, and Data
199
TABLE 9.1 Basic Authentication Patterns Pattern One
Pattern Two
1. Create a secure channel
1. Send security credential in secure format
2. Send security credential to server
2. Server verifies security credential
3. Server verifies security credential
3. Server accepts or denies request
4. Server accepts or denies request
A second difference lies in the verification step, depending on the type of trust relationship that exists between the two parties. In direct trust relationships, the server compares the client’s credential against some information the server maintains, such as a list of user names and their passwords or a shared secret. In brokered trust relationships, the server may verify, via a separate message sequence, the credential with the third-party broker. In delegated trust relationships, the server trusts an earlier service to have verified the credential. User IDs and Passwords User ID and password schemes depend on a shared secret, the password, to verify the identity the user ID represents [NIST800-12, NIST800-63]. The Web Services server will normally access a user table or access control list to match the clientprovided password against a previously stored value. If they match, the server assumes the client is the person, service, or process the user ID represents. User-ID and password schemes assume that only the person, or process, owning the user ID knows the password. User-ID and password schemes frequently require a secure channel between the client and server to compensate for the client sending the user-ID and password information to the server in plaintext. For this arrangement to work, the client and server must have previously agreed upon a mechanism for creating the secure channel or be able to negotiate one at the point of the exchange. SSL is often the choice for creating the secure channel. As another option, some browsers now support use of a message digest algorithm to convert the plaintext password into a secure format. If the client is a browser, you will also want to use password-type tags on the Web page to prevent prying eyes from seeing the password as the user types it in. While this protects the password at the presentation layer, it is still in plaintext in the client-workstation’s memory, in cache, and in the channel.
200
Enterprise Web Services Security
X.509 Public Key Authentication X.509 replaces user IDs and passwords with digital certificates, third-party CAs, and an authentication scheme built around public key encryption [RFC2459]. CAs have already been introduced in this chapter. The ISO X.509 standard and Public Key Cryptography Standards (PKCS) define X.509 certificates and their use. With X.509, a trusted, third-party CA assigns each user a signed digital certificate and a pair of encryption keys: one public and one private. The CA may be part of a chain of CAs, with the highest-level link being the Internet PCA Registration Authority (IPRA). The IPRA certifies and issues certificates to policy certification authorities (PCAs), who in turn certify and issue certificates to CAs. X.509 authentication makes the following assumptions: Both parties to the message exchange trust a common CA. Only the CA, or trusted delegates, can issue valid certificates. Only the owner of the digital certificate possesses the corresponding private encryption key. In most environments, it is safe to use X.509 certificates following the secure format pattern. Figure 9.4 illustrates using the X.509 authentication scheme for a message exchange. The process begins with both parties exchanging certificates. The client sends its certificate to the server and the server sends its certificate to the client. Both parties verify the identity and CA information contained in the certificate. The parties can use the CA’s public key to verify the CA’s signature on the certificate. The parties then exchange a series of messages to verify each other’s identity; this process is known as mutual authentication. The process begins with the client generating a unique transaction ID (Tran ID1), which it sends as part of a message to the server. The client encrypts the message using the server’s public key (which is obtainable from the certificate). The server decrypts the message, generates a unique transaction ID of its own (Tran ID2) that it returns in a message, which also includes Tran ID1, to the client. The server encrypts this message with the client’s public key. The client decrypts this message and verifies that it contains Tran ID1. The client can now trust the server since only the server should have the private key necessary to decrypt the first message. The client now sends a message to the server that contains Tran ID2, which it encrypts using the Server’s public key. The server decrypts this message and can now trust the client. The server now generates a session key, using some previously agreed upon or negotiated algorithm, which it returns to the client in a message that it encrypts with the client’s public key. The client and server can now exchange messages securely using the session key. The
Protecting Messages, Transactions, and Data
201
client and server use different algorithms for authentication and message exchange because of performance. Secret key encryption algorithms are normally more efficient than public key algorithms.
Messages
Client
Server
Client Certificate Verify CA Server Certificate
Verify CA
Message A with Trans ID 1 Generate Trans ID 1
Generate Trans ID 2
Message B with Trans ID 1 and ID 2 Server Now Trusted Message C with Trans ID 2 Client Now Trusted Random Key
Messages
Generate Random Key Session Messages
FIGURE 9.4 The X.509 authentication process.
LDAP (The Role of Directory Services) In the scenario above, the client and server began their dialogue by exchanging digital certificates. An alternative would be for each party to request the other’s certificate from the CA. Yet another alternative would be to obtain the certificate from a public directory containing the name and public key of each user in the domain. With a directory service in the picture, the client and server need only exchange or know the identity of the other party. They can then use the directory to obtain the corresponding credentials. A directory service approach is more secure because the CA can now revoke credentials and either maintain a revocation list or periodically republish the directory to remove users that are no longer valid. The directory service you will most frequently encounter is LDAP [RFC2251]. The University of Michigan designed the Lightweight Directory Access Protocol (LDAP) for accessing an X.500-type directory service over TCP/IP. (X.500 is an ISO
202
Enterprise Web Services Security
specification for directory systems.) Netscape, IBM, Oracle, Microsoft, and others have agreed to follow the LDAP standard for implementing Internet directories. The LDAP directory service consists of a directory implementing a hierarchical namespace and an open protocol for accessing information in the directory. The LDAP directory implements a schema defining object classes that can include users, services, network and computing devices, etc. Each object class consists of one or more entries. Each entry consists of one or more attributes, which in turn consist of a type (or syntax) and one or more values. The attribute’s type defines how to interpret its values. Types include distinguished names, common names, telephone numbers, etc. The LDAP protocol provides operations for binding to the directory service and for searching for and comparing entries. The basic sequence of operations is for the requesting party to BIND to the directory service, execute a query to find and retrieve the directory entry for the party it is interested in, followed by an UNBIND. There are two common implementations for the directory. Given the directory’s tree-like structure, most implementers use a hierarchical database model. This provides high-speed access for individual queries but is relatively inefficient for high rates of insertions and joins. The Netscape Web server (which became iPlanet™, which is now Sun ONE™) is a prototypical example of this implementation. However, the hierarchical structure is not very efficient for relational database systems that want to access the directory as part of their search process. This has led to implementations where the LDAP wraps a traditional relational database management system (RDBMS). Oracle Corporation’s Oracle Internet Directory (OID) is an example of this type of implementation. Depending on whether you are writing Web Services for the Internet, an extranet, or an intranet, you may find up to three levels of directories involved. At the Internet level, you may use large public directory services such as Big Foot or Infospace. Within an extranet, you may use organizational directories belonging to one or more organizations, such as a company, university, or government agency, or a common directory specifically defined for the space. Within an intranet, you may use either a global directory or individual department or group-level directories. Kerberos Two versions of Kerberos are currently in widespread use: Versions 4 and 5. We will describe Version 4 because it is simpler to describe, yet most of the discussion is directly relevant to Version 5 as well. The foundations for Kerberos authentication are the concept of shared secrets and the idea that if only two parties know a secret, then either can verify the other’s identity by their knowledge of the secret. The Kerberos service assumes a Kerberos
Protecting Messages, Transactions, and Data
203
KDC server exists that contains the user IDs and passwords of all the users within its domain (or realm). The Kerberos server also maintains a unique secret key for each server in the realm. The secret key is a shared secret between the Kerberos server and the server it supports. The Kerberos servers supporting two realms can share a secret key and form a trust relationship between the two realms. Kerberos uses a three-step authentication process as shown in Figure 9.5. The three steps correspond to three subprotocols. The Authentication Service subprotocol provides clients with a session key and a ticket-granting ticket. The ticketgranting service (TGS) subprotocol issues service session keys and service-granting tickets (SGTs). The client-server (CS) subprotocol enables clients to request services from providers. The Kerberos KDC implements the first two services.
Client 1. Login requesting UID and Password . 2. Client sends ticket Request to Kerberos
Messages Ticket-Granting Request
Ticket-Granting Ticket
AS. 3. Client uses password to decrypt TGT.
Kerberos AS 1. Server generates TGT which it encrypts with its own secret key. 2. Server includes TGT in larger message and encrypts it with a key derived from the user’s password.
Kerberos TGS 4. Client sends service ticket request to Kerberos TGS. Request includes TGT as an authenticator.
Service-Ticket Request
Service-Granting Ticket
Service Request 5. Client sends service request to Web Service. Request includes SGT and an authenticator.
Authentication Message
1. Server verifies Client bona fides. 2. Server generates a session key for the two parties, an SGT, and encrypts the SGT using service’s secret key. 3. Server includes SGT in larger message that it encrypts using the session key.
Web Service 1. Service verifies Client bona fides. 2. Mutually authenticates if necessary.
FIGURE 9.5 The Kerberos authentication pattern.
Once per session, a client must log on and request a ticket granting ticket from the Kerberos authentication service. To avoid having to send the client’s password through an unsecured channel, the client sends a request containing its ID, the authentication service’s ID, and a timestamp to the AS. The authentication service
204
Enterprise Web Services Security
generates a TGS ticket made up of the client’s ID, the client’s network address, the authentication service’s ID, a second timestamp, a lifetime value, and a session encryption key. The authentication service encrypts this service ticket with its own secret encryption key. The authentication service includes the encrypted TGS ticket in a larger message containing the authentication service’s ID, the timestamp, the lifetime value, and the session key, which it encrypts with a key derived from the client’s password (the authentication service obtains the client’s password from a local database) and sends it to the client. The client generates a decryption key using the password it obtained and decrypts the message. The KDC is able to conclude in subsequent service requests that the client is who he claims by virtue of his having been able to decrypt this message, under the assumption that only the client knows its password. In order to use a service, the client must first obtain an SGT from the Kerberos TGS. The client initiates this process by sending a request for an SGT to the TGS. The request includes the TGS ticket it received from the authentication service, the ID of the service it wants to use, and an authenticator. The authenticator is made up of the client’s ID, its network address, and a timestamp. The client encrypts it using the session key it received from the authentication service. The TGS decrypts the request using the shared session key, as a first step in authenticating the request, and then verifies the client’s ID and network address from the authenticator with those in the TGS ticket to ensure the request is coming from the client. After verifying that the client is authorized to access the service, the TGS generates a servicesession key for the client and service to share, includes this in an SGT that it encrypts using the secret key the TGS shares with the server supporting the requested service. The SGT includes the service-session key the service will share with the client, the client’s ID and network address, a timestamp, a lifetime value, and the service’s ID. The TGS includes the SGT in a larger message that includes the service’s ID, a timestamp, and the shared service-session key the client is to use in communicating with the service. The TGS encrypts this larger message with the session key it shares with the client and sends it to the client. The client must request an SGT for each service it uses. The client decrypts the message from the TGS and sends the SGT and an authenticator to the Web Service to obtain service. The authenticator includes the client’s ID, network address, and a timestamp. The client encrypts the authenticator using the service-session key it shares with the service. The assumption is that only the client is able to decrypt the message from the TGS service that generated that key. The Web Service receiving the message decrypts the SGT, using its secret key, extracts the shared service-session key, and uses it to decrypt the authenticator. The Web Service then validates the client’s ID and network address, and assuming that they all match, concludes that the client is whom they claim. To mutually authenticate, the Web Service sends the client a message containing the timestamp from the
Protecting Messages, Transactions, and Data
205
authenticator portion of the client’s message incremented by one, encrypted using the shared service-session key. At the end of this process, the client and Web Service can securely exchange messages using the TGS-created secret service-session key they share. Kerberos Version 4 used DES as the heart of its encryption scheme. Version 5 relaxed this constraint by incorporating encryption type and key length information into the ticket structure. This structure allows the use of any algorithm for Kerberos encryption. Microsoft uses Version 5 with public key encryption in its implementation. Version 5 also improves the generality of the service and its use of encryption; the basic concepts and ticket exchange sequence, however, remain the same.
AUTHORIZATION While the authentication service determines a user’s identity, the authorization service determines what the user or process associated with an identity can do. Authorization therefore assumes successful authentication [CNSS03]. The authorization service determines what a user can do by matching the user’s identity with a set of privileges or permissions. The privileges correspond to specific functions or actions the user or service can take. At an operating systems level, privileges include login; creating, reading, updating, and deleting files; and executing processes. As you move up through higher-level services, such as Web servers, applications servers, and database servers, privileges take on service-specific meanings such as accessing or updating a Web page, accessing one or more Entity JavaBeans™ (EJBs) or component object model (COM) objects, and producing (running) a specific query or report. As a Web services developer, you will need to be familiar with authorization mechanisms at all different levels and of different types because you may need to develop Web Services implementing everything from wrapping hardware-level services, such as a print service, to advanced applications services, such as credit card authorization. You should always follow the principle of least privilege in implementing your authorization services. The principle of least privilege says, “Every user of the service should operate using the least privileges necessary to complete the task at hand” [CNSS03]. AuthorizationDecision = AuthorizationFunction ( identity, resource, privilege ) This formula illustrates the basic authorization function: given an identity, a resource, and the privilege the identity needs to perform a specific action, can the identity perform the action the privilege represents? Complexity comes in two forms: in how identities map to resources and privileges and in where within the overall applications model the actual authorization decision is made.
206
Enterprise Web Services Security
How you map identities to resources and privileges is an important decision; it establishes the level of administrative burden on your system administrators and the complexity of the authorization function. Normally, the simpler the systems administration, the more complex the authorization function, and vice versa. We discuss privileges and resources separately because you may treat them either separately or collectively depending on your particular requirement. For example, you may say user X has privilege Y for resource Z (this user can print on this printer using this print server) or you may aggregate either the privileges, the resources, or both (this user can print on any printer belonging to this print server, this user has all privileges for this printer on this print server, or this user has all privileges for all printers belonging to this print server). Figure 9.6 depicts the three options for mapping identities to resources and privileges: direct, indirect, and computational. In a direct mapping, identities map directly to resources and privileges. Giving user X privilege Y for resource Z is an example of direct mapping. In an indirect mapping, identities map to an intermediate entity, normally a role (or group), and resources and privileges to the same intermediate entity. Giving users with the “customer” role authorization to submit customer feedback via a customer feedback form on your Web site is an example of indirect mapping. Privilege
Privilege Identity
Identity
Role Resource
Resource
a) Direct
b) Indirect
Privilege Identity
F(Ai, Ax) Resource
c) Computationally FIGURE 9.6 Mapping identities to resources and privileges.
Role mapping simplifies the administration function because you can now aggregate identities, resources, and privileges to roles. However, it complicates the authorization service because the authorization service must now identify the resource or privilege needed and the role associated with that resource or privilege
Protecting Messages, Transactions, and Data
207
and then verify that the identity possesses that role. Computational mapping goes a step further and maps some set of attributes the user possesses against a role or set of attributes associated with the resource, the privilege, or both. An authorization decision mapping users who are administrative assistants working in XYZ Division with system administrator privileges for printers located in XYZ Division is an example of a computational mapping. To make this decision, the authorization service must map job functions to privileges and user organizational locations to resource to facilities to organizational locations. The second complicating factor in implementing an authorization service is where to make the authorization decision. There are choices in terms of both where the decision is made in the OSI protocol stack and the component involved. You may be asking, “Why wouldn’t I always make the decision in the Web Service (or the applications layer)?” Consistency of implementation and level of risk are two major reasons you wouldn’t. If you are writing a Web Service that exclusively controls and uses a resource, implementing the authorization service within the applications layer as part of the Web Service itself is an option. However, generally, any number of different Web Services will need to share a resource, and you will want to consistently implement the authorization service across those services. So, as a general rule, you will want to implement your authorization service as a choreographable service and, particularly if you are dealing in a mixed environment, as a Web Service. This allows many Web Services to share the same authorization service. The second issue, level of risk, is even more important. The higher in the protocol stack you go in implementing the authorization service that controls a resource, the higher the risk of successful attack from a lower level. This leads to the principle that you always want to implement the authorization service for a resource as low in the stack and as close to the resource as possible. How far down in the stack you should go depends on the resource involved and the availability of appropriate protection mechanisms for protecting that type of resource at each level. To better understand this point, let’s look at an example. Assume you want to protect a particular Web Service. The Web Service is unknown at the hardware level. At best, it is merely a series of bits on a hard drive somewhere. The operating system hosting the HTTP server may know it is an executable of some sort, assuming it is a simple executable file; otherwise, it too is oblivious. If it were a simple executable file, then one option would be to protect it using the operating system’s filesystem access control mechanism. What if the service is implemented as an Active Server Page (ASP) or EJB? In that case, the HTTP server is the lowest level in the stack that knows it is an executable being called. If you want to control access to the service at the lowest possible level, you would have to control it through the HTTP server and through access to the specific ASP or EJB function supporting the service. You could control it at higher levels, for example, within the service itself, but that would open the process
208
Enterprise Web Services Security
and the data to additional vulnerabilities and attacks because unauthorized users would be allowed to execute the service. Based on this discussion, we can modify our earlier principle to be that you should protect resources at the lowest level in the stack where identifiable and appropriate protection mechanisms exist. Since most of the Web Services you will write will use some form of Web server, we will take a closer look at the authorization points you can expect to find and the decisions you will need to make in several typical environments. Basic Web Servers The basic Web server is an HTTP service running on top of a native operating system such as UNIX or Windows server. The HTTP service on such a server may be little more than a listener with an HTTP interpreter. In its most primitive form, it will at most contain a primitive scripting interpreter capable of launching Common Gateway Interface (CGI) programs and possibly server side includes, but little more. A basic Web server will probably only include basic authentication services, which utilize user IDs and passwords [RFC2617]. Newer versions of basic Web servers also include some form of digest authentication, which uses an MD5 digest algorithm to protect the user’s password as the client transmits it to the server Basic servers will also sometimes include some form of SSL authentication, but will probably not include more sophisticated approaches unless you want to implement them as application code within your Web Service. You will probably write any Web Services you want to run on a basic Web server as a CGI application. A CGI application runs as an external application to the HTTP service itself as a separate address space or daemon process that has direct access to the operating system and operating system functions. This is an important point because you may lock down the HTTP service itself yet leave the system vulnerable to CGI applications. As Figure 9.7 illustrates, there are three basic authorization points on such a basic Web server. One is the operating system itself. At the operating system level, you can protect the filesystem, both files and directories, and programs. These can be protected by limiting access to the file containing the executable or by restricting execution privileges. Restricting access to files or directories may require your CGI application to be able to proxy the user’s identity since the HTTP service itself may not be able to do so in a way the operating system understands. The second authorization point is at the HTTP service level. You can generally choose to give users either anonymous or authenticated access to this service. Anonymous access is a concern if you allow users to access and execute programs and the Web server contains sensitive information. If you are going to provide
209
Protecting Messages, Transactions, and Data
Request
HTTP Basic Service
Common Gateway Interface Program
Client Response HTTP Service
Web Pages & Scripts
Database
Operating System
Database Access Files and Programs
FIGURE 9.7 Web server authorization points.
anonymous access to some capabilities, you need to carefully lock down the root directory, the filesystem, and executables (the cgi-bin area). Otherwise, you will open yourself up to attack. If you use authenticated access, the HTTP service may provide capabilities for restricting access to Web pages and executables. The server will generally implement access controls through either a configuration file or a database. As general rule, it is better to restrict access to identifiable Web objects at this level because the HTTP service can enforce access controls before it fetches Web pages, runs scripts, or launches a CGI program. The third authorization point is within the CGI program. It is critical for you to understand what permissions the HTTP service will give the CGI program on launch and what options you have for limiting or controlling those privileges. Ideally, the CGI program will receive minimum privileges under the assumption it will switch to a valid user’s identity, thereby inheriting that user’s privileges, as part of its authorization processing. A common problem is allowing CGI programs to operate with the HTTP services privileges or squirreling away a user ID and password the CGI program can use. In both cases, the CGI program essentially runs with system privileges, which allows the use access to files users normally would not be permitted to read, as well as allowing the possibility of corrupting the system configuration. To illustrate some of the choices you will face when dealing with a basic Web server, let’s assume a situation where we have a CGI program accessing a database. The database could be a real database, such as an SQL Server or Oracle RDBMS, or files within the filesystem. There are two basic concerns here: how to control access to the CGI program and how to control access to the database it is accessing. If at all possible, either the operating system or the HTTP service should control access
210
Enterprise Web Services Security
to the CGI program. Why? Because in situations where the CGI program is protecting itself, it is vulnerable to attack, assuming someone can modify or alter its behavior before it can reach an authorization decision (buffer overflow types of attacks attempt to exploit this vulnerability). Given that the CGI program is executing on behalf of an authorized user, the next concern becomes where to protect the data. It depends on the type of database the program is accessing. It is generally best to use the operating system’s access control mechanisms for restricting access to files within the filesystem. As we will discuss in a later section, it is generally better to use the database product’s access control mechanisms to restrict access to a RDBMS and its capabilities. Why wouldn’t you implement the database access control in the CGI program? Because the filesystem or database is then exposed to attack by anyone who can find a way to get direct access to them, possibly through another CGI program. J2EE Applications Servers J2EE (Java 2 Enterprise Edition) applications servers (apps servers) are an increasingly popular platform for developing Web Services applications. The combination of a standards-based hosting environment and standards-based messaging formats and protocols leverage the promise of write-once, run-anywhere code. An apps server includes an HTTP server running on top of a native operating system and at a minimum a Web container [J2EE04]. The Web container provides the hosting environment for servlet and Java Server Page (JSP) applications. More advanced apps servers also contain an EJB container. The EJB container provides the hosting environment for any Java beans you may write. Depending on your particular circumstance, you may deploy the Web and EJB containers on the same or different physical servers or as different logical instances. A J2EE apps server normally provides several authentication options. Formbased authentication lets you use any HTML form to perform the basic authentication check. You simply need to include an action of j_security_check and the parameters j_username and j_password. Since apps servers are also HTTP servers, most apps servers also support HTTP basic authentication. With basic authentication, the Web server sends a “401 Authentication Request” header to the client to indicate a user ID and password are required. Many also support digest authentication that uses MD5 digest codes to avoid sending passwords across the network. Being a Java platform, most apps servers also support the Java Authentication and Authorization Service (JAAS) [JAAS04]. JAAS is based on the concept of a stackable pluggable authentication module (PAM) framework [PAM96]. The PAM framework lets you add multiple authentication mechanisms without changing login services. With JAAS, applications deal with a LoginContext that is independent of the authentication mechanism. Many apps servers also support custom
Protecting Messages, Transactions, and Data
211
authentication that allows you to retrieve credentials and then compare them to a database or an LDAP directory. You will generally write the Web Services applications that you want to run on a J2EE apps server as either a servlet or an EJB. With either, you may choose to chain components together depending on the functionality that you need to implement. Figure 9.6 shows the same authorization point options on an apps server as would be on a basic Web server, with all the same advantages and disadvantages. The J2EE apps server adds an additional option: container authorization. Container authorization essentially provides an intermediate level, between the HTTP server and the application, for J2EE applications [J2EE04]. Container authorization is role based and normally offers two options: Java Runtime Environment (JRE)/container and application authorization. JRE/container authorization works for both the Web and EJB container; its advantage is that the authorization check occurs before any code executes. It is useful if you need to control access to a servlet, JSP, or bean. JRE/container authorization is often referred to as declarative security because it is declared in configuration files on the server. Application authorization occurs as the application executes. Application authorization breaks down into role based (the application makes the authorization decision based on the client’s role) and segment based (the application makes the authorization decision based on user attributes). In both cases, the container has initiated and given control to the application’s code before the application makes the authorization decision. ASP.NET Servers Microsoft was an early adopter of Web Services and has been a platform of choice for many Web Services applications. Building Web Services in a Microsoft environment, of course, means building them to run on an Internet information server (IIS) system using technologies such as ActiveX, Active Server Pages (ASP), and ASP.NET. IIS is an HTTP server. IIS supports two types of requests: anonymous and authenticated [IISAuth04]. With anonymous requests, the IIS server only knows the IP address of the client. Anonymous requests run under the machine name of the IIS server. With anonymous authentication, IIS only denies requests the operating system denies. Since you will generally give the IIS server broader privileges than you would to any individual user, you generally should not use anonymous authentication unless you are protecting the resources at a higher level. IIS supports four types of authenticated requests: basic, digest, integrated windows challenge/response, and client certificate matching. Basic and digest authentication are similar to those found in traditional HTTP servers, as both depend on a user ID and password. Basic authentication implements HTTP 1.0 authentication
212
Enterprise Web Services Security
using Windows accounts. With basic authentication, the client sends passwords to the IIS server in Base64-encoded format. Digest authentication sends a digest instead of the password across the network. The client receives the password it uses to compute the digest from the user; the IIS server retrieves the password it uses to verify the digest from the active cirectory. The two digests must match for authorization to be successful. Integrated Windows authentication (often referred to as integrated login or NTLM) uses Windows logon credentials. Integrated Windows authentication uses either native Kerberos V5 or a user-ID and password scheme based on Windows accounts. Client certification matching authentication maps one (one-to-one) or more (many-to-one) X.509 certificates to a user ID. IIS can also use SSL to authenticate the client using X.509 certificates. IIS also supports Fortezza as an add-on cryptographic service provider (CSP). Fortezza is a National Security Agency (NSA)–developed authentication mechanism based on a certification authority and smart cards. Microsoft adds a second level of authentication services with ASP.NET [ASPAuth04]. This second level of authentication is similar in concept to Java’s container authorization. ASP.NET supports three types of authentication: forms, passport, and windows. With forms authentication, ASP.NET uses HTML forms to collect authentication information from the user. Passport authentication uses Microsoft’s Passport services to authenticate the user. The user must have signed up for Passport services and that Passport service must be available to the ASP.NET process. Windows authentication uses Window’s accounts to authenticate the user. ASP.NET also supports custom authentication providers where you set the authentication mode to none and then authenticate within the application itself. ASP.NET uses impersonation to execute processes under the identity of the requesting user. If impersonation is not enabled, ASP.NET executes processes with the privileges of the ASP.NET user account. At the IIS level, you can control traditional resources such as files and processes. ASP.NET adds an extra authorization dimension by supporting both file and URL authorization [ASPAuthorize04]. File authorization checks an (ACL) to determine a user’s ability to execute a particular aspx or asmx file. URL authorization checks the user’s accesses against parts of the URL namespace. Recent enhancements to IIS have made the HTTP Listener a kernel process and introduced the concept of worker processes where each request effectively launches, or assigns, its own processing thread containing a request-specific set of configurable IIS services. This increases the overall security of the authorization mechanism. Windows Authentication with impersonation allows you to map users and resources consistently across systems and the Web based on user credentials. You may be asking, “Why not always use Windows Authentication?” The problem is that the Windows challenge/response protocols do not pass through some firewalls, causing authentication attempts to fail. For Windows Authentication to
Protecting Messages, Transactions, and Data
213
work, both parties must be able to communicate with either the same domain controller or at least domain controllers that are in communication with one another.
ACCESS CONTROL The distinction between authorization and access control is one of granularity. In this book, we use the term authorization to refer to coarse-grained access control for objects such as Web pages, CGI applications, servlets, or COM objects. We use the term access control to refer to fine-grained access control for lower-level objects such as rows, tables, and documents within a data source. Some group the two together under the term authorization. We distinguish between the terms for two reasons. First, database products, such as Oracle Database Server and Microsoft SQL Server, provide authorization mechanisms that understand and are capable of controlling access to database objects such as tables, records, reports, and stored procedures [OracleASO01, SQLServer03]. Second, you may use different authorization strategies for coarsegrained and fine-grained access. Depending on the environment you are working in, you will likely choose role-based access control for coarse-grained access and may choose some other form (we will discuss the options later) for data access control. Filesystems and many filesystem-based DBMS products only provide coarsegrained access control. If a given user has access to the file or knows the password to the database, he has access to everything in that file or database. In these situations, authorization and access control are in effect the same. As Figure 9.8 illustrates, if the data you want to access is defined at the filesystem level and a file object is the right level of granularity, the operating system is the best option for making authorization decisions. Most operating systems allow you to set create, read, update, delete, and execute privileges at the file and directory level. What if you need to control access to objects within the file such as rows in a table, documents within a file, or paragraphs within a document and the product you are using doesn’t provide access control at that level? Your only option then is to implement access control as part of your Web Service or as a service your Web Service can draw upon. Filesystem-based DBMS products that include an access control mechanism provide a third option: to use the DBMS product’s capabilities to implement access control. DBMS products normally provide control over things the DBMS understands as objects. The list normally includes tables, views, and stored procedures. They also generally offer one or more ways of mapping user identities to those objects. User-level access control is generally the minimum capability. Role-based
214
Enterprise Web Services Security
Request Web Service
Content Within File Object
Client Response
DBMS W/O AC
Operating System
File Objects
Database
FIGURE 9.8 Local filesystem or filesystem-based databases.
access control is gaining popularity and is found in an increasing number of products. Some are also beginning to support more sophisticated constructs, such as rule- or attribute-based access control, at increasing levels of granularity, that is, row-level access control. Under what conditions would you implement access control within your Web Service instead of within the DBMS product itself? When the product you are using doesn’t control access To objects you want to control (you want to control access to a stored procedure and that isn’t supported natively) At the level you need (you want to implement row-level access control and the product only supports table access control) In the way you need to support it (you need to control access by attribute and the product only supports control by database object) Once you move access control decisions out of the DBMS into your Web Service, you also have to decide whether you want to use the DBMS’s account management structure. In order to reduce the administrative overhead or to supplement the underlying DBMS’s capabilities, it is sometimes tempting to substitute a table look-up or algorithmic access control scheme for the native DBMS’s account structure. We recommend against this type of approach, unless absolutely necessary, for two reasons. First, it precludes, or complicates, the use of commercial offthe-shelf (COTS) products, such as report writers or query-by-example tools, that
Protecting Messages, Transactions, and Data
215
depend on the DBMS’s account structure. Second, as a general rule, it is best to implement access control as close to the data source as possible, and with DBMS products, that means within the DBMS product itself. The first concern arises because commercial report writers (such as Seagate Crystal Reports™) that convert user requests into SQL out-of-the-box expect to use the DBMS’s security features. At best, they provide an interface for customizing access by inserting code into the middle of this conversion process. The vulnerability arises when these types of tools are introduced in environments where the DBMS depends on some other interface to protect the data it contains. Since the commercial tools aren’t coming through this interface, they effectively have system-high access to the data. Server-based DBMS products operate as a service instead of as an extension of the operating system’s filesystem. Being a service means the DBMS service implements some protocol for communicating between it and your Web Service. In today’s environment, that protocol normally rides on top of TCP/IP, and your Web Service will access the DBMS service through an abstraction layer such as Microsoft’s Open Database Connectivity (ODBC) or J2EE’s Java Database Connectivity (JDBC™). Most vendors still offer proprietary connectors for their products. The choice between using an open connector or a proprietary connector is generally between portability and performance. You can setup server-based DBMS products in one of two ways. In a singleserver configuration the DBMS service runs on the same operating system and server as the Web Service (see Figure 9.9). While this configuration may be OK in a small office environment, it is generally discouraged for enterprise-level services because of performance. In a multiple server configuration the Web Service runs on one hardware server under one instance of the operating system, and the DBMS service runs on another hardware server under a different instance of the operating system or possibly even a different operating system. For example, in a multipleserver configuration, you may run your Web Service as a servlet on a J2EE apps server using SUN Solaris™ while your DBMS service is Microsoft’s SQL Server running on a Windows XP server. The single-server configuration introduces the question of controlling service access. One option is to control access through your Web Service; the other is to control access through the DBMS service. If you decide to control access through your Web Service, you need to configure the DBMS service to give the Web Service the maximum privileges (system high) needed by any of the Web Service’s clients and then depend on the Web Service to broker the access decision. You have two choices in controlling access using the DBMS service. One option, authenticated user, is to have the Web Service authenticate as the user (proxy the user’s identity) with the DBMS service. This approach generally only works with user-ID and password schemes because the Web Service is able to proxy the identity of the user to the DBMS service and provides a password the Web Service obtains either from the
216
Enterprise Web Services Security
Request Web Service
Client
Database Service
Response
Operating System
Service Access Database
FIGURE 9.9 Single server architecture.
client or from a database belonging to the Web Service. The authenticated user approach doesn’t work for authentication schemes that require the Web Service to possess something only the client can possibly possess, such as the client’s private key with X.509 or the client’s IP address with Kerberos. The second option, trusted user, has the Web Service authenticate as itself with the DBMS service, ideally with minimum privileges, and then switch to the client’s identity as part of the transaction. The switch to the client’s identity may involve switching the user context, by setting a variable, by logging on as the client within the session context, by using a function such as Oracle’s Proxy User, or through delegation as in Microsoft’s impersonation feature. The options available to you are a function of the products you are using and what they support. Table 9.2 summarizes the options. Depending on the DBMS service’s capabilities, you may need to create an account for the Web Service on the DBMS service. If you do need to create such an account, you should assign it the minimum privileges and resources necessary to support its function. Multiple-server configurations add the complexity of establishing a trust relationship and a trusted path between the server hosting your Web Service and the server hosting the DBMS service. In this configuration, you have three identities involved in the transaction (the two servers and the Web Services client), three physical boxes (the client and the two servers), and the potential for man-in-the-middle attacks between any two of the parties. There are two options for creating a secure channel between the parties. One is to create point-to-point trust relationships
Protecting Messages, Transactions, and Data
217
TABLE 9.2 WS-DBMS Relationships Relationship Type
Web Service Authenticates With:
System high
The DBMS service using its own credentials and receives the maximum privileges needed by the Web Service’s most privileged client
Authenticated user
The DBMS service using the client’s credentials and receives the client’s privileges
Trusted user
The DBMS service using its own credentials and receives the minimum privileges necessary, then switches to the client’s identity as part of the request
using SSL sessions between the client and the Web Service and between the Web Service and the DBMS service. The other is to create an end-to-end trust relationship where the Web Service simply passes the request it receives from the client to the DBMS service and then simply echoes whatever result the DBMS service returns. Choosing the Identity Mapping Scheme Once you understand the products and configuration you are dealing with, the first decision you need to make in designing your Web Service’s access control strategy is how you are going to map identities to privileges and privileges to resources. Figure 9.7 illustrates the basic options. The answer frequently turns on performance and administrative overhead. Performance is a function of the number of rules involved in making the access decision. Each rule maps an identity (some representation of the client making the request) to a set of privileges to an object, such as a row in a table. The more granular the access and the more entities involved, the more computationally intensive this calculation becomes. The administrative burden comes in the form of how many entities (humans, privileges, and resources) systems administrators must manage. As we go through the various access control options, you will notice different levels of abstraction coming into play to simplify this burden. User-Based Access Control (UBAC)
UBAC maps individual users, or proxies, to privileges and resources [NIST800-12]. The access control question is, does this user have the privileges to perform the requested function against the resources in question? Systems administrators grant
218
Enterprise Web Services Security
privileges to individual users against individual or groups of resources. The number of rules increases rapidly as a function of the number of users and the number of resources. You can reduce the administrative burden by aggregating users and privileges into groups and resources into collections. Most DBMS services support UBAC. Systems administrators set up accounts for each user, using the DBMS’s administrative tool, and map users to privileges and resources. Granularity can be a problem. Most DBMS services support mapping privileges to database objects such as tables, views, and stored procedures, but few go below this level. Some, such as Oracle’s Advanced Security Option (ASO), offer row-level security [OracleLabel04]. If you need this capability and it is not part of the DBMS service you are using, you must implement it yourself either within a stored procedure or as part of your Web Service. Role-Based Access Control (RBAC)
RBAC introduces a level of abstraction by mapping users, privileges, and resources to a common intermediate value, a role [NIST800-12, RBAC04]. The access control question is, does the user making the request share a role with the privileges and resources for which the request is being made? Each role represents a collection of users, a collection of privileges, and a collection of resources. The role presumably has significance and meaning beyond the users and privileges brought together. Roles frequently reflect organizational positions or job functions, based on the premise that users occupying a particular position can perform certain functions. The RBAC strategy requires fewer rules than UBAC because the rules calculation becomes additive rather than multiplicative, as the number of users and resources increases. RBAC degenerates whenever the number of roles is greater than either the number of users or the number of resources. RBAC can degenerate beyond UBAC in situations where both conditions are true. Many DBMS services now natively support RBAC. Under this scheme, systems administrators still create accounts for each user, using the DBMS’s administrative tools, but now they assign that user to one or more roles. Systems administrators or processes-creating resources also map privileges and resources to roles. The access control decision becomes one of marrying the two sets of roles order to make the access decision. One advantage of RBAC is that it allows you to separately manage users and resources; this is important in situations where you are trying to separate administrative functions. If the DBMS service you are using does not support RBAC, an option is to use groups. By mapping users to groups and privileges and resources to the same groups, you can effectively turn group names into roles in a UBAC scheme.
Protecting Messages, Transactions, and Data
219
Rule- or Attribute-Based Access Control (RuBAC)
RuBAC increases the level of abstraction beyond simple RBAC schemes to include arbitrary sets of attributes describing users, privileges, and resources [Rule97]. The access control question is, does this user possess some set of attributes that map to a corresponding set of attributes belonging to the privileges and resources involved? The access control decision function can become extremely complex depending on the numbers and types of attributes involved in making the decision. In the simplest case, you can think of the problem as being one of appending some additional set of constraints to the WHERE clause of every request your Web Service makes against the data source. The other extreme is a complex function that must collect some set of information concerning the user through a series of queries and a corresponding set of information for the privileges and resources, also involving a series of queries, culminating in a matching operation for the decision itself. Oracle’s fine-grained access control options are examples of the capabilities necessary to support RuBAC natively within a DBMS service [OracleLabel04]. Oracle’s Virtual Private Database (VPD) option allows you to implement security policies as functions that can execute at the row level. Oracle’s Label Security builds on VPD to restrict access based on a user’s predefined sensitivity tags or labels. The RuBAC rules function is case specific. Its performance characteristics are a function of the number of attributes and the complexity of the matching function. If you need to use RuBAC, you should estimate the performance overhead early in the design to ensure that you can actually implement the function within acceptable performance ranges. Mandatory Access Controls If you are working on U.S. government projects, especially with the military or the intelligence community, you may run into the concept of mandatory access controls (MACs) [Orange85]. MACs are similar to roles but are based on classification labels. MAC is built on the concept of hierarchical (unclassified, confidential, secret, top secret) and nonhierarchical labels and the concept of dominance. Multilevel environments maintain integrity by enforcing two rules: No read-up: A user in a lower-level domain can only read information at the same or a lower level. No write-down: A user in a higher-level domain can only write down information at the same or a lower level than the lower-level domain. Taken together, these two principles ensure that information only flows vertically or upward, from a security level or sensitivity perspective, in the hierarchy, never downward.
220
Enterprise Web Services Security
Choosing the Access Control Decision Point Once you answer the identity-mapping question, the next question becomes where to actually make the access control decision. Figure 9.10 illustrates the options for implementing the access control decision point. Path A shows the access control decision being made within the context of the Web Service as either part of the service itself or as a call to an external procedure. You would normally choose to implement this decision point as a Java Data Access Object (DAO), EJB, ADO.NET component, or subroutine in order to encapsulate the business logic underlying the decision and to be able to share the function with any Web Service wanting to access the resources in question. Path B moves the access control decision to a stored procedure running within the context of the DBMS service. Path C makes the DBMS service’s access control service the access control decision point. The DBMS service’s access control service should always be the first choice, but that assumes the DBMS service supports the level of granularity and identity mapping scheme you need for your application. The stored procedure implementation would be the second choice, because it aligns with the principle of protecting the resource as close to the resource as possible, but writing stored procedures in SQL-based languages can be difficult. Some products offer Java or some other procedural language for writing stored procedures, which makes this option more attractive. Moving the decision point into your Web Service is the least attractive option, but if the DBMS service doesn’t offer the features you need and a stored procedure isn’t an option, it may be the only choice you have.
Request
Data Access Object
Path A Stored Procedure
Path B Path C
Database DBMS AC Service
Response Web Service
DBMS Service
FIGURE 9.10 Possible access control paths.
Protecting Data as Close to the Source as Possible
We have mentioned several times that you should always protect data as close to the source as possible. Why? In order to reduce risk. The further you move the access control decision point away from the data, the greater the risk that someone will be
Protecting Messages, Transactions, and Data
221
able to successfully attack the data source. Ideally, every piece of data would be selfprotecting, but until that becomes a technical reality, the best you can do is protect data as close to the data source as you can.
SUMMARY In this chapter, we looked at the primary actors involved in creating trust relationships between Web Services clients and servers and the importance of secure channels in ensuring the confidentiality and integrity of the communications between them. We explored the third element of the information security triad, availability, and looked at the key role identity management plays in creating trust relationships and the issues and concerns that authentication, authorization, and access control services must address and some of the tradeoffs they make. In our discussion of identity management, we briefly introduced some of today’s major approaches including passwords and pass-phrases, smart cards, biometrics, certificates, ticketing systems, Microsoft’s Passport, and Liberty Alliance. They all share the goal of allowing one user or process to rely on the asserted identity of another. Authentication is the basic process for validating this asserted identity. We introduced two basic authentication patterns and discussed how they relate to different identity techniques. We delved deeply into the issues of authentication and authorization and the options for performing authentication and authorization decisions on Web, J2EE, and database servers. We also looked in detail at access control, discussing different ways of securing data including user-based, role-based, and rulebased access control. Authorization and access control services are both concerned with mapping identities to privileges, where privileges determine what a user is allowed to see or do, and are therefore closely allied with the concept of authentication.
REFERENCES [ASPAuth04] Microsoft Corporation, “Designing Distributed Applications with Visual Studio .NET, ASP.Net Authentication.” Available online at http://msdn. microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxcon ASPNetAuthentication.asp, 2004. [ASPAuthorize04] Microsoft Corporation, “Designing Distributed Applications with Visual Studio .NET, Authorization.” Available online at http://msdn. microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxcon Authorization.asp, 2004.
222
Enterprise Web Services Security
[CNSS03] CNSS, “National Information Assurance (IA) Glossary, CNSS Instruction No. 4009.” Available online at http://www.cnss.gov/Assets/pdf/cnssi_4012. pdf, May 2003. [FIPS199 03] National Institute of Standards and Technology, “Standards for Security Categorization of Federal Information and Information Systems, Federal Information Processing Standards Publication (FIPS) 199.” Available online at http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf, December 2003. [IATF02] Information Assurance Solutions Technical Directors, “Information Assurance Technical Framework Release 3.1.” Available online at http://www. iatf.net/framework_docs/version-3_1/index.cfm, September 2002. [IISAuth04] Microsoft Corporation, “Designing Distributed Applications with Visual Studio .NET, IIS Authentication.” Available online at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconIISAuthentication.asp, 2004. [J2EE04] Armstrong, Eric, et al., “The J2EE 1.4 Tutorial.” Available online at http://java.sun.com/j2ee/1.4/docs/tutorial/doc/J2EETutorial.pdf, August 31, 2004. [JAAS04] Mahmoud, Qusay, “Java Authentication and Authorization Service (JAAS) in Java 2, Standard Edition (J2SE) 1.4.” Available online at http://java. sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide.html, August 9, 2004. [Liberty04] Liberty Alliance, “Liberty Alliance Project.” Available online at http:// www.projectliberty.org. [NECCC02] The National Electronic Commerce Coordinating Council, “Identity Management: A White Paper.” Available online at http://www.ec3.org/ Downloads/2002/id_management.pdf, December 4–6, 2002. [NIST800-12] National Institutes of Standards and Technologies, “An Introduction to Computer Security: The NIST Handbook.” NIST Special Publication 800-12. Available online at http://csrc.nist.gov/publications/nistpubs/80012/handbook.pdf, October 1995. [NIST800-33] National Institute of Standards and Technology, “Underlying Technical Models for Information Technology Security,” NIST Special Publication 800-33. Available online at http://csrc.nist.gov/publications/nistpubs/80033/sp800-33.pdf, December 2001. [NIST800-63] National Institutes of Standards and Technologies, “Electronic Authentication Guidelines,” NIST Special Publication 800-63 Version 1.0.1. Available online at http://csrc.nist.gov/publications/nistpubs/800-63/SP80063v6_3_3.pdf, September 2004. [OracleASO01] Oracle Corporation, “Oracle Advanced Security 9i: Enterprise User Security: An Oracle Whitepaper.” Available online at http://www.oracle. com/technology/deploy/Security/aso/pdf/EUS901.doc, August 2001.
Protecting Messages, Transactions, and Data
223
[OracleLabel04] Oracle Corporation, “Oracle Label Security: An Oracle Data Sheet.” Available online at http://www.oracle.com/technology/deploy/Security/ pdf/ds_security_db_labelsecurity_10r1_0104.pdf, January 2004. [Orange85] Brand, S., et al., “Department of Defense Trusted Computer System Evaluation Criteria.” Available online at http://www.fas.org/irp/nsa/rainbow/ std001.htm, December 1985. [OSI94] International Standards Organization, “ISO 7498-1 Information Processing Systems—Open Systems Interconnection—Basic Reference Model: The Basic Model, Technical Report.” International Standards Organization, 1994. [PAM96] Samar, Vipin, “Unified Login with Pluggable Authentication Modules (PAM).” CCS ’96, New Delhi, India. Available online at http://portal.acm. org/citation.cfm?id=238177. [Passport04] Microsoft Corporation, “Microsoft .NET Passport.” Available online at http://www.passport.net/. [RBAC04] American National Standards Institute, “Role-based Access Control.” Document Number ANSI/INCITS 359-2004. Available online at http://csrc. nist.gov/rbac/, February 3, 2004. [RFC1510] Kohl, J., et al., “The Kerberos Network Authentication Service (V5).” Available online at http://www.ietf.org/rfc/rfc1510.txt, September 1993. [RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0.” Available online at http://www.ietf.org/rfc/rfc2246.txt, January 1999. [RFC2251] Wahl, M. et al., “Lightweight Directory Access Protocol (v3).” Available online at http://www.ietf.org/rfc/rfc2251.txt, December 1997. [RFC2459] Houslet, R., et al., “Internet X.509 Public Key Infrastructure Certificate and CRL Profile.” Available online at http://www.ietf.org/rfc/rfc2459.txt, January 1999. [RFC2617] Franks, J., et al., “HTTP Authentication: Basic and Digest Access Authentication.” Available online from http://www.ietf.org/rfc/rfc2617.txt, June 1999. [RFC2818] Rescorla, E., “HTTP Over TLS.” Available online at http://www. ietf.org/rfc/rfc2818.txt, May 2000. [Rule97] Didriksen, Tor, Rule-based Database Access Control—A Practical Approach, ACM Workshop on Role Based Access Control, ACM Press, 1997. Available online at http://portal.acm.org/citation.cfm?id=266772. [SAML04] Hughes, John, et al., “Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1.” Available online at http://www.oasisopen.org/committees/documents.php?wg_abbrev=security, May 11, 2004. [SQLServer03] Chander, Girish, et al., “SQL Server 2000 SP3 Security Features and Best Practices.” Available online at http://www.microsoft.com/technet/ prodtechnol/sql/2000/maintain/sp3sec00.mspx, May 16, 2003.
224
Enterprise Web Services Security
[Stallings95] Stallings, William, Network and Internetwork Security: Principles and Practice. Prentice Hall, 1995. [Websters04] Merriam Webster, “Merriam Webster Online.” Available online at http://www.m-w.com. [WSFederation03] Bajaj, Siddharth, et al., “Web Services Federation Language (WS-Federation).” Available online at http://www-106.ibm.com/developerworks/webservices/library/ws-fed/, July 8, 2003. [WSReferal01] Nielsen, Henrik F., et al., “Web Services Referral Protocol (WSReferral).” Available online at http://msdn.microsoft.com/ws/2001/10/Referral/, October 23, 2001. [WSRouting01] Nielsen, Henrik F. and Satish Thatte, “Web Services Routing Protocol (WS-Routing).” Available online at http://msdn.microsoft.com/ws/ 2001/10/Routing/, October 23, 2001. [WSSecurity04] Nadalin, Anthony, et al., “Web Services Security: SOAP Message Security 1.0 (WS-Security 2004).”. Available online at http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf, March 15, 2004. [WSTrust04] Anderson, Steve, et al., “Web Services Trust Language (WS-Trust) Version 1.1.” Available online at http://www-106.ibm.com/developerworks/ library/ws-trust/, May 2004. [XACML03] Godik, Simon, et al., “eXtensible Access Control Markup Language (XACML) Version 1.0.” Available online at http://www.oasis-open.org/ committees/documents.php/2406/OASIS-XACML-1.0.pdf, February 18, 2003.
10
Implementing the Information Security Triad
In This Chapter Confidentiality Integrity Summary References
n the last chapter, we began our discussion of the three important concepts of information security: confidentiality, integrity, and availability with a focus on availability. In this chapter, we turn our attention to the other two elements: confidentiality and integrity. Confidentiality controls are responsible for ensuring that information is protected from unauthorized access. In our discussion of availability, we discussed the importance of and options for mapping identities to privileges and the use of privileges to control access. In our discussion of confidentiality, we will look at mechanisms for protecting information even from parties we cannot identify and in situations where we cannot even control their access to the information. Integrity controls complement confidentiality controls in providing mechanisms for guaranteeing message validity and detecting tampering even if control is lost over a message or its content. In this chapter we will discuss how each
I
225
226
Enterprise Web Services Security
of the three aspects of the confidentiality-integrity-availability (CIA) triad can be enforced using the controls that are available to a Web Services system and its supporting infrastructure. The important technical mechanisms for enforcing security are presented in detail to help you choose the appropriate technology for your environment and specific concerns.
CONFIDENTIALITY One of the three elements of the information security triad is enforcement of confidentiality. Like most terms of art, this one has a meaning that is precise but that is easily misunderstood by those who have not been initiated. Most people think of confidentiality as being equivalent to secrecy, but there is a difference. Given a piece of information that you know, you keep it secret by not telling anyone. As long as you never reveal it, the information is secret (unless, of course, someone can find it out by some other means). Confidentiality is different because it usually involves the controlled disclosure of the information being protected. In most situations involving confidentiality protection, you want to reveal the information to another person while protecting that information from third parties who want to snoop on your information exchange. In concrete terms, you want to reveal your secret to someone and expect the system to make sure that nobody else is able to eavesdrop on that disclosure. Whatever technology provides you with confidentiality protection must allow for a controlled release of information. We talk about “controlled release” because you must reveal the information to someone for it to be used. If it’s never released for use, it’s confidential but not very useful. We control the release of the information for use so that only the people who need access to the information are allowed to use it. The system must enforce the rule that only people who have authorization to access the information are allowed to see it. The question is, “how do we provide this sort of protection?” In most instances where we talk about confidentiality protection, the answer is to use some form of encryption. Encryption is one of the ways that WS-Security provides protection for Web Service messages. Encryption Encryption systems have been in use for centuries. They are used to thwart interception attacks, which are situations where a third party gains access to the information and can act upon it. The components of a basic encryption system are shown in Figure 10.1, which introduces several of the terms used with encryption. The message the users wish to share is called the plaintext (plain as in normal format, understandable by the owner or the owner’s application) or cleartext. An encryption
Implementing the Information Security Triad
227
algorithm (such as the Advanced Encryption Standard [AES], the Data Encryption Standard [DES], or Rivest, Shamir, and Adelman [RSA]) processes the plaintext. The encryption algorithm uses an encryption key to transform the plaintext into ciphertext, which is constructed from the plaintext by some method that obscures the original plaintext. The transformation between the plaintext and the ciphertext depends upon the value of the encryption key. The ciphertext is transmitted between the two parties over some means (a network, a floppy disk, USB key, etc.; the transport isn’t important). A decryption algorithm uses the decryption key to transform the ciphertext back into the original plaintext. For many practical encryption systems, things are simpler than Figure 10.1 shows. One common simplification used by many systems is that the same key is used for both encryption and decryption. The users of the system must simply agree upon a single shared key to use for encrypting communications between them. Also, the encryption and decryption algorithms are usually the same. To decrypt, you run the algorithm in reverse, which performs a sort of “un-do” operation, reversing the changes that lead to the ciphertext.
Plaintext Input
Encryption Algorithm
Transmitted Ciphertext
Encryption Key
Encryption Algorithm
Plaintext Output
Decryption Key
FIGURE 10.1 A basic encryption scheme.
The purpose of the cryptosystem shown in Figure 10.1 is to protect the plaintext message while allowing the parties to share that message. For a network transmission, we normally assume that the network between the sender and the receiver is insecure, allowing an eavesdropper to read the ciphertext. We also assume that the attacker knows the encryption algorithm being used. Therefore, the protection of the plaintext lies entirely in the strength of the encryption algorithm and the secrecy of
228
Enterprise Web Services Security
the encryption key. You will notice that we have a “chicken and egg” situation where the parties must exchange the encryption key in secret prior to the use of that key in encrypted sessions. There must be some way outside of the normal data transfer for that key exchange to take place. If an eavesdropper were to observe the key exchange, the encryption would serve no purpose, as the eavesdropper could simply apply the (known) decryption algorithm and key to read the messages. If one looks at Figure 10.1 from the point of view of people who want to eavesdrop on the message, there are several other places where they may mount an attack. First, if they can read the message before the sender encrypts it, the encryption process does the users no good. They can also mount this attack on the receiving system after the message has been decrypted. Another method is for them to sniff the encrypted data in transit. If they are able to store enough encrypted data, they may be able to mount a statistical attack against the plaintext. Simply knowing that a message has been sent may provide information on its own. If the two parties are a company and a customer, the message exchange probably represents the purchase of a product, for example. An encryption algorithm takes an input stream (a stream is a series of bits) and processes it to create a ciphertext stream. The two classes of cryptographic algorithms are called block ciphers and stream ciphers. A block cipher works on one block of input data at a time (common block sizes are 64, 128, and 512 bits). Plaintext input is read until a buffer is full, and then that buffer is passed to the encryption algorithm for encryption. The output of the encryption algorithm is a block of data, usually the same size as the input buffer. A stream of input data must be collected until a block is filled before a ciphertext block is issued. If there is not enough data to fill a block, a block cipher must pad the input data by adding extra bits to fill in for the missing bits. Some mechanism must be employed to remove the pad when the block is decrypted. On the other hand, stream ciphers work on the input one byte at a time, emitting a ciphertext byte immediately upon receipt of each plaintext byte. Encryption systems are expected to resist attempts to decode the information in the ciphertext in order to determine the plaintext. Cryptanalysts are concerned with attempting to find ways to decrypt private communications; cryptographers try to create cryptosystems that resist cryptanalysis. Cryptosystems can be attacked in several ways, in increasing usefulness to the attacker: Ciphertext Only: The analyst has access to the ciphertext and knows the encryption algorithm being used. Known Plaintext Attacks: The analyst knows the plaintext and corresponding ciphertext.
Implementing the Information Security Triad
229
Chosen Plaintext Attacks: The analyst can choose a plaintext message and learn the corresponding ciphertext. Chosen Ciphertext Attacks: The analyst has access to plaintext-ciphertext pairs and is allowed to choose the ciphertext result. Ciphertext-only attacks are the most difficult to mount, as the cryptanalyst has the most limited knowledge. As one proceeds down the list above, the effectiveness of the attack improves because the attacker has more information to work with. Clearly, it is unlikely that anyone will permit an attacker the sort of access implied by chosen text attacks, but the other attacks are practical. For example, it is very likely that an attacker can choose the plaintext if he is able to enter a transaction into a system and observe the resulting ciphertext. Another way in which known plaintext attacks become practical are when they are mounted against virtual private network (network encryption) schemes. Every IP packet sent over a network has an IP header that has the same first few bytes (these give the IP version number, which is 4 for most current Internet traffic, and the header length, which is usually five octets in length). These and other header contents are sufficiently regular to provide an avenue for known plaintext attacks. The attacker can use this technique to probe the statistical properties of the ciphertext. This attack involves making small changes to the plaintext while looking for the corresponding changes in the ciphertext, hoping that such changes will provide insight that allows derivation of the key. To avoid these sorts of attacks, a strong cryptographic system attempts to avoid statistical correlation between the plaintext and the ciphertext. If an attacker is able to relate bits of the input to corresponding bits of the output, that relationship may provide help derive the associated key. Consequently, expectations are placed on cryptosystems that help analysts decide whether a system is worthy of use. These help measure how well the system avoids correlations between input and output. First, a system is expected to avoid correlation between changes in input bits and changes to output bits. This allows the system to avoid tracking plaintext bits when ciphertext bits are known. Usually this is performed by operations that switch bit positions multiple times; this technique is called confusion. A highly confused output cannot be used to determine information about the input. Another technique is to ensure that a change to a single input bit causes multiple changes in the output. Ideally, a single bit change to the plaintext would change all the ciphertext output bits. This technique, called diffusion, also avoids attacks based on small input changes. A strong cryptosystem uses both diffusion and confusion in multiple steps, called rounds, which mash the data in unpredictable ways that resist cryptanalysis. In the absence of a statistical attack, cryptanalysis is limited to brute-force key attempts. A good cryptographic system ensures that these attacks are impractical, as described below.
230
Enterprise Web Services Security
Symmetric and Asymmetric Key
There are two different classes of cryptographic systems in common use today. Almost all bulk encryption systems in common use today (those used to encrypt large amounts of data, or those where performance matters, such as virtual private network [VPNs]) use symmetric key encryption. The distinction between these systems is that a symmetric key system uses the same key value for encryption as the key used for decryption. Only one key need be shared between users for such a system to work. Asymmetric key systems use different encryption and decryption keys or different encryption and decryption schemes. Commonly used symmetric key algorithms are the AES, the older DES and the RC4® cipher. The most common asymmetric key ciphers are the Diffie-Hellman and RSA systems, which will be described later. Symmetric key systems are easy to use and manage and easy for most people to understand. The cryptograms printed in your daily paper use a symmetric key that is the correspondence between the plaintext letter and the ciphertext letter. (Incidentally, the fact that these cryptograms use a fixed transposition between plaintext and ciphertext is what makes them easy to solve: they have the same letter frequency as plain English text, where “e” is the most common letter.) Bulk encryption algorithms such as AES and DES use this method. The key used for encryption is simply fed into the same algorithm used in reverse in order to decrypt the ciphertext. These are (relatively) simple systems for people to understand because they usually do something to scramble the plaintext and do the same thing again to recover the plaintext. Just about all of the early cryptographic systems used symmetric, shared keys. The simplicity of these systems is their downfall, however. When you attempt to implement a symmetric cryptographic system for a large community of users, you immediately run into the problem of key distribution. The key distribution problem is easily illustrated. While a simple exchange between parties A and B (usually referred to as Alice and Bob) only requires one key shared by Alice and Bob, a system with six users (Alice, Bob, Charley, Dave, Ed, Frank, and George) requires 15 keys. The formula for the number of keys needed is
(n)(n - 1) , 2
where n is the number of users. Why are different keys used for each
pair of users? Because it allows Alice to send something to Bob that Charley, Dave, and so forth can’t also read. Using one key would mean that everyone could read everything, leading to the large number of keys illustrated. For a company with 500 users who wish to communicate confidentially, this means someone must manage 124,750 keys. Worse, when employees join or leave the company, all their keys with other users must be either issued (for the new employee) or invalidated (for the person leaving the organization). You would need a full-time employee to issue, distribute, and invalidate keys. This key management issue is why almost all widely used systems use asymmetric cryptography. (We say
Implementing the Information Security Triad
231
“almost all” because there is a well-known counterexample: the systems banks use to support funds transfer uses symmetric, individually configured encryption keys. This is an example of how impracticality need not be a barrier if there’s enough money involved. The ability to withdraw money from your checking account in almost any industrialized country demonstrates that the system works well despite how practical it may or may not be.) An asymmetric cryptographic system attempts to work around the key management problem by reducing the number of keys that need to be transferred for the system to work. In such a system, every user is assigned at least one pair of related keys. One key is used to encrypt data being sent to that user; the other key is used to decrypt the user’s data. The information cannot be decrypted without the user’s key, which corresponds to the key that was used to encrypt it. Knowing the encryption key does not help in decrypting the message. These systems are built upon a system that relates multiple (usually three) pieces of information. One is a common modulus used for mathematical operations, and the others are a related pair of encryption and decryption keys that are associated with that modulus value. A user’s encryption key and the modulus are published as the public key for that user. The term publish is important, as anyone is allowed to know that public key information. That information could be printed in a newspaper without compromising any information that is encrypted using that key information, so it can be sent to the public key owner. The owner of that key is the only person who knows the private key that corresponds to the public key. The private key uses the same modulus but uses a decryption value known only by the owner of the public key that can be used to decrypt information that was encrypted using the public value and modulus. The advantage of a public key system is that only one piece of information need be published for each user. A directory system can be set up to store the public key data for each user of the system; given access to the directory, any user on the system can communicate confidentially with every other user. Invalidation is also easy because removing the user’s entry from the directory system immediately stops all users from sending that user encrypted data (equivalently, new employees are introduced to everyone by publishing them in the directory). Asymmetric key systems usually publish user identity by use of certificates. A certificate contains the owner’s identity information (name, company ID number, department, etc.) along with his public key encryption data and modulus. The content of the certificate is attested to and protected from tampering by using a digital signature (which will be described later). The purpose of digital certificates is often confusing to people just being introduced to cryptographic systems. It is important to remember that a certificate only contains public information. Anything in a certificate is information that anyone could be allowed to know without compromising the owner’s private information. The associated private key value is the only
232
Enterprise Web Services Security
information that the certificate owner must protect. Note that the side effects of private key compromise are much less serious than those with a symmetric key system. If a symmetric key user loses his or her key, everyone else in the system must be notified to not use that key any longer. For a public key system, all the user must do is to publish a new public key pair (associated with his new private key.) Key Strength Comparisons
The primary measure of the strength of a cryptographic system is the key size (or key length). (However, see the discussion of “snake oil” below.) If the system is properly defined, adding an additional key bit doubles the strength of the system; that is, twice as much work must be done to break the key. It’s difficult for most people to understand the value of such doubling and how quickly it increases the strength of the underlying crypto. Our gut reaction is that a simple change that adds a few bits doesn’t improve things much. To demonstrate this problem, consider the following scenario: you are offered a job for a single month with 31 days. You are offered the following options for your pay: 1. One thousand dollars for each work day 2. One penny for day one, doubled to two cents for day two, and doubled again (to four cents) for day three, etc. Most people would intuitively choose the first option, which earns them $31,000 by the time the month is out. However, it’s easy to point out the failure of the intuition. If you choose the penny doubling pay, you’re pretty miserable by the end of the first week. You’ve only received 64 cents for your day’s work at the end of the first week. After two weeks, it’s still not very positive, as on day fourteen, you’re still only getting $81.92 for the day. It’s not until day 18 that you finally start to catch up, with $1317.02 for the day, which is still far behind the $18,000 the other people have received. However, week three starts to look better because you collect $10,485.76, allowing you to start to catch up to the opponent. If you calculate your pay for the last day of the month ($10,737,418.24) it’s apparent that choosing the smaller payout at the beginning is the correct choice. The same growth in encryption strength is seen when key sizes increase. Adding another bit of key size doubles the strength of the system (at least for a brute-force attack). A brute-force attack is where the attacker tries every possible key value until one is found that decrypts the ciphertext correctly. A well-designed cryptosystem does not allow any attack that is better (quicker to perform) than a brute-force attack. Just like the pay analogy above, increasing key size can quickly make it entirely impractical to break a system using brute force. If, for example, your 32-bit key can
Implementing the Information Security Triad
233
be broken in one year by a brute-force attack, just increasing the key size to 40 bits means your attacker must work for 256 years for the attack to succeed. Given that current encryption systems commonly use 64, 128, or larger key lengths, it’s clear that there is little chance of brute force being successful. There are some complications, however, as it’s not always possible to compare “x” bits to “y” bits and decide which is stronger. First, symmetric algorithms typically depend upon the computational strength of their algorithms to protect the data encrypted with a particular key size. This means that as computers become faster and faster, it becomes easier to implement a brute-force attack. If computers double in power every 18 months (as given by Moore’s law), they catch up with one more bit of key length every 18 months. If your cryptographic product needs to have a 10-year lifespan, you must have enough key length to resist the 15 times increase in computer power that’s gained over that time as four additional key bits will allow the system to continue to resist attacks. However, there are some cryptographic algorithms where the strength cannot be increased by just growing the key size. The DES algorithm uses a 56-bit key. When the National Security Agency (NSA) originally proposed the DES, some wondered, “Why didn’t it use a 64-bit key?” Over time, cryptanalysts have discovered that there are subtle weaknesses in the algorithm that means there are attacks that are better than brute force for key sizes much above 56 bits. Increasing the key size would not have improved the resistance of the DES to attack. Another difficulty with comparing algorithms is that the strength afforded by the key size may not be easily compared. Symmetric key algorithms use fairly small keys (56 bits, 128 bits, etc.), whereas asymmetric algorithms use much larger keys (1024 bits or larger). This is because they typically rely on the attacker’s inability to factor a large number (that is, determine what numbers multiplied together yield the original large number). Factoring a 64-bit number is quite easily done with current technology, but larger numbers (1024 bits or more) are far more difficult. To have an equivalent work factor (amount of work necessary for a brute-force attack), the symmetric key algorithm needs much smaller keys to make brute-forcing impractical than the key sizes needed by asymmetric key algorithms. Thus, a 256-bit AES key is currently much stronger than a 1024-bit RSA key. You can’t just look at the number and declare the RSA key to be better. In fact, it’s difficult to pin down experts as to exactly how large an RSA key should be to be equivalent to a 56-bit DES key. Something around 300–400 bits seems to be a rough consensus, but there’s no straightforward or authoritative table giving the equivalence. One also needs to be careful when comparing key lengths because cryptographic algorithms are continually being invented with huge key sizes or claims of “new, revolutionary” algorithms. The reliance on huge keys or on proprietary, secret encryption techniques are signs of crypto “snake oil” products (see http:// www.interhack.net/people/cmcurtin/snake-oil-faq.html) that are likely not worthy of
234
Enterprise Web Services Security
consideration. We already have excellent cryptographic products that are free for anyone to use (AES, DES, and so forth); why would people consider an unproven product they have to pay for? When a cryptographic product needs thousands of key bits to be secure, there’s probably something wrong and it’s something to be avoided. The best thing to do is use known, established cryptographic libraries. The Data Encryption Standard
DES is a symmetric cryptographic algorithm that uses a 56-bit key. It is a block cipher that uses a 64-bit block size. In 1977, the National Bureau of Standards (NBS) (now called the National Institute for Standards and Technology) published the standard that defines how DES operates [NIST77]. It was originally proposed for use in hardware encryption engines for protecting commercial and U.S. government unclassified information. DES was designed by IBM based on an older IBM cipher called Lucifer. The NSA suggested several changes in the proposed IBM cipher that were incorporated into DES. There have always been questions about the level of involvement the NSA had in the design of DES, but the design has endured both brute force and more sophisticated attacks for two decades. The basic structure of the DES algorithm is shown in Figure 10.2. It is a fairly simple algorithm, with an encryption operation repeated several times (for 16 repeats, or “rounds”) to provide the required encryption strength. (Some attacks have been demonstrated for DES with a limited number of rounds, but those attacks were not able to penetrate a full 16-round DES.) Each round takes a 48-bit key derived from the encryption key. Before encryption starts, the input block is scrambled by a fixed permutation operation where each bit of the input block is moved to a designated bit on the block being processed. The DES round operation is diagrammed in Figure 10.3. For encryption (Figure 10.3a), the 64-bit block is first split into left and right halves. The right half of the current round becomes the left half input to the next round. The left half is manipulated by a scrambling function and combined with the left half and becomes the right half input to the next round. The scrambling function expands the 32-bit value to 48 bits wide by duplicating bits, uses a table lookup (called an “S-box”) to transform the resulting values into new output values, and generates a new 32-bit output value. This is combined with the current left half using an exclusive OR (XOR) function (depicted by the circle with a plus sign in Figure 10.3). The XOR function allows the input to be transformed so that it can be reversed. Reversal is possible because taking an arbitrary input A and combining it with another value B using XOR results in a value C; taking the XOR of C and B results in the original value A. Table 10.1 shows the XOR function in operation.
Implementing the Information Security Triad
64-bit input
235
56-bit key
Initial Permutation
16 Round Keys
Round 1
Round 2
Round 16
Swap Left and Right Halves
Final Permutation
64-Bit output
FIGURE 10.2 DES structure.
TABLE 10.1 The Exclusive OR Operation A
B
C (A XOR B)
Recovered A (C XOR B)
0
0
0
0
0
1
1
0
1
0
1
1
1
1
0
1
Each DES encryption round takes half of the input block and transforms it to a new value based on the left and right halves of the input. The output from that round becomes the input to the next round. Each round uses a unique round key
236
Enterprise Web Services Security
64-bit input
32-Bit L
64-bit output
32-Bit R
R
R
32-Bit L
32-Bit R
R
Scrambling Function
32-Bit L
32-Bit R
R+1
R+1
R
Scrambling Function
32-Bit L
32-Bit R
R+1
64-bit output
64-Bit Input
a) Encryption
b) Decryption
R+1
FIGURE 10.3 DES round structure.
derived from the encryption key. The output from the final round is permuted (like the initial permutation) and becomes the final encrypted block. Multiple rounds are used to increase the strength of the encryption function. Each round increases the dispersion of the input data, leading to improved diffusion and confusion of the input data. The decryption round depicted in the right half of Figure 10.3 runs the algorithm in reverse, with the key schedule also operated in reverse. Triple DES
The DES algorithm, which was released in 1977, lasted for 20 years as a presumably secure encryption function. The NBS held recertification reviews of the DES algorithm every five years; at the second review in 1987, one suggestion made by the NBS was to decertify DES and replace it with secret encryption algorithms known only to the NSA. This suggestion was rejected and the DES recertified for another five years [NIST88]. In the early 1990s researchers began to take advantage of the Internet connectivity that allowed them to distribute a brute-force cracking effort across thousands of volunteer systems around the world. Several distributed bruteforce attacks were mounted against DES, culminating in an effort in 1999 that demonstrated cracking a DES-encrypted value in just over 22 hours with a combination of a relatively inexpensive DES cracking engine (which cost $200,000 to design and build) and a distributed network of volunteers [McNett99]. Computing
Implementing the Information Security Triad
237
power and the availability and cost of dedicated DES brute-force hardware had improved to the point that DES alone could not be considered a secure means of protecting information. Users were reluctant to abandon DES because it had a long history without compromise (other than the previously described brute-force attacks). One means proposed to fix this problem was to use multiple DES operations in a series, with the output of one DES operation being used as the input to a new, separate DES operation. Using DES twice would not provide a significant improvement in brute-force resistance. Because of an attack called the “meet-in-themiddle” attack, double DES would only add one additional bit of strength, which was not enough to be worthwhile. The proposed fix was to use DES three times in sequence, creating an algorithm called triple DES (3DES). 3DES can take two forms. The most common use strings a DES encryption function with a 56-bit key 1, followed by a DES decryption using key 2 and a final encryption using key 1. (Notice that the first and third keys are the same.) This form of 3DES provides a 112-bit key (two 56-bit keys) but allows compatibility with single DES if both key 1 and key 2 use the same value. This is because the first block encrypts using key one and the second decrypts using the same key. This combination has no effect on the input; and only the final DES encrypt has any effect on the input. For more secure requirements, the system can use two different keys for the first and second rounds. This structure is called EDE for encryptdecrypt-encrypt. If three DES operations are used that all encrypt with three separate key values, the algorithm is referred to as EEE (encrypt-encrypt-encrypt) and has a 168-bit equivalent key strength. Most users found the strength of the 112-bit 3DES to be a useful stopgap while research into an improved public encryption algorithm proceeded. The Advanced Encryption Standard
While 3DES was considered to be an acceptable stopgap, there were some objections to its widespread use. 3DES was considered slow, as the processing cost for a 3DES system provided less protection against brute-force attack than competing encryption algorithms. Given the increase in network bandwidth, performance of the encryption algorithm began to be a real concern, as using a 3DES encryptor create a bottleneck in a network encryption system. This led to a demand for an improved, higher-performance encryption standard that could be used royalty free by anyone, just like DES. The National Institute of Standards and Technology (NIST) issued a contest in January 1997 to help select the replacement algorithm for DES. Algorithms were accepted from cryptographers worldwide, subjected to scrutiny by other cryptographers, and tested by NIST for performance. This is very different from the earlier proposals to replace DES with a secret algorithm, avoiding some of the concerns that people outside the U.S. had about the U.S. dominating the design.
238
Enterprise Web Services Security
Of particular concern was avoiding NSA influence on the design, even though history has shown that the NSA suggestions for the DES design strengthened the ability of the cipher to resist certain attacks. The contest rules required submission of an unencumbered (royalty-free) algorithm that allowed multiple key sizes (128, 192, and 256 bits) with a 128-bit block size. Fifteen algorithms were submitted; of those, five finalists were chosen for further review: MARS (from IBM), RC6 (from RSA Laboratories), Rijndael (from Joan Daemen and Vincent Rijmen), Serpent (from Ross Anderson, Eli Biham, and Lars Knudsen), and Twofish (from Chris Hall, Niels Ferguson, John Kelsey, Doug Knudsen, and Bruce Schneier). After comments from the cryptographic community, Rijndael (pronounced Rhine doll) was chosen as the winner [NIST99]. Rijndael is a 128-bit block cipher that allows 128-, 192-, and 256-bit keys. The basic design of Rijndael is similar to the design of DES in many respects. AES uses a scrambling algorithm to transform the input into ciphertext; the algorithm may be repeated 10, 12, or 14 times. Unlike DES, AES operates on the entire 128-bit block for each round. For each round, the data is subjected to a byte substitution where each input byte is transformed into a different output byte. The rows in the input block are then shifted by zero, one, two, or three places. A mixing operation multiplies the input block by a fixed matrix. A final operation adds the round key (using an XOR operation) to the block, yielding the output block to be fed to the next round. AES uses a different set of mathematical operations to scramble the input data. While DES uses lookup tables and bit transpositions, AES uses shifts, multiplication, and lookup tables. This combination of operations allows AES to more quickly diffuse the input block into an output block. For AES, only two rounds are adequate to fully disperse the input bits (each of the 128 output bits would depend upon each of the 128 input bits). AES uses 10 rounds, as there have been attacks shown that are better than brute force for up to six rounds, while no known attack is better than brute force at seven rounds. The additional three rounds were felt to provide a margin of safety if improvements to the attacks are found. As this is being written, AES is just beginning to be used in commercial products. For example, some wireless encryption products use AES to replace the flawed RC4 implementation used in Wired Equivalent Privacy (WEP). RC4
Both DES and AES are block ciphers. While these are widely used (particularly for file encryption operations where it is convenient to work with data in fixed-size blocks), network traffic does not lend itself to block operations. One reason for this is the requirement to pad input to fill out a block. Often messages transported over a network connection are an odd number of bytes. Since this requires padding of
Implementing the Information Security Triad
239
almost every message, there is a potential for a significant amount of the network bandwidth to be wasted in pad bits (this is especially true since the network layers are designed to forward traffic to the network layer as soon as it is available rather than waiting for later data to arrive). The additional delay adds latency to the network, which can impact applications that are sensitive to delay, such as Voice over IP (VoIP). The solution to this problem is to use a stream cipher, such as the RC4 cipher described in this section. The RC4 algorithm was designed by Ron Rivest (RC is an acronym for Rivest Cipher) and was originally a trade secret. The algorithm was reverse-engineered and published as an Internet request for comments titled ARC4 (for Alleged RC4) [ARCFOUR]. The algorithm has had significant cryptanalysis and is believed to be secure as long as it is used properly. RC4 accepts a key from 8 to 2048 bits in length. The algorithm maintains a 256byte state table initialized from the key value. Once initialized, RC4 modifies the state table while calculating an output byte that is used to encrypt the data. Once the algorithm is “cranked” a few times, the output byte stream is very random. (RC4 applications usually discard the first 256 output bytes in order to ensure that the output is well mixed and unpredictable.) The RSA encryption operation is very simple. As plaintext bytes arrive, a new encryption byte is received from the RC4 algorithm. This byte is combined with the plaintext byte using an XOR operation. The resulting ciphertext is then transmitted to the destination. The RSA decryption operation is identical to the encryption operation. Since the RC4 algorithm on the decryption end generates the same random byte stream, it can be combined with the ciphertext byte to recover the original plaintext. This is because the ciphertext is P R (where P is a plaintext byte and R is a random RC4 byte) combined with an XOR operation. At the decryption side, the client receives P R, generates the same R (since they are using the same key), and recovers P by using P R R. The two XOR operations with the same R value cancel each other out, yielding the original plaintext byte P. Diffie-Hellman
The encryption algorithms discussed so far are all symmetric key operations. The RSA algorithm (which will be described later) is a public key system that is built on ideas first published by Diffie and Hellman in a paper published in 1976. Diffie and Hellman proposed a way of building a public key system and provided a sample implementation that allowed users to exchange a secret key value. While the DiffieHellman system does not provide encryption or signatures, it was an important first step toward a full public key cryptosystem.
240
Enterprise Web Services Security
Diffie-Hellman allows two (or more) users to communicate a new key value over an open network without fear that eavesdroppers can figure out what the key is. It uses two public values: a generator (g) and a prime modulus (p). A prime modulus is a prime number (a number that can only be evenly divided by itself and one) that is used in a modular arithmetic operation. Modular math is just like normal math except that the results are limited to a range. For example, clock operations are modular; adding four hours to 9:00 yields 1:00, as the result wraps at the 12:00 point. The clock operations are done modulo 12 (for a 12-hour clock). The results from modular calculations are processed by a division operation, and the remainder of that division becomes the result. For example, 12 + 16 mod 5 = 28 mod 5 = 3 because 28/5 is 5 with a remainder of 3. 12 + 17 mod 5 = 29 mod 5 = 4 because 29/5 is 5 with a remainder of 4. 12 + 18 mod 5 = 30 mod 5 = 0 because 30/5 is 6 with a remainder of 0. The result of a modular arithmetic operation cycles between zero and p 1, then starts over at zero. The clock example given above is a bit different, as it cycles from 1 through 12. Use of Diffie-Hellman requires the participants to come up with a large prime value p and a g value that is less than p. These values can be published anywhere and form the public key of the Diffie-Hellman system. Table 10.2 shows the steps in a Diffie-Hellman key exchange between two users. TABLE 10.2 Diffie-Hellman Key Exchange Alice
Bob
1. Pick KA at random KA
2. Compute TA = g
3. Pick KB at random mod p
5. Send TA to Bob
4. Compute TB = gKB mod p 6. Send TB to Alice
KA
7. Compute SA = TB
mod p
8. Compute SB = TAKB mod p
Before the system can be used, the parties must agree on a prime and a generator. There is no reason for protecting this public key value (that’s why it’s called a public key). When Alice wants to exchange a key with Bob, she begins by choosing a random number KA (Alice’s key) and then computes a value to be traded (TA) by exponentiating the generator g KA times. That TA value is sent to Bob, who chooses his own random KB, does the same exponentiation, and sends the result back to
Implementing the Information Security Triad
241
Alice. An eavesdropper knows the TA and TB values but cannot know the random values because it is not practical to guess the K values without brute force (trying g2, then g3, g4, g5, g6, g7, g8 until all possible values are tried). This difficulty forms what is called a trapdoor function, which is something that is easily computed one way but much more difficult to reverse. It’s easy to compute gK mod p, but reversing it is hard because the mod operation resets the result periodically. This means you can’t just guess at a K, look at the value, and decide if your guess is too big or too small. (This is called a discrete logarithm trapdoor. These are also used in RSA.) The two S values computed by Alice and Bob end up computing the same value: Alice computes (gKB)KA and Bob computes (gKA)KB. These calculations have the same result. Bob and Alice can use their public key to generate new temporary session keys as often as they like. They can also share their public key with others, allowing a large community to communicate securely. A compelling example of such widely known public key values is use of Diffie-Hellman within the Internet Key Exchange (IKE) protocol. IKE is used to initialize encrypted communications over IP Security (IPSec) Virtual Private Networks. IKE uses a predefined set of Diffie-Hellman public key parameters to allow the systems setting up their VPN to decide upon session keys. RSA
Diffie and Hellman set out to create a public key encryption system but were not able to come up with a practical encryption scheme based on their ideas. Several alternatives were proposed to complete the system, but the most successful was the RSA public key system, published in 1977 [RSA78]. (RSA is named for its creators, Rivest, Shamir, and Adleman.) Like Diffie-Hellman, RSA uses modular arithmetic as the basis of its operations. Three values are calculated and two are published as the user’s public key. The user retains the third for the private key. The setup for a user’s RSA key pair is performed only once when the user requests a key pair. First, the system generates two large prime numbers (p and q). The product of those two primes becomes the modulus n. The strength of the RSA system depends upon the inability of an attacker to factor the modulus (that is, determine what two primes were multiplied to calculate it). Therefore, the resulting modulus should be large. Modulus sizes of 1024 bits or more are common. This means the p and q should be on the order of 100 digits long. Once a modulus is calculated, an encryption key e is chosen and a decryption key d is calculated. The two primes that generated the modulus are used to calculate the encryption and decryption keys. Once the keys are known, those primes can be discarded, as they will no longer be used. The user’s public key is the pair n and e and is published so that anyone who wishes to communicate with the user can
242
Enterprise Web Services Security
find out those values. Very often, the encryption key and modulus are stored in an X.509 public key certificate that binds those keys to a particular user’s identity. Anyone who wishes to communicate with the user downloads his certificate and retrieves his e and n values. Encryption in RSA is performed by taking the plaintext message m, raising it by the exponent e, and computing the result modulo n. The resulting ciphertext c is then transmitted to the recipient. The decryption operation exponentiates the ciphertext by the decryption exponent d modulo n, resulting in the original plaintext. How this works is outside the scope of this book, but it uses the extended Euclidean algorithm (published around 300 BC) to compute the required d, which is the multiplicative inverse of e in the fixed field n. If you’re interested, a Web search for “extended Euclidean” should provide some interesting reading. RSA provides a practical implementation of public key encryption, but it is rarely used for bulk encryption (encryption of large amounts of data). The central processing unit cost of RSA encryption is much less than the performance of ciphers such as DES or AES. Consequently, most public key encryption systems work by using a symmetric block cipher (DES or AES) to encrypt the data using a random session key. That session key is encrypted using the RSA public key of the recipient and is included with the ciphertext. The recipient then uses his private key to decrypt the session key and uses the appropriate symmetric cipher to decrypt the data. Another reason for using RSA to only encrypt a temporary session key is that often messages are sent to multiple recipients. If you wish to send a message to 10 users, you would need to send 10 copies, each of which was encrypted with one recipient’s public key. When symmetric key encryption is used, all you need to do is encrypt the session key with each recipient’s public key and transmit one copy of the message. Much less redundant data need be sent in the case of a large message. Steganography Steganography is a way of keeping information confidential that is very different from cryptographic techniques. In normal cryptographic systems, it is clear to anyone who eavesdrops that some message is being transmitted. Steganography tries to hide in plain sight by concealing a hidden message inside some other message. The word derives from the Greek for “hidden writing.” Classical examples of steganographic techniques is the use of grilles (see Figure 10.4). The writer lays down a sheet with cutouts upon it and writes the message in the cutouts. After removing the cutout, a message is composed around the real message. The recipient has a grille with the same pattern of cutouts that he lays over the message to read the hidden text. Other steganographic techniques include invisible ink, ciphers decoded by reading the first letter of every word, and so forth. These mechanical schemes are not practical for computer usage.
Implementing the Information Security Triad
ship
243
sails
at noon
attack
at
dawn
FIGURE 10.4 An example of a steganographic grille.
Steganography has become more interesting with the use of the Internet to transfer images as part of Web pages. There is enough redundancy in most images that small changes in colors at various points in the image can be made without seriously degrading the quality of the image. This allows imbedding a hidden message inside an image on a Web page. Someone without the tool to extract the hidden message may well be unaware of the hidden payload. Several public domain programs do this. Some have speculated about the possible use of steganography by terrorist organizations for communications with their field operatives, but no instance of this usage has been proven. SSL and TLS Probably the way most people use encryption at the present time is by an encrypted Secure Sockets Layer (SSL) connection using their Web browser. Most Web users know what an “encrypted connection” is and what the padlock on their browser’s toolbar means. The connection to the remote host is “secure.” SSL and Transport Layer Security (TLS) are more than just a Web browser add-on; they are a generalpurpose encryption and authentication layer that can be applied to any TCP/IP connection, independent of the underlying protocol. SSL came first as an add-on to Netscape’s Navigator in 1995. SSL version 3 is the current revision of the SSL protocol suite. Current widely used browsers support SSLv3. The Internet Engineering
244
Enterprise Web Services Security
Task Force attempted to standardize the SSL protocol in their TLS protocol request for comments (RFC) but made changes to the protocol that made TLS incompatible with SSLv3. Current browsers support TLS, but it is disabled by default; the defacto standard is SSLv3. We will refer to the protocols as SSL rather than “SSL or TLS” for brevity, as both operate essentially the same way. An SSL client (again, usually a Web browser) is preconfigured with a set of trusted certificate authorities that are allowed to sign public key certificates for Web sites the browser visits. The SSL protocol verifies the validity of the Web site certificate and checks whether it was issued by a trusted certificate authority prior to allowing the user to connect to the target Web site. This provides a somewhat more secure operation, as the Web site certificate attests to the fact that you did indeed connect to amazon.com and not someone attempting to spoof them. SSLv3 and TLS also allow Web sites to authenticate users. If a user is issued a public key certificate, it can be presented to the Web site during the SSL connection setup so the Web site can verify the identity of the user. This allows the client and the server to mutually authenticate each other, which adds additional assurance beyond the encryption that comes with SSL. The SSL protocol uses the public key infrastructure for key exchange. When a client connects to an SSL-enabled Web site, that site transmits its public key certificate to the user. The user then generates a random number (called a nonce) and encrypts that using the public key contained in the Web site’s certificate. That encrypted nonce is sent to the server and used by the server to set up the session encryption key. (Since the nonce is encrypted with the server’s public key, only the server is able to determine the content of the nonce, as only the server has access to the server’s private key.) Once the key is set up, it is used with a symmetric cipher to encrypt the session contents. The default cipher for most browser-server combinations is RC4 with a 128-bit key. DES and 3DES are also commonly available, as well as variants of cryptographic algorithms that use “export-grade” 40-bit keys. While providing privacy for user communications, SSL also provides tamper resistance by implementing integrity checking of session content. A sequence number is used in the integrity check to protect against an attacker trying to replay old traffic. Figure 10.5 illustrates the overall SSL process; let’s step through it in detail. 1. The process begins with the Web Services client sending a “Hello” message to port 443 of the server hosting the Web Services server. As part of this message, the client nominates the SSL version and algorithms it wants to use for authentication, message encryption, and message integrity (SSL supports RSA, Diffie-Hellman, and Fortezza for authentication; DES,
Implementing the Information Security Triad
2. 3.
4. 5. 6.
7.
8.
9. 10. 11.
245
IDEA, RC2®, and RC4 for message encryption; and SHA and MD5® for message integrity). The client also sends a challenge string as part of the message. The Web Services server returns a “Hello” message, agreeing on the SSL version, algorithms, and key-lengths it wants to use, and a connection ID. The server sends its digital certificate to the client for inspection. The client can now verify that the server has a certificate it trusts based on the certificate authority’s (CA’s) signature on the certificate it receives using the CA’s public key. The server sends a “certificate request” to the client, requesting the client’s certificate. The server completes the setup process with a “Server Hello Done” message. The client responds by sending its digital certificate to the server. The server can now verify that the client has a certificate it trusts based on the CA’s signature on the certificate it receives using the CA’s public key. The two parties are now ready to securely communicate, right? Wrong. So far the two parties have only exchanged information that would be available in a public directory: each others’ certificates that contain their public keys. They must now exchange a set of secrets to establish their identities. The client begins this process by generating a symmetric encryption key, Sym Key 1, that only it knows, encrypts that key with the server’s public key, which it can obtain from the server’s certificate, and sends that as message A to the server. The client encrypts a piece of known plaintext, such as the original challenge string and connection ID, with its private key and sends it to the server as a “Certificate Verify” message. The client next sends a “Change Cipher Spec” message to the server, telling the server that all future messages will be encrypted. The client concludes its side of the sequence by sending a “Finished” message that is encrypted using the key, Sym Key 1, that it generated. Neither side yet trusts the other, but the elements are now in place for that to happen. The server decrypts message A, which provides a potential shared secret, the symmetric encryption key. The server decrypts the “Certificate Verify” message using the client’s public key, which establishes the client’s identity. (The client could have included the connection ID, the original challenge message, or the symmetric encryption key in its “Certificate Verify” message as a way for the server to have a second check of its identity, but it is really the client’s possession of its private key that establishes identity.) The server next sends its own “Change Cipher Spec”
246
Enterprise Web Services Security
message to the client, telling the client that all future messages will be encrypted. 12. The server concludes with its own “Finished” message, which includes the original challenge string and a session ID that is encrypted with the symmetric encryption key, Sym Key 1. The client is able to ascertain the server’s identity based on the server’s ability to decrypt message A and use the key that it contained. 13. The secure connection is now complete and the client and server can now communicate using the secret key they share. This process works because the two parties can create a shared secret, the shared symmetric encryption key, based on the CA’s signature on each party’s certificate, providing there is some level of assurance the certificate is valid and has not been altered, and on the assumption that only the owners of the certificates hold the corresponding private keys. An attacker must either obtain one of the private keys or compromise the CA.
Client Generate plaintext challenge
Messages
Server
Client Hello Server Hello
Server Certificate Verify CA Certificate Request Server Hello Done
Client Certificate Generate Sym Key 1
Message A with Sym Key 1
Verify CA Sym Key 1 becomes shared secret
Certificate Verify Client Trusted Change Cipher Spec Finished Change Cipher Spec
Finished Server Trusted Messages
Session Messages
FIGURE 10.5 The SSL authentication pattern.
Implementing the Information Security Triad
247
INTEGRITY The next element of the information security triad is assurance of integrity. Integrity checking is used to detect attempts to tamper with the content of a message when it is transmitted between partners in a transaction. We saw an example in the SSL discussion above where a CA’s digital signature was used to verify the integrity of the client and server’s certificates. While there are several ways for integrity of data to be protected, the common method is for the system to compute some sort of integrity check value that is a function of the data contents and transmit that check value with the data. The recipient recomputes the check value and rejects the data if the computed value does not match the expected check value. In most cases, this causes the sender to retransmit the original message until it is received correctly. Integrity checking is usually done using cryptographic hash functions, which will be discussed later in this chapter. Digital Signatures A problem with a simple integrity check is that while it detects errors that occur because of network failures, it cannot protect against hostile attackers. If someone wants to tamper with the content of a message, he can simply modify it, recompute the new integrity check value, and send the new message. This attack works because the integrity check algorithm is known (so that the recipient can recompute it during the check). Since everyone knows the way the integrity check is calculated, anyone can compute a valid check for an invalid message. To provide real integrity, some mechanism must be designed to allow the sender to generate a check value that anyone can verify but that nobody but the sender can generate. Digital signatures are designed to solve this problem. A digital signature uses the sender’s asymmetric key pair to protect the integrity of a message. When a user wishes to send an integrity-checked message, he computes the integrity check value of that message and then encrypts the check value with his private key. The receiver then recomputes the check value, decrypts the transmitted integrity check using the sender’s public key, and verifies the result. Since only the sender has access to his private key, nobody else can tamper with the integrity check value since they cannot encrypt the new integrity check value without the sender’s private key. Notice that the digital signature uses the key pair in reverse: if you wish to send an encrypted message to someone, you encrypt it with his public key and he decrypts it using his private key. For a signature, he encrypts it with his private key and anyone can decrypt it using their public key. A digital signature provides strong proof of origin for a message. Unlike symmetric key cryptography, where multiple parties share a single key, only one person
248
Enterprise Web Services Security
holds the private key. Other aspects of this proof of origin will be discussed later in the chapter in the section about nonrepudiation. The simplest form of digital signature is to encrypt the entire message being transmitted using the user’s private key. This provides a stronger proof that the message has not been tampered with than an integrity check value (the reasons for this will be discussed below). In practice no systems do this, for the same reason that RSA is not used for bulk encryption: the performance of public key encryption is slow enough to strongly discourage integrity checking by encryption of entire message bodies. If you think about it, you would pay a double penalty by encrypting the entire message as an integrity check. If you want to transmit a message in secret that is integrity checked, you would need to sign the message (encrypt it with your private key) and then encrypt it with the recipient’s public key. The receiver would then need to perform two additional RSA operations to decrypt and verify the message. The overhead of this is why hash algorithms are used for integrity checking. Hash Algorithms
A hash algorithm is a means of computing a message integrity check value for a given block of data. A hash is a trapdoor, or one-way, function similar to that used with Diffie-Hellman. In this case, the function is a one-way transform of the input to an output value where the inverse cannot be computed. In other words, given the hash, you cannot calculate the message that generated that hash. A hash function accepts a random-length message and computes a small integer that represents the contents of the message in compact form. Given that, multiple messages may have the same hash value. For example, if you have 500-bit plaintext messages (which means there are 2500 possible values) and only 2128 hash values, it’s clear that there are several collisions where two messages have the same hash value (2372 different messages hash to each hash value). A “good” hash has the properties that it is not feasible for someone to take advantage of these collisions by computing a message that corresponds to a given hash and it is infeasible to find two messages that have the same hash value. These properties mean that given a hash value that corresponds to a valid message, it is not feasible for an attacker to find a different message to send that matches the original message digest. The output of a hash function is called a message digest. An ideal message digest algorithm is similar to an ideal encryption algorithm. In both cases the output should appear random, with no correlation between input bits and output bits. Small changes in the input should lead to large changes in the hash (on average, a one-bit change in the input should lead to half of the output bits changing).
Implementing the Information Security Triad
249
While it is important to avoid message digest collisions, it is also important to note that these are somewhat difficult attacks to mount. It’s not likely that the messages that collide with the original message will make any sense as a new message. Gibberish is likely to result if someone were to try to reverse engineer the message text from its digest. Message digests can be used for more than integrity checking. If used with shared secret keys, they can also be used in other ways. For example, a message digest can be used as an authentication mechanism. For example, assume Alice and Bob share a secret key S. When Alice and Bob want to authenticate each other (in other words, to make sure they really are talking to each other), they can use a digest to do this. Alice starts by generating a random nonce rA and sends that to Bob. Bob appends their shared secret S to Alice’s random value, hashes that, and then returns the result. Alice can verify the hash because she knows the secret key and nonce. Bob uses the same scheme to challenge Alice using his own nonce value and verifies the result. Using this protocol, they have mutually authenticated. Message digests can also be used in what are called message authentication codes (MACs). In this case, the parties share a secret key. A message digest is computed by appending the message to the secret key to form a new message, then computing the digest. (That new message is then discarded and not transmitted; otherwise, you would be transmitting the secret key.) The resulting MAC cannot be computed by someone who does not know the secret key, thus authenticating the origin of the message. A more complex form of a MAC is called an HMAC. This involves computing the MAC of the key plus the message, then rehashing the result digest a second time along with the key. This construction is used to eliminate some potential flaws with large messages when a simple MAC is used. Digest Methods
Several hash methods have been proposed over the years. These were primarily driven by the performance problem with RSA when used to sign large messages. The two most popular digest methods used today are MD5 and SHA-1. MD5
Ron Rivest of RSA Laboratories wrote the MD5 message digest algorithm. MD5 is based on earlier derivations of his work (his first published hash was MD2®, which is documented in RFC 1319). MD2 was superseded by MD4® (RFC 1320). MD4 used 32-bit operations to improve the speed of the hash. Some potential weaknesses were found in MD4, which led to Ron Rivest creating MD5 (RFC 1321). MD5 is a block hash that works on the input in 512-bit blocks. The output is a 128-bit message digest. The algorithm uses what is called a compression function to compute the hash based on an initial hash value combined with the current 512-bit
250
Enterprise Web Services Security
block. The algorithm processes each block four times with a combination of AND, OR, shift, XOR, and rotate operations. Messages hashed using MD5 must be padded to a multiple of 512 bits. The padding is accomplished by appending a single one bit to the message, followed by enough zero bits to fill the last block so that 64 bits are left. The final 64 bits contain the length of the original message. SHA-1
The SHA family of algorithms was proposed by NIST as a standard message digest function. The original SHA algorithm was changed just before it was approved, yielding an updated algorithm that is referred to as SHA-1. SHA-1 is a block hash that is very similar to MD5. It operates on 512-bit message blocks and generates a 160-bit hash output. The algorithm uses similar functions to MD5 (shift, OR, AND, and XOR) to calculate the hash. SHA-1 padding is performed similarly to the method used by MD5. The only difference is that SHA-1 restricts the length of the original message to 264 bits (this is not a particularly serious limitation, as it would take over 100 years to calculate the hash of a 264-bit message). Nonrepudiation The description of digital signatures above concentrates on the integrity checking aspects of a signature. When you receive a signed message, you know it has not been tampered with (subject to the power of the hash function to resist such tampering, of course). If you trust the hash, you can trust that the message is intact. One gains other assurances from the signature. First, since the signature is generated using a user’s private key and verified using the user’s public key certificate, you know the identity of the sender. This provides what is called a strong binding between the message and the originator of that message. The sender cannot deny having sent it because it is signed with his private key. A signature can also contain a time stamp that denotes when the message was signed. These properties of a digital signature support what is often considered an additional information security goal, that of nonrepudiation. Nonrepudiation enforces the responsibility for sending a message by denying the sender the ability to claim to be not responsible for it (that is, it does not allow the sender to repudiate the message). Nonrepudiation is important if electronic business transactions are to replace face-to-face transactions. In an in-person transaction, the two parties see each other and sign and date a contract. Often such contract documents are attested to by a notary public who verifies the identity of the contracting parties. The notary then affixes his signature and date to the document to verify that it is valid. Attempting
Implementing the Information Security Triad
251
to repudiate a contract that is notarized is not likely to be successful. The use of digital signatures provides similar protections for online transactions by replacing the notary public with a public key certification authority that attests to the identities of the transacting parties.
SUMMARY This chapter provided details of technologies that can be used to implement confidentiality and integrity controls. Details of several cryptographic algorithms were discussed along with how they may be appropriately used in securing a Web Services environment. Most confidentiality services are built around some form of cryptography. Cryptography algorithms translate plaintext into ciphertext in a way that we hope is efficient yet difficult to break without knowledge of the keys involved. Cryptographic algorithms fall into two categories, stream and block, based on how they process the input. The algorithm uses a key that can either be a shared secret key (symmetric) or half of a public-private key (asymmetric) pair to encrypt and decrypt the text. The strength of the encryption is a function of the strength of the algorithm and the key length. We discussed some examples where a shorter key length for one algorithm may provide stronger encryption than a longer key length with another. Integrity services are built around the concepts of hash algorithms and digital signatures. Digital signatures are a form of cryptography. Algorithms and key lengths again come into play, but the challenge is different. With cryptography, an attacker’s goal is to recover the plaintext from the ciphertext by reversing the cryptographic function. With a digital signature, the goal is to hide tampering by finding an equivalent, modified message that would hash to the same result, which is very difficult.
REFERENCES [ARCFOUR] Kaukonen, K. and R. Thayer, “A Stream Cipher Encryption Algorithm ‘Arcfour.’” Available at http://www.mozilla.org/projects/security/pki/nss/ draft-kaukonen-cipher-arcfour-03.txt. [McNett99] McNett, David, “US Government’s Encryption Standard Broken in Less Than a Day.” Available online at http://www.distributed.net/des/releasedesiii.txt.
252
Enterprise Web Services Security
[NIST77] National Institutes for Standards and Technologies, Federal Information Processing Standards Publication (FIPS PUB) 46, Data Encryption Standard (DES). January 15, 1997. Superseded by FIPS PUB 46-1, 46-2, 46-3. [NIST88] National Institutes for Standards and Technologies, Data Encryption Standard (DES). FIPS Pub 46-2. Available at http://www.itl.nist.gov/fipspubs/ fip46-2.htm. [NIST99] National Institutes for Standards and Technologies, “Announcing Draft Federal Information Processing Standard (FIPS) 46-3, Data Encryption Standard (DES), and Request for Comments.” Available at http://csrc.nist.gov/ cryptval/des/fr990115.htm. [RSA78] Rivest, R.L., A. Shamir, and L.M. Adleman, “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems.” Communications of the ACM (2)21 (1978): 120–126.
11
Communicating Security Credentials
In This Chapter Client-Server Credential Communication WS-Security Summary References
n the previous two chapters, we discussed the basic processes supporting authentication, authorization, access control, confidentiality, and integrity services, the options and algorithms involved, and how Web Services clients and servers can apply them as effective countermeasures within a basic message exchange. In order to be effective, the parties must agree on the countermeasures to be applied and the consistent and appropriate application of those mechanisms. Agreement assumes communication. In Chapter 7 we looked at how the Web Services server can make its requirements known and how the client can discover those requirements. In Chapter 14 we will look at how the two parties can negotiate the specifics of how a client can meet a given requirement. For now, let’s assume there isn’t a negotiation and the Service offers several options for meeting a particular requirement. In this scenario the question becomes, how does the client convey how it has met the server’s requirements to the server? That is the subject of this chapter.
I
253
254
Enterprise Web Services Security
In this chapter, we will look at the approved and evolving Web Services standards that create the grammar and syntax for communicating security credentials and artifacts between Web Services clients and servers. Clients can use these standards to clearly communicate how they are meeting a server’s requirements and in some instances the order in which they performed certain functions. Order can be important when the server has to reverse the client’s actions in a step-by-step fashion, and the standards provide a way to unambiguously convey this information.
CLIENT-SERVER CREDENTIAL COMMUNICATION Figure 11.1 summarizes the overall discussion. A service process (authentication, confidentiality, or integrity) executing on the Web Services client obtains some set of security credentials or creates some set of security artifacts that it needs to communicate to the Web Services server. The client communicates the credentials and artifacts as part of the messages it sends to the server. Corresponding service processes executing on the Web Services server use the credentials or artifacts to determine whether to honor, ignore, or reject a request. The client and server would reverse processing roles for messages in the other direction. You will notice that additional services not present on the client (authorization and access control) execute on the server. This is because the Web Services server will normally, though
Claims
Messages
Web Services Client (requestor) N
C
Tokens
I
Web Services Server (provider)
Claims
A
C
R
I
N
N
Authentication
A
Authorization
R
Access Control
C
Confidentiality
I
Integrity
FIGURE 11.1 Web Services security key concepts.
Communicating Security Credentials
255
not necessarily, use the same credentials for authentication, authorization, and access control. If the Web Services server uses different credentials for these purposes, the client will need corresponding authentication service processes to obtain the necessary credentials. We saw in Chapter 7 how a Web Services server could communicate its requirements to the Web Services client as part of its Web Services Description Language (WSDL) or Universal Description, Discovery, and Integration (UDDI) description of the service it is providing. The server may elect to support a single type of credential or artifact for each of its security services or allow a choice among several at the client’s discretion. Whichever the case, the server should clearly communicate its options and preferences, where applicable, to the client as part of its policy expression.
WS-SECURITY Web Services Security (WS-Security) was first introduced in 2002 as part of the overall Web Services Roadmap [Roadmap02, WSSecurity02]. It has since been approved as an Organization for the Advancement of Structured Information Systems (OASIS) standard [WSSecurity04]. WS-Security specifies an abstract security model for protecting messages. WS-Security defines the header block and the rules for attaching security tokens and elements. WS-Security builds on eXtensible Markup Language (XML) Signature for message integrity and XML Encryption for message confidentiality. Message Security Model Figure 11.2 illustrates the Web Services abstract security model as defined in WSTrust [WSTrust04]. The actors in this model are a requestor, a Web Service, and an optional security token service. The Web Service indicates the claims that it requires for a service through a policy. The requestor finds the policy, determines the claims it needs, and incorporates tokens representing those claims within its service request. If the requestor does not possess the necessary claims, it can request them from an appropriate authority (a security token service). The Web Service would identify an appropriate authority as part of its policy or the two parties could come to some agreement out of band. The Web Service validates the claims and either honors or rejects the request. WS-Security provides two alternatives for including security tokens in a message. One option is to include them directly, or by value. The other option is to include a reference to the token.
256
Enterprise Web Services Security
Policy Security Token Service Token
Claims
Policy
Policy Requestor
Claims
Token
Web Service Token
Claims
FIGURE 11.2 Web Services trust model.
Security Header Element WS-Security defines the header block as a mechanism for communicating security information among the requestor, the Web Service, and any intermediary actors. The element is a Simple Object Access Protocol (SOAP) subelement as illustrated in Listing 11.1. The optional actor attribute identifies the recipient for which a security header subelement is intended. If omitted, any actor can process the entry. You can use the optional mustUnderstand attribute to indicate that they must be able to process the entry. The optional role attribute provides a way for you to indicate that an intermediary or service playing a specific role is the targeted recipient of the information. The SOAP can contain multiple elements; however, only one is permitted per actor or role and only one can omit both the actor and role attributes. The subelements within the element are specific to the security tokens being used. LISTING 11.1
The Security Element Syntax
...
Communicating Security Credentials
257
... ...
Since only one global rule (one without an actor or role attribute) and one rule per actor or role attribute is permitted, a question arises about ordering and appending information within a given block. WS-Security defines a prepending rule whereby processes creating or modifying a header block should prepend (be added to the front of) information they are adding to existing subelements to avoid creating any forward dependencies. This allows the recipients to “unwrap” the message by processing elements within a block in the order in which they appear. Including Tokens by Value
WS-Security defines several subelements for including security tokens in XML format directly in the header. In addition to these subelements, security tokens that are already in XML format, such as Security Assertion Markup Language (SAML), can also be included directly. User Name Tokens
WS-Security defines the basic subelements for including username and password values in a header. The Web Services Security Username Token Profile makes specific recommendations on using these types of tokens [Username04]. Listing 11.2 illustrates the element and its recommended subelements. The subelement contains a string value representing the requestor’s claimed identity. The subelement contains the corresponding password. The password can be in either of two forms as indicated by the optional Type attribute: #PasswordText, which is the default format, or #PasswordDigest, which is the Base-64 encoding of a digest value (note: both uniform resource identifier [URI] fragments are relative to the Username Token Profile URI). The Username Profile recommends that passwords in digest form be computed using Secure Hash Algorithm 1 (SHA1) including a nonce, a creation timestamp, and the password. The Profile adds the optional and subelements to support this recommendation.
258
Enterprise Web Services Security
LISTING 11.2
The UsernameToken Element Syntax
... ... ... ... ... ...
X.509 Certificate Tokens
WS-Security provides the element for including X.509, and other binary forms of security tokens in a header. The Web Services Security X.509 Certificate Token Profile defines the options for encoding X.509 certificates using this element [X50904]. Listing 11.3 illustrates the basic element syntax. The ValueType attribute specifies the type of binary security token included in the header, and the EncodingType attribute indicates the encoding format (Base64Binary for Base-64, HexBinary for hexadecimal encoding). The X.509 Profile identifies three ways of representing X.509 certificates: #X509v3 for an X.509v3 certificate, #X509PKIPathv1 for a certificate path reference, and #PKCS7 as an alternate way to specify a certificate path reference (note: the URI fragments are relative to the X.509 Certificate Token Profile URI). The X.509 Profile recommends the public key infrastructure (PKI) path approach for representing a certificate path reference.
Communicating Security Credentials
LISTING 11.3
259
The BinarySecurityToken Element Syntax
... ... ...
Kerberos Tokens
You also use the element to include Kerberos tokens in a header. The Web Services Security Kerberos Token Profile defines the ValueType value of #KerberosV5_AP_REQ for representing Kerberos tokens (note: the URI fragment is relative to the Kerberos Profile URI) [Kerberos04]. This value indicates that the element contains the Kerberos ticket in Base-64-encoded form in the AP (ticket + authenticator) format. Earlier versions of WS-Security permitted the direct inclusion of Kerberos ticket granting and service tickets using Kerberosv5TGT and Kerberosv5ST value type values, respectively. SAML Assertions
Since SAML statements are in XML format, the subelement can contain SAML statements directly as illustrated in Listing 11.4. The Web Services Security SAML Token Profile describes two confirmation methods for establishing the relationship between the message and the SAML assertions: holder-of-key and sender-vouches [SAMLProf04]. In the holder-of-key confirmation method, the subelement includes a element containing either a public or secret key a recipient can use to confirm the subject’s identity
260
Enterprise Web Services Security
through a corresponding digital signature, included in a element, created using that key. With the sender-vouches method, the sender must sign both the content being protected and the corresponding SAML assertion and include the and used for that purpose. LISTING 11.4
Including SAML Assertions
... ... ...
Including Tokens by Reference
WS-Security defines the element for passing security tokens by reference and three methods for expressing token references: direct, indirect, and embedded. An actor uses one of the first two methods when the token is not contained within the message itself or is in another part of the message, and the third when the reference includes the token value. Listing 11.5 illustrates the basic element’s syntax.
Communicating Security Credentials
LISTING 11.5
261
The SecurityTokenReference Element Syntax
... ... ...
WS-Security defines the wsu:Id attribute depicted on the
Direct Reference
WS-Security defines the subelement, illustrated in Listing 11.6, for creating direct token references. A direct token reference is in effect a pointer to the token. The optional URI attribute contains either a URI pointing to an external token or a URI fragment pointing to an ID within the document containing the reference. The optional ValueType attribute contains a URI that specifies the type of security token reference. The WS-Security Token Profiles define the valid token types as summarized in Table 11.1.
262
Enterprise Web Services Security
LISTING 11.6
The Reference Element Syntax
... ...
TABLE 11.1 Token Value Types for Reference Elements Profile
ValueType Value
UserName Profile
#UsernameToken
X.509 Certificate Profile
#X509v3 #X509PKIPathv1 #PKCS7
Kerberos Profile
#Kerberosv5_AP_REQ
SAML Profile
#SAMLAssertion-1.0 #SAMLAssertion-1.1 #SAMLAssertionID
The ValueType values illustrated are prefixed by the corresponding Token Profile URI.
Communicating Security Credentials
263
Indirect References
WS-Security provides two ways to indirectly reference security tokens: by key identifier and by key name. In both cases, an identifying value replaces the token itself in the reference. WS-Security recommends using the element for references because there is a one-to-one mapping between the key identifier value and the corresponding token, whereas there can be a one-to-many mapping between a key name and a set of tokens. Listing 11.7 illustrates the syntax of the element as a child to a element. The optional ValueType attribute contains a URI specifying the type of key identifier being used. The WS-Security Token Profiles define the valid token types as summarized in Table 11.2. The optional EncodingType attribute contains a URI specifying the encoding format of the value. Base-64 is the default (#Base64Binary is the base value that is relative to the WS-Security specification’s URI). LISTING 11.7
The KeyIdentifier Element Syntax
... ... ...
264
Enterprise Web Services Security
TABLE 11.2 Token Value Types for KeyIdentifier Elements Profile
ValueType Value
UserName Profile
None Defined
X.509 Certificate Profile
#X509SubjectKeyIdentifier
Kerberos Profile
#Kerberosv5_AP_REQ
SAML Profile
#SAMLAssertion-1.0 #SAMLAssertion-1.1 #SAMLAssertionID
The ValueType values illustrated are prefixed by the corresponding Token Profile URI. While WS-Security discourages the use of key name references, it does recommend that if they must be used the element conform to section 2.3 of RFC 2253, which is the Lightweight Directory Access Protocol (LDAP) guidelines for encoding attribute type and value into strings [RFC2253]. The element cannot be used for user name and Kerberos tokens. The X.509 Certificate Token Profile also recognizes XML Signature’s as a valid way to reference X.509 certificates by the issuing authority’s name and the certificate’s serial number. Embedded References
WS-Security also supports the option of embedding tokens within a reference. WSSecurity defines the subelement illustrated in Listing 11.8 for this purpose. The element contains the elements necessary to describe the token and its value. LISTING 11.8
The Embedded Element Syntax
265
Communicating Security Credentials
... ... ...
WS-Security also recognizes the use of XML Signature’s subelement for embedding key references, allowing subelements to be directly embedded within a subelement. Table 11.3 summarizes the various token reference options available. The variability is necessary because the different types of tokens and token references do not follow any common usage pattern. WS-Security’s preferred order is direct references, key identifiers, and key names, followed by embedded references. TABLE 11.3 Token Reference Summary Reference Type
UserName
X.509
Kerberos
SAML
Direct
Y
Y
Y
Y
Indirect
N
Y
Y
Y
N
Y
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Embedded
XML Encryption WS-Security builds on XML Encryption for confidentiality. XML Encryption defines the elements and processes needed for encrypting XML documents and provides options for encrypting an entire document, selected elements, or the content of selected elements [XMLEncrypt02]. This flexibility is one of the advantages WSSecurity has over point-to-point solutions such as Secure Sockets Layer (SSL).
266
Enterprise Web Services Security
XML Encryption defines an element for carrying cipher text and an element for carrying information about encryption keys. The element replaces the document root, element, or content being encrypted, depending on the level of encryption being used. XML Encryption supports a number of block cipher algorithms including Data Encryption Standard (DES), Rivest, Shamir, and Adleman (RSA), and Advanced Encryption Standard (AES). XML Encryption supports superencryption, that is, encrypting data multiple times to strengthen the encryption; however, elements cannot be nested. To superencrypt an element, the element must be encrypted in its entirety, which creates an element, which then must be encrypted in its entirety again using element encryption in order to create a superencrypted element. The and elements are built from the same basic abstract element model, so they have the same child elements: , , , and as illustrated in Listing 11.9 for the element. LISTING 11.9
The EncryptedData Element Syntax
... ... ...
The subelement identifies the encryption algorithm, in the form of a URI, used to encrypt the information contained within the encapsulating or element. XML Encryption includes algorithms for block encryption, key wrapping, key exchange, and hashing as shown in Table 11.4. While XML Encryption does not provide for stream encryption algorithms, it is extensible for this support, provided both the Web Services client and server agree on the algorithm and its usage.
Communicating Security Credentials
267
TABLE 11.4 XML Encryption Algorithms Category
Name
URI
Block
Triple DES
http://www.w3.org/2001/04/xmlenc#tripledes-cbc
AES-128
http://www.w3.org/2001/04/xmlenc#aes128-cbc
AES-256
http://www.w3.org/2001/04/xmlenc#aes256-cbc
AES-192
http://www.w3.org/2001/04/xmlenc#aes192-cbc
Stream
None
Key transport
RSA v1.5
http://www.w3.org/2001/04/xmlenc#rsa-1_5
RSA OAEP
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgflp
Key agreement
Diffie-Hellman
http://www.w3.org/2001/04/xmlenc#dh
Key wrap
Triple DES
http://www.w3.org/2001/04/xmlenc#kw-tripledes
AES-128
http://www.w3.org/2001/04/xmlenc#kw-aes128
AES-256
http://www.w3.org/2001/04/xmlenc#kw-aes256
AES-192
http://www.w3.org/2001/04/xmlenc#kw-aes192
SHA 1
http://www.w3.org/2001/04/xmlenc#sha1
SHA 256
http://www.w3.org/2001/04/xmlenc#sha256
SHA 512
http://www.w3.org/2001/04/xmlenc#sha512
RIPEMD
http://www.w3.org/2001/04/xmlenc#ripemd160
Message digest
The subelement contains information about the key that was used to perform the encryption in terms of a: :
an element referring to a element elsewhere in the document : an element containing the public key : an element containing a link to an element within the document : an element describing the key : an element that can be used to derive the shared secret using a method determined by a key agreement algorithm The subelement contains the cipher text, either in the form of a where the cipher text is carried as content, or a ,
,
268
Enterprise Web Services Security
where a URI points to the data. The element can include a series of transforms for processing the cipher text during the decryption process. The element can carry additional information about the encryption such as the date and time or serial number of the devices used to perform the encryption. In addition to the elements above, the element can contain two additional child elements as shown in Listing 11.10. The element identifies the encrypted objects within the document that were encrypted with the key. The element can contain child elements to point to entries or child elements to point to entries. The element associates a user-readable name with a key. The elements within one or more structures can reference this name. This provides a second means by which multiple structures can point to the same key. The same element value can also occur in multiple structures. This provides a simple mechanism for providing an encryption key, encrypted with different values, to multiple services. Each service can have its own structure, each having the same , using the recipient attribute on the element to identify the application. LISTING 11.10
The EncryptedKey Element Syntax
... ... ... ...
In order to pull these concepts together, let’s look at an example. Listing 11.11 shows a simple XML document containing some financial detail. There are several different strategies for encrypting the information in this file. If the objective is to protect all the information in the file, it can be encrypted at the file level as shown in Listing 11.12. The element becomes the root element to the
Communicating Security Credentials
269
document, the encrypted data has the “text/xml” multimedia Internet mail extension (MIME) type, and the cipher text is included in the element. The element indicates that the Triple DES algorithm was used to perform the encryption. The element provides a name to be used to identify the key used to perform the encryption; presumably it is something known to both the Web Services client and server. If the goal were changed to protecting only the account information, element-level encryption, as shown in Listing 11.13, could be used. The element replaces the element in the XML document. The Type attribute on the element signifies encryption at the element level by referencing the #Element anchor point in the XML namespace. In this example, the AES algorithm was used to encrypt the data. Finally, if the goal were changed to protecting only the account number, contentlevel encryption, as shown in Listing 11.14, could be used. In this case, the element replaces the content of the element. The Type attribute on the element now points to the #Content anchor point in the XML namespace. The document in this example does not include any information about the encryption algorithm or the key used in encrypting the document. The implication is that the sender and receiver have either agreed on an encryption algorithm and key or that information is being exchanged out of band—outside the document itself. LISTING 11.11
Sample XML Document
John Q. Doe First Bank and Trust 2394 8743 2901 1734 $50,000
LISTING 11.12
Document-Level Encryption
Payment Methods
270
Enterprise Web Services Security
AB359631
LISTING 11.13
Element-Level Encryption
John Q. Doe First Bank and Trust Payment Methods 3417BC91 $50,000
LISTING 11.14
Content-Level Encryption
John Q. Doe First Bank and Trust 4678CD13 $50,000
Communicating Security Credentials
271
XML Signature WS-Security builds on XML Signature for message integrity. A digital signature is created in a two-step process as shown in Figure 11.3. The first step processes the document to be signed through a secure hash function, such as the Secure Hash Algorithm (SHA), to create a message digest, which is a digital fingerprint of the document. The second step encrypts the message digest, using the sender’s private encryption key, to create a digital signature. The digital signature is then appended to the document.
Document or Element(s) to be Signed
Hash Function
Message Digest
Signature Creation
Digital Signature
Private Encryption Key
FIGURE 11.3 Digital signature creation process.
The message recipient reverses the process as illustrated in Figure 11.4. First, the recipient performs the same process the sender used to create a message digest. The message digest the recipient created is fed into a verification function along with the digital signature created by the sender and the sender’s public encryption key. The public key may come from a central directory service or certificate authority (CA), may be part of a certificate attached to the document being verified, or may be obtained from the sender using a key exchange process such as DiffieHellman or RSA key exchange. The verification function decrypts the signature, using the sender’s public key, compares the message digest from the signature with the one that was generated, and based on that comparison, determines whether the signature is valid and whether the document has been changed since it was signed. XML Signature extends the XML language to support digital signatures in a uniform way [XMLSig02]. XML Signature adds the elements shown in Listing 11.15 to the XML document.
272
Enterprise Web Services Security
Digital Signature
Signed Document or Element(s)
Hash Function
Message Digest
Signature Creation
Valid Digital Signature Yes or No?
Public Encryption Key
FIGURE 11.4 Digital signature verification process.
LISTING 11.15
XML Signature Elements
... ... ... ... ... ... ...
Communicating Security Credentials
273
The element encapsulates the XML digital signature information for a document. The structure is made of up to four parts: information about how the signature was generated, the signature itself, information about the key that was used in generating the signature, and optional objects that were included in creating the signature or additional information about how the document was signed. The element encapsulates information about how the signature was generated. Three child elements come into play in describing the process. The canonicalization method is the canonicalization, or standard serialization, algorithm used to convert the document into standard form prior to its being processed to create a message digest. The Exclusive XML Canonicalization recommendation specifies Canonical XML (XML-C14N) as the standard serialization technique [EXCC14N, XMLC14N]. The element’s algorithm attribute identifies the serialization algorithm used via one of the canonicalization URIs shown in Table 11.5.
TABLE 11.5 XML Signature Algorithms Category Message digest
Canonicalization
MAC
Name
URI
SHA 1
http://www.w3.org/2001/04/xmlenc#sha1
SHA 256
http://www.w3.org/2001/04/xmlenc#sha256
SHA 512
http://www.w3.org/2001/04/xmlenc#sha512
RIPEMD
http://www.w3.org/2001/04/xmlenc#ripemd160
Canonical XML
http://www.w3.org/2001/ REC-xml-cl4n-20010315
With comments
http://www.w3.org/2001/ REC-xml-cl4n-20010315#WithComments
Exclusive XML
http://www.w3.org/2001/10/xml-exc-c14n
With comments
http://www.w3.org/2001/10/xml-excc14n#WithComments
HMAC/SHA1
http://www.w3.org/TR/2001/09/ xmldsig#hmac-sha1
q
274
Enterprise Web Services Security
Category
Name
URI
Reference type
Object
http://www.w3.org/TR/2001/09/ xmldsig#Object
Manifest
http://www.w3.org/TR/2001/09/ xmldsig#Manifest
Properties
http://www.w3.org/TR/2001/09/ xmldsig#SignatureProperties
DSA
http://www.w3.org/TR/2001/09/ xmldsig#DSAKeyValue
RSA
http://www.w3.org/TR/2001/09/ xmldsig#RSAKeyValue
X509
http://www.w3.org/TR/2001/09/ xmldsig#X509Data
PGP
http://www.w3.org/TR/2001/09/ xmldsig#PGPData
PKI
http://www.w3.org/TR/2001/09/ xmldsig#SPKIData
Mgmt
http://www.w3.org/TR/2001/09/ xmldsig#MgmtData
DSA/SHA1
http://www.w3.org/TR/2001/09/ xmldsig#dsa-sha1
RSA/SHA1
http://www.w3.org/TR/2001/09/ xmldsig#rsa-sha1
XPath filter
http://www.w3.org/2002/06/ xmldsig-filter2
XSL transform
http://www.w3.org/1999/XSL/Transform
Decrypt XML
http://www.w3.org/2002/07/ decrypt#XML
Decrypt binary
http://www.w3.org/2002/07/ decrypt#binary
Env signature
http://www.w3.org/2000/09/ xmldsig#enveloped-signature
Normalization
http://www.w3.org/TR/2003/NOTE-soap12-n11n-20030328/
Dereference
http://www.docs.oasis-open.org/wss/ 2004/01/oasis-200401-wss-soapmessage-security-1.0#STR-Transform
Base-64
http://www.w3.org/2000/09/ xmldsig#base64
Retrieval method
Signature
Transformation
Encoding
Communicating Security Credentials
275
The element identifies the algorithm(s) used to generate the signature via its Algorithm attribute, which is also in the form of a URI taken from the list of signature algorithms shown in Table 11.5. The signature algorithm has two components: one reflecting the algorithm used to create the message digest, the other reflecting how the signature was encrypted. The element identifies the digest algorithm, value, and any other transforms applied in generating the digital signature. The URI and Type attributes on the element provide additional information about the object that was signed. The URI may point to an object, a set of signature properties, or a manifest. The Type attribute indicates the kind of reference using one of the reference type URIs from Table 11.5. The element identifies the step-by-step transforms performed to create the message digest as an ordered set of elements. Each element points to a specific transform via its Algorithm attribute, which is one of the transformation URIs from Table 11.5. The input to the first transform is the dereferenced object the URI attribute points to on the element; the input to subsequent transforms is the output from the transform preceding it. The output from the last transform is input to the message digest algorithm. The element’s Algorithm attribute identifies the method used to generate the message digest using one of the message digest algorithms from Table 11.5. The element contains the hashed message digest as a Base-64encoded value. The element contains the digital signature value. The digital signature is also represented as a Base-64-encoded value. The element contains information about the key that was used in generating the signature. This information may be provided in terms of a key name, a key value, or a method for retrieving the key. The element provides an identifier that the recipient can use to retrieve the key that was used. The recipient must understand what the value represents and how to transform that information into a specific key in order to correctly decrypt the digital signature. The element contains the actual key value in either a or element, depending on the algorithm used. The element provides a link to the key information. The element uses the same format as the element, except that there are no or child elements. Instead, the element contains a reference to the key, and its URI attribute indicates the key format using one of the retrieval method URIs from Table 11.5. The element is an optional element that can include any MIME data that was used in creating the digital signature. The Encoding and MIME attributes indicate how the data is encoded and its MIME type.
276
Enterprise Web Services Security
The element, which is an optional child element to the element, contains a list of references, as elements, to aid in processing multiple objects. The element can be used to reserve reference validation decisions to the application by showing the separate objects and how they were processed in formulating the final signature. The element is an optional element that can provide additional information about how the digital signature was created. Information that might be included in this element includes the date and time the signature was generated and the serial number of the hardware that was used. A number of different transforms can be applied to a document in creating the message digest or encrypting either the signature or the document. Documents can also be encrypted after signatures have been applied. In addition to the canonicalization transform discussed above, other frequently used transforms include Base64 decoding, XPATH filtering [XPATHF02], XSL transformation, and decryption [Hughes02]. The decryption transform provides both XML and binary options; it also defines an child element to the element that can be used to exclude sections of the document from the decryption process. Table 11.5 lists the valid transformation URIs. WS-Security recommends against using the enveloped signature transform because of the mutability of the message header by intermediaries during their processing of the document. Elements should be explicitly included instead. Message Protection WS-Security makes several recommendations about combining WS-Security, XML Signature, and XML Encryption elements for specific purposes with the goal of improving both confidentiality and integrity. WS-Security recommends using encryption for protecting message content from being intercepted and digital signatures for ensuring that messages have not been modified and for verifying the sender’s identity. Several of WS-Security’s recommendations in this context include: Recipients should reject messages with invalid, missing, or incomplete claims. Recipients should not process undefined elements in the header. ID references should be used instead of more general references such as XPATH when signing documents. The element should be used to carry key materials instead of elements for keys carrying binary data. The element should be included inside elements when using XML Signature and XML Encryption.
Communicating Security Credentials
277
The element should be used for creating token references when direct references are not used. Exclusive XML Canconicalization should be used for message canonicalization. Elements should be signed and explicitly included, and care should be exercised in encrypting and signing elements that intermediaries must process. elements should be used in conjunction with elements to create manifests in situations where multiple elements are being encrypted, where elements are being used to encrypt cryptographic key information, and where is being used to encrypt the data itself.
Putting It Together: An Example Now that we have described the major elements making up WS-Security, let’s look at an example that includes components for authentication, confidentiality, and integrity. Listing 11.16 illustrates a message that includes all three elements. It includes an X.509 token encoded in Base-64 format that the recipient can use to authenticate the sender’s identity and also for any authorization or access control decisions that must be made. To ensure confidentiality, the sender encrypted the message using the AES algorithm. The message includes an element carrying the encryption key that was used. The element identifies the key that was used to encrypt the AES key value to ensure the confidentiality of the key exchange. The subelement shows the elements encrypted using the key, in this case the . To ensure integrity, the sender also signed the message body using RSA over SHA1 so that the recipient could verify its authenticity. The exclusive canonicalization algorithm was used to canonicalize the signed elements, and SHA1 was used to compute the included message digest value. The sender signed the message using the X.509 key included in the element. The element contains the value created as part of the encryption process. The order in which the encryption and signature elements appear within the header is important. Based on WS-Security’s prepending rule, the sender in this example signed the message before encrypting it. The and elements would be reversed if the sender had encrypted the message before signing it. LISTING 11.16
WS-Security Example
WKlr689E... DK43HJ15... CN=XYZ Inc., C=US
Communicating Security Credentials
279
ABfgktRe... KlMwrSXf... AC761196...
SUMMARY WS-Security creates the basic framework for communicating security credentials. It provides the syntax for defining security headers as part of the SOAP message header and for including tokens both directly and by reference. WS-Security supports both traditional tokens and mechanisms such as user names and X.509 certificates and emerging standards such as SAML. WS-Security builds on XML Encryption for message confidentiality and on XML Signature for message integrity. In this chapter, we looked in detail at the grammar and syntax of the WS-Security, XML Encryption, and XML Signature elements and how they can be used in a Web Services environment. An important point to remember is that these standards help communicate the result of a process or service conveying either what was done or the output product. They build on the traditional information security capabilities we discussed in Chapters 9 and 10 for performing the action.
280
Enterprise Web Services Security
REFERENCES [EXCC14N] Boyer, John, et al., “Exclusive XML Canonicalization Version 1.0.” Available online at http://www.w3.org/tr/xml-exc-c14n, July 18, 2002. [Hughes02] Hughes, Merlin, et al., “Decryption Transform for XML Signature.” Available online at http://www.w3.org/tr/xmlenc-decrypt, August 2, 2002. [Kerberos04] Nadalin, Anthony, et al., “Web Services Security Kerberos Token Profile 1.0, Working Draft 05.” Available online at http://www.oasis-open.org/ committees/download.php/8266/oasis-xxxxxx-wss-kerberos-token-profile1%200.pdf, July 27, 2004. [RFC2253] Wahl, M., et al., “Lightweight Directory Access Protocol (v3):UTF-8 String Representation of Distinguished Names.” Available online at http:// www.ietf.org/rfc/rfc2253.txt, December 1997. [Roadmap02] IBM Corporation and Microsoft Corporation, “Security in a Web Services World: A Proposed Architecture and Roadmap: A Joint White Paper from IBM Corporation and Microsoft Corporation.” Version 1.0. Available online at http://www-106.ibm.com/developerworks/webservices/library/ ws-secmap, April 7, 2002. [SAMLProf04] Hallam-Baker, Phillip, et al., “Web Services Security: SAML Token Profile Working Draft 15.” Available online at http://docs.oasis-open.org/ wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf, July 19, 2004. [Username04] Nadalin, Anthony, et al., “Web Services Security Username Token Profile 1.0.” Available online at http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-username-token-profile-1.0.pdf, March 15, 2004. [WSSecurity02] Atkinson, Bob, et al., “Web Services Security (WS-Security) Version 1.0.” Available online at http://www-106.ibm.com/developerworks/webservices/ library/ws-secure/, April 5, 2002. [WSSecurity04] Nadalin, Anthony, et al., “Web Services Security: SOAP Message Security 1.0 (WS-Security 2004).” Available online at http://docs.oasis-open. org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf, March 15, 2004. [WSTrust04] Anderson, Steve, et al., “Web Services Trust Language (WS-Trust) Version 1.1.” Available online at http://www-106.ibm.com/developerworks/ library/ws-trust/, May 2004. [X50904] Hallam-Baker, Phillip, et al., “Web Services Security X.509 Certificate Token Profile 1.0.” Available online at http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0.pdf, March 15, 2004. [XMLC14N] Boyer, John, et al., “Canonical XML Version 1.0, W3C Recommendation.” Available online at http://www.w3.org/TR/xml-c14n, March 15, 2001.
Communicating Security Credentials
281
[XMLEncrypt02] Eastlake, Donald, et al., “XML Encryption Syntax and Processing.” Available online at http://www.w3.org/tr/xmlenc-core, August 2, 2002. [XMLSig02] Eastlake, Donald, et al., “XML Signature Syntax and Processing.” Available online at http://www.w3.org/tr/xmldsig-core, February 12, 2002. [XPATHF02] Boyer, John, et al., “XML-Signature XPATH Filter 2.0.” Available online at http://www.w3.org/tr/xmldsig-filter2, July 18, 2002.
This page intentionally left blank
12
Audit
In This Chapter Goal of Audit What to Audit Auditable Events Audit Information Levels of Audit Active versus Passive Auditing Audit Data Processing Intrusion Detection and Prevention Systems Summary References
ver the previous four chapters, we have discussed how an enterprise can proactively protect itself and its Web Services from attack. We concentrated on how to protect systems, networks, and services against threats by using the CIA triad to help identify what countermeasures need to be put in place to ensure that the confidentiality, integrity, and availability of your information, systems, networks, and services is not compromised. Unfortunately, no system is absolutely secure, meaning that with enough time and effort, a persistent and skilled attacker will eventually breach your security. In this chapter we turn our attention to the equally important subjects of detecting attacks once they are underway and recovering from those attacks. This is an often-overlooked part of an enterprise’s overall security strategy, where the basic risk-cost tradeoff may not meet the threshold for implementing countermeasures against a specific threat. However, there is a third way that offers a less costly way of mitigating against the
O
283
284
Enterprise Web Services Security
attack. This chapter discusses an important set of tools that can be used when security controls for a system fail: the audit and intrusion detection and protection systems.
GOAL OF AUDIT An audit trail, or audit log, for a system contains a record of all operations the system performed. The goal of creating and maintaining the audit trail is to be able to reconstruct exactly what happened when a system was attacked so that the extent of the damage can be determined. Audit trails are also used to help determine what went wrong if the system malfunctioned for other reasons, such as software bugs or hardware failures. To be effective, an audit trail should maintain records of all operations performed by the system. A good audit trail maintains a record of all of the details of each transaction so the integrity of the underlying data can be verified. This level of detail is necessary if a database becomes inconsistent and must be reconciled to correct lost, missing, or corrupt transactions. A good audit trail also maintains the information in such a way that the audit trail itself is not easily compromised. Unfortunately, many systems do not maintain complete audit records. This means the system owners cannot tell what happened when some unexpected event occurs. The typical reasons for not maintaining good audit trails are that they are additional overhead, slowing the system down, and that they consume extra disk space. If the audit trail is very rarely used (which is usually the case), it is sometimes difficult to justify the overhead and storage cost.
WHAT TO AUDIT Auditing is a forensic tool and as such is only as good as the information available at the time a security breach is suspected or a compromise is detected. The security event may be an active attack against either the network or a server or a passive attack against a particular communications channel. It is generally too late once an event has been detected to determine the auditing strategy; by that time an infrastructure or data compromise has already occurred and the goal has changed to closing the security breech and conducting a damage assessment, which may involve collecting information necessary to prosecute either a civil or criminal action.
Audit
285
The answers to four basic questions drive an enterprise’s auditing strategy: What events need to be audited? What information needs to be captured as part of the audit trail for that event? At what level is that information available in the detail, or format, needed? Are tools available to permit passive auditing or must services and applications be instrumented to actively record audit information?
AUDITABLE EVENTS An auditable event is generally any event where a person or process accesses or changes a controlled object. A controlled object is anything you would consider placing either authorization or access controls against. Controlled objects include: Networks Systems Services Processes Files Databases Database items Auditable events involving these objects include: Authentication Authorization Access control Interprocess or interservice communications Input/output events Covert channel Process execution Data creation, update, deletion, and access Access administration Network, system, services, or data administration and configuration changes Hardware, software, and network configuration management
286
Enterprise Web Services Security
AUDIT INFORMATION The information that needs to be captured regarding any event normally revolves around answering the questions of who, what, when, where, and how as part of a possible postmortem. An audit must balance the number of events monitored and the amount of information captured about each event against performance. Monitoring too many events or capturing too much information about each event can result in slowed performance or large audit logs. Not capturing enough information about an event or not auditing the right events can make it difficult to map events to responsible users and processes and to detect or assess attacks against the system. Information that should be captured in the audit log about an event includes: The date and time the event occurred The event or action being taken The identity of the user or process performing the event The event’s outcome The object’s name The object’s type The object’s security level In the case of data, before and after images of the affected data object Space limitations and whether logs are being overwritten or archived frequently determine how much auditing information may be available for performing a damage assessment. Another concern is that processing large audit logs may be very slow if the files are not frequently “rotated” so that new log files are opened periodically. Searching for the cause of an event that occurs on a particular day is much easier to do if the log file being searched only covers events from that day and harder if the log file covers long time periods.
LEVELS OF AUDIT Audit trails can be recorded at several levels in the infrastructure. One advantage of doing this is that audit logs recorded by different systems can be correlated to help verify that the log records are correct and consistent. In Chapter 9 we discussed the pros and cons of various authorization and access control decisions points. Much of that discussion applies to the discussion of audit decision points. The key drivers in the audit discussion are where the right information is available for an event and how that information is most easily
Audit
287
captured. As Figure 12.1 illustrates, it is possible to capture audit information about different objects at different levels. As in the case of access control, it is generally best to capture audit information at the lowest point, where both the event and object are identifiable as entities at the right level of granularity. For example, you can capture messaging events at either the network or Web Services level. The network logs, however, may only show the IP address of the partners involved in the exchange. If it is important to know the identities of the parties, the only option may be to capture the audit record at the service level.
Network Objects
Request
Web Service
Services Objects
Client Response
DBMS
Database Objects
Operating System
Process and File Objects
Database
FIGURE 12.1 Possible audit points.
Network Network logs are typically recorded by firewalls and guards. In many cases these logs are very detailed and provide start time, finish time, source and destination IP, and protocol type details for every transaction that passes through the firewall or guard. Even routers can provide some level of detail if they are configured to do so. Usually routers send their audit trail data to a centralized logging server, as they do not have storage capacity for large amounts of log data. For studying the methodology and source of external attacks (those from outside your network), the best source of audit information will come from the firewall systems. Network administrators should be encouraged to log as much information as is practical and to retain the audit logs for a reasonable period of time. One
288
Enterprise Web Services Security
common recommendation is to store a month’s worth of audit data. This may be impractical for a high bandwidth firewall simply because of the sheer volume of audit data logged, but you should strive to retain as much detailed log information as you can. Server Server logs are frequently a better source of audit information than network logs. This is because some events on the servers aren’t visible elsewhere. For example, user logins, what applications a user starts, and what files the user accesses are all best audited on the server systems. Many of the same performance and disk capacity concerns found with network auditing also exist on the server systems. What events can be audited is often determined by disk space and system performance constraints. Another problem is that some systems do not have very complete auditing systems. While Windows systems can generate audit records for any action where a permission decision is performed, UNIX systems generally do not have this same level of flexibility. On the other hand, Windows does not generate audit records unless the configuration is changed, while UNIX systems generally audit important events (login, logout, and login failures) in their default configuration. Components Audit logs generated by system components add another level of detail to server and network logs. This is because these components have information that the server operating system does not. Specifically, these logs can tell why a user opened a file, what changes the user made to that file, and why. None of this detail is available at the operating system level, as it only has visibility to the file access operation; only the application knows what the user is doing with that file (or other protected object). While these lower-level audit records have additional detail, they may consume more resources (system CPU and disk space). At each audit point, the amount of detail at each level must be appropriately chosen to avoid interference with normal system operation. The following sections describe ways in which additional audit data can be generated by application logs and how that information may be used. Database
A database audit log generally records significant events: New tables being created Tables being dropped (deleted)
Audit
289
User account creation or deletion User login failures Other database events that can be logged include: User logins (database connections) Table modifications Database row insertions View, stored procedure, and rollback segment creation Query, update, and delete operations Audit records may be stored in a database table or in an external file, depending on the database product being used [ORA98] Middleware
Middleware components can also generate audit records that can be used to trace operations performed by a user. From a Web Services perspective, this usually means that a middleware component should record all Simple Object Access Protocol (SOAP) transactions generated on behalf of a service user. These audit records would record what services are involved in each transaction, what actions are being performed on behalf of the user, and potentially the contents of SOAP transaction details. The credentials used to authenticate the user’s access should be included in the audit log. The log should also record transaction success and failure, including any error messages generated by SOAP requests. Web Server
All Web servers generate access logs of some format. There is a standard World Wide Web Consortium (W3C) format for server logs that record Web server access request information including the IP address of the requester, the page being referenced, and a success or failure indication [W3Clog]. The Web server logs provide another detailed view of the processing of user requests. Web servers may also log accesses to back-end database servers. These log records provide a means of cross-referencing middleware, operating system, and back-end audit logs. Application The most detailed logs are those maintained by applications, as these have the best information about the details of user requests. While the potential exists for applications to create very detailed audit records, most application developers do not bother with implementing even basic audit records beyond simple logging.
290
Enterprise Web Services Security
There are several options for capturing audit information at the applications level. One is to define a general audit function that services can call in-line to write audit records to an audit log. Another is to use callback functions tied to the Documents Object Model (DOM) processing Web Services messages to “trap” events and write them to a log. A third option is to use notification messages to send audit information to an audit service. As Figure 12.2 illustrates, the ultimate goal, regardless of how or where the information is captured, is to write that information to the log in a secure way to prevent intruders from altering the logs to hide their activity. XML Document
... ... ...
3 Message Web Service
DOM Parser
Audit Listener
Audit Service
2
1 Variables
Audit API Audit Record
Encryption Function
FIGURE 12.2 Capturing audit information at the applications level.
For the callback option, XML Events provides the XML extensions for wiring event listeners and handlers into the DOM infrastructure through an XML interface [XMLEvents03]. Specifically, XML Events provides the syntactic and semantic extensions needed to
Audit
291
Create event handlers and listener elements in XML documents Identify elements within XML documents where event listeners or handlers are to be attached Map event listeners on nodes, or subtrees, of the DOM tree corresponding to the document Tie event listeners or handlers to an event propagation phase Control the action taken, regarding further event propagation or action cancellation, following handler execution XML Events defines an event as an asynchronous occurrence tied to an element in an XML document such as the security header elements in a SOAP message. The event target is the element where the event occurred. An observer is any element in the path extending from the root node of the document to the target element. The DOM processor propagates events by passing them down the document tree from the root node to the target element and back up again using a three-phase (capture, target, bubbling) process. XML Events allows event listeners to be connected to any of the nodes along a path by either defining elements and associating them with one or more of the nodes using ID attributes or adding event attributes, defined in the XML Events namespace, to the document elements themselves. The XML Events syntax allows listeners to be defined for any of the three phases. The event listeners can act on, stop propagation for, or cancel the default action associated with any of the events they handle. In the case of audit, the event listener can capture audit information from elements contained within messages and write it to the audit log. Listing 12.1 illustrates a element within the context of a header element and its associated attributes. LISTING 12.1
XML Event Syntax
... ... ...
ACTIVE VERSUS PASSIVE AUDITING Many products today can be configured to automatically capture audit information. This type of passive auditing is generally more reliable and consistent then active auditing, which depends on services consistently defining events and writing an audit record at appropriate audit points. Web Services Distributed Management (WSDM) identifies auditing as part of service manageability. The WSDM Management Using Web Services (MUWS) specification defines how services provide manageability interfaces, and the WSDM Management of Web Services (MOWS) specification defines how to use those interfaces to manage, and audit, Web Services [MOWS04, MUWS04]. MUWS describes services and endpoints in terms of properties, operations, and events. MUWS defines properties in terms of global element declarations (GEDs) that describe the semantics, cardinality, and relevant metadata associated with each exposed property. MUWS uses WSDL to describe operations in terms of their porttype, semantics, and their metadata. MUWS uses the endpoint reference construct defined in WS-Addressing for identifying and recording information about endpoints. MUWS defines events in terms of topics and GEDs, where the combination of the topic and message content element uniquely identify the event. WSDM-
Audit
293
based products can provide passive auditing of Web Services message exchanges based on these constructs.
AUDIT DATA PROCESSING The emphasis so far in this chapter has been on generation and storage of detailed audit records. The rationale for detailed auditing is that you may not have prior knowledge of what information is necessary to reconstruct events during a security incident. The problem with such detailed logging is that significant events can be lost in the noise when one or two significant audit records are buried in tens of thousands of routine events. Audit processing tools are an absolute necessity if the administrators are going to be able to make daily use of the audit log. The primary tools for audit processing are audit reduction tools. An audit reduction tool processes an audit log and filters out routine or expected events and displays those that aren’t expected. A log viewer can also provide a statistical view of log events. For example, the tool may provide a summary count of the number of accesses to a particular application, file, or Web site. This processing allows an administrator to quickly view the details of the log and find events that are out of the ordinary. Many UNIX administrators use a simple search tool that rejects all records that match patterns that are known to be routine (using grep –v –f pattern-file). This allows the two goals of recording all available information for later forensic analysis while providing a small summary that can be easily reviewed by the administrator. Following an attack, some of the information administrators need to quickly gather includes: Anomalous system log entries Changes to critical system files Audit record correlations to develop a picture of what has occurred Scanning tools can help identify vulnerabilities, configuration changes, and network and system configurations as part of this analysis. Another source of information that may be useful in diagnosing the source of an attack is information gathered from network vulnerability scanning tools. Freely available tools can be used to probe a system to search for vulnerabilities. Ideally these will be used before an attacker uses them so any of the discovered vulnerabilities can be corrected, but they may be useful during the investigation of an incident to help determine what methods an attacker may have used.
294
Enterprise Web Services Security
The Network Mapper (NMAP), for example, is an open source utility that uses raw IP packets to identify a number of the details of systems on a network being scanned [NMAP04]. These details include: Which hosts are reachable from the scanning system What network services are offered by the systems tested What operating system type and version is being used What packet filtering or firewall rules are in use to protect those systems Argus™ provides a generic UNIX IP transaction auditing tool developed by Carnegie Mellon University’s Software Engineering Institute that is capable of categorizing IP packets based on Boolean expressions that can be used to filter and isolate traffic [Argus]. Tcptrace is another UNIX utility, developed at Ohio State University, that can be used to analyze network connections based on audit logs produced by systems such as tcpdump, snoop, etherpeek, Win Dump, and HP NetMetrix® [TCPTrace]. These tools can be combined with graphical and network analysis tools such as Netmap and Analysts Notebook® to create link and timeline diagrams to help identify suspicious connections and activity [AnalystsNotebook, Netmap]. The Tripwire® change auditing system, which is available for both UNIX and Windows systems, is a useful tool for identifying altered system files across servers and network devices [Tripwire].
INTRUSION DETECTION AND PREVENTION SYSTEMS The discussion thus far has focused on creating audit logs with an eye toward a systems or security administrator being able to review those logs to detect an intrusion or in the case of a postmortem to identify the perpetrator. Intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) try to automate this process. (Sometimes the name intrusion protection system is used for IPS.) Free and commercial products are available that gather system details dynamically, or use those captured in audit logs, in order to provide closer to real-time IDS or IPS capabilities than an administrator, no matter how conscientious, can provide. Prelude, for example, is an open source IDS that is able to find traces of malicious activity from different sensors such as Snort, honeyd, Samhain, and over 30 types of systems logs [Prelude, Snort]. These types of scanning and IDS tools can be used to create an accurate record of the configuration state that is frequently necessary when interpreting audit results or using them in a postmortem.
Audit
295
Intrusion Detection System Basics An IDS monitors events occurring within systems, the network, or services in order to detect signs of an intrusion. An intrusion is an attempt to compromise or circumvent the system’s overall security mechanisms. The IDS works by Collecting Data: The IDS may deal directly with network and system devices and processes to capture events in real time or process those systems audit logs in order to identify appropriate events. WSDM will help define Web Services–specific auditable events that can be used as part of this process. Reducing and Analyzing that Data: The IDS must reduce this information to identify suspicious transactions or behavior patterns. The IDS may accomplish this by looking either for predefined events or patterns (attack signatures) or for abnormal patterns (anomalous behavior). Generating Alerts or an Appropriate Response: Once the IDS detects suspicious activity, it generates a response, which may be notifying an administrator (a passive response) or automated intervention (an active response). IDS systems come in three basic varities: Host Based: Host-based IDSs monitor a specific system or set of systems. Network Based: Network-based IDSs capture and analyze network traffic and when strategically placed can monitor relatively large networks. Applications Based: Applications-based IDSs are tuned for the specific set of events created by a specific type of application such as a Web server, a middleware server, a database server, or Web Services transactions. Signature-based systems are generally better than anomaly-based systems because the former are looking for specific patterns and therefore generate fewer false positives. Intrusion Prevention Systems IPSs are considered by many to be the next generation of IDS. In reality, IPSs have many of the features previously seen in proxy-based firewall systems. In theory, an IPS combines an IDS with network components in an attempt to not only detect, but to automatically respond to intrusions. One of the major differences between an IDS and an IPS is that the IPS integrates the intelligence and the knowledge of the network necessary to not only detect an attack, but to send commands to the network devices to try to automatically respond to that attack by terminating or rerouting connections, devices, and traffic.
296
Enterprise Web Services Security
SUMMARY We have covered the reasons for storing detailed application logs and where those log files may be generated. We briefly discussed tools for audit log processing as well. The ability to conduct a comprehensive postmortem following an attack or a data compromise depends on auditing the right events at the right levels and capturing the appropriate audit information. We also briefly discussed proactive mechanisms such as IDS and IPS that can provide earlier and more consistent detection of intrusions and probes. Auditing, IDS, and IPS support and enhance the proactive security mechanisms discussed in earlier chapters. While they can help close some of the gaps, they are not a substitute for those mechanisms.
REFERENCES [AnalystsNotebook] Investigative Analysis Software, Analysts Notebook homepage. Available online at http://www.i2inc.com. [Argus] QoSient, LLC. Argus homepage. Available online at http://www.qosient. com/argus/index.htm. [MOWS04] Sedukhin, Igor. Web Services Distributed Management: Management of Web Services (WSDM-MOWS) 1.0, Committee Draft. OASIS, 2004. Available online at http://docs.oasis-open.org/wsdm/2004/12/wsdm-mows-1.0.pdf, December 10, 2004. [MUWS04] Vambenepe, William, Web Services Distributed Management: Management Using Web Services (MUWS 1.0) Part 1, Committee Draft. OASIS, 2004. Available online at http://docs.oasis-open.org/wsdm/2004/12/wsdm-muwspart1-1.0.pdf, December 9, 2004. [Netmap] Sourceforge.net, NetMap Generator homepage. Available online at http://netmap.sourceforge.net/. [NMAP04] Insecure.org, “Nmap Free Security Scanner, Tools & Hacking Resources.” Available online at http://www.insecure.org. [ORA98] Couchman, Jason S, ORACLE Certified Professional DBA Certification Exam Guide. McGraw Hill, 1998: pp. 469–478. [Prelude] Prelude Project, “Prelude Hybrid IDS.” Available online at http:// www.prelude-ids.org. [Snort] Snort.org, “Snort: The Open-Source Intrusion Detection System.” Available online at http://www.snort.org. [TCPTrace] TCP Trace homepage. Available online at http://jarok.cs.ohiou.edu/ software/tcptrace/tcptrace.html.
Audit
297
[Tripwire] Tripwire, Inc. Tripwire home page. Available online at http://www. tripwiresecurity.com. [W3Clog] Hallam-Baker, Phillip and Brian Behlendorf, “Extended Log File Format, W3C Working Draft WD-logfile-960323.” Available online at http:// www.w3.org/TR/WD-logfile.html. [XMLEvents03] McCarron, Shane, et al., “XML Events: An Events Syntax for XML.” W3C, 2003. Available online at http://www.w3.org/tr/xml-events/, October 14, 2003.
This page intentionally left blank
13
Virtual Domain Model for Web Services Security
In This Chapter Trust Relationships General Security Context Model Types of Trust Relationships Creating Physical and Logical Trust Domains Creating Virtual Trust Domains Summary References
he foundation for business relationships is trust; if the two parties in the transaction do not trust each other, they will be very reluctant to do business with each other. In Chapters 9 and 11 we looked at the basic issues of trust and how parties exchange credentials in order to establish trust relationships. The discussion centered on the interactions between the principles to the transaction. We mentioned different types of trust relationships and only vaguely defined what we meant by those and by the overall concept of trust itself. In this chapter we will provide a more formal definition of trust and its implications. We will also describe the ways in which the partners in the Web Services transaction can build a trust relationship with each other that allows them to be confident in the outcome of their transactions. We will go into detail about what we mean by a trust domain and about how trust domains come into play in establishing trust relationships between
T
299
300
Enterprise Web Services Security
principles and in creating trust relationships among trust domains. We will also define virtual trust domains in greater detail and discuss techniques for creating trust relationships in situations where physical or logical domains do not exist.
TRUST RELATIONSHIPS In order to conduct business on the Web, the parties involved must first establish a trust relationship sufficient to address whatever risks each sees in the transaction. For example, it would be impossible for a retailer on the Web to conduct even an elementary transaction if their customer did not believe the retailer would deliver purchased goods or if the retailer suspected the customer was using a fraudulent identity or credit card. Trust not only underpins basic business transactions; it also underpins any type of exchange that involves sensitive or confidential information where it is important to know the parties can safely conduct the exchange and maintain the confidentiality of the information. Trust, in effect, is a shorthand way of discussing the interdependency between two parties and the rules they use in establishing a mutually beneficial relationship. To better understand this point, let’s look at more formal definitions of what we mean by trust and trust relationships. Webster’s defines trust as the assured reliance on the truth of someone or something or their ability to perform a specific function [Websters04]. The key phrase in this definition is “assured reliance” because it is in creating this assurance that security comes into the picture. It is the security mechanisms in place that provide the necessary levels of assurance each party needs in order to trust the other. In order to gain a better understanding of trust relationships and what it might mean to create a trust relationship within a Web Services context, let’s look at the concept of trust and some of its implications from a sociological standpoint. Williams said that, “Two agents cooperate when they engage in a joint venture for the outcome of which the actions of each are necessary, and where a necessary action by at least one of them is not under the control of the other” [Williams00]. In this type of relationship, one party, the depending party, depends on the other. In a Web Services environment, the agents are the Web Services client and server; the Web Services client depends on the Web Services server to provide some service. This dependency viewpoint leads to Good’s observation that “trust is based on an individual’s theory as to how another person will perform on some future occasion, as a function of that target person’s current and previous claims, either implicit or explicit, as to how they will behave” [Good00]. Good’s observation raises the critical questions of claims, how they are established, and whether they are created solely on the basis of the individual’s assertions or whether there is a reliance on a trusted third party.
Virtual Domain Model for Web Services Security
301
Luhmann expands on Good’s observation to note that “Trust . . . requires a previous engagement,” “it presupposes a situation of risk,” and that “trust is only possible in a situation where the possible damage may be greater than the advantage you seek” [Luhmann00]. In Web Services terms, trust implies the need to protect something (either sensitive information or a protected process) and that there is a possibility of loss associated with that trust. Gambetta ties trust to the classic security-cost tradeoff when he says that “trust will typically be relevant when at least one party is free to disappoint the other, free enough to avoid a risky relationship, and constrained enough to consider that relationship an attractive option” [Gambetta00]. Trust is, in other words, a risk mitigation strategy. While some of the terminology may appear strange, as you can see, many of the concepts underlying trust, trust relationships, and risk have corollaries within the context of human activities and relationships. In this chapter, we will discuss the various types of trust and trust relationships you will encounter in a Web Services environment and present a general model for describing the actors involved in creating these relationships. In the next chapter, we will look at the Web Services standards either in place or evolving that address the establishment of trust and the creation of trust relationships.
GENERAL SECURITY CONTEXT MODEL Figure 13.1 presents a general model we can use for framing the discussion of trust and trust relationships in a Web Services environment. Figure 13.1 illustrates two principals, presumably a Web Services client and server, P1 and P2 respectively, who want to communicate. In the illustration the two principals are in two separate domains (D1 and D2) and there are three token services: A1, A2, and A3. The principals create a virtual trust domain, V-D3, between them in order to effect their message exchange. The principals have several options for establishing this trust relationship: Direct trust between the principals: P1 and P2 create a direct trust relationship based on a shared secret. Direct trust with token service: The requesting principal, P1, creates a trust relationship with A2, the token service in the Web Services server’s domain, which allows P1 to obtain a token in A2’s domain. Direct brokered trust: The token services A1 and A2 establish a trust relationship that allows P2 to turn to A2 and ask A2 to endorse P1’s claims in creating the trust relationship. Indirect brokered trust: The token services A1 and A2 depend on a third token service, A3, to broker the trust relationship.
302
Enterprise Web Services Security
A3 6 3
A1
D1
A2
2
4
P1
1
5
P2
D2
P3
V-D3
FIGURE 13.1 General model for trust relationships.
Confused? To help you better understand the different options and their implications, we will break down trust relationships along their various axes and look at the ramifications associated with selecting different options at each level. At a minimum, trust relationships break down along the following lines: The type of trust relationship between the principals The number and types of trust domains involved The type of trust relationship between domains The level at which the trust relationship will be created within the Open Systems Interconnection (OSI) model [OSI94] The credentials being used in identifying the parties to the relationship How credentials are initially provisioned The actors and their roles within the trust model The infrastructure underpinning the relationship, whether it is physical, logical, or virtual
TYPES OF TRUST RELATIONSHIPS WS-Trust defines trust as “the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make a set of assertions about a set of objects and/or scopes” [WSTrust04]. A trust relationship is therefore the condition where two entites have entered into an assured reliance association, as defined by Webster’s, based on a set of claims (credentials), presumably to their mutual benefit. This relationship is dependent on the two parties unequivocally
Virtual Domain Model for Web Services Security
303
establishing each other’s identity and trustworthiness. Within a Web Services environment, trust relationships come into play in two contexts: Between Principals: Between the client and the server or between the client and/or the server and an STS Between Trust Domains: Between the STSs implementing the domain policy Trust Relationships Between Principals In Figure 13.1, the principals are P1, P2, and P3. They want to exchange one or more messages in order to accomplish some end. What are their options? Let’s look at this question from the standpoint of one of the principals and then expand it to include more complex relationships. Naïve Trust
The simplest trust relationship of course is the one where none is required. Children initially have a naïve trust of their environment; they are unaware of the dangers that may be around them. Distrust is a learned behavior. Open access is a form of naïve trust in a Web Services environment. The extreme example is where a service neither locks down its own resources nor requires any lockdown or identification of the users it supports. Users come through an anonymous authentication and authorization process and execute with the service’s privileges. In such a relationship, neither party is considered trustworthy. Self-Trust
Self-trust is the next higher level. The principal in question locks down its resources and services, but makes no assumptions about the users of its services. The service still offers its services to others through an anonymous authentication and authorization process and they still execute with the privileges of the service itself. The difference lies in users having knowledge of the service’s lockdown and thus having some assurance of the service’s trustworthiness. In other words, in this type of relationship, others can be assured that the principal in question provides some level of integrity regarding its services; however, the reverse is not true. In the model illustrated in Figure 13.1, an example of a self-trust relationship would be a selftrusting P2 offering a service that any P1 could access regardless of their identity or their home domain. Direct Trust
In a direct trust relationship, the two principals create a relationship based on some information known to both parties. The classic example is a user-ID and password
304
Enterprise Web Services Security
scheme where the requesting service, P1, proves its identity through the knowledge of both its user ID and password. P2’s assumption is that only the owner of the user ID knows the password. In order for P1 to assume anything regarding P2, it must use either a mutually agreed upon encryption scheme or digest algorithm to ensure that P2 is witting of the password without it being sent by P1 in plain text. This is called a direct trust relationship because only the two principals are involved. Third Party
In third-party trust relationships, one or both of the principals depend on a trusted third party to vouch for the other principal’s trustworthiness. In Figure 13.1, a third-party relationship would be one where P2 would depend on the token service within its domain, A2, to vouch for P1’s bona fides. A2 could be a certificate authority, a Kerberos ticket granting service (TGS) within a realm, or a Security Assertion Markup Language (SAML) authentication server. The key is that P1 must possess or have knowledge of something P2 can pass to A2 that A2 can use to verify P1’s identity and authorizations. For our purposes, we assume P1 passes to P2 a token that P1 obtained from A1. P2 cannot trust that token to create a direct trust relationship because P2 does not have a relationship with A1. It must therefore depend on a third party, A2 in this example, to create the trust relationship. Mutual Trust
In a mutual trust relationship, the two principals each confirm the identity and trustworthiness of the other before entering into the relationship. The relationship itself may be either direct or through a mutually trusted third party. Delegated or Proxied Trust
In a delegated (or proxied) trust relationship, one principal vouches for the identity of another principal to a third. In Figure 13.1, a delegated relationship is illustrated by P2 proxying requests from P1 to P3. The delegated trust relationship could be either a direct or third party one depending upon the nature of the credentials involved. We will say more about this in the context of our discussion of trust between domains. Trust Domains A trust domain is a collection of trusted entities under a common set of policies and controls. RFC-3324 offers one definition of a trust domain as being a set of nodes belonging to a single owner/operator that can be aggregated into larger domain
Virtual Domain Model for Web Services Security
305
structures through a bilateral agreement [RFC3324]. This definition is useful when we think of the domain including the hardware, software, and networks underlying the relationship. WS-Federation defines a trust domain as “an administered security space in which the source and target of a request can determine and agree whether particular sets of credentials from a source satisfy the relevant security policies of the target” [WSFederation03]. As with trust relationships, we can characterize trust domains along several dimensions, both in terms of their physical scope and in terms of how the domains create their interdomain trust relationship. Physical Trust Domain
In a physical trust domain, all the entities in question are interconnected physically through an infrastructure belonging to a single owner/operator. For example, the depiction in Figure 13.1 of domain D2 shows P2, P3, and A2 belonging to the same organization and being under the same policies as established by A2. Logical Trust Domain
In a logical trust domain, the entities in question belong to multiple owners/operators and are brought together through a common set of policies and controls established by bilateral agreement among the owners/operators. For example, assume in Figure 13.1 that P1 and A1 belong to one organization and one domain, D1, and that P2, P3, and A2 belong to another organization and domain, D2. A bilateral agreement between the owning organizations and a common set of policies and controls can bring the two domains together into a single logical domain. The parties could implement such an agreement through the establishment of a common token service, A3, or the cross certification of their existing token services, A1 and A2. We have used the term owners/operators very loosely in this context; they could be two parts of the same organization or completely different organizations. Virtual Trust Domain
A virtual trust domain is a set of entities belonging to multiple owners/operators that are dynamically interconnected in a logical relationship without a prior bilateral agreement. For example, in Figure 13.1, P1 and P2 may be in different physical domains, D1 and D2. If a domain-level trust relationship does not exist between the domains, then P1 and P2 must create a virtual relationship, V-D3, either directly or using one or both of the STSs within their respective domains, dynamically, at runtime.
306
Enterprise Web Services Security
Single-Domain Relationship
In a single-domain relationship, all the parties involved in a transaction belong to a single physical or logical trust domain. In Figure 13.1, P2, P3, and A2 are parts of a single-domain relationship in which P2 and P3 would depend on A2 for creating the relationship. Multiple-Domain Relationship
In a multiple-domain relationship, the parties to a transaction belong to two or more domains. In Figure 13.1, P1 and P2 belong to two different domains. P1 could establish its interdomain relationship with P2 directly, through a trust relationship with A2, or through an interdomain relationship created between A1 and A2. Trust Relationships Between Domains Trust relationships between domains are similar to those between principals. The difference lies in the entities creating the trust relationship and its scope. In domain-level trust relationships, the secrutity token services controlling the domains become the principals in establishing the domain-level trust relationships necessary to create an interdomain trust model that has domain scope. WSFederation describes a number of different types of interdomain trust relationships [WSFederation03]. Direct Trust
In an interdomain context, a direct trust relationship exists when a principal in one domain can directly accept the claims presented by a principal from another domain. Looking back at our example in Figure 13.1, there are two ways in which P1 and P2 could enter into a direct relationship. One way is for P2 to be able to directly trust whatever credential P1 may have obtained from its local token service A1. The other way is for P1 to be able to request from A2, based on the credential it received from A1, a credential that it can present to P2. The first step in both scenarios is for A1 and A2 to create a direct interdomain trust relationship (line 3) and exchange the metadata they need to support cross-domain trust. The relationship would be created in such a way that either P2 could directly trust P1’s credential (line 1) or P1 could directly obtain a credential from A2 (line 2) that it could use for its transactions with service P2. In both situations P2 would use the credential it received from P1 in its authentication and authorization processes. Cross-certified PKI certificates and Kerberos interrealm authentication services
Virtual Domain Model for Web Services Security
307
are two examples of this type of relationship. WS-Federation describes this scenario as its Basic STS model. Direct Brokered Trust
In a direct brokered trust relationship one party relies on another to vouch for a third party. The second party directly trusts the claims of the first party. An example of this type of relationship in a cross-domain context is one where the STSs in the two domains create a direct trust relationship between them that allows the STS in one domain to accept credentials issued by the STS in the other. Referring back to Figure 13.1, let’s assume A1 and A2 have created such a relationship (line 3). In order for P1 to create a relationship with P2, P1 would pass the credentials it received from A1 (line 4) to P2 (line 1). P2 would pass those credentials to A2 (line 5), who would endorse the claims represented by those credentials based on the relationship it has with A1. Cross-domain SAML Policy Decision Points is an example of this type of relationship. WS-Federation describes this scenario in its Alternate STS model. Indirect Brokered Trust
In an indirect brokered trust relationship, one party still relies on another to vouch for a third party; however, the second party cannot directly endorse the claims presented. The second party must either further negotiate the claims with the first party or depend on yet another party to endorse the claims. An example of this type of relationship is one where the STSs within two domains are dependent on a third STS for creating their interdomain relationship (as illustrated by line 6 in Figure 13.1). WS-Federation describes this scenario in its Indirect Trust model. Multiple Trust Domains and Delegation
In a Web Services environment, Web Services clients and servers may need to communicate across several domains. Those domains may each enter into direct or brokered trust relationships and may need to delegate trust relationships across domains either directly or indirectly as illustrated in Figures 13.2 and 13.3. In Figure 13.2, P1 uses the credential it receives from A1 (line 1) to obtain a second credential from A2 (line 2), which it sends to P2 (line 3). P2 in turn obtains a proxy credential from A3 (line 4) that it sends to P3 (line 5). In this scenario, domain trust relationships exist between A1 and A2 and between A2 and A3. A3 issues the proxy credential to P2 based on the trust relationship it has with A2. In Figure 13.3, the same sequence occurs, but now A3 endorses the proxy relationship based on its trust relationship with A1 rather than on a trust relationship with A2. WS-Federation defines both scenarios depicted as variations of its Delegation model.
308
Enterprise Web Services Security
A1 D1
A2
A3
D2
1
D3
2
4
P1
P2
P3
3
5
FIGURE 13.2 The direct delegation model.
A1 D1
A2
A3
D2
1
D3
2
4
P1
P2 3
P3 5
FIGURE 13.3 The indirect delegation model.
CREATING PHYSICAL AND LOGICAL TRUST DOMAINS The trust domain concepts discussed in the previous sections assume a trust infrastructure that allows the creation of cross-domain trust relationships between principals. Either physical or logical trust domains may provide the underpinnings for this infrastructure. The concepts we have discussed have been at an abstract level because we have wanted them to include all the various types of tokens and services available (X.509, Kerberos, SAML, etc.). We will now turn our attention to the decisions you must make in implementing physical and logical trust domain infrastructures. At some point, we hope a single standard will emerge that will simplify this problem, but until that happens, Web Services have to deal with the implementation complexity that diverse environments create. Where Should Trust Relationships Be Created? In deciding how to implement a given trust domain infrastructure, one of the first questions that must be answered is, where within the hardware and software stack
Virtual Domain Model for Web Services Security
309
should the trust relationships be established? If you are dealing with a legacy environment, this may be a given. If not, you have a number of options available. Figure 13.4 shows a modified OSI model. It is modified in two ways. First, we have collapsed the applications, presentation, and session layers into a Web Services layer. The second change is to add a platform layer between the Web Services and transport layers. When you look at the entire stack, there are both hardware and software options available for implementing trust relationships. Hardware solutions at the lower levels give way to software solutions as you move beyond the network layer. Two data-link layer options available for creating trust relationships are Serial Line Internet Protocol (SLIP) for dial-up connections and Point-to-Point Protocol (PPP) for more sophisticated types of devices. An option for creating trust relationships at the network layer is Internet Protocol version 6 (IPv6). Transport layer options for creating trust relationships include Transport Layer Security (TLS), its predecessor Secure Socket Layer (SSL), and Secure Internet Protocol (IPSec). A broad range of options for creating trust relationships becomes available at the Web Services layer, including WS-Security, XML Encryption and Signature, SAML, and eXtensible Access Control Markup Language (XACML). We added the platform layer to the diagram because higher-level protocols and services assume the underlying server, services, and protocols are appropriately locked down.
Web Services Client Platform Transport Layer
Applications Level WS-Security XML Encryption XML SIgnature
Transport Level
Web Services Server Platform Transport Layer
TLS SSL IPSec
Network Layer
Network Level
Network Layer
IPv6
Data-Link Layer
Link Level
Data-Link Layer
PPP SLIP
Physical Layer
Physical Layer
FIGURE 13.4 Where should trust be implemented?
What Credentials Will Be Used? The answer to this question may be dictated by The legacy environment you are operating in The answer to the previous question (a legacy product may dictate the use of user ID and passwords, for example)
310
Enterprise Web Services Security
Choices made by others within a shared environment, such as an extranet, where interoperability is concerned If you are answering the question for the first time, in the absence of any other consideration, the options boil down to how you plan manage identities. As we discussed in Chapter 9, you have a broad range of identity management choices including everything from user IDs and passwords to various types of identity management services including public key infrastructure (PKIs), Kerberos, SAML, Microsoft Passport, and Liberty Alliance. If you are using or providing services across a number of different trust domains, your services may need to support multiple identity management schemes belonging to multiple owners. A question you will face in this type of situation is whether you want to cross-certify credentials among the owners, implement some common, trusted root, or implement a pseudonym service to maintain alternate identity information. Identity and credential mapping is one approach to addressing the problem of mapping identities, credentials, or both in heterogeneous environments. An identity or credential mapping service maps either an identity or a credential in one space to a corresponding identity or credential in another. The mapping can be one-to-one or many-to-many in either direction (e.g., one user with many identities or credentials or one identity or credential with many users). The basic concept behind the service is that it accepts and abstracts the diversity. The alternative is to strive for homogeneity by either implementing a common identity or credential service across the domains (e.g., a common third-party service) or adopting a service that deals with the diversity at the endpoints while presenting an abstraction across the domains (e.g., a SAML service). What Are the Integrity and Confidentiality Considerations? As we discussed in Chapters 9 and 10, you have several options in implementing integrity and confidentiality between two parties. The decisions you make in this regard affect trust relationships in that they determine the number of different trust relationships you need to create between parties. Point-to-Point
Point-to-point integrity and confidentiality only guarantee integrity and confidentiality between two endpoints. In a Web Services environment, the simplest pointto-point trust relationship is between the Web Services client and Web Services server. The problem becomes more complex when there are intermediaries
Virtual Domain Model for Web Services Security
311
between the Web Services client and server that have access to and must process the traffic. In that situation, pairwise point-to-point integrity and confidentiality are necessary. SSL is an example of a point-to-point solution. If intermediaries must process the messages, separate SSL sessions are required between each pair of principals involved. End-to-End
End-to-end integrity and confidentiality guarantees integrity and confidentiality between the Web Services client and server regardless of how many intermediaries become involved or their roles. A trust relationship between the Web Services client and server, therefore, is all that is really necessary in an end-to-end solution. If intermediaries must process the messages, the Web Services client can separately sign and encrypt each segment, depending on which components must process it, and therefore independently create a trust relationship between it and those intermediaries. How Will Credentials Be Provisioned? In Chapter 9, we discussed three models for managing identities: direct, commonbroker, and federation. In each, there is a question of how principals receive the initial tokens representing their credentials. Out-of-Band
One option is out-of-band, or outside the normal message stream. An administrator may Install the token on the user’s workstation or on the server supporting an authorized process Email the token to the principal in question and depend on him to install it himself Send the password, pass-phrase, or smart card and pin to a user via snail-mail and depend on the user to enter the information directly Self-Registration
Self-registration is a popular option on the Internet. With self-registration, a user creates an account including a password or pass-phrase the first time he uses a service. Depending upon the sensitivity of the information to be shared with a selfregistered user or service, some additional out-of-band information may be used to increase the integrity of the relationship.
312
Enterprise Web Services Security
What Principals Will a Given Principal Trust? Given a set of principals and a corresponding set of tokens, one of the next questions that arises is, how will principals decide which other principals they will trust? Once a requesting principal’s identity is established, the principal offering a service can determine the requesting principal’s accesses via authorization and access control mechanisms. The question is therefore really one of how will principals authenticate one another? Fixed Trust Roots
WS-Trust identifies fixed trust roots as the simplest mechanism for a principal to determine its partners [WSTrust04]. With fixed trust roots, an administrator or some other authorized person specifically identifies the valid partners that can create relationships with a given principal. A list of valid certificate authorities, or valid IP addresses or subnets, or domains are examples of this approach. Figure 13.5 illustrates the concept of fixed trust roots. Each principal effectively has a fixed list of associations that it can use to create trust relationships. Adding a new relationship requires modifying the lists associated with the corresponding principals.
A3
A1 D3
D1
A2 D2
FIGURE 13.5 Fixed trust roots.
Virtual Domain Model for Web Services Security
313
Trust Hierarchies
WS-Trust identifies trust hierarchies as a second mechanism for a principal to determine its partners. With a trust hierarchy, an administrator or some other authorized person designates that all the tokens of a specific type and belonging to a specific set or hierarchy of domains can be trusted. Trust hierarchies apply to PKIbased certificates, Kerberos, and attribute-based services such as SAML. Figure 13.6 illustrates a hierarchy of domains and principals. In order for P1 and P2 to create a trust relationship, they must be able to find a common ancestor, designated by the domain node (D2) pointed to by line 1. For either P1 or P2 to create a trust relationship with P3, they too must be able to find a common ancestor such as the one designated by the domain node (D1) pointed to by line 2. The term heirarchy comes into play because there is assumed to be a set of hierarchial relationships that enable principals, wherever they reside, to be able to find a common ancestor that allows them to establish a trust relationship. 2
D1
1
P1 and P2
D2
D4
D7
(P1 or P2) and P3
D3
D5
D8
P1
FIGURE 13.6 Trust hierarchies.
D9
P2
D6
D10
D11
D12
P3
314
Enterprise Web Services Security
Authentication Service
WS-Trust identifies an authentication service as a special type of fixed-root trust relationship where a principal uses a fixed root to establish a trust relationship with an authentication service that it can then use to broker requests for its services. Both SAML and XACML are based on this model.
CREATING VIRTUAL TRUST DOMAINS Thus far, we have focused on physical and logical trust domains—situations where an administrator or some other authorized person can predefine trust relationships between the members of the domains either directly or indirectly through certificate lists, trust hierarchies, or some other means. You will primarily find these types of trust relationships in intranet or extranet environments with fixed infrastructures where it is possible to predetermine the credentials and trust hierarchies in question and preposition the necessary tokens. You will also find them in Internet environments where the owner/operators of the underlying domains have mutually agreed to extend their domains across an Internet backbone. Virtual trust domains approach the problem from the standpoint of two principals wanting to dynamically create a trust relationship without a prior bilateral agreement or predefined set of trust relationships. Virtual trust domains are more common in Internet environments, where service owners may not know who the users of their services will be until runtime. Experience Based There are several different strategies for creating virtual trust domains. The first one we will discuss is one based on the principal’s direct experience. In an experiencebased model, the two principals create a trust relationship based solely on the information or capabilities they have between them. Figure 13.7 illustrates the basic model where two principals create a shared secret that allows them to create a trust relationship that has increasing degrees of trustworthiness built in as the principals gain experience and confidence with each other. This model is very similar to the one human’s use in situations where there isn’t a trusted third party both parties can trust. An example of this model is our credit card system. Credit card companies issue credit cards to people who do not have credit histories. They are willing to accept a certain degree of risk at the onset of the relationship that is generally reflected in the credit limit. The credit card company gradually increases the credit limit as the credit card holder proves his trustworthiness over time through a pattern of charging against the card and paying off those charges.
Virtual Domain Model for Web Services Security
315
Trust
P1
P2 Shared Secret
Successful Transactions
FIGURE 13.7 Experience-based trust model.
To walk through this model in a Web Services context, let’s begin with a situation where the principal offering a service, P2, asks the principal needing the service, P1, to create an account, including a user ID and password, the first time P1 calls upon the service. The password becomes the shared secret between the two parties (P2 should create an SSL connection to protect the confidentiality of this first transaction) that they can use to verify that future transactions are coming from the same principal as the original. By allowing P1 to create an account, P2 assumes a certain degree of risk and may limit what P1 can do. P1 and P2 continue to conduct transactions over time, and as they conduct those transactions, P2’s confidence (or trust) in P1 increases with each successful transaction and P2 becomes more willing to share information or provide services to P1. Reference Based When possible, humans turn to the people they trust when trying to determine the trustworthiness of a stranger. Children turn to their parents, adolescents to their friends, workers to their coworkers, and so on. The equivalent model in a Web Services context is a reference-based trust model where one principal relies on some set of references from a subset of those it already trusts in order to determine the trustworthiness of a previously unknown party. As in the human world, the Web Service may either turn to its peers or to an authority figure.
316
Enterprise Web Services Security
Figure 13.8 illustrates the web-of-trust model for implementing referral-based virtual trust domains. The web-of-trust model is a peer-based model where the principal wanting to establish the trustworthiness of a previously unknown party turns to its peers. There are two variations on how the principal queries its peers. One is directly: the principal wanting to establish the bona fides of another asks its peers, “How many of you have either used or provided services to the principal in question within the last x timeframe?” The other is an indirect approach where parties maintain a portfolio of references detailing their last n-transactions. When they need to establish their trustworthiness, they pass the portfolio to the principal they need to convince and that principal uses the entries in the portfolio to determine whether any of the transactions were with peers that it trusts. In both cases, the principal requiring the trust relationship depends on its circle of friends to establish the trustworthiness of an unknown second party. The web-of-trust model is very similar to the human model where people turn to their friends, or family, in order to determine whether to admit a new person into their circle.
P1
P2
FIGURE 13.8 Web-of-trust model.
Figure 13.9 illustrates the more traditional hierarchical model for implementing referral based virtual trust domains. In the hierarchical model, the principals find a common root that allows them to establish a trust relationship. The root can be a business unit, a corporate affiliation, an industrial classification, or any other
Virtual Domain Model for Web Services Security
317
membership-type relationship that allows the two principals to determine that they are part of some larger group that they trust. In the figure, principals P1 and P3 have to ascend to the root of the tree in order to find a common relationship; principals P2 and P3, however, need only traverse two levels before they find a common ancestor.
P1
P2
P3
FIGURE 13.9 Hierarchical trust model.
As humans, we use the reference-based model in many day-to-day situations. We use it in résumés, in capability statements, in club memberships, in word-ofmouth marketing. In a Web Services context, a reference-based model requires agreement on identity, on what it means to trust another party, and on the algorithm for establishing both the identity and the level of trust. How does this model differ from the more traditional trust hierarchy? The difference lies in the relationship not depending on a previously known, shared set of
318
Enterprise Web Services Security
credentials or authorities. A Web Service, for example, may conclude that it can trust a requestor from a particular organization by verifying that the requestor and that organization (as represented by its Web presence) have an IP address or email root in common. The key is that the party needing to validate the relationship will do so at runtime based on some non-credential-based algorithm. Reputation Based A third option for creating virtual trust domains is based on the reputation model. In the reputation model, P2 determines that it can trust P1 based on P1’s reputation. The assumption is that past behavior is a predictor of future behavior. Webster’s defines reputation as the recognition by other people of some characteristic (in this case trustworthiness) of another [Websters04]. The reputation model is similar to the referral model in that the depending principal is relying on another entity to help make the trustworthiness decision. The difference lies in how that other entity determines the trustworthiness of the principal in question. In the referral model, that determination is made through direct experience. In the reputation model, the determination is made through either some characteristic of the principal whose trustworthiness needs to be established or through the experience of others. Figure 13.10 illustrates the reputation-based model, where the depending principal, P2, confers with a cloud of potential authorities on the trustworthiness of P1. The authorities could be the list of Fortune 500 hundred companies, Dun & Bradstreet, or the Better Business Bureau. In each case, the basic questions P2 asks are, “Have you heard of the principal in question?” and “Have you heard anything bad about them?” In each instance, the authority will respond based on its knowledge of the principal’s past behavior. The eBay auction system is a good example of a reputation-based user confidence mechanism. In the eBay system, buyers and sellers can receive information regarding their counterparts based on the experiences other users have had with the principal in question. eBay itself only creates the common marketplace and the scoring mechanism for its members to use. Depending upon previous feedback, a user can determine whether he wants to engage in a transaction with another under the assumption that past behavior and others’ experiences are good predictors of future behavior. Another way to look at a reputation-based model is, how do others’ ratings correlate with the asking principal’s risk threshold? Drawing on our eBay example, a principal with a high aversion to risk would want to see a large number of positive responses and few, if any, negative responses before being willing to create a trust relationship. A more risk-tolerant principal would be willing to accept fewer positive responses. The risk question comes into play in terms of setting thresholds for reputation-based schemes.
Virtual Domain Model for Web Services Security
319
Dun & Bradstreet® Better Business Bureau® Fortune 500® UDDI
P1
FIGURE 13.10
P2
Reputation-based trust model.
In a Web Services environment, UDDI offers a mechanism for collecting information concerning the behavior of a particular business entity or service, assuming the parties in question can agree on how to register and interpret that information and how to prevent either the principal or some other third party from manipulating the result. By definition, there is more risk associated with virtual trust domains than with either physical or logical domains. Why would you use them? Because you want to offer or use services but do not have a situation where you can predict your user population or provision the tokens necessary to create a less risky infrastructure. As Gambetta noted, you consider the relationship an attractive option [Gambetta00].
SUMMARY The exchange of sensitive information between two parties hinges on their ability to create a trust relationship that both accept. We have traditionally approached this problem from the standpoint of creating either physical or logical trust domains where parties can agree on tokens and trust relationships based on either physical control and ownership or bilateral agreement. Web Services introduces requirements for the ability to create not only these traditional types of trust domains but also virtual trust domains where one entity must determine the trustworthiness of another based on either direct experience, references, or reputation.
320
Enterprise Web Services Security
In this chapter, we have gone into detail about what we mean by trust, a trust relationship, and a trust domain. We also looked at different types of trust and trust relationships and the importance of both where and how these relationships are created. For trust domains, we looked at physical, logical, and virtual domains and techniques for establishing trust in virtual domains where supporting physical and logical domains are insufficient or do not exist.
REFERENCES [Gambetta00] Gambetta, Diego, “Can We Trust Trust?” Trust: Making and Breaking Cooperative Relations, electronic edition, edited by Diego Gambetta. Department of Sociology, University of Oxford, 2000: pp. 213–237. Available online at http://www.sociology.ox.ac.uk/papers/gambetta213-237.pdf. [Good00] Good, David, “Individuals, Interpersonal Relations and Trust.” Trust: Making and Breaking Cooperative Relations, electronic edition, edited by Diego Gambetta. Department of Sociology, University of Oxford, 2000: pp. 31–48. Available online at http://www.sociology.ox.ac.uk/papers/good31-48.pdf. [Luhmann00] Luhmann, Niklas “Familiarity, Confidence, Trust: Problems and Alternatives.” Trust: Making and Breaking Cooperative Relations, electronic edition, edited by Diego Gambetta. Department of Sociology, University of Oxford, 2000: pp. 94–108. Available online at http://www.sociology.ox.ac.uk/ papers/luhmann94-107.pdf. [OSI94] International Standards Organization, ISO 7498-1 Information Processing Systems—Open Systems Interconnection—Basic Reference Model: The Basic Model, Technical Report, ISO, 1994. [RFC3324] Watson, M., “RFC-3324 Short-term Requirements for Network Asserted Identity.” Available online at http://www.ietf.org/rfc/rfc3324.txt. [Websters04] Merriam Webster, “Merriam Webster Online.” Available online at http://www.m-w.com. [Williams00] Williams, Bernard, “Formal Structures and Social Reality.” Trust: Making and Breaking Cooperative Relations, electronic edition, edited by Diego Gambetta. Department of Sociology, University of Oxford, 2000: pp. 3–13. Available online at http://www.sociology.ox.ac.uk/papers/williams3-13.pdf. [WSFederation03] Bajaj, Siddharth, et al., “Web Services Federation Language (WS-Federation).” Available online at http://www-106.ibm.com/developerworks/webservices/library/ws-fed/, July 8, 2003. [WSTrust04] Anderson, Steve, et al., “Web Services Trust Language (WS-Trust) Version 1.1.” Available online at http://www-106.ibm.com/developerworks/ library/ws-trust/, May 2004.
14
Establishing and Communicating Trust
In This Chapter Types of Trust Relationships WS-Trust WS-Federation WS-SecureConversation XKMS SAML XACML Summary References
rust in a Web Services environment translates into agreement on a set of credentials and the grammatical elements and protocols for communicating those credentials to the parties involved. Creating trust relationships can involve third-party brokers and requests to those brokers to either issue or validate credentials. From this perspective, the credential may be an identity token, an assertion, or either an encryption or signature key. In this chapter we explain how partners in a Web Services transaction can establish and communicate the details of trust relationships using the evolving set of Web Services and eXtensible Markup Language (XML) specifications for these purposes. We discuss WS-Trust and WSFederation, which are two specifications describing the grammars and message syntax for requesting and validating tokens and for creating trust relationships in a federated environment. We also discuss the XML Key Management Specification
T
321
322
Enterprise Web Services Security
(XKMS), which defines services for registering and retrieving keys. We also discuss Security Assertion Markup Language (SAML) and eXtensible Access Control Markup Language (XACML), two rapidly evolving standards that are tackling the single sign-on problem by introducing new ways of thinking about identity and access management and for encoding authentication, authorization, and access decision rules. Enterprise Web Services may have to support or interact with several of these technologies, depending on the heterogeneity of their environment.
TYPES OF TRUST RELATIONSHIPS In the previous chapter, we looked at the various types of trust relationships a Web Service may need to create depending on the complexity and diversity of the target environment. Table 14.1 summarizes the various options based on the scope and type of relationship.
TABLE 14.1 Types of Trust Relationships Scope
Type
Relationships
Between principals
Direct
Principal-to-principal Principal-to-token service
Third party
Principal-to-token service
Mutual
Direct or third-party
Delegated
Direct or third-party
Direct
Principal-to-principal Principal-to-remote token service Token service–to–token service
Direct brokered
Principal-to–token service Token service–to–token service
Indirect brokered
Principal-to–token service Token service–to–third-party
Delegated
Direct interdomain Indirect interdomain
Between domains
Token service
Establishing and Communicating Trust
323
As you can see from Table 14.1, there are at least three types of communications patterns involved: between principals, between a principal and a token service, and between token services. In Chapter 11, we looked at the Web Services and XML standards for representing security tokens in SOAP messages and the grammatical elements and protocols for communicating credentials between principals in peer-to-peer, or direct, relationships. In this chapter we will focus on the other two types of communication patterns. In a Web Services context, principals communicate with token services for two basic reasons when it comes to establishing trust relationships: To ask the token service to issue a security token or credential the principal can use in a transaction To ask the token service to validate a credential the principal received as part of a transaction WS-Trust provides the foundation for these interactions. The token service in this context acts in its role as the local domain authority for a set of users and resources within a physical trust domain belonging to a single owner/operator. Token services play an expanded role when it comes to creating trust relationships at a domain level. The primary communication between token services within this context is in the form of a metadata exchange. The token services controlling their respective domains either directly or indirectly (through a third token service) exchange domain policies, key attributes, and in some instances, credentials. The Web Services specifications supporting this interaction include: WS-Federation laying the foundation for creating various types of federated interdomain relationships WS-MetadataExchange for the metadata exchange WS-SecureConversation to improve the efficiency of the exchange Identities and identity management play a key role in establishing cross-domain trust relationships. An identity mapping, or matching, problem exists where different domains use different types of credentials for managing identity within their respective domains. Somehow the domains must agree on the identities and the credentials they will use. WS-Federation identifies a number of specialized services to help manage this problem: identity provider services, attribute services, pseudonym services, and validation services. XKMS augments this list with key registration and retrieval services supporting XML Signature and Encryption to help address the equally important key management problem.
324
Enterprise Web Services Security
The emerging SAML standard takes a different approach to managing the identity mapping problem. Whereas WS-Federation takes the approach of using pseudonym and attribute services to elevate the identity mapping problem to a set of specialized services that can be used where needed, SAML takes the approach of supporting diversity within domains while standardizing across domains by replacing identity-based credentials with assertions. The complementary XACML standard addresses the issues of standardizing the ways access policies underpinning these assertions are written and interpreted. In the remainder of this chapter, we will delve deeper into each of these standards and specifications and their contributions to establishing and communicating trust.
WS-TRUST Let’s begin our discussion by defining what we mean by security token. WS-Security defines a security token as the representation of a collection of claims, where a claim can be an identity, an encryption key, a digital signature, an assertion, or a set of attributes [WSSecurity04]. WS-Trust builds on WS-Security, adding the grammatical elements for requesting and returning security tokens; for issuing, renewing, and validating tokens; and for implementing a negotiation and challenge framework [WSTrust04]. The Web Services Trust Model WS-Trust is built around the policy-based model shown in Figure 14.1. The model is constructed around the concept that a Web Service can require a set of claims from a requestor of its services that the service can use to verify compliance with the policy in place. The requestor can either provide the necessary claims or contact an appropriate security token service (STS) to obtain tokens representing those claims. The STS may require the requestor to provide appropriate proof of claims and policy compliance before issuing the requested tokens. Once the requestor sends the claims to the Web Service, the Web Service may either use the claims as presented or call upon an STS to validate the requestor’s claims or to transform them into a useable form. Requesting and Returning Tokens: The STS Framework WS-Trust’s STS framework is based on a simple request and response model where requestors use messages to request tokens from STSs, and STSs use messages to respond. Requestors in this model can be Web Services clients, Web Services servers, or STSs.
Establishing and Communicating Trust
325
Policy Security Token Service Token
Claims
Policy
Policy Requestor
Claims
Token
Web Service Token
Claims
FIGURE 14.1 The Web Services trust model.
RequestSecurityToken
The element is a SOAP subelement that is illustrated in Listing 14.1. The optional Context attribute contains a URI that the parties can use to correlate the request with the response. The only requirement is that the URI must be uniquely identifiable by both parties. The optional subelement contains a URI (from those shown in Table 14.2) indicating the type of token being requested. The subelement contains a URI (from those shown in Table 14.3) indicating the type of request being made. An Issue request asks the STS to issue a new token based on the credentials included in the request message. A Renew request asks the STS to update the expiration time associated with a previously issued token. A Validate request asks the STS to return a status, a new token, or both; the optional subelement indicates what the requestor wants to be returned. The optional subelement provides a security token reference as the basis for the request. For example, the security token included in the subelement could be the one being used to protect the message. WS-Trust recommends that requests be signed. The optional subelement contains any tokens that provide additional claims supporting the request. LISTING 14.1
The RequestSecurityToken Element Syntax
... ... ... ... ...
326
Enterprise Web Services Security
TABLE 14.2 Valid Token Types Token Type
URI
X.509
http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0#X509v3
Kerberos
http://schemas.xmlsoap.org/ws/2003/12/kerberosv5ST
Kerberos2
http://schemas.xmlsoap.org/ws/2003/12/kerberosv5_AP_REQ
Username
http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0#UsernameToken
Security context
http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct
Derived key
http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk
Status
http://schemas.xmlsoap.org/ws/2004/04/security/ trust/RSTR/Status
TABLE 14.3 Types of Token Requests Type
Meaning
URI*
Issue
Issue a new token
Issue
Renew
Refresh token’s expiration time
Refresh
Validate
Validate token’s claims
Validate
*The URI Prefix = http://schemas.xmlsoap.org/ws/2004/04/security/trust.
RequestSecurityTokenResponse
The
element can appear in either the SOAP or element depending on the request. Listing 14.2 illustrates the element’s basic syntax. The optional Context attribute contains the identifier, if any, contained on the original request. The optional subelement indicates the type of token the response contains, and the optional subelement contains either the token itself or a reference to the token. The reference can be relative, pointing to another location in the document, or absolute, a URI pointing to an external token.
Establishing and Communicating Trust
LISTING 14.2
327
The RequestSecurityTokenResponse Element Syntax
... ... ...
Binding Specific Elements
Each type of request (issue, renew, validate) represents a specific protocol binding. WS-Trust defines the binding specific elements shown in Table 14.4. The additional elements extend the basic framework providing compositional granularity that can be used in specific operational scenarios and use cases as described in the WS-Trust specification [WSTrust04]. TABLE 14.4 Binding Specific Elements Binding
Element
Description
Issue request
WS-Policy-defined element that can be used to define scope in lieu of
Issue response
Renew
Validate
Claims satisfying policy
Entropy used to create key
Base-64 encoded entropy format may be fixed, by policy, inferred, or determined by token
Time range for token used in concert with the Created and Expires elements
Response token
Response token reference
Proof-of-possession token
Permits future timestamps
Renewal semantics
Encoded validation results
Validation code, e.g., Valid or Invalid
Human-readable reason
328
Enterprise Web Services Security
Negotiation and Challenge Extensions The STS framework covers the simple case where requests can be handled using a simple request and response message pattern. Sometimes this model breaks down, specifically, when a requestor provides inconsistent or incomplete information or when a credential’s lifetime has expired. WS-Trust extends the model for these more complex use cases by adding a challenge and negotiate pattern. WS-Trust defines a negotiation framework built on the following four-step process: Step 1: Service A sends a token request to service B. Step 2: Service B returns a challenge response requesting additional detail or clarifying information. Step 3: Service A returns the additional information requested. Step 4: Service B returns the requested token. The parties may repeat steps 2 and 3 as many times as necessary. WS-Trust identifies specific types of challenges where this pattern applies, including those for questioning a message’s timestamp, signature, or adherence to policy, for exchanging binary tokens, and for exchanging key material. WS-Trust describes the use of the additional elements in Table 14.5 for handling these specific use cases.
TABLE 14.5 Additional Negotiation and Challenge Elements Use
Element
Description
Message freshness
Used to ensure requests and responses meet lifetime requirements
Policy
WS-Policy elements to question or clarify policy requirements
Signature
Challenge a signature
Respond to the challenge
Exchange
Base-64 binary blobs forming part of the challenge or negotiation
Key exchange
Request key exchange token
Provide a key exchange token
Establishing and Communicating Trust
329
Key and Token Extensions Thus far, we have looked at the problem from the standpoint of the requesting party being the one requiring or needing the requested token. This model works in simple, single-domain use cases but breaks down in complex, cross-domain scenarios where one party is acting on behalf of another. WS-Trust provides extensions to the STS framework to handle these more complex second-party transactions (those on behalf of others) and delegation and to allow more robust negotiation of both the security tokens and the elements used to secure those tokens. Table 14.6 lists the elements added to the basic framework for this purpose and their intended use cases. TABLE 14.6 Key and Token Extensions Use
Element
Description
Authenticating exchange
Proof of knowledge of a computed hash
Base-64 encoding of hash
Request is on behalf of another
Issuer of a token presented in the element
URI describing the type of authentication desired
Type of key (PublicKey or SymmetricKey) desired
The size of the key required in bits
Signature algorithm desired
Encryption algorithm desired
Desired canonicalization method
Requests returned token be encrypted
Requests proof-of-possession tokens be encrypted
Use existing key for encrypting returned token
Second-party request
Key and encryption desired
330
Enterprise Web Services Security
Use
Delegation and forwarding
Authorized participants
Element
Description
Desired signature algorithm for returned token
Desired encryption algorithm for returned token
Issued token to be delegated to another identity
Request issued token be marked forwardable
Request issued token be marked delegable
Request pseudonym information for issued token
Identifies parties sharing the token
Identifies the primary user of a token
Identifies party that plays a role in the use of the token
WS-FEDERATION The combination of WS-Security and WS-Trust provides the basic elements you will need for dealing with most single-domain and simple cross-domain scenarios (those involving a single type of security token or exclusively dealing with direct trust relationships). WS-Federation builds on WS-Policy, WS-Security, and WSTrust to extend the model to more complex, multidomain scenarios where multiple STSs and multiple types of credentials are involved. WS-Federation, as the name implies, takes a federated approach to the problem, presenting various models for
Establishing and Communicating Trust
331
Sharing identities Sharing authentication and authorization information Brokering trust relationships Exchanging security tokens WS-Federation describes five types of token services, each providing a specific set of capabilities within a trust domain or realm or across a federated group of services [WSFederation03]: Security Token Service: A Web Service that issues security tokens such as identity credentials or encryption keys Identity Provider: A service that can act as an authentication service for principals and as a source of identity information for other service providers Attribute Service: A service that maintains attribute information about the principals and security services within a trust domain or realm or across a federated group of services Pseudonym Service: A service that maintains alternate identity information about the principals and services within a trust domain or realm or across a federated group of services Validation Service: A Web Service that validates a set of tokens in order to determine the level of trust WS-Federation is neutral on whether a service provides the capabilities individually or collectively, leaving the way open for technologies to select the most advantageous configuration meeting their needs. Basic Concepts Figure 14.2 illustrates WS-Federation’s basic concepts. In the WS-Federation model, passive and active requestors (which are Web Services components) utilize services offered by various token services. Requestors and services within an administered security space create a trust domain or realm (Figure 14.2 depicts three trust domains: D1, D2, and D3). Federations are collections of trust domains and realms that have created cross-domain trust relationships. Requests can be between parties within a single domain or cross domain boundaries. The domains in a federation need not contain a uniform set of services or roles. Figure 14.2 illustrates this point showing three domains, each with a distinct set of services. Domain D1, for example, contains two services: a STS and an identity provider service. In the configuration shown, the identity provider would provision
332
Enterprise Web Services Security
Metadata
D1
D3 Federation
D2 Security Token Service
Pseudonym Service
Identity Provider
Validation Service
Attribute Service
Requestor
FIGURE 14.2 Basic WS-Federation conceptual model.
identity information to the STS. The STS, in turn, would then interact directly with requestors to service their requests. Domain D2 illustrates a slightly more complex example. D2 contains both an identity provider and a pseudonym service. The idea represented here is that the STS would use the identity provider to broker withindomain requests and the pseudonym service to broker cross-domain requests. The pseudonym service may translate between X.509 certificates and Kerberos tickets, for example. D2 also contains an attribute service that could come into play to support SAML or other attribute-based authorization requests. Domain D3 illustrates the use of a centralized validation service to validate tokens as part of authentication and authorization processing. WS-Federation builds on the basic security service constructs it introduces to describe models for direct, direct brokered, indirect brokered, delegated multidomain, and federated cross-domain trust relationships. We discussed these models in Chapter 13 in the section on creating trust relationships between domains, so we will not repeat that discussion here.
Establishing and Communicating Trust
333
Federation Metadata In order to federate services across domains, services must be able to exchange metadata describing policies, security profiles, and STS locations. WS-Federation builds on the WS-MetadataExchange specification for exchanging metadata among federated domain services and adds a element that services can add to their WS-Policy statements in order to point back to a particular STS location [WSMetatdata04]. WS-Federation also adds a message for the STS controlling a domain to use to notify its federation partners that they should clean up any cached metadata and a element that allows federation partners to subscribe to sign-out messages. Attribute and Pseudonym Services As we discussed in Chapter 9, characteristics other than identity play an important part in role-based and rule-based access control systems. These additional attributes can belong to any principal, be it a user, a resource, or a service. An attribute service provides a mechanism for storing additional information about an identity and for providing access to that information to authorized users. X.509 is an example of where this type of service can come into play. X.509 Certificates can optionally contain attribute information. Authorized users can generally obtain this information through Lightweight Directory Access Protocol (LDAP) Directory requests. WS-Federation generalizes this service for the Web Services environment by defining a principal attribute taxonomy tModel entry that allows Universal Description, Discovery, and Integration (UDDI) Directories to store attribute information, thereby turning UDDI into a potential attribute service that can be used when one does not already exist. WS-Federation defines a pseudonym service as a special type of attribute service. A pseudonym service stores alternate identity information about a principal, possibly in addition to a general set of attributes. The alternate identity information comes into play in cross-domain scenarios where principals need to traverse domain boundaries, changing either identities or tokens as part of the process. To support pseudonym services, WS-Federation defines , , and messages for retrieving, updating, and deleting pseudonym entries in a directory and the corresponding response messages. WS-Federation describes two potential scenarios for associating tokens with pseudonyms. One scenario has the requestor dealing directly with both the identity provider/STS and the pseudonym service in order to match identities with tokens with resources. The other scenario has the requestor dealing with an identity provider/STS that calls on a pseudonym service in order to automatically make the necessary associations.
334
Enterprise Web Services Security
WS-SECURECONVERSATION Web Services normally use a simple request and response model where a transaction consists of a requestor making a simple request followed by the provider returning a simple response. In some situations, however, the two parties need to exchange a number of messages and do not want to incur the overhead associated with separately authenticating and authorizing each message sequence. The metadata exchange between two STSs is a case in point; a long-running series of messages between two principals would be another. Security Context WS-SecureConversation introduces the concept of a session context, composed of a shared secret between two principals, which enables the principals to securely exchange messages within a given session’s lifetime [WSSecureConversation04]. WS-SecureConversation defines the element for communicating security context and a mandatory subelement for attaching a unique URI the sender and receiver can use to refer to the shared context. A session begins when one of the principals creates a shared context by Creating a security context token and sending it to its partner via an unsolicited
Requesting a security context token from an STS via a and receiving a containing a pointing to the token and a pointing to the shared secret Negotiating a security token context with its partner using WS-Trust’s fourstep negotiation protocol Figure 14.3 overlays WS-SecureConversation’s basic concepts on WS-Trust’s security trust model. Context Binding A security context is a shared secret. Once the principals share a secret, they can reliably exchange messages by signing messages using the shared secret or by deriving keys from the shared secret and then using the derived keys to sign and encrypt messages. WS-SecureConversation recommends using derived keys associated with a security context rather than the shared secret itself. For more complex use cases, WS-SecureConversation also defines protocols for propagating shared secrets among principals and amending contexts.
Establishing and Communicating Trust
335
Security Token Service
Shared Secret
Re
qu
es
tf
ro m
ST S
Step1: Create security context token representing a shared secret between the parties
Requestor
Web Service
Create and send Negotiate with partner
Signed/Encrypted Messages
Step 2: Exchange one or more messages using either the shared secret or derived encryption keys
FIGURE 14.3 WS-SecureConversation basic concepts.
XKMS The XML Key Management Specification (XKMS) builds on XML Signature and XML Encryption, providing a service for registering and distributing public keys for use with those standards [XKMS04]. XKMS defines and describes the protocols for two key services, a registration service and an information service, as illustrated in Figure 14.4. Let’s walk through an example to explain these services. XML Key Registration Service Let’s assume a requestor wants to send an encrypted message to a Web Service. One of the first questions that arises is, how does the requestor discover the Web Service’s public key? When we look at this question more closely, we find there are actually two parts to the question: the first is, how does the Web Service make its public key known? The second is, how does the requestor discover this key? XKMS provides an XML Key Registration Service Specification (X-KRSS) that answers the first part of the question: how does the Web Service make its public key known? The X-KRSS service defines the protocols for registering, revoking, and recovering key pairs. So, the first step in the process is for the Web Service to register its public key with the X-KRSS service as depicted in Figure 14.4. When the Web Service registers the key, it can associate additional information, such as a name, identifier, or set of attributes, that others can use to help locate the key.
336
Enterprise Web Services Security
Step 3: Send encrypted message Requestor
Step 2: Discover Key
Web Service
Step 1: Register Public Key
X-KISS Service
X-KRSS Service Key Store
FIGURE 14.4 The XKMS model.
XML Key Information Service The second step is for the requestor to discover the key. XKMS provides the XML Key Information Service Specification (X-KISS), which defines protocols for both locating and validating keys. In our example, the requestor would use an X-KISS service’s locate function to discover the key it needed as illustrated by step 2 of Figure 14.4. The requestor may discover the key by name, identifier, or attribute. With the public key information, the requestor can encrypt the message before sending it to the Web Service in step 3. Though the example shows the X-KRSS and X-KISS services as being separate, a single service can provide both functions. Our example illustrates using X-KISS for discovering a public key in order to complete an encryption operation. Requestors can also use X-KISS services for interpreting digital signature elements and for converting the information they may have in a element into a form they can use. For example, a requestor may use an X-KISS service to Retrieve a KeyValue based on a KeyName Retrieve both a KeyName and KeyValue based on a RetrievalMethod Retrieve a KeyValue by parsing an X509v3 certificate Validate the binding between a key and a name, identifier, or set of attributes While our example has focused on requestors using XKMS services, the XKMS’s services are equally valuable to the corresponding Web Service, which can use them to discover, interpret, and validate signatures and key information pertaining to requestors as well.
Establishing and Communicating Trust
337
XML Key Management Service Bulk Operations The X-KRSS protocols are designed to handle key registration one key at a time. Key factories such as those associated with smart cards, cable modems, public key infrastructure (PKI) certificate authorities, and token devices need to be able to register keys in bulk. The XML Key Management Specification Bulk Operations (X-BULK) specification builds on X-KRSS to provide the additional elements and protocols necessary to support these types of operations including the ability to correlate batch requests and responses [XBULK02].
SAML Single sign-on has been a Holy Grail within the computer industry for almost as long as there has been a computer industry. The promise of single sign-on is that a user or service can authenticate once and then transparently use whatever resources or services are needed with whatever additional authentication may be required occurring transparently behind the scenes. Single sign-on has historically been an identity management problem with three traditional solution approaches: Trusted Tickets: Users authenticate to a common ticket granting service. All other services recognize and honor tickets issued by the service, thereby eliminating requirements for reauthentication. Synchronized Credentials: User credentials in one system or domain remain synchronized across systems and domains through password synchronization, credential cross certification, or another synchronizing technique. Pseudonym Services: A proxy service maintains a repository of user credentials and credential mappings and provides the credentials to depending services (those needing context dependent credentials) when needed. As we saw in our earlier discussion of WS-Federation, the Web Services specifications support these traditional approaches by providing federation mechanisms for exchanging credential information across domains and by identifying key services such as attribute and pseudonym services for tying credentials to user and resource attributes and to alternate identities. Single sign-on interoperability in a cross-domain environment was one of the major drivers behind SAML [SAML03, SAML04]. SAML defines a framework for exchanging authentication and authorization information across domains in the form of assertions rather than identities or traditional security tokens. SAML defines a language for expressing assertions, the protocols for requesting and obtaining assertions from SAML authorities, and the bindings for mapping SAML onto messaging and transport protocols.
338
Enterprise Web Services Security
An assertion is a coded statement that a SAML service creates in response to the successful completion of an event. Three major types of assertions of interest are: Authentication Assertion: Subject was authenticated using some means at a given point in time Attribute Assertion: Subject possesses additional attribute information that may be useful to a request Authorization Decision Assertion: Subject should be granted access to a specified resource Figure 14.5 illustrates the basic processing cycle for a requestor needing services in a SAML environment. The process begins with a requestor (a subject in SAML terminology) using its credentials to request some set of assertion references from appropriate SAML services (step 1 in the process). The SAML services grant the
2 Policies
Authentication Authority
1
Attribute Authority
Authorization Authority
Credentials
3 Requestor (Subject)
XML Document Authentication Assertion
4 Attribute Assertion
Web Service Policy Enforcement Point
Authorization Assertion
5 6 Policy Decision Point
FIGURE 14.5
The SAML model.
Assertion References
Establishing and Communicating Trust
339
requested references after validating the subject’s credentials and comparing the requested permissions against policy (step 2 in the process). Assuming the subject is authorized to perform the requested functions, the assertion references become part of the message (step 3) that is communicated to the object of the request, the Web Service, in step 4. The Web Service is the policy enforcement point (PEP). In the SAML model, the PEP is the entity responsible for enforcing actual access control decisions. The PEP performs this function by calling on a policy decision point (PDP), as illustrated by step 5 in the model, to interpret the given request in terms of the policy in force and to render an appropriate access decision. The PDP uses the assertion references from the SAML services in deriving its decision. The PDP requests the associated assertions from the issuing authorities and validates the user’s request based on these assertions and returns an authorization decision either permitting or denying access. Listing 14.3 illustrates a simple SAML authentication assertion. The assertion consists of an assertion ID, an issuer ID and timestamp, a subject identifying the authentication data, and the conditions under which the assertion is valid. LISTING 14.3
Simple SAML Authentication Assertion
340
Enterprise Web Services Security
... ... ...
XACML In our discussion of SAML above, we mentioned the role of the PDP but intentionally left the decision step itself rather vague. The reason for this is that the Organization for the Advancement of Structured Information Systems (OASIS) has published a second, complementary standard that defines A standard set of XML elements for expressing access control policies A request and response protocol for issuing requests and responses A policy language model for processing policy requests XACML defines a hierarchical model for defining and evaluating policies [XACML03]. A policy document containing either a policy set or policy is at the root of each policy. A is the elementary element in a policy. A describes the target to which the rule applies, the effect of the rule, and an optional condition. The rule’s target identifies the set of resources, subjects, and actions covered by the rule. The rule’s effect indicates the consequence of the rule’s condition being met: whether the request should be Permitted or Denied. The rule’s optional condition is a Boolean expression for evaluating the request against the target. The condition is optional because in many instances the target implies the predicate. For example, the target may be , which matches any subject.
Establishing and Communicating Trust
341
A element may contain a target, one or more elements, a rule-combining algorithm, and an optional set of obligations. The policy’s target identifies the set of resources, subjects, and actions to which the policy applies. The rule-combining algorithm defines how rules are to be combined in reaching a decision. The obligations are a set of operations that should be performed in conjunction with the enforcement of the policy and are returned as part of the response to the PEP. A element may contain a target, one or more elements, a policy-combining algorithm, and a set of obligations. The policy-combining algorithm defines how policies are to be combined in reaching a decision. The other components are as described above. The XACML specification defines four combining algorithms: Deny Overrides: Return Deny if any evaluation returns a Deny. Permit Overrides: Return Permit if any evaluation returns Permit. First Applicable: Return result from first applicable evaluation or NotApplicable if none apply. Only One Applicable: Return result from evaluation if only one rule applies; otherwise return Indeterminate if multiple evaluations apply or NotApplicable if none apply. XACML’s processing model includes many of the same actors as SAML’s model. Figure 14.6 illustrates using SAML and XACML together. In this depiction, the process begins with a requestor sending a request for a resource to the Web Service (step 1), which is acting as the SAML PEP. The Web Service sends the request to a SAML PDP (step 2). The SAML PDP issues a decision request to an XACML context handler (step 3). The context handler calls on an attribute authority, which is also acting as an XACML policy information point (PIP), to collect subject, resource, and environment attributes (step 4). The PIP retrieves the requested attributes from an attribute store (step 5) and returns them to the context handler (step 6). The context handler passes the target, attribute, and environment information to an XACML PDP service, requesting a decision (step 7). The XACML PDP queries an XACML PolicySet store (step 8), invokes the appropriate rule and policy-combining algorithms, and returns an authorization decision along with any obligations to the context handler (step 9). The context handler returns the decision along with any obligations to the SAML PDP (step 10), which in turn returns it to the Web Service (step 11).
342
Enterprise Web Services Security
Web Service Policy Enforcement Point
1 Requestor (Subject)
2
11
SAML Policy Decision Point
3
10
9 XACML Policy Decision Point
XACML Context Handler
Decision
7 Target, attribute, and resource information
8
Attributes
4
PolicySet
5
6
Attribute Authority (Policy Information Point)
Subject, resource, and environmental attributes
FIGURE 14.6 The XACML processing model.
One actor that is different between the SAML and XACML processing models is the context handler. XACML defines the context handler as part of an abstraction layer that permits XACML to be used with any legacy format. The role of the context handler is to natively handle requests from a particular type of PEP and to convert those requests into a canonical form or XACML “context.” Though the context handler is shown as a major processing component in our illustration, in the case of SAML, the context handler can be as simple as an XSLT since both SAML and XACML are XML schema–based languages.
Establishing and Communicating Trust
343
Listing 14.4 illustrates a simple XACML policy. The policy applies to any subject, resource, or action. It contains two rules. The first rule returns a Permit response for requests from XYZ Corporation users. The second rule returns a Deny response for everyone else. The RuleCombiningAlgId on the tag specifies using the permit-overrides combining algorithm for evaluating the policy. LISTING 14.4
Simple XACML Policy
This is simple XACML policy to illustrate some of the language constructs CN=A User,OU=XYZ User,O=XYZ Corp, C=US
344
Enterprise Web Services Security
Deny everything not permitted by Simple Rule
SUMMARY Communicating in a Web Services environment hinges on trust and the ability to create trust relationships. WS-Security lays the foundations for creating trust relationships by providing the standards for communicating security tokens through SOAP messages between principals. WS-Trust builds on this foundation to define the elements and protocols for requesting, renewing, and validating security tokens with third-party STSs. WS-Federation builds on WS-Policy, WS-Security, and WS-Trust to extend the model to cross-domain scenarios and introduces additional services such as attribute and pseudonym services needed in this environment. WS-SecureConversation adds the concept of a security context that allows services, such as domain STSs, to exchange multiple messages without having to reauthenticate or reauthorize after each request. XKMS adds registration and information services for managing keys in a cross-domain environment. SAML offers an alternative to traditional approaches to solving the crossdomain, single sign-on problem. SAML propagates assertions rather than identities and provides a model for making authentication and authorization decisions. XACML provides a language, protocols, and bindings for describing access control policies as sets of rules and a processing model for evaluating those rules in order to reach an access decision.
REFERENCES [SAML03] Maler, Eve, et al., “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1.” Available online at http://www.oasisopen.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf, September 2, 2003. [SAML04] Hughes, John, et al., “Technical Overview of the OASIS Security Assertion Markup Language (SAML) Version 1.1.” Available online at http://www. oasis-open.org/committees/documents.php?wg_abbrev=security, July 22, 2004.
Establishing and Communicating Trust
345
[WSFederation03] Bajaj, Siddharth, et al., “Web Services Federation Language (WS-Federation).” Available online at http://www-106.ibm.com/developerworks/webservices/library/ws-fed/, July 8, 2003. [WSMetadata04] Ballinger, Keith, et al., “Web Services Metadata Exchange (WSMetadataExcahnge).” Available online at http://msdn.microsoft.com/library/ en-us/dnglobspec/html/ws-metadataexchange.pdf, September 2004. [WSSecureConversation04] Anderson, Steve, et al., “Web Services Secure Conversation Language (WS-SecureConversation), Version 1.1.” Available online at http://www-106.ibm.com/developerworks/library/ws-secon/, May 2004. [WSSecurity04] Nadalin, Anthony, et al., “Web Services Security: SOAP Message Security 1.0 (WS-Security 2004).” Available online at http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf, March 15, 2004. [WSTrust04] Anderson, Steve, et al., “Web Services Trust Language (WS-Trust) Version 1.1.”, May 2004. Available online at http://www-106.ibm.com/developerworks/library/ws-trust/. [XACML03] Godik, Simon, et al., “eXtensible Access Control Markup Language (XACML) Version 1.0.” Available online at http://www.oasis-open.org/ committees/download.php/2406/oasis-xacml-1.0.pdf, February 18, 2003. [XBULK02] Hughes, Merlin, editor, “XML Key Management Specification Bulk Operations.” W3C Working Draft. Available online at http://www.w3.org/ TR/xkms2-xbulk/, March 18, 2002. [XKMS04] Hallem-Baken, Phillip, editor, “XML Key Management Specification Version 2.0.” Available online at http://www.w3.org/TR/xkms2/, April 5, 2004.
This page intentionally left blank
15
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services In This Chapter Enterprise Web Services Step 1: Identify the Parties Involved Step 2: Identify Relevant Domain Infrastructure and Capabilities Step 3: Identify Necessary Security Services Based on Local Policies Step 4: Identify Gaps and Project a Virtual Trust Domain Step 5: Allocate New Infrastructure Services across Physical and Logical Domains Step 6: Allocate Security Services across Actors Step 7: Create and Distribute Discovery and Policy Artifacts Summary
ver the past 14 chapters, we have laid the foundations for addressing security for enterprise-level Web Services applications in a systematic and coherent way. Now that we have the building blocks in place for building secure enterprise-level Web Services applications, we can present the whole picture in a unified way. In this chapter we will review the points made earlier and show how these can be brought together to help support the design and deployment of a secure online Web Services–based system. After discussing what we mean for a Web Service to be an enterprise Web Service, we will present a series of models to help you look at that service’s security-relevant characteristics within the overall context of the enterprise’s security policy and infrastructure in order to ensure that the service’s security mechanisms are complete and appropriate for the environments that it must support. We will also look at how projecting a virtual trust
O
347
348
Enterprise Web Services Security
domain helps simply this process. As mentioned earlier, one of our goals has been to demystify the whole area of information security and how it applies to enterprise Web Services.
ENTERPRISE WEB SERVICES An enterprise Web Service is one that meets the needs of an enterprise. The enterprise may be an academic institution, a business, or a government organization, and can be either real or virtual in terms of its makeup. An enterprise Web Service may scale vertically, serving a specific part of the enterprise, or horizontally, serving elements across the enterprise. In its capacity as an enterprise Web Service, the Web Service may cross any number of enclave or domain boundaries. In order to be an enterprise Web Service, the Web Service must support the enterprise’s policy, infrastructure, and security requirements. It is this last set of requirements that we are most interested in here. The mechanisms implementing these requirements represent the service’s security-relevant characteristics. What would the security-relevant characteristics for an enterprise Web Service be? Anything having to do with Important service or infrastructure components or the connections between them The position or function of security mechanisms within either the service or the underlying infrastructure The components or services making security-related decisions The strength of the security mechanisms providing a particular securityrelated service Security-relevant information flows The sensitivity of the information or the capabilities the service supports Some examples of security-relevant characteristics include the mechanisms the service uses to implement confidentiality, integrity, and availability requirements and the client communities and security domains the service supports. As we discussed in Chapter 6, you can look at security from either the security policy’s or the Web Service’s point of view, both being different aspects of the same problem—one is inside-out and the other is outside-in. In Chapter 6, we took the inside-out viewpoint in order to develop security policy based on a defensein-depth strategy and to give you an appreciation of the layered nature of the problem. In this chapter, we take the service’s viewpoint as we look at a few fun-
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
349
damental questions about a Web Service’s security and deployment characteristics in order to develop a general model for securing enterprise Web Services. An organization must ask these questions whenever a service is deployed for the first time into a new space or whenever a security-relevant change occurs in the service’s security characteristics or in the supporting infrastructure. The answers to these questions will help drive the security solution put into place so that it adequately protects the Web Service and the information and capabilities it represents.
STEP 1: IDENTIFY THE PARTIES INVOLVED The first step is to identify all the actors involved with the Web Service. At a minimum, there is a Web Services client and a Web Services server involved in every Web Services transaction. Other actors become involved with either the client or the server playing some specific, supporting role. Figure 15.1 illustrates the relevant actors that may be involved either directly or indirectly in any given transaction. Though not illustrated in the figure, some actors may appear multiple times, depending on the diversity and complexity of the target environment.
Token Service
Web Services Client
UDDI Service
Intermediaries
WSDL Service
FIGURE 15.1 Potential actors and roles.
Web Services Server
Supporting Service
350
Enterprise Web Services Security
You can think of these additional actors as being the fan-in and fan-out of a given Web Services context, where the context is a particular client’s usage of the service. They can be different for any client-server pair. Fan-out applies to both the Web Services client and server; it is the number of actors the client or service call to complete a transaction. Intermediaries between the client and server would be part of the client’s fan-out. Fan-in, on the other hand, only applies to the Web Services server; it is the number of other services the server must call to complete the transaction and any services those services may call. Who Are the Clients? The first question has to be, who are the service’s consumers. In any transaction some party plays the part of the Web Services client. Is that role played by other Web Services servers, a portal, a user from a Web browser, or all of the above? It is important to identify all of a given Web Service’s clients in order to scope that Service’s context properly. How Will Clients Access the Service? For each client or class of clients, the next question is, how will they access the service? Will they access the service via a fixed infrastructure, a dial-up connection, or a wireless network? As we will see later, how clients access the service is one factor driving the security mechanisms that must be in place. How Will Clients Discover the Service? At this point, we have a mapping of the two major endpoints. The next step is to begin systematically identifying the additional players supporting any given transaction. There are three parts to the service discovery question and they are generally interrelated. The first part is, how do clients discover the Web Service’s existence? The answer may be through a Universal Description, Discovery, and Integration (UDDI) directory entry. If so, the UDDI service becomes a party to the transaction. The second part is, how do clients discover the Web Services’ interface requirements—its Web Services Description Language (WSDL) file? The answer again may be through the UDDI service or it may be through a WSDL service. If the latter, there is yet another actor involved in the transaction. The third part of the question is, how do clients discover the security policy controlling the Web Service? As we discussed in Chapter 7, WS-PolicyAttachment provides mechanisms for attaching policies to either WSDL elements or UDDI entries. If some other mech-
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
351
anism is being used, it may introduce yet another actor into the mix of those involved in the transaction. What Intermediaries Are Involved in the Transaction? The next question revolves around how clients create the channel between themselves and the Web Services server. Will the Web Service’s clients deal directly with the Web Service or are intermediaries for routing or referring messages involved? If there are intermediaries, what are their roles? As we will see later, gateways are frequently involved in crossing domain, enclave, and technology boundaries. If they can be identified at this point, they should be called out. If they cannot be identified at this point, that is OK. We will look at specific techniques to help identify them below. Does the Web Service use Other Services? The questions so far have dealt with the Web Services client. The final step here is to shift the focus to the Web Services server and ask the question about its supporting services. Is the Web Service in question self-contained or does it use other services? If it uses other services, each of them represents additional actors to the transaction.
STEP 2: IDENTIFY RELEVANT DOMAIN INFRASTRUCTURE AND CAPABILITIES The answers to the questions in the first step produce a list of actors and their roles. The only one shown in Figure 15.1 not covered so far is the security token service (STS), which steps 3 and 4 below will cover once the underlying domain infrastructure is understood and the security needs of that infrastructure have been identified. Given a list of actors and roles, the next step is to begin identifying the securityrelevant infrastructure in place or needed to support the Web Service. We can do this through a series of questions revolving around the general model illustrated in Figure 15.2. Figure 15.2 takes the perspective of an organization offering a Web Service from its internal intranet environment to Web Services clients located on connected extranets, the Internet, and within attached enclaves. A simple reorientation permits the use of the same model to discuss any Web Service being provided or accessed within any of the various environments. A series of simple expansions, by adding additional domains or enclaves, permits its use to discuss Web Services being deployed in extremely complex environments.
352
Enterprise Web Services Security
Web Services Client
Internet Web Services Client
Web Services Client
Web Services Server
Web Services Client
Enclave Intranet
Extranet
FIGURE 15.2 General enterprise model.
How Many Security Domains are Involved in Supporting the Service? The first step in identifying the relevant domain infrastructure supporting a Web Service is to lay out the list of actors and roles identified in step 1 against the general model depicted in Figure 15.2. This provides a first cut at potential risks, the security domains and policies involved, and the security infrastructure that is already in place. Presumably if a service is spanning multiple domains and enclaves, this is because of the demands of the policy in place. Otherwise, why are the domain and enclave boundaries there? What Security Services are Provided in the Domains Involved? Given the list of the domains involved, the next step is to catalog the security services that are already in place. Security services are the mechanisms supporting authentication, confidentiality, and integrity within the domain. This information is needed in the third step when we look at the specific services that are needed. What Token Services are Involved in Providing those Services? The security services within a domain or enclave are generally provided by, or at least supported by, one or more STSs. Web Services clients and servers by default will normally look to local STSs first to satisfy their needs. The purpose of this question is to identify any local services not identified earlier and to add those services to the list of potential actors created in Step 1.
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
353
What Supporting Services are Provided in the Domains Involved? Supporting services within a domain or enclave include those supporting service discovery, routing, referral, and invocation. Web Services clients within a domain or enclave first look to local services for meeting their needs. The purpose of this question is to identify the local services and to add them to the list of potential actors created in Step 1.
STEP 3: IDENTIFY NECESSARY SECURITY SERVICES BASED ON LOCAL POLICIES All security services are not always needed in all environments. The security services needed are a function of the risks and the sensitivity of the information or capabilities involved. Each domain or enclave will have a specific set of requirements implementing its local policies. The purpose of this step is to identify the security services that are needed for interactions between each pair-wise set of actors identified in steps 1 and 2 based on these local policies. Figure 15.3 illustrates a general model for this purpose, where each interaction consists of a client, a server, and a channel between them. The client in this model is generally, but not necessarily, the Web Services client. Different services may assume the client role as you fan-out from the Web Services client and work your way toward the Web Services server. The Web Services server itself becomes the client in the final steps as you look at the services that it uses. The server is any of the security or support services, including the Web Services server, that the client in a given context needs to interact with as part of completing a transaction. It is OK at this juncture that one set of policies may control one actor while another controls the other. Step 4 will look at reconciling these policy differences. At this the point, the objective is to simply catalog them. Are Authentication Services Needed? Since one of the first things two parties often want to do is authenticate one another, assuming authentication is necessary, the first question we need to ask is, what authentication services are needed, by which party, using what type of credential? The answer to this question will identify whether an STS is involved in the process, whether a secure channel is necessary for the credential exchange, whether there is a potential token mismatch or provisioning issue, and so on. As we discussed in Chapters 9 and 13, many options are potentially available for representing identities and creating trust relationships. Depending upon the environment, each domain or enclave may implement a different strategy, and some may implement
354
Enterprise Web Services Security
A
Channel
Client
C
A AC
I
A
AC
Server
C
I
Authentication
Authorization/Access Control
C
Confidentiality
I
Integrity
FIGURE 15.3 General security service model.
multiple strategies. Answering this question within the context of the specific domains and enclaves involved provides a list of the domain and enclave requirements for a particular service that we will use in the next step when we get to our gap analysis. What Resource or Information Needs To Be Protected? Given that two parties want to exchange information or utilize a resource, the next question is, what resource or information needs to be protected? Is the issue privacy of the message exchange, the integrity of the transaction on the server, the indisputable identity of either party? Answering this question will help answer the next set of questions. Are Authorization and Access Control Services Needed? Depending on whether it is a resource or information that needs protection, authorization or access control services may be needed to protect that resource or information. As we discussed in Chapter 9, multiple options are available for providing authorization and access control services, depending upon the type of resource or information in question and the supporting environment. Each authorization or access control service will generally use some form of identity (either
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
355
that of the client or an intermediary) to control access, and that identity may not be the same one that was used to authenticate the two parties. The goal here is to identity both the service and its requirement because its requirements could involve the introduction of additional actors into the equation. For example, a particular service may use X.509 certificates for authentication and a Security Assertion Markup Language (SAML) service for authorization. The goal of our question when applied to this example is to reveal the requirement for the service’s clients to provide both their X.509 certificate and a SAML assertion as part of their service request and to identify the SAML service as a new actor in the overall transaction. Questions about authorization and access control requirements can also reveal additional questions about what services are needed, at what levels, and so on and can raise questions about how identities will be passed or proxied among those services. Are Confidentiality Services Needed? The sensitivity of the information or exchange between the parties should drive the answer to this question. As we discussed in Chapter 10, because confidentiality is a requirement, there are a number of options available and questions that must be answered to help determine the right mechanisms. One of the first questions is, at what level? Do you need to encrypt the channel or just the message? If just the message needs to be encrypted, what information within the message needs to be encrypted, that is, is message, element, or content-level encryption necessary? Is any of that information needed by intermediaries? If so, is that information only relevant to the intermediary or is it needed by multiple parties? Are all the intermediaries trustworthy with regard to the sensitivity of the information involved? Given the answers to these questions, the next questions are what algorithms to use and at what strengths. There are two sometimes-opposing viewpoints when looking at this question. One is from the perspective of the sensitivity of the information being protected; the other is from the perspective of the capabilities of the parties involved. Given the sensitivity of the information, you may want to use the strongest algorithm and longest key length available to protect it. However, all the clients, the server, or some of the intermediaries involved in processing the message may not have or be able to support that particular algorithm or key length. This can lead to using multiple encryption algorithms with multiple key lengths within the same message. Encryption also comes at a performance cost. The client incurs some amount of processing overhead for each message component it encrypts. The server and any intermediate or supporting actors also incur some level of processing overhead for the message components they decrypt. As we mentioned in Chapter 13, there are options regarding where within the protocol stack the encryption and decryption operations are performed and a choice between hardware and software encryption.
356
Enterprise Web Services Security
As a general rule, the processing overhead increases as you move up the stack from the hardware through the software layers. A corollary to this line of questioning is the key management question. As we discussed in Chapters 10 and 14, various key management strategies and protocols can come into play. Each algorithm and key length combination potentially represents a key distribution question. How do you get the right keys to the right parties? Answering this question can lead to the introduction of new actors or to the need to support multiple algorithms and key lengths within a given message. Are Integrity Services Needed? Integrity services come into play to detect tampering and for nonrepudiation. Digital signatures are one of the most prevalent techniques for implementing this service. Assuming integrity services are needed, some of the questions that must be answered include, what information needs to be signed, by whom, using what algorithms? As we discussed in Chapter 10, multiple options are available, and as was the case with the confidentiality question, there is also a need versus capability aspect to this question. You can look at the set of confidentiality questions above and substitute signature for encryption and signature algorithms and keys for encryption algorithms and keys into those questions and use them to address integrity as well. Digitally signing a message or message parts also comes at a performance cost. The client incurs some amount of processing overhead for each message digest it computes and each signature it creates. The server and any intermediate or supporting actors also incur some level of processing overhead for each signature they verify. Again, there is a choice of where within the protocol stack these operations are performed and a choice between hardware and software mechanisms. As was the case with encryption, there is a performance penalty as you move up the stack.
STEP 4: IDENTIFY GAPS AND PROJECT A VIRTUAL TRUST DOMAIN The first three steps produce A list of the actors and their interactions An identification of the existing security domain and enclave infrastructures and their capabilities including local security and supporting services The requirements for security services between each pair-wise set of actors including any inconsistencies in security services based on local domain or enclave-specific policies
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
357
The next step is to use a gap analysis of the technologies, services, and provisioning strategies involved. The gap analysis identifies the components of a virtual domain across the entire space, as shown in Figure 15.4, which could theoretically support Web Services clients from any domain or enclave accessing the Web Services server in question. The virtual domain is shown as a projection of the domain or enclave hosting the service because it is that domain or enclave’s policies that establish the minimum threshold across the space. As we will discuss, bringing clients and services with equal or more stringent policies into compliance can be relatively straightforward. Bringing clients and services with lesser policy requirements into compliance can be challenging.
Web Services Client
Internet Web Services Client
Web Services Client
Web Services Server
Web Services Client
Enclave Intranet
Extranet
Virtual Domain
FIGURE 15.4 Projecting a virtual domain.
The gap analysis’ goal is to identity four things the solution must address: 1. 2. 3. 4.
Missing services Differences in services Security-relevant differences across domains and enclaves New boundaries and boundary services
358
Enterprise Web Services Security
Missing Services There are two types of missing services: those where the service is missing altogether (this is the first time a given service has ever been needed within the enterprise) and those where the service is missing within a particular domain or enclave. The analysis in steps 1 and 3 should have revealed any services that are missing altogether. This would be a situation where the Web Services client or server, since they are the only two required actors, need some service that doesn’t exist. An example is when discoverability is a requirement, yet there is not a discovery service available. The question becomes, do you remove the requirement, provision a new service meeting the requirement (such as UDDI), leverage an existing service (such as the UDDI Business Registry [UBR]) belonging to someone else, or handle the requirement in some other way (out-of-band, for example)? Services that are missing within a domain or enclave are readily identified from the information collected in step 3, as they are services where the client must cross a domain or enclave boundary in order to access that service’s capabilities. Policy determines whether this cross-domain access is OK or not. For example, it may be perfectly OK for a Web Services client on the Internet to access the WSDL service on an enterprise’s intranet (the enterprise may have implemented the WSDL service as an open service that is accessible from all domains and enclaves, for example). If the policy does not permit the type of cross-boundary interaction required, the options are to Not permit the interaction (which could imply some set of clients are not able to use a particular service) Provision the missing service so that it is accessible from the domain in question (notice we didn’t say within the domain because the organization may want to implement the WSDL service that is accessible from all domains) Elevate the client needing the service to meet the policy requirements to access the service It may not be practical to provision all services to all environments or to elevate all clients to meet a single set of policies, so some tradeoffs may be involved. The result of these tradeoffs may mean some set of Web Services clients cannot access a particular Web Services server or that the clients access the server through either a relaxation of policy or through one-off security solutions within a particular domain or enclave. Having many denied clients or one-off solutions could be an indicator of the need to provision a new service within a particular domain or enclave.
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
359
Differences in Services Different services can come in a variety of different implementations. For example, there are different kinds of identity tokens and forms of both encryption and signing algorithms and the latter can be of different strengths. These differences can occur both within boundaries and across boundaries. The analysis in step 3 flagged these differences based on the domain or enclave policies in effect. Presumably clients and servers within a domain or enclave are capable of meeting the local policies. If these capabilities are inconsistent with those needed by the remote domain, it may indicate that new capabilities need to be provisioned. The goal at this juncture is to examine each difference and identify the options for addressing them. For each difference, four dynamics come into play in identifying available options: 1. 2. 3. 4.
The policy that must be met The capabilities that are currently available but not being used The capabilities that can be made available The equivalents that can be found
The policy that must be met is that of the domain or enclave hosting the server side of the relationship. For example, if a particular domain requires 128-bit, Advanced Encryption Standard (AES) encryption for accessing a service within it, then clients of that service must be able to meet that minimum or find an acceptable equivalent. This raises five possibilities: 1. 2. 3. 4. 5.
Leverage an existent, but latent capability. Provision the missing capability. Find an equivalent capability. Revise the policy. Deny access to the service.
Clients may already possess the capability they need to meet the requirement but may not be using it within their own domain or enclave because their local policy doesn’t require it. In this situation, the solution is straightforward; the client simply needs to use the proper capability whenever it accesses the service. The client of course needs to recognize that it needs to do something other than the norm— something it can potentially garner from the service’s UDDI or WSDL entry if the client is designed to dynamically discover and act on that type of information. An example of this situation is a case where a client is using 112-bit, triple–Data Encryption Standard (DES) in its own domain based on the local domain policy,
360
Enterprise Web Services Security
but is capable of using 128-bit AES if needed. The client discovers the need to use the different algorithm and simply makes the right service call or parameter adjustments to do so. If the client doesn’t possess the necessary capability, then one option is to determine how to provide it. An example of this situation is where clients within one domain or enclave use user IDs and passwords but need X.509 certificates to access a particular service. The solution could be to provision X.509 certificates from the certificate authority (CA) controlling the service either directly to the clients that need the service or to a boundary proxy service that can act on their behalf. In either case, the service would continue to use X.509 certificates and the client would be able to provide one either directly or through a proxy. A second option is to identify an equivalent capability that is acceptable to the domain or enclave hosting the service and to the client. If we go back to the encryption example, let’s assume the client cannot produce 128-bit, AES-encrypted messages but can produce 112-bit, triple-DES. If triple-DES is acceptable to the domain or enclave hosting the service, then an option could be to let clients use either AES or triple-DES to access the service, depending on their capabilities. Note that expanding the options may imply not only a change to the service (so that it can accept either) but also to the underlying security policy. What if a client can’t support a capability, it can’t be provisioned, and an equivalent can’t be found? In that situation, the options are to change the policy or deny the service to some set of clients. Security-Relevant Differences in Levels Each domain and enclave potentially represents a different set of security policies. Some of the differences between these policies may be security relevant and some not. In the example above, where it was acceptable for a client in one domain to simply use a different encryption algorithm when crossing the domain boundary, there wasn’t a security-relevant difference between the two domains in terms of the clients, just in the implementation of the confidentiality service. Presumably in this scenario any client in one domain could ask for any service in the other and vice versa, they simply need to use an acceptable encryption algorithm for the transaction. What if that isn’t the case? What if there is a security-relevant difference between the domains? Addressing security-relevant differences between domains is one of the most difficult problems to solve when deploying a service. By definition, the two domains or enclaves are at different levels in this situation (one is higher [more secure] than the other), and the higher-level domain’s policies dominate those of the lower-level domain. Ensuring security integrity in this situation requires close attention to how transitions across the boundary occur. Figure 15.5 illustrates a
361
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
basic framework for addressing this issue: a client in one domain needs to use a service in another, any or all security services may be required, and the channel between the client and server must cross a boundary separating the two domains. The approach to the problem and its possible solution depend on whether the client or the service is in the higher-level domain.
Domain A
Boundary
A
A Client
C
A AC
Domain B
Channel
I
C
A
AC
Server
I
C
I
Authentication
Authorization/Access Control
C
Confidentiality
I
Integrity
FIGURE 15.5 Addressing cross-domain security-relevant differences.
Client Is in the Higher-Level Domain
This is a scenario where the client in the higher-level domain needs to write to (execute) an object (service) in the lower-level domain. The client being in the higher level domain is analogous to the no write-down/no read-up situation in a multilevel access control (MAC) environment that we discussed in Chapter 9. We can therefore apply similar types of rules. Write-down and read-up operations are generally permitted in this situation, provided that what the client is allowed to write-down is strictly controlled, because the security policies in the higher-level domain dominate those in the lower level
362
Enterprise Web Services Security
and the risks are lower. The security services depicted in Figure 15.5 may require some form of translation or transformation, as they cross the domain boundary, but other than that, access is straightforward. The client calls the service; it executes and returns a result. The translation and transition services for crossing the domain boundary all become potential intermediaries in the original service delivery diagrams from step 1. The Web Services Server Is in the Higher Domain
If the service is in the higher-level domain, then the question changes to one of how to extend the higher-level domain’s policy to encapsulate prospective clients in the lower-level domain. In some situations it may be OK for clients in the lower-level domain to execute the service in the higher-level domain. Tunneling could be an option in this situation. Assuming the client is trusted, tunneling allows it to communicate securely across the untrusted domain. Secure Sockets Layer (SSL) is one form of tunneling. Virtual private networks (VPNs) are another. Tunneling may imply changes in security policies, client capabilities, or boundary services. In situations where policy, client, or boundary changes aren’t possible, rehosting the service either in the lower-level domain or in a boundary enclave could be an option in situations where the lower-level domain’s policies sufficiently protect the data or the service in question. It isn’t always possible to provide services from higher-level domains to clients in lower-level domains or enclaves. The choice may ultimately boil down to one of some set of clients not being able to access some set of services. New Boundaries and Boundary Services The discussion thus far has primarily focused on situations where some level of domain infrastructure already exists. The first time an organization provides a service within a domain or to a new technology base, it must carefully look at the domain boundary and the services that may be needed there to maintain integrity within the domain. As we discussed in Chapter 6, introducing services into a new domain may require the introduction of firewalls, VPNs, guards, or special access services to protect the domain or enclave boundary.
STEP 5: ALLOCATE NEW INFRASTRUCTURE SERVICES ACROSS PHYSICAL AND LOGICAL DOMAINS The previous step may have identified a set of new services or capabilities that must be introduced into the underlying domain and enclave infrastructure in order to
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
363
create a virtual domain spanning the space. The services or capabilities may be targeted to clients within a domain, to a domain, or to boundaries between domains or enclaves. The purpose of this step is to allocate the new services or capabilities across the existing domain and enclave infrastructure. As we discussed in Chapter 13, the infrastructure underpinning a particular point may be physical, logical (statically defined), or virtual (dynamically defined), depending on whether it belongs to a single owner/operator, is established by bilateral agreement, or is dynamically interconnected in a logical relationship without a prior bilateral agreement. Figure 15.6 provides a model for allocating services across the infrastructure as a series of provisioning and transition points. Provisioning points are ones where a new service or capability needs to be provided or provisioned. Transition points are ones where a service or capability needs to be translated or transformed in some way. The model identifies security and support services with provisioning points within domains and enclaves and transition points at the boundaries. Provisioning may be in-band as part of a distribution service or out-of-band as an administrative function.
P P
T
Internet
P
T
T
T P
P P
P
T
T
Enclave Intranet
P Extranet
P
Security Service Provisioning Point
T
Security Service Transition Point
P
Support Service Provisioning Point
T
Support Service Transition Point
FIGURE 15.6 Service allocation model.
364
Enterprise Web Services Security
Security Services Security services include authentication, authorization, access control, confidentiality, integrity, and identity and key management. Provisioning these capabilities may involve identity and key creation and distribution, cross certification, directory maintenance, service distribution, and so on. Transformations include token, encryption, and signature pseudonym and translation services. Support Services Support services include those supporting service discovery, dynamic service invocation, and policy distribution. Provisioning these services may involve creating UDDI entries, updating WSDL service entries, creating or updating policy entries, or creating and distributing WSDL files. Transformations may involve translating TCP/IP addresses, DNS names, or WSDL port types or assignments. Service Distribution Strategy To centralize or not to centralize? That is the question. An enterprise can take various approaches to service distribution, depending on its policies. As we discussed in Chapter 6, the goal is to balance risk against resource implications. A centralized strategy looks at providing a centralized set of services across domains and enclaves and is more viable, the more homogenous the information and services are in terms of their sensitivity and the environments are in terms of their risks. A decentralized strategy looks at providing services locally within domains and enclaves and is more viable, the more heterogeneous the information and services are in terms of their sensitivity and the environments are in terms of their risks.
STEP 6: ALLOCATE SECURITY SERVICES ACROSS ACTORS Once the underlying infrastructure decisions are made, the next step is to allocate security services across the client, the server, and any intermediate processes. We will look at this problem from the standpoint of a Web Services client requesting a service from a Web Services server hosted within a trust domain formed by one or more systems in physical trust relationships. The Web Services server establishes a dynamic trust relationship with the client, thereby creating a virtual trust domain between them. The client and Web Services server then exchange whatever number of messages is relevant to the transaction, including the necessary security tokens and signing and encrypting message parts, as appropriate. The security policies in place, in combination with the strength of the security tokens, encryption, and digest algorithms in use, establish the strength of the trust relationship.
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
365
J2EE Environment Figure 15.7 illustrates a Web Services client accessing a Web Services server that has been implemented as a combination of a servlet and an Enterprise Java Bean (EJB) in a Java 2 Enterprise Edition (J2EE) environment. We selected this combination for illustrative purposes, recognizing that in a J2EE environment either a servlet alone or an EJB can just as easily be used to implement the Web Services server.
Virtual Trust Domain
Channel A A Client
I Servlet
EJB
C C
AC
I
Database Server AC
AU JSP Web Container
EJB Container
J2EE Server
Physical Trust Domain
A
Authentication
AU
Authorization
AC
Access Control
C
Confidentiality
I
Integrity
FIGURE 15.7 Component allocation in a J2EE environment.
In the configuration shown, the client contains an authentication element and both integrity and confidentiality capabilities. The authentication element in the client is responsible for obtaining whatever security tokens the Web Services server may require and encoding them within messages that it sends to the Web Services
366
Enterprise Web Services Security
server (see Chapters 11 and 14 to see how tokens can be obtained and encoded). Similarly, the integrity and confidentiality components are responsible for signing and encrypting the message, message elements, or element content (see Chapter 11 for a discussion of these operations). The Web Services client should be able to determine the server’s requirements from its published policy (see Chapter 7). The integrity and confidentiality components use algorithms the Web Services server will accept and incorporate the signed and encrypted content into the message along with the necessary Simple Object Access Protocol (SOAP) header elements for reversing the canonicalization, signing, encrypting, and transformation processes. The Web Services client sends messages to the Web Services server across a channel that may be secured. Chapter 9 contains a discussion of when the channel between the client and server should be secured and techniques for securing the channel. The authentication component within the servlet running on the J2EE server is responsible for authenticating requests it receives from the client. This component is allocated to the servlet because it is the first component on the server with access to the message, and the assumption is that the servlet performs most of the processing for the message. While we allocated authentication responsibilities to the servlet in this example, J2EE Container Authorization is an option that could be considered, provided it is available in the J2EE Applications Server supporting the implementation. The servlet also contains the integrity and confidentiality components. The integrity component is responsible for verifying the digital signature in the message and verifying that an intermediary did not change the content. The confidentiality component is responsible for decrypting the content. These services are in the servlet because you want to identify integrity and confidentiality issues with a message as early as possible in the process. As we discussed in Chapter 11, the elements in the SOAP message header determine signature validation and decryption order. The servlet would use this information to validate the signature and decrypt the message’s encrypted content. In the implementation shown, the EJB is responsible for data access, as it communicates with the database server. The figure shows one authorization and two access control components. The authorization component in the EJB Container is responsible for controlling access to the EJB, for example, for ensuring the client is able to execute that component. As we discussed in Chapter 9, the EJB Container may use container security and some form of role mapping based on the client’s identity for this purpose. The EJB itself contains one of the two access control components controlling access to the data; the database server contains the other one. Depending upon the database and access control scheme being used, the EJB may
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
367
log into the database server using either its own identity or by proxying the user’s identity. The database server would authorize the EJB’s data creation, update, and access requests based on the privileges given to the logged in identity. As we discussed in Chapter 9, the database server may use a user-based, role-based, or some form of rule-based access control scheme to protect the data. A key question to answer with this configuration concerns the identity-mapping scheme across the authentication, authorization, and access control services. .NET Environment Figure 15.8 illustrates a Web Services client accessing a Web Services server that has been implemented as a combination of a Web Service and one or more managed code components within a .NET Framework.
Virtual Trust Domain
Managed Code Components
Channel I A
C
.NET COM Object
Web Service
Client I
AC
C
A
ASP .NET
AU
.NET Framework
Physical Trust Domain
A AU
Authentication Authorization
AC
Access Control
C
Confidentiality
I
Integrity
FIGURE 15.8 Component allocation in a .NET environment.
Database Server AC
368
Enterprise Web Services Security
As was the case in the J2EE discussion above, the client contains an authentication element and both integrity and confidentiality capabilities. The components implementing these capabilities on the client have the same roles and responsibilities as they did in the J2EE example. The Web Services client’s capabilities could be implemented using either J2EE or .NET technologies. That is one of the advantages of Web Services: Web Services is technology independent. Regardless of how they are implemented, they would collect the security tokens, sign and encrypt the necessary message components, and incorporate these into a SOAP message sent across a channel to the Web Services server. Once again, the channel between the Web Services client and Web Services server may need to be secured. As we discussed in Chapter 9, there are various options for securing the channel and various levels within the protocol stack where protection mechanisms can be implemented. In the configuration shown, the authentication component within the .NET Framework is responsible for authenticating the request. The framework authenticates the request before invoking the Web Service or any of the managed code components. We have allocated message integrity and confidentiality responsibilities to the Web Service running within the framework because it is the first application-level component to receive the request. The integrity component is responsible for verifying the digital signature in the message and verifying that content has not changed; the confidentiality component is responsible for decrypting that content. Once again, the elements in the SOAP message header control the sequence of the signature validation and decryption operations. In the implementation shown, a managed code component, a .NET COM Object, is responsible for communicating with the database server. This figure depicts one authorization and two access control components. The authorization component controls access to the .NET COM Object, for example, for authorizing the client to use the component in question. The COM Object, in a role similar to that of the EJB in the J2EE example above, contains one of the two access control components controlling access to the data; the database server contains the other one. Once again, the database server may use a user-based, role-based, or some form of rule-based access control scheme to protect the data. Identity mapping across the .NET Framework, the COM Object, and the database server is a key concern that must be addressed in this implementation. Crossing a Technology Boundary Figure 15.9 illustrates an allocation you might find in an environment supporting wireless clients accessing a Web Service within a local area network or wide area network domain. We chose this example in order to discuss boundary services and transformations. The Web Services client and server are of little interest in this
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
369
scenario other than to recognize that there are still requirements for authentication, authorization, access control, integrity, and confidentiality, even in a wireless implementation, and that some form of transformation gateway is necessary to create a technological bridge between environments.
Virtual Trust Domain
Wireless A
A
A Channel
C
I
A
Client
C
C
I
I
I
Web Services Server C
AC
Gateway
Physical Trust Domain
A AC C I
Authentication Authorization/Access Control Confidentiality Integrity
FIGURE 15.9 Component allocation in a wireless environment.
Figure 15.10 illustrates a notional transformation gateway. We say that it is notional because you can put almost any two disparate technologies on the two sides of the gateway and have similar requirements for transformational capabilities. On one side, the gateway supports a wireless network where wireless clients want access to Web Services hosted on an enterprise network. The wireless network uses wireless protocols for communication such as the global system for mobile communication (GSM), code-division multiple-access (CDMA), or short message service (SMS) and the Wireless Application Protocol (WAP) stack. The WAP stack includes:
370
Enterprise Web Services Security
WAP Datagram Protocol (WDP): WDP provides transport layer services. Wireless Transport Layer Security (WTLS): WTLS provides digital signing and encryption. WAP Transaction Protocol (WTP): WTP provides transaction support including both reliable (TCP) and unreliable (UDP) datagram delivery. WAP Session Protocol (WSP): WSP provides both connection-mode and connectionless session support. Wireless Application Environment (WAE): WAE provides Wireless Markup Language (WML), WMLScript, and Wireless Telephony Application Interface (WTAI) support that includes Web browsing and well-defined formats for images, phone book entries, and a calendar. The other side of the gateway interfaces to a traditional local area or wide area networks, such as the Internet, hosting the Web Services server and uses the TCP/IP stack we discussed in earlier chapters.
WAE
Web Services Server Encode/Decode
WSP
HTTP
WTP
A Identity Mapping
A
TLS
WTLS
I
Signature Transform
I
TCP
C
Encrypt/Decrypt
C
WDP
IP
GSM,CDMA,SMS
A
Authentication
C
Confidentiality
I
Integrity
FIGURE 15.10
ATM,ISDN,FDDI
Notional wireless gateway.
The wireless gateway is responsible for converting requests between the two environments. For requests from the wireless network, the gateway transforms the request into a form that the Web Services server can understand. It reverses the process for responses from the Web Services server going to the wireless client. For example, the gateway translates XML into WML, JavaScript or VBScript into
Pulling It All Together: Using Virtual Trust Domains to Secure Enterprise Web Services
371
WMLScript, TCP/IP into WDP and performs domain name look-up services and data compaction services to convert between the two environments and to offload some processing from wireless devices such as phones and PDAs. The gateway also transforms security-relevant services and must potentially be able to map or translate between Wireless client identities and enterprise identities or tokens Different signing algorithms and key lengths Different encryption algorithms and key lengths As discussed in Chapter 6, an organization may use a variety of types of gateways and firewalls to protect enclave boundaries. Gateway capabilities similar to those described in this scenario are frequently required.
STEP 7: CREATE AND DISTRIBUTE DISCOVERY AND POLICY ARTIFACTS Once the services are allocated across the infrastructure and across the various actors, the final step is to distribute those services (where appropriate) and to create and distribute discoverable policy documents either via WSDL files or via UDDI (as discussed in Chapter 7) and the WSDL files themselves. Depending on the complexity of the implementation and the number of different access points for a service, multiple policy files and WSDL documents may be necessary.
SUMMARY An enterprise Web Service meets the needs of the enterprise; it supports the enterprise’s policy, infrastructure, and security requirements. Enterprise scope often determines the service’s security-relevant characteristics that in turn drive the service’s authentication, authorization, access control, integrity, and confidentiality requirements. This chapter presents a seven-step process and several models based on the concept of virtual trust domains for working through the deployment and security questions that frequently arise for enterprise Web Services. The steps in the process are Identify the parties involved. Identify relevant domain infrastructure and capabilities. Identify necessary security services based on local policies.
372
Enterprise Web Services Security
Identify gaps in technologies, services, and provisioning strategies in order to project a virtual trust domain. Allocate new infrastructure services across physical and logical domains. Allocate security services across actors. Create and distribute discovery and policy artifacts. The first time an organization deploys an enterprise Web Service, quite a bit of effort will necessarily go into answering questions about what the service should provide for itself versus what it should be provided by its underlying infrastructure. Over time, as the organization deploys more services and creates a richer domain and enclave infrastructure, the simpler the questions and their answers become.
16
FutureScape
In This Chapter Going Mobile What Is Self-Protecting Data? Protecting Data In Transit Protecting Data At Rest Protecting Data In Use Web Services’ Role Summary References
he Web Services standards we have discussed thus far in this book are continuing to evolve, some of them very rapidly. You should stay plugged into the major standards committees’ (W3C, OASIS, WS-I, IETF) Web sites to make sure you are working with the most recent versions of the standards and to keep abreast of changes to existing standards and new standards as they are approved. You should also work with your vendors to ensure they are incorporating the standards you need in ways that help you maintain the flexibility and independence Web Services promise. One of the evolving areas that we have left to the end because we believe it will have a big future is mobile computing and the concept of “self-protecting data.” We didn’t delve into it in earlier parts of the book because it is still a relatively new area that, while it is rapidly evolving, isn’t yet mainstream. Digital rights manage-
T
373
374
Enterprise Web Services Security
ment (DRM), autonomic storage, and secure mobile database and encryption products are emerging that will contribute to making truly secure mobile applications a reality. We see Web Services as an enabler that will help fuel this next revolution as the need to connect mobile devices with traditional infrastructures grows.
GOING MOBILE In some ways, going mobile simply means that there are an increasing number of client platforms available that can use your Web Services. You are no longer limited to traditional desktop and laptop computers. There are now PDAs, cell-phones, smart phones, Web phones, Blackberries, and a growing list of other wireless devices that make it possible for employees and customers to operate anywhere, anytime. These devices bring diversity in addition to mobility. Each type of device represents a different architecture and set of capabilities. A question you must ask in this situation is, do you “dummy down” your services in these environments, seeking least common denominator solutions, or do you look for managed approaches that leverage the capabilities within each to the maximum extent possible? Another question is, how do you bridge between the mobile technologies you want to use and your enterprise infrastructure? We believe you should design and develop for managed approaches and that a key part of those designs are wireless gateways similar to the one we discussed in Chapter 15.
WHAT IS SELF-PROTECTING DATA? A key concept in this mobile world, made up of drastically different infrastructures, is that of self-protecting data. Self-protecting data is simply data that can protect itself. That is, the data inherently contains the protection mechanisms it needs to prevent or to at least detect compromise. If we look at Figure 16.1, the data can be in any of three states where it needs protection: In Transit: While the data is being moved between two endpoints In Use: While it is being read or modified by one of the endpoints At Rest: While it is in storage on one of the endpoints
375
FutureScape
A
Channel
A
C
Server
I In-
Us
e
In-Trans it
Client
AC
C
U In -
I
se
Secure At-Rest
A AC C I
Authentication
Authorization/Access Control
Confidentiality
Integrity
FIGURE 16.1 Data protection states.
PROTECTING DATA IN TRANSIT Protecting data in transit is about protecting the data in the communications channel, regardless of how complex, between the Web Services client and the Web Services server. As Chapter 9 discussed, there are choices between end-to-end and point-to-point techniques and among levels within the protocol stack. Chapter 15 outlined the issues gateways must address in translating between environments. Figure 16.2 depicts a notional environment with different gateways as part of the channels between the Web Services server and various types of clients.
376
Enterprise Web Services Security
A Client
Ce ll
A
C
ph
on
I
e
C A I
C
Ga te wa y
Ch
an
ne
I
l
Blackberry A
A
Client
C
C
I
I
I
C
A
A
I Web Services Server
Channel
C
AC
Gateway l
ne
A PD
an
Ch
A C
A
I C I A
y wa te Ga
Client C
A AC C I
I
Authentication Authorization/Access Control Confidentiality Integrity
FIGURE 16.2 Protecting data in transit.
The issue in protecting data in transit is one of maintaining confidentiality. As Chapter 10 discussed, the solution is some form of encryption, and the choices are between algorithms and key lengths and between point-to-point and end-to-end
377
FutureScape
encryption techniques. As Chapter 11 discussed, the combination of WS-Security and eXtensible Markup Language (XML) Encryption provides end-to-end mechanisms for communicating messages encrypted at the message, element, or content level and the use of multiple encryption algorithms or keys.
PROTECTING DATA AT REST Protecting data at rest is about protecting the data while it is in some storage mechanism, be it a filesystem or a database, and while it is on some device, be it an enterprise server or a cell phone. Some form of encryption is again a solution. The question is, where and at what level does the encryption need to be applied? Figure 16.3 illustrates various points on both the client and, in this case, a J2EE server in combination with a database server where confidentiality can be provided. To answer the question of where, you must first answer the questions of what specific types of attacks or concerns you are trying to protect against and from whom. Encrypting at the filesystem level using a common algorithm and key can be sufficient if the concern is someone loosing a laptop, for example, or someone removing media from the data center. It may be insufficient if the concern is separation of duties for administrators. In this situation, protecting at a higher level in the stack may be necessary in order to map the right privileges with the right individuals.
Channel
Client
Servlet
EJB C
C
Database Server
C C JSP
Web Container
EJB Container
C
J2EE Server
C
Confidentiality
FIGURE 16.3 Protecting data at rest.
C
378
Enterprise Web Services Security
A number of protection-at-rest solutions are available or evolving. IBM and Cisco Systems, for example, are developing the idea of “self-protecting” storage as part of an autonomic computing initiative [IBM03]. They define self-protecting storage as storage that is able to detect, identify, and protect against hostile behaviors and to take action in order to make it less vulnerable. iAnywhere®, a subsidiary of Sybase®, offers a mobile security solution as part of their SQL Anywhere® DBMS product [iAnywhere]. SQL Anywhere basically encrypts the data within the database itself. WS-Security and XML Encryption are again an option for addressing the atrest problem. One of the strengths of WS-Security and XML Encryption are that they can encrypt data at the message, element, or content level using multiple encryption algorithms or keys or both. This means data can be selectively encrypted to include everything from the entire message to only certain elements. Since search is often one of the services users have available in conjunction with the data, the flexibility this solution offers is that the content can be fully searchable (by the server with copies of the keys) or selectively searchable (by the server with keys to selected sections, abstracts, metadata, or summaries).
PROTECTING DATA IN USE Data in use is the most difficult of the three states to address. For the data to be useable, the user or server has to have the data in a usable form, meaning it is by definition decrypted into plaintext format. Conceptually, you can think of the problem for any given device as being the need to create a sandbox within which the data can be protected, with access to external devices and capabilities tightly controlled as illustrated in Figure 16.4. External devices and capabilities in effect tunnel through the outer operating system layer to the sandbox. Some of you may immediately think of the sandbox created by the Java Virtual Machine (JVM), but its purpose is the opposite of the one necessary in this context. The Java sandbox protects the operating system and its environment from code executing within the sandbox. The data-in-use sandbox protects the virtual machine, its storage and processes, and its interfaces to external devices and capabilities from the outside, from attacks against the operating system or its file and storage management components. Protecting data in use is more than just keeping external threats out. In some instances it is also about controlling what the user can do: being able to store, print, or copy the data, for instance.
FutureScape
379
Network Objects
Printer Clipboard
Request Virtual Machine
Server Response
Sandbox Process and File Objects
Operating System
FIGURE 16.4 Protecting data in use.
A secure operating system could be the sandbox, but it would be necessary for it to include capabilities for Memory protection Protected kernel rings Input/output access control Service access control Sandboxes for untrusted code Differentiated user and process privileges As we discussed in Chapter 8, the goal would be either an A1 or EAL 7–level operating system. Commercial operating systems generally used today, however, are either at the C2 or EAL 4 level depending on the criteria being used. No A1 or EAL 7 systems are in use today (at least not in the commercial market; they’re impractical because of cost and functional limitations). Digital Rights Management Many of the capabilities needed by the environment depicted in Figure 16.4 are part of the ongoing development within the DRM arena. Much of the research in this area is focused on how to provide movies (in the form of DVDs) and music (in the form of downloadable content) across the Web in a way that protects the intellectual property rights of the copyright owner. Some of the challenges include [Kocher03]
380
Enterprise Web Services Security
Renewability: Security must survive the compromise of individual products. End-to-End Security: Content must be protected throughout the distribution process. Player Diversity: Security must be consistent across a broad range of devices. Openness: Security must be based on a set of published standards. Watermarks and forensic markings are two approaches being investigated to address these issues, and the availability of programmable devices allows the separation of the device from the security code. Rights Expression Languages A rights expression language (REL) is a way for a content owner or distributor to express the rights another has in some content. It consists of a set of rules for tying together a set of rights with a set of constraints potentially based on a set of payment mechanisms. An REL allows a content owner to determine what activities someone can perform, within some timeframe, based on some cost. For example, a movie publisher can determine that a particular user can play a given movie n-number of times within an x-week period. As another example, a bookseller could stipulate that a given user could read a particular book over a one-month period. The Open Digital Rights Language (ODRL) is an XML-based rules language for combining rights, constraints, and payments that has been developed as part of the Open Digital Rights initiative [ODRLNet, ODRL02]. The eXtensible Rights Markup Language (XrML) is another XML-based language, developed by ContentGuard [XrML]. Building on XrML, the MPEG-21 Rights Expression Language (ISO/IEC 21005-5) is a set of seven architectural elements for packing and delivering multimedia-based content [Rightscom03] including: Digital item declaration Digital item identification and description Content handling and usage Transaction/use/relationship Intellectual property management and protection Terminals and networks Content representation The Web Services Rights Expression Language (REL) Token Profile from OASIS defines the syntax and grammar for encoding ISO/IEC 21000-05 licenses as WS-Security tokens and describes processing models for authentication and confidentiality [REL04]. The processing model for REL tokens is the same as the
FutureScape
381
processing model for other WS-Security token formats that we described in Chapter 11.
WEB SERVICES’ ROLE The Web Services and XML security standards are enablers for all three protection states in mobile environments: in transit, in use, and at rest. As such, we expect to see them continue to evolve as interconnecting wireless and traditional enterprise environments as the use of Web Services for providing similar levels of service across the environments becomes more pervasive. We also expect to see broader endorsement of the standards and their incorporation into leading products.
SUMMARY Mobile computing is rapidly changing the landscape for the enterprise when it comes to where and how enterprise data must be protected. Web Services and research in the areas of digital rights management and autonomic computing are combining to develop the concept of self-protecting data. Self-protecting data must be able to protect itself in transit, at rest, and in use. We see Web Services Security and XML Encryption as major enablers in this area. XML Encryption provides the confidentiality mechanisms for protecting data in transit and at rest, and XMLbased rights expression languages such as ODRL, XrML, and MPEG-21 and the recently approved OASIS REL Token Profile for encoding and processing ISO/IEC 21000-05 licenses are paving the way for mainstream products in these areas.
REFERENCES [iAnywhere] iAnywhere Solutions homepage. Available online at http://www.ianywhere.com. [IBM03] Studwell, Thomas, et al., “Adaptive Services Framework Version 1.0.” Available online at http://www-03.ibm.com/autonomic/pdfs/Cisco_IBM_ ASF_100.pdf, October 14, 2003. [Kocher03] Kocher, Paul, et al., “Self-Protecting Digital Content, A Technical Report from the CRI Content Security Research Initiative.” Cryptography Research, Inc. (CRI), 2003. Available online at http://www.cryptography.com/ technology/spdc/white_papers.html. [ODRLNet] Open Digital Rights Initiative Homepage. Available online at http://odrl.net.
382
Enterprise Web Services Security
[ODRL02] Iannella, Remato, “Open Digital Rights Language (ODRL) Version 1.1,” W3C Note. Available online at http://www.w3c.org/TR/2002/NOTE-odrl20020919, September 19, 2002. [REL04] DeMartini, Thomas, et al., “Web Services Security Rights Expression Language (REL) Token Profile 1.0.” Available online at http://docs.oasisopen.org/wss//oasis-wss-rel-token-profile-1.0.pdf, December 19, 2004. [Rightscom03] Rightscom Ltd, “The MPEG-21 Rights Expression Language, A White Paper,” Version 1.0. Available online at http://www.contentguard.com/ whitepapers/MPEG21_REL_whitepaper_Rightscom.pdf, July 14, 2003. [XrML] XrML Organization Homepage. Available online at http://xrml.org.
Appendix
A
The Security Policy Document
In This Chapter Introduction Responsible Organizations Physical Security Personnel Security Security Standards Defending the Computing Environment Defending the Enclave Boundary Defending the Network and Infrastructure Supporting Infrastructure Web Services Security Incident Handling and Response References
here are several approaches to developing an enterprise security policy document. One approach is to develop it from scratch, either in-house or through the use of a security consultant. Another approach is to purchase a security policy template and customize it to fit your organization’s needs. In either case you should be familiar with the kinds of information the policy document should contain and the issues it should address. Which approach to take depends on what the policy authors have available in terms of prior content and expertise. If an existing policy is being modified, that’s a good starting point. However, you should avoid using large amounts of boilerplate text that don’t reflect your organization. Less content can be better if the resulting policy more closely reflects your organization’s goals.
T
383
384
Enterprise Web Services Security
Figure A.1 presents an outline for a sample security Policy document developed around the IATFF framework’s defense-in-depth strategy. We will step through each of the sections, highlighting key points you should be looking for or making in your own policies.
1. Introduction Scope Goals and Objectives 2. Responsible Organizations Physical Security Personnel Security IT Security and Administration 3. Physical Security Building Access Visitors Access Computer Facilities Access 4. Personnel Security User Administration Training Appropriate Use Employee Privacy 5. Security Standards Identity Management Authorization Access Control Confidentiality Integrity 6. Defending the Computing Environment Workstation Security Server Security Operating Systems
HTTP Server DBMS Services Application Services Network Security Secure Messaging Mobile Code 7. Defending Enclave Boundaries Firewalls Virtual Private Networks Remote Access Guards Content Filtering Virus Protection 8. Defending the Network and Infrastructure Switches and Routers 9. Supporting Infrastructure Key Management Intrusion Protection Auditing/Monitoring Backup/Retention Disaster Recovery 10. Web Services 11. Security Incident Handling Notification Points of Contact Containment Recovery
FIGURE A.1 Sample security policy outline.
INTRODUCTION The reason for having security policies is to clearly communicate to managers, users, and administrators their roles and responsibilities in protecting information and technology assets. The policy should clearly define the scope, goals, and objectives of the policy. Scope identifies which parts of the organization are covered and who is affected by the policies. Goals and objectives define what the overall policy is trying to accomplish. Depending on the size of your organization, the security policy may be either part of a larger set of policies and guidelines or self-contained.
Appendix A: The Security Policy Document
385
RESPONSIBLE ORGANIZATIONS Accountability is a major part of any policy. One of the first things a good security policy should identify is the parts of the organization responsible for the different aspects of the policy. Each responsible organization is a key stakeholder of the policy and should have policy authority within their respective areas of concern. In a small organization, these responsibilities may fall to a single individual, but in larger organizations you will generally have different organizational components responsible for facilities, personnel, and the IT infrastructure (including IT applications and services). The three must work together to ensure a safe and secure computing environment. Within the IT organization, you may further separate duties to ensure the persons responsible for performing one function are not responsible for others in order to minimize the risks of exposure and loss. For example, you may have different groups responsible for systems administration functions, performing systems backups, and responding to incident reports.
PHYSICAL SECURITY A key question the security policy must answer is how you intend to physically protect critical IT assets such as servers and network infrastructure. This includes policies concerning Grounds access Building access Computer room access Visitors’ access As a general rule, you should keep sensitive computer and network equipment in a controlled location with locking doors and a badge entry, cipher lock, or logging system, with only systems administrators having access to the area. If you are protecting extremely sensitive information, you may want to implement a twoperson rule, where a minimum of two people must always be present in this area. A central visitor’s entrance with a visitor’s log and a badge system with escort and no-escort badges can help employees identify unauthorized persons roaming about a facility unescorted.
386
Enterprise Web Services Security
PERSONNEL SECURITY The goal of personnel security policies (which are often called acceptable use policies) is to reduce the risk of exposure or loss caused by human error, fraud, theft, misuse, or abuse of IT infrastructure or assets. Personnel security policies should clearly identify the criteria and procedures for obtaining access to computing capabilities. These include any clearance, vetting, or training prerequisites to obtaining security credentials or accesses and the procedures for both granting and revoking access. Access should generally be granted by qualified systems administrators or data owners and should be revoked when no longer needed. Users should also only be given access to the resources they need to perform their job function. Appropriate use standards and training are also an important part of an organization’s personnel security policies. Personnel security policies must also address employee privacy. Any restrictions on employees’ use of email, chat rooms, instant messaging, or other capabilities should be clearly defined along with any intent to monitor those activities. Employees should be asked to sign a statement, prepared by the organization’s legal counsel, consenting to any monitoring that may occur.
SECURITY STANDARDS The heart of an organization’s security policy is how they intend to protect the availability, confidentiality, and integrity of their systems. If rules are not consistently applied, the gaps can create serious vulnerabilities within the computing environment. Standards are the clearest way of achieving consistency within the organization. Depending on the organization’s structure and the level of its connectivity, it may use multiple standards. When it does, the security policy should clearly identify when, where, and under what circumstances each of the standards are to be used, as well as how any interface points should be managed. The key areas policies should address are Identity Management: How to identify users, the credentials to use, and who is responsible for administering those credentials Authorization: Defining the guidelines for protecting information and making access decisions Access Control: Establishing the rules for accessing information and data resources Confidentiality: Defining when and how to use encryption to protect resources Integrity: Defining the services to use to ensure that information is not altered or destroyed in an unauthorized manner
Appendix A: The Security Policy Document
387
The standards cannot stop just with the organization. Today, many organizations operate across multiple security domains and security enclaves because of their external business relationships. The IATF defines a domain as the context within which an IT system is operating. It is a logical collection of resources operating under a common, or at least agreed upon, control and authority structure. The information within the domain is partitioned based on common access control, need to know, and security policies. An enclave is a physical set of components operating under a single security policy. An organization may participate in multiple domains and may have multiple enclaves within or across those domains. Security standards may be different for each operational environment. The security policy must set clear guidelines for the standards to use in each environment and how to transition across boundaries, while making provision for any credential proxy or delegation considerations. IATF discusses policy standards within these environments in terms of defending the computing environment, enclave boundaries, and the network and infrastructure. The Center for Internet Security (CIS) and the National Security Agency (NSA) are two resources you can draw upon in formulating your security policies in these areas. CIS is a not-for-profit cooperative among government, industry, and academia that maintains a Web site promoting best practices and tools for managing information security risks [CIS04a]. NSA’s Information Assurance Division’s Central Security Service Web site provides a similar service [NSAIAD04]. On these sites you can find benchmark, configuration, and lockdown information for operating systems; database, applications, and Web servers; and many network devices such as hubs, routers, and switches. In the next three sections, we have abstracted some of the common themes from the detailed lockdown instructions at these sites and melded them with the IATF and Internet Engineering Task Force (IETF) recommendations to create what are some common features you should be looking for or including as part of your security policy. Given that you will be looking at a specific set of products in specific configurations, we suggest you refer back to the latest, more detailed lockdown instructions for the products you use in formulating your policy.
DEFENDING THE COMPUTING ENVIRONMENT The computing environment for an organization includes everything from the client workstations users use to perform their jobs to the servers and applications supporting those functions. The policies concerning how the computing environment should be locked down creates the first line of defense for some threats, such as the trusted insider threat, and the last line of defense against others, such as denial-of-service attacks launched through a Web Service. The IATF framework
388
Enterprise Web Services Security
defines the computing environment as a set of IT components under the same security polices and controls. The computing environment that exists within an enclave may have its own physical protection mechanisms. An organization may have several different computing environments within different enclaves depending on its protection needs. Workstation Security User workstations represent one of the easiest entry points into your computing environment. Therefore, it is important that you take adequate security measures to protect the integrity of both desktop and laptop computers. IETF’s RFC 2504, User’s Security Handbook, outlines many of the concerns organizations should take into consideration in developing their workstation policies [RFC2504]. The first step is, of course, physical security. Users should be cautious about sharing workstations and laptops, should not share passwords, should always use a passwordprotected screen saver when they leave their machine unattended, and should keep their security credentials, such as passwords, secret. Users should also be cautioned against downloading files from the Internet or their email. They should be warned to be particularly cautious when it comes to executing downloaded programs. Policies should include a provision concerning the use of virus scanning software to detect viruses and provisions for reporting any viruses found. More information on these topics is available in Chapter 8. Server Security Severs represent one of the most vulnerable points within the infrastructure when it comes to exposure because of the data they contain. A trusted insider could easily walk away with invaluable assets in the form of a backup tape or disk. Security policies must therefore approach servers from several perspectives. The security features of the systems in a Web Services environment are enforced by the host operating system (OS), which is the software that provides a way for applications to interface with the system hardware. The OS provides an application programming interface that is independent of the peripherals or options installed on a system. The OS controls access to the system devices and memory while usually allowing multiple applications to execute. Security enforcement is usually the responsibility of the OS, as all access to system devices is controlled, or mediated, by the OS. A practical security policy should consider the available security features of off-the-shelf operating systems. We discuss operating systems and server security in far greater detail in Chapter 8.
Appendix A: The Security Policy Document
389
HTTP Services HTTP servers should be configured to provide the minimum services necessary to serve up documents. In some instances, this may include limiting the services available for executing common gateway interface (CGI) programs and other types of scripting programs such as Active Server Pages (ASP) and Java Server Pages (JSP). You should always keep in mind that opening any unneeded service unnecessarily creates a potential point of attack. Policies and procedures should identify specific services to be excluded and ports that are to be opened. The general rule should be to lock everything down and open up only what is absolutely necessary. Policies should address concerns such as Document root Directory access Use of weak authentication IP filtering requirements Executable content Database Management System (DBMS) Services Policies should specify stricter lockdown requirements for DBMS servers than any other type. Database management system servers contain the information that attacks will most often target. Policies should address whether the system administrator for the server itself is also the database administrator and whether the database administrator administers database design elements, user accounts and privileges, and data access privileges. With most OSs and products, the system administrator and database administrator responsibilities are separable, and with an increasing number of products, database administration duties are also becoming divisible. Since HTTP servers and applications servers will generally proxy user requests to the DBMS server, policy should also address the issue of credential passing and whether database services need to reauthenticate users or how trust is to be passed. Another issue that sometimes arises is the level of physical or logical separation: different physical servers, different installations of the product running on the same server, or different instances of a single install running on a shared server. The three options offer different degrees of separation and security but increase costs and data sharing problems. Policy should provide guidelines for making the decision based on data sensitivity and protection requirements.
390
Enterprise Web Services Security
Applications Services Applications servers normally run on top of an HTTP server. Therefore, all the lockdown procedures for HTTP servers within an enclave will normally also apply to the applications servers within the same enclave. Policies should address questions about the use of container authorization services, identity delegation, remote access and upgrade, and control of applications server–specific configuration files and information. Network Security The network includes the hosts, routers, hubs, switches, and other types of network devices supporting communications within the computing environment. Many of the network devices are themselves computers that have their own configuration, administration, and operations requirements. An organization’s security polices should include guidelines for configuring and administering these types of devices. Some areas that should be addressed in the policies include: Shutting down unnecessary servers and services Blocking certain types of content (.exe, .bat, .vb, etc.) Blocking printer access from outside the computing environment because printers now include Web servers and other advanced services Disabling Simple Network Management Protocol (SNMP) where it isn’t needed Use of TCP/IP filters to limit protocols and services supported to only those needed Control of accounts, passwords, and management ports on switches and routers Use of switches versus hubs within the computing environment Secure Messaging Confidentiality and integrity may be a concern within the computing environment. An organization’s security policy should define the specific products, technologies, and algorithms for use in securing traffic between components within the computing environment. For example, the policy might state that all Web servers containing sensitive personnel information should use SSL with dual authentication for maintaining server-to-server and client-to-server confidentiality. Mobile Code At a minimum, an organization’s security policy should state that users and servers should not execute any code they may receive from nontrusted sources. A non-
Appendix A: The Security Policy Document
391
trusted source should be anyone not specifically trusted. In the Internet environment, users receive executables via email, they can download executables from many Web sites, and many Web pages contain active content. There is always the possibility that this code contains viruses or malicious code. The organization’s security policy should include guidelines for filtering or at least verifying the source of mobile code. This topic was covered in more detail in Chapter 8.
DEFENDING THE ENCLAVE BOUNDARY The IATF framework defines an enclave as an environment under common personnel and physical security measures belonging to a single authority [IATF02]. An organization may have multiple enclaves because they are dealing with information at several different sensitivity levels. Enclaves may have access to other enclaves or be accessible to traveling users via remote connections. Defense of the enclave centers on defense of the enclave boundary (which is defined as the points where data flows into or out of the enclave) and physical access points where insiders can either gain access to the enclave or facilitate access from the outside. Defending the enclave includes services for either controlling or filtering information flows across the boundary and for monitoring the information flow in order to detect attacks and to alert responsible parties of anomalies and potential attacks. Different enclave boundaries may require different protections. For example, an organization may require one set of protection mechanisms between the organization’s internal network and the Internet, another set between the internal network and any extranets, and yet a third set between the internal network and remote users. Firewalls An organization should use firewalls to separate networks containing different levels of sensitive information or different degrees of trust. As the name implies, the idea is to provide an impenetrable wall to stop the uncontrolled entry or spreading of information from the untrusted network to the trusted network. To be successful, all traffic between the two networks must pass through the firewall; otherwise back channels exist between the two networks that may permit the uncontrolled flow of information. An organization’s security policy should clearly define the types of firewalls that should be used to protect enclave boundaries. The most secure boundary is an airgapped system, where the components are not physically connected by the network; there is effectively an “air-gap” between them. However, this assumes some mechanism for shuttling traffic between the two networks.
392
Enterprise Web Services Security
Virtual Private Networks (VPNs) VPN technology uses encryption to effectively create a subnetwork of a different classification or sensitivity level within another network. An external user or server establishes a session with a VPN server within the enclave, thereby creating a virtual point-to-point tunnel between the internal enclave and the external user or device. The external user could be another enclave. The internal enclave and the external user are assumed to be at the same sensitivity level. VPNs logically extend the enclave and are a way of connecting either remote or traveling users or two enclaves of like sensitivity levels into a single logical enclave. An organization’s security policy should identify appropriate VPN use including: The specific technologies to use The types of connections to be supported: remote access or site-to-site The levels of data sensitivity supported For example, an organization may say it is OK to use VPN technologies to support connections between traveling employees and the central network, but not to the servers containing the most sensitive personnel or finance information within that network. Remote Access The IATF framework identifies three types of connections that support remote users [IATF02]: Dial-up via the public telephone network (PTN) Direct or dial-up connection to an Internet service provider (ISP) Dedicated connections through a telecommunications service provider In addition, policies regarding remote users should address: The use of smart cards or subscriber identity module (SIM) cards for authentication (the combination of something the user must know plus something the user must also possess is stronger than either of the two separately) The use of VPN technologies for connecting to the network Protecting the mobile device and information it contains from loss Protecting distribution of hardware and software updates Confidentiality and integrity measures sufficient to protect sensitive information in uncontrolled environments, for example, the Internet and the public telephone system
Appendix A: The Security Policy Document
393
Guards A guard is special type of firewall device normally found within the Department of Defense (DoD) and intelligence community. A guard sits between two networks of different sensitivity levels, controlling message flow, providing filtering, data blocking, and enforcing rules for downgrading information as it flows from high to low and low to high. Filtering capabilities may include sender and receiver access control lists, security-level screening, attachment filtering, “dirty word” screening, and human review. The security policy for an organization dealing in this environment should specifically address the issue of connecting multilevel enclaves and the specific types of guards and filtering to be used in these connections. Content Filtering An organization’s security policy should specifically address any restrictions on content flowing between enclaves. Examples cited above include executable content that may introduce threats into the enclave and sensitive data that either cannot be shared between enclaves (and therefore must be blocked) or can be shared only under certain circumstances determined by human review or filtering. Virus Protection Viruses are programs that exploit vulnerabilities in operating systems and applications. They are an increasing threat to user workstations and to systems servers. An organization’s security policy should include specific guidelines and clear responsibilities for ensuring that virus-scanning software is deployed to all possible entry points and kept up-to-date. The policies should always identify points of contact for notification and for removal of the virus once infected. Web Services are a form of executable content. Therefore, they are subject to known vulnerabilities such as buffer overflow attacks. Web Services messages can also communicate executable content and are therefore a potential source of viruses. Though binary content in SOAP messages is generally encoded in Base-64 or some other format, it can be just as dangerous as simply downloading and executing an executable file if encoded content is indiscriminately accepted, decoded, stored, and potentially executed. Gateway Spam Filtering and Virus Protection Spam (unsolicited bulk email) filtering should also be considered as part of your security policy. It is convenient to implement spam filtering on the gateways between enclaves, as they are points where all email flows. Antivirus filtering on the gateway systems should also be considered.
394
Enterprise Web Services Security
DEFENDING THE NETWORK AND INFRASTRUCTURE If your organization connects to the Internet, or to an extranet, one or more routers create the perimeter between your internal network and the external networks. These routers are the first line of defense between your organization’s network and systems and the outside world. The routers may be under your control or be provided by your ISP or business partner. The IATF framework identifies three types of traffic crossing these routers: user, control, and management [IATF02]. These three types of traffic correspond to the information flow between two endpoints, the control mechanisms needed to establish the connections between those endpoints, and the management protocols needed to maintain the health of the network. If the boundary routers are within your control, it is important that you have specific policies in place as to how they should be “locked down” to securely establish this perimeter and ensure the reliability, integrity, and confidentiality of different flows. Some guidelines include: Ensure that default user IDs and passwords are changed. Use strong passwords. Use secure shell (SSH) to securely manage Telnet access to the router. Turn off unneeded ports and services. Promptly install vendor patches and service packs containing security upgrades.
SUPPORTING INFRASTRUCTURE The IATF framework identifies two key supporting infrastructures related to the defense-in-depth strategy: the key management infrastructure and the detect-andrespond capabilities built into the infrastructure [IATF02]. We add backups and retention and disaster recovery to that list because of the key role they play in recovering from attacks and natural disasters. Key Management Encryption is a critical component of many protection mechanisms. Cryptography services assume efficient and secure mechanisms for issuing certificates and creating, distributing, and managing encryption keys. The IATF framework recognizes two levels of infrastructure: a high-assurance public key infrastructure for protecting the most sensitive information and a medium-assurance commercial capability for lower sensitivity levels [IATF02].
Appendix A: The Security Policy Document
395
Organizations using encryption capabilities as part of their security infrastructure should include in their security plan The organization responsible for managing the certificate authority A key and message recovery policy The organization responsible for creating and distributing certificates and keys The organization responsible for maintaining any directory services offered Protocols to be used in connecting to directory capabilities Key aging and revocation policy Guidelines for using cryptography to assure confidentiality, integrity, and nonrepudiation If the organization has multiple enclaves, the policy should provide this information for each enclave and also cover issues such as certification hierarchies that discuss how credentials from each enclave relate to those within others. Intrusion Protection It is impossible to eliminate all active attacks unless you completely isolate your networks. The best you can do is to incorporate components into your infrastructure for detecting and responding to attacks. Intrusion detection systems (IDSs) provide capabilities for detecting attacks and notifying someone to respond. Network IDS (NIDSs) monitor network components to detect various types of probes, scans, and attacks. Signature-based IDSs look for patterns in order to recognize different types of attacks and sound an alert when such patterns are detected. Statistical analysis techniques look for event patterns to identify suspicious activities. Anomaly detection systems look at current event patterns as a whole in relation to historical patterns in order to detect anomalies. Host-based IDSs monitor systems logs, audit logs, and system activity and traffic in order to detect suspicious patterns and alert responsible parties. An organization’s security policy should cover when, where, and what types of IDSs should be used and identify the parties responsible for managing the organization’s IDSs and responding to alerts. It should also address the continuous tuning of the systems to reduce the number of false alarms such systems sometimes raise and the human tendency to begin to accept such false alarms as normal if they occur too frequently. Intrusion prevention systems (IPSs) are also available. An IPS uses methodologies similar to IDSs to detect attacks, but rather than simply report problems that are detected, an IPS attempts to deflect the attacks by disconnecting attacking systems. The organization’s security policy should consider how these should be integrated with IDSs and firewalls.
396
Enterprise Web Services Security
Audit Audit plays a critical role in ensuring policy compliance and both user and systems administrator accountability. Audit is also a key subelement within both detection and response systems. Programs scanning audit logs can help detect attacks as they occur by recognizing unusual behavior, suspicious patterns, or atypical error messages. Audit logs are also a key source of information for damage assessments and planning recovery actions. An organization’s security policy should provide guidance on the types of audits to be implemented, what the organization considers to be auditable events, the information to be captured as part of the audit, and the retention period for audit records. The policy should also identify the parties responsible for collecting, retaining, and reviewing auditing information. Backups and Retention System backup and recovery procedures and the retention period for system backups impact an organization’s ability to recover from events that destroy or significantly damage data. Many organizations use nightly incremental backups, with full backups on a weekly or monthly schedule to ensure they can recover from the problems that arise through normal operations. RAID technology has reduced the traditional problems caused by hardware failures by nearly eliminating disk failures as single points of failure that result in catastrophic damage or data loss. The widespread adoption of RAID technology has left backups primarily as safeguards against accidental loss or damage. An organization’s security policy should identify The organizations responsible for conducting backups What information is to be backed up The frequency of incremental backups The frequency of full backups The backup retention period Any offsite storage requirements The policy should also address the issue of offsite storage of backups to support reconstitution following catastrophic events. Disaster Recovery Attacks on high-profile targets are well understood. After the first attacks on the World Trade Center, many organizations moved their backup and data retention systems to New Jersey. The awareness of the potential for attacks to disrupt systems
Appendix A: The Security Policy Document
397
became even more widespread following 9/11. Now it can be said that most business managers are aware of the importance of disaster recovery. Terrorist acts aren’t the only disasters that can have catastrophic affects on an organization’s IT infrastructure. Natural disasters such as floods, hurricanes, and earthquakes can also put a site at least temporarily out of commission. The organization’s disaster recovery plan should provide detailed procedures and guidelines for addressing the disaster recovery issue and should cover such questions as, what information must be reconstituted, on what schedule, with what equipment, at what location, to support which groups of users? The answers to these questions will drive the IT infrastructure disaster recovery design.
WEB SERVICES Web Services transactions occur at the applications layer of the Open Systems Interconnection (OSI) model [OSI94]. The Web Services transaction rides “on-top” of the systems and network infrastructure we have discussed thus far in the defensein-depth strategy. As such, Web Services security countermeasures must be consistent with, and also leverage, protection mechanisms at lower levels within the stack. Figure A.2 depicts example standards at various levels of the OSI stack that must be considered in formulating the overall protection strategy.
Application Layer WS-Security XML Encryption XML Signature SOAP WSDL XML UDDI S/MIME Presentation Layer Session Layer Transport Layer TLS
SSL IPSec
Network Layer Data-Link Layer PPP
SLIP
Physical Layer
FIGURE A.2 Example services within the OSI model.
398
Enterprise Web Services Security
The security policy for an organization that uses Web Services must address the questions of authentication, authorization, access control, confidentiality, and integrity for those services both within the context of the enclave within which the Web Services serve exists and for that of the Web Services client. Protocols must be specifically enabled to traverse routers and firewalls, and decisions must be made about the OSI layer within which specific security threats are to be addressed.
SECURITY INCIDENT HANDLING AND RESPONSE In developing a security policy, the organization must assume incidents will occur. The questions then become, who should be notified, what precautions should they take to contain the incident, and what procedures should they follow in restoring normal operations? Notification An organization needs clearly defined notification procedures for identifiable types of incidents. These include everything from a user noticing the existence of a virus on a workstation, to the loss or theft of a workstation or laptop containing sensitive information or credentials, to the suspicious behavior of an application or system. The security policy should clearly identify the organizations responsible for developing these incident reporting procedures and, where practicable, the procedures themselves. Employee and user training must clearly be part of the process. Employees and users must know how to report various incidents, and response teams must know how to respond. The responding teams should be trained to understand the need to protect what may become a crime scene to avoid contaminating evidence. They should also be trained to know how to collect evidence so it is admissible in court. Knowing what not to do may be as important as what is done in cases where criminal charges are contemplated. Points of Contact At a minimum, the security policy should identify clear points of contact within the organization for different types of incidents. The policy should also address who should contact what outside agencies, under what circumstances, and what steps should be taken to preserve forensic information. For some incidents, guidelines may be necessary on when to bring in law enforcement or oversight regulatory or investigative agencies.
Appendix A: The Security Policy Document
399
Containment Once an incident occurs, the response team must quickly act to contain the problem and limit further damage. Sun outlines two possible responses: “protect and proceed” and “pursue and prosecute” [SUN04]. For some incidents, the response team may take a protect-and-proceed approach, where the goal is to preserve assets and return to normalcy as quickly as possible. In others, the team may need to take a pursue-and-prosecute approach, where activity is allowed to continue until responsible parties can be notified and law enforcement brought in. A pursue-andprosecute-approach can place assets at greater risk, so it should only be used in instances where systems are well protected and recoverable. Assess Damage, Perform Triage Once the incident is contained, the team should assess the damage that has occurred and determine what immediate steps are necessary to gather evidence and begin to correct the damage. Triage is performed to prioritize the systems that need the most immediate attention to help return to operation. Recovery Recovery involves removing the threat, restoring systems to normal operations, and capturing lessons learned from the incident. Removing the threat may be as simple as running a virus removal program or reconfiguring a border router or may require a more in-depth approach such as the introduction of a new IDS, the reconfiguration of a system or system component, or the installation of a new firewall capability. A postmortem following any significant incident is always a good idea to learn as much as you can about an incident in order to prevent a reoccurrence or to improve response and containment procedures. A good security policy emphasizes periodic review of both the policies and protection mechanisms for improvement as the organization’s security posture and the technologies it uses mature.
REFERENCES [CIS04a] The Center for Internet Security. Available online at http://www. cisecurity.org, 2004. [IATF02] Information Assurance Solutions Technical Directors, “Information Assurance Technical Framework Release 3.1.” Available online at http://www.iatf. net/framework_docs/version-3_1/index.cfm, September 2002.
400
Enterprise Web Services Security
[NSAIAD04] National Security Agency, “Information Assurance Directorate, Central Security Service.” Available online at http://www.nsa.gov/snac/, 2004. [OSI94] International Standards Organization, “ISO 7498-1 Information Processing Systems—Open Systems Interconnection—Basic Reference Model: The Basic Model,” Technical Report, 1994. [RFC2504] Guthman, E., et al., “RFC-2504 User’s Security Handbook.” Available online at http://www.ietf.org/rfc/rfc2504.txt, February 1999. [RFC3838] Barbir, A., et al., “RFC-3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES).” Available online at http://www.ietf.org/rfc/rfc3838.txt, August 2004. [SUN04] Sun Microsystems, “How to Develop a Network Security Policy: An Overview of Internetworking Site Security.” Available online at http:// itpapers.zdnet.com/whitepaper.aspx?scid=285&kw=&dtid=0&sortby=dated&do cid=984.
Appendix
B
About the CD-ROM
his appendix describes the contents of the CD-ROM distributed with this book.
T
SYSTEM REQUIREMENTS Some of the files on the CD-ROM are Microsoft Office format files—Microsoft Word, PowerPoint, and Visio® format files. Your system must have the appropriate software installed to be able to use these files. Adobe® Acrobat® Portable Document Format (pdf) copies of these files are provided on the CD-ROM. PDF viewers for many operating systems are freely available. See http://www.adobe.com/ support/downloads/main.html for a pointer to the free Adobe Reader. For the XML source files distributed on this CD-ROM, you will need a system with Web Services support software installed. Examples of Web Services implementations are available from many companies and as open source from http://apache.org/. Any Windows, Macintosh, or UNIX system that allows reading this CD-ROM will have the ability to view and display the files on this CD-ROM. Viewing the Adobe Acrobat PDF format files will require use of a system that supports the Acrobat viewer and will be able to use most of the files on this CD-ROM. Office software may have additional hardware (CPU or memory) or software requirements. 401
402
Enterprise Web Services Security
CD-ROM CONTENTS The CD-ROM distributed with this book contains four major items: 1. Copies of all of the XML listings referenced in the book, in the folder “Code Samples.” 2. Copies of all figures used in this book, organized by chapter. The folder name is “Figures.” 3. A document containing all reference materials used from this book, with clickable hyperlinks in the folder “References.” This document is provided in Word and HTML formats. 4. A work sheet that can be used to capture the information needed when deploying a Web Services system as described in Chapter 15, in the folder “WorkSheet.”
WEB SITE Errata for this book and an up-to-date reference document is available on the Web at http://www.rickmurphy.net/WebServices/.
Index
3DES encryption, 236–237 A access control auditing, 287 choosing decision points, 220–221 described, 13 in enterprise Web Services, 354–355 file, permissions, 182–183 filesystems, filesystem-based databases, 214–217 identity mapping schemes, 217–219 mandatory controls, 219 to servers, 177–178 vs. authorization, 213 accounts, user. See user accounts active attacks, 124 active auditing, 292 ActiveX and browser security, 159, 163 browser support for controls, 75 controls, downloading, 165 controls, and mobile-code threats, 32–33 security of, 167–169 actors, Web Services, 349–351 addresses, IP. See IP addresses administration, system, and security, 178 administrators, weak administrative control vulnerability, 24 AES (Advanced Encryption Standard), 227, 238, 359 aggregators, agora described, 4 algorithms See also specific algorithm decryption, 227 hash, described, 248 RC4, 238 secure hash algorithm (SHA1), 133 XML encryption (table), 139, 267 XML signature (table), 141–142, 273–274 alliances described, 4 Amazon.com, ActiveX control support, 75 angle brackets () and BNF rules, 131 antivirus programs and client protection, 37 Apache Web server vulnerability, 82 Web Services toolkit for, 116 applets browser handling of, 162 described, 170 Java, vulnerabilities, 76–77 application-layer encryption, 191 applications auditing, 289–291 Web Service, security of, 157 architecture common object request broker architecture (CORBA), 9 services-oriented (SOA), 87 single server (fig.), 216
Web browser (fig.), 160 Argus auditing tool, 294 ARPAnet, scalability and reliability, 59 ASP.NET servers, 211–212 assembly of managed code components, 166 assets identifying those to protect, 122–123 protecting your, 41–42, 48 asymmetric, symmetric key encryption, 230–234 asynchronous communications and SOAP, 99 attacks See also specific attack countermeasures. See countermeasures described, 20–21 against environment, 47 IATF types, 124 threats, vulnerabilities, countermeasures, 20–21 attributes and pseudonym services, WS-Federation, 333 WS-Policy, 133 and XML, 88–90, 93 auditing data processing, intrusion detection and prevention, 293–295 goals, what to audit, 283–285 levels of, 286–292 in security policy document, 396 and server policy guidelines, 178 authentication and applets, 366 basic types, patterns, 198–199 described, 13 in enterprise Web Services, 353–354 IIS, Windows, 211–213 Java Authentication (JAAS), 210 Kerberos, 137, 145, 197, 202–205, 258–259 public key, 36 spoofing, 32 SSL (Secure Sockets Layer), 243–246 systems described, 57–58 user IDs, passwords, 198–199 weak and strong, 181 and Web servers, 208–210 and WS-Security standard, 135–137 X.509 certificates, 200–201 Authenticode, 168–169 authorizations in enterprise Web Services, 354–355 and authentication, 208–210 availability network vulnerability, 173 security goal, 55–56 B B2B (business to business), 3–4 B2C (business to consumer), 4 backups, 396 Backus-Naur-Form (BNF) rules, 131 Bagel worm, 157
Base-64 encoding, 33, 133 Basic Authentication, 181 BGP (Border Gateway Protocol), 78 black hat hackers, 25 Blaster worm, 72 block ciphers, 228 blogs (Web logs) and zombie attacks, 27 book, this CD-ROM contents, system requirements, 401–402 organization of, audience for, xxii–xxiv Border Gateway Protocol (BGP), 78 bots, botnets, 157 breaches of privacy, confidentiality, 27–29 brokered relationships and data protection, 193 brokering portals, 4 browsers and HTTP, 68 security of, 159–164 vulnerabilities, 74–76 brute-force attacks, 37 buffer overflow attacks, 36, 43 bulk data encryption, 29 business on the Internet, 3–5 transactions, and nonrepudiation, 250–251 and trust relationships, 299–301 business to business (B2B), 3–4 business to consumer (B2C), 4 bytecode, 76, 170 C CAB files, 166 callback functions, and auditing, 290 cascading style sheets (CSSs), 97 CD-ROM with book, contents and system requirements, 401–402 certificate authorities in enterprise Web Services, 360 and identity management, 197 and X.509 public key authentication, 200–201 certificates and asymmetric key systems, 231 digital, 197 PKI, and information protection, 29–30 and SSL, 57–58 channels, secure, 190 checksums, cryptographic, 30 Children’s Online Privacy Protection Act, 5 chokepoints described, 58–59 CIA triad, triangle, 53–54, 56 ciphertext, 228 ciphertext attacks, 229–230 classful, classless network masks, 65 classified information and asset protection, 123 clients credentials, 254–255 in enterprise Web Services, 350 HTTP, 68 protecting, 156–157
403
404
Index
and servers, networked system model, 21–22 SSL (Secure Sockets Layer), 244–246 system vulnerabilities, 73–76 in Web Services exchanges, 188–190 Web Services, protecting, 37 close-in threats, 124 code assemblies described, 166 Base-64 encoding, 33 malicious, execution of, 168–169 mobile-code threats, 32–34 reviews, using for debugging, 44 signing techniques, 169 colons (:) and BNF rules, 131 COM controls, 167 comments in XML, 90 common broker trust model, 194–195 Common Criteria Evaluation and Validation Scheme described, 45 operating system security, 159 security assurance levels (table), 46 threat evaluation, 50 Common Gateway Interface (CGI) vulnerabilities, 179–180 and Web server vulnerabilities, 82 and Web servers, 208 Common Language Runtime (CLR), 163 common object request broker architecture (CORBA), 9 communicating security credentials, 253–277 communications channels, securing, 190–192 compromises described, 20 ‘Computer Crime and Security Survey,’ 125 Computer Matching and Privacy Protection Action of 1988, 7 Computer Security Institute (CSI), 125 computing environment defense, in security policy document, 387–391 confidence schemes, 34 confidentiality breaches, 27–29, 36 and CIA triad, encryption, 226–242 considerations in trust relationships, 310–311 controls, 54 and cryptography, 251 described, 13 on the Internet, 6–7 network vulnerability, 173 protection mechanisms (table), 28 services, in enterprise Web Services, 355–356 vs. integrity vs. availability, 55 Confidentiality assertion, WS-SecurityPolicy, 137–138 confusion, and ciphertext attacks, 229 connections, encrypted, SSL and TLS, 243–246 container authorization, 211 content filtering, 393 contracts, and nonrepudiation, 59 controls ActiveX, security, 167–169 administrative, 24 confidentiality, 54 cookies, 30, 158 copyright protection and the Internet, 6 corporate confidentiality, 6 costs of security incidents, 125–126 countermeasures choosing the right, 51–52 described, 21 to mobile code attacks, 34 to Web Services security challenges, 13, 20–21 crackers, techniques of, 49 credentials client-server communication, 254–255 communicating security, 253–254 forged user, 37 using in trust domains, 309–310, 311 WS-Security, 255–279 credit cards and online identification, 130 protections, 28
smart cards, 196 cryptographic checksums, 30 controls on BGP, 78 protections and network security, 174 wireless protection, 174–175 CSSs (cascading style sheets), 97 D data backups and retention, 396 protecting close to source, 220–221 Data Encryption Standard. See DES data integrity, violations of, 29–30, 46–47 data processing, audit, 293–294 data protection data at rest, 377–378 data in transit, 375–377 data in use, 378–381 self-protecting data, 374–375 database audit logs, 288–289 database management systems. See DBMSs Database Nation (Garfinkel), 28 database servers vulnerabilities, 83 datagrams, 23 DBMSs (database management systems) in security policy document, 389 using for access control, 214–217 debugging, using code reviews, 44 decision points, access control, 220–221 declarations, XML namespace, 89 declarative security, 211 decryption algorithms, 227 defense-in-depth IATF framework, 126–127 security policy, 120–121 delegated trust relationships, 304, 307–308 denial of service (DoS) attacks described, 10, 26–27, 124 eBay, 48 and server security, 180–181 Web Services environmental considerations, 35–38 DES (Data Encryption Standard), 234–237, 359–360 DHCP (Dynamic Host Control Protocol) described, 78 DHTML (dynamic HTML), 172 Diffie-Hellman encryption, 192, 239–241 diffusion, and ciphertext attacks, 229 Digital Capital (Tapscott), 4 Digital Encryption Standard (DES) encryption, 192 digital rights management (DRM), 379–380 digital signatures Authenticode, 169 and CIA triad, 247–250 creation, XML (fig.), 271 and nonrepudiation, 250–251 and online transactions, 59 digitally signed cabinet (CAB) files, 166 direct brokered trust relationships, 307 direct identity mapping, 206 direct trust model, 195, 303–304, 306 directory services and LDAP, 201–202 disaster recovery, 396–397 display engine, browser, 161–162 distributed authentication schemes, 57 distributed denial of service (DDoS) attacks, 26–27 distribution attacks, 124–125 distribution of enterprise services, 364 distributive networks described, 4 DNS (Domain Name Service) and address translation, 65 poisoning, 36 and single points of failure, 59 and spoofing attacks, 78 Document Object Model (DOM) and SOAP, 101 document-style messaging, SOAP, 99–101 documents security policy, 127, 383–399 simple XML (fig.), 88–89
well formed, valid, testing for, 95 domain name service. See DNS domains creating virtual trust, 314–319 hierarchy of principals and (fig.), 313 security, 15, 71–73 trust, 304–306 DoS. See denial of service (DoS) attacks downloading plug-ins and helper applications, 165 Spybot Search and Destroy, 173 system components, 164–167 DRM (digital rights management), 380 Dynamic Host Control Protocol. See DHCP dynamic HTML pages, 82, 172 dynamic link libraries (DLLs), and operating system security, 160 E eBay, DoS attacks on, 48 EC-MAScript, 172 EDI (electronic data exchange), 4 email proof of origin, 81 and Web bugs, 80 enclaves, network, 15 encryption See also specific type bulk data, 29 DES (Data Encryption Standard), 234–237, 359–360 key distribution problem, 230 link, network, application layer, 191 point-to-point, 191 SSL, TLS, 243–246 steganography, 242–243 symmetric, asymmetric key, 230–234 systems and approaches, 226–229 types, 192 XML, 139, 143 end-to-end encryption, 192 enterprise Web Services allocating new infrastructure services across domains, 362–364 allocating security services across actors, 364–371 distributing services, 371 identifying domain infrastructure, capabilities, 351–353 identifying gaps, projecting virtual trust domain, 356–362 identifying necessary security services, 353–356 identifying parties involved, 349–351 overview, 348–349 security policy document development, 383–399 environment attacks against, 47 plug-in and ActiveX (fig.), 164 Web Servers security considerations, 47 events, auditable, 285 exploits, availability, 50–51 extended SMTP (ESMTP), 80 eXtensible Access Control Markup Language (XACML), 197, 309, 340–344 eXtensible Markup Language. See XML extranets, security, 12 F ‘f00f’ bug, 46 federated trust model, 195 federation metadata, WS-Trust, 333 File Transfer Protocol (FTP), 2, 64 Financial Modernization Act of 1999, 7 firewalls in enclave defense, 391 and network domains, 72 network logs, and auditing, 287–288 and security, 175
Index
format attacks, 36 forms, online, and browser security, 159 Fortezza authentication, 192 fraud types of, 34–35 and Web Services, 38 FTP (File Transfer Protocol), 2, 64 full-duplex connections, 66 G game programs and mobile-code threats, 33 Garfinkel, Simson, 28 gateways CGI flaws, 179–180 notional wireless (fig.), 370 security of, 176 spam filtering, 393–394 and wireless networks, 12 Gator, license agreement, 37, 38 general security context model, 301–302 GET method and HTTP, 69 GNU Privacy Guard (GPG), 81 Gopher system and server vulnerabilities, 81 Gramm-Leach-Bliley Act, 7 guards, security, 176, 393 H handshake, three-way, 66 hardware vulnerabilities, 45–47 hash algorithms, 248 HEAD method and HTTP, 69 headers HTTP request, 69–70 WS-Security , 256–265 Health Insurance Portability and Accountability Act of 1996 (HIPAA), 5 heap corruptions, 43 hierarchies, trust, 314, 317 high-assurance systems, 44 high-integrity information, 29 HIPAA (Health Insurance Portability and Accountability Act of 1996), 5, 7 Homeland Security threat levels, Web site, 47, 48 host penetration attacks, 10 hosts and DoS attacks, 35–36 HotJava, 169 HTML (HyperText Markup Language) and browser security, 161–162 dynamic (DHTML), 172 protocol described, 2 and Web pages, 67–68 HTTP (HyperText Transport Protocol) described, 67–71 protocol described, 2 services, security, 389 and TCP, 66 and TCP/IP, 64 HTTP over IP (IPSEC), 191 hubs, and security, 176 HyperText Markup Language. See HTML HyperText Transport Protocol. See HTTP I IATF. See Internet Engineering Task Force ICMP (Internet Control Message Protocol) described, 78 identity management and trust, 192–198 IDSs (intrusion detection systems), 294–295, 395 impact of threats, 50 in-band, out-of-band credentials exchange, 188 incident handling, response, 398–399 indirect brokered trust relationships, 307 indirect identity mapping, 206 INF files, 166 information assurance practice, 44 audit, 286 classified, 123 high-integrity, 29
protection, privacy, confidentiality, 5–7 security, assurance, 60 information (INF) files, 166 information security (CIA) triad, implementing, 225–226 information technology (IT), security policy importance, 120–121 infrastructure, IT defending supporting, 394–397 in enterprise Web Services, 351–353 and security policy, 122–127 Inquiry API, UDDI, 109 insider attacks, 124–125 integrity attacks, 36 checking, 247–249 considerations in trust relationships, 310–311 data, violations of, 29–30 digital signatures, nonrepudiation, 247–251 message, described, 13 network vulnerability, 173 services, in enterprise Web Services, 356 violations described, 43 vs. confidentiality, 54–55 Integrity assertion, WS-SecurityPolicy, 139–142 integrity checking, 247 Intel Pentium ‘f00f’ bug, 46 interception attacks, 46–47 interfaces, Web Services, 106 Internet Control Message Protocol. See ICMP Internet Engineering Task Force (IATF) security policy recommendations, 122 standards for security policy, 387 Web site, 59 Internet Explorer browser vulnerability, 74–76 CLR use, 163 and security domains, 73 Internet Information Server (IIS) authentication, 211 Internet Protocol (IP) and TCP/IP, 23 Internet, the See also Web, the address hierarchy (fig.), 64 business on, 3–5 business risks and, 11–12 intranets, security, 11–12 intrusion detection systems (IDSs), 294–295, 395 intrusion prevention systems (IPSs), 294–295, 395 IP (Internet Protocol), 23, 64 IP addresses and DHCP, 78 forged, 37 spoofing, 32 and TCP/IP, 65–67 IP packets and TCP/IP flaw, 77 IP Security (IPSec), 177 IPSs (intrusion prevention systems), 294–295, 395 J Java and browser security, 159 language, and security, 169–171 Java 2 Enterprise Edition (J2EE) in enterprise Web Services, 365–367 Web Services toolkit for, 115–116 Java applets and mobile-code threats, 32–33 Java Archive (JAR) facility, 164 Java virtual machine (JVM) and browser functions, 162–163 function described, 170–171 vulnerabilities, 76–77 JavaScript vulnerabilities, 74–75 K Kazaa, license agreement, 38 KDC (Kerberos Key Distribution Center), 197 Kerberos authentication, 137, 145, 197, 202–205, 258–259 key attacks described, 10
405
key files and server policy guidelines, 178 key management and VPN, 177 keys and token extensions, WS-Trust (table), 329–330 keystroke logging, 37 L LANs (local area networks) and extranets, 12 and the Internet, 64 LDAP (Lightweight Directory Access Protocol) and directory services, 201–202 levels of auditing, 286–292 LexisNexis spoofing attack, 32, 34 Liberty Alliance Project, 198 license agreements See also specific programs antivirus programs, 37 Lightweight Directory Access Protocol (LDAP), 201–202 link encryption described, 191 local area networks (LANs), 12,64 locked down systems described, 22 locking down servers, 178 system subcomponents, 22 logical trust domains, 305, 308–314 logins and replay attacks, 37 logs, audit, 284, 286 lottery scams, 35 M malware, 168 man-in-the-middle attacks, 30–31, 36 management identity, approaches (fig.), 195 mapping identities to resources and privileges (fig.), 206 identity scheme, choosing, 217–219 roles, 207 threats to loss (fig.), 126 masks, network, 65 masquerade attacks, 124 MD5 encryption, 192, 208, 249–250 merging security policies, 135 message archive attacks, 10, 27–29 Message Digest, Version 5 (MD5) encryption, 192, 208, 249–250 message digests, and encryption, 248–249 message sequence numbers and spoofing, 32 MessageAge assertions, WS-SecurityPolicy, 144 messages HTTP formats (fig.), 68 ICMP, 78 modification attacks, 124 protecting, WS-Security, 276–277 SMTP, 79–81 SOAP, 99–102 WSDL, 106–108 messaging model, SOAP, 9 secure, in security policy document, 389 meta-symbols and BNF rules, 131 Metcalf’slaw, 2 Microsoft Web server security, 159 Microsoft IIS (Internet Information Server), authentication on, 211 Microsoft .NET Passport, 197–198 Microsoft Open Database Connectivity (ODBC), 215 Microsoft SQL Server bug, 50–51 Microsoft’s Web Developer Center, 115–116 middleware, auditing, 289 MIME (multimedia Internet Mail extension) and HTTP requests, 68 S/MIME (Secure MIME), 81 and SMTP, 79–81 types, 163 mobile-code threats, 32–34, 37, 390–391 mobile, data protection, 374 models
406
Index
basic security (fig.), 189 business webs, 4–5 experience-based trust (fig.), 315 general security context, 301–302 message security, 255–256 messaging, 9 networked client-server system, 21–22 NSTISSC security (fig.), 56 OSI, , 190, 309, 397 reputation-based trust, 318–319 SAML (fig.), 338 service allocation (fig.), 363 SOAP-RPC (fig.), 103 trust relationships, 194 virtual domain, for Web Services security, 15–16 web-of-trust (fig.), 316 Web Services policy (fig.), 131 Web Services trust, 324–325 WS-Federation, 331–333 WSDL abstraction (fig.), 106 XACML processing, 341–342 XKMS (fig.), 336 Mozilla browser, 74 multimedia Internet Mail extension. See MIME multiple-domain relationships, 306 mutual trust relationships, 304 N naïve trust relationship, 303 namespaces, XML, 90–92 National Institute for Standards and Technology, DES encryption, 234, 236, 237 National Security Agency (NSA) operating system security, 159 server hardening guidelines, 182 .NET Framework and browser security, 160 component allocation in, 367–368 managed code and, 167 and Web Services toolkits, 115 Netscape browser vulnerability, 74 and SSL, 192, 243 network logs, 287–288 networks attacks. See attacks botnets, 157 defending, 394 distributive, described, 4 Metcalf’slaw, 2 protocol and server vulnerabilities, 77–83 reliability, ensuring, 21–24 security, vulnerabilities, 173–174 spoofing, 10 virtual private. See virtual private networks vulnerabilities. See vulnerabilities Wi-Fi wireless, 13 nonce, SSL, 244 nonrepudiation and CIA triad, 247–251 and integrity services, 356 and online transactions, 59–60 NSTISSC security model (fig.), 56 O object linking and embedding (OLE), 163, 167 ODBC (Open Database Connectivity), 215 ODRL (Open Digital Rights Language), 380 OLE (object linking and embedding), 163, 167 online fraud, 35 online transactions and nonrepudiation, 59–60 Open Database Connectivity (ODBC), 215 Open Digital Rights Language (ODRL), 380 Open Systems Interconnection (OSI) model, 190, 309, 397 Opera Web browser, 74 operating systems Orange Book (DOD) for operating system security, 45
protecting, 158–159 security of, 181–183, 388 Oracle Internet Directory (OID), 202 Oracle Proxy User, 216 Orange Book (DOD) for operating system security, 45 OSI (Open Systems Interconnection) model, 190, 309, 397 out-of-band, in-band credentials exchange, 188, 311 overload attacks, 46 P pass-phase, password services, 195–196 passive attacks, 124 passive auditing, 292 Passport service (Microsoft), 197–198 passwords and authentication, 199 and authentication spoofing, 32 and pass-phrase services, 195–196 and server policy guidelines, 178 sniffing and, 37 and Web servers, 208 patches and server policy guidelines, 178 and worms, 71–72 PE image files, 166 peer-to-peer described, 9 penetration, host, network, 10 permissions and access control, 182–183 personnel security, in security policy document, 386 physical access to servers, 177 physical security, in security policy document, 385 physical trust domains, 305, 308–314 pipe (|) and BNF rules, 131 PKI (public key infrastructure) and information protection, 29 and SSL, 244 using, 31 plaintext attacks, 229–230 plaintext format, 158 planning security policy, 122–127 plug-ins and security, 164–165, 172–173 point-to-point encryption, 191 Point-to-Point Protocol (PPP), 309 policy security. See security policy WS-Policy, 131–135 policy decision points (PDPs), 197 policy enforcement points (PEPs), SAML model, 339 pop-up blockers, 74–75 portable executable (PE) image files, 166 portals, B2B (business to business), 3–4 POST method and HTTP, 69 PPP (Point-to-Point Protocol), 309 Pretty Good Privacy (PGP), 81 principal trusts, 312–314 privacy and asset identification, 123 breach mitigation, 36 on the Internet, 5–6 threats, 27–29 violations described, 43 Privacy Act of 1974, the, 7 procurement portals, 4 protecting company assets, 41–42 data in transit, at rest, in use, 375–381 file content, 183 information on the Internet, 5–7 sensitive Web server content, 82 protocol stacks, Web Services (fig.), 86 protocols See also specific protocol client-server, 23 connectionless, connection-oriented, 65–66 encrypted, 29 network, and vulnerabilities, 77–83
reusable design, 23 routing, 78 sessionless, 161 standards-based, 2 proxy trust relationships, 304 public key infrastructure. See PKI publish, and public keys, 231 Publish API, UDDI, 109 publisher assertion framework, UDDI, 114 PUT method and HTTP, 69 Q quotation marks (“”) and attributes, 89 R RBAC (Role-Based Access Control), 218 RC4 algorithm, 238 redirect attacks, 36 reduction tools, audit processing, 293 references, token, 261–265 registering Web Services, 109 REL (rights expression language), 380 relational database management system (RDBMS), 202 relationships trust. See trust relationships WS-DBMS (table), 217 reliability, ensuring, 21–24 remote access attacks, 125 in enclave defense, 392 remote hosts, secure connections, 243 remote procedure calls. See RPCs replay attacks, 43, 47, 78, 124 replay-based spoofing attacks, 31–32, 37 replication, mitigating DoS attacks, 35–36 repudiation attacks, 10 request messages, SOAP-RPC (listing), 104 request-response model, SOAP and, 9 requests headers, 69–71 element, WS-Trust, 325–327 residual risks, 52 responsible organizations, in security policy document, 385 rights expression language (REL), 380–381 Rijndael algorithm, 238 RIP (Routing Information Protocol), 78 risks assets protection, 42 authentication service, 207 minimizing, 53 with networks, 2 reducing vulnerabilities, 43–47 and security policy, 120–121 Rivest Cipher (RC) encryption, 192 Rivest, Ron, 249 Rivest, Shamir, and Adelman (RSA) algorithms, 192, 227, 241–242 Role-Based Access Control (RBAC), 218 role mapping, 206 routers, security of, 176 routing protocols, and packets, 78, 102 Routing Information Protocol (RIP), 78 RPCs (remote procedure calls) and SOAP-RPC, 103–105 vs. XML schema, 100 RSA encryption, 192, 227, 241–242 RuBAC (Rule-Based Access Control), 219 rules Backus-Naur-Form (BNF), 131 XSLT transformation, 97 S S/MIME (Secure MIME), 81 sabotage, 24–26, 35 SAML assertions and WS-Federation, 337–340 and WS-Security, 259–260
Index
sandboxes, Java, 33, 76, 171, 378 Sapphire worm, 49, 50–51 Sarbanes-Oxley Act of 2002, 5 Sasser worm, 72 SAX (Simple API for XML), 101 scalability, transaction security goal, 58 scanning tools, and auditing, 293 schemas, XML, 89, 92–95 scope security policy, 152 XML namespace declaration, 91 script-kiddies, 25, 49 scripting language interpretation by browser, 162 security of, 171–172 secure channels, 190 Secure Hash Algorithm (SHA) encryption, 192 secure hash algorithm (SHA1), 133, 140, 250, 257 Secure Sockets Layer. See SSL securing communications channels, 190–192 security assurance levels (table), 46 basic model (fig.), 189 of browsers, 159–164 challenges for Web Services, 10–13 controls for system components, 155–156 credentials. See credentials declarative, 211 from different perspectives (fig.), 121 domains, 15, 71–73, 352 enclave defense, 391–393 enterprise perspective, 348 firewalls. See firewalls gateways, guards, routers, 176 goals, conflict between, 53–56 implementing the information security (CIA) triad, 225–251 incident handling, response, 398–399 Java, 169–171 in networked world, 1–3 operating system, 158–159 plug-ins, 172–173 policy. See security policy programs, protecting assets, 41–42 scripting, 171–172 servers, Web servers, 177–181 standards, in security policy document, 386–387 terminology, 42–43 token service (STC), 324–330 transaction security goals, 56–60 vulnerabilities. See vulnerabilities Web Services virtual domain model, 15–16 Wi-Fi, 13 and wireless networks, 12–13, 174–175 zones, and ActiveX, 169 Security Assertion Markup Language (SAML), 14, 197, 337–340 header, WS-Security, 256–265 security policy basics of, 119–121 challenges for Web Services, 10–11 communicating, expressing in Web Services, 129–135 developing, 121–127 document development, 383–399 effective, 152–153 making discoverable, 148–152 role in Web Services security enforcement, 60–61 trusted domains, 71–73 tying to subjects, 146–148 WS-* family of standards, 14 WS-SecurityPolicy, 135–146 SecurityHeader assertions, WS-SecurityPolicy, 143–144 SecurityToken assertion, WS-SecurityPolicy, 136–138 self-protecting data, 374–375 self-registration, 311 self-trust relationships, 303 Serial Line Internet Protocol (SLIP), 309
servers ASP.NET, 211–212 hardening, 182 J2EE (Java 2 Enterprise Edition), 210–211 locking down, 178 logs, and auditing, 288 Microsoft Passport, 197–198 and RPCs, 8 scalability and bottlenecks, 58–59 security of, 177–178, 388 vulnerabilities, 81–82 service-granting service (SGS), Kerberos, 203–204 services authentication. See authentication passwords, pass-phase, 195–196 Web. See Web Services sessionless protocols, 161 sessions, SSL (Secure Sockets Layer), 192 SHA1 (secure hash algorithm), 133, 140, 250, 257 shared secrets Kerberos, 202 WS-SecureConversation, 334 signatures digital. See digital signatures signed code, 171 XML, 140, 271–276 Simple API for XML (SAX), 101 Simple Object Access Protocol. See SOAP single-domain relationships, 306 single sign-on, 337 Site Security Handbook (IATF), 122 Slammer worm, 50–51 SLIP (Serial Line Internet Protocol), 309 smart cards, 196 SMTP (Simple Mail Transfer Protocol) vulnerabilities, 79–81 sniffing user passwords, 37 SOAP-RPC model, messages, 103–105 SOAP (Simple Object Access Protocol) auditing, 289 described, 8–9 messages, 99–102 request-response model (fig.), 87 and WS-Security standard, 60 sockets described, 66 source routing, 78 spam and workstation vulnerabilities, 157–158 and SMTP vulnerability, 79–81 and spyware, 33 spoofing attacks, countermeasures, 31–32 DNS, 78 forged IP addresses, user credentials, 37 network, 10 Spybot Search and Destroy, 173 spyware detection, 34, 173 and mobile code, 33, 37 SQL Slammer worm, 45, 50–51 SSL (Secure Sockets Layer) and authentication, 57–58 implementing, 243–246 and information protection, 29 and Microsoft Passport, 198 and network vulnerabilities, 174 using to establish secure sessions, 192 stand-alone document declaration (SDD), 89 standards browser, 75 future evolution of, 373–374 protocols, history of, 2 in security policy document, 386–387 Web Services, 85–105 WS-* family of, 14–15 status codes and HTTP responses, 70 STC (security token service), 324–330 steganography techniques, 242–243 stream ciphers, 228 style sheets, 96–99 supply portals described, 4 switches, and security, 176
407
symmetric, asymmetric key encryption, 230–234 synchronous communications and SOAP, 99 system isolation and information protection, 29 system requirements, CD-ROM, 401–402 systems authentication, 57–58 component audit logs, 288–289 cracker techniques, 49 downloading components, 164–167 operating. See operating systems secure, high-assurance, 44 security controls for components, 155–156 T Tapscott, Don, 4 TCP/IP (Transmission Control Protocol/Internet Protocol) and encryption, 191 packet transmission, 65–67 protocol described, 2, 23, 64–65 and SOAP, 9 vulnerabilities, 77–78 TCP stacks and zombie attacks, 26–27 TCP (Transmission Control Protocol) and TCP/IP, 23 telephones and wireless security, 12 testing for well formed and valid documents, 95 theft over the Internet, 6 third-party trust brokers, 196–197 relationships, 304 threats See also attacks assessing impact of, 50, 125 Common Criteria evaluation, 45, 50 Homeland Security levels, 48 IATF types, 124 mapping to loss (fig.), 126 mobile-code, 32–34 vulnerabilities and countermeasures, 20–21 Winkler’s threat level equation, 52–53 three-way handshake and TCP/IP, 66 ticket-granting service (TGS), Kerberos, 203–204 TLS (Transport Layer Security) described, 29 implementing, 243–246 tModel structure, UDDI, 113–114 types and keys (table), 150 tokens services, in enterprise Web Services, 352 valid WS-Trust (table), 326 and WS-Security standard, 136, 257–265 WS-SecurityPolicy TokenType values (table), 137 traffic analysis attacks, 10 trails, audit, 284 transaction security goals, 56–60, 187–188 transactions and trust relationships, 299–301 transformations WS-Policy compact to normal form rules (table), 134 XSL and XML, 96–98 Transmission Control Protocol/Internet Protocol. See TCP/IP transmission state diagram (fig.), 66 Transport Layer Security (TLS), 29, 243–246 trapdoor functions, 241 Trojan horses, 10, 33 trust relationships business and, 299–301 and data protection, 187–188 between domains, 306–308 general model for (fig.), 302 identity management and, 192–198 and OSI model, 309 in security domains, 16 and spoofing, 31–32 types of, 302–308, 321–324 types of (fig.), 194 Web Services exchange protection, 188–190
408
Index
trusted computing base (TCB), 44, 73 trusted domains, 71 trusted sites zone, 169 tunneling attack described, 10 in enterprise Web Services, 362 U UBAC (User-Based Access Control), 217–218 UDDI. See Universal Description, Discovery, and Integration UDDI Business Registry (UBR), 109 uniform resource locators. See URLs Universal Description, Discovery, and Integration (UDDI) attaching security policies using, 149 described, 14 and Web Services, 86, 109–115, 319 and WS-Federation, 333 UNIX operating system security, 159 URLs (uniform resource locators) and WS-Policy, 133 user accounts and operating system security, 181–182 User-Based Access Control (UBAC), 217–218 user credentials, forged, 37 User Data Protocol (UDP), 66 user IDs for authentication, 199 user name tokens, WS-Security, 257–258 usernames and WS-Security standard, 137–138 User’s Security Handbook (IETF), 157 V value chains, 4 vandalism, 24–26, 35 verifying digital signatures, 271–272 virtual domain model for Web Services security, 15–16 virtual private networks (VPNs) in enclave defense, 392 and encryption, 230 security of, 177 virtual trust domains, 305, 314–319, 356–362 viruses described, 10 and mobile code, 33 protection, 393 Visibility assertion, WS-SecurityPolicy, 142–143 VPNs. See virtual private networks vulnerabilities CGI, 179–180 client system, 73–76 described, 21 HTTP, SMTP, 79–81 Java virtual machine (JVM), 76–77 network, 173–174 reducing, 43–47 TCP/IP, 77–78 weak administrative controls, 24 Web servers, 82, 179–181 workstation, protecting, 157–158 W WAP (Wireless Application Protocol), 12, 157, 369–370 warranty registration cards, 28 Web browsers. See browsers Web bugs, 80 Web pages, and dynamic HTML pages, 82 Web servers access logs, 289 and authentication, 208–210 security of, 177–181 vulnerabilities, 82, 179–181 Web Services described, 7–8 enterprise. See enterprise Web Services environments, special security considerations for, 35–38
exchange protection, 188–190 introduction to, xxi–xxii and mobile computing, 381 protocols. See specific protocol security challenges for, 10–13 security policy. See security policy standards, 85–105 threats and attacks, reliability, 19–24 toolkits, 115–116 transactions. See transactions trust relationships. See trust relationships vandalism, sabotage, 24–26 virtual domain model for security, 15–16 Web Services Description Language (WSDL) described, 86 in exchange, 189 and WS-PolicyAttachment, 130 Web Services Distributed Management (WSDM), 292 Web Services Interoperability Organization (WSI), 10 Web Services Routing Protocol (WS-Routing), 102 Web sites authentication, 57 and browser support, 74–75 Homeland Security, 47 Microsoft’s Web Developer Center, 115 ‘secure,’ 12 this book’s errata, 402 Web, the See also Internet, the described, 63–64 and HTTP, 67–71 WEP (Wired Equivalent Privacy), 175 Wi-Fi networking hardware, 13 security of, 174–175 Windows authentication, 212 operating system security, 159 Winkler, Ira, 52 Wired Equivalent Privacy (WEP), 175 Wireless Application Protocol (WAP), 12, 157, 369–370 wireless networks component allocation in (fig.), 369 security of, 12–13, 174–175 Wireless Protected Access (WPA), 175 workstations security, 388 vulnerabilities, 157–158 World Wide Web. See Web, the worms Bagel, 157 Blaster, 72 and mobile code, 33 network, 45 Sapphire, 49 Sasser, 72 SQL Slammer, 45 WPA (Wireless Protected Access), 175 WS-* family of standards for Web Services, 14–15 WS-Security standard (OASIS), 60 WS-Federation concepts, model, 330–333 WS-Policy, 130–135 WS-PolicyAttachment, 146–153 WS-SecureConversation, security context, binding, 334–335 WS-Security, 255–279, 378 WS-SecurityPolicy, 135–146 WS-Trust, 302, 324–330 WSDL attaching security policies using, 148 and Web Services interfaces, 105–108 WSDM Management of Web Services (MOWS), 292 WSDM Management Using Web Services (MUWS, 292 WSDM (Web Services Distributed Management), 292
X X-KRSS service, model, 335–337 X.509 certificates authentication, 200–201 and identity management, 197 and Web Services, 130 and WS-Security standard, 137, 145, 258–259 XACML (eXtensible Access Control Markup Language), 197, 309, 340–344 XKMS (XML Key Management Specification), 335–337 XML Events, 102 XML Events, auditing, 290–292 XML (eXtensible Markup Language) encryption and BNF, 131 described, 2, 8, 138, 143 protecting data at rest, 378 signature algorithms (table), 141–142 signatures, 271–276 tying security policies to subjects, 146–148 and Web Services, 85–99 and WS-Security, 265–277 and WS-Security standard, 60 XML Key Information Service Specification (XKISS), 336 XML Key Management Specification Bulk Operations (X-BULK), 337 XML Key Management Specification (XKMS), 335–337 XML key management specification (XKMS), 14 XML Path Language (XPath), 96–98 XML Pointer Language (XPointer), 98 XPATH filtering, 276 XPath (XML Path Language), 96–98 XSL (eXtensible Stylesheet Language), 96–98 XSL-FO (XSL Formatting Objects), 96–98 XSLT (XSL Transformations), 96–98 Z ‘zero-day’ attacks, 49 zombie attacks, 26–27, 33, 157–158 zones, trusted sites, 169
