Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
368 Military Communications and Information Technology... 3) Types of claims: Two key classes of claims have been identified concerning entities within the system: • Organizational claims, described as “Custodial Identity” in [8], are issued by the IdP of the entities, and represent their organizational role independent of the applications to be accessed. This includes common attributes such as nationality, clearance, email address, etc. A unique identifier should be also included, for which a common format has to be agreed. NATO unique identifiers will be generated by the NATO Enterprise Directory Service (NEDS), when deployed in the operational environment (mid 2013); • Application specific claims, described as “Contextual Identity” in [8], are issued by the relying party STSs and contain application-specific attributes to support authorization, and have little or no validity outside the scope of the application or service being consumed. These attributes are most likely to be retrieved from local attribute stores, such as directories or databases, and contain data about the roles of the actor in the application. In addition, Context claims describe the environment in which the entity is acting, and may be used as further parameters for evaluating authorization decisions. 4) Modality of claims: When categorizing the requirement to include a claim in a token, modality values are proposed as follows: • Mandatory – only the Unique Identifying Claim should be mandated; • Recommended; • Optional; • Not Recommended; • Forbidden. 5) Unique Identifying Claim: The Unique Identifying Claim should be used to identify the source of an entity as well uniquely identify the entity in all application-specific attribute stores. Therefore this unique identifier will be an organizational, rather than application claim. There is still some debate as to what the format of this attribute should be, though some requirements have been identified: • it will uniquely identify all entities (users, services, devices, etc.); • it will allow the identification of the source domain; • it will be semantically abstracted from the underlying data through the use of a NATO-specific URI. i.e. even though it may be the user’s email address, it will have a URI that identifies it as a unique identifier (ID) rather than email address; • it may be multi-valued, i.e. it may contain more than one attribute value. This will allow the use of other values (then e.g. an e-mail address) like
Chapter 4: Information Assurance & Cyber Defence 369 the NATO Enterprise Identifier (NEDS terminology). Where multiple values are used for the identifying claim, then each value should be verified (at least by the federation broker) to ensure that it has been issued by the correct STS; • it will be a primitive data-type, i.e. a string value. E. Operational security This decision point covers the following areas: • Assertion-Based Authentication and Authorization Assurance – it is imperative that in a classified environment, such as the NATO enterprise, the identity of the subject is cryptographically bound to the message that is being sent. Therefore, when for example consuming or providing web services, it is required that some sort of proof of possession mechanism is used, such as one of the WS-Security Token Profiles; • Secure Communications – the aim of secure communications is to “provide mutual authentication and protect the integrity and confidentiality of communications channels”. In the case of browser-based sessions, it recommends the use of mutual authentication using client certificates over Hypertext Transfer Protocol Secure (HTTPS). However, within a NATO environment, confidentiality is provided at the lower levels of the stack, and the use of HTTPS, while not forbidden, is not preferred, in order to allow real-time monitoring by Intrusion Detection Systems; • Assertion-Level Security – assertions issued by the STS MUST be digitally signed to ensure that they are trusted by the relying parties. Although the confidentiality of the token in the NATO environment is again provided by the lower layers of the stack, Encrypted Assertions MAY be used to further protect the contents of SAML assertions that are distributed by the STS. Therefore, any STS MUST be able to issue both encrypted and unencrypted tokens, and any Policy Enforcement Point (PEP) MUST be able to process both encrypted and unencrypted security tokens; • Audit and Forensics – regardless of the NATO dimension being considered (“NATO as an Enterprise” vs. “NATO as an Alliance”), the NATO applications require tight controls within the domains where they are used. It implies a requirement to use strong detective controls, not just the preventive ones. Currently, NATO is executing the NATO Computer Incident Response Capability (NCIRC) project, aimed to deploy the cyber defence capabilities (including audit and forensic functions) in both NS and NU/ NR environments. In the context of the “NATO as an Enterprise” scenario, the task would be to identify the interfaces and mechanisms through which the federation services can be controlled and secured by the operational security infrastructure provided with the NCIRC project. The situation
- Page 317 and 318: Application of CID Server in Decisi
- Page 319 and 320: Chapter 3: Information Technology f
- Page 321 and 322: Chapter 3: Information Technology f
- Page 323 and 324: Chapter 3: Information Technology f
- Page 325 and 326: Chapter 3: Information Technology f
- Page 327 and 328: Chapter 3: Information Technology f
- Page 329 and 330: Chapter 3: Information Technology f
- Page 331 and 332: Managing Lessons Learnt from Daily
- Page 333 and 334: Chapter 3: Information Technology f
- Page 335 and 336: Chapter 3: Information Technology f
- Page 337 and 338: Chapter 3: Information Technology f
- Page 339 and 340: Chapter 3: Information Technology f
- 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 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 and 392: Chapter 4: Information Assurance &
- Page 393 and 394: 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 &
Chapter 4: <strong>Information</strong> Assurance & Cyber Defence<br />
369<br />
the NATO Enterprise Identifier (NEDS terminology). Where multiple<br />
values are used for the identifying claim, then each value should be verified<br />
(at least by the federation broker) to ensure that it has been issued by<br />
the correct STS;<br />
• it will be a primitive data-type, i.e. a string value.<br />
E. Operational security<br />
This decision point covers the following areas:<br />
• Assertion-Based Authentication <strong>and</strong> Authorization Assurance – it is imperative<br />
that in a classified environment, such as the NATO enterprise,<br />
the identity of the subject is cryptographically bound to the message that<br />
is being sent. Therefore, when for example consuming or providing web<br />
services, it is required that some sort of proof of possession mechanism<br />
is used, such as one of the WS-Security Token Profiles;<br />
• Secure <strong>Communications</strong> – the aim of secure communications is to “provide<br />
mutual authentication <strong>and</strong> protect the integrity <strong>and</strong> confidentiality<br />
of communications channels”. In the case of browser-based sessions, it recommends<br />
the use of mutual authentication using client certificates over<br />
Hypertext Transfer Protocol Secure (HTTPS). However, within a NATO<br />
environment, confidentiality is provided at the lower levels of the stack,<br />
<strong>and</strong> the use of HTTPS, while not forbidden, is not preferred, in order to<br />
allow real-time monitoring by Intrusion Detection Systems;<br />
• Assertion-Level Security – assertions issued by the STS MUST be digitally<br />
signed to ensure that they are trusted by the relying parties. Although<br />
the confidentiality of the token in the NATO environment is again provided<br />
by the lower layers of the stack, Encrypted Assertions MAY be used<br />
to further protect the contents of SAML assertions that are distributed by<br />
the STS. Therefore, any STS MUST be able to issue both encrypted <strong>and</strong><br />
unencrypted tokens, <strong>and</strong> any Policy Enforcement Point (PEP) MUST be<br />
able to process both encrypted <strong>and</strong> unencrypted security tokens;<br />
• Audit <strong>and</strong> Forensics – regardless of the NATO dimension being considered<br />
(“NATO as an Enterprise” vs. “NATO as an Alliance”), the NATO applications<br />
require tight controls within the domains where they are used.<br />
It implies a requirement to use strong detective controls, not just the preventive<br />
ones. Currently, NATO is executing the NATO Computer Incident<br />
Response Capability (NCIRC) project, aimed to deploy the cyber defence<br />
capabilities (including audit <strong>and</strong> forensic functions) in both NS <strong>and</strong> NU/<br />
NR environments. In the context of the “NATO as an Enterprise” scenario,<br />
the task would be to identify the interfaces <strong>and</strong> mechanisms through which<br />
the federation services can be controlled <strong>and</strong> secured by the operational<br />
security infrastructure provided with the NCIRC project. The situation