Information Labeling and Handling Policy Authoring Guidelines · Information Labeling and Handling...
Transcript of 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.
ILH Policy Authoring Guidelines
© 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
5 Aug 11 0 3 JP Buu-Sao
Modified after feedback from Richard Skedd, and addition of general guidance on BA Distribution
Richard Skedd Review with ILH team
17 Aug 11 0 4 JP Buu-Sao
Modified after feedback from EC SMEs, adding clearance, country of incorporation, support for Country Lists
EC SMEs Review with ILH team
22 Aug 11 0 5 JP Buu-Sao
Structured on business process steps
ILH Team Review with ILH team
23 Aug 11 0 6 JP Buu-Sao
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
ILH Team Ready for review by AB
2 Oct 12 0 8 JP Buu-Sao
Modified after feedback from Richard Skedd and John Tolbert
ILH Team Ready for review by AB
ILH Policy Authoring Guidelines
© 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
ILH Policy Authoring Guidelines
© 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
ILH Policy Authoring Guidelines
© 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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 2 of 52
2 Business Process Overview
This document focuses on the business process depicted below:
Figure 1. Business process overview
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 3 of 52
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 4 of 52
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 5 of 52
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 6 of 52
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 7 of 52
Spad-Romania
Role Select: Signatory
Address Line 1 Enter: 63-81 Calea Victoriei
Address Line 2 Enter: București
Country Enter: RO
The screen should look similar to:
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 8 of 52
The screen should look similar to:
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.
The screen should look similar to:
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.”
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 9 of 52
The screen should look similar to:
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.”
The screen should look similar to:
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)
Skills Business level
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 10 of 52
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.
The screen should look similar to:
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.
Input Contract/agreement documentation (e.g., TAA)
Output Business Authorization in BAF format (e.g., TAA-1.xml)
Skills Business level
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 11 of 52
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)
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 12 of 52
The screen should look similar to:
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.
Input Contract/agreement documentation (e.g., TAA)
Output Business Authorization in BAF format (e.g., TAA-1.xml)
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).
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 13 of 52
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 14 of 52
The screen should look similar to:
5. Click on the tab “BACat 2” in order to enter the information related to the second Business Authorization Category of this TAA.
6. Make sure that this Business Authorization Category is enabled. Enabled should be checked.
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
Topics Select: Created after milestone M3
Products Select: GNU, EGPSU, MGPSR
Work efforts Select: Integration
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 15 of 52
The screen should look similar to:
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.
Input Contract/agreement documentation (e.g., TAA)
Output Business Authorization in BAF format (e.g., TAA-1.xml)
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).
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 16 of 52
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
Products Select: GNU, EGPSU, MGPSR
Work efforts Select: DetailedDesign, Simulation
Locations Select: US, GB
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 17 of 52
The screen should look similar to:
11. Click on the tab “BACat 2” in order to enter the information related to the second Business Authorization Category of this TAA.
12. Make sure that this Business Authorization Category is enabled. Enabled should be checked.
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
Products Select: GNU, EGPSU, MGPSR
Work efforts Select: Integration
Locations Select: US, RO
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 18 of 52
The screen should look similar to:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 19 of 52
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)
Output 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
Business Authorization Category TAA-1.2
URN Enter: urn:curtiss:ba:taa:taa-1.2
OID Enter: 1.3.6.1.4.1.30000.300.2
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 20 of 52
The screen should look similar to:
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.
Input Business Authorization in BAF format (e.g., TAA-1.xml)
Output Business Authorization in BAF format (e.g., TAA-1.xml)
Skills Business level
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 21 of 52
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).
The screen should look similar to:
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:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 22 of 52
Business Authorization Category TAA-1.1 – Categorization rules
Topics Select: Created after milestone M3
Classifications Select: USML:11A, USML:11B
Business Authorization Category TAA-1.2
Topics Select: Program-Z after milestone M3
Classifications Select: USML:11A
The screen should look similar to:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 23 of 52
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.
Input Business Authorization in BAF format (e.g., TAA-1.xml)
Output Business Authorization in BAF format (e.g., TAA-1.xml)
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.”
The screen should look similar to:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 24 of 52
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.
Input Business Authorization in BAF format (e.g., TAA-1.xml)
Output Business Authorization in BAF format (e.g., TAA-1.xml)
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:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 25 of 52
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.
Business Authorization Category TAA-1.1 and TAA 1.2 – Physical marking #2
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.
Business Authorization Category TAA-1.1 and TAA 1.2 – Physical marking #3
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
Business Authorization Category TAA-1.1 and TAA 1.2 – Physical marking #5
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 26 of 52
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.
The screen should look similar to:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 27 of 52
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.
Input Business Authorization in BAF format (e.g., TAA-1.xml)
Output Business Authorization in BAF format (e.g., TAA-1.xml)
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 28 of 52
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)
Skills Business level
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 29 of 52
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.
Format: medium string (less than 40 characters)
Document-Footer Purpose: Short language located at the bottom of each document's pages.
Format: medium string (less than 40 characters)
Email-First Line Of Text
Purpose: Language located at the end of the email body.
Format: medium string (less than 80 characters)
Email-Last Line Of Text
Purpose: Language located at the end of the email body.
Format: medium string (less than 80 characters)
Email-Subject prefix Purpose: Short language located at the beginning of the email subject.
Format: short string (less than 20 characters)
Email-Subject suffix Purpose: Short language located at the end of the email subject.
Format: short string (less than 20 characters)
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 30 of 52
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.
Input Business Authorization in BAF format (e.g., TAA-1.xml)
All intermediate policy artifacts
Output Business Authorization in BAF format (e.g., TAA-1.xml)
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 31 of 52
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 32 of 52
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:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 33 of 52
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 34 of 52
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 35 of 52
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 36 of 52
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 37 of 52
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
Skills Business level
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 38 of 52
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:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 39 of 52
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 40 of 52
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:
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 41 of 52
Service Providers – Rules Evaluation Policies
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
Business requirements
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 42 of 52
Service Providers – Rules Evaluation Policies
(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)
Implementation options
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 43 of 52
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:
Attribute Implementation Policy
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.
Business requirements
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]
Business requirements
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 44 of 52
Attribute Implementation Policy
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.
Technical requirements
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]
Business requirements
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 45 of 52
Attribute Implementation Policy
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.
Technical requirements
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 46 of 52
Attribute Implementation Policy
Purpose
Used for Access Management purposes on the two ACL-based Access Management Profiles ACL-1 and ACL-2.
4. Organizations
[ABAC-1]
Business requirements
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.
Technical requirements
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]
Business requirements
Semantics
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 47 of 52
Attribute Implementation Policy
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.
Technical requirements
The attribute will be conveyed using either Identity Federation, or cross-domain provisioning, as shown below:
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
Used for Access Management purposes on the two ABAC-based Access Management Profiles ABAC-1 and ABAC-2.
6. Characteristics
[ABAC-1]
Business requirements
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
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 48 of 52
Attribute Implementation Policy
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.
Technical requirements
The attribute will be conveyed using either Identity Federation, or cross-domain provisioning, as shown below:
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"}
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 49 of 52
Attribute Implementation Policy
Multiplicity of the attribute: mandatory, multiple
Purpose
Used for Access Management purposes on the two ABAC-based Access Management Profiles ABAC-1 and ABAC-2.
7. Nationality
[ABAC-1]
Business requirements
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.
Technical requirements
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.
Audit-Log Implementation Policy
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 50 of 52
Audit-Log Implementation Policy
Implementation options
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:
Audit-Log Implementation Policy
Administration of user attributes
[Identity Provider]
Business requirements
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]
Business requirements
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]
Business requirements
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 51 of 52
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.
ILH Policy Authoring Guidelines
© 2013 TSCP, Inc. Page 52 of 52
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.