Military Communications and Information Technology: A Trusted ...

Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...

22.01.2015 Views

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

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!