information labeling and handling policy authoring guidelines · information labeling and handling...

Information Labeling and Handling

Policy Authoring Guidelines

Prepared by: ILH Team

Lead Author: Jean-Paul Buu-Sao, TSCP

Released to: TSCP Architecture Committee Edition: 0.8 Published: January 14, 2013

ILH Policy Authoring Guidelines

© 2013 TSCP, Inc. i

Copyright © 2013 Transglobal Secure Collaboration Participation, Inc.

All rights reserved.

Terms and Conditions

Transglobal Secure Collaboration Participation, Inc. (TSCP) is a consortium comprising a number of commercial and government members (as

further specified at http://www.tscp.org) (each a “TSCP Member”). This specification was developed and is being released under this open source

license by TSCP.

Use of this specification is subject to the disclaimers and limitations described below. By using this specification you (the user) agree to and

accept the following terms and conditions:

1. This specification may not be modified in any way. In particular, no rights are granted to alter, transform, create derivative works from, or

otherwise modify this specification. Redistribution and use of this specification, without modification, is permitted provided that the following

conditions are met:

Redistributions of this specification must retain the above copyright notice, this list of conditions, and all terms and conditions

contained herein.

Redistributions in conjunction with any product or service must reproduce the above copyright notice, this list of conditions, and all

terms and conditions contained herein in the documentation and/or other materials provided with the distribution of the product or

service.

TSCP’s name may not be used to endorse or promote products or services derived from this specification without specific prior

written permission.

2. The use of technology described in or implemented in accordance with this specification may be subject to regulatory controls under the laws

and regulations of various jurisdictions. The user bears sole responsibility for the compliance of its products and/or services with any such laws

and regulations and for obtaining any and all required authorizations, permits, or licenses for its products and/or services as a result of such laws

or regulations.

3. THIS SPECIFICATION IS PROVIDED “AS IS” AND WITHOUT WARRANTY OF ANY KIND. TSCP AND EACH TSCP

MEMBER DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION,

ANY IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY, QUIET ENJOYMENT, ACCURACY,

AND FITNESS FOR A PARTICULAR PURPOSE. NEITHER TSCP NOR ANY TSCP MEMBER WARRANTS (A) THAT THIS

SPECIFICATION IS COMPLETE OR WITHOUT ERRORS, (B) THE SUITABILITY FOR USE IN ANY JURISDICTION OF ANY

PRODUCT OR SERVICE WHOSE DESIGN IS BASED IN WHOLE OR IN PART ON THIS SPECIFICATION, OR (C) THE

SUITABILITY OF ANY PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF

TSCP OR ANY THIRD PARTY.

4. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY CLAIM

ARISING FROM OR RELATING TO THE USE OF THIS SPECIFICATION, INCLUDING, WITHOUT LIMITATION, A CLAIM

THAT SUCH USE INFRINGES A THIRD PARTY’S INTELLECTUAL PROPERTY RIGHTS OR THAT IT FAILS TO COMPLY

WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS SPECIFICATION, THE USER WAIVES ANY SUCH CLAIM

AGAINST TSCP OR ANY TSCP MEMBER RELATING TO THE USE OF THIS SPECIFICATION. IN NO EVENT SHALL TSCP

OR ANY TSCP MEMBER BE LIABLE FOR ANY DIRECT OR INDIRECT DAMAGES OF ANY KIND, INCLUDING

CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER ARISING OUT OF OR

RELATED TO ANY USER OF THIS SPECIFICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

5. TSCP reserves the right to modify or amend this specification at any time, with or without notice to the user, and in its sole discretion. The user

is solely responsible for determining whether this specification has been superseded by a later version or a different specification.

6. These terms and conditions will be interpreted and governed by the laws of the State of Delaware without regard to its conflict of laws rules.

Any party asserting any claims related to this specification irrevocably consents to the personal jurisdiction of the U.S. District Court for the

District of Delaware and to any state court located in such district of the State of Delaware and waives any objections to the venue of such court.


© 2013 TSCP, Inc. ii

DOCUMENT CHANGE RECORD

DOCUMENT NAME: ILH Policy Authoring Guidelines Edition 0.81, 2012-11-20

DATE WHEN VERSION WAS CREATED

VERSION NUMBER

AUTHOR CHANGES WITHIN VERSION

REVIEWERS WHO CONTRIBUTED TO VERSION

DOCUMENT STATUS

26 July 11 0 0 JP Buu-Sao

Initial version, based upon Policy Authoring Excel Template 24 July

Review with ILH team

3 Aug 11 0 2 JP Buu-Sao

Modified after feedback from Richard Skedd, and SEv.2 visual marking requirements

Richard Skedd, SEv.2 team

Review with ILH team


Modified after feedback from Richard Skedd, and addition of general guidance on BA Distribution

Richard Skedd Review with ILH team


Modified after feedback from EC SMEs, adding clearance, country of incorporation, support for Country Lists

EC SMEs Review with ILH team


Structured on business process steps

ILH Team Review with ILH team


Incorporated feedback from 22 Aug Team review

ILH Team Ready for review by AB

16 Sept 11 0 7 JP Buu-Sao

Modified section on Protection Profile Builder


2 Oct 12 0 8 JP Buu-Sao

Modified after feedback from Richard Skedd and John Tolbert



© 2013 TSCP, Inc. iii

1 Document Purpose ................................................................................................. 1

1.1 Intended Audience ........................................................................................................... 1

1.2 References ....................................................................................................................... 1

1.3 Glossary ........................................................................................................................... 1

2 Business Process Overview .................................................................................. 2

3 Creation of the Initial Business Authorization ..................................................... 3

3.1 Capture of the Administrative Information ........................................................................ 3

3.2 Capture of the Related Documentation ............................................................................ 9

3.3 Capture of the Characteristics ....................................................................................... 10

3.4 Capture of the Business Authorization Categories ........................................................ 12

3.5 Capture of the Access Rules ......................................................................................... 15

4 Creation of an Implementable Business Authorization ..................................... 19

4.1 Addition of Identifiers ..................................................................................................... 19

4.2 Refinement of the Categorization Rules ........................................................................ 20

4.3 Refinement of the Access Rules .................................................................................... 23

4.4 Specification of the Physical Markings ........................................................................... 24

5 Creation of a Business Context Specific Resource Protection Profile ............ 27

5.1 Determination of the Risk Impacts ................................................................................. 27

5.2 Harmonization of the Physical Markings ........................................................................ 28

5.3 Determination of the Policy Locators in Production ....................................................... 30

5.4 Creation of the Business Context Specific Resource Protection Profile Artifact ............ 30

5.5 Refinement of the Business Context Specific Resource Protection Profile ................... 33

5.6 Validation of the Business Context Specific Resource Protection Profile ...................... 34

6 Filter to Intended Organizations .......................................................................... 35

7 Add Contractual Elements ................................................................................... 36

7.1 Rules-Evaluation Implementation Policy ........................................................................ 37

7.2 Attribute Implementation Policy ..................................................................................... 42

7.3 Audit-Log Implementation Policy ................................................................................... 49

8 Distribution of Business Context Protection Profiles ....................................... 51

8.1 Security Requirements ................................................................................................... 51

8.2 Support in ILH v.1 .......................................................................................................... 51

9 Appendices ........................................................................................................... 52

9.1 Policy Artifact: TAA#1 .................................................................................................... 52


© 2013 TSCP, Inc. iv

Table of Figures

Figure 1. Business process overview ........................................................................................... 2

Figure 2. Hypothetical assistance agreement ............................................................................... 4

Figure 3. Requirement for NDA for third-country nationals ......................................................... 11

Figure 4. Summary of the business context specific resource protection profile ........................ 33


© 2013 TSCP, Inc. Page 1 of 52

1 Document Purpose

This document describes the business steps that start at the contracts/agreements phase and end at the production of an implementable Business Context Protection Profile. This document provides guidelines on how to accomplish each step, independently of any specific toolset, and provides information as to how these steps can be performed using a reference tool, the Information Labeling and Handling (ILH) v.1 Policy Authoring Tool. Finally, this document provides an overview of the cognitive activities involved in such a process.

1.1 Intended Audience

This document is intended for the following stakeholders:

The TSCP Architecture Board

Policy subject matter experts

1.2 References

Business Authorization Framework (BAF) v.1

http://www.tscp.org/assets/TSCP_BAFv1.pdf

Business Authorization Identity and Labeling Scheme (BAILS) v.1

http://www.tscp.org/assets/TSCP_BAILSv1.pdf

Common Operating Rules (COR) v.1

http://www.tscp.org/assets/tscp_idfed_cor.pdf

1.3 Glossary

Business Authorization – The result of the analysis of a human-readable policy artifact and of the expression, in a consistent and precise manner, of all the components of information protection policies required for consistent interpretation of policy artifacts.

Business Context Specific Resource Protection Profile – The result of the analysis of all the Business Authorizations applicable under a given Business Context, and capture, in a consistent and precise manner, of the components required for consistent implementation across collaboration partners.

Implementable Business Context Specific Resource Protection Profile – A Business Context Specific Resource Protection Profile enriched with implementation attributes and fit for implementation.

http://www.tscp.org/assets/TSCP_BAFv1.pdf

http://www.tscp.org/assets/TSCP_BAILSv1.pdf

http://www.tscp.org/assets/tscp_idfed_cor.pdf



2 Business Process Overview

This document focuses on the business process depicted below:

Figure 1. Business process overview



3 Creation of the Initial Business Authorization

The purpose of this business activity is to capture human-readable agreements or contracts in a computer-processable form. This is the initial phase of the capture, where the focus is on making sure that the terms of the agreements or contracts are appropriately expressed in the BAF format. Implementation details will be added at the following phase, described in 19, Creation of an Implementable Business Authorization.

3.1 Capture of the Administrative Information

Administrative Information

Purpose To capture the administrative information of the contract/agreement and the parties and work efforts involved

Input Contract/agreement documentation

Output Business Authorization in BAF format

Skills Business level

Steps 1. Record the name of the policy authority.

2. Record the type of the policy (Export Control, National Security, or Intellectual Property).

3. Record the country (for Export Control and National Security policies).

4. Record the name of the policy.

5. Record the name of the business context.

6. Record the identifier for the business authorization.

7. Record the version number for the business authorization.

8. Record the start validity date (if applicable).

9. Record the stop validity date (if applicable).

10. Record the organizations in scope.

11. Record the work efforts in scope.



Going forward, this document uses the example of an ITAR Technical Assistance Agreement (TAA) to illustrate the business process. The full text version of this TAA can be found in 52.

Figure 2. Hypothetical assistance agreement

Follow the steps below to create the initial Business Authorization and capture the information above highlighted from the human-readable TAA:

1. Start the Policy Authoring tool (Generic.xlsx).

2. Click on the “General” tab in order to enter the general administrative information:

Name of the Attribute Description Value

Policy Authority Designates the entity with authority over the business authorization.

How is this determined? There is a need to know that a TAA is under the authority of the US-Directorate of Defense Trade Controls (DDTC).

Enter: DDTC

Policy Type Type of the policy.

How is this determined? There is a need to know that a TAA is an Export Control agreement.

Select: Export Control

Country Country code for policy of type National Security or Export Control (otherwise the control is disabled).

How is this determined? There is a need to know that a Technical Assistance Agreement is under the authority of the US-DDTC.

Enter: US



Name of the Attribute Description Value

Policy name Name of the policy.

How is this determined? There is a need to know that a Technical Assistance Agreement is an artifact of the ITAR policy.

Enter: ITAR

Business context Designates the business context that is related to this TAA.

How is this determined? It’s indicated in the TAA.

Enter: Program-Z

Identifier Identifier of this business authorization. This identifier is used to root the identifier(s) of the business authorization category(ies).

How is this determined? The number of TAAs applicable under the business context must be known in order to generate a simple identifier (ordinal number) used to discriminate TAAs.

Enter: TAA-1

Version Number The version number of this Business Authorization for the purpose of configuration management.

How is this determined? Issuing organizations must include a version number using the appropriate versioning scheme fit to support configuration management internally and across partner organizations.

Enter: 1.0

Start Validity Date Defines the first date of validity of the Business Authorization.

How is this determined? It’s indicated in the TAA.

Uncheck “No stipulation,” click the calendar icon, and select: 30 July 2010

Stop Validity Date Defines the last date of validity of the Business Authorization.

How is this determined? It is not specified by the TAA; there is a need to know the default validity for a TAA (5 years).

Uncheck “No stipulation,” click the calendar icon, and select: 30 July 2015



The screen should look similar to:

3. Scroll down to get to the section labeled “Organizations (OBS) in scope” in order to enter the information related to the organizations that are referred to in the Business Authorization.

4. There are three organizations that need to be created: Curtiss, Packard, and Spad Romania. Click the button “Create” to create each organization, and enter the associated attributes:

Curtiss

Name Enter: Curtiss Corporation

Role Select: Applicant

Address Line 1 Enter: 100 Infinite Loop

Address Line 2 Enter: Cupertino

Country Enter: US

Packard

Name Enter: Packard Ltd

Role Select: Signatory

Address Line 1 Enter: 7 Regent St

Address Line 2 Enter: London

Country Enter: GB

Spad-Romania

Name Enter: Spad Romania



Spad-Romania

Role Select: Signatory

Address Line 1 Enter: 63-81 Calea Victoriei

Address Line 2 Enter: București

Country Enter: RO


5. Scroll down in order to get to the section labeled “Work Efforts (WBS) in scope” in order to enter the information related to the work-efforts (elements of the Work Breakdown Structure) that are referred to in the Business Authorization.

6. There are three work efforts that need to be created: DetailedDesign, Simulation, and Integration. Click the button “Create” to create each work-effort, and enter the associated name.




7. Scroll down in order to get to the section labeled “Products (PBS) in scope” in order to enter the information related to the product references (element of the Product Breakdown Structure) that are referred to in the Business Authorization.

8. There are three work product references that need to be created: GNU (GPS Navigation Unit), EGPSU (Extended GPS Unit), and MGPSR (Multimode GPS Receiver). Click the button “Create” to create each product reference and enter the associated names.


9. Scroll down in order to get to the section labeled “Topics” in order to enter the topic information that can be referred to by the categorization rules.

10. Categorization rules can make use of topic information in order to add precision to the context of the application of a policy to an information object. In the Program-Z example, there are various milestones that the program must follow. Milestone 3 (M3) is of particular importance as it denotes the beginning of actual collaboration across partners. Hence, all documents that are produced after M3 must be appropriately labeled. Click the button “Create” to create a topic and enter the name “Created after milestone M3.”




11. Scroll down in order to get to the section labeled “Content Types” in order to enter the content types that can be referred to by the categorization rules.

12. Categorization rules can make use of content types in order to add precision to the context of the application of a policy to an information object. The ITAR policy mandates that the export of certain goods or services must be subject to an export license. We are going to create two content types to indicate the type of goods and services that must fall under TAA-1.1 and TAA-1.2. These content types are the items 11A and 11B of the US Military List (USML).

13. Click the button “Add,” enter the name “USML:11A,” click the button “Add,” and enter the name “USML:11B.”


3.2 Capture of the Related Documentation

Related Documentation

Purpose To capture a reference to a human-readable document that describes the terms of the contract/agreement.

The information (URL, referred document contents) provided at this stage is not necessarily final, and can provide the input to subsequent implementation phases.

Input Contract/agreement documentation (e.g., TAA)

Output Business Authorization in BAF format (e.g., TAA-1.xml)




Related Documentation

Steps 1. Record the URL for accessing the human-readable policy documentation.

2. Record the appropriate description to facilitate the exploitation of the locator.

1. Scroll down in order to get to the section labeled “Documentation locator.”

2. Enter the URL http://www.curtiss.com/ba/taa-1.pdf.

3. Enter the following description: Obtainable on Curtiss WEB portal using your partner credentials.


3.3 Capture of the Characteristics

Characteristics

Purpose To identify and capture the requirements which will result in procedural controls that the user’s affiliated organizations will need to apply.

The information is needed to ensure that requirements, which cannot be enforced systemically, are explicitly identified for procedural enforcement; implementing organizations must setup appropriate procedures to meet the requirements.




Steps 1. Identify the requirements that must be met via procedural controls.

2. Allocate these requirements to one or more characteristics which organizations can assert for their users to testify that these users meet the procedural controls.

http://www.curtiss.com/ba/taa-1.pdf



In the example of TAA-1, there are two such characteristics required:

a) The explicit requirement for a non-disclosure agreement (NDA) for users who are third-country nationals. See below.

