Information Exchange Framework Reference Architecture

(1)

Date:

November 2014

Information Exchange Framework Reference

Architecture

Initial Submission

__________________________________________________

OMG Document Number: MARS/2014-11-01

Standard document URL:

Normative Machine Consumable File(s):

TBD

http://www.omg.org/spec/IEF/IEF-RA/

_________________________________________________

This OMG document replaces the submission document (mars/2013-12-05, 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

[email protected]

by June 20, 2014.

You may view the pending issues for this specification from the OMG revision issues web page

http://www.omg.org/issues/

.

The FTF Recommendation and Report for this specification will be published on September 26, 2014. If

you are reading this after that date, please download the available specification from the OMG

(2)

ii

Information Exchange Packaging Policy Vocabulary, Initial Submission

Copyright © 2003-2013, Advanced Systems Management (ASMG) Group Ltd.

Copyright © 2003-2013, Thematix Partners LLC

Copyright © 2003-2013, 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,

royalty-free, 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,

(3)

iii

electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval

systems--without permission of the copyright owner.

Copyright © 2003 - 2013, Advanced Systems Management (ASMG) Group Ltd.

Copyright © 2003 - 2014, Object Management Group, Inc.

Copyright © 2003-2013, 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,

royalty-free, 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.

(4)

iv

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 252.227-7013 or in

subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R.

52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48

C.F.R. 12.212 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™ ,

(5)

v

Unified Modeling Language™, Model Driven Architecture Logo™, Model Driven Architecture Diagram™,

CORBA logos™, XMI Logo™, CWM™, CWM Logo™, IIOP™ , MOF™ , OMG Interface Definition 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

(6)

vi

Table Contents

TABLE CONTENTS

VI

LIST OF FIGURES

X

LIST OF TABLES

XII

PREFACE

XVIII

A

BOUT THE

O

BJECT

M

ANAGEMENT

G

ROUP XVIII

PART I

1

1 INFORMATION EXCHANGE FRAMEWORK REFERENCE ARCHITECTURE

2

1.1 S

COPE

2

1.2 O

RGANIZATION OF THIS

S

PECIFICATION

3

1.3 M

OTIVATION

3

1.4 IEF

A

PPROACH

5

1.5 IEF

D

ELIVERED

C

APABILITIES

6

1.6 IEF

O

BJECTIVES

7

1.7 IEF

RA

D

ESIGN

P

RINCIPLES

8

2 COMPLIANCE

10

2.1 I

NTRODUCTION

10

2.2 S

ELECTING A

C

OMPLIANCE

P

OINT

10

2.3 C

OMPLIANCE

P

OINTS

10

2.3.1 File Sharing

10

2.3.2 Email

10

2.3.3 Instant Messaging

10

2.3.4 Messaging Middleware

10

2.3.5 Web Services

10

3 NORMATIVE REFERENCES

11

4 TERMS AND DEFINITIONS

12

5 SYMBOLS/ACRONYMS

13

5.1 S

YMBOLS

13

6 ADDITIONAL INFORMATION

14

6.1 I

NTENDED

A

UDIENCE

14

6.2 A

CKNOWLEDGEMENTS

14

6.3 A

DDITIONAL

M

ATERIALS

14

(7)

vii

6.4 R

EFERENCE

A

RCHITECTURE

14

6.4.1 Introduction to IEF RA

14

6.4.2 Philosophy

14

6.5 M

ODELING

C

ONVENTIONS

15

7 IEF REFERENCE ARCHITECTURE

16

7.1 IEF

O

VERVIEW

16

8 EXTERNAL ACTORS

19

9 POLICY ADMINISTRATION POINT

30

9.1 PAP

IN AN

I

NTER

-A

GENCY

E

NVIRONMENT

30

9.2 PAP

D

ESCRIPTION

30

9.2.1 PAP Use Case Diagrams

30

9.2.2 PAP Class Diagrams

36

9.2.3 Sequence Diagrams

43

10 POLICY DECISION POINT

44

10.1 U

SE

C

ASES

44

10.1.1 Authorize Action Use Case Diagram

44

10.1.2 Email PDP Use Case Diagram

47

10.1.3 File PDP Use Case Diagram

49

10.1.4 IM PDP Use Case Diagram

51

10.1.5 Receiver Directed Messaging PDP Use Case Diagram

53

10.1.6 Session Directed Messaging PDP Use Case Diagram

54

10.2 C

LASS

D

IAGRAMS

55

10.2.1 Policy Decision Point Class Diagram

55

10.3 S

EQUENCE

D

IAGRAMS

58

10.3.1 Policy Decision Point Sequence Diagram

58

11 POLICY ENFORCEMENT POINTS

61

11.1 PEP

O

VERVIEW

61

11.1.1 PEP Components Class Diagram

61

11.1.2 PEP Specialization Class Diagram

65

11.2 E

MAIL

PEP

69

11.2.1 Email PEP Use Cases

70

11.2.2 Email PEP Class Diagrams

76

(8)

viii

11.3 F

ILE

S

HARING

PEP

93

11.3.1 File Share Use Cases

94

11.3.2 File PEP Class Diagrams

111

11.3.3 File PEP Sequence Diagrams

118

11.4 I

NSTANT

M

ESSAGING

PEP

137

11.4.1 Instant Messaging Use Cases

137

11.4.2 Instant Messaging Class Diagrams

143

11.4.3 IM PEP Class Diagram

144

11.4.4 Sequence Diagrams

149

11.5 S

ESSION

D

IRECTED

M

ESSAGING

PEP

163

11.5.1 Session Directed Messaging Use Cases

163

11.5.2 Class Diagrams

167

11.5.3 Session Directed Messaging PEP Class Diagram

167

11.5.4 Sequence Diagrams

168

11.6 R

ECEIVER

D

IRECTED

M

ESSAGING

PEP

169

12 DATA PACKAGING AND PROCESSING SERVICES

178

12.1 O

PTIONAL

R

EQUIREMENTS

179

12.2 M

ESSAGE

P

ACKAGING AND

P

ROCESSING

S

ERVICE

U

SE

C

ASE

D

IAGRAMS

179

12.2.1 Package Structured Message Use Case Diagram

179

12.2.2 Assemble Information Package Use Case Diagram

181

12.2.3 Assemble Releasable Data Set Use Case Diagram

183

12.2.4 Process Structured Information Element Use Case Diagram

186

12.2.5 Package Structured Message Use Case Diagram

188

12.3 C

LASS

D

IAGRAMS

190

12.4 S

EQUENCE

D

IAGRAMS

203

13 COMMON SERVICES

204

13.1 U

SE

C

ASES

204

13.1.1 Authorize User Use Case Diagram

204

13.1.2 Encrypt Information Element Use Case Diagram

208

13.1.3 Decrypt Information Element Use Case Diagram

211

13.2 C

LASS

D

IAGRAMS

212

13.2.1 Authorization Class Diagram

213

(9)

ix

13.2.3 Identity Management Class Diagram

224

13.2.4 Logging Class Diagram

227

13.2.5 Marking Class Diagram

233

13.2.6 Secure Asset Container Class Diagram

238

13.3 S

EQUENCE

D

IAGRAMS

239

14 POLICY VOCABULARIES

240 ANNEX F: BIBLIOGRAPHY (INFORMATIONAL)

1 ANNEX G – TERMS AND ACRONYMS (INFORMATIONAL)

1 G

ENERAL

T

ERMS AND

D

EFINITIONS

1 A

CRONYMS

9 ANNEX H – CONFORMANCE WITH RFP

1 Mandatory Requirements

1

(10)

x

List of Figures

Figure 1 -Concept Use Case Diagram ... 16

Figure 2 -Administer Policy Environment Use Case Diagram... 31

Figure 3 -Policy Administration Use Case Diagram ... 33

Figure 4 -Policy Management Use Case Diagram ... 35

Figure 5 -Authorize Action Use Case Diagram ... 45

Figure 6 -PDP Administration Use Case Diagram ... 46

Figure 7 -Email PDP Use Case Diagram ... 48

Figure 8 -File PDP Use Case Diagram ... 50

Figure 9 -IM PDP Use Case Diagram ... 51

Figure 10 -Receiver Directed Messaging PDP Use Case Diagram ... 53

Figure 11 -Session Directed Messaging PDP Use Case Diagram ... 54

Figure 12 -Send Email Use Case Diagram ... 71

Figure 13 -Receive Email Use Case Diagram ... 75

Figure 14 -Access File Share Use Case Diagram ... 94

Figure 15 -Manage Protected File Use Case Diagram ... 96

Figure 16 -Copy File Use Case Diagram ... 98

Figure 17 -Create File Use Case Diagram ... 100

Figure 18 -Cut File Use Case Diagram ... 101

Figure 19 -Delete File Use Case Diagram ... 102

Figure 20 -List Files Use Case Diagram ... 103

Figure 21 -Move File Use Case Diagram ... 104

Figure 22 -Open File Use Case Diagram ... 106

Figure 23 -Paste File Use Case Diagram ... 108

Figure 24 -Rename File Use Case Diagram ... 108

Figure 25 -Save File Use Case Diagram ... 110

Figure 26 -List and Join Chat Use Case Diagram ... 138

Figure 27 -Receive IM Use Case Diagram ... 140

(11)

xi

Figure 29 -Send Session Directed Message Use Case Diagram ... 164

Figure 30 -Receive Message Use Case Diagram ... 166

Figure 31 -Send Session Directed Message Use Case Diagram ... 170

Figure 32 -Receive Email Use Case Diagram ... 172

Figure 33 -Package Structured Message Use Case Diagram ... 180

Figure 34 -Assemble Information Package Use Case Diagram ... 182

Figure 35 -Assemble Releasable Data Set Use Case Diagram ... 184

Figure 36 -Process Structured Information Element Use Case Diagram ... 186

Figure 37 -Package Structured Message Use Case Diagram ... 189

Figure 38 -Authorize User Use Case Diagram ... 204

Figure 39 -Bind Markings to Information Element Use Case Diagram ... 206

Figure 40 -Encrypt Information Element Use Case Diagram... 209

(12)

xii

List of Tables

Table 1 - Concept Use Case Diagram Descriptions ... 17

Table 2 – External Actors ... 19

Table 3 - Administer Policy Environment Use Case Diagram Descriptions ... 31

Table 4 - Policy Administration Use Case Diagram Descriptions ... 33

Table 5 - Policy Management Use Case Diagram Descriptions ... 35

Table 6 – Policy Administration Point Class Diagram Descriptions... 37

Table 7 – Policy Administration Point Class Diagram - Interface Descriptions ... 38

Table 8 – Policy Administration Point Class Diagram - Association Descriptions ... 39

Table 9 – Identity Attribute Administration Point Class Diagram Descriptions ... 40

Table 10 – Identity Attribute Administration Point Class Diagram - Interface Descriptions ... 41

Table 11 – Identity Attribute Administration Point Class Diagram - Association Descriptions ... 42

Table 12 - Policy Administration Point Sequence Diagram - Message Descriptions ... 43

Table 13 - Authorize Action Use Case Diagram Descriptions ... 45

Table 14 - PDP Administration Use Case Diagram Descriptions ... 46

Table 15 - Email PDP Use Case Diagram Descriptions ... 48

Table 16 - File PDP Use Case Diagram Descriptions ... 50

Table 17 - IM PDP Use Case Diagram Descriptions ... 52

Table 18 - Receiver Directed Messaging PDP Use Case Diagram Descriptions ... 53

Table 19 - Session Directed Messaging PDP Use Case Diagram Descriptions ... 54

Table 20 – Policy Decision Point Class Diagram Descriptions... 56

Table 21 – Policy Decision Point Class Diagram - Interface Descriptions ... 57

Table 22 – Policy Decision Point Class Diagram - Association Descriptions ... 58

Table 23 - Policy Decision Point Sequence Diagram - Message Descriptions ... 59

Table 24 – PEP Components Class Diagram Descriptions ... 62

Table 25 – PEP Components Class Diagram - Interface Descriptions ... 64

Table 26 – PEP Components Class Diagram - Association Descriptions ... 64

Table 27 – PEP Specialization Class Diagram Descriptions ... 66

(13)

xiii

Table 29 – PEP Specialization Class Diagram - Association Descriptions ... 69

Table 30 - Send Email Use Case Diagram Descriptions ... 71

Table 31 - Receive Email Use Case Diagram Descriptions ... 75

Table 32 – Email PEP Class Diagram Descriptions ... 77

Table 33 – Email PEP Class Diagram - Interface Descriptions ... 82

Table 34 – Email PEP Class Diagram - Association Descriptions ... 83

Table 35 - Send Email Sequence Diagram - Message Descriptions... 85

Table 36 - Receive Email Sequence Diagram - Message Descriptions ... 89

Table 37 - Access File Share Use Case Diagram Descriptions ... 94

Table 38 - Manage Protected File Use Case Diagram Descriptions ... 96

Table 39 - Copy File Use Case Diagram Descriptions ... 98

Table 40 - Create File Use Case Diagram Descriptions ... 100

Table 41 - Cut File Use Case Diagram Descriptions ... 102

Table 42 - Delete File Use Case Diagram Descriptions ... 103

Table 43 - List Files Use Case Diagram Descriptions ... 104

Table 44 - Move File Use Case Diagram Descriptions ... 105

Table 45 - Open File Use Case Diagram Descriptions ... 106

Table 46 - Paste File Use Case Diagram Descriptions ... 108

Table 47 - Rename File Use Case Diagram Descriptions ... 109

Table 48 - Save File Use Case Diagram Descriptions ... 110

Table 49 – File PEP Class Diagram Descriptions ... 112

Table 50 – File PEP Class Diagram - Interface Descriptions ... 116

Table 51 – File PEP Class Diagram - Association Descriptions ... 117

Table 52 - Copy File Sequence Diagram - Message Descriptions ... 119

Table 53 - Create File Sequence Diagram - Message Descriptions ... 121

Table 54 - Cut File Sequence Diagram - Message Descriptions ... 122

Table 55 - Delete File Sequence Diagram - Message Descriptions ... 124

Table 56 - List Files Sequence Diagram - Message Descriptions ... 125

Table 57 - Move File Sequence Diagram - Message Descriptions... 127

(14)

xiv

Table 59 - Paste File Sequence Diagram - Message Descriptions ... 130

Table 60 - Retrieve File Sequence Diagram - Message Descriptions ... 131

Table 61 - Save File Sequence Diagram - Message Descriptions ... 134

Table 62 - List and Join Chat Use Case Diagram Descriptions... 138

Table 63 - Receive IM Use Case Diagram Descriptions ... 140

Table 64 - Send IM Use Case Diagram Descriptions ... 142

Table 65 – IM PEP Class Diagram Descriptions ... 144

Table 66 – IM PEP Class Diagram - Interface Descriptions ... 148

Table 67 – IM PEP Class Diagram - Association Descriptions ... 148

Table 68 - List Chat Rooms Sequence Diagram - Message Descriptions ... 150

Table 69 - Join Chat Room Sequence Diagram - Message Descriptions ... 152

Table 70 - Send IM Sequence Diagram - Message Descriptions ... 155

Table 71 - Send Special Message Sequence Diagram - Message Descriptions ... 156

Table 72 - Receive IM Sequence Diagram - Message Descriptions ... 160

Table 73 - Receive Special Message Sequence Diagram - Message Descriptions ... 161

Table 74 - Send Session Directed Message Use Case Diagram Descriptions ... 164

Table 75 - Receive Message Use Case Diagram Descriptions ... 166

Table 76 – Session Directed Messaging PEP Class Diagram Descriptions ... 168

Table 77 – Session Directed Messaging PEP Class Diagram - Interface Descriptions ... 168

Table 78 – Session Directed Messaging PEP Class Diagram - Association Descriptions ... 168

Table 79 - Send Message To Session Sequence Diagram - Message Descriptions ... 169

Table 80 - Receive Message Sequence Diagram - Message Descriptions ... 169

Table 81 - Send Session Directed Message Use Case Diagram Descriptions ... 170

Table 82 - Receive Email Use Case Diagram Descriptions ... 172

Table 83 – Receiver Directed Messaging PEP Class Diagram Descriptions ... 174

Table 84 – Receiver Directed Messaging PEP Class Diagram - Interface Descriptions ... 174

Table 85 – Receiver Directed Messaging PEP Class Diagram - Association Descriptions ... 175

Table 86 - Send Receiver Directed Messaging Sequence Diagram - Message Descriptions ... 176

Table 87 - Receive Message Sequence Diagram - Message Descriptions ... 177

(15)

xv

Table 89 - Assemble Information Package Use Case Diagram Descriptions ... 182

Table 90 - Assemble Releasable Data Set Use Case Diagram Descriptions ... 184

Table 91 - Process Structured Information Element Use Case Diagram Descriptions ... 186

Table 92 - Package Structured Message Use Case Diagram Descriptions ... 189

Table 93 – Data Assembly Service Class Diagram Descriptions ... 191

Table 94 – Data Assembly Service Class Diagram - Interface Descriptions ... 192

Table 95 – Data Assembly Service Class Diagram - Association Descriptions ... 196

Table 96 – Data Packaging Service Class Diagram Descriptions ... 198

Table 97 – Data Packaging Service Class Diagram - Interface Descriptions ... 199

Table 98 – Data Packaging Service Class Diagram - Association Descriptions ... 202

Table 99 - Authorize User Use Case Diagram Descriptions ... 204

Table 100 - Bind Markings to Information Element Use Case Diagram Descriptions ... 207

Table 101 - Encrypt Information Element Use Case Diagram Descriptions ... 209

Table 102 - Decrypt Information Element Use Case Diagram Descriptions ... 212

Table 103 – Authorization Class Diagram Descriptions ... 213

Table 104 – Authorization Class Diagram - Interface Descriptions ... 215

Table 105 – Authorization Class Diagram - Association Descriptions ... 217

Table 106 – Cryptography Class Diagram Descriptions ... 218

Table 107 – Cryptography Class Diagram - Interface Descriptions ... 220

Table 108 – Cryptography Class Diagram - Association Descriptions ... 223

Table 109 – Identity Management Class Diagram Descriptions ... 225

Table 110 – Identity Management Class Diagram - Interface Descriptions ... 226

Table 111 – Identity Management Class Diagram - Association Descriptions ... 227

Table 112 – Logging Class Diagram Descriptions ... 228

Table 113 – Logging Class Diagram - Interface Descriptions ... 231

Table 114 – Logging Class Diagram - Association Descriptions ... 232

Table 115 – Marking Class Diagram Descriptions ... 234

Table 116 – Marking Class Diagram - Interface Descriptions ... 236

(16)

xvi

(17)

(18)

xviii

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 http://www.omg.org/.

OMG Specifications

As noted, OMG specifications address middleware, modeling and vertical domain frameworks. All OMG Specifications are available from the OMG website at:

http://www.omg.org/spec

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

(19)

xix

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 02494 USA

Tel: +1-781-444-0404

Fax: +1-781-444-0320

Email:

[email protected]

Certain OMG specifications are also available as ISO standards. Please consult

http://www.iso.org

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 Definition 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

(20)

(21)

Information Exchange Framework Reference Architecture, Initial Submission

1 Part I

(22)

2

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.

(23)

3

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 Definitions

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



Clause 13: User Services



Annex A:



Annex C:



Annex D:



Annex E:



Annex F:



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

(24)

4 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

self-contained 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,

http://dl.acm.org/citation.cfm?doid=507711.507726

(25)

5 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 2011. 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.

3_{http://www.computerworld.com/s/article/9242493/Snowden_s_role_provided_perfect_cover_for_NSA_data_theft}

(26)

6

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.

(27)

7

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

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

Data-centric

IEF policy decision and enforcement points operate on the data for

each instance of the information and data elements being assessed

for release.

Achieve Dynamic

Interoperability

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.

Flexibility, Adaptability,

and Agility

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.

Architecture Alignment

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.

Integration Overlay

Operate as an overlay to existing systems and infrastructure.

Defense-in-Depth

Integrate elements manner that to safeguard individual data and

information assets based on their sensitivities.

Self-Defending

Employ internal elements to safeguard its own data and

information elements (e.g., policies, instructions and logs).

Vendor Agnostic

Define specification that vendors can use to developed

off-the-shelf integration layers of complete ISS solutions.

Reuse of Existing

Standards and Specifications

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

(28)

8 dissemination) and interfaces (e.g., XAMCL for exchange of

policies).

1.7 IEF RA Design Principles

The Key principles of the IEF and its support Environment.

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

machine-readable rules.

• Provide users with the data needed for:

o

Governance;

o

Modeling and simulation;

o

Auditing (e.g., security and privacy):



Design,



Real-time Monitoring, and



Forensic;

o

Retention of Institutional Memory; and

o

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.

(29)

9

• 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

(30)

10

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 (E-mail);

c)

Instant Messaging (IM);

d)

Messaging Middleware; and

e)

Web Services.

2.3.1 File Sharing

2.3.2 Email

2.3.3 Instant Messaging

2.3.4 Messaging Middleware

2.3.5 Web Services

(31)

11

3 Normative References

XACML

(32)

12

4 Terms and Definitions

The focus of this specification is the development of a formal …

.

(33)

13

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.

(34)

14

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

5. .

6.3 Additional Materials

N/A

6.4 Reference Architecture

6.4.1 Introduction to IEF RA

6.4.2 Philosophy

The IEF RS …

(35)

15

6.5 Modeling Conventions

(36)

16

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.

(37)

17 Table 1 - Concept Use Case Diagram Descriptions

Name

Definition

Redact Content 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.

Log Transaction An IEF solution will log all IEF transactions and record each record in a

tamper-resistant 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 short-term security incident and event monitoring and long-short-term forensic auditing.

Enforce Information Sharing Policy

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. Receive Releasable

Information

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

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).

Mark Information Element 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