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 David,

So you are proposing something like the following…

Action-id: read
Action-protocol: http
Action-method: get

…or

Action-id: read
Action-method: http-get

Thanks

b

On Dec 13, 2013, at 1:59 AM, David Brossard <david.brossard@axiomatics.com> wrote:

Also, John, the value HTTP for action-id is quite odd. At best an action id would be the protocol's method (GET, POST, PUT...) and HTTP would be the protocol type. That could still be expressed in the action category.

Also the transport / protocol action is perhaps not what is interesting. Rather a business action (view, edit...) that reflects the original English policy seems more adequate.

Thoughts?


On Fri, Dec 13, 2013 at 2:58 AM, Steven Legg <steven.legg@viewds.com> wrote:

Hi John,


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

Proposal 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


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.

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

http://confidential.acme.com/eyes-only.xml

Resource-location

webserver1.acme.com



Subject Attributes

Values

Subject-ID

Alice

Subject-ID-qualifier

acme.com

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





--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
LinkedIn: http://www.linkedin.com/companies/536082
Web: http://www.axiomatics.com
Twitter: http://twitter.com/axiomatics


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