Chapter 2. Assessment of Scope of NISP

< Prev		Next >

Chapter 2. Assessment of Scope of NISP

2.1. Introduction

2.1. Introduction

54. The application of the principles outlined in Chapter 1 has resulted in the assessments captured in the next tables (Table 2.1 to Table 2.4).

Area/ class	Standardization Requirement	Openness	Legacy	Procurement Cost/ risk
1: User Interface Services
Graphical User Interafce	These services are not necessary for system to system interoperability but do provide benefits to NCF Systems e.g. people portability.training	Standards exist to proliferate User Interface services (e.g. Character-Orientated, Graphical User Interafaces, as well as dedicated) within multiple functional domain areas.	Support is required based on the version of Windows/X Windows utilized.
Look & Feel	As above	As above	As above	The type of COTS available may be limited in scope or not all-inclusive (e.g. style guides). As a result Military should refer and conform to their respective Defence documents accordingly. Associated costs will differ based on resource applicability.
Toolkit	As above	Toolkits exist to support standards	As above
2: Data Management
Dictionary/ Directory (Data Dictionary)	Specific to individual nations, i.e. no Coaltion Interoperability requirement. However, NATO needs to identify, develop definitions, and store common data elements for NCF systems, in the NC3 IRDS.
Database management systems (Relational and Object-Orientated)	Specific to individual nations i.e. no Coalition Interoperability requirement. Required for NCF systems.
Distributed Data
Remote Data Access	There is a Coalition Interoperability requirement for remote data access (e.g. between server/server environments).	SQL CLI only open standard. ODBC is the Microsoft variant. SQL*NET (ORACLE) regarded as dominant product. Web-based access protocols are widely used across the Internet; these offer limited database functionality. SOAP and XML related protocols could serve this purpose.	No significant impact.	No significant impact.
Database Replication	There is a requirement to support database replication by "push" only. There are some aspirations to use database replication as a mechanism to satisfy Coalition interoperability requirements although the extent of the requirement is not finalised. Replication may be employed within individual systems to meet survivability and performance requirements - this does not justify inclusion of this service within the NCSP at this time, but will need to be effectively addressed in the near future (e.g. ATCCIS, CCEB CWAN.)	There are only a few acceptably open standards for replication protocols: this is the prime hindrance to standardization. See note A.3	Many legacy systems employ flat-file databases which do not support efficient replication protocols.	Adoption of a single database product NATO-wide will not be acceptable on procurement grounds.
NATO Common Schema See Note A.2	Interoperability requires common syntactic and semantic understanding of data. This necessitates standardization of data definitions and schema. However, from a NCSP perspective: only data exchanged between systems needs to be standardized; only data common to all or most nations needs to be standardized in the NCSP. Both categories are under development by the NATO Data Administration Group (NDAG).	Metadata standards are open but there are no open standards for military data (except geospatial and Hydrographic; see standard data products below). It is important to note that the CALS standard [MIL-STD-28003B] for metadata references/profiles ISO 8632 CGM. The title is 'Digital Representation for Communication of Illustrative Data.'; There is also an ISO 8632 profile that has been developed in the US by NIMA.	Much existing software uses well-established military data models such as ACP133.	Widespread data standardization requires huge investment. Bilateral arrangements are likely to be cheaper for the bilateral arrangements, but much more expensive in multilateral arrangement situations.
3: Data Interchange
Graphics
Images (Vector and Raster)	There is a Coalition Interoperability requirement for standardization for formatting digital imagery files and imagery related products.	Many open standards exist. Some standards are military-specific, but are open in the sense that they are widely supported. (E.g., CALS has developed a metadata standard MIL-PRF-28003A which profiles the ISO computer Graphics Metafile (CGM) standard ISO 8632. Also, a CALS Raster Standard MIL-PRF-28002C puts raster graphics into a binary format.	The continuing support for the majority of these formats is required for legacy systems.	No significant impact.
Fax	There is a Coalition Interoperability requirement to exchange fax data.	Open standards exist.	No significant impact.	No significant impact.
Video/ Audio (Moving Images and Audio/ Video)
Packet Switched (Voice-over-IP)	There is a Coalition Interoperability requirement.	Open standards exist in most areas.	No significant impact.	No significant impact.
Circuit Switched	There is a Coalition Interoperability requirement.	Open standards exist in most areas.	No significant impact.	No significant impact.
Tactical Digital Information Links (Communication Standards for TADILs are dealt with under the Communication Service Area)	There is a Coalition Interoperability requirement for real-time data interchange. Primarily a C2I requirement	No open standards exist, so TADILs are military specific	Different Data Link is in use. Guidance is provided in "Data Link Migration Strategy" SACLANT 3000 C/03/Ser: NU0606, Sept 1998	COTs providers are limited
Military Message Text Formats	All formats identified thus far are specific to C2I systems. (This category does not cover formats related to message handling policy (e.g. P772) which is covered separately below.) C2I-specific messages can be included as the "body part" of STANAG 4406 messages.	These formats are military-specific but most are effective in the sense that they are widely supported.	The continuing support for the majority of these formats is required for legacy systems.	No significant impact.
Civil Message Text	There is a Coalition Interoperability requirement for these interchange formats. Certain message formats (e.g. CALS) are specific to a particular business function so the strength of the NATO-wide requirement for these is questionable.	Effective standards (either military-specific de jure standards or open commercial specifications) exist in most areas.	Some widely used message formats vital for continued interoperability with legacy systems.	No significant impact.
Geographical (GIS)	There is a Coalition Interoperability requirement for interchange of geospatially-referenced data (e.g. overlays). Primarily a C2I requirement. Formats for standard geospatial and Hydrographic data products need to be standardized across all recipient nations. There is a requirement to share geospatial data, but no requirement to standardize on an application.	De jure format standards exist for distribution purposes. Attempts are being made by GIS vendors to develop some standards for APIs and data interchange. Agreement by the Open GIS Consortium (OGIS) on an API standard has now been achieved.	There are many GIS in use in existing systems and significant quantities of GIS data in proprietary formats. Legacy applications software assumes proprietary formats which will require conversion either to other proprietary formats or to less common de jure format standards. Some NCSP-conformant systems will need to support additional (proprietary) formats to provide interoperability with specific legacy systems; the legacy systems themselves will dictate where and what additional formats will be needed. There are lots of legacy applications and geospatial databases around.	Adoption of a de jure interchange format for geographically indexed data could preclude use of many COTS GIS products, unless partnership with GIS vendors helps to ensure development and maintenance of data interchange converters.
Document
Mark-up Languages	Coalition Interoperability requirements exist for transfer of information in device-specific formats (e.g. camera-ready documents and artwork or where an application unique to one NATO nation needs to pass a printable output to another NATO nation's system).	Open standards exist.	Many systems will be unable to interpret the mark-up tags .	No significant impact.
Page description or display languages	Coalition Interoperability requirements exist for transfer of information in device-specific formats (e.g. camera-ready documents and artwork or where an application unique to one NATO nation needs to pass a printable output to another NATO nation's system).	Open standards exist.	Many systems will be unable to read, display or print current page description formats.	No significant impact.
Office Automation interchange formats (Cover under remarks column in NCSP)	There is a NATO-wide requirement to exchange OA documents.	MS Office formats open by virtue of market dominance. Within NATO pdf is the exchange format for invariable documents. De jure document formats (e.g. ODA) are not sufficiently well supported to qualify as acceptably open. See note A.4	Many legacy OA packages in use but functionally limited converters available for many formats.	No significant impact.
Hypertext interchange formats	There is a NATO-wide requirement to exchange hypertext documents (for Intranet purposes or as an alternative interchange format for OA). See note A.5	Open formats exist (HTML plus widely supported proprietary extensions).	No significant impact.	Depends on organizational requirements. For instance, a single data stream can be used by a variety of applications to support multiple devices that include: cellular telephones, computers, web television, etc. This can be accomplished by processing XHTML tags within the XML data stream. As a result, this could reduce existing costs significantly
File compression and archiving	There is a Coalition Interoperability requirement to exchange compressed data.	Many open compression standards exist.	Support may not be available on certain legacy systems for compression formats.	No significant impact.
Military Symbology	Coalition Interoperability requirements exist to pass symbolic information. This relates to the symbol types (e.g. heavy battle tank, frigate) and the actual graphical symbols used to represent them.	No open standards exist, though there are military standards which are widely supported by NATO nations (e.g., MIL-STD-1477B for engagement operations symbology). For force operations, MIL-STD-2525B is also referenced.	Many systems will not support adopted standards.	No significant impact.
Encoding
Character sets and alphabets	There is a NATO-wide requirement to support a common character set.	International alphabet #5 (with National variants) is the only genuinely open standard at present. Future product support for internationalized character sets (e.g. UNICODE) will become more widespread. IA#5 assumed by other formats (e.g. for OA).	No significant impact.	No significant impact.
Data Encoding	There is a Coalition Interoperability requirement to exchange encoded data.	Many open encoding standards exist.	No significant impact.	No significant impact.
Optical Encoding	There is a Coalition Interoperability requirement particularly within the logistics community to read barcode data in support of TAV (Total Asset Visibility).	Many open encoding standards exist.	No significant impact.	No significant impact.
Voice Encoding
Multimedia and distributed real time service data interchange	There is evidence that requirements exist for distributed real-time services and data interchange standards.	Numerous national multimedia standards are accessible in version 4 through the [US] Federal Telecommunications Recommendation (FTR)-1080A-1998, Appendix A.:	Support may or may not be available to various legacy systems.	No significant impact.
4: Graphics
Graphics Development	There is ar equirement for NCF systems	National (US NIMA and CALS) standards are available as a reference point.
Graphics Programming/ Modelling	There may be a requirement for NCF systems in the near future
5: Communications
Application Layer
Messaging	These services are necessary for Coalition Interoperability	Open solutions exist for server to server message transfer protocols (i.e. X.400 P1 protocol and equivalent). The openness of mail client to server protocols (i.e. X.400 P7, POP3, proprietary mail protocols) is not clear. See note A.6	Support is required within the messaging infrastructure for ACP127 (Radio and Teletype RATT Broadcasts) and other legacy messaging protocols.	Most COTS solutions do not satisfy all military requirements. However, systems which are designed specifically for military applications can result in higher developmental and life cycle costs due to the need to obtain additional maintenance support.
Directory Services (Schema, Access, Chaining, Replication, Operational Management)	These services are necessary for Coalition Interoperability As a result, requirements exist for an allied directory system that can support the transfer of directory information. This requires that the following are standardized (as per ACP 133): access and interchange protocols; common schema; common security, authorization and certificate policy; The directory will also be responsible for provision of security certificates which are demanded by the NATO messaging profile. See conclusion	Standards for directory systems exist (e.g. X.500,) and have growing product support. See note A.7	Generally directory systems have been applied to network level services or in a localised context for local messaging systems. Support is required between an ACP 133/X.500 and either an ACP 100/ACP 117 environment or a proprietary/Internet environment. These will require integration and consolidation with ACP 133/X.500 based systems in order to scale and provide the allied service levels demanded with the full range of security requirements.	The risk to allied capability is that the directory support services are not provided in a secure and scaleable way. Since ACP 133 defines a target, nations may in the interim implement similar, yet non-interoperable subsets of the specification.
Domain Name Service	There is a Coalition Interoperability requirement for the exchange of naming and addressing data	Open specifications exist: DNS and X.500 Both will be required: see note A.11	No significant impact.	No significant impact.
Naming and Addressing	There is a NATO Interoperability requirement for the standardization of names and addresses as documented in NACOSA Operating Instructions. This will have an impact on Coalition Interoperability having to use similar naming and addressing rules	Names and addresses should follow DNS and X.500 rules. In addition procedural rules are required.	No significant impact.	No significant impact.
File transfer	There is an evident Coalition Interoperability requirement for file transfer.	IPS applications are open.	No significant impact.	No significant impact.
Remote terminal	There is a Coalition Interoperability requirement for remote terminal access between nations; it is limited to legacy systems.	IPS applications are open.	Remote terminal possibly the only means of interoperability with certain legacy systems.	No significant impact.
Hypertext transfer	There is a NATO-wide requirement to transfer hypertext documents (for Intranet purposes).	Open protocols exist (HTTP).	No significant impact.	No significant impact.
Bulletin Board	There is a possible future Coalition Interoperability requirement for News group and bulletin services.	Open protocols exist (e.g. NNTP)	No significant impact.	No significant impact.
Time services	No evidence of a Coalition Interoperability requirement.	Open protocols exist (e.g. NTP)	No significant impact.	No significant impact.
Audio/Video Teleconferencing	There is evidence of a Coalition Interoperability requirement for transfer of sound between CIS	Open protocols exist in most areas.	No significant impact.	No significant impact.
	There is a Coalition Interoperability requirement to perform video conferencing.	Open standards exist.	No significant impact.	No significant impact.
Whiteboarding	There is a possible future requirement for Whiteboarding services.	Open standards exist.	Most legacy systems will not support Whiteboarding.	Adopting a product that subsequently fails to win market share could incur significant cost penalties.
Application Sharing	There is a NCF requirement for application sharing.	Open standards exist (Data protocols for multi-media conferencing (ITU T.120))
Miscellaneous
	Interoperability requirements arise from: those communications applications (e.g. OSI X.400 applications) that make use of specific upper layer profiles; those distributed computing services that make use of, or independently provide, upper layer functionality.	Standards and profiles are readily available (e.g. ACP 133 and DHCP)	No significant impact.	No significant impact.
Presentation Layer	OSI Presentation layer services are included within specific applications	Profiles exist in the upper layer (e.g. ACP 133)	No significant impact.	No significant impact.
Session Layer	OSI Session layer services are included within specific applications	Profiles exist in the upper layer (e.g. ACP 133)	No significant impact.	No significant impact.
Transport Layer	There is a requirement to standardize transport protocols between nations CIS	Open standards exist	No significant impact.	No significant impact.
Network Layer
Internetworking	There is a requirement to standardize methods for LAN/WAN & LAN/LAN interworking for the purposes of inter-system interconnection.	Open standards exist	No significant impact.	No significant impact.
Router Services (Covered in NCSP remarks column for Internetworking)	Coalition Interoperability requirements exist.	Open standards exist	No significant impact.	No significant impact.
Circuit Switched Wide Area Networking	There is a requirement to link into national telephone networks of NATO nations during joint operations. There is also a requirement for NATO nations to communicate over secure telephone circuits.	Standards are available	No significant impact.	No significant impact.
Point-to-point services (Covered in NCSP remarks column for circuit switched)	These services are necessary for Coalition Interoperability	Open standards exist. Point to Point standards such as IETF RFC, PPP Multilink Protocol allows for aggregation of bandwidth via multiple simultaneous dial-up connections.	No significant impact anticipated.	Based on distributed system configuration restraints.
Packet Switched Wide Area Networking	There is a requirement for standardization of the services provided by the wide-area communications infrastructure.	Open standards exist	See system evolution.	No significant impact.
Tactical data link Services	Tactical data links are widely used by the NATO nations. There is a requirement for these to be integrated into future CIS.	De facto military standards exist.		Disparate data link message formats and related communications often cause a delay in critical battlefield information. Associated cost and risk factors need to be taken into account as a result.
Data Link/ Physical Layer
SATCOM		De facto military standards exist.
Radio	No Coalition Interoperability requirement (other than at point of attachment to wide-area communications infrastructure - see above).	De facto military standards exist.	No significant impact.	No significant impact.
Cable	No Coalition Interoperability requirement (other than at point of attachment to wide-area communications infrastructure - see above).	Open standards exist	No significant impact.	No significant impact.
6: Operating Systems				Based upon specific OS releases and versions (e.g., NT vs. W2K or UNIX 95 vs. UNIX 98) most costs and associated risks may prove exponential to the project goals and objectives undertaken.
Kernel Operations	There services are necessary for Coalition Interoperability
Non Real Time	There is a NATO requirement to standardize on platforms as much as possible for reasons for costs and training	Two operating systems support application software (i.e., POSIX & Windows) for C2 systems in version 4 throughout most coalition environments. Within NATO Windows is the predominant platform .	System administrative support is required for management purposes based on the operating platform, its resources and users based community.
Real Time	There is a requirement to have real time platforms interoperate with non-real time platforms.	When requiring real or near-real-time capabilities, open standards must be considered for this purpose (i.e., IEEE 1003.13:1998).
7: Internationalisation	See Data Interchange Class Encoding
8: System and Network Management
Enterprise Management	No evidence of a Coalition Interoperability requirement See note A.9 See Conclusion	Sufficiently open standards exist (e.g. SNMP) for cross system management.	No significant impact.	No significant impact.
System and Network Management
LAN Management	No evidence of a Coalition Interoperability requirement for management of local area networks. Network management standardization will be required within the wide-area communications infrastructure. But this is not relevant to the management of networks under the control of end-systems. See note A.10. See Conclusion See systems management conclusion above.	Open standards exist for LAN management only. However, these often do not meet security requirements associated with the management of Defence systems.	No significant impact.	No significant impact.
WAN Management	A Coalition Interoperability requirement exists for CWAN. For the immediate future, special procedures will be required to manage the CWAN. See note A.15 See Conclusion
9a: General Security
Authentication	There is an aspiration in future to be able to provide a NATO-wide logon to national systems and the CWAN with automatic propagation of identity and access rights Less ambitious Inter-Nation requirements include the ability to coordinate the management of user identities, access rights, passwords etc. across systems; the ability to pass clearances or other privilege attributes (e.g. group memberships) between systems when making access requests.	Open standards exist in this area (e.g. X.509), but agreement on the syntax and the semantics of clearance attributes is required.	Few legacy systems offer any sophisticated security functionality which would make them amenable to interconnection in this way.	Single log-on across heterogeneous systems is an immature area which would represent a risky standardization undertaking. A lack of commonality in approaches will be an increasingly significant impediment to interoperability. National constraints over system security policies will represent a cost and risk to many projects.
Access Control	See authentication above	As with authentication, the overwhelming requirement to standardize for interoperability can be argued to outweigh the openness disadvantages. NATO-specific standards will be required in areas such as security class labeling.	Few legacy systems offer security functionality amenable to interconnection in this way.	Inter-Nation access control mechanisms and policies need to be established that do not force all end-systems to adopt a uniform security policy or achieve the same assurance targets.
Key Management and Distribution	Coalition Interoperability requirements arise from: the need to distribute keys from a central issuing authority to individual end-systems. This; will be determined by wider Government policy. the need for separate end-systems to exchange keys (e.g. for digital signature purposes). This is a potential NCSP requirement.	There are open standards in this area. Assymetric keys can be distributed via PKI and Symmetric keys can be distributed via EKMS. Nation-specific variants of open standards are under development. See note A.8	No significant impact.	Automated transfer of keys and other security attributes between systems is an immature technology and represents a significant risk.
Confidentiality	Coalition Interoperability requirements exist for confidentiality and integrity options within more direct communications mechanisms, such as RPCs and transport layer protocols.	Open standards do exist for options in transport protocols via Internet technologies (e.g. SSL, TLSP) may soon provide a solution. Operation of RPC mechanisms in version 4 through firewalls is still immature.	Link layer encryption has been the traditional means of providing confidentiality services, and few legacy systems offer this service at other layers. However, even if a common IP high grade crypto is achieved, it will not meet all the requirements for the foreseeable future in respect of availability, transec and traffic flow security, hence there will continue to be a need for high grade link cryptos to meet these requirements.	Inter-nation data confidentiality mechanisms and policies need to be established that do not force all end systems to adopt a uniform security policy or achieve the same assurance levels. This will of course have an impact on the degree of interoperability
Integrity	See data confidentiality above.	See above.	See above.	No significant impact.
Accounting and Audit	These services are necessary for Coalition Interoperability	Open standards exist. Procedure-based mechanisms may need to be adopted.	No significant impact.	No significant impact.
Non-repudiation	Coalition Interoperability requirements exist for non-repudiation of information exchange other than messaging.	No specific open standard exists, but may be achieved by combing open standards, such as hashing and digital signature.	Few legacy systems offer this service other than by procedural controls.	Adoption of a non-COTS solution will increase cost and risk.
Security Domain Mediation	Security domain mediation mechanisms are needed for interoperability but the requirement for them generally arises on a bilateral basis. A future NATO security policy may give rise to a need to standardize mediation services.	No open standards for such services presently exist. Firewall products have a general utility in securing interconnections between end-systems. However, these are not sufficiently well standardized to qualify as being open.	Special enabling mechanisms will continue to be needed to mediate between the security policies of legacy systems.	Building high-assurance guard devices add to cost and risks of interconnection.
9b: Message Security
Message origin authentication	There is a clear Coalition Interoperability requirement that the origin of all formal messages can be authenticated.	Standards exist in this area (X.509) and five nations within the NATO have agreed common algorithms for digital signatures (e.g. DSS).	Users on legacy systems that do not support the use of certificates and digital signatures will be unable to authenticate message origin unless a boundary device is utilized to verify the digital signature of the originator, and mechanisms are employed within the legacy system to guarantee integrity of the message between the boundary device and the recipient. Similarly outgoing messages can have the digital signature of the boundary device appended to provide a level of authentication in the other direction.	Sufficiently strong algorithms are in the public domain, and commercial products are available to implement them. Five nations within the NATO have agreed on common algorithms for digital signatures. The main cost/risk issue is in the supporting infrastructure for the generation and distribution of certificates and tokens and the cost/risk impact of this aspect may be significant.
Message Access Control	There is a clear Coalition Interoperability requirement for exchange of clearance information and security labels in support of formal messaging.	Standards exist in this area (e.g. X.411).	Other than communications and intelligence systems, few legacy systems support the use of security labels or the processing of clearance information.	Commercial products today do not implement X.411 with the clearance extensions hence are not regarded as providing sufficiently strong security to meet the military requirement; but they appear to be moving in this direction so the cost/risk impact may be acceptable.
Message content privacy/ confidentiality	Three of the five NATO/CCEB nations have stated a requirement for per-message confidentiality within message transfers.	Open standards exist for options within messaging protocols; SMIME, PCT and ACP 120 support the military requirement.	Few legacy systems offer security functionality within messaging protocols.	All nations are implementing some type of security (ACP 120, PCT or SMIME) and the cost to implement the necessary mechanisms and management infrastructure for interoperability is likely to be acceptable. Different national policies on encryption may hinder adoption of a common policy.
Message content integrity	Coalition Interoperability requirements exist for integrity options within message transfers.	Open standards exist (e.g. SHA-1, MD5) for options within messaging protocols.	Few legacy systems offer security functionality within messaging protocols.	Sufficiently strong algorithms for integrity are in the public domain, and commercial products are available to implement them. However, when these are combined with encryption to form a digital signature, the main cost/risk issue is in the supporting infrastructure for the generation and distribution of certificates and tokens and the cost/risk impact of this aspect may be significant.
Certificate managent and distribution	Coalition Interoperability requirements arise from the need to distribute signed certificates from a central issuing authority to a directory which is accessible to individual end-systems, and for individual end systems to be able to verify the authenticity of those certificates.	There are open standards for directories (e.g. X.500) and emerging standards for Public Key Authentication Frameworks and Certificate Management Infrastructures.	Few legacy systems provide the necessary mechanisms.	Automated transfer of signed certificates between systems is an immature technology and represents a significant risk. Current commercial products are not deemed sufficiently secure. Alternative mechanisms such as cross-certificates are currently being examined.
Message non-repudiation with proof of origin	Coalition Interoperability requirements exist for non-repudiation of message transfers. No other instances of inter-nation non-repudiation requirements have been identified.	Open standards exist (e.g. digital signatures) for options within messaging protocols.	Few legacy systems offer security functionality within messaging or other protocols, however most legacy messaging systems offer this service in version 4 through procedural controls.	Commercial products implementing ACP 120 are available, and products supporting SMIME are emerging. Cost/risk issues are not expected to be significant.
Message non-repudiation with proof of delivery	Coalition Interoperability requirements exist for non-repudiation of message transfers. No other instances of inter-nation non-repudiation requirements have been identified.	Open standards exist (e.g. signed receipts with trusted time stamps) for options within messaging protocols.	Few legacy systems offer security functionality within messaging or other protocols, however most legacy messaging systems offer this service in version 4 through procedural controls.	Commercial products are available so cost/risk issues are not expected to be significant.
Message security labelling	This is a subset of Message Access Control.
Message accountability	Coalition Interoperability requirements exist.	Some standards do exist.	Few legacy systems offer security functionality within messaging or other protocols, however most legacy messaging systems offer this service in version 4 through procedural controls.	Implementation cost and risk will be high if commercial products cannot provide the required functionality and assurance.
10: Distributed Computing
Environment/ Remote Process	No evidence of a present Coalition Interoperability requirement but future requirements may arise.	No open standards. ONC+ RPC, DCE RPC and Windows RPC are all interoperable to an extent but not in a secure manner.	Upgrades should be evaluated to eliminate security issues.	Based on user/organizational requirements.
Distributed Database Management System
Remote presentation services	No evidence of a Coalition Interoperability requirement.	Open standards exist for UNIX environment (X11). Widely licensed proprietary standards exist for the Windows environment.	No significant impact.	No significant impact.
File Services	No evidence of a Coalition Interoperability requirement.	Open standards exist (SMB, NFS).	No significant impact.	No significant impact.
Print Services	No evidence of a Coalition Interoperability requirement.	Open standards exist (SMB, LPD).	No significant impact.	No significant impact.
Distributed transaction processing services	No evidence of a present Coalition Interoperability requirement but future requirements may arise.	No Open Standards.	No significant impact.	No significant impact.
Object Services	Coalition Interoperability requirements in this area are presently confined to the representation of objects embedded within OA documents Wider use of distributed computing mechanisms for Inter-Nation interoperability is considered under the distributed computing category below. There may be a NATO Common Funded Systems (NCF) need for such services. See note A.12.	DCOM is to be controlled in the future by an open standards body and will therefore qualify as an open standard. Sufficiently open standards (e.g., DCE and CORBA)	No significant impact. No significant impact.	No significant impact. No significant impact.
Time Services
Simulation Services
11: Software Engineering	Services in this area are relevant only to NCF services
Languages
Case
Software Development
12: Common C2 Applications	No evidence of a Coalition Interoperability requirement. Porting of applications may be used as a route to interoperability where no open standards exist.	No genuinely open products.	Potentially relevant, e.g. Nauticus.	Application standardization may lead to undesirable procurement constraints.
Correlation Services	There is a requirement to share track data (and hence a common picture), but no requirement to standardize on an application.	There are no open standards for track management services. Military standards for passing track data exist (e.g. OTH-Gold).	Potentially relevant. The wide use of Nauticus as the main track management application could lead to problems if support for the product changes.	Application standardization may lead to undesirable procurement constraints.
Alert Services	There is evidence of a Coalition Interoperability requirement to pass alerts such as flash messages. See note A.13.	No open standards	No significant impact.	No significant impact.
Data Fusion	There is no requirement at present, however as coalition forces become more integrated there may arise a need to fuse data from disparate sources.	No open standards	Not applicable at present.	Not applicable at present.
13: Collaborative Computing (This will not be added as a new area but all these services will be covered under other areas).
Workflow Services	There is a possible future Inter-Nation requirement for workflow services.	Open standards are emerging.	No significant impact.	No significant impact.
Information Dissemination Management (IDM)	There is a requirement for the support of group access but in read-only mode.	Open standards exist.	No significant impact.	No significant impact.

Table 2.1. Application of General Scoping Principles

Area/ Class	Boundary Issues	Interconnection Security Policy	System Evolution	Conclusion
1: User Interface Services
Graphical User Interafce	N/A	N/A	N/A	Not relevant for system to system interoperability.
Look & Feel	N/A	N/A	N/A	Not relevant for system to system interoperability.
Toolkit	N/A	N/A	N/A	Not relevant for system to system interoperability.
2: Data Management Services
Dictionary/ Directory	No significant impact.	No significant impact.	No significant impact.	Within NCSP scope.
Database Management System (Relational, Object Oriented)	No significant impact	No significant impact	No significant impact	Within NCSP scope.
Distributed Data	No significant impact	No significant impact	No significant impact	Within NCSP scope.
Remote Data Access	Interworking/middleware products exist which could offer a defined interface at system boundary.	Interconnection security policy will often prohibit direct client/server access between systems.	No significant impact.	In scope of NCSP, however security issues may make system-to-system implementation difficult.
Database Replication	It is generally not feasible to convert between replication protocols at system boundaries, so a common protocol needs to be supported by interoperating database products. A number of interoperable database products now exist which support a common protocol.	No significant impact	No significant impact	Within NCSP scope.
NATO Common Schema (NATO level data management)	For interoperability purposes standardization can be limited to external schema. Current work mainly presupposes a relational database-to-database method of interoperability. Object approaches providing encapsulation may permit standardization to be limited to methods provided at system boundaries.	No significant impact	Common data definitions obviate the need to update many local data definitions as individual systems evolve or are adapted to meet new requirements.	Within NCSP scope.
3: Data Interchange
Graphics
Images (Vector and Raster) (Graphical/still image data interchange)	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Fax	No significant impact.	Special circuits or user equipment are required for secure fax transmission.	No significant impact.	Within NCSP scope.
Video/ Audio (Moving Image and Audio/ Video data interchange standards)
Packet Switched (Voice-over-IP)	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Circuit Switched	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Tactical Digital Information Links (Communication Standards for TADILs are dealt with under the Communication Service Area)	Support for designated interchange formats is required at system boundaries only.	No significant impact.	No significant impact.	Within NCSP scope.
Military Message Text Formats (Military data interchange formats)	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Civil Message Text (Business-transaction-orientated data interchange standards)	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	Meeting the security issues could incur significant cost and risk.	There could be significant security issues regarding the use of digital signatures with EDI.	Within NCSP scope (limited to those areas where NATO-wide requirements exist. It is important that National systems and NATO systems eventually utilize the same transaction sets. In addition, there is a need for a common bar code so that international shipments can be tracked effectively.
Geographical (GIS) (Geospatially referenced data interchange standards)	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally. Can avoid standardizing on products by adopting interchange formats (if they become sufficiently).	No significant impact.	No significant impacts assuming that data interchange standards are sufficiently well supported. Application-specific GIS data bases can be difficult to evolve or port to newer systems	Formats of geospatial and Hydrographic data within NCSP scope for distribution purposes. Emergence of future standards will need to be monitored and NCSP extended to include overlay interchange formats. If a suitable, widely adopted data interchange format emerges then there would be no requirement to standardize on a GIS application (except of application or people portability).
Document
Mark-up Languages	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Page description or display languages	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Office Automation interchange formats.	Support required for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	Concurrent support for different generations of interchange format required.	Within NCSP scope.
Hypertext interchange formats	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	Based on evolving requirements, HTML may need to be reevaluated periodically in order to meet ongoing organizational web development specifications.	Hypertext document standards are evolving rapidly but new versions are generally backward compatible. However, the next generation follow-on to HTML is XHTML (eXtensible HyperText Markup Language) which formulates HTML as an XML.	Within NCSP scope.
File compression and archiving	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally	No significant impact.	No significant impact.	Within NCSP scope. The NCSP should consider all open compression formats (.gz, .zip, .tar, etc.) and specify these instead of the compression utilities themselves.
Military Symbology	No significant impact.	No significant impact.	No significant impact.	The standardization of graphical military symbols may be a desirable goal but at present it is only relevant to people or application portability. It is relevant for systems to be able to inform each other of the presence and location of other units. How those units are represented is a matter for individual nations. All nations want to be able to know if their airspace is being compromised. MIL-STD-2525B provides numerous military symbol information that can be passed digitally. MIL-STD-2525B provides each national system with the ability to interpret the digital signature and depict it in their own way.
Encoding
Character sets and alphabets	Support required for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Data Encoding	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Optical Encoding	Support for designated interchange formats is required at system boundaries only (in this case the reader device); in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope.
Voice Encoding
Multimedia and distributed real time service data interchange standards	Support for designated video teleconferencing standards are based on specific system requirements (e.g., Real-time control protocol for simplex applications [H.224]).	No significant impact.	No significant impact.	All standards under this category are already covered in one of the other data interchange categories. For video, see sections on Graphical/Still Image, Moving Image and Audio/Visual data interchange standards. For audio, see section on Audio Data Interchange Standards.
4: Graphics
Graphics Development (Graphics programming languages and APIs)
Graphics Programming/ Modelling (Product data and General Purpose)
5: Communications
Application Layer
Messaging	Support is only required for message transfer protocols and message content formats. The NCSP does not specify messaging protocols or formats used nationally. Agreement is also required on security profiles used at boundaries, including message-labeling formats.	Secure message gateways may be necessary to mediate security services between domains.	COTS functionality is converging with military requirements.	Only message transfer protocols and message content formats are within NCSP scope. Where attachments are to be exchanged, relevant data interchange standards also apply (see 7). Security services for messaging are considered separately below (12)
Directory Services (Schema, Access, Chaining, Replication, Operational Management)	Border directory systems will be used according to national policy to ensure that sensitive national directory information is protected from the shared environment. Strong Authentication will be used for client and server connections to provide the correct levels of trust in the access and transfer of directory information.	As defined in ACP 133 and other ACPs that apply directory for security services.	There is a need to rationalise and manage directory information within nations to ensure consistent information is input into any allied system.	ACP 133 must be applied to provide the most effective and secure way of providing all forms of information and voice exchange between the allied nations. N ATO will need to identify, develop definitions, and store common data elements or there will be ongoing problems in the exchange of information.
Domain Name Service	Different name services may be used internally (e.g. WINS).	Automated exchange of naming information may be prohibited for some interconnections.	No significant impact.	Within NCSP scope.
Naming and Addressing Services
File transfer	No significant impact.	Direct forms of interconnection will often be precluded by security policy.	No significant impact.	Within NCSP scope.
Remote terminal	No significant impact.	Direct forms of interconnection, especially remote terminal, will often be precluded by security policy.	No significant impact.	Within NCSP scope.
Hypertext transfer	No significant impact.	HTTP only includes basic authentication. It therefore cannot be used where in situations where access controls need to be applied on the basis of subscriber identity.	No significant impact.	Within NCSP scope.
Bulletin Board	No significant impact.	No significant impact.	No significant impact.	Within NCSP scope.
Time services	Different time protocols may be used internally (e.g. Microsoft proprietary).	System time is relevant to several system security functions (e.g. auditing) so many system security policies will preclude remote synchronisation.	No significant impact.	Note: As bit rates increase, Universal time becomes more important.
Audio/Video Teleconferencing (Analogue)	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	No significant impact.	No significant impact.	Within NCSP scope. Video conferencing standards are relevant to the communications systems only.
Audio/Video Teleconferencing (Digital)	No significant impact.	Supporting packet switched VTC across security boundaries is likely to require a dedicated VPN because of the close coupling of user terminals and the lack of security mechanisms.	No significant impact.	Within NCSP scope.
Whiteboarding	No significant impact.	Supporting Whiteboarding across security boundaries is likely to require a dedicated VPN because of the close coupling of user terminals and the lack of security mechanisms.	No significant impact.	Within NCSP scope.
Application Sharing
Miscellaneous
(ISO services on top of the transport layer)	Affiliated services should provide the capability to exchange information according to standardized reference models as deemed appropriate (see Openness).			Within NCSP scope. However, conformance to upper layer protocol standards is solely determined by NCSP requirements in other areas (e.g. messaging, RPC). See note A.14.
Presentation Layer
Session Layer (Socket Services)
Transport Layer (Transport Services)	No significant impact.	No significant impact.	No significant impact.	Within NCSP scope.
Network Layer (Networking)
Internetworking	Internetworking regimes used internally within a system are outside NCSP scope.	Internetworking methods may be complicated by the need for guard or firewall mediation in interconnections.	No significant impact.	NCSP scope limited to specification of the permissible modes of LAN/WAN & LAN/LAN interworking for the purposes of interconnection.
Router services	Routing regimes used internally within a system are outside NCSP scope.	No significant impact.	No significant impact.
Circuit Switched Wide Area Networking (Telephony)	Secure telephony requires user equipment to conform to agreed standards, hence it is not purely a system boundary issue.	Secure telephony requires the use of accredited user equipment.	No significant impact.	Telephony standards are within NCSP scope. Specific communications compression standards (e.g. V.42) may need to be standardized within specific nations, or for use within the NATO communications infrastructure.
Point-to-point services	Support is necessary for purpose of splitting, recombining, and sequencing datagrams across multiple PPP links connecting two systems.	No significant impact anticipated.	It is expected that other multilink protocol standards will continue to emerge.	Within NCSP scope.
Packet Switched Wide Area Networking	Unless interconnections are mediated by a communications application (e.g. messaging, firewall), interoperating end-systems must employ the same internetwork and transport protocol.	No significant impact.	Wide-area communications infrastructure evolves slowly because of the investment required for change. Wide-area networks will continue to offer services long after the corresponding standards have been superseded.	NCSP scope limited to specification of the services provided by the wide-area communications infrastructure (i.e. internetworking protocols, data link and physical layer specifications at point of attachment). The technologies used to implement the service are within NCSP scope, but see conclusion under Physical and non-physical bearer systems.
Tactical data link Services	Due to the diversity of warfighter requirements, no single data link is applicable to every platform and weapon system.	TDLs are structured on bit-oriented message standards that evolve to meet critical real-time and near-real-time message requirements. Security issues need to be addressed on a case by case basis.	Greater emphasis must be placed on automated functionality.	Within NCSP scope.
Data Link/ Physical Layer
Bearers
SATCOM	Standardization is only required at the boundary.			National standards exist (see MIL-STD-188-180 series).For example, the US has standardized the terminals for UHFSATCOM DAMA
Radio	Standardization is only required at the boundary.	No significant impact.	No significant impact.	Within NCSP scope in as far as it is necessary to capture the standards that could exist for non-physical bearer systems across the interconnection infrastructure. It is important to note that national standardization efforts have been put in place (e.g., for Joint Task Force LANS on behalf of the US).
Cable	Standardization is only required at the boundary.	No significant impact.	No significant impact.	Within NCSP scope in as far as it is necessary to capture the standards for physical bearer systems that could exist across the interconnection infrastructure.
6: Operating Systems
Kernel Operations
Non Real Time
Real Time
7: Internationalisation				Not relevant except for character sets which are covered under data interchange.
8: System and Network Management
Enterprise Management (System Management)	No significant impact.	Security policy will usually preclude system management interactions between systems. Special considerations required for transfer of access control and authentication data between systems (see below). SNMPv3 builds on SNMPV1 and addresses the deficiencies in SNMPv2 relating to security (e.g., authentication and privacy) and administration (e.g., naming of entities and key management, and proxy relationships).	No significant impact.	Falls within the scope of NCSP (Systems management) for NATO common funded systems (NCF).
System and Network Management
LAN Management See note A.16	No significant impact.	Security policy will usually preclude network management interactions between systems.	No significant impact.	LAN management is Outside NCSP scope (no requirement). It is important to note that a LAN standard for deployment is required (especially between NATO and National systems). LAN management should be integrated into the overall Network Management System. In addition, the system has to be protected by encryption.
WAN Management (CWAN Management)				Within NCSP scope. A Coalition Wide Area Network management approach is required before deployment. LAN management has to be integrated into the overall Network Management System. Furthermore, the overall CWAN would have to be protected by encryption.
9: Security
9a. General Security
Authentication	Security properties at the boundary between systems are strongly dependent upon the mechanisms used internally so any standardization is likely to have an extensive 'systemic' effect.	Policy may preclude access or the transmission of security attributes between systems in many cases (e.g. where the systems have different security assurance levels). Proxy servers or boundary/border devices may be the only mechanisms allowed under national security policies.	Any adopted policy that cannot be supported by commercial products will adversely affect the ability of systems to evolve.	The current NCSP should standardize authentication mechanisms in support of secure inter-networking protocols.
Access Control	As with authentication, security properties at the boundary between systems are strongly dependent upon the mechanisms used internally. Translation of certain aspects can take place at boundaries (e.g. security classification labels).	See authentication above.	No significant impact.	The current NCSP should standardize security classification labels (i.e. permissible labels and their representation). Standardization in other areas will be conditional upon a significant shift in the market position of relevant technologies.
Key Management and Distribution	There are several issues in both PKI (e.g. path processing across boundaries) and EKMS (e.g. common Transfer Key Encryption Keys) that need to be resolved before keys can be exchanged across national boundaries.	Policy may preclude the transmission of security attributes between systems in many cases (e.g. where the systems have different security assurance levels or processing mechanisms).	No significant impact.	Outside NCSP scope at present but may be included in medium term. National policies need to be monitored to determine applicability of commercial standards and national variants.
Confidentiality	Security policy needs to be defined to determine where the confidentiality security services terminate.	At present, high grade security for connectivity can only be achieved in version 4 through link layer encryption. IP based encryption is not yet sufficiently mature.	S/MIME is expected to evolve to include many of the features specified in ACP 120 and could become a suitable mechanism for application layer confidentiality services for some systems.	Scope dependent on availability of standards. Confidentiality options within direct interworking mechanisms (e.g. HTTP, RPCs) may be relevant to the medium-term.
Integrity	See above.	No further issues.	No significant impact.	Scope dependent on the extent to which direct interworking services are adopted in the NCSP in the medium term. As for confidentiality above.
Accounting and Audit	Audit trails are usually maintained within a system boundary and require applications to produce the necessary logs. Audit logs can be passed across system boundaries (e.g. using SNMP), but national security policies may preclude this.	Security Operating Procedures for Accounting and Audit within nations apply. Audit logs could be passed across system boundaries, however this can weaken security (see conclusion).	No significant impact.	Within NCSP scope. Accounting and audit mechanisms can be used locally to support non-repudiation Security is of concern when audit logs are passed in version 4 through firewalls which typically form the boundary of a system. Management protocols (e.g. SNMP) run over UDP; operating UDP in version 4 through a firewall will weaken the security it provides.
Non-repudiation	Security policy needs to be defined to determine where the non-repudiation security service terminates.	No further issues.	Any adopted policy that cannot be supported by commercial products will adversely affect the ability of systems to evolve.	Non-repudiation options within information exchange are within scope of the current NCSP. However there is currently a lack of standards.
Security Domain Mediation	Firewalls typically form the boundaries of systems and are responsible for mediation between the internal system and external WAN environments.	The effectiveness of a firewall is dependent upon the mediation principles that it enforces.	No significant impact.	Outside NCSP scope. A future NATO-wide security policy may bring such services within NCSP scope.
9b. Message Security
Messge origin authentication	Since a digital signature is formed by encrypting a message digest or hash with a private key, common algorithms and certificate profiles are required if this is to succeed across national boundaries. The binding of the corresponding public signature key to the originator is achieved by the signing of the certificate by the Certification Authority. For certificate path processing to be successful across boundaries, the Certificate Management Infrastructure Authentication Framework also needs to extend across these boundaries.	No further issues.	Lack of an acceptable certificate management infrastructure will slow system evolution.	The NCSP should standardize authentication mechanisms in support of message transfer.
Message Access Control	Common security policies or policy equivalence mappings are required to support this service across boundaries.	No further issues.	Lack of acceptable commercial products will slow system evolution.	Within NCSP scope. The current should adopt: X.411 security label syntax (i.e. the way the labels are represented when they are exchanged); security label semantics (i.e. standardize the meaning of security labels) are currently being specified by the INFOSEC ISME For signatures, see Message Origin Authentication. However, given that, unlike NATO, the NATO is not a treaty organisation, in the past it has been deemed impossible to take this logical step forward. clearance semantics (i.e. standardize the meaning of clearance attributes) are a subset of the security label and are currently being specified by the INFOSEC ISME.
Message content privacy/ confidentiality	No significant impact.	Significant issues exist including key management and the use of common encryption algorithms.	Lack of acceptable products will slow system evolution.	Within NCSP scope The security policy should specify confidentiality options within messaging protocols.
Message content integrity	No significant impact, unless the message digest or hash is also encrypted to form a digital signature.	There are significant issues relating to the issuing and management of digital signatures and certificates as well as the adoption of common algorithms.	The reluctance of nations to decide to implement a Certificate Management Infrastructure will affect system evolution.	Within NCSP scope NCSP should standardize integrity options within messaging protocols.
Certificate managent and distribution	There are significant boundary issues particularly in relation to directory shadowing, replication and certificate path processing.	There are significant issues relating to the generation, distribution, management and user validation of signed certificates.	The reluctance of nations to decide to implement a Certificate Management Infrastructure may slow system evolution.	Within NCSP scope at present, but may be more realistic to be included in future NCSP specifications. National policies need to be monitored to determine applicability of commercial standards and Government variants.
Message non-repudiation with proof of origin	Security policy needs to be developed to determine where the non-repudiation security service terminates.	Significant issues including management of digital signatures and the adoption of common algorithms.	Commercial products implementing ACP 120 are available, and products supporting SMIME are emerging.	Within NCSP scope
Message non-repudiation with proof of delivery	Security policy needs to be developed to determine where the non-repudiation security service terminates.	Significant issues including management of digital signatures and the adoption of common algorithms.	Commercial products are available	Within NCSP scope
Message security labelling
Message accountability	Security policy needs to be defined to determine where the accountability security service terminates.	Significant issues including management of digital signatures and the adoption of common algorithms.	Lack of products will affect system evolution.	Within NCSP scope.
10: Distributed Computing
Environment/Remote Process	No significant impact.	System security policy may preclude the direct interconnection between systems demanded for RPC. Should consider IP encryption to reduce current problems. Ipv6 could prove to be a good start.	No significant impact known at this time.	Outside NCSP scope as there is no requirement. Possible requirements and status of standards and products need to be continuously monitored.
Distributed database management system				Covered under project level data management
Remote presentation services	No significant impact.	No significant impact.	No significant impact.	Outside NCSP scope. (For other graphics services see Data Interchange above)
File Services	No significant impact.	File services are usually at the heart of a system security policy. File sharing between systems may therefore force systems to adopt uniform security policies.	No significant impact.	Outside NCSP scope. If an inter-nation requirement emerges then this service would come into scope. Security constraints would still be an issue.
Print Services	No significant impact.	Procedural aspects of control over printed output may limit the distribution of print jobs between systems.	No significant impact.	Outside NCSP scope.
Distributed transaction processing services	No significant impact.	No significant impact.	No significant impact.	Outside NCSP scope at present. Possible requirements and status of standards and products need to be monitored.
Object Services	Competing standards are interoperable to a degree.	Risks associated with import of logic bombs or viruses are greatly magnified with distributed object technologies making interconnection impractical for many systems at present. See DCE Authentication and Security Specification C311 (Open Group) and OMG document formal/98-12-10, CORBA Security Service.	May impact distributing computing configuration based on authentication requirements.	Possible requirements and status of standards and products need to be continuously monitored.
Object Services	Support for designated interchange formats is required at system boundaries only; in all cases, different formats may be used internally.	DCOM uses RPC, for which no acceptably open security standard exists. There it will not be possible to use such mechanisms in situations where access controls need to be applied.		NCSP scope presently limited to OA document formats; see Document Interchange formats above.
Time Services
Simulation Services
11: Software Engineering services				Not relevant.
Languages
Case
Software Development
12: Common C2 Applications	Can avoid standardizing on products by adopting interchange formats in some cases.	No significant impact.	No significant impact.	Outside NCSP scope.
Correlation Services	Can avoid standardizing on products by adopting interchange formats.	No significant impact.	No significant impact.	Outside NCSP scope. At present interoperability can only be achieved by specification of a single product. If a suitable data interchange format emerges then there would be no requirement to standardize on a product. Variable Message Format should be considered [Ref: MIL-STD-2045-47001B] as a viable alternative.
Alert Services	No significant impact.	No significant impact.	No significant impact.	Outside scope of current NCSP because there are no open standards. It is deemed desirable for certain alerts to be sent between NATO nations, particularly in relation to threat warnings. At present, however, there are no open standards and no suitable products.
Data Fusion	Not applicable at present.	Not applicable at present.	Not applicable at present.	Outside NCSP scope at present. However, national capabilities do exist. If permissible, source and method indicators can be removed from the information. This would allow information to be sent effectively to various units in the field.
13: Collaborative Computing (This will not be added as a new area but all these services will be covered under other areas).
Workflow Services	The immature status of emerging standards make interoperability at system boundaries difficult to achieve.	No significant impact.	No significant impact.	Outside NCSP scope at present because there are no sufficiently open standards. Future requirements, the status of standards from the Workflow Management Coalition^[a]and the status of products (e.g. Lotus Notes, SAP & PeopleSoft) need to be monitored.
Information Dissemination Management (IDM)	Support for designated interchange format is required at system boundaries only. Different formats may be used internally.	Write access to on-line published information would need suitable security measures in place.	Standards are evolving rapidly but new versions are generally backwards compatible.	Within NCSP scope for read access only. Write access will come within the NCSP scope if security issues can be resolved.
^[a]The Workflow Management Coalition, founded in August 1993, is an international organisation of workflow vendors, users, analysts and university/research groups. The Coalition's mission is to promote and develop the use of workflow in version 4 through the establishment of standards for software terminology, interoperability and connectivity between workflow products. Consisting of over 130 members, spread in version 4 throughout the world, the Coalition has quickly become established as the primary standards body for this rapidly expanding software market.

Table 2.2. Application of Interoperability Scoping Principles

Area/ Class	Application Accessibility	Reduce In version 4 through-life costs	People Portability and Training	Conclusion
1: User Interface Services
Graphical User Interafce				Relevant to NCF Systems; remote presentation and IPC are addressed under distributed computing.
Look & Feel
Toolkit
2: Data Management Services
3: Data Interchange
4: Graphics
Graphics Programming Languages and APIs				Relevant to NCF Systems for application and people portability
Graphics capability within applications				Relevant to NCF Systems for application and people portability
5: Communications
6: Operating System Services	Most heterogeneous systems utilize either POSIX or Win 32 Application Program Interfaces (APIs). Defining which OS is used often depends on each Application Platform size and/or function. OS security services should be investigated in accordance with the OS being utilized (regardless if used in a standalone or distributed manner).	Linux has emerged as a viable alternative to Unix within specific functional domain areas. However, it is not yet mature enough for implementation purposes within an NCF environment.		Operating System services are necessary in order to perform and provide the functionality in which application software can access a particular platform.
7: Internationalisation				Not relevant except for character sets which are covered under data interchange.
8: System and Network Management
System Management				Falls within the scope of NCSP (Systems management) for NATO Common Funded Systems (NCF).
LAN Management				LAN management is Outside NCSP scope (no requirement). It is important to note that a LAN standard for deployment is required (especially between NATO and National systems). LAN management should be integrated into the overall Network Management System. In addition, the system has to be protected by encryption.
WAN Management				National WAN management will be managed by national staff hence there will be no Coalition Interoperability requirement. It is however important to take national interconnectivity into consideration (if deemed appropriate).
Communications Bearer system management				Outside of NCSP scope presently. Communications systems will be managed by national staff hence there is no inter-nation requirement.
9: Security
9a. General Security
9b. Message Security
10: Distributed Computing
11: Software Engineering services				Not relevant.
12: Common C2 Applications
13: Collaborative Computing
Workflow Services	No significant impact.	The current lack/immaturity of standards means that NCF systems would need to adopt a common application. This would effectively lock-in NCF systems to a single vendor and reduces NATO's ability to effectively manage technology obsolescence.	Adopting a common workflow package would be a benefit.	Within NCSP scope for NCF systems only.
Information Dissemination Management (IDM)				Within NCSP scope for read access only. Write access will come within the NCSP scope if security issues can be resolved.

Table 2.3. Application of NCF System Scoping Principles

Area/ Class	Definition of class/sub class name	Justification for NCSP Standard Selection
1: User Interface Services
Graphical User Interafce	This category covers a miscellany of standards relevant to the Human-Computer Interface, including look and feel standards/conventions, APIs for windowing systems, desktop managers plus desktop hardware and operating system environments. It includes remote presentation protocols (e.g. X11) and inter-process communication protocols (e.g. DDE) which are also listed under Distributed Computing below.	Standards are based on the 2 main platforms selected for NATO use: Windows 2000 and Unix. Standards carried forward from NCSP v 2
Look & Feel		Standards are based on the 2 main platforms selected for NATO use: Windows 2000 and Unix. Standards carried forward from NCSP v 2
Toolkit		Standards are based on the 2 main platforms selected for NATO use: Windows 2000 and Unix. Standards carried forward from NCSP v 2
2: Data Management
Dictionary/ Directory (Data Dictionary)	These are software development support tools that facilitate the management and use of project data dictionaries.	The NC3 Repository is the common repository for standard data elements for the NATO CorpDM. This standard has been selected by the NDAG/NDAO
Database Management System (Relational and Object Orientated)	These are the facilities provided by a conventional RDBMS and OODBMS.	Standards carried forward from NCSP v 2
Distributed Data	See sub-classes below
Remote Data Access	These are mechanisms that allow clients to access data on remote database servers in a client/server environment.	Standards carried forward from NCSP v 2
Database Replication	These are mechanisms for replication of data between DBMSs, such as provided by modern commercial DBMS products.	The ATCCIS Replication Mechanism (ARM) supports the land component as a View Model of the NATO CorpDM
NATO Common Schema See note A.2	This category covers what would normally be described as data management. It includes data models plus associated metadata standards and data management procedures.	The NATO CorpDM v1 has been selected by the NDAG/NDAO.
3: Data Interchange
Graphics	See sub-classes below
Images (Vector and Raster) (Graphical/still image data interchange)	A wide range of standards used for representation of still image and graphic data,	Standards carried forward from NCSP v 2. Some new standards have been added for interchange and compressed storage of raster images that will eventually replace GIF and NITFS
Fax	Fax standards for representation and transfer of page images.	Standards carried forward from NCSP v 2
Video/ Audio (Moving Image and Audio/ Video data interchange standards)	As above but for moving images. It also includes standards for video conferencing and video telephony.	Standards carried forward from NCSP v 2 and ACP 140A
Packet Switched (Voice-over-IP)	A range of standards used for telephony over IP-based networks.
Circuit Switched	Services for voice encoding across both analogue and digital dial-up connections. Includes modem services.	New Sub-class and standards have been added to be used for Tactical Communications. Standards. These standards are currently in use in NATO and have been agreed by SC/6
Tactical Digital Information Links (Communication Standards for TADILs are dealt with under the Communication Service Area)	Links supporting the transfer of tactical information between coalition forces.	Standards have been approved by the Data Link Working Group of the SC/5
Military Message Text Formats	Encodings of military-specific information in structured or unstructured form. Structured formats include both binary (bit-level) encodings and text-based (machine and human-readable) messages.	Standards have been approved by the Message Text Formatting Working Group of the SC/5
Civil Message Text	Specific text- or bit-oriented formats for representation of business-related data.	Standard carried forward from NCSP v 2. EbXML is expected to replace EDIFACT
Geographical (GIS)	This category covers a wide range of standards used for representation of still image and graphic data, including geospatially referenced data formats. It also includes the fax standards (group 3 and group 4) for representation and transfer of page images.	Digest and related exchange formats have been agreed by the Nations as the mandatory Geo Data exchange formats and are carried forward from NCSP v2.
Document	See sub-classes below
Mark-up Languages	Standards for marking-up (tagging) text, both structure and content.	Standards carried forward from NCSP v 2 and ACP 140A. Other XML-related suite of standards also added for completeness.
Page description or display languages	Standards for describing page layouts for submission to print or display devices (e.g. postscript).	Standards carried forward from NCSP v 2
Office Automation interchange formats.	Formats used for interchange of documents between OA tools (word processor, spreadsheet, etc.).	Standards carried forward from NCSP v 2
Hypertext interchange formats Hypertext transfer protocols in Comms Service Area	Formats for representation and transfer of hypertext documents.	Standards carried forward from NCSP v 2
File compression and archiving	Standards for the extraction and encoding of compact file representations.	Zip has been added as it is the de-facto market standard
Military Symbology	Standards for representation of military symbols (usually on map overlays).	For CCEB the standard is Mil-Std 2525B. For NATO APP-6/ STANAG 2019 and STANAG 3675 are the agreed standards
Encoding
Character sets and alphabets	Binary encodings used to represent alphanumeric characters and special characters used in foreign languages or technical literature.	Standards carried forward from NCSP v 2 Service Area Internationalisation
Data Encoding	Standards for encoding of binary or structured data, usually for transfer via a communications medium. This category covers ASN.1 and its encoding rules and UUENCODE.	Standards carried forward from NCSP v 2 Service Area Internationalisation
Optical Encoding	Special characters that are transposed to represent binary encodings of scanned data via optical devices (e.g. barcodes).	ISO standard xxxx (code 39) is widely used by the military and commercial logistics communities around the world. ISO standard xxxx (code 128) is rapidly emerging.
Voice Encoding	Standards for encoding of voice, usually for transfer via a communications medium. This category covers ASN.1 and itsxs encoding rules and UUENCODE.
Multimedia and distributed real time service data interchange standards	A range of standards used for reprasentation of moving images, including standards for video-coferencing and video telephony.
4: Graphics
Graphics Development		Standards carried forward from NCSP v2
Graphics Programming/ Modelling (Product data and General Purpose)	Languages or language bindings to facilitate the production of graphics-based applications software.	Standards carried forward from NCSP v2
5: Communications
Application Layer	OSI applications over TCP/IP lower layers are included
Messaging	Store-and-forward transfer of messages	Standards agreed by the Message Handling Woking Group of the SC/5 and carried forward from NCSP v 2. X.400 has been deleted as it is part of STANAG 4406, and X.400 only systems are not foreseen.
Directory Services (Schema, Access, Chaining, Replication, Operational Management)	Services for the provision of information relating to all forms of communications and information services including the support of messaging and security services.	Standards agreed by the Directory Services Working Group of the SC/5 and carried forward from the NCSP v2. X.500 has been deleted as it is part of the ACP 133B Profile.
Domain Name Service	Services for resolution of computer or server names into specific addresses.	Standard carried forward from NCSP v 2.
Naming and Addressing Services	The specification of rules and formats for Domain names and IP addresses.	Standards carried forward from NCSP v2, but needs to be replaced by NACOSA Operating Instructions when available.
File transfer	Protocols and applications to provide a file transfer facility. They include both OSI application-layer standards and their IPS equivalents.	Standard carried forward from NCSP v 2.
Remote terminal	Protocols and applications that enable remote terminals to connect into a system. They include both OSI application-layer standards and their Internet Protocol Suite (IPS) equivalents. Such connections typically emulate character-based terminals and are used to provide access to legacy systems.	Standard carried forward from NCSP v 2.
Hypertext transfer	Protocols used for the transfer of hypertext documents between systems, including selective transfer for 'browsing'.	Standard carried forward from NCSP v 2.
Bulletin Board	Information transfer services designed to notify registered subscribers of updates occurring in news groups and transfer relevant information	Standard carried forward from NCSP v 2.
Time services	Protocols for synchronisation of system clocks.	Standard carried forward from NCSP v 2.
Audio/Video Teleconferencing	Standards for transmitting audio and video between CIS	Standard carried forward from NCSP v 2.
Whiteboarding	Services supporting the sharing of displays across a network allowing multiple users to collaborate simultaneously in the creation, review and updating of graphical or textual information.	Standard carried forward from NCSP v 2.
Application Sharing	Services supporting the sharing of applications across a network.	Standard carried forward from NCSP v 2.
Miscellaneous		Standard carried forward from NCSP v 2.

Presentation Layer		OSI Presentaion Layer standards have been deleted as their services are included within the applications that provide the higher layer services
Session Layer	This category includes APIs providing access to Internet protocols (e.g. WinSock) and associated applications.	OSI Session Layer standards have been deleted as their services are included within the applications that provide the higher layer services
Transport Layer	Services providing user access to internetworking services and end-to-end quality enhancement	Standard carried forward from NCSP v2.
Network Layer	See sub-classes below.
Internetworking	Standards for the transfer of data across LAN/WAN and LAN/LAN boundaries.	Standard carried forward from NCSP v2.
Router services (Covered in NCSP remarks column for internetworking)	Routers are used to interconnect networks of differing types, including sub-networks and end systems.	OSPF carried forward from NCSP v2 and covered under Internetworking
Circuit Switched Wide Area Networking	Services for voice encoding across both analogue and digital dial-up connections. Includes modem services.	Standards carried forward from NCSP v2.
Point-to-point services (Covered in NCSP remarks column for circuit switched)	Services providing full duplex, synchronous or asynchronous network connections over a serial line.	Standard carried forward from NCSP v2 covered under Circuit Switched WAN
Packet Switched Wide Area Networking	Standards for the transfer of data across wide area networks including X.25, Frame Relay, ISDN, B-ISDN (ATM) and SONET	Standards carried forward from NCSP v2.
Tactical data link Services	Tactical data links provide the means for exchanging tactical information used for battle management	Communication standards in use for Link 11, 16 and 22.
Data Link/ Physical Layer	See sub-classes below.
SATCOM	Standards for the transfer of data across SATCOM links including UHF, SHF and EHF.	CCEB uses range of Mil-Stds carried forward from ACP140A. NATO uses STANAG4231, 4233 and 4522
Radio	Standards for the transfer of data across Radio links including VLF, LF, HF, VHF, UHF and SHF.	CCEB uses range of Mil-Stds carried forward from ACP140A. NATO uses STANAG 4203, 4204, 4205, 4197A, 4285, 4444, 4246 and 4175.
Cable	Standards for the transfer of data across copper and fibre links including Optical, Shielded Twisted Pair and UTP	Standards currently in use within NATO. (to be verified by SC/6)
6: Operating Systems	Standards for the services provided by computer operating systems and the means of accessing them by user applications.
Kernel Operations
Non Real Time		UNIX98 standard carried forward from NCSP v2 MS Windows 2000 carried forward from NCSP v2 LINUX LSB 1.1: Emerging std - second largest and fastest growing userbase in server market; open source provides advantages for implementation of security features. See Note A.17
Real Time		UNIX98 standard: standard carried forward from NCSP v2
7: Internationalisation	Internationalisation services are those standards and conventions that facilitate the use or re-use of systems or software within different National or cultural contexts. They cover a broad range of Internationalisation standards which can be loosely categorised as character sets, specific data representations and Internationalisation aspects of system interfaces (mainly HCI).	Standards have been moved to Data Interchange: Encoding, Character Sets and Alphabets
8: System and Network Management
Enterprise Management	Services supporting the management of end-systems, including user administration, configuration management, fault management, security management, etc.	Standards carried forward from NCSP v2
System and Network Management	Services supporting the management of networks under the control of end-systems or within the wide-area communications infrastructure.
LAN Management		Standards carried forward from NCSP v2
WAN Management		Standards carried forward from NCSP v2
9a: General Security (General security and message security will be comnbined into a service area called security with the classes General and Messages)
Authentication	Authentication services are those services supporting the reliable identification of individual users or groups of users of one system attempting to access services or information provided by another system.
Access Control	Access control services are those services supporting the exercise and promulgation of access rights for service/information exchange between systems based on user identity, role, group, clearance or other privilege attributes. This includes standards for security labels where these are used (e.g. message exchange).
Key Management and Distribution	Services supporting the management and distribution of cryptographic keys.	Standards carried forward from NCSP v2
Confidentiality	Services supporting the confidentiality of information/services exchanged between systems.	For CCEB standards carried forward from ACP120
Integrity	Services supporting the integrity of information/services exchanged between systems.	For CCEB standards carried forward from ACP120 For NATO standards carried forward from NCSP v2
Accounting and Audit	Services supporting the recording and analysis of security-relevant events involved in the exchange of services/information between systems.
Non-repudiation	Services supporting the verification of provision/acceptance of services or information between systems.
Security Domain Mediation	Services supporting the secure exchange of services between systems operating under differing security policies or within separate security domains.
9b. Message Security
Messge origin authentication	Service providing assurance that a message was originated by the user indicated as the sender. It is the veritable identification of the user or organisation which originated the message.
Message Access Control	Services for validating authorisation of the user to originate messages is a national prerogative. The originator should ensure that the lowest common clearance of the communications system, end system and recipient dominate the classification of the message. This is to ensure that messages sent do not violate the security policies of the originating domains. Similarly, the receiving domain must compare the classification of the message with the clearance of the receiving domain. For the purposes of interoperability, this only includes standards for exchange of clearance information and security labels.
Message content privacy/ confidentiality	Service providing assurance that a message was originated by the user indicated as the sender. It is the veritable identification of the user or organisation which originated the message.
Message content integrity	Services supporting the integrity of messages exchanged.	For NATO STANAG 4406 is carried forward from NCSP v2. For CCEB interoperability the standards ACP120 has been carried forward from ACP140A
Certificate managent and distribution	Services supporting the management and distribution of certificates required to implement the message integrity and authentication security services.	For CCEB interoperability the standards ACP120 has been carried forward from ACP140A
Message non-repudiation with proof of origin	Services providing the recipient of a message with proof of its origin. This provides the ability to prove to a third party that a message was released by the originator and will protect against any attempt by the message originator to falsely deny having sent the message.	For CCEB interoperability the standards ACP120 has been carried forward from ACP140A
Message non-repudiation with proof of delivery	Services providing the originator of a message with proof of its delivery. This provides the ability to prove to a third party that a message was received by a particular recipient and will protect against any attempt by the message recipient falsely to deny having received the message.	For CCEB interoperability the standards ACP120 has been carried forward from ACP140A
Message security labelling	Services providing a method for associating security labels with objects in a MHS.
Message accountability	This service provides assurance that messages sent are received by the intended recipient, or permitted alternate recipient. The message originator is notified of any problems with message delivery. This can form a part of overall non-repudiation.	For CCEB interoperability the standards ACP120 has been carried forward from ACP140A
10: Distributed Computing
Environment/ Remote Process	Remote procedure call (included in this category are the other forms of inter-process communication).
Distributed database management system	Services for maintenance or querying of databases distributed over multiple physical locations.
Remote presentation services	Protocols permitting graphical user interfaces to execute remotely from the client application (e.g. X11).
File Services	File sharing protocols.
Print Services	Protocols for transfer of print jobs from client to spooler/printer.
Distributed transaction processing services	Services for the management of transactions involving participants on different end-systems.
Object Services	Services for location of, or access to, objects when distributed over a network.
Time Services	Protocols for synchronisation of system clocks.
Simulation Services
11: Software Engineering services	This category mainly covers standards for the system/software lifecycle processes and associated tools but also includes standards for programming languages and their bindings
Languages		Standards carried forward from NCSP v2. C# has been added as the Microsoft equivalent for Java.
Case
Software Development
12: Collaborative Computing (This will not be added as a new area but all these services will be covered under another area)
Workflow services	Services supporting the automated transfer of documents or other information between users or organisations on the basis of a predefined business process.
Information Dissemination Management (IDM)	Services supporting group access (read/write) to structured or unstructured information on the basis of subject area or other categorisation.
Collaborative Computing	Services supporting the sharing of displays across a network.
13: Common C2 Applications (Maps to NCOE component model)
Correlation Services	Applications providing services relating to the acquisition, correlation, update and query of tracks.
Alert Services	Information transfer services designed to support the rapid or widespread distribution of information, usually having great operational significance.
Data Fusion	Services supporting the fusion of data from a variety of possible sources in support of a common opertional picture.

Table 2.4. Justification for NCSP Standard Selection

< Prev		Next >
	Home