Proposed security section

This is a working draft of a proposed section on Security for the 
stakeholder's section.

I have stolen text where possible from the document produced by the 
security TF, and from Mike Mahan's initial text; but all errors are 
mine. Comments are welcome; especially constructive ones!

Security and the WSA

Goal AG004 of the WSA requirements states that "The WSA must provide a 
secure environment for online processes". This is further analyzed into 
two critical success factors: security (AC006) and privacy (AC020).

Security, and privacy, issues are often extremely detailed and often 
quite implementation specific. For example, there are many famous cases 
of security being compromised through the incorrect implementation of 
fixed-length buffers ( so-called buffer overruns permit an intruder to 
corrupt a target's address space and sometimes to gain unauthorized 
access). This architecture is necessarily at a level of abstraction 
where such considerations are moot; since implementation itself is out 
of scope for the architecture.

In the context of security, the prime concerns in the development of 
the WSA are the identification threats to security and what 
architectural features are necessary to respond to those threats.

3.xx.xx Threats to security and privacy

Security issues tend to revolve around access and use of resources; the 
primary task being to ensure that it is not possible for intruders to 
access resources for which they do not have the appropriate rights. We 
can summarize the principal security threats as:

1. Inappropriate access on behalf on unauthorized entities. It should 
be possible to reliably determine the identity of entities such as 
agents, service providers, resources and so on.
2. Corruption of communication and resources. It should be possible to 
ensure the data integrity of communications and transactions.
3. Information leaking. It should be possible to ensure that 
information is accessible only to intended parties. This certainly 
includes the content of messages; but may also include the mere fact 
that a communication between particular parties has taken place.
4. Inappropriate access to resources. It should be possible to ensure 
that resources and actions are not possible for entities not properly 
authorized. Again, this often extends to the right to even see that a 
given resource exists: unauthorized persons may not even be permitted 
to know the existence of certain resources or certain actions.
5. Denial of service. It should not be possible for parties to prevent 
legitimate parties to access resources and perform actions that they 
have the right to.

Note that certain theoretical limitations will prevent us from ever 
guaranteeing that these risks do not become realities. However, it is 
certainly a viable goal to significantly reduce the risk of security 
breaches.

There are other security-related threats that this architecture is not 
designed to combat:

1. Non-repudiation. The risk associated with this is that a party may 
subsequently deny its involvement with a transaction.  Non-repudiation 
is important; however, this architecture regards this threat as 
primarily an application-level threat.
2. Mis-information. A malicious party may attempt to corrupt a Web 
service by deliberately feeding it incorrect information. For example, 
by communicating invalid credit card information, a fraudulent Web 
service requester may attempt to gain service that it would not 
normally have the right to. This is similar to the buffer overrun style 
of security breach; however, generally this security breach involves 
sending well-formed but false information.
3. Copy and replay. Given a copy of a Web service agent, it may be 
possible to execute it in an environment that could give a malicious 
party information not ordinarily available. For example, given a copy 
of a Web service requester agent that acts on behalf of a customer, a 
malicious Web service provider may simulate a series of transactions 
with the captured agent in order to determine the maximum price the end 
user is expected to pay for goods and services.

Privacy issues tend to revolve around the use of personal information, 
in particular the abuse of personal information; again, this can often 
be expressed in terms of the wrong people having access to the wrong 
information. We can summarize the threats to privacy as:

1. Information use. An end user may have the right to know how, when, 
and to what extent their personal or sensitive information will be used 
by the Web services processing nodes. Protected usage includes the 
sharing of personal or sensitive information obtained by a processing 
node with any third party. These rights are often founded on 
legislation that varies on a global basis.
2. Confidentiality. Similar to above security threat: third party 
access access to sensitive information represents a threat to the 
privacy of the end user.

Also central is that these practices should be exposed by the 
processing nodes prior to a service invocation, allowing a service 
requestor to factor a processing node’s privacy practices in the 
decision to use a particular Web service or to follow a particular 
message route. Hence, the publishing and accessibility of a Web service 
processor’s privacy practices will aid an end user to retain control 
over his personal information. This is contingent on the compliance to 
the published privacy by the Web service processor and is outside of 
the scope of technology solutions.

3.x.x Policies

