[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:
This is not a natural access-subject attribute. Its value does not depend on the access-subjectProposal in draft. Suggestions welcome.
Use case:
1.1.1.1 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.
Attribute:
1.1.2 Authorized-Application
This identifier indicates whether or not the requesting application is approved for the actions requested.
urn:oasis:names:tc:xacml:3.0:subject:authorized-application
The DataType of this attribute is http://www.w3.org/2001/XMLSchema#boolean.
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.
Regards,
Steven
Example:
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
Values
Resource-ID
Resource-location
Subject Attributes
Values
Subject-ID
Alice
Subject-ID-qualifier
Authorized-application
False
Action Attributes
Values
Action-ID
HTTP
1.1.3.1 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
DENY
Obligation:
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]