Information Exchange Framework Reference Architecture

Transcription

1 Date: November 2014 Information Exchange Framework Reference Architecture Initial Submission OMG Document Number: MARS/ Standard document URL: Normative Machine Consumable File(s): TBD This OMG document replaces the submission document (mars/ , Alpha). It is an OMG Adopted Beta specification and is currently in the finalization phase. Comments on the content of this document are welcome, and should be directed to by June 20, You may view the pending issues for this specification from the OMG revision issues web page The FTF Recommendation and Report for this specification will be published on September 26, If you are reading this after that date, please download the available specification from the OMG Specifications Catalog.

2 Copyright , Advanced Systems Management (ASMG) Group Ltd. Copyright , Thematix Partners LLC Copyright , Object Management Group, Inc. USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royaltyfree, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, Information Exchange Packaging Policy Vocabulary, Initial Submission ii

3 electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems-- without permission of the copyright owner. Copyright , Advanced Systems Management (ASMG) Group Ltd. Copyright , Object Management Group, Inc. Copyright , Defence Research and Development Canada, Centre for Security Sciences (CSS) USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royaltyfree, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. Information Exchange Packaging Policy Vocabulary, Initial Submission iii

4 GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems-- without permission of the copyright owner. DISCLAIMER OF WARRANTY WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R or as specified in 48 C.F.R of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 109 Highland Avenue, Needham, MA 02494, U.S.A. TRADEMARKS IMM, MDA, Model Driven Architecture, UML, UML Cube logo, OMG Logo, CORBA and XMI are registered trademarks of the Object Management Group, Inc., and Object Management Group, OMG, Information Exchange Packaging Policy Vocabulary, Initial Submission iv

5 Unified Modeling Language, Model Driven Architecture Logo, Model Driven Architecture Diagram, CORBA logos, XMI Logo, CWM, CWM Logo, IIOP, MOF, OMG Interface Language (IDL), and OMG SysML are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners. COMPLIANCE The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites Information Exchange Packaging Policy Vocabulary, Initial Submission v

6 Table Contents TABLE CONTENTS LIST OF FIGURES LIST OF TABLES PREFACE VI X XII XVIII ABOUT THE OBJECT MANAGEMENT GROUP XVIII PART I 1 1 INFORMATION EXCHANGE FRAMEWORK REFERENCE ARCHITECTURE SCOPE ORGANIZATION OF THIS SPECIFICATION MOTIVATION IEF APPROACH IEF DELIVERED CAPABILITIES IEF OBJECTIVES IEF RA DESIGN PRINCIPLES 8 2 COMPLIANCE INTRODUCTION SELECTING A COMPLIANCE POINT COMPLIANCE POINTS File Sharing Instant Messaging Messaging Middleware Web Services 10 3 NORMATIVE REFERENCES 11 4 TERMS AND DEFINITIONS 12 5 SYMBOLS/ACRONYMS SYMBOLS 13 6 ADDITIONAL INFORMATION INTENDED AUDIENCE ACKNOWLEDGEMENTS ADDITIONAL MATERIALS 14 Information Exchange Packaging Policy Vocabulary, Initial Submission vi

7 6.4 REFERENCE ARCHITECTURE Introduction to IEF RA Philosophy MODELING CONVENTIONS 15 7 IEF REFERENCE ARCHITECTURE IEF OVERVIEW 16 8 EXTERNAL ACTORS 19 9 POLICY ADMINISTRATION POINT PAP IN AN INTER-AGENCY ENVIRONMENT PAP DESCRIPTION PAP Use Case Diagrams PAP Class Diagrams Sequence Diagrams POLICY DECISION POINT USE CASES Authorize Action Use Case Diagram PDP Use Case Diagram File PDP Use Case Diagram IM PDP Use Case Diagram Receiver Directed Messaging PDP Use Case Diagram Session Directed Messaging PDP Use Case Diagram CLASS DIAGRAMS Policy Decision Point Class Diagram SEQUENCE DIAGRAMS Policy Decision Point Sequence Diagram POLICY ENFORCEMENT POINTS PEP OVERVIEW PEP Components Class Diagram PEP Specialization Class Diagram PEP PEP Use Cases PEP Class Diagrams PEP Sequence Diagrams 84 Information Exchange Packaging Policy Vocabulary, Initial Submission vii

8 11.3 FILE SHARING PEP File Share Use Cases File PEP Class Diagrams File PEP Sequence Diagrams INSTANT MESSAGING PEP Instant Messaging Use Cases Instant Messaging Class Diagrams IM PEP Class Diagram Sequence Diagrams SESSION DIRECTED MESSAGING PEP Session Directed Messaging Use Cases Class Diagrams Session Directed Messaging PEP Class Diagram Sequence Diagrams RECEIVER DIRECTED MESSAGING PEP DATA PACKAGING AND PROCESSING SERVICES OPTIONAL REQUIREMENTS MESSAGE PACKAGING AND PROCESSING SERVICE USE CASE DIAGRAMS Package Structured Message Use Case Diagram Assemble Information Package Use Case Diagram Assemble Releasable Data Set Use Case Diagram Process Structured Information Element Use Case Diagram Package Structured Message Use Case Diagram CLASS DIAGRAMS SEQUENCE DIAGRAMS COMMON SERVICES USE CASES Authorize User Use Case Diagram Encrypt Information Element Use Case Diagram Decrypt Information Element Use Case Diagram CLASS DIAGRAMS Authorization Class Diagram Cryptography Class Diagram 217 Information Exchange Packaging Policy Vocabulary, Initial Submission viii

9 Identity Management Class Diagram Logging Class Diagram Marking Class Diagram Secure Asset Container Class Diagram SEQUENCE DIAGRAMS POLICY VOCABULARIES 240 ANNEX F: BIBLIOGRAPHY (INFORMATIONAL) 1 ANNEX G TERMS AND ACRONYMS (INFORMATIONAL) 1 GENERAL TERMS AND DEFINITIONS 1 ACRONYMS 9 ANNEX H CONFORMANCE WITH RFP 1 Mandatory Requirements 1 OPTIONAL REQUIREMENTS 5 Information Exchange Packaging Policy Vocabulary, Initial Submission ix

10 List of Figures Figure 1 -Concept Use Case Diagram Figure 2 -Administer Policy Environment Use Case Diagram Figure 3 -Policy Administration Use Case Diagram Figure 4 -Policy Management Use Case Diagram Figure 5 -Authorize Action Use Case Diagram Figure 6 -PDP Administration Use Case Diagram Figure 7 - PDP Use Case Diagram Figure 8 -File PDP Use Case Diagram Figure 9 -IM PDP Use Case Diagram Figure 10 -Receiver Directed Messaging PDP Use Case Diagram Figure 11 -Session Directed Messaging PDP Use Case Diagram Figure 12 -Send Use Case Diagram Figure 13 -Receive Use Case Diagram Figure 14 -Access File Share Use Case Diagram Figure 15 -Manage Protected File Use Case Diagram Figure 16 -Copy File Use Case Diagram Figure 17 -Create File Use Case Diagram Figure 18 -Cut File Use Case Diagram Figure 19 -Delete File Use Case Diagram Figure 20 -List Files Use Case Diagram Figure 21 -Move File Use Case Diagram Figure 22 -Open File Use Case Diagram Figure 23 -Paste File Use Case Diagram Figure 24 -Rename File Use Case Diagram Figure 25 -Save File Use Case Diagram Figure 26 -List and Join Chat Use Case Diagram Figure 27 -Receive IM Use Case Diagram Figure 28 -Send IM Use Case Diagram Information Exchange Packaging Policy Vocabulary, Initial Submission x

11 Figure 29 -Send Session Directed Message Use Case Diagram Figure 30 -Receive Message Use Case Diagram Figure 31 -Send Session Directed Message Use Case Diagram Figure 32 -Receive Use Case Diagram Figure 33 -Package Structured Message Use Case Diagram Figure 34 -Assemble Information Package Use Case Diagram Figure 35 -Assemble Releasable Data Set Use Case Diagram Figure 36 -Process Structured Information Element Use Case Diagram Figure 37 -Package Structured Message Use Case Diagram Figure 38 -Authorize User Use Case Diagram Figure 39 -Bind Markings to Information Element Use Case Diagram Figure 40 -Encrypt Information Element Use Case Diagram Figure 41 -Decrypt Information Element Use Case Diagram Information Exchange Packaging Policy Vocabulary, Initial Submission xi

12 List of Tables Table 1 - Concept Use Case Diagram Descriptions Table 2 External Actors Table 3 - Administer Policy Environment Use Case Diagram Descriptions Table 4 - Policy Administration Use Case Diagram Descriptions Table 5 - Policy Management Use Case Diagram Descriptions Table 6 Policy Administration Point Class Diagram Descriptions Table 7 Policy Administration Point Class Diagram - Interface Descriptions Table 8 Policy Administration Point Class Diagram - Association Descriptions Table 9 Identity Attribute Administration Point Class Diagram Descriptions Table 10 Identity Attribute Administration Point Class Diagram - Interface Descriptions Table 11 Identity Attribute Administration Point Class Diagram - Association Descriptions Table 12 - Policy Administration Point Sequence Diagram - Message Descriptions Table 13 - Authorize Action Use Case Diagram Descriptions Table 14 - PDP Administration Use Case Diagram Descriptions Table PDP Use Case Diagram Descriptions Table 16 - File PDP Use Case Diagram Descriptions Table 17 - IM PDP Use Case Diagram Descriptions Table 18 - Receiver Directed Messaging PDP Use Case Diagram Descriptions Table 19 - Session Directed Messaging PDP Use Case Diagram Descriptions Table 20 Policy Decision Point Class Diagram Descriptions Table 21 Policy Decision Point Class Diagram - Interface Descriptions Table 22 Policy Decision Point Class Diagram - Association Descriptions Table 23 - Policy Decision Point Sequence Diagram - Message Descriptions Table 24 PEP Components Class Diagram Descriptions Table 25 PEP Components Class Diagram - Interface Descriptions Table 26 PEP Components Class Diagram - Association Descriptions Table 27 PEP Specialization Class Diagram Descriptions Table 28 PEP Specialization Class Diagram - Interface Descriptions Information Exchange Packaging Policy Vocabulary, Initial Submission xii

13 Table 29 PEP Specialization Class Diagram - Association Descriptions Table 30 - Send Use Case Diagram Descriptions Table 31 - Receive Use Case Diagram Descriptions Table 32 PEP Class Diagram Descriptions Table 33 PEP Class Diagram - Interface Descriptions Table 34 PEP Class Diagram - Association Descriptions Table 35 - Send Sequence Diagram - Message Descriptions Table 36 - Receive Sequence Diagram - Message Descriptions Table 37 - Access File Share Use Case Diagram Descriptions Table 38 - Manage Protected File Use Case Diagram Descriptions Table 39 - Copy File Use Case Diagram Descriptions Table 40 - Create File Use Case Diagram Descriptions Table 41 - Cut File Use Case Diagram Descriptions Table 42 - Delete File Use Case Diagram Descriptions Table 43 - List Files Use Case Diagram Descriptions Table 44 - Move File Use Case Diagram Descriptions Table 45 - Open File Use Case Diagram Descriptions Table 46 - Paste File Use Case Diagram Descriptions Table 47 - Rename File Use Case Diagram Descriptions Table 48 - Save File Use Case Diagram Descriptions Table 49 File PEP Class Diagram Descriptions Table 50 File PEP Class Diagram - Interface Descriptions Table 51 File PEP Class Diagram - Association Descriptions Table 52 - Copy File Sequence Diagram - Message Descriptions Table 53 - Create File Sequence Diagram - Message Descriptions Table 54 - Cut File Sequence Diagram - Message Descriptions Table 55 - Delete File Sequence Diagram - Message Descriptions Table 56 - List Files Sequence Diagram - Message Descriptions Table 57 - Move File Sequence Diagram - Message Descriptions Table 58 - Open File Sequence Diagram - Message Descriptions Information Exchange Packaging Policy Vocabulary, Initial Submission xiii

14 Table 59 - Paste File Sequence Diagram - Message Descriptions Table 60 - Retrieve File Sequence Diagram - Message Descriptions Table 61 - Save File Sequence Diagram - Message Descriptions Table 62 - List and Join Chat Use Case Diagram Descriptions Table 63 - Receive IM Use Case Diagram Descriptions Table 64 - Send IM Use Case Diagram Descriptions Table 65 IM PEP Class Diagram Descriptions Table 66 IM PEP Class Diagram - Interface Descriptions Table 67 IM PEP Class Diagram - Association Descriptions Table 68 - List Chat Rooms Sequence Diagram - Message Descriptions Table 69 - Join Chat Room Sequence Diagram - Message Descriptions Table 70 - Send IM Sequence Diagram - Message Descriptions Table 71 - Send Special Message Sequence Diagram - Message Descriptions Table 72 - Receive IM Sequence Diagram - Message Descriptions Table 73 - Receive Special Message Sequence Diagram - Message Descriptions Table 74 - Send Session Directed Message Use Case Diagram Descriptions Table 75 - Receive Message Use Case Diagram Descriptions Table 76 Session Directed Messaging PEP Class Diagram Descriptions Table 77 Session Directed Messaging PEP Class Diagram - Interface Descriptions Table 78 Session Directed Messaging PEP Class Diagram - Association Descriptions Table 79 - Send Message To Session Sequence Diagram - Message Descriptions Table 80 - Receive Message Sequence Diagram - Message Descriptions Table 81 - Send Session Directed Message Use Case Diagram Descriptions Table 82 - Receive Use Case Diagram Descriptions Table 83 Receiver Directed Messaging PEP Class Diagram Descriptions Table 84 Receiver Directed Messaging PEP Class Diagram - Interface Descriptions Table 85 Receiver Directed Messaging PEP Class Diagram - Association Descriptions Table 86 - Send Receiver Directed Messaging Sequence Diagram - Message Descriptions Table 87 - Receive Message Sequence Diagram - Message Descriptions Table 88 - Package Structured Message Use Case Diagram Descriptions Information Exchange Packaging Policy Vocabulary, Initial Submission xiv

15 Table 89 - Assemble Information Package Use Case Diagram Descriptions Table 90 - Assemble Releasable Data Set Use Case Diagram Descriptions Table 91 - Process Structured Information Element Use Case Diagram Descriptions Table 92 - Package Structured Message Use Case Diagram Descriptions Table 93 Data Assembly Service Class Diagram Descriptions Table 94 Data Assembly Service Class Diagram - Interface Descriptions Table 95 Data Assembly Service Class Diagram - Association Descriptions Table 96 Data Packaging Service Class Diagram Descriptions Table 97 Data Packaging Service Class Diagram - Interface Descriptions Table 98 Data Packaging Service Class Diagram - Association Descriptions Table 99 - Authorize User Use Case Diagram Descriptions Table Bind Markings to Information Element Use Case Diagram Descriptions Table Encrypt Information Element Use Case Diagram Descriptions Table Decrypt Information Element Use Case Diagram Descriptions Table 103 Authorization Class Diagram Descriptions Table 104 Authorization Class Diagram - Interface Descriptions Table 105 Authorization Class Diagram - Association Descriptions Table 106 Cryptography Class Diagram Descriptions Table 107 Cryptography Class Diagram - Interface Descriptions Table 108 Cryptography Class Diagram - Association Descriptions Table 109 Identity Management Class Diagram Descriptions Table 110 Identity Management Class Diagram - Interface Descriptions Table 111 Identity Management Class Diagram - Association Descriptions Table 112 Logging Class Diagram Descriptions Table 113 Logging Class Diagram - Interface Descriptions Table 114 Logging Class Diagram - Association Descriptions Table 115 Marking Class Diagram Descriptions Table 116 Marking Class Diagram - Interface Descriptions Table 117 Marking Class Diagram - Association Descriptions Information Exchange Packaging Policy Vocabulary, Initial Submission xv

16 Information Exchange Packaging Policy Vocabulary, Initial Submission xvi

17 Information Exchange Packaging Policy Vocabulary, Initial Submission xvii

18 Preface About the Object Management Group Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry standards consortium that produces and maintains computer industry specifications for interoperable, portable, and reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information Technology vendors, end users, government agencies, and academia. OMG member companies write, adopt, and maintain its specifications following a mature, open process. OMG's specifications implement the Model Driven Architecture (MDA ), maximizing Return on Investment (ROI) through a full-lifecycle approach to enterprise integration that covers multiple operating systems, programming languages, middleware and networking infrastructures, and software development environments. OMG's specifications include: UML (Unified Modeling Language ); CORBA (Common Object Request Broker Architecture); CWM (Common Warehouse Metamodel); and industry-specific standards for dozens of vertical markets. More information on the OMG is available at OMG Specifications As noted, OMG specifications address middleware, modeling and vertical domain frameworks. All OMG Specifications are available from the OMG website at: Specifications are organized by the following categories: Business Modeling Specifications Middleware Specifications CORBA/IIOP Data Distribution Services Specialized CORBA IDL/Language Mapping Specifications Modeling and Metadata Specifications UML, MOF, CWM, XMI UML Profile Modernization Specifications Platform Independent Model (PIM), Platform Specific Model (PSM), Interface Specifications CORBAServices CORBAFacilities Information Exchange Packaging Policy Vocabulary, Initial Submission xviii

19 OMG Domain Specifications CORBA Embedded Intelligence Specifications CORBA Security Specifications All of OMG's formal specifications may be downloaded without charge from our website. (Products implementing OMG specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format, may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. at: OMG Headquarters 109 Highland Ave, Needham, MA USA Tel: Fax: Certain OMG specifications are also available as ISO standards. Please consult Typographical Conventions The type styles shown below are used in this document to distinguish programming statements from ordinary English. However, these conventions are not used in tables or clause headings where no distinction is necessary. Times/Times New Roman - 10 pt.: Standard body text. Helvetica/Arial - 10 pt. Bold: OMG Interface Language (OMG IDL) and syntax elements. Courier - 10 pt. Bold: Programming language elements. Helvetica/Arial - 10 pt: Exceptions. NOTE: Terms that appear in italics are defined in the glossary. Italic text also represents the name of a document, specification, or other publication. Issues The reader is encouraged to report any technical or editing issues/problems with this specification to Information Exchange Packaging Policy Vocabulary, Initial Submission xix

20

21 Part I Information Exchange Framework Reference Architecture, Initial Submission 1

22 1 Information Exchange Framework Reference Architecture 1.1 Scope The Information Exchange Framework (IEF) is an OMG initiative to develop a family of specifications for policy-driven, data-centric information sharing and safeguarding (ISS) services. These services target the automation of key policy decision and enforcement points to enable responsible information sharing across a broad range of business and operational scenarios. The IEF Reference Architecture (RA) will be used to guide the overall IEF effort, broaden general understanding of domain requirements, and guide the development of information sharing and safeguarding (ISS) solutions. The IEF RA is primarily targeting operational environments that require the ability to share information within and beyond agency boundaries and are often challenged by rapid, unpredictable changes in operational contexts (e.g., threat, risk, roles & responsibilities, scale, scope, and severity). These include: 1. Military (coalition and Civilian-Military) operations; 2. National Security; 3. Public Safety; 4. Crisis Management; 5. Border Security; 6. Emergency Management; 7. Peace Keeping; and 8. Humanitarian Assistance. Although these environments are the primary focus on the specification, most of the features equally support the transactional domains of a broad range of public and private sector organizations that require: 1. The ability to exchange information in a secure and trusted manner with clients, partners and subcontractors; 2. The ability to selectively share elements of an information holding with individuals and agencies in conformance with legislation regulation and policy, e.g.: a. Healthcare: Electronic Health Records (EHR); b. Finance: Banking and Insurance records; c. Justice: Criminal Case File; d. Government Programs; e. Customs and Immigration. 3. The ability to log and audit the exchange of information holdings. The IEF will adopt domain agnostic vocabulary that can easily translate to ISS in all of these domains. It will defines concepts for expressing rules governing: 1. The packaging (assemble and format) of information for release; 2. The processing (parse, process and store) of received messages or datasets; 3. The disseminations of releasable information to users (Individuals; Organizations; Role; Performer, Community or Topic; Systems; applications; or service) based on their authorizations to access specific information elements. 2 Information Exchange Framework Reference Architecture, Initial Submission

23 1.2 Organization of this Specification This specification includes seven Clauses and nine Seven: Clause 1: Provides an overview of the specification, including: Scope; Objectives; Within the Context of the Information Exchange Framework; Problem Statement; Support for Policy-driven Data-centric Information Sharing and Safeguarding; and IEF Concept. Clause 2: Defines the compliance points for the IEF RA. Clause 3: Identifies Normative References for this specification. Clause 4: Identifies Terms and their s used in various parts of the specification. This Clause does not include concepts and properties comprising the IEF RA. Clause 5: Identifies any special Symbols/Acronyms used in the development of this specification. Clause 6: Provides Additional Information about this specification. Clause 7: Provides an Overview of the IEF Reference Architecture. Clause 8: Policy Decision Point (PDP) Clause 9: Policy Administration Point (PAP) Clause 10:Policy Enforcement Points Clause 11:Policy-based Packaging Services Clause 12: Supporting Services Annex A: Annex C: Annex D: Annex E: Annex F: Clause 13: User Services Annex G: Required Discussion Points Annex H: Describes how the specification elements address the RFP requirements. 1.3 Motivation Numerous after-action and news reports on events such as SARS, the 2007 London subway bombing, the 1998 Ice Storm (eastern Canada and Northern New York State), Haiti, Afghanistan, Katrina, and 9/11 events have documented the challenges faced by even the most technologically advanced agencies to effectively and efficiently interoperate with partners. Equally prevalent are the reports documenting the growing need for agencies to increase the quantity and quality of information they share with partners when responding to an emergency or crisis situation; e.g.: Today, information sharing is critical to almost every institution. There is no more critical need for information sharing than during an international crisis, when international coalitions dynamically form. In the event of a crisis, whether it is humanitarian relief, natural disaster, combat operations, or terrorist incidents, international coalitions have an immediate need for information. These coalitions are formed with international cooperation, where each participating country offers whatever resources it can muster to support the given crisis. These situations can occur suddenly, simultaneously, and without warning. Often times, participants are Information Exchange Framework Reference Architecture, Initial Submission 3

24 coalition partners in one crisis and adversaries in another, rising difficult security issues with respect to information sharing. 1 Each participating agency requires the ability to rapidly establish pre-planned or ad hoc ISS capabilities to enable: Shared situational awareness; Collaboration (e.g., operational planning and intelligence); Coordination; and Command-and-Control. Operational users tend to emphasize the need to share; and to maximize the volume, variety and quality of information discoverable and accessible by authorized users and partners. They recognize information is vital to the formation, quality, and timeliness of decisions, as well as, the creation of decision advantage (/decision superiority). Conversely, Security and Privacy Officers, representing data owners, stewards, and custodians, apply and emphasize need-to-know practices and principles; to ensure that only users with the appropriate credentials, authorizations and need are provided access to designated information elements. These need-to-know practices result in the development and deployment of multiple selfcontained enclaves based on security level and warning terms, or caveats, such as Eyes Only, Canadian- US, and NATO. These enclaves are logically and physically separated; isolated in terms of policies, applications, platforms, networks, infrastructures, and information stores. In addition to being expensive to develop, maintain, and deploy, these enclaves are silos that are often detrimental to information provision, i.e., the realization of shared situational awareness, collaboration, coordination, and decision making. Conversely, need-to-share has introduced additional risks into information management environments. An increasing number of participants are being authorized to access security enclaves. Once a participant is authorized to enter an enclave, they are provided access to a wide range of information elements. Conventional access control solutions do not typically provide sufficient fidelity and flexibility in the application of policy/rules. They do not apply policies/rules to the actual content of individual information elements or provide defense-in-depth, i.e., layering safeguards based on the value of key data elements (e.g., security and privacy tags) within the instances of the information element. Recent security incidents illustrate the limitations of conventional access control solutions and their inability to exert sufficient control over and protect critical information assets: As part of the response to the 9/11 attacks, the US determined that increased information sharing between departments and their infrastructure was necessary to prevent future terrorist activity. The perception of departments information stores as hardened silos was seen as a barrier to effective security response. As a result, a new culture of openness was in effect at the Sensitive Compartmented Information Facility (SCIF). In this environment, Bradley Manning was able to use unrestricted and uncontrolled access to information to disclose large amounts of sensitive data. 2 1 Charles E. Phillips, Jr. et al, SACMAT '02 Proceedings of the seventh ACM symposium on Access control models and technologies, Pages 87-96, Information Exchange Framework Reference Architecture, Initial Submission

25 Edward Snowden's role as a systems administrator provided easy access to classified National Security Agency documents sitting in a file-sharing location on the spy agency's intranet portal. As a contracted NSA systems administrator with top-secret Sensitive Compartmented Information (SCI) clearance, Snowden could access the intranet site and move especially sensitive documents to a more secure location without triggering security incident alarms. 3 SLt. Delisle has admitted to selling secret information to the Russians over a 4 ½-year period jeopardizing Canada s ability to protect itself, as well as its standing with key partner nations. Canadian officials concede they do not know precisely what SLt. Delisle gave the Russians between 2007 and They re drawing inferences from material they intercepted just before arresting him. 4 While the two priorities sharing and safeguarding are often seen as mutually exclusive, in reality they are mutually reinforcing. Information systems that strengthen protections and the fidelity of controls for sensitive information help build trust within the user and stakeholder communities. This trust will provide data owners and custodians with the confidence to: Increase operational effectiveness Improve information sharing capability Increase information safeguarding capability Reduce operational costs Reduce management costs Reduce acquisition costs 1.4 IEF Approach The IEF defines a framework for delivering defense-in-depth solutions that address a broad range of information sharing and safeguarding requirements. The framework will include specifications defining the requirements for: A reference Architecture (this document); Formal Information Sharing and Safeguarding Policy Vocabularies; Data Centric Policy Decision and Enforcement Points; Policy Administrations Points; and Policy Development, Management and Dissemination Tools. These specifications will enable the development of information management and security measures targeting the responsible sharing of information in accordance with policy and commensurate with the sensitivity of the data being accessed or shared. The IEF Reference Architecture (this document) defines an integration layer for off-the-shelf products and services that will enable the enforcement of ISS policy at the data level rather than the networks, platforms systems and applications Information Exchange Framework Reference Architecture, Initial Submission 5

26 1.5 IEF Delivered Capabilities The IEF seeks to deliver a policy-driven data centric solution using a set of layered defense-in-depth safeguards to achieve responsible information sharing solutions. Where available, the IEF will align and integrate existing open standards and specifications for data centric practices, tools, technologies, and protocols. Where necessary, the IEF Working Group will promote the development of specifications that fill gaps in the IEF standards portfolio. The IEF Reference Architecture will provide specifications for policy driven, data-centric ISS solutions delivered as a set of shared infrastructure, integrating off-the-shelf products and services, that can rapidly tailored to the planning and spontaneous operational needs. The IEF separates the development and maintenance of policy/rules from the specific systems and services (i.e., policy decision and enforcement points) that enforce them. This separation will enable users to: Evolve ISS policy/rules independent of services and infrastructure; Specify and acquire ISS services and infrastructure without specifying the operational use cases; Re-host ISS policies to multiple ISS services and infrastructures; and Evolve and instantiate ISS policy in response to changing business and operational requirements. The capabilities provided users with the flexibility and agility to rapidly extend or enhance policy (/policy models) and accommodate: Changing mandates, roles and responsibilities; Changing mission and operational context; Evolving threats and risks; Evolving institutional policy; and Advancements in technology. By providing a model driven approach to policy development that facilitates the integration of ISS policy into segment, operational and enterprise architectures. The integration of ISS policy model into architecture frameworks and tools will: Align ISS policy models related architectural artifacts (operational topologies and deployments, platforms, systems, interfaces and data and information elements). Develop traceability to policy instruments (e.g., legislation, regulation, service Level Agreements (SLS), Memorandum of Understanding (MoU) and Operating Procedures); Provide information needed to effectively and efficiently validate, verify, and certify operational configurations and deployments. The integration of ISS policy development into architecture will promote retention of institutional knowledge and an overall reduction in overall life-cycle costs. 6 Information Exchange Framework Reference Architecture, Initial Submission

27 1.6 IEF Objectives The IEF will provide the ability and capacity for people, processes, and systems to work together efficiently and ensure that the right information is available to the right people or system at the right time. This will require solutions that: Policy-driven Data-centric Achieve Dynamic Interoperability Flexibility, Adaptability, and Agility Architecture Alignment Integration Overlay Defense-in-Depth Self-Defending Vendor Agnostic Reuse of Existing Standards and Specifications Provide a fully traceable path from information sharing an d safeguarding policy to the rules executed by decision and enforcement points in the information systems and services the execute them IEF policy decision and enforcement points operate on the data for each instance of the information and data elements being assessed for release. Solution have the ability to operate on data over time. As the context of the operation and the states of its associated systems change, ensure that systems have the ability to integrate assumptions and constraints affecting their information interchanges. Enable the rapid re-use and repurposing of policy and data patterns for both planned and spontaneous operations; and enable run-time changes to active policy environments. The IEF will define strategies that enable users to integrate IEF elements into business and system architecture views. Provide strategies, techniques and tools that enable users to translate institutional policy (policy instruments) into human consumable and machine-readable rules; the former enabling a manual process and the latter enabling automation of policy governing the sharing and safeguarding of information assets. Operate as an overlay to existing systems and infrastructure. Integrate elements manner that to safeguard individual data and information assets based on their sensitivities. Employ internal elements to safeguard its own data and information elements (e.g., policies, instructions and logs). Define specification that vendors can use to developed off-theshelf integration layers of complete ISS solutions. Integrate existing and evolving specifications and standards to define and implement of IEF component. The Platform Specific Models will represent the assignment of specific standards and specifications to the components (e.g., DDS for data Information Exchange Framework Reference Architecture, Initial Submission 7

28 1.7 IEF RA Design Principles The Key principles of the IEF and its support Environment. dissemination) and interfaces (e.g., XAMCL for exchange of policies). Support Environment (e.g., Policy Authoring Environment): Define strategies, practices and tools that: Enables rapid development and deployment of ISS Policy. Align and integrate ISS policy into an organizations segment, mission and enterprise architectures. Enable the automated translation of policy models into human consumable and machinereadable rules. Provide users with the data needed for: o Governance; o o o o Modeling and simulation; Auditing (e.g., security and privacy): Design, Real-time Monitoring, and Forensic; Retention of Institutional Memory; and Lower life-cycle costs Policy Environment: Define Policy Vocabularies that: Offer multiple Policy Language Implementations (e.g., XACML, SAML, and RulesML); Offer Modeling Language Profiles (e.g., UML); Are Domain Vocabulary agnostic; Enable multiple marking (tags, labels or metadata) schemes; and Enable automated translation between policy models, languages and executable rules; Enable the speciation of policies/rules that are enforced at the data level Policy ownership/control rests with the owner/steward of the data asset. IEF Services: Define Services that: Separate the definition of policies (/rules/instructions) from the services employed to enforce them, which will in turn provide users: o With greater control over their data and policy environment; o With the ability to re-host ISS policies to multiple vendor solutions; o With the ability evolve and align policies for specific operational/mission requirements; and o With the ability host multiple policy and data environments on a sheared infrastructure. Ingest policies at run-time without the requirements to disable running services. 8 Information Exchange Framework Reference Architecture, Initial Submission

29 That enable users to manage and administer Policies in running services. Enforcement of ISS policies/rules at the data level, enabling: o Defence-in-Depth strategies rather than perimeter protection ISS Solutions; o Greater fidelity in privacy and security decisions; o Data level redaction and the selective sharing of information using common message structures (e.g., NIEM). General: Reuse existing standards where and whenever possible Vendor neutral specifications, yielding: o Option to reuse existing infrastructure o Multiple heterogeneous implementation options o Leverage existing open-standards. Information Exchange Framework Reference Architecture, Initial Submission 9

30 2 Compliance 2.1 Introduction The Information Exchange Reference Architecture defines five (5) separate information sharing and safeguarding service patterns. Each pattern forms a separate compliance point. An implementer may select to implement one of more of the service patterns. 2.2 Selecting a Compliance Point The IEPPV is a vocabulary specification. It defines a set of concepts that combine to express the rules governing packaging, processing and dissemination of information. The compliance points allow the implementers to select the level of message complexity they need to support. CP1 through CP2c build on the concepts defined in the previous levels. CP-3 provides a set of concepts that enable users to assign information elements to specific information dissemination services. 2.3 Compliance Points To be express compliance to this specification, an implementer must implement all mandatory features of: 1. Policy Administration Point (Clause 9); 2. Policy Decision Point (Clause 10); 3. Common Elements (Clause xx) and 4. At least on following Policy Enforcement Points: a) File Share; b) Electronic Mail ( ); c) Instant Messaging (IM); d) Messaging Middleware; and e) Web Services File Sharing Instant Messaging Messaging Middleware Web Services 10 Information Exchange Framework Reference Architecture, Initial Submission

31 3 Normative References XACML IEPPV Information Exchange Framework Reference Architecture, Initial Submission 11

32 4 Terms and s The focus of this specification is the development of a formal. 12 Information Exchange Framework Reference Architecture, Initial Submission

33 5 Symbols/Acronyms 5.1 Symbols There are no additional symbols defined for this specification. All symbols used in this specification are based on standard UML. Information Exchange Framework Reference Architecture, Initial Submission 13

34 6 Additional Information 6.1 Intended Audience This specification will be of interest to end users, analysts and integrators who will use this profile to define information exchange specifications and tool vendors interested in developing tools support for the development and sustainment of information interoperability solutions. End users, auditors and developers will have a clearer understanding of the semantic and business rules (sharing and safeguarding) for information exchange. 6.2 Acknowledgements The following organizations are the direct submitters to this specification: Advanced System Management Group (ASMG) Ltd. Contributors (/Contributing Entities) The following organization contributed to the development of the specification: Centre for Security Science (CSS) / Defence Research and Development Canada (DRDC) Cord3 The following organizations identified support for the concepts and content included in this specification. 1. MIAB Systems Ltd; 2. Lecomte Systems; 3. Advanced System Management Group (ASMG) Ltd. 4. IJIS Institute; and Additional Materials N/A 6.4 Reference Architecture Introduction to IEF RA Philosophy The IEF RS 14 Information Exchange Framework Reference Architecture, Initial Submission

