OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] DLP-NAC: authorized applications

Hi John,

On 13/12/2013 8:04 AM, Tolbert, John W wrote:

Proposal in draft.  Suggestions welcome.


Use case: Prevent sensitive data from being read/modified by unauthorized applications

Policies may stipulate which applications can read or modify resources to prevent insecure applications or malware-compromised applications from contaminating or exfiltrating sensitive data. This use case assumes that the Policy Decision Point (PDP) can call an external configuration management database to determine if the application is on the approved list.



1.1.2 Authorized-Application

This identifier indicates whether or not the requesting application is approved for the actions requested.


The DataType of this attribute is http://www.w3.org/2001/XMLSchema#boolean

This is not a natural access-subject attribute. Its value does not depend on the access-subject
at all and a context handler would not be looking in the same place for this attribute that it
would be for other access-subject attributes. The obvious lookup key for access-subject
attributes is subject-id, but that wouldn't be useful for fetching an approved applications list
(the PEP could provide the attribute, but if we are concerned that the application may be
compromised, then perhaps we shouldn't be taking its word that it is an authorized application).
A better category would be "codebase" or "intermediary-subject". Even "environment"
would be a better choice than "access-subject".

A context handler could look up the authorized-application attribute using the subject-id
attribute in the codebase category, but if the authorized applications are maintained as
a list, then it would be more appropriate to have that list appear as an environment
attribute and policies would test if the subject-id in the codebase category is one of the
values in the list.

A single list is also very coarse. An application is either approved or not regardless of the
circumstances. If policies test the codebase subject-id against bags of values in their conditions,
then it is possible to be more subtle. For example, an application is approved for read actions
but not write actions, or is approved if it's running on a company desktop but not if it is
running on a smartphone.

It is worth saying in the Security Considerations that the context handler should take steps
to verify the authenticity of the subject-id in the codebase category by, for example,
cross-checking with the authenticated identity of the PEP, or by ignoring any provided value
and generating the value itself using the authenticated identity.





1.1.3 Prevent sensitive data from being read/modified by unauthorized applications

Acme security policy prohibits unapproved applications from reading and modifying sensitive data.  Alice attempts to open a sensitive document with an unauthorized application. The request fails.  Sample attributes and values are listed below.


Resource Attributes






Subject Attributes








Action Attributes



HTTP Description

This sample policy can be summarized as follows:


Target: This policy is only applicable to Resource-location = “webserver1.acme.com

AND Resource-ID contains “confidential\.acme\.com


Rule:  This rule is only applicable if Action-ID contains “HTTP”

Then if

Subject-ID-qualifier = “acme.com” AND Authorized-application = false




On DENY log attempt to use an authorized application


Sample Policy….


To be added

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]