Figure 3. Requirement for NDA for third-country nationals

b) The implicit requirement of ITAR training and awareness for all users.

1. Scroll down in order to get to the section labeled “Characteristics in scope” in order to enter the information related to the characteristics (various procedural requirements on individuals) that are referred to in the Business Authorization.

2. There are two characteristics that need to be created. Click the button “Create” to create each characteristic, and enter the associated name and descriptions.

Characteristic #1

Name Enter: TAA-1-NDA

Description Enter: "Prior to transfer to third country nationals (including dual nationals), employees must execute a non-disclosure agreement (NDA) that includes the provisions in this TAA. The foreign party must provide CURTISS a copy of each NDA, and CURTISS will maintain a copy of the NDA for five years after the expiration date of this TAA."

Characteristic #2

Name Enter: TAA-TRAINING

Description Enter: Per training requirements indicated at (TO-DO: reference to ITAR training)




3.4 Capture of the Business Authorization Categories

Business Authorization Categories

Purpose To identify and capture the Business Authorization Categories, designating a uniquely identifiable construct that defines a subset of the requirements within a Business Authorization.



Skills Business level, with analytical skills.

Steps 1. Identify the Business Authorization Categories (at least one needed for each Business Authorization).

2. For each such Business Authorization Category:

a) Provide a name

b) Provide the categorization rules