35 6.5 Modeling Conventions The IEF is modeled using standard UML and UML Profiles. Information Exchange Framework Reference Architecture, Initial Submission 15

36 7 IEF Reference Architecture This defines the Information Exchange Framework Reference Architecture. 7.1 IEF Overview As illustrated, the IEF integrate the sharing of information with the parallel need to safeguard sensitive information. In reality these to concepts cannot be separated - they combine to enable authorized users to responsibly access and sharing information. Treating sharing (/accessing) and safeguarding as independent capabilities often leads to: The release of sensitive information to unauthorized recipients; and The denial of access to information needed to inform or trigger an operational decision. Either event can have severe implications on an organization's or community's ability to successful completion its mission or achieve their desired outcomes. Figure 1 -Concept Use Case Diagram 16 Information Exchange Framework Reference Architecture, Initial Submission

37 Table 1 - Concept Use Case Diagram Descriptions Redact Content Log Transaction Remove information or data elements from an information exchange in order to reduce the sensitivity of the overall exchange and make the remainder of the exchange accessible to with those with lesser access rights. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Enforce Information Sharing Policy Receive Releasable Information Provide quality information to authorized recipients. The goal of the IEF is to maximize the provision of quality information (timely, accurate, relevant, digestible, concise, and trusted) to authorized participants, while simultaneously protecting sensitive information from unauthorized access/release and tampering. Intercept any receipt of information and verify that the recipient has the policy rights to receive the information element(s). Issue Alerts and Warnings Based on policy, if the user is attempting to perform an activity that is not authorized, issue a warning or alert to responsible individuals. The IEF uses internal services to disseminate the warnings and alerts. The thresholds of activity calling for a warning or alert is controlled by policy. Enforce Information Safeguarding Policy Mark Information Element Provide a layered defense-in-depth environment that protects data and information holdings using techniques such as: data and information element redaction / filtering; tagging and labeling; transformation; cryptography; and logging (for the purpose of real-time and forensic auditing). Prompt the user to provide the appropriate markings (e.g., security, privacy, and caveat restrictions) for the file and then bind them to the information element. *Note: The marking and values for the markings are specified by the user in conformance with the organizations' data marking (labeling/tagging) policy and standards. Authorize Action Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication channel), - action (READ/WRITE/Update/Delete/exchange), and - contextual environment (time of day, location, duty officer shift, threat, risk,...) Information Exchange Framework Reference Architecture, Initial Submission 17

38 Table 1 - Concept Use Case Diagram Descriptions Administer Active Policies When an authorized user interacts with active policy sets and: - Load additional or new policies; - Activate policies in the environment; - Deactivate policies in the environment; - Configure policies on one or more operational nodes; and - Save/Archive policies to a persistent data store. The IEF employs the use of Policy Administration Points (PAP) in the environment that can interface with selected local or remote Security Policy Repositories. Theses PAPs can be deployed as local or remote services across the network architecture defined by the user. The objective is for the PAD to disseminate and administer ISS policy. Request Information Element Intercepts any request for information and assure the requester is authorized to make the specific request. Encrypt Information Element Send Releasable Information Transform the information content of an information element into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each information element is encrypted using its own unique symmetric key. When a user attempts to send information it is intercepted and assessed to verify that the user is authorized to send the information and each recipient is authorized to receive and access the information content. 18 Information Exchange Framework Reference Architecture, Initial Submission

39 8 External Actors The external actors to the IEF RA include both Users (e.g., administrators, and participants to an information exchange), and infrastructure elements (e.g., Identity Management, Encryption services, middleware and exchange applications) provisioned by the user. These actors include: Table 2 External Actors Active PDP Policy Store Storage location where the ISS services access their current and active set of policies in a form that enables immediate action (enforcement).it is a secure information store that persists the information sharing and safeguarding policies that are enforced by IEF services. Administrator An authorized user responsible for managing the IEF and other system, network and security services. This user is responsible for the topology, configuration of Services and users and the disposition of ISS policies over the IEF PDPs and PEPs. The PAP is the primary application for the administration of IEF services. Alerting and Warning Services Local (user specified) services that provide warnings and alerts to selected users in the environment. This service notifies users of issues/incidents related to the suspicious operations (/transactions) within the environment protected by the IEF. Application A set of programs, procedures, routines and functionalities associated storing, and processing data and for delivering information, and digital products. Audit Services Local (user specified) services that provide measurable assessments of a systems, applications or services enforcement of information sharing and safeguarding policy (/business rules). These may include security, privacy, performance (or quality of service), or other assessments, e.g., - Policy Consistency Checking (i.e., identify policy conflicts, e.g., contradictory rules in a policy set and multiple policy sets that conflict [Army vs Navy release conflicting rules for some type of info]); and - Policy Change Checking (i.e., identify implications of policy changes before implementation, e.g., identify changes that will occur when the new policy replaces the current policy). This capability may be required to verify policy sets being built before there is a willingness to switch policy sets. Might use meta-policies to filter, group, and summarize changes. Post mission analysis that seeks to improve situational awareness, collaboration, and/or decision support. - Audit services may provide or enable: - Real-time Incident and Event Monitoring; and - Forensic audit. Information Exchange Framework Reference Architecture, Initial Submission 19

40 Table 2 External Actors Authentication Service Component of Identity Management that verifies the identity of a user logging into a network, system or service. Passwords, digital certificates, smart cards and biometrics can be used to prove the identity of the client to the network. Passwords and digital certificates can also be used to identify the network to the client. The IEF is specified in a manner that employs existing user infrastructure. Authorization Service An essential part of the IEF safeguarding infrastructure that determines whether a user has the access rights (is authorized) to access a particular resource: in this case data/information resources. Authorization is performed by verifying that the requesting user s attributes authorize access to and use of, the systems, services, devices, directories and information elements being requested or provisions. The IEF authorizes both the provisioning and receiving users to each exchange of information. Do the recipients have the policy rights to receive the information and does the sender have the policy rights to provision the information given the marking on the information elements. Authorization is central to the delivery of the defense in depth strategies being applied in the IEF. Moreover, authorization services provides complex access controls based on attributes, markings, policies and context, including mission/operation, threat, risk, user attributes, user roles / groups, actions taken, access channels, location, time, resources requested, external data and business rules. Authorized Receiver A user (individual, system, service or application) that is authorized to subscribe to or receive information with the specific sensitivities and restrictions. Authorized Sender A user (individual, system, service or application) that is authorized to publish or send information with the specific sensitivities and/or restrictions. Broadcast Service Broadcast communications allow a message to be sent to all users (endpoints) on the network or security domain. Like publish subscribe, in ab broadcast mode the sender (publisher) of messages does not specify the individual recipients (subscribers) of any message. In IEF context, a broadcast would override many of the safeguards offered to the information elements. The user must ensure that the content of the message is accessible to all potential recipients on the network. Community Self-organizing network of people with common agenda, cause, or interest, who collaborate by sharing ideas, information and other resources. 20 Information Exchange Framework Reference Architecture, Initial Submission

41 Table 2 External Actors Credential Management Services. Local (user specified) service employed in host environment to manage the identifier(s) and credentials used to validate those identities of users, applications, and devices accessing the environment. The user community is left to specify the authentication methods and credential used within their environments; e.g.: username/passwords, digital certificates, tokens and smart cards, Hardware tokens and credit-card-sized smart cards. Credentials Registry Local (User Specified) protected information store that captures, maintains and provisions objects that are verified when presented to the verifier in an authentication transaction. Credentials may be bound in some way to the individual, system or device to whom they were issued, or they may be bearer credentials. The former are necessary for identification, while the latter may be acceptable for some forms of authorization. Electronic credentials can be digital documents used in authentication and access control that bind an identity or an attribute to a claimant's token or some other property, such as a current network address. Credentials are verified when presented to the verifier in an authentication transaction. Anonymous credentials are used to evaluate an attribute when authentication need not be associated with a known personal identity. Cryptographic Services Component of the IEF security infrastructure. These services are used to provide encryption/decryption of data and information elements managed in an IEF environment. When data and information elements become subject to IEF protection, they are individually encrypted so protected elements cannot be subsequently disclosed except through IEF access controls. Encrypted information elements carry a "key Token" provisioned by the Key Escrow service. This token is used by authorized services to request the decryption key from the Key Management Service. The means by which individual data and information element types enter the IEF protection model depends on the nature of the data itself, E.g.: - Files being copied to an IEF protected file share are encrypted prior to storage; - messages (and attachments) sent through an IEF protected mail server are encrypted for storage at the mail server; - Instant messages are stored in encrypted form while hosted at an IEF protected IM server; and - Structure Messages (e.g., NIEM message) are encrypted during assembly and/or packaging and stored in an encrypted form while awaiting release to an IEF protected dissemination/distribution service. Similarly, when data assets (files, s, instant messages and structured messages) are received by an authorized user, the IEF decrypts the assets for the user. In all cases, the IEF interfaces with a local cryptographic services provider where these operations are performed. Cryptographic Transformation Service Local (User specified) cryptographic application(s) or appliance(s) that perform the actual encryption/decryption functions. Information Exchange Framework Reference Architecture, Initial Submission 21

42 Table 2 External Actors Data Exchange Service User specified/provided services that store and/or exchange information assets securely across the Internet or intranet. Decryption Service Local (User specified) services that decipher encrypted messages and files for users that are authorized to access the unique cryptographic key for the file or message. Client User specified/provided off-the-shelf -client application. Encryption Service Local (User specified) processes for encoding messages or information in such a way that only authorized parties can read it. Encryption does not of itself prevent interception, but denies the message content to the interceptor. File Service Client Local (user specified) service that enable authorized users access to selected information elements stored on a local or remote (networked) files system. *Note: This client must enable users to meta-tag files with privacy, security and operational markings. Forensic Audit Local (User Specified) practices and services that execute a manual or systematic assessment of the policy enforcement services and policies being enforced. Identity Management Service Component of the IEF security infrastructure that provides the ability to: manage a directory of the personal data the system uses to define individual users; add, modify, and delete user data (life-cycle management); regulate user access (enforcement of security policies and access privileges (attributes)); and an audit and report on user activity. The identity management services may also include: - Authentication: Verification that an entity (user, application or device) is who/what it claims to be using a User-name/password, public key infrastructure (PKI) certificate or biometric information (fingerprint, retinal scan), or distinctive behavior such as a gesture pattern on a touchscreen. - - Roles: groups of operations that are granted to a particular job or job function. These services may also be provided as separate services. For the purposes of the IEF RA, we will only expose those elements that are explicitly required to deliver IEF services: - Credential Management: the Management of data/attributes that enable the authentication if an entity and permit access to environmental resources. - De-provisioning: process of removing an identity from an ID repository and terminating access privileges. - Digital identity Management: Manages the description of the users and their access privileges. - Entitlement Management: manages the set of attributes that specify the access 22 Information Exchange Framework Reference Architecture, Initial Submission

43 Table 2 External Actors rights and privileges of an authenticated security principal. - Identity synchronization: Process for ensuring that multiple identity stores contain consistent data for a given digital ID. - Password reset: Process that allows users to re-establish their own passwords. - Provisioning: The process of creating identities, defining their access privileges and adding them to an ID repository. Part of the Identity Management System, this Local (user specified) protected information store captures, maintains and provisions the identity of authorized users of IEF services. IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. Together these two infrastructures comprise the Secure Messaging Service. Individual A single user being distinct from an identified group, community, organization and the systems, application and services they might employ to access information. Inference Service Local (User Specified) Rules or Inference Service that is part of the Policy Decision Point(PDP) and that executes decision logic to determine if a user has the policy rights to execute the requested operation or access the requested data. General : Rules or Inference Services; and used execute the variety and complexity of decision logic that is used by operational systems within an organization or enterprise. This logic, also referred to as business rules, includes policies, requirements, and conditional statements that are used to determine the tactical actions that take place in applications and systems. Information Exchange Service Local (User Specified) services that enable the exchange of data and information elements. Information Store Local (User Specified) service/system that collects, stores and retrieves data and information elements. A data store is a repository for persistently storing collections of information elements. Instant Messaging Client Local (User Specified) service that provides access to one or more technologies for text-based communication between two or more participants over the Internet or Information Exchange Framework Reference Architecture, Initial Submission 23

44 Table 2 External Actors other types of networks. Instant messaging systems tend to facilitate connections between specified known users (often using a contact list). Depending on the instant messaging protocol being used, the technical architecture can be peer-topeer (direct point-to-point transmission) or client-server (a central server retransmits messages from the sender to the receiver). Local (user specified) service that provide an authorized user with access to realtime instant messaging, known as chat, text messaging and instant messaging (IM). Instant Messaging Server Local (User Specified) communication technologies used for text-based communication between two or more participants over the Internet or other types of networks. Key Escrow Service Local (User Specified) service that is entrusted with the storage and retrieval of cryptographic keys. Under normal operation, keys are released to an IEF decryption service if the user of that service has the policy rights to access the information. The decryption keys are held in escrow so that, under policy prescribed circumstances, an authorized IEF service can access the key to decrypt the specific data or information element. When a cryptographic key is placed in escrow,the escrow service returns a key token.using the token the specific key for decrypting an information asset can be retrieved. The key token is simply a lookup index value; it is not possible to determine the stored key from the key token. Key Generation Service Local (User Specified) service(s) for generating the symmetric-keys used to encrypt data and information elements placed under the protection of the IEF. Key Management Service A component of the IEF security infrastructure that provides the ability to perform the following functions: Key Generation: creates a new symmetric key from the current entropic source based on a request from an external service (input attributes: none, and Return: A symmetric key); Key Storage: stores a supplied key at the local escrow (Input attributes: symmetric key and Returns: key token. Key Retrieval: This operation retrieves a specific key from the escrow. A key token A symmetric key Generate and Store: This operation created a new symmetric key and stores the key in the escrow. Essentially, this is a combination of the Key Generation and Key Storage operations. None A symmetric key and the associated key token 24 Information Exchange Framework Reference Architecture, Initial Submission

45 Table 2 External Actors Local Policy Store A policy archive that is local to the PDP. This policy store is the primary location for the PAP to access or archive inactive policies. The PAP uses this store to load policies into the active policy store Local Security Services The IEF is a vendor/technology agnostic framework that overlays existing platforms, infrastructures and networks. The IEF defined decision and enforcement points are specified to inter-operate with Local (user defined) Security Services through set of internal service interfaces that bridge to external security services (e.g., Identity Management Services, Authorization Services,Logging Service and Cryptographic Services). The IEF employs these services to deliver policy driven data centric information sharing and safeguarding services; providing defense in depth to the information and data element level. Mail Server Local (user specified) service that provide an authorized user with access to services. Often referred to as simply "mail server", an server is a system within the environment that operates as a virtual post office (sent, receive and store ). A mail server usually consists of: - A storage area where is stored for local users, - A set of user definable rules which determine how a message will be handled and routed, - A database of user accounts that the mail server recognizes and will deal with locally, and communication modules that handle the transfer of messages to and from other mail servers. Multi-cast Service Multi-cast communications allows a message to be sent to selected users (endpoints) on a network or security domain. Multicast (one-to-many or many-tomany distribution) is where information is addressed to a group of users simultaneously. Open File Share Local file store that is not protected by the IEF. It is assumed that it s files are unmarked and unencrypted. * note: integrating the IEF with other file protections schemes is a future requirement. Open Information Store Local (user specified) information store in which data and information elements are unprotected and unencrypted. Organization An administrative and functional structure defining a hierarchical arrangement of lines of authority, communications, rights and duties of an organization. Organizational structure determines how the roles, power, rights and Information Exchange Framework Reference Architecture, Initial Submission 25

46 Table 2 External Actors responsibilities are assigned, controlled, and coordinated, and how information flows between the different levels of management. Other User Application Unspecified client application that may be secured via the IEF PAP IEF Policy Administration (/Management) Point. Uses in use case diagrams where the PAP is not the focus of the use case. PDP IEF Policy Decision Point. Uses in use case diagrams where the PDP is not the focus of the use case. Policy Authoring Environment The definition of this environment is outside the scope of this specification. The Policy Authoring Environment (PAE) will enable used to manage the life-cycle of policies or policy sets. The environment may support a wide range of functionality, including: policy modeling (e.g., IEPPV), MDA transformation and serialization of polices, configuration management primitives such as check-out, check-in, compare, branch, merge, restore superseded versions, etc. Policy Development Environment Practices, tools, and technology (e.g., Dissemination services) use to manage deployment of policies throughout their life-cycle. Policy Management Environment Practices, tools, and technology (e.g., Dissemination services) use to manage deployment of policies to administration and decision points. Policy Store Local (User specified) protected information store(/database) for IEF policy; Sets of rules that direct the decisions and actions of IEF decision and enforcement points. Policy Testing and Analysis Environment The definition of this environment is outside the scope of this specification. The Policy Testing and Analysis Environment is part of the life cycle management of a user policies. The PTAE enables user to test and analyze policies, sets of policies, or deployments of policies by automated tools. The PTAE may include both pre and post operation testing and analysis in the areas of: - Performance, - Threat/Risk; - Forensic Audit; - Security Audit; - Modeling and Simulation; and - What-If. 26 Information Exchange Framework Reference Architecture, Initial Submission

47 Table 2 External Actors Protected File Share Local (user specified) service responsible for the storage and management of data files so that users can access the files. This file server allows users to share information over a network without having to physically transfer files electronically versus manual transfers files using memory sticks or some other external storage device. Protected Information Store Local (user specified) information store in which all data and information elements are encrypted. Publish and Subscribe Service Publish subscribe is a messaging pattern in which senders (publisher) of messages do not specifically specify the individual recipients (subscribers) of any message. Published messages are characterized into topics, without specific knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in one or more topics, and only receive all messages on that topic, without knowledge of what, if any, publishers there are. Within an IEF environment, each of these topics would be assigned attributes that control the breadth, and sensitivity of the information published to a topic and access control on the ability of individual users to have knowledge of and subscribe to topics. Request Response Service Request response, also known as request-reply, is a data exchange pattern in which a user (requester) sends a request message to a replier/responder that receives and processes the request, ultimately returning the data/information requested in response. This messaging pattern allows two users, systems, applications, and services to have a two-way conversation with one another over a communication or network channel. Role A prescribed or expected behavior associated with a particular position or status in a group or organization. Each role has an expected set of connected behaviours, rights, obligations, and norms as conceptualized by people in an operational situation/context. Roles typically depict: - divisions of labor into heterogeneous specialized position; - a set of permitted behaviors; - individuals or actors; - a set of rights and obligations. Rules management Local (User Specified) Rules Management services that are used to define, deploy, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organization or enterprise. This logic, also referred to as business rules, includes policies, requirements, and conditional statements that are used to determine the tactical actions that take place in applications and systems. Information Exchange Framework Reference Architecture, Initial Submission 27

48 Table 2 External Actors Secure Message Bus A data exchange service that enables IEF services to communicate with each other. Service A set of related software programs, procedures, routines, and functionalities that can be reused for different purposes, together with the policies that should control its usage. System An integrated set of technologies for collecting, storing, and processing data and for delivering information, and digital products. Tamper Resistant Logging Service A component of the IEF security infrastructure that provides a tamper-resistant record of IEF transactions (e.g., policy decision activities) in a manner that enables both real-time Security Incident and Event Monitoring and longer-term forensic activities. Text Messaging Client Local (User Defined) text messaging client that enables the binding of labels (properties) to individual text messages and their attachments. User A user that has the policy rights and attributes that permit or deny access to specific services and/or resources (data/information). An authorized user may be a provider or a recipient of an information element. Authorized users may include: - Individuals; - Organizations; - Role; - Community or Topic; - Systems; - applications; or - service. Each member of the identified categories will have credentials, attributes and policy rights to access data/information holding designated markings. User & Attribute Management Service An integral service to the IEF through which user's identity attributes are assigned and managed. The service must provide a protected policy-based data exchange. That is, the interface that is used to maintain user security attributes must enforce the domain s security policy. User & Attribute Registry A protected data store used as a repository for User security credentials. The contents of which are maintained by the User and Attribute Management Service and queried through the course of user action authorization. 28 Information Exchange Framework Reference Architecture, Initial Submission

49 Table 2 External Actors User Application A user acquired or developed application that employs IEF interfaces and services. Web Client Local (user specified) services that enable authorized users to publish information to and access information from the Web. Web Portal A web portal is most often one specially designed Web page which brings information together from diverse sources in a uniform way. Usually, each information source gets its dedicated area on the page for displaying information (a portlet); often, the user can configure which ones to display. Web Server Local (user specified) hardware and software that delivers web content that can be accessed through the Internet. The most common use of web servers is to host websites, but there are other uses such as middleware, data storage, portals, enterprise applications, FTP, or other web uses. Information Exchange Framework Reference Architecture, Initial Submission 29

50 9 Policy Administration Point The Policy Administration Point 5 is a single entity which is the source of policies for a given domain. The IEF defines a general architecture for a PAP, which identifies its core subcomponents, its functions, and its interfaces (e.g., protocols and content). 9.1 PAP in an Inter-Agency Environment A core design principle is the ownership/control of policies rests with the owner/steward of the data asset. This implies that: 1. Policies (rules /instructions / constraints) are developed, tested, administered and manages separate from the process, services and technologies used to enforce them; 2. Data owners/stewards have control over the release of data/information assets; and 3. Policies (executable, or actionable policies) reflect and are traceable the policy instruments adopted by the data owners / stewards. This further implies that the PAP, PDPs and PEPs are in the control of the data owner/steward and that it is likely. 9.2 PAP Description The following clauses provide the Use Case diagrams for the IEF Policy Administration Point services PAP Use Case Diagrams Administer Policy Environment Use Case Diagram 5 The Policy Administration Point descriptions and definitions were derived from those XACML definitions. ( 30 Information Exchange Framework Reference Architecture, Initial Submission

51 Figure 2 -Administer Policy Environment Use Case Diagram Table 3 - Administer Policy Environment Use Case Diagram Descriptions Configure Policies Administer Policy Environment On the instruction of an authorized PAP, set the configurable attributes of a policy or set of policies. Maintain Policy Schedules Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Maintain PDP Deployment Profiles Maintain a lost of active and inactive PDPd in the operational environment: - Identifier; - PDP ; - PDP Role(s); - Controlled PEPs; - Active Policy Set - Authorized Policy Sets Information Exchange Framework Reference Architecture, Initial Submission 31

52 Table 3 - Administer Policy Environment Use Case Diagram Descriptions Synchronize Policy Stores - Archived Policy Sets - PDP Status and Events (alerts/warnings) - Other Synchronized policy environments with other active PAPs in the environment. Policy Administration Use Case Diagram Provide the functions needed to centrally administer information sharing and safeguarding policies during operations. A PAP must be able to support multiple PDPs, with distinct sets of active policies. Policies (or policy sets) may be used used by different PDPs in the domain managed by the PAP. For redundancy or performance the a single domain may be services by one or more PAPs. The PAPs are responsible manage the deployment and activation of the policies on each of the PDPs within its operating environment. For time sensitive policies, the PAP should supply the PDPs with their active policies in advance of their validity time and switch to using them when they become effective and without any interruption in service. 32 Information Exchange Framework Reference Architecture, Initial Submission

53 Figure 3 -Policy Administration Use Case Diagram Table 4 - Policy Administration Use Case Diagram Descriptions Package Policies Administer Policy Environment Packaging individual or sets of policies for dissemination to one or more PDPs. Enable users to assemble policy sets for one or more PDPs that addresses operational needs based on a current or future context. Archive PDP Policies Log Transaction When requested by an authorized user, interface with one or more Policy Administration Points( PAPs) to store/archive and activate/configure a set of policies for one or more operational PDPs. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in Information Exchange Framework Reference Architecture, Initial Submission 33

54 Table 4 - Policy Administration Use Case Diagram Descriptions the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Receive PDP Policy Archive Receive Policies Validate & Verify Policies Decrypt Policies Administer Active Policies Receive a policy or set of policies from a PAP or Policy Management Environment. Policies are provided as an encrypted data file using the IEF's own information safeguarding services and policies to protect PDP policies in transit and when stored. Verify that a received set of policies was issued (disseminated) by an authorized source (e.g., Headquarters, organization, or Policy Management System) and validate that the policies conform to the operation of the PDP, e.g.: Which PEP(s) the PDP is supporting. Transform the content of a policy set back into its original form using the unique symmetric key retrieved from escrow. The exchange of policies utilizes the same exchange and cryptographic services as used to exchange and store other information elements shared and protected by IEF services. When an authorized user interacts with active policy sets and: - Load additional or new policies; - Activate policies in the environment; - Deactivate policies in the environment; - Configure policies on one or more operational nodes; and - Save/Archive policies to a persistent data store. The IEF employs the use of Policy Administration Points (PAP) in the environment that can interface with selected local or remote Security Policy Repositories. Theses PAPs can be deployed as local or remote services across the network architecture defined by the user. The objective is for the PAD to disseminate and administer ISS policy. Store Policies After policies are received and validated, they are placed in a local policy store. Disseminate Policies The PAP is responsible for distributing policies to PDPs. For this to occur the PAP requires access to Policies (& Policy Sets) and and the list of PDPs for the distribution. The PAP will need the ability to create, modify, activate, deactivate, override and deletes dissemination schedules. Encrypt Policies Transform an information policy or policy-set into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each policy or policy-set is encrypted using its own unique symmetric key. 34 Information Exchange Framework Reference Architecture, Initial Submission

55 Policy Management Use Case Diagram Provide the functions needed to manage information sharing and safeguarding policies during operations. Figure 4 -Policy Management Use Case Diagram Table 5 - Policy Management Use Case Diagram Descriptions Load Policies Archive PDP Policies Log Transaction On the instruction of an authorized PAP, or authorized PDP Service, load a policy or set of policies into active memory of the PDP. If authorized, the PDPs can load and activate policies from a local policy store. When requested by an authorized user, interface with one or more Policy Administration Points( PAPs) to store/archive and activate/configure a set of policies for one or more operational PDPs. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Information Exchange Framework Reference Architecture, Initial Submission 35

56 Table 5 - Policy Management Use Case Diagram Descriptions Receive Policies Display Policies Receive a policy or set of policies from a PAP or Policy Management Environment. Policies are provided as an encrypted data file using the IEF's own information safeguarding services and policies to protect PDP policies in transit and when stored. Display the policies contained within the Active Policy Store. DeactivatePolicies Store Policies Interface with one or more policy administration points and enable an authorized user to deactivate one or more policies on an operational PDP. After policies are received and validated, they are placed in a local policy store. Configure PDP Policies When an authorized user (e.g., IEF administrator) requests changes to the configuration of a policy or set of policies on one or more Secure Policy Repositories, the PAP interfaces with the repository(s) and instantiates the new policy configuration.the PAP responds with an acknowledgment of the instruction by creating a log record of the transaction. Manage Active Policies Activate PDP Policy When an authorized user (e.g., IEF administrator) requests the activation of a policy or set of policies on one or more PDPs, the PAP interfaces with the PDP(s) and activates the policy(ies) on the PDP(s) PAP Class Diagrams The following clauses provide the Class diagrams for the IEF Policy Administration Point services. Policy Administration Point Class Diagram A Web PEP implements the Policy Administration Point interface that allows a Security Officer to manipulate and disseminate the security policies that are used by the AS. If the PAP is a web interface, access to the service can be controlled through the use of the Web Session PEP. 36 Information Exchange Framework Reference Architecture, Initial Submission

57 Figure 1 -Policy Administration Point Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 6 Policy Administration Point Class Diagram Descriptions Web Session PEP The Web Session PEP (Web PEP) operates between the WebBrowser (Client) and the target WebService. The PEP intercepts each request, determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the information assets involved. The PEP intercepts each response from the target web service, determines if the user has the authorizations (policyrights) to receive the information given sensitivities of the information assets involved and the target store (e.g., device, directory, and application) of the received information. This PEP limits access to only those users that have an access right to use the web services protected by the PEP Web Session PEP Operations: Web Session PEP PolicyRepository The ISS Policy Repository is a secure information store that persists the information sharing and safeguarding policies that are enforced by IEF services. The Policy Administration Point (PAP) provides the services needed to manage and administer the policies applicable to the environment or operation. The policies are stored in a database that can be queried by a PDP to acquire the relevant policies to the evaluation of the user request. ISS policies are immediately enforced once they are loaded and activated within the Policy Repository. The IEF can be configured with a single ISS Policy Store accessible by all PDPs, or as a federated repository with local repositories for the PDPs to access. In the Information Exchange Framework Reference Architecture, Initial Submission 37

58 Table 6 Policy Administration Point Class Diagram Descriptions latter configuration, all federated policy repositories are securely updated in real time from the PAP. PolicyRepository Operations: PolicyRepository Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 7 Policy Administration Point Class Diagram - Interface Descriptions PolicyAdministrationPoint The PAP is a service that: 1. Provides a protected web-based interface for the security officer on the front end; and 2. Includes database connectivity that can be used to retrieve and set policies at the security policy repository. Through this interface, current policies are displayed, new policies can be created and existing policies can be deleted. Policies may be activated or deactivated. Parameters to the interface must include: UserId or User Caveat Action Resource Caveat Result Once the Security Policy Repository has been updated, any policies are immediately enforced. Since for every policy request the AS retrieves all applicable policies, the AS is always referencing the latest set of policies. PolicyAdministrationPoint Operations: EDIT_POLICY: Operation Parameters: DELETE_POLICY: Operation Parameters: NEW_POLICY: Operation Parameters: 38 Information Exchange Framework Reference Architecture, Initial Submission

59 Table 7 Policy Administration Point Class Diagram - Interface Descriptions ACTIVATE_POLICY: Operation Parameters: DEACTIVATE_POLICY: Operation Parameters: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 8 Policy Administration Point Class Diagram - Association Descriptions SQL Owner: IEF Service Elements Identity Attribute Administration Point Class Diagram The Identity Attribute Administration Point provides an interface that allows the Identity Administrator to set the security attributes for IEF users. To ensure the integrity of the architecture, the IAAP and the Identity Management Repository are not directly accessible to the user community. However, a user s security attributes must be available at the endpoint in order to support a marking solution (A marking solution must be able to display those attributes that are available to the user). As a result, attributes from the authoritative source (the Identity Management Repository) are pushed to the non-authoritative source (Active Directory) where they can be accessed from the DATA network. The attributes that are read from Active Directory do not require strong integrity since they are only used for marking; when policy decisions are performed on data assets, the security attributes from the authoritative source, the Identity Management Repository are used. Information Exchange Framework Reference Architecture, Initial Submission 39

60 Figure 1 -Identity Attribute Administration Point Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 9 Identity Attribute Administration Point Class Diagram Descriptions IdentityAttributeSynchroni zationutility IMS Service that synchronizes the information between the IdM repository and the local ISE Identity Management Store. The service periodically: Connects to the IdM Repository to retrieve identity and security attributes of the users. Connects to the Directory Services to update each user s identity and other security attributes. IdentityAttributeSynchronizationUtility Operations: IdentityAttributeSynchronizationUtility DirectoryService A special-purpose database designed to maintain data about users (individuals, roles, groups, computers, devices, organizational units and other object types) and resources (e.g., data and information elements, devices, applications and services). When queried it returns data about a named user or report, e.g., When sent the identity of a user, it returns the profile of the individual, which includes attributes, permissions (policy-rights) to access, action and release resources (e.g., data and information elements). When given a resource, it returns the profile for of the resource, which 40 Information Exchange Framework Reference Architecture, Initial Submission

61 Table 9 Identity Attribute Administration Point Class Diagram Descriptions includes its markings, and configuration. DirectoryService Operations: unnamed1: Operation Parameters: DirectoryService IdentityManagementRepos itory The Identity Management Repository is the IEF's authoritative source for users identity and security attributes, including nationality, clearance level and membership in communities of interest. IdentityManagementRepository Operations: IdentityManagementRepository Identity Management Service Identity Management Service is an essential part of the IEF safeguarding infrastructure. It provides a bridge to an external user provided Identity Management Solution. During a standard policy request the Authorization Service leverages the Identity Management Service to retrieve a user s security credentials. Identity Management Service Operations: Identity Management Service Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 10 Identity Attribute Administration Point Class Diagram - Interface Descriptions IdentityAttributeAdministr ationpoint The interface through which identity attributes are assigned to users must be itself, a protected policy-based data exchange. That is, the interface that is used to maintain user security attributes must enforce the domain s security policy. 1. Provides a web-based interface to the identity administrator on the front end; and 2. Includes connectivity that can be used to retrieve and set user security attributes at the security policy repository. Through this interface, current users security attributes are displayed, new users can be added and existing users can be deleted. The IAAP holds, within its configuration, the necessary account access to write and modify directory entries. Once the security attribute repository has been updated, users new security Information Exchange Framework Reference Architecture, Initial Submission 41

62 Table 10 Identity Attribute Administration Point Class Diagram - Interface Descriptions attributes are reflected in any subsequent policy checks. That is, when the AS queries the IAS for users security attributes, the latest security attributes are retrieved from the security attribute repository. Similarly to the PAP, the IAAP is a web interface and access to the service can be controlled through the use of a Web Services PEP. IdentityAttributeAdministrationPoint Operations: SYNCHRONIZE: 1) The utility connects to the Security Attribute Repository on the SECURITY network and retrieves the security attributes for each user. 2) The utility connects to Active Directory on the DATA network and updates each user s AD entry with their security attributes. Operation Parameters: DELETE_USER: Operation Parameters: UPDATE_USER_INFO: Operation Parameters: ADD_USER: Operation Parameters: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 11 Identity Attribute Administration Point Class Diagram - Association Descriptions synchronize Owner: IEF Service Elements 42 Information Exchange Framework Reference Architecture, Initial Submission

