Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
392 Military Communications and Information Technology... Within the CIPE Service each individual Content Filter is explicitly identifiable by its type. A Content Filter may be of an Identification, Verification or Transformation type, or any combination of the three: 1. Identification Content Filter is responsible for correct identification of the type(s) of a data object. 2. Verification Content Filter is responsible for enforcing that the data object conforms to the claimed type and that no malicious or confidential content is present in the data object. This Content Filter also performs as a content exploder and a content flattener for data objects which contain embedded data object(s). 3. Transformation Content Filter is responsible for mitigating the potential threat of malicious content by either removing the active content that was found by the Verification Filter, or by transforming the content to another format. This Content Filter can also transform content by obfuscating or removing data attributes or values that should not be released across the information system boundary. The types of data formats that are allowed for import or release across the HAAG are specific to a CIPE Profile. Each data format type has its own set of Content Filter Rules. A set of Content Filter Rules represents a subset of the CIPE Profile security and assurance requirements specified for a given data format type. The Content Filter Rules are asserted by the Content Filter(s). E. Trusted Base Platform Trusted Base Platform consists of the operating system (OS) kernel, the tools and applications, which are part of the OS, and the hardware, on which the OS runs. Security requirements related to user roles and user authentication are implemented in the OS. The base OS and hardware also provide the isolation of the security components from other components of the HAAG. VI. Conclusions and future work The development of the high level design and the protection profile for the HAAG is the first step on a path to achieve effective information sharing between NATO and its external partners. One of the important aspects of the future work is the development of a formal model for the CPR security policies. We are aiming at specifying a basic CPR policy in a natural language, translating it into a formal representation and validating it using some well-known tools, such as Isabelle [21]. The recently established the NATO Science and Technology Organization (STO) Information Systems Technology (IST) Task Group on Trusted Information Sharing for Partnerships (IST-114) aims at advancing the IEG Scenario D
Chapter 4: Information Assurance & Cyber Defence 393 and the Object Level Protection concepts. The focus of the group includes high assurance guards, as well as extensions to the existing security labelling specifications. The results of IST-114 can potentially influence the requirements and design of the HAAG. Acknowledgment This research has been sponsored by the NATO Allied Command Transformation Scientific Programme of Work 2011/2012. References [1] K. Wrona, S. Oudkerk, and G. Hallingstad, “Designing medium assurance XML-labelling guards for NATO,” in Proceedings of the Military Communications Conference (MILCOM), San Jose, CA, USA, 2010. [2] K. Wrona and G. Hallingstad, “Controlled Information Sharing in NATO Operations,” in Proceedings of the IEEE Military Communications Conference (MILCOM), Baltimore, 2011. [3] R. Danyliw, J. Meijer, and Y. Demchenko, “The Incident Object Description Exchange Format,” Request for Comments RFC 5070, 2007. [4] J. Baker, M. Hansbury, and D. Haynes, “The OVAL Language Specification Version 5.10.1,” The MITRE Corporation, 2012. [5] L. Ward, “Improving your custom Snort rules,” Sourcefire, 2010. [6] S. Oudkerk, “NATO Profile for the ‘Binding of Metadata to Data Objects’ – version 1.0,” The Hague, Technical Note TN-1455, 2011. [7] S. Oudkerk, “NATO Profile for the ‘XML Confidentiality Label Syntax’ – version 1.0,” The Hague, Technical Note TN-1456, 2011. [8] T. Wilson, “OGC KML Version 2.2.0,” Open Geospatial Consortium Inc., OGC Standard OGC 07-147r2, 2008. [9] Common Criteria, “Common Criteria for Information Technology Security Evaluation Version 3.1 Revision 3,” CCMB-2009-07-001, 2009. [10] IAD, “U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness, Version 1.03,” 2007. [11] D. Baier et al., A Guide to Claims-Based Identity and Access Control – Authentication and Authorization for Services and the Web.: Microsoft Corporation, 2010. [12] Nigel P. Smart and Frederik Vercauteren, “Fully Homomorphic Encryption with Relatively Small Key and Ciphertext Sizes,” in Public Key Cryptography, 2010, pp. 420-443. [13] M. Abdalla et al., “Wildcarded Identity-Based Encryption,” Journal of Cryptology, vol. 24, no. 1, pp. 42-82, 2011. [14] NC3B, “NATO Architecture Framework v3,” Brussels, Belgium, ANNEX 1 TO AC/322-D(2007)0048, 2007.
- Page 341 and 342: Chapter 3: Information Technology f
- Page 343: Chapter 3: Information Technology f
- Page 347 and 348: Federated Cyber Defence System - Ap
- Page 349 and 350: Chapter 4: Information Assurance &
- Page 351 and 352: Chapter 4: Information Assurance &
- Page 353 and 354: Chapter 4: Information Assurance &
- Page 355 and 356: Chapter 4: Information Assurance &
- Page 357: Chapter 4: Information Assurance &
- Page 360 and 361: 360 Military Communications and Inf
- Page 362 and 363: 362 Military Communications and Inf
- Page 364 and 365: 364 Military Communications and Inf
- Page 366 and 367: 366 Military Communications and Inf
- Page 368 and 369: 368 Military Communications and Inf
- Page 370 and 371: 370 Military Communications and Inf
- Page 372 and 373: 372 Military Communications and Inf
- Page 374 and 375: 374 Military Communications and Inf
- Page 377 and 378: Development of High Assurance Guard
- Page 379 and 380: Chapter 4: Information Assurance &
- Page 381 and 382: Chapter 4: Information Assurance &
- Page 383 and 384: Chapter 4: Information Assurance &
- Page 385 and 386: Chapter 4: Information Assurance &
- Page 387 and 388: Chapter 4: Information Assurance &
- Page 389 and 390: Chapter 4: Information Assurance &
- Page 391: Chapter 4: Information Assurance &
- Page 395 and 396: Network Traffic Characteristics for
- Page 397 and 398: Chapter 4: Information Assurance &
- Page 399 and 400: Chapter 4: Information Assurance &
- Page 401 and 402: Chapter 4: Information Assurance &
- Page 403 and 404: Chapter 4: Information Assurance &
- Page 405 and 406: Chapter 4: Information Assurance &
- Page 407 and 408: Chapter 4: Information Assurance &
- Page 409 and 410: Chapter 4: Information Assurance &
- Page 411 and 412: Chapter 4: Information Assurance &
- Page 413 and 414: Chapter 4: Information Assurance &
- Page 415 and 416: Methodology for Gathering Data Conc
- Page 417 and 418: Chapter 4: Information Assurance &
- Page 419 and 420: Chapter 4: Information Assurance &
- Page 421 and 422: Chapter 4: Information Assurance &
- Page 423 and 424: Chapter 4: Information Assurance &
- Page 425 and 426: Chapter 4: Information Assurance &
- Page 427 and 428: Chapter 4: Information Assurance &
- Page 429: Chapter 4: Information Assurance &
- Page 432 and 433: 432 Military Communications and Inf
- Page 434 and 435: 434 Military Communications and Inf
- Page 436 and 437: 436 Military Communications and Inf
- Page 439 and 440: On Multi-Level Secure Structured Co
- Page 441 and 442: Chapter 4: Information Assurance &
392 <strong>Military</strong> <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong>...<br />
Within the CIPE Service each individual Content Filter is explicitly identifiable<br />
by its type. A Content Filter may be of an Identification, Verification or Transformation<br />
type, or any combination of the three:<br />
1. Identification Content Filter is responsible for correct identification<br />
of the type(s) of a data object.<br />
2. Verification Content Filter is responsible for enforcing that the data object<br />
conforms to the claimed type <strong>and</strong> that no malicious or confidential content<br />
is present in the data object. This Content Filter also performs as a content<br />
exploder <strong>and</strong> a content flattener for data objects which contain embedded<br />
data object(s).<br />
3. Transformation Content Filter is responsible for mitigating the potential<br />
threat of malicious content by either removing the active content that<br />
was found by the Verification Filter, or by transforming the content to another<br />
format. This Content Filter can also transform content by obfuscating<br />
or removing data attributes or values that should not be released across<br />
the information system boundary.<br />
The types of data formats that are allowed for import or release across the HAAG<br />
are specific to a CIPE Profile. Each data format type has its own set of Content Filter<br />
Rules. A set of Content Filter Rules represents a subset of the CIPE Profile security<br />
<strong>and</strong> assurance requirements specified for a given data format type. The Content<br />
Filter Rules are asserted by the Content Filter(s).<br />
E. <strong>Trusted</strong> Base Platform<br />
<strong>Trusted</strong> Base Platform consists of the operating system (OS) kernel, the tools<br />
<strong>and</strong> applications, which are part of the OS, <strong>and</strong> the hardware, on which the OS runs.<br />
Security requirements related to user roles <strong>and</strong> user authentication are implemented<br />
in the OS. The base OS <strong>and</strong> hardware also provide the isolation of the security<br />
components from other components of the HAAG.<br />
VI. Conclusions <strong>and</strong> future work<br />
The development of the high level design <strong>and</strong> the protection profile for<br />
the HAAG is the first step on a path to achieve effective information sharing between<br />
NATO <strong>and</strong> its external partners.<br />
One of the important aspects of the future work is the development of a formal<br />
model for the CPR security policies. We are aiming at specifying a basic CPR policy<br />
in a natural language, translating it into a formal representation <strong>and</strong> validating<br />
it using some well-known tools, such as Isabelle [21].<br />
The recently established the NATO Science <strong>and</strong> <strong>Technology</strong> Organization<br />
(STO) <strong>Information</strong> Systems <strong>Technology</strong> (IST) Task Group on <strong>Trusted</strong> <strong>Information</strong><br />
Sharing for Partnerships (IST-114) aims at advancing the IEG Scenario D
Change language