An analysis of the TAA shows that two Business Authorization Categories are required:

a) TAA-1.1: export of technical data to the United Kingdom.

Categorization rules

This Business Authorization Category includes any information object that originates from (Curtiss) and is about products (GNU, EGPSU, or MGPSR) and is produced by work efforts (DetailedDesign or Simulation) and is approved for release to (Packard).



b) TAA-1.2: export of technical data to Romania.

Categorization rules

This Business Authorization Category includes any information object that originates from (Curtiss) and which is about products (GNU or EGPSU) and is produced by work efforts (Integration) and is approved for release to (Spad Romania).

Follow the steps below to create these Business Authorization Categories and their respective categorization rules:

1. Click on the tab “BACat 1” in order to enter the information related to the first Business Authorization Category of this TAA.

2. Make sure that this Business Authorization Category is enabled. Enabled should be checked.

3. Enter the information identifying this Business Authorization Category.

Business Authorization Category 1

Name Enter: TAA-1.1

4. Enter the categorization rules for this Business Authorization Category:

Business Authorization Category 1 – Categorization Rules

Originating organizations

Select: Curtiss Corporation

Receiving organizations

Select: Packard Ltd

Topics Select: Created after milestone M3

Products Select: GNU, EGPSU, MGPSR

Content Types Select: USML:11A

Work efforts Select: DetailedDesign, Simulation




5. Click on the tab “BACat 2” in order to enter the information related to the second Business Authorization Category of this TAA.


7. Enter the information identifying this Business Authorization Category:

Business Authorization Category 2

Name Enter: TAA-1.2

8. Enter the access rules for the second Business Authorization Category:

Business Authorization Category 2 – Categorization rules

Originating organizations

Select: Curtiss Corporation

Receiving organizations

Select: Spad Romania



Work efforts Select: Integration




3.5 Capture of the Access Rules

Business Authorization Categories

Purpose To identify and capture the set of access rules for each Business Authorization Category.

Each set of access rules define the criteria under which an individual can access an information object. These rules are to be used for the configuration of access management systems, as well as for the setting of procedural enforcement means.



Skills Business level, with analytical skills

Steps 1. For each Business Authorization Category:

a) Provide the access rules.

An analysis of the TAA shows that two Business Authorization Categories are required:

a) TAA-1.1: export of technical data to the United Kingdom.

Access rules:

Any individuals of nationality (US or GB) affiliated to (Curtiss or Packard) incorporated in (US or GB) cleared to (ITAR-Training) are permitted to access information about products (GNU or EGPSU) while assigned to work efforts (DetailedDesign or Simulation) and at locations (US or GB).



b) TAA-1.2: export of technical data to Romania.

Access rules:

Any individuals of nationality (US or RO) affiliated to (Curtiss or Spad-Romania) incorporated in (US or RO) cleared to (ITAR-Training) are permitted to access information about products (GNU or EGPSU) whilst assigned to work efforts (Integration) and at locations (US or RO).

Follow the steps below to create these Business Authorization Categories and their respective categorization rules and access rules:

9. Click on the tab “BACat 1” in order to enter the information related to the first Business Authorization Category of this TAA.

10. Enter the access rules for this Business Authorization Category:

Business Authorization Category 1 – Access rules

Nationalities Select: US, GB

Organizations Select: Curtiss Corporation, Packard Ltd

Characteristics Select: TAA-1-NDA, TAA-Training

Effect Select: Permit


Work efforts Select: DetailedDesign, Simulation

Locations Select: US, GB




11. Click on the tab “BACat 2” in order to enter the information related to the second Business Authorization Category of this TAA.


13. Enter the access rules for this Business Authorization Category:

Business Authorization Category 2 – Access Rules

Nationalities Select: US, RO

Organizations Select: Curtiss Corporation, Spad Romania

Characteristics Select: TAA-1-NDA, TAA-Training

Effect Select: Permit


Work efforts Select: Integration

Locations Select: US, RO



4 Creation of an Implementable Business Authorization

The purpose of this phase is to refine a Business Authorization by adding attributes required for implementation which were not present in the original contract/agreement.

4.1 Addition of Identifiers

Identifiers

Purpose To define identifiers for each Business Authorization Category; these identifiers are to be used in BAILS metadata to uniquely designate Business Authorization categories.

Input Business Authorization in BAF format (e.g., TAA-1.xml)


Skills Technical level

Steps 1. Identify the appropriate Uniform Resource Name (URN) and Object Identifier (OID) namespaces; it is recommended to use the same namespaces for all Business Authorization Categories of the same Business Authorization.

2. In the selected namespaces, create URN and OID identifiers for each Business Authorization category.

1. For each Business Authorization Category, click on the associated tab “BACat 1” or “BACat 2.”

2. In “the Business Authorization Category Identification” section, enter the identifiers below:

Business Authorization Category TAA-1.1

URN Enter: urn:curtiss:ba:taa:taa-1.1

OID Enter: 1.3.6.1.4.1.30000.300.1


URN Enter: urn:curtiss:ba:taa:taa-1.2

OID Enter: 1.3.6.1.4.1.30000.300.2




4.2 Refinement of the Categorization Rules

Identifiers

Purpose To define more precise categorization rules for each Business Authorization Category; this information will be needed as an input to the training for end-users who need to apply Business Authorization Categories to documents.




Steps 1. Identify and create topics that help to characterize relevant contexts for each Business Authorization Category; this step is always relevant.

2. Identify and create classifications that help to characterize relevant contexts for each Business Authorization Category; this step is relevant only if the policy implies classifications, which is generally the case for Export Control policies.

3. Refine the Categorization Rules on each Business Authorization Category by selecting the relevant topics and classifications.



1. Click on the “General” tab.

2. Scroll to the relevant sections “Topics” and “Content Types” in order to create the following elements:

Topic #1

Name Enter: Created after milestone M3

Content Type #1

Name Enter: USML:11A

Content Type #2

Name Enter: USML:11B

Note that in content type names, the character ‘:’ (column) is used as a separator between the classification list name (e.g., USML) and the classification number (e.g., 11A).


3. For each Business Authorization Category, click on the associated tab “BACat 1” or “BACat 2.”

4. In each “Category rules” section, select the following elements:



Business Authorization Category TAA-1.1 – Categorization rules


Classifications Select: USML:11A, USML:11B


Topics Select: Program-Z after milestone M3

Classifications Select: USML:11A




4.3 Refinement of the Access Rules

Identifiers

Purpose To define more precise access rules for each Business Authorization Category; this information will be needed as an input to the applications and systems for the purpose of access management.



Skills Technical

Steps 1. Identify and create the actions that are relevant for the considered information objects.

2. Refine the Access Rules on each Business Authorization Category by selecting the relevant actions for permission or denial.

Note: although BAF and supporting toolsets support multiple, granular actions, ILH v.1 specifies only one action – “Any.”

1. Click on the “General” tab.

2. Scroll down to the “Actions” section, and create the action “Any.”

3. In the “Access rules” section of each Business Authorization category, select the action “Any.”




4.4 Specification of the Physical Markings

Identifiers

Purpose To define the visual indicators on information objects that are required for the procedural enforcement of all the applicable policies.

At this stage, it is necessary to provide the set of physical markings that are mandated by the policies; these physical markings are generally independent of business contexts and any specific implementations. The context and implementation specific aspects of the physical markings will be added at future stages.



Skills Business

Steps 1. Identify the marking requirements associated to the contract/agreement.

2. On each appropriate Business Authorization Category, specify the appropriate physical markings. Each physical marking is defined as a text that must appear to the end-user, and a type that determines where this text must appear. Section 8 of the BAILS specification defines possible various types.

1. Physical marking requirements can be specified within the agreement, within overarching policy documents that govern the agreement, or can be agreed upon within the context of the collaboration.

2. In this example, specifications for physical marking are laid out in the agreement document. Based on this document, we can determine that there are five physical markings defined by each Business Authorization Category; for each of these, click on the “Create” button in order to create an access rule, and enter the following information:



Business Authorization Category TAA-1.1 and TAA 1.2 – Physical marking #1

Type Select: General: DistributionStatement

Contents Enter: Distribution authorized to U.S. Government Agencies and private individuals or enterprises eligible to obtain export-controlled technical data in accordance with DoD 5230.25, July 20, 2010. The controlling DoD office is CURTISS.


Type Select: General: WarningStatement

Contents Enter: This document (or software if applicable) contains technical data whose export/ transfer/disclosure is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et. seq.) or the Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25. Dissemination to non-U.S. persons whether in the United States or abroad requires an export license or other authorization.


Type Select: Document: Footer

Contents Enter: Export controlled – see sheet 1

Business Authorization Category TAA-1 – Physical marking #4

Type Select: Document: Summary

Contents Enter: US DDTC – ITAR export controlled under TAA 1.1

Business Authorization Category TAA-2 – Physical marking #4

Type Select: Document: Summary

Contents Enter: US DDTC – ITAR export controlled under TAA 1.2


Type Select: Email: First Line Of Text

Contents Enter: Export controlled under ITAR