63 Table 11 Identity Attribute Administration Point Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Sequence Diagrams The following clauses provide the Sequence diagrams for the IEF Policy Administration Point services. Policy Administration Point Sequence Diagram interaction Policy Administration Point Sequence Diagram [ Policy Administration Point Sequence Diagram ] Figure 1 -Policy Administration Point Sequence Diagram Table 12 - Policy Administration Point Sequence Diagram - Message Descriptions Information Exchange Framework Reference Architecture, Initial Submission 43

64 10 Policy Decision Point The Policy Decision Point (PDP) integrates local (user specified) security services and provides the IEF with the ability to access to user (e.g., identity, credentials, and policy-rights(/attributes)), system (e.g., date, and time) and operational data needed to authorize a users actions or access, the release of information to a particular communication channel. The PDP defines both the integration services and interfaces needed to exchange information requited to the IEF authorization and access controls. Data interfaces will be defined to the following services: Security services, including: o Identity Management (IdM) services, o Authentication services, o Credential Management services, and o Attribute Management services; Decision management services, including: o Rules or Inference Services, and o Rules Management services; Tamper Resistant Logging Services; and Alerting and Warning Services Use Cases The following clauses provide the Use Case diagrams for the IEF Policy Decision Point services Authorize Action Use Case Diagram As illustrated the PDP integrates several user specified services that combine to enable the IEF to determine whether or not a specified user has the policy rights to initiates an action involving a specified data or information element. 44 Information Exchange Framework Reference Architecture, Initial Submission

65 Figure 5 -Authorize Action Use Case Diagram Table 13 - Authorize Action Use Case Diagram Descriptions Authorize Action Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication channel), - action (READ/WRITE/Update/Delete/exchange), and - contextual environment (time of day, location, duty officer shift, threat, risk,...) Communicate with Local Security Infrastructure Messaging infrastructure that enables IEF services to securely communicate among themselves and with other user specified services. PDP Administration Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 45

66 Figure 6 -PDP Administration Use Case Diagram Table 14 - PDP Administration Use Case Diagram Descriptions Receive Policies Validate & Verify Policies Decrypt Policies Receive a policy or set of policies from a PAP or Policy Management Environment. Policies are provided as an encrypted data file using the IEF's own information safeguarding services and policies to protect PDP policies in transit and when stored. Verify that a received set of policies was issued (disseminated) by an authorized source (e.g., Headquarters, organization, or Policy Management System) and validate that the policies conform to the operation of the PDP, e.g.: Which PEP(s) the PDP is supporting. Transform the content of a policy set back into its original form using the unique symmetric key retrieved from escrow. The exchange of policies utilizes the same exchange and cryptographic services as used to exchange and store other information elements shared and protected by IEF services. 46 Information Exchange Framework Reference Architecture, Initial Submission

67 Table 14 - PDP Administration Use Case Diagram Descriptions Archive Policies When requested by an authorized PAP place active policies in a collection of historical policy sets. Store Policies After policies are received and validated, they are placed in a local policy store. Activate Policy On the instruction of an authorized PAP, activate (make operational) a policy or set of policies into active memory of the PDP. If the policy is not loaded in active memory, load the policy and then activate it. Configure Policies Log Transaction On the instruction of an authorized PAP, set the configurable attributes of a policy or set of policies. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Administer Local Policies Issue Alerts and Warnings Based on policy, if the user is attempting to perform an activity that is not authorized, issue a warning or alert to responsible individuals. The IEF uses internal services to disseminate the warnings and alerts. The thresholds of activity calling for a warning or alert is controlled by policy. Load Policies Deactivate Policy On the instruction of an authorized PAP, or authorized PDP Service, load a policy or set of policies into active memory of the PDP. If authorized, the PDPs can load and activate policies from a local policy store. On the instruction of an authorized PAP, deactivate a policy or set of policies in the active memory of a PDP PDP Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 47

68 Figure 7 - PDP Use Case Diagram Table PDP Use Case Diagram Descriptions Authorize Recipient Verify that each recipient is individually authorized to receive and access the and its attachments. If the recipient s rights are verified, grant access to the user and deliver the . The recipient is verified at both release and receipt of the . If the recipient does not have the policy rights to access the or any of its attachment(s), the is returned to the sender so they have the opportunity to adjust the so that some or all the elements are releasable to the recipient. Authorize CC Recipient Authorize Action Verify that a Copied recipient is authorized to receive and access the and all attachments. If the user's rights are verified, grant access to the user and release the . The recipient is verified at both at release and receipt of the . This verification is repeated for each copied recipient. Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication channel), - action (READ/WRITE/Update/Delete/exchange), and - contextual environment (time of day, location, duty officer shift, threat, risk,...) 48 Information Exchange Framework Reference Architecture, Initial Submission

69 Table PDP Use Case Diagram Descriptions Authorize User to Receive Verify that the recipient has the policy rights to access the content of the . Authorize Sender Verify that the user has the policy rights to send an and attachments with the specific markings. Administer Local Policies Authorize TO Recipient Authorize BCC Recipient Verify that a primary recipient is authorized to receive and access the and all attachments. If the user's rights are verified, grant access to the user and release the . The recipient is verified at both release and receipt of the . This verification is repeated for each primary recipient. Verify that a blind-copied recipient is authorized to receive and access the and all attachments. If the user's rights are verified, grant access to the user and release the . The recipient is verified at both release and receipt of the . This verification is repeated for each blind-copied recipient File PDP Use Case Diagram The following figure illustrate the alignment of use cases that are involved in the verification of a user to perform the file action requested. Information Exchange Framework Reference Architecture, Initial Submission 49

70 Figure 8 -File PDP Use Case Diagram Table 16 - File PDP Use Case Diagram Descriptions Access Source Directory Attributes Access the markings for the directory containing the files being accessed. Access Target Device Attributes Access the markings for the target (copy, move, store, archive functions) device for the files. Used to determine if the user has the policy rights to place a file with those marking on the selected devices. Authorize File Action Authorize Action Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication 50 Information Exchange Framework Reference Architecture, Initial Submission

71 Table 16 - File PDP Use Case Diagram Descriptions channel), - action (READ/WRITE/Update/Delete/exchange), and - contextual environment (time of day, location, duty officer shift, threat, risk,...) Access Target Directory Attributes Access the markings for the target (copy, move, store, archive functions) directory for the files. Used to determine if the user has the policy rights to place a file with those marking in the selected directory Administer Local Policies Access File Markings Access the markings for the files being accessed. Access Source Device Attributes Access the markings for the device containing the files being accessed IM PDP Use Case Diagram Figure 9 -IM PDP Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 51

72 Table 17 - IM PDP Use Case Diagram Descriptions Administer Local Policies Authorize User to Join Chat room Verify the Users policy rights to join the chat room. Authorize User to Create Chat Room When a user requests the creation of a chat room, intercept the request and verify the Users policy rights to create the chat room. Authorize Action Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication channel), - action (READ/WRITE/Update/Delete/exchange), and - contextual environment (time of day, location, duty officer shift, threat, risk,...) Authorize IM Recipient Verify that the user has the policy rights to access the IM or chat room and receive the instant messages. Verify that a user is authorized to receive and access the specific information element via IM services. If the user's rights are verified, grant access to the user and release the information element. The recipient is verified at both release and receipt of the information. Note: Authorization is performed once for messages that have standard markings for the chat room; the users policy right to join the room provides policy rights to this information. Each user (participant) is authorized independently, for each specially marked message Authorize IM Sender Verify that the user has the policy rights to access the IM or chat room and send the instant messages. Verify that the user has the policy rights to release or publish information bound with the specific markings via instant messaging through the specified chat-room. 52 Information Exchange Framework Reference Architecture, Initial Submission

73 Receiver Directed Messaging PDP Use Case Diagram Figure 10 -Receiver Directed Messaging PDP Use Case Diagram Table 18 - Receiver Directed Messaging PDP Use Case Diagram Descriptions Administer Local Policies Authorize Web Request Authorize Action Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication channel), - action (READ/WRITE/Update/Delete/exchange), and - contextual environment (time of day, location, duty officer shift, threat, risk,...) Authorize Web Release Information Exchange Framework Reference Architecture, Initial Submission 53

74 Session Directed Messaging PDP Use Case Diagram Figure 11 -Session Directed Messaging PDP Use Case Diagram Table 19 - Session Directed Messaging PDP Use Case Diagram Descriptions Administer Local Policies Authorize Structured Message Sender Authorize Information Dissemination Service Authorize Action Check that the sender has the policy rights to send information with the security/sensitivity classification of the marked structured message and provide authorization if they do. Verify that an information dissemination service is authorized to transport the content of the specific information element. Authorization is based on the channel's security attributes and the markings (e.g., classifications and restrictions, and warnings) bound to each information element. If the channel attributes are verified, grant release of the information element to the service.. Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication channel), - action (READ/WRITE/Update/Delete/exchange), and 54 Information Exchange Framework Reference Architecture, Initial Submission

75 I d e n t i t y M a n a g e m e n t S e r v i c e e v a l u a t e s S e c u r i t y P o l i c y o l i c y D e c i s i o n P o i n t r e t r i e v e s P o l i c y R e p o s i t o r y Table 19 - Session Directed Messaging PDP Use Case Diagram Descriptions - contextual environment (time of day, location, duty officer shift, threat, risk,...) Authorize Structured Message Recipient Check that the recipient(s) have the policy rights to receive information with the security/sensitivity classification of the marked structured message and if they do provide the authorization Class Diagrams The following clauses provide the Class diagrams for the IEF Policy Decision Point services Policy Decision Point Class Diagram The PDP is a processing function that interprets a policy request and evaluates that request against the currently stated security policy. The security policy is an expression of the access control rules for the security domain and the policy engine, or PDP, is the processing component that evaluates an access request in the context of the security policy to derive the correct access control decision. package Policy Decision Point Class Diagrams [ Policy Decision Point Class Diagram ] Authorization Service P request/response Figure 1 -Policy Decision Point Class Diagram Information Exchange Framework Reference Architecture, Initial Submission 55

76 Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 20 Policy Decision Point Class Diagram Descriptions PolicyDecisionPoint The PDP or Policy Engine is the processing component that evaluates an access request in the context of the security policy to derive the correct access control decision. The PDP decision logic evaluates policy requests in three separate stages using the following inputs: 1. Requesting users unique identity(subject) 2. Requested resource 3. Requested action The PDP must now request the user s security attributes from the Identity Management System, usually a list of the user s COI memberships. Next it must retrieve a list of policies from the policy storage repository that are relevant to this user and/or any of the COIs to which the user belongs. From the list of relevant policies the PDP must now match any that correspond to the original policy request based on the inputs. The results of the matching process based on the per-policy evaluation yield the final decision to permit or deny which is returned to the PEP via the Authorization Service. PolicyDecisionPoint Operations: PolicyDecisionPoint PolicyRepository The ISS Policy Repository is a secure information store that persists the information sharing and safeguarding policies that are enforced by IEF services. The Policy Administration Point (PAP) provides the services needed to manage and administer the policies applicable to the environment or operation. The policies are stored in a database that can be queried by a PDP to acquire the relevant policies to the evaluation of the user request. ISS policies are immediately enforced once they are loaded and activated within the Policy Repository. The IEF can be configured with a single ISS Policy Store accessible by all PDPs, or as a federated repository with local repositories for the PDPs to access. In the latter configuration, all federated policy repositories are securely updated in real time from the PAP. PolicyRepository Operations: PolicyRepository SecurityPolicy The security policy is an expression of the access control rules for the security domain SecurityPolicy Operations: 56 Information Exchange Framework Reference Architecture, Initial Submission

77 Table 20 Policy Decision Point Class Diagram Descriptions Authorization Service SecurityPolicy Part of policy Decision Point, the Authorization Service determines whether or not a user can access, use or release information in the manner requested. This service acquires/gathers: The applicable ISS policies; The data/information markings (e.g., metadata, tags, labels, caveats, restrictions); The user attributes (e.g., policy rights, access rights, roles, location, and status); and The source and target resources' attributes (e.g., processing rights and restrictions). The service gathers information about the user, the recipients, the information asset(s), and the resources involved in the actions, and determines if the user/recipients have the rights to perform the requested action. The service then returns its decision to the Policy Enforcement Point(PEP) to execute the decision. The PDP possible responses include: Permit (action is permitted), Deny (action is denied) or Error. Authorization Service Operations: Authorization Service Identity Management Service Identity Management Service is an essential part of the IEF safeguarding infrastructure. It provides a bridge to an external user provided Identity Management Solution. During a standard policy request the Authorization Service leverages the Identity Management Service to retrieve a user s security credentials. Identity Management Service Operations: Identity Management Service Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 21 Policy Decision Point Class Diagram - Interface Descriptions Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Information Exchange Framework Reference Architecture, Initial Submission 57

78 Table 22 Policy Decision Point Class Diagram - Association Descriptions evaluates Owner: IEF Service Elements request/response retrieves The policy request for each user information access transaction, such as: retrieving a file or sending an message. IEF does not dictate the format of the policy requests so long as the request/response cycle is well-formed XACML expressions. The type of policy decisions that can be provided through the AS is not tied to a specific set of policy query attributes or conditions. Owner: IEF Service Elements Queries to the security policy repository are made using SQL over the security network. Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements 10.3 Sequence Diagrams The following clauses provide the Sequence diagrams for the IEF Policy Decision Point services Policy Decision Point Sequence Diagram Detailing the steps required to authorize an action request by a user. A PEP typically provides a user name matched with an action request to the PDP. The PDP leverages the Authorization Service to fetch the User's security credentials from the Identity Management Service. With the requested action on a data 58 Information Exchange Framework Reference Architecture, Initial Submission

79 asset the Authorization Service queries the Policy Repository for relevant policies and returns these to the PDP where the decision logic is applied. The result is a Permit or Deny response for the requested action. Figure 1 -Policy Decision Point Sequence Diagram Table 23 - Policy Decision Point Sequence Diagram - Message Descriptions RELEVANT POLICIES QUERY Information Exchange Framework Reference Architecture, Initial Submission 59

80 Table 23 - Policy Decision Point Sequence Diagram - Message Descriptions service response POLICY_REQUEST QUERY service response RESULTSET REQUEST_USER_CR EDENTIALS 60 Information Exchange Framework Reference Architecture, Initial Submission

81 11 Policy Enforcement Points Policy Enforcement Point (PEP) intercepts a user request to a resource, and enforces the decision from the Policy Decision Point (PDP). The PEP queries the PDP to see if the user has access to the resource (in this case data and information resources), and depending on the PDP response, allows the filter to pass or fail. There are five (5) Policy Enforcement Points (PEP) defined by the IEF Reference Architecture. The following clause define the information safeguards comprising each of the PEPs. For each PEP the Reference Architecture will provide the a set of Use Case, Abstract Services Classes, Interfaces and Operational Sequences diagrams describing the interfaces layer for off-the-shelf services, i.e.: Receiver Directed Messaging PEP; Session Directed Messaging PEP; and Specialized PEPS o , o File Share, and o Instant Messaging PEP Overview PEP Components Class Diagram At a minimum, any PEP that conforms to the IEF architecture will consist of two subcomponents or modules. 1. The Policy Enforcement Data Intercept (PEDI) is the sub-component that interrupts the data request/response cycle to extract information related to the data request in order to apply policy enforcement; and 2. The Policy Enforcement Message Client (PEMC) is the sub-component that connects to the Secure Messaging Service which provides a gateway to the security services required to enforce Information Protection Logic (IPL). Information Exchange Framework Reference Architecture, Initial Submission 61

82 Figure 1 -PEP Components Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 24 PEP Components Class Diagram Descriptions IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. The information exchange protocol conforms to industry accepted, open standards that are based on XML(e.g., extensible Messaging and Presence Protocol (XMPP)). The messaging services/infrastructure) provisions information (messages) between IEF services /components). Although the specific protocol, format and content of the messages will depend on the nature of service being accessed, all messages are delivered through the same communications mechanism. The ability to provide robust, secure and trusted delivery of security messages between IEF services forms the critical core of the IEF architecture. IEF Secure Messaging Service Operations: 62 Information Exchange Framework Reference Architecture, Initial Submission

83 Table 24 PEP Components Class Diagram Descriptions Generic PEP IEF Secure Messaging Service The PEP intercepts each request and response between the user (e.g., service clients, and applications) and the IEF enabled services (e.g., file share, , Instant Messaging, and message dissemination). The PEP provides the ability to link an information exchange service to the IEF safeguarding infrastructure. The PEP then verifies that the user has the authorizations to perform the operation and that the operation is permitted for the information asset on the designated device(s). If the User has the authorizations (policy-rights) the request is relayed to the enabled service for execution. Generic PEP Operations: Generic PEP PolicyEnforcementDataInt ercept The Policy Enforcement Data Intercept (PEDI) is a component of the PEP that intercepts client requests and data service responses in order to enforce ISS policy. The PEDI performs the following functions: Intercepts information requests that are sent from the workstation to the target data server; Intercepts data server responses; Collects information (e.g., information markings, resource attributes, user (producer and recipient) attributes) that are needed to formulate a policy request; Provides the information to the IEF services/functions responsible for enforcing the ISS authorization logic; and Based on the response from the ISS authorization logic, the PEDI will permit the information action/request to proceed or not. PolicyEnforcementDataIntercept Operations: PolicyEnforcementDataIntercept PolicyEnforcementMessag eclient The Policy Enforcement Message Client (PEMC) is the component within a PEP that connects to the required security services through the Secure Messaging Service. The PEP engages the PEMC when it needs to leverage external services in performing it s designated function PolicyEnforcementMessageClient Operations: PolicyEnforcementMessageClient Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Information Exchange Framework Reference Architecture, Initial Submission 63

84 Table 25 PEP Components Class Diagram - Interface Descriptions Data-Service-Interface Data-Service-Interface Operations: Client-Service-Interface Client-Service-Interface Operations: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 26 PEP Components Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Logging Service Connection Owner: IEF Service Elements Security Services Connection Owner: IEF Service Elements 64 Information Exchange Framework Reference Architecture, Initial Submission

85 E m a i l P E P I n f o r m a t i o n E x c h a n g e P E P I M P E P W e b S e s s i o n P E P F i l e P E P Table 26 PEP Components Class Diagram - Association Descriptions A PEDI must be able to know which user has submitted an information request. The determination of the user s identity is necessary for: Service; policy-based queried to the Authorization Service; and Owner: IEF Service Elements PEP Specialization Class Diagram A Policy Enforcement Point (PEP) is a component that is inserted into an application s data request/response cycle in order to add information protection capabilities through the leveraging of the core security services. PEPS may be specialized to function for the protection of specific data assets though these specializations will always leverage the Generic PEP's core functionality. package Policy Enforcement Point Class Diagrams [ PEP Specialization Class Diagram ] Generic PEP Figure 1 -PEP Specialization Class Diagram Information Exchange Framework Reference Architecture, Initial Submission 65

86 Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 27 PEP Specialization Class Diagram Descriptions Web Session PEP The Web Session PEP (Web PEP) operates between the WebBrowser (Client) and the target WebService. The PEP intercepts each request, determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the information assets involved. The PEP intercepts each response from the target web service, determines if the user has the authorizations (policyrights) to receive the information given sensitivities of the information assets involved and the target store (e.g., device, directory, and application) of the received information. This PEP limits access to only those users that have an access right to use the web services protected by the PEP Web Session PEP Operations: Web Session PEP File PEP The File PEP operates between the FileManager client and the File Share (server). The PEP intercepts each request, determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the files involved. The File PEP is intended to provide information protection for individual files as they are hosted on a protected file share. The File PEP requires that files have the appropriate security markings. The File PEP intercepts each user request to the File Share. The PEP then verifies that the user has the authorizations to perform the operation and that the operation is permitted for the information asset on the designated device(s). If the User has the authorizations (policy-rights) the request is relayed to the file server for execution. File PEP Operations: File PEP InformationExchangePEP The Information Exchange PEP operates between the Information service (user application, information system or information packaging service) and the machine-to-machine middle-ware that moves information assets between users publishers/producers and subscribers/receivers. The PEP intercepts each release of information and determines if the user has the authorizations (policy-rights) to release the information given sensitivities of the information assets involved. The PEP also intercepts receipt of information and determines whether or not the user has the authorizations (policy-rights) to receive the information given sensitivities of the information assets involved and the target store (e.g., device, directory, and application) for the received information. This PEP limits the receipt of information to only those users that have an access right to use the exchange services protected by the PEP. 66 Information Exchange Framework Reference Architecture, Initial Submission

87 Table 27 PEP Specialization Class Diagram Descriptions InformationExchangePEP Operations: InformationExchangePEP PEP The PEP operates between the client and the Mail server. The PEP intercepts each request, determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the information assets involved. Retrieve When a user sends a request to the Mail server to retrieve new e- mail, the PEP: 1. Intercepts the request and verifies that the user is authorized to access the server; 2. If the user has the policy-rights to access the Mail server, the request is relayed to the server; 3. Intercepts the response from the Mail server and verifies the user is authorized to receive each of the s and their attachments. For each returned from the server, the PEP 1. Disassembles each of the message; 2. Determines if the user has the authorizations (policy-rights) to access the contents of the and each of the attachments; 3. If the user is authorized to see the contents, decrypts the contents of each element, repackages the and relays it to the client. Send 1. Intercepts the request and verifies that the user is authorized to release information of the marked sensitivity, over ; to each of the recipients. 2. If the user has the policy-rights to release the content of the and all the recipients are authorized to receive the content, the message is encrypted, repackaged and relayed to the server; 3. If the user is not authorized to send the content of the or one or more of the recipients is not authorized to receive the content, the is returned to the user with the appropriate error message. For each returned from the server, the PEP 1. Disassembles each of the message; 2. Determines if the user has the authorizations (policy-rights) to access the contents of the and each of the attachments; 3. If the user is authorized to see the contents, decrypts the contents of each element, repackages the and relays it to the client. Each transaction is reported to the tamper resistant logging service. PEP Operations: Evaluate_Message: Operation Parameters: Evaluate_Send_Message: Operation Parameters: Evaluate_Received_Message: Information Exchange Framework Reference Architecture, Initial Submission 67

88 Table 27 PEP Specialization Class Diagram Descriptions Generic PEP Operation Parameters: Accept_Client_Connection: Operation Parameters: Forward_Message_to_Mail_Server: Operation Parameters: Forward_Message_to_ _Client: Operation Parameters: PEP The PEP intercepts each request and response between the user (e.g., service clients, and applications) and the IEF enabled services (e.g., file share, , Instant Messaging, and message dissemination). The PEP provides the ability to link an information exchange service to the IEF safeguarding infrastructure. The PEP then verifies that the user has the authorizations to perform the operation and that the operation is permitted for the information asset on the designated device(s). If the User has the authorizations (policy-rights) the request is relayed to the enabled service for execution. Generic PEP Operations: Generic PEP IM PEP The IM PEP operates between the IM-Client and the IM server. The PEP intercepts each request\response and determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the chatroom involved. The IM PEP mediates access to chat rooms and protects messages as they reside at IM server. In normal operations, the granularity of the safeguards is at the level of the chat room. That is, each chat room is assigned security attributes and it is those attributes that are used in the access control checks. For the IM PEP, security attributes are stored as part of the chat room s description and are stored in the IM server s database. User s also have the option to mark-up specific messages within a chat room. That is, the user can apply security attributes (COIs) to individual messages. Marked-up messages are handled slightly differently than normal chat room messages. When the IM PEP receives a marked up message, the message must be individually checked against the policy. Users must have the policy-rights to create content using the specified attribute, or COI, for the IM PEP to allow the message to be added to the history of chat room messages. Similarly, when a user receives IM messages, individual marked up messages must be evaluated against the security policy to ensure that they have the right to receive the message. Marked up messages, therefore, may only be deliverable to a subset of the users that have already been granted access to the chat room 68 Information Exchange Framework Reference Architecture, Initial Submission

89 Table 27 PEP Specialization Class Diagram Descriptions IM PEP Operations: List_Char_Rooms: Operation Parameters: Join_Chat_Room: Operation Parameters: Accept_Client_Connection: Operation Parameters: Send_Message: Operation Parameters: Receive_Messaage: Operation Parameters: IM PEP Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 28 PEP Specialization Class Diagram - Interface Descriptions Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 29 PEP Specialization Class Diagram - Association Descriptions PEP IEF PEP intercepts each message as it transits between the client and the server. The PEP verifies that: The content (message body and all attachments) is encrypted while at rest and in transit; Information Exchange Framework Reference Architecture, Initial Submission 69

90 The sender of the has the policy-rights to send the specific content; and Each recipient (To, cc, and bcc) is individually authorized (has the policy-rights) to receive and access the content of the body and each of the attachments. Upon receipt, the policy-rights are again verified prior to any decryption of the s content. The PEP applies protections to each element ( body and all attachment) included in the message. Each element must therefore be bound with all relevant sensitivity markings (e.g., privacy, confidentiality, classification, legally significance), and caveats (warning orders and restrictions) necessary for the IEF services to determine the policy defined protections appropriate to the s content. Where needed, the IEF services will provide services prompt and enable a user to bind the appropriate marking to each part of the message PEP Use Cases The following clauses provide the Use Case diagrams for the PEP services. Send Use Case Diagram When a user sends an message, the IEF intercepts and interprets the message in order to extract the following information: - The identity of the sender; - The identities of the recipients (TO, CC and BCC recipients); and - The markings on the message body. The IEF also decodes the attachments to get access to the original file and its markings. Once all the information is gathered, the IEF executes the following safeguarding logic: - Determines if the sender has the policy-rights to send a message; - Determine if each of the recipients has the policy-rights to receive and access the . For each file attachment, the markings are extracted and the IEF executes the following safeguarding logic: - Verify if sender has the policy-rights to send files with the designated sensitivity; and. - Verify that each recipient has the policy-rights to receive and access files with the designated sensitivity. For example, an with two attachments going to three people would have twelve separate policy checks (4 users x 3 objects). If the sender or any recipient does not have the policy-rights to access the contents of the or its attachment, the message is returned to the sender to correct the issues. If the message passes all policy checks, the IEF encrypts the entire message and then delivers the encrypted message to the mail server. messages are encrypted in transit and while stored at the mail server. As a final step the IEF logs each transaction to the tamper resistant logging service to create a permanent record of this operation. The IEF prepares a record of each the transactions and punishes the record to a tamper-resistant log as an immutable record of this activity. 70 Information Exchange Framework Reference Architecture, Initial Submission

91 Figure 12 -Send Use Case Diagram Table 30 - Send Use Case Diagram Descriptions Mark Body Prompt the user to provide the appropriate markings (e.g., security, privacy, and caveat restrictions) for the body and then bind them to the . *Note: The marking and values for the markings are specified by the user. Authorize Recipient Verify that each recipient is individually authorized to receive and access the and its attachments. If the recipient s rights are verified, grant access to the user and deliver the . The recipient is verified at both release and receipt of the . If the recipient does not have the policy rights to access the or any of its Information Exchange Framework Reference Architecture, Initial Submission 71

92 Table 30 - Send Use Case Diagram Descriptions attachment(s), the is returned to the sender so they have the opportunity to adjust the so that some or all the elements are releasable to the recipient. Encrypt Package Redact elements Mark Attachment Transform the information content of the body and its attachments into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. The body and each attachment is encrypted using its own unique symmetric key. Gather the elements of the (body, attachments and markings) and then format the information for release to the mail server. When an is sent, it is intercepted and information elements that the recipient(s) do not have access rights to are removed before the is delivered Prompt the user to provide the appropriate markings (e.g., security, privacy, and caveat restrictions) for the file and then bind them to the attachment (file) prior to being stored. *Note: The marking and values for the markings are specified by the user. Gather Attachments Encrypt Attachments Prompt User for Markings Gather the set of attachments, including markings, the user linked to the . If an attachment is not marked, prompted the user to set the markings. Transform the information content of an attachment file into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each attachment is encrypted using its own unique symmetric key. Prompts the user to add markings (e.g., security and privacy) to an information element by binding the markings to the element being exchanged, e.g.: - ; - Attachments; - Instant Message; - File; - Web; and - Structured Message. This use case may be specialized to accommodate the different information types. There is also an option to automate the process based on the security domain in which the information element was generated. Release to Server Log Transaction After all the elements of the are authorized for release, and it is packaged for release, send the to the local Mail server.. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. 72 Information Exchange Framework Reference Architecture, Initial Submission

93 Table 30 - Send Use Case Diagram Descriptions Encrypt Body Generate Markings Transform the information content of the body into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. The body has its own unique symmetric key. Automate the generation of markings based on user defined policies. Notes: and verify them (make sure they have not been altered) and validate them (make sure they are still correct given the current labeling policy) Authorize Sender Block Release to Unauthorized Recipient Verify that the user has the policy rights to send an and attachments with the specific markings. If the sensitivity of the -body exceeds the credentials of one or more of the recipients (TO, CC and BCC recipients), the is returned to the sender to correct the issue. Optionally, the PEP may remove the unauthorized part from the distribution and notification is provided to the sender. In the latter case all other authorized recipients receive the . The User may be prompted to alter the content and markings to enable its release to the unauthorized recipients. Remove Unauthorized Attachment Prompt the user to remove the unauthorized information element and identify any elements not authorized for specific recipients. Send When a user sends an message, the IEF intercepts and interprets the message and gathers following information: - The identity of the sender; - The identities of the recipients (TO, CC and BCC recipients); - The marking on the message body; and - The markings on each attachment. The PEP then executes the following information protection logic: - Assure the sender has the policy right to send a message and attachments with the bound security markings (/attributes); - Assure each recipient has the policy right to access information with the bound security attributes and attachments. If any element in the (body or attachments) exceeds the senders of recipients policy rights, the message is returned to the sender where the sender can: - drop recipients from the list (TO, CC, Bcc), - drop attachments from the message or alter the security attributes on the message. If the message passes all policy checks, the IEF encrypts the message body as well as any attachments with a unique symmetric key and then delivers the encrypted message to the back end mail server. Messages remain encrypted while they are stored at the mail server. Each step of the operation is recorded to a tamper-proof log in support of: - Incident and Event Monitoring; and Information Exchange Framework Reference Architecture, Initial Submission 73

94 Table 30 - Send Use Case Diagram Descriptions - Forensic Auditing. Prepare Prepare the , including the markings, and the identification of its attachments. Receive Use Case Diagram When a user retrieves an message from the mail server, the IEF intercepts the message. The security label on the message is extracted and the IEF assures that the recipient has the policy right to access the message. If the user has that right, the IEF decrypts the message, using the symmetric key retrieved from the Key Escrow service. The decrypted message is then delivered to the user. The re-verification of policy rights may seem redundant as the same check that was made when the message was originally sent. In actuality, check in receive is necessary since in the interim between when the message was sent and when it was received, either the recipient s security attributes or the security policy itself may have been altered. Allowing the recipient to retrieve the message under these conditions may violate the new policy, therefore a supplemental policy check on receive is necessary. If the policy or policy rights have changed, the IEF can redact the offending information. 74 Information Exchange Framework Reference Architecture, Initial Submission

95 Figure 13 -Receive Use Case Diagram Table 31 - Receive Use Case Diagram Descriptions Decrypt Attachments Transform the information content of an attachment back into its original form using the unique symmetric key retrieved from escrow. Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Authorize User to Receive Attachment Authorize User to Receive When there is an attachment received as part of an information exchange the IEF extracts the attachment from the , and checks the associated markings on the attachment, and then validates the recipient has the policy rights to receive the attachment. If the recipient is authorized, the attachment is included, else, the attachment is redacted from the information received. Verify that the recipient has the policy rights to access the content of the . Information Exchange Framework Reference Architecture, Initial Submission 75

96 Table 31 - Receive Use Case Diagram Descriptions Intercept On receipt of an from the mail server, the PEP intercepts the in order to enforce policy. Extract Markings from Extract markings from an (main body and attachments), e.g.: Security Tags; Privacy Tags; informational metadata, Constraints; and Warning Orders. Decrypt Deliver to Authorized User Transform the information content of the body back into its original form using the unique symmetric key retrieved from escrow. Deliver the decrypted content of the and its attachment(s) to the client for the authorized user PEP Class Diagrams The following clauses provide the Class diagrams for the PEP services. PEP Class Diagram The PEP is intended to provide information protection of messages as they are sent to, stored at and retrieved from an existing mail server in the target environment. The PEP is implemented as a proxy architecture where traffic is directed through the proxy and information protection logic is applied during the sending and receiving of messages. 76 Information Exchange Framework Reference Architecture, Initial Submission

97 Figure 1 - PEP Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 32 PEP Class Diagram Descriptions IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. The information exchange protocol conforms to industry accepted, open standards that are based on XML(e.g., extensible Messaging and Presence Protocol (XMPP)). The messaging services/infrastructure) provisions information (messages) between IEF services /components). Although the specific protocol, format and content of the messages will depend on the nature of service being accessed, all messages are delivered through the same communications mechanism. The ability to provide robust, secure and trusted delivery of security Information Exchange Framework Reference Architecture, Initial Submission 77