The approach adopted in the WSA to address both security and privacy 
concerns revolves around the concept of policy. A policy is a document, 
preferably machine-processable, that expresses some constraint on the 
behavior of the overall system; generally on the behavior of agents. 
Closely connected to the concept of policy is the concept of policy 
guard. A policy guard is some mechanism that is used to enforce policy. 
Hence security is expressed in terms of the policies that the owners of 
resources wish to enforce, together with mechanisms put in place to 
enforce those policies. Similarly, privacy is expressed in terms of the 
policies that the owners of data -- typically the users of Web services 
-- have, together with mechanisms necessary to ensure that the owners' 
rights are respected.

While many policies relate to actions, and to resources, it is not 
always the case. Many security and privacy-related constraints are 
concerned with maintaining certain kinds of state. For example, a Web 
service provider may have a constraint that any P3P tags associated 
with a use of one of its Web services are appropriately propagated to 
third parties. Such a constraint cannot easily expressed in terms of 
the allowed actions that the Web service provider may perform; it is 
really an obligation to ensure that the publicly observable condition 
(the proper use of P3P tags) is always maintained (presumably 
maintained in private also). Similarly, a Web service provider may 
(will) link the possible actions that a Web service requester may 
perform to the Web service requester maintaining a particular level of 
secure access (e.g., administrative tasks may only be performed if the 
request is using secure communications).

Policies can be logically broken down into two main types: permissive 
policies and obligatory policies. A permissive policy concerns those 
actions and accesses that entities are permitted to perform and an 
obligation policy concerns those actions and states that entities are 
required to perform. These are closely related, and dependent: it is 
not consistent to be obliged to perform some action that one does not 
have permission to perform. A given policy document is likely to 
contain a mix of obligation and permission policy statements.

The two kinds of policies have different enforcement mechanisms: a 
permission guard is a mechanism that can be used to verify that a 
requested action or access is permitted; an audit guard can only verify 
after the fact that an obligation has not been met. The precise form of 
these guards is likely to vary, both with the resources being 
controlled and with the implementation technologies deployed. The 
architecture is principally concerned with the existence of guards and 
their role in the architecture. In a well engineered system it may be 
possible to construct guards that are not directly visible to either 
the requester nor the provider of Web services.

A permission guard acts as a guard enabling or disabling action to a 
resource or action. In the context of SOAP, for example, one important 
role of SOAP intermediaries is that of permission guards: the 
intermediary may not, in fact, forward a message if some security 
policy is violated.

An audit guard acts as a monitor; watching resources and agents, 
validating that obligations that have been established are respected 
and/or discharged. Due to the nature of obligations it is often not 
possible to prevent obligations; instead the focus is on observing that 
obligations are respected. If an audit guard detects a policy 
violation, then it normally cannot prevent the violation; instead some 
form of retribution or remediation must be enacted. The precise forms 
of this are, of course, beyond the scope of this architecture.

3.x.xx.x. Policies and security.

The threats enumerated above can be countered by a combination of 
suitable mechanisms and policy documents that govern the enforcement 
mechanisms. For example, the unauthorized access threat may be 
countered by a mechanism that validates the identity of potential 
agents who wish access the controlled resource. That mechanism is, in 
turn, controlled by the policy document which expresses what evidence 
must be offered by which agents before the access is permitted.

Not all guards are active processes. For example, confidentiality of 
information is encouraged (we hesitate to claim guaranteed) by 
encryption of messages. As noted above, it is potentially necessary to 
encrypt not only the content of SOAP messages (say) but also the 
identities of the sender and receiver agents. The guard here is the 
encryption itself; although this may be further backed up by other 
active guards that apply policy.

3.x.xx.y Policies and privacy

Privacy policies are typically much more of the obligatory form than 
access control policies. A policy that requires a Web service provider 
to properly propagate P3P tags, for example, represents an obligation 
on the provider. It is not possible to prevent a rogue Web service 
provider from leaking private information; it should be possible, 
however, to monitor the public actions of the Web service to ensure 
that the tags are propagated.


3.xx.x.x Policies beyond security

Policies have application beyond security and privacy. For example, 
many Quality of Service requirements can be expressed in terms of 
policies (especially obligation-style policies). Furthermore, many 
application-level policies may also apply. Thus the fundamental 
concepts of policies and guards may also benefit Web services 
applications as well as helping to ensure their security.

It should be noted that, currently, the architecture does not address 
the issues associated with enacting policies; except in so far that 
enactment can be modeled in terms of Web services that are themselves 
subject to policies. The focus of the Architecture is those elements 
that are needed to ensure that policies are adhered to.

Received on Monday, 14 July 2003 17:06:11 UTC