Home | Sitemap | ABC | Contact

1.4. Interoperability Scoping Principles

32. This section defines the scoping principles that should be applied to the services required to support interoperability between NCF systems, the NII and national NII. These principles must be applied in addition to the general principles defined in Section 1.3.

1.4.1. System and Infrastructure Boundary Issues

33. As far as possible, conformance with NISP standards should be confined to requirements to provide specified services at the interface between systems or network infrastructures.

34. For interoperability purposes, the NISP should be confined to specifying those characteristics of systems that are necessary to achieve NCF system interoperability and NCF to coalition nation NII interoperability. It will often be sufficient that systems or networking infrastructures comply with a standard at their external boundaries; interoperability does not necessarily demand that services conforming to the same standards be used internally. Conformance to a standard at the boundary will, however, often mean that certain requirements do need to be satisfied internally. For example, the NISP might demand that a certain external schema is used when relational DBMS information is exchanged; the schema used internally need not be identical to this but it must clearly be rich enough that data can be accurately translated between internal and external formats.

35. Systems should be capable of meeting NISP external interface standards, but this should not preclude the agreement of additional interfaces between two or more systems if these satisfy local[3] requirements more effectively.

36. Any system offering a service within the scope of the NISP is obliged to offer external interfaces conformant with the NISP standard. This allows any other system to interoperate readily if it also offers a compliant interface. However, there will remain circumstances where additional, agreed interfaces may be more effective in meeting specific local interoperability requirements, either in terms of performance or cost-effectiveness. In these cases, the NISP should not force projects to adopt a sub-optimal solution where it can be shown that alternative arrangements are more effective. (It is reiterated, however, that every system within the scope of the NISP must always offer NISP conformant interfaces, in addition to any other interfaces.

1.4.2. Interconnection Security Policy

37. The NISP must embody a practical security policy compatible with the goals of widespread interconnection between systems and NII.

38. Current NATO and Coalition partner security policy guidance regarding the interconnection of secure systems or NII is still being formulated by the NATO Security Committee (NSC). Until an agreed policy emerges it will be impossible to decide the level of security functionality and assurance that will be necessary to support the envisaged level of internetworking between NATO and Coalition partner systems or NII.

39. A more fundamental difficulty exists, namely that interconnections between systems inevitably weaken security. Irrespective of security technology developments, a widely interconnected system will always provide opportunities for attack that are absent in a standalone system. Also, greater potential damage can be caused in an interconnected system by a security breach regardless of whether it was an unintentional mistake or the result of deliberate attack. A viable security policy within the NISP will be unachievable unless the NATO and Coalition partners can strike a realistic balance between the level of security provided (and thus risk accepted) and the extent of interconnection sought.

1.4.3. System Evolution

40. The NISP must accept and provide for a range of standards and technologies to permit interoperability between systems or NII of different technological vintages.

41. Although the NISP will need to evolve in response to technological developments, the pace of evolution of systems or NII will to a large degree depend upon factors outside NISP control (e.g. funding and operational constraints). This means that the NISP must support a range of compatible technologies to support continued interoperability between systems or NII of different NISP vintages: older technologies or standards versions will need to be supported to allow a realistic period for migration. Conversely, the introduction of new technologies or standards within the NISP must not be delayed too long since this could inhibit end-systems' or NII uptake of those technologies. A balance must therefore be struck between the desire to embrace new technological developments within the NISP and the practical ability of existing systems or NII to evolve to maintain conformance with it.



[3] In this context 'local' can mean between two CIS or NII from a single nation, internal to NATO or between CIS or NII of different nations.

Copyright © NATO - OTAN 1998-2010 | Disclaimer