98 Table 32 PEP Class Diagram Descriptions messages between IEF services forms the critical core of the IEF architecture. IEF Secure Messaging Service Operations: IEF Secure Messaging Service SecureAssetContainer An envelope that allows some unprotected information to exist outside of the protected (encrypted) payload. In addition to the encrypted payload, the envelope includes: The key token that is used as a reference to the actual key (stored in the key escrow system) that was used to protect the payload; A hash digest to detect tampering of the container contents; The original file name of the information asset; and A copy of the security marking on the information asset as it existed when the IEF originally protected the asset: a copy of the original asset security marking. SecureAssetContainer Operations: SecureAssetContainer hashdigest: All SAC's include a digest that is calculated at creation time that is used to detect tampering of the container upon decryption. The digest is calculated using the SHA- 512 hash algorithm. Digest calculation is dependent on the order in which the source material is submitted for the calculation. For SAC's, the digest is calculated as follows: 1. The contents of the encrypted file; 2. The caveat for the original file; 3. The token for the key; 4. The filename of the original file; and 5. The key used to encrypt the original file. keytoken: When a request to decrypt the file is received, the container is opened and the keytoken is extracted. This is then used to retrieve the key from the KMS. file: The filename of the original file POP3_proxy The POP3 proxy is an intermediary service connecting to the mail server. The e- mail client connects to the proxy server, which requests service from the mail server. The proxy service adds the IEF structures and encapsulates the mail server. The proxy service adds the structures that enable the IEF to: 1. Intercept user requests to receive their s from the server. Before the proxy delivers an message it hands off the to a staging area where the PEP can apply the necessary information protection logic. The security markings from the encrypted messages are extracted and used to determine if the security policy allows the user to receive the message. If the security policy allows the user to receive the message it is then 78 Information Exchange Framework Reference Architecture, Initial Submission

99 Table 32 PEP Class Diagram Descriptions decrypted and forwarded to the users client. 2. Intercept user requests to send an to the server. Before the proxy sends the mail message it hands off the to a staging area where the PEP can again apply the necessary information protection logic. The security attributes from the message are extracted and used to determine if the sender can send the message. If the security policy allows the user to send the message it is then encrypted and forwarded to the mail server for delivery. POP3_proxy Operations: PEP POP3_proxy messageintransit: The PEP operates between the client and the Mail server. The PEP intercepts each request, determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the information assets involved. Retrieve When a user sends a request to the Mail server to retrieve new e- mail, the PEP: 1. Intercepts the request and verifies that the user is authorized to access the server; 2. If the user has the policy-rights to access the Mail server, the request is relayed to the server; 3. Intercepts the response from the Mail server and verifies the user is authorized to receive each of the s and their attachments. For each returned from the server, the PEP 1. Disassembles each of the message; 2. Determines if the user has the authorizations (policy-rights) to access the contents of the and each of the attachments; 3. If the user is authorized to see the contents, decrypts the contents of each element, repackages the and relays it to the client. Send 1. Intercepts the request and verifies that the user is authorized to release information of the marked sensitivity, over ; to each of the recipients. 2. If the user has the policy-rights to release the content of the and all the recipients are authorized to receive the content, the message is encrypted, repackaged and relayed to the server; 3. If the user is not authorized to send the content of the or one or more of the recipients is not authorized to receive the content, the is returned to the user with the appropriate error message. For each returned from the server, the PEP 1. Disassembles each of the message; 2. Determines if the user has the authorizations (policy-rights) to access the contents of the and each of the attachments; 3. If the user is authorized to see the contents, decrypts the contents of each element, repackages the and relays it to the client. Each transaction is reported to the tamper resistant logging service. Information Exchange Framework Reference Architecture, Initial Submission 79

100 Table 32 PEP Class Diagram Descriptions Trusted Logging Service PEP Operations: Evaluate_Message: Operation Parameters: Evaluate_Send_Message: Operation Parameters: Evaluate_Received_Message: Operation Parameters: Accept_Client_Connection: Operation Parameters: Forward_Message_to_Mail_Server: Operation Parameters: Forward_Message_to_ _Client: Operation Parameters: PEP The Trusted Logging Service (TLS) is one of the central IEF Security Services and is the key service for maintaining and demonstrating the integrity of IEF information protection processes.. The Trusted Log Files that are protected and stored though the TLS keep a transactional history of the policy decisions and access control enforcement across all IEF protected resources. Since all policy enforcement activities are recorded within the TLS and the integrity of the TLS can be demonstrated, the TLS can be used to track information access requests and the rationale for why information was disclosed to IEF users. Trusted Logging Service Operations: Trusted Logging Service SMTP_proxy The PEP SMTP proxy is an intermediary service connecting the client to the mail server. The client connects to the proxy server, which requests service from the mail server. The proxy service adds the IEF structures and encapsulates the mail server. The proxy service adds the structures that enable the IEF to: 1. When the user sends an message, the client connects to the SMTP proxy. The proxy software receives the message and places the contents in a staging area. The proxy software then calls the PEP information protection logic, that is, the software validation routine that evaluates the message to ensure it meets policy and information protection requirements. 2. Once it is determined that the message can be sent and the message has been properly protected, it is forwarded on to the mail server for delivery. 80 Information Exchange Framework Reference Architecture, Initial Submission

101 Table 32 PEP Class Diagram Descriptions Authorization Service SMTP_proxy Operations: SMTP_proxy messageintransit: Part of policy Decision Point, the Authorization Service determines whether or not a user can access, use or release information in the manner requested. This service acquires/gathers: The applicable ISS policies; The data/information markings (e.g., metadata, tags, labels, caveats, restrictions); The user attributes (e.g., policy rights, access rights, roles, location, and status); and The source and target resources' attributes (e.g., processing rights and restrictions). The service gathers information about the user, the recipients, the information asset(s), and the resources involved in the actions, and determines if the user/recipients have the rights to perform the requested action. The service then returns its decision to the Policy Enforcement Point(PEP) to execute the decision. The PDP possible responses include: Permit (action is permitted), Deny (action is denied) or Error. Authorization Service Operations: Authorization Service Marker Software service that integrates with an off-the-shelf client that obliges and enables an authorized user to appropriately mark the and its attachments. In the service of the PEP the Marker retrieves the markings from messages and attachments. Marker Operations: Marker Cryptographic Transformation Service The Cryptographic Transformation Service (CTS) provides the interface between the PEP and the user specified/provided cryptographic application(s) or appliance(s) that : Encrypt information assets; and Decrypt information assets for authorized users. The application of cryptographic services is dependent on the type of asset being protected. The CTS provides protection for the following data types: Files are encrypted when they are transferred from the user s workstation to the IEF protected file share and decrypted when they are retrieved from the file share for delivery to an authorized user. messages, including attachments, are encrypted when they are stored/prepared for delivery and decrypted when a user retrieves the from the server. IM messages are encrypted as they are exchanged by the IM server. Only when a Information Exchange Framework Reference Architecture, Initial Submission 81

102 Table 32 PEP Class Diagram Descriptions user is permitted to enter a chat room are these message decrypted and delivered. Structured Message payloads and attachments are encrypted prior to release by an information dissemination service. Cryptographic Transformation Service Operations: Cryptographic Transformation Service Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 33 PEP Class Diagram - Interface Descriptions -Client-SMTP- Interface Standard Interface for user specified/provided off-the-shelf SMTP client applications. -Client-SMTP-Interface Operations: Mal-Server-POP3- Interface Standard Interface for user specified/provided off-the-shelf POP3 mail server. Mal-Server-POP3-Interface Operations: Mail-Server-SMTP- Interface Standard Interface for user specified/provided off-the-shelf SMTP mail server. Mail-Server-SMTP-Interface Operations: -Client-POP3- Interface Standard Interface for user specified/provided off-the-shelf POP3 client applications. 82 Information Exchange Framework Reference Architecture, Initial Submission

103 Table 33 PEP Class Diagram - Interface Descriptions -Client-POP3-Interface Operations: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 34 PEP Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Information Exchange Framework Reference Architecture, Initial Submission 83

104 Table 34 PEP Class Diagram - Association Descriptions Owner: IEF Service Elements PEP Sequence Diagrams The following clauses provide the Sequence diagrams for the PEP services. Send Sequence Diagram When a user creates and submits an message to the PEP, the PEP must be able to apply the security policy to all file attachments and ensure that the policy is applied to not only the sender of the message, but each of the recipients as well. This includes users specified as TO, CC and BCC recipients. Figure 1 -Send Sequence Diagram 84 Information Exchange Framework Reference Architecture, Initial Submission

105 Table 35 - Send Sequence Diagram - Message Descriptions Reject_ Attachment_Markings Extract_ _Marking s Request_Crypto_Key The CTS will leverage the KMS, to obtain a new symmetric key for the operation and store this key in the escrow system. Policy_Decision(PERM IT) Recipient_Authorization s Return Token Information Exchange Framework Reference Architecture, Initial Submission 85

106 Table 35 - Send Sequence Diagram - Message Descriptions Policy_Decision(PERM IT) Request_Recipient_Attri butes Log_ _Transaction Request_Recipient_Attri butes Recipient_Attributes Process Next Attachment Service Response The containers location is made known to the PEP Log_ _Transaction 86 Information Exchange Framework Reference Architecture, Initial Submission

107 Table 35 - Send Sequence Diagram - Message Descriptions Forward Secure_Emai l The PEP will encode the newly created encrypted container so that it is in compliance with the mail server s message format specification. The PEP then transmits the container (as a MIME compliant message) to the mail server with the original source and destination routing information. Store_Crypto_Key _Markings The PEP gets a unique set of security attributes from the markings that have been attached to the message body and its attachments. Extract_Attachment_Ma rkings Log_ _Transaction Reject_ Information Exchange Framework Reference Architecture, Initial Submission 87

108 Table 35 - Send Sequence Diagram - Message Descriptions SMTP The PEP receives the entire message from the client and stores it in a local staging area for processing. Request_Release_Autho rization Reject_ Request_Release_Autho rization Crypto_Key With this new key, the CTS encrypts the file and places it in a container. Return Encrypted & Tolken Encrypt_ the PEP calls the CTS to encrypt the originally intercepted base64 encoded message (which includes all MIME attachments). 88 Information Exchange Framework Reference Architecture, Initial Submission

109 Table 35 - Send Sequence Diagram - Message Descriptions package_secure_ Receive Sequence Diagram When a user connects to the mail server to retrieve messages, the POP3 proxy allows the message retrieval commands to be sent to the back end mail server. When messages are returned through the proxy, however, the proxy intercepts the messages and stores them in a local staging area so that each message may have information protection logic applied to it. Figure 1 -Receive Sequence Diagram Table 36 - Receive Sequence Diagram - Message Descriptions Request_Recipient_Cre dentials The user security attributes are retrieved from the IMS via a security attribute request Information Exchange Framework Reference Architecture, Initial Submission 89

110 Table 36 - Receive Sequence Diagram - Message Descriptions Policy Decision(PERMIT) Recipient_Credentials Return_ _Markings Rejected_Attachment Policy_Decision(PERM IT) Retrieve_Unique_Crypt o_key Attachment_Markings 90 Information Exchange Framework Reference Architecture, Initial Submission

111 Table 36 - Receive Sequence Diagram - Message Descriptions Decrypted_ _Mess age Recipient_Credentials Message Retrieval Decrypt_Attachment Request_Recipient_Cre dentials Extract_ _Marking s Through a call to the SMS, the PEP acquires the security attributes from the encrypted 's container for the message body as well as any attachments. Decrypted_Attachment Information Exchange Framework Reference Architecture, Initial Submission 91

112 Table 36 - Receive Sequence Diagram - Message Descriptions Crypto_Key Rejected_ The PEP will then create a log file record, that specifies the transaction details and send the record to the TLS to create a permanent record of the transaction. Decrypt_ Retrieve_Unique_Crypt o_key Using the token in the container, call the KMS to retrieve the symmetric key that was used to encrypt the file with a key request message. Extract_Attachment_Ma rkings Deliver Message The PEP will encode the decrypted message and signal the POP3 proxy to deliver the message to the user s client. 92 Information Exchange Framework Reference Architecture, Initial Submission

113 Table 36 - Receive Sequence Diagram - Message Descriptions Request_Release_Autho rization Request_Release_Autho rization POP 3 Unique_Crypto_Key Log Transaction 11.3 File Sharing PEP The File Sharing PEP protects individual files are they are stored to and accessed from the IEF protected file share. The file sharing approach assures that each files stored and retrieved from the protected store are appropriately marked with security, privacy and caveat (warning orders) and supporting metadata. The markings are permanently bound to the files while they are protected by the IEF. The IEF operates between the file management client and the protected-file share. The IEF intercepts all user requests and brokers the requested action (e.g., open, store, move, copy, cut, paste, and delete). The IEF verifies that for each action the user has the policy-rights to effect the requested operation on an information asset with the declared (/marked) sensitivities. The IEF supports policy enforcement for the following files operations. Information Exchange Framework Reference Architecture, Initial Submission 93

114 File Share Use Cases The following clauses provide the Use Case diagrams for File Share PEP services. Access File Share Use Case Diagram The following figure illustrated the core use cases for the IEF Protected files share. The IEF verifies that a user is authorized to see or access the specific directory or file on the IEF protected shared files share. If the user/application has the policy rights to the requested action fulfill the request. Figure 14 -Access File Share Use Case Diagram Table 37 - Access File Share Use Case Diagram Descriptions Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in 94 Information Exchange Framework Reference Architecture, Initial Submission

115 Table 37 - Access File Share Use Case Diagram Descriptions the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Manage Protected File When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is decrypted and opened in the tool selected by the user. Issue Alerts and Warnings Based on policy, if the user is attempting to perform an activity that is not authorized, issue a warning or alert to responsible individuals. The IEF uses internal services to disseminate the warnings and alerts. The thresholds of activity calling for a warning or alert is controlled by policy. Access Directory Access File Share Redact Directory Content List Directory Content When a user requests access to a directory, the IEF intercepts the request and assesses whether or not the user has the policy rights to open the directory and access its content. If the user is authorized, the IEF directs the file share services to opens the directory and list the specific content the user is authorized to access. When a user attempts to access a protected file share, the IEF intercepts the requests and determines whether or not the user has the policy rights to access the directory. When a user accesses a directory or requests a directory listing, the request is intercepted and the contents of the directory are assessed vis a vis the access right of the user. Those files to whichthe user does not have access rights are removed (redacted) from the list of all files in the directory. In this way, the recipient only has knowledge of files they have access rights to see. When a user requests a directory listing for the file share, the user is only able see those files to which the user has a policy right to access. The IEF receives a complete list of files from the file share and then redacts any file that the user does not have the policy right to see. For each file the IEF: - Obtain the bound markings (e.g., security, privacy, and caveat restrictions); - Determines if the user has the policy right to see it; and - Redacting each files for which there is not a policy right. The resulting list only contains files that the user has the policy right to access. Authorize File Access Verify that the user has the policy rights to access the contents of a file. Information Exchange Framework Reference Architecture, Initial Submission 95

116 Manage Protected File Use Case Diagram The following figure illustrates the generalized use case for file actions within the context of the IEF protected file share. Figure 15 -Manage Protected File Use Case Diagram Table 38 - Manage Protected File Use Case Diagram Descriptions Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Delete File Remove the file from the directory in the protected file share.. Create File Move File Manage Protected File When a user attempts to create file, the IEF intercepts the request and authorizes each step in the process. When a user attempts to move a file to or from an IEF protected device, the IEF intercepts the request and authorizes each step in the process. When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is 96 Information Exchange Framework Reference Architecture, Initial Submission

117 Table 38 - Manage Protected File Use Case Diagram Descriptions decrypted and opened in the tool selected by the user. Open File When a user (e.g. individual, application or system) requests access to the contents of a file in an IEF protected file share: The File PEP - intercepts the request; - determines whether or not the user has policy rights to access the file; and if authorized, decrypts the file and provides it to the user. Replace File Rename File Save File Copy File Delete the previous version of the file in the directory and replace it with the version that the user has requested to save, stored, moved or copied to the directory. When an authorized user or user application requests that a file be renamed within the IEF file share. When an authorized user or user application requests that a file be stored/saved within the IEF file share. When a user attempts to copy a file to or from and IEF protected device, the IEF intercepts the request and authorizes each step in the process. Copy File Use Case Diagram Users should only be able to copy a file if they have the policy-rights to access and use the file. When a user requests to copy a file, the IEF intercepts the request and extracts the markings bound to the requested file and verifies that the user has the policy-rights to access and use the content of the file. If the operation is permitted by policy, the IEF determines if the security policies require that a new cryptographic key must be applied. If a new key is required, the IEF retrieves the original file, decrypts the file, re-encrypts the file with a new cryptographic key, and holds the encrypted file in a temporary storage location until the paste operation is requested. If a new key is not required, the IEF retrieves the original file, stores a copy of the encrypted file to requested location. The request/result is then recorded in the tamper-resistant log as an immutable record of this activity. Information Exchange Framework Reference Architecture, Initial Submission 97

118 Figure 16 -Copy File Use Case Diagram Table 39 - Copy File Use Case Diagram Descriptions Authorize File Action Put File Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). Put the file into the target directory. Manage Protected File When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is decrypted and opened in the tool selected by the user. Encrypt File Transform the information content of the file into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each file is encrypted using its own unique symmetric key. 98 Information Exchange Framework Reference Architecture, Initial Submission

119 Table 39 - Copy File Use Case Diagram Descriptions Copy File When a user attempts to copy a file to or from and IEF protected device, the IEF intercepts the request and authorizes each step in the process. Get File Retrieve/get the encrypted file from the IEF protected file share. Mark File Prompt the user to provide the appropriate markings (e.g., security, privacy, and caveat restrictions) for the file and then bind them to the file being stored. *Note: - The marking and values for the markings are specified by the user. - This breaks the security overlay concept since it requires software to be loaded at the client side. We should make the assumption that objects are properly labeled prior to being uploaded. (to be debated) Decrypt File Transform the information content of the files back into its original form using the unique symmetric key retrieved from escrow. Create File Use Case Diagram The following figure illustrates the use case for creating a file on the IEF protected file share. Information Exchange Framework Reference Architecture, Initial Submission 99

120 Figure 17 -Create File Use Case Diagram Table 40 - Create File Use Case Diagram Descriptions Authorize File Action Put File Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). Put the file into the target directory. Encrypt Information Element Create File Manage Protected File Transform the information content of an information element into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each information element is encrypted using its own unique symmetric key. When a user attempts to create file, the IEF intercepts the request and authorizes each step in the process. When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is 100 Information Exchange Framework Reference Architecture, Initial Submission

121 Table 40 - Create File Use Case Diagram Descriptions decrypted and opened in the tool selected by the user. Open File When a user (e.g. individual, application or system) requests access to the contents of a file in an IEF protected file share: The File PEP - intercepts the request; - determines whether or not the user has policy rights to access the file; and if authorized, decrypts the file and provides it to the user. Cut File Use Case Diagram A User should only be able to cut a file if they have the policy-rights to access and use its contents and that security policy permits the deletion of the file from the location. When a user requests a cut operation, the IEF intercepts the request, extracts the markings from the requested files and verifies that the user has the policy-rights to access the content, and also verities that it is permitted to delete the contents from the original location. If the operation is permitted, the IEF retrieves the file, marks the file for deletion and holds the file in a temporary location until the user issues the paste command. The request/result is then recorded in the tamper-resistant log as an immutable record of this activity package File PEP Use Case Diagrams [ Cut File Use Case Diagram ] Figure 18 -Cut File Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 101

122 Table 41 - Cut File Use Case Diagram Descriptions Delete File Use Case Diagrame A User should only be able to delete a file if they have the policy-rights to access the contents of the files and security policy permits the deletion of the file from the location. When a user requests the deletion of a file, the IEF intercepts the request, extracts the markings from the requested file and verifies that the user has the policy-rights to access its content. The IEF also verifies that it is permitted to be deleted from the requested location. If the operation is permitted, the IEF directs the file system to delete the files from the protected file store. The request/result is then recorded in the tamper-resistant log as an immutable record of this activity Figure 19 -Delete File Use Case Diagram 102 Information Exchange Framework Reference Architecture, Initial Submission

123 Table 42 - Delete File Use Case Diagram Descriptions Authorize File Action Delete File Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). Remove the file from the directory in the protected file share.. Remove File Delete/Remove the encrypted file from the protected file share. Manage Protected File When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is decrypted and opened in the tool selected by the user. List Files Use Case Diagram A user should only be able to view information about files to which the user has a policy-right to access and use. When a user issues a list directory command, the IEF intercepts the command. It requests a complete list of files from the files system managing the protected file share and redacts any file information that the user does not have the policy-right to access. For each file, the IEF accesses the files markings verifies the users policy-rights to access s files with a bound markings. The resulting list is then provided to the user. The operation is then recorded in the tamper-resistant log as an immutable record of this activity. package File PEP Use Case Diagrams [ List Files Use Case Diagram ] Figure 20 -List Files Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 103

124 Table 43 - List Files Use Case Diagram Descriptions Move File Use Case Diagrame File Move: Users should only be able to move a file if they have the policy-rights to access its contents of the files and the source and target devices/directories. When a user issues a move command for a file, the IEF intercepts the command, extracts the markings bound to the identified file and verifies that the user has the policy-rights to access and move the requested file. The IEF also verifies that the user has the policy-rights to move the file to the target location and remove (/delete) the files from its source location. If the operation is permitted (all the policy-rights are verified), the IEF determines if the security policies require that a new cryptographic key must be applied to the file. If a new key is required, the IEF retrieves the original file, decrypts the file, re-encrypts the file with a new cryptographic key, directs the file system to stores the encrypted file to target location, and then removes the files from the original location. If a new key is not required, the IEF retrieves the original file, stores the encrypted file to requested location, and then removes the files from the original location. The request/result is then recorded in the tamper-resistant log as an immutable record of this activity. Figure 21 -Move File Use Case Diagram 104 Information Exchange Framework Reference Architecture, Initial Submission

125 Table 44 - Move File Use Case Diagram Descriptions Authorize File Action Put File Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). Put the file into the target directory. Delete File Remove the file from the directory in the protected file share.. Move File Manage Protected File When a user attempts to move a file to or from an IEF protected device, the IEF intercepts the request and authorizes each step in the process. When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is decrypted and opened in the tool selected by the user. Encrypt File Get File Transform the information content of the file into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each file is encrypted using its own unique symmetric key. Retrieve/get the encrypted file from the IEF protected file share. Mark File Prompt the user to provide the appropriate markings (e.g., security, privacy, and caveat restrictions) for the file and then bind them to the file being stored. *Note: - The marking and values for the markings are specified by the user. - This breaks the security overlay concept since it requires software to be loaded at the client side. We should make the assumption that objects are properly labeled prior to being uploaded. (to be debated) Decrypt File Transform the information content of the files back into its original form using the unique symmetric key retrieved from escrow. Open File Use Case Diagram Users should only be able to retrieve/access/open a file if they have the policy-rights to access its contents. When a user requests a file, the IEF intercepts the request, extracts the markings from the requested file and verifies that the user has the policy-rights to access and use the files. If the operation is Information Exchange Framework Reference Architecture, Initial Submission 105

126 permitted by policy, the IEF decrypts the file and the decrypted file is provided to the requesting user. The request/result is then recorded in the tamper-resistant log as an immutable record of this activity. Figure 22 -Open File Use Case Diagram Table 45 - Open File Use Case Diagram Descriptions Authorize File Action Manage Protected File Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is decrypted and opened in the tool selected by the user. Open File When a user (e.g. individual, application or system) requests access to the contents of a file in an IEF protected file share: The File PEP - intercepts the request; - determines whether or not the user has policy rights to access the file; and if authorized, decrypts the file and provides it to the user. 106 Information Exchange Framework Reference Architecture, Initial Submission

127 Table 45 - Open File Use Case Diagram Descriptions Provide File to Selected Application Provide the decrypted file to the selected application. Authorize File Access Verify that the user has the policy rights to access the contents of a file. Get File Retrieve/get the encrypted file from the IEF protected file share. Decrypt File Transform the information content of the files back into its original form using the unique symmetric key retrieved from escrow. Paste File Use Case Diagram A User should only be able to paste a file if they have the policy-rights to access and its contents, and has the policy rights to store information in the requested location. When a user issues a paste command, the IEF extracts its markings and verifies that the user has the policy-rights to access use the contents ion the file, and verifies the user has the policy-rights too store contents in the requested location. If the operation is permitted by policy, the IEF decrypts the file and the decrypted file is provided to the requesting user. If a version of the file already exists in the storage location, the IEF verifies that the security policies allow the replacement of files in the storage location. If the replacement is allowed, the file is stored in the storage location, replacing the original file. If the replacement of the file is not permitted, the User is prompted to rename the file before it is stored. The request/result is then recorded in the tamper-resistant log as an immutable record of this activity. Information Exchange Framework Reference Architecture, Initial Submission 107

128 package File PEP Use Case Diagrams [ Paste File Use Case Diagram ] Figure 23 -Paste File Use Case Diagram Table 46 - Paste File Use Case Diagram Descriptions Rename File Use Case Diagrame Figure 24 -Rename File Use Case Diagram 108 Information Exchange Framework Reference Architecture, Initial Submission

129 Table 47 - Rename File Use Case Diagram Descriptions Authorize File Action Rename File Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). When an authorized user or user application requests that a file be renamed within the IEF file share. Manage Protected File When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is decrypted and opened in the tool selected by the user. Save File Use Case Diagram A user should only be able to store/save/write a file to the protected file share if they have the policy-right to store a file with the assigned markings in the target location (device/directory) and the target location has the policy-rights to store files with the bound markings. When a user issues the store command, the IEF intercepts the command, it then extracts the files markings and ensures that the user has the policyrights to create/update/replace a file with the bound marking to the requested device/file-share/directory. If the file is not marked, the user is prompted and provided services bind markings for the file. If the user has the policy-rights to perform the store operation, the IEF encrypts the file using a new unique symmetric key. It then binds the appropriate markings to the encrypted file, and sent it to the file system to be saved within the protected file share. If the file system identifies that a version of the file already exists in the storage location, the user is prompted to decide if the existing file should be updated/replaced or renamed. It the user the IEF verifies that the security policies allow the replacement of files in the storage location (device/directory). If the replacement is allowed, the file system is directed to store in the storage location, replacing the original file. If the replacement of the file is not permitted, the User is prompted to rename the file before it is stored. The request/result is then recorded in the tamper-resistant log as an immutable record of this activity. Information Exchange Framework Reference Architecture, Initial Submission 109

130 Figure 25 -Save File Use Case Diagram Table 48 - Save File Use Case Diagram Descriptions Authorize File Action Encrypt File Persist File to Protected File Share Verify that the user has the policy rights to access the specified file(s) and perform the requested action. The policy rights must extend to the specific device, directory and file(s). The verification is determined by applying user defined policies to the attributes of the user/role (e.g., access rights and privileges) and to the attributes of the file (e.g., classification, restrictions and warning orders). Transform the information content of the file into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each file is encrypted using its own unique symmetric key. Place the marked and encrypted file into the shared file store. Save File Mark File When an authorized user or user application requests that a file be stored/saved within the IEF file share. Prompt the user to provide the appropriate markings (e.g., security, privacy, and caveat restrictions) for the file and then bind them to the file being stored. *Note: - The marking and values for the markings are specified by the user. - This breaks the security overlay concept since it requires software to be loaded at the client side. We should make the assumption that objects are properly labeled prior to being uploaded. (to be debated) 110 Information Exchange Framework Reference Architecture, Initial Submission

131 Table 48 - Save File Use Case Diagram Descriptions Manage Protected File When a user attempts to access a protected file, the IEF intercepts the request and assesses whether or not the user has policy rights to access the content of the requested file. If the user is authorized to see the contents of the file, the file is decrypted and opened in the tool selected by the user. Bind Markings to File Bind markings (meta-data, tags and labels) as file attributes to the persisted file. Persisting markings to a file will depend on the capabilities of the user's: - File Service; and/or - Records & Document Management Services (System) File PEP Class Diagrams The following clauses provide the Class diagrams for the File Share services. File PEP Class Diagram This PEP is intended to provide information protection for individual files as they are hosted on a IEF protected file share. For the File Sharing PEP, the granularity of the data centric security model is taken to the individual file level. The File Sharing PEP requires that files have a security marking. Therefore, the user must ensure that any files sent to the File Sharing PEP are marked: Information Exchange Framework Reference Architecture, Initial Submission 111

132 Figure 1 -File PEP Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 49 File PEP Class Diagram Descriptions IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. The information exchange protocol conforms to industry accepted, open standards that are based on XML(e.g., extensible Messaging and Presence Protocol (XMPP)). The messaging services/infrastructure) provisions information (messages) between IEF services /components). Although the specific protocol, format and content of the messages will depend on the nature of service being accessed, all messages are delivered through the same communications mechanism. The ability to provide robust, secure and trusted delivery of security messages between IEF services forms the critical core of the IEF architecture. 112 Information Exchange Framework Reference Architecture, Initial Submission

133 Table 49 File PEP Class Diagram Descriptions IEF Secure Messaging Service Operations: IEF Secure Messaging Service SecureAssetContainer An envelope that allows some unprotected information to exist outside of the protected (encrypted) payload. In addition to the encrypted payload, the envelope includes: The key token that is used as a reference to the actual key (stored in the key escrow system) that was used to protect the payload; A hash digest to detect tampering of the container contents; The original file name of the information asset; and A copy of the security marking on the information asset as it existed when the IEF originally protected the asset: a copy of the original asset security marking. SecureAssetContainer Operations: SecureFileShare SecureAssetContainer hashdigest: All SAC's include a digest that is calculated at creation time that is used to detect tampering of the container upon decryption. The digest is calculated using the SHA- 512 hash algorithm. Digest calculation is dependent on the order in which the source material is submitted for the calculation. For SAC's, the digest is calculated as follows: 1. The contents of the encrypted file; 2. The caveat for the original file; 3. The token for the key; 4. The filename of the original file; and 5. The key used to encrypt the original file. keytoken: When a request to decrypt the file is received, the container is opened and the keytoken is extracted. This is then used to retrieve the key from the KMS. file: The filename of the original file The file share location that is to be protected by the File Sharing PEP is mounted in a staging area on the PEP s host file system. SecureFileShare Operations: SecureFileShare Trusted Logging Service The Trusted Logging Service (TLS) is one of the central IEF Security Services and is the key service for maintaining and demonstrating the integrity of IEF information protection processes.. The Trusted Log Files that are protected and stored though the TLS keep a transactional history of the policy decisions and access control enforcement across all IEF protected resources. Since all policy enforcement activities are recorded Information Exchange Framework Reference Architecture, Initial Submission 113

134 Table 49 File PEP Class Diagram Descriptions within the TLS and the integrity of the TLS can be demonstrated, the TLS can be used to track information access requests and the rationale for why information was disclosed to IEF users. Trusted Logging Service Operations: Trusted Logging Service FileMarker Software service that integrates with an off-the-shelf file manager, file browser or office application which obliges and enables an authorized user to appropriately mark files. FileMarker Operations: FileMarker File PEP The File PEP operates between the FileManager client and the File Share (server). The PEP intercepts each request, determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the files involved. The File PEP is intended to provide information protection for individual files as they are hosted on a protected file share. The File PEP requires that files have the appropriate security markings. The File PEP intercepts each user request to the File Share. The PEP then verifies that the user has the authorizations to perform the operation and that the operation is permitted for the information asset on the designated device(s). If the User has the authorizations (policy-rights) the request is relayed to the file server for execution. File PEP Operations: File PEP Authorization Service Part of policy Decision Point, the Authorization Service determines whether or not a user can access, use or release information in the manner requested. This service acquires/gathers: The applicable ISS policies; The data/information markings (e.g., metadata, tags, labels, caveats, restrictions); The user attributes (e.g., policy rights, access rights, roles, location, and status); and The source and target resources' attributes (e.g., processing rights and restrictions). The service gathers information about the user, the recipients, the information asset(s), and the resources involved in the actions, and determines if the user/recipients have the rights to perform the requested action. The service then returns its decision to the Policy Enforcement Point(PEP) to execute the decision. The PDP possible responses include: Permit (action is permitted), Deny (action is denied) or Error. 114 Information Exchange Framework Reference Architecture, Initial Submission

135 Table 49 File PEP Class Diagram Descriptions Authorization Service Operations: Authorization Service FileShareProxy Cryptographic Transformation Service The PolicyEnforcementDataIntercept (PEDI) of a File PEP provides a File Share Proxy that intercepts each file request and response between the user and the file share/server. The proxy provides a locally mounted volume as a staging area where protected operations are performed. FileShareProxy Operations: FileShareProxy p1: The Cryptographic Transformation Service (CTS) provides the interface between the PEP and the user specified/provided cryptographic application(s) or appliance(s) that : Encrypt information assets; and Decrypt information assets for authorized users. The application of cryptographic services is dependent on the type of asset being protected. The CTS provides protection for the following data types: Files are encrypted when they are transferred from the user s workstation to the IEF protected file share and decrypted when they are retrieved from the file share for delivery to an authorized user. messages, including attachments, are encrypted when they are stored/prepared for delivery and decrypted when a user retrieves the from the server. IM messages are encrypted as they are exchanged by the IM server. Only when a user is permitted to enter a chat room are these message decrypted and delivered. Structured Message payloads and attachments are encrypted prior to release by an information dissemination service. Cryptographic Transformation Service Operations: Cryptographic Transformation Service Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Information Exchange Framework Reference Architecture, Initial Submission 115

136 Table 50 File PEP Class Diagram - Interface Descriptions File-Manager-Client- Interface The PEP itself provides an interface to IEF users, allowing access to the file staging location. In this way, a user can mount the File PEP and will see the files that are present on the FileShareServer. File-Server-Interface File-Manager-Client-Interface Operations: List_Files: Operation Parameters: Create_File: Operation Parameters: Open_File: Operation Parameters: Save_File: Operation Parameters: Copy_File: Operation Parameters: Cut_File: Operation Parameters: Paste_File: Operation Parameters: Move_File: Operation Parameters: Delete_File: Operation Parameters: Standard Interface to local (User specified/provided) services or set of services that provide a shared disk access (i.e. shared storage of computer files) that can be accessed by the users file managers and applications. The term server highlights the role of the machine in the client server scheme, where the clients are the users file browsers and applications. It is designed primarily to enable the storage and retrieval of data while the computation is carried out by the workstations. The IEF requires an unmodified file server as its protected file share. The IEF ensures that: Markings are bound to the files stored on the protected file share; and All files on the protected file share are appropriately encrypted. The IEF ensures that all actions (e.g., access, move, copy, delete, store) requested by a user are authorized and that all files are appropriately marked and encrypted at rest (when stored) and in motion. 116 Information Exchange Framework Reference Architecture, Initial Submission

