Web-Based Access Control

Web-based Access Control is used to determine the online resources a subject can access on a particular system. The intent of this technology is to prevent a subject from

interacting with unauthorized online content within the context of an otherwise allowable application. For example, an organization may wish to use a streaming media application to display training sessions to remote participants while preventing this same application from being used to watch live sporting events. More generally, this is including but not necessarily limited to the following behaviors:

 URL access: accessing online content identified by a URL that may contain malicious or inappropriate content

 File access: opening web content or downloading documents, images, executable binaries, and other files that are hosted online and may contain malicious or inappropriate content

 Executable script access: running an executable script such as JSP or ActiveX that is contained within a web page or controlling (enabling/disabling) one’s own ability to run these

 Form access: uploading a file or posting data to a web page via an HTTP operation (GET, POST) that does not serve a valid organizational purpose such as a social networking site or general interest message board

For more information regarding the implementation of HTTP operations, refer to RFC 2616, Hypertext Transfer Protocol – HTTP/1.1 at http://www.ietf.org/rfc/rfc2616.txt.

FDP_ACC.1 Access Control Policy

Hierarchical to: No other components.

FDP_ACC.1.1 The TSF shall enforce the [access control Security Function Policy (SFP)] on [

 Subjects: subset of users from an organizational data store; and

 Objects: URLs, files, executable scripts, forms; and

 Operations: access, open, download, execute, enable, disable, HTTP operations]

Application Note: Examples of access control SFPs based on the types of devices outlined in section 1.4 are listed below. Note that these examples are only representative of the types of

subjects, objects, and operations that can be used when completing the assignment for this requirement. The ST author must develop their own assignment data based on the behavior of the TSF as opposed to using any of these examples verbatim. It may be possible for multiple instances of the TOE to be in one ESM system. If this is the case, then each unique TOE policy must be captured in a new iteration of this requirement.

Dependencies: FDP_ACF.1 Security Attribute Based Access Control FDP_ACF.1 Access Control Functions

Hierarchical to: No other components.

FDP_ACF.1.1 The TSF shall enforce the [access control SFP] to objects based on the following: [all operations between users and objects based upon the attributes defined in Table 7 below].

Application Note: Consistent with the intent of ESM, the SFP-relevant security attributes that define subjects are expected to exist in the Operational Environment. The TOE should enforce policy based on legacy subjects that are globally defined by the organization deploying it.

FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [rules received from an authorized and compatible Policy Management product].

FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules:

[assignment: additional rules]

Application Note: The intent of this requirement is to allow for an explicitly authorized bypass of the regular rule enforcement process for situations where access control should never be applied.

An example of this is the support of anonymous access.

Such access might be permitted based on the source of the address (i.e., internal requests do not require authentication), using wording such as ―if web content is located on the organizational web domain, allow all users of the TOE to read the data if it does not require authentication‖.

FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment:

additional rules].

Application Note: The ST author must specify the specific objects protected by the explicit denial process. This explicit denial process must be implemented independent of any policy consumed by the TSF.

The ST author must define the specific mechanism of enforcement for these additional rules in sufficient detail for the evaluator to devise testable scenarios to confirm the effectiveness of these rules.

Dependencies: FDP_ACC.1 Subset Access Control FMT_MSA.3 Static Attribute Initialization

Application Note: Application of a web-based access control policy is dependent on an authenticated subject attempting to access environmental web resources through a centralized TOE that enforces this policy. In addition to controlling access based on an established session, the TOE may also prevent the establishment of such a session (FTA_TSE.1). The ST author should consider incorporating this optional requirement (found in Appendix C.4.1) if the TOE provides this capability.

Table 7. FDP Requirement Table for Web-Based Access Control

Subject Object Operation

User URLs Access via HTTP operation

Files Open | Download

Executable Scripts Execute Enable | Disable

Forms HTTP GET | HTTP POST

Assurance Activity:

The evaluator shall check the TSS in order to verify that the TOE is capable of mediating the activities that are defined in Table 6 above and that the access control policy enforcement mechanism is described.

The evaluator shall check the operational guidance in order to verify that it provides instructions on how it receives access control policy data. For example, if the TOE receives policy rules in some defined language, the operational guidance shall indicate the statements in this language that correspond with the activities that are defined in Table 16 above.

The evaluator shall also check the operational guidance to verify that it provides information about how the TOE’s rule processing engine. This allows administrators to design access control policies with appropriate expectations for how they will be enforced.

The evaluator shall then use an authorized and compatible Policy Management product to define policies that contain rules for mediating these activities. For each subject/object/operation/attribute combination, the evaluator shall execute at least one positive and one negative test in order to show that the TSF is capable of appropriately mediating these activities.

For example, consider the following combinations:

- authorized users/groups (subject), http://www.test.url (object), access via HTTP operation (operation), 1:00 PM (attribute)

The evaluator could test this combination by deploying a policy that allows a certain user and a certain group the ability to access http://www.test.url in their web browser between the hours of 9:00 AM and 5:00 PM. They can then log in as that user and observe that they are allowed to access the website at 1:00 PM. They can then test other aspects of this combination in the following manner:

- logging in as a different user and observing that they are not allowed to access the website

- assigning the unauthorized user to the group that is authorized to access the website and observing that they can now access it themselves

- accessing a different website that is not allowed by the policy and observing that this site cannot be accessed

- accessing the same website at 5:30 PM and observing that their access attempt is rejected due to the time attribute

This activity is then repeated for each other subject/object/operation/attribute combination.