3. You need to select a Marking precedence value. This is a number between 1 and 10 which determines the precedence of the visual marking of this Business Authorization Category over other Business Authorization Category’s visual markings appearing on the same information object. A value of 1 expresses a low precedence, whereas the value of 10 expresses the highest precedence. Labeling tools use the marking precedence to determine the position of the visual markings that need to share the same space. For example, in two



cases, if Email First Line of Text is required, the one with the higher marking precedence would appear first.

4. For this example, let us select 8 (by clicking several times on the up arrow). Notice that the reason we selected 8, a high precedence, instead of 10, the maximum value, is that we want to allow for a fair distribution of the precedence across all the Business Authorization Categories of the Protection Profile. It would be useless, and non-deterministic, to have, say, 3 Business Authorization Categories of the same precedence, e.g., 10. Instead, we would rather have the values of 10, 9, and 8.




5 Creation of a Business Context Specific Resource Protection Profile

The purpose of this phase is to collect all implementable Business Authorizations and generate a set of implementation requirements which each participant can use for actual implementations of procedures and systems.

The actor of this business activity is typically the prime contractor of the business context who has either produced the implementable Business Authorizations, per the previous phase, or has obtained them from collaborating partners. In any case, the prime contractor must have all the implementable Business Authorizations involved in the Business Context at his disposal in order to start this phase.

5.1 Determination of the Risk Impacts

Determination of the Risk Impacts

Purpose To characterize the impact level with the knowledge of the sensitivity of the information to be exchanged, as well as various business context dependent factors, such as the means of the exchange (e.g., are public networks allowed?).

This information is used to drive the security controls that will be mandated on each collaboration partner.



Skills Business and technical (Risk analysis and mitigation)

Steps 1. For each Business Authorization Category, determine the risk impact scale, and within this scale, determine the Confidentiality, Integrity, and Availability.

The Policy Authoring tool currently knows about two Risk impact scales: FIPS-199 (defining three levels) and UK-Cabinet (defining four levels). The risk impact is decomposed into three components: Confidentiality, Integrity, and Availability. It follows that the user needs to select a Risk impact scale, and under this scale, select the Risk impact values for each one of the three aspects of Confidentiality, Integrity, and Availability.

1. For each Implementable Business Authorization Category that is applicable to the business context:

a) Characterize the risk impact scale, and the levels associated to Confidentiality, Integrity, and Availability risks.

b) Using the Policy Authoring Tool, open each implementable Business Authorization XML BAF file.

c) For each Business Authorization category, click on the associated tab, scroll to the “Risk impact” section.

d) Select a risk impact scale.

e) Select the risk levels for Confidentiality, Integrity, and Availability.



5.2 Harmonization of the Physical Markings

Harmonization of the Physical Markings

Purpose To harmonize the specification of the physical markings for all Business Authorization Categories applicable to the Business Context with respect to the UI names (labels appearing to end-users), and precedence indicators.

The resulting, refined, physical marking specifications are intended to be used for the configuration of labeling tools and document templates.

Input Business Authorizations in BAF format (e.g., TAA-1.xml, IPL-1.xml)

Output Business Authorizations in BAF format (e.g., TAA-1.xml, IPL-1.xml)


Steps 1. For all Business Authorization Categories in scope:

a) Determine a consistent naming scheme for the user-interface labels allowing end-users to select Business Authorization Categories.

b) Create or modify the marking precedence indicator to ensure a deterministic result.

Thus far, the specification of the physical marking in each Business Authorization Category was merely a capture of the language that could be found in (or inferred from) associated human-readable policy artifacts. The purpose of this step is to ensure that this specification is consistent across Business Authorizations and implementable by the applications known to the business context.

Each physical marking is identified by the means of an identifier, which provides purpose and an expected format to the physical marking, as indicated in the table below:

Physical Marking Guidelines

Identifier Purpose, format

UI-Name Purpose: to provide a hint to the Implementers on the name that appears to the end-user, in order to apply the associated Business Authorization Category.

Format: short string (less than 20 characters)

Recommendation: harmonize the UI names of all Business Authorization Categories with the Business Context Specific Resource Protection Profile, so that each name is unique, and makes the most sense to end-users. For example, these names may be chosen to designate business products, rather than the protection policies that must protect these products.

UI-Disclaimer Purpose: to provide the language shown to the user (by an application, e.g., SharePoint) before he can access information, and where the user (the potential recipient of the data) needs to acknowledge that he has read the disclaimer.

Format: multiline string; may include hyperlinks for web applications



Physical Marking Guidelines

General-Summary Purpose: to provide a summary of the business authorization category that is typically located in a single place within the document, e.g., in a security control information table.

Format: medium string (less than 40 characters)

General-Warning-Statement

Purpose: Language typically located at the beginning of a document (e.g., on the cover page) that warns the end-user about the protection policy that must apply, and possibly the consequences of non-compliance.

Format: multiline string

General-Distribution-Statement

Purpose: Language typically located at the beginning of a document (e.g., on the cover page) that provides information on the distribution requirements of the document.

Format: multiline string

Document-Header Purpose: Short language located at the top of each document's pages.


Document-Footer Purpose: Short language located at the bottom of each document's pages.


Email-First Line Of Text

Purpose: Language located at the end of the email body.


Email-Last Line Of Text

Purpose: Language located at the end of the email body.


Email-Subject prefix Purpose: Short language located at the beginning of the email subject.


Email-Subject suffix Purpose: Short language located at the end of the email subject.




5.3 Determination of the Policy Locators in Production

Determination of the Policy Locators in Production

Purpose To ensure that all the policy locators on all Business Authorization categories can be used by all collaboration partners to locate and access the associated human-readable policy artifacts; also, ensures that the policy artifacts are published in a form that is appropriate to the business context, when required.


All intermediate policy artifacts


Published final policy artifacts on publication systems with appropriate access management in place.

Skills Business and technical

5.4 Creation of the Business Context Specific Resource Protection Profile Artifact

Creation of the Business Context Specific Protection Profile Artifact

Purpose To produce a file that collects the implementation requirements for all Business Authorization Categories applicable to the Business Context. This file will be subsequently used to collect all additional, application specific, requirements.

Input Applicable implementation Business Authorizations in BAF format

Output Business Context Specific Protection Profile Excel Worksheet

Skills Business Level

Steps 1. Collect all the Business Authorizations that must be applicable for the Business Context.

2. Record the administrative information identifying the Business Context Specific Resource Protection Profile.

3. Package the resulting Business Context Specific Resource Protection Profile in human-readable and computer-processable forms.

The current guidance defines three possible representations for the resulting Business Context Specific Resource Protection Profile. These representations are:

XACML

The BAF specification defines a profile, called BAF profile for XACML 3.0, which allows representing a full Business Context Specific Resource Protection Profile inclusive of its administrative information, access rules, handling rules, categorization rules, and labeling rules using XACML 3.0 constructs. Note that this XACML representation is meant to support interoperability on the exchange of policy requirements across administrative domains, and is not meant to support direct execution by a XACML engine. Hence, this representation is particularly suited for the exchange of Policy Profiles across administrative domains in support of their automated implementations.



XLSX (Microsoft Excel)

This guidance recommends always distributing the Business Context Specific Resource Protection Profile in a format that can be directly interpreted by human users, such as Microsoft Excel, in order to support their manual (non-automated) implementation.

XML proprietary

The Reference Implementation Policy Authoring Tool, which this guidance uses as an example of a DPM toolset, reads and writes Business Authorizations and Business Context Specific Resource Protection Profile using a tool-specific XML representation. It follows then, that this format can be suited for the storage of writes Business Authorizations and Business Context Specific Resource Protection Profiles before they are shared across administrative domains, and is not suited for their exchange across administrative domains.

Launch the Protection Profile Builder (C:\Program Files\TSCP\ILH Policy Management\ProtectionProfileBuilder.exe).

1. Click on “Open Business Authorizations” to multi-select (hold the Ctrl-key) all the implementation business authorizations that need to be part of the Business Context Specific Resource Protection Profile.

2. Provide the administrative information for the Business Context Specific Resource Protection Profile:

Business Context Specific Resource Protection Profile for Program-Z

Business Context Enter: Program-Z

Version Number The version number of this Business Context Specific Resource Protection Profile, for the purpose of configuration management.

How is this determined? Issuing organizations must include a version number using the appropriate versioning scheme fit to support configuration management internally and across partner organizations.

Enter: 1.0

Contact Enter: [email protected]

Identifier Enter: urn:curtiss:pp:program-z



3. Click on “Save to Protection Profile” and enter the filename: Program-Z.xml.

4. Depending on the contents of each Business Authorization that are part of the Business Context Specific Resource Protection Profile, the tool may ask to help resolve similar names. For example, the screen below shows that the two organizations “Curtiss” and “Curtiss Corporation” look similar. By clicking on “<<Overrides” the user signifies that the right spelling is in fact “Curtiss Corporation” as seen below:

5. Once all the required name resolutions are performed, verify that the three representations of

the Business Context Specific Resource Protection Profile are generated:

a) Program-Z.xacml

b) Program-Z.xlsx

c) Program-Z.xml

6. Open the Summary worksheet of Program-Z.xlsx to see a summary of the Business Context Specific Resource Protection Profile, which may help fixing the remaining errors or inconsistencies:



Figure 4. Summary of the business context specific resource protection profile

5.5 Refinement of the Business Context Specific Resource Protection Profile

Identifiers

Purpose To produce a file that collects the implementation requirements for all Business Authorization Categories applicable to the Business Context. This file will be subsequently used to collect all additional application-specific requirements.

Input Business Context Specific Resource Protection Profile Artifact (Excel Workbook)

Output Business Context Specific Resource Protection Profile Artifact (Excel Workbook)

Skills Technical level, with knowledge of the collaborative applications

Steps For all collaborative applications in scope (e.g., DSIF and SE):

1. Determine the application-specific implementation requirements that are applicable for each Business Authorization Category.

2. Specify these requirements in a format that is consistent across Business Authorization Categories.



5.6 Validation of the Business Context Specific Resource Protection Profile

Identifiers

Purpose To ensure that the Business Context Specific Resource Protection Profile is valid and consistent before distribution for implementation.

Input Business Context Specific Resource Protection Profile Artifact (Excel Workbook)

Output Business Context Specific Resource Protection Profile Artifact

Skills Business and technical level

Steps In the scope of the Business Context Specific Resource Protection Profile:

1. Verify that all identifiers are harmonized and consistent.

2. Verify that there is no rules conflict.

3. Verify that the resulting rules express the intent of the original regulations.

The purpose of this important business step is to perform the final review before the Business Context Specific Resource Protection Profile Artifact is filtered and distributed to recipient entities for implementation.

ILH v.1 recognizes this requirement, but does not provide systemic support by applications and tools. Organizations must define and apply adequate validation rules.



6 Filter to Intended Organizations

The Business Context Specific Resource Protection Profile has to be distributed to all organizations involved in the business context. There are, however, cases where not all organizations can see the details concerning other organizations in order to prevent partner organizations from knowing about details on bilateral arrangements if they do not need to.

ILH v.1 recognizes this requirement, but does not provide systemic support by applications and tools.

ILH v.1 provides the following general procedural guidance for the filtering of Business Context Specific Resource Protection Profiles across organizations:

1. For each Business Authorization Category of the Business Context Specific Resource Protection Profile, determine whether the existence of this Business Authorization Category can be disclosed to non-involved organizations.

2. For each Business Authorization Category of the Business Context Specific Resource Protection Profile, determine, for each involved organization, the elements that need to be hidden to the other involved organizations.

3. Based on the results of 1 and 2 above, establish, for each organization involved in the Business Context Specific Resource Protection Profile, the Business Authorization Category and its content that the organization can see; the resulting set is the Business Context Specific Resource Protection Profile that this organization can see.



7 Add Contractual Elements

The purpose of the Contractual Business Context Specific Resource Protection Profile is to provide collaboration partners with the contractual and technical artifacts needed to support the setup and execution of collaboration in compliance with all the required protection policies. The Contractual Business Context Specific Resource Protection Profile is made of two artifacts.

The Business Context Specific Resource Protection Profile Information Control Document is a human-readable artifact that constitutes a contractual obligation for the document signatories and contains the following:

A definition of the business context inclusive of the definition of the work packages, associated organizations, and deliverables.

Human readable forms of all applicable Business Authorization Categories.

Attributes implementation policy – defines the accepted options for conveying the attributes (of the subject, of the resource, of the environment, etc.) to the authorization process (e.g., provisioning, attribute exchange, assertions, attribute services, topologies of identity, attribute providers, etc.).

Rules implementation policy – defines the accepted options for evaluating the access rules that are defined by every Business Authorization category (e.g., ACL based, Role based, Attribute based, etc.).

Audit implementation control – defines the accepted options for producing the audit data required to assure compliance.

The Business Context Specific Resource Protection Profile Dataset is a computer-processable artifact that contains the following:

Identifiers specification – defines the identifiers for the collaborative parties.

The nomenclature for the elements of the Work Breakdown Structure (WBS), Organization Breakdown Structure (OBS), and Product Breakdown Structure (PBS), that collaboration partners can use to configure the mapping with their own WBS, OBS, and PBS management systems.

Trust specification – defines the technical artifacts (e.g., token signing certificates and certificate chains) needed to establish technical trust with the collaborative parties.

Attributes specification – defines how the requestor and environmental attributes need to be expressed and conveyed to the relying party.

Labeling rules – expressed in a computer-processable form, labeling rules allow automation of the configuration of labeling tools.

Access rules – expressed in a computer-processable form, access rules allow automation of the configuration of access management tools within applications.

Below, details are provided regarding the creation of the implementation policies, including the attribute, rules, audit log, and implementation policies.

Creation of the Contractual Business Context Specific Resource Protection Profile

Purpose To specify the implementation options that are allowed with respect to attributes, rules-evaluation, and audit-log.



Creation of the Contractual Business Context Specific Resource Protection Profile

Input Business Context Specific Resource Protection Profile

Knowledge of the generic applications in scope

Knowledge of the generic infrastructures and deployment types in scope

Implementation policies templates

Output Attribute Implementation Policy

Rules Evaluation Implementation Policy

Audit-Log Implementation Policy


Technical level

Steps 1. For each abstract, define access rules in the Business Context Specific Resource Protection Profile.

7.1 Rules-Evaluation Implementation Policy

The Rules-Evaluation Implementation Policy is a section of the Business Context Specific Resource Protection Profile Implementation Control Document, whose purpose is to specify the set of access rules that are required to ensure information protection, and to specify how precisely these access rules must be implemented. All collaboration partners must implement the rules-evaluation attribute policy by supplying their Rules-Evaluation Implementation Statement. The concept of Rules-Evaluation Implementation Policy and associated Rules-Evaluation Implementation Statement(s) form the cornerstone of ILH access management trust.

The rules-evaluation implementation policy is closely dependent upon access management mechanisms within the considered applications.

Let us consider the following two types of applications:

Information containers applications – these applications support most primary capabilities (e.g., storage, search, navigation, and indexing) and business workflows (e.g., approval and reporting) needed for information management. These applications are generally server based, and use web-based access protocols (i.e., users access these applications through a web-browser). Microsoft SharePoint 2010 is a representative application of this category.

Authoring applications – these applications are used to create, view, and modify particular types of information. These applications generally run on the client computing environment.

1

Applications of the Microsoft Office 2010 Suite are representative of this category.

The ILH v.1 capability provides consistent access management for only the first type of applications (information container applications). There is currently no mechanism to allow desktop applications to enforce the same applicable policies as can be enforced on server-side applications.

1 We recognize that authoring applications can be server-based, as well as accessed via web-protocols,

and through web-browsers. ILH v.1 has not focused on this category of authoring applications.



This current guidance considers two main implementation approaches to compliant policy enforcement:

Group-based Authorization

Security officers evaluate the entitlement of each user who may potentially participate in the business context; for each such user, the security officer determines the set of Business Authorization Categories that the user is entitled to by manually running the access rules called out by each Business Authorization Category. As a result, users are assigned to authorization groups, which reflect all the Business Authorization Categories that the users are entitled to. Membership to these groups is conveyed to the resource providers at the time of resource access so the authorization decision can occur. This approach is suitable for resource providers for which authorization mechanisms can be solely group-based. The ILH guidance designates these resource providers as Access Control List (ACL) based.

Attributes-based Authorization

Security officers evaluate the business attributes for each user who may potentially contribute to the business context; most of these business attributes are shared across the Business Authorization Categories of the business context, hence, this administrative activity is largely reduced when compared to the above approach. Business attributes are conveyed to the resource providers at the time of resource access so the authorization decision can occur. This approach is suitable for resource providers for which authorization mechanisms can be attributes-based. The ILH guidance designates these resource providers as ABAC (Attributes Based Access Control) based.

Attributes-based authorization offers several benefits over the group-based authorization approach:

Lower user-administration cost – there are far fewer business attributes to be administered for each user compared to their total number of entitlements.

Higher agility and risk reduction – access rules can be administered independently of the administration of the business attributes, which the access rules articulate, making it possible to update the access rules in a unilateral fashion, for example, in order to mitigate a new risk.

Higher granularity and higher security – group-based authorization cannot evaluate rules that are dependent upon dynamic conditions (such as environmental attributes, e.g., defense condition, or DEFCON) as they are solely based upon the static administration of users attributes.

More sophisticated – with better support for consistent enforcement across the enterprise, attribute-based authorization is supported by standard specifications (OASIS XACML) which are implemented by a host of enterprise entitlement management solution providers. This allows for a consistent enforcement of all the required information protection policies across applications, platforms, and devices.

The selection of the appropriate access management approach is largely determined by the capability and maturity of the IT infrastructures and their supporting business processes within the implementing organizations. Currently, access management in the applications deployed across organizations is largely group-based; although recommended for all the benefits outlined above, ABAC is currently supported on a very minor proportion of applications. It follows that a rules-evaluation policy would typically specify group-based access management implementations together with attribute-based implementations should the later be available for implementation.

The term “Access Management Profile” designates how a given access management implementation can be used to meet the information protection policy requirements. ILH v.1 currently recognizes four Access Management Profiles. These are described in the table below:



Type Access Management Profile

Description

Group-based

ACL-1 The requestor’s organization a) assigns users to groups that express that the users are entitled to individual Business Authorization Categories, b) determines all the valid combinations of these entitlement groups, and c) conveys to the resource provider the combinations of these groups for the considered business context.

The resource provider can perform the authorization decision based upon the combined groups for the user.

This access management profile is recommended when resource providers cannot, due to technical limitations, perform the determination of all the valid combinations. This determination needs to be performed on the requestor side. The main drawback is the size of information that needs to be conveyed between the requestor and resource provider. When Identity Federation is used as a communication channel, the main drawback of this access management profile is potential token bloats.

ACL-2 The requestor’s organization a) assigns users to groups that express that the users are entitled to individual Business Authorization Categories, and b) conveys to the resource provider the individual group memberships.

The resource provider a) determines all the valid combinations of these groups, and b) performs the authorization decision based upon the combined groups for the user.

This access management profile is recommended when resource providers can perform the determination of all the valid combinations. The main benefit of this access management profile is to avoid any potential token bloats, in particular when Identity Federation is used to convey the group memberships to the resource provider.

Attributes-Based

ABAC-1 The requestor’s organization a) administers primary, discrete, business attributes for their users, and b) conveys to the resource provider the attributes that are required for the considered business context.

The resource provider can perform the authorization decision based on the received attributes for the user.

This access management profile is recommended when resource provider’s access management can be attribute-based.

ABAC-2 The requestor’s organization a) administers primary, discrete, business attributes for their users, together with derived business attributes, and b) conveys to the resource provider the attributes that are required for the considered business context.

The resource provider can perform the authorization decision based upon the received attributes for the user.

This access management profile is recommended when resource provider’s access management can be attribute-based, and when some primary business attributes cannot be expressed per regulatory



Type Access Management Profile

Description

reasons (e.g., in most EU countries, the user’s primary attribute designating its nationalities cannot be expressed as per privacy requirements). In this case, the requestor’s organizations need to convey derived business attributes.

The Rules-Evaluation Implementation Policy document must contain the following:

Rules-Evaluation Implementation Policy

Abstract rules Describes the set of abstract rules that are needed to protect information, using a structured-English formalism that is agnostic of the allocation of the rule to parties (as the rule can be distributed between the relying party, resource provider, and third parties) and of the technical evaluation means.

Implementation options

Describes the technical implementations that are accepted for each abstract rule of the abstract rules set including:

who/what can evaluate the rule (partitioning)

whether or not the rule can be evaluated directly or as derived attributes

accepted technical options for the implementation of the evaluation of the rule (i.e., ACL-1, ACL-2, ABAC-1, or ABAC-2)

As an illustrative example, the Program-Z business context allows for the ACL-2 and ABAC-1 implementations. This would be expressed as follows within the Implementation Control Document:

Rules Evaluation Implementation Policy

Service Providers must protect information by following one (or more) of the following two implementation options: ACL-2 or ABAC-1. This section provides details on each one of the two allowed options.

Service Providers – Rules Evaluation Policies

ACL-2

Business requirements

Overview

Information is protected by the means of one access control list formed by the list of the Business Authorization Categories under which the information must be protected. A user can access any given information if he qualifies for ALL the Business Authorization categories that are specified on the ACL.

In this option, the Service Provider consumes two attributes about the user:

1. The assertion of the list of all the Business Authorization Categories that the user is entitled to. This assertion takes the form of a single value which contains the concatenated list of all Business Authorization Categories using an agreed separator.

2. The assertion of the user’s physical location.

Business process

Service Providers typically perform the following steps:




a) At the time a document is checked-in, the Service Provider looks at the list of Business Authorization Categories that must apply to the document (by analyzing the BAILS metadata) and applies the ACL that is most appropriate for representing the “AND” condition on all applicable Business Authorization Categories.

b) At the time a document is accessed, with the input that 1) the Service Provider computes all the possible combinations of Business Authorization Characteristics, and 2) the Service Provider discards the combinations that do not meet the physical location requirement; finally the Service Provider can match the remaining combinations of Business Authorization Categories with the ACL that was applied on a) a permit or deny access, accordingly.

c) The Service Provider meets the audit-log requirements described in above19 of this document.

ABAC-1


Overview

Information is protected by means of an engine that, at information access-time, evaluates all the access rules required by the Business Authorization Categories under which the information must be protected. Each access rule typically makes use of attributes about the user, attributes about the resource, and environmental attributes. If case access is permitted, these engines typically have ways to also enforce additional obligations.

In this option, the Service Provider consumes five attributes about the user:

1. Organizations to which the user is affiliated

2. Nationality of the user

3. Work efforts assigned to the user

4. Characteristics of the user with respect to ITAR (NDA and training)

5. User’s physical location

Business process

Service Providers typically perform the following steps:

a) At the time a document is accessed, the Policy Enforcement Point (PEP) within the application sends an authorization request to the Policy Decision Point (PDP) together with sufficient context information that will allow the PDP to retrieve the attributes that he needs to provide an authorization decision.

b) The PDP identifies all the applicable access rules. The criteria of application is typically specified in the “target” section of the access rules, which can refer to attributes on the user and to attributes of the resource. In the TSCP context, BAILS metadata (attributes of the resource) are key to the identification of the applicable access rules.

c) The PDP evaluates all the applicable access rules with the required input formed by user, resource, and environmental attributes. The TSCP access rules are structured (via BAF) in such a way that they either evaluate to “allow” or “deny.” The PDP treats the first “deny” as final




(deny-override). Hence, the authorization request is granted only if all applicable access rules are allowed; otherwise the request is denied.

d) The PDP returns the authorization decision to the PEP. In the case of an “allow,” the PDP also transmits all the obligations that access rules can potentially specify.

e) The PEP enforces the decision; in the case of an “allow,” the PEP also needs to apply the specified obligations.

Throughout the whole process, PEP and PDP meet the audit-log requirements described in 19 of this document.

7.2 Attribute Implementation Policy

The Attribute Implementation Policy is the section of the Business Context Specific Resource Protection Profile Implementation Control Document whose purpose is to specify the set of attributes that are required to ensure information protection. All collaboration partners must implement the attribute policy by supplying their Attribute Implementation Statement. The concept of Attribute Implementation Policy and associated Attribute Implementation Statement(s) form the cornerstone of ILH attribute trust.

The Attribute Implementation Policy section must contain the following:

Attribute Implementation Policy

Attribute set Describes the set of attributes that are needed to protect information, structured along with requestor, resource, environmental, and other attributes.

For each such attribute, specification of:

a) Generic name (technical implementation independent)

b) Semantics (with appropriate references to policy artifacts)

c) Business process (required to manage attribute lifecycle)

d) Authoritativeness (who is authoritative over the attribute)


Describes the technical implementations that are accepted for each attribute of the attribute set, including:

The Access Management Profile that the attribute is associated with by reference to the Access Management Profiles allowed per the Rules-Evaluation Implementation Policy section of this document.

Who/what can assert the attribute?

Can the attribute be expressed directly or as derived attributes?

Must the attribute be determined dynamically (if so, it cannot be provisioned)?

Accepted technical options for asserting the attribute (e.g., provisioning, ID federation, associated technical profiles, etc.).

The steps leading to the production of an attribute implementation policy are:

1. For each attribute in-use of the Business Context Specific Resource Protection Profile, call out the definition of the attribute.



2. Identify derived attributes, if applicable to the collaboration, and call out the definition of each derived attribute.

3. Identify the allowed technical options, which are formed of the following: combinations of attribute-sets, technical means (e.g., IDFed, groups provisioning), and modality (e.g., push/pull).

4. For each technical option, call out the attribute policy.

As an illustrative example, the Program-Z business context allows for the ACL-2 and ABAC-1 implementations. This would be expressed as follows within the Implementation Control Document:

Attributes Implementation Policy

The requirements below must be met by all Identity Providers of Program-Z, in order to support the required information protection:


1. User principal

Required by the COR, provides the unique identifier of the requestor.

The following is provided for the convenience of the reader only. Please refer to the COR for reference language on semantics, business process, and technical implementation.


Semantic

COR: “Each security principal must have a unique, permanent, and never reassigned identifier within the scope of their IdP which can be uniquely associable with tokens, credentials, and/or attributes issued to that identity.”

Business process

Section 2.1.2 of the COR provides a precise and comprehensive business process for the management of the attribute.

Technical requirements

The "Principal" attribute will be conveyed using Identity Federation, as shown below:

Identity Federation

Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

Data type – name form of an email address as specified in RFC 2821, as defined in SAML 1.1.

Purpose

Not used for Access Management purposes.

Used for Audit-Log purposes (see 27).

2. Physical Location

[ACL-2]

[ABAC-1]


Semantics

The "physical location" attribute is the indication of the country where the requestor is physically located

1 at the time

2 of the authentication.

1Location, expressed above as a country, could be more granular when

required (e.g., site location).

2Accuracy and timeliness could be more timely when required (e.g., at the




time of the access request).

Business process

The physical location is an attribute1 that organizations administer for their

own users based upon the following process:

The default country location for all users is recorded as a user attribute. Users traveling outside of the default country location must provide sufficient notice and details in order to allow for the appropriate tracking of their country location throughout their travel.

2

1 Determination of the location, although defined above as statically

administered, could be dynamically determined under particular conditions, and with appropriate technologies (e.g., some technical mechanism that can detect that the end user is on-site and physically connected to the enterprise network).

2 Details on the business process could be more accurate and timely

when required, and when enabling technologies are available.

Authority

Each organization is authoritative over the location of the individuals that they manage.


The attribute will be conveyed using Identity Federation, as shown below:

Identity Federation

Name: http://schemas.tscp.org/2012-03/claims /Location

Data type: 1) ISO 3166

1) The data type needs to align with the semantics of the attribute. Here, ISO 3166 is required to express country codes; should the location be more granular (e.g., site location), the data type must change accordingly (e.g., namespace-qualified site identifier).

Multiplicity: 1

Purpose

Used for Access Management purposes by all ITAR Business Authorization Categories: TAA-1.1, TAA-1.2, and in all Access Management Profiles.

3. Business Authorization Category Entitlements

[ACL-2]


Semantics

The "Business Authorization Category Entitlements" attribute is the list of Business Authorization Categories that the requestor is entitled to by his organization.

Business process

Organizations must maintain, for the business context, and for each user who can potentially contribute to the collaboration, the list of Business Authorization Categories that the user is entitled to by evaluating the rules




associated with each such Business Authorization Category.

A given user must be entitled to a given Business Authorization Category only if all the user's attributes match the user-attribute requirements specified by the Business Authorization Category.

To ensure appropriate accuracy and timeliness, the rules for each user must be re-evaluated in a periodic fashion, at a rate of at least two times per year.

1

Organizations must define a process to establish the BA Category Entitlements for their users, and must review this process in a yearly basis.

1Accuracy and timeliness – this criterion must be adapted for the

business context.

Authority

Each organization is authoritative over the Business Authorization Category entitlements of the individuals that they manage.


The attribute will be conveyed using either Identity Federation, or cross-domain provisioning, as shown below:

Identity Federation

Depending on the capability of a targeted relying party, two options are permitted:

a) All Business Authorization Category Entitlements are transmitted to the relying party as a multi-valued SAML attribute.

b) All Business Authorization Category Entitlements are transmitted to the relying party as a single-valued SAML attribute formed by concatenating all the individual Business Authorization Category Entitlements.

The choice of the option is dependent upon the technical capability of the relying party.

a) Multi-value SAML attribute:

Name: http://schemas.tscp.org/2012-03/claims/BAC-Entitlement

Value: Business Authorization Category name that the user is entitled to

Domain value for each BA Category name: "IPL-2.1 ", "TAA-1.1 ", "TAA-2.1 ", and " UK-Restricted-1.1"

Multiplicity: Multiple, Optional

b) Single-value SAML attribute:

Name: http://schemas.tscp.org/2012-03/claims/BAC-Entitlements

Value: a string formed by the concatenation of all the identifiers of each Business Authorization Category names that the user is entitled to; each identifier is delimited by the character ‘|’

Domain value for each BA Category: " IPL-2.1 ", "TAA-1.1 ", "TAA-2.1 ", and "UK-Restricted-1.1"

Multiplicity: unique, optional




Purpose

Used for Access Management purposes on the two ACL-based Access Management Profiles ACL-1 and ACL-2.

4. Organizations

[ABAC-1]


Semantics

The list of the organizations the requestor is affiliated with that need to be indicated in the scope of the business context; users are affiliated as employees or sub-contractors.

1

1 Affiliation types – enumerate the affiliation types that are accepted by the

business context.

Business process

Organizations that are either Curtiss, Packard, Spad, or Spad-RO2 must

maintain the affiliation status of their users, and most critically, must update this status in a timely fashion when the affiliation terminates.

To ensure appropriate accuracy and timeliness, the rules, for each user, must be re-evaluated in a periodic fashion, at a rate of at least two times per year.

3

Organizations must define a process to establish the organization affiliation for their users, and must review this process on a yearly basis.

2 If required, specify only the organizations referred to by all the access rules

of the business context for organizational privacy purposes.

3 Accuracy and timeliness – this criterion must be adapted for the business

context.

Authoritativeness

Each organization is authoritative over the organization affiliation attribute of the individuals that they manage.


Identity Federation

Name: http://schemas.tscp.org/2012-03/claims/OrganizationID

Value: Organization identifier

Data type: schema-qualified identifier {duns:name | FR-KBIS:name | ... | name}

Multiplicity: multiple, mandatory1

1The COR specifies that this attribute is optional. This document makes the

attribute mandatory, as it is required for the evaluation of the IPL-2.1 access rules.

Purpose

Used for Access Management purposes on the two ABAC-based Access Management Profiles ABAC-1 and ABAC-2.

5. Work Efforts

[ABAC-1]


Semantics




The list of work-efforts to which the requestor is assigned to. The business context defines three possible products (Navigation System, Flight Control System, and Communication System) and three activities (High Level Design, Detailed Design, and Simulation). The work-effort is the Cartesian products of the product and activity to which the user is assigned.

Business process

The organization must maintain, for the business context, and for each user who can potentially contribute to the collaboration, the list of work-efforts the user is assigned to. The attribute must be updated no later than one business day after any of the individual work effort assignment changes for the requestor.

Authoritativeness

Each organization is authoritative over the work effort attributes of the individuals that they manage.



Identity Federation

Name: http://schemas.tscp.org/2012-03/claims/Work-Effort

Type: string uniquely designating a work effort, expressed by the combination of a product and an activity qualifier:

Product qualifier domain value {"NS", "FCS", "CS"}

Activity qualifier domain value {"HLD", "DD", "SIM"}

Attribute domain value {"NS.HLD", "NS.DD", "NS.SIM", "FCS.HLD", "FCS.DD", "FCS.SIM", "CS.HLD", "CS.DD", "CS.SIM"}

Multiplicity of the attribute: mandatory, multiple

Purpose


6. Characteristics

[ABAC-1]


Semantics

List of business conditions that the requestor satisfies, and which have been procedurally verified by the IDP prior to the request. The business specifies the following characteristics

1:

a) TAA NDA Required for the evaluation of TAA-1.1 and TAA-1.2 access rules. This means that the user has signed an NDA, and the user’s affiliated organization maintains a copy of this NDA for five years after the expiration of this TAA.

b) TAA Training Required for the evaluation of TAA-1.1 and TAA-1.2 access rules. This means that the user is up to date with respect to his training and




awareness on ITAR policy. 1Defined here is a list of characteristics required by the business context with an

indication of the associated Business Authorization Categories.

Business process

a) Organizations must maintain for the business context, and for each user who can potentially contribute to the collaboration, the list of characteristics the user can receive by applying the following rules:

A user must be entitled for “TAA NDA” when all the following conditions are met:

1. The user is a non-US national (including dual nationals).

2. The user needs to access information that falls under TAA-1.1 or under TAA-1.2.

3. The user has executed an NDA that includes the provisions in TAA-1.1 and/or in TAA-1.2.

4. The organization affiliated to the user has provided a copy of this NDA to CURTISS.

5. The organization affiliated to the user has means for maintaining a copy of this NDA until July 30, 2020.

b) A user must be entitled for “TAA NDA” when all the following conditions are met:

1. The user is a non-US national (including dual nationals).

2. The user needs to access information that falls under TAA-1.1 or under TAA-1.2.

To ensure appropriate accuracy and timeliness, the clearance criteria, for each user, must be re-evaluated in a periodic fashion, at a rate of at least one to two times per year.

1

Organizations must define a process to establish the characteristics for their users, and must review this process on a yearly basis.

1Accuracy and timeliness – this criterion must be adapted for each business context.

Authoritativeness

Each organization is authoritative over the clearance(s) attribute of the individuals that they manage.



Identity Federation

Name: http://schemas.tscp.org/2012-03/claims/Characteristic

Type: string uniquely designating a clearance

Domain value: {"TAA-1.1-NDA", "TAA-1.2-NDA", "TAA-1.1-Training", "TAA-1.2-Training"}




Multiplicity of the attribute: mandatory, multiple

Purpose


7. Nationality

[ABAC-1]


Semantics

List of the nationalities of the user.

Business process

Organizations that must maintain a list of nationalities for each user who can potentially contribute to the collaboration. To ensure appropriate accuracy and timeliness, the nationalities attribute, for each user, must be re-evaluated in a periodic fashion, at a rate of at least once per year.

1

Organizations must define a process to establish the characteristics for their users, and must review this process on a yearly basis.

1Accuracy and timeliness – this criterion must be adapted for the business

context.

Authoritativeness

Each organization is authoritative over the nationality attribute of the individuals that they manage.


Identity Federation

Name: http://schemas.tscp.org/2012-03/claims/Nationality

Data type: ISO 3166

Multiplicity: mandatory, multiple

Purpose

Used for Access Management purposes on the ABAC-1 Access Management Profile.

7.3 Audit-Log Implementation Policy

The Audit-Log Implementation Policy is a section of the Business Context Specific Resource Protection Profile Implementation Control Document whose purpose is to specify the audit-log requirements that are mandated to ensure auditability of the Business Context Specific Resource Protection Profile implementation. All collaboration partners must implement the Audit-Log Implementation policy by supplying their Audit-Log Implementation Statement. The concept of Audit-Log Implementation Policy and associated Audit-Log Implementation Statement(s) form the cornerstone of ILH compliance audit trust.


Abstract actions Describes the set of abstract actions that are involved in the collaboration, inclusive of key administrative and execution phases, and which are subject to audit-log.





Describes the technical implementations that are accepted for audit-log of each abstract action inclusive of:

Who/what can audit-log the action (partitioning).

What information must be logged and for how long.

Accepted technical options for the actual audit-log mechanism.

As an illustrative example, the Program-Z business context specifies the following audit-log implementation within the Implementation Control Document:


Administration of user attributes

[Identity Provider]


Overview

Identity providers must generate and maintain audit-log information on the update of the user attributes referred by the Program-Z Protection Profile in order to support the compliance verification and forensics business processes.

Business process

Identity Providers must keep the record of the administrative operations of creation, update, and deletion affecting any of the attributes referred to in Section 3 of this document by meeting the audit-logging procedure set out in Section 2.9.4 of the COR.

Administration of access management mechanisms

[Service Provider]


Overview

Service providers must generate and maintain audit-log information on the administration of access management mechanisms in order to support the compliance verification and forensics business processes.

Business process

Service Providers must keep the record of the administrative operations affecting any of the access rules implementations referred to in Section 4 of this document by meeting the audit-logging procedure set out in the TO-DO section of the COR.

Access to information

[Identity Provider]

[Service Provider]


Overview

Identity Providers and Service providers must generate and maintain audit-log information on the runtime access to information in order to support the compliance verification and forensics business processes.

Business process

Identity Providers and Service Providers must keep the record of the runtime access to information, inclusive of attempts of access, grant and denial of access, and by meeting the audit-logging procedure set out in the TO-DO section of the COR.



8 Distribution of Business Context Protection Profiles

8.1 Security Requirements

Business Context Protection Profiles are to be authored by individuals who have, within their own organizations, the appropriate training and mandate to do so. This is of particular importance as Business Context Protection Profiles are authoritative implementation requirements that collaborative partners must meet.

It follows that Business Context Protection Profiles must be distributed using means that guarantee the authenticity (assurance of the identity of the author) and authorization.

8.2 Support in ILH v.1

ILH v.1 recognizes these requirements, but does not provide systemic support by applications and tools.

More specifically, in ILH v.1:

1. The identity of the individual authoring a Business Context Protection Profile is not captured by any tool.

2. There is no tools-support for approval workflows on Business Context Protection Profiles.

3. There is no tools-support for the recording of the individuals who are authorized to issue Business Context Protection Profiles within a particular entity or organization.

4. There is no tools-support for the configuration management of Business Context Protection Profiles.

5. There is no tools-support for the integrity of a Business Context Protection Profile.

ILH v.1 provides the following procedural guidance for the distribution of Business Context Protection Profiles across organizations in a trustworthy manner:

1. Within organizations authoritative for the issuance of Business Context Protection Profiles, put the appropriate workflow in place using existing applications and tools to ensure that Business Context Protection Profiles are correctly reviewed and approved before they can be distributed.

2. Organizations distributing Business Context Protection Profiles must verify that information contained in the individual Business Authorizations is adequate for each individual recipient organization, in particular, with respect to confidentiality requirements; it may be required to filter out some information and proceed with a targeted distribution so not all of the recipients receive the exact same content.

3. Within organizations producing and consuming Business Context Protection Profiles, put the appropriate workflow in place using existing applications and tools to ensure the appropriate Configuration Management of Business Context Protection Profiles.

4. Use Secure Email v.1 (with signature and encryption) to distribute a Business Context Protection Profile with the assurance of the identity of the sender, and with the assurance that the Business Context Protection Profile has not been tempered with in transit.

5. Within organizations receiving a Business Context Protection Profile, use-agreed, out-of-band procedures that ensure the originator of a Business Context Protection Profile is authorized to do so by his organization are necessitated.

In all cases, ensure that the exchange of original and updated Business Context Protection Profiles is appropriately and securely recorded for audit purposes.



9 Appendices

9.1 Policy Artifact: TAA#1

HYPOTHETICAL TECHNICAL ASSISTANCE AGREEMENT

Between

CURTISS CORPORATION

and

PACKARD LTD

And

SPAD ROMANIA

for the Program Z Navigation System

This TECHNICAL ASSISTANCE AGREEMENT (TAA) is entered into by and between:

Curtiss Corporation, having offices at 100 Infinite Loop, Cupertino, CA, USA, a corporation organized and existing under the laws of Delaware (hereinafter referred to as “CURTISS”);

Packard Ltd, having offices at 7 Regent St, London, Great Britain (hereinafter referred to as “PACKARD”);

Spad Romania having offices at 63-81 Calea Victoriei, București, Romania (hereinafter referred to as “SPAD-RO”).

WHEREAS, CURTISS develops navigation systems; and

WHEREAS, CURTISS has modified its commercial navigation system for the Program-Z fighter; and

WHEREAS, PACKARD will assist CURTISS in the simulation of the navigation system; and

WHEREAS, SPAD-RO will assist CURTISS in the integration of the navigation system.

NOW THEREFORE, the Parties desire to enter into a Technical Assistance Agreement (hereinafter referred to as “TAA” or “Agreement”) as follows:

HYPOTHETICAL TECHNICAL ASSISTANCE AGREEMENT

Between

CURTISS CORPORATION

and

PACKARD LTD

And

SPAD ROMANIA

for the Program Z Navigation System

This TECHNICAL ASSISTANCE AGREEMENT (TAA) is entered into by and between:

Curtiss Corporation, having offices at 100 Infinite Loop, Cupertino, CA, USA, a corporation organized and existing under the laws of Delaware (hereinafter referred to as “CURTISS”);

Packard Ltd, having offices at 7 Regent St, London, Great Britain (hereinafter referred to as “PACKARD”);

Spad Romania having offices at 63-81 Calea Victoriei, București, Romania (hereinafter referred to as “SPAD-RO”).

WHEREAS, CURTISS develops navigation systems; and

WHEREAS, CURTISS has modified its commercial navigation system for the Program-Z fighter; and

WHEREAS, PACKARD will assist CURTISS in the simulation of the navigation system; and

WHEREAS, SPAD-RO will assist CURTISS in the integration of the navigation system.

NOW THEREFORE, the Parties desire to enter into a Technical Assistance Agreement (hereinafter referred to as “TAA” or “Agreement”) as follows:

1. CURTISS will require exchange of technical data in detailed design, simulation and integration of the GPS Navigation Unit (GNU), the Embedded GPS Navigation Unit (EGPSU) and the Multimode GPS Receiver (MGPSR).

2. PACKARD and the Integration division of SPAD-RO will provide expertise in design and simulation of the GNU, EGPSU and MGPSR.

3. No technical information exchanged under this agreement will be U.S. classified.

4. No technical information exchanged under this agreement will be Foreign Government classified.

1. CURTISS will require exchange of technical data in detailed design, simulation and integration of the GPS Navigation Unit (GNU), the Embedded GPS Navigation Unit (EGPSU) and the Multimode GPS Receiver (MGPSR).

2. PACKARD and the Integration division of SPAD-RO will provide expertise in design and simulation of the GNU, EGPSU and MGPSR.

3. No technical information exchanged under this agreement will be U.S. classified. 4. No technical information exchanged under this agreement will be Foreign Government classified. 5. PACKARD and SPAD-RO subcontractors may receive technical information under this agreement, providing they agreed to the

provisions of this agreement and execution of a Non-Disclosure Agreement (NDA).

6. Technical information will be exchanged in the countries of U.S, U.K, and Romania. CURTISS, PACKARD and SPAD-RO may

provide technical data and assistance to employees who are third country nationals (including dual nationals) of Romania, the

United Kingdom, and Italy. Prior to transfer to third country nationals (including dual nationals), employees must execute a Non-

Disclosure Agreement (NDA) that includes the provisions in this TAA. The foreign party must provide CURTISS a copy of each

NDA, and CURTISS will maintain a copy of the NDA for five years after the expiration date of this TAA.

This agreement shall remain in force until July 30, 2011.

information labeling and handling policy authoring guidelines · information labeling and handling...

Documents