137 Table 50 File PEP Class Diagram - Interface Descriptions File-Server-Interface Operations: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 51 File PEP Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Information Exchange Framework Reference Architecture, Initial Submission 117

138 Table 51 File PEP Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements File PEP Sequence Diagrams The following clauses provide the Sequence diagrams for the File Share PEP services. Copy File Sequence Diagram 118 Information Exchange Framework Reference Architecture, Initial Submission

139 Figure 1 -Copy File Sequence Diagram Table 52 - Copy File Sequence Diagram - Message Descriptions service response1 COPY REQUEST_USER_CR EDENTIALS POLICY_REQUEST Information Exchange Framework Reference Architecture, Initial Submission 119

140 Table 52 - Copy File Sequence Diagram - Message Descriptions service response COPY service response2 PROCESS_LOG_REC ORD EXTRACT_MARKING S Create File Sequence Diagram 120 Information Exchange Framework Reference Architecture, Initial Submission

141 interaction Create File Sequence Diagram [ Create File Sequence Diagram ] Figure 1 -Create File Sequence Diagram Table 53 - Create File Sequence Diagram - Message Descriptions Cut File Sequence Diagram Information Exchange Framework Reference Architecture, Initial Submission 121

142 Figure 1 -Cut File Sequence Diagram Table 54 - Cut File Sequence Diagram - Message Descriptions PROCESS_LOG_REC ORD service response service response2 122 Information Exchange Framework Reference Architecture, Initial Submission

143 Table 54 - Cut File Sequence Diagram - Message Descriptions REQUEST_USER_CR EDENTIALS CUT POLICY_REQUEST CUT EXTRACT_MARKING S service response1 Delete File Sequence Diagram Information Exchange Framework Reference Architecture, Initial Submission 123

144 interaction Delete File Sequence Diagram [ Delete File Sequence Diagram ] Figure 1 -Delete File Sequence Diagram Table 55 - Delete File Sequence Diagram - Message Descriptions List Files Sequence Diagram When the user s File Explorer requests a directory listing of the current directory (either automatically or directly by the user), the client software formulates a listing request and sends it to the File PEP. The FileShareProxy within the PEP allows this request to be forwarded to the FileShareServer, but intercepts (1) the listing as it is returned. At this stage, the File PEP has a complete list of the files in the target directory. The PEP examines each of the files in the list in sequence to determine if the presence of the file can be disclosed to the user. 124 Information Exchange Framework Reference Architecture, Initial Submission

145 Figure 1 -List Files Sequence Diagram Table 56 - List Files Sequence Diagram - Message Descriptions POLICY_REQUEST The PEP calls the AS with the user s identity, the security attributes of the file and the policy action to get a policy decision as to whether the user should be able to see the target file. Return Authorized List Once all files in the directory structure have been processed, the File PEP allows the (possibly reduced) directory structure to be returned to the user s Explorer session. The user will be unaware if any files have been scrubbed from the listing since the listing is filtered prior to delivery. This means that two different users will see different contents in a directory depending on each user s COI membership and the security policy that was used to authorize the action. Service Response a. If the AS states that the policy decision is to permit the user to see the file, the target file is allowed to stay in the directory listing data structure. b. If the policy decision is to deny the action, the target file is removed Information Exchange Framework Reference Architecture, Initial Submission 125

146 Table 56 - List Files Sequence Diagram - Message Descriptions from the directory listing data structure. Listing Returned The File PEP intercepts the file listing returned from the FileShareServer. REQUEST_USER_CR EDENTIALS Get the users access rights. DIR() The FileShareProxy within the PEP allows this request to be forwarded to the FileShareServer PROCESS_LOG_REC ORD An log file record is generated by the PEP and sent to the TLS to be added to the AuditableLogRepository. DIR Extract Markings The PEP calls the SMS to extract the security attributes on the target file(s). 126 Information Exchange Framework Reference Architecture, Initial Submission

147 Table 56 - List Files Sequence Diagram - Message Descriptions Service Response Service Response Move File Sequence Diagram Figure 1 -Move File Sequence Diagram Table 57 - Move File Sequence Diagram - Message Descriptions service response Information Exchange Framework Reference Architecture, Initial Submission 127

148 Table 57 - Move File Sequence Diagram - Message Descriptions PROCESS_LOG_REC ORD MOVE REQUEST_USER_CR EDENTIALS service response MOVE service response EXTRACT_MARKING S 128 Information Exchange Framework Reference Architecture, Initial Submission

149 Table 57 - Move File Sequence Diagram - Message Descriptions POLICY_REQUEST Open File Sequence Diagram interaction Open File Sequence Diagram [ Open File Sequence Diagram ] Figure 1 -Open File Sequence Diagram Table 58 - Open File Sequence Diagram - Message Descriptions Paste File Sequence Diagram Information Exchange Framework Reference Architecture, Initial Submission 129

150 interaction Paste File Sequence Diagram [ Paste File Sequence Diagram ] Figure 1 -Paste File Sequence Diagram Table 59 - Paste File Sequence Diagram - Message Descriptions Retrieve File Sequence Diagram When a user requests a file from a protected file share, the File PEP will execute the information protection logic in accordance with the following sequence diagram. 130 Information Exchange Framework Reference Architecture, Initial Submission

151 Figure 1 -Retrieve File Sequence Diagram Table 60 - Retrieve File Sequence Diagram - Message Descriptions RETURN DECRYPTED FILE PROCESS_LOG_REC ORD Service Response Information Exchange Framework Reference Architecture, Initial Submission 131

152 Table 60 - Retrieve File Sequence Diagram - Message Descriptions OPEN RETRIEVE_KEY POLICY_REQUEST The user s identity, the security attribute from the file and the policy action of READ are sent to the AS in a policy request message Extract_File_Markings Through a call to the SMS the PEP acquires the security attributes on this working file. Service Response Service Response 132 Information Exchange Framework Reference Architecture, Initial Submission

153 Table 60 - Retrieve File Sequence Diagram - Message Descriptions If the file has been authorized for disclosure (the security policy permits the release of the information and there have been no errors in processing the request), the file is delivered to the user s workstation. REQUEST_USER_CR EDENTIALS The AS itself sends the IMS a user security attribute request to acquire the user s COI membership list from the user security attribute repository. This information is used as part of the policy decision-making process. Service Response The policy decision is to allow the file to be disclosed to the user. Service Response FILE_DECRYPT_TOK EN The PEP calls the CTS to decrypt the file. EXTRACT_MARKING S Through a second call to the SMS, the PEP acquires the security attributes on the decrypted file. Since the security attributes in the container were taken from the security attributes from the original file when the container was created, the file s attributes and the container s copy of the attributes should match. If there is a mismatch, the container has been tampered with and the file should not be disclosed to the user. Information Exchange Framework Reference Architecture, Initial Submission 133

154 Table 60 - Retrieve File Sequence Diagram - Message Descriptions Save File Sequence Diagram When a user stores a file to the back end file share, either by copying the file or saving an active file to that location, the File PEP will execute the process shown in the following diagram. Figure 1 -Save File Sequence Diagram Table 61 - Save File Sequence Diagram - Message Descriptions Service Response Service Response 134 Information Exchange Framework Reference Architecture, Initial Submission

155 Table 61 - Save File Sequence Diagram - Message Descriptions Service Response GENERATE_STORE The CTS will leverage the KMS to obtain a new symmetric key for the operation and store this key in the escrow system. SAVE/COPY Once the container has been successfully created, the PEP will move the container from the staging area and store it at the FileShareServe. The file data is allowed to be uploaded to the PEP and the PEP places the file in a local staging area. EXTRACT_MARKING S The PEP calls the SMS to acquire the security attributes on this local file. Note that this means that the file must be properly marked at the endpoint before it is sent to the PEP. Service Response Information Exchange Framework Reference Architecture, Initial Submission 135

156 Table 61 - Save File Sequence Diagram - Message Descriptions Service Response With this new key, the file is encrypted and placed in a container. The container is also populated with the other data elements namely, the caveat, the digest and the token. FILE_ENCRYPT_TOK EN PROCESS_LOG_REC ORD The PEP will then create an log file record that specifies the file store transaction details and send the record to the TLS to create a permanent record of the transaction. REQUEST_USER_CR EDENTIALS The AS itself sends the IMS a user security attribute request in order to acquire the user s COI membership list from the user security attribute repository. This information is used as part of the policy decision-making process. POLICY_REQUEST The PEP determines if the user has the policy based right to create protected content using the security attributes on the file. The user s identity, the security attributes from the file and the policy action of WRITE are sent to the AS in a policy request message 136 Information Exchange Framework Reference Architecture, Initial Submission

157 11.4 Instant Messaging PEP The Instant Messaging (IM), intercepts each message as it transits between the IM client and the IM server. The IM PEP enables users to establish a secure chat room that protects each message level. Each chat room is assigned a set of markings and a unique symmetric key for that room. Each participant in the chat room must have the policy rights to access the chat-room. The IM PEP can also protect an individual messages. A user can mark a message for special handling and limit access to selected users. These messages are assigned separate markings and are protected with their own unique symmetric key. The IM PEP provides the following user operations: Chat Room Listing; Join Chat Room; Receiving a message; Sending a message; Sending a special message; and Receiving a marked up message Instant Messaging Use Cases The following clauses provide the Use Case diagrams for Instant Messaging PEP services. List and Join Chat Use Case Diagram When a user connects to the IM server, through the IM PEP, and requests a list of chat rooms, the list is vetted to ensure that only those rooms to which a user has the policy right to access are presented to the user. When a user requests access to a chat room, a similar policy check is made to ensure that the user has the policy right to access the room. Typically the IM server will send a brief history of recent messages. These messages are handled as described below. Information Exchange Framework Reference Architecture, Initial Submission 137

158 Figure 26 -List and Join Chat Use Case Diagram Table 62 - List and Join Chat Use Case Diagram Descriptions Interact with Instant Messaging Services Generalization of the use cases that define the interaction between the user and the IM client. The IEF intercepts these interactions and authorizes each transaction. Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Request Current Chat Rooms Request a list of active chat rooms and their markings on the IM server. Create Chat Room When a user attempts to create a chat room, the IEF intercepts the request and authorizes each step in the process. 138 Information Exchange Framework Reference Architecture, Initial Submission

159 Table 62 - List and Join Chat Use Case Diagram Descriptions Authorize User to Create Chat Room When a user requests the creation of a chat room, intercept the request and verify the Users policy rights to create the chat room. Redact Chat Room List Set the Markings for a Chat Room When a user requests a list of IM/Chat rooms that are active, the request is intercepted and the list limited to only chat rooms that the user has the policy rights to join. If the user is not authorized to join the chat room, remove the chat room from the list of available chat rooms. Prompt the user to set the security and privacy markings, constraints and warning orders for the chat room. Authorize User to Join Chat room Verify the Users policy rights to join the chat room. Join Chat Room List Chat Rooms Identify Chat Room Participants Each time a user requests access to a chat room, the IEF verifies the user s policy rights to access the chat room and share information at that room s sensitivity level. The IEF presents a redacted list of chat rooms to each user. When a user connects to the Instant Messaging Server protected by the IEF and requests a list of available chat rooms, the IEF provides a list identifying only the rooms that the user has the policy right to access. Mark a chat room such that only listed users may join. Receive IM Use Case Diagram For normal (non-marked up messages) there is no need to do policy checks against each message since: All messages inherit the security attributes of the room; and The user has been granted access to the room, given the room s security attributes. Therefore the user will have inherent rights to see these messages. Messages are automatically decrypted and delivered to the recipient. When the IM server attempts to deliver a marked-up message to a chat room participant, it calls the AS to ensure that the user has the policy right to access information with this security label. If permitted, the IEF decrypt the message, using the unique chat room/caveat combination to retrieve the key for this operation. The decrypted message is then delivered to the user. Information Exchange Framework Reference Architecture, Initial Submission 139

160 Figure 27 -Receive IM Use Case Diagram Table 63 - Receive IM Use Case Diagram Descriptions Interact with Instant Messaging Services Generalization of the use cases that define the interaction between the user and the IM client. The IEF intercepts these interactions and authorizes each transaction. Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Receive Instant Message When an Instant Messaging Server attempts to deliver a message it is intercepted and if the message has no special marks, there is no need to re-authorize the exchange since: - All messages inherit the security attributes of the room; - All messages are encrypted at-rest and in-motion; and - The user has been granted access to the chat-room and assigned room s security attributes. The users' authorization to see and join the chat room confers the inherent rights to see these messages. The IEF will engage the local (user specified) escrow services 140 Information Exchange Framework Reference Architecture, Initial Submission

161 Table 63 - Receive IM Use Case Diagram Descriptions to retrieve the key and decrypt the received message. Receive Marked Instant Message When the IM PEP receives an IM message possessing special marks, it intercepts the message and verifies that the recipient has the policy rights to access the contents of the specially marked information. If the receiver is authorized to receive the message content, the unique chat room/caveat combination key is requested from the escrow server. The message is then decrypted and delivered to the user. Even though the user had access to join the chat room, specially marked messages may not be delivered unless the user has the special access attributes required. Un-authorized users are not provided any indication that the specially marked message was exchanged. Decrypt Specially Marked Instant Message Decrypt Instant Message Authorize IM Recipient Obtain the special key token from the Instant Messaging chat-room for messages with the specific marks. If the recipient is authorized to access the contents, transform the information content of an instant message back into its original form using the unique symmetric key retrieved from escrow. Transform the information content of an instant message back into its original form using the unique symmetric key retrieved from escrow. Verify that the user has the policy rights to access the IM or chat room and receive the instant messages. Verify that a user is authorized to receive and access the specific information element via IM services. If the user's rights are verified, grant access to the user and release the information element. The recipient is verified at both release and receipt of the information. Note: Authorization is performed once for messages that have standard markings for the chat room; the users policy right to join the room provides policy rights to this information. Each user (participant) is authorized independently, for each specially marked message Send IM Use Case Diagram When a user sends an IM message, the message is intercepted by the IM PEP and encrypted so that it is stored in a protected form at the IM server. The room s cryptographic key is retrieved from the escrow and used to encrypt the message that is then sent to the IM server for delivery to all room participants. Sending a marked up message: A marked up message must be protected inside a virtual private room with the room having its own access control and key management. When the IM PEP receives a marked-up message it extracts the caveat from the message. The IEF ensures that the user has the policy right to send data with this security attribute. If the action in permitted, the IEF requests a new key for this chat Information Exchange Framework Reference Architecture, Initial Submission 141

162 room/caveat combination, encrypts the message and sends the protected message to the IM server for delivery to all authorized chat room participant(s). Figure 28 -Send IM Use Case Diagram Table 64 - Send IM Use Case Diagram Descriptions Interact with Instant Messaging Services Generalization of the use cases that define the interaction between the user and the IM client. The IEF intercepts these interactions and authorizes each transaction. Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Send Marked Instant Message A marked-up message is protected within the virtual private chat-room with the room having its own access control and key management. When the IEF intercepts a marked-up message, it extracts the markings from the message. The PEP must then check the users policy rights for authorization to send the content. If the action is permitted, the IEF completes the release of the information in a normal 142 Information Exchange Framework Reference Architecture, Initial Submission

163 Table 64 - Send IM Use Case Diagram Descriptions fashion. (see "Send Information Message"). However, in this case, the message is encrypted using a unique key for a message bound with the specific marks. Encrypt Marked Instant Message Encrypt Instant Message Redact Instant Message Gather Attachments Send Instant Message Route Instant Message Transform the information content of an instant message into a form that in unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each specially marked message is encrypted using its own unique symmetric key. The IM PEP must obtain the special key in order to provide the initial encryption and then must register the key s token with the Instant Messaging chat-room for cryptographic operations on future messages with the same specific marks. Transform the information content of an instant message into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each IM message within a chat-room is encrypted using the chat-room's own unique symmetric key. When a user sends a specially marked instant message it is intercepted, to assure that the message and any attachments can be sent by the user to the specific IM chatroom. If the access rights of the user or the attributes of the IM/Chat room do not allow the exchange, the unauthorized elements may be removed and the IM sent. Gather the set of attachments, including markings, the user linked to the . If an attachment is not marked, prompted the user to set the markings. When a user, through the chat client, sends an Instant Message, the message is intercepted and encrypted so that it is stored and exchanged in a protected form by the Instant Messaging server. Authorize Chat Room Authorize IM Sender Verify that the IM chat room has the correct security attributes to transport Information elements with the specific markings. Verify that the user has the policy rights to access the IM or chat room and send the instant messages. Verify that the user has the policy rights to release or publish information bound with the specific markings via instant messaging through the specified chat-room Instant Messaging Class Diagrams The following clauses provide the Class diagrams for Instant Messaging Sequence services. Information Exchange Framework Reference Architecture, Initial Submission 143

164 IM PEP Class Diagram The IEF provides and interface layer between standard IM clients and servers. The granularity of protection is at the chat room level. Meaning, each chat room is assigned default security attributes (e.g., security level, caveat and restrictions) and messages in each chat room are protected through a unique symmetric key for that room. However, a user can also protect individual messages, isolating it to particular users within the chat room. A user can mark up or flag a message for special handling. These messages are assigned separate security attributes and are protected with their own unique symmetric key. Users must have a policy based right to access a chat room, given the chat room s security marking, before access to the room is granted. Once in the chat room, all normal messages are delivered to the user, but marked-up message are delivered only if the user has the access right to see data with the associated security attributes. For peer-to-peer chat or IM sessions, a user would establish a chat room that only provides access to the other participant. Figure 1 -IM PEP Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 65 IM PEP Class Diagram Descriptions IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes 144 Information Exchange Framework Reference Architecture, Initial Submission

165 Table 65 IM PEP Class Diagram Descriptions and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. The information exchange protocol conforms to industry accepted, open standards that are based on XML(e.g., extensible Messaging and Presence Protocol (XMPP)). The messaging services/infrastructure) provisions information (messages) between IEF services /components). Although the specific protocol, format and content of the messages will depend on the nature of service being accessed, all messages are delivered through the same communications mechanism. The ability to provide robust, secure and trusted delivery of security messages between IEF services forms the critical core of the IEF architecture. IEF Secure Messaging Service Operations: IEF Secure Messaging Service ImMarker As a component of the IM PEP, the IM Marker sets the security markings for each chat room. Chat rooms must be initialized before they can be made available to IEF users. The initialization process is performed by the IMMarker that creates/initiates a chat room by: 1. Assigning the new chat room to a COI (the default community); 2. Setting the markings at the chat room; and 3. Acquiring a new cryptographic key that will be used to protect messages in the chat room. The IMMarker places the default COI and key token within the description field for the chat room as it is defined at the IM server ImMarker Operations: Trusted Logging Service ImMarker unnamed1: The Trusted Logging Service (TLS) is one of the central IEF Security Services and is the key service for maintaining and demonstrating the integrity of IEF information protection processes.. The Trusted Log Files that are protected and stored though the TLS keep a transactional history of the policy decisions and access control enforcement across all IEF protected resources. Since all policy enforcement activities are recorded within the TLS and the integrity of the TLS can be demonstrated, the TLS can be used to track information access requests and the rationale for why information was disclosed to IEF users. Trusted Logging Service Operations: Information Exchange Framework Reference Architecture, Initial Submission 145

166 Table 65 IM PEP Class Diagram Descriptions IM Proxy Trusted Logging Service Provides a means to connect to a protected IM Server so that messages stored in a protected chatroom s message store may be unencrypted and delivered to the user. The IM Proxy intercepts each IM message the user (IM Client) and the IM server share. It routes the message, requests and responses, to the IM PEP to perform the ISS processing logic and ensure that IM messages adhere the ISS policies. IM Proxy Operations: IM Proxy Authorization Service Part of policy Decision Point, the Authorization Service determines whether or not a user can access, use or release information in the manner requested. This service acquires/gathers: The applicable ISS policies; The data/information markings (e.g., metadata, tags, labels, caveats, restrictions); The user attributes (e.g., policy rights, access rights, roles, location, and status); and The source and target resources' attributes (e.g., processing rights and restrictions). The service gathers information about the user, the recipients, the information asset(s), and the resources involved in the actions, and determines if the user/recipients have the rights to perform the requested action. The service then returns its decision to the Policy Enforcement Point(PEP) to execute the decision. The PDP possible responses include: Permit (action is permitted), Deny (action is denied) or Error. Authorization Service Operations: Authorization Service IM PEP The IM PEP operates between the IM-Client and the IM server. The PEP intercepts each request\response and determines if the user has the authorizations (policy-rights) to perform the requested action given sensitivities of the chatroom involved. The IM PEP mediates access to chat rooms and protects messages as they reside at IM server. In normal operations, the granularity of the safeguards is at the level of the chat room. That is, each chat room is assigned security attributes and it is those attributes that are used in the access control checks. For the IM PEP, security attributes are stored as part of the chat room s description and are stored in the IM server s database. User s also have the option to mark-up specific messages within a chat room. That is, the user can apply security attributes (COIs) to individual messages. Marked-up messages are handled slightly differently than normal chat room messages. When the IM PEP receives a marked up message, the message must be 146 Information Exchange Framework Reference Architecture, Initial Submission

167 Table 65 IM PEP Class Diagram Descriptions individually checked against the policy. Users must have the policy-rights to create content using the specified attribute, or COI, for the IM PEP to allow the message to be added to the history of chat room messages. Similarly, when a user receives IM messages, individual marked up messages must be evaluated against the security policy to ensure that they have the right to receive the message. Marked up messages, therefore, may only be deliverable to a subset of the users that have already been granted access to the chat room IM PEP Operations: List_Char_Rooms: Operation Parameters: Join_Chat_Room: Operation Parameters: Accept_Client_Connection: Operation Parameters: Send_Message: Operation Parameters: Receive_Messaage: Operation Parameters: IM PEP Cryptographic Transformation Service The Cryptographic Transformation Service (CTS) provides the interface between the PEP and the user specified/provided cryptographic application(s) or appliance(s) that : Encrypt information assets; and Decrypt information assets for authorized users. The application of cryptographic services is dependent on the type of asset being protected. The CTS provides protection for the following data types: Files are encrypted when they are transferred from the user s workstation to the IEF protected file share and decrypted when they are retrieved from the file share for delivery to an authorized user. messages, including attachments, are encrypted when they are stored/prepared for delivery and decrypted when a user retrieves the from the server. IM messages are encrypted as they are exchanged by the IM server. Only when a user is permitted to enter a chat room are these message decrypted and delivered. Structured Message payloads and attachments are encrypted prior to release by an information dissemination service. Cryptographic Transformation Service Operations: Information Exchange Framework Reference Architecture, Initial Submission 147

168 Table 65 IM PEP Class Diagram Descriptions Cryptographic Transformation Service Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 66 IM PEP Class Diagram - Interface Descriptions IM Server Interface IM Server Interface Operations: IM Client Interface IM Client Interface Operations: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 67 IM PEP Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements 148 Information Exchange Framework Reference Architecture, Initial Submission

169 Table 67 IM PEP Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements The IM PEP is implemented as a proxy architecture. Owner: IEF Service Elements Sequence Diagrams The following clauses provide the Sequence diagrams for Instant Messaging PEP Services. List Chat Rooms Sequence Diagram For each chat room in the list, the IM PEP calls the AS to determine if the user has a policy based right to see that room. Information Exchange Framework Reference Architecture, Initial Submission 149

170 Figure 1 -List Chat Rooms Sequence Diagram Table 68 - List Chat Rooms Sequence Diagram - Message Descriptions forward The IM PEP forwards this request (unmodified) on to the back end IM server. filtered list The filtered list of available chat rooms that the user has a policy based right to see is returned to the user s IM client. service response If the policy decision is to permit the user to see the chat room, the chat room is allowed to remain in the chat room list that is returned to the user s IM client, otherwise, the chat room is removed from the list. 150 Information Exchange Framework Reference Architecture, Initial Submission

171 Table 68 - List Chat Rooms Sequence Diagram - Message Descriptions REQUEST_USER_CR EDENTIALS PROCESS_LOG_REC ORD For each policy decision, the IM PEP will create a log file record, that specifies the IM chat room list operation details and send the record to the TLS to create a permanent record of the transaction. POLICY_REQUEST For each chat room in the list, the PEP calls the AS to determine if the user has the policy based right to see that room. The PEP formulates and sends a policy request message to the AS. In this message, the user s identity is taken from the IM session and the resource is the default COI for the chat room as specified in the local data structure (cache) for chat room security attributes. service response The IM server returns the list of chat rooms to the PEP where the PEP will filter the list according to the security policy. ACCEPT_CLIENT_CO NNECTION The IM client sends a discovery message that requests the list of available MUC rooms (multi-user chat). LIST_CHAT_ROOMS Information Exchange Framework Reference Architecture, Initial Submission 151

172 Table 68 - List Chat Rooms Sequence Diagram - Message Descriptions service response Join Chat Room Sequence Diagram Once a user has connected to the IM PEP, they can request to join a protected chat room. Figure 1 -Join Chat Room Sequence Diagram Table 69 - Join Chat Room Sequence Diagram - Message Descriptions service response 152 Information Exchange Framework Reference Architecture, Initial Submission

173 Table 69 - Join Chat Room Sequence Diagram - Message Descriptions PROCESS_LOG_REC ORD For each policy decision, the IM PEP will create a log file record that specifies the IM chat room join operation details and send the record to the TLS to create a permanent record of the transaction. service response JOIN_CHAT_ROOM REQUEST_USER_CR EDENTIALS JOIN If the policy decision was permit, the user is allowed to enter the chat room, otherwise, the messaging session with the chat room is not established and the user cannot send messages to or receive messages from the chat room. POLICY_REQUEST The PEP calls the AS to determine if the user has the policy based right to join that room. The PEP formulates and sends a policy request message to the AS. In this message, the user s identity is taken from the IM session and the resource is the default COI for the chat room as specified in the local data structure for chat room security attributes. Information Exchange Framework Reference Architecture, Initial Submission 153

174 Table 69 - Join Chat Room Sequence Diagram - Message Descriptions The user sends a request to join a chat room and the IM PEP intercepts this join request. Send IM Sequence Diagram In order for a user to be able to send a message to a chat room, that user must already have joined the chat room. Joining a chat room through the IM PEP implies that the user was granted access to the chat room after a security policy check was made to ensure that the user has the policy right to access the chat room s content. Therefore, it is not necessary to perform a policy check on individual messages since the user s participation in the chat room already implies that they have the policy right to send messages through the chat room. Figure 1 -Send IM Sequence Diagram 154 Information Exchange Framework Reference Architecture, Initial Submission

175 Table 70 - Send IM Sequence Diagram - Message Descriptions SEND_MESSAGE User sends a message to the IM server; the IM PEP intercepts the message. The IM PEP writes the message content out to a working file in the local staging area on the PEP machine. POST The PEP transmits this newly protected message to the IM server. RETRIEVE_KEY The CTS will leverage the KMS to retrieve the key for this chat room. FILE_ENCRYPT_TOK EN The PEP calls the CTS to encrypt the message in the working file. When the IM PEP was started, the PEP retrieved the security attributes for the chat room, including the key token that references the key that is to be used to encrypt this chat room s messages. ACCEPT_CLIENT_CO NNECTION service response The CTS encrypts the working file to create an encrypted version. service response Information Exchange Framework Reference Architecture, Initial Submission 155

176 Table 70 - Send IM Sequence Diagram - Message Descriptions Send Special Message Sequence Diagram Figure 1 -Send Special Message Sequence Diagram Table 71 - Send Special Message Sequence Diagram - Message Descriptions service response service response The IM PEP checks the local cache to see if there is a key token for this chat room/coi combination. If no such key exists, this is the first time this 156 Information Exchange Framework Reference Architecture, Initial Submission

177 Table 71 - Send Special Message Sequence Diagram - Message Descriptions COI will have been used in this chat room and a new key must be generated to protect these messages. service response The CTS then encrypts the working file. SEND The encrypted message is sent to the IM server with the COI data prepended (unencrypted) to the message. POLICY_REQUEST The PEP calls the AS to determine if the user has the policy based right to send a message that has been marked up with that COI. The PEP formulates and sends a policy request message to the AS. In this message, the user s identity is taken from the IM session, the resource is the marked up COI in the message service response SEND_MESSAGE The user sends a marked-up message to the IM Server and the IM PEP intercepts the message. The PEP detects that this is a marked up message by parsing the message and determining the COI that should be applied to this message. The IM PEP writes the message content out (including the marked up text) to a working file in the local staging area on the PEP machine. Information Exchange Framework Reference Architecture, Initial Submission 157

178 Table 71 - Send Special Message Sequence Diagram - Message Descriptions UPDATE This key token must be stored at the IM Server so that there is a permanent record of the chat room / COI key token. Recall that when the IM PEP starts, it reads (in an OOB message exchange) the security attributes for all protected chat rooms. If a new key has been generated by the PEP, the associated key token must be sent to the IM Server so that the mapping of chat room / COI to key token can be retrieved the next time the IM PEP is started. The updated security attributes for the chat room is sent to the IM Server PROCESS_LOG_REC ORD The IM PEP will create a log file record that specifies the marked up message operation details and send the record to the TLS to create a permanent record of the transaction. REQUEST_USER_CR EDENTIALS RETRIEVE_KEY The CTS, in turn, will leverage the KMS to retrieve the key associated with this key token. FILE_ENCRYPT_TOK EN The PEP calls the CTS to encrypt the message in the working file. The operation requested from the CTS is to encrypt the working file using the key token supplied in the request (FILE_ENCRYPT_TOKEN). service response 158 Information Exchange Framework Reference Architecture, Initial Submission

179 Table 71 - Send Special Message Sequence Diagram - Message Descriptions GENERATE_STORE The PEP requests a new key from the KMS. In this exchange, the KMS will create a new key, store the key in the escrow system and return the key token to the IM PEP. At the end of this exchange, there is now a key available to protect the message. Receive IM Sequence Diagram Figure 1 -Receive IM Sequence Diagram Information Exchange Framework Reference Architecture, Initial Submission 159

180 Table 72 - Receive IM Sequence Diagram - Message Descriptions RECEIVE_MESSAGE The IM server sends a message to the user s IM client. The IM PEP writes the message content out to a working file in the local staging area on the PEP machine. The PEP will decode the message to restore the object as it was encrypted by the PEP when it was sent. service response The CTS decrypts the working file to create a decrypted version. The PEP reads in the decrypted working file and replaces the plaintext text in the message with the decrypted text. RETRIEVE_KEY The CTS will leverage the KMS to retrieve the key for this chat room. service response FILE_DECRYPT_TOK EN The PEP calls the CTS to decrypt the message in the working file. When the IM PEP was started, the PEP retrieved the security attributes for the chat room, including the key token that references the key that is to be used to encrypt this chat room s messages. RECEIVED The PEP transmits this newly released message to the user s IM client. 160 Information Exchange Framework Reference Architecture, Initial Submission

181 Receive Special Message Sequence Diagram When a chat room message is sent from the IM server to a chat room participant, the IM PEP examines the message to determine if it is a marked up message. If the message is not marked up, the IM PEP will treat the message as a normal encrypted message. If the message is a marked up message, however, the process described in the following diagram is followed: Figure 1 -Receive Special Message Sequence Diagram Table 73 - Receive Special Message Sequence Diagram - Message Descriptions servive response POLICY_REQUEST The PEP calls the AS to determine if the user has the policy based right to receive a message that has been marked up with that COI. The PEP formulates and sends a policy request message to the AS.In this message, the user s identity is taken from the IM session, the resource is the marked up COI in the message. Information Exchange Framework Reference Architecture, Initial Submission 161

182 Table 73 - Receive Special Message Sequence Diagram - Message Descriptions RETRIEVE_KEY The call to the CTS includes the key token for the message so that the CTS can request the appropriate key from the KMS with which to apply the cryptographic transformation. PROCESS_LOG_REC ORD The IM PEP will create a log file record that specifies the marked up message operation details and send the record to the TLS to create a permanent record of the transaction. DELIVER The PEP reads in the decrypted working file and replaces the plaintext text in the message with the decrypted text. The PEP transmits this newly released message to the user s IM client. DELIVER The IM PEP intercepts the chat room message as it is sent from the IM Server to the chat room participant. The IM PEP examines the message to see if it is marked up and, if so, extracts the COI from the message. The PEP writes out the encrypted portion of the message, that is, everything after the prepended COI information and base 64 decodes the message to get the originally encrypted content from when the message was sent. FILE_DECRYPT_TOK EN Using the local cache of chat room security attributes, the key token for this chat room/coi combination is used in a call to the CTS to decrypt the protected message. 162 Information Exchange Framework Reference Architecture, Initial Submission

183 Table 73 - Receive Special Message Sequence Diagram - Message Descriptions REQUEST_USER_CR EDENTIALS service response service response service response 11.5 Session Directed Messaging PEP The Session Directed Messaging PEP intercepts messages transiting between a user application and message/data centric dissemination services (e.g., DDS, Message Bus, or Web Service), of which, the PEP and PDP do not have the identity and the specific users participating in, or subscribing to the communication channel. The PEP relies on the security built into the underlying channel infrastructure (e.g., Secure DDS) to assure that only authorized users are provided access to subscribe to information released (/published) to the channel (e.g., DDS Topic). In this case the PDP determines if the User has the authorizations to release the specific information asset (/information content) to the specific session (IEF interface to a channels dissemination infrastructure) and that the specific session has the policy-the PDPs decision is then enforced by the PEP Session Directed Messaging Use Cases The following clauses provide the Use Case diagrams for Session Directed Messaging PEP services. Information Exchange Framework Reference Architecture, Initial Submission 163

184 Send Session Directed Message Use Case Diagram Figure 29 -Send Session Directed Message Use Case Diagram Table 74 - Send Session Directed Message Use Case Diagram Descriptions Apply Exchange Protocol Log Transaction Following the assembly of a releasable data set, structure and format the data in accordance with the specified protocol (e.g., NIEM XSD, MIP PDU, EDXL XSD, or CAP XSD.) prescribed by policy. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Authorize Structured Message Recipient Check that the recipient(s) have the policy rights to receive information with the security/sensitivity classification of the marked structured message and if they do provide the authorization. 164 Information Exchange Framework Reference Architecture, Initial Submission

185 Table 74 - Send Session Directed Message Use Case Diagram Descriptions Send Structured Message to Information Exchange Services Once message has been fully authorized discover the delegated exchange mechanism and forward the message to the service(s) Prescribe Exchange Participation Verify the set of authorized exchanges that this message may be sent over. Authorize Structured Message Sender Obtain Packaging Profile Load Policies Package Structured Message Check that the sender has the policy rights to send information with the security/sensitivity classification of the marked structured message and provide authorization if they do. Obtain, from the local policy store, the packaging protocol for the information element. These profiles define the structure and format for the information exchange element (e.g., , text message, structured message, web exchange). On the instruction of an authorized PAP, or authorized PDP Service, load a policy or set of policies into active memory of the PDP. If authorized, the PDPs can load and activate policies from a local policy store. Assemble and format a structured-message in accordance with exchange policies specified in an information exchange specification (see IEPPV). Authorize Information Dissemination Service Verify that an information dissemination service is authorized to transport the content of the specific information element. Authorization is based on the channel's security attributes and the markings (e.g., classifications and restrictions, and warnings) bound to each information element. If the channel attributes are verified, grant release of the information element to the service.. Receive Message Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 165

186 Figure 30 -Receive Message Use Case Diagram Table 75 - Receive Message Use Case Diagram Descriptions Initiate Information Exchange If the processing of the Structured Message results in the successful construction of a Semantic Element and an obligation to share the Semantic exists, trigger an information exchange. Marshall Data Elements Log Transaction After validating the received data and enforcing completeness rules as per active policy, persist the data to local Information Store. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Authorize Structured Message Recipient Process Structured Message Check that the recipient(s) have the policy rights to receive information with the security/sensitivity classification of the marked structured message and if they do provide the authorization. On receipt of a structured message the IEF first extracts the markings (metadata)from the message and then validates the policy rights of the user to receive the message and if the user has appropriate rights: 166 Information Exchange Framework Reference Architecture, Initial Submission

187 Table 75 - Receive Message Use Case Diagram Descriptions Parses the message and extracts each of the attachments to the message; each of the information packages, information elements and data elements; Prepares the information and data elements for processing and marshaling to the local data stores. Receive Structured Message From Information Exchange Service Employ a Data Assembly Service to provide processing of received structured messages. The Service will provide structured data aggregation according to active policies. Store Attachments By employing a File PEP save any file attachments to a protected file share. Identify Completed Watchpoints Based on the presence of any WatchPoint records found in the inbound message, aggregate the received data using the set of associated Transactional and Semantic patterns. If any of these are built successfully check the obligations to replicate the data Class Diagrams The following clauses provide the Class diagrams for Session Directed Messaging PEP services Session Directed Messaging PEP Class Diagram package Policy Enforcement Point Class Diagrams [ Session Directed Messaging PEP Class Diagram ] Session Directed Messaging PEP Information Exchange Framework Reference Architecture, Initial Submission 167

188 Figure 1 -Session Directed Messaging PEP Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 76 Session Directed Messaging PEP Class Diagram Descriptions Session Directed Messaging PEP Session Directed Messaging PEP Operations: Session Directed Messaging PEP Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 77 Session Directed Messaging PEP Class Diagram - Interface Descriptions Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 78 Session Directed Messaging PEP Class Diagram - Association Descriptions Sequence Diagrams The following clauses provide the Sequence diagrams for Session Directed Messaging PEP services. Send Message To Session Sequence Diagram 168 Information Exchange Framework Reference Architecture, Initial Submission

189 interaction Send Message To Session Sequence Diagram [ Send Message To Session Sequence Diagram ] Figure 1 -Send Message To Session Sequence Diagram Table 79 - Send Message To Session Sequence Diagram - Message Descriptions Receive Message Sequence Diagram interaction Receive Message Sequence Diagram [ Receive Message Sequence Diagram ] Figure 1 -Receive Message Sequence Diagram Table 80 - Receive Message Sequence Diagram - Message Descriptions 11.6 Receiver Directed Messaging PEP The Receiver Directed Messaging PEP intercepts messages transiting between a user application and message/data centric dissemination services. The PDP is provided with the identity and policy-rights of Information Exchange Framework Reference Architecture, Initial Submission 169

190 each recipient (user) participating in the exchange. In this case the PDP determines if the recipient is authorized (has the policy-rights) to release the specific information asset (/information content) the specific session (IEF interface to a channels dissemination infrastructure), and its decision is enforced by the PDP Receiver Directed Messaging Use Case Diagrams The following clauses provide the Use Case diagrams for Receiver Directed Messaging PEP services. Send Session Directed Message Use Case Diagram Figure 31 -Send Session Directed Message Use Case Diagram Table 81 - Send Session Directed Message Use Case Diagram Descriptions Apply Exchange Protocol Log Transaction Following the assembly of a releasable data set, structure and format the data in accordance with the specified protocol (e.g., NIEM XSD, MIP PDU, EDXL XSD, or CAP XSD.) prescribed by policy. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be 170 Information Exchange Framework Reference Architecture, Initial Submission

191 Table 81 - Send Session Directed Message Use Case Diagram Descriptions configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Authorize Structured Message Recipient Send Structured Message to Information Exchange Services Check that the recipient(s) have the policy rights to receive information with the security/sensitivity classification of the marked structured message and if they do provide the authorization. Once message has been fully authorized discover the delegated exchange mechanism and forward the message to the service(s) Prescribe Exchange Participation Verify the set of authorized exchanges that this message may be sent over. Authorize Structured Message Sender Obtain Packaging Profile Load Policies Package Structured Message Check that the sender has the policy rights to send information with the security/sensitivity classification of the marked structured message and provide authorization if they do. Obtain, from the local policy store, the packaging protocol for the information element. These profiles define the structure and format for the information exchange element (e.g., , text message, structured message, web exchange). On the instruction of an authorized PAP, or authorized PDP Service, load a policy or set of policies into active memory of the PDP. If authorized, the PDPs can load and activate policies from a local policy store. Assemble and format a structured-message in accordance with exchange policies specified in an information exchange specification (see IEPPV). Authorize Information Dissemination Service Verify that an information dissemination service is authorized to transport the content of the specific information element. Authorization is based on the channel's security attributes and the markings (e.g., classifications and restrictions, and warnings) bound to each information element. If the channel attributes are verified, grant release of the information element to the service.. Receive Message When a user retrieves an message from the mail server, the IEF intercepts the message. The security label on the message is extracted and the IEF assures that the recipient has the policy right to access the message. If the user has that right, the IEF decrypts the message, using the symmetric key retrieved from the Key Escrow service. The decrypted message is then delivered to the user. Information Exchange Framework Reference Architecture, Initial Submission 171

192 The re-verification of policy rights may seem redundant as the same check that was made when the message was originally sent. In actuality, check in receive is necessary since in the interim between when the message was sent and when it was received, either the recipient s security attributes or the security policy itself may have been altered. Allowing the recipient to retrieve the message under these conditions may violate the new policy, therefore a supplemental policy check on receive is necessary. If the policy or policy rights have changed, the IEF can redact the offending information. Figure 32 -Receive Use Case Diagram Table 82 - Receive Use Case Diagram Descriptions Decrypt Attachments Transform the information content of an attachment back into its original form using the unique symmetric key retrieved from escrow. Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. 172 Information Exchange Framework Reference Architecture, Initial Submission

193 Table 82 - Receive Use Case Diagram Descriptions Authorize User to Receive Attachment Authorize User to Receive When there is an attachment received as part of an information exchange the IEF extracts the attachment from the , and checks the associated markings on the attachment, and then validates the recipient has the policy rights to receive the attachment. If the recipient is authorized, the attachment is included, else, the attachment is redacted from the information received. Verify that the recipient has the policy rights to access the content of the . Intercept Extract Markings from On receipt of an from the mail server, the PEP intercepts the in order to enforce policy. Extract markings from an (main body and attachments), e.g.: Security Tags; Privacy Tags; informational metadata, Constraints; and Warning Orders. Decrypt Deliver to Authorized User Transform the information content of the body back into its original form using the unique symmetric key retrieved from escrow. Deliver the decrypted content of the and its attachment(s) to the client for the authorized user Class Diagrams The following clauses provide the Class diagrams for Receiver Directed Messaging PEP services. Receiver Directed Messaging PEP Class Diagram The Web Session PEP (Web PEP) is one variety of PEP that operates on web data. This PEP limits access to only those users that have a access right to use the web services protected by the PEP. Information Exchange Framework Reference Architecture, Initial Submission 173

194 package Policy Enforcement Point Class Diagrams [ Receiver Directed Messaging PEP Class Diagram ] Receiver Directed Messaging PEP Figure 1 -Receiver Directed Messaging PEP Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 83 Receiver Directed Messaging PEP Class Diagram Descriptions Receiver Directed Messaging PEP Receiver Directed Messaging PEP Operations: Receiver Directed Messaging PEP Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 84 Receiver Directed Messaging PEP Class Diagram - Interface Descriptions 174 Information Exchange Framework Reference Architecture, Initial Submission

195 Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 85 Receiver Directed Messaging PEP Class Diagram - Association Descriptions Sequence Diagrams The following clauses provide the Sequence diagrams for Receiver Directed Messaging PEP services. Send Receiver Directed Messaging Sequence Diagram When a user requests access to a web service via the Web PEP, the PEP will first ensure that the user s session is authenticated. As previously described, if the session is not authenticated, the Web Server should prompt the user for a username/password and then authenticate the user. Once authenticated, the Web PEP will know the identity of the user and the COI that applies to the web service being accessed. The information processing logic to handle the request is shown in the following diagram. Figure 1 -Send Receiver Directed Messaging Sequence Diagram Information Exchange Framework Reference Architecture, Initial Submission 175

196 Table 86 - Send Receiver Directed Messaging Sequence Diagram - Message Descriptions service response service response REQUEST_USER_CR EDENTIALS GET The user s information request is sent to the Web PEP over TLS/SSL. The PEP has the COI for the requested virtual host from the SSL certificate for the virtual host. The PEP also has the user s identity for this web session. POLICY_REQUEST The PEP calls the AS to determine if the user has the policy based right to access this Web Service, given the COI to which it belongs. GET If the policy decision was to allow the user access to the web service, the PEP allows the message to be forwarded to the destination on the target Web Server. If the policy decision denies the user access to the requested Web Service, an HTTP error code 403 (Not Authorized) is returned to the user s web session. 176 Information Exchange Framework Reference Architecture, Initial Submission

197 Table 86 - Send Receiver Directed Messaging Sequence Diagram - Message Descriptions PROCESS_LOG_REC ORD The Web PEP will create a log file record that specifies the web service access operation details and send the record to the TLS to create a permanent record of the transaction. Receive Message Sequence Diagram interaction Receive Message Sequence Diagram [ Receive Message Sequence Diagram ] Figure 1 -Receive Message Sequence Diagram Table 87 - Receive Message Sequence Diagram - Message Descriptions Information Exchange Framework Reference Architecture, Initial Submission 177

198 12 Data Packaging and Processing Services The Message Packaging and Processing Service (MPPS) is an integrated policy decision and enforcement point for the packaging and processing of structured messages. Extracted from the original IEPPS RFP: This RFP solicits proposals for a service specification describing the application-visible interface(s) and behavior of the enforcement services. This includes services for data aggregation and marshalling; data guarding and filtering; syntactic and semantic validation; tag and label processing; data transformation; release control; and routing. The proposals should describe how the service interacts with the middleware and communication networks. In addition, it should address issues related to security, privacy, Quality of Service (QoS), logging, and auditing. 1. The IEPPS shall accept information exchange policies conforming to one or more of the language profiles defined in the Information Exchange Policy Vocabulary (IEPV) Specification. (This specification is currently under development under the RFP: mars/ ). 2. The IEPPS shall provide an interface that allows active policies to be configured at runtime. The interface will support but not be limited to the following operations: a. Import new or modified policies; b. Activate existing, new or modified policies; c. Deactivate existing policies; d. Export policies in a persistent format. 3. The IEPPS shall support the dynamic and static invocations of the operations listed above. 4. The IEPPS shall restrict the release of information messages and content to that specified in active policies. 5. The IEPPS shall release and accept information to one or more selected middleware (e.g. DDS, CORBA, and Web Services),. 6. The IEPPS shall record changes to policies. 7. The IEPPS shall record transactions (for both release and receive operations), including the state or results of the transaction (e.g., rejected, incomplete semantic, data error, or success). 8. The IEPPS shall provide an interface to record its operational status. 9. The IEPPS shall provide an interface to report its operational status to external applications. 178 Information Exchange Framework Reference Architecture, Initial Submission

199 12.1 Optional Requirements This clause identifies optional requirements considered beneficial to the development and deployment of IEPPS implementations. 1. The IEPPS may provide a PSM that supports enforcement of policies defined for the SOPES Information Exchange Data Model (IEDM). 2. The IEPPS may provide interfaces to interoperate with user specified IEF services and policies. Such services and policies may include: a. Identity Management; b. Credential Management; c. Access Management; d. Security Key Management (e.g., Public Key Infrastructure (PKI)); e. Encryption. 3. The IEPPS may provide interfaces for integration with user applications. 4. The IEPPS may provide interfaces to control resource usage (e.g., thread priority, memory usage, bandwidth) 5. The IEPPS may provide interfaces that support the configuration of recording detail levels: e.g., None, Minimal, Normal, Detailed, Debugging ) Message Packaging and Processing Service Use Case Diagrams The following clauses provide the Use Case diagrams for message packaging and processing services that enable the IEF to: Package information: o Access data elements for the data stores; o Assemble (aggregate, transform, mark and redact) data and information elements; o Structure and format information and/or message for release; and o Release Information. Process o Receive Information; o Parse and transform information and data elements; and o Marshal data elements to the assigned data stores Package Structured Message Use Case Diagram The following figure illustrated the IEF use cases for the assembly or processing of a structured message/payload. Information Exchange Framework Reference Architecture, Initial Submission 179

200 Figure 33 -Package Structured Message Use Case Diagram Table 88 - Package Structured Message Use Case Diagram Descriptions Apply Exchange Protocol Assemble Information Payload Following the assembly of a releasable data set, structure and format the data in accordance with the specified protocol (e.g., NIEM XSD, MIP PDU, EDXL XSD, or CAP XSD.) prescribed by policy. Assemble an Information payload by enforcing the policies/rules defined by the referenced FilteredSemanticElement. Assemble Releasable data Set Assemble an information payload (releasable data set) resulting from the execution of policies/rules defined by a specific FilteredSemanticElement. Aggregate, transform, mark and redact, as specified in policy, the data pattern (semantic and transactional elements) and all its enclosed patterns. 180 Information Exchange Framework Reference Architecture, Initial Submission

201 Table 88 - Package Structured Message Use Case Diagram Descriptions Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Assemble Attachments Assemble the attachments (e.g., files) to be included as part of a specific message. Assemble Information Package Obtain Packaging Profile Package Structured Message Assemble the Information Payload, Digest, Attachment Summary, linkages, Narrative Text, and Rendering Instructions as specified in the policy set for the message pattern. Obtain, from the local policy store, the packaging protocol for the information element. These profiles define the structure and format for the information exchange element (e.g., , text message, structured message, web exchange). Assemble and format a structured-message in accordance with exchange policies specified in an information exchange specification (see IEPPV). Assemble Message Markings Obtain Marking profile Assemble the message markings (e.g., time stamps, author information, security, restrictions/constraints, and privacy) as directed by the referenced FilterSemanticElement. Obtain the marking protocol for the specific type of information element from the local policy store Assemble Information Package Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 181

202 Figure 34 -Assemble Information Package Use Case Diagram Table 89 - Assemble Information Package Use Case Diagram Descriptions Assemble Information Payload Assemble an Information payload by enforcing the policies/rules defined by the referenced FilteredSemanticElement. Assemble Releasable data Set Assemble an information payload (releasable data set) resulting from the execution of policies/rules defined by a specific FilteredSemanticElement. Aggregate, transform, mark and redact, as specified in policy, the data pattern (semantic and transactional elements) and all its enclosed patterns. Assemble Attachment Summary Assemble the list of attachments associated with an information package. This may be a subset of all the attachments forming part of the Message. Assemble Digest Assemble the contents of an information package digest. Gather Assemble Rendering Instructions Extract from the markings (/metadata) the user s instruction for the processing of the dataset for release to the specified recipient. These instructions (e.g., applicable XSD) are used to structure and format the data for release. 182 Information Exchange Framework Reference Architecture, Initial Submission

203 Table 89 - Assemble Information Package Use Case Diagram Descriptions Assemble Information Package Markings Assemble the InformationPackage markings (e.g., time stamps, author information, security, restrictions/constraints, and privacy) as directed by the referenced FilterSemanticElement. Assemble Information Package Assemble Linkages Get Narrative Text Assemble the Information Payload, Digest, Attachment Summary, linkages, Narrative Text, and Rendering Instructions as specified in the policy set for the message pattern. Assemble the linkages between elements of the package and other packages in the Message. Retrieve the narrative text to be integrated into the Information Package Assemble Releasable Data Set Use Case Diagram The following figure expands the definition of the "Aggregate data Assemblies" use case. Information Exchange Framework Reference Architecture, Initial Submission 183

204 Figure 35 -Assemble Releasable Data Set Use Case Diagram Table 90 - Assemble Releasable Data Set Use Case Diagram Descriptions Assemble Releasable data Set Assemble an information payload (releasable data set) resulting from the execution of policies/rules defined by a specific FilteredSemanticElement. Aggregate, transform, mark and redact, as specified in policy, the data pattern (semantic and transactional elements) and all its enclosed patterns. Assemble Filtered Semantic Assemble the enclosed data assemblies, conforming to user defined filters, comprising releasable data (information elements). Assemble Transactional Element Aggregate, transform, mark and redact, as specified in packaging policy, one of the transactional patterns within the semantic pattern specifying the releasable information payload. 184 Information Exchange Framework Reference Architecture, Initial Submission

205 Table 90 - Assemble Releasable Data Set Use Case Diagram Descriptions Filter Elements Execute filter policies during the assembly and packaging of structured datasets. These filters tailor the standard dataset by redacting (or removing) data and information elements in order to tailor (e.g., desensitize) information to the access rights of individual recipients. Filters execute against the instance values of the users data/attributes/meta-data aggregated at runtime. *Note: During the assembly, meta-data is treated in the same manner as data attributes and used to filter or transform selected elements. Mark Data Assembly Identify Enclosed Assemblies Assess the sensitivity of each assembly of data (information element) to determine the marks and constraints that apply to the assembly and bind the markings to the data assembly. Identify all data assemblies that are included in the semantic or transactional element being processed and schedule their assembly. Watch for Data Change Watch for a data change in those data elements identified in policy as triggers for the release of information to participants. Transform Data Elements Assemble Semantic Element Execute the transformation policies (/rules) for data elements and attributes. Transformations convert a data value or set of data values from the format of the source environment into the format of the target environment. Assemble the enclosed data assemblies comprising releasable data (information element). Identify Enclosing Information Elements Identify all semantic and transactional elements that enclose (or include) the transactional element being processed and schedule their assembly. Trigger the Assemble of the Watch Point Transactional Trigger the construction of a Transactional element and its enclosing elements where one of those elements is a WatchPoint. Get Wrapper Element Data Get data from local data stores referenced by the wrapper elements in the active packaging policies. Assemble related Data Element Information Exchange Framework Reference Architecture, Initial Submission 185

206 Process Structured Information Element Use Case Diagram The following figure provides the use case for the processing of a structured message. Figure 36 -Process Structured Information Element Use Case Diagram Table 91 - Process Structured Information Element Use Case Diagram Descriptions Parse Package Markings Analyze a structured dataset, divide it into its parts and describe their syntactic roles. Extract the name value pairs contained in the package markings. Populate Transactional Patterns Extract the information parsed from a received structured message and fill the transactional patterns (see IEPPV) used to package and process the message elements. 186 Information Exchange Framework Reference Architecture, Initial Submission

207 Table 91 - Process Structured Information Element Use Case Diagram Descriptions Parse Information Payload Analyze a structured dataset, divide it into its parts and describe their syntactic roles. Extract the name value pairs contained in the Information payload. Parse Message markings Process Attachments Analyze a structured dataset, divide it into its parts and describe their syntactic roles. Extract the name value pairs contained in the message markings. Process the attachments included in the received message. Parse Digest Analyze a structured dataset, divide it into its parts and describe their syntactic roles. Extract the name value pairs contained in the package digest. Process Structured Information Element Identify the information elements contained in the received structured message and initiate construction of the subtended data elements. Populate Wrapper Elements Extract the instance data in the received structured message and use it to build the wrappers (see IEPPV) used to package and process the message elements. Parse Message Elements Load Policies Persist Complete Information Elements Analyze a structured message, divide it into its parts and describe their syntactic roles. On the instruction of an authorized PAP, or authorized PDP Service, load a policy or set of policies into active memory of the PDP. If authorized, the PDPs can load and activate policies from a local policy store. For received information elements that have all the necessary or appropriate data elements (as specified in IE Policy) store the information in the local data store. Hold pattern for completion Complete Pattern from local data Encrypt Information Element Populate Data Patterns When a data pattern cannot be completed with received data or local data holdings, hold the pattern in abeyance until the necessary data is received or the pattern times out. If a message is received that does not have the data elements needed to complete the mandatory data patterns in a transactional element, check local data stores for data elements that complete the patterns.. Transform the information content of an information element into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each information element is encrypted using its own unique symmetric key. Extract the instance data parsed from a received structured message and use it to fill the data patterns (see IEPPV) used to package and process the message elements. Information Exchange Framework Reference Architecture, Initial Submission 187

208 Table 91 - Process Structured Information Element Use Case Diagram Descriptions Save File When an authorized user or user application requests that a file be stored/saved within the IEF file share. Parse Information Packages Analyze an information package, divide it into its parts and describe their syntactic roles. Identify patterns in the information element Parse Structured Payload Identify the Transactional elements that are used to process the data contained in the received information elements. These patterns will contain each information element in the message. Analyze a structured dataset, divide it into its parts and describe their syntactic roles. Extract the name value pairs contained in the payload Package Structured Message Use Case Diagram The following figure illustrated the IEF use cases for the assembly or processing of a structured message/payload. 188 Information Exchange Framework Reference Architecture, Initial Submission

209 Figure 37 -Package Structured Message Use Case Diagram Table 92 - Package Structured Message Use Case Diagram Descriptions Apply Exchange Protocol Assemble Information Payload Following the assembly of a releasable data set, structure and format the data in accordance with the specified protocol (e.g., NIEM XSD, MIP PDU, EDXL XSD, or CAP XSD.) prescribed by policy. Assemble an Information payload by enforcing the policies/rules defined by the referenced FilteredSemanticElement. Assemble Releasable data Set Assemble an information payload (releasable data set) resulting from the execution of policies/rules defined by a specific FilteredSemanticElement. Aggregate, transform, mark and redact, as specified in policy, the data pattern (semantic and transactional elements) and all its enclosed patterns. Log Transaction An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in Information Exchange Framework Reference Architecture, Initial Submission 189

210 Table 92 - Package Structured Message Use Case Diagram Descriptions the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Assemble Attachments Assemble the attachments (e.g., files) to be included as part of a specific message. Assemble Information Package Obtain Packaging Profile Package Structured Message Assemble the Information Payload, Digest, Attachment Summary, linkages, Narrative Text, and Rendering Instructions as specified in the policy set for the message pattern. Obtain, from the local policy store, the packaging protocol for the information element. These profiles define the structure and format for the information exchange element (e.g., , text message, structured message, web exchange). Assemble and format a structured-message in accordance with exchange policies specified in an information exchange specification (see IEPPV). Assemble Message Markings Obtain Marking profile Assemble the message markings (e.g., time stamps, author information, security, restrictions/constraints, and privacy) as directed by the referenced FilterSemanticElement. Obtain the marking protocol for the specific type of information element from the local policy store Class Diagrams The following clauses provide the Class diagrams for message packaging and processing service. Data Assembly Service Class Diagram The Data Assembly Service receives structured message data content from an authorized exchange. It performs data validation and policy based aggregation of received data as well as supplemental aggregation from internal Information stores. 190 Information Exchange Framework Reference Architecture, Initial Submission

211 Figure 1 -Data Assembly Service Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 93 Data Assembly Service Class Diagram Descriptions DataFilter A component of the Data Assembly Service which performs instance data filtering either by preconfigured/modelled filters or dynamically by user supplied parameters at runtime. DataFilter Operations: DataFilter Data Assembly Service IEF service that assembles, transforms, marks, and filters structured data elements in accordance with rules defined using the Information Exchange Packaging Policy Vocabulary (formal ). The Service provisions a dataset conforming to the semantic content required by user defined policy. Data Assembly Service Operations: Data Assembly Service Data Transformation Service This service is responsible for providing encryption of data elements as well as provisioning of Semantic attribution such as data marking and other transforms. Information Exchange Framework Reference Architecture, Initial Submission 191

212 Table 93 Data Assembly Service Class Diagram Descriptions Provides a means of converting a set of data values from the data format of a source data system into the data format of a destination data system. Data Transformation Service Operations: Data Transformation Service InformationStore User specified/provided off-the-shelf database management system. A database that stores information about both the data and how it is related. Data and relationships are represented in a flat, two-dimensional table that preserves relational structuring and provides structure to the information at rest. InformationStore Operations: InformationStore PolicyRepository The ISS Policy Repository is a secure information store that persists the information sharing and safeguarding policies that are enforced by IEF services. The Policy Administration Point (PAP) provides the services needed to manage and administer the policies applicable to the environment or operation. The policies are stored in a database that can be queried by a PDP to acquire the relevant policies to the evaluation of the user request. ISS policies are immediately enforced once they are loaded and activated within the Policy Repository. The IEF can be configured with a single ISS Policy Store accessible by all PDPs, or as a federated repository with local repositories for the PDPs to access. In the latter configuration, all federated policy repositories are securely updated in real time from the PAP. PolicyRepository Operations: PolicyRepository DataMarking A type of transformation that takes place at construction of the data composite modeled using attribution and operations within the Semantic pattern. DataMarking Operations: DataMarking Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 94 Data Assembly Service Class Diagram - Interface Descriptions SecureLoggingAdminPoin t Use of the interface through which log file records are reviewed must be, itself, an IEF policy-based data exchange. That is, the interface that is used to perform audit 192 Information Exchange Framework Reference Architecture, Initial Submission

213 Table 94 Data Assembly Service Class Diagram - Interface Descriptions analysis, audit review and forensic activities must enforce the domain s security policy. As an example, the access right to review log file records could be assigned to a specific community; only those users that belong to that community will have access to the SLAP interface. Use of this interface would then be subject to all IEF protection from access control to auditing. 1. Provides a web-based interface to the Audit Reviewer on the front end; and 2. Includes database connectivity that can be used to retrieve log file records from the repository. Since the SLAP is a web interface, access to the service can be controlled through the use of a Web Session PEP SecureLoggingAdminPoint Operations: ProxyDatabaseServer ProxyDatabaseServer Operations: PackagingServiceInterface PackagingServiceInterface Operations: PROCESS_MESSAGE: Operation Parameters: CTSinternal CTS message format for cryptographic responses: XML-based message format with name-value pairs to specify the returned values. All messages are comprised of a list elements that contains the name-value pairs and a status element that reports the completion state of the response: success or error. all list messages are defined as cryptoop responses. COPY_ENCRYPT = target, path to container file Information Exchange Framework Reference Architecture, Initial Submission 193

214 Table 94 Data Assembly Service Class Diagram - Interface Descriptions COPY_DECRYPT = target, path to plain text file FILE_ENCRYPT_TOKEN = target, path to cypher text file FILE_DECRYPT_TOKEN = target, path to plain text file The CTS will return an error code to the caller if any of the following conditions are encountered: Message cannot be parsed due to a malformed request; No action element was specified in the request or the action is unsupported; The source file for the operation cannot be accessed; or An error occurred in the external crypto library. CTSinternal Operations: COPY_DECRYPT: If the requested action is COPY_DECRYPT the CTS will perform the following operations: 1. Perform a digest hash of the contents of the container and compare the result to the digest that is stored in the container to ensure that the container has not been tampered with. 2. Retrieve the token from the container. 3. Use this token in a RETRIEVE_KEY message and send this message to the KMS. The KMS will return the associated key for this token. 4. Use this retrieve key in a call to the Crypto library to transform the source file into a decrypted version of that file. Once the original file has been successfully decrypted, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the decryption process will be reflected in the response message to the PEP. Operation Parameters: COPY_ENCRYPT: If the requested action is COPY_ENCRYPT the CTS will perform the following operations: 1. Extract the security marking from the Environment element of the message. 2. Formulate and send a GENERATE_STORE message to the KMS and receive a key and token in response. Since the CTS is being requested to create a new encrypted asset, a new unused key is required from the KMS. 3. Use this new key in a call to the Crypto library to transform the source file into an encrypted version of that file. 194 Information Exchange Framework Reference Architecture, Initial Submission

215 Table 94 Data Assembly Service Class Diagram - Interface Descriptions 4. Generate a hash digest of the encrypted file using the methodology described in the previous section. 5. Create a new container file (ZIP archive) with the name of the target file and add the following data to the container: the encrypted payload, token, the hash digest, the original filename of the file (taken from source) and the marking. Once the container has been successfully created, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the encryption process will be reflected in the response message to the PEP. Operation Parameters: FILE_ENCRYPT_TOKEN: If the requested action is FILE_ENCRYPT_TOKEN the CTS will perform the following operations: 1. Extract the token from the Environment element of the message. 2. Use this token in a RETRIEVE_KEY message and send this message to the KMS. The KMS will return the associated key for this token. 3. Use this retrieved key in a call to the Crypto library to transform the source file into an encrypted version of that file. Once the encrypted file has been successfully created, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the encryption process will be reflected in the response message to the PEP. Operation Parameters: FILE_DECRYPT_TOKEN: If the requested action is FILE_DECRYPT_TOKEN the CTS will perform the following operations: 1. Extract the token from the Environment element of the message. 2. Use this token in a RETRIEVE_KEY message and send this message to the KMS. The KMS will return the associated key for this token. 3. Use this retrieved key in a call to the Crypto library to transform the source file into a decrypted version of that file. Once the decrypted file has been successfully created, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the decryption process will be reflected in the response message to the PEP. Information Exchange Framework Reference Architecture, Initial Submission 195

216 Table 94 Data Assembly Service Class Diagram - Interface Descriptions Operation Parameters: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 95 Data Assembly Service Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Interfaces Owner: IEF Service Elements Owner: IEF Service Elements 196 Information Exchange Framework Reference Architecture, Initial Submission

217 Table 95 Data Assembly Service Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Data Packaging Service Class Diagram The Data Packaging Service sits in between the Data Assembly Service and the Data Exchange Service. Once a data composite has been assembled it is passed to the Packaging Service where packaging policies are applied to the preparation of the message These policies govern the format of the prepared data elements and the structure of the message along with the security marking requirement. The service also implements a Policy Administration Point so that authorized users may manipulate packaging policies. All packaging operations are fully logged to the Trusted Logging Service. Figure 1 -Data Packaging Service Class Diagram Information Exchange Framework Reference Architecture, Initial Submission 197

218 Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 96 Data Packaging Service Class Diagram Descriptions Data Packaging Service The Policy-based Packaging Service (PPS): The PPS Assembles data and information elements from local data-stores in a manner that is tailored to a recipients' or sessions (Community of Interest, organization, or individual) access rights to receive information. The service selectively aggregates data and information elements such that the aggregate information element is releasable to the selected recipient or session. The resulting information element is then formatted in accordance with the schema (e.g., XSD) agreed upon for the exchange. Data Packaging Service Operations: Data Packaging Service DataFormatter A component of the Packaging Service whose responsibility is to apply formatting to the data elements of the message. DataFormatter Operations: DataFormatter PDP Governs packaging procedures for the information element(s) including the format of the message. Connects to the Policy stores for packaging instruction and authorization to apply security markings to packaged data. PDP Operations: PDP PolicyRepository The ISS Policy Repository is a secure information store that persists the information sharing and safeguarding policies that are enforced by IEF services. The Policy Administration Point (PAP) provides the services needed to manage and administer the policies applicable to the environment or operation. The policies are stored in a database that can be queried by a PDP to acquire the relevant policies to the evaluation of the user request. ISS policies are immediately enforced once they are loaded and activated within the Policy Repository. The IEF can be configured with a single ISS Policy Store accessible by all PDPs, or as a federated repository with local repositories for the PDPs to access. In the latter configuration, all federated policy repositories are securely updated in real time from the PAP. PolicyRepository Operations: PolicyRepository 198 Information Exchange Framework Reference Architecture, Initial Submission

219 Table 96 Data Packaging Service Class Diagram Descriptions StructuredMessageMarker The PEP service used to: Bind security markings to a structured message. Retrieve security markings from a structured message. StructuredMessageMarker Operations: StructuredMessageMarker Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 97 Data Packaging Service Class Diagram - Interface Descriptions ASinternal The Authorization Service expects all PEPs to express policy requests in the form of a context request messages and will, in turn, supply context response messages when returning a policy decision. The following describes the information that can be provided to the AS within an context request message: Information Element: 1. SUBJECT: This is the unique identifier of the originator of the policy request. This is the user that initiated the data transaction that requires a policy check. The PEP determines the unique identity of the user and encodes this information within the Subject element of the expression. 2. RESOURCE: This is the caveat in the security marking on the information asset that is being requested by the user. The PEP, often leveraging the Security Marking Service, acquires the caveat from the asset and encodes this information within a Resource element of the expression. 3. ACTION: This is the action that is being performed against the data asset. The action is encoded within an Action element of the expression. ASinternal Operations: Policy_Request: The following describes the information that can be provided to the AS within an policy request message: Subject: This is the unique identifier of the originator of the policy request. This is the user that initiated the data transaction that requires a policy check. The PEP determines the unique identity of the user and Information Exchange Framework Reference Architecture, Initial Submission 199

220 Table 97 Data Packaging Service Class Diagram - Interface Descriptions encodes this information within a Subject element of the policy request expression. Resource: This is the caveat in the security marking on the information asset that is being requested by the user. The PEP, often leveraging the Security Marking Service, acquires the caveat from the asset and encodes this information within a Resource element of the policy request expression. The source of the caveat will depend on the data asset being requested. For example, a file will hold caveat information within a security marking whereas an IM chat room will have the caveat stored as a property of the room itself. PolicyAdministrationPoint Action: This is the action that is being performed against the data asset.the action is encoded within an Action element of the policy request expression. The action value can take any alphanumeric textual form (e.g.read,write). Operation Parameters: The PAP is a service that: 1. Provides a protected web-based interface for the security officer on the front end; and 2. Includes database connectivity that can be used to retrieve and set policies at the security policy repository. Through this interface, current policies are displayed, new policies can be created and existing policies can be deleted. Policies may be activated or deactivated. Parameters to the interface must include: UserId or User Caveat Action Resource Caveat Result Once the Security Policy Repository has been updated, any policies are immediately enforced. Since for every policy request the AS retrieves all applicable policies, the AS is always referencing the latest set of policies. PolicyAdministrationPoint Operations: EDIT_POLICY: Operation Parameters: DELETE_POLICY: 200 Information Exchange Framework Reference Architecture, Initial Submission

221 Table 97 Data Packaging Service Class Diagram - Interface Descriptions Operation Parameters: NEW_POLICY: Operation Parameters: ACTIVATE_POLICY: Operation Parameters: DEACTIVATE_POLICY: Operation Parameters: PackagingServiceInterface PackagingServiceInterface Operations: PROCESS_MESSAGE: Operation Parameters: TLSinternal Trusted log records are sent from the PEPs to the TLS and formatted as XML records based on a fully specified schema. Since PEPS are the principle clients of the TLS each PEP logs with it's unique identifier attached to every log instance. TLSinternal Operations: Process_Log_Record: Principal. userid:the identity of the IEF user that initiated the data request associated with this log file record. This is the same identity that was used in the policy check to the AS. ipaddress: The address of the PEP that submitted the log file record. program: An identifier of the type of PEP that submitted the log file record. Action. operation: What action was performed on the data. In this context, the action is the policy action (e.g. READ,WRITE) that was submitted to the AS for a policy decision. target: The resource against which the policy decision was made. In this context, the target is the security marking of the asset against which the policy decision was made. tacorigin: A identifier that uniquely differentiates the log file record created by this PEP from those of other PEPs. notes: A free form section in which per operation or per file type data can be inserted into an log file record. timestamp: A timestamp on the log file record, referencing the time when the log file record was created. Operation Parameters: Information Exchange Framework Reference Architecture, Initial Submission 201

222 Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 98 Data Packaging Service Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements 202 Information Exchange Framework Reference Architecture, Initial Submission

223 12.4 Sequence Diagrams The following clauses provide the Sequence diagrams for message packaging and processing service. Information Exchange Framework Reference Architecture, Initial Submission 203

224 13 Common Services The following clauses identify and describe a set of services/functions common to multiple PAP, PDP and PEP capabilities. All implementations must include the elements described below Use Cases The following clauses provide the Use Case diagrams for common IEF services Authorize User Use Case Diagram Verify that a user has the policy rights to access the information elements and perform the requested action. Figure 38 -Authorize User Use Case Diagram Table 99 - Authorize User Use Case Diagram Descriptions Authorize Recipient Verify that a user is authorized to receive and access the content of the specific information element. Authorization is based on the users access rights and the markings (e.g., classifications and restrictions, and warnings) bound to each information element protected by the IEF. If the user's rights are verified, grant access to the user. Individual authorization criteria can be defined for: - Files; 204 Information Exchange Framework Reference Architecture, Initial Submission

225 Table 99 - Authorize User Use Case Diagram Descriptions - and attachments: (To, CC, and Bcc) - Instant messaging and attachments, - Structured Messaging; and - Web Access. Identify User Log Transaction Establish a unique machine-readable name that enables recognition of users or resources as identical to those previously described in the environment. An IEF solution will log all IEF transactions and record each record in a tamperresistant information store. The level of logging to be performed can be configured by an authorized user to address resource and performance concerns in the runtime environment. The logging of IEF transactions supports both shortterm security incident and event monitoring and long-term forensic auditing. Issue Alerts and Warnings Based on policy, if the user is attempting to perform an activity that is not authorized, issue a warning or alert to responsible individuals. The IEF uses internal services to disseminate the warnings and alerts. The thresholds of activity calling for a warning or alert is controlled by policy. Authorize Action Verify that a user has the policy rights to access the specific information element and perform the requested action(s). Authorization is based on the user s access rights and the markings (e.g., classifications and restrictions, and warnings) bound to an information element. If the user's right to access is verified, access is granted to the user and the action is completed. User authorization based on (one or all of): - Subject (identity, clearance, role, community), - resources (source and target platform, data location, application, communication channel), - action (READ/WRITE/Update/Delete/exchange), and - contextual environment (time of day, location, duty officer shift, threat, risk,...) Verify Policy Right to Access Information Element Using the active receipt or release policy, verify that the User has the policy rights to perform the specific action on the information element. Authorization is based on the active policies, the user's attributes and the markings on the specified file. Authorize Sender Verify that the user has the policy rights to release or publish a specific information element bound with its specific markings (e.g., classifications and restrictions, and warnings) and check the recipient s access rights to verify if they may receive such information. Individual authorization criteria can be defined for: - Files; - and attachments: (To,CC, and Bcc) - Instant messaging and attachments, - Structured Messaging; and - Web Access. Information Exchange Framework Reference Architecture, Initial Submission 205

226 Table 99 - Authorize User Use Case Diagram Descriptions Obtain User Access Rights Obtain the users access rights from the user supplied identity management services. Authorize Session Bind Markings to Information Element Use Case Diagram A core element in the IEF approach is the binding of Figure 39 -Bind Markings to Information Element Use Case Diagram 206 Information Exchange Framework Reference Architecture, Initial Submission

227 Table Bind Markings to Information Element Use Case Diagram Descriptions Bind Markings to Attachment Collect and bind markings (metadata, tags and labels) as file attributes to the main body of an Attachment. Persisting markings to an and its attachments will depend on the capabilities of the user's clients and server(s). Bind Markings to Body Bind Informational Markings Bind markings (metadata, tags and labels) to the main body of an . Persisting markings to an and its attachments will depend on the capabilities of the user's clients and server(s). Collect and bind informational meta-data to an information element. Informational meta-data may include: - Submitter meta-data; - Data Owner meta-data; and - Handling Instructions. Bind Markings to File Bind markings (meta-data, tags and labels) as file attributes to the persisted file. Persisting markings to a file will depend on the capabilities of the user's: - File Service; and/or - Records & Document Management Services (System). Obtain Packaging Profile Bind Sensitivity Markings Bind Constraint Markings Obtain, from the local policy store, the packaging protocol for the information element. These profiles define the structure and format for the information exchange element (e.g., , text message, structured message, web exchange). Collect and bind sensitivity (e.g, security classification, confidentiality and privacy) markings to the information element. Collect and bind the constraint/caveat/warning-orders markings to the information element. Bind Markings to Structured Message Bind markings to Instant Message Bind Key-Token to Information Element Bind markings (metadata, tags and labels) as file attributes to a Structured Massage. Persisting markings to a structured message will depend on the messaging protocol adopted by the user and that of the user's information dissemination services. Bind markings (metadata, tags and labels) as file attributes to an Instant Message. Persisting markings to an instant message and its attachments will depend on the capabilities of the user's IM clients and server(s). As a minimum, the instant message will inherit the attributes of the chat room in which it was exchanged. Bind the key-token to an information element. This token is required to retrieve the cryptographic (symmetric) key from the escrow service in order to decrypt the information element. For environments where multiple cryptographic services are used, embed information that would enable the identification of the cryptographic service providing the decryption services. Information Exchange Framework Reference Architecture, Initial Submission 207

228 Table Bind Markings to Information Element Use Case Diagram Descriptions Obtain Marking profile Obtain the marking protocol for the specific type of information element from the local policy store. Bind Markings to Information Elements Bind Markings (metadata, tags and labels) to information elements in accordance to the labeling profile/protocol. Bind Markings to Web Exchange Bind marking (metadata, tags and labels) as file attributes to an Web Exchange. Persisting markings to an information element provisioned via Web service or portal will depend on the capabilities of the user's Web server or portal. Most likely attributes will be bound to a web site s certificate and not to the exchange Encrypt Information Element Use Case Diagram The following figure illustrates the use-cases for encrypting information. 208 Information Exchange Framework Reference Architecture, Initial Submission

229 Figure 40 -Encrypt Information Element Use Case Diagram Table Encrypt Information Element Use Case Diagram Descriptions Encrypt Structured Elements Encrypt Body Encrypt Marked Instant Message Transform the internal elements in a structured dataset into a form that in unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each information element (dataset) is encrypted using its own unique symmetric key. Transform the information content of the body into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. The body has its own unique symmetric key. Transform the information content of an instant message into a form that in unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each specially marked message is encrypted using its own unique symmetric key. The IM PEP must obtain the special key in order to Information Exchange Framework Reference Architecture, Initial Submission 209

230 Table Encrypt Information Element Use Case Diagram Descriptions Encrypt Encrypt Instant Message Clear Key Memory Identify Cryptographic Service provide the initial encryption and then must register the key s token with the Instant Messaging chat-room for cryptographic operations on future messages with the same specific marks. Transform the information content of the body and its attachments into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. The body and each attachment is encrypted using its own unique symmetric key. Transform the information content of an instant message into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each IM message within a chat-room is encrypted using the chat-room's own unique symmetric key. On completion of the encryption process, sanitize the keys from memory and temporary stores. At the end of the process there must be no residual memory of the cryptographic keys outside the escrow service. Identify the cryptographic service to be employed to encrypt the information element(s). Encrypt File Retrieve Key Token Transform the information content of the file into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each file is encrypted using its own unique symmetric key. Retrieve key token from the Key Escrow Service when storing the generated key. Request Cryptographic Key Bind Key-Token to Information Element Request a unique symmetric key for the Information Element. Symmetric key encryption is a system in which the sender and receiver share a single, common key that is used to encrypt and decrypt the message. Symmetric-key systems are simpler and faster, but their main drawback is that the two parties must somehow exchange the key in a secure way. The IEF encryption scheme employs an escrow service to share the key between the sender and recipient of the information. Bind the key-token to an information element. This token is required to retrieve the cryptographic (symmetric) key from the escrow service in order to decrypt the information element. For environments where multiple cryptographic services are used, embed information that would enable the identification of the cryptographic service providing the decryption services. Encrypt Attachments Encrypt Information Element Transform the information content of an attachment file into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each attachment is encrypted using its own unique symmetric key. Transform the information content of an information element into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each information element is encrypted using its own unique symmetric key. 210 Information Exchange Framework Reference Architecture, Initial Submission

231 Table Encrypt Information Element Use Case Diagram Descriptions Store Cryptographic Keys Place the cryptographic key used to encrypt the information element into escrow. When storing a key, the key escrow returns a key-token. The key-token is bound to the encrypted information element and is used by authorized services to call the key escrow to retrieve the previously stored symmetric key. The key token may be a lookup index value; Because the token is bound to the encrypted data rather than disseminating the key, it is not possible to decrypt the data without authorization to access the escrow service and retrieve the key. Encrypt Policies Transform an information policy or policy-set into a form that is unintelligible unless it is transformed back into its original form using the key provide by the IEF. Each policy or policy-set is encrypted using its own unique symmetric key Decrypt Information Element Use Case Diagram Figure 41 -Decrypt Information Element Use Case Diagram Information Exchange Framework Reference Architecture, Initial Submission 211

232 Table Decrypt Information Element Use Case Diagram Descriptions Decrypt Attachments Transform the information content of an attachment back into its original form using the unique symmetric key retrieved from escrow. Identify Cryptographic Service Identify the cryptographic service to be employed to encrypt the information element(s). Decrypt Specially Marked Instant Message Decrypt Policies Decrypt Instant Message Decrypt Information Element Obtain the special key token from the Instant Messaging chat-room for messages with the specific marks. If the recipient is authorized to access the contents, transform the information content of an instant message back into its original form using the unique symmetric key retrieved from escrow. Transform the content of a policy set back into its original form using the unique symmetric key retrieved from escrow. The exchange of policies utilizes the same exchange and cryptographic services as used to exchange and store other information elements shared and protected by IEF services. Transform the information content of an instant message back into its original form using the unique symmetric key retrieved from escrow. Transform the information content of an information element back into its original form using the unique symmetric key retrieved from escrow. Obtain Key Token Decrypt File Retrieve Cryptographic Key Retrieve the key token bound to the information element(s) when the element(s) were originally encrypted. The token is used to retrieve the cryptographic key and may be used to identify the cryptographic service (algorithm) used. Transform the information content of the files back into its original form using the unique symmetric key retrieved from escrow. Using the key token, request the symmetric key from the Key Escrow Service. Decrypt Transform the information content of the body back into its original form using the unique symmetric key retrieved from escrow Class Diagrams The following clauses provide the class diagrams for common IEF services. 212 Information Exchange Framework Reference Architecture, Initial Submission

233 Authorization Class Diagram Figure 1 -Authorization Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 103 Authorization Class Diagram Descriptions IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. The information exchange protocol conforms to industry accepted, open standards that are based on XML(e.g., extensible Messaging and Presence Protocol (XMPP)). The messaging services/infrastructure) provisions information (messages) between IEF services /components). Although the specific protocol, format and content of the messages will depend on the nature of service being accessed, all messages are delivered through the same communications mechanism. The ability to provide robust, secure and trusted delivery of security messages between IEF services forms the critical core of the IEF architecture. Information Exchange Framework Reference Architecture, Initial Submission 213

234 Table 103 Authorization Class Diagram Descriptions IEF Secure Messaging Service Operations: IEF Secure Messaging Service PolicyDecisionPoint The PDP or Policy Engine is the processing component that evaluates an access request in the context of the security policy to derive the correct access control decision. The PDP decision logic evaluates policy requests in three separate stages using the following inputs: 1. Requesting users unique identity(subject) 2. Requested resource 3. Requested action The PDP must now request the user s security attributes from the Identity Management System, usually a list of the user s COI memberships. Next it must retrieve a list of policies from the policy storage repository that are relevant to this user and/or any of the COIs to which the user belongs. From the list of relevant policies the PDP must now match any that correspond to the original policy request based on the inputs. The results of the matching process based on the per-policy evaluation yield the final decision to permit or deny which is returned to the PEP via the Authorization Service. PolicyDecisionPoint Operations: PolicyDecisionPoint PolicyRepository The ISS Policy Repository is a secure information store that persists the information sharing and safeguarding policies that are enforced by IEF services. The Policy Administration Point (PAP) provides the services needed to manage and administer the policies applicable to the environment or operation. The policies are stored in a database that can be queried by a PDP to acquire the relevant policies to the evaluation of the user request. ISS policies are immediately enforced once they are loaded and activated within the Policy Repository. The IEF can be configured with a single ISS Policy Store accessible by all PDPs, or as a federated repository with local repositories for the PDPs to access. In the latter configuration, all federated policy repositories are securely updated in real time from the PAP. PolicyRepository Operations: PolicyRepository Authorization Service Part of policy Decision Point, the Authorization Service determines whether or not a user can access, use or release information in the manner requested. This service acquires/gathers: 214 Information Exchange Framework Reference Architecture, Initial Submission

235 Table 103 Authorization Class Diagram Descriptions The applicable ISS policies; The data/information markings (e.g., metadata, tags, labels, caveats, restrictions); The user attributes (e.g., policy rights, access rights, roles, location, and status); and The source and target resources' attributes (e.g., processing rights and restrictions). The service gathers information about the user, the recipients, the information asset(s), and the resources involved in the actions, and determines if the user/recipients have the rights to perform the requested action. The service then returns its decision to the Policy Enforcement Point(PEP) to execute the decision. The PDP possible responses include: Permit (action is permitted), Deny (action is denied) or Error. Authorization Service Operations: Authorization Service Generic PEP The PEP intercepts each request and response between the user (e.g., service clients, and applications) and the IEF enabled services (e.g., file share, , Instant Messaging, and message dissemination). The PEP provides the ability to link an information exchange service to the IEF safeguarding infrastructure. The PEP then verifies that the user has the authorizations to perform the operation and that the operation is permitted for the information asset on the designated device(s). If the User has the authorizations (policy-rights) the request is relayed to the enabled service for execution. Generic PEP Operations: Generic PEP Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 104 Authorization Class Diagram - Interface Descriptions ASinternal The Authorization Service expects all PEPs to express policy requests in the form of a context request messages and will, in turn, supply context response messages when returning a policy decision. The following describes the information that can be provided to the AS within an context request message: Information Element: Information Exchange Framework Reference Architecture, Initial Submission 215

236 Table 104 Authorization Class Diagram - Interface Descriptions 1. SUBJECT: This is the unique identifier of the originator of the policy request. This is the user that initiated the data transaction that requires a policy check. The PEP determines the unique identity of the user and encodes this information within the Subject element of the expression. 2. RESOURCE: This is the caveat in the security marking on the information asset that is being requested by the user. The PEP, often leveraging the Security Marking Service, acquires the caveat from the asset and encodes this information within a Resource element of the expression. 3. ACTION: This is the action that is being performed against the data asset. The action is encoded within an Action element of the expression. ASinternal Operations: Policy_Request: The following describes the information that can be provided to the AS within an policy request message: Subject: This is the unique identifier of the originator of the policy request. This is the user that initiated the data transaction that requires a policy check. The PEP determines the unique identity of the user and encodes this information within a Subject element of the policy request expression. Resource: This is the caveat in the security marking on the information asset that is being requested by the user. The PEP, often leveraging the Security Marking Service, acquires the caveat from the asset and encodes this information within a Resource element of the policy request expression. The source of the caveat will depend on the data asset being requested. For example, a file will hold caveat information within a security marking whereas an IM chat room will have the caveat stored as a property of the room itself. Action: This is the action that is being performed against the data asset.the action is encoded within an Action element of the policy request expression. The action value can take any alphanumeric textual form (e.g.read,write). Operation Parameters: 216 Information Exchange Framework Reference Architecture, Initial Submission

237 Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 105 Authorization Class Diagram - Association Descriptions PEP's submit policy requests that contain: the requesting user s identity, security attribute information of the desired information asset and a statement of the operation that is being performed on the resource. Owner: IEF Service Elements Owner: IEF Service Elements Security policies are stored in a database that is queried by the PDP to access the policies that are relevant in the evaluation of a policy request. The PDP requests relevant policies from the security policy repository over SQL. The repository returns these policies to the PDP and the PDP evaluates the policy request in the context of the retrieved policies. Owner: IEF Service Elements The AS extracts the policy request from the payload and sends the request to its PDP processing module. Owner: IEF Service Elements Cryptography Class Diagram Information Exchange Framework Reference Architecture, Initial Submission 217

238 Figure 1 -Cryptography Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 106 Cryptography Class Diagram Descriptions Cryptographic Service Provider External user specified/provided cryptographic application(s) or appliance(s) that perform the actual encryption/decryption functions. Cryptographic Service Provider Operations: Cryptographic Service Provider Key Escrow The key escrow system stores keys and allows them to be retrieved using a key token to specify the key The key token is supplied by the escrow system and the format of the token is, therefore, specific to the key escrow solution. Key Escrow Operations: Key Escrow KeyGenerator A key generation service that will create the needed cryptographic keys. KeyGenerator Operations: 218 Information Exchange Framework Reference Architecture, Initial Submission

239 Table 106 Cryptography Class Diagram Descriptions Key Management Service KeyGenerator The KMS is a bridging component that will link cryptographic key requests from the CTS to two separate subcomponents in the target environment: 1. A key generation service that will create the needed keys; and 2. A key escrow system that will store the keys and allow them to be retrieved using the key token to specify the key that is to be retrieved. The key token is supplied by the escrow system and the format of the token is, therefore, specific to the key escrow solution. Key storage and retrieval operations are performed by the KMS by reformulating the key request to the format required by Key Escrow implementation. Each IEF protected data or information element is encrypted with its own unique key and the KMS provides all symmetric key management functions that are needed by the IEF Cryptographic Transformation Services (CTS). Key Management Service Operations: Key Management Service Cryptographic Transformation Service The Cryptographic Transformation Service (CTS) provides the interface between the PEP and the user specified/provided cryptographic application(s) or appliance(s) that : Encrypt information assets; and Decrypt information assets for authorized users. The application of cryptographic services is dependent on the type of asset being protected. The CTS provides protection for the following data types: Files are encrypted when they are transferred from the user s workstation to the IEF protected file share and decrypted when they are retrieved from the file share for delivery to an authorized user. messages, including attachments, are encrypted when they are stored/prepared for delivery and decrypted when a user retrieves the from the server. IM messages are encrypted as they are exchanged by the IM server. Only when a user is permitted to enter a chat room are these message decrypted and delivered. Structured Message payloads and attachments are encrypted prior to release by an information dissemination service. Cryptographic Transformation Service Operations: Cryptographic Transformation Service Information Exchange Framework Reference Architecture, Initial Submission 219

240 Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 107 Cryptography Class Diagram - Interface Descriptions KMSInternal The message response format is an XML-based message format with name-value pairs to specify the returned values. All response messages are comprised of a list element that contains the name-value pairs and a status element that reports the completion state of the response: success or error. For the KMS, all list messages are defined as keyop responses. The following describes the name-value pairs that are returned for each key command: GENERATE_STORE = key: newly generated key, token: key token that was provided by the key escrow system when the key was stored. RETRIEVE_KEY=key: key that was retrieved from the key escrow system for the key token that was supplied in the RETRIEVE_KEY call The KMS will return an error code to the caller if any of the following conditions are encountered: Message cannot be parsed due to a malformed request; No action element was specified in the request or the action is unsupported; The key or token could not be extracted from the request; or An error occurred in one of the external service providers. KMSInternal Operations: RETRIEVE_KEY: If the message is a RETRIEVE_KEY command, the KMS performs the following actions: 1. The KMS extracts the supplied key token that was specified in the resource element of the context message. 2. The KMS formulates a key retrieval request that includes the key token and sends it to the key escrow system over a protected session. 3. The key escrow system returns a response that contains the requested key.. 4. The KMS formulates a response message with the key token and the key and sends the payload to the CTS. Operation Parameters: 220 Information Exchange Framework Reference Architecture, Initial Submission

241 Table 107 Cryptography Class Diagram - Interface Descriptions CTSinternal DESTROY_KEY: If the message is a DESTROY_KEY command. 1. The KMS extracts the supplied key token that was specified in the resource element of the context message. 2. The KMS formulates a key destruction request that includes the key token and sends it to the key escrow system over a protected session. Operation Parameters: GENERATE_STORE: If the message is a GENERATE_STORE command, the KMS performs the following actions: 1. The KMS calls the cryptographic library, to request a key. 2. The KMS formulates a key storage request and sends it to the key escrow system over a protected session. 3. The key escrow system returns a response that contains a key token. 4. The KMS formulates a response message with the key token and the key and sends the payload to the CTS. Operation Parameters: CTS message format for cryptographic responses: XML-based message format with name-value pairs to specify the returned values. All messages are comprised of a list elements that contains the name-value pairs and a status element that reports the completion state of the response: success or error. all list messages are defined as cryptoop responses. COPY_ENCRYPT = target, path to container file COPY_DECRYPT = target, path to plain text file FILE_ENCRYPT_TOKEN = target, path to cypher text file FILE_DECRYPT_TOKEN = target, path to plain text file The CTS will return an error code to the caller if any of the following conditions are encountered: Message cannot be parsed due to a malformed request; No action element was specified in the request or the action is unsupported; The source file for the operation cannot be accessed; or An error occurred in the external crypto library. CTSinternal Operations: COPY_DECRYPT: If the requested action is COPY_DECRYPT the CTS will perform the following operations: 1. Perform a digest hash of the contents of the container and compare the Information Exchange Framework Reference Architecture, Initial Submission 221

242 Table 107 Cryptography Class Diagram - Interface Descriptions result to the digest that is stored in the container to ensure that the container has not been tampered with. 2. Retrieve the token from the container. 3. Use this token in a RETRIEVE_KEY message and send this message to the KMS. The KMS will return the associated key for this token. 4. Use this retrieve key in a call to the Crypto library to transform the source file into a decrypted version of that file. Once the original file has been successfully decrypted, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the decryption process will be reflected in the response message to the PEP. Operation Parameters: COPY_ENCRYPT: If the requested action is COPY_ENCRYPT the CTS will perform the following operations: 1. Extract the security marking from the Environment element of the message. 2. Formulate and send a GENERATE_STORE message to the KMS and receive a key and token in response. Since the CTS is being requested to create a new encrypted asset, a new unused key is required from the KMS. 3. Use this new key in a call to the Crypto library to transform the source file into an encrypted version of that file. 4. Generate a hash digest of the encrypted file using the methodology described in the previous section. 5. Create a new container file (ZIP archive) with the name of the target file and add the following data to the container: the encrypted payload, token, the hash digest, the original filename of the file (taken from source) and the marking. Once the container has been successfully created, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the encryption process will be reflected in the response message to the PEP. Operation Parameters: FILE_ENCRYPT_TOKEN: If the requested action is FILE_ENCRYPT_TOKEN the CTS will perform the following 222 Information Exchange Framework Reference Architecture, Initial Submission

243 Table 107 Cryptography Class Diagram - Interface Descriptions operations: 1. Extract the token from the Environment element of the message. 2. Use this token in a RETRIEVE_KEY message and send this message to the KMS. The KMS will return the associated key for this token. 3. Use this retrieved key in a call to the Crypto library to transform the source file into an encrypted version of that file. Once the encrypted file has been successfully created, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the encryption process will be reflected in the response message to the PEP. Operation Parameters: FILE_DECRYPT_TOKEN: If the requested action is FILE_DECRYPT_TOKEN the CTS will perform the following operations: 1. Extract the token from the Environment element of the message. 2. Use this token in a RETRIEVE_KEY message and send this message to the KMS. The KMS will return the associated key for this token. 3. Use this retrieved key in a call to the Crypto library to transform the source file into a decrypted version of that file. Once the decrypted file has been successfully created, the CTS can return a status message to the PEP indicating that the operation is complete. Any errors encountered in the decryption process will be reflected in the response message to the PEP. Operation Parameters: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 108 Cryptography Class Diagram - Association Descriptions This system should support key storage and retrieval over a protected connection Owner: IEF Service Elements Information Exchange Framework Reference Architecture, Initial Submission 223

244 Table 108 Cryptography Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements When a key is needed, the CTS sends a context request message that contains the key operation request. Owner: IEF Service Elements Identity Management Class Diagram This service provides supplemental security attribute information related to IEF users. This supplemental information can be requested through the service s interface by any component with a need to know user attribute information. Typically the Authorization Service (AS) is the only IEF component that leverages the IMS to retrieve security attribute information. The Authorization Service requests security attributes for a given IEF user in the context of evaluating a policy request. 224 Information Exchange Framework Reference Architecture, Initial Submission

245 Figure 1 -Identity Management Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 109 Identity Management Class Diagram Descriptions Identity Management Solution User specified/provided system for managing electronic identities. The system framework includes the technology needed to support identity management, which enables the administration of electronic identities within an environment (such as a country, a community of interest, a coalition, a network, or an enterprise) and controlling their access to resources within that system by associating user rights and restrictions with the established identity. IdM systems are used to initiate, capture, record and manage user identities and their related access permissions in an automated fashion. This ensures that access privileges are granted according to one interpretation of policy and all individuals and services are properly authenticated, authorized and audited. Identity Management Solution Operations: unnamed1: Operation Parameters: Identity Management Solution Information Exchange Framework Reference Architecture, Initial Submission 225

246 Table 109 Identity Management Class Diagram Descriptions IdentityManagementRepos itory The Identity Management Repository is the IEF's authoritative source for users identity and security attributes, including nationality, clearance level and membership in communities of interest. IdentityManagementRepository Operations: IdentityManagementRepository Identity Management Service Identity Management Service is an essential part of the IEF safeguarding infrastructure. It provides a bridge to an external user provided Identity Management Solution. During a standard policy request the Authorization Service leverages the Identity Management Service to retrieve a user s security credentials. Identity Management Service Operations: Identity Management Service Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 110 Identity Management Class Diagram - Interface Descriptions IMSinternal The IMS receives a message payload in form of a formatted search request. The following information can be provided to this service as part of an information request: 1. ACCOUNT NAME: This is the name that uniquely identifies the user for which the security attributes are requested. 2. SECURITY ATTRIBUTE: This is the list of attributes that are requested from the identity management repository for the specified user. IMSinternal Operations: REQUEST_USER_CREDENTIALS: When the IAS receives a message from another IEF component such as the Authorization Service, information in the request is extracted including: Account : the unique account name of the user and Identifying the security attributes that are to be extracted. This identity attribute request information is reformatted into an equivalent query format. A connection is made to the SecurityAttributeRepository and the query is run. 226 Information Exchange Framework Reference Architecture, Initial Submission

247 Table 110 Identity Management Class Diagram - Interface Descriptions The response from the server is parsed to extract the returned information for the queried user. The response format includes the name of the requested user and individual specification for each security attribute that was requested. Requested attributes may include: nationality: Text representing the user s nationality. clearance: Text representing the user s clearance. caveats: A comma separated list containing all the communities to which the user belongs This information is placed into an appropriate message response and sent to the requesting component.should the user not exist or if any of the requested attributes is unspecified, a fully formed response message will be returned to the requester with an empty value. Operation Parameters: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 111 Identity Management Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Logging Class Diagram The TLS supports the integrity of the IEF trust model through the creation of log file records that are linked via a chain-of-custody to ensure tampering has not occurred Information Exchange Framework Reference Architecture, Initial Submission 227

248 within the audit trail. The records that are protected and stored through the TLS keep a transactional history of the policy decisions and access control enforcement across all IEF protected resources. Since all policy enforcement activities are recorded within the TLS and the integrity of the TLS can be demonstrated, the TLS can be used to track information access requests and the rationale for why information was disclosed to IEF users. Figure 1 -Logging Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 112 Logging Class Diagram Descriptions IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. The information exchange protocol conforms to industry accepted, open standards that are based on XML(e.g., extensible Messaging and Presence Protocol (XMPP)). The messaging services/infrastructure) provisions information (messages) between IEF services /components). Although the specific protocol, 228 Information Exchange Framework Reference Architecture, Initial Submission

249 Table 112 Logging Class Diagram Descriptions format and content of the messages will depend on the nature of service being accessed, all messages are delivered through the same communications mechanism. The ability to provide robust, secure and trusted delivery of security messages between IEF services forms the critical core of the IEF architecture. IEF Secure Messaging Service Operations: IEF Secure Messaging Service SecureLogStore Generic PEP A special-purpose database designed to provide a tamper-resistant record of IEF events and transactions (e.g., policy decision activities) in a manner that enables both real-time Security Incident and Event Monitoring and longer-term forensic activities. SecureLogStore Operations: unnamed1: Operation Parameters: SecureLogStore The PEP intercepts each request and response between the user (e.g., service clients, and applications) and the IEF enabled services (e.g., file share, , Instant Messaging, and message dissemination). The PEP provides the ability to link an information exchange service to the IEF safeguarding infrastructure. The PEP then verifies that the user has the authorizations to perform the operation and that the operation is permitted for the information asset on the designated device(s). If the User has the authorizations (policy-rights) the request is relayed to the enabled service for execution. Generic PEP Operations: Generic PEP TrustedLogFile A tamper-resistant record of policy decision and effected operations. The log supports both Security Incident and Event Monitoring (SIEM) and long-term forensic activities. Each IEF transaction is recorded in a manner that resists tampering and alteration of the log records. The log is intended to maintain a chain-of-custody record for all information elements protected by an IEF implementation. The log uses an XML-based schema that includes information such as: 1. The identity of the user that requested the data transaction; 2. The identities of the users (e.g., recipients, target devices, target services) involved in the request; 3. The IP address of the PEP that handled the transaction; 4. The name/type of PEP that handled the transaction; 5. The operation requested on the data asset; 6. The name of the target asset (e.g. file name); and 7. A timestamp generated by the IEF pertaining to when each transaction was Information Exchange Framework Reference Architecture, Initial Submission 229

250 Table 112 Logging Class Diagram Descriptions handled. Each log record is encrypted in motion and storage and assigned a chained digital signature. TrustedLogFile Operations: TrustedLogFile Trusted Logging Service The Trusted Logging Service (TLS) is one of the central IEF Security Services and is the key service for maintaining and demonstrating the integrity of IEF information protection processes.. The Trusted Log Files that are protected and stored though the TLS keep a transactional history of the policy decisions and access control enforcement across all IEF protected resources. Since all policy enforcement activities are recorded within the TLS and the integrity of the TLS can be demonstrated, the TLS can be used to track information access requests and the rationale for why information was disclosed to IEF users. Trusted Logging Service Operations: Trusted Logging Service SecurityEventManagement Security Event Monitoring solution that accepts TLS error condition messages and raises an alert about this condition and sends an message to a security officer. The TLS supports security event notification. When an error condition is encountered, the TLS will create and submit a TLS message to an appropriate facility within the deployment environment. Error conditions are raised whenever a IEF component fails to service a request (e.g. a back end database is offline) or when there is a violation of implicit security logic. For example, the policy denial for the retrieval of a file from a protected file share should not happen and may be indicative of malicious activity. In such a case, the TLS would submit a syslog message in addition to an audit record. The TLS configuration specifies the target syslog service. A SIEM deployment may be configured to read in syslog messages stored by the co-located syslog server. The SIEM solution processes each syslog event to determine if it should be raised as a security event. Security events are sent to a Security Officer as messages SecurityEventManagement Operations: 230 Information Exchange Framework Reference Architecture, Initial Submission

251 Table 112 Logging Class Diagram Descriptions SecurityEventManagement Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 113 Logging Class Diagram - Interface Descriptions SecureLoggingAdminPoin t Use of the interface through which log file records are reviewed must be, itself, an IEF policy-based data exchange. That is, the interface that is used to perform audit analysis, audit review and forensic activities must enforce the domain s security policy. As an example, the access right to review log file records could be assigned to a specific community; only those users that belong to that community will have access to the SLAP interface. Use of this interface would then be subject to all IEF protection from access control to auditing. 1. Provides a web-based interface to the Audit Reviewer on the front end; and 2. Includes database connectivity that can be used to retrieve log file records from the repository. Since the SLAP is a web interface, access to the service can be controlled through the use of a Web Session PEP SecureLoggingAdminPoint Operations: TLSinternal Trusted log records are sent from the PEPs to the TLS and formatted as XML records based on a fully specified schema. Since PEPS are the principle clients of the TLS each PEP logs with it's unique identifier attached to every log instance. TLSinternal Operations: Process_Log_Record: Principal. userid:the identity of the IEF user that initiated the data request associated with this log file record. This is the same identity that was Information Exchange Framework Reference Architecture, Initial Submission 231

252 Table 113 Logging Class Diagram - Interface Descriptions used in the policy check to the AS. ipaddress: The address of the PEP that submitted the log file record. program: An identifier of the type of PEP that submitted the log file record. Action. operation: What action was performed on the data. In this context, the action is the policy action (e.g. READ,WRITE) that was submitted to the AS for a policy decision. target: The resource against which the policy decision was made. In this context, the target is the security marking of the asset against which the policy decision was made. tacorigin: A identifier that uniquely differentiates the log file record created by this PEP from those of other PEPs. notes: A free form section in which per operation or per file type data can be inserted into an log file record. timestamp: A timestamp on the log file record, referencing the time when the log file record was created. Operation Parameters: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 114 Logging Class Diagram - Association Descriptions If the log file record is for an security event (i.e. represents a security incident or includes a processing error code), the TLS generates a syslog record. The syslog record is described using the following format (10 elements, comma separated): a. The time that the event record was generated (the TLC timestamp); b. The IP address of the TLS that processed the audit record; c. The identity of the user that created the audit record; d. The resource that was requested as part of the transaction; e. The requested policy action on the resource (e.g. READ/WRITE); f. The IP address of the PEP that created the audit record; g. The program name (PEP) that generated the audit record; h. The requested IEF operation on the resource (e.g. file policy check); i. The error code associated with the transaction; and j. The text for the error condition associated with the transaction 232 Information Exchange Framework Reference Architecture, Initial Submission

253 Table 114 Logging Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements stores creates A PEP that receives an information request will generate an log file record to state whether the transaction was permitted or denied as per the security policy, this transaction includes the ancillary meta data to support a complete audit record. The PEP will also create log file records for error conditions that are reported from IEF security services. For example, if a file s security label cannot be extracted. Such a transaction is submitted to the TLS with the error condition reported within the record. Owner: IEF Service Elements Architecturally, the PEPs submit audit records to the TLS and the TLS stores the processed (integrity protected) auditable records in an independent repository. These records are stored as signed and encrypted files to protect the integrity of the system and to provide a trusted auditable record of security transactions within the IEF. The TLS uses direct SQL inserts to store the records in the repository. Owner: IEF Service Elements Owner: IEF Data Elements Marking Class Diagram The SMS Service is a bridging component that will link IEF Security Marking request messages to software modules or external services that are able to interpret the security attribute information that is bound with specific information assets. Information Exchange Framework Reference Architecture, Initial Submission 233

254 Figure 1 -Marking Class Diagram Class Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 115 Marking Class Diagram Descriptions IEF Secure Messaging Service In the IEF data protection is provided by a set of interconnected services that work through the exchange of messages on two separate and isolated messaging infrastructures: A security messaging infrastructure that carries policy data, security attributes and cryptographic information; and An messaging infrastructure that carries auditable operational logging information. The information exchange protocol conforms to industry accepted, open standards that are based on XML(e.g., extensible Messaging and Presence Protocol (XMPP)). The messaging services/infrastructure) provisions information (messages) between IEF services /components). Although the specific protocol, format and content of the messages will depend on the nature of service being accessed, all messages are delivered through the same communications 234 Information Exchange Framework Reference Architecture, Initial Submission

255 Table 115 Marking Class Diagram Descriptions mechanism. The ability to provide robust, secure and trusted delivery of security messages between IEF services forms the critical core of the IEF architecture. IEF Secure Messaging Service Operations: IEF Secure Messaging Service Security Marking Service Generalization for the File, IM, , Web and Structured Messaging Marking Services. These services enable the IEF to apply, extract, verify and validate markings on data objects. Security Marking Service Operations: Security Marking Service Generic PEP The PEP intercepts each request and response between the user (e.g., service clients, and applications) and the IEF enabled services (e.g., file share, , Instant Messaging, and message dissemination). The PEP provides the ability to link an information exchange service to the IEF safeguarding infrastructure. The PEP then verifies that the user has the authorizations to perform the operation and that the operation is permitted for the information asset on the designated device(s). If the User has the authorizations (policy-rights) the request is relayed to the enabled service for execution. Generic PEP Operations: Generic PEP ImMarker As a component of the IM PEP, the IM Marker sets the security markings for each chat room. Chat rooms must be initialized before they can be made available to IEF users. The initialization process is performed by the IMMarker that creates/initiates a chat room by: 1. Assigning the new chat room to a COI (the default community); 2. Setting the markings at the chat room; and 3. Acquiring a new cryptographic key that will be used to protect messages in the chat room. The IMMarker places the default COI and key token within the description field for the chat room as it is defined at the IM server ImMarker Operations: ImMarker unnamed1: Information Exchange Framework Reference Architecture, Initial Submission 235

256 Table 115 Marking Class Diagram Descriptions FileMarker Software service that integrates with an off-the-shelf file manager, file browser or office application which obliges and enables an authorized user to appropriately mark files. FileMarker Operations: FileMarker WebServiceMarker Marker The PEP service used to bind the security markings to the web service site certificate for each protected site.. The security markings for each web service are set at the Web Services PEP. WebServiceMarker Operations: unnamed1: Operation Parameters: WebServiceMarker Software service that integrates with an off-the-shelf client that obliges and enables an authorized user to appropriately mark the and its attachments. In the service of the PEP the Marker retrieves the markings from messages and attachments. Marker Operations: Marker StructuredMessageMarker The PEP service used to: Bind security markings to a structured message. Retrieve security markings from a structured message. StructuredMessageMarker Operations: StructuredMessageMarker Interface Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Table 116 Marking Class Diagram - Interface Descriptions SMSInternal SMSInternal Operations: VALIDATE_MARKINGS: Operation Parameters: EXTRACT_MARKINGS: 236 Information Exchange Framework Reference Architecture, Initial Submission

257 Table 116 Marking Class Diagram - Interface Descriptions Operation Parameters: FILE_GET_MARKINGS: If the requested action is FILE_GET_LABEL the SMS will perform the following operations: 1. Determine the type of the target file. 2. If the file is an external file (Microsoft Office file with a security label) the SMS will open the custom.xml file in the file s archive format and retrieve the caveat list from the caveats property. 3. If the file is an internal file (IEF protected file) the SMS will open the container (archive file) and retrieve the caveat list from the caveats file. Once the caveats have been successfully retrieved, the SMS can return a status message to the PEP indicating that the operation is complete along with a comma separated list of the caveats found. Any errors encountered in the retrieval process will be reflected in the response message to the PEP. The SMS will return an error code to the PEP if any of the following conditions are encountered: unsupported; the operation cannot be accessed; or MarkingAdminPoint Operation Parameters: MarkingAdminPoint Operations: BIND_KEY_TOKEN: Operation Parameters: BIND_CONSTRAINTS: Operation Parameters: BIND_SENSITIVITY: Operation Parameters: BIND_INFORMATIONAL: Operation Parameters: Association Descriptions The following tables identifies the descriptions for each of the classes identified on the previous figure. Information Exchange Framework Reference Architecture, Initial Submission 237

258 Table 117 Marking Class Diagram - Association Descriptions Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements The PEP makes a call to the SMS that will extract security marking information from the information asset. Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Owner: IEF Service Elements Secure Asset Container Class Diagram #printclasscasediag ($usediag) 238 Information Exchange Framework Reference Architecture, Initial Submission

259 13.3 Sequence Diagrams The following clauses provide the Sequence diagrams for common IEF services. To be added. Information Exchange Framework Reference Architecture, Initial Submission 239

260 14 Policy Vocabularies To be added 240 Information Exchange Framework Reference Architecture, Initial Submission

261 Annex F: Bibliography (Informational) The following are informational Elements referenced in this specification: ISO/IEC JTC1 SC32 WG2 is the Working Group that develops international standards for metadata and related technologies: -- home page of ISO JTC 1 SC32 WG 2, where the ISO standard documents extensible Access Control Markup Language (XACML); from OASIS; Information Exchange Framework Reference Architecture, Initial Submission F-1

262

263 Annex G Terms and Acronyms (Informational) General Terms and s The following represent more general terms used in this specification: Accurate: Information that exactly, precisely, and correctly presents availability, usability and deployability of C4ISR capability, systems and services. Adaptive Information Sharing: The ability to selectively share information content based on operational or business context (e.g., roles, relationship, risks, threats, severity, scale, and trust). This includes the ability of users (manually) or systems (automatically) to adjust active ISS Policies to accommodate changes in business and operational context. Active Policy: The set of policies (/rules) that are instantiated and set active for one or more of the environment policy enforcement and decision points. Aggregation: Defines the process through which data elements are combined to referentially and semantically complete data sets. Asymmetric Information Sharing: The ability to share content with different communities, agencies or individuals conforming to legislative, regulatory, policy, contractual of service level requirements while leveraging standard or shared protocols, interfaces and infrastructure. Caveat: a warning or proviso of specific stipulations, conditions, or limitations to the sharing of data and information elements. Caveat Separation: The process for selective exchange of information based on security policy and security profiles of the information and consumer of the information. Caveat separation may apply to data elements with the information or the aggregation of information. Challenged Networks or Communication: Under operational conditions most front line communications are provided by radio (HF, VHF, or HCDR). These forms of communications are inherently less robust than the Wi-Fi and wired networks realized by most organizations. Challenged refers to the reality that these networks: Have limited bandwidth capability (as low as 1Kb/Sec); Are prone to outages (e.g., range limitations, jamming, and voice override); Large node count; and Packet loss. Classified Information: Classified information is sensitive information to which access is restricted by law or regulation to particular classes of persons. A formal security clearance is required to handle classified documents or access classified data. Coalition: An alliance for combined action of distinct parties, persons, or states, without permanent incorporation into one body. Common Operating Picture (COP): A collaborative set of technologies that provide the user(s) with a shared understanding of the operational environment including: Threats; Opportunities; Resources; Situational Awareness and other relevant information. The technologies combine to integrate perspectives; deliver actionable knowledge and structure information to the specific User(s) needs. Common Representational Operating Picture (CROP): Is equivalent to the COP but limits access to that information required to exercise the role or function of the user. Communication Channel: A Information Exchange Framework Reference Architecture, Initial Submission G-1

264 means of communication or access. For the purposes of this specification communication channels will be limited to the middleware used to move information between suppliers (/publishers) and consumers (/subscribers). Community: A community of interest or community of practice. Community of Interest (CoI): A collaborative group of users that must exchange information in pursuit of its shared goals, interests, missions, or business processes and therefore must have shared vocabulary for the information exchanges. DoD , December 2, Or, a group of people interested in sharing information and knowledge in a particular topic or domain of discourse. Community of Practice: Informal, self-organized, network of peers with diverse skills and experience in an area of practice or profession. Such groups are held together by the members' desire to help others (by sharing information) and the need to advance their own knowledge. Or, a group of people or organizations that are active practitioners in a domain of activity (e.g., Emergency Management, Law Enforcement, Military Operation) and where it is not appropriate for non-practitioners to participate. Conceptual Interoperability: The assumptions and constraints of the meaningful abstraction of reality are aligned, the highest level of interoperability is reached. This requires that conceptual models are documented based on engineering methods enabling their interpretation and evaluation by other engineers. Confidential Information: Privileged communication shared with only a few people for furthering certain purposes, such as with an attorney for a legal matter, or with a doctor for treatment of a disease. Receiver of confidential information is generally prohibited from using it to take advantage of the supplier of that information. Content Centric: refers to both information-centric and data-centric. Contract: (source: SOPES and UPDM) A contract represents a grouping of Semantic construction rules and information flow controls which specify a formal information sharing agreement between two or more operational nodes or participants in a domain or community. Equivalent terms in this specification are Information Exchange Agreement, Information Exchange Specification and Information Exchange Contract. Crisis Management: Coordinated actions taken to diffuse crises, prevent their escalation into armed conflict and/or contain resulting hostilities. The crisis management machinery provides decision-makers with the necessary information and arrangements to use appropriate instruments (political, diplomatic, economic, and military) in a timely and coordinated manner. (MC 400/1). Data: facts used usually to calculate, analyze, or plan. Data Centric: enforce policies/rules against individual data assets; often referring to metadata or tags included within an information asset. Data Composite: A data set resulting from the aggregation of data elements. Data Integrity: Compliance to the allowable types, ranges or domain values for each data element (or attribute). Data Integration: The process of combining two or more data elements from separate sources into a single semantically and referentially complete piece of information (or business object). Data ownership: Identification that the data or information is controlled by the entity in such a way that only that entity is allowed to modify the data or information elements. Data Packaging: see Information Packaging. G-2 Information Exchange Framework Reference Architecture, Initial Submission

265 Data Pattern: A plan, diagram, or model to aggregate data elements. Data Stewardship: Accountable for integrity and quality of data. Deadline: A QoS attribute describing the latest acceptable time for the occurrence of certain events. Decision Advantage: Enable commanders and/or decision makers, based upon information advantage and situational understanding, to make effective and informed decisions more rapidly than the adversary, thereby allowing one to dramatically increase the pace, coherence, and effectiveness of operations. Derived from: Decision Superiority: U.S. Joint Forces Command Glossary Defence-in-Depth: The coordinated application of multiple security services (countermeasures) to protect the integrity of the assets and resources of an enterprise. The strategy is based the principle that it is more difficult for an adversary to defeat a complex and multi-layered defense than to penetrate a single barrier. Defence-in-Depth (for data/information assets) : A layering information safeguards to protects a specific information asset based on the reported value of key of that asset (e.g., security and privacy tags) bound to the instance of the information or data element. : A representation of a concept by a descriptive statement which serves to differentiate it from related concepts. Domain: A sphere of knowledge or information identified by a name. Dynamic Coalition: A dynamic coalition may be formed spontaneously, members may join and leave without warning, and the nature of the relationships between participants may vary dramatically across the coalition as well as throughout its lifetime. Dynamic Interoperability: As a system operates on data over time, the state of that system will change, and this includes the assumptions and constraints that affect its data interchange. The systems are able to identify the state changes in the assumptions and constraints and they can adjust or be adjusted to address changes in context or situation. The effect of the information exchange within the participating systems is unambiguously defined. Information: Facts or details about a subject (Data in Context; composite of data elements used to inform a decision). Information Advantage: Enable the provision of information needed to develop a degree of control in the information domain that permits the conduct of operations without effective opposition. Derived from: Joint Warfighter S&T Plan Chapter IV Achieving Joint Warfighting Capability Objectives; Information Artifact: A composite of data elements that satisfy the Semantic construction rules for an agreement to exchange information between a supplier and a consumer. Information Centric: enforce policies/rules against individual information assets (assemblies of data elements that satisfy information-sharing requirements). Information Consumer: Any User, System Application, Channel or Node using information managed by the IEPPS. Information Contract: An agreement between an information supplier and information consumer to exchange selected information, based on a specified format, protocol and communication link. Information Quality: Describes the ability of organizations, systems and persons to provide information that is: Information Exchange Framework Reference Architecture, Initial Submission G-3

266 Trustworthy: Information quality and content can be trusted by stakeholders, decision makers and users; Relevant. Information content tailored to specific needs of the decision maker; Timely. Information provided when and where it is needed to support the decision making process; Usable. Information is presented in a common functional format, easily understood by the decision makers and their supporting applications; Complete. Information that provides all necessary and relevant data (where available) to facilitate a decision; Concise: Information is provided in a form that is brief and succinct, yet including all important information; Trusted: Information that is accepted as authoritative by stakeholders, decision makers and users; Secure: Information is protected from inadvertent or Malicious Release to unauthorized persons, systems or organizations; and Protected: Information is protected from inadvertent or malicious release. Information Packaging: The process of assembling (aggregating, transforming, tagging/marking and redacting/filtering) data and information elements and formatting them to service a specific information exchange requirement. Information Processing: The parsing, transformation and marshaling of information and data elements to information or data store(s). Information Supplier: This includes any user, application or system providing information to the environment. Instrument: See Policy Instrument. Legally Significant: Levels of Interoperability: The level to which practices and services deliver the ability and capacity to ensure the right information is available to the right people or system at the right time. Level 0: Stand-alone systems have No Interoperability or Integration. Level 1: On the level of Technical Interoperability, a communication protocol exists for exchanging data between participating systems. Level 2: The Syntactic Interoperability level introduces a common structure to exchange information; i.e., a common data format is applied. Level 3: If a common information exchange reference model is used, the level of Semantic Interoperability is reached. On this level, the meaning of the data is shared; the content of the information exchange requests are unambiguously defined. Level 4: Pragmatic Interoperability is reached when the interoperating systems are aware of the methods and procedures that each system is employing. Level 5: As a system operates on data over time, the state of that system will change, and this includes the assumptions and constraints that affect its data interchange. If systems have attained Dynamic Interoperability, they are able to comprehend the state changes that occur in the assumptions and constraints that each is making over time, and they are able to take advantage of those changes. G-4 Information Exchange Framework Reference Architecture, Initial Submission

267 Level 6: Finally, if the conceptual model i.e. the assumptions and constraints of the meaningful abstraction of reality are aligned, the highest level of interoperability is reached: Conceptual Interoperability. Local Services: Services defined and used by the user community to perform a specific set of functions. Marshaling: Defines the process through which data sets are divided and put into the data elements described by the underlying data store(s). Memorandum of Understanding (MOU): A bilateral or multilateral agreement between parties. Messaging Protocol: The rules, formats and functions for exchanging messages between the components of a messaging system. Middleware: Software that serves as an intermediary between systems software and an application. Multilevel Security (MLS): Information systems and networks that provide the ability to process information with incompatible classifications (i.e., at different security levels and caveats). These systems and networks permit access to information elements by authorized users (users holding the appropriate security clearances and needs-to-know), and prevent access to users that lack authorization. Ontology: "In the context of knowledge sharing, the term ontology means a specification of a conceptualization. Ontology is a description (like a formal specification of a program) of the concepts and relationships that can exist for an agent or a community of agents. This definition is consistent with the usage of ontology as set-of-concept-definitions, but more general. And it is certainly a different sense of the word than its use in philosophy." DOI: /knac DOI: /ijhc Operating Concept: It describes the operating characteristics for a system, typically from the viewpoint of the individuals who will use that system. It also used describes how the set of systems capabilities (e.g., services, decision & enforcement points and interfaces) may be employed to achieve a desired objective or end state. Ideally it offers a clear methodology to realize the goals and objectives for the system, while not intending to be an implementation or transition plan itself. The following elements that may be include: Statement of the goals and objectives; Operational conditions/contexts affecting the system; Organizations, activities, processes and interactions among participants using the system; Specific operational concept and processes for fielding the system; and Processes for initiating, developing, maintaining and adapting the system. Operation: For the purpose of this RFP the term operation is restricted to events and activities describing a Crisis Response Action including Military. Operational Context: A set of network, node, system, application or user characteristics that define the current state of dynamically evolving operational conditions. Operational Domain: The sphere of knowledge, influence, or activity for a specific mission or operation. Pattern: A plan, diagram, or model to be followed in making things (in this instance dataset conforming to information sharing and safeguarding agreement). Planned Incident: An incident for which there exists standard operating procedures or safeguards to mitigate or recover from the impact of the incident. Planned Threat: A threat for which there exists standard operating procedures or safeguards to prevent or mitigate the impact of the threat. Information Exchange Framework Reference Architecture, Initial Submission G-5

268 Policy: "a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions." Within this document it refers to: "a defined course or method of action in response to a request for or change in information or data. Within the context of this specification, "specification of a method of action for aggregating, transforming and filtering data and information elements to conform to stipulated Semantic construction rules for an information sharing agreement or Community of Interest". Or, a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions (Webster Merriam Dictionary). Policy automation: The use of software services to automate the selection of a course of action (decision) and the execution of that selected course of action (execution). For the purpose of this RFP, this refers to the actions to be taken by IEF services (including decision and enforcement points) to share and safeguard information assets. Policy Driven: A process through which user defined policy instruments are translated into machine readable rules (/instructions) and enforced by software services and systems. This process results in full traceability from policy instrument to implementation (policy decisions and enforcement points). Policy Instrument: A formal business document used by organization to direct and describe methods or processes to be used or applied. These instruments may include: Legislation, regulation, agency policy, memorandum of understanding (MoU), and service level agreements (SLA). Or, formal document describing a plan of action by an individual agency or community to handle information sharing and safeguarding (e.g., legislation, regulation, memorandum of understanding and services level agreements). Policy Model: An architectural model aligning information sharing and safeguarding instruments with a specific data domain. Policy-Right: A permission granted through the application of a policy. Policy Transformation: The single or multi-stage transformation of policy instruments into machine readable and enforceable rules. Pragmatic Interoperability: The systems are aware of the methods and procedures that each system is using. The use of the data or the context of its application is understood by the participating systems; the context in which the information is exchanged is unambiguously defined. This layer puts the (word) meaning into context. Private Information: Information about behavior that occurs in a context in which an individual can reasonably expect that no observation or recording is taking place, and information which has been provided for specific purposes by an individual, which the individual can reasonably expect will not be made public. Proprietary Information: Privately owned knowledge or data, such as that protected by a registered patent, copyright, or trademark. Protocol Data Unit (PDU): Binary variable length messaging protocol used by the MIP Data Exchange Mechanism. QoS History: A record of past information generated by the system that is kept around for the benefit of applications that are late joining the network. QoS: See Quality of Service. Quality Information: provision of high-quality information tailored to the needs of the decision makers': G-6 Information Exchange Framework Reference Architecture, Initial Submission

269 a. Accurate. Information that exactly, precisely, and correctly presents availability, usability and deploy-ability of C4ISR capability, systems and services; b. Authoritative. information that is recognized or accepted as being true or reliable; c. Relevant. Information content tailored to specific needs of the decision maker; d. Timely. Information provided when and where it is needed to support the decision making process; e. Usable. Information is presented in a common functional format, easily understood by the decision makers and their supporting applications; f. Complete. Information that provides all necessary and relevant data (where available) to facilitate a decision; g. Concise: Information is provided in a form that is brief and succinct, yet including all important information; h. Trusted. Information that is accepted as authoritative by stakeholders, decision makers and users; and i. Secure. Information is protected from inadvertent or Malicious Release to unauthorized persons, systems or organizations. Quality of Service - A set of attributes that can be used to define the middleware's capabilities to meet the requirements of the application for the purpose of data-delivery or management such as reliability, ownership policy, history size, time-to-keep, etc. Real-time: Refers to the event-triggered (e.g. data change) global update of information across all nodes, systems and applications requiring access to the information. Redact: To obscure or remove (text or data) from a document prior to publication or release. This function is typically performed by data filters. Reference Architecture: defines abstract architectural elements within the domain in terms that are independent of specific technologies, protocols, and Tools. Reference Model: defines an abstract framework for understanding significant relationships among the entities comprising a domain. The reference model does not address specific standards, technologies or other concrete implementations, but provide common foundation for aligning and/or unambiguously comparing elements from different implementations. Releasable Dataset: A collection of data elements that can be provided to the recipient(s) as defined by policy. Releasable Message: A message where the content can be provided to the recipient(s) as defined by policy. Reliability: A QoS attribute describing the guarantees and feedback provided to the application regarding the delivery of the information supplied to the middleware. Responsible Information Sharing: Compliant with law, regulation and policy; consistent with community and agency strategy and direction, to include protect of information, sources and methods, and civil liberties and privacy; and accountable through governance and oversight - maximize the quantity and quality of information that is discoverable and accessible to authorized users and partners. Responsible Information Sharing (alternately): Compliant with legislation, regulation and policy; consistent with agency strategy, policy and direction; and accountable through governance and oversight: Information Exchange Framework Reference Architecture, Initial Submission G-7

270 Maximize the volume, variety and quality of information that is discoverable and accessible by authorized users; Protect sensitive (classified, private, confidential and legally significant) information from unauthorized access/release and tampering Protect information sources and processing-methods; Protect civil rights/liberties; and Ensure that information is assured in its content, safe in transmission and use, and safeguarded from the threat of malicious acts, unauthorized use, clandestine exfiltration or compromise by remote intrusion. derived from: 1. US Intelligence Community STRATEGIC INTENT FOR INFORMATION SHARING ( 2. National Security through Responsible Information Sharing ( and 3. A Legal and policy Approach for Responsible Information Sharing ( Semantic Integrity: Compliance to the structure, format and content (mandatory or optional) for information sets (or business objects). Semantic Interoperability: Semantics concerns the study of meanings. Semantic interoperability refers to the ability of information systems to exchange information/data with unambiguous, shared meaning. It is a requirement to enable information integration, machine analytics, inferencing, knowledge discovery, and data federation. Semantic interoperability is not only concerned with the packaging of data (structure and syntax), but the simultaneous provision of intent and meaning (semantics). Semantic Pattern: A plan, diagram, or model to aggregate Transactional patterns that conform to an information sharing and safeguarding agreement. Sensitive Information: Information elements identified as classified, private, confidential or legally significant. Service Level Agreement (SLA): An agreement between two or more parties where the level of service is formally defined. Specialized Data Set: A collection of data that is specifically tailored to a specific context and recipient. Specialized Message: A message for which the content is specifically tailored to a specific context and recipient. Stakeholder: a person with an interest or concern in the effective application of ISS Policy. Stage: To gather and prepare information for release to a community in accordance with established policy, memorandum of understanding or service level agreements. Syntactic Interoperability: A common structure to exchange information; i.e., a common data format is applied. On this level, a common protocol to structure the data is used; the format of the information exchange is unambiguously defined. G-8 Information Exchange Framework Reference Architecture, Initial Submission

271 Tearline: A physical line on a message or document separating categories of information that have been approved for disclosure and release. Technical Interoperability: An agreed communication protocol exists for exchanging data between participating systems. The protocol operates over an agreed and established communication infrastructure allowing systems to exchange bits and bytes, and the underlying networks and protocols are unambiguously defined. Trust: Within the scope of this RFP Trust refers to the level of confidence an information supplier has relating to the release of selected information to a specific consumer of that information. Unplanned Incidents: An occurrence of an action or situation that is not addressed by plans or operating procedures. Unplanned Threat: An expression of intention to inflict evil, injury, or damage that is not accounted for in the threat risk assessment or mitigation plans. Vocabulary: A representation of a set of concepts by formal, descriptive statements which serves to differentiate those concepts from related concepts within a given domain or area of expertise. Terminological dictionary (3.7.1) which contains designations (3.4.1) and definitions (3.3.1) from one or more specific subject fields (3.1.2). NOTE: The vocabulary may be monolingual, bilingual or Multilingual. ISO :2000. Acronyms The following acronyms are used as part of this specification. C4I COP CP CRO CROP DEM DHS DNDAF DODAF DTF EDXL EDXL-DE HCDR Consultation, Command, Control, Communications and Intelligence Common Operational Picture Compliance Point Crisis Response Operation Common Representative Operational Picture Data Exchange Mechanism Department of Homeland Security Department of National Defence Architecture Framework Department of Defense Architecture Framework Domain Task Force Emergency Data Exchange Language Emergency Data Exchange Language Distribution Element High Capacity Digital Radio Information Exchange Framework Reference Architecture, Initial Submission G-9

272 HF ICAM IE IEA IEAPV IECPV IEDM IEDPV IEF IEIPV IEM IEP IEPAS IEPL IEPMS IEPV IEPPS IEPPV IEQPV ISA ISE LEXS MDA MEM MIP MLS MODAF MOF MOU NAF NATO NGO OCL ODM High Frequency Identity, Credentials and Access Management Information Exchange Information Exchange Agreement Information Exchange Access Policy Vocabulary Information Exchange Credential Policy Vocabulary Information Exchange Data Model Information Exchange Dissemination Policy Vocabulary Information Exchange Framework Information Exchange Identity Policy Vocabulary Information Exchange Mechanism Information Exchange Policy Information Exchange Policy-based Authorization Service(s) Information Exchange Policy Language Information Exchange Policy Management Service(s) Information Exchange Policy Vocabulary Information Exchange Policy-based Packaging Service Information Exchange Packaging Policy Vocabulary Information Exchange Quality of Service (QoS) Policy Vocabulary Information System Application Information Sharing Environment Logical Entity exchange Specification Model Driven Architecture Message Exchange Mechanism Multilateral Interoperability Programme Multi-level Security Ministry of Defence Architecture Framework Meta-Object Facility Memorandum of Understanding NATO Architecture Framework North Atlantic Treaty Organization Non-Government Organization Object Constraint Language Ontology Metamodel G-10 Information Exchange Framework Reference Architecture, Initial Submission

273 OODBMS ORDBMS PDU PIM PM-ISE PSM PVO SLA SOPES UPDM UML XMI Object Oriented Database Management System Object-Relational Database Management System Protocol Data Unit Platform Independent Model Project Manager Information Sharing Environment Platform Specific Model Private Volunteer Organization Service Level Agreement Shared Operational Picture Exchange Services Unified Profile for DODAF and MODAF Unified Modeling Language XML Metadata Interchange Information Exchange Framework Reference Architecture, Initial Submission G-11

274

275 Annex H Conformance with RFP Mandatory Requirements The following table provides a conformance matrix to the mandatory requirements in the IEF RA RFP. Requirement Sub Element Addressed in Clause The Submissions shall define an IEF RA that includes: A PIM that defines the abstract architectural elements that makes up the IEF domain. The PIM shall be defined in terms independent of the technologies, protocols, and tools used to design, implement, and sustain responsible information sharing. This model will also define the interactions and communications between the elements defined in the IEF RA. The reference model will not address specific standards, technologies or other concrete implementations, but will provide a common foundation to align and/or unambiguously compare elements from different implementations IEF PSMs: providing one or more platform specific models, aligning IEF RA elements to specific open standards, protocols, tools, and technologies Discussion Information Exchange Framework Reference Architecture, Initial Submission G-1

276 Requirement Sub Element Addressed in Clause Discussion IEF Concept(s) of Operation: describing the operating characteristics for a system resulting from the implementation of an IEF reference model from the viewpoint of the user or operator. This would include: a. Statement of the goals and objectives; b. Operational conditions/contexts affecting the system; c. Organizations, activities, processes, and interactions among participants using the system; d. Specific operational concepts and processes for fielding the system; and e. Processes for initiating, developing, maintaining and adapting the system IEF Use Cases: providing guidance on how IEF RA elements are used to share and safeguard information. Submissions must address one or more of the following information sharing techniques: file sharing; ; text/instant messaging; Web Service; structured messaging (e.g., NIEM and OWL). G-2 Information Exchange Framework Reference Architecture, Initial Submission

277 Requirement Sub Element Addressed in Clause The following items identify key elements for the delivery of Policy-driven Data-centric ISS capability. The submissions shall define how these elements are combined (/integrated) to deliver a flexible, agile, and adaptive set of services that enforce user defined ISS policy at the data level. As a minimum, the submissions shall identify and describe architectural elements that include: A use case should define the features to be implemented and the resolution of any errors that may be encountered The description and requirements 6 for policy vocabulary elements to be enforced by each IEF service ( ). Note: the development of policy vocabulary extensions will be addressed in separate RFPs or RFCs. See Clause Error! Reference source not found.. Discussion The description and core requirements 7 for a set of information services that ingest and automatically enforce ISS policy at the data-level. Service descriptions and core requirements shall be provided for elements including: a. Policy decision and enforcement points for information sharing capabilities. 6 Vocabulary requirements should be specified at a level of detail equivalent to that in an RFP for the development of a policy vocabulary standard for a particular service. 7 Core requirements provided should be specified at a level of detail equivalent to that in an RFP for the development of a standard. Information Exchange Framework Reference Architecture, Initial Submission G-3

278 Requirement Sub Element Addressed in Clause b. Information security services, including: 1. Identity Management, 2. Credential/Attribute Management, 3. Authorization, 4. Encryption, 5. Information Asset Release; 6. Secure Storage; 7. Transaction Logging; 8. Channel / Domain Management; and 9. Information Assembly (e.g., aggregation, transformation, filtering/redaction, tagging/labeling/marking and formatting) and Processing (e.g., parsing, transformation and marshalling). c. User services: 1. Information Discovery, 2. Information Request, 3. Tagging, Labeling and Marking, 4. Policy Management & Administration, and 5. Auditing. d. Information Dissemination Services. Discussion G-4 Information Exchange Framework Reference Architecture, Initial Submission

279 Optional Requirements The following table provides a conformance matrix to the optional requirements in the IEF RA RFP. Requirement Sub Element Addressed in Clause Discussion Information Exchange Framework Reference Architecture, Initial Submission G-5

280 G-6 Information Exchange Framework Reference Architecture, Initial Submission

281 Information Exchange Packaging Policy Vocabulary, Initial Submission G-1

282

283 Information Exchange Framework Reference Architecture, Initial Submission G-1