ANWI Architecture Initial System and Technical View

N A T O U N C L A S S I F I E D 

IFB-CO-13300-ANWI-AMD-2 

SECTION 12. ANNEX D: ANWI Architecture Initial System 

and Technical View 

12.1 Introduction 

12.1.1 Purpose 

12.1.1-p1 The purpose of this technical annex is to provide architecture initial 

system and technical view information and requirements that will drive the production 

of the ANWI design as required by section 5 of this SoW. 

12.1.1-p2 A key purpose of this annex is to describe all interfaces within the ANWI 

project, and all interfaces between the ANWI and the external services. 

12.1.2 Annex Structure 

12.1.2-p1 This Annex contains the following chapters: 

A. Section 12.2 provides the design drivers. 

B. Section 12.3 provides the initial architecture system view and identifies at 

the high level the external interfaces to the ANWI capability. 

C. Section 12.4 provides an overview of the ANWI modules and identifies 

internal interfaces 

D. Section 12.5 specifies the external interfaces. 

E. Section 12.6 provides the end-to-end information flows showing the 

service traversal through internal modules and interfaces to external 

interfaces. 

12.2 Design Drivers 

12.2.1 General 

12.2.1-p1 The scope of this section is to drill down on the key architecture 

principles as introduced in annex C and provide design guidance that the ANWI 

contractor shall address in ANWI design: 

12.2.2 Mobility 

12.2.2-p1 The ANWI design shall address the implementation of the New NATO 

HQ operational mobility concept that consists of two key pillars: 

12.2.2-p2 Mobile devices that embrace Unified Communication and Collaboration 

(UCC) capabilities: 

A. Support Data, Voice and Video 

B. To experience a similar „look and feel‟ on various mobile and fixed 

devices. 

C. Services that are capable of switching automatically and transparently (to 

the User) from one device to another (dependent upon user/device 

location). 


Book II Page IV-166 of 532



Book II Page IV-167 of 532 


D. Extensive Unified Communications & Collaboration (UCC) tools, which will 

be seamlessly integrated between the various devices (e.g. continuously 

synchronized email and Calendar/Agenda). 

E. Presence/Availability services (e.g. if a user makes a telephone call he 

should be identified „busy‟ for other UCC services). 

12.2.2-p3 Adopt the increasing use of the Business Infrastructure for processing 

NATO information 

12.2.3 Identity Management 

12.2.3-p1 The ANWI design shall address the implementation of Identity and 

Access Management to achieve the following effects: 

12.2.3-p2 Identity Management shall include the provision of a single sign on user 

experience for ANWI user for ANWI end-2-end services. This include the integration 

of logical (ANWI access) and physical (building access) Identify and Access 

management for the Business Infrastructure utilising the building access smartcard 

capability as provided by HN Belgium as part of the ESS capability. 

12.2.3-p3 Identity Management shall include the provision of a single identity and 

identity authoritative data sources across the ANWI security domains. 

12.2.3-p4 Identity Management shall support federated identity and access 

management for access to/from security domains external to the ANWI domains. 

12.2.3-p5 Identity Management shall support integration of business applications 

Identity and Access Management mechanisms with the ANWI provided Identity and 

Access management services. 

12.2.4 Infrastructure as a Service (IaaS) 

12.2.4-p1 The ANWI design for the ANWI infrastructure services (see Annex F) 

shall adopt an IaaS cloud-ready approach. 

12.2.4-p2 

It shall include all functionality for on-demand self service. 

12.2.4-p3 It shall ensure broad network access for the ANWI (local) network 

environment and shall include provisions to extend this to the WAN environment. 

12.2.4-p4 It shall support resource pooling: dynamical assignment and deassignment 

of infrastructure resources. 

12.2.4-p5 It shall support rapid elasticity within the boundaries as defined for 

scalability as the local ANWI level (see section 11) and it shall include provisions to 

extend elasticity support at the WAN level shared IT. 

12.2.4-p6 It shall allow for full measuring and metering and reporting of all 

infrastructure services on all its indicated performance, capacity, elasticity, resource 

assignment features (see annex F). 

12.2.5 Green IT 

12.2.5-p1 The NNHQ project has a focus on sustainability, which must be 

inherited by the ICT projects. The ANWI Contractor shall incorporate and cover in the 

PMP and design the following three Strategic areas that are part of the NNHQ Green



IT strategy (see reference 1.1.1.7.7) and proof compliance to these strategies 

through processes, procedureal or technical/services measures: 

A. Energy Optimisation Management. 

B. IT Governance. 

C. Communication. 

12.2.5-p2 Any green optimizations that negatively impact NATO´s primary 

objectives or increase the life cycle cost shall not be proposed. 

12.2.5-p3 The following targets shall be completed by the end of the build phase 

and of the migration to the new NATO headquarters. 

12.2.5-p4 Energy reduction - The success of this target shall be measured as the 

reduction of the overall energy consumption per employee. The target will be set 

after the initial measurement. The ANWI Contractor shall provide support to this effort 

by performing and reporting the baseline ANWI energy concsumtion measurements 

by FOC. The ANWI Contractor shall formally manage and report ANWI energy 

consumption after baselining the ANWI energy consumption as part of the overall 

ANWI services change management procedures. 

12.2.5-p5 Green Procurement - The ANWI Contractor shall provide relevant 

environmental compliance documents for all its products and suppliers (Electronic 

Product Environmental Assessment, Energy Star) and their own environmental 

policy. 

12.2.5-p6 

The following are specific Green IT targets for the ANWI project: 

12.2.5-p7 Paper reduction - The printing services shall by default provide options 

to reduce printed paper, for example double sided printing. 

12.2.5-p8 The ANWI Contractor shall take into account the environmental 

specifications for each service specified in Annexes F – I. 

12.2.5-p9 All devices used in the ANWI environment shall be optimized for energy 

efficiency and “Green” settings should be used and enforced as much as possible. 

12.2.5-p10 The ANWI user facing devices shall have limited heat production 

and shall ensure the user working environment environmental conditions for the 

users remain at all times within the limits of workable conditions given the building 

environmental slab cooling capacity. 

12.2.6 Virtualization 

12.2.6-p1 Virtualization is a key requirementfor NATO so the ANWI Contractor 

shall provide the service through a vitualised infrastructure. 

12.2.6-p2 Any deviation of the proposed solution from deploying the virtualized 

environment (due to very specific hardware component or peripheral dependencies, 

and so on) shall be documented in detail with its justification and be subject to the 

approval of the Purchaser. 

12.2.6-p3 In case of a non-virtualized solution being proposed, the physical 

infrastructure shall be integrated into the ANWISMC environment minimizing direct 

physical interaction with the servers needed. 



12.2.7 User Experience 



12.2.7-p1 With remote workers, branch offices, security demands and other 

reasons, most modern ICT solutions combine different workplace solutions for their 

users (desktops, laptops, Virtual Desktop Infrastructure (VDI), Server Based 

Computing (SBC)). For users working with these solutions, this can be quite 

confusing. Desktops change, icons are different, and versions of software can be 

different. 

12.2.7-p2 The Man-Machine Interface (MMI) shall be similar enough between all 

workplace solutions in order for a normal user to be able to use them conveniently. 

12.2.7-p3 Whether a user works on a laptop or on a SBC solution, the look and 

feel of his desktop shall be the same and a user shall have minimal confusion when 

switching between workplaces. 

12.2.7-p4 The user interfaces shall make it instantly clear (visible) on which 

security network the user is currently working, to prevent accidents resulting in 

security violations. 

12.2.7-p5 

centrally. 

12.2.8 Standardization 

The management of these different user environments shall be done 

12.2.8-p1 The ANWI Contractor shall design and implement the ANWI services 

using a well-defined set of products that are to be standardized to the extent possible 

thus ensuring a minimized variation of components and products across the ICT’s 

infrastructure. 

12.2.8-p2 Components that perform the same function across different locations, 

networks within ANWI shall be of same brand, model, capacity and feature. 

12.2.8-p3 The ANWI Contractor shall clearly document the justification and the 

results of exceptional cases where use of same equipment is not possible. 

12.2.8-p4 

All physical interfaces shall be based on industry standards. 

12.2.8-p5 All logical interfaces shall be based on industry standards and 

protocols. The minimum is to ensure the ANWI interfaces comply with standards as 

promoted in the NISP. As and when there is no match with the NISP promoted 

standards then either a reference to open standards (OSI, ITU, ..) need to be 

provided or in case it is about a proprietary or industry standards a justification of its 

use and interoperability (limitations) should be provided. 

12.2.8-p6 All hardware shall comply with the Bi-SC Minimum Hardware 

Procurement Specifications (see 1.1.1.5.1). Compliance with this document shall be 

limited at the level of specific hardware components (e.g. server, processing unit…) 

as part of the design and considered as minimum component requirements. The 

contractor’s design shall address the additional HW component features needed to 

achieve an integrate ANWI service. 




12.2.9 High Available NNHQ ICT Environment 


12.2.9-p1 The ANWI contractor shall provide the necessary means to minimize 

service disruption and data loss, to meet or exceed the requirements stated in this 

section and in specific Annexes. 

12.2.9-p2 

Availability is defined as: Availability = uptime / total time. 

12.2.9-p3 The ANWI contract has introduced an additional metric to entertain 

efficient management (limit size and frequency in a certain period) of scheduled 

downtime: Reliability. Reliability is defined as: Reliability = uptime / (total time – 

scheduled downtime) 

12.2.9-p4 ANWI services shall be designed and implemented to meet the specific 

availability criteria provided in Annex E – I. 

12.2.9-p5 Disruptions, ranging from user error to the complete failure of a server 

room, shall result in minimal data loss and minimal disruption of ICT services, using a 

combination of failover mechanisms. 

12.2.9-p6 ANWI shall have its core components and capabilities installed into two 

server rooms within NNHQ building. 

12.2.9-p7 Based on the required availability thresholds, the ANWI Contractor shall 

design and implement required configurations across two server rooms for each 

component (such as an active-active setup). 

12.2.9-p8 In case of failure in one server room, from a single server or a storage 

unit, to the entire server room, the other server room shall automatically take over the 

functionality, with minimal disruption of user services. 

12.2.9-p9 Apart from the dual server rooms, there shall also be dual 

Communication rooms (TCF) built in the NNHQ. 

12.2.9-p10 Where needed, ANWI components shall be installed or integrated 

with equipment across these two Communication Rooms following the same high 

availability principles as the Server Rooms. 

12.2.10 Additional Availability Requirements 

12.2.10-p1 ANWI design and implementation shall take into account the 

requirement to be able to use a third storage node for disaster recovery purposes. 





12.2.10-p2 Data synchronization between the server rooms shall be 

considered, on multiple levels, for example: 

A. Application replication, e.g. Active Directory (AD) synchronization or 

Exchange Database Availability Group (DAG). 

B. Storage replication. 

12.2.10-p3 The following requirements on availability of data and services shall 

be taken into consideration in addition to the individual specific figures in Annex E –I 

A. Basic Office automation services (for example: authentication, user 

settings, file & print services, email) shall be high available. Even if a 

complete collapse of one server room occurs, there shall be limited 

noticeable disturbance for users. More service specific availability figures 

can be found in Annex E-I. 

B. NATO client-server or web based applications shall be redundantly setup 

over both server rooms, making them highly available. 

C. Client-server applications, which cannot have an active-active setup, shall 

lose only a limited amount of data. The amount of lost data is dependent 

upon 1) the amount of changes per time period in the databases and 2) 

the transfer speed of the changes. E.g. a critical Database (DB), with few 

and small changes, could synchronize its changes (log shipping) every 10 

minutes. 

D. All servers/applications that cannot be configured as an active-active 

configuration, shall, in case of failure of that server, or of the entire server 

room, be available to restart in the second server room. 

E. All data shall be available in either server room, to be accessible in case 

there is a problem in the other room. 

12.2.11 Modularity Principle 

12.2.11-p1 The ANWI design and physical implementation shall support a 

modular approach where system functions are logically and physically bundled in 

modules that can easily be expanded vertically (scale out, adding 

functions/performance) or horizontally (scale up, adding capacity). More information 

about the ANWI modularity requirements is provided in paragraph 12.5. 

12.2.12 Reduced ICT Capacity 

12.2.12-p1 In case of unavailability of a complete server room the ANWI services 

shall have a maximum allowed performance degradation per service as indicated in 

the table below. 

No. Reduced ICT Capacity Max Degradation - 

Performance 

Services 

1 Specific Communities Of Interest (SCOI) 

1.1 Service Management Capabilities (SMC) 25% 

1.2 Information Assurance Policies & Management 25% 






Performance 

Services 

(IAM) 

2 Infrastructure Services 

2.1 Processing n.a. 

2.2 Storage n.a. 

2.3 Printing & Scanning 25% 

2.4 Network Infrastructure 25% 

2.5 

a 

2.5 

b 

LAN (Wired) 

LAN (Wireless) 

n.a. 

n.a. 

2.6 Cross Domain 25% 

3 UCC (Unified Communications & Collaboration Services 

3.1 Voice 10% 

3.2 Voicemail 25% 

3.3 Video-Teleconferencing (VTC) 10% 

3.4 E-mail 25% 

3.5 Unified Messaging 25% 

3.6 FAX 25% 

3.7 Instant Messaging (IM)/chat 25% 

3.8 Presence 25% 

3.9 Directory Service 25% 

3.1 

0 

3.1 

1 

Collaboration 25% 

Mobility 25% 

4 Client Provisioning Services 

4.1 Software provisioning 25% 

4.2 Client devices n.a. 






Performance 

Services 

5 Supplementary Services 

5.1 GSM n.a. 

5.2 GSM Blocking n.a. 

5.3 Wireless Blocking n.a. 

5.4 Site Security Communications (Radio) n.a. 

5.5 IPTV 25% 

12.2.12-p2 For the ANWI Services (except Voice/VTC) – a single server room shall 

be able to support 75% of the total users/load without Performance degradation. 

12.3 Initial System View 

12.3.1 ANWI System View 

12.3.1-p1 Figure 12.1 shows the high-level ANWI system view that identifies the 

following main elements: 

A. External Entities, entities PFE (Annex B) shall be fully integrated into the 

ANWI capability by the ANWI Contractor. 

B. The two major infrastructures that comprise the ANWI capability. These 

major infrastructures will be further defined in section 12.3.2 and 12.3.3 

respectively: 

1. NS Infrastructure. 

2. Business Infrastructure. 

C. Cross Domain Services, described in 12.3.4, that secure and regulate the 

interfaces and information flows: 

1. To the external entities. 

2. Between the Business and NS infrastructures. 





Figure 12.1: ANWI System View 

12.3.2 External Entities 

12.3.2-p1 The ANWI shall interface with and integrate to the external entities as 

identifiedin figure 12.1 in the following groupings: 

A. NATO Services; The NGCS is responsible for providing connectivity and 

services across NATO and between NATO and NATO Nations. 

Interconnection between NATO and other International Organisations (EU, 

Partners for Peace, Mediterranean Dialogue), will be via the PIA gateway. 

Annex B provides a detailed NGCS Operational Connectivity description. 

The NATO Network Services, connected through NGCS will present 

network interfaces into other NATO Services. 

B. Commercial Network Services. These are services available through 

(public) service providers. 

C. Passive Building Facility Related Services; Representing the physical 

(passive) building related services (e.g. cabling, desk space, rack/floor 

space, power/cooling) see Annex B. 

D. Active Building Facility Related Services; Representing the (active) 

information services related to building security management and 

conference facilities (e.g. Enterprise Security System (ESS, see Annex B), 

the building management services (BMS, see Annex B) and the Audio 

Video Infrastructure (AVI, see Annex B) related services). 

E. Business Applications; Represents end-user or application services that 

are provided to HQ users and/or users accessing the applications via 

extranet portals (see Annex B). 





12.3.2-p2 The ANWI shall integrate and interface, via NGCS, with the following 

NATO Services: 

A. VTC: see Annex B. 

B. PIA: see Annex B. 

C. Reserved 

D. Voice: see Annex B. 

E. NEDS: see Annex B. 

F. IA Services: 

1. NCIRC: see Annex B. 

2. NPKI: see Annex B. 

3. Firewall Management: see Annex B. 

G. Domain Services: 

1. Active Directory 

2. AIS AD domain services: See Annex B. 

3. Future Single Forest Single Domain, or federated NU and NR domains. 

H. Messaging Services, consisting of: 

1. AIS email Active Directory based Services: See Annex B. 

2. NATO Messaging Services: See Annex B 

I. SMC/CIS management consisting of: 

1. NCGS management: See Annex B 

2. AIS Enterprise Management Services (EMS): See Annex B 

12.3.2-p3 The ANWI system shall interface and integrate with the following 

external Commercial Services: 

A. The IPTV service shall manage and administer IP rendered Television 

content and stream it to end-user devices using various delivery protocols, 

the required video/audio quality and the required video formats. 

B. Coverage/access to all authorised GSM service suppliers at authorised 

locations within the NNHQ building. 

C. Voice: Additional VoIP/PSTN/ISDN services that augment the NGCS 

Voice services. 

12.3.2-p4 The ANWI shall interface with the following external Active and Passive 

Building Facility Related Services (defined in Annex B): 

A. Cabling infrastructure will be provided by the PNWI, HN Belgium. It 

comprises of fibre and copper backbone. For more detail on the PNWI 

project cabling infrastructure, see Annex B. 

B. Racking and floor space will be provided by the PNWI. For more detail on 

the PNWI project racking infrastructure, see Annex B. 

C. Power/ cooling will be provided by the PNWI. For more detail on the PNWI 

project power/cooling facilities, see Annex B. 

D. The Audio Visual Infrastructure (AVI) that will be implemented by Host 

Nation Belgium, covers a broad range of technologies such as: 

presentation, conference and interpretation, broadcast and multi-media. 

Further details are in see Annex B. 





E. The other interface with the ANWI infrastructure is the video 

teleconferencing provisioning from the conference rooms to the desktops 

on demand. The AVI shall use the Storage Area Network (SAN) storage 

of the NS and Business networks for storing and archiving all video 

conferences. 

F. The ElectronicSecurity System (ESS) provides a campus-wide coverage 

throughsecurity cameras and other devices that keep track of events 

happening in and outside the building. An ESS viewer allows security 

personnel to watch any event from a workstation on the Business Network 

and take appropriate action if required. The ESS servers shall be installed 

on the Business Network and shall use its SAN storage for archiving and 

recovery. Further details are in Annex B. 

G. The Building Management System (BMS) keeps track of all technical 

related events in the building. It is connected to the building 

heating/cooling system and regulates the building power consumption. 

The BMS is connected to the ANWI and provides technical staff access to 

the BMS on workstations from anywhere in the building. The BMS servers 

shall be installed on the Business network and make use of the SAN 

storage. Further details are in Annex B. 

12.3.2-p5 The ANWI system shall interface with the following Business 

Application Services supported by the NNHQ O&M Authority: 

A. The Business Application are outside the scope of the ANWI project, 

however, they will make use of the ANWI services. 

B. Extranet Applications through extranet portals: There are a number of 

extranet portals that require ANWI connectivity in integration with ANWI 

services.An overview of the ICTM business application, including extranet 

portal is provided in Annex B. 

12.3.3 Cross Domain Gateways (CDGW) 

12.3.3-p1 To achieve the required cross domain services six Cross Domain 

Gateway (CDGW) capabilities have been identified that are visualised in figure 12.2 

and specified in table 12.1. 





Figure 12.2 Cross Domain Gateways 

CDGW # Interoperability Interface Operational Concept 

1 External: 

NS NS WAN 

Collaboration and information sharingat the NATO 

enterprise level in a federated way with NATO entities 

connected to the NS WAN. 

2 External: 

NR NR WAN 

NR NU WAN 

Internal via CDGW3: 

NR Public/INTERNET 

3 External: 

Public/CDGW2Public 

Networks/Internet 

Internal via CDGW3 

Business Public 

Networks/Internet 

4 Internal: 

NS EAPC 

This includes information sharing with NATO Nation 

SECRET (IEG B concept) and NATO Mission Secret (IEG 

C concept) where the NS WAN interconnection allows to 

interconnect with these gateways (i.e. IEG B and C). 

Collaboration and information sharing at the NATO 

enterprise level in a federated way. 

Interconnection with NATO wide NU and NR WAN. 

Interconnection via CDGW3 to exchange information with 

public (to include INTERNET and PUBLIC). 

Public Information Access for NATO HQ users as well as 

access from users on public networks to information and 

collaboration services made available to those CoIs by the 

use of Publishing or Extranet Web Site/Portal concepts. 

The service provided “over the Internet” is via a VPN for 

roaming users, remote users or offices (fixed device of 

LAN). 

Secure and controlled capability to automate release of 

information from the NS domain to the EAPC network 

users and enable EAPC SECRET message exchange 

through the registry. 





CDGW # Interoperability Interface Operational Concept 

5 Internal: 

NS Business 

Release and information sharing between the Business LAN 

which is planned to be the primary environment for day-today 

business and the NATO SECRET, the primary 

infrastructure for official document repositories, for various 

purposes. 

6 Internal: Public > NS Provision of information about CIS assets and services to 

the central integrated CIS management capability residing 

on the NS network. 

Table 12.1: ANWI Cross Domain Gateways (CDGW) 

12.3.4 ANWI NS Infrastructure System View 

12.3.4-p1 The first major infrastructure capability, the NS infrastructure and its 

substructures, is depicted in figure 12.3. The system architecture as shown in 12.3 

comprises the system view architecture for backend infrastructure. Extension of the 

infrastructure to the end points is covered by the LAN services as specified in chapter 

14 annex F. The infrastructure is redundantly spread over two in-building locations 

(server rooms and interfaces to the TCFs). 

12.3.4-p2 The system architecture view shows the following main elements: 

A. External Connectivity to the NGCS NS network. 

B. The following zones: 

1. EAPC LAN security domain used to host EAPC backend and user 

services. 

2. NS LAN security domain use to host NS backend and user services. 

C. The following Cross Domain Gateways: 

1. CDGW 1: Interconnection to the NS WAN. This Gateway support the 

following DMZ segments/zones: 

a. NS level front end (FE) DMZ for information sharing and federation (NS 

extranet) with other CoI’s through the NS WAN (interfaced via GW1). 

b. NS level backend (BE) DMZ services in support of the front end (user 

facing) NS extranet services (interfaced via GW1). 

c. NS authentication DMZ to support direct or federated authentication for 

external users to NS (DMZ) provided services. 

2. CDGW4: Interconnection of the NS LAN to/from the EAPC LAN, 





Figure 12.3: ANWI NS Level infrastructure system architecture view 

12.3.5 ANWI NU/NR/Public Level Infrastructure System View 

12.3.5-p1 The second major infrastructure capability, in support of the Business 

and Public LAN (at NR level and NU/Public level respectively) and its substructures, 

is depicted in figure 12.4. The system architecture as shown in 12.4 comprises the 

backend infrastructure. Extension of the infrastructure to the end points is covered by 

the LAN services as specified in chapter 14 annex F. The infrastructure is 

redundantly spread over two in-building locations (server rooms and interfaces to the 

TCFs). 





12.3.5-p2 The system architecture view shows the following main elements: 

A. External Connectivity to: 

1. The Internet via the PIA Gateway. 

2. The NGCS for: 

a. Interconnection to the NR WAN. 

b. Interconnection to the NU WAN. 

B. The following zones: 

1. NR LAN (business) security domain used to host Business backend 

and user services. 

2. Public (W)LAN security domain used to: 

a. Host Public backend and user services. 

b. Public WLAN extension to support WLAN access for mobile business 

users inside the building. 

C. The following Cross Domain Gateways: 

1. CDGW 2: Interconnection to the NR WAN (NR enterprise), NU (NU 

WAN) and PIA (via CDGW3). This gateway supports the following DMZ 

segments/zones: 

a. NU/NR level front end DMZ for information sharing and federation (NU 

extranet) with other CoI’s through the external networks (Internet, 

NGCS NU and NR WAN), interfaced via CDGW2). There will be 

multiple instances of this type of DMZ to support multiple CoI’s. 

b. NU/NR level backend DMZ services in support of the front end (user 

facing) NU/NR extranet services (interfaced via CDGW 2). 

c. Remote access DMZ to support VPN level interconnection for remote 

users/offices/sites. 

2. CDGW3: Interconnection to Internet/Public Networks utilising the PIA 

GW services in support of Internet access, Public Network Access and 

remote/mobile user/site VPN services. This gateway supports the 

following DMZ segments/zones: 

a. Public (non-classified) level Internet Publishing DMZ used to share 

information with the public communities. 

b. Public level Backend DMZ in support of the internet publishing DMZ 

services. 

c. Remote access DMZ supporting reachback. 





Figure 12.4: ANWI NR/NU/Public Infrastructure system architecture view 

12.3.6 NATO HQ NS to NU/NR/Public Cross Domain Infrastructure 

12.3.6-p1 Figure 12.5 shows the “shared” cross domain infrastructure that support 

information sharing across the two major infrastructures. 

12.3.6-p2 This system subview adds two more gateways use for internal NATO 

HQ interconnection purposes ONLY: 

A. Gateway 5, the NS NR gateway. This gateway support DMZ 

segment/zones both ways for providing access to NR and/or NS. 

B. Gateway 6, the Public to NS gateway for collecting management 

information from the Public LAN and consolidating that on the NS SMC 

capability. 





Figure 12.5: Cross domain infrastructure across the NS and NU/NR/Public 

infrastructures 

12.3.7 Cross Domain Gateway Coherency View 

12.3.7-p1 Annex E section 13.2.1 will take the architecture systems views as 

presented in 12.3.3, 12.3.4 and 12.3.5 forward and provide: 

A. more details on each of the individual cross domain gateway services, and 

B. provide the perspective of a consistent Cross Domain Module (CDM), see 

also section 12.4) that includes a uniform, flexible, scalable way of 

managing and expanding cross domain gateway services in two ways: 





1. providing additional gateways, 

2. Adding services to existing gateways. This view provides the holistic 

perspective on how all the GW are consistently managed and 

interconnected to the infrastructures, domains and zones. 

12.4 ANWI Modules and Internal Interfaces Identification 

12.4.1 ANWI Modules 

12.4.1-p1 To enable proper analysis and description of various services for the 

multiple networks within NNHQ and clearly identifying their interfaces with other 

entities, a module based definition of the required infrastructure and services is 

introduced in this section. The module concept introduces a container perspective 

that is valid for all infrastructures, security domains and zones. 

12.4.1-p2 The architecture is sub-divided into four major modules, used as logical 

groupings to achieve a structured approach. 

1) The Core AIS Module (CAM) providing core and infrastructure services. 

2) The Core AIS Client Module (CACM) end-user (client) core and 

infrastructure services. 

3) The Cross Domain and external network interfaces Module (CDM) providing 

the cross security domain services and interconnection to external 

networks. 

4) The Core Communications LAN Module (CCLM), providing the LAN 

services. 

5) In addition three more stand-alone type services are identified that are not 

logically bundled in a module but are connected to the ANWI modules as 

one-off services: 

6) GSM blocking 

7) WIFI blocking 

8) Site Security Communications 

12.4.1-p3 The ANWI Contractor shall follow the same modular approach while 

describing details of the design and implementation of ANWI. Modules and interfaces 

as identified in Annex D shall be referred to and worked out in more detail as part of 

the ANWI design creating a more detailed technical view of the system architecture 

views as presented in this Annex. As and when the contractor in his/her design 

decides to change or enhance the system view architecture a clearly written 

justification with attained design rationale shall be provided. 





Figure 12.6: ANWI Modules and information flows 

12.4.1-p4 Figure 12.6 provides an overview of the ANWI modules in action. It 

shows the ANWI modules and depicts the internal and external interfaces involved in 

information flows that traverse the ANWI infrastructure. The remainder of this section 

will identify and describe at a high level: 

A. Module scope and functionality. 

B. Inter module interfaces. 

12.4.1-p5 Section 12.5 will focus on specifying the external interfaces and section 

will 12.6 will complete the end-2-end flow description by listing the ANWI governed 

end-2-end (user level) services.The ANWI contractor shall be responsible for both 

the end-2-end design, testing and delivery of the ANWI governed end-2-end (user 

level) services in full cooperation of providers of services needed to achieve the end- 

2-end service. 

12.4.1.1 Core AIS Module (CAM) 

12.4.1.1-p1 The Core AIS Module (CAM) provides the architecture of the server 

and storage infrastructure for each of the four networks (NATO SECRET, EAPC 

SECRET, Business and Public). The module provides various interfaces to other 

modules and external interfaces that enable the use of infrastructure or core 

services. 

12.4.1.1-p2 

Figure 12.7 is an example for the NS CAM for the NNHQ. 





Figure 12.7: NS Network CAM 

12.4.1.1-p3 A combination of physical servers and virtualised servers, in a 

resilient configuration, spread over two server rooms shall be supported by a SAN 

structure, providing a high available, high capacity, flexible storage environment. 

12.4.1.1-p4 The servers shall be connected to the Network via the switches in 

the server room. More details are described in the Core Communications LAN 

Module (CCLM) paragraph. 

12.4.1.1-p5 Each of the other domains mayfollow the same layout as the NS 

domain and/or may be consolidated into NS/EAPC and NU/NR/Public infrastructure 

while complying with the NATO security regulation and proof TCO reductions. 

12.4.1.2 Core AIS Client Module 

12.4.1.2-p1 The role of the Core AIS Client Module (CACM) is to describe the 

approach to provide the client devices including voice clients. 

12.4.1.2-p2 The CACM shall provide end-users with sufficient client processing 

power to satisfy their business requirements. 

12.4.1.2.1 Client-Provisioning 

12.4.1.2.1-p1 The following ANWI client devices are identified: 

A. Fixed Desktop. 

B. Fixed Desktop Network Agnostic. 

C. Fixed Desktop High Performance. 

D. Thin Client 

E. Mobile (laptop/Tablet). 

F. VOIP phone. (Basic/Secretarial) 



G. Secure IP-phone. 

H. Smart phone/PDA. 



12.4.1.2.1-p 2 Any ANWI Client device proposed by the ANWI Contractor that 

matches with a client device, as listed below, shall comply with the requirements 

specified in the MHWPS (see 1.1.1.5.1) : 

A. Office Desktop PC, standard desktop for normal office workers. 

B. High Performance workstations used for applications that are processor 

intensive, e.g. CIS management workstations and INFOSEC management 

workstations. 

C. Laptop for mobile users. 

12.4.1.2.2 Client locations 

12.4.1.2.2-p1 NS users work on NS devices located in the HQ, or in remote 

offices (see Annex M). NR users work on NR devices in the HQ, or remotely on NR 

devices over the Internet. NATO Restricted over the Internet (NRoI) is an in-service 

solution for mobile users, using a NATO owned device and NR approved VPN to get 

(remote) access to NR network services. 

12.4.1.2.2-p2 

Other users to access NS devices on the HQ network are: 

A. NATO NS cleared personnel of other agencies/organizations where HQ 

NS devices are located and 

B. Non NATO, but NS cleared, personnel (nations or international 

organizations like the EU) working on HQ NS devices located at their 

offices. 

12.4.1.2.2-p3 The NRoI, or a comparable concept, shall be reused and where 

necessary be extended to provide reach-back capability to the users, within the 

limitations of client form factor, classification of the service, location of the user, and 

applicable IA restrictions. 

12.4.1.2.2-p4 The NRoI device shall be connected to the Public network when 

in the HQ Building, and use the NRoI Virtual Private Network (VPN) solution to 

access NR services. 

12.4.1.2.3 Computer Client Architecture 

12.4.1.2.3-p1 The CACM shall run on a passive network cabling infrastructure 

provided by the PNWI for the following three networks: NATO SECRET, EAPC 

SECRET and Business. 

12.4.1.2.3-p2 The Mobile (laptop) capability for the Business Network shall use 

wired or wireless network services and connect to the Business Domain via the 

public LAN security domain using a Secure VPN solution (NRoI). 

12.4.1.2.3-p3 Where possible, a desktop Keyboard, Video and Mouse (KVM) 

switch shall be used to reduce the number of screens and monitors on the desktop 

(the number of thin clients or PCs shall remain the same). 

12.4.1.2.3-p4 The ANWI Contractor shall follow SDIP-29/1 (see 1.1.1.3.3) 

installation guidelines regarding the physical separation of classified equipment. 




12.4.1.2.4 Conference Room Client Access Infrastructure 




12.4.1.2.4-p1 In the official conference and meeting rooms the ANWI 

Contractor shall implement network agnostic clients that can be connected to any 

network domain dependent on the classification of the conference or meeting. This 

holds for the presentation and conference support (interpreter) clients. 

12.4.1.2.4-p2 WLAN connectivity for mobile clients is available as and when 

the conference Authority is allowing wireless access, given the classification and 

sensitivity of the conference. 

12.4.1.3 Core Communication LAN Module 

12.4.1.3-p1 The Core Communication LAN Module (CCLM) shall provide 

connectivity between the devices located throughout the building as well as providing 

connectivity to outside networks, via the interface to Cross Domain Module (CDM). 

12.4.1.3-p2 CCLM also shall provide the network transport services for 

telephony and IPTV services throughout the buildings. 

12.4.1.3-p3 CCLM shall provide active infrastructure for the combination of 

multiple wired infrastructures based on Ethernet running over fibre or copper cables 

utilising and extending, where necessary, the cable infrastructure as provided as PFE 

(see Annex B) and wireless connectivity will be provided using 802.11 based 

networks that shall be connected to the wired network. 

12.4.1.3-p4 CCLM shall provide access to appropriate services for a given 

network classification. 

12.4.1.3-p5 CCLM implementation shall follow the NCIRC security guidance that 

allows, under certain conditions, for logical separation of networks (1.1.1.6.9) which 

allows for a certain level of ANWI infrastructure consolidation (see Annex F Appendic 

6). 

12.4.1.3-p6 AllLAN components provided by the ANWI Contractor shall adhere 

to the Bi-SC AIS Minimum Hardware Procurement Specifications (see 1.1.1.5.1). 

12.4.1.4 Cross Domain Module 

12.4.1.4-p1 

The cross domain module shall achieve three major functions: 

12.4.1.4-p2 Secure network connectivity and interconnections to networks or 

value added network services that are available via NATO wide network capabilities 

(NGCS) or via public networks. 

12.4.1.4-p3 Cross domain solutions to support secure information access and 

information sharing across the ANWI identified major infrastructure, security domains 

and zones. 

12.4.1.4-p4 An integrated, consistent, coherent, flexible and scalable 

management capability of the Cross Domain Gateways (CDGW) as identified in 

section 12.3 and all other cross domain solutions related to zoning. This will allow for 

a unified way of either locally or centrally manage cross domain functionality and 

consistent managed interfaces with NATO centralised Information Assurance 

services such as NCIRC, central Firewall Management and NPKI. Annex E, appendix



2, provides the specification of the CDM architecture and of the individual CDGW’s it 

is managing. 

12.4.2 ANWI Module Internal Interface Identification 

12.4.2-p1 Figure 12.8 shows the ANWI inter-module interfaces. The interface 

details are specified later on in this Annex. 

Figure 12.8: ANWI Inter-module Interfaces 

12.4.2-p2 Figure 12.8 shows the relationship within the various internal ANWI 

modules. The relationships are described in terms of the OSI model, where the 

green arrows represent the physical, the yellow the transport, and purple the service 

layer (representing the OSI session, presentation and application layers), 

respectively. 

12.4.2-p3 Table 12.2 describes the module high level interfaces at any of the 

three identified levels. In the remainder of this appendix as well as in the specification 

of each of the individual services more interface details are provided at either the 

information flow level (this appendix) or at the individual service interface level 

(Annexes E-I). 

# and description Physical Layer Transport Protocol Service Protocol 

1 CCLM-CACM Either copper RJ45 Layer 2-3 (Ethernet, - 

or Fiber connector IPv4, IPv6) 

2 CCLM-CAM Either copper RJ45 Layer 2-3 (Ethernet, CCLM management 

or Fiber connector IPv4, IPv6) 

information services 

3 CCLM-CDM Either copper RJ45 All allowed IP - 

or Fiber connector TCP/UDP ports 

IPv4/IPv6 

4. CAM – CDM - All allowed IP All ANWI services 

TCP/UDP ports that related to cross 

IPv4/IPv6 

domain end-to end 





# and description Physical Layer Transport Protocol Service Protocol 

information flows 

5 CAM- CACM - All allowed IP 

TCP/UDP ports 

IPv4/IPv6 

All ANWI 

infrastructure, UCC 

services 

Table 12.2: ANWI inter module interfaces 

12.5 External Interfaces 

12.5-p1 For each of the external entities as identified in section 12.2, the interfaces 

and interface standards are specified. 

12.5.1 Facility-Physical Interfaces 

12.5.1-p1 

The following figure identifies all ANWI physical external interfaces. 

Figure 12.9: ANWI Physical Interfaces 

12.5.1-p2 

The following table describes in more detail the physical interfaces: 





Interface Protocol Description Remarks 

PNWI-ANWI IPv4/MAC/SNMP Cabling and Intelligent Patching See description below 

DESK-ANWI - User desks See description below 

POW-ANWI - Power for all ANWI See description below 

COOL-ANWI - Cooling for ANWI components See description below 

RACK-ANWI - 19’ racks in server room, TERs, TCF See description below 

ESS-ANWI IPv4 Security camera connectivity, Building 

Access Card 

See description below 

BMS-ANWI IPv4 Building management connectivity See description below 

AV-ANWI IPv4 Audio Visual Infrastructure connectivity See description below 

Table 12.3: ANWI physical interfaces 

A. PNWI-ANWI: All passive cabling, both fibre and copper, will be provided 

by PNWI and are described in Annex B. All cabling in racks shall be 

provided by ANWI. All rack cabling on NS and EAPC classification 

networks shall be fibre (see 1.1.1.3.2), except for those cables located in 

class I security areas (copper). PNWI is managed through an Intelligent 

Patching capability that is integrated to ANWI at the LAN SMC level (See 

Annex B). 

B. DESK-ANWI: A desk outlet module will be included with every desk, with 

power, a copper RJ45 connector (for public/phone connectivity) and four 

(4) fibre connectors (See Annex B). ANWI shall provide the patch cords 

from the desk outlet to the device (connector types defined in Annex B.) 

C. POW-ANWI: All power in the server room (220v single phase or three 

phase high-voltage), TERs and in all other locations, including UPS and 

generator facilities, will be provided by the GCCproject and have Type E " 

French style CEE 7/5 Schuko plugs. The ANWI Contractor shall provide 

the server room power distribution scheme within the limitations of the 

server room’s maximum power capacity (see Annex B). 

D. COOL-ANWI: All cooling for the server rooms and TER’s equipment is 

provided by GCC, (see Annex B). 

E. RACK-ANWI: All racks will be 19” wide and 45U high, provided by the 

PNWI project. Racks will have an electronic access control system. Details 

of the system are provided in Annex B. 

F. ESS-ANWI: All security cameras are connected via ESS cabling to the 

Business network. All video data is stored on the Business network. 

Workstations to view ESS data are located on the Business network. Also 

the building access card, NPKI enabled, will be used by ANWI for user 

token based access to the different Networks. Details of the system are 

provided in Annex B. 





G. BMS-ANWI: All building management systems are connected to the 

Business network. All data is stored on the Business (NR) network. 

Workstations to view BMS data are located on the Business network. 

Details of the system are provided in Annex B. 

H. AVI-ANWI: All AVI conference facilities shall make use of ANWI services 

(such as processing, storage, network infrastructure) and also 

interconnect to NATO Wide VTC via NGCS. Details of the system are 

provided in Annex B. 

12.5.2 NS Infrastructure External/Internal Interfaces 

12.5.2-p1 In this section the service and protocol interfaces are listed for the two 

major domains on the NS infrastructure: NS and EAPC. 

12.5.2.1 NS Domain 

12.5.2.1-p1 

The following picture describes the interfaces of the NS Network. 

Figure 12.10: NS network interfaces 





12.5.2.1-p2 

NS Network: 

The following table describes in more detail the interfaces for the 

Flow 1/2 way Service Service name 

Supported 

Protocols 

Remarks 

NS-CDGW1 Two way NS-NPKI Authentication TBD NATO PKI 

Two way NS-NVTC VTC TBD NATO wide VTC 

Two way NS-NCIRC IDS TBD FW, IDS, IPS, DD 

Two way 

NS-SMC 

Two way NS-NSWAN Extranet 

Monitoring, Configuration 

Management, Software 

distribution, Service Desk 

SNMP, XML SQL, 

HTTP(S) 

HTTP(S), DNS 

Software distribution 

based on SCCM 

AIS services 

monitoring based on 

SCOM agents 

Two way NS-NDOM Windows AD LDAP Part of AIS SFSD 

Two way NS-NMSG Email, NMS SMTP, MMHS AIS email, NMS 

Two way NS-NEDS Directory Synchronisation LDAP Through AIS 

Two way NS-NSWAN NSWAN Extranet HTTP(S) Through AIS 

Two way NS-Roff Remote offices All ANWI services 

NS-CDGW4 Two way NS-EAPC Email SMTP Releasable to EAPC 

Two way NS-EAPC 

File 

CIFS, FTP, 

WebDAV 

Releasable to EAPC 

NS-CDGW5 One way NS-BUS Email SMTP Notification only 

CDGW4-NS One way EAPC-NS CIS Management XML 

CDGW5-NS One way BUS-NS CIS Management XML 

One way BUS-NS 

File 

CIFS, FTP, 

WebDAV 

One way BUS-BUS Email SMTP 

CDGW6-NS One way PUB-NS CIS Management XML 

NS-APP 

NS-XNET 

Two way 

Two way 

NNHQApplications 

NS Extranet 

See Annex B 

See Annex B 

Various protocols as 

identified in 

applications services 

list 

Various protocols as 

identified in 

applications services 

list 

Table 12.4: NS domain interfaces 

12.5.2.2 EAPC Domain 

12.5.2.2-p1 

The following picture describes the interfaces of the EAPC Network. 





Figure 12.11: EAPC domain interfaces 

12.5.2.2-p2 

EAPC Network: 


Flow 1/2 way Service Service name Supported Protocols Remarks 

EAPC- 

CDGW4 One way EAPC-NS CIS Management 

CDGW4- 

EAPC 

Two way NS-EAPC Email SMTP 

File Transfer (XML 

formatted), XML web 

services (messaging), 

SNMP 

Releasable to EAPC, labelled 

with attachments 

Two way NS-EAPC File CIFS, FTP, WebDAV Releasable to EAPC 

Table 12.5(a): EAPC network interfaces 

12.5.2.2-p3 GSM and WIFI blocking is not shown as a service interface since its 

intention is to ensure GSM and WIFI signals do not interfere with NS domain 

services. 

12.5.3 Business Infrastructure External Interfaces 

12.5.3-p1 This section will specify the services and protocol interfaces for the two 

key user domains in the business infrastructure: NR domain and Public Domain 





12.5.3.1 NR Domain 

12.5.3.1-p1 The following picture describes the interfaces of the NR domain. 

Figure 12.12: Business network interfaces 

12.5.3.1-p2 

NR domain: 



BUS-CDGW2 Two way BUS-CVO Telephony 

POTS, ISDN, VOIP, 

PLAR 

Commercial voice 

Two way BUS-NVO Telephony VOIP, PLAR NATO voice 

Two way- BUS-GSM GSM Voice/SMS/MMS Integrate with UCC service 

Two way BUS-INT Internet browsing HTTP(S), DNS InternetNRWAN/NUWAN 

Two way BUS-INT Extranet HTTP(S), DNS Via CDGW3 

Two way BUS-NGCS Extranet HTTP(S), DNS NU WAN and NR WAN 

Two way BUS-Roff Remote offices VPN User Type U8a 

Two way BUS-Eusr External users VPN User Type U7a 

Two way BUS-NEDS NR NEDS LDAP 

Two way BUS-NMSG NR Email SMTP 

Two way 

Two way 

BUS-DOM Windows AD LDAP 

BUS-SMC 

Monitoring, 

Configuration 

Management, 

Software distribution, 

Service Desk 

SNMP, XML SQL, 

HTTP(S) 

Part of NATO enterprise NR 

SFSD 

Software distribution based on 

SCCM 

AIS services monitoring based 

on SCOM agents 






Two way BUS-NCIRC Management TBD FW, IDS, DDD 

Two way BUS-NPKI Authentication TBD 

Two way BUS-NTVC VTC TBD 

CDGW2-BUS One way IPTV-BUS IPTV TBD IPTV->CD3->CD2->NR 

BUS-CDGW5 

One way BUS-NS CIS Management 




SNMP 

One way BUS-NS File CIFS, FTP, WebDAV 

One way BUS-NS Email SMTP 

CDGW5-BUS One way NS-BUS Email XML Notification only 

BUS-APP Two way - NNHQApplications See Annex B 

BUS-XNET Two way - 

BUS-WLAN 

NR Extranet 

NU Extranet 

- - WLAN WIFI 

See Annex B 

Table 12.5(b): Business network interfaces 

Various protocols as identified 

in applications services list 

Various protocols as identified 

in applications services list 

Combined with Public WLAN 

to achieve Business Network 

Access based on VPN 

12.5.3.2 Public Domain 

12.5.3.2-p1 

The following picture describes the interfaces of the Public Domain. 

Figure 12.13: Public network interfaces 





12.5.3.2-p2 

Public Network: 



PUB-CDGW6 

One way PUB-NS CIS management 




SNMP 

PUB-CDGW3 Two way PUB-INT Internet HTTP(S), SMTP, DNS 

Two-way 

Two way 

PUB-BUS 

PUB-NCIRC 

Management 

Two way PUB-CVO Comm. voice 

CDGW3-PUB One way IPTV-PUB IPTV TBD 

CDGW3-PUB One way 

Internet 

Publishing 

SMTP, File, HTTP 

POTS, ISDN, VOIP, 

PLAR 

No user info exchange but in 

support of support to the public 

domain 

Central Mgmt FW, IDC, DD, 

works via Business Domain 

NATO TV distribution to Public 

networks 

Web publishing HTTP(S), DNS NATO public websites 

Table 12.6: Public network interfaces 

12.5.3.2-p3 GSM and WIFI blocking is not shown as a service interface since its 

intention is to ensure GSM and WIFI public signals are blocked in areas where Public 

network access is not authorised. 

12.6 End to End Services 

12.6-p1 The following table describes the services of the ANWI project. The table 

basically is a list of ANWI services and their position in the end to end services chain. 

12.6-p2 The information provided in the table can be read as follows: 

FROM and TO fields are the two endpoints of the service flow. 

1or2 WAY field identifies if the flow is restricted to one way or not. 

GW field identifies the Cross Domain Gateway elements that need to be part 

of the flow. 

EXTERNAL SERVICE field identifies any external service dependencies for 

the flow. 

A yellow line means the functionality is still in question, or is available, but in a 

different form than the other solutions. 

User 

Services 

From 1/2 way GW To Provider External service Remarks 

Processing - - - PUBLIC PNWI 

- - - NR PNWI 

- - - EAPC PNWI 

- - - NS PNWI 



Processing 

backend for 

PUBLIC 

Processing 

backend for NR 

Processing 

backend for 

EAPC 

Processing 

backend for NS



User 

Services 


Storage - - - PUBLIC PNWI 

- - - NR PNWI 

- - - EAPC PNWI 

- - - NS PNWI 

Printing - - - PUBLIC 

- - - NR 

- - - EAPC 

- - - NS 

NR > CDGW5 NS ANWI 



Central Storage 

for PUBLIC 


for NR 


for EAPC 


for NS 

Printing service 

for PUBLIC 


for NR 


for EAPC 


for NS 

AD synch NR WAN CDGW2 NR ? NR Domain 

federated or 

single domain 

structure 

NS WAN CDGW1 NS NCIA Bi-SC AIS 

federated or 

single domain 

structure 

LAN - - - PUBLIC PNWI 

Mainly WLAN 

based 

- - - NR PNWI (W)LAN 

- - - EAPC PNWI LAN 

- - - NS PNWI LAN 

Email NR - NR ANWI - 

NRWAN CDGW2 NR ? NATO NR mail 

NR CDGW3 Internet NGCS PIA gateway 

NR > CDGW5 NS ANWI - 

NS - NS ANWI - 

NSWAN CDGW1 NS NCIA Bi-SC AIS 

EAPC - EAPC ANWI - 

NS CDGW4 EAPC ANWI - 

NS > CDGW5 NR ANWI - 

IM NS - NS ANWI - 

Email within 

ANWI NR 

Email between 

ANWI NR and 

NATO Federated 

NR 

Email between 

ANWI NR and 

Internet Via 

CDGW2 - 

>CDGW3 

One way e-mail 

from NR to NS 

Email within 

ANWI NS 

Email between 

ANWI NS and 


NS 

Email within 

ANWI EAPC 

Email between 

ANWI NS and 

ANWI EAPC 

Email 

NOTIFICATIO 

N ONLY from 

ANWI NS to 



Internal



User 

Services 



NR - NR ANWI - 

NRWAN CDGW2 NR ? NRNRWAN 

NU - NU ANWI - 

Voice NR - NR ANWI 

PUBLIC CDGW3 NR ANWI 

NATO CDGW3 NR NGCS - 

NR > CDGW3 external NGCS - 

NATO CDGW3 NU NGCS - 

PUBLIC > CDGW3 external NGCS - 

NR CDGW3 external Commercial - 

PUBLIC CDGW3 external Commercial - 


federated or 

Single Domain 

NS 


Internal 

ANWI NR to 

federated or 

Single Domain 

NR 

NU extranet portalbased 

IM 

(EIM/ERP) 

VOIP on NR 

BUS to BUS soft 

clients 

VoIP session 

between ANWI 

PUBLIC to 


(From CDGW3 

to CDGW2 to 

NR) 

VoIP session 

between NATO 

VoIP Networks 

to ANWI NR 

(From CDGW3 

to CDGW2 to 

NR) 

VoIP session 

between External 

Networks to 


(From CDGW3 

to CDGW2 to 

NR) 

VoIP session 

between NATO 

Networks / 

ANWI NU 

VoIP session 

between External 

Networks to 

ANWI PUBLIC 

Commercial 

Backup Route 

for Above NGCS 

link 

Commercial 

Backup Route 

for Above NGCS 

link 

Fax NS CDGW1 NSWAN - UCC integrated. 

NR CDGW3 external Commercial - 

UCC integrated, 

via CDGW2 - 

>CDGW3. 

NU CDGW3 external Commercial - UCC integrated. 

VTC/VMR NSWAN CDGW1 NS NGCS NATO Wide VTC 

VTC session btw 

ANWI and NATO 

Wide VTC 





User 

Services 


Services NRWAN CDGW2 NR NGCS NATO Wide VTC 

NUWAN CDGW3 NU NGCS NATO Wide VTC 

NSWAN CDGW1 AVI NGCS NATO Wide VTC 

NRWAN CDGW2 AVI NGCS NATO Wide VTC 

NUWAN CDGW3 AVI NGCS NATO Wide VTC 

NS - NS HN BE AVI 

NR - NR HN BE AVI 

NU - NU HN BE AVI 

NR NR 




Wide VTC 



Wide VTC 


AVI and NATO 

Wide VTC 



Wide VTC 



Wide VTC 


ANWI and AVI 

endpoints 



endpoints 



endpoints 

VTC session 

within ANWI end 

points 

VTC session 

within ANWI 

endpoints 

UM NS - NS ANWI - ANWI Internal NS 



NRWAN CDGW2 NR ? NRNRWAN 


Presence NS - NS ANWI - 

NSWAN CDGW1 NS NGCS NSNSWAN 


NRWAN CDGW2 NR NGCS NRNRWAN 

Collaboration NS - NS ANWI - 

NSWAN CDGW1 NS NGCS NSNSWAN 


NRWAN CDGW2 NR NGCS NRNRWAN 

From federated / 

single domain NS 

to ANWI NS 

ANWI Internal 

NR 

From federated / 

single domain NR 

to ANWI NR 


UM 

(EIM/ERP) 


Internal 


federated or 

single domain 

NS 


Internal 


federated or 

single domain 

NR 


Internal 


federated or 

single domain 

NS 


Internal 


federated or 

single NR 





User 

Services 

UCC 

Directory 




NRWAN CDGW2 NR ? NATO NR mail 

NR CDGW2 PUBLIC ANWI - 



NUWAN CDGW2 PUBLIC NCIA Bi-SC AIS 

PUBLIC - PUBLIC ANWI 

NS > - EAPC ANWI 

IPTV - > CDGW3 PUBLIC Commercial - 

- > CDGW3 NR Commercial - 

File services NR > CDGW5 NS ANWI - 

File 

Transfer 

Event 

Logging/Mo 

nitoring 

Remote 

users 

NS > CDGW4 EAPC ANWI - 

NU > CDGW6 NS ANWI 

NR > CDGW5 NS ANWI 

EAPC > CDGW4 NS ANWI 

NR external CDGW3 NR NGCS PIA gateway 




coll. 

(EIM/ERP) 

UCC Directory 

to support ANWI 

NR 

Directory 

Exchange 


NR and NATO 

Federated NR 

Directory 

Exchange 


NR and ANWI 

PUBLIC (via 

CDGW3) 

UCC Directory 


NS 

Directory 

Exchange 


NS and NATO 

Federated NS 

Directory 

Exchange 


PUBLIC and 


NU (via 

CDGW3) 

UCC Directory 


PUBLIC 

UCC Directory 


EAPC 

One way flow 

from provider to 


One way flow 

from provider to 

ANWI NR( via 

CDGW2) 

File transfer 

between NS and 

NR 

One way file 

transfer from NS 

to EAPC 

Based on 

XMLfile 

transfer, 

messaging and 

SNMP 

From CDGW3 to 

CDGW2 to NR



User 

Services 


Offices NS external CDGW1 NS NGCS 

Browsing PUBLIC CDGW3 Internet NGCS PIA gateway 

NR CDGW2 

Internet 

Publishing 

ANWI 

NR CDGW3 NUWAN NGCS 

Via PIA 

NR CDGW3 Internet NGCS PIA gateway 

NR CDGW2 NU Extranet ANWI 

NR CDGW2 NR Extranet ANWI 

NR CDGW2 NRWAN NGCS 

NS CDGW1 NSWAN NGCS 

NS CDGW1 NS extranet ANWI 

NS > CDGW4 EAPC ANWI 

1 through NATO approved/provided NR access mechanisms 

Table 12.7: End to End services 

Exceptional 

cases. 


browsing to 

Internet 


browsing ANWI 

Internet Site (via 

CDGW3) 


browsing to 

NUWAN (Via 

CDGW2) 


browsing to 

Internet (Via 

CDGW3 to 

CDGW2 to NR) 


browsing to 

ANWI NU 

Extranet (Via 

CDGW3) 


browsing to 


Extranet 


browsing to 

NRWAN 


browsing to 

NSWAN 


browsing to NS 

Extranet 




SECTION 13. ANNEX E: SMC and IA SERVICES 

13.1 Appendix 1: Service Management and Control 

13.1.1 Definition 


13.1.1-p1 Service Management and Control (SMC) is used in this SOW to define 

the capability and processes needed to manage the life-cycle and support the 

delivered ANWI services. 

13.1.2 Scope 

13.1.2-p1 The ANWI Contractor shall deliver a SMC suite of tools supporting the 

following ITIL ® Processes: 

A. Service Design processes: 

1. Service Level Management 

2. Capacity Management 

3. Availability Management 

4. Service Catalogue Management 

5. Continuity Management 

6. Information Security Management 

B. Service Transition processes: 

1. Change Management 

2. Service Asset Management 

3. Configuration Management 

4. Release Management 

5. Knowledge Management 

C. Service Operations processes: 

1. Event Management 

2. Incident Management 

3. Problem Management 

3. Request Fulfilment 

4. Access Management 

D. Continuous Service Improvement processes: 

1. SLA Reporting 

2. Service Measurement. 

13.1.2-p2 The ANWI Contractor shall provide ITIL v3 based tools supporting these 

lifecycle management processes. 

13.1.2-p3 Figure 13.1 shows the SMC service mapping to the services taxonomy 

(as introduced in Annex C) as a vertical capability (supported by tools) that 

interfaces, monitors, supports and reports on the suite of ANWI services. 

13.1.2-p4 Each ANWI service identifies specific ELement Management (ELM) 

services in support of day-to-day operation and configuration/deployment. 

13.1.2-p5 

SMC delivers the capability to manage end to end service provisioning. 

13.1.2-p6 SMC includes the portfolio of end-user and internal services throughout 

their life-cycle. 





13.1.2-p7 The ANWI service portfolio and service catalogue are key authoritative 

information sources for the definition of these services. 

Figure 13.1: SMC services mapped to the Services Taxonomy 

13.1.2-p8 The ANWI Contractor shall procure the needed tools, document the 

processes and implement tools for the above ITILv3 processes as part of the SMC. 

13.1.2-p9 

The Purchaser will review the SMC processes for acceptance. 

13.1.2-p10 The ANWI Contractor shall provide: consolidated service monitoring 

information gathering and visualization (i.e. dashboard), detailed monitoring 

information gathering and visualization and periodic or request triggered reporting 

capabilities for the NNHQ O&M Authority and Purchaser use. The above shall be 

provided by the ANWI Contractor regardless of the service delivery model. 

13.1.3 Governance 

13.1.3-p1 

The Purchaser will establish a SMC governance board for the NNHQ. 



13.1.3-p2 

Authority. 





The SMC governance board will be chaired by the NATO O&M 

13.1.3-p3 The HQPO, local NNHQ ICT staff, and Purchaser will be members of 

the SMC governance board. 

13.1.3-p4 The ANWI Contractor and ANWI IV&V shall be members of the NNHQ 

SMC governance board through FSA. 

13.1.4 Architecture 

13.1.4.1 Architecture Requirements 

13.1.4.1-p1 The SMC covers the full range of automated information systems 

(AIS), communication services, networks, building management system (BMS), etc. 

Management systems shall be provided for all services, components, and elements 

that can be managed. 

13.1.4.1-p2 AIS, service, network, and element management shall be 

centralized to the extent possible. A protected management network shall be 

provided in each security domain. This management network must allow local 

management (within the HQ) and remote support management by NCIA for the 

components that are centrally managed by NCIA , and remote from an external 

location to be determined following a disaster recovery. 

13.1.4.1-p3 The SMC shall use a centralized Integrated Operation Support 

System (IOSS), located in a protected (at least by the firewall) management network 

in the NS security domain, providing aggregation, correlation, and de-duplication of 

events. Also providing root cause analysis and visualization of the global service 

status, root-cause analysis of incidents, and centralized control and centralized 

configuration management. 

13.1.4.1-p4 The SMC shall use reporting, monitoring and tracking automation to 

the maximum extend feasible. Critical configuration changes shall require human 

authorizations. Risk assessment may allow a limited set of automatic automated 

configuration changes to take place. 

13.1.4.1-p5 Each security domain requires dedicated AIS/service management 

and dedicated N/ELM system(s) for networking, communication, IT service and other 

services components. 

13.1.4.1-p6 The AIS/service manager and the N/ELM in the different security 

domains shall report to the central IOSS. 

13.1.4.1-p7 The SMC shall have complete N/ELM and AIS/service management 

capability on NS network. 

13.1.4.1-p8 The SMC shall have basic N/ELM and AIS/service management 

capability monitoring and reporting on the EAPC network. 

13.1.4.1-p9 The SMC shall have complete N/ELM and AIS/service management 

capability in Business network. 

13.1.4.1-p10 The SMC shall have basic N/ELM and AIS/service management 

monitoring and reporting capability on the Public network.





13.1.4.1-p11 All SMC N/ELM components shall provide a ‘north bound’ interface 

to the central IOSS (located in NS security domain in Mons). 

13.1.4.1-p12 SMC components (N/ELM, AIS/service managers, IOSS) shall be 

integrated through the SMC enterprise service bus (ESB) infrastructure. All N/ELM 

and AIS/service management components shall have a documented and open 

interface towards the SMC ESB. (E.g. using web-services, JMS, SOAP, etc.). 

13.1.4.1-p13 The SMC ESB shall be based on open standards like Multi- 

Technology Operations System Interface (MTOSI), Operations Support System 

through Java Initiative (OSS/J), eXtensible Markup Language (XML). 

13.1.4.1-p14 Management systems that require a database capability shall use a 

SQL database (with an open API) as the database backend, have the database 

model described/available, allow exploitation of the data store for future integration 

efforts. 

13.1.4.1-p15 All management systems shall be accessible through the SMC ESB 

allowing future integration with future SMC systems/components if and when 

required. 

13.1.4.2 Protocol Requirements 

13.1.4.2-p1 The IOSS shall use open interfaces like web-services, JMS or 

SOAP allowing integration, through an enterprise services bus, with 3rd party 

systems and automation through external 3rd party workflow engines, allowing 

control and information import and export. 

13.1.5 Installation 

13.1.5-p1 The ANWI Contractor shall install the SMC ELM services on the 

delivered ANWI services to support monitoring the service’s Service Level Targets 

(SLTs). 

13.1.5-p2 The specific CoI SMC services shall be provided on all 4 networks – 

NATO SECRET, EAPC SECRET, BUSINESS and PUBLIC. 

13.1.5-p3 The ANWI Contractor shall install the ANWI’s Service Management 

console, central information management and SMC reporting capabilities on the 

ANWI’s NS network. 

13.1.5-p4 The ANWI Contractor shall install service element managers on each of 

the other networks (EAPC, Business and Public) and ensure that their 

monitoring/reporting output is routed through the ANWI Cross Domain Gateways to 

the NS’ Service management console. 

13.1.5-p5 The ANWI Contractor shall configure the SMC to ensure that the NATO 

O&M Authority can provide: remote device management; remote asset/configuration 

management querying and Service Level Agreement (SLA) monitoring. 

13.1.5-p6 The ANWI Contractor shall configure the SMC to provide trouble ticket 

escalationis reported (up) to the NATO O&M Authority. 

13.1.5-p7 The ANWI Contractor shall configure the SMC to provide 

asset/configuration management information (up) to the NATO O&M Authority.





13.1.5-p8 The ANWI Contractor shall ensure that the NATO O&M Authority is able 

to remotely monitor and manage CDGW and other IA devices. 

13.1.6 Service Desk 

13.1.6-p1 The ANWI Service Desk shall provide Service Desk staff access to all 

SMC processes and tools. 

13.1.6-p2 The ANWI Contractor provided Service Desk Software shall have an 

overview of the user environment and can easily prioritize requests based upon 

urgency, priority and impact on the user. 

13.1.6-p3 The Service Desk shall serve as the single point of contact for all 

inquiries on ICT for all users for all networks and services. 

13.1.6-p4 The Service Desk shall use a service desk application to provide 

service desk functionality. The selected service desk application must support the 

ITIL service management framework at time of deployment. 

13.1.6-p5 The Service Desk shall be the user interface for all queries on and 

administering all software licenses and service contracts. 

13.1.6-p6 

13.1.6-p7 

The central Service Desk IT infrastructure is located in the NS network. 

The Service Desk shall support incident and availability management. 

13.1.6-p8 The Service Desk shall support a knowledge base populated by the 

designers and operators. 

13.1.6-p9 

13.1.6-p10 

13.1.6-p11 

management. 

13.1.6-p12 

CMDB. 

The Service Desk shall support asset management. 

The Service Desk shall support change management. 

The Service Desk shall support routine/day-to-day service 

The Service Desk application(s) shall interface with the central 

13.1.6-p13 The Service Desk infrastructure shall provide an interface for 

financial management of CIS services. 

13.1.6-p14 The Service Deskshall use automation where feasible. The service 

desk application(s) shall be integrated with the rest of the SMC infrastructure through 

the management ESB. 

13.1.6-p15 The Service Desk shall interoperate with NCIA’s central Service 

Desk tool (currently BMC express) for escalation and/or receiving trouble tickets.. 

13.1.7 Trouble Ticketing 

13.1.7-p1 

the SMC. 

The ANWI Contractor shall provide a trouble ticketing system as part of 

13.1.7-p2 The ANWI Contractor’s tool shall log, categorise and prioritise work 

tickets for action. 

13.1.7-p3 The Service Desk staff can, via email notification, assign and reassign 

work orders to support staff on the NS and Business domains.

13.1.7-p4 

from users. 





The ANWI Contractor’s tool shall capture ticket closure after verification 

13.1.7-p5 The ANWI Contractor’s tool shall launch a feedback (via short survey) 

from the user to measure user satisfaction. 

13.1.7-p6 

portal. 

The ANWI Contractor’s tool shall be integrated with the self-service 

13.1.7-p7 Self-Service Portal shall provide: 

A. User trouble ticket creation for either incident or request templates 

B. Status tracking capability to view trouble tickets 

C. User password changes without a trouble ticket 

D. Workflow tracking 

E. Self Help Portal for users 

F. Knowledgebase access 

G. Integration with SMC processes 

13.1.7-p8 Email integration (for notifications to the user of trouble ticket resolution, 

trouble ticket state change or trouble ticket escalation) shall be supported. 

13.1.8 Performance Management 

13.1.8-p1 The ANWI Contractor shall provide a tool to monitor the performance of 

delivered ANWI services. 

13.1.8-p2 The ANWI Contractor shall monitor the performance of each service 

and virtual server suite provided under the infrastructure service. 

13.1.8-p3 The AIS monitoring manager shall use a separate reporting service to 

render service performance reports, using a specific reporting tool. 

13.1.8-p4 

statistics. 

The SMC shall collect, display and store network and service usage 

13.1.8-p5 The SMC shall collect, display and store KPI/KQI statistics from internal 

and external services. 

13.1.8-p6 Collected usage, KPI, and KQI statistics shall be analysed for use in 

resource planning and SLA management. The infrastructure shall provide automated 

reports for this purpose and shall allow ad-hoc reports allowing for further analysis. 

13.1.9 Service Design Processes 

13.1.9.1 Service Level Management (SLM) 

13.1.9.1-p1 The ANWI Contractor’s SLM delivered process shall define and 

document the SLA framework for monitoring, measuring, reporting and reviewing of 

provided ANWI services to ensure SLTs and SLAs are met. 

13.1.9.1-p2 The ANWI Contractor’s SLM delivered process shall ensure that the 

specific ANWI service targets are identified and monitored and measurable for all 

services. 

13.1.9.1-p3 The ANWI Contractor’s SLM delivered process shall be used to 

monitor service performance against SLAs.





13.1.9.1-p4 The ANWI Contractor’s SLM delivered process shall check that the 

service catalogue information presents users with clear information on the level of 

service to be delivered with every service catalogue item. 

13.1.9.1-p5 The ANWI Contractor’s SLM delivered process shall identify cost 

effective proactive measures to support improving the implemented ANWI delivered 

service levels. 

13.1.9.1-p6 The ANWI Contractor’s SLM process shall capture and analyse 

service metrics for use in the creation of service level reports. 

13.1.9.1-p7 The ANWI Contractor’s SLM tool shall be used to create, monitor 

and track customer satisfaction and the quality of the delivered service via user 

surveys. 

13.1.9.1-p8 The ANWI Contractor’s SLM delivered process shall be used as the 

framework to conduct service reviews and initiate service improvements. 

13.1.9.1-p9 The ANWI Contractor’s SLM delivered process shall be capable to 

diversify SLM for different communities and users and fully aligned with the billing 

functions. 

13.1.9.2 Capacity Management 

13.1.9.2-p1 The ANWI Contractor shall deliver a capacity management process 

with supporting tool to manage the capacity of the ANWI’s ICT resources. 

13.1.9.2-p2 The ANWI Contractor shall produce and maintain an appropriate 

and up-to-date capacity plan, which reflects the current and future needs of the 

NNHQ ANWI. 

13.1.9.2-p3 ANWI routine KPI and KQI compliance status shall be reported 

every 24 hours to the SMC. 

13.1.9.2-p4 The ANWI Contractor shall deliver a capacity management process 

where the user experience is monitored using network traffic and network health 

status monitoring (may include passive and active measurements) and reported to 

the SMC . 

13.1.9.2-p5 The Service Desk shall provide automated KPI and KQI routine and 

on-demand performance reporting. 

13.1.9.2-p6 The ANWI Contractor’s capacity plan and implementation shall 

ensure proper provisioning of sufficient IT resource capacity for the immediate need; 

provide the ability to expand to proactively address growth while managing demand; 

address the strategy for long term capacity through the end of the 5 year life cycle 

and how capacity will capitalise on the technological evolution during the life cycle 

period. 

13.1.9.2-p7 The ANWI Contractor’s capacity plan and implementation shall 

support user and ANWI service capacity and performance related issues 

13.1.9.2-p8 The ANWI Contractor’s capacity management tool shall monitor the 

capacity, growth and performance ensuring that service performance parameters of 

the ANWI service SLAs meet or exceed all of their agreed performance targets, by 

managing the performance and capacity of both services and resources



13.1.9.2-p9 The ANWI Contractor’s capacity management tool shall support the 

diagnosis and resolution of performance and capacity related incidents and 

problems. 

13.1.9.2-p10 The ANWI Contractor’s capacity management tool shall support the 

analysis and impact of all changes on the capacity plan, and the performance and 

capacity of all services and resources 

13.1.9.2-p11 The ANWI Contractor’s capacity management tool shall provide 

monitoring patterns of capacity activity and the SLM plan 

13.1.9.2-p12 The ANWI Contractor’s capacity management process shall, for 

each Service/ SLA identify the agreed capacity and performance levels and for each 

identify the current usage or demand (e.g. measured transaction volumes) against 

the agreed usage levels; provide a trend analysis; identify the expected demand 

increase or decrease for the services 

13.1.9.2-p13 The ANWI Contractor’s capacity plan shall identify the decision 

points and metrics to decide which components need to be upgraded and at what 

time 

13.1.9.3 Availability Management 

13.1.9.3-p1 The ANWI Contractor shall provide an availability management 

process with supporting tool to monitor, measure, analyse, report and manage the 

ANWI components’ availability 

13.1.9.3-p2 The ANWI Contractor’s availability management process and 

supporting tool shall provide unavailability analysis 

13.1.9.3-p3 The ANWI Contractor availability management process shall use 

proactive activities to ensure the agreed ANWI level of service availability 

13.1.9.3-p4 The ANWI Contractor’s availability management process shall 

support availability input to SLA reporting 

13.1.9.3-p5 The ANWI Contractor’s availability management process and 

supporting tool shall address monitoring and reporting of redundant service solutions 

13.1.9.3-p6 The ANWI Contractor’s availability management tool shall support 

the failure impact analysis of ANWI components/services. 

13.1.9.3-p7 The IOSS shall receive services status change notifications from 

external service providers (service available/unavailable, KPI/KQI threshold 

reached). 

13.1.9.4 Service Catalogue Management 

13.1.9.4-p1 

The ANWI Contractor shall implement a service catalogue. 

13.1.9.4-p2 The ANWI Contractor’s service catalogue shall be a local e- 

commerce application populated with the ANWI services (and expandable to support 

business applications and other future NATO services) so that users are able to raise 

new service requests. 





13.1.9.4-p3 The ANWI Contractor’s implemented service catalogue shall be role 

based, so that a user logs in and based on his/her role has access to their 

configuration and is able to request an update of their capabilities and/or components 

13.1.9.4-p4 The ANWI Contractor shall implement a workflow in the service 

catalogue that flows from requestor, to supervisor, to fund approver/releaser, 

ordering, and appropriate service managers to accommodate technical scope (sizing, 

performance, capacity, LAN, cabling, etc.) 

13.1.9.4-p5 The ANWI Contractor’s implemented service catalogue shall be web 

based Windows oriented GUI that is intuitive to end users and shall be menu driven 

based on a taxonomy developed by the ANWI Contractor which considers users 

groups, roles and requirements (e.g. a normal user on EAPC will only see EAPC 

offered services and options). 

13.1.9.4-p6 The ANWI Contractor’s service catalogue shall provide a user a 

transparent view of available services categories and options 

13.1.9.4-p7 The ANWI Contractor’s implemented service catalogue shall 

monitor trends in ordering and trace delivery time 

13.1.9.4-p8 The ANWI Contractor’s service catalogue shall permit a user to 

track/monitor the state of their request from submission through approval and 

ordering to fulfilled or denied 

13.1.9.4-p9 The ANWI Contractor’s service catalogue shall clearly identify for 

each service item: description, options, costs, conditions, and support services 

(appropriate SLAs) 

13.1.9.5 Continuity Management 

13.1.9.5-p1 The ANWI Contractor shall implement a continuity process that is 

documented in the SMC’s continuity management plan 

13.1.9.5-p2 The ANWI Contractor’s continuity management plan shall be used 

to manage the risk of a disaster event so that the ANWI services are offered at an 

agreed minimum level and support the recovery operation. 

13.1.9.5-p3 The ANWI Contractor’s continuity management plan shall address 

backup and recovery strategy, as well as address failover technologies used. 

13.1.9.5-p4 The ANWI Contractor shall ensure that the SMC information store’s 

underlying databases (CMDB, Asset Management) are highly-available across both 

server rooms. 

13.1.9.5-p5 The ANWI Contractor shall ensure that all SMC data is kept in 

synch for the SMC in both server rooms so that in the case of a server room failure 

the surviving server room SMC information store can continue the service without 

data loss. 

13.1.9.5-p6 The ANWI Contractor shall, as part of the SMC information lifecycle, 

ensure that management data and supporting storage solutions include data 

and information backup strategies to safeguard the information and data against 

catastrophic events. 







13.1.9.5-p7 The ANWI Contractor shall, as part of the SMC information lifecycle, 

ensure that management data and supporting storage solutions include data 

and information backup strategies to safeguard the information and data for long 

term data backup and archival. 

13.1.9.5-p8 The SMC information life-cycle shall support the following metrics, 

in-line with the critical function of SMC: 

13.1.9.5-p9 

13.1.9.5-p10 

13.1.9.5-p11 

13.1.9.5-p12 

process. 

RTO: 30 minutes. 

RPO: 30 minutes. 

Information Security Management 

The ANWI Contractor shall implement an information security 

13.1.9.5-p13 The ANWI Contractor’s information security process shall provide 

access requesting, detection and reporting utilities 

13.1.9.5-p14 The ANWI Contractor’s information security utility shall log, 

categorise and prioritise access requests based on user support profile 

13.1.9.5-p15 The ANWI Contractor’s information security utility shall trigger and 

provide input to other SMC processes 

13.1.9.5-p16 The ANWI Contractor’s information security access process shall 

log requests, track fulfilment and closure; this can be supported by another process 

or tool 

13.1.9.5-p17 The ANWI Contractor’s information security process shall evaluate 

Access Requests to determine if they are likely to reoccur 

13.1.9.5-p18 

Security management shall be an integral part of the SMC. 

13.1.9.5-p19 SMC shall make use of NATO PKI to support the required Identity 

and Access management security mechanisms. 

13.1.9.5-p20 The SMC shall use centralized authentication, authorization and 

accounting (AAA) to consoles, clients and network elements. 

13.1.9.5-p21 AAA, in support of SMC, shall be centralized through a directory 

service synchronized with the enterprise directory service information. 

13.1.9.5-p22 Management systems shall be installed on a separate zone 

ensuring protection against unauthorized access from the user domain. 

13.1.9.5-p23 BPS systems shall be managed centrally from NCIA but a local fall 

back capability (physical access to devices) shall be provided. 

13.1.9.5-p24 Management of BPS systems shall be done from the internal or 

high side (where possible, via dedicated network interface) and shall be restricted to 

management systems in the management network only. 

13.1.9.5-p25 Intrusion detection/prevention system (ID/PS) management is 

provided by NCIRC – see section 13.2.4. ArcSight Connectors collect events from 

different products/sensors (e.g. firewalls, network and host based-IDS/IDP) and 

provide them to ArcSight Enterprise Management Systems. SMC is collecting events





and performing event correlation and analysis. ArcSight database is used for midterm 

storage of collected events. 

13.1.9.5-p26 IDS management traffic shall be transported to NCIRC using a 

commercial IPsec VPN through a dedicated VPN client based on NCIRC 

specifications. Once installed, the VPN appliance shall be managed by NCIRC (se 

13.2.4.3). 

13.1.10 Service Transition Processes 

13.1.10.1 Change Management 

13.1.10.1-p1 The ANWI Contractor shall provide an ITIL compatible change 

management process and supporting utility for the SMC. 

13.1.10.1-p2 The ANWI Contractor’s change management utility shall provide an 

overview of all ongoing, planned, successful and unsuccessful changes. 

13.1.10.1-p3 The ANWI Contractor’s change management process shall be 

integrated with other SMC management processes (e.g. release and deployment, 

asset and configuration management) ensuring that all changes are screened, 

approved, managed and implemented based on an automated workflow process 

(workflows can be serial, parallel or ad hoc based on the defined process). 

13.1.10.1-p4 The ANWI Contractor’s change management utility’s workflow shall 

graphically visualise the change process, the current state and status, steps 

completed with date and steps to be completed. 

13.1.10.1-p5 The ANWI Contractor’s change management utility shall be 

integrated with the SMC’s Incident and Problem Management. 

13.1.10.1-p6 The ANWI Contractor’s change management utility shall provide 

web based form(s) integrated into the workflow process that is email enabled for 

alerts, notifications and approvals. 

13.1.10.1-p7 The ANWI Contractor’s change management utility shall provide 

functionality to identify and manage minor, major and emergency changes. 

13.1.10.1-p8 The ANWI Contractor shall provide a SMC calendar service where 

all main SMC events and tasks as well as SMC key personnel personal calendars 

can be displayed. 

13.1.10.1-p9 The ANWI Contractor’s change management utility shall interface 

with the SMC calendar to display all scheduled changes and provides drill down 

capability to specific changes. 


integrated with SLM to ensure all OLAs and SLAs are tracked and managed 

13.1.10.1-p11 

generate reports. 

The ANWI Contractor’s change management utility shall 

13.1.10.1-p12 The ANWI Contractor’s change management utility shall also 

easily create customisable (customer-specific) reports. 


integrated with release and deployment management; asset and configuration



management. Configuration Items (CIs) cannot be changed unless the CI is linked to 

a change. 

13.1.10.1-p14 The ANWI Contractor’s change management utility shall have bidirectional 

integration with other SMC processes (e.g. request fulfilment, incident and 

problem management). 

13.1.10.2 Service Asset Management 

13.1.10.2-p1 The ANWI Contractor shall provide an asset management 

process and supporting ITIL compliant tool that is integrated into the SMC. 

13.1.10.2-p2 The ANWI Contractor’s asset management utility shall provide an 

inventory agent which will inventory all ANWI provided assets. 

13.1.10.2-p3 The ANWI Contractor’s asset management utility shall provide 

and populate the ANWI’s CMDB. 

13.1.10.2-p4 The ANWI Contractor’s asset management utility shall record 

assets based on the ANWI CI list and attributes. 

13.1.10.2-p5 The ANWI Contractor’s asset management utility shall permit 

defining the relationships between CIs and associated service(s). 

13.1.10.2-p6 The ANWI Contractor’s change management utility shall not 

allow a CI record to be changed unless it is linked to a Change Request. 

13.1.10.2-p7 The ANWI Contractor’s asset management utility shall link the CI 

to all SMC requests. 

13.1.10.2-p8 The ANWI Contractor’s asset management utility shall be 

integrated with all other required SMC processes. 

13.1.10.2-p9 The ANWI Contractor’s asset management utility shall interface and 

exchange data with the HN BE provided active cable management system. 

13.1.10.2-p10 

The ANWI Contractor’s asset management utility shall 

interface and exchange data with the NCIA ’s CMDB (BMCs’ Atrium). 

13.1.10.2-p11 The ANWI Contractor’s asset management utility shall be able to 

bundle multiple CIs assets to one system configuration to simplify the display. 

13.1.10.2-p12 The ANWI Contractor’s asset management utility shall provide 

asset life cycle tracking and monitoring. 

13.1.10.2-p13 The ANWI Contractor’s asset management utility shall provide an 

auditing capability for verification and validation of the CMDB. 

13.1.10.2-p14 The ANWI Contractor’s asset management utility shall 

programmatically take regular snapshots of the Configuration Baselines for review 

and auditing. 

13.1.10.3 Configuration Management 

13.1.10.3-p1 The ANWI Contractor shall provide a configuration management 

process and utility as part of the ANWI SMC. 

13.1.10.3-p2 SMC shall use a single centralized configuration management 

database (CMDB). Used in, amongst others: Service Desk, Monitoring servers, 







Software and configuration distribution/deployment, license management, and 

supporting contract information. 

13.1.10.3-p3 The CMDB shall use a SQL backend and must provide an open 

API that allows further integration if and when required at a later stage. 

13.1.10.3-p4 The ANWI Contractor shall base the ANWI CMDB schema on the 

TeleManagement Forum (TMF) SID or DTMF Common Information Model (CIM) 

supporting a WBEM interface. 

13.1.10.3-p5 The ANWI Contractor shall align the ANWI CMDB with the NATO 

enterprise wide CMDB schema. 

13.1.10.3-p6 

XML schema. 

The ANWI Contractor shall provide the ANWI CMDB schema as an 

13.1.10.3-p7 The ANWI Contractor shall be put any CMDB schema 

enhancements under formal change management justified through the ANWI CMDB 

design. 

13.1.10.3-p8 The CMDB shall be based on the Telemanagement Forum 

(TMF) Common Information Model (CIM). 

13.1.10.3-p9 The configuration change request and approval capability shall 

be integrated in the selected service desk solution, configuration management and 

deployment system and the N/ELM systems. 

13.1.10.3-p10 

The CMDB shall hold all relevant information on external 

interfaces and related SLA information (including KPI and KQI). 

13.1.10.3-p11 

The ANWI Contractor’s configuration management utility 

shall interface with the tool used by the NCIA enterprise management section (MS 

SCCM) 

13.1.10.3-p12 


shall be able to centrally monitor, manage and deploy software (OS or application) to 

servers and clients. 

13.1.10.3-p13 


shall monitor the accepted baseline and non-compliant baseline configurations shall 

be auto remediated after a period that permitted the user to update the baseline. 

13.1.10.3-p14 The ANWI Contractor’s configuration management utility shall 

support software and security patch updating. 


manage mobile ANWI user devices. 

13.1.10.3-p16 The ANWI Contractor’s configuration management utility shall be 

able to monitor and manage energy saving devices and with power management 

tools – to the rack and equipment level. 


monitor and evaluate client device ‘health’. 


monitor and report asset (hardware and software) use.






support the asset (inventory) process. 

13.1.10.4 Release Management 

13.1.10.4-p1 

process. 

The ANWI Contractor shall provide a release management 

13.1.10.4-p2 The ANWI Contractor’s release management process shall be 

integrated with the SMC calendar. 

13.1.10.4-p3 The ANWI Contractor’s release management process shall 

address planning, design, coordinating, building and configuring of releases, release 

distribution and installation, and acceptance. 

13.1.10.5 Knowledge Management 

13.1.10.5-p1 The ANWI Contractor shall provide a knowledge management 

database for use by the support staff to document best practices and solutions to 

common problems. 

13.1.10.5-p2 The ANWI Contractor tool shall be able to share practical 

solutions with the NNHQ users. 

13.1.10.5-p3 The ANWI Contractor tool shall provide local search and allow 

federated searching from NATO search engines (FAST and Autonomy) based on 

attributes such as author, title, date, free text or keywords. 

13.1.10.5-p4 The ANWI Contractor tool shall provide a template to capture the 

problem description, OS, solution, author and date. 

13.1.11 Service Operations Processes 

13.1.11.1 Event Management 

13.1.11.1-p1 The ANWI Contractor shall provide an event management 

process and supporting tool. 

13.1.11.1-p2 

The ANWI Contractor’s tool shall consolidate event reporting. 

13.1.11.1-p3 The ANWI Contractor’s tool shall provide predictive analytics, 

correlation and dynamic prioritization of ANWI events irrespective of its source. 

13.1.11.1-p4 The ANWI Contractor’s tool shall provide configurable rules to 

process an event received from an ANWI monitored system. 

13.1.11.1-p5 The ANWI Contractor’s tool shall integrate with the SMC’s 

monitoring/dashboard system. 

13.1.11.1-p6 The ANWI Contractor’s tool shall assign the event through the 

ANWI trouble ticket system. 

13.1.11.1-p7 

SMC processes. 

The ANWI Contractor’s tool shall be integrated with all necessary 

13.1.11.1-p8 The ANWI Contractor’s tool shall be able to interface with the 

NCIA Microsoft SCOM/MOM applications for bidirectional communication.





13.1.11.1-p9 The ANWI Contractor’s tool shall interface with the NCIA 

Openview Network Management System for bi-directional communication.. 

13.1.11.1-p10 The ANWI Contractor’s tool shall flexible rules to support 

assignment, notification and workflow to resolve an event. 

13.1.11.1-p11 

reports. 

The ANWI Contractor’s tool shall detect events and generate 

13.1.11.1-p12 All events shall be automatically logged recoding at a minimum a 

timestamp, the reporting source, and notification content. 

13.1.11.1-p13 

SMC shall provide automated event filtering and consolidation. 

13.1.11.1-p14 The building management system (BMS) shall be integrated 

through web services with the SMC ESB in order to import BMS events relevant for 

communication and information systems services provisioning into the SMC. 

13.1.11.1-p15 The ANWI Contractor’s event management tool shall support 

physical, virtual environments and shall be extensible to cloud environments. 

13.1.11.2 Incident Management 

13.1.11.2-p1 The ANWI Contractor shall provide an incident management 

process and supporting tool. 

13.1.11.2-p2 The ANWI Contractor’s tool shall integrate with E-mail (also to 

support ESS and BMS reporting), the self-service portal, ANWI device monitoring 

tools and other ITIL linked SMC processes 

13.1.11.2-p3 The ANWI Contractor’s tool shall interface with the Service 

Catalogue forms to capture user required data for incident submission 

13.1.11.2-p4 The ANWI Contractor’s tool shall allow the Service Desk easy 

access to all trouble ticket updates aiding in resolution and reporting 

13.1.11.2-p5 The ANWI Contractor’s incident process tool shall: 

A. Capture and report incidents 

B. Log, categorise and prioritise incidents for resolution 

C. Provide initial Incident support 

D. Trigger other processes with input 

E. Initiate incident investigation and diagnosis 

F. Capture incident resolution or recovery using workarounds. 

G. Capture incident closure after verification from users 

H. Incident monitoring and interaction to other processes 

13.1.11.2-p6 Entering workarounds into Known Error Data Base (KEDB) and 

trigger the Problem Management process 

13.1.11.2-p7 The ANWI Contractor’s tool shall be able to tag incidents if they are 

likely to reoccur or impact other users 

13.1.11.2-p8 The ANWI Contractor’s tool shall integrate with and link incidents to 

a Known Error Database or Problem log/registry. 

13.1.11.2-p9 The ANWI Contractor’s tool shall provide appropriate ITIL based 

workflows to support the incident management process.



13.1.11.2-p10 The ANWI Contractor’s tool shall be integrated with the 

contractor provided trouble ticketing system. 

13.1.11.2-p11 The ANWI Contractor’s tool shall provide configurable 

escalations and notifications. 

13.1.11.2-p12 

scheduled reports. 

The ANWI Contractor’s tool shall provide interactive and 

13.1.11.2-p13 The ANWI Contractor’s tool shall be integrated with Incident, 

Problem, Knowledge, Change, CMDB and Service Level Management. 

13.1.11.2-p14 The ANWI Contractor’s tool shall be integrated with the SMC 

regular customer support survey support capability 

13.1.11.2-p15 The ANWI Contractor’s SMC shall automatically generate a 

trouble ticket in case of, component, service, or link status failure. 

13.1.11.2-p16 The ANWI Contractor’s SMC shall automatically generate a 

trouble ticket when a KPI or KQI is exceeded. 

13.1.11.2-p17 ANWI incidents shall be automatically analysed against the 

overall service impact. 

13.1.11.3 Problem Management 

13.1.11.3-p1 The ANWI Contractor shall provide a problem management process 

and supporting tool. 

13.1.11.3-p2 The ANWI Contractor’s tool shall support proactive IT management 

via tracking and trending incidents and events. 

13.1.11.3-p3 The ANWI Contractor’s tool shall provide the functionality and 

reporting to ensure that the Service Desk can minimize the effect of infrastructure 

issues. 

13.1.11.3-p4 The ANWI Contractor’s tool shall be integrated with the ANWI 

monitoring capability so that when an event or incident occurs, a problem ticket is 

automatically created and assigned to the appropriate staff to resolve. 

13.1.11.3-p5 The ANWI Contractor’s tool shall create reports which permit 

analysis of problem data to improve the performance of problem management. 

13.1.11.3-p6 The ANWI Contractor’s tool shall integrate problem management 

with all other SMC process (linked to SLM, Incidents, Knowledge, CMDB and 

Changes). 

13.1.11.3-p7 The ANWI Contractor’s tool shall link Configuration Items (CIs) to a 

problem so impact analysis can be performed on the CI as it is related to the linked 

problem. 

13.1.11.3-p8 The ANWI Contractor’s tool shall be able to capture problems using 

hardware/software agents or ANWI monitoring tools. 

13.1.11.3-p9 The ANWI Contractor’s tool shall provide configurable escalations 

and notifications. 




13.1.11.4 Known Error Data Base (KEDB) 




13.1.11.4-p1 The ANWI Contractor’s KEDB shall maintain information about 

Known Errors and Workarounds. 

13.1.11.4-p2 The ANWI Contractor’s KEDB shall maintain the root-causes of 

Incidents in the KEDB. 

13.1.11.4-p3 The ANWI Contractor’s KEDB shall make workarounds available to 

Incident Management while Problem Management develops final solutions for Known 

Errors. 

13.1.11.4-p4 The ANWI Contractor’s KEDB shall provide a trend-analysis of 

problems for important services and historical Incidents. 

13.1.11.4-p5 The ANWI Contractor’s problem process tool shall provide: 

A. Integrated customer surveys to collect user feedback. 

B. Capture unplanned service interruptions 

C. Problem detection and reporting 

D. Log and categorise problems 

E. Provide initial problem support 

F. Initiate other SMC processes with problem data as input 

G. Capture problem diagnosis 

H. Close incidents after verification from users 

i. Problem monitoring and interaction to other processes 

j. Enable entering workaround entry into Known Error Data Base (KEDB) 

k. Track problem management solutions 

l. Track procedures for major Problems 

13.1.11.4-p6 The ANWI Contractor’s tool shall be able to tag incidents if they are 

likely to reoccur or impact other users 

13.1.11.5 Request Fulfilment 

13.1.11.5-p1 The ANWI Contractor shall deliver a process tool supporting ITIL 

request fulfilment requirements. 

13.1.11.5-p2 The ANWI Contractor’s tool shall provide the means to respond to 

all ICT Service Requests. 

13.1.11.5-p3 The ANWI Contractor’s tool shall provide logging, categorization 

and prioritizing of Service Requests 

13.1.11.5-p4 The ANWI Contractor’s tool shall trigger other necessary SMC 

processes with required input for execution 

13.1.11.5-p5 The ANWI Contractor’s tool shall request fulfilment closure after 

verification from the requesting user 

13.1.11.5-p6 The ANWI Contractor’s tool shall monitor and produce necessary 

request fulfilment management information to track adherence to the billing SLA 

13.1.11.5-p7 The ANWI Contractor’s tool shall provide a capability to identify and 

track if the service request is likely to reoccur 

13.1.11.5-p8 The ANWI Contractor’s tool shall support a priority based fulfilment 

need based on either impact or urgency



13.1.11.5-p9 Routine move, add or change (MAC) request of user clients 

(workstations, telephones, user accounts, etc.) shall be executed within 4 hours by 

the ANWI Contractor. 

13.1.11.5-p10 The service provisioning shall support 1000 routine 

move/add/change requestsfrom user clients per day. 

13.1.11.5-p11 The SMC shall provide a centralized interface for user account 

management including an interface to network access control (NAC) functions. 

13.1.11.6 Access Management 

13.1.11.6-p1 

for the ANWI. 

The ANWI Contractor shall provide an access management process 

13.1.11.6-p2 The ANWI Contractor’s access management process shall establish 

a catalogue of user roles and associated access profiles for the ANWI services 

13.1.11.6-p3 The ANWI Contractor’s access management process shall be 

extensible to accommodate extensions of the roles and profiles to support the PFE 

projects (ESS, BMS, business applications and data access). 

13.1.11.6-p4 The ANWI Contractor’s access management catalogue shall 

interface with the ANWI directories (Active Directory, UCCand any SMC ELM 

systems that support an internal directory for Identity and Access management) for 

role and profile management. 

13.1.11.6-p5 The ANWI Contractor’s access management catalogue shall allow 

support staff easy access and viewing of a user’s role, access rights and 

permissions. 

13.1.11.6-p6 The ANWI Contractor’s access management process shall provide 

users the ability to change their own network passwords. 

13.1.11.6-p7 The ANWI Contractor’s access management process shall interface 

with the service catalogue to request the granting, changing or removing a user’s 

right to use a particular service or asset by the Service Desk from an authorised user. 

13.1.12 Continuous Service Improvement Processes 

13.1.12.1 Service Level Agreement (SLA) Reporting 

13.1.12.1-p1 The ANWI Contractor shall create bi-weekly reports on each ANWI 

Service usage, from the start of users arrival on site and establish the mechanism to 

have the reports generated monthly after FSA. 

13.1.12.1-p2 The ANWI Contractor shall create an ANWI SLA report based on 

the information captured from the monitoring and SMC tools and compare it to the 

SLTs and SLA 

13.1.12.1-p3 The ANWI Contractor shall use the data and previous reports to 

identify service trends. 

13.1.12.1-p4 

Purchaser 

The ANWI Contractor shall provide the SLA reports to the 




Number of SLAs 




13.1.12.1-p5 The ANWI Contractor shall review the provided ANWI SLA reports 

with the Purchaser 

13.1.12.2 Service Measurement 

13.1.12.2-p1 The ANWI Contractor’s service measurement shall primarily focus 

on availability, reliability and performance parameters augmented with other 

parameters to ensure SLAs and SLTs are satisfied. 

13.1.12.2-p2 The ANWI Contractor shall review the ANWI’s availability, reliability 

and performance data and report their status the Purchaser 

13.1.12.2-p3 The ANWI Contractor shall analyse the ANWI’s availability, reliability 

and performance trend 

13.1.12.3 Billing 

13.1.12.3-p1 The ANWI Contractor shall provide a billing capability to track 

services consumed and appropriately invoice serviced customers 

13.1.12.3-p2 The ANWI Contractor shall develop a financial management 

process with the Purchaser for billing serviced customers. 

13.1.12.3-p3 The ANWI Contractor’s tool shall interface with the NNHQ’s 

financial management process to support the invoicing and collection process. 

13.1.12.3-p4 The ANWI Contractor’s tool shall monitor and produce necessary 

financial management information to track adherence to the billing SLA. 

13.1.13 Key Performance Indicators (KPIs) and Metrics 

13.1.13.1 Performance KPI 

13.1.13.1-p1 

13.1.13.2 SLM KPIs 

13.1.13.2-p1 

at present 

13.1.13.2-p2 

13.1.13.2-p3 

13.1.13.2-p4 

13.1.13.2-p5 

13.1.13.2-p6 

place 

13.1.13.3 SLM Metrics 

13.1.13.3-p1 

13.1.13.3-p2 

13.1.13.3-p3 

13.1.13.3-p4 

Per infrastructure annex 

Number of services that are not meeting agreed service targets 

Number of services without updated SLAs at present 

Number of SLA targets missed 

Number of SLA targets threatened 

Percentage of services covered by SLAs 

Percentage of the coverage of OLAs and third-party contracts in 

Number of times the service is bypassed 

Number and severity of service breaches 

Number of services with timely reports and active service reviews



13.1.13.3-p5 Results from Customer Satisfaction Surveys 

13.1.13.3-p6 Evidence that issues raised at service and SLA reviews are 

being followed up and resolved 

13.1.13.3-p7 Incidents noted against the service 

13.1.13.4 Capacity KPIs 

13.1.13.4-p1 Plan over forecasted Capacity requirements 

13.1.13.4-p2 Plan over SLA forecasting to Capacity 

13.1.13.4-p3 Relevant information from the Event Management 

13.1.13.4-p4 Number of present SLA breaches due to substandard service or 

component performance 

13.1.13.4-p5 Mean percentage of over-capacity 

13.1.13.5 Capacity Metrics 

13.1.13.5-p1 Number of service thresholds exceeded 

13.1.13.5-p2 Number of Incidents caused by performance overload 

13.1.13.5-p3 Number of urgent purchases made to address urgent 

performance/capacity issues 

13.1.13.5-p4 Accuracy of forecasts of operational trends 

13.1.13.6 Billing KPIs 

13.1.13.6-p1 Cost of Services today 

13.1.13.6-p2 Up to date status of invoices issued 

13.1.13.6-p3 Up to date status of invoices paid 

13.1.13.6-p4 Up to date service costs based on the Service Catalogue’s 

services 

13.1.13.7 Availability KPIs 

13.1.13.7-p1 Plan over forecasted Availability requirements 

13.1.13.7-p2 Plan over SLA forecasting to Availability 

13.1.13.7-p3 Relevant information from Event Management 

13.1.13.7-p4 Percentage of services and componentscurrently unavailable 

13.1.13.7-p5 Mean time between failures 

13.1.13.7-p6 Mean time between system Incidents 

13.1.13.7-p7 Mean time to restore service 

13.1.13.7-p8 Mean time to repair component 

13.1.13.8 Availability Metrics 

13.1.13.8-p1 Number of times the process is bypassed 





13.1.13.8-p2 

13.1.13.8-p3 

Number of Incidents against the service 

Percentage of overall availability of services and components 

13.1.13.9 Service Catalogue KPI 

13.1.13.9-p1 Number of users accessing / browsing the site 

13.1.13.9-p2 Number of requests submitted 

13.1.13.9-p3 Items being ordered 

13.1.13.10 Continuity Management KPI 

13.1.13.10-p1 Number of disaster exercises held 

13.1.13.10-p2 Number of shortcomings identified during a disaster exercise 

13.1.13.11 Information Security Management KPIs 

13.1.13.11-p1 Number of Access open requests (not handled) 

13.1.13.11-p2 Response times - Amount of Access requests handled within the 

time scale defined in the SLA 

13.1.13.11-p3 Number of currently open unauthorized Access rights 

13.1.13.11-p4 Number of preventative security measures implemented 

13.1.13.11-p5 Duration from identification of a threat to implementation of 

counter measure 

13.1.13.11-p6 Number of security incidents by severity 

13.1.13.11-p7 Number of incidents causing a service interruption 

13.1.13.12 Information Security Metrics: 

13.1.13.12-p1 Number of times the Access Management process is bypassed 

13.1.13.12-p2 Number of Access requests performed through the Access 

Management process 

13.1.13.12-p3 Number of Access requests performed with the Directory 

Services tool to manage access and rights 

13.1.13.12-p4 Number of triggers to process 

13.1.13.12-p5 Number of Access requests processed per agent 

13.1.13.12-p6 Number of users attempting to access services without proper 

Authority 

13.1.13.12-p7 Number of Access requests from users compared to Access 

Management being triggered by Event Management 

13.1.13.12-p8 Number of live operational SLAs in use 

13.1.13.12-p9 Number of Security Policies in use 

13.1.13.12-p10 Number of many to one Access requests through use of group 

rights 



13.1.13.12-p11 

13.1.13.12-p12 

requests. 


Number of complaints and/or letters of praise 




Identifying, logging, categorizing and prioritizing all Access 

13.1.13.12-p13 Access Management cost - Cost based on time used from 

Access request logging to closure. 

13.1.13.12-p14 Percentage number of Access requests from customer compared 

to operational changes 

13.1.13.12-p15 

13.1.13.12-p16 

Results of customer satisfaction surveys 

Hours worked against budget 

13.1.13.13 Change Management KPIs 

13.1.13.13-p1 

The Change Schedule not adversely affecting the organization. 

13.1.13.13-p2 Number of Changes proceeding to Change Authority that should 

have been previously defined as Standard Changes, i.e. definition = low impact + low 

cost still going through Change Authority. 

13.1.13.13-p3 

Number of planned Changes without detailed roll back plan. 

13.1.13.14 Change Management Metrics 

13.1.13.14-p1 

13.1.13.14-p2 

changes 

Number of times the process is bypassed 

Number of emergency changes, normal changes and standard 

13.1.13.14-p3 Number of changes defined as standard changes after one 

change management process run through. 

13.1.13.14-p4 

13.1.13.14-p5 

13.1.13.14-p6 

13.1.13.14-p7 

13.1.13.14-p8 

13.1.13.14-p9 

more aligned 

Number of changes that comply with customer strategy 

Reduction of number of unplanned changes 

Reduction of unplanned service outages 

Reduction of change roll backs 

13.1.13.15 Asset Management KPI 

13.1.13.15-p1 

13.1.13.15-p2 

management data 

13.1.13.15-p3 

Reduction of number of incidents after approved changes 

Evaluation process's predicted performance actual performance 

Frequency of configuration verifications 

Number of incidents resulting from incorrect configuration 

Average work (effort) for configuration management verification 

13.1.13.15-p4 Number of incorrect changes made using automated 

configuration updates 

13.1.13.15-p5 

audit 

Number of configuration management errors identified during an



13.1.13.16 Asset Management Metrics 

13.1.13.16-p1 Number of times the process is bypassed 

13.1.13.16-p2 Number of errors in information through timely audits compared 

to real-life 

13.1.13.16-p3 Number of times the process has been triggered 

13.1.13.16-p4 Population of the CMDB 

13.1.13.16-p5 Time of actual triggering of the process compared to actual 

Change time. 

13.1.13.16-p6 Accurate information of CIs and Service Assets in CMDB 

13.1.13.16-p7 Few errors on CIs information entered 

13.1.13.17 Release Management KPI 

13.1.13.17-p1 Number of major and minor releases 

13.1.13.17-p2 Duration of deployment (approval to work completed) 

13.1.13.17-p3 Number of releases which had to be reversed 

13.1.13.17-p4 Proportion of automatic releases 

13.1.13.18 Event Management KPIs 

13.1.13.18-p1 Reasons documented for present Event monitoring 

13.1.13.18-p2 Number of Events triggering Incident Management process 

13.1.13.18-p3 Number of Events eventually leading to Change 

13.1.13.19 Event Management Metrics 

13.1.13.19-p1 Number of bypasses of the process made 

13.1.13.19-p2 Number of Events per category 

13.1.13.19-p3 Number of important Events 

13.1.13.19-p4 Number of Events requiring human intervention 

13.1.13.19-p5 Number of Events per Service 

13.1.13.19-p6 Number of Events per application 

13.1.13.19-p7 Number of Events per Operating System 

13.1.13.19-p8 Number of Events wrongly sorted 

13.1.13.19-p9 Number of Events that detected in relation to Incidents detected 

by IT staff 

13.1.13.20 Incident Management KPIs 

13.1.13.20-p1 Number of Incidents not presently assigned 

13.1.13.20-p2 Number of Incidents resolved through the Incident Management 

process 





13.1.13.20-p3 Incident Response Time - Amount of Incidents handled within the 

time scale defined in the SLA 

13.1.13.20-p4 Length of time before the Incident Management phone is 

answered 

13.1.13.20-p5 Length of time before user gets feedback from input to Service 

Desk. 

13.1.13.21 Incident Management Metrics 

13.1.13.21-p1 Number of Incidents where staff proceeded into Problem 

Management 

13.1.13.21-p2 Time of day when most Incidents were 

opened/assigned/resolved/closed 

13.1.13.21-p3 Number of bypasses to the process 

13.1.13.21-p4 Number of Incidents closed in service desk, first line support, 

using KEDB for workarounds. 

13.1.13.21-p5 Number of calls received 

13.1.13.21-p6 Number of calls missed 

13.1.13.21-p7 Number of calls logged 

13.1.13.21-p8 Number of non-logged calls 

13.1.13.21-p9 Number of calls escalated 

13.1.13.21-p10 Number of Incidents processed per agent 

13.1.13.21-p11 Number of complaints and/or letters of praise 

13.1.13.21-p12 Percentage of repeat calls for the same Incident 

13.1.13.21-p13 Percentage of Incidents resolved by help desk - first level 

13.1.13.21-p14 Percentage of operations support requests closed 

13.1.13.21-p15 Percentage number of Incidents compared to incoming calls 

13.1.13.21-p16 Mean Elapsed Time - Time between Incident report and 

resolution 

13.1.13.21-p17 Mean time to achieve Incident resolution 

13.1.13.21-p18 Incident cost - Cost based on time used from Incident logging to 

Incident closure. 

13.1.13.21-p19 Length of time before the phone is answered 

13.1.13.21-p20 Average duration of phone calls 

13.1.13.21-p21 Results of customer satisfaction surveys 

13.1.13.21-p22 Hours worked against budget 





13.1.13.22 Problem Management KPI 

13.1.13.22-p1 Number of Problems not handled at the present i.e. Open 

Problems 

13.1.13.22-p2 Problem Response Time - Amount of Problems managed within 

the time scale defined in the SLA 

13.1.13.22-p3 Percentage of Problems presently being escalated 

13.1.13.22-p4 Planned initial Problem team groups 

13.1.13.23 Problem Management Metrics 

13.1.13.23-p1 Percentage reduction in the Incidents and Problems affecting 

service to Customers 

13.1.13.23-p2 Percentage reduction in average time to resolve Problems 

13.1.13.23-p3 Percentage reduction of the time to implement fixes to Known 

Errors 

13.1.13.23-p4 Percentage reduction of the time to diagnose Problems 

13.1.13.23-p5 Percentage reduction of the average number of undiagnosed 

Problems 

13.1.13.23-p6 Percentage reduction of the average backlog of 'open' Problems 

and errors. 

13.1.13.23-p7 Percentage of incidents defined as Problems 

13.1.13.23-p8 Percentage of proactive Problem Management triggers 

13.1.13.23-p9 Percentage of Problems managed through the Problem 

Management process model 

13.1.13.23-p10 Number of bypasses on the process 

13.1.13.23-p11 Number of Problem resolved through the Problem Management 

process 

13.1.13.23-p12 Number of complaints and/or letters of praise 

13.1.13.23-p13 Number of Problems logged 

13.1.13.23-p14 Number of Problems fixed 

13.1.13.23-p15 Number of Problems outstanding 

13.1.13.23-p16 Number of Workarounds added to the KEDB 

13.1.13.23-p17 Number of added Workarounds in KEDB used by Incident 

Management 

13.1.13.23-p18 Number of Problems solved by initial diagnosis 

13.1.13.23-p19 Number of RfCs sent to Change Management 

13.1.13.23-p20 Number of non-recurring incidents due to fixes 

13.1.13.23-p21 Number of many-to-one incident fixes compared to one-to-one 

incident fixes 





13.1.13.23-p22 

13.1.13.23-p23 

Problem closure. 

13.1.13.23-p24 

13.1.13.23-p25 

13.1.13.23-p26 

13.1.13.23-p27 

performance 

Time between Problem Logging and Problem resolution 

Problem cost - Cost based on time used from Problem logging to 



Resolution times with respect to service level requirements 

Hardware, software and help desk support, response and 

13.1.13.24 Request fulfilment KPIs 

13.1.13.24-p1 

13.1.13.24-p2 

13.1.13.24-p3 

Number of presently unanswered Requests 

Number of Requests that have stopped dead in the process 

Number of staff presently running the process 

13.1.13.25 Request fulfilment Metrics 

13.1.13.25-p1 

13.1.13.25-p2 

Number of bypasses to the process 

Time of day Requests have been submitted. 

13.1.13.25-p3 Number of Service Requests through the Request Fulfilment 

Management process 

13.1.13.25-p4 

13.1.13.25-p5 

13.1.13.25-p6 

Number of Service Requests processed 

Number of Standard Changes processed 

Number of complaints and/or letters of praise 

13.1.13.25-p7 Request Fulfilment cost - Cost based on time used from Service 

Request logging to Service Request closure. 

13.1.13.25-p8 

13.1.13.25-p9 

13.1.13.26 Billing Metrics 

13.1.13.26-p1 



Number of bypasses to the process 

13.1.13.26-p2 Number of times Financial Management has been triggered by 

other ITSM processes 

13.1.13.26-p3 Number of Services with up to date Valuationsand TCO (Total 

Cost of Ownership) 

13.1.14 End-to-End Scenario Testing 

13.1.14-p1 SMC performance shall be measured during the end-to-end test 

scenario which will be a structured walkthrough of all the identified ITIL processes to 

be supported where provider, customer, user and IV&V are represented. 





13.1.14-p2 During the scenario testing the following performance shall be 

measured: 

A. Mean Customer wait time. 

B. Mean customer Request duration time. 

C. First call resolution percentage. 

D. Volume of customer requests. 

E. Cost efficiency of customer management. 

F. Mean reporting wait time. 

G. Mean change management and CMDB update wait time. 

H. Mean change management and asset management update wait time. 

i. Reporting to Central NATO SMC (NCIA ). 

J. Providing monitoring info to Central NATO SMC (NCIA ). 

13.1.14-p3 Consume and proliferate Software package from Central NATO 

SMC and distribute to NNHQ infrastructure. 

13.1.15 Training 

13.1.15-p1 The ANWI Contractor shall provide NATO O&M personnel (for 

NONO services only) full training of the SMC tools and processes to fit the identified 

ITIL processes, if the service is identified as NONO. 

13.1.15-p2 Users shall be provided with an informational guide to be able to 

effectively communicate with the Service Desk, service catalogue and interact with 

the Self-Service portal. 

13.1.16 Cross Domain Requirements 

13.1.16-p1 Cross domain management information XML messages shall use a 

highly normalized and strictly enforced XML schema. 

13.1.16-p2 Cross domain management information XML messages shall be 

signed before exchanging the message across the cross domain boundary and 

verified upon receipt on the other side. XML messages with incorrect signatures 

and/or untrusted signers are rejected. The signing entity must only permit messages 

from entities that are trusted and permitted to send messages across the security 

domain boundary. 

13.1.16-p3 Violations of the cross domain XML message schema and/or 

signature shall be logged and a notification shall be send to the IOSS. 

13.1.17 Future Technology Requirements 

13.1.17-p1 Where the cross domain exchange of management information is 

initially constrained to unidirectional low-to-high exchange of management 

information, using a data-diode, due to unavailability of a bi-directional gateway that 

can be accredited, the SMC infrastructure (including AIS Managers, N/ELM, IOSS, 

and ESB systems) shall be prepared for augmenting the data-diode with a bidirectional 

cross domain management information gateway when and where 

available. 




13.1.18 SMC Service Level Agreement/Target 

SLT feature 


Value 

Availability (6 months period) 

Service Availability 99.5 

Response time 

Number of Service Interruptions 1 

Duration of service interruptions (hours) 1 

TBD 

Number of Service Availability Measurements (over the period) 43800 

Capacity 

Number of capacity shortfall incidents 5 

Number of capacity modifications 1 

Resolution time of capacity adjustments (hours) 1 

Capacity reserve 25% 

Reliability 

MTBF (hours) 4380 

MTTR (hours) 4 

Number of critical failures 1 

Maintainability 

Mean Time to Replace (hours) 24 

Table 13.1 SMC SLTs 

13.1.19 Management and Operational Requirements 

13.1.19.1 Interfaces 

13.1.19.1-p1 The ANWI Contractor shall describe the following internal interfaces 

and dependencies for the Specific COI SMC capability, interfacing with the 

respective SMC (element management) services of each of the individual services. 

User Services 

Processing 

Storage 

Printing 

AD 

DNS 

DHCP 

NTP 

NAC 

Client 

Provisioning 

LAN 

Cross Domain 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 

ICTM applications 

Web Publishing 

SMC 

SMC X X X X X X X X X X X X X X X X X X X X X 

Table 13.2 SMC Interfaces 

13.1.19.1-p2 In support of the SMC management concept to consolidate SMC 

management information on the NS network the following interfaces are required that 

are linked to the functionality of CDGW. These are the internal NNHQ internal Cross 

Domain Interfaces as specified in Annex E Appendix 2. 

CDM function protocols comment 





CDGW4-NS XML, SMTP, SNMP, FTP (XML preferred) EAPC-NS (one way initial) 

CDGW5-NS XML, SMTP, SNMP, FTP (XML preferred) Business-NS (one way initial) 

CDGW6-NS XML, SMTP, SNMP, FTP (XML preferred). Public-NS (one way initial) 

Table 13.3 Cross Domain Gateway Interfaces for the SMC 

13.1.19.1-p3 For the sharing of SMC services and interfaces with the central 

NCIA CIS management services the following Cross Domain Gateways are 

instrumental to support that function. 

CDM function 

CDGW1-NSNS WAN 

CDGW2-NR NR WAN 

CDGW2NU WAN 

CDGW3-Public Public 

Public PIA services 

functions 

Monitoring, software distribution, remote management (which is a function of each 

individual service SMC interface) 

The ANWI specific COI SMC service interfaces with the NCIA central management 

monitoring, reporting and CMDB capability: 

HP OpenView (Comms Monitoring) 

SCOM (AIS monitoring) 

SCCM (AIS inventory and metering) 

Remedy (Service Desk management Comms and Central Management of CIS services) 

SDE (Service Desk management AIS) 

CMDB 

Monitoring, software distribution, remote management (which is a function of each 

individual service SMC interface). 

Monitoring, software distribution, remote management 

(which is a function of each individual service SMC interface). 

Table 13.4 Cross Domain Gateway functions 




13.2 Appendix 2: Information Assurance 




13.2-p1 The ANWI Contractor shall implement and integrate the ANWI IA vertical 

services components into the existing NATO SMI environment and centralized IA 

management system. 

13.2-p2 The ANWI IA management services shall be an integrated part of the SMC 

services. 

13.2-p3 The ANWI IA management services shall be centralized as specified in 

section 13.2.1-13.2.5. Currently, the central IA management systems are installed 

outside of the NATO HQ and operated by NATO that are assigned the responsibility 

for central management of certain IA related capabilities for central management 

(e.g. NCIA , NCIRC). In case of an ANWI IA service to be centrally managed certain 

dedicated management tasks may be delegated to the local admins. 

13.2-p4 Required local IA management capabilities shall be provided and installed 

in Class 1 Security Areas. IA management services shall be reachable only from 

certain admin workstations in the NNHQ building, or through a management server. 

13.2-p5 The ANWI contractor shall implement Specific COI IA services that map to 

the Security Mechanisms as outlined in Annex C section 11.8. 

13.2-p6 Ultimately, the ANWI contractor shall verify and validate the ANWI IA 

management services comply with the security CONOPS 1.1.1.7.4 and report the 

results to the Purchaser. 

13.2-p7 The ANWI Information Assurance services are specified in Table 13.1. 

13.2-p8 The required ANWI IA services and ANWI IA management services as 

identified in Table 13.1 are all part of a bigger picture NATO wide IA services scope. 

For the scoping of the ANWI contractor responsibilities in this area three areas are 

covered: 

A. Delivery of ANWI provided service components. 

B. Delivery of ANWI provided IA management service components. 

C. Level of integration into a NATO wide capability. 

13.2-p9 Each of the ANWI IA services as identified in the table is specified in more 

detail in the respective paragraphs in sections 13.2.2.2-13.2.2.6. 

ANWI IA 

service 

Cross Domain 

Module 

Anti-Virus 

ANWI service 

Provision of 

consistent cross 

domain services and 

support to the 6 

CDGW’s as identified 

in section 12.3.2.6. 

Part of the following 

ANWI service – 

Processing Services, 

Cross-domain 

Services, Client 

provisioning service, 

UCC service 


management 

service 

Local Firewall, 

guards and NCIRC 

management 

services as 

defined NATO 

wide. 

Local Anti-Virus 

management 

capability fit to 

the NATO wide 

NIATC anti-virus 

capability 

Integration 

Integration into NATO wide 

central management of BPDs. 

Integration into NCIRC. 

Integration with PIA GW 

See appropriate SMs in 

section 11.8.2.2for details 

Integrates to NIATC Anti-Virus 

support on the NS and NU/NR 


section 13.4 for details 

Relevant 

Security 

Mechanisms 

SM01, SM06- 

09, SM 11, 

SM14-20, SM22 

SM01-05, 

SM08-09



NPKI 

Incident 

Management 

Security Patch 

and 

Configuration 

Management 

ANWI shall integrate 

NATO wide PKI 

services 

ANWI shall provide 

two factor 

authentication using 

NPKI (included in 

Client Provisioning 

Service) and RAs 

Part of Processing 

Services (PR060-061) 

– host-based IDS and 

Cross-domain 

services 

No specific security 

patch management – 

see SMC 

ANWI shall 

provide 

Registration 

Authorities(RAs) 

for NS and 

Business network 

Local 

management of 

H-ID/PS; 

N-ID/PS, FPC 

centrally 

managed by 

NCIRC; 

Log collection for 

NCIRC (via 

ArcSight 

Connectors/ 

Loggers) 

NPKI integration – see Annex 

B 

Security tools (apart from H- 

IDS and AV) shall be centrally 

managed by NCIRC. Note: 

NCIRC FOC project may 

provide N-ID/PS, OCF and FPC 

to be integrated into CDMs. 

Integration with NCIRC for log 

collection 


section 13.4 for details 

SM11-13, 

SM17, SM30, 

SM42, SM49 

SM16, SM21, 

SM28, SM36 

See SMC See SMC SM40, SM43 

Table 13.5ANWI Specific CoI IA and IA management Services 

13.2-p10 These specific IA services, addressed in subsequent sections, shall be 

provide on all 4 networks within New NATO HQ (NS, EAPC, Business and Public), 

within and between the internal networks and between ANWI and all external 

networks. 

13.2.1 Cross Domain Module (CDM) 

13.2.1-p1 Cross-domain capabilities provide the required connectivity of NNHQ 

ANWI LAN infrastructures to external networks or to each other. 

13.2.1.1 Architecture 

13.2.1.1-p1 The CDM architecture shall be based on a modular approach where 

additional modules may be added or old modules replaced with newer modules. 

13.2.1.1-p2 As mentioned in Annex D (table 12.1), the CDM shall initially consist 

of six major gateways: 

A. CDGW1: NSNS WAN, 

B. CDGW2: NRNR WAN/NU/Public, 

C. CDGW3: Public Access, 

D. CDGW4: NSEAPC, 

E. CDGW5: NSNR, 

F. CDGW6: Public >NS. 







13.2.1.1-p3 CDM components shall be installed in the server rooms (Class 1 

secure areas), in a redundant and high available configuration. 

A. The Cross Domain Module shall implement the ANWI CDM architecture in 

an integrated, resilient, logical, modular and scalable way as shown in 

Figure 13.3. 

B. The CDM shall be implemented in a redundant load balancing fashion 

across the two server rooms as depicted in section 12.3 

C. The CDM shall present one integrated and consolidate management 

interface that allows to manage all cross domain gateways, both locally 

and centrally (remote). 

D. The CDM shall be scalable and allow for creation of additional CDGWs or 

expanding on existing CDGW enhancements. 

E. The CDM management interface shall be used as the primary tool for level 

1 CDM operations and maintenance. Through this tool access to other 

CDM component management tools shall be organised. 

F. The CDM management interface shall be used to create, visualise CDM 

component configuration settings (rulesets) and present the end-to-end 

cross domain information flows based on the following parameters: 

1. Cross domain information services active 

2. Configuration Settings 

3. Performance and throughput 

4. Incidents detected 

G. The CDM management interface shall allow security staffs to inspect and 

audit the overall active Cross Domain architecture and cross domain 

services in a top-down fashion. 

H. All individual CDM, CDGW components shall allow for local and central 

management and reporting interface. 

i. Backup and recovery devices shall be available to preserve the overall 

availability of the CDM and its CDGWs. 

J. The availability of on-line redundant components for all CDM component 

shall be determined by the availability, reliability and MTTR requirements 

as specified in the services paragraph (13.2.2.2.2). 

K. Implementation of the CDM and CDM management interfaces shall not 

negatively impact the end-to-end services performance (delays). 

L. IP stack: Gateway 1 to 6 shall support IPv4 and IPv6 in a dual stack 

configuration. 

M. All exchanged data shall be checked for malicious code. 

N. There shall be validation of the format of exchanged data. 

O. An intrusion detection / prevention system shall be implemented to include 

network or host based detection / prevention, online computer forensics 

and full packet capturing that complies with the NCIRC FOC 

specifications. 

P. All gateway components shall be administered by staff possessing NATO 

Cosmic Top Secret security clearances and shall operate in a NATO class 

1 security area. 

Q. User authentication information shall be used. 

R. User authorization shall be used.



S. Network communication information shall be taken into account (IP 

address, domain, other network protocols). 

T. Application layer information shall be used (screening for "dirty words", 

HTTP commands). 

U. "White"- or "black"-listing methods shall be used (e.g. IP-ranges, file types, 

user groups). 

V. Cross-domain, management of: The management of the cross domain 

gateway's Mail guard components shall be centralized from the high side 

(typically using a SSH2 terminal connection). 

W. Cross-domain, management of: The management of the cross domain 

gateway's XML guard components shall be centralized from the high side 

(typically using a SSH2 terminal connection). 

X. Cross-domain, management of: The management of the cross domain 

gateway firewall components shall be centralized from the high side. 

Y. Cross-domain, management of: The management of data dioded 

components shall be centralized from the high side (typically using a 

SSH2 terminal connection). 

Z. Cross-domain, management of: The management of Ethernet switching 

and IP routing component of cross domain gateways shall be done from 

the N/ELM located in the security domain that it belongs to. 

AA. Where technically possible, appropriate NATO security settings (currently 

available for Windows and Solaris based servers) shall be implemented 

and network equipment (e.g. switches) shall be configured in accordance 

with NIATC security guidance (Ref. 1.1.1.6.36 and 1.1.1.6.37). 





Figure 13.3 CDM architecture across the dual server rooms 

13.2.1.1-p4 The subsections of this chapter list requirements which have an 

impact on architecture and components of particular cross domain gateways. The 

Contractor is responsible for designing Gateways in accordance with these 

requirements and IA-related NATO directives and guidance listed in section 1.1.1.6. 

13.2.1.1.1 CDGW1 

13.2.1.1.1-p1 The architecture of CDGW1 (depicted in Figure 13.4) shall follow the 

NGCS Target Architecture document (see reference 1.1.1.8.13.) as the key reference 

for SIPs and SIOPs. In addition, the following requirements shall be fulfilled: 

A. The gateway shall include a Boundary Protection Device (firewall) limiting 

network traffic to authorized protocols. 

B. The BPD shall be evaluated to at least EAL3 according to Common 

Criteria or national equivalent. 





C. The intermediate servers/concentrators shall be placed in the DMZ 

segments and diversify between the following three types of DMZ 

segments as specified in section 12.3.3 : 

1. NS level FE DMZ 

2. NS level BE DMZ 

3. NS authentication DMZ 

D. Due to different user and security requirements voice and video traffic 

should be separated from the other network traffic. 

Figure 13.4 CDGW1 architecture 

13.2.1.1.2 CDGW2 

13.2.1.1.2-p1 This gateway capability (depicted in Figure 13.5) shall facilitate interface 

to the future NR enterprise WAN as described in the NGCS TA (1.1.1.8.13). From an 

AIS perspective CDGW2 shall facilitate integration and/or information sharing with 

(federated NATO) entities through the NR WAN, NU WAN and the Internet at the 

NU/NR level. 

13.2.1.1.2-p2 The architecture proposed by the Contractor shall be compliant with the 

following requirements: 

A. The gateway shall include a Boundary Protection Device (firewall) limiting 

network traffic to authorized protocols. 

B. The BPD shall be evaluated to at least EAL3 according to Common 

Criteria or national equivalent. 





C. The intermediate servers/concentrators may be placed in the DMZ 

segments and diversify between the following types of DMZ segments as 

specified in section 12.3.4: 

1. NU or NR FE DMZ 

2. NU or NR BE DMZ 

3. NU or NR authentication DMZ 

D. Due to different user and security requirements voice and video traffic 

should be separated from the other network traffic. 

E. The NR domain IP address scheme shall be concealed from the NU 

domain by NAT or similar. 


13.2.1.1.3 CDGW3 

13.2.1.1.3-p1 The architecture of CDGW3 (depicted in Figure 13.6) shall follow the 

NGCS Target Architecture document (see reference 1.1.1.8.13.) as the key reference 

for SIPs and SIOPs. 






13.2.1.1.3-p2 The CDGW3 architecture shall be compliant with the following 

requirements: 

A. The minimum assurance level for the security enforcing elements of the 

CDGW3 is EAL4 or national/international equivalent. 

B. The Boundary Protection Devicess (BPDs) shall ensure that only NU 

information is provided to public network. 

C. A DMZ access for both NR, NU and Public Level segments shall be fully 

integrated and supported in conjunction with CDGW2. 

D. The intermediate servers/concentrators may be placed in the DMZ 



1. Internet Publishing FE DMZ 

2. Internet Publishing BE DMZ 

3. Remote Access DMZ 

E. The BPC shall validate the format of all exchanged data (e.g. checking 

that web traffic is in fact HTTP or HTTPS) to minimize the risk of exploits. 

13.2.1.1.4 CDGW4 

13.2.1.1.4-p1 The architecture of CDGW4 (depicted in Figure 13.7) shallsupport bidirectional 

email exchange and use secure release mechanisms from NS to EAPC to 

release or publish document. It shall also be used for management information 

transfer from the EAPC network to the NS network. 






13.2.1.1.4-p2 The CDGW4 architecture shall be complaint with the following 

requirements: 

A. Network traffic shall be limited (by BPDs) to set of services authorized by 

the Security Accreditation Authority (SAA). 

B. The interconnection architecture shall use a DMZfor the exchange of 

information unless it is operationally not acceptable. 







D. Authorized data flow need to be controlled (e.g. bye-mail or XML guard) to 

make sure that NATO information not releasable to EAPCshall not pass 

through the Gateway. 

E. The mail guard shall be protected by the Boundary Protection Device (s). 

F. The minimum EAL for the security enforcing elements of the BPD is 4. 



13.2.1.1.5 CDGW5 



13.2.1.1.5-p1 The CDGW5 architecture (depicted in Figure13.8) shall be compliant 

with the following requirements: 

A. There shall be network services control use (e.g. implemented on firewall 

limiting network traffic to set of services authorized by the Security 

Accreditation Authority (SAA)) of guard or data diode (e.g. by e-mail or 

XML guard) to ensure that data from higher domain (NS) shall not be 

released to lower domain (NR). 

B. The interconnection architecture shall use a DMZ for the exchange of 

information unless it is operationally not acceptable. 







4. NR level FE DMZ 

5. NR level BE DMZ 

6. NR authentication DMZ 






13.2.1.1.5-p2 Currently (2Q 2012) evaluated guards supporting all services required 

by NNHQ users are not available, so initially CDGW5 architecture shall be based on 

a data diode solution with mail guard allowing notification of data transfer. 

A. The low side server (LSS) shall be protected by the BPD (e.g. firewall) to 

ensure that only authorized systems/hosts can exchange data with the 

LSS. 

B. All exchanged data shall be checked against malicious software at the low 

side (it can be installed on the LSS itself or on each hosts which provides 

data for the LSS). 

C. There shall be a protocol conformance checker (mechanisms remove 

potentially harmful protocol options, using for instance an application layer 

(proxying) firewall) to be implemented at the low side. 

D. Data scrubbing shall be implemented at the high side – to ensure that 

threats such as active content are removed from the information flow. 

Additionally, transforming data (e.g. from one file format to another) or 

masking data (e.g. removing or zero-izing data field contents) may be 

useful to sanitize data without the loss of semantics and may help prevent 

a successful attack. 





E. Protection against malicious software shall be implemented at the high 

side – all data need to be scanned before transmission to internal NS 

LAN. Use of different anti-virus software than on the low side is 

recommended. 

F. The mail guard shall be protected by the firewall(s) 

G. Firewalls, guard(s), high and low side servers shall be centrally managed 

(2 instances of centralize management capabilities for data diode servers: 

on NR and NS level, management on NS level for firewalls and guards). 

As centrally managed data diodes solutions and firewalls are/shall be 

implemented at various NATO sides, the selected solutions should be 

consistent with existing (at the implementation time) products used within 

NATO and managed by NCIA . 

H. Strong (two factor) authentication for administrators of High and Low Side 

Servers shall be implemented. 

13.2.1.1.6 CDGW6 

13.2.1.1.6-p1 The architecture of CDGW6 (depicted in Figure 13.9) shall consist of 

data diodes as its key components providing transfer of network/component 

management-related data to the NS domain from the unclassified network. 


A. Strong (two factor) authentication for administrators of High and Low Side 

Servers shall be implemented. 

B. The low side server (LSS) shall be protected by the BPD (e.g. firewall) to 

ensure that only authorized systems/hosts can exchange data with the 

LSS. 







C. All exchanged data shall be checked against malicious software at the low 

side (it can be installed on the LSS itself or on each hosts which provides 

data for the LSS). 

D. There shall be a protocol conformance checker (mechanisms remove 

potentially harmful protocol options, using for instance an application layer 

(proxying) firewall) to be implemented at the low side. 

E. Data scrubbing shall be implemented at the high side – to ensure that 

threats such as active content are removed from the information flow. 

Additionally, transforming data (e.g. from one file format to another) or 

masking data (e.g. removing or zero-izing data field contents) may be 

useful to sanitize data without the loss of semantics and may help prevent 

a successful attack. 

F. Protection against malicious software shall be implemented at the high 

side – all data need to be scanned before transmission to internal NS 

LAN. Use of different anti-virus software than on the low side is 

recommended. 

G. Firewalls, guard(s), high and low side servers shall be centrally managed 

(2 instances of centralize management capabilities for data diode servers: 

on NR and NS level, management on NS level for firewalls and guards). 

As centrally managed data diodes solutions and firewalls are/shall be 

implemented at various NATO sides, the selected solutions should be 

consistent with existing (at the implementation time) products used within 

NATO and managed by NCIA . 

13.2.1.2 Service 

13.2.1.2-p1 Cross domain module supports information exchange between 

different networks/security domains (e.g. LANs with different security classification or 

networks managed by different CIS Operating Authorities). Table 13.2 summarises 

the nature of each of the individual cross domain gateways information exchange 

services. The detailed summary of cross domain information services per CDGW is 

provided in the paragraphs 13.2.1.2.1-13.2.1.2.6. 

Gateway 

CDGW1: NSNS 

WAN 

CDGW2: 

NRNR/NU/Public 

CDGW3: Public 

Access 

Service 

information sharing between the NS LAN and the NS WAN 

network; 

the external interfaces to the NS based network services. 

information sharing between the NR LAN and the NR/NU 

WAN NGCS networks, and 

the connectivity between NR and NU/Public for voice and 

internet services through CDGW3, 

Authenticate remote users or remote offices on NR level); 

Access to the Public Information Access Gateway (PIA GW) – 

see annex B 

the Public Voice Services Access Gateway- this gateway 

plays an important role in the establishment of a voice (VOIP) 

and SMS interface from the public telephony domain to the 

NATO HQ UCC services; 

Support Remote VPN access (up to NR level)

Gateway 

CDGW4: 

NSEAPC 

CDGW5: NSNR 

CDGW6: Public 

>NS 


 

 

 

 


Service 

Automated transfer of documents and notifications between 

NATO registry and partners that are connected to the EAPC 

network. 

Support for information sharing between the Business LAN 

and the NS network, 

Transfer of the management information from the Business 

network to the NS network. 

the management information transfer from the Public network 

to the NS network 

Table 13.6Nature of ANWI cross domain information exchange per Cross Domain 

Gateway 

13.2.1.2-p2 Table 13.3 CDM generic SLTs shows the generic Service Level 

Target for providing all CDM based services. As and when there are different SLTs 

for a specific CDGW services this is listed as a specific CDGW service requirement. 

Service Level Target Parameters 

Capacity 

Capacity SLTs (6 months period) 

Number of Capacity Shortfall Incidents 2 

Number of Capacity Modifications 1 

Resolution Time for Capacity Adjustments (hours) 1 

Capacity Reserve (%) 25 

Availability SLTs (6 months period) 

Service Availability (%)(generic, may be overruled by specific SLTs in the 

remaining SLT requirements) 99.95 

Response Time (s) 


Duration of Service Interruptions (hours) 1 

Number of Service Availability Measurements 

Reliability SLTs (6 months period) 

Table 13.7CDM generic SLTs 



Shall be specified for each CDGW 

specifically 

 

Mean Time Between Failures (MTBF) (hours) 4380 

Mean Time Between Critical Failures (hours) 4380 

Number of Critical Failures 1 

Maintainability SLTs (6 months period) 

Mean Time To Replace / Repair (MTTR) (hours) 24 

Number of Corrective Maintenance Actions 

Number of Preventive Maintenance Actions 

Turnaround Time in Depot (hours) 

Transportation Time Between HQ and Depot (hours) 

Performance Parameters 

TBD 

Continuous 

 

 

 

 

TBD

13.2.1.2.1 CDGW1 Services 



13.2.1.2.1-p1 The CDGW1 shall support the following cross domain information 

exchange services as identified in Figure 13.10). 

13.2.1.2.1-p2 The CDGW1 shall support the following specific SLTs: 

A. Overall capacity of the CDGW1 capability 100 Mbps. 

B. Availability of cross domain voice services: 99.995% 

Figure 13.10 CDGW1 cross domain services 

13.2.1.2.2 CDGW2 Services 

13.2.1.2.2-p1 The CDGW2 shall support the following cross domain information 

exchange services as identified in Figure 13.11). 


A. Overall capacity of the CDGW2 capability 1 Gbps. 







13.2.1.2.2-p3 The contractor shall implement the following specific CDGW2 cross 

domain service requirements: 

13.2.1.2.2.1 Requirements applicable to e-mail: 

13.2.1.2.2.1-p1 The gateway shall provide bi-directional email with attachments 

between users of the NR business LAN and the NU WAN, NR WAN and via CDGW3 

with the Internet. 

13.2.1.2.2.1-p2 The gateway shall allow rewriting of header information such as 

‘from’ addresses so that the internal domain structure is concealed from external 

recipients. 

13.2.1.2.2.1-p3 

The gateway shall support aliases and distribution lists. 

13.2.1.2.2.1-p4 The gateway shall attempt to correct addressing errors in 

incoming email by trying to match the address with known NR domain recipients. At 

the minimum the following features shall be implemented: 

Closest match within sent domain correcting name typos, removing dots, 

dashes, and other non-alphabetic characters. 

matching to an alias list (e.g. for addresses known for miss-spelling). 

13.2.1.2.2.1-p5 All email shall be marked with classification and releasability 

labels by x-header extensions (e.g. by Titus Labs). This information shall be stripped 

from email traversing the gateway from NR to Internet and added to email travelling 

from Internet to NR. 

13.2.1.2.2.1-p6 All attempts to send NR e-mail to an external Internet or NU 

address shall generate an alert to a system administrator. 

13.2.1.2.2.1-p7 All attempts to send NR e-mail to external Internet or NU 

addresses shall be blocked and quarantined for manual inspection. 





13.2.1.2.2.1-p8 The gateway shall block unauthorized types of attachments or 

unreadable attachments. 

13.2.1.2.2.1-p9 In addition to the security label attached by the originator, all mail 

(including attachments) shall be automatically scanned to try to identify classified 

content. If such content is identified an alert shall be generated. If such content is 

suspected, the email shall be quarantined for manual inspection and then either 

released or logged as a violation. 

13.2.1.2.2.1-p10 All email passing through the gateway shall be scanned for 

viruses and other malicious content and appropriate action taken upon detection. 

13.2.1.2.2.1-p11 

specified domains. 

13.2.1.2.2.1-p12 

13.2.1.2.2.1-p13 

audit purposes. 

The gateway shall allow mail to be blocked to and from 

The gateway shall provide spam protection. 

The gateway shall keep a log of all email and attachments for 

13.2.1.2.2.2 Requirements applicable to Internet web access: 

13.2.1.2.2.2-p1 

World Wide Web. 

The gateway shall allow users of the NR domain to browse the 

13.2.1.2.2.2-p2 The gateway shall block all attempts toaccess any and all 

Business LAN NR services from NU/Internet. 

13.2.1.2.2.2-p3 

DMZ. 

13.2.1.2.2.2-p4 

All browsing shall be mediated by a proxy device in the gateway 

The gateway shall check all data for malicious content. 

13.2.1.2.2.2-p5 The gateway shall allow only a configured set of services and 

content types to be accessed from the NR domain. 

13.2.1.2.2.2-p6 The gateway shall open and inspect https and ssl content, and 

check external server certificates for validity. 

13.2.1.2.2.2-p7 

13.2.1.2.2.2-p8 

13.2.1.2.2.2-p9 

purposes. 

The gateway shall block all uncheckable encrypted data transfer. 

The set of domains accessible from NR shall be configurable. 

The gateway shall keep a log of all web access for audit 

13.2.1.2.2.3 Requirements applicable to telephony: 

13.2.1.2.2.3-p1 A VOIP gateway shall allow unified messaging services to be 

provided to users of the NR domain. 

13.2.1.2.2.4 Requirements applicable to remote access: 

13.2.1.2.2.4-p1 The gateway shall support Remote User (NRoI) capabilities for 

establishing NRoI VPN connection to the NR Business LAN by supporting access to 

the GDGW3 VPN services. 

13.2.1.2.2.4-p2 

PIA gateway. 

The remote user authentication solution shall integrate with the 





13.2.1.2.2.5 Requirements applicable to business to business connections: 

13.2.1.2.2.5-p1 The gateway shall support VPN relay capabilities for establishing 

NR B2B connections to trusted business partners through the NR extranet DMZ 

segments and the VPN capability of CDGW3. 

13.2.1.2.3 CDGW3 services 

13.2.1.2.3-p1 The ANWI Contractorshall provide a complete 

design/architecture for CDGW3 and as an option indicated how the PIA gateway 

services (see Annex B) can be integrated. 

13.2.1.2.3-p2 The CDGW3 shall support the following cross domain 

information exchange services as identified in Figure 13.12). 


A. Overall capacity of the CDGW3 capability 2 Gbps. 



13.2.1.2.3-p4 The contractor shall implement the following specific CDGW3 

cross domain service requirements: 




13.2.1.2.3.1 Requirements applicable to e-mail: 


13.2.1.2.3.1-p1 The gateway shall allow rewriting of header information such as 

‘from’ addresses so that the internal domain structure is concealed from external 

recipients. 

13.2.1.2.3.1-p2 

The gateway shall support aliases and distribution lists. 

13.2.1.2.3.1-p3 The gateway shall attempt to correct addressing errors in 

incoming email by trying to match the address with known NR domain recipients. 

13.2.1.2.3.1-p4 All attempts to send NR e-mail to an Internet address shall 

generate an alert to a system administrator. 

13.2.1.2.3.1-p5 All attempts to send NR e-mail to Internet addresses shall be 

blocked and quarantined for manual inspection. 

13.2.1.2.3.1-p6 The gateway shall block unauthorized types of attachments or 

unreadable attachments. 

13.2.1.2.3.1-p7 In addition to the security label attached by the originator, all mail 

(including attachments) shall be automatically scanned to try to identify classified 

content. If such content is identified an alert shall be generated. If such content is 

suspected, the email shall be quarantined for manual inspection and then either 

released or logged as a violation. 

13.2.1.2.3.1-p8 All email passing through the gateway shall be scanned for 

viruses and other malicious content and appropriate action taken upon detection. 

13.2.1.2.3.1-p9 

domains. 

13.2.1.2.3.1-p10 

The gateway shall allow mail to be blocked to and from specified 

The gateway shall provide spam protection. 

13.2.1.2.3.1-p11 The gateway shall be configured in accordance with Internet 

best practice recommendations. 

13.2.1.2.3.1-p12 

audit purposes. 

The gateway shall keep a log of all email message traffic for 

13.2.1.2.3.2 Requirements applicable to Internet web access: 

13.2.1.2.3.2-p1 

DMZ. 

13.2.1.2.3.2-p2 

All browsing shall be mediated by a proxy device in the gateway 

The gateway shall check all data for malicious content. 

13.2.1.2.3.2-p3 The gateway shall allow only a configured set of services and 

content types to be accessed from the NR business LAN through CDGW2. 

13.2.1.2.3.2-p4 The gateway shall open and inspect https and ssl content, and 

check external server certificates for validity. 

13.2.1.2.3.2-p5 

13.2.1.2.3.2-p6 

13.2.1.2.3.2-p7 

purposes. 

The gateway shall block all uncheckable encrypted data transfer. 

The set of domains accessible from NR shall be configurable. 

The gateway shall keep a log of all web access for audit 





13.2.1.2.3.3 Requirements applicable to telephony: 

13.2.1.2.3.3-p1 A public to NR voice gateway via CDGW2 shall support the 

secure interconnection of Public to NATO voice services at the NU level. 

13.2.1.2.3.3-p2 A VOIP gateway shall allow unifiedmessaging services to be 

provided to users of the NR domain via CDGW2. 

13.2.1.2.3.4 Requirements applicable to remote access: 

13.2.1.2.3.4-p1 The gateway shall include VPN termination capabilities for 

establishing NRoI VPN connection to the NR network. 

13.2.1.2.3.4-p2 The VPN solution shall be able to integrate with the PIA gateway. 

13.2.1.2.3.5 Requirements applicable to business to business connections: 

13.2.1.2.3.5-p1 The gateway shall include VPN termination capabilities for 

establishing NR B2B connections to trusted business partners. 



information exchange services as identified inFigure 13.13). 






13.2.1.2.4-p2 The CDGW4 shall support the following specific SLT: 


13.2.1.2.4-p3 The contractor shall implement the following specific CDGW4 

cross domain service requirements: 

13.2.1.2.4.1 The requirements for the bi-directional email with attachments: 

13.2.1.2.4.1-p1 All email and attachments passing from NATO to EAPC shall be 

checked for ‘releasable to EAPC’ security markings. 

13.2.1.2.4.1-p2 The device must be formally accredited to a level specified by a 

security risk assessment. 

13.2.1.2.4.1-p3 

security alerts. 

Attempts to send data not marked as releasable shall generate 

13.2.1.2.4.1-p4 The device shall be centrally managed by the NCIA Boundary 

Protection team at NCIA . 

13.2.1.2.4.1-p5 

13.2.1.2.4.1-p6 

The NEXOR Sentinel device shall be used. 

The email interface shall be SMTP. 

13.2.1.2.4.1-p7 Availability requirements shall dictate whether an online 

redundant configuration is required. 

13.2.1.2.4.2 The requirements applicable to directory services: 

13.2.1.2.4.2-p1 NCIA shall provide an LDAP service to populate a directory in the 

gateway with email addresses and other information of all users reachable in or 

through the NATO domain. The LDAP service shall read similar directory information 

published in the directory from the EAPC CIS and publish it in the NATO domain. 

The EAPC must provide a similar service to read NATO data and write EAPC data in 

the DMZ directory. (Note that security requirements shall determine if this should be 

a full or partial list of users). 

13.2.1.2.4.2-p2 

Device. 

The LDAP services shall be mediated by a Boundary Protection 

13.2.1.2.4.3 The requirements applicable to web browsing 

13.2.1.2.4.3-p1 A proxy service in the DMZ shall allow NATO users to access 

any web content published in the EAPC domain. 

13.2.1.2.4.3-p2 Web browsing from NS to the EAPC domain shall be mediated 

by a Boundary Protection Device. 

13.2.1.2.4.3-p3 The Boundary Protection Device shall prevent any access to the 

NATO domain from the EAPC domain. 

13.2.1.2.4.4 The requirements applicable to file transfer: 

13.2.1.2.4.4-p1 The Boundary Protection Device shall allow authorised users in 

the NATO domain to read and write data directly onto data stores in the EAPC 

domain. 




13.2.1.2.4.5 The requirements applicable NS extranet services: 


13.2.1.2.4.5-p1 The Boundary Protection Device shall ensure that any (web/file 

services) allow authorised users in the NATO domain to read and write data directly 

onto data stores in the EAPC domain. 

13.2.1.2.4.5-p2 The Boundary Protection Device shall ensure that any 

information on the extranet DMZ is labelled releasable EAPC. 

13.2.1.2.4.5-p3 For the transfer of CIS management information, CDGW4 shall 

comply with all requirements as stated for CDGW6, which is essentially only a CIS 

management gateway. 







13.2.1.2.5-p3 Automatic data transfer from NS to NR security domain shall be 

limited to data classified up to and including NR and agreed file format and protocols 

(the BPCs shall be able to validate the format and content).Encrypted on 

“unreadable” (via the BPCs) data shall be not permitted. 





13.2.1.2.5-p4 Initially automatic data transfer shall be limited to short 

notification about new e-mail on NS (standard text (classified NU), no attachments, 

no sensitive data included in message (header and message body)). 

13.2.1.2.5-p5 At the moment there is no accredited solution in NATO which 

supports all these services. Lack of evaluated guards is another issue. From these 

reasons the services to be supported by the CDGW5 have been limited to the 

following list: 

A. Email shall be allowed from the NR to the NS security domain. 

B. Notification mail, stripped from all sensitive andclassified NC or above 

content, shall be sent from the NS to the NR securitydomain. 

C. File transfer shall be allowed from the NR to the NS security domain. 

13.2.1.2.5-p6 In the future, when appropriate guards shall be available, this list 

can be extended to support additional services initially requested by the NATO HQ 

users. 

A. Communication via NR-NS interconnection shall be limited to authorized 

file formats and network protocols (the BPC shall be able to validate the 

format of exchanged data). 

B. Information exchanged via the interconnection shall follow NATO labelling 

schema (Ref. 1.1.1.6.12 and 1.1.1.6.13). 

C. The interconnection shall be implemented in accordance with Ref. 

1.1.1.6.4. 

D. For the protocols being transmitted sufficiently secure and evaluated 

BPDs (e.g. guards) shall be used. 

E. There shall be logging and auditing in accordance with Ref. 1.1.1.6.5 and 

1.1.1.6.4. 

F. The BPDs (e.g. mail guard) shall be evaluated at least to EAL4. 

G. GW5 NS->NR: There shall be non-repudiation of origin (not mandated if 

only notifications are sent from NS to NR). 

H. GW5 NS->NR: There shall be label checking. 

i. GW5 NS->NR: There shall be content checking (including, but not limited 

to, “dirty words”, file type). 

13.2.1.2.5-p7 For the transfer of CIS management information, CD GW5 shall 

comply with all requirements as stated for GW6, which is essentially only a CIS 

management gateway. 











13.2.1.2.6-p3 Gateway 6 (CDGW6), the Public>NS gateway, currently only 

supports the transfer of CIS Management information from the public network to NS. 

It shall provide the infrastructure to support centralized management of CIS 

components residing in the public network, from the NS management network. 

13.2.1.2.6-p4 The CDGW6 shall support the cross-domain transfer of: 

A. Event messages. 

B. (Externally originating) trouble tickets. 

C. Status updates. 

D. Statistics from CIS components and environmental sensors. 

E. Configuration data. 

F. IP and service routing information. 

13.2.1.2.6-p5 The message format exchanged across the gateway is typically 

structured XML or XML encapsulated bulk data. 

13.2.1.2.6-p6 Due to the one way data transfer via a diode, manual intervention 

shall be needed to provide “high to low” feedback if and when required. 

A. CDGW6 shall provide the cross-domain management information 

exchange gateway "Public and Extranet - NS Management Network". This 

is used for "AIS & N/ELM - IOSS" management information exchange. 

B. The initial cross-domain management information exchange, provided by 

CDGW6, shall be unidirectional low-to-high only (using a data-diode). It is 

anticipated that controlled bidirectional exchange of management traffic 

shall be available at a later stage. 







C. The N/ELM, within the Public network shall forward notifications of 

element, interface and (service) status changes to the IOSS (located in 

NS) through CDGW6. 

D. The AIS/service manager, within the Public network, shall forward 

notifications of service status changes to the IOSS (located in NS) through 

CDGW6. 

E. When/where the exchange of cross-domain management information is 

limited to low-to-high, the AIS/service manager and N/ELM shall 

independently schedule discoveries of configuration and topology 

changes. The AIS/services manager and N/ELM shall compare to a local 

CMDB and sent changes to the IOSS through CDGW6. 

F. Cross domain management information exchange, through CDGW6, shall 

be based on the exchange of XML messages. 

G. CDGW6 shall provide inspection (access and flow control) verifying all 

incoming messages. Only messages corresponding to a known and 

allowed message flow shall be forwarded. 

H. CDGW6 shall provide viruses and malicious code scanning. 

i. CDGW6 shall interface with the AIS manager and the N/ELM on one side 

and the IOSS on the other side through the SMC enterprise service bus 

(ESB) infrastructure. 

J. CDGW6 shall provide release control. This implies: Ensure that the 

message corresponds to the defined cross-domain messaging policy. Not 

authorised messages/sources/destinations shall be dropped, archived and 

logged. 

K. CDGW6 shall have a message firewall function allowing only permitted 

message flows. Other messages and flows are blocked and logged. A 

notification is sent on policy violation to the IOSS. 

L. The SMC/CDGW6 shall anticipate the future availability of an accredited 

bidirectional cross-domain management information exchange gateway 

between the public network and the NS IOSS management network. This 

capability is not likely to be available before initial deployment. 

M. A future bidirectional CDGW6 shall allow low-to-high status updates (from 

AIS manager to IOSS and from N/ELM to IOSS), on demand (requested 

from IOSS) low-to-high topology updates (e.g. routing table, connectivity 

discovery), on demand (requested from IOSS) low-to-high statistics 

forwarding; and high-to-low configuration management (IOSS to N/ELM 

and IOSS to AIS manager). 

N. When at a later stage CDGW6 allows controlled bidirectional transfer of 

management information, the IOSS shall be able to deploy configuration 

changes directly (through a human approval mechanism), request on 

demand polls of status and configuration, and request on demand polls for 

statistics counters from network elements. Requests from the IOSS are 

executed through the AIS manager or N/ELM in the destination security 

domain. 

13.2.1.3 Management 

13.2.1.3-p1 It is assumed that all the gateways shall be managed by the same 

CIS Operating Authority (CISOA) (e.g. NCIA ). Where technically feasible, the



Boundary Protection Components shall be centrally managed, if possible, from 

existing management environments (e.g. centralized firewall management from NCIA 

SMD facilities at SHAPE) – see also 13.2.13. 

A. The management of the cross domain gateway's Mail guard components 

shall be centralized from the high side (typically using a SSH2 terminal 

connection). 

B. The management of the cross domain gateway's XML guard components 

shall be centralized from the high side (typically using a SSH2 terminal 

connection). 

C. The management of the cross domain gateway firewall components shall 

be centralized from the high side. 

D. The management of Ethernet switching and IP routing component of cross 

domain gateways shall be done from the N/ELM located in the security 

domain that it belongs to. 

E. The management of Data Diode components of cross domain gateways 

shall be done from the N/ELM located in the security domain that it 

belongs to. 

F. The management of the cross domain components in the CIS 

management function of CDGW4, CDGW5 and CDGW6 shall be possible 

from the local management LAN and shall be possible centrally from NCIA 

. 

13.2.1.3.1 Firewall management 

13.2.1.3.1-p1 It is assumed that firewalls shall be centrally managed by NCIA , 

similarly as it is conducted nowadays. Currently (2Q 2012) NCIA manages firewalls 

from management servers on NU and NS level from facilities at SHAPE (and backup 

facilities at Brunssum, NL). NCIA supports two firewall products: CheckPoint and 

PaloAlto Networks. Both of them are managed from appropriate management 

servers (Provider-1 and Panorama respectively) and dedicated management 

workstations at NCIA SMD. Local staffs (from sites where firewall enforcement 

modules are installed) in general have no admin rights and can conduct only basic 

tasks related with enabling connectivity with management servers. They can have 

also access to logs from “their” firewall only. 

13.2.1.3.1-p2 Firewall monitoring is integrated with NCIRC. Security events 

from firewalls are initially submitted to Firewall Management Server, and later to 

appropriate ArcSight Connector and ESM. Example of Figure 13.16 illustrates how it 

works in case of CheckPoint Firewall: 

A. The logs from the firewall enforcement module, and firewall system health 

status information are sent to a central management server Provider-1. 

B. From Provider 1 logs are sent via the ArcSight Connector for CheckPoint 

firewall to the ArcSight Manager, for analysis and correlation with logs 

from other devices. 

C. Finally the logs are stored in an ArcSight database at NCIRC. 





Figure 13.16 Current Central Firewall Management Solution 

13.2.1.3.1-p3 The ANWI Contractor shall be responsible for the installation and 

initial configuration (to set up network connectivity) of firewalls according to 

instructions and procedures provided by NCIA SMD. 

13.2.1.3.1.1 Guard management 

13.2.1.3.1.1-p1 It is assumed, that guard management also shall be centralized 

and that guards included in ANWI CDMs shall be managed by NCIA SMB in similar 

ways as nowadays. 

13.2.1.3.1.1-p2 As most of the guards currently (2Q 2012) used within NATO 

supports local management system console, NCIA uses console server (e.g. Avocent 

Advanced Console Server) connected directly to console port of the guard. The 

console server is accessible from designated NCIA SMD servers/workstations via 

ssh over NS WAN. Copy of guard configuration is stored on management server at 

NCIA SMD. Logs from guards are uploaded to log server at NCIA SMD and provided 

to NCIRC (via appropriate ArcSight Connector) for analysis 





Figure 13.17 Current Central Guard solution 

13.2.1.3.1.1-p3 If the integration of the solution selected for ANWI with the 

existing (at ANWI implementation time) centralized guard management capabilities 

shall be technically feasible, the ANWI Contractor shall be responsible for installation 

and initial configuration (to set up network connectivity) of the guards according to 

instructions and procedures provided by NCIA SMD. 

13.2.1.3.2 Data diode servers management 

13.2.1.3.2-p1 At the time of writing (2Q 2012), implementation of centralized 

management of data diode servers within NATO is on progress. It is assumed that 

data diode servers provided by ANWI shall be managed in a similar way as the 

current management. 

13.2.1.3.2-p2 Currently NCIA SMD has management servers deployed in NU 

and NS management LANs. Management (including configuration and log storage) is 

very similar to guard management, but this time NCIA connects directly to the diode 

servers (and not to console servers) via ssh over PAN or NS WAN. Low servers are 

managed from NU centralized management facilities and high servers from NS, as 

presented on Figure 13.18 below 





Figure 13.18 Current Central Data Diode solution 

13.2.1.3.2-p3 If the integration of the solution selected for ANWI with the 

existing (at ANWI implementation time) centralized diode management capabilities 

shall be technically feasible, the ANWI Contractor shall be responsible for installation 

and initial configuration (to set up network connectivity) of the diode servers 

according to instructions and procedures provided by NCIA SMD. 

13.2.1.4 Integration 

13.2.1.4-p1 The ANWI contractor is responsible for integration (reuse) of the 

following CDM components/services into the CDM architecture that shall be available 

as PFE: 

A. PIA: the PIA GW services as available through the PIA GW contract (see 

Annex B) shall be used to compose the ANWI CDGW3 capability. 

B. Intrusion detection services. CDM network and host based IDS services 

shall be integrated with NCIRC FOC as specified in section 13.2.2.4. 

C. (Optional) Integration of reused components and SW licenses of the 

Current Gateway Components (to be decided after contract award): 

1. CDGW 1 and CDGW 2/3 Web and Messaging Proxies and Content 

Filtering including AV for HTTP/FTP (see SM06-SM09) 

2. CDGW 1 and CDGW 2/3 inner and outer perimeter and application 

firewalls and routers-switches (SM14, 15, 18-20 22). 







D. SMC: Integration with ANWI and Central Management SMC services. 

E. AV: Integration with the ANWI and central AV management services as 

specified in 13.2.2.3 

13.2.2 AV management 


13.2.2.1-p1 IA agents and software shall be installed on all servers and clients 

and IA platforms in the NNHQ and are integrated with Processing Services, Client 

Provisioning Service, CDM and UCC Services as service features. (called end-point 

AV services). 

13.2.2.1-p2 On each of the ANWI security domains a redundant AV 

management server capability shall be installed that shall manage and distribute AV 

updates to the end-points. 

13.2.2.1-p3 AV updates are obtained through the centrally managed AV 

updates test and verification facility as managed by NIATC and are available for the 

McAfee, Kasperski, and TrendMicro. 


13.2.2.2-p1 The AV management service is required for each of the ANWI 

security domains and for the CDM elements. AV management services shall comply 

with the SLT as specified in Table 13.4 AV management SLT. 

13.2.2.2-p2 The AV management service shall retrieve updates from the 

centralisedNIATC AV management server/portal. 

Service Level Target 

Parameters 

Capacity 

Capacity SLTs (6 months 

period) 

Number of Capacity Shortfall 

Incidents 

Number of Capacity 

Modifications 

Resolution Time for Capacity 

Adjustments (hours) 


Availability SLTs (6 months 

period) 

Service Availability (%) 99.95 


Number of Service 

Interruptions 

Duration of Service 

Interruptions (hours) 

Number of Service 

Availability Measurements 

Reliability SLTs (6 months 

Sufficient AV management server processing and network capacity to manage and update 

all the NATO HQ IT platforms within 2 hours as and when new updates are published by 

NIATC. 

2 

1 

1 

 

1 

1 

Continuous




Parameters 

period) 

Mean Time Between Failures 

(MTBF) (hours) 

Mean Time Between Critical 

Failures (hours) 


Maintainability SLTs (6 

months period) 

Mean Time To Replace / 

Repair (MTTR) (hours) 

Number of Corrective 

Maintenance Actions 

Number of Preventive 


Turnaround Time in Depot 

(hours) 

Transportation Time 

Between HQ and Depot 

(hours) 


TBD 

4380 

4380 

24 

 

 

 

 

TBD 

Table 13.8AV management SLT 


13.2.2.3-p1 Updates for NS network can be downloaded directly from NIATC 

server and not manually transferred from NU via air gap as it is done nowadays. 

13.2.2.3-p2 Alerts from AV management server shall be submitted to NCIRC via 

appropriate ArcSight Connector. 


13.2.2.4-p1 Besides the integration of the ANWI AV management servers into 

the NIATC AV management structure there is an option requirement to 

integrate/reuse Malware solutions as in use today: 

A. Optional reuse and integration of Current Malware SW licenses: 

1. Malware protection for server (see SM01) 

2. Malware protection for client (SM02) 

3. Malware protection for PDA (SM03) 

4. Malware protection for email server (SM04) 

5. Malware protection for Web server (SM05) 

13.2.3 NPKI 


13.2.3.1-p1 The NPKI architecture is predominantly hosted on the NATO wide 

NS and NR infrastructures. The NATO HQ infrastructures are aligned with the NPKI 





for all four security domains where for the NS and NR the RA function is delegated to 

the local HQ security Authority. 

13.2.3.1-p2 

User level certs and CRLs are distributed using NEDS. 

13.2.3.1-p3 NPKI support for NU and EAPC domains shall be provided through 

the NS and NR domain implying that the CDGW4 and CDGW 2 and 3 will need to 

support (in addition to NPKI based user services) NPKI management services. The 

NPKI architecture is further specified Annex B. 


13.2.3.2-p1 The NPKI service is required for each of the ANWI security domains 

and for the CDM elements. Related to the NATO HQ ANWI supported RA servers 

the following SLTs are applicable: 


Capacity 




Resolution Time for Capacity Adjustments 1 

(hours) 







Number of Service Availability 

Measurements 


Mean Time Between Failures (MTBF) 

(hours) 

Mean Time Between Critical Failures 

(hours) 



Mean Time To Replace / Repair (MTTR) 

(hours) 

Number of Corrective Maintenance 

Actions 

Number of Preventive Maintenance 

Actions 

Turnaround Time in Depot (hours) 

Transportation Time Between HQ and 

Depot (hours) 


TBD 

Sufficient capacity to handle Certificate Requests for all NPKI dependent 

applications (tokens, user authentication, VPN, Application Services, CDM, 

NAC/NAP) 

 

Continuous 

4380 

4380 

24 

 

 

 

 

TBD 




Table 13.9NPKI NATO HQ RA SLT 



13.2.3.3-p1 The Local NPKI based management is an integrated (delegated 

part of the NPKI management) and is described in Annex B. 

13.2.3.3-p2 The RA shall be locally operated and managed. Main management 

efforts are to ensure that the Directory Services based interfaces (NEDS) are 

operational in the NCIA centrally managed NPKI infrastructure (e.g. the CA and Sub- 

CA’s). 

13.2.3.3-p3 Alerts from RA servers shall be submitted to NCIRC via appropriate 

ArcSight Connector. 

13.2.3.3.1 Integration 

13.2.3.3.1-p1 The ANWI project shall integrate for all its PKI services into the 

NPKI infrastructure. 

13.2.4 Incident Management 


13.2.4.1-p1 The NATO HQ incident management services are an integrated part 

of the NATO (Alliance) wide Incident management infrastructure that on the NATO 

side is realised via the NCIRC FOC project. 

13.2.4.1-p2 IA agents and software shall be installed on all servers and clients 

in the NNHQ. Network-based IDS shall be part of CDM. Placement of online 

computer forensicsand Full Packet Capture shall be coordinated with NCIRC FOC. 


13.2.4.2-p1 The incident management service is required for each of the ANWI 

security domains and for the CDM elements. The NATO HQ SLTs are directly 

derived from the NCIRC FOC SLTs: 


Capacity 


Number of Capacity Shortfall 

Incidents 

Number of Capacity 

Modifications 

Resolution Time for Capacity 

Adjustments (hours) 


Availability SLTs (6 months 

period) 



Sufficient capacity to locally manage, analyse, collect, store and forward all logging 

based incidents and required reports to NCIRC FOC. 

2 

1 

1 

 







Duration of Service Interruptions 

(hours) 

Number of Service Availability 

Measurements 

Reliability SLTs (6 months 

period) 


(MTBF) (hours) 

Mean Time Between Critical 

Failures (hours) 


Maintainability SLTs (6 months 

period) 

Mean Time To Replace / Repair 

(MTTR) (hours) 

Number of Corrective 


Number of Preventive 


Turnaround Time in Depot 

(hours) 

Transportation Time Between 

HQ and Depot (hours) 


TBD 

1 

Continuous 

4380 

4380 

24 

 

 

 

 

TBD 

Table 13.10NPKI NATO HQ RA SLT 


A. The ANWI Incident Management services shall fully integrate into the 

NCIRC FOC IDS and FPC management. 

B. The ANWI Incident Management services network interface shall be 

provided via a redundant VPN interface to the NCIRC FOC management 

capability. 

13.2.4.3.1 NCIRC sensor management: ID/PS, OCF and FPC management 

13.2.4.3.1-p1 Current management of IDS sensors (network- and host-based) 

and online computer forensic and full packet capture is conducted by NCIRC. Note: 

According to [Ref 1.1.1.6.49], forensic packet capture should be installed in: 

A. NU/NR networks: Gateways, then remote sites. 

B. NS: Gateways, then backbone nodes and optionally remote sites. 

13.2.4.3.1-p2 At the time of writing (2Q 2012), NCIRC has implemented two 

management and monitoring centres: 

A. NU level for monitoring unclassified NATO systems and their connection 

to the Internet – NCIRC TC NU. 

B. NS level for monitoring NS systems and their interconnection to NS WAN 

and/or Mission systems – NCIRC TC NS. 





13.2.4.3.1-p3 NCIRC FOC project will enhance existing infrastructure, 

implement additional sensors at critical sites and “upgrade” NCIRC TC NU 

management environment to NU/NR level. When NCIRC FOC will be completed, 

NCIRC will be able to manage sensors located in NU, NR, NS and MS domain and 

collect logs from different BPCs (e.g. firewalls) located within all of these domains as 

illustrated on Figure 13.19 below. 

NCIRC TC 

NCIRC TC NR 

NCIRC TC NS 

TIER 2 – NCIRC Technical Centre 

SIEM 

Other NCIRC services 

Management 

Servers/ Log collection - NR 

SIEM 

Other NCIRC services 

Management 

Servers/ Log collection - NS 

Management 

Servers/ 

Log collection - NU 

BPS 

Management 

Servers/ 

Log Collection - MS 

BPS 

TIER 3 – CIS Operating Authorities 

Management 

servers - NU 

Internet 

NGCS 

Management 

servers - NR 

Management 

servers - MS 

NGCS 

Management 

servers - NS 

sensors/agents - NU 

sensors/agents – NR 

sensors/agents - MS 

sensors/agents – NS 

Figure 13.19 NCIRC sensors management 

13.2.4.3.1-p4 Architecture of NCIRC TC NR and NCIRC TC NS is similar and 

consists of: 

A. Management Servers for each type of sensor/product managed by NCIA 

System Management Division (SMD). 

B. ArcSight Connectors for collecting events from different product/sensors 

(e.g. firewalls, network- and host based-IDS/IDP). 

C. Arcsight Enterprise Management Systems (EMS) collecting events from 

ArcSight Connectors and performing event correlation and analysis. 

D. ArcSight database – for mid-term storage of collected events. 

13.2.4.3.1-p5 To manage and monitor network-based IDS/IDP sensors NCIRC 

currently (2Q 2012) uses small dedicated VPN gateways connected directly to an 

interface of network-based IDS. Similar approach will be used for NCIRC FOC. 

Events from the sensors are submitted via VPN tunnel over NGCS (for NS and NR 

(in the future)) or Internet (for NU) to IDS/IDP Management server located at NCIRC. 

From this server, events are sent via appropriate ArcSight Connector to Arcsight 

Enterprise Management System (used for event correlation and analysis). Sensor 

management is performed from the Management Server at NCIRC - policies and 





configurations are pushed from this server to sensors via VPN tunnel over NGCS (for 

NS and NR (in the future)) or Internet (for NU). 

13.2.4.3.1-p6 Management/event monitoring for forensic packet capture 

devices is performed in similar way. The ANWI Contractor shall be responsible for 

installation and initial configuration (to set up network connectivity) of IDS/IDPs, OCF 

and FPCs according to instructions and procedures provided by NCIRC. 

Figure 13.20: Current NCIRC solution 


13.2.4.4-p1 All ID/PS based products shall be in line with NCIRC FOC and 

provided as PFE to the ANWI contractor. 

13.2.4.4-p2 ANWI contractor shall integrate the NCIRC FOC agents with all 

ANWI platforms (all servers all CDM elements). 

13.2.5 Security Patches and Configuration Management 

13.2.5-p1 See 13.1 





SECTION 14. ANNEX F: INFRASTRUCTURE SERVICES 

14.1 APPENDIX 1: Introduction to Infrastructure Services 


14.1.1-p1 The infrastructure services are fundamental services that are metered 

and also provide capabilities to support and deliver other services (IaaS). These 

capabilities will allow the other consuming services to be able to operate and offer 

user features. 

14.1.1-p2 The infrastructure services can be perceived as platform services 

closely linked to the Information and Communication Systems equipment, in short: 

the ANWI platform. This service shall be used to host other Core Enterprise Service’ 

specific CoI or enabling CoI services in support of user applications and/or to be 

accessed by user devices. 

14.1.2 Service Overview 

14.1.2-p1 The Infrastructure service shall provide the service provider 

(Contractor/ICTM) with the infrastructure, software and management solution to 

effectively assign resources for other services, application hosting and user 

provisioning. 

14.1.2-p2 Besides the physical hardware (e.g. servers, storage and switches) it 

shall also provide the virtualization and Operating system layer as well as the 

standard infrastructure service features (e.g. authentication, file sharing, etc.). 

14.1.2-p3 Advanced management and security products and features (e.g. QoS, 

I/O optimization and data guards) shall provide infrastructure resources to be 

assigned to specific services. 

14.1.3 Scope 

14.1.3-p1 The capabilities that shall make up the infrastructure services platform 

are: 

A. Physical Data Centre (Mechanical and Electrical) – Provided as PFE. 

B. Processing service (Physical Servers). 

C. Storage service (data storage). 

D. Virtualization Capability. 

E. Networking service (Wired and Wireless LAN). 

F. Cross-Domain Modules (Border Protection and monitoring): 

G. Operating Systems (Windows, UNIX, Linux). 

H. Infrastructure Network Services capabilities: 

1. Identification and Authentication (based on MS Active Directory/NPKI). 

2. Network access control solution to protect the network. 

3. Supporting services like DNS, DHCP, time services, etc. 

4. File serving. 

5. Web Browsing (Proxy). 

6. Printing and scanning. 





14.1.3-p2 Figure 14.1 provides an overview of the Infrastructure Services mapped 

to the Services Taxonomy as introduced in Annex C as represented by the blue 

section. 

Figure 14.1: Infrastructure overview 

14.1.4 Service Requirements 

14.1.4-p1 The Contractor shall design the infrastructure capabilities to deliver the 

required ANWI Infrastructure Services as specified in Appendices 14.2-14.6. 

14.1.4-p2 The Contractor shall clearly describe how the service and the individual 

components are integrated into the Service Management and Control (SMC) and 

Information Assurance Services to support the overall ICT SMC and IA management 

concept as indicated in figure 14.1 and defined in Annex E. 

14.1.4-p3 The Infrastructure Services shall be sized to support all the current 

applications and the expected near future applications (Annex B). 

14.1.4-p4 The physical Data Centre capabilities shall be provided as PFE (Annex 

B). The Contractor shall use no more than 50% of the total allocation of power, 

cooling and floor space in his calculations as the data centre is shared with other 

PFE services. 







14.1.4-p5 The Contractor shall base his estimates for sizing of the infrastructure 

capabilities on the requirement figures provided later in this section. 

14.1.4-p6 Infrastructure shall be available on all 4 networks – NATO SECRET, 

EAPC SECRET, NR and PUBLIC. 

14.1.4-p7 Under appropriately protected configurations, different network 

classifications may be consolidated on the same infrastructure (Hardware) but 

virtually separated. Only NATO accredited or National COMSEC approved solutions 

shall be offered. In case of National COMSEC approved solutions the ANWI 

Contractorshall still hold responsibility for the security accreditation effort under the 

ANWI scope. In case of rejection the ANWI contractor shall be responsible for 

alternative solutions to satisfy the requirements in the contract without cost impact 

(overall TCO impact). 

14.1.5 Service Level Agreement/Targets 

14.1.5-p1 As indicated in the definition, the Infrastructure Service provides the 

base capabilities for all other services and as such shall have the highest required 

availability. 

14.1.5-p2 The Infrastructure Service shall have a service availability of 99.99% 

across both server rooms. This availability figure shall be achieved end-to-end over 

all underlying infrastructure sub-services unless otherwise specified. 

14.1.5-p3 For some of the sub-services described in the appropriate appendix, 

some performance degradation is acceptable in case of a catastrophic failure (ex. 

Server room failure). More details are found in the corresponding Infrastructure 

Services appendices. 

14.1.5-p4 The ANWI contractor shall provide an additional 25% capacity for all the 

required infrastructure services to host additional information and application 

services. The infrastructure services shall provide a flexible capacity expansion 

beyond the required 125%. 

14.1.6 Service Testing and Reporting 

14.1.6-p1 The Infrastructure Services are managed through the SMC and shall 

provide the Service Level Target (SLT) metrics reporting on each infrastructure subservice 

to measure the compliance of the service against the defined Service Level 

Agreement (SLA). 

14.1.6-p2 Individual sub-services shall be tested for compliance against the 

technical requirements of the specific sub-service. 

14.1.6-p3 Overall end-to-end infrastructure integration tests shall be conducted to 

verify the integration of the individual capability into the Infrastructure Service. These 

integration tests shall also include the measurement metrics supporting the SMC and 

IA capabilities and requirements. 

14.1.7 Dependencies 

14.1.7-p1 The Infrastructure Service interfaces with several different entities and 

the Contractor shall identify, assess and mitigate these risks in the service’s design 

and shall log these risks in the Risk Register.



14.1.7-p2 The ANWI Infrastructure Services shall interface with and integrate to 

the external context as shown in figure 14.2 consisting of the following major entities 

(for more information see Annex D: 

A. NGCS 

B. NATO services. 

C. Commercial Network Services. 

D. Active and Passive Building Facility related services. 

E. Business Application services. 

Figure 14.2: External interfaces 

14.1.7-p3 The ANWI Infrastructure Services shall interface with the external 

NATO CIS services (for more information, see Annex B). 


Commercial Networks Services (for more information, see Annex B). 


Active and Passive Building Facility Related Services (for more information, see 

Annex B). 

14.1.7-p6 The ANWI Infrastructure Services shall interface with the Business 

Applications (for more information, see Annex B). 




14.2 APPENDIX 2: Processing Services 





14.2.1-p1 The processing service is an essential back-end of the Infrastructure 

Service providing the resources (CPU and memory) to host core and functional 

applications. 

14.2.2 Scope/Scenario 

14.2.2-p1 The processing service is a critical component of the Infrastructure 

Service that shall use the latest NATO approved OS including updates and patches. 

14.2.2-p2 The processing service shall deliver physical and virtual servers in a 

resilient configuration, spread over two server rooms to host other services and 

applications. 

14.2.2-p3 The processing service shall provide server consolidation through 

virtualization to optimize the use of available processing resources supporting the 

running of multiple services on the same physical hardware. 

14.2.2-p4 The ANWI Contractor shall size the processing service to support all 

ANWI services in this SOW with additional 25% free resources (CPU and memory) to 

support expected near-future applications. To support the current Business 

Applications the contractor shall provide processing resources to provision the 

amount of servers as indicated in the table (ICTM apps) in section 14.2.3.4 Table 

14.1. 

14.2.2-p5 The ANWI Contractor’s processing service shall be designed to easily 

expand the service for future growth, beyond the provided 25% identified above. 


14.2.3.1 Domains 

14.2.3.1-p1 The ANWI Contractor shall deliver and install processing services 

on all 4 networks – NATO SECRET, EAPC SECRET, NR and PUBLIC in a high 

available configuration across the two NNHQ server rooms to create a NNHQ data 

centre. 

14.2.3.2 Location 

14.2.3.2-p1 The ANWI Contractor’s server room design shall be planned around 

the building’s physical layout provisions and constraints (a representative Server 

Room layout is provided in Annex B): 

A. The current server room design has enough floor space for 100+ racks per 

server room. 

B. It has raised floors, with cold air entering from below the floor. 

C. Racks are placed in 10 rows, with the backs of a pair of racks covered, 

thus creating hot aisles. 

14.2.3.2-p2 

14.2.3.2-p3 

Power distribution is located above the racks. 

The average cooling capacity per Server Room rack is 3.2 kW.





14.2.3.2-p4 The total heat that can be dissipated by the cooling system per 

Server room is 378kW (7 CRACs of 54kW each). 

14.2.3.2-p5 

The average power per double row of racks is 72kW. 

14.2.3.2-p6 Each server room has up to 360kW of available electrical power, 

supported by UPS, in fully redundant mode. 

14.2.3.2-p7 The ANWI Contractor provided server room concept shall ensure 

that: 

A. All server power supplies shall be at least 90% efficient. 

B. All server processors shall support power management. 

C. The processing service design shall specify server consolidation. 

D. The processing service design shall specify flexibility and scalability to limit 

overprovisioning. 

14.2.3.2-p8 The processing service design shall specify "virtualization, unless 

specifically not recommended by specific software vendor or test results confirm the 

need for physical servers, AND approved by Purchaser". 

14.2.3.2-p9 

components. 

14.2.3.2-p10 

solution. 

The processing service design shall specify standardization of 

The processing service design shall specify a high available 

14.2.3.3 Minimum Hardware Procurement Specifications (MHWPS) 

14.2.3.3-p1 The ANWI shall comply with the following hardware and software 

requirements, over and above those requirements identified in the minimum 

hardware procurement specifications (MHWPS see 1.1.1.5.1); the server shall 

comply at minimum with the GP server or blade server requirements from the 

MHWPS. 

14.2.3.3-p2 

The server shall support 2 to 4 processors. 

14.2.3.3-p3 The server processor shall be x64 AND x86 compatible (or any 

future generation processor, if mainstream by 2015). 

14.2.3.3-p4 The memory modules shall be current technology, and in line with 

the server specifications and shall be installed according to the brand’s specifications 

to ensure optimal performance. 

14.2.3.3-p5 All servers (physical and virtual) shall support IPv4 and IPv6 in a 

dual stack configuration. 

14.2.3.3-p6 All servers shall have redundant connections to the LAN and the 

storage network. 

14.2.3.3-p7 All servers shall have an option for adding extra connectivity 

hardware; minimum expansion of 1 LAN and 1 SAN 

14.2.3.3-p8 

specifications. 

14.2.3.3-p9 

from SAN 

The hardware shall be current technology, in line with the server 

There shall be a minimum of 60 GB per server and support for Boot


14.2.3.3-p10 The controller shall support RAID 1. 

14.2.3.3-p11 

later. 

14.2.3.3-p12 

14.2.3.3-p13 


The server shall be certified for Windows Server 2008 R2 SP1 or 

The server shall be certified for VMware vSphere 5 or later. 

The server shall be 19" rack mountable, directly or in an enclosure. 

14.2.3.3-p14 Operating temperature: The servers shall be able to operate at 

maximum efficiency in between 10°C - 35°C. 

14.2.3.3-p15 

The servers shall have an infrastructure management port. 

14.2.3.4 Scaling per Network Classification 

14.2.3.4-p1 The ANWI Contractor shall scale the processing services for each 

classification as identified below: 

NS EAPC Business Public 

ANWI Core TBD by Ctr TBD by Ctr TBD by Ctr TBD by Ctr 

ICTM Apps 500 10 1000 50 

ESS - - Post EDC - 

BMS 

Post EDC 

AVI Post EDC Post EDC Post EDC Post EDC 

Table 14.1 Processing service scaling 

14.2.3.4-p2 For ICTM Application 15% of the servers cannot be virtualised, the 

remaining servers can be virtualised with the same scalability as defined in 14.2.3.4- 

p4. The total number of ICTM Application servers is across both server rooms. 

14.2.3.4-p3 The ANWI Contractor’s design shall provide information on how the 

processing capability shall be scaled based on the requirement that virtualization is 

the preferred design approach, but recognising that physical servers may still be 

required beyond the virtualization host servers. 

14.2.3.4-p4 

server: 

14.2.3.4-p5 

14.2.3.4-p6 

The ANWI shall provide the following minimum resources per virtual 

There shall be at least one core per two virtual servers. 

Physical and Virtual Servers shall have a minimum 4 GB RAM. 

14.2.3.4-p7 Connectivity of the physical server shall be at least 0,25 Gbps per 

virtual server to LAN and storage network. 

14.2.3.4-p8 The ANWI Contractor design and implementation shall build the 

ANWI with COTS standard components acknowledging that the final distribution of 

processing components across the different classifications shall be optimized at the 

latest possible stage (such that the overall processing requirement is unchanged but 

noting that a reduction of processing requirement on the NS network are 

compensated with a comparable increase in processing on the Business network). 



14.2.3.5 Virtualization and OS Baseline 





14.2.3.5-p1 The ANWI Contractor’s ANWI design and implementation shall 

provide the following hypervisor features: 

14.2.3.5-p2 

The hypervisor shall provide administrative tools for management. 

14.2.3.5-p3 The server virtualisation design shall not be impacted by the 

hypervisor limitations. 

14.2.3.5-p4 

16. 

14.2.3.5-p5 

14.2.3.5-p6 

14.2.3.5-p7 

14.2.3.5-p8 

The maximum amount of physical server per cluster shall be at least 

The hypervisor shall support High Availability options. 

The hypervisor shall support Live Migration of VM's. 

Thin provisioning shall be supported by the hypervisor. 

Virtual switches shall be supported by the hypervisor. 

14.2.3.5-p9 The Hypervisor shall support use of MS Windows Server and 

Desktop OS's, Linux OS's, Unix Os's. 

14.2.3.5-p10 Support for the Hypervisor by the technology provider shall last for 

at least 5 more years. 

14.2.3.5-p11 The ANWI Contractor’s design and implementation shall provide for 

the following server operating system’s requirements of: 

14.2.3.5-p12 On the NS Network NNHQ shall join the NATO AIS Active Directory 

domain and email organization. 

14.2.3.5-p13 


14.2.3.6 Information Assurance 

Standard OS environment will be PFE NATO Server Baseline 

14.2.3.6-p1 The ANWI Contractor’s design and installation shall take into 

account the following restrictions for the placement of electronic equipment of 

different classifications [ref SDIP 29/1] and their physical or virtual separation (see 

1.1.1.3.3). 

14.2.3.6-p2 Server room layout: Components from different classifications shall 

be at least one meter apart in all dimensions. 

14.2.3.6-p3 The ANWI Contractor shall implement a NATO-approved Anti-Virus 

solution (listed on current (at implementation time) version of AFPL - 1.1.1.8.4). 

14.2.3.6-p4 

14.2.3.6-p5 

14.2.3.6-p6 

14.2.3.6-p7 

Every server shall have an antivirus product installed and running. 

Antivirus software shall be kept up to date. 

Antivirus policy in case of an outbreak shall be in place. 

Antivirus management server(s) shall be in place per network. 

14.2.3.6-p8 An antivirus product from a different vendor (than the servers and 

workstations) shall be deployed on Microsoft Exchange Servers to check user 

mailboxes for malicious code.



14.2.3.6-p9 The ANWI Contractor’s IDS/IPS design and implementation shall 

meet the following requirements: 

14.2.3.6-p10 Host Intrusion Protection Software (HIPS) shall be procured and 

installed on critical servers. 

14.2.3.6-p11 

14.2.3.6-p12 

14.2.3.6-p13 

requirements: 

The NCIRC supported HIDS product shall be deployed. 

The HIPS shall be managed centrally by the NCIRC. 

The ANWI Contractor shall implement the following security setting 

14.2.3.6-p14 The appropriate NCIRC provided (at contract award) role based 

security settings shall be applied to the appropriate servers. 

14.2.3.6-p15 Settings for Windows Servers shall be managed centrally via the 

use of Microsoft Group Policy. 

14.2.3.6-p16 NCIRC Security settings for virtualisation software shall be applied 

to the virtualised environment. 

14.2.3.6-p17 

requirements: 

The ANWI shall meet the following Forensic examination 

14.2.3.6-p18 The NCIRC shall have the ability to carry out online forensic 

examinations of all servers. 

14.2.3.6-p19 The Forensic Agent selected by NCIRC FOC shall be deployed on 

all servers. (PFE) 

14.2.3.6-p20 

14.2.3.7 Service Management 

The agents shall be managed centrally by the NCIRC. 

14.2.3.7-p1 The ANWI Contractor shall implement the following Server 

infrastructure management features: 

14.2.3.7-p2 The AIS monitoring manager shall monitor the physical and virtual 

infrastructures for each network classification. 

14.2.3.7-p3 

status. 

The AIS monitoring manager shall monitor the server hardware 

14.2.3.7-p4 The SMC shall receive event notifications from relevant 

environmental monitoring and control systems in key equipment rooms and correlate 

these to impact on infrastructure and service health. 

14.2.3.7-p5 Computing hardware shall support an open platform management 

interface like Intelligent Platform Management Interface (IPMI). Platform status 

information shall be reported to the SMC. 

14.2.3.7-p6 The SMC shall monitor and manage the Processing capacity. It 

shall be able to provide accurate capacity information and also support future 

capacity assessment. 

14.2.3.7-p7 The SMC shall provide management for virtualized and nonvirtualized 

services including a Lights-out physical equipment handling. 





14.2.3.7-p8 The ANWI Contractor shall design the processing services based 

on all required capabilities (including the high level capabilities requirements of 

service management and information management) and clearly describe how the 

processing service and its individual capabilities are integrated in the service 

management concept (SMC). 

14.2.3.7-p9 The ANWI Contractor’s provided Processing Service shall conform 

to the following Service Level Agreement/Targets: 

14.2.3.7.1.1.1.1 Service Level Target Parameters 

Capacity SLTs 

Availability SLTs 

Service Availability (%) 

Max number for scheduled downtimes (month) 

Manageability SLTs 

Frequency of Service Measurements 

Frequency of SLA Reports 

Max Time to provision new Server (Virtual-Physical) 

Reliability SLTs 

Service reliability (%) 

Maintainability SLTs 

Mean Time To Restore (MTTR) (hours) 

99,5% 

1 

Continuous 

Daily/Weekly 

2-8 hours 

>99,99% 

Table 14.2 Network Infrastructure processing SLTs 

4 



14.2.4.1-p1 The ANWI processing service design shall describe the following 

internal interfaces and dependencies: 

Processing 

Storage 

Printing 

User Services 

Processing X X X X X X X X X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 

Table 14.3 Network Infrastructure processing interfaces 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

AVI 

BMS 



SMC 

14.2.4.2 Backup and Recovery 

14.2.4.2-p1 The ANWI Contractor shall design and implement a back-up 

strategy that supports all servers (physical and virtual) and additional applications 

running on the processing capability by the data storage service. 

14.2.4.2-p2 The ANWI Contractor shall ensure that in case of failures, the ANWI 

service level target mandates the problem resolution for a RTO of 4 hours. 



14.2.5 Testing 



14.2.5-p1 The ANWI Contractor shall test the processing service using the 

following End-to-End Test Scenarios: 

A. Processing service stress test with load simulation (CPU and memory 

stressing). 

B. Monitoring period (ex. 15 days) after the initial loading and migration of 

Core applications (e.g. E-Mail). 

C. Monitoring period (ex. 15 days) after loading and migration of ICTM 

applications (e.g. Document system). 

D. Overall processing capacity reporting: 

1. Allocated resources. 

2, Headroom for Growth – 25%. 

3. System Overhead (e.g. VM host). 

E. High Availability features – Server room fail-over. 

F. Provisioning of a new Server (virtual). 

1. Resource allocation flexibility/control. 

G. Fail-over simulation and availability check for different services. 

H. Backup and Recovery 

i. Live migration of running service (e.g. Scheduled HW maintenance). 

J. Performance metering: 

1. Sustained performance metering for a fixed period to endorse resource 

capacity allocation figures. 

2. Resource allocation reporting over certain time period (5days – 3 

weeks). 

3. Server (Physical/Virtual) Backup and Recovery. 


14.2.6-p1 The ANWI Contractor shall train the ICTM on how to install, configure 

and troubleshoot the following areas to support the processing service: 

A. Hardware installation and configuration. 

B. Hardware troubleshooting and fault finding. 

C. Hardware maintenance tasks (e.g. Firmware and Bios upgrades). 




14.3 APPENDIX 3: Storage services 



14.3.1-p1 The storage service is an essential back-end service supporting all 

ANWI services providing the physical capacity parameters for user and application 

data storage. 


14.3.2-p1 The storage service is part of the Infrastructure Service and shall 

provide a tiered data storage solution supporting the full data lifecycle management 

having at least the following levels: 

A. Tier 1: On-line Storage (mission-critical, high-frequency data). 

B. Tier 2: Near-line Storage (non-frequent data, online archive). 

C. Tier 3: Off-line Storage (Offline archive, Backup, offline records). 

14.3.2-p2 The ANWI Contractor’s storage service shall be sized to provide data 

storage for all the current applications/users; all ANWI services; all external NNHQ 

services’ needs (e.g. AVI, ESS and BMS. 

14.3.2-p3 The ANWI Contractor shall ensure that the storage solution is designed 

to provide the highest availability and resilience. 

14.3.2-p4 The Storage service in combination with the processing service shall 

provide a file sharing solution. This shall enable the users to access a common 

network drive to store information 



14.3.3.1-p1 The ANWI Contractor shall deliver and install storage services on all 

4 networks – NATO SECRET, EAPC SECRET, NR and PUBLIC. 


14.3.3.2-p1 The ANWI Contractor’s storage design shall be planned around the 

building’s physical layout compliance limits defined in the Processing Services 

Location (Section 14.2.3.3.2). 

14.3.3.2-p2 

requirements: 

The ANWI Contractor’s design shall also include the following ANWI 

A. The Storage power supplies shall be at least 90% efficient. 

B. The Storage design shall include tiered storage (for energy and speed 

optimized storage). 

C. The Storage solution shall support de-duplication of data, and other 

intelligent technologies to reduce the amount of storage needed. 

D. The Storage service design shall specify flexibility and scalability to limit 

overprovisioning. 

E. The Storage service design shall specify standardization of components. 





F. The Storage solution shall support Hypervisor virtualisation. 

G. The Storage service design shall specify an active-active setup in the dual 

server rooms. 

14.3.3.3 Minimum Hardware Procurement Specifications (MHWPS) 

14.3.3.3-p1 The ANWI shall comply with the following hardware requirements 

over and above those requirements identified in the MHWPS (see 1.1.1.5.1): 

14.3.3.3-p2 

14.3.3.3-p3 

14.3.3.3-p4 


14.3.3.3-p5 

The storage power supply shall be redundant. 

The storage power supply shall be hot pluggable. 

The storage solution shall support IPv4 and IPv6 in a dual stack 

The storage solution shall be redundantly connected to the network. 

14.3.3.3-p6 The storage solution shall provide enough connectivity to all 

projected servers. 

14.3.3.3-p7 

simultaneously. 

The storage solution shall provide iSCSI and FC connectivity 

14.3.3.3-p8 The storage solution shall support other protocols, like FCIP, FCoE, 

10+ Gb Storage network protocols. 

14.3.3.3-p9 

14.3.3.3-p10 

storage model. 

The storage controllers shall be redundant, active-active controllers. 

The storage solution shall support different disks, for a tiered 

14.3.3.4 Scaling per Network Classification 

14.3.3.4-p1 The ANWI Contractor shall scale the storage solution to comply with 

the following estimated usable data capacity requirements: 

14.3.3.4-p2 The storage space requirements for VM's, snapshots etc. shall be 

calculated by ANWI Contractor. 

14.3.3.4-p3 

classification. 

There shall be enough offline capacity to backup ALL data, per 

14.3.3.4-p4 All data shall also be backed up on disk, for fast restore actions.The 

Disk to Disk (D2D) backup shall be stored on different disks than where the actual 

data is stored. 

14.3.3.4-p5 Backup Capacity: Backup capacity shall be redundantly available in 

the two server rooms. 

Type 

Total 

Usable 

storage 

Tier 1 

Online 

Tier 2 

Online/ 

Near-line 

Tier 3 

Offline 

(archive) 

Backup 

D2D2T 

NATO SECRET 

ANWI systems 

TBD by CTR 





Type 

Total 

Usable 

storage 

Tier 1 

Online 

Tier 2 

Online/ 

Near-line 

Tier 3 

Offline 

(archive) 

Backup 

D2D2T 

User-Based Storage 

(mail / files) 

60 TB 40% 60% YES* 

Application Data 118 TB 50% 50% YES* 

AVI 40 TB 50% 50% NO 

EAPC 




TBD by CTR 

30 TB 40% 60% YES* 

AVI 40 TB 50% 50% NO 

NR 




TBD by CTR 

100 TB 40% 60% YES* 


AVI 40 TB 50% 50% NO 

ESS 1050 TB 15% 85% NO 

BMS 10 TB 100% NO 

NU/PUBLIC 




TBD by CTR 

16 TB 40% 60% YES* 


AVI 40 TB 50% 50% NO 

NATO-TV 80 TB 50% 50% NO 

*D2D backup storage is already included in the total usable storage number (30% of the total Storage 

capacity). D2T Backup has not been integrated in the above number. 

Table 14.4Storage Planning Information 

14.3.3.4-p6 The ANWI Contractor shall provide a storage solution with an I/O 

capacity of at least 100.000 front end IOPS: 





14.3.3.4-p7 The ANWI Contractor storage design shall have an average SAN 

infrastructure latency (for the primary online storage) of not more than 10ms. 

14.3.4 Information Assurance 

14.3.4-p1 The ANWI design and installation shall take into account the following 

restrictions for the placement of electronic equipment of different classifications [ref 

SDIP 29/1] and their physical or virtual separation (see 1.1.1.3.1): 

14.3.4-p2 

apart. 

Components from different classifications shall be at least one meter 

14.3.4-p3 The ANWI Contractor shall define and implement a Secure Long Term 

Data Backup and Archival capability for forensic and security analysis purposes and 

provided by an offline backup and a secure storage facility. 

14.3.4-p4 There shall be secure Long Term Data Backup and Archival, for a 

period of at least 5 years, for forensic purposes. 

14.3.4-p5 Backup shall be protected against unauthorized modification (e.g. use 

of digital signatures and time stamping compliant with NPKI) and deletion. 

14.3.4-p6 

features: 

The ANWI Contractor shall provide the following service management 

14.3.4-p7 The SMC shall provide an automated display of the aggregated status 

of file service per security domain. 

14.3.4-p8 

The AIS monitoring manager shall monitor the storage. 

14.3.4-p9 The ANWI Contractor’s provided Storage Service shall conform to the 

following Service Level Agreement/Targets: 


Capacity SLTs 


Service Availability (%) 99,99% 

Max number for scheduled downtimes (month) 1 



Continuous 


Daily/Weekly 

Max Time to provision LUN 

4 hours 


Service reliability (%) >99,99% 


Mean Time To Restore (MTTR) (hours) 4 







14.3.5.1-p1 The ANWI storage service design shall describe the following 


Processing 

Storage 

Printing 

User Services 

Storage X X X X X X X X X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 



LAN 

Cross Domain 

Email 

14.3.5.2-p1 The Storage Service shall provide backup capacity to backup all 

systems and data on both the SAN and individual servers. The backup capability 

shall be integrated in the Information Lifecycle Management (ILM) solution. 

14.3.5.2-p2 The ANWI Contractor, as part of the ANWI’s data life cycle 

management concept, shall provide a storage solution that includes data backup 

strategies to safeguard the data against a catastrophic event and supports long term 

data backup and archival (ex. forensic investigation) 

14.3.5.2-p3 The backup capability shall provide at minimum the following 

restore capabilities 

A. Disk: shall contain online-restore capability up to 5 days (daily Increment) 

B. Disk/Tape: Shall contain online-restore capability up to 6 months (monthly 

Increment) 

C. Tape: Shall contain offline restore capability up to 7 years. 

14.3.5.2-p4 The backup capability shall implement a tape retention policy that 

has the following restore capabilities: 

A. Incremental backup – 2 years 

B. Monthly Full backup – 5 years 

C. Yearly Full backup – 7 years 

14.3.5.2-p5 The ANWI Contractor’s storage capability shall be high available 

across both server rooms guaranteeing that data shall be kept in sync on the storage 

systems in both server rooms. 

14.3.5.2-p6 The ANWI Contractor shall ensure that in case of a server room 

failure the surviving server room’s storage system shall continue the service without 

any data loss. 

14.3.5.2-p7 The ANWI contractor shall design and implement a storage 

capability that meets the following (Disaster) Recovery requirements: 

ANWI CAMPUS 

DR LOCATION (out of scope) 

TIER 1 TIER 2 TIER 1 TIER 2 

RTO 30 minutes 1 hour 4 hours 8 hours 

RPO




14.3.6-p1 The ANWI Contractor shall test the storage service using the following 

End-to-End Test Scenarios: 

A. Hardware Inspection – Physical inspection of the storage components. 

B. Capacity Tests (Raw storage size vs. Usable storage size): 

1. Usable storage = Raw Storage size (right-sized) – Storage Overhead 

(e.g. RAID, HA). 

2. All Tier storage capacity. 

C. Availability Test: 

1. Demonstrates High availability. 

2. Simulate SAN/Server room fail-over. 

3. Simulate component failure (disk, FC switch, and controller). 

4. RTO and RPO reporting (requirements vs. test results). 

D. Performance tests (Test shall be conducted over a predefined period not 

point in time test): 

1. I/O monitoring (with specific tools): 

a. For different storage types and data types. 

b. Under normal conditions. 

c. With reduced capacity (after component or system failure). 

E. Overall Storage Reporting using SMC service: 

1. Total storage (data size). 

2. Used storage (throughout project lifecycle). 

3. IOPS usage/headroom. 


14.3.7-p1 The ANWI Contractor shall train the ICTM on how to install, configure 

and troubleshoot the following areas to support the storage service: 




D. Basic storage configuration and management: 

1. LUN creation. 

2. RAID management. 

E. Advanced storage configuration and management: 

1. Mirroring setup and maintenance. 

2. HA policy and failover scripts. 

F. Creation and management of data life cycle policies. 




14.4 APPENDIX 4: Printing and Scanning Services 



14.4.1-p1 The printing service is an essential client service providing the ability to 

print hardcopies of documents or other electronic data via ‘follow-me’ printing based 

on a user’s Identity-card. 

14.4.1-p2 The scanning capability provides the client the ability to digitize 

hardcopies of documents or pictures and have the scanned result sent to the user’s 

email account. 


14.4.2-p1 The ANWI Contractor provided printing-scanning capability is designed 

and implemented as part of the Infrastructure Service and shall deliver improved 

efficiency by allowing users to more easily print/scan a hardcopy from any 

appropriate security domain device on the NNHQ campus so the long term cost 

reductions are realised by deploying fewer devices and cleansing print requests 

when not demanded via an ID-card request. 

14.4.2-p2 The ANWI Contractor’s Printer Services implementation for each 

classification level shall be subject to information assurance requirements of the 

respective classification. 

14.4.2-p3 “Cross Domain Printing” solutions between NR and NS networks can be 

proposed optionally to satisfy the required functionality, however the proposed 

system shall not introduce additional limitations in terms of usability, manageability 

and functionality, shall not increase the TCO for the lifecycle and shall be subject to 

the accreditation (as any other system and solution). 

14.4.2-p4 The ANWI contractor shall implement and MFP solution that allows for 

printing/scanning and copy from the same device. In case the ANWI contractor 

proposes a cross-domain printing solution, a NR network scanning solution shall be 

included on the Business network. 



14.4.3.1-p1 The ANWI Contractor shall provide printing and scanning services 

that are readily available on and to all 4 networks – NATO SECRET, EAPC 

SECRET, NR and PUBLIC. 


14.4.3.2.1 The ANWI Contractor print/scan design and implementation shall comply 

with the following: 

14.4.3.2.1-p1 

All ANWI printing shall be network based. 

14.4.3.2.1-p2 The ANWI Contractor shall install the printers around the lift 

shafts in each wing/floor. 



14.4.3.2.1-p3 

areas. 

14.4.3.2.1-p4 

areas. 



Printers for Public classification shall be provided for Public 

Printers for EAPC classification shall be provided in the EAPC 

14.4.3.2.1-p5 Printers for NR classification shall be provided throughout all 

IS/IMS marked wings AND conference areas (Class 2 secure areas). 

14.4.3.2.1-p6 

areas. 

Printers for NS classification shall be provided in Class 1 secure 

14.4.3.2.1-p7 The ANWI Contractor provided printing services shall comply 

with the following Green IT and availability requirements: 

A. Print jobs shall be printed at any device on the user’s network where the 

user authenticates with his ID-card (follow me printing). 

B. Default printer settings shall be optimized for Green IT (double sided, N-up 

printing, suppress header print). 

C. The ANWI Contractor shall optimize the number of printers/worker, with 

consolidation and centralization of printing devices. 

D. Printers shall have a low-power state, such as a standby or sleep mode. 

E. Print services shall be redundantly available over both server rooms. 

F. If a print server fails, users shall be able to print through another instance 

without extra configuration on the user side. 

14.4.3.2.1-p8 The ANWI Contractor provided printers shall comply with the 

following hardware requirements: 

A. Printers shall be Energy Star Qualified. 

B. Printers shall be able to print on A3 and A4 paper. 

C. Printers shall have a sorter/stacker with a capacity of 1000 pages. 

D. Card readers shall be securely attached to the print device requiring 

special tools to be removed. 

E. Printers driver shall support the latest Windows server products. 

F. Printers driver shall support the latest Windows desktop products. 

G. Printers shall support IPv4 and IPv6 in a dual stack configuration. 

14.4.3.2.1-p9 The ANWI Contractor printing solution shall satisfy the following 

IA requirements for all printers (per 1.1.1.6.39): 

A. Print jobs shall be queued and shall only print when a user activates a 

device using their ID-card. 

B. The Contractor shall address in the SRA the IA measures related to local 

printer memory devices (harddisk and memory) 

C. Printers control panel must have the possibility to be locked. 

D. Printers options shall be configurable, and to be restricted in options. 

1. All unnecessary services and network protocols shall be disabled. 

2. Unneeded management protocols shall be disabled. 

3. Static IP addresses shall be assigned to printers/MFP (multi-function 

printer). 

4. MPFs should be installed in VLANs specific to those devices. Access to 

MPFs should be limited to particular ports and protocols using a BPD 

(e.g. firewall). 

E. MFP shall maintain its configuration state after power-down or reboot. 







14.4.3.2.1-p10 The ANWI Contractor shall ensure that the printing service is 

interfaced, as follows, with the ANWI Service Management and Control 

requirements: 

A. Printers shall be able to be remotely managed. 

B. Printers shall support SNMPv3. 

C. Printers/MFPs should support SSHv2 and SCP. 

14.4.3.2.1-p11 The ANWI Contractor scanners shall comply with the following 

requirements: 

A. Scanners shall have a low-power state, such as a standby or sleep mode. 

B. Scan services shall be redundantly available over both server rooms. 

C. General: Scan services shall be available for all users via Network 

scanners. 

D. Scanners shall be Energy Star Qualified. 

E. Card readers shall be securely connected to the scan device. 

F. Scanners shall support IPv4 and IPv6 in a dual stack configuration. 

14.4.3.2.1-p12 The ANWI Contractor scanner solution shall comply with the 

following Information Assurance requirements: 

A. Scanner functionality shall only be activated when the user activates the 

scanner using their ID card. 

B. Scans shall be sent to the a-mail address associated with the ID card that 

activated the scanner; other options shall not be available. 

14.4.3.2.1-p13 The ANWI Contractor shall ensure that the scanning service is 

interfaced, as follows, with the ANWI Service Management and Control 

requirements: 

A. Scanners shall be able to be remotely managed. 

B. Scanners shall support SNMPv3. 

14.4.3.2.1-p14 The ANWI Contractor’s provided Print/Scan Service shall 

conform to the following Service Level Agreement/Targets: 


Capacity SLTs 

Service Capacity 

Supported sizes 

Supported colours 

Copy – Print – Scan to mail 

A3 – A4 

Monthly volume (Pages) >100,000 

Supported colour 






Frequency of SLAReports 

Max duration for Toner replacement 


Full colour - Black and White 

Continuous 

Daily/Weekly 

1 hour 

Service reliability (%) 99,9% 

Maintainability SLTs




Mean Time To Restore Service (MTTR) (hours) 4 

Max Time to Repair individual Printer (hours) 24 



14.4.4.1-p1 The ANWI print and scan service design shall describe and 

implement the following internal interfaces and dependencies: 

Processing 

Storage 

Printing 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 

Printing X X X X X X X X X X X X X 

14.4.4.1-p2 The ANWI Contractor’s design and implementation shall document 

and support the following cross-domain interfaces: 

Flow 1. 

1/2 way 2. Service 3. Service name 4. Supported Protocols 5. Remarks 

6. BUS-CD5 One way BUS-NS CD Printing UDP 




not Mandatory dependant on 

design 

14.4.4.2-p1 The ANWI Contractor shall include the back-end print infrastructure 

into the overall ANWI backup policy. 

14.4.4.3 Testing 

14.4.4.3-p1 The ANWI Contractor shall test the print-scan service using the 


A. Follow-me printing scenario (ID-Card Authentication). 

B. Scan to mail scenario. 

C. Print server failure test scenario. 

D. Off-site printing test scenario. 

E. Print usage reporting test scenario. 

F. Cross-domain printing (if applicable), 


14.4.5-p1 The ANWI Contractor shall train the users in the following areas: 

A. Follow-me printing. 

B. Print device default (power saving) settings. 

C. Cross Domain printing, if applicable. 

D. Printer and scanner menu settings. 

14.4.5-p2 The ANWI Contractor shall train the ICTM staff on how to install, 

configure and troubleshoot the following areas to support the print and scan 

capability: 

A. Print server configuration. 

B. Central management of printers (DHCP/DNS integration).


C. Configuration of client printing agent. 

D. Print queue management. 

E. Follow-me printing software. 

F. Scanning software. 

G. Email - scanner software interface. 





14.5 APPENDIX 5: Infrastructure Network Services 



14.5.1-p1 Infrastructure Network services provides authentication and 

authorization, Name Resolution, DHCP, Time services and network Access control 

(NAC) functionality to the ANWI. 


14.5.2-p1 The infrastructure network services are part of the Infrastructure 

services and shall reside on each network and interact with all devices and users that 

connect to that NNHQ network, by either allowing/denying access (AD/NAC) or 

facilitating the ICT services (DHCP/DNS). 



14.5.3.1-p1 The ANWI Contractor shall deliver and install the network 

infrastructure services on all 4 networks – NATO SECRET, EAPC SECRET, NR and 

PUBLIC. 


14.5.3.2-p1 The ANWI Contractor’s infrastructure network service’s servers shall 

be located in both server rooms in order to keep basic network services running even 

in case of a major failure, which also includes losing one of the server rooms. 

14.5.3.2-p2 The ANWI Infrastructure Services shall interact with all NNHQ users 

that connect to the NNHQ network, from remote offices on NS and mobile NR 

devices via the Internet. 



14.5.3.3 Directory Services 



14.5.3.3-p1 The ANWI Contractor shall install and configure Active Directory 

(AD) Services on each NNHQ network in accordance with the following diagram and 

requirements: 

Figure 14.3: NATO HQ Integrated Bi-SC AIS Domain Services 

A. The NNHQ Active Directory (NS level) shall join the AIS single forest. 

B. The NNHQ Active Directory (NS level) shall join the AIS single domain. 

14.5.3.3-p2 The ANWI Contractor provided AD Services for EAPC, NR 

classifications shall be installed and configured in accordance with the following 

requirements: 

A. The NNHQ Active Directory (NR level) shall follow the design of the AD at 

NS level. 

B. The NNHQ Active Directory (Public level) shall follow the design of the AD 

at NS level. 

C. The NNHQ Active Directory (EAPC level) shall follow the design of the AD 

at NS level. 

D. NNHQ AD Services for NR classification shall be prepared to federate with 

/ integrate to future NATO-wide Business NR AD Service. 

14.5.3.3-p3 For the public network the contractor shall provide AAA services. 

A. The public network shall support RADIUS or an equivalent technology. 

14.5.3.3.1 NATO Enterprise directory service (NEDS) 

14.5.3.3.1-p1 NEDS - The current specification for the NATO Enterprise 

Directory Service (NEDS) solutions is based on the requirement to support email 

Global Address List (GAL) synchronisation and Active Directory user synchronisation 

for cross authentication of users between forests (see Annex B for more detail); to 

that end the ANWI Contractor shall connect the NNHQ’s Active Directory (NS and 

NR level) with the NATO Enterprise Directory Service (NEDS). 





14.5.3.3.1-p2 The ANWI Contractor shall design and implement each of the 4 

NNHQ networks to comply with the following: 

A. The Active Directory service shall be highly available and redundant on all 

classification networks. 

B. At least one AD server per server rooms shall be hosted on a physical 

server. 

14.5.3.3.1-p3 The ANWI Contractor shall design and implement the AD 

restricting administrative rights to certain individuals who may add, change or delete 

items in the Active Directory service. 

14.5.3.3.1-p4 The ANWI Contractor shall centrally monitor and display the 

Active Directory service according to the following: 

A. The SMC shall provide an automated display of the aggregated status of 

directory services per security domain. This is an aggregation of server 

and service status and network status. 

B. The AIS monitoring manager shall monitor the active directory (AD). 

C. The SMC shall provide an automated display of the aggregated status of 

browsing service per security domain (this is an aggregation of relevant 

network, DNS and gateway status). 

D. The SMC shall provide an automated display of the aggregated status of 

web publishing service per security domain (this is an aggregation of 

relevant network, web-servers (and associated storage), DNS and 

gateway status). 

E. The SMC shall provide an automated display of the aggregated status of 

remote user service per security domain. This is an aggregation of 

gateway, VPN service status and relevant network status. 

F. The AIS monitoring server shall monitor core services like: Windows 

Active Directory, DNS, MS SQL. 

G. The AIS monitoring manager shall monitor the database(s). 

H. The AIS monitoring manager shall monitor the web sites and web 

services. 

14.5.3.4 Domain Name System (DNS) 

14.5.3.4-p1 The ANWI Contractor’s design and implementation shall use DNS 

to resolve DNS names related to systems and services on the 4 NNHQ (NS, EAPC, 

NR and the Public) networks, and/or to point to DNS resolvers on external networks 

that can resolve DNS names of systems/services that are external to NATO HQ. 

14.5.3.4-p2 The ANWI Contractor shall design and implement the DNS according to 

the following DNS service requirements: 

A. The internal DNS infrastructure shall be split from the External DNS and 

will not be accessed from external networks. 

B. The network shall use an internal DNS root and namespace, where all 

Authority is internal. 

C. DNS servers shall limit zone transfers to specified IP-addresses, if 

needed. 

D. DNS servers shall be configured to listen on specified IP-addresses. 

E. Cache pollution prevention shall be enabled on all DNS servers. 







F. DNS solution shall provide efficient network discovery and automated IP 

address management 

G. Internal DNS zones shall be stored in Active Directory, with a DACL to 

allow specified individuals to add, delete or modify DNS data. 

H. The DNS service shall allow to be managed from a single console. 

I. Internal DNS servers shall be configured with root hints that point to the 

internal DNS servers that host the root zone for the internal namespace. 

J. The DNS service shall be high available on all classification networks. 

K. The DNS service shall be redundant on all classification networks. 

14.5.3.4-p3 The ANWI Contractor shall implement the DNS service, like all other 

components in the network, to support multiple IP stacks according to the following: 

A. The DNS service implementation for the NNHQ shall be IPv4. 

B. The DNS service implementation shall be able to support an IPv6 

implementation. 

14.5.3.4-p4 The ANWI Contractor shall implement the DNS service so that the 

AIS monitoring manager (in Mons) shall monitor the DNS. 

14.5.3.5 Windows Internet Name Service (WINS) 

14.5.3.5-p1 

applications. 

The WINS service shall not be used, unless needed for legacy 

14.5.3.6 Dynamic Host Configuration Protocol (DHCP) 

14.5.3.6-p1 The ANWI Contractor shall implement the DHCP service to assign an 

IP-number to a client or connection to the network supporting the following 

requirements: 

A. All DHCP servers shall be authorized. 

B. The DHCP service shall not be installed on Domain Controllers. 

C. DHCP relaying on routers shall be used to relay DHCP request to the 

central DHCP servers. 

D. Each scope of the DHCP service shall be high available on all 

classification networks. 

E. Each scope of the DHCP service shall be redundant on all classification 

networks. 

14.5.3.6-p2 The ANWI Contractor shall implement the DHCP service, like all other 

components in the network, to support multiple IP stacks: 

A. The DHCP service implementation for the NNHQ shall be IPv4. 

B. The DHCP service implementation shall be able to support an IPv6 


14.5.3.7 Network Time Protocol (NTP) 

14.5.3.7-p1 The ANW Contractor shall implement the following requirements for the 

NTP service: 

A. All end systems, network and security devices shall be synchronised to a 

common time source to facilitate computer and network forensics 

investigations. 

B. Windows servers shall use W32time for timekeeping.



C. For the NS network the authoritative time shall be provided by the AIS 

network (PFE). 

D. When using VMware, VMware tools periodic time synchronization shall be 

disabled. 

E. For Public/NR Networks an authoritative (stratum-1) time server shall be 

supplied by ANWI. 

14.5.3.8 Network Access Control (NAC) 

14.5.3.8-p1 Network Access Control (NAC) services review the configuration of 

devices connecting to a network based on endpoint security (such as OS patch level, 

antivirus updates, host IPS, etc.), user and system authentication and network 

security enforcement. The NAC will protect the network by preventing non-compliant 

clients from accessing the network at the IP-level. In case of a device that is not 

compliant with a defined security policy it shall be isolated / quarantined and has to 

undergo a remediation and sanitization process. Only when successful, the device 

may be granted access to the network and in accordance with its identity 

characteristics. 

14.5.3.8-p2 The NAC solutions shall provide End-point-protection features for all 

ANWI client types. The End-point protections shall cover from real-time malware 

protection to in-depth network and device control and protection (including peripheral 

management and control). 

14.5.3.8-p3 The NAC Solution shall enable context-aware security in the 

network; this shall allow for granular visibility and control, down to the user and 

device level. 

14.5.3.8-p4 The NAC Solution shall provide flexible authentication options - 

802.1x, MAC, client- and web-based authentication. The NAC solutions shall be able 

to integrate with the NATO PKI and NATO Directory Services (ex. MS AD). 

14.5.3.8-p5 The ANWI Contractor shall support, through design and 

implementation, the following list of NAC requirements for the four different security 

networks: 

A. There shall be no restrictions on devices connected to the network, 

provided they comply with the NAC policy. 

B. The system shall recognize and be able to report on NATO approved 

devices and external devices that connect to the network. 

C. The system shall be able to access devices to ensure they are compliant 

before granting access to network resources. 

D. The system shall restrict devices access to network resources, other than 

those needed for remediation, until they are compliant or the isolation is 

overridden by an admin. 

E. If a valid device fails an integrity check, there shall be a mechanism by 

which the device can be brought back into compliance. 

F. It shall be possible for visitors to gain access to resources, as an internet 

connection, provided they accept or comply with NAC policy. 

G. The system shall not restrict compliant users on compliant devices to 

access resources. 

H. A system shall support, and not restrict, the current and future choice of 

network devices. 





I. The system shall be able to use the existing authentication method to 

grant system or user access to network resources. 

J. The system shall enable admins to create, deploy, monitor and enforce 

NAC policies which reflect the NNHQ NAC policy. 

K. The ANWI shall be able to capture en disseminate info regarding endpoint 

and the systems own status, in a manner and format which can be used to 

manage the system and the issues and to identify trends. 

L. The ANWI shall be able to raise alert in case of issues. 

M. The ANWI shall be able to be supported as other management systems. 

N. The NAC solution shall support the automated deployment of the user 

agent. 

O. The ANWI Contractor shall provide regular updates, for new devices, 

Operating systems and software at the time of release by their 

manufacturers. 

P. The ANWI Contractor shall confirm on the policy of to cover 3rd party 

events, as virus outbreaks, or Microsoft "Patch Tuesday" results. 

Q. The ANWI shall not adversely impact functionality or performance of user 

and systems. 

R. The ANWI itself shall be secure against attacks or attempts to bypass the 

protection it affords NNHQ systems. 

S. The ANWI shall support license monitoring and reporting. 

T. The ANWI Contractor’s provided Network Infrastructure Service shall 

conform to the following Service Level Agreement/Targets: 







Continuous 


Daily/Weekly 






Response Time (DNS) - (ms) 

Response Time (DHCP) - (sec) 

Response Time (Authentication) – (sec) 

Response Time (NTP) – (ms) 

Response Time (NAC) – (sec) 

< 50ms 

< 5 sec 

< 10 Sec 

< 50ms 

< 5 Sec 







14.5.4.1-p1 The ANWI network infrastructure service design shall describe and 

implement the following internal interfaces and dependencies: 

Processing 

Storage 

Printing 

User Services 

AD X X X X X X X X X X X X X X X X X X X X X X X X 

DNS X X X X X X X X X X X X X X X X X X X X X X X X X 

DHCP X X X X X X X X X X X X X X X X X X X 

NTP X X X X X X X X X X X X X X X X X 

NAC X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 


and support the following cross-domain interfaces: 


PUB-CD3 Two way PUB-NEDS NU NEDS conn 

PUB-CD3 Two way PUB-NMSG NU Messaging SMTP Federated or NU email 

PUB-CD3 Two way PUB-NDS NU Domain LDAP Federated or NU domain 

PUB-APP - - ICTM Apps 

PUB-XNET - - PUB Extranet 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 


BUS-CD2 Two way BUS-NEDS NR NEDS 

BUS-CD2 Two way BUS-NMSG NR Email 

BUS-CD2 Two way BUS-NDS Dir sync LDAP Federated domain 

BUS-APP - - ICTM Apps 

BUS-XNET - - NR Extranet 


EAPC-APP - - ICTM Apps 


NS-GW1 Two way NS-NDS Dir sync Ldap Bi-SC AIS domain 






NS-GW1 Two way NS-NEDS Dir sync Ldap Through Bi-SC AIS 

NS-APP Two way ICTM Apps 

NS-XNET Two way NS Extranet 


14.5.4.2-p1 The ANWI Contractor shall include the configuration files of the 

Infrastructure Network Service into the overall ANWI backup policy. 

14.5.4.3 Testing 

14.5.4.3-p1 Testing The ANWI Contractor shall test the Network Infrastructure 

service using the following End-to-End Test Scenarios: 

User Services From 1/2 way GW To Provider External service Remarks 

AD synch NR WAN GW2 NR ? NR Domain federated or single domain structure 

NS WAN GW1 NS NCIA Bi-SC AIS 

14.5.4.3-p2 The ANWI Contractor shall ensure that the test scenarios simulate 

the use of network services during peak and off-hours regarding: 

A. Active Directory: 

1. simulate AD interactions to reflecting expected user traffic (e.g. 

ADTEST.exe). 

2. NPKI token login in AD environment. 

3. availability and resilience test in case of server failure. 

B. DNS: 

1. resolution for internal and external resources. 

2. Use test tool to test response times (e.g. DPT). 

3. DNS security settings implementation checks. 


C. DHCP: 

1. IP acquisition for devices (internal LAN and DHCP relays). 

2. DHCP response times for varying user load. 


D. NTP: 

1. Performance: NTP Response time. 

E. NAC: 

1. connect out-of-date end-user device and perform remedial actions. 

2. Test rejection policy. 

3. NAC response times with varying load (requests). 



14.5.5-p1 The ANWI Contractor shall train the ICTM staff on know how to install, 

configure, operate and troubleshoot the following areas to support the network 

infrastructure capability: 

A. Active Directory management in the NATO delegation model. 

B. Network Access control: 



1. Configuration. 

2. Operation. 

3. Maintenance. 





14.6 APPENDIX 6: LAN services 




14.6.1-p1 In general the LAN module provides three types of services: 

A. Packet Switching Services, related to the required switched transport 

services. This translates very much to one of the applicable Ethernet 

standards. It also includes support for multicast. 

B. QoS and Security services such as VLAN, NAC, QoS, which relate to 

network services. 

C. Management services, needed to manage and measure network and 

transport service performance. 


14.6.2-p1 The LAN capability shall provide infrastructure for both wired and 

wireless Local Area Networks. 

14.6.2-p2 Unclassified voice and Public networks may be provided by single 

switched infrastructure, with appropriate security measures including VLAN 

separation where the specific implementation shall undergo security accreditation. 

14.6.2-p3 NR, NS and EAPC shall be implemented on physically separated 

switched infrastructures; unless a nationally accredited solution which is allowed to 

be exported and used by NATO is provided. 

14.6.2-p4 The wired LAN services shall distinguish between: 

A. Core Switching; these are switching and routing capabilities that are 

oriented in the core of the network and shall provide for Access switch, 

Server and SAN connectivity as well as added services like load-balancing 

and content switching functionalities. 

B. Server/SAN switching shall provide connectivity for servers and SAN 

components (Dedicated or converged) 

C. Access Switching shall provide connectivity to end-user devices. 

14.6.2-p5 IDS and monitoring switch modules may be required at specific 

locations on site, based on the outcome of the Contractor’s detailed site and design’s 

risk assessment. 

14.6.2-p6 As part of the switching infrastructure – a load balancing solution shall 

be provided. This solution shall provide redundant and high available load balanced 

services. These shall include but not limited to HTTP(S), FTP and DNS. The load 

balancing solution shall also provide advanced features like SSL Offload, TCP 

buffering, client authentication, content aware switching and HTTP compression. 

14.6.2-p7 The ANWI Contractor shall size the LAN service to support all ANWI 

equipment and services in this SOW, with additional 25% free resources to support 

expected near-future applications. 







14.6.3.1-p1 The LAN capability shall be available on all 4 networks – NATO 

SECRET, EAPC SECRET, NR and PUBLIC. 

14.6.3.1-p2 The Wireless LAN (WLAN) capability shall be available on the 

PUBLIC network. NR clients shall connect through PUBLIC to NR, via a secure VPN 

connection. 

14.6.3.2 LAN Service Types 

14.6.3.2-p1 The following table provides information on the type of LAN services 

required per classification: 

Classification LAN Type Cable type 

NS Wired Fibre Optic 

EAPC Wired Fibre Optic 

NR Wired Fibre Optic 

Wireless 

Public Wired Copper 

Wireless 

N/A 

N/A 

Table 14.1: LAN services per classification 

14.6.3.3 Service Capacity 

14.6.3.3-p1 The Access Switch port requirements will be determined by the 

actual allocation of users to the building. As this is still an on-going task it is 

impossible to provide exact access switch port allocation per classification and TER. 

However the number of devices that need to be supported for a specific classification 

is known. As the ANWI design requires flexibility in the allocation of resources and 

capabilities the ANWI Contractorshall provide an access switch solution based on the 

following numbers: 

Classification NS NR EAPC Public 

Total FO Ports 2200 3400 220 

Total CU Ports 3000 

Supported devices 

NS Client 

NS peripheral 

-NR Client (cabled) 

-NR Peripheral 

-ESS devices 

-BMS devices 

-AV devices 

(These port quantities do not included the 25% spare capacity) 

EAPC Client 

EAPC Peripheral 

WLAN AP 

Telephone 

IPTV devices 

Public Client 


14.6.3.4-p1 Core, Server (rack) and Storage switches shall be located in the 

dual server rooms. 





14.6.3.4-p2 Access switches shall be located in the TER’s, which are in the 

basement of the NNHQ. 

14.6.3.4-p3 There are 45 TER rooms across the ANWI Campus of which 41 are 

in the main building. 

14.6.3.4-p4 Wireless access points shall be located throughout the main 

building and staff centre. 

14.6.3.4-p5 For Access switches, located in the TERs, there is the following limit: 

A. The maximum cooling per TER is 3.2 kW or 6.4 kW (where 2 CRACs are 

available) - Annex B 

B. Security cameras shall be connected by fibre. 

C. BMS access controllers shall be connected by fibre. 

D. Wireless access points connect via copper PoE connections. 

E. VOIP phones connect via copper PoE connections. 

F. Trunk connections between switches shall be at least 10Gbit Ethernet. 

G. All network devices shall support IPv4 and IPv6 in a dual stack 


H. The following list describes the End point capacity and quality: 

1. User capacity oversubscription shall not exceed 5:1. 

2. End-user sustained capacity shall be at least 40Mbps. 

3. Voice units sustained capacity shall be at least 0.080Mbps, expedite 

service. 

4. BMS Video units sustained capacity shall be at least 4Mbps, expedite 

service. 

5. Wireless access point sustained capacity shall be at least 80% of 

maximum device capacity. 

6. Server capacity oversubscription shall not exceed 1:1. 

I. The LAN capability shall comply with the below public wireless network 

service requirements: 

1. Wireless capability shall cover the entire NNHQ main building and staff 

centre. 

2. There shall be sufficient redundancy in coverage that 10% failed 

Access Points will not impact the WLAN’s availability. 

3. The Wireless capability shall support internal roaming (between Access 

Points). 

4. The Wireless capability shall be sized to support over 5,000 concurrent 

users, this are both internal staff as well as public guest access. 

5. The Wireless capability shall support as a minimum the WLAN 

standards at the time of bidding. 

6. The Wireless capability shall support various end-user devices e.g. 

laptops, tablets, PDA’s, mobile phones. 

7. The Wireless Capability shall provide segmentation between the Guest 

and NATO user WLAN networks. 

* Note: PNWI passive Fibre and Copper specifications are found in Annex B. 





14.6.3.4-p6 The wired LAN Services shall comply with the below generic wired 

network service requirements: 

A. Maximum of 2 different vendors/brands to provide the complete LAN and 

WIFI solution. Number of modular chassis types and/or "boxed" switches 

is limited to 2 of each. 

B. The network shall be End-to-End Ethernet based. 

C. All access switches shall be installed in the TER, WLAN access points 

shall be installed throughout the building out of user reach. 

D. Port based network access control shall use 802.1x EAP. 

E. Network devices shall have a redundant power supply N+1. 

F. Power supply and cords shall be delivered according to local 

requirements. 

G. Devices shall use a Server Room High availability features processor, 

switching module. 

H. All devices shall use hot swappable components. 

I. Software: Software & Documentation shall be included, the latest release 

on CD or printed media. 

J. Rack mounted equipment must be capable of being mounted in standard 

19” racks. 

K. Equipment shall provide port mirror functionality (bi-directional). 

L. Equipment shall provide broadcast control blocking / limiting mechanism. 

M. Consolidation of LAN and SAN traffic in the server rooms shall be in line 

with industry standards like FCoE and ISCSI. 

14.6.3.4-p7 The wired network service provided through a Switched 

environment shall support the following protocols: 

A. Protocols: Layer2: 

1. Provide support for at least 1000 VLANs. 

2. VLAN Standards 802.1q (VLAN). 

3. Spanning Tree 802.1d (Spanning Tree Protocol). 

4. 802.1s (Multiple Spanning Tree Protocol). 

5. 802.1w (Rapid Spanning Tree Protocol). 

6. QOS/COS 802.1p (QOS on MAC level) (by 802.1Q tags, DSCP, 

minimum 5 queues). 

7. Port based network access control 802.1x EAP. 

8. Flow control 802.3x. 

9. Link aggregation 802.3ad. 

B. support for TRILL or equivalent 

C. DHCP snooping 

D. Dynamic ARP inspection 

E. private VLANs 

F. Protocols: Layer 3: 

1. RIP v1 and v2. 

2. OSPF v2 and v3. 

3. VRRP. 

4. PIM. 

5. BGPv4 







14.6.3.4-p8 For the Public/NR LAN services, the following requirements apply: 

A. Connections, if wired, must be wired with Copper for NU and Public. 

B. Connections, if wired, must be wired with Fibre for NR. 

C. Devices shall be modular based or single fixed configured stackable. 

D. The device must be able to support at least 40,000 MAC addresses. 

E. Wireless access points shall support PoE. 

F. The device uplink must be dual homed and connected to each server 

room for redundancy. 

G. The device shall be upgradable to at least the next capacity level (e.g. 

implement 10 Gbps, service must be upgradable to at least the next 

capacity level at 40 Gbps). 

* Note: Stackable switches are not the same as cascadable switches, a stack of stackable switches 

act as one switch. 

14.6.3.5 SECRET Network Design 

14.6.3.5-p1 For the EAPC SECRET LAN services, the following requirements 

apply: 

A. Connections must be wired, with Fibre for EAPC. 

B. Devices shall be modular based or single fixed configured stackable. 

C. The device must be able to support at least 16,000 MAC addresses. 

D. The device uplink must be dual homed and connected to each server 


E. The device shall be upgradable to at least the next capacity level (e.g. 



14.6.3.5-p2 For the NATO SECRET LAN services, the following requirements 

apply: 

A. Connections must be wired, with Fibre for NS. 

B. Devices shall be modular based or single fixed configured stackable. 

C. The device must be able to support at least 16,000 MAC addresses. 

D. The device uplink must be dual homed and connected to each server 


E. The device shall be upgradable to at least the next capacity level (e.g. 



14.6.4 Conference Room Infrastructure 

14.6.4-p1 In the conference room area requires network access to all 4 networks. 

The ANWI contractor shall provide switching capability for 400 user devices in this 

area. The Conference area LAN capability shall be able to be switched flexible 

between network classifications depending on the classification of the conference. 

14.6.4-p2 Information and requirements for the Network agnostic clients can be 

found in Annex H, Appendix 3. 

14.6.5 Information Assurance 

14.6.5-p1 NITC guidance on the hardening of switches and routers shall be used 

as a guideline for securing the NNHQ networks.

14.6.5-p2 


Port Security shall be implemented 




14.6.5-p3 Logical segmentation along functional boundaries using VLANs shall be 

implemented, at a minimum voice, management and user data shall be separated. 

14.6.5-p4 Authentication of access to switches and routers shall be via a 

mechanism based on the use of a security server such as TACACS+ or RADIUS . 

14.6.5-p5 

guidance . 

Switches and routers shall be hardened in accordance with NITC 

14.6.5-p6 Wireless LAN shall be used only for UNCLASSIFIED information and 

shall be implemented in accordance with the guidance. 

14.6.5-p7 Wireless user-based authentication shall be based on an Extensible 

Authentication protocol standard. 

14.6.5-p8 Wireless LAN (WLAN) Access Points (AP) shall be placed in secured 

areas to prevent unauthorized access. 

14.6.5-p9 WLAN AP shall be separated from wired LAN by Boundary Protection 

Devices (e.g. firewall and IDS). 

14.6.5-p10 Wireless VLANs – shall use separated VLANs for NATO internal 

users and guests. 

14.6.6 Service Management 

14.6.6-p1 The generic management requirements: 

A. There shall be out of band management (Ethernet based, at minimum 

fibre based for classified equipment). – All LAN devices shall have a 

dedicated management port. 

B. LAN devices shall be programmable via a secure interface offering 

SSHv2, HTTP with SSL and SNMPv3. 

C. LAN devices shall support at least IGMP v2 and 3, Telnet, TFTP, (S)NTP. 

D. LAN device management via RMON and web based management 

functionality (at a minimum – Traffic Statistics, history, events and alarms) 

shall be provided internally to the switch. This capability, when turned on, 

shall not severely diminish the processing capability, degrade performance 

and speed of the switch. 

E. LAN devices shall be manageable (remotely monitor, control and 

diagnose) via SNMP and RMON capabilities (module). They shall have 

support for network management packages (e.g. HP Openview, IBM 

Tivoli/Netview, SPECTRUM, MS SCCM/SCOM). 

F. The wired network service component shall support: SNMP v3, NetFlow 

(or comparable) MIBII, RMON MIB I&II and RMON-II MIB, Ethernet MIB, 

802.1x MIB,(VRRP MIB,OSPF MIB, BGP MIB, IGMP MIB, PIM MIB, 

Router MIB) and SSH where applicable. 

G. Configurations of network elements and networking services are controlled 

through a configuration management and deployment system using the 

CMDB. Network elements may not be configured (less emergency 

interventions) by administrators in isolation directly on the hardware (either 

through direct or remote terminal connections).



H. Scheduled and on demand automated infrastructure discovery shall be 

used to validate against approved configuration in CMDB. Discrepancies 

shall result in a trouble ticket to be automatically generated. Critical 

unauthorized configuration changes may result in roll-back action 

depending on the policy. Authorized deltas between deployed and stored 

configurations shall lead to update of CMDB. 

I. Automatic infrastructure discovery shall find and store the configuration of 

infrastructure elements and the relationships/mapping between them. 

J. Configuration changes on infrastructure elements shall trigger an event to 

the N/ELM, which is logged and must trigger a re-discovery and potential 

follow-up action if the re-discovery determines that the configuration 

change unauthorized. 

K. Configurations of network elements and changes thereof shall be centrally 

controlled and approved recording an audit trail recording requester, 

approver, and implementer. 

L. Network elements shall use SNMP Trap and/or Syslog for event reporting. 

M. Network elements shall generate as a minimum an event upon element 

status change, interface status change, exceeding environmental 

thresholds (typically internal temperature sensors) and terminal access. 

N. Wireless Access Points shall be controllable centrally. The solution shall 

be controller based using CAPWAP protocol. 

O. The wireless system shall be able to detect, identify and locate the source 

of interferences 

P. A dedicated radio shall be used to detect interference 

14.6.6-p2 The ANWI Contractor’s provided LAN Service shall conform to the 

following Service Level Agreement/Targets: 







Continuous 


Daily/Weekly 






Switch Throughput (Server-Server) 

~ 1 Gbps 

Switch Throughput (Server-Client) 

~ 100 Mbps 

Network Latency < 10 ms (layer 2/3) 







14.6.7.1-p1 The ANWI LAN (wired and wireless) design shall describe the 

following internal interfaces and dependencies: 

Processing 

Storage 

Printing 

User Services 

LAN X X X X X X X X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 



LAN 

Cross Domain 

Email 

14.6.7.2-p1 The ANWI Contractor shall include the configuration files of network 

devices shall be available on both online and offline storage. 


14.6.8-p1 The ANWI Contractor shall test the (wired and wireless) LAN service 

using the following End-to-End Test Scenarios: 

A. Throughput/latency tests to verify switch performance. 

B. Performance testing: 

1. From server to server (rack switch). 

2. From server to end devices (end-to-end). 

3. From end device to end device. 

IM 

B. Spanning tree testing. (or comparable protocol e.g. TRILL) 

C. Test accessibility of restricted VLANs (E.g. the management VLAN should 

be restricted from a user VLAN). 

D. Test IPv6 support (IPv6 only, IPv4/IPv6 together). 


14.6.9-p1 The ANWI Contractor shall train the ICTM staff on how to install, 

configure, operate and troubleshoot the following areas to support the LAN capability: 




D. Configuration of LAN infrastructure. 

E. Management of LAN infrastructure. 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 





SECTION 15. ANNEX G: UCC SERVICES 

15.1 APPENDIX 1: Introduction to UCC Services 


15.1.1-p1 This section describes the requirements of the UCC capability to be 

provided as part of the ANWI for the new NATO HQ building. While this contract only 

deals with NATO HQ UCC capability, UCC services will also be implemented NATO 

Wide at a later stage. 

15.1.1-p2 UCC is defined as an evolving technology architecture that integrates 

real-time and non real-time communication and collaboration services delivered 

ubiquitously across a protected and highly available network infrastructure. Its goal is 

to improve productivity and efficiency through enhanced human communication and 

collaboration. UCC is not a single product, but a set of services that provide a 

consistent unified user interface and user experience across multiple devices and 

media types. 

15.1.2 Scope 

15.1.2-p1 The services made available shall be configurable using the parameters 

in the following table: 

Scenario Parameter Minimum Set of Values 

Users NNHQ User Types (Reference: 1.1.1.7.1.) 

Devices 

NNHQ Managed 

Locations 

Inside NNHQ Campus – Class 2 (Reserved Zone) 

Inside NNHQ Campus – Class 1 (Secure Compartments) 

Inside NNHQ Campus – ADMZ (Controlled Zone) 

Inside NNHQ Campus – Base (Common Zone) 

Outside NNHQ Campus – Remote Sites 

Outside NNHQ Campus – Anywhere 

Table 15.1 UCC Overall Site Parameters 


15.1.2.1-p1 The requirements apply for: NATO SECRET, EAPC SECRET, 

BUSINESS (NR) and PUBLIC. 


15.1.2.2-p1 The UCC service components shall be delivered and installed in two 

NNHQ server rooms. The ANWI Contractor shall design a physical layout in 

compliance with the limits defined in the Processing Services Location (Section 

15.2.3.2). 

15.1.2.2-p2 The client software shall be provisioned as described in Annex H. 



15.1.2.3 UCC Integration 



15.1.2.3-p1 The UCC environment shall be constructed through the integration 

of a set of communication and collaboration services that either exist in current 

NATO systems or additional UCC services provided through the ANWI UCC system. 

When combined together they shall integrate to the full extent, allowing users to 

make use of all available services in a converged unified communication and 

collaboration environment. 

15.1.2.4 UCC Integration Concept 

15.1.2.4-p1 The NNHQ UCC Services shall be part of an integrated approach, 

the UCC concept, as depicted in figure 15.1. 

Figure 15.1: NATO UCC Concept 

15.1.2.4-p2 The UCC capability shall be compliant with the NATO UCC 

conceptas depicted in figure 15.1. 

15.1.2.4-p3 

Integration. 

The UCC capability shall provide Service and User-Interface 

15.1.2.4-p4 The ANWI Contractor shall deliver a UCC capability which shall 

provide the following service components: 

A. Voice. 

B. Voicemail. 

C. VTC. 

D. Email. 

E. Fax. 

F. Calendar/scheduling. 



G. Instant Messaging (IM). 

H. Presence. 

I. Unified messaging. 

J. Directory services. 

K. Collaboration tools. 

L. Mobility. 



15.1.2.4-p5 As part of the Detailed Technical Design of his technical solution to 

be provided in the relevant Section of the ANWI Design Document, the ANWI 

Contractor shall describe and provide the ANWI UCC design that reflects the ANWI 

UCC logical model and ANWI UCC architecture as specified in sections 15.1.3- 

15.1.4 covering the following aspects: 

 

 

 

 

The network access requirements for both ANWI internal and external network 

interfaces. 

The service integration capabilities that comprise a full unified capability. 

The unified UCC ELM capability and its interface to centralised management. 

Using a modular approach as introduced in the ANWI UCC architecture. 


15.1.2.5-p1 Figure 15.2 shows the ANWI UCC services mapping to the services 

taxonomy as introduced in Annex C. 





Figure 15.2: ANWI UCC services mapped to services taxonomy. 





15.1.3 Logical Model 

Figure 15.3: NATO UCC Logical Model 

15.1.3-p1 The UCC delivered capability shall be based on the logical model as 

depicted in figure 15.3 and have at least the following logical modules: 

A. UCC Service Integration Module: The module that shall achieve the 

unified communications and collaboration presentation of both end-user 

(UCC client) as well as backend service (UCC core and NATO HQ 

services components). 

B. NATO HQ UCC clients module providing the service to the UCC enabled 

clients to include the UCC vendor user application that allows a user to 

have unified access to all UCC marked services as well as the interface 

(API) to user application either residing on the client or as part of the 

ANWI backend services. 

C. NATO HQ UCC Service Delivery System module: responsible for end-toend 

delivery of UCC services by utilising the ANWI core UCC services, the 

NATO HQ service components (other ICT service in the building) and the 

services available through the services domain gateway (either NATO 

wide or commercially provided UCC related services). 

D. Services domain gateway module that is interface from the UCC service 

delivery module to the external UCC related services. 

15.1.3-p2 The Logical Model abstracts from the security domain model. The 

ANWI contractor shall determine with ANWI UCC components need to be hosted on 

what infrastructure and associated domains/DMZ segments. 





15.1.3-p3 As part of the Detailed Technical Design of his technical solution to be 

provided in the relevant Section of the ANWI Design Document , the ANWI 

Contractor shall, in compliance with the Logical Model defined in Figure 15.3, 

describe the architecture (server and client side) delivering the UCC experience and 

the integration functions. 

15.1.3-p4 The UCC Core services shall provide interfaces that adhere to the 

prescribed UCC services internal and external interface standards to integrate with 

all other ANWI services. 

15.1.3-p5 The UCC internal interfaces between the UCC logical model 

components shall adhere to the prescribed UCC service standards and based on 

open industry standards to achieve a coherent and unified architecture for all 

identified UCC services. 

15.1.3-p6 The ANWI Contractor shall outline the compatibility of the UCC 

capability with existing service component systems that are either identified as 

internal ANWI interfaces or external ANWI interfaces in each of the individual UCC 

service specification as provided in Appendix 15.2-15.12. 

15.1.3-p7 UCC Service Integration Module shall provide service integration at 

either server and/or client side. 

15.1.3-p8 The NATO HQ UCC capability shall, integrate with the ANWI cross 

domain module (see Annex E) to provide external connectivity via the Service 

Domain Gateways to allow Alliance or NATO wide interoperability or interoperability 

with services as provided by commercial providers.. 

15.1.3-p9 The ANWI Contractor shall provide UCC clients with both UCC User 

applications and with UCC functionalities which are integrated with business 

applications…delivering the UCC experience. 

15.1.3-p10 The delivered UCC capability shall allow the usage of all different 

types of user devices as described in the Client Provisioning Service Annex. 

15.1.4 ANWI UCC Architecture 

15.1.4-p1 Based on the logical model from figure 15.3 the architecture is defined 

and visualised in figure 15.4. The modules are described in more detail in the 

following sections. 





Figure 15.4: ANWI UCC Architecture, Service Component View 

15.1.4.1 HQ UCC Service Delivery System 

15.1.4.1-p1 The architecture introduces three main building blocks mapping the 

to the logical model as introduced in figure 15.3: 

A. NATO HQ UCC Service Delivery System, which consists of the following 

modules: 

1. NATO HQ Service Component Systems, (external) non-UCC core 

systems that consume UCC services and deliver UCC based services, 

(these could be specific Business applications). In the remainder of this 

section these systems will not be defined in further detail. 

2. UCC Core Service Interfaces. 

3. UCC Service Delivery Core System, which provide the UCC SMC, UCC 

service integration API’s and UCC Client service API’s. 

B. Service domain gateway 

C. NATO HQ UCC Clients including the UCC devices and, UCC client 

integration API and the UCC user interfaces. 

15.1.4.1-p2 The architecture reflects a clear distinction between the NATO HQ 

UCC Service delivery System and the UCC Service Delivery Core system. 

Integration of (existing or future) service components are defined at this layer via 

(Industry standard) interfaces. The ANWI contractor shall deliver NATO HQ UCC 

services by using the UCC core services interfaces. 




15.1.4.2 UCC Service Delivery Core System 


15.1.4.2-p1 The following components are envisioned to form the UCC Service 

Delivery Core System: 

A. The Service Component Core system interfaces shall allow integration of 

“external Industry Standardised Interfaces into the UCC capability. This 

will enable new NATO defined service components (NATO HQ Service 

Component systems) to be integrated into the vendor proposed solution. 

B. The UCC services are available via the client interfaces (APIs) for the 

UCC Clients. 

C. This component implements the management functionality of the UCC 

capability/appliance. It shall be scalable and provide wide support of 

clients: 

1. Services management. 

2. User management. 

3. Monitoring & reporting. 

4. Security. 

15.1.4.2-p2 The delivered UCC capability shall allow modular expansion by 

addition or hardware and / or software. The ANWI Contractor shall identify the 

granularity and limitations of the delivered UCC capability expansion in the Detailed 

Technical Design part of the ANWI Design Document. The contractor shall explain 

and describe how the modular expansion capability of the UCC capability will be 

implemented. 

15.1.4.2-p3 The UCC Service Delivery Core system shall deliver the 

functionality as required for each of the ANWI UCC services as specified in Appendix 

15.2-15.12. 

15.1.4.2-p4 The UCC service shall provide seamless integration between the 

UCC core system and the NATO-defined service components. The ANWI Contractor 

delivered capability may provide all the service components as part of the UCC core 

system but shall provide as a minimum, functionality identified by the NATO-defined 

service components outlined in Figure 15.4. 

A. Voice 

B. Voicemail 

C. VTC 

D. Email 

E. IM 

F. Presence 

G. Directory 

H. Collaboration Tools 

I. Calendar/scheduling 

J. Mobility 

15.1.4.2-p5 The integration of the functionality of the different service 

components required to deliver the UCC user experience may happen in the core 

system or in the client. The ANWI Contractor shall specify where in the architecture 

the functionality provided by his capability resides 

15.1.4.2-p6 The UCC capability shall provide a unique user id valid for reaching 

the user via different service components. 





15.1.4.2-p7 The UCC Service Delivery Core System shall perform access 

control for access of UCC users to the UCC services utilising the user and device 

authentication mechanism.as specified in annex F. 

15.1.4.3 General UCC Client requirements 

15.1.4.3-p1 Clients: UCC Clients are Clients providing access to several of the 

UCC service components. The following Clients shall be used: 

A. Analogue/Basic SIP phone. 

B. Medium SIP phone. 

C. Multimedia SIP phone. 

D. VTC client. 

E. Smartphone/Basic wireless device. 

F. Tablet PC/Medium Wireless Device. 

G. Netbook, Laptop/Advanced wireless Device. 

H. Desktop computer/Server. 

15.1.4.3-p2 The ANWI Contractor shall provide a list of Clients proposed in their 

capability and shall identify, for all ANWI clients and all possible other client, the level 

of support of UCC services and client user interfaces. 

15.1.4.4 Service Domain Gateway 

15.1.4.4-p1 Services Domain Gateways shall provide service and/or security 

related cross domain functions. All UCC service gateway functions shall meet 

requirements as stated in the Cross Domain Services in Annex E Appendix 2 and 

adhere to the end-2-end UCC services cross domain interfaces as specified in each 

UCC service specification in appendix 15.2-15.12 

15.1.5 UCC Services and NNHQ Multiple Classification Networks 

15.1.5-p1 UCC is most efficient if there is one UCC environment serving the entire 

community of the NNHQ. However NNHQ shall consist of 4 separated classification 

domains: 

A. Public domain. 

B. Business Network (NATO Restricted network). 

C. Euro-Atlantic Partnership Council (EAPC) domain. 

D. NATO Secret domain. 

15.1.5-p2 UCC service components shall be available on all 4 networks. However, 

not all the networks receive all the UCC capabilities. 

15.1.5-p3 Connectivity between the different classification networks shall be 

strictly controlled by gateways which limit full functionality integration of each of the 

service components. In addition to the service requirements between the different 

classification networks inside the NNHQ, there are also service requirements to other 

NATO locations (federated or equal level of security domain), on external networks 

15.1.5-p4 A service matrix table at each service component provides an overview 

of services that shall be supported as a minimum, in between the multiple 

classification networks both internal to NNHQ as well as to external locations. The 

comprehensive table including all services requirement can be found in section 

Technical Annex D section 12.6: End-to-End Services. 







15.1.5-p5 The ANWI Contractor shall implement UCC Services on the NS 

infrastructure supporting the NS and EAPC user domains and on the NU/NR/Public 

infrastructure supporting the Business (NR) and Public user domains. 

15.1.5-p6 The ANWI Contractor shall design the UCC services considering all the 

required capabilities including the high level capabilities requirements of service 

management and information management. 

15.1.5-p7 The ANWI Contractor shall clearly describe how the service and the 

individual capabilities are integrated in the service management and control (SMC) 

and Information Assurance Services in support of the overall ICT SMC and IA 

management concept as indicated in Annex E. 

15.1.6 UCC Service Management Requirements 

15.1.6-p1 This component implements the management functionality of the UCC 

capability/appliance. It shall be scalable and provide wide support of management 

functions and clients: 

A. Services management. 

B. User management. 

C. Monitoring & reporting. 

D. Security. 

15.1.6-p2 The ANWI Contractor shall deliver UCC management consoles the 

UCC management functionality for use on designated workstations subject to user 

role.providing centralized system management of the whole service and service (and 

service supporting) components (per security domain). 

15.1.6-p3 The UCC system shall support availability management from the 

centralized overarching management system Integrated Operation Support System 

(IOSS) using SNMPv3. 

15.1.6-p4 There shall be policy-based centralised user-, service and client 

management (policy based deployments to control user environment, software 

update propagation). 

15.1.6-p5 The ANWI Contractor shall provide the following Management functions 

that shall be run from centralised locations for the user, service, client and system 

for: 

A. Planning. 

B. Configuration. 

C. Deployment. 

D. Activation. 

E. Quality monitoring (passive and/or active data collection). 

15.1.6-p6 The ANWI contractor shall implement service performance reporting 

(scheduled and on demand reporting). 

15.1.6-p7 The ANWI contractor shall implement the necessary security 

mechanisms in-line with the SRA to achieve a robust security capability for UCC 

SMC user access. 

15.1.6-p8 There shall be detailed error logging with fault resolution (event 

correlation, root cause analysis).



15.1.6-p9 Devices shall not be allowed to connect to the UCC system without 

granted network access (authentication). 

15.1.6-p10 The UCC shall keep call records of attempted and successful calls, 

connections recording originator, receiver, session start and session stop 

(asymmetric messaging record a message transmitted timestamp and no session 

start and stop timestamp). 

15.1.6-p11 The ANWI Contractor shall provide information on future UCC 

technologies and enhancement that can become in scope for a mature and solid 

infrastructure services towards 2015. 

15.1.6-p12 Both static provisioning and DCHP based provisioning shall be 

possible to configure network parameters. 

15.1.6-p13 

upgrade. 

The ANWI SMC shall be capable of remote firmware and software 

15.1.7 Service Level Agreement/Targets 

15.1.7-p1 As indicated in the definition, the UCC services provide all 

communication and collaboration capabilities including synchronous capabilities for 

all users and other services. 

15.1.7-p2 The UCC service shall have a service availability of 99.99%. This 

availability shall be ensured across both server rooms. This availability figure shall be 

achieved end-to-end over all underlying sub-services, (excluding external 

dependency outages). 

15.1.7-p3 For some of the sub-services described in the appendix, some 

performance degradation is acceptable in case of a catastrophic failure (E.g. Server 

room failure). More details can be found in each of the UCC service annexes 15.2- 

15.12. 

15.1.7-p4 The common SLTs for each of the individual services as shown in the 

table below shall be achieved: 


UCC Services 








Response Times 

N/A 




Continuous 








UCC Services 





Number of Corrective Maintenance Actions 1 

Number of Preventive Maintenance Actions 1 

Table 15.1 UCC SLT/SLA 



15.1.7-p5 

Performan 

ce 

Capacity 

(minimum) 

Mean 

Opinion 

Score (ITU 

P.800) 

Voice 


Other required specific sub service SLTs are specified in the table below: 

1000 

simultaneous 

internal calls, 

500 

simultaneous 

external calls 

Internal 

higher than 

4.0, External 

higher than 

Voic 

ema 

il 

30 

min 

utes 

/use 

r 

VTC 

100 

simultaneous 

internal 

desktop VTC, 

100 

simultaneous 

external 

desktop VTC, 

Simultaneous 

VTC from ALL 

VTC/Conferen 

ce rooms 

Email 

10 internal 

messages / hour / 

user, 10 external 

messages / hour / 

user 

Unified 

Messagi 

ng 

N/A 

FAX 

200 

messages 

/hour 



Instant Messaging 

ALL users to be 

online 

simultaneously, 10 

internal messages / 

hour / user, 10 

external messages / 

hour / user 

Prese 

nce 

ALL 

users 

to be 

online 

simult 

aneou 

sly 

UCC 

Directo 

ry 

ALL 

users to 

be 

online 

simulta 

neously 

3.8 N/A N/A N/A N/A N/A N/A N/A N/A N/A 


Collaboration 

200 simultaneous 

internal sessions, 

100 simultaneous 

external sessions 

Mobility 

1000 

simultaneous 

internal calls, 

500 

simultaneous 

external calls 

Higher than 

3.8 

Less 

than 1 

secon 

d N/A N/A N/A 

300 dpi or 

higher N/A N/A N/A 1080p or Higher N/A 

Delay (s) Max … N/A Max … N/A N/A N/A 

720p or 

Resolution N/A N/A Higher N/A N/A 

Less 

than 

100 

Server 

messag 

Queue N/A N/A N/A 

es N/A N/A N/A N/A N/A 

Less than 100 

messages 

Less than 5 minutes 

Less than Less than 5 seconds 

external, Less than 1 

5 minutes external, Less than 2 

Send Delay N/A N/A N/A 

minutes internal N/A external seconds internal N/A N/A N/A N/A 

Request/se 

c N/A N/A N/A N/A N/A N/A N/A N/A 100 N/A N/A 

Less 

Latency N/A N/A N/A N/A N/A N/A N/A N/A than 1 N/A N/A

Performan 

ce 

Voice 

Voic 

ema 

il 

VTC 

Email 


Unified 

Messagi 

ng 

FAX 


Prese 

nce 

UCC 

Directo 

ry 

ms 

internal 


Collaboration 

For internal 

connection, 

Responsive 

ness N/A N/A N/A N/A N/A N/A N/A N/A N/A 

Keypress delay less 

than 500 ms 

3 seconds 

10 secondes 

External, 1 

External, 5 

Max time second 

seconds 

5 seconds 

before call Internal N/A Internal N/A N/A External N/A N/A N/A N/A 

Peak 

Mobile 

Client (%) N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 100 

Average 

Mobile 

Client (%) N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 40 

Table 15.2 Sub Service SLTs 

Mobility 

N/A 

3 seconds 

External, 1 

second 

Internal 






15.1.8-p1 The ANWI Contractor shall manage UCC services through the SMC. 

The SMC shall also provide the capability to provide reports on the different UCC 

sub-services. These reports shall also be required to measure the compliance of the 

system towards the SLA requirements. 

15.1.8-p2 Individual sub-services shall be tested for compliance on the technical 

requirements of the specific sub-service. 

15.1.8-p3 Overall end-to-end UCC integration tests shall be conducted to verify 

the integration of the individual capabilities into the service. These integration tests 

shall include the SMC and IA capabilities and requirements. 




15.2 APPENDIX 2: Voice ServiceComponent 



15.2.1-p1 The ANWI Contractor shall provide a new voice service component for 

the NNHQ which shall integrate with the current NATO wide voice service 

component. 

15.2.2 Scope / Scenario 

15.2.2-p1 The ANWI Contractor shall design and implement a voice service into 

the ANWI to deliver voice communications support that integrates into the ANWI 

UCC. 

15.2.2-p2 The ANWI voice service shall be designed and implemented to support 

the following interconnection scenarios: 

User 

Servic 

es 

1/2 

From way 

G 

W To 

Provide 

r 

External 

service Remarks 

Voice NR - NR ANWI VoIP on NR BUS to BUS soft clients 

PUBL G 

VoIP session between ANWI PUBLIC to ANWI NR (From GW3 

IC 

NAT 

O 

NR > 

NAT 

O 

PUBL 

IC > 

NR 

PUBL 

IC 

W3 NR ANWI 

to GW2 to NR) 

G 

VoIP session between NATO VoIP Networks to ANWI NR (From 

W3 NR NGCS - 

GW3 to GW2 to NR) 

G exter 

VoIP session between External Networks to ANWI NR (From 

W3 nal NGCS - 

GW3 to GW2 to NR) 

G 

W3 NU NGCS - VoIP session between NATO Networks / ANWI NU 

G exter 

W3 nal NGCS - VoIP session between External Networks to ANWI PUBLIC 

G exter Commer 

W3 nal cial - Commercial Backup Route for Above NGCS link 

G exter Commer 

W3 nal cial - Commercial Backup Route for Above NGCS link 

Table 15.3 Voice service interconnections 



15.2.3.1-p1 The ANWI Contractor shall deliver and install the voice service on 

the NATO SECRET, BUSINESS (software clients) and PUBLIC networks. 

15.2.3.1-p2 All NNHQ users shall access commercial and NATO core network 

telephony via the PBX/Soft PBX located on the BUSINESS network. 

15.2.3.1-p3 NNHQ secured voice shall be provided via VOIP phones routed 

through the NGCS’ NATO SECRET wide area network. 


15.2.3.2-p1 The ANWI Contractor’s UCC service voice components shall be 

delivered and installed in the two NNHQ server rooms per the physical layout and 

limits defined in the communications’ room Appendix (Annex B). 





15.2.3.2-p2 The ANWI voice endpoints shall be distributed across the NNHQ 

campus and remote offices as described in Annex M. 

15.2.3.2-p3 The ANWI Contractor shall design and implement the voice service 

in accordance to the following: 

A. Functional, performance and Interface details of the Voice Service 

component and integration capability are outlined in the following sections. 

B. The ANWI Contractor shall provide a new voice service component for the 

NNHQ which shall integrate with the current NATO wide voice service 

component. 

15.2.3.3 Functional requirements: 

15.2.3.3-p1 The NNHQ voice service component has to have at a minimum, the 

same functionality as the current NATO wide voice services. 

15.2.3.3-p2 The delivered NATO HQ Voice System (NVOS) equipment shall be 

modular and expandable as follows: 

A. The initially delivered hardware and software equipment for 6000 users 

shall have expansion capability up to 10,000 users which should be 

reached by only making minor (configurational) changes. 

B. The delivered equipment shall allow expansion up to 15,000 by addition of 

hardware and software. 

C. The ANWI Contractor shall specify the limitation of the expansion required 

above in the UCC Detailed Technical Design. 

15.2.3.3-p3 The NATO HQ Voice System shall provide Call management and 

System management functions via dedicated Consoles. 

15.2.3.3-p4 The NATO HQ Voice System (NVOS) shall be made of an IP 

Private Branch Exchange (IP PBX) using Voice over IP (VoIP) and Telephony over 

IP (ToIP) technology and principles. The delivered IP PBX shall be composed as a 

minimum of the following components: 

A. A call / session manager. 

B. A Gateway. 

C. A management system. 

15.2.3.3-p5 Call Admission Control shall be enforced to meet the service 

performance requirements. 

15.2.3.3-p6 5 levels of priority for each provided UCC services and features 

shall be delivered 

15.2.3.3-p7 

Dial and DTMF tones and announcements shall be provided. 

15.2.3.3-p8 The system shall ensure that the authorized precedence level is not 

exceeded by the user. 

15.2.3.3-p9 The voice routing plans shall comply with numbering schemes such 

as STANAG4214, ITU-T E.164 and the NGCS 7 digit-numbering scheme. 

15.2.3.3-p10 Echo cancellation shall meet the requirements of ITU 

Recommendation G.165 and G.168. 





15.2.3.3-p11 The Voice Service Component shall be built on a common 

Integrated Session Management function based on RFC 3261 / RFC 4411 / RFC 

4412 based MLPP capable SIP protocol. 

15.2.3.3-p12 The NVOS shall be capable of providing following types of trunks 

interfaces: 

A. SIP Trunking. 

B. Analogue trunk access. 

C. EURO ISDN BRA (2B + D). 

D. EURO ISDN PRA (30B + D, E1 or fractional E1). 

E. QSIG (standard ETS 300 172 of ETSI). 

F. DPNSS1 (E1 or fractional E1). 

G. CAS (Channel Associated Signalling). 

15.2.3.3-p13 The NVOS shall provide different subscriber types: 

A. Analogue subscribers. 

B. ISDN subscribers using Basic Rate interfaces. 

C. VoIP subscribers using SIP interfaces. 

D. VoIP subscribers using H 323 interfaces. 

E. DECT subscribers (GAP Compliant). 

15.2.3.3-p14 The NVOS shall provide the following basic telephone services for 

all subscriber types (PSTN, ISDN, VOIP, DECT): 

A. Direct call to internal network. 

B. Direct call to NCN. 

C. Direct call to local and national PTT. 

D. Direct call to international PTT. 

E. Direct call to other connected private or corporate telephone network. 

F. Direct calls from any external networks. 

15.2.3.3-p15 The NVOS shall offer a minimum of seven classes of service so that 

users can be allocated access to networks in accordance with the staff function 

performed. The seven classes of service shall be individually and collectively 

assignable and are the following: 

A. Access to the international public network. 

B. Access to the national public network. 

C. Access to the local public network. 

D. Access to the NATO Core network. 

E. Access to the National Defence Network to which the switch is connected. 

F. Access to an International Virtual Private Network (IVPN). 

G. Access to other extensions on the same IP PBX. 

15.2.3.3-p16 

The user shall be notified of missed calls. 

15.2.3.3-p17 NVOS shall be capable of providing interfaces to user client devices 

(not enabled with IP-VOIP interface) by either using interface cards or terminal 

adapters. 

15.2.3.3-p18 

The NVOS shall permit the hot swap replacements of system parts. 

15.2.3.3-p19 The ANWI Contractor equipment shall implement the configuration 

of the numbering plan as currently in use by NATO. 







15.2.3.3-p20 The ANWI Contractor equipment shall allow number range 

expansion and re-configuration of the initial numbering plan. 

15.2.3.3-p21 The ANWI Contractor equipment shall provide public service 

provider features through a personal subscriber identification code. 

15.2.3.3-p22 The NVOS shall include as a minimum the following supplementary 

services and features: 

A. Abbreviated dialling (general). 

B. Abbreviated dialling (individual). 

C. Calling line identification presentation (CLIP). 

D. Connected identification presentation (COLP). 

E. Call transfer (XFER). 

F. Call forwarding busy (CFB). 

G. Call forwarding no reply (CFNR). 

H. Call forwarding unconditional (CFU). 

I. Call Wait (WAIT). 

J. Call completion to a busy subscriber (CCBS). 

K. Add-on conference call (CONF). 

L. Pre-set conference. 

M. Closed User group (CUG). 

N. Hotline (automatic call to a pre-set number). 

O. Night service (all incoming calls automatically re-directed). 

P. Call pick up (any member of a group of users to pick-up). 

Q. Group hunting. 

R. Help line (in case of failure of the CTN, automatic connection to PTT line). 

S. Notification of missed calls. 

T. Audio conferencing for 3 or more user clients. 

U. Automatic call back on busy subscriber. 

15.2.3.3-p23 The NVOS shall allow remote access of centralised management by 

the NCIA NATO Wide Voice System Management Team. 

15.2.3.3-p24 

15.2.3.3-p25 

The NVOS shall implement call billing and accounting per user. 

The NVOS shall allow its management using SNMPv3. 

15.2.3.3-p26 The ANWI Contractor shall deliver an automatic pager or SMS 

capability to forward alarms to technicians in the event of an equipment failure. The 

level of alarm shall be configurable and related to failure types as defined by the 

maintenance team. 

15.2.3.4 Performance requirements 

15.2.3.4-p1 The delivered NVOS shall be configurable in redundant 

configurations so that failure of one piece of equipment shall not render the session 

management service unavailable. 

15.2.3.4-p2 The delivered NVOS shall have an architecture that provides full 

redundancy of all critical elements. Critical elements are elements whose failure 

causes a loss of NVOS capability (connection, services and features) and currently 

processed calls. This particularly implies the redundancy of at least power supply and 

call processing devices/cards.



15.2.3.4-p3 The availability of any subscriber telephone line shall be as a 

minimum of 99.95%. 


15.2.3.5-p1 The Voice system components shall support the following Interfaces 

and protocols: 

A. Ethernet, ISDN and Analogue interfaces. 

B. IP protocols SIP, RFC 3261 / RFC 4411 / RFC 4412 based MLPP 

capable SIP, RTP/SRTP. 

C. QSIG on ISDN interfaces. 

D. Simplified Message Desk Interface (SMDI). 

15.2.3.5-p2 The Voice component shall be able to interface to H323. 

15.2.3.5-p3 The SIP RFCs implemented within the delivered UCC capability 

shall be listed in the UCC Detailed Technical Design. 


15.2.4.1 Internal Interfaces 

Processing 

Storage 

Printing 

User 

Services 

Voice X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 

15.2.4.2 Cross Domain interfaces 


PUB-CD3 Two way PUB-NVO NATO voice VOIP 

Two way PUB-CVO Comm. voice PSTN, ISDN, VOIP 


BUS-CD2 Two way BUS-CVO Telephony PSTN Commercial voice 

Two way BUS-NVO Telephony VOIP NATO voice 


15.2.4.3-p1 RTO: 30 minutes 

15.2.4.3-p2 RPO: 30 minutes 






15.2.5.1 End-to-End Test Scenario 

15.2.5.1-p1 All scenarios described in Section 15.2.2-p2 of this Annex shall be 

included as test cases. 

15.2.5.1-p2 

Hardware Inspection – Physical inspection of the components 

15.2.5.1-p3 Capacity Tests: 

A. Concurrent use. 

15.2.5.1-p4 Availability Test 

A. Demonstrate High availability. 

B. Simulate Server room fail-over. 

C. Simulate component failure (disk, interface, controller). 

D. RTO and RPO reporting (requirements vs. test results). 

15.2.5.1-p5 Performance tests (test shall be conducted over a predefined period 

not point in time test): 

A. Call drops monitoring. 

B. Call quality monitoring. 

15.2.5.1-p6 Overall reporting using SMC service: 

A. Call details (lists/logs). 

B. Statistical usage details (totals, time based distributions, averages). 

15.2.5.1-p7 IA tests shall include the following minimum set where applicable: 

A. Access Control Mechanism 

B. Detection Performance (Malware, Content Checking) 

C. Releasability Control 

D. Integrity Checking 

E. Intrusion Detection 

F. Logging 

G. Auditing 


15.2.6-p1 The ANWI Contractor shall train the NNHQ-SPA staff on how to install, 

configure and troubleshoot the following areas to support the storage service: 

A. Hardware installation and configuration 

B. Hardware troubleshooting and fault finding 

C. Hardware maintenance tasks (e.g. Firmware and Bios upgrades) 

D. Software installation 

E. Software troubleshooting 

F. Basic configuration and management 

1. User / Line management 

G. Advanced configuration and management 

1. HA policy and failover scripts 

15.2.6-p2 The ANWI Contractor shall train the NNHQ users on how to use the 

Voice service 




15.3 APPENDIX 3: Voicemail ServiceComponent 



15.3.1-p1 Voice Mail services shall support the overall UCC solution to 

complement the voice services with the capability to store messages for missed calls, 

to be presented to the user when he/she is available, through the voice system and 

email. 


15.3.2-p1 The voicemail service shall be available to all authorized UCC users, 

configurable by system administrator. 

15.3.2-p2 The voicemail service shall cover the following scenarios: 

A. Customize the greeting message (centrally and by user if authorized). 

B. Customize a PIN number for the user 

C. Answer unanswered calls (if configured). 

D. Answer second calls if line is busy (if configured). 

E. Answer all calls (if configured). 

F. Record message by calling party, if the caller wishes to do so. 

G. Indicate that new voicemail is received in all relevant UCC interfaces. 

H. Enable processing of messages (listen/reply/forward/delete/store) 

I. Enable listening voicemail through all relevant UCC interfaces, including 

but not limited to: 

1. Voice clients / software clients. 

2. Email attachment. 



15.3.3.1-p1 

PUBLIC. 


The Voicemail service shall be available on: BUSINESS (NR) and 




15.2.3.2). 

15.3.3.3 General Requirements 

15.3.3.3-p1 The ANWI Contractor shall provide a new voicemail service 

component for the NNHQ which shall integrate with the current NATO wide voice 

service component.be capable of answering all incoming calls and recording 

messages based on the configuration. 

15.3.3.3-p2 Functional, performance and interface details of the Voice Service 

component and integration capability are outlined in the following sections. 



15.3.3.4 Functional Requirements 



15.3.3.4-p1 The ANWI Contractor shall deliver a voice mailbox feature which 

shall provide to all users their own voice mailbox accessible via personal 

password/PIN. 

15.3.3.4-p2 The ANWI Contractor shall deliver customizable IVR features for the 

user voicemail box: 

A. Customize the greeting message (centrally and by user if authorized). 

B. Customize a PIN number for the user 

C. Answer unanswered calls (if configured). 

D. Answer second calls if line is busy (if configured). 

E. Answer all calls (if configured). 

F. Record message by calling party, if the caller wishes to do so. 

G. Indicate that new voicemail is received in all relevant UCC interfaces. 

H. Enable processing of messages (listen/reply/forward/delete/store) 

I. Enable listening voicemail through all relevant UCC interfaces, including 

but not limited to: 

1. Voice clients / software clients. 

2. Email attachment. 

15.3.3.4-p3 

15.3.3.4-p4 

15.3.3.4-p5 

15.3.3.4-p6 

15.3.3.4-p7 

The voicemail system shall allow skipping of voicemail messages. 

Voicemail shall be accessible via any fixed or mobile client. 

The Client shall display a message waiting indicator. 

The messages shall be stored for a configurable amount of time. 

Deleted messages shall be reported to the user. 


15.3.3.5-p1 The voicemail messaging system shall comply with section 15.2.3.6: 

Voice Service components - Protocols. 



Processing 

Storage 

Printing 

User 

Services 

Voice X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 

15.3.4.2 Cross Domain interfaces 







PUB-CD3 Two way PUB-NVO NATO voice VOIP 

Two way PUB-CVO Comm. voice PSTN, ISDN, VOIP 


BUS-CD2 Two way BUS-CVO Telephony PSTN Commercial voice 

Two way BUS-NVO Telephony VOIP NATO voice 


15.3.4.3-p1 

15.3.4.3-p2 


RTO: 30 minutes 

RPO: 30 minutes 


15.3.5.1-p1 All scenarios described in Section 15.3.2 of this Annex shall be 


15.3.5.1-p2 

Hardware Inspection – Physical inspection of the components 



B. Per user message capacity. 

C. Total message capacity. 

15.3.5.1-p4 Availability test: 



C. Simulate component failure (e.g. disk, interface, controller). 




A. Answered calls monitoring. 



A. Answered Call details (lists/logs). 










F. Logging 

G. Auditing 





configure and troubleshoot the following areas to support the voicemail service: 




D. Software installation. 

E. Software troubleshooting. 

F. Basic configuration and management. 

1. User / Voicemail box management. 

G. Advanced configuration and management 



Voicemail service. 




15.4 APPENDIX 4: VTC ServiceComponent 



15.4.1-p1 VTC/VMR/Desktop VTC services shall be delivered as a part of the 

UCC capability, in close coordination with NATO Wide VTC Project and HN BE AVI 

Project. 

15.4.1-p2 The complete capability will be a sum of HN BE AVI project, NATO 

Wide VTC project and ANWI VTC/VMR/Desktop VTC capabilities. 


15.4.2-p1 

The service shall cover the following scenarios: 

User Services From 1/2 way GW To Provider External srv Remarks 

VTC/VMR NSWAN GW1 NS NGCS NATO Wide VTC VTC session btw ANWI and NATO Wide VTC 

Services NRWAN GW2 NR NGCS NATO Wide VTC VTC session btw ANWI and NATO Wide VTC 

NSWAN GW1 AVI NGCS NATO Wide VTC VTC session btw AVI and NATO Wide VTC 

NRWAN GW2 AVI NGCS NATO Wide VTC VTC session btw AVI and NATO Wide VTC 

NS - NS HN BE AVI VTC session btw ANWI and AVI endpoints 

NR - NR HN BE AVI VTC session btw ANWI and AVI endpoints 

NU - NU HN BE AVI VTC session btw ANWI and AVI endpoints 

NS - NS ANWI - VTC session within ANWI endpoints 

NR - NR ANWI - VTC session within ANWI endpoints 

NU - NU ANWI - VTC session within ANWI endpoints 



15.4.3.1-p1 

(NR). 


The VTC service shall be available on: NATO SECRET, BUSINESS 




15.2.3.2). 

15.4.3.2-p2 The VTC services shall, in addition to the VTC/VMR endpoints in 

the NNHQ main building , be provided to remote locations as specified in Annex M. 

15.4.3.3 General Description 

15.4.3.3-p1 The ANWI Contractor shall provide a VTC system which shall offer 

similar functions as listed in Project NATO Wide VTC [Ref: CO-13093-VTC]. 

15.4.3.3-p2 The delivered UCC capability shall integrate a VTC capability which 

shall be compliant with the NCIA Contract Reference CO-13093-VTC Technical 





requirements as expressed in the related SOW and technical annexes, specifically 

the NGTS-56. 

15.4.3.3-p3 The Video Service Component shall be built on a common 

Integrated Session Management function based on SIP protocol. 

15.4.3.4 Functional Requirement 

15.4.3.4-p1 See General description section 15.4.3.3. 

15.4.3.5 Performance Requirements 


15.4.3.6 Interface and protocols 




Processing 

Storage 

Printing 

User Services 

VTC services X X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 

15.4.4.2 Cross Domain Interfaces 


PUB-CD3 Two way PUB-NVTC VTC & VMR 


BUS-CD2 Two way BUS-NTVC VTC 


NS-GW1 Two way NS-NVTC VTC NATO wide VTC 




15.4.4.3-p1 

15.4.4.3-p2 



RTO: 30 minutes 

RPO: 30 minutes 







15.4.5.1-p2 



Hardware Inspection – Physical inspection of the components. 

15.4.5.1-p4 Availability Test: 







A. Call drops monitoring. 



A. Call details (lists/logs). 








F. Logging 

G. Auditing 



configure and troubleshoot the following areas to support the VTC service: 






F. Basic configuration and management: 

1. User / Line management. 

G. Advanced configuration and management:





VTC service. 




15.5 APPENDIX 5: Email Service Component 



15.5.1-p1 The ANWI email service is a strategic capability for NNHQ users and 

other systems and shall be provided as part of the UCC services as described in this 

Appendix. 


15.5.2-p1 The ANWI Contractor shall design a robust and highly available email 

service into the ANWI to ensure continuous email and messaging support. 

15.5.2-p2 The ANWI email service not only includes the back-end server 

components but shall also include the user side software to provide end-to-end 

delivery. 

15.5.2-p3 The ANWI email service shall be designed and implemented to support 

the following scenarios: 

User 

Service 

s From 

1/2 

way 

GW To 

Provide 

r 

External 

service 

Remarks 

Email NR - NR ANWI - Email within ANWI NR 

NRWA GW 

N 2 NR ? NATO NR mail Email between ANWI NR and NATO Federated NR 

GW Interne 

NR 3 t NGCS PIA gateway Email between ANWI NR and Internet Via GW2 -> GW3 

NS - NS ANWI - Email within ANWI NS 

NSWA GW 

N 1 NS NCIA Bi-SC AIS Email between ANWI NS and NATO Federated NS 

EAPC - EAPC ANWI - Email within ANWI EAPC 

NS 

GW 

4 EAPC ANWI - Email between ANWI NS and ANWI EAPC 

GW 

Email NOTIFICATION ONLY from ANWI NS to ANWI 

NS > 5 NR ANWI - 

NR 



15.5.3.1-p1 The ANWI Contractor shall deliver and install the MS Exchange 

email service on 3 networks: NATO SECRET, EAPC SECRET, and BUSINESS 

(NR). 


15.5.3.2-p1 The ANWI Contractor’s UCC service components shall be factored 

into the server room design then delivered and installed in the two NNHQ server 

rooms per the physical layout and limits defined in the Processing Services Location 

(Section 15.2.3.2). 

15.5.3.2-p2 The ANWI Contractor shall provision the email service client 

software as described in Annex H. 





15.5.3.2-p3 The ANWI Contractor shall design and implement the email service 


A. A separate email system per classification shall be delivered. 

B. The mail systems shall be to the same as the existing Bi-SC AIS email 

architecture and software which is currently based on MS Exchange. 

C. Cross domain and inter-site emails shall pass through an edge mail server 

that validates mail label requirements. 

D. The NS email organization will have one unique X400 namespace. 

E. Each email organization may have multiple SMTP namespaces. 

F. DNS MX records will allow delivery of SMTP messages from other mail 

organisations directly to the mailbox server assigned to a specified 

command. 

15.5.3.2-p4 The ANWI Contractor shall deliver the email service to comply with 

the following functional requirements: 

A. The following functions shall be supported on all four classifications: 

1. User/shared Mailboxes. 

2. Calendaring. 

3. Mail exchange. 

4. A directory offering the global address list functionality. 

5. Workstation Mail MAPI Client. 

6. Mail Formats: plain text, RTF, HTML, MIME. 

B. The Business network shall provide web based access to the email 

services for remote/mobility clients. 

C. The following requirements shall also be provided: 

1. Anti-Virus/SPAM filtering. 

2. Mail Priority Marking. 

3. Mail Delivery Notification Status. 

4. Out of office notification. 

5. Mailbox filtering capability. 

6. Mailbox archive. 

D. The email system shall allow use of “notification messages” to a 

configured recipient, without revealing the content or metadata of the 

message causing the trigger, to allow informing users on lower 

classification (e.g. NS to BUSINESS notification for the user to check NS 

Email). 

E. A redundant, active-active setup of the email environment shall be 

installed: 

1. All email databases shall be available in both server rooms. 

2. Processing capacity for the email service shall be available in both 

server rooms. 

F. Loss of up to a server room shall not hinder availability of the email service 

(some performance degradation is allowed). 

G. UNDELETE functionality shall be possible without restoring a complete 

database. 





H. Restoring a mailbox shall be possible without restoring a complete 

database. 

I. Email (including attachments) shall be archived for legal purposes for 5 

years. 

15.5.3.2-p5 The ANWI Contractor’s email service shall be designed and 

implemented to use the following interfaces and protocols: 

A. The following different NATO systems shall require interfaces to the new 

NATO HQ email system: 

1. The NATO legacy Informal Email system (i.e. the ‘NATO Email’ 

organisation). 

2. The NATO HQ informal Email system. 

3. The NATO nations informal email systems. 

4. The NATO systems embedding an email capability (they are MAPI 

compliant). 

5. The NATO legacy Formal Messaging system (only available on NS). 

6. The NATO Enclaves informal email systems. 

B. The Email service shall support as a minimum the following Interfaces and 

protocols: 

1. SMTP. 

2. MAPI/IMAP/POP3. 

3. HTTP/HTTPS. 

4. MIME/SMIME. 

5. HTML/RTF/plain text. 

15.5.3.2-p6 The ANWI Contractor’s provided email service shall conform to the 

following Capacity Requirements: 

A. Minimum user mailbox size (excluding legal archive requirement): 5 GB 



15.5.4.1-p1 The ANWI email service design shall describe the following internal 

interfaces and dependencies. 

Processing 

Storage 

Printing 

User Services 

Email X X X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 


and support the following cross domain interfaces: 

A. The following table describes the email interfaces for the Business 

Network: 


BUS-CD2 Two way BUS-INT Internet HTTP, HTTPS, SMTP Internet, NUWAN 

Two way BUS-NMSG NR Email SMTP NRWAN 

Email 

IM 

Voice 

VTC services 

Presence 



Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC




CD5-BUS One way NS-BUS Email XML Notification only 

BUS-APP - - ICTM Apps 

B. The following table describes the email interfaces for the EAPC Network: 


CD4-EAPC Two way NS-EAPC Email SMTP Releasable to EAPC 

EAPC-APP - - ICTM Apps 

C. The following table describes the email interfaces for the NS Network: 


NS-GW1 Two way NS-NMSG Email SMTP Bi-SC AIS email 

NS-GW4 Two way NS-EAPC Email SMTP Releasable to EAPC 

NS-GW5 One way NS-BUS Email SMTP Notification only 

NS-APP Two way ICTM Apps 

NS-PNWI - - 


15.5.4.2-p1 The ANWI Contractor’s email capability shall be configured across 

both server rooms guaranteeing that messages shall be kept in sync on the storage 

systems in both server rooms. 

15.5.4.2-p2 The ANWI Contractor shall ensure that in case of a server room 

failure the surviving server room’s email components shall continue the service 

without any data loss. 

15.5.4.2-p3 The ANWI Contractor, as part of the ANWI’s data life cycle 

management concept, shall provide an email solution that includes data backup 

strategies to safeguard the data against a catastrophic event and supports long term 

data backup and archival (ex. forensic investigation) 

15.5.4.2-p4 The ANWI Contractor’s email service shall be fully integrated into 

the ANWI backup strategy and provide a RTO of 30 minutes. 


15.5.5-p1 The ANWI Contractor shall test the email service using the following 


A. All scenarios described in Section 15.5.2-p3 of this Annex shall be 


B. Hardware Inspection – Physical inspection of the components. 

C. Capacity Tests: 

1. Individual mailbox capacities. 

2. Total service capacity. 

D. Availability Test: 

1. Demonstrate Features in support of High availability. 

2. Simulate Server room fail-over. 





3. Simulate component failure (e.g. disk, interface, controller). 

4. RTO and RPO reporting (e.g. requirements vs. test results). 

E. Performance tests (test shall be conducted over a predefined period 

notpoint in time test): 

1. Inbound message throughput. 

2. Outbound message throughput. 

F. Overall reporting using SMC service: 

1. Message details (lists/logs). 

2. Statistical usage details (totals, time based distributions, averages). 

G. IA tests shall include the following minimum set where applicable: 

1. Access Control Mechanism 

2. Detection Performance (Malware, Content Checking) 

3. Releasability Control 

4. Integrity Checking 

5. Intrusion Detection 

6. Logging 

7. Auditing 



configure and troubleshoot the following areas to support the email service: 

A. Hardware installation and configuration 

B. Hardware troubleshooting and fault finding 

C. Software installation 

D. Software troubleshooting 

E. Basic software configuration and management 

F. User account management 


Email service. 







15.6 APPENDIX 6: Unified Messaging Service Component 


15.6.1-p1 The unified messaging service shall enable convergence / cross service 

access to the various messaging service components within the UCC Service as 

described in this Appendix. 


15.6.2-p1 

The service shall cover the following interconnection scenarios: 


UM NR - NR ANWI - ANWI Internal NR 



15.6.3.1-p1 The Unified Messaging service shall be made available on: 

BUSINESS (NR). 





15.2.3.2). 

15.6.3.3 General Description 

15.6.3.3-p1 

System. 

The delivered UCC Capability shall provide a Unified Messaging 

15.6.3.3-p2 The Unified messaging system shall provide messaging features 

and service integration and translation to/from the following different types: 

A. Voice – voicemail. 

B. Video. 

C. Data – email, IM. 

D. Mobile – SMS,MMS, IM, Email. 

15.6.3.4 Functional Requirement 

15.6.3.4-p1 The Unified messaging system shall allow all authorized users to 

send, receive, retrieve or leave messages based on the table below. 

Service 

Voice 

Video Call 

Email 

ANWI Unified Messaging Services Matrix 

Message 

Text to Speech to 

Message Stored 

Message Retrieved Natively Retrievable 

Speech Text 

Natively 

Through 

Through Email As Required Required 

Voicemail Phone Device / Soft Phone Attachment Only Metadata YES 

Videomail Video Phone / VTC / Soft VTC Attachment Only Metadata YES 

Email Email Client / Web Mail Native YES N/A



ANWI Unified Messaging Services Matrix 

Service 

IM 

SMS 

MMS 

FAX 

Message 

Text to Speech to 

Message Stored 

Message Retrieved Natively Retrievable 

Speech Text 

Natively 

Through 

Through Email As Required Required 

Instant Message IM Client / Web IM Email YES N/A 

Text Message Phone Device / Soft Phone Email YES N/A 

Multimedia Message Phone Device / Soft Phone Attachment YES YES 

Document FAX Device / Printer Attachment Only Metadata N/A 

Table: 15.6ANWI Unified Messaging Service Matrix 

15.6.3.4-p2 The Unified messaging system shall provide reliable translation for 

unified messaging where no information shall be lost due to the translation. 

15.6.3.4-p3 Text-to-speech services shall be provided both for the English and 

French language. 

15.6.3.5 Performance Requirements 

15.6.3.5-p1 The Unified messaging service shall process messages in less than 

60 seconds. This is measured starting from the time the message is stored natively 

to the time UM Service processing has been completed. 





15.6.4.1-p2 




B. Individual UM capacity. 

C. Total UM capacity. 

15.6.4.1-p4 Availability Test: 





15.6.4.1-p5 Performance tests (Test shall be conducted over a predefined 

period not point in time test): 

A. Inbound messages throughput. 


A. Message details (lists/logs). 












F. Logging 

G. Auditing 



configure and troubleshoot the following areas to support the Unified Messaging 

service: 







1. User / Line management. 

G. Advanced configuration and management: 

H. HA policy and failover scripts. 


Unified Messaging service. 




15.7 APPENDIX 7: FAX Service Component 



15.7.1-p1 The ANWI Contractor shall provide FAX services (send and receive 

classified and non-classified faxes) to all users from the ANWI provided client device. 


15.7.2-p1 The ANWI FAX service shall be designed and implemented to support 

the following scenarios: 

Fax NS GW1 NSWAN - UCC integrated. 

NR GW3 external Commercial - UCC integrated, via GW2 -> GW3. 

NU GW3 external Commercial - UCC integrated. 



15.7.3.1-p1 The FAX service shall be delivered and installed on the ANWI to be 

available on the NATO SECRET, and BUSINESS (NR) [the NS shall be via the 

registry]. 


15.7.3.2-p1 The ANWI Contractor’s UCC service components shall be delivered 

and installed in the two NNHQ server rooms per the physical layout limits defined in 

the Processing Services Location (Section 15.2.3.3.1). 

15.7.3.2-p2 The ANWI Contractor shall provision the FAX service client software 

as described in Annex H. 

15.7.3.2-p3 The ANWI Contractor shall design and implement the FAX service 


A. The delivered UCC Capability shall provide a centralised Fax services 

system. 

B. The delivered Centralised Fax system shall be connected to the Public 

network. 

15.7.3.2-p4 The ANWI Contractor shall deliver the FAX service to comply with 

the following functional requirements: 

A. The delivered centralised Fax system shall allow all authorised users to 

send and receive Faxes via a specific internal email address. 

B. The delivered centralised Fax system shall be reachable from users 

external to NATO HQ via a local and/or international telephone number 

C. The delivered centralised Fax system shall allow the temporary storage of 

all incoming and outgoing faxes in electronic format for the last 30 days. 

D. The delivered centralised Fax system shall allow transferring the stored 

faxes in electronic format to a long term storage appliance and/or server. 

E. The delivered Centralised Fax system shall provide incoming document 

with a resolution of a minimum of 600x600 dpi to the users. 





15.7.3.2-p5 The ANWI Contractor’s FAX service shall be designed and 

implemented to use the following interface and protocols: 

A. The Fax service shall support the following Interfaces and protocols: 

1. FAX3-T4. 

2. FAX4-T6. 

3. FAX – T38. 

15.7.3.2-p6 Interfaces 

A. The ANWI FAX service design shall describe the following internal 

interfaces and dependencies shown through Voice services as FAX 

service is achieved through the Voice connectivity): 

Voice 

User Services 

Processing 

Storage 

Printing 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 

IM 

X X X X X X X X X X X X X X X X X 


and support the following cross Domain interfaces: 

A. The following table describes the FAX interfaces for the Public Network: 


PUB-CD3 Two way PUB-NVO NATO voice VOIP FAX 

Two way PUB-CVO Comm. voice PSTN, ISDN, VOIP FAX 

B. The following table describes the FAX interfaces for the Business 

Network: 


BUS-CD2 Two way BUS-CVO Telephony PSTN FAX 

Two way BUS-NVO Telephony VOIP FAX 

C. The following table describes the FAX interfaces for the Secret Network: 


NS-GW1 Two way NS-NSVO VoSIP FAX 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 


15.7.3.3-p1 The ANWI Contractor’s FAX service shall be fully integrated into the 

ANWI backup strategy and provide a RTO of 30 minutes. 


15.7.4-p1 The ANWI Contractor shall test the FAX service using the following 


A. All scenarios described in Section 15.7.2 of this Annex shall be included 

as test cases. 



1. Concurrent use. 






1. Demonstrate High availability. 




E. Performance tests (Test shall be conducted over a predefined period not 


1. Inbound messages throughput. 










6. Logging 

7. Auditing 


15.7.5-p1 The ANWI Contractor shall train the NNHQ-SPA staff onhow to install, 

configure and troubleshoot the following areas to support the FAX service: 






15.7.5-p2 

service. 

The ANWI Contractor shall train the NNHQ users on how to use the Fax 







15.8 APPENDIX 8: Instant Messaging/Chat Service Component 


15.8.1-p1 The ANWI IM/chat service shall provide all authorized NATO HQ users 

with the ability to find users in a central directory and create a contact list on any 

designated UCC client showing the contacts and location information, and use 

instant messages to communicate through an instant messaging client, and other 

relevant ANWI provided UCC interfaces. 


15.8.2-p1 The ANWI IM service shall be designed and implemented to support the 

following scenarios: 


IM NS - NS ANWI - ANWI NS Internal 

NSWAN GW1 NS NCIA Bi-SC AIS ANWI NS to federated or Single Domain NS 

NR - NR ANWI - ANWI NR Internal 

NRWAN GW2 NR ? NRNRWAN ANWI NR to federated or Single Domain NR 



15.8.3.1-p1 The ANWI Contractor shall deliver and install the IM/chat service on 

the NATO SECRET and BUSINESS (NR) networks. 





(Section 15.2.3.2). 

15.8.3.2-p2 The ANWI Contractor shall provision the IM/chat service client 


15.8.3.2-p3 The ANWI Contractor shall design and implement the IM/chat 

service in accordance to the following: 

A. The IM system shall allow all NATO HQ users to send, receive instant 

messages and identify user presence and location via UCC clients on the 

business network. 

B. The IM system shall be compatible with existing NATO instant messaging 

architectures on classified networks (Ref 1.1.1.8.23 and 1.1.1.8.24). 

15.8.3.2-p4 The ANWI Contractor shall deliver the IM/chat service to comply 

with the following functional requirement 

A. The following functional requirements shall be available: 

1. Integration with Desktop Office suite. 

2. Integration of presence. 

3. Person to Person Chat. 

4. Multi-User Chat.


5. Permanent Chat Rooms. 

6. Classification/ labelling on sessions & Chat rooms. 

7. Web Based Instant Messaging Client Access. 

8. Active Directory (LDAP) Integration. 

9. Enterprise Server to Server Message Relay. 

10. Integration with cross domain solution options. 

B. The IM service shall have 99.99% availability. 


15.8.3.2-p5 The ANWI Contractor’s IM/chat service shall be designed and 


A. The IM/Chat service shall support the following Interfaces and protocols: 

1. XMPP. 

2. SIP/SIMPLE. 




15.8.4.1-p1 The ANWI IM/chat service design shall describe the following 


Processing 

Storage 

Printing 

User Services 

IM X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 


and support the following Cross Domain interfaces: 

A. The following table describes the IM interfaces for the Business Network: 


BUS-CD2 Two way BUS-INT Internet Chat HTTP(S), SIP, XMPP Internet, NUWAN 

Two way BUS-NMSG NR Chat HTTP(S), SIP, XMPP NRWAN 

B. The following table describes the IM interfaces for the NS Network: 


NS-GW1 Two way NS-NMSG NS Chat HTTP(S), SIP, XMPP Bi-SC AIS Chat 


15.8.4.2-p1 The ANWI Contractor’s IM/chat service shall be fully integrated into 



15.8.5-p1 The ANWI Contractor shall test the IM/chat service using the following 


A. All scenarios described in Section 15.8.2. of this Annex shall be included 





Email 

IM 

Voice 

VTC services 

Presence 


Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC


1. Individual user contact list capacities. 








E. Performance tests (test shall be conducted over a predefined period not 


1. Inbound messages throughput. 

2. Outbound messages throughput. 










6. Logging 

7. Auditing 


15.8.6-p1 The ANWI Contractor shall train the NNHQ-SPA staff onhow to install, 

configure and troubleshoot the following areas to support the IM/chat service: 







1. User / Line chat room set up. 


Instant Messaging service, 




15.9 APPENDIX 9: Presence Service Component 



15.9.1-p1 The ANWI Presence service is a critical element of the ANWI UCC 

concept and shall provide all authorized NATO HQ users with the ability to observe 

presence information of other users and publish their presence status either manually 

or through automation of predefined stages (such as calendar based updates). 


15.9.2-p1 The ANWI presence service shall be designed and implemented to 

support the following scenarios: 


Presence NS - NS ANWI - ANWI NS Internal 

NSWAN GW1 NS NGCS NSNSWAN ANWI NS to federated or single domain NS 


NRWAN GW5 NR NGCS NRNRWAN ANWI NR to federated or single domain NR 



15.9.3.1-p1 The ANWI Contractor shall deliver and install the Presence service 

on the NATO SECRET and BUSINESS (NR) networks. 





(Section 15.2.3.2). 

15.9.3.2-p2 The ANWI Contractor shall provision the presence service client 


15.9.3.2-p3 The ANWI Contractor shall design and implement the presence 


15.9.3.2-p4 The Presence service shall provide all NATO HQ users with the 

ability to find users in a central directory and create a contact list on any designated 

UCC client showing the contacts’ presence and location information. 

15.9.3.2-p5 The ANWI Contractor shall deliver the presence service to comply 

with the following functional requirements: 

A. The Presence service shall have integration with Desktop Office suite. 

B. There shall be Presence Awareness and Location notification. 

C. There shall be integration with all UCC service components. 

D. The user shall be able to manage authorization for publishing presence 

information. 





15.9.3.2-p6 The service shall display the presence information of users, with 

status labels: 

A. Busy. 

B. Connected. 

C. Offline. 

D. Office. 

E. Home. 

F. Mobile. 

G. Editable by user. 

15.9.3.2-p7 The ANWI Contractor’s presence service shall be designed and 


The Presence service shall support the following Interfaces and protocols: 

o SIP/SIMPLE. 

o XMPP. 

o LDAP/X.500. 

o HTTP/HTTPS. 

o XML. 



15.9.4.1-p1 The ANWI presence service design shall describe the following 


Processing 

Storage 

Printing 

User Services 

Presence X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 


and support the following Cross Domain interfaces 

The following table describes the Presence interfaces for the Business 

Network 


BUS-CD2 Two way BUS-INT Internet Presence HTTP(S), SIP, XMPP Internet, NUWAN 

 

Two way BUS-NMSG NR Presence HTTP(S), SIP, XMPP NRWAN 

Email 

The following table describes the Presence interfaces for the NS Network: 


NS-GW1 Two way NS-NMSG NS Presence HTTP(S), SIP, XMPP Bi-SC AIS Presence 


15.9.4.2-p1 The ANWI Contractor’s presence service shall be fully integrated 

into the ANWI backup strategy and provide a RTO of 30 minutes. 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 






15.9.5-p1 The ANWI Contractor shall test the presence service using the following 


15.9.5-p2 All scenarios described in Section 15.9.2 of this Annex shall be included 


15.9.5-p3 


15.9.5-p4 Capacity Tests: 

A. Individual user contact list capacities. 

B. Total service capacity. 

15.9.5-p5 Availability Test: 





15.9.5-p6 Performance tests (test shall be conducted over a predefined period not 


A. Status change responsiveness. 

15.9.5-p7 Overall reporting using SMC service: 

A. Presence details (lists/logs). 


15.9.5-p8 IA tests shall include the following minimum set where applicable: 






F. Logging 

G. Auditing 



configure and troubleshoot the following areas to support the presence service: 

A. Software installation. 

B. Software troubleshooting. 

C. Basic configuration and management: 

1. User management. 


Presence service. 




15.10 APPENDIX 10: UCC Directory Service Component 



15.10.1-p1 The ANWI UCC Directory service shall provide the central directory 

repository function for all relevant UCC services. 


15.10.2-p1 The ANWI directory service shall be designed and implemented to 

support the following scenarios: 

User 

Services From 

1/2 

way 

GW To 

Provid 

er 

External 

service 

Remarks 

UCC 

Directo 

ry NR - NR ANWI - UCC Directory to support ANWI NR 

NRWA 

N 

NR 

GW 

2 NR ? 

GW 

3 

NATO NR 

mail 

Directory Exchange between ANWI NR and NATO 

Federated NR 

PUBLI 

C ANWI - Directory Exchange between ANWI NR and ANWI PUBLIC 

NS - NS ANWI - UCC Directory to support ANWI NS 

NSWA GW 

Directory Exchange between ANWI NS and NATO 

N 1 NS NCIA Bi-SC AIS Federated NS 

NUWA GW PUBLI 

Directory Exchange between ANWI PUBLIC and NATO 

N 3 C NCIA Bi-SC AIS Federated NU 

PUBLI 

C - 

PUBLI 

C ANWI UCC Directory to support ANWI PUBLIC 


15.10.3.1 Domains 

15.10.3.1-p1 The ANWI Contractor shall deliver and install the Directory service 

on all 4 domains: NATO SECRET, EAPC SECRET, BUSINESS (NR) and PUBLIC. 





(Section 15.2.3.2). 

15.10.3.2-p2 The ANWI Contractor shall design and implement the directory service 


A. Directory services shall be available on all security domains and shall 

provide a central repository which can be used by all UCC services. 

B. Directory services shall integrate to and/or be compatible with the existing 

Microsoft Windows Active Directory services which will be used in the 

NNHQ. 

15.10.3.2-p3 The ANWI Contractor shall deliver the directory service to comply with 

the following functional requirement 

A. The Directory service shall interface to all UCC services. 

B. The Directory service shall be integrated with Active Directory. 





C. The Directory service shall have NATO Enterprise Directory Service 

(NEDS) compatibility. 

D. The Directory service shall have the capability to find users and their 

accessible services from the directory. 

15.10.3.2-p4 The ANWI Contractor’s email service shall be designed and 


A. The Directory service shall support the following Interfaces and protocols: 

1. LDAP/X.500. 


3. XML. 


15.10.4-p1 The ANWI Directory service design shall describe the following 


Us 

er 

Se 

rvi 

ces 

Di 

rec 

tor 

y 

Processing 

Storage 

Printing 

Directory 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Email 

X X X 1. X X X X X X X X 

IM 

X 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 



File services 

Remote users 

Browsing 

ESS 

BMS 



X X X X X X X X X X X X X 

15.10.4-p2 The ANWI Contractor’s design and implementation shall document 


A. The following table describes the UCC Directory interfaces for the 

Business Network: 


BUS-CD2 Two way BUS-INT Internet DirExc HTTP(S), LDAP Internet, NUWAN 

Two way BUS-NMSG NR DirExc HTTP(S), LDAP NRWAN 

B. The following table describes the UCC Directory interfaces for the NS 

Network: 


NS-GW1 Two way NS-NMSG NS DirExc HTTP(S), LDAP Bi-SC AIS Directory 

NS-GW1 Two way NS-NEDS NEDS LDAP Interface to NEDS 


15.10.4.1-p1 The ANWI Contractor’s directory service shall be fully integrated 



15.10.5-p1 The ANWI Contractor shall test the directory service using the 


15.10.5-p2 All scenarios described in Section 15.10.2 of this Annex shall be 


15.10.5-p3 


SMC

15.10.5-p4 Capacity Tests: 

A. Total service capacity. 


15.10.5-p5 Availability Test: 






15.10.5-p6 Performance tests (test shall be conducted over a predefined period 


A. Concurrent user / service load test. 

15.10.5-p7 Overall reporting using SMC service: 

A. Directory request details (lists/logs). 

B. Directory modification details (lists/logs). 

C. Statistical usage details (totals, time based distributions, averages). 

15.10.5-p8 IA tests shall include the following minimum set where applicable: 






F. Logging 

G. Auditing 


15.10.6-p1 The ANWI Contractor shall train the NNHQ-SPA staff on how to 

install, configure and troubleshoot the following areas to support the directory 

service: 







1. AD management. 

2. Interface connections between ANWI and NEDS. 


UCC Directory service. 




15.11 APPENDIX 11: Collaboration Service Component 



15.11.1-p1 The ANWI Collaboration service shall provide all authorized NATO 

HQ users with the ability to share (based on the shared user’s specific approval) a 

computing device’s screen or a subset such as an application window (whiteboard), 

with other users, for read only, remote access or co-editing scenarios. 


15.11.2-p1 The ANWI collaboration service shall be designed and implemented 

to support the following scenarios: 


Collaboration NS - NS ANWI - ANWI NS Internal 

NSWAN GW1 NS NGCS NSNSWAN ANWI NS to federated or single domain NS 


NRWAN GW2 NR NGCS NRNRWAN ANWI NR to federated or single NR 

NU - NU ANWI - NU extranet portal-based coll. (EIM/ERP) 


15.11.3.1 Domains 

15.11.3.1-p1 The ANWI Contractor shall deliver and install the Collaboration 

service on the NATO SECRET and BUSINESS (NR) networks. 





(Section 15.2.3.2). 

15.11.3.2-p2 The ANWI Contractor shall provision the collaboration client 


15.11.3.2-p3 The ANWI Contractor shall design and implement the collaboration 


A. Collaboration shall consist of: 

1. Shared workspace. 

2. Application and Document sharing. 

3. Calendar sharing. 

4. Whiteboard sharing. 

B. NATO HQ users shall have the ability to collaborate from the desktop 

client with multiple participants in real-time on the Business network. 

C. NATO HQ users shall have the ability to collaborate with multiple 

participants on remote NATO locations across different domain networks. 







15.11.3.2-p4 The ANWI Contractor shall deliver the collaboration service to 

comply with the following functional requirements: 

A. NATO HQ users shall have the ability to store, share, present and edit 

documents integrated through EIM portals 

B. There shall be integration with existing NATO Bi-SC AIS shared 

workspace users. 

C. There shall be integration with Desktop Office suite. 

D. There shall be integration Presence. 

E. There shall be integration with Active Directory (LDAP). 

F. The service shall provide public and corporate portals/storage. 

G. The service shall conform to NATO IKM/EIM portal standards. 

H. The Collaboration Service Component shall be capable to share, edit and 

update files and share desktop/application GUI in real-time with multiple 

users. 

i. Users shall have the ability to share and delegate calendar read/write 

access to multiple users. 

J. Users shall have the ability to share and edit graphics and freeform text 

online in real-time between multiple users/clients. 

K. Users shall have the ability to upload documents or graphical files and to 

edit or highlight the document in freeform. 

L. There shall be Web Client integration. 

15.11.3.2-p5 The ANWI Contractor’s collaboration service shall be designed and 


A. The Collaboration service shall support the following Interfaces and 

protocols: 

1. SIP. 

2. LDAP/X.500. 

3. RDP. 


5. XML. 



15.11.4.1-p1 The ANWI collaboration service design shall describe the following 


Processing 

Storage 

Printing 

User Services 

Collaboration X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 


and support the following cross Domain interfaces: 

A. The following table describes the Collaboration interfaces for the Business 

Network: 


Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC




BUS-CD2 Two way BUS-INT Internet Chat HTTP(S), SIP, XMPP, RDP Internet, NUWAN 

Two way BUS-NMSG NR Collaboration HTTP(S), SIP, XMPP, RDP NRWAN 

B. The following table describes the Collaboration interfaces for the NS 

Network: 


NS-GW1 Two way NS-NMSG NS Collaboration HTTP(S), SIP, XMPP, RDP Bi-SC AIS Collaboration 


15.11.4.2-p1 The ANWI Contractor’s collaboration service shall be fully integrated 



15.11.5-p1 The ANWI Contractor shall test the collaboration service using the 


A. All scenarios described in Section 15.11.2 of this Annex shall be included 










E. Performance tests (test shall be conducted over a predefined period not 


1. Responsiveness of shared screen / application. 


1. Session details (lists/logs). 

2. Directory modification details (lists/logs). 








6. Logging 

7. Auditing 



install, configure and troubleshoot the following areas to collaboration the storage 

service: 

A. Software installation. 

B. Software troubleshooting. 




C. Basic configuration and management: 

1. User / application management. 



Collaboration service. 




15.12 APPENDIX 12: Mobility Service Component 



15.12.1-p1 The ANWI Mobility service shall provide authorized NATO HQ users 

with the ability to use a variety of ANWI provided end user devices to seamlessly 

access the UCC services. 


15.12.2-p1 The service shall cover the following scenarios: 

A. ANWI users shall be able to initiate and receive voice calls from any voice 

capable UCC device that they are logged on to. 

B. ANWI users shall be able to initiate and receive video calls from any voice 


C. ANWI users shall be able to initiate /join chat sessions from any IM 


D. ANWI users shall be able to switch between logged on devices to continue 

active communication sessions (such as continuing a chat session started 

using a smartphone, and switching to a laptop if extensive typing is 

needed). 

E. For calls / messages received while offline, (and if configuration is set for 

it), messages shall be stored until the user logs on from a capable device 

and receives the messages left (see Unified Messaging Service) 


15.12.3.1 Domains 

15.12.3.1-p1 The ANWI Contractor shall deliver and install the mobility service on 

the BUSINESS (NR). 





(Section 15.2.3.3.1). 

15.12.3.2-p2 The ANWI Contractor shall provision the mobility service client 

software on Business mobile clients as described in Annex H. 

15.12.3.2-p3 The ANWI Contractor shall design and implement the mobility 


A. User experience shall be consistent between device types and only limited 

by the device technical limitations. 

B. The ANWI Contractor shall deliver the mobility service to comply with the 

following functional requirement 

C. The UCC capability shall provide a follow-me unique id. 

D. The UCC capability shall provide roaming and device mobility. 

E. Users shall be able to change the connection point of their devices to the 

network and have access to their services automatically. 

F. Incoming sessions shall be directed to the user preferred device. 







G. The network administrator/user shall be able to define the order of 

preference of access methods in the case of devices with multiple access 

technology capabilities. 

H. Users shall be able to leave and re-join the session from a different client. 

i. The Mobility service shall be designed and implemented to support the 

following Interfaces and protocols: 

1, SIP. 



15.12.4.1-p1 The ANWI Contractor’s mobility service shall be fully integrated into 




A. The mobility service does not provide additional user interfaces but 

enables use of multiple end devices or interfaces to access information 

made available by other UCC services such as voice. Thus, no additional 

specific interface definitions are provided in this section. 

B. The Contractor shall perform the required analysis based on the proposed 

mobility solution to enhance identify, propose and implement any 

necessary additional cross domain information exchange. 


15.12.5-p1 All scenarios described in Section 15.12.2 of this Annex shall be 


15.12.5-p2 The ANWI Contractor shall test the mobility service using the 


A. Hardware Inspection – Physical inspection of the components. 

B. Capacity Tests: 

o Total service capacity. 

C. Availability Test: 

o Demonstrate High availability. 

o Simulate Server room fail-over. 

o Simulate component failure (e.g. disk, interface, controller). 

o RTO and RPO reporting (requirements vs. test results). 

D. Performance tests (test shall be conducted over a predefined period not 


o Performance tests for functions across multiple end point devices. 

o Responsiveness of switching to the configured device to takeover functions. 

E. Overall reporting using SMC service: 

o Session details (lists/logs). 

o Directory modification details (lists/logs). 

o Statistical usage details (totals, time based distributions, averages). 

F. IA tests shall include the following minimum set where applicable:


o 1. Access Control Mechanism 

o 2. Detection Performance (Malware, Content Checking) 

o 3. Releasability Control 

o 4. Integrity Checking 

o Intrusion Detection 

o Logging 

o Auditing 




install, configure and troubleshoot the following areas to support the mobility service: 







1. User / application management. 


Mobility service. 





SECTION 16. ANNEX H: CLIENT-PROVISIONING SERVICE 

16.1 APPENDIX 1: Introduction to Client Provisioning Services 


16.1.1-p1 Client provisioning is the process of providing users with access to data 

and technology resources. Provisioning can be thought of as a combination of the 

duties of a service provider, where users are given access to data repositories or 

granted authorization to systems, applications and databases based on a unique 

user identity, and supplying users with the appropriate fit-for-purpose client form 

factor hardware resources, such as desktops, laptops or phones. User rights and 

privileges shall be monitored and tracked to ensure the security of the enterprise 

resources. 


16.1.2-p1 The client provisioning service has two (2) distinct parts: 

A. Software provisioning service: this is the back-end capability that provides 

the Operating systems and applications to the users. There are several 

different ways to provide software provisioning capability; these are 

described in Appendix 2 of this Annex. 

B. Client Devices: this encompasses the provision of a physical and/or virtual 

device to the end-users with which they receive access to the software 

provisioning service. These devices include: 

1. Office Desktop PC, standard desktop for normal office workers. 

2. High Performance workstations used for applications that are processor 

intensive, e.g. CIS management workstations and INFOSEC 

management workstations. 

3. Thin client for Virtual desktop provisioning. 

3. Laptops / Tablets for mobile users. 

4. Feature rich Unified Communication and Collaboration (UCC) User 

access device. 

5. PDA or portable communicator device for mobile users (using NR 

approved security settings). 

6. Print and scan devices. 

16.1.3 Scope 

16.1.3-p1 The client provisioning service shall be provided through the following 

sub-services: 

A. Software provisioning. 

B. Client Devices. 

16.1.3-p2 Figure 16.1 illustrates the mapping of the client provisioning services to 

the services taxonomy as introduced in Annex C. 





16.1.3-p3 The services which are further specified in this annex mapped to the 

appendices are as follows: 

A. Appendix 2, Software Provisioning, will specify the provisioning of 

common, specific application and operating system software provisioning 

service. 

B. Appendix 3, Client Devices, will specify the various client devices and 

common CoI user applications and operating system services baseline (in 

short: NATO desktop baseline). 

Figure 16.1: Client provisioning services mapping to services taxonomy 


16.1.4-p1 Infrastructure shall be available on all 4 networks – NATO SECRET, 

EAPC SECRET, BUSINESS (NR) and PUBLIC with the following possibilities for 

client and software provisioning: 

Network (Qty) Client Processing Storage Technology 

NS (1306) Desktop Local Central Streaming 





Network (Qty) Client Processing Storage Technology 

Central Central SBC/VDI 

Thin Client Central Central SBC/VDI 

EAPC (150) Desktop Local Central Streaming 



Business (1600) Laptop / Tablet Local Local NRoI/local applications 

Local Central Application streaming 

Central Central SBC/VDI for applications 

Business (633) Desktop Local Central Streaming 



Public (34) Desktop Local Central Streaming 



Guest (n.a.) BYOD Local Local Only Wireless limited Access 

Table 16.1a: Client and software provisioning possibilities 

16.1.4-p2 In order to provide a comprehensive and flexible solution for ANWI the 

contractor shall provide a similar solution for the NATO Secret, EAPC and public 

network as well as the “desktop“ clients on the Business network. For the mobile 

Business users a solution based on mobile clients (laptops/tablets) shall be used. 

16.1.4-p3 The ANWI Contractor shall provide flexible client provisioning solutions 

for four (4) networks: 

A. For the Business network the preferred client shall be mobile clients 

(laptops/tablets), however some desktops will also be required for specific 

functions. The mobile clients shall use a NATO approved secure VPN 

capability that will allow them to connect to the Business network from any 

public network through a secure VPN/NPKI solution.. For accessing the 

business network inside the HQ the business user will connect to the 

ANWI public Wireless network and establish a VPN connection to the 

Business network. The VPN connection shall utilise the VPN service that 

can be accessed via Cross Domain Gateway 2. 

B. The NATO secret and EAPC networks require mostly desktop clients. 

These shall be deployed without local storage capability for the standard 

desktops. Specific exceptions can get a high performance workstation that 

has local storage capabilities. 

C. The public network clients shall consist of a number of “kiosk” machines 

that can be used by multiple users. No specific applications beyond the 

standard desktop are required. The main function of these clients will be to 

provide internet access to HQ visitors. The public clients shall use the 

same provisioning technology and clients as the NATO Secret and EAPC 

solution. 





D. Clients shall comply with the MHWPS (ref 1.1.1.5.1). The current version 

of the MHWPS does not contain minimum specifications for a Thin Client 

or a Tablet. Therefore, Table 16.1b below provides the minimum 

specifications for a Thin Client, and Table 16.1c for a Tablet. 

Item 

Client capabilities 

Display 

Security 

NIC 

Sound 

Keyboard 

Mouse 

Noise emission 

Power supply and 

cords 

Ports 

Case 

Power consumption 

Manageability 

Minimum Requirements 

Fully supporting operations using: 

Microsoft RDP/RemoteFX 

Citrix ICA/HDX 

VMware VDI/View 

Two outputs, supporting a minimum resolution of 

1920x1200@60Hz in single display and of 1024x768 in dual 

display, 16-bit colour 

SSL 3.0/TLS 1.0 or higher, Setup/boot password/system 

configuration protection & cabinet lock 

100Base-T RJ-45 or 100Base-FX LC/SC 

Audio input and output using 3.5mm jack 

US QWERTY keyboard 

Optical/laser scroll mouse 

Silent (fan-less) 

According to local requirements (CEE 7/7 power plugs) 

minimum 1 USB 2.0 or higher and 1 USB 3.0 port available, 

excluding Keyboard and Mouse connection 

Small Form Factor 

Average below 10W 

Supported remote wake-on-LAN, monitoring, control and 

patching 

All identified components installed/integrated into the 

system 

Overall hardware configuration must be robust in order to 

support business type operations 

Table 16.1b: Thin Client Minimum Hardware requirements 

Item 

Minimum Requirements Optimal Requirements (highperformance 

(basic – on Atom Z2460) 

– on i5-3470T) 

Compatibility Windows 7 and 8 compatible 

Processor Dual thread or more Dual core or more 

Maximum/turbo frequency: 1.6 Maximum/turbo frequency: 3.0 GHz 

GHz or faster 

or faster 

Support for EIST, Execute Support for EIST, Execute Disable 

Disable Bit 

Bit, 64bit instruction set, AES-NI, 

(Optional: support for 64bit VT-x, VT-d 

instruction set) 

Memory 2GB dual channel LPDDR2- 4GB dual channel DDR3-1333 or 







Item 



Optimal Requirements (highperformance 

– on i5-3470T) 

800 or faster faster 

Storage 60GB of flash storage 120GB of flash storage 

Screen Min. 9-10” IPS or AM-OLED Min. 9-10” IPS 1920x1080 or higher 

1280x800 or higher resolution resolution 

Anti-glare coating, contrast 

500:1, brightness 350 nits 

(cd/m 2 ) 

Anti-glare coating, contrast 500:1, 

brightness 300 nits (cd/m 2 ) 

Horizontal and vertical viewing angle 

Horizontal and vertical viewing at least 160º 

angle at least 160º 

Four-points or more multitouch 

Four-points or more multi-touch 

support 

support 

GPU 

Keyboard 

Battery 

Wi-Fi 

Bluetooth 

USB 

Modem 

Case 

Drivers 

Power 

supply 

Weight 

Support for: 

- DirectX 9.L, OpenGL ES2.0 or 

higher 

- H.264 MPEG4/2, VC1, WMV9 

hardware decoding 

- Support for 1280x1024 or 

higher resolutions 

- HDMI (mini/micro/normal) 1.3 

or MHL or DisplayPort 1.1 

connectivity for external 

display supporting a minimum 

of 1920x1080p resolution 

Attachable US QWERTY keyboard 

min. 8 hours running time 

battery 

max. 4 hours loading time to 

80% 

Wireless LAN 802.11 b/g/n 

2.4GHz 

(Optional: 2.4GHz and 5GHz 

dual-band) 

Bluetooth 3.0 or higher 

1x free USB 2.0 port 

(excluding Smart Card Reader 

port if used via USB) 

Support for: 

- QuickSync Video enc/dec 

- DirectX 11, OpenGL 3.1 or higher 

- H.264 MPEG4/2, VC1, WMV9 

hardware decoding 

- Support for 1920x1080 or higher 

resolutions 

- HDMI (mini/micro/normal) 1.3 or MHL 

or DisplayPort 1.1 connectivity for 

external display supporting a minimum 

of 1920x1080p resolution 

min. 6 hours running time battery 

max. 2 hours loading time to 80% 

Wireless LAN 802.11 b/g/n 2.4GHz 

2x2 MIMO 

(Optional: 2.4GHz and 5GHz dualband) 

1x free USB 3.0 port (excluding 

Smart Card Reader port if used via 

USB) 

Optional: 

Integrated HSPA (800/850/900/1900/2100MHz) of maximum 

theoretical bandwidth min.: download 14Mbps, upload 5Mbps 

A sleeve and carrying case enabling self-standing position of the 

device 

All drivers must be compatible with the hardware and software used 

Auto sensing 110/220V power with local power cord 

Less than 1.1kg with its power 

supply 

Less than 1.4kg with its power 

supply



Item 



Optimal Requirements (highperformance 

– on i5-3470T) 

Security Trusted Platform Module (TPM) 1.2 (or later) chip on the 

motherboard 

Smart Card reader (embedded or through an USB port) 

Docking A dedicated docking station or a port replicator having at least: 

- 100BaseT RJ45 interface or faster 

- a minimum of 2 x USB 2.0 and 1 x USB 3.0 ports 

- Audio input and output 

- DVI or HDMI or DisplayPort video output 

Other Integrated flash card reader (SD, µSD or newer) 

Integrated Webcam 

Integrated speaker and microphone 

3.5mm headphone and microphone jack (through a TRRS 

connector) 

Table 16.1c: Tablet Minimum Hardware requirements 

E. Where possible, a desktop Keyboard, Video and Mouse (KVM) switch 

shall be used to reduce the number of screens, monitors and mice on the 

desktop (the number of thin clients or PCs shall remain the same). 

16.1.4-p4 The ANWI Contractorshall base his estimates for sizing of the 

infrastructure capabilities on the figures provided in Appendix 3 of this Annex. 

16.1.5 Service Level Agreement / Targets. 

16.1.5-p1 The two distinct parts of the Client provisioning service have different 

service level targets: 

A. Software provisioning: this back-end capability has the entire HQ in its 

scope and it services all users. This requires a high available capability. 

The software provisioning capability requires 99.99% availability. In case 

of a catastrophic event (up to one server room failure) a maximum service 

performance impact of 25% to the required service performance is 

acceptable. 

. bEnd-user client devices have a much smaller scope, mostly on individual 

basis, therefore high availability is difficult to achieve. Client faults and 

failure are handled as incidents that shall get a specific priority. Users 

should be able to work on multiple devices (roaming) and exchanging 

devices should be supported without the need for extensive 

reconfigurations. The ANWI Contractor shall provide information on client 

MTBF figures and warranty concepts and onsite spare requirement for the 

different clients. 


16.1.6-p1 The Client provisioning service is managed through the SMC. The SMC 

shall also provide the capability to provide reports on the software provisioning 

capability and client devices. These reports shall also be required to measure the 

compliance of the system towards the SLA requirements. 






requirements of the specific sub-service. Overall end-to-end client provisioning 

integration tests shall be conducted to verify the integration of the individual 

capabilities into the client provisioning service. These integration tests shall include 

the SMC and IA capabilities and requirements. 


16.1.7-p1 The client provisioning service interfaces mainly with the ANWI 

infrastructure services and passive network infrastructure (PNWI) with respect to the 

back-end interfaces and with the actual end-users on the presentation level, as 

visualized in figure 16.1. 

16.1.7-p2 Mobile users on the business network also interface with commercial 

services when working outside the HQ (internet providers for access to the NRoI 

VPN through the PIA gateway) 




16.2 APPENDIX 2: Software Provisioning 



16.2.1-p1 The Software Provisioning service is an essential back-end service 

providing the capability to deploy Operating Systems for servers and clients, and 

make software available for user to use, on (terminal) server, desktop, laptops and 

other client devices (for information on Client devices see Appendix 3 of this Annex). 


16.2.2-p1 

service. 

The Software provisioning service is part of the Client provisioning 

16.2.2-p2 The Software Provisioning capability shall deliver Operating Systems 

and applications on all classification networks, to all involved client devices. 

16.2.2-p3 The Software Provisioning capability shall consider deployment using 

various methods to all locations involved in the NNHQ, including remote offices and 

remote (VPN) users. 

16.2.2-p4 The software provisioning capability shall be sized to meet the following 

capacity requirements. 

16.2.3 Domains 

16.2.3-p1 The Software provisioning service shall be available on all 4 networks – 

NATO SECRET, EAPC SECRET, BUSINESS (NR) and PUBLIC. 

16.2.4 Location 

16.2.4-p1 The locations of the servers for all the Software provisioning services 

are both server rooms. These basic services are expected to keep running even in 

case of a major failure, up to losing one of the server rooms. 

16.2.5 Client Platform Provisioning 

16.2.5-p1 NATO HQ users inside and outside of the building are expected to use 

a variety of client form factors including desktop computers, mobile computers, 

tablets and smartphones. To provide an effective client capability in a centrally 

managed manner, capable of providing a heterogeneous software portfolio including 

legacy applications, a combination of the following provisioning technologies shall be 

utilized: 

A. Physical Client Platform with Local Storage and Processing: This defines a 

physical device with local storage and processing capabilities. Local 

storage is essential for mobile platforms as they are expected to function 

offline or while not directly connected to the ANWI. The software platform 

on such devices will be centrally managed. Examples of such platforms 

are Traditional Desktops and Laptops, NRoI clients. 





B. Physical Client Platform with Central Storage and with Local Processing 

[OS Streaming]: This defines a “diskless client” capability, where the client 

devices are directly connected to the ANWI services, and they rely on the 

central storage infrastructure to be virtually presented as a local disk 

through the network. The disk images are managed and stored centrally, 

and when the devices are turned off, no data is stored on the client. This 

type of provisioning is also called Desktop Streaming. NCIA NS clients are 

such examples. As the processing happens at the client and the OS is 

running directly on the local hardware, not a server (compared to VDI 

below), this option has a much wider flexibility in terms of accessing 

legacy or state of the art peripherals, the multimedia capabilities are only 

limited to the ability of the client, and device drivers are running on the 

native hardware as they are majorly tuned to do, but not on a virtual 

platform. 

Note that although this is mainly considered to be a physical platform, such provisioning can also be 

provided to a virtual machine. This enables the virtual platform to be stateless (storing no local data) 

thus limits the access to the environment to online use within NATO HQ. 

C. Physical Client Platform with Central Storage and Processing [Server 

Based Computing]: This option is where the client software runs on a 

central server infrastructure, and a client desktop is provided to the users 

through a remote desktop protocol, which provides a remote view of the 

desktop running on the central server. Note that this option relies on an 

access capability being used to reach the service provided on the server 

infrastructure. The access capability can be provided through the options 

defined in a). b). above, or through thin clients. 

D. Virtual Client Platform with Central Storage and Processing [VDI]: This 

defines a set of virtual clients running on a server platform, using the 

central storage. The OS on these clients can be local (to the VM, not the 

endpoint) or streamed through the same mechanism for the Diskless 

clients. This method has a few specific features, which are potentially an 

advantage for implementations where the hardware and multimedia 

requirements are significantly homogeneous and well defined, and where 

a variety of client software configurations need to be frequently redeployed 

(such as training and test facilities). 

Note that this option relies on an access capability being used to reach the service provided on the 

server infrastructure. The access capability can be provided through the options defined in a). b). c) 

above, or through thin clients. 

16.2.5-p2 In order to provide a comprehensive and flexible solution for ANWI the 

contractor shall provide a similar solution for the NATO Secret, EAPC and public 

network as well as the “desktop”clients on the Business network. For the mobile 

Business users a solution in line with option a. shall be used. 

16.2.5-p3 The ANWI contractor shall support specific COI’s (ex. Graphic 

designers) with an adequate Client provisioning solution. Due to the nature of the 

activities performed by these COI’s a deviation from the standard client provisioning 

method shall be required (ex. Graphic intensive workloads, Video editing and 

CAD/CAM activities) 







16.2.5-p4 Whether using only one of the above solutions, or any combination of 

these options, on all four possible security networks, all HQ users should have a 

consistent experience when using the NNHQ ICT environment. 

A. The User experience for accessing resources on the NNHQ environment 

shall be the same, whichever provisioning combination is used. 

B. The operating system shall use the NATO desktop baseline. 

16.2.5-p5 NATO currently has an Enterprise Agreement with Microsoft, and all 

current client computers are Microsoft Operating System and Office Suite based.The 

contractor shall deliver every client with an OEM Windows professional version. The 

purchaser will provide the Microsoft enterprise desktop as PFE. Included in the MS 

enterprise desktop package is: 

A. Office Professional Plus. 

B. Enterprise Client Access Licenses (e-CAL) for Windows Server, Exchange 

Server, SharePoint Server, Lync Server, System Center, Forefront and 

SQL Server. 

16.2.6 Application Provisioning 

16.2.6-p1 With any of the possible client platform provisioning solutions 

mentioned in the previous paragraph, applications need to be deployed to have users 

be able to do their work. All applications shall be manageable centrally, deployed 

from central depositories. To provide an effective client capability in a centrally 

managed manner, capable of providing a heterogeneous software portfolio including 

legacy applications, a combination of the following application provisioning 

technologies shall be utilized: 

A. Through a central software deployment solution, like SCCM, software is 

deployed to a workstation and installed locally. Through the central 

management console, the software can be kept up to date, with patches 

and new releases. 

B. In addition to installing software locally, it is also possible to use 

applications without leaving a “footprint” on the local Operating System. 

Application streaming provides a method of delivering applications to the 

Client Platform, without the need for a local installation. Application 

Streaming retains centralised application management, whilst using local 

processing power to run the applications. A package is prepared on a 

central server and is then streamed to clients the first time the application 

is run, after which the application runs locally until a new configuration is 

deployed centrally. 

C. The client software runs on a central server infrastructure, and the 

application is published to the users through a remote desktop protocol, 

which provides a remote screen view of an application running on the 

central server. 

16.2.6-p2 The ANWI contractor shall also support HQ Support Staff during the 

migration of the business applications. The ANWI client provisioning solution shall be 

able to support the different ICTM Business applications. 

16.2.6-p3 As with the client-provisioning, whatever combination is used, the user 

experience should be the same for all users. Central management shall also include



methods of restricting software usage, and shall have clear reporting on which 

software is in use, based on the number of concurrent and licensed users. 

A. Licensing: All software in use shall be licensed. 

B. Monitoring: All software usage shall be centrally monitored. 

C. Software use: Software use can be centrally restricted. 

D. Reporting: (Concurrent) Use of software can be reported on. 

16.2.7 Client provisioning infrastructure 

16.2.7-p1 The ANWI Contractor shall design the client provisioning infrastructure 

to support all the required client in a high available setup. In case of catastrophic 

event (Server room failure) the client provisioning solution shall still be able to 

available to all users with a maximum performance degradation of 25% to the 

required service performance. 

16.2.7-p2 The ANWI Contractor shall design a scalable and flexible solution that 

includes a 25% spare capacity and allows for easy capacity expansion beyond the 

25%. The table below provides the required initial capacity numbers: 

Client provisioning Capacity 

NATO Secret 2,000 

EAPC 200 

Business 2,500 

Public 50 

Table 16.1d Client Provisioning per Domain 

16.2.7-p3 The client provisioning usage shall not cause any degradation to the 

other infrastructure services like storage or network performance due to specific 

events (ex. Logon Storm). Sufficient infrastructure resources for processing, storage 

and networking shall be provisioned in the infrastructure services or dedicated in the 

client provisioning service. (ex. SAN). 

16.2.8 Service Level Agreement/Target 


Capacity SLTs 










Continuous 

Daily/Weekly








Time to deploy a standard non-mobile client. 

Max 30 minutes 

Time to deploy a mobile client 

Max 2 hours 

Time to deploy a baseline Image 

Next business day 

Time to provision anew application (high priority) 

Next business day 



16.2.9.1-p1 The following internal interfaces and dependencies shall be 

described for the Software provisioning capability. 

Processing 

Storage 

Printing 

User Services 

Client Provisioning X X X X X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 


NAC 


LAN 

16.2.9.2-p1 All Software Provisioning Servers and underlying data and 

databases shall be backed up online and offline. 

Cross Domain 

16.2.9.2-p2 In case of failures the capability availability is set in the service level 

target. The recovery target for restoring the failed service components is: 

16.2.9.2-p3 


RTO: 4 hours 

16.2.10-p1 End-to-End Test Scenario 

A. Deployment of Operating systems to all devices on all networks. 

B. Deployment of Applications to all devices, on all networks. 

C. Deployment of patches updates and upgrades, on all device, on all 

networks. 

D. Stress test: Deployment of multiple devices (20) at the same time. 

E. Deployment to remote offices and remote users. 

F. Monitoring of license use for deployed applications. 

G. Limiting the use of software for deployed applications. 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 






16.2.11-p1 ICTM staff shall need to know how to install, configure and 

troubleshoot the following areas to support the Software Provisioning service: 

A. Server/Service installation and configuration. 

B. Server/Service troubleshooting and fault finding. 

C. Configuration and installation of updates for applications/OS. 



16.3 APPENDIX 3: Client Devices 




16.3.1-p1 This appendix specifies the client device form factors and client device 

requirements that will enable the various user types to get access to the required 

information and UCC services. 

16.3.1-p2 The client devices are part of a holistic concept, as explained in the 

UCC concept that will allow users to access the NNHQ ICT services or a subset of 

those services dependent on the type of client device and its mobility features. 

16.3.1-p3 The ANWI client devices are indicated in table 16.2. 

Type of Client Description Comment 

Fixed Desktop (Ultra) Small form factor desktop Diskless 

Fixed High Performance Desktop High Performance Workstation Form factor is fat client 

Fixed Desktop Network Agnostic (Ultra) Small form factor desktop Needed in conference areas where 

Client 

network classification will switch – no 

information should be stored or left on 

the client – diskless. 

Thin Client Thin client VDI / SBC solutions 

Mobile Client Laptop or Tablet Needs to support the NATO OS 

baseline. 

Basic Desk phone 

Normal desk phone 

Secretarial Desk phone 

Desk phone with enhancements 

PDA/Smart phone 

Small form factor device with GSM 

option 

KVM 

Needed to switch single Keyboard Not a client device 

Video Mouse to different clients 

connected to different networks 

Table 16.2: ANWI client devices identification 

16.3.2 Scope 

16.3.2-p1 Partly due to security considerations, desktops are the primary working 

environment at NATO. For HIGH security networks this will be the case for quite 

some time, as other solution will have to be accredited to be used for these 

classifications. For the other networks Laptops are already in use and smartphones 

are already used to connect to business resources. With the rapidly changing market 

for mobile devices, where all devices from smartphones to laptops will blur into a 

group best described as mobility devices, enterprise environments will also change. 

Add to that the changing OS environments, with desktop OS en smartphone OS 

blurring in functionality and it becomes clear that in the near future a smartphone can 

be “docked” and used as a desktop device. 

16.3.2-p2 For the current environment, the NS, EAPC and public networks shall 

use mostly desktop devices. The Business network shall use a combination of 

desktop devices and mobile devices. In order to limit the number of devices on the 

desk the ANWI contractor shall implement a KVM solution to connect the desktop 

keyboard, mouse, monitor and other peripherals to all possible classifications. 





16.3.2-p3 Table 16.3 summarises the user community, by user type and network 

classification 

User Type 

Quantity Comments 

Staff Member 

4.500 Including 2000 IS/IMS, 2000 National and 500 partner delegates 

Conference Visitor 1.500 

NS User 

2.700 Including 1500 National delegates 

EAPC User 600 

NU/NR User 

4.000 Including 2000 National delegates 

Public User 2.000 

Table 16.3: User community per network 

16.3.2-p4 The number of clients required to implement the client solutions 

described in this chapter are listed in Table 16.4 below. 

User / Location NS EAPC NU/NR Public Comments 

U1 - NATO HQ User 1,200 100 400 - 

U2 - NATO HQ Nation User 56 - 56 - 

U3 - NATO HQ Partner User - 50 - - 

U7 - NATO HQ Mobile User (NRoI) - - 1,600 - 

U8 - NATO HQ Remote User (RU) 40 - 60 - 

Office wings - - 63 - It is assumed that all 21 IS/IMS office wings have 3 devices 

in the 'collaboration area' 

Press Area - Library - - - 10 10 PC's in the Public area 

Visitors area - Business Centre - - - 16 

Conference Rooms 

234 The devices in the conference centre are agnostic of the 

network. 

Agora - - 4 4 4 PC's in the Public area and 4 PC's for NATO staff in the 

Agora (switchable) 

Basement 

Briefing Room 

10 The devices in the conference rooms are agnostic of the 

network. 

Senior Decision Makers Room 


network. 

Watch Room 


network. 

Multi Media - VTC Room 


network. 

Training Room - - 20 - 

Ground Floor VTC Room 


network. 

Site Security Control Room 1 - 6 - 

Alternate Site Security Control Room 1 - 6 - 

Crisis Centre Monitoring Room 6 - 6 - 

Staff Centre - - 10 4 10 PC's in the training room and 4 PC's in the Public area 

Industrial Infrastructure - - 14 - 

Guard Houses 2 - 8 - 

284 The total number of devices that are agnostic of the 

network (switchable) 

Subtotal Fixed End user devices 1,306 150 653 34 

Subtotal Mobile devices 1,600 

TOTAL 1,306 150 2,253 34 

Table 16.4: Client Numbers per Network 

16.3.2-p5 

16.5. 

The distribution of ANWI client types per network is provided in table 





desktop/laptop Nr Client Tot 

(Thin Client/ 

(diskless 

desktop) 

Hig Perf. 

Client 

Mobile 

(Laptop) 

Mobile 

(Tablet) 

Network 

Agnostic 

Desktop KVM 

NATO Secret 1306 95% 5% (283) 1266 

EAPC 150 95% 5% (283) 

Business 2253 25% 4% 53% 18% (283) 

Public 34 100% (283) 

*Softphone on mobile client devices 

Secretarial 

Phone 

Voice Nr Client Tot Basic Phone 

NATO Secret N.A. 

EAPC - - - - 

Business 1600* - - - 

Smart Phone 

PDA 

Public 1232 43% 10.5% 46.5% 

Table 16.5: Distribution of ANWI clients device types per network 

16.3.2-p6 The client devices are located in different wings per classification. NS 

and Business desktops are located in the wings for NATO personnel, EAPC devices 

are to be found in the EAPC and NATO area and Public devices are only to be found 

in the public areas. 


16.3.3-p1 The NNHQ is effectively a large glass building and cooling this building 

has its consequences. For that reason power consumption of computer devices is 

restricted. 

A. The maximum power usage per seat is 180 W, due to building airconditioning 

restrictions. 

16.3.3-p2 In accordance with design considerations mentioned in Annex A, the 

following list describes some design requirements for the desktop environment: 

A. The ANWI Contractor shall provide all client patch cables 

B. The computers and monitors shall have a low power state, such as a 

standby or sleep mode. 

C. For all workspace equipment default energy savings settings shall be set. 

D. There shall be an automated process for turning off devices. 

E. Desktop hardware shall be fit for purpose. 

F. All client devices shall support Power management policies through the 

Central SMC capability. 

G. Devices shall use SSD, or be diskless clients, to lower power 

consumption. 

H. The highest possible efficiency power supply shall be used (>90%). 

i. Standardization: A minimal numbers of different configurations shall be 

used. 

J. The network cards shall support IPv4 and IPv6. 

K. Desktop devices shall be (ultra) small form factor devices. 







16.3.3-p3 The proposed AIS desktop configuration is based on the standard 

NATO desktop core components, as described in the latest NCIA Approved Fielded 

Product List (see 1.1.1.8.4). 

A. Desktop OS with NATO approved user and security settings 

http://nww.ncirc.nato.int (on NS WAN). 

B. Core Tools Components. The actual components to be provided will 

depend on the client hardware (PC, High performance workstation, 

Laptop, PDA), and the network. The versions will be based on the latest 

approved. 

C. Software components: The latest approved version of the NATO Desktop 

will provide the essential office automation and collaboration functionality 

to the user population in support of their daily duties (see 

http://www.ia.nato.int/niapc/ (Internet – NU version) and http://nww.NCIA 

.nato.int/NCIA HQ/SystemMana/CMO (on NS WAN)). 

16.3.3-p4 HIGH security classification devices, devices on the NS and EAPC 

networks, have several different requirements, due to security reasons. The following 

is a list of requirements for these devices: 

A. Device form factor: High security classification devices may not be mobile 

deviceswith the exception of the mobile travel kit (ref. Annex M). 

B. Network: High security classification devices are connected to the network 

through fibre connections. 

C. Internal storage: A device on a high secure classification network shall not 

have an internal storage device. 

D. High security classification devices shall include a smart card reader. 

E. Computer devices shall automatically lock after not being used for 15 

minutes. 

F. Antivirus software shall be installed on all computer devices. 

G. An e-mail labelling software tool shall be installed on all client devices. 

16.3.3-p5 LOW security classification devices, NU and NR devices will be a 

combination of mobile and desktop devices. Desktop devices for those place where 

mobility is not needed or wanted and mobile devices for all other users. 

Requirements for NR desktop devices are: 

A. Network: NR classification desktop devices are connected to the network 

through fibre connections. 

16.3.3-p6 In support of mobile users the following additional features need to be 

included to support the Business network users that use the same client capability 

both on-travel as well as in-the-office: 

A. Laptop devices shall have a battery that supplies the laptop for at least 

three hours under normal load. 

B. Laptop devices shall have at least 2 USB ports (or, by 2015, similar 

industrial standard connectivity options). 

C. Laptop devices shall have an industry standard external video output 

connector. 

D. Laptop devices shall have speakers. 

E. Laptop devices shall have a microphone. 

F. Laptop devices shall have a camera. 

G. Laptop devices shall have the option to connect an external microphone.





H. Laptop devices shall have the option to connect an external headset. 

i. Docking stations for mobile devices shall also be included. 

J. Interface into the Network Access Control Services to assure compliancy 

of the returning laptop with the internal LAN security policies. 

K. Portable computing devices shall indicate discreetly to the user the highest 

classification of information that may be stored on them. 

16.3.3-p7 In order to minimize the number of devices on the desktop the 

keyboard, mouse and monitor(s) shall be shared between the different Classifications 

by usage of a KVM switch. The ANWI Contractor shall provide a common set of 

input/output devices per workspace consisting of: 

A. 20/21” TFT Monitor or larger 

B. Multimedia Keyboard 

C. Mouse 

D. Smart Card Reader 

E. Speaker/Microphone (can be integrated in the monitor) 

16.3.3-p8 Throughout the building corridors there will be phones which can be 

used for emergency calling. These phones will shall be passively directly connected 

(through copper) to the UCC IP PBX infrastructure. On the NR level Business 

Network there will be active UCC connected devices used as phones. The 

requirements for the NU and NR phones are: 

A. NU voice OR UCC devices shall communicate through VOIP. 

B. Most (see table 16.5) NU/NR voice/UCC devices shall be wired devices. 

C. There shall be some (see table 16.5) voice/UCC devices with extended 

capabilities, for connecting devices, conferencing (e.g. for secretaries). 

D. There shall be some (see table 16.5) voice/UCC devices which shall be 

wireless. 

16.3.3-p9 The following requirements for KVM switches (see 1.1.1.6.26.) are 

applicable: 

A. KVM switches shall not be used with desktop components that contain 

digital memory (e.g. programmable keyboards, and devices with smart 

card readers). 

B. The KVM switch shall only connect the desktop keyboard, monitor and 

mouse (the user level interface hardware) to one LAN at a time and will 

not allow sharing of information between the LAN environments connected 

to the switch. 

C. The KVM switch shall be an optically coupled switch. 

D. The KVM switch shall be manually operated. 

E. The KVM switch shall not contain any processors and little or no memory. 

F. When the switch is in a specific position, it shall providea visual indication 

of which LAN the user is currently operating on. 

G. The each LAN shall have differently configured end connectors to prevent 

accidental interconnection between different security domains. 

H. The network connectors shall be coloured coded and have specific 

shaped physical connectors to ensure that no accidental cross 

connections can occur. 

i. Appropriate separation between cabling of different level systems shall be 

maintained in accordance with Ref. 1.1.1.3.3.


16.3.4 ClientDevice’s Information Assurance 

16.3.4-p1 


The client computers require the following security components: 

16.3.4.1 Common Security Components: 

16.3.4.1.1 Anti-virus 

A. Every client computer shall have an antivirus product (NATO-approved 

anti-Virus solution (listed on current (at implementation time) version of 

AFPL - 1.1.1.8.4) installed and running. 

B. Antivirus software shall be kept up to date 

C. The anti-virus software shall be managed by the infrastructure anti-virus 

management server.(see 15.2.3.7-p7). 

16.3.4.1.2 System Management Agent 

A. A system management agent shall be installed on all clients. 

B. The agent shall be integrated with the ANWI SMC (Ref Annex E, Appendix 

1). 

C. The system management agent shall provide visibility of patching status 

and, application of security settings. 

16.3.4.1.3 User and computer identification and authentication 

A. Each user and computer is required to perform identification and 

authentication (I&A) before accessing the network and systems. 

B. I&A for users shall be provided as an integrated part of the client computer 

operating system. 

C. I&A for guests on the Public network shall be based on the issuance of 

temporary access credentials. 

D. Computer authentication shall be based on port security as described in 

[Ref GG].Ref GG: see 1.1.1.6.36. 

16.3.4.1.4 PKI client, token and token reader 

 

 

 

A PKI software client license, hardware token and token reader shall be 

provided on all client computers (desktop and mobile client devices)that 

require PKI services, including Business, NS and EAPC. 

Separate Tokens & Client licences shall be provided for NU/NR and NC/NS. 

Tokens for use on the Secret networks shall be approved by the national 

COMSEC Authority– PKI tokens shall be provided as PFE. 

16.3.4.1.5 Removable Storage Management System 

16.3.4.1.5-p1 Removable mass storage (RMS) is a term used to describe USB 

storage tokens, CD/DVD RW/R. 

16.3.4.1.5-p2 A mechanism to manage removable mass storage (RMS) media 

shall be implemented. 

A. Data imported via an RSM shall be checked for malicious code. 

B. Data export to an RSM shall be access controlled based on user identity. 



16.3.4.1.6 Tokens 



16.3.4.1.6-p1 The term token shall apply to a traditional ISO 7816 smart card 

or any other appropriate form factor. 

16.3.4.1.6-p2 

Clients shall support two factor authentication using NPKI. 

16.3.4.1.6-p3 Client workstations at the Secret level shall require a token in 

order to complete the logon. 

16.3.4.1.6-p4 

password. 

The presentation of a token shall be in addition to the use of a 

16.3.4.1.6-p5 The logon session and associated network access shall 

terminate immediately on token removal. 

16.3.4.1.6-p6 

identity. 

The token shall be cryptographically bound to the user’s real 

16.3.4.1.6-p7 User certificates used in this process shall be compliant with the 

NATO PKI Certificate Policy. 

16.3.4.2 Additional Countermeasures Applicable to Mobile Devices 

16.3.4.2.1 Adapted requirements for NRoI 

16.3.4.2.1-p1 When an NRoI laptop is connected to Business network, the antivirus 

software shall be managed by the anti-virus management server(ref SOW 

13.2.2). 

16.3.4.2.1-p2 For remote access from NRoI laptop to the Business network two 

factor authentication shall be used (token & password). 

16.3.4.2.1-p3 Wireless shall support authentication using the NPKI 

infrastructure. Ref 1.1.1.6.24. 

16.3.4.2.2 Wireless Network Encryption 

16.3.4.2.2-p1 The strongest available commercial Wireless network encryption 

shall be enabled for mobile systems up to NR. 

16.3.4.2.2-p2 

infrastructure. 

16.3.4.2.3 Hard disk encryption 

16.3.4.2.3-p1 

16.3.4.2.3-p2 

Restricted. 

16.3.4.2.3-p3 

16.3.4.2.4 VPN client 

16.3.4.2.4-p1 

mobile devices. 

Wireless shall support authentication using the NPKI 

Full hard disk encryption shall be installed on Mobile NR devices. 

Disk encryption shall be approved for use up to NATO 

Disk encryption for NR shall be software based. 

A NATO Approved NR VPN client shall be installed on NR 





16.3.4.2.4-p2 

Password. 

16.3.4.2.4-p3 

VPN Authentication shall combine a physical Token and a 

The Token shall support the use of NATO PKI X.509 Certificates. 

16.3.4.2.5 Host firewall 

16.3.4.2.5-p1 

computers. 

Centrally managed Local Firewall shall be activated on client 

16.3.4.2.5-p2 The Firewall shall be built in to the Operating System or a 

centrally managed desktop firewall solution (compliant with NCIRC and/or listed on 

AFPL – 1.1.1.8.4.) shall be implemented. 

16.3.4.2.5-p3 

traffic flows. 

16.3.4.2.6 Security Management 

The Firewall shall support mediation of IPv4 and IPv6 based 

16.3.4.2.6-p1 Security management performed by the CIS Management 

System will address INFOSEC and Information Assurance management tasks such 

as patching, vulnerability scanning, online computer forensics, computer operating 

system security settings and policy compliance monitoring. 

The NCIRC standard online computer forensics agent shall be installed and 

configured on the client. 

The NCIRC standard anti-virus agent shall be installed and configured on the 

client. 

The standard compliance monitoring agent shall be installed and configured 

on the client. 

16.3.4.2.7 Host-based Intrusion Detection System (HIDS) 

16.3.4.2.7-p1 HIA Host Intrusion Detection System (HIDS) shall be installed on 

mobile devices classified NR or above. 

16.3.4.2.7-p2 The solution shall be compatible with the existing NCIRC HIDS 

management systemand/or listed on AFPL – 1.1.1.8.4). 

16.3.4.2.8 Web-filter 

16.3.4.2.8-p1 

mobile devices. 

A NATO approved web filtering application shall be installed on 

16.3.4.2.8-p2 The web filtering solution shall be centrally managed by CIS 

Management System. 


16.3.4.3-p1 The software distribution and deployment server shall provide 

automated software deployment, inventory, patching, license metering, installation, 

etc. The product shall be interoperable with System Centre Configuration Manager 

(SCCM) 2007 or later. 

16.3.4.3-p2 AIS Configuration Manager shall provide the site server role. 





16.3.4.3-p3 Software update manager (such as WSUS/SCCM) shall support the 

regular software updates for the operating systems and the various core applications 

(such as IE, Office). 

16.3.4.3-p4 The AIS monitoring manager shall monitor the base operating system. 


16.3.5-p1 The client devices and their interfaces are tested as part of end-to-end 

services testing related to the other ANWI service. The client devices should be 

tested and inspected to work properly from a user handling perspective. 


16.3.6-p1 Internal interfaces are shown in table 16.7, where the ANWI Contractor 

shall describe the interfaces and dependencies. 

Processing 

Storage 

Printing 

User Services 

Client Provisioning X X X X X X X X X X X X X X X X X X X X X X 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

Table 16.7: Client to ANWI internal interfaces 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 





SECTION 17. ANNEX I: SUPPLEMENTARY SERVICES 

17.1 APPENDIX 1: Introduction to Supplementary Services 


17.1.1-p1 Supplementary services are services provided by ANWI, which don’t fall 

under any of the other categories. 


17.1.2-p1 The supplementary services are a collection of capabilities which aren’t 

directly connected to core ANWI office environment of the NNHQ, but which are 

needed as additional features for the ANWI users. Some of these services are 

provided by external (commercial) parties. 

17.1.3 Scope 

17.1.3-p1 The Supplementary services group the following capabilities: 

A. GSM service. 

B. GSM blocking service. 

C. Wireless blocking service. 

D. Secure communications (Tetra). 

E. IPTV services. 

17.1.3-p2 Figure 17.1 identifies the mapping of the supplementary services to the 

services taxonomy as introduced in Annex C 





Figure 17.1: Mapping of Supplementary services to services taxonomy. 


17.1.4-p1 The ANWI Contractorshall design the infrastructure services 

considering all the required capabilities including the high level capabilities 

requirements of service management and information management. 

17.1.4-p2 The ANWI Contractorshall clearly describe how the service and the 

individual capabilities are integrated in the service management and control (SMC) 

and Information Assurance (IA) Services in support of the overall ICT SMC and IA 

management concept as indicated in figure 17.1. 

17.1.4-p3 The ANWI Contractor shall provide information on future technologies 

and enhancement that can be in scope of the supplementary services towards 2015. 

17.1.4-p4 The specific capability requirements are provided in the respective 

appendices. 

17.1.5 Service Level Agreement / Targets 

17.1.5-p1 As the supplementary services cannot be perceived as a fully integrated 

service capability it is not possible to define a target on service level. The individual 

capabilities however shall meet the service level targets as indicated in their 

respective capability appendix. 


17.1.6-p1 The supplementary services are managed through the SMC, if 

applicable. The SMC shall also provide the capability to provide reports on the 





different supplementary sub-services. These reports shall also be required to 

measure the compliance of the system towards the SLA requirements. 


requirements of the specific sub-service. 


17.1.7-p1 There are certain dependencies of the supplementary service 

capabilities with other ANWI services, for example dependencies on the 

Infrastructure and UCC services. The detailed dependencies of the different 

capabilities are described in the respective appendices. 




17.2 APPENDIX 2: GSM Service continuity 



17.2.1-p1 The GSM service continuity capability is providing GSM coverage and 

capacity to a defined geographical area to deliver voice, messaging and data to: 2G, 

3G and 4G handsets. 


17.2.2-p1 The ANWI Contractor shall coordinate with Mobile Network Operators 

(MNOs) in Belgium and assure that NNHQ campus has 100% indoor and outdoor 

coverage and capacity to support the volume of prospective users and that all public 

services are available within the campus for all Belgium operators. It is believed that 

the building may not allow GSM signals to propagate into the complete building. The 

ANWI Contractor shall identify a solution to provide GSM coverage throughout the 

building and to act as an interface between the users’ personal GSM handset and 

his/her GSM provider without any additional roaming charges in case the personal 

GSM is using one of the Belgian GSM providers. 


17.2.3-p1 The ANWI Contractor shall provide GSM services continuity within the 

NATO HQ compound, including all buildings. 

17.2.3-p2 The ANWI Contractor shall provide GSM services continuity which shall 

allow all Mobile Telephony operators providing services in Belgium to provide the 

same level of services throughout the NATO compound. 

17.2.3-p3 The ANWI Contractor shall provide GSM services continuity within the 

NATO HQ compound at no additional cost for the users of mobile telephony services. 

17.2.3-p4 The ANWI Contractor shall provide GSM services continuity at a unique 

one off cost for NATO covering the initial investment required for implementing the 

technical solution required for the service provision. 

17.2.3-p5 The ANWI Contractor shall not charge NATO for the cost of the support 

of the technical solution required for the service provision. 

17.2.3-p6 The ANWI Contractor shall provide GSM services continuity as a 

minimum for the following standards: 

A. 2G GSM. 

B. 2.5G GPRS. 

C. 2.75G EDGE. 

D. 3G CDMA 200 1xEV and UMTS. 

E. 3.5G HSDPA and HSUPA. 

F. 3.75G HSOPA. 

G. 4G LTE and WIMAX. 

17.2.3-p7 The ANWI Contractor shall deliver required services without installing 

antennae on the roof of the NNHQ. 

17.2.3-p8 NATO will grant permanent access to the personnel which will be in 

charge of the maintenance of the technical solution required for the service provision 

extension within the NATO HQ with a maximum of 4 persons. 





















 










17.2.5.1-p1 

applicable 

Continuous 

 

 

Standard service levels provided by operators to public shall be 

17.2.5.1-p2 UCC integration for Mobility, Voice Mail, Call Forwarding and 

Unified messaging. 

GSM GSM - - Commercial Commercial Voice 

GSM GW3 Public ANWI Voice 

GSM GW3 Public ANWI Data (IP) Can be tested with Browsing / Email 

GSM GW3 Public ANWI SMS Can be tested in conjunction with UCC unified messaging 

17.3 APPENDIX 3: GSM Blocking 


17.3.1-p1 Commercial GSM coverage will be available all over the NNHQ and 

surrounding buildings. Some areas will have the possibility to be blacked out, when 

needed, for example when a classified meeting takes place. 


17.3.2-p1 The ANWI Contractor shall provide complete solutions for jamming in 

physically secure environments while blocking the publicly available network. The 

solution shall ensure zero cell phone activity within its coverage area. The solution 

provided shall also be remote controlled.



17.3.2-p2 The blocking capability shall provide fixed devices in the NAC and the 

EAPC conference room. Mobile device to be used anywhere on the NNHQ campus, 

where and when needed. 

17.3.2-p3 The GSM and Wireless (Appendix 3) blocking may be done with the 

same device. 


17.3.3-p1 The ANWI Contractor shall implement a GSM Blocking capability in the 

new NATO HQ. 

17.3.3-p2 The GSM Blocking capability shall allow the NATO HQ designated 

personnel to bar access to any GSM service provision network within the conference 

areas. 

17.3.3-p3 The GSM Blocking capability shall be compliant with the Health and 

Safety laws, rules and regulations applicable in Belgium. 

17.3.3-p4 The GSM Blocking capability shall as a minimum deny services of the 

following mobile telephony standards: 

A. 2G GSM. 

B. 2.5G GPRS. 

C. 2.75G EDGE. 

D. 3G CDMA 200 1xEV and UMTS. 

E. 3.5G HSDPA and HSUPA. 

F. 3.75G HSOPA. 

G. 4G LTE and WIMAX. 















 








Continuous 

 

 







17.3.5.1-p1 The service does not interact with any other service, except to 

disrupt GSM communication. 


17.3.5.2-p1 

needed. 


17.3.6-p1 

Configuration files shall be available offline, to be restored if 

End-to-End Test Scenario 

17.3.6-p2 User testing shall be conducted if the entire HQ has GSM coverage. 

When the Blocking devices are turned on, users should not be able to use GSM 

anywhere in the rooms where the Blocking is turned on, but they should have GSM 

coverage outside of these areas. 


17.3.7-p1 ICTM staff shall need to know how to install, configure, operate and 

troubleshoot the following areas to support the GSM Blocking capability: 

A. Installation and configuration. 

B. Troubleshooting and fault finding. 





17.4 APPENDIX 4: Wireless Blocking 





17.4.1-p1 Wireless network coverage will be available all over the NNHQ and 

surrounding buildings. Some areas will have the possibility to be blacked out, when 

needed, for example when a classified meeting takes place. 


17.4.2-p1 The capability shall provide fixed devices in the NAC and the EAPC 

conference room. Mobile device to be used anywhere on the NNHQ campus, where 

and when needed. 

17.4.2-p2 The GSM (Appendix 2) and Wireless Blocking may be done with the 

same device. 


17.4.3-p1 The ANWI Contractor shall implement a Wireless Blocking capability in 

the new NATO HQ. 

17.4.3-p2 The Wireless Blocking capability shall allow the NATO HQ designated 

personnel to bar access to any Wireless network within the conference areas and 

elsewhere on the NNHQ campus, with the mobile jammers. 

17.4.3-p3 The Wireless Blocking capability shall be compliant with the Health and 

Safety laws, rules and regulations applicable in Belgium. 

17.4.3-p4 The Wireless Blocking capability shall as a minimum deny services on 

the following Wireless standards and frequencies: 

A. 802.11 legacy 2,4GHz. 

B. 802.11b 2,4GHz. 

C. 802.11a 2,4GHz/5GHz. 

D. 802.11g 2,4GHz. 

E. 802.11n 2,4GHz/5GHz. 

F. WiGig * . 2,4GHz/5GHz/60GHz. 

17.4.3-p5 WiGig is not yet a standard, but will possibly be the next standard for 

Wireless. The newest technology standard for Wireless shall be considered when 

considering Wireless blocking. 

A. Bluetooth is often included in Blocking devices. Bluetooth Blocking shall 

also be considered when considering the solution for Wireless Blocking. 









Service Availability (%) 99.99









 










Continuous 

 

 

17.4.5.1-p1 The service does not interact with any other service, except to 

disrupt Wireless communication. 


17.4.6-p1 

End-to-End Test Scenario 

17.4.6-p2 User testing shall be conducted if the entire HQ has Wireless coverage. 

When the Blocking devices are turned on, users should not be able to use Wireless 

anywhere in the rooms where the Blocking is turned on, on any frequency (on 

network Legacy, A, B, G, N, WiGig) but they should have Wireless coverage outside 

of these areas. 


17.4.7-p1 ICTM staff shall need to know how to install, configure, operate and 

troubleshoot the following areas to support the Wireless Blocking capability: 

A. Installation and configuration. 

B. Troubleshooting and fault finding. 





17.5 APPENDIX 5: Site Security Comms (TETRA) 





17.5.1-p1 Terrestrial Trunked Radio (TETRA) is a professional mobile radio and 

two-way transceiver specification. 


17.5.2-p1 The TETRA service shall start with a site survey of the NNHQ to assess 

the TETRA’s signal penetration throughout the building. 

17.5.2-p2 If the signal propagates sufficiently to cover the entire NNHQ the ANWI 

Contractor shall: 

A. The ANWI Contractor shall extend the existing mobile communication 

system use by the NATO security personnel (handsets and vehicle 

mounted) by relocating the TETRA radio antenna from the current NATO 

HQ location to the NNHQ antenna farm. 

B. The ANWI Contractor shall relocate the NATO HQ’s current base station 

to the NNHQ, when NATO security is able to enter and occupy the NNHQ. 

(the movement of this antenna and base unit will not impact the system up 

time as the alternate system, located in Batiment Z, shall become the 

operational system during the move and after the move again serve as the 

back up unit with possible coverage issues). 

C. The ANWI Contractor shall provide the following: 

1. The ANWI Contractor shall migrate the existing TETRA system 

currently operational in the existing NATO HQ and implement additional 

equipment as required to meet the coverage requirements. 

2. The ANWI Contractor shall deliver additional terminals as described in 

the SSS. 

17.5.2-p3 If the signal does not propagate sufficiently to cover the entire NNHQ 

the ANWI Contractor shall provide a base station inside the building (but ensure that 

3V/m is not exceeded). 


17.5.3-p1 The following is a list for the requirements of the Site Security 

Communications system. The technical specifications of the existing Security 

Communications system can be found in Annex B. 

A. The ANWI Contractor shall deliver and implement a security 

communications system which: 

1. shall be based on a TETRA radio system. 

2. shall provide a full coverage, 100% of internal and external area, of the 

NNHQ campus and all its associated buildings. 






Resolution Time for Capacity Adjustments (hours) 1












 










Continuous 

 

 

17.5.5.1-p1 The Site security communication services must be fully integrated 

with: local telephony services, the TETRA-system and (selected) local emergency 

services (Belgian ASTRID emergency communications system for local police, 

national police, local fire department, etc.). 



17.5.6.1-p1 


17.5.7-p1 

The ANWI Contractor shall provide the End to End testing scenario. 

The ANWI Contractor shall recommend and provide training. 



17.6 APPENDIX 6: IPTV 




17.6.1-p1 Internet Protocol television (IPTV) is a system through which television 

services are delivered using the Internet Protocol Suite over a packet-switched 

network like the Internet, instead of being delivered through traditional terrestrial, 

satellite signal, and cable television formats. 


17.6.2-p1 

site. 

The Contractor shall provide an IPTV point of presence at the NNHQ 

17.6.2-p2 IPTV service shall be consumed through hardware nodes (Set Top 

Boxes (STB) or similar) for required locations and also be available through software 

nodes (web browser, soft client) on Public and Business networks. 

17.6.2-p3 The Contractor shall provide as a service the selected TV channels as 

identified and listed in reference 1.1.1.7.11. 

17.6.2-p4 

The system shall support restricting available channels per node. 

17.6.2-p5 The service is to be provided as an outsourced service, hence detailed 

equipment details are not required. 

17.6.2-p6 A metering and billing service will also be required to bill the consumers 

of the IPTV service. 

17.6.2-p7 

This service shall also be extended to all nations as well as IMS and IS. 


17.6.3-p1 The following general requirements have been identified for the IP TV 

Capability: 

A. The Contractor shall provide IP TV capability to the New NATO HQ by 

providing the two following components: 

1. IP TV services consisting of provisioning TV channels at the interface 

delivery point at the New NATO HQ. 

2. An IP TV system for distribution of the provided IP TV channels within 

the New NATO HQ infrastructure. 

B. The IP TV Capability shall be composed of and provide the interfaces as 

described in the following picture. 





IP TV SYSTEM 

NGCS 

(NATO WAN) 

Terrestrial Fibre 

Optic Connection 

Management 

System 

Web Portal Server 

Smart Phone 

Tablet 

SATCOM Connection 

LAN 

IP TV Core System 

Laptop 

Terrestrial Aerial 

Connection 

Desktop 

NATO VTC 

NATO TV 

Channels 

Public Access TV 

(Channel choice via Web) 

Figure 17.2: IPTV architecture 

17.6.3-p2 IP TV System Requirements: 

A. As part of the IP TV capability, the Contractor shall deliver an IP TV 

System which shall allow the reception of public TV channels and the redistribution 

of these TV channel to NATO users’ community. 

B. The delivered IP TV System shall allow the reception of NATO VTC 

sessions as well as NATO TV channels and the re-distribution of these 

VTC sessions and NATO TV Channels to the NATO users’ community. 

C. The delivered IP TV System shall allow the re-distribution of all received 

TV channels (Public and NATO) to the NATO users’ community being 

either located in NATO HQ or anywhere in the NATO network (NGCS). 

D. The IP TV System shall allow the direct reception of all TV channels to 

public TV sets distributed across the NATO HQ LAN. 

E. The IP TV System shall provide an IP TV System Web portal which shall 

allow the selection of the TV channel to be displayed on public TV via an 

intuitive interface. 

F. The IP TV System shall allow the reception of all TV channels to the 

following types of users clients via the embedded UCC client application: 

1. Desktop stations. 

2. Laptop. 

3. Tablet. 

4. Smart Phones. 

5. Multi-Media SIP Telephone Set. 





G. The delivered IP TV System shall be compliant with the OPEN IPTV 

Forum Release 2 Specifications. 

H. The provided channels shall be provided at the highest standard definition 

at which they are available for commercial distribution. 

17.6.3-p3 IPTV Client Requirements: 

The Contractor shall deliver dedicated IPTV clients that shall be installed throughout 

the NNHQ campus. There shall be 425 IPTV clients, these clients shall be based on 

60” displays with integrated IPTV functionality. The minimum IPTV client 

specifications are provided in Table 17.1. 

Display 

Item 


Enclosure 

Rugged for commercial indoor usage with flexible mounting 

options using VESA mounting 

Operation type Designed for continuous operation in 24x7 mode 

Size 

Min. 60” diagonal 

Native resolution Min. 1920x1080 

Brightness >=450 nits (or cd/m 2 ) 

Contrast (static) >=4000:1 

Viewing angles 170º horizontally and vertically, anti-glare coating 

Response time Gray-to-Gray =





IPTV Player 

Item 


Enclosure 

Rugged for commercial indoor usage mountable to a display 

Operation type Designed for continuous operation in 24x7 mode 

Noise 

Up to 35dB in room conditions 

Inputs - Network: 100Base-T, (Optional 802.11gn) 

Outputs 

Through direct connection with the display (plug-in module) 

or 

- Video: DVI, DSUB15, HDMI 1.3 

- Audio: RCA / stereo mini-jack or SPDIF 

Operating 

Min. 5°C-40°C 

temperature 

Power consumption =






Performance parameters 

Delay factor 

 

 

< 50 ms 

Media Loss Rate < 4 x 10-3 

17.6.4-p1 The Contractor shall monitor the delivered TV Services in real time and 

shall report disruption of services through an automatic and electronic monitoring 

tool. The contractor shall report data with respect to the following criteria defining 

availability, degradation and unavailability of the delivered services: 

Parameter 

Delay 

Factor 

Media Loss 

Rate 

Service 

Service 

Available if Degraded if 

0 all values in 50 ms one value 100 ms 

this window minimum is in 

0 4x10-3 this window, 8x10-3 

the other being 

available 

Service 

Unavailable if 

one value 

minimum is in 

this area 

17.6.4-p2 As specified in the Contract Special provisions, the Contractor shall pay 

Service Credit in case the delivered TV Services is Degraded or Unavailable as 

defined in paragraph 17.6.4.1. The Contractor shall calculate the amount of the 

service credit as follows: 

A. For Degraded services, the following table shall be applied for calculation 

of service credits, where TA equals the time during which the service shall 

be available: 

Duration of Status (worst case) 

0 < T < TA 0 

Degraded services penalties 

TA < T < 1h 0.25 x channel(s) daily rate / 24 * 1 

1h < T < 4h 0.5 x channel(s) daily rate / 24 * 6 

4h < T < 24h 

0.75 x channel(s) daily rate 

B. For Unavailable services, the following table shall be applied for 

calculation of service credits, where TA equals the time during which the 

service shall be Unavailable services penalties. 

Duration of Status (worst case) 

0 < T < TA 0 

Unavailable services penalties 

TA < T < 1h 0.5 x channel(s) daily rate / 24 * 1 

1h < T < 4h 1.0 x channel(s) daily rate / 24 * 6 

4h < T < 24h 

1.5 x channel(s) daily rate 

C. The status of any TV Channel will be declared available, degraded or 

unavailable after one continuous minute during which the parameters will 

meet conditions of paragraph 17.6.4.1. 







17.6.5.1-p1 The following internal interfaces and dependencies shall be 

described for the IPTV capability: 

User Services 

Processing 

Storage 

Printing 

AD 

DNS 

DHCP 

NTP 

NAC 


LAN 

Cross Domain 

IPTV X X X X X X X X X X X 

17.6.5.1-p2 Cross-domain interfaces: 


CD3-PUB One way IPTV-PUB IPTV 

Email 

IM 

Voice 

VTC services 

Presence 

Collaboration 

IPTV 

File services 

Remote users 

Browsing 

ESS 

BMS 



SMC 


CD2-BUS One way IPTV-BUS IPTV IPTV->CD3->CD2->NR 


17.6.6-p1 End-to-End Test Scenario 

IPTV - > GW3 NU Commercial - 

- > GW3 NR Commercial - 





SECTION 18. ANNEX J: INTEGRATION AND TESTING 

SERVICES 

18.1 APPENDIX 1: Introduction to Integration and Testing Services 

18.1-p1 The Integration and Testing Services (ITS) shall be implemented, operated 

and maintained by the ANWI Contractor at NCIA Brussels facilities (Bâtiment Z). This 

facility will serve as the main integrationtestbed for all projects that are part of the ICT 

programme, including building support systems. It will be used to test the different 

portions in a single (logical) environment to mitigate the integration risks. Integration 

with other testing facilities already procured for the Bi-SC AIS programme will be 

pursued. 

18.1.1 Interfaces 

18.1.1-p1 The ITS will interface with the NATO Wide Services Reference Test and 

Integration Services (AIS, NGCS, PIA, NCIRC and NPKI) and with Commercial 

Services Test and Integration Services. 

18.1.2 Security 

18.1.2-p1 The ITS will operate at NU level and should not be subject to security 

accreditation. It will provide a test environment to simulate NS, Business and Public 

services. It will not process, store or retrieve classified information. The ITS should 

not directly support the ANWI security accreditation process but it can be used to 

perform security tests. 


18.1.3-p1 It is not planned that training on ITS will be required for the ANWI 

project implementation as provision, operation and maintenance of the ITS shall be 

under the entire responsibility of the ANWI Contractor during this phase. 

18.1.3-p2 However, ITS being ultimately a NATO property, training may be 

required in the case ITS is planned to continue to be used by NATO after project 


18.1.3-p3 Therefore, training requirements for operation and maintenance of the 

ITS shall be provided by the ANWI Contractor. 

18.1.4 Requirements 

18.1.4-p1 

capabilities. 

The ITS shall reflect the performances to be provided by the ANWI 

18.1.4-p2 The ITS shall include all the ANWI services as identified in Annex C and 

all ANWI services internal and external interfaces as identified in Annex D. 

18.1.4-p3 

capabilities. 

The ITS shall reflect the expected operational use of the ANWI 

18.1.4-p4 The ITS availability is subject to the SLA in Appendix 3. 





18.1.4-p5 The ANWI Contractor shall put in place appropriate Back-up/Recovery 

measures in order to meet the ITS SLA requirements. 

18.1.4-p6 The ITS and the supported tests to be performed shall be subject to 

Configuration Management in order to have appropriate records of the test facilities 

baseline and of the tests configurations. 

18.1.5 Acceptance 

18.1.5-p1 The ITS will be accepted as part of the final ANWI acceptance process. 

Conformance to the SLA will be part of the acceptance criteria. 

18.1.5-p2 Hardware and software, procured as part of the ITS, shall be subject to 

normal warranty conditions. 

18.1.6 Documentation 

18.1.6-p1 ITS hardware and software standard documentation shall be provided 

by the Contractor. 

18.1.6-p2 All documents related to installation, operation (including all testing 

activities) and maintenance shall be provided by the Contractor. 

18.1.6-p3 Training requirements documentation for possible reuse of the ITS by 

NATO shall be provided by the Contractor. 

18.1.7 Architecture and Services 

18.1.7-p1 The ANWI contractor shall support the ITS architecture as introduced in 

figure 18.1 below: 





Figure 18.1: ITS high level architecture 

18.1.7-p2 The ITS shall support the following key features: 

A. The ITS shall allow Host Nations to test systems and services at the 

physical, logical and service interface levels; 

B. Physical interface testing shall be done at the ITS location; 

C. The ITS shall offer an external network interface through the NATO 

assigned testbed interconnection network to allow HNs to perform remote 

testing; 

D. The ITS shall support the following four “simulated”security classifications: 

1. NATO Secret. 

2. EAPC Secret 

3. NATO Restricted. 

4. NATO Unclassified [default classification]. 

18.1.8 Location and Facility Context 

18.1.8-p1 

The ITS shall be based at the NCIA Brussels facilities (Bâtiment Z). 

18.1.8-p2 Room-space shall separate at least three functions: server space, user 

space, little office space. 

18.1.8-p3 The ANWI contractor shall provide NATO with an ITS floor space 

design that will identify at the minimum: 

Facilities requirements (Cooling, Power, Floorspace). 

Network requirements (External connectivity to NATO Testbeds and Internet). 

Security requirements. 





18.1.8-p4 The Purchaser will providethe ANWI contractor the following 

systems/services from NATO for the duration that the ITS services are needed: 

A. Room-space that reasonably complies with the ANWI contractor provided 

ITS floor space design. 

B. Access to the following NATO network services: 

1. NATO wide test service network at the various classification domains. 

2. Equipment available via HN Belgium. 

a. Racks. 

b. Cabling. 

18.1.9 Organisational Support Requirements 

18.1.9-p1 The ANWI contractor shall be responsible for managing the ITS as a 

service and shall involve the required personnel to execute the ITS Concept of 

Operations as specified in Paragraph 18.1.11. 

18.1.9-p2 The ANWI contractor shall ensure that the ITS administrator, indicated 

in paragraph 18.1.9.3., is full time available to the Purchaser at the ITS location. 

18.1.9-p3 The ANWI Contractor shall assure the following minimum manning of 

the ITS during office hours: 

A. ITS administrator. 

B. ITS team manager/engineer. 

18.1.9-p4 The ANWI contractor shall assure that, in support of the full lifecycle of 

the HN tests, qualified personnel areavailable at the right time and with the proper 

subject matter expertise level to support the ITS’ services. 

18.1.10 Management Requirements 

18.1.10-p1 

The ANWI contractor shall manage ITS capability until FOC. 

18.1.10-p2 The ITS capability may be required to be managed until FSA. The 

ANWI Contractor shall be prepared tosupport an extension to the operation of the 

ITS. 

18.1.10-p3 The ANWI Contractor shall treat the ITS capability as the ANWIprelife 

system ensuring that the implemented and delivered configuration is under 

configuration management control. 

18.1.10-p4 The ANWI contractor shall provide ITS support to NNHQ related 

projects in the full test lifecycle of performing integration tests at the ITS as a 

prerequisite for deployment to the NNHQ site. 

18.1.10-p5 The ANWI contractor shall start providing the ITS services and 

complete the services by the end of the Post FSA operational testing and 

improvement activity as specified in paragraph 6.19. 

18.1.10-p6 The ANWI contractor shall assure that the ITS at all times is a 100% 

accurate representation of the ANWI capability as implemented or planned to be 

implemented in the new building. 

18.1.10-p7 The ANWI contractor shall update the ANWI ITS technologies in 

accordance with the technology confirmation principle as specified in paragraph 





3.7.2-p1 and this shall be reflected in the implementation plan. Three major update 

cycles are foreseen as (timelines are per Annex A): 

A. Initial ITS operation based on the ANWI design . 

B. ANWI IOC operation, including a major technology refresh based on the 

final design of the backend infrastructure (server room based) . 

C. ANWI FOC operation, including a major technology refresh primarily 

focused on the end-user devices . 

18.1.10-p8 The ANWI contractor shall provide ITS support during the various 

NNHQ ICT system/services life-cycle phases: 

A. Pre-migration and integration testing and validation prior to deployment of 

ICT systems to the new building. 

B. Post FSA Integration testing in support of system/services improvement 

and change management. 

C. [Option] O&M based continued integration test services. 

18.1.11 Concept of Operations 

18.1.11-p1 The ANWI Contractor shall operate the ITS as a service and 

support the full test life-cycle as shown in the process diagram in figure 8.2. 

18.1.11-p2 The General ITS life-cycle model will be divided into 6 main phases, 

as shown in Figure 18.22 below: 

Figure 18.2: ITS Life-cycle Model 

18.1.11.1 Planning and Controlling the ITS 

18.1.11.1-p1 The ANWI Contractor shall plan and control the use of the ITS and 

all testing activities performed on it throughout the whole duration of the ANWI 

project. 

18.1.11.1-p2 The ANWI Contractor shall develop an ITS Master Test Plan (MTP) 

for the purpose of informing all stakeholders concerning the generic description of 

testing approach, schedule, budget, activities and products to be delivered. 

18.1.11.1-p3 The ITS MTP shall include Generic Test Agreements, Test Policy 

and testing line organization. 




18.1.11.2 Setting Up and Maintaining the ITS Infrastructure 




18.1.11.2-p1 The ANWI Contractor shall set up and maintain the ITS 

infrastructure from the timeline as specified in Annex A, till FSA (see paragraph 

6.19). 

18.1.11.2-p2 The ANWI Contractor shall develop an ITS Infrastructure 

Specification Document that will include the following elements: 

A. Detailed specification of operational workplace. 

B. Detailed specification of operational test environment. 

C. Description of Test tools installed. 

D. “Workplace intake” Checklist. 

E. “Test environment intake” Checklist. 

F. “Test tools intake” Checklist. 

G. Intake procedure. 

H. Operational and Maintained infrastructure. 

18.1.11.3 Test Preparation and Specification 

18.1.11.3-p1 For the use of the ITS, the Host Nations (HN) will develop and 

submit a Test Plan derived from the ITS MTP and will also nominate a Test Manager 

who will be responsible for the whole Test Execution phase. The Test Plan will 

include the following elements: 

A. Establishment of Assignment. 

B. Definition of Test basis. 

C. Analysis of Product risks. 

D. Definition of Test Strategy. 

E. Estimation of Effort. 

F. Proposed Planning. 

G. Roll Back Plan. 

H. Allocation of Test Units and Test Techniques. 

i. Definition of Test products. 

J. Definition of the organization. 

K. Definition of the Infrastructure. 

L. Description of the management. 

M. Identification of Test risks and countermeasures. 

18.1.11.3-p2 On reception of the Test Plan, the ANWI Contractor and NATO will 

review the document, with the support of the IV&V Team. Upon agreement of the 

Test Plan and designation by the ANWI Contractor of an ITS Administrator and/or 

Engineer who will support the Test Manager, the test execution phase can start. 

18.1.11.3-p3 The HN Test Manager will confirm validity of the Test Plan and, on 

that basis, develop Test specifications. 

18.1.11.4 Test Execution and Completion 

18.1.11.4-p1 The HN Test Manager, with the support of the ITS Administrator 

and/or Engineer, will execute the Test and produce a test report which will include 

the test results. 

18.1.11.4-p2 The ANWI Contractor shall provide an ITS Test report from an 

ANWI perspective.



18.1.11.4-p3 In the case of differences between expectations and obtained test 

results, investigations will be carried out immediately after test execution and when 

test results are available. These differences can be caused by one or more of the 

following reasons: 

A. Tested product fault. 

B. Error in test basis. 

C. Error in test environment. 

D. Error in the test specification. 

18.1.11.5 Test Re-execution 

18.1.11.5-p1 In case of test failure, under the direction of the customer, the ANWI 

Contractor shall take all necessary measures to plan a test re-execution if this 

decision is taken by the Customer. 

18.1.11.6 Information Flow Diagram 

18.1.11.6-p1 The information flow diagram during the Test execution phase is 

described in the following figure 18.3. 

Figure 18.3: Information flow diagram 

18.2 APPENDIX 2: ITS Reference Environment 

18.2.1 Introduction 

18.2.1-p1 ITS is a reference system for the ANWI project. 





18.2.1-p2 It shall host a simulated environment representing all ANWI services to 

enable testing, verification and validation of the interconnections and interfacing 

between the ANWI services. 

18.2.1-p3 ITS shall also provide resources capacity to test the interfacing and 

integration of the HN Belgium components of ESS, BMS and AVI as well as the test 

and verification platform for the ICTM business application migration and 

integration.The contractor shall be responsible to provide the proper interfaces for the 

references systems to use and interact with ANWI services and provide support the 

different tests. 


18.2.2-p1 ITS shall represent a simulated ANWI environment with a test capacity 

for up to 100 concurrent simulated ANWI users (from a services perspective). 

A. UCC Services 

B. SMC 

C. Cross-domain capabilities 

D. Client Provisioning 

18.2.2-p2 

Reserved 

18.2.3 ITS Infrastructure 

18.2.3.1 ANWI Services 

18.2.3.1-p1 The contactor shall design and size the ITS components like 

processing, Storage, networking and Clients in such a manner that all the ANWI 

services based on a 100 concurrent user capacity can be hosted. Furthermore shall 

the contractor take into account an additional 50% processing resources to cover for 

HN Belgium and ICTM services. 

18.2.3.1-p2 From a storage perspective the contractor shall provide 10TB 

usable SAN space to host "simulated” data. This storage capacity is on top of the 

required Storage to host the ITS ANWI services and corresponding backup 

capability. 

18.2.3.2 Availability 

18.2.3.2-p1 As part of the ANWI ITS infrastructure the contractor shall be able to 

demonstrate the high availability and fail-over requirements of the actual ANWI 

services. 

18.2.3.3 Cross-Domain Services 

18.2.3.3-p1 In order to test and validate the Cross-domain functionalities the 

contractor shall provide a simulated CMD environment capable of simulating the 

required and proposed cross-domain traffic. This includes a both the sending and 

receiving network in case of cross domain transfers.This shall enable the contractor 

to test the cross-domain services requirements (ref. SOW Annex E Appendix 2). 



18.2.3.4 ITS Optimization 



18.2.3.4-p1 In order to avoid an extensive ITS infrastructure the contractor shall 

propose a flexible ITS solution capable of staging and storing different "scenario's" 

(virtual images of specific configurations) without the need for dedicated 

infrastructure for every use case. (Ex. ITS shall be able to simulate different 

scenarios for testing using the same infrastructure). The ITS infrastructure should be 

able to simulate all possible ANWI services as well as support the interfaces to other 

systems as identified in Annex D. 

18.2.3.5 Physical Client 

18.2.3.5-p1 From a physical client perspective the contractor shall provide for 40 

client configurations to include at least 10 each of every proposed client 


A. Desktopclient device (standard / high Performance / Agnostic) 

B. Mobile Client device 

C. Laptop/Tablet 

D. IP Phones (standard and secretarial) 

E. PDA/Smartphone 

18.2.3.6 Dedicated Test Hardware 

18.2.3.6-p1 As part of the ITS environment the contractor shall also provide 

dedicated test hardware and/or software (ex. Traffic/Load generators) required to 

support the different test scenarios.In order to run in-depth test the contractor shall 

provide tools that run tests automatically overnight, and produce reports about any 

failures. 




18.3 APPENDIX 3: ITS Service Level Agreement (SLA) 

18.3.1 Introduction 

18.3.1.1 Background 


18.3.1.1-p1 This Service Level Agreement is part of the Contract CO-13300- 

ANWI and it establishes a commitment for the provision and management of 

Integration and Testing Services (ITS) and associated infrastructure between the 

Service Contractor (ANWI Main Contractor) and Customer. This document defines 

the specifics of the Service Level Agreement (SLA) to be put into effect between the 

Customer (NATO) and the Service Contractor. 

18.3.1.2 Scope of Agreement 

18.3.1.2-p1 This SLA is established between NATO (The Customer) and the 

ANWI Contractor. It describes the Services under the provision of Integration and 

Testing Services. 

18.3.1.2-p2 The SLA documents the terms and conditions under which, the 

ANWI Contractor shall deliver the Services to the Customer. The main objective is to 

provide ITS in an efficient and cost-effective manner throughout the whole duration of 

the ANWI Project. 

18.3.1.3 Contact Points 

18.3.1.3-p1 The services to be provided involve a number of ANWI Project 

stakeholders and of Contact Points who are identified in the table 18.1 below. 

Position Name Telephone Fax 

ANWI Contractor 

ANWI Project Manager TBD TBD TBD 

ITS Team Manager/Engineer TBD TBD TBD 

ITS Administrator TBD TBD TBD 

NATO 

HQPO TBD TBD TBD 

NCIA TBD TBD TBD 

ICTM TBD TBD TBD 

BELGIUM 

TBD TBD TBD TBD 

Table 18.1: Customer and Contractor Contact Points 

18.3.1.4 SLA Review Procedure 

18.3.1.4-p1 The SLA is reviewed each month. The review will be based on input 

from both parties, including the outcomes of user surveys, technological 

opportunities, developing requirements, tests reports and issues raised at the 

quarterly Customer/Contractor performance review meetings. 







18.3.1.4-p2 This SLA will be reviewed periodically and an out of cycle review will 

be held under the following circumstances: 

A. The Contractor fails to achieve the service level targets detailed in this 

document for two consecutive weeks or; 

B. Any two in four consecutive weeks. 

18.3.2 Service Delivery 

18.3.2.1 Service Levels 

18.3.2.1-p1 The Contractor shall deliver agreed Services under this SLA in 

accordance with the ANWI SOW, Customer priorities and the Service Levels 

indicated in Paragraph 18.3.2.3. 

18.3.2.1-p2 The Customer shall have full read access to the monitoring and 

reporting mechanisms of the ANWI Contractor. This is required for the Customer to 

allow trend analysis on performances and availability of the delivered Services, as 

the services provided under this Agreement are directly linked to services provided in 

Customer owned internal SLAs and other Formal Arrangements. 

18.3.2.1-p3 The ANWI Contractor shall ensure that the customer has full access 

to a dashboard(s) that displays all the agreed up on Service levels as recorded in 

Paragraph 18.3.2.3 or in any part of this Agreement. 

18.3.2.2 Service Continuity 

18.3.2.2-p1 The ANWI Contractor shall notify the Customer of any scheduled 

maintenance or outages at least 10 working days in advance. Scheduled outages of 

ITS shall be coordinated with the Customer’s Project Manager and approved by the 

Customer. For scheduled events, the ANWI Contractor shall contact the Customer 

for confirmation 5 working days prior to executing the outage. Provided there are no 

overruns, scheduled outages periods will not count towards performance indicator 

calculations. 

18.3.2.2-p2 The ANWI Contractor shall provide roll-back plans for all scheduled 

maintenance. The plans shall be submitted to the customer with the outage request. 

These plans are to identify: impact analysis on ITS availability, functionality and time 

thresholds that can be initiated by either the ANWI Contractor or the Customer when 

any threshold identified in the outage plan is reached. This may include unscheduled 

events elsewhere, requiring the restoration of the Service element undergoing 

maintenance in order to comply with agreed Service Levels. 

18.3.2.2-p3 The ANWI Contractor shall provide the maintenance requirements, 

if any, and send them to the Customer’s Project Manager, as identified in the table 

18.1, via email or another common approved form. 

18.3.2.2-p4 It is the Customer's responsibility to inform the ANWI Contractor at 

least 10 working days in advance of any projects or events to be undertaken on life 

support Services (electricity, air conditioning, etc.) that may potentially impact any 

portion, component or segment of the ITS provided under this agreement. 

18.3.2.2-p5 In either of the above cases, interruption of Services should be kept 

to a minimum and scheduled outside normal office hours (08H00-18H00 Brussels



Time) unless approved by the Customer, and must be officially requested and fully 

coordinated ahead of time with the appropriate POCs for both parties. 

18.3.2.2-p6 All upgrades to operating systems Hardware/Software (HW/SW) 

shall be completed without unscheduled downtime where this is not possible then it is 

mandatory that the Contractor uses the Service Continuity procedure. 

18.3.2.2-p7 

All planned outages will be agreed and approved by the Customer. 

18.3.2.2-p8 The ANWI Contractor shall keep the Configuration Change Log Up 

to Date after every maintenance window. 

18.3.2.3 Support Services 

18.3.2.3-p1 From the date of availability of the ITS, the services to be provided 

will be subject to this SLA and will be monitored according to the following indicators: 

Event ANWI Contractor Action Quality Indicator 

Type Supporting Type 

Supporting Documents 

Documents 

Request to Letter 

Reply to the request Letter 

Response time: 

conduct a test Test Plan Review Test Plan 

confirm test execution 

schedule 

Comments on Test Plan 

Confirmation of test 

execution 

Nominate Test 

Administrator 

2 working days 

Test 

execution 

Test 

completed 

Provide technical support 

during all test execution 

Personnel availability: 100 % 

Test report Produce ITS Test Report ITS Test report Document delivery: 

2 working days after test 

completion 

Test failure Test report Confirm test re-execution 

schedule 

Confirmation of test reexecution 

schedule 

Table 18.2: ITS indicators 

Response time: 

5 working days 

18.3.3 SLA Change Management 

18.3.3.1 Changes to the SLA 

18.3.3.1-p1 

other party. 

If changes are required to this SLA they shall be agreed by the 

18.3.3.1-p2 This shall be achieved by the requesting party documenting the 

change(s) required and the reason for the change(s) and forwarding this document to 

the appropriate contact point as follows: 

A. Changes requested by the ANWI Contractor should be addressed to the 

Purchaser’s Project Manager, as identified in Para 18.2.1.3. 

B. Changes requested by the Purchaser should be addressed to the 

Contractor’s Project Manager, as identified in Para 18.2.1.3. 

18.3.3.1-p3 Once the request is received this shall be approved via the change 

control process within the ANWI project. 



18.3.3.2 Control of the SLA 





18.3.3.2-p1 The ANWI Contractor’s Project Manager shall be responsible for 

updating this agreement and shall ensure that all changes have been approved and 

significant changes highlighted before the new version is distributed. 

18.3.3.2-p2 This SLA and any subsequent changes must be approved by the 

Customer’s Project Manager. 

18.3.3.2-p3 This SLA will be distributed in accordance with the defined 

distribution list. It shall be available through the Project Manager to the ANWI 

Contractor personnel responsible for the delivery of the service so that they become 

familiar with this SLA and Service requirements. 

18.3.3.3 SLA Change Control Authorisation 

18.3.3.3-p1 This section covers the request for additional services and changes 

to the SLA. The SLA shall be reviewed regularly and any changes to the SLA will be 

made as part of that process. However, during the course of the service provision it 

may be necessary to request services additional to those provided by the SLA or to 

request temporary changes to the service. 

18.3.3.3-p2 

of the parties. 

This agreement shall be amended upon the written mutual consent 

18.3.3.4 Changes to Service Provision 

18.3.3.4-p1 A change to the contracted service must be proposed in written 

format by both parties. All agreed changes shall be made in accordance with the 

defined and agreed change management procedure. 

18.3.3.4-p2 Requests for changes shall only be accepted and approved by the 

following personnel: 

A. The Customer’s Project Manager. 

B. The ANWI Contractor’s Project Manager. 

18.3.4 Roles and Responsibilities 

18.3.4.1 Customer Responsibilities 

18.3.4.1-p1 The Customer will: 

A. Allow the Contractor to carry out its ITS operations by affording 

appropriate physical facilities and systems. It is the goal to have a fully 

integrated solution allowing both parties full visibility of the integrated 

components and Services. 

B. Provide the contractor personnel with space offices, and generic office 

automation (Phone, classified and unclassified E-mail) in the NATO 

facilities. 

C. Provide direction, information, prioritisation, authorisations or decisions 

that are reasonably necessary for the ANWI Contractor to deliver the ITS 

Services. 

D. Serve as the Security Authority and Security Accreditation Authority. The 

Customer will ensure that pertinent security measures are implemented in 

accordance with NATO regulations.


18.3.4.2 ANWI Contractor Responsibilities 


18.3.4.2-p1 The ANWI Contractor will: 

A. Deliver Services in accordance with customer-established priorities and 

identified Service Levels. 

B. Provide Services in a manner consistent with applicable NATO and 

relevant national technical and security standards, codes and best 

practices. 

C. Keep the Customer informed of developments that may affect the level of 

Service provided under this Agreement. 

D. Ensure that all Services are performed by appropriately qualified, trained 

and English speaking personnel. 

E. Deliver the Service in accordance with the provisions of the SOW. 

F. Ensure that all Services are performed with due care and diligence, 

including conducting periodic quality audits of the Service and associated 

documentation and supporting databases. 

G. Provide sufficient resource to meet delivery of the Service to the agreed 

level of service. 

H. Work closely with other support teams, in particular for problem resolution 

and change control. 

I. Advise the Customer of any patches or upgrades which it may be 

necessary to load. 

J. Adhere to the working practices agreed between the ANWI Contractor and 

the Customer, including all aspects of the corporate data policy. 

K. Provide adequate and full information, as far as is reasonably practical, to 

enable incident and problem resolution. 

L. Submit problems which may be, as far as can be reasonably discerned, 

within the ANWI Contractor’s scope of responsibility. 

M. Provide appropriate points of response or contact for passing back 

solutions and information, such as direct phone numbers, e-mail or fax. 

N. Notify impending outages in areas within the Customer responsibility on 

which the Service is dependent. This notice will be on the same terms as 

that expected from the ANWI Contractor as detailed in Para 18.2.2.2. 

O. Notify forecasts, trends or projections of growth where these may affect 

the overall Service performance. 





SECTION 19. ANNEX K: DOCUMENTATION AND REPORTS 

19.1 Appendix 1: ANWI Document Requirements 

19.1.1 Purpose 

19.1.1-p1 This Annex describes the requirements for each document that that the 

ANWI Contractor shall provide as part of the ANWI contract. 

19.1.1-p2 This introductory section identifies the general guidelines and 

requirements for ANWI documentation submitted as part of this contract. 

19.1.2 Format Requirements for Project Documentation 

19.1.2-p1 The ANWI Contractor shall ensure that all delivered documentation 

complies with the identified format and content specifications as identified in the 

following appendices. 

19.1.2-p2 Where no format is specified, the ANWI Contractor shall propose a 

format from his selected management methodology to the Purchaser to agree on the 

structure and content of the document. 

19.1.2-p3 All documentation provided to the Purchaser shall be written in English 

with spelling and usage based on the Concise Oxford English Dictionary, 11th 

edition. 

19.1.2-p4 The convention to be used for numbers appearing in textual documents 

is for a comma to be the thousands separator and a period to be the decimal 

separator (e.g., 1,365,276.24). 

19.1.2-p5 The convention to be used for dates appearing in free text (e.g., quoting 

dates of meetings) is day-month-year (25 May 2013). 

19.1.2-p6 Documentation labelling: 

A. Documentation shall neither be marked with corporate logos nor contain 

warnings limiting the rights to use or reproduction. 

B. Every page shall include a header and footer indicating the highest 

classification of content on that page using one of the following labels: 

NATO CONFIDENTIAL (as built document containing IP addresses and 

locations), NATO RESTRICTED (sensitive information identifying a named 

location or security assessment), or NATO UNCLASSIFIED 

C. If the ANWI information is to be released to a non-NATO nation (partner), 

the originator shall mark the document or equipment in accordance with its 

classification level, and add a “RELEASABLE TO EAPC” tag, after the 

appropriate classification marking. 

D. The document’s cover page’s header and footer shall reflect the highest 

classification of content in the document 

E. All project documentation shall contain a version number appropriate to 

the major / minor concept (e.g. v1.0, v1.1, v1.2, v2.0, v3.0) where the first 

number represents a major release or significant change to the content 

while the second number represents a smaller change (e.g. spelling 

corrections, formatting or minor adjustments). 




19.1.3 Submission of Project Documentation 



19.1.3-p1 The Contractor shall submit documentation as follows: 

A. The ANWI Contractor shall submit all contracting documentation (e.g., 

change proposals, invoices) in paper form. 

B. The ANWI Contractor shall submit all project management documentation 

(e.g., plans, schedules, reports, etc.) as electronic copies in MS Office 

2010 format to the Purchaser for review and comment. 

C. The ANWI Contractor shall submit all other types of deliverables as an 

electronic copy in a format which is best suited for review and 

maintenance per the following guidelines: Microsoft Word shall be used for 

generating text document; Microsoft Excel shall be used for tabular or 

matrix data; Microsoft Visio shall be used for drawings; Microsoft Project 

shall be used for schedule; and Microsoft PowerPoint shall be used for 

briefings. 

19.1.3-p2 The ANWI Contractor shall provide a first draft (version 0.1) of each 

deliverable for Purchaser review by the date specified in the Schedule of Supplies 

and Services or as agreed between the Purchaser’s Contracting Officer and 

Contractor. 

19.1.3-p3 The ANWI Contractor’s first draft shall be substantially complete, 

consistent and correct. 

19.1.3-p4 The ANWI Contractor shall not provide any contractual documentation 

in a partial or gradual manner. 

19.1.3-p5 The ANWI Contractor shall not rely on the Purchaser’s review to fill in 

deficiencies or obtain missing Purchaser information. 

19.1.4 Delivery and Distribution of Project Documentation 

19.1.4-p1 The ANWI Contractor shall deliver project documentation to the NCIA’s 

Contracting Officer 

19.1.4-p2 The ANWI Contractor shall place an electronic copy of the 

delivered/issued document on the Project’s Website, and send a link to the 

Purchaser 

19.1.4-p3 The Purchaser’s Contracting Officer will distribute the delivered/issued 

ANWI document link to: 

A. the Purchaser’s Project Manager 

B. the Technical Leader 

C. the ANWI IV&V Contractor 

19.1.5 Review of Project Documentation 

19.1.5-p1 The Purchaser will provide comments, corrections, and suggested 

changes to the Contractor’s version 0.1 within two (2) weeks of receipt, unless 

otherwise specified in the SOW appendix covering the document in question. 

19.1.5-p2 The Purchaser reserves the right to return without review a document 

that has significant deficiencies (e.g. a document only including a table of contents); if 

this is the case the ANWI Contractor shall resubmit a new document as version 0.1 

within 1 week. 

N A T O U N C L A S S I F I E D



19.1.5-p3 The ANWI Contractor shall repair all reported deficiencies and submit 

the revised draft (version 0.2) incorporating the Purchaser's comments within two (2) 

weeks after receipt, unless otherwise specified in the SOW appendix covering the 

document in question. 

19.1.5-p4 The ANWI Contractor’s changes shall be provided in the form of: 

A. change pages for contractual documentation; pen and ink corrections or 

‘track changes’ shall not be acceptable. 

B. track changes for all other project documentation requiring an iterative 

review processes is acceptable. 

19.1.5-p5 The Purchaser will review and respond to the ANWI Contractor’s 

version 0.2 within one (1) week of receipt. 

19.1.5-p6 The ANWI Contractor shall review and repair any last (reported) 

deficiencies and provide the Final (version 1.0) document within one (1) week of 

receipt of the Purchaser's comments on the revised draft. 

19.1.5-p7 The Purchaser will, within two weeks, either accept version 1.0 as the 

baseline or revert to version 0.2 to the ANWI Contractor. 

19.1.5-p8 If the document is included as part of a Development Baseline, Product 

Baseline or Project Management documentation, the ANWI Contractor shall remain 

responsible for updating the document to reflect changes in: project management, 

system requirements, design, or support arrangements as part of Contractor’s 

Configuration Management tasks throughout the contract. 

19.1.6 Control Information for Project Documentation 

19.1.6-p1 Every document submitted to NATO shall contain the following pages 

and section in addition to the specific content identified in the appropriate appendix: 

19.1.6-p2 

Cover Page 

19.1.6-p3 

The cover page shall contain the following information: 

Header Classification 

Title 

Contract number (CO-13300-ANWI) 

Version X.X 

Delivery date (DD MMM YYYY) 

Footer Classification 

The control information section shall contain the following information: 

Information Page 

Status 

draft, review, released, approved, rejected 

Due Date 

Day, month and year – DD MMM YYYY 

Delivery Date 

Day, month and year – DD MMM YYYY 

CLIN 

Number from the ANWI SSS 

Version/Revision History 

Optional for internal documents while in 

draft and review, but is mandatory for 

released documents and those reviewed. 

Major versions are those approved by 

NCIA and are identified as #.0; minor 

versions will be identified as #.x reflecting 

the revision number 





Document Approval 

Table showing those reviewing the 

document and the date reviewed 

Table of Contents Page 

Self-explanatory 

Table of Figures Page 


Table of Tables (DRAWINGS, 


ILLUSTRATIONS, CHARTS) Page 

19.1.6-p4 Every document shall contain an abbreviations section that contains 

only those abbreviations/acronyms used in the provided document. 

19.1.6-p5 Every document shall include, as needed, a section for references used 

in the writing of the document. 




19.2 APPENDIX 2: Design Document 

19.2.1 Introduction/Purpose 


19.2.1-p1 The purpose of the design document is to obtain agreement from all 

NNHQ parties on the vision and plans for the ANWI design to support the 

implementation of the New NATO Headquarters. 

19.2.2 Scope/Assumptions 

19.2.2-p1 The ANWI Contractor shall produce and maintain the ANWI design 

document which implements the ANWI technical requirements in accordance with the 

ANWI SOW 

19.2.2-p2 The ANWI Contractor shall produce the ANWI design in accordance 

with the ‘document structure’ section defined below. 

19.2.2-p3 The ANWI design document shall addresses the ANWI service 

requirements, environment, services, service management concept, detailed service 

design, processing logic, and external interfaces to build the various services that 

together are the ANWI. 

19.2.2-p4 The ANWI design document shall also describe the architecture, 

technologies, standards, and equipment to deliver the needed capabilities as well as 

how the capabilities shall be bundled to support the needs of the services identified in 

the SOW and finally how they shall be technically managed. 

19.2.3 Reporting& Provisioning 

19.2.3-p1 The ANWI Contractor shall use the review processes described in 

Annex K Appendix 1for the CMP. 

19.2.3-p2 The Contractor shall deliver the design document in accordance with 

the Schedule of Supplies and Services. 

19.2.3-p3 The ANWI Contractor shall update and adjust the document, as 

required, after every review and as needed during the period Effective Date of 

Contract (ED) through Final Operating Capability (FOC). 

19.2.4 Document Structure 

19.2.4-p1 

below: 

Section 

# 

The Design Document shall be structured according to the format 

Section Title 

Executive Summary 

Section Description 

Provides a managerial description of the 

project from and an overview of the 

framework used to develop the conceptual 

ANWI design. 







Section Section Title 


# 

1 Introduction This section defines the purpose and overall 

objective of the document focusing on 

delivery, installation, and configuration for the 

various networks and how capabilities and 

services fit together. It also addresses the 

baselines used, service management and the 

goals of the design. 

1.1 Purpose and Scope State the purpose of the ANWI Design 

Document and identify the materiel to which 

the design is to be applied and the 

management/acquisition philosophy to which 

it is tailored. 

High level discussion of the design’s 

deliverables 

1.2 Document 

Organization 

This section describes the organization of the 

Systems Design Document. 

1.3 Points of Contact Provides the title and organization of the key 

points of contact for the overall design and 

each subsystem of the ANWI system 

implementation. These points of contact 

must also include/identify the project’s: 

Quality Assurance (QA) Manager, Security 

Manager, and Configuration Manager. 

1.4 Glossary Includes a glossary of all terms and 

abbreviations used in this document. If the 

glossary is several pages in length, it may be 

included as an appendix 

2 Requirements 

2.1 Location 

requirements 

2.2 Information 

Exchange 

Requirements 

2.3 Security 

Requirements and 

Constraints 

2.4 Service Management 

and Control (SMC) 

This section identifies the physical campus 

locations and how they are to be overall 

supported. 

This section identifies the types of 

information and their flows through the 

system and outside the system. 

This section identifies the definitions / 

specifications needed to provide the 

information assurance capabilities for the 

ANWI design and any provided appliances. 

This section identifies the 

definitions/specifications needed to provide 

the SMC hardware and software capabilities 

to deliver monitor and manage the ANWI 

capabilities. 

This section also addresses how the ANWI 

SMC interfaces with the NCIA main service

Section 

# 


Section Title 

2.5 Security Domains 

and Remote Sites 





management node for reporting and how 

NCIA will be able to provide management 

oversight of the NNHQ assets 


specifications needed to deliver the campus’ 

4 network security domains, and to support 

the remote NATO sites 

2.6 Network Services This section identifies the definitions / 

specifications needed to provide high 

availability and redundant (failover) network 

services required in the annexes and 

appendices 

2.7 Client Services This section identifies the definitions / 

specifications needed to provide the client 

service capabilities and configurations 

required in the annexes and appendices 

2.8 Unified 

Communications & 

Collaboration (UCC) 

2.9 Supplementary 

Services 

2.10 Integration & Test 

Service (ITS) 


specifications and integration needed to 

provide the UCC capabilities required for the 

configurations 


specifications needed to provide the 

supplementary services’ and meet EU 

emission (health and ) standards supporting 

the ANWI 


specifications needed to provide the ITS 

capability to ensure the complete testing of 

services prior to installation on the ANWI 

2.11 Service Interfaces This section identifies the definitions / 

specifications needed to describe the service 

interface points supporting the delivery of the 

ANWI. 

2.12 Service Delivery This section identifies the definitions / 

specifications needed to describe how each 

service is to be packaged to meet the 

specified requirements 

2.13 Environmental 

Controls and Power 

requirements 

3 Architecture& 

Performance 

This section addresses how the Contractor 

will meet the ‘green IT’ requirements and its 

application in the ANWI design criteria 

In this section, describe the ANWI services 

and it subsystem(s) architecture for the 

projectstressing the incorporation 

ofmodularity and interface design as defined 

in the Target Architecture.


# 

3.1 Architectural 

Principles 






This introductory section describes the ANWI 

architecture’s adoption of the basic principles 

described in the SOW and explains how the 

ANWI design ensures that the following 

principles are incorporated into the design 

3.1.1 Performance This subparagraph describes how the 

contractor is going to design a system that 

meets the performance requirements found 

in the SOW’s annexes. 

3.1.1,1 Reliability This subparagraph explains how the 

contractor will identify and implement quality 

reliable COTS products to reduce the length 

of time between service or component 

failures 

3.1.1.2 Availability This subparagraph describes how the 

contractor is going to design a robust system 

that minimises downtime versus uptime 

though the provision of highly available 

services and capabilities 

3.1.1.3 Scalability This subparagraph explains the contractor’s 

concept of accommodating the scalability and 

flexibility of processing, memory usage and 

storage capacity as defined in the service 

parameters found in the SOW’s annexes 

3.1.1.4 Flexibility This subparagraph describes the contractor’s 

concept of supporting the dynamic increase 

and release of server/storage services based 

on demand within the parameters of the 

SOW 

3.1.1.5 Confidentiality This subparagraph explains the high level 

concept of how the contractor will ensure that 

proper information assurance measures are 

implemented to prevent data loss, data 

leakage and information integrity 

3.1.1.6 Continuity This subparagraph describes how the 

contractor will ensure that the time to restore 

a service is per recovery targets 

3.1.1.7 Maintainability This subparagraph explains how the design 

of the overall system will minimise the 

average time to repair a service, capability or 

component 

3.1.1.8 Serviceability This subparagraph discusses how the 

delivered capabilities will be monitored 

demonstrating that the provided services and 

capabilities are meeting the terms of the 

service contract







# 

3.1.2 Standardisation This subparagraph addresses how the ANWI 

design will minimize the variation of 

components and products in the ICT 

infrastructure through the use of a set of welldefined 

products that are standardized to the 

extent possible across the four networks. 

3.2 Logical Layout This section addresses the logical layout of 

the various capabilities reflecting the 

connections and services 

3.2.1 NATO SECRET (NS) 

network 

This section logically depicts the NS network 

with its server room configurations, 

communications connections, TER 

connectivity, services on this security domain 

and how services will be delivered to the 

users for each of the networks and their 

associated services 

3.2.2 EAPC network This section logically depicts the EAPC 

network with its server room configurations, 






3.2.3 Business (NR) 

network 

This section logically depicts the Business 

network with its server room configurations, 



(as well as its hosted NATO Unclassified 

services) and how services will be delivered 

to the users for each of the networks and 

their associated services 

3.2.4 Public Network This section logically depicts the network with 

its server room configurations, 






3.2.5 Cross Domain 

Modules (CDMs) 

This section logically depicts the cross 

domain module and its CDGWs with their 

configurations, communications connections, 

TER connectivity, and the services offered 

via these modules 

3.3 Physical architecture This section addresses the interconnection of 

the various capabilities reflecting the





Section 

# 

Section Title 


interfaces and standards used, as referred to 

in Annexes C and D 

3.3.1 HardwareArchitecture Describes the overall system hardware 

including a list of hardware components (with 

a brief description of each item), how the 

hardware will be monitored by the SMC and 

diagrams showing the connectivity between 

the components and subsystems (use 

3.3.2 Core Service 

Software Architecture 

3.3.3 Communications 

Architecture 

subsections to show each ANWI subsystem). 

Describe the overall system software by: 

including a list of software applications and/or 

modules; a brief description of the 

purpose/use of each item (use subsections to 

address each application and/or module); 

maps the software to its service capability; 

define its security rolesettingsand how the 

software will be monitored by the SMC. Use 

diagrams to map the data flow and 

processes. 

Describe the overall communication (internal 

and external to NATO) in the system and 

provide diagrams showing the 

communications path(s) between the system 

and subsystem modules (use subsections for 

each subsystem flow) also in view of the 

redundancy requirements 

3.3.4 Technology Forecast Describe the possible impact of the trends in 

technology and the long term (5 year) viability 

of the proposed architecture and 

technologies with respect to these trends 

3.3.5 Future Contingencies Describe any contingencies that are 

deployed to support the ANWI’s technical 

evolution due to technology updates and new 

hardware/software releases. Also address 

interfacing systems and services, even 

whilethe ANWIis still beinginstalled. 

4 Design 

4.1 Design/System 

Overview 

Provides a non-technical description of the 

ANWI in narrative form. It provides a highlevel 

system architecture diagram showing 

ANWI subsystem breakout. The high-level 

system architecture and subsystem diagrams 

must show interfaces to external systems 

and a high-level context diagram for the 

system and subsystems. Ensure that this is

Section 

# 


Section Title 

4.2 Design Constraints 

and Assumptions 



mapped to the requirements traceability 

matrix to satisfy the requirements in this 

design document 

Describes any constraints in the design and 

include any assumptions made in developing 

the system design as well as addressing the 

relationship to other plans/projects 

4.2.1 Assumptions This section provides the list of assumptions 

for the design for the ANWI 

4.2.2 Dependency 

Constraints 

This section identifies 

anydependencyconstraints to the project 

4.2.3 Environmental 

Constraints 

This section identifies the power, cooling and 

UPS constraints in the server rooms, 

communications rooms, and TERs based on 

the proposed design 

4.3 NATO SECRET 

Security Domain 

4.3.1 Concept of 

Operations 


requirements 

4.3.3 Standardisation of 

components & Reuse 

This section addresses how the services use 

the various capabilities to deliver the full 

scope of the service and how these services 

shall be managed and controlled to meet the 

SLAs. Additionally, this section shows how all 

the services integrate to deliver a coherent 

solution supporting the user requirements. 

This section addresses the physical locations 

of devices and rack configurations in the 

server rooms and TERs 

This subparagraph addresses how the 

ANWI’sNS design minimizes the variation of 

components and products in the overall 

ANWI ICT infrastructure through the use of a 

set of well-defined common products that are 

standardized to the extent possible across 

the four networks. 

4.3.4 Service Delivery This section addresses how each capability 

of the NS is bundled to meet the 

performance, reliability, availability, 

scalability, security, maintainability and 

serviceability of each required service (by 

annex). Additionally, it addresses how the NS 

services are managed by the SMC to meet 

the SLAs. 

4.3.4.1 Network Services This section addresses the hardware and 

software definitions/specifications needed to 







Section 

# 

Section Title 


provide the information assurance 

capabilities of the NS. This also section 

addresses the design scope and 

configuration of the NS portion of the ANWI. 

Its subsections will detail the various services 

provided on and via the NS network. 

4.3.4.1.1 Wired This section identifies the switched design for 

this network 

The number of servers and clients 

to be included on the network 

LAN topology 

Configuration and settings 

4.3.4.1.2 Processing This section identifies the server room 

configuration/rack layout and defines how the 

processing requirement is to be satisfied 

meeting the availability, reliability, scalability, 

flexibility and performance requirements 

addressing items like: 

Power input requirements for each 

component 

Network connector specifications 

Server memory and local disk 

space requirements 

Processor requirements (speed 

and functionality) 

Graphical representation of the 

racks 

Server room cable type(s) and 

length(s) 

Rack console(s) 

4.3.4.1.3 Storage This section describes the storage design, 

availability, reliability, scalability, flexibility 

and performance requirements 

4.3.4.1.4 Infrastructure This section identifies how these services will 

be provided on the NS and integrated with 

the wider NS WAN 

4.3.4.1.5 Print & Scan This section describes how these services 

will be provided on the NS 

4.3.4.2 Unified 



Services 

This section addresses the hardware and 

software definitions/specifications and 

integration needed to provide the required 

UCC capabilities andservice 

4.3.4.3 Client Services This section addresses the hardware 

configurations and software 

definitions/specifications needed to provide



Section 

# 

Section Title 

4.3.4.4 Security 

Configurations 


the ANWI NS client capabilities 

Power input requirements for the 

device and monitor 

Memory 

Connectivity to storage 



Wall-device cable type(s) and 

length(s) 

User interfaces 

Hard drive/floppy drive/CD-ROM 

requirements 

Monitor resolution 

The section explains the security 

components used and how they combine to 

satisfy theinformation assurance 

requirements. It also explains the need and 

configuration for any security appliances. 

Finally identifies security risks and 

configurations needed for the services and 

networks to secure accreditation 

Internal security to restrict access 

of critical data items to only those 

access types required by users 

Audit procedures to meet control, 

reporting, and retention period 

requirements for operational and 

management reports 

Application audit trails to 

dynamically audit retrieval access 

to designated critical data 






capabilities related to SMC. 

This section also explains how the services 

are to be managed and monitored across the 

various networks into the NNHQ network 

operations centre (NOC). Additionally, it 

explains how the operational status/metrics 

shall be captured, routed, monitored, ‘billed’ 

and displayed in the NOC to show that the 

service is meeting its SLA and how the 

information will be decomposed to show what 

part of the service is causing the issue. 









# 

4.3.5 Service Interfaces A Service Interface Profile (reference Annex 

K Appendix 17 - SIP) will be developed that 

specifies the interface logical and physical 

characteristics and configuration parameters 

for all service (internal and external) 

interfaces. 

4.3.6 Service Integration As there are numerous networks and 

numerous services, this section addresses 

how the ANWI contractor and subcontractors 

shall deliver and seamlessly integrate the 

ANWI deliverables and NATO PFE into a 

coherent highly available network to provide 

the required end-to-end services as well as to 

support provision of end-to-end services by 

services provides that need ANWI services. 

4.3.7 System Attributes & 

Configuration 

documentation 



requirements 

Inclusion of system-to-systems matrix. 

This section identifies and documents the 

service elements and their attribute settings 

to establish the configuration baseline 

This section addresses the power, cooling 

and rack UPS requirements need to sustain 

the suite of devices and racks located in 

server rooms, and TER 

4.3.9 Remote Sites This section addresses the hardware 


the remote site capabilities. Also identifies 

the NS wireless solution that will be used by 

the ANWI’s limited and selected users 

4.4 EAPC Security 

Domain 


Operations 


requirements 













This subparagraph addresses how the ANWI 

EAPC design minimizes the variation of 

components and products in the overall 


set of well-defined common products that are





Section 

# 

Section Title 





of the EACP is bundled to meet the 

performance, reliability, availability, 



annex). Additionally, it addresses how the NS 

services are managed by the SMC to meet 

the SLAs. 

4.4.4.1 Network Services This section addresses the hardware 


the information assurance capabilities of the 

EAPC security domain. This section 

addresses the design scope and 

configuration of the EAPC portion of the 

ANWI. Its subsections will detail the various 

services provided on and via the NS. 

4.4.4.1.1 Wired This section identifies the switched design for 

this network 



LAN topology 



configuration/rack layout and defines how the 

processing requirement is to be satisfied 





component 







racks 


length(s) 



availability, reliability, scalability, flexibilityand 

performance requirements 

4.4.4.1.4 Infrastructure This section identifies how these services will



Section 

# 

Section Title 


be provided 





Services 

will be provided 




UCC capabilities and service 




the ANWI EAPC client capabilities 

 

 

 

 

 

 

 

 



Memory 

Connectivity to 




length(s) 



requirements 






provide information assurance requirements. 

It also explains the need and configuration for 

any security appliances. Finally identifies 

security risks and configurations needed for 

the services and networks to secure 

accreditation 







This section explains how the services are to 

be managed and monitored across the 




shall be captured, routed and displayed in the 

NOC to show that the service is meeting its 

SLA and how the information will be 

decomposed to show what part of the service 





Section 

# 

Section Title 


is causing the issue. The capture, 

measurement and monitoring of service 

metrics is key to this area 

4.4.5 Service Interfaces A Service Interface Profile (Annex K 

Appendix 17) will be developed that specifies 

the interface’s logical and physical 

characteristics and configuratin parameters 

for all service (internal and external) 

interfaces. 



how the ANWI contractor and outsourced 

service providers shall deliver and 

seamlessly integrate the deliverables into a 




services providers that need ANWI services. 


Configuration 

documentation 



requirements 

4.5 Business (NATO 

RESTRICTED and 

NATO 

UNCLASSIFIED) 

Security Domain 


Operations 


requirements 




This section identifies the elements and their 

attribute settings to establish the 

configuration baseline 


and UPS requirements need to sustain the 

suite of devices and racks located in server 

rooms, TER, user areas and printing areas 












ANWI’s Business design minimizes the 





Section 

# 

Section Title 


variation of components and products in the 

overall ANWI ICT infrastructure through the 

use of a set of well-defined common products 

that are standardized to the extent possible 

across the four networks. 


of the Business network is bundled to meet 

the performance, reliability, availability, 



annex). Additionally, it addresses how the 

supplementary services and associated HN 

Belgium services (ESS, BMS and AVI) are 

integrated to provide an overall coherent 

service via the Business network. Finally, it 

will address the SMC of Business services to 

meet their SLAs. 




capabilities of the Business network. This 

section also addresses the design scope and 

configuration of the Business portion of the 

ANWI. Its subsections will detail the various 

services provided on and via the Business 

network (wired and wireless). 

4.5.4.1.1 Wired & wireless This section identifies the switched design for 

this wired and wireless network 



 

 



LAN topology 

Design of the wireless network with 

its planning parameters for user 

distribution across and locations of 

Access Points 



configurations/rack layout and defines how 

the processing requirement is to be satisfied 




 

 


component 

Network connector specifications






# 






racks 


length(s) 






be provided on the Business and integrated 

with the wider NR WAN 


will be provided on the Business and how 

cross domain printing is to be addressed 


Communications 

&Collaboration (UCC) 

Services 




UCC capabilities and service 




the ANWI Business client capabilities (wired 

and wireless) 





Memory 

Connectivity to storage 




length(s) 



requirements 




provide information assurance requirements. 

It also explains the need and configuration for 

any security appliances. Finally identifies 




Section 

# 


Section Title 





accreditation 

Internal security to restrict access 

of critical data items to only those 

access types required by users 

Audit procedures to meet control, 

reporting, and retention period 

requirements for operational and 

management reports 

Application audit trails to 

dynamically audit retrieval access 

to designated critical data 










shall be captured, routed, monitored and 

displayed in the NOC to show that the 








for all service internal and external interfaces. 



how the ANWI contractor and subcontractors 

shall deliver and seamlessly integrate the 

ANWI deliverables and NATO PFE into a 






Configuration 

documentation 



service elements and their attribute settings 

to establish the configuration baseline 

4.5.8 Environmental This section addresses the power, cooling 





Section 

# 

Section Title 


requirements 

4.6 PUBLIC (Non- 

CLASSIFIED and 

NATO 

UNCLASSIFIED 

Releasable to the 

Internet) Security 

Domain 


Operations 


requirements 


















ANWI’s Public design minimizes the variation 

of components and products in the overall 


set of well-defined common products that are 



4.6.4 Service Delivery This section addresses how Public capability 

is bundled to meet the performance, 

reliability, availability, scalability, security, 

maintainability and serviceability of each 

required service (by annex). Additionally, it 

addresses how the Public services are 

managed by the SMC to meet the SLAs 




capabilities of the Public security domain. 

This section addresses the design and 

configuration of the network (wired and 

wireless) specifying protocols, evolution of 

the switching environment and failover/high 

availability configurations. 

4.6.4.1.1 Wired & wireless This section identifies the switched design for 

this network and how it supports the access 







Section 

# 

Section Title 


to Business network 

4.6.4.1.2 Processing This section defines how the processing 

requirement is to be satisfied and meet the 




component 







racks 


length(s) 






be provided on the Public security domain 


will be provided via the Public kiosks 

4.6.4.2 Client Services This section addresses the hardware and 


provide the Public kiosk capabilities. Also 

address the provisioning and monitoring of a 

user’s Internet access from a Bring Your Own 

Device (BYOD) concept. 







provide the Public network’s information 

assurance requirements. It also explains the 

need and configuration for any security 

appliances. Finally identifies security risks 

and configurations needed for the services 

and networks to secure accreditation. 







various networks into the NNHQ network



Section 

# 

Section Title 




shall be captured, routed, monitored and 

displayed in the NOC to show that the 











how the ANWI contractor, subcontractors and 

outsourced service (WCM) providers shall 

deliver and seamlessly integrate the 

deliverables into a coherent highly available 

network to provide the required end-to-end 

services as well as to support provision of 

end-to-end services by services providers 

that need ANWI services. 


Configuration 

documentation 



requirements 

4.7 Cross Domain 

Gateways / Module 


Operations 


requirements 



elements and their attribute settings to 

establish the configuration baseline 





This section addresses the various cross 

domain gateways / modules and how the 

various services use the modules’ 

capabilities to deliver the full scope of the 

service and how these services shall be 

managed and controlled to meet the SLAs. 

Additionally, this section shows how all the 

services integrate to deliver a coherent 






Section 

# 


Section Title 












set of products that are standardized 

to the extent possible across the four 

networks. 

Components that perform the same function 

across different locations, domains networks 

within ANWI shall be of same brand, model, 

capacity and feature. 

The Contractor shall clearly document the 

justification and the results of exceptional 

cases where use of same equipment is not 

possible. 

4.7.4 Service Delivery This section addresses how each CDGW as 

an integrated part of the CDM is bundled to 

meet the performance, reliability, availability, 


serviceability of each required CDGW 

4.7.4.1 CDGW1 This section addresses the hardware 


the information assurance capabilities 

required in the CDGW configuration. It 

addresses the design, protocols, 

management and configuration of the 

CDGW and its environment as part of the 

CDM to provide the information assurance 

requirements and failover/high availability 

configurations. Finally identifies security risks 


and networks to secure accreditation 






management and configuration of the CDM’s 

environment as part of the CDMto provide 

the information assurance requirements and 

failover/high availability configurations. 

Finally identifies security risks and 

configurations needed for the services and 

networks to secure accreditation 

4.7.4.3 CDGW3 This section addresses the hardware






# 




addresses the design, 

protocols,management and configuration of 

the CDMGW and its environment as part of 

the CDM to provide the information 

assurance requirements and failover/high 

availability configurations. Finally identifies 



accreditation 






management and configuration of the CDGW 

and its environment as part of the CDM to 





















required in the CGW configuration. It 











Section 

# 

Section Title 





This section explains how the operational 

status/metrics shall be captured, routed and 

displayed in the NNHQ and provided to the 

Mons’NOC thus showing that the service is 

meeting its SLA. It will also show how the 


part (if any) of the service is causing an issue 

to the SLA. 

4.7.5 CDM Integration As there are numerous networks and 


how the ANWI contractor and outsourced 

service providers shall deliver and 

seamlessly integrate the deliverables into a 

coherent highly available network meeting all 

security requirements to provide the required 

end-to-end services that traverse across 

multiple security domains as well as to 




Configuration 

documentation 

4.8 Integration Test 

Service (ITS) 


Operations 


requirements 









scope of the ITS service and how these 

services shall be managed and controlled to 

initially test the various SLAs. Additionally, 

this section shows how all the services will be 

provided to demonstrate and test the 

integrationof a coherent solution supporting 

the ANWI requirements. 



server rooms and TERs and cable runs 





set of products that are standardized 





Section 

# 

Section Title 


to the extent possible across the four 

networks. 

Components that perform the same function 

across different locations, domains networks 

within ANWI shall be of same brand, model, 

capacity and feature. 

The Contractor shall clearly document the 

justification and the results of exceptional 

cases where use of same equipment is not 

possible. 

4.8.4 Service Delivery This section addresses how the ITS will be 

able to assert that the environment will 

replicate the ANWInetworks in terms of all 

aspects of performance, reliability, 

availability, scalability, security, 

maintainability and serviceability of each 

required service to attest to the validity of the 

test environment. 



provide and test the information assurance 

capabilities of any two networks 

(concurrently). This section also addresses 

the design and configuration of the replicated 

networks (wired and/or wireless) replicating 

protocols, the switching environment and 

failover/high availability configurations to 

ensure a properly replicated network for 

testing. 




Services 



integration needed to provide and test the 

required UCC capabilities 

4.8.4.3 Client Services This section addresses the hardware and 


provide and test the full suite of client 

capabilities required in the ANWI 

4.8.4.4 Supplementary 

Services 


software needs of supplementary services 

and any contractual conditions for contractor 

provided appliances for testing a simulated 

ANWI security domain. 




# 











components used can be adjusted to support 

any security domain and cross domain 

module and how they combine to support the 

testing of the information assurance 

requirements. It also explains how the 

baselines will be maintained and managed to 

expedite testing and any security 

accreditation needs. 

This section addresses how the hardware 

definitions/specifications to provide the 

information assurance and SMC capabilities 

will be maintained and managed. 

Additionally, it explains how the operational 

status/metrics demonstrate and evaluatethe 

capture, routing and display of parameters to 

show that the tested service may suitably 

meet its SLA and how the information will 

assessed and offered to NCIA . 






4.8.6 Service Integration .As there are numerous networks and 


how the ANWI contractor will provide 

sufficient equipment to test the integration of 

the deliverables on a highly available ITS 

network 


Configuration 

documentation 



requirements 


Services 





and UPS requirements need to sustain the 

suite of devices (organic to the ITS and 

tested equipment) and racks located in the 

ITS 


software needs of supplementary services 

and any contractual conditions for contractor 

provided appliances. 

4.9.1 GSM This section will address the provisioning 

design of the GSM solution in the NNHQ as 

well as describes the selection of 

GSM/smartphone selection


# 

4.9.2 GSM & Wireless 

Blocking 

4.9.3 Site Security 







This section discusses the implementation 

and blocking solutions, as well as addresses 

the design, support and implementation of 

the 3 V/m rule. 

This sections provides the design, coverage 

area and implementation of the NNHQ’s Site 

Security Communications 

4.9.4 IPTV This section addresses the design of the 

IPTV solution and how the TV signal will be 

distributed to fixed TVs and broadcasted to 

and displayed on fixed and/or mobile user 

devices (per service catalogue ‘purchase’) 

irrespective of the user device footprint 

4.10 Migration This section addresses the migration of HQ 

to NNHQ servers and storage 

4.10.1 User E-Mail / 

calendar / contacts 

This section describes the process that will 

be used to ensure that a user’s HQ e- 

mail/calendar/contact data is migrated to the 

user’s ANWI e-mail account while 

maintaining access permissions and currency 

of data ensuring no data loss. 

4.10.2 User Share Data This section explains how a user’s Windows 

share data will be migrated to an ANWI 

Windows share while maintaining access 

permissions and currency of data ensuring 

no data loss. 

4.10.3 Voice and voicemail This section explains how a user’s telephone 

information (saved voice mail, speed dial and 

phone configuration/permissions) will be 

migrated to the ANWI UCC solution while 

maintaining currency of data ensuring no 

data loss. 

5 Risks 

5.1 Design Risks This section identifies the risks to the ANWI 

system 

5.2 Security Risk 

Assessment 

This section identifies the security risks to the 

ANWI’s system 

6 Administration & 

Support 

6.1 Warranty This section addresses the hardware and 

software warranty conditions and how the 

ANWI Contractor proposes to manage and 

support these conditions 

6.2 Training This section identifies the results of the 

Contractor’s training needs assessment of 

skills and provides a recommended number



Section 

# 

Section Title 


of staff needed to properly support and 

maintain each provided capability and service 

included in the ANWI design 

6.3 Documentation This section identifies & provides the 

supporting, installation and configuration 

documentation 

6.4 Drawings This sections shall hold the ‘to be’ drawings 

and later replaced by the ‘as built’ 

6.5 Requirements This section shall contain the requirements 

trace from the contractual specifications 

through the approved requirements review 

into the design document. The Contractor’s 

Requirements Traceability Matrix reflects this 

trace. 

6.6 Design standard This section shall define the selected 

international/NATO design standard that the 

Contractor will use for the ANWI design,as 

well as the adaptations to that standard that 

the Contractors will apply. 

6.7 Verification This section shall provide a verification matrix 

that defines how to verify all requirements, 

and which acceptance criteria to apply. 

Appendix 1 Server room design This appendix provides the layout of the 

server room detailing the network-rack 

distribution; room scaling; power and cooling 

needs; failover between server rooms and 

connectivity to the TER (communications and 

switching) 

Appendix 2 Traceability Matrix This appendix provides a table (or database) 

that traces the totality of the ANWI 

requirements to their associated service, 

hardware/software and supporting 

configuration 




19.3 Appendix 3: Project Management Plan (PMP) 



19.3.1-p1 The purpose of this plan is to documentthe project management 

structure and methodology of the Contractor. 

19.3.1-p2 The PMP shall also explain the organisation, relation and roles of the 

sub-contractors. 


19.3.2-p1 The ANWI Contractor shall establish and maintain a Project 

Management Plan (PMP) for the project. 

19.3.2-p2 The PMP shall cover all aspects of the project’s management including 

its project management structure and processes, personnel assignments, external 

relationships, and other necessary management aspects to provide the capability as 

required by the ANWI contract. 

19.3.2-p3 The PMP shall identify all major ANWI Contractor operating units and 

any Sub-Contractors/partners involved in the delivery of the ANWI including a 

description and quantification (%) of the portion of the overall effort or deliverable 

item for which each is responsible. 

19.3.2-p4 The PMP shall contain an organisational chart showing the members of 

the ANWI Contractor’s Project Team (including the members of the PMO) and 

showing their respective responsibilities and Authority. 

19.3.2-p5 The PMP shall be detailed to ensure that the Purchaser is able to 

assess the ANWI Contractor’s plans, capabilities, and ability to manage the entire 

project and implement it in conformance with the requirements as specified in this 

SOW. 

19.3.2-p6 The initial version of the PMP shall be provided to the Purchaser for 

acceptance. 

19.3.2-p7 After Purchaser Acceptance, the PMP shall be placed under the 

Contractors Configuration Control and any changes to the PMP shall be brought 

forward to the Purchaser PM for acceptance. 

19.3.2-p8 The acceptance of the PMP by the Purchaser signifies only that the 

Purchaser agrees to the ANWI Contractor’s approach in meeting the requirements. 

This acceptance in no way relieves the ANWI Contractor from its responsibilities to 

meet the requirements stated in this Contract. 

19.3.2-p9 The ANWI Contractor shall ensure that the PMP remains current 

throughout the duration of the Project through monthly updates to reflect the actual 

state of the ANWI Contractor's organisation and efforts. 



Annex K Appendix 1for the PMP. 







19.3.3-p2 The ANWI Contractor shall deliver the PMP in accordance with the 

Schedule of Supplies and Services. 

19.3.3-p3 The ANWI Contractor shall update the PMP after each meeting and 

adjust the document throughout the project to FOC. 


19.3.4-p1 

Section 

# 

The PMP shall be structured according to the format below: 

Section Title 



Provides the managerial approach for the 

project and how the project will be managed. 

1 Introduction This section provides a high level overview of 

the project management and how the 

contractor will manage the project 

1.1 Purpose and Scope State the scope of the project and how . 

1.2 Document 

Organization 


project management plan 


points of contact for the project 





2 Project Team This section identifies the 

contractors/partners that comprise the ANWI 

contractor team 

2.1 Project Management 

Structure 

This section identifies the relationship among 

the various ANWI contractors and provides a 

diagram of the organisational structure of the 

team 

2.2 Prime Contractor This section identifies the scope of the main 

contractor and defines the roles and 

responsibilities of key staff provided by the 

contractor 

2.3 Consortium Partner This section identifies the scope of the 

consortium partner(s) and defines the roles 

and responsibilities of key staff provided by 

the contractor 

2.4 Sub-contractors This section identifies the scope of the subcontractors 

and defines the roles and 

responsibilities of key staff provided by the 

sub-contractor 

3 Management 

Processes 

This section defines the main project 

management processes, procedures and 

templates that will be used during the ANWI 

project.



3.1 Change Management This section describes the contractor’s 

change control process that will be used in 

managing the project; as well as identify the 

approval process for changes; who and how 

they are submitted; and how they will be 

tracked and monitored 

3.2 Communications 

Management 

This section defines the communication 

requirements for the project and how 

information flows and will be distributed. 

Communications management provides the 

following in a RACI matrix: 

Communication requirements by roles 

What information is to be 

communicated 

How the information is communicated 

When will information be distributed 

Who is responsible for the 

communication 

Who receives the communication 

3.3 Scope Management This section identifies how the ANWI 

Contractor will define, track and manage the 

and then how the ANWI Contractor will 

measure and verify the scope (i.e. Quality 

Checklists, Scope Baseline, Work 

Performance Measurements, etc.) 

3.4 Relationship to other 

plans 

4 Project Management 

Activities and Controls 

This section address how the other project 

related plans (PIP, RMP, CMP, etc) are 

managed, reviewed and updated. 

This section identifies the management tasks 

that are to be fulfilled as part of the ANWI 

project and how they will be controlled. 

4.1 Project Key Dates This section provides a discussion of how the 

PIP’s key project dates are identified and will 

be controlled. 

4.2 Project Control & 

Corrective Actions 

4.2.1 Managerial Reporting 

Activities 

4.2.2 Integration Testing 

Service (ITS) 

This section identifies how the ANWI 

Contractor will manage and control the 

project and support the integration of NATO 

PFE 

This section identifies the ANWI Contractor’s 

reporting procedures for status reports from 

his sub-contractors and how they will be 

validated. 

This section identifies how the ANWI 

Contractor is going to manage and control the 

ITS to ensure synchronisation of test activities 

with all dependent project parties (ESS, BMS, 

AVI, VTC, NEDS, NPKI, etc.) 



4.2.3 Project Progress 

Review Meeting 

(PPRM) 



This section explains how the contractor will 

use the PPRM to provide information, raise 

issues/concerns and report progress. 

4.2.4 Design Reviews This section explains how the ANWI 

Contractor will use the design process and 

design reviews to manage the implemented 

solution to ensure that the ANWI does 

support innovation, delivery of current 

technology and is properly integrated with 

NATO PFE and SMC. 

4.2.5 Contractor Meetings This section outlines how the ANWI 

Contractor plans to work with the other 

dependent projects to ensure that the ANWI 

can interface with the provided services 

4.2.6 Problem Reporting & 

Monitoring 

This section identifies how the Contractor will 

identify, report and manage ANWI problems 

that require the Purchaser’s support 

Annex A ANWI Project Team This annex contains the Curriculum Vitae of 

the project’s key personnel 

A.1 ANWI Project Manager 

(PM) 

Contains the CV of the Purchaser approved 

ANWI PM 

A.2 ANWI Technical Lead 

(TL) 


ANWI TL 

A.3 ANWI Test Director 

(TD) 


ANWI TD 

A.4 Additional This section identifies other personnel 

needed, outlining a description of their 

functions, duties and responsibilities as well 

as how they will be used in the project. This 

list can include but is not limited to: 

 

 

 

 

Quality Assurance Manager 

Site Implementation and Support 

Manager(s) 

Trainer(s) 

Test Expert 




19.4 Appendix 4: Project Implementation Plan (PIP) 



19.4.1-p1 The purpose of the Project Implementation Plan (PIP) is to document 

the plan for the implementation of the ANWI. 

19.4.1-p2 The primary focus of the PIP is the project schedule which not only 

dictates the timeline of ANWI activities/deliverables but also identifies the necessary 

sequencing for coordination of dependent ANWI activities. 


19.4.2-p1 

The PIP shall explain the project’s scope, objectives and deliverables. 

19.4.2-p2 The ANWI Contractor shall provide and maintain a PIP consisting of an 

implementation plan, schedule, and work breakdown structure (WBS). 

19.4.2-p3 The ANWI Contractor shall structure the PIP so that general 

implementation information is maintained in the body of the plan and site-specific 

details (e.g. site installation and activation checklists) are kept as annexes. 

19.4.2-p4 Project Schedule 

A. The ANWI Contractor shall identify key dates and milestones in the project 

schedule. 

B. The ANWI Contractor’s project schedule shall include and reflect the 

dependencies of the NNHQ Programme’s key programme milestones as 

identified in this IFB’s Annex A. 

C. The ANWI Contractor’s project schedule shall depict the sequence, 

duration, and interdependencies among the project’s work breakdown 

structure’s work packages to include internal QA events. 

D. The ANWI Contractor’s project schedule shall include activity network, 

activity Gantt, milestone, and critical path views of the project schedule. 

19.4.2-p5 Work Breakdown Structure. 

A. The ANWI Contractor shall establish and maintain a Project Work 

Breakdown Structure (PWBS) as it is the primary framework for Contract 

planning and reporting to the Purchaser. 

B. The ANWI Contractor shall use the latest commercial version of the MS 

Project to create the work breakdown schedule (WBS) and shall use that 

version of MS Project throughout the life of the ANWI project. 

C. The WBS shall define the ANWI tasks needed to guarantee the successful 

management, delivery and acceptance of the ANWI: design, site survey, 

testing, delivery, installation, training, capability, service and site 

activation, system acceptance, and support as well as management 

products (e.g. project plans, Project Status Reports, Purchaser reviews, 

provision of specific Purchaser-furnished items), including at least the 

initial version and the final one. 

D. The WBS shall identify the start and finish dates, duration, predecessors, 

successors, and resource requirements for each task. 







E. The WBS shall decompose all ANWI tasks to a level that exposes all 

project risk factors and allows accurate estimation of each task’s duration, 

resource requirements, inputs and outputs, and predecessors and 

successors. 

F. The WBS shall be traceable to performance and delivery requirements of 

the Schedule of Supplies and Services. 

G. The ANWI Contractor shall not change the WBS without the approval of 

the Purchaser. 

H. The WBS shall be provided to the Purchaser for acceptance and any 

changes to the PWBS are required to be approved by the Purchaser’s PM 

for acceptance. 

19.4.2-p6 The site survey(s) and installation sequence and dates reflected in the 

PIP shall be co-ordinated by the ANWI Contractor with the Purchaser and the Site 

Point of Contacts (POC) to accommodate site-specific requirements, exercises, 

holiday periods, and other considerations. 

19.4.2-p7 The ANWI Contractor shall update and maintain the PIP to reflect the 

findings and results of the Site Survey activities and in relation with the progress of 

installation and activation activities. 

19.4.2-p8 The ANWI implementation and migration activities may generate 

outages at NATO HQ and/or the NNHQ site during the period between IOC and 

FOC. 

19.4.2-p9 The ANWI Contractor shall ensure that any NATO HQ and/or 

NNHQoutages be kept short (less than 3 hours in duration), planned (approved by 

the Purchaser at least 48 hours in advance based on an ANWI Contractor-provided 

back-out plan to restore functionality within 30 minutes), and localised (limited to 

areas agreed to by the Purchaser). 

19.4.3 Reporting & Provisioning 


Annex K Appendix 1for the PIP. 

19.4.3-p2 The ANWI Contractor shall deliver the PIP in accordance with the 


19.4.3-p3 The PIP shall be placed under Configuration Control and provided to 

the Purchaser for acceptance. 

19.4.3-p4 The acceptance of the Product Baseline by the Purchaser signifies only 

that the Purchaser agrees to the ANWI Contractor's approach in meeting the 

requirements. This acceptance in no way relieves the ANWI Contractor from its 

responsibilities to meet the requirements stated in this Contract. 

19.4.3-p5 

The ANWI Contractor shall review the PIP prior to each project meeting. 

19.4.3-p6 The ANWI Contractor shall report the project’s schedule status and 

suggest/request any changes, as needed, for Purchaser consideration at project 

meetings. 

19.4.3-p7 

decision. 

The ANWI Contractor shall adjust the PIP based on the Purchaser’s



19.4.3-p8 The PIP is a ‘living document’ that the ANWI Contractor shall maintain 

(update and adjust the document, as required) from Effective Date of Contract (ED) 

through Final Operating Capability (FOC). 


19.4.4-p1 

Section 

# 

The PIP shall be structured according to the format below: 

Section Title 



Provides a managerial description of how the 

project will be implemented. 

1 Introduction This section explains the purpose and overall 

objective of the PIP and identifys the major 

activities to be undertaken in the ANWI 

project. 

1.1 Purpose and Scope State the purpose of the PIP and explicitly 

state that this is a living document and that it 

is to be updated as the project evolves. 

1.2 Document 

Organization 


PIP. 


points of contact for the production, analysis 

and assertions made in the PIP 





2 Assumptions and 

Constraints 

This section describes the assumptions and 

constraintsconcerning the development and 

execution of the implementation plan 


o Schedule 

o Hardware 

o Software and other technology to 

be reused or purchased, 

o Interfaces constraints 

3 Implementation Plan This section provides the framework for the 

approach taken to create the project 

schedule. 

3.1 Major Tasks This section describes the major ANWI 

(generic or overall) project tasks required to 

deliver both the ITS as well as the ANWI 

(hardware, software, migration, and validate 

the ANWI services and system). This 

ultimately concludes with the construction of a 

complete Work Breakdown Structure. 



3.2 Implementation 

Schedule 





This subsection of the Project Implementation 

Plan provides a schedule of activities to be 

accomplished. Show the required tasks 

(described in Subsection 3.1, Major Tasks) in 

chronological order, with the beginning and 

end dates of each task. If MS Project is used 

to plan the implementation, include the 

project Gantt chart. Include any milestones 

from the projects that are dependent on this 

project and vice-versa 

This includes the scheduling tool/format, 

schedule milestones, and schedule 

development roles and responsibilities. 

3.3 Project Milestone List This section provides a discussion of the 

milestones and a summary list of project 

milestones and their associated dates. 

3.4 Security This section provides an overview and 

discussion of the security aspects related to 

the ANWI implementation concerning 

security: 

o 

o 

o 

o 

o 

o 

o 

Personnel clearances 

Screening of equipment 

Storage of equipment 

Movement and transportation 

Security testing & evaluation 

Documentation and review 

Migration of ANWI core data from 

the existing HQ 

3.5 Design This section shall address the tasks needed 

to produce the ITS and ANWI designs and 

supporting reviews. 

4 Implementation This section describes the site-specific 

implementation requirements and 

procedures. 

4.1 NNHQ Campus This section defines the requirements that 

must be satisfied for the orderly 

implementation of the ANWI services and 

system for the main campus 

4.1.1 NATO SECRET This section addresses the implementation 

specifics of the NS including an overview 

description of the implementation: team, 

schedule, procedures, and data. 

4.1.2 EAPC This section addresses the implementation 

specifics for the EAPC including an overview 



4.1.3 Business This section addresses the implementation 

specifics for the Business including an





overview description of the implementation: 

team, schedule, procedures, and data. 

4.1.4 Public This section addresses the implementation 

specifics for the Public including an overview 



4.2 Cross Domain 

Gateways 

This section addresses the implementation 

specifics for the cross domain gateways 

including an overview description of the 

implementation: team, schedule, procedures, 

and data. 

4.3 Remote Sites This section addresses the specifics of the 

implementation for the remote sites including 

an overview description of the 

implementation: team, schedule, procedures, 

and data. 

4.4 Risk and Contingency 

Planning 

This section identifies the risks and actions to 

take in the event the implementation fails or 

needs to be altered at any point and includes 

the factors to be used for making the decision 

(refer to the Risk Management Plan as 

needed) 

4.5 Acceptance Criteria This subsection of the Project Implementation 

Plan establishes the exit or acceptance 

criteria for transitioning the system into 

production. Identify the criteria that will be 

used to determine the acceptability of the 

deliverables as well as any required technical 

processes, methods, tools, and/ or 

performance benchmarks required for product 

acceptance 

5 Implementation 

Support 

This section describes the general support 

required for the implementation. 

5.1 Hardware This section provides a list of all hardware 

needed for installing and testing the ANWI 

services. Identify the hardware by make, 

model and configuration; also add information 

about warranty/maintenance contract(s). If 

this information is provided in another 

document identify that item here and 

reference appropriately otherwise add as an 

Annex to this document. 

5.2 Software This section provides a list of all software 

(software, operating systems, utilities, etc and 

identify the software as COTS, custom 

developed or legacy) required to 

implementation the ANWI. Identify the



software by name/acronym, version & release 

numbers, and configuration settings; as well 

as add information about vendor support, 

licensing, usage, and maintenance contract 

and associated costs. If this information is 

provided in another document identify that 

item here and reference appropriately 

otherwise add as an Annex to this document. 

5.3 Facilities This section identifies the physical facilities 

(space), accommodations, location(s) and 

time (hours per day needed, number of days, 

and anticipated dates) required to support the 

storing, staging, implementing and support of 

the ANWI. 

5.4 Issues This section addresses any known issues or 

problems with respect to implementation 

planning. 

5.5 Performance 

Monitoring 

5.6 Configuration 

Management Interface 

This section describes how the ANWI 

Contractor will monitor the performance and 

determine if the implementation’s progress 

This section addresses the relationship 

between implementation and Configuration 

Management (e.g. when versions will be 

distributed) 

6 Implementation Impact This section describes how the migration is 

expected to impact the ANWI’s 

implementation for the HQ with respect to 

Annex A 

ANWI Project Gantt 

Chart 

o 

o 

o 

o 

Network / infrastructure 

User community 

Impact to the ITS. 

Service Level Agreements 

requirements (performance, 

availability, security) 

o System backups, expected 

transaction rates 

o Storage requirements (with 

expected growth rate) 

o Help desk support requirements 

This annex provides the MS Project portion of 

the PIP 




19.5 Appendix 5: Risk Management Plan (RMP) 

19.5.1 Introduction/purpose 


19.5.1-p1 The purpose of this plan is to document the policies and procedures 

that will be used for identifying and handling project risks. 

19.5.1-p2 Risk must be considered as those items that will possibility result in a 

negative impact on the project, be it decreased quality, increased cost, delays, or 

failure. 

19.5.2 Scope/assumptions 

19.5.2-p1 The ANWI Contractor shall establish and maintain an overall Risk 

Management Plan (RMP) and risk process for the project. 

19.5.2-p2 The ANWI Contractor’s RMP shall establish and maintain a Risk Log for 

the project which is available on the ANWI project website. 

19.5.2-p3 The ANWI Contractor shall ensure that risks are identified early, 

assessed accurately, and quickly mitigated with the Purchaser. 

19.5.2-p4 The ANWI Contractor shall identify any management, technical, 

schedule, and cost risks, evaluate each risk, and select a proposed response for 

each risk mentioned in the Risk Log. 

19.5.2-p5 

impact. 

Each risk shall be rated based on its probability of occurrence and 

19.5.2-p6 The ANWI Contractor shall propose an appropriate response for each 

risk from the following list: 

A. Prevention: Terminate the risk – by doing things differently and thus 

removing the risk, where it is feasible to do so. Countermeasures are put 

in place that either stop the threat or problem from occurring or prevent it 

from having any impact on the project or business. 

B. Reduction: Treat the risk – take action to control it in some way where the 

action either reduce the likelihood of the risk developing or limit the impact 

on the project to acceptable levels. 

C. Acceptance: Tolerate the risk – e.g. if nothing can be done at a reasonable 

cost to mitigate it or the likelihood and impact of the risk occurring are at 

an acceptable level. 

D. Contingency: plan and organise actions to come into force as and when 

the risk occurs. 

E. Transference: Pass the management of the risk to a third party (e.g. 

insurance policy or penalty clause), such that the impact of the risk is no 

longer an issue for the health of the project. 

19.5.2-p7 The ANWI Contractor shall include in the Project Status Report a chart 

that lists all active risks rated high on any factor and note any significant forecasted 

changes in these risks. 

19.5.2-p8 The ANWI Contractor shall update and brief the Risk Log at every 

Project Progress Review Meeting and Design Review Meeting. 







Annex K Appendix 1for the RMP. 

19.5.3-p2 The ANWI Contractor shall deliver the RMP in accordance with the 


19.5.3-p3 The ANWI Contractor shall update the RMP after each meeting and 

adjust the document throughout the project to FOC. 


19.5.4-p1 

Section 

# 

The RMP shall be structured according to the format below: 

Section Title 




project’srisk management concept and how 

risks will be addressed throughout the 

project. 

1 Introduction 

1.1. Purpose This section identifies and explains the 

purpose of the risk management plan. 

1.2 Intended Audience Describes the intended audience of the plan, 

including the sub-contractor team. 





2 Risk Management 

Approach 

This section identifies the overall risk 

management approach and should follow the 

standard risk management approach of: 

analyse, plan monitor and controlidentification 

2.1 Risk Identification This section will explain how the sources of 

risk, possible risk events and risk symptoms 

will be determined (details and specifics are 

addressed later in the document). 

2.2 Risk Analysis This section explains how the following will be 

determined: the value of opportunities to 

pursue vs. the threats to avoid and the 

opportunities to ignore vs. the threats to 

accept (details and specifics are addressed 

later in the document). 

2.3 Response Planning This section explains the response planning 

process and its relationship between risk 

management and contingency plans (details 

and specifics are addressed later in the 

document). 




# 

2.4 Risk Monitoring and 

Control per milestone 

3 Roles and 

Responsibilities 






This section explains the risk monitoring and 

control process and how corrective action 

plans are developed, implemented, and 

monitored (details and specifics are 

addressed later in the document). 

For each project role, this section will 

describe the responsibilities with respect to 

risk; additional roles can be added. 

3.1 Project Manager The section formalises that the project 

manager is responsible for approval of the 

risk management plan (this document), leads 

and participates in the risk management 

process, and takes ownership of risk 

mitigation/contingency planning and 

execution, ultimately making the project 

manager responsible for the decisions on risk 

actions, in coordination with the project 

sponsors. 

3.2. Project Team The section explains how the project team 

members (analysts/product managers, 

designers, developers, testers, and 

deployment team members) will participate in 

the risk identification, monitoring and 

mitigation process/activities. 

3.3. Quality Assurance 

Lead 

This section addresses how the quality 

assurance (QA) lead will be involved in 

ensuring that identified risks are being 

managed per the risk management plan and 

his/herinvolvement in identifying new risks 

and/or proposing mitigation strategies and 

contingency plans, along with proposing 

improvements to the risk management plan 

and processes. 

3.4. Project Sponsors Project sponsors participate in risk 

identification and risk activities, as necessary. 

Project sponsors also receive escalated risks 

and assist with mitigation and contingency 

actions for escalated risks 

3.5. Project Stakeholders Stakeholders assist in monitoring risk action 

effectiveness and participate in risk 

escalation, as necessary. 

4. Risk Identification 

4.1 Sources This section provides the detailed description 

of how risk identification will be done 

throughout the project’slife-cycle even though 

the majority of the risks should be identified

Section 

# 

Section Title 




early on in the project. The following may be 

considered as tools and techniques for risk 

identification: 

Analysis of high-level deliverables 

 

 

 

 

 

 

 

 

Analysis of the PIP 

Analysis of change requests 

Analysis of project assumptions 

Project team input 

Lessons learned 

QA audits and reviews 

Performance and status reports 

Diagramming techniques 

4.2 Risk Register This section identifies and documents the 

selection logic for the risk sources, events 

and symptoms and collects the risks’ 

informationand builds/establishes the 

principle and need for the risk register 

(maintain as a separate document) where the 

following information should be noted: 

Risk category 

 

 

 

 

 

Risk trigger 

Potential outcome 

Raised By 

Date Raised 

Source 

4.2.1 Taxonomy of the 

Identified Risks 

This should be explained here and provided 

in RMP Appendix A 

4.2.2 Operational Risks This section identifies the list of operational 

risks 

4.2.3 Support Risks This section identifies the list of support 

related risks 

4.2.4 External Risks This section identifies the list of dependency 

and external (project) risks 

5. Risk 

Analysis/Assessment 

5.1. Background This section describes the summary of the 

Risk Management Process against the 

following criteria: 



Section 

# 

Section Title 


 

 

 

 

 

 

 





Methods of Risk Assessment 

Probability estimationof the risk 

occurrence 

Impact estimationof the risk, if it 

occurs 

Cost estimation 

Schedule estimation 

External risks 

Risk Ranking for the phases of the of 

the project: design, 

implementation,operations, and 

support 

5.1.1. Qualitative Analysis This section describes the qualitative analysis 

process used to determine: 

The likelihood of the risk occurring 

 

 

The qualitative impact on the project 

The quality of the risk data being 

utilized 

5.1.2. Quantitative Analysis If quantitative analysis is to be used, this 

section should contain information on: 

The criteria for which risks will 

undergo quantitative analysis 

 

 

Technique(s) to be utilized 

o The impact to cost or schedule 

for risks 

o The probability of meeting 

project cost and/or schedule 

targets 

o Realistic project targets on cost, 

schedule, and/or scope 

Expected outputs of analysis 

5.2. Documentation The results of risk analysis should be 

documented in the risk register. The 

following information shall be entered in the 

register: 

Risk impact 

 

 

Risk probability 

Risk matrix score – computed by the

Section 

# 

Section Title 


 

 





risk register spreadsheet after impact 

and probability are entered 

Risk priority – computed by the risk 

register spreadsheet after impact and 

probability are entered 

Qualitative impact – descriptive 

comments about the potential risk 

impact 

6. Response Planning 

6.1. Background This section describes the risk strategy and 

planning processto minimize the effects of the 

risk and how it will be controlled and 

managed. 

Risk Handling Process 

 

 

Evaluation and Selection of options 

Tracking of the process 

6.2. Risk Strategies This section describes the methods for 

responding to risks and defines the various 

terms. 

6.2.1. Avoid 

6.2.2. Transfer 

6.2.3. Mitigate 

6.2.4. Accept 

6.3. Documentation This paragraph addresses the risk register 

showing: 

Issues 

 

 

 

Response strategy (avoid, transfer, 

mitigate, or accept) 

Response notes 

Risk owner 

7. Risk Monitoring and 

Control 

7.1. Background This section identifies the monitoring and 

control of the risk environment and describes 

the following tasks are performed: 

Identification and planning for new 

risks 

 

 

Tracking of identified risks and their 

trigger conditions 

Periodicallyreview risk and issue

Section 

# 

Section Title 


 

 



status/review as part of project 

performance information 

Re-analyze existing risks to see if the 

response plan must change 

Review the effectiveness of the RMP 

7.2. Timing This section discusses how often the risk 

monitoring and control process will occur over 

the lifetime of the project. 

7.3. Documentation This section identifies the updating of the risk 

register with information based on the status 

of the risk item: 

Identified – Risk documented, but 

analysis not performed 

 

 

 

 

 

 

 

Analysis Complete – Risk analysis 

done, but response planning not 

performed 

Planning Complete – Response 

planning complete 

Triggered – Risk trigger has occurred 

and threat has been realized 

Resolved – Realized risk has been 

contained 

Retired – Identified risk no longer 

requires active monitoring (e.g. risk 

trigger has passed) 

Trigger Date – if the risk has been 

triggered 

Comments/notes 

8. Appendix A: 

Definitions 

8.1. Risk Categories The following diagram offers pre-defined risk 

categories for consideration. Risk categories 

should be used to support the identification of 

risks. 





Table 1 – Risk Categories 

8.2. Risk Probability Definitions The contractor should use a table like 

this to identify the risk probability 

definitions. 

Probability 

Probability Description 

Category 

Very High 0.90 Risk event is expected to occur 

High 0.70 Risk event is likely to occur 

Medium 0.50 Risk event may or may not occur 

Low 0.30 Risk event is not likely to occur 

Very Low 0.10 Risk event is not expected to occur 

Table 2 – Risk Probability Definitions 

8.3. Risk Impact Definitions The following chart should be used to 

show risk impact definitions across 

each of the potentially impacted 

project areas (cost, schedule, scope, 

and quality). During the risk analysis 

the potential impact of each risk is 

analyzed and an appropriate impact 

level (0.05, 0.10. 0.20, 0.40, or 0.80) 

is selected from the chart below 





Project 

Objective 

Cost 

Schedule 

Scope 

Quality 

Very Low 

0.10 

Insignifican 

t cost 

impact 

Insignifican 

t schedule 

impact 

Barely 

noticeable 

Barely 

noticeable 

Low 

0.30 

< 10% cost 

impact 

< 5% 

schedule 

impact 

Minor 

areas 

impacted 

Only very 

demanding 

application 

s impacted 

Moderate 

0.50 

10-30% 

cost impact 

5-10% 

schedule 

impact 

Major 

areas 

impacted 

Sponsor 

must 

approve 

quality 

reduction 

High 

0.80 

30-50% 

cost impact 

10-20% 

schedule 

impact 

Changes 

unacceptab 

le to 

sponsor 

Quality 

reduction 

unacceptab 

le to 

sponsor 

Table 3 – Definition of Risk Impact Scales 

Very High 

0.90 

> 50% cost 

impact 

> 20% 

schedule 

impact 

Product 

becomes 

effectively 

useless 

Product 

becomes 

effectively 

useless 

8.4. Risk Probability and Impact 

Matrix 

The risk probability and impact matrix 

should be used to show the 

combination of risk impact and 

probability and should be used to 

decide the relative priority of risks. 

Risks falling into the red-shaded cells 

are the high priority and those that fall 

into the yellow-shaded cells are the 

next highest priority, followed by risks 

that fall into the green-shaded cells. 

Probabilit Impact 

y 

0.10 0.30 0.50 0.70 0.90 

0.90 0.09 0.27 0.45 0.63 0.81 

0.70 0.07 0.21 0.35 0.49 049 

0.50 0.05 0.15 0.25 0.21 0.45 

0.30 0.03 0.09 0.15 0.21 0.27 

0.10 0.01 0.03 0.05 0.07 0.09 

Table 4 – Risk Probability and Impact Matrix 




19.6 APPENDIX 6: Quality Assurance Plan (QAP) 



19.6.1-p1 The purpose of the Quality Assurance Plan (QAP) is to identify the 

planned and systematic activities to be implemented in in the ANWI project so that 

the quality requirements for the services will be fulfilled. 

19.6.1-p2 Essential discussions in the QAP are the determination of a service’s “fit 

for purpose" and how the ANWI Contractor will implement controls, processes, and 

inspections to catch and eliminate mistakes. 


19.6.2-p1 The ANWI Contractor shall establish, execute, document and maintain 

an effective Quality Assurance (QA) programme throughout the Contract’s lifetime 

(see references 1.1.1.1.1 – 1.1.1.1.3). 

19.6.2-p2 The ANWI Contractor‘s QA effort shall meet the requirements of the 

QAP for installation and integration activities. 

19.6.2-p3 The ANWI Contractor‘s QA effort shall apply to all services and all 

products (both management products and specialist products) to be provided by the 

ANWI Contractor under this contract (this includes all hardware and software – 

COTS as well as developed for this project – documentation and supplies that are 

designed, developed, acquired, maintained or used, including deliverable and nondeliverable 

items). 

19.6.2-p4 The ANWI Contractor ‘s QA effort shall ensure that procedures are 

developed, implemented and maintained to adequately control the design, 

development, production, purchasing, installation, inspection, testing, configuration 

management and customer support of all services and all products (both 

management products and specialist products), in accordance with the requirements 

of this Contract. 

19.6.2-p5 The ANWI Contractor‘s QA effort shall be described in detail in the 

Quality Assurance Plan (QAP). 

19.6.2-p6 The QAP shall clearly indicate the QA activities, responsibilities, and 

checks for the Contractor and any sub-contractors. 


19.6.3-p1 The initial version of the QAP shall be configuration controlled and 

provided to the Purchaser for acceptance. 

19.6.3-p2 The acceptance of the QAP by the Purchaser signifies only that the 

Purchaser agrees to the ANWI Contractor’s approach in meeting the requirements. 

This acceptance in no way relieves the Contractor from its responsibilities to meet 

the requirements stated in this Contract. 

19.6.3-p3 The ANWI Contractor shall review his QA programme periodically and 

audit it for adequacy, compliance and effectiveness. 





19.6.3-p4 If the Purchaser detects that the ANWI Contractor does not respect the 

QA programme as described in the QAP, the Purchaser has the right to suspend the 

Contractor’s activities without any compensation for the Contractor. 

19.6.3-p5 Purchaser Quality Assurance Representative 

A. The Purchaser has the right under STANAG 4107 to delegate some of the 

Quality Assurance Representative (QAR) responsibilities to a National 

Quality Assurance Representative (NQAR) and the Purchaser will employ 

an Independent Verification & Validation (IV&V) Contractor to fulfil a 

portion of this role. 

B. The ANWI Contractor shall agree to provide all necessary assistance to 

the NATO QAR or his delegated NQAR. 

19.6.3-p6 The ANWI Contractor shall make his quality records, and those of his 

subcontractors, available for evaluation by the QAR/NQAR throughout the duration of 

the Contract. Note: quality audits at the ANWI Contractor or subcontractors premises 

will in principle only be executed by the QAR/NQAR if the quality records provided by 

the ANWI Contractor do not provide sufficient evidence that an effective and 

economical QA system is operational is available. 

19.6.3-p7 The QAR will use AQAP-160 (see reference 1.1.1.1.3) and ISO/IEC 

9126 as guides for QA reviews of software and software based customisation that 

have to be developed under this Contract. 


Annex K Appendix 1for the QAP. 

19.6.3-p9 The Contractor shall deliver the QAP in accordance with the Schedule 

of Supplies and Services. 

19.6.3-p10 The ANWI Contractor shall update the document, as required, from 

the delivery date of the initial QAP through Final Operating Capability (FOC). 


19.6.4-p1 The ANWI Contractor shall produce the ANWI design in accordance 

with the ‘document structure’ section defined below. 

Section 

# 

Section Title 




project’s quality management will be 

implemented. 


objective of the PIP identifying the major 

activities to be undertaken in the ANWI 

project. 

1.1 Purpose and Scope State the purpose of the QAP and explicitly 



1.2 Document 

Organization 


QAP. 








points of contact for the quality assurance 

activities 





2 General This section explains how the ANWI 

Contractor will ensure necessary resources 

(manpower, facilities, training, equipment 

etc.) needed for carrying out the required 

activities are provided. The QAP should 

address the relationship between the QAP 

and the Risk Management Plan specifying: 

risk analysis, risk mitigation activities, and the 

methods of risk management. 

2.1 Organization and 


2.2 Quality Management 

System Activities 

2.2.1 Processes (General 

requirements) 

2.2.2 Documentation 

requirements 

3 Product Realization 

Activities 

3.1 Planning of product 

realization 

This section describes how the quality 

requirements for management review will be 

fulfilled. It will clearly state how requirements 

related to management commitment, 

customer focus and quality policy are met 

This section describes how the requirements 

are flowed down to where the work is being 

performed (e.g. through work instructions, 

computerized production management 

system, work orders etc.) and focuses on how 

the performance of work is expected to be 

continuously measured and reported to the 

ANWI Contractor’s management. 

This section describes the quality metrics that 

will be used for monitoring the effectiveness 

of the ANWI’s Quality Management 

performance under the QAP. It also provides 

an audit plan that covers contract specific 

processes and activities, including those at 

sub-suppliers. 

This section describes how the QAP is 

expected to be maintained and controlled 

during the contract period as well as how the 

required and/or involved plans, documents, 

procedures etc will be controlled and how 

project records will be established, 

maintained, and stored. 

This section describes how product 

conformance to contract requirements will be 

provided (e.g. processes needed,

3.2 Customer related 

processes 

3.3 Design and 

development 

3.4 Control of subsuppliers 

3.5 4.7.5 Production and 

service provisioning 




requirements for the product, criteria for 

product acceptance and the method of 

inspection, verification, validation etc). 

Additionally, the relevant quality activities for 

delivery, installation and placing into 

operational order (commissioning) form part 

of this section 

This section explains that the ANWI 

Contractor understands that the Purchaser’s 

IV&V will serve as NATO’s QAR and how the 

ANWI Contractor will interface with the NATO 

IV&V 

This section describes how quality assurance 

will be applied and recorded with respect to 

the design and development of the ANWI’s 

service requirements; as well as how the 

design and development outputs are 

provided, verified, and approved. 

This section also describes the processes 

and plans for performing systematic design, 

development review, test methods and 

verification and validation in order to ensure 

that the services meet the requirements and 

how changes are to be controlled forming 

part of the requirement. 


Contractor will control the service delivery & 

implementation information and how 

requirements are flowed down to subsuppliers, 

and how verification that the 

services meet the requirements are to be 

carried out. This also must include a 

review/audit plan for the inspection of 

incoming products and/or services 

This section describes the requirements 

explaining how validation of processes for 

production and service provisioning will be 

carried out to demonstrate their ability to 

achieve planned results. Procedures for 

identification of the product should be 

included. If product traceability is required, 

procedures for control and record of the 

unique identity of the product should be 

defined. The procedures of exercising care 

with customer property should be 

documented. The methods used to preserve 

the conformity of the product should be 

described. Contract specific requirements for 

storage, preservation and handling should be 


3.6 Control of monitoring 

and measuring devices 


management 

3.8 Reliability and 

Maintainability 

4 Measurement, 

Analysis and 

Improvement Activities 





documented. 


Contractor will monitor and control testing of 

components and service deliverables 


Contractor will apply the CM practices 

(defined in the CMP) to documents, plans, 



Contractor will ensure reliability and 

maintainability of documents, plans, 



Contractor will measure, analyse and improve 

documents, plans, components and service 

deliverables 

4.1 Customer satisfaction This section describes how the ANWI 

Contractor will demonstrate product 

conformity to customer requirements, 

processes and products, handling of nonconformities, 

customer claims etc 

4.2 Internal audit This section describes the ANWI Contractor’s 

internal auditing mechanisms and processes 

4.3 Analysis of data This section describes the process the ANWI 

Contractor will use to analyse the 

4.4 Control of nonconforming 

product 

4.5 Certificate of 

Conformity 

5 NATO Additional 

Requirements 

This section describes the process the ANWI 

Contractor will use when he determines a 

component or service does not conform to the 

SOW’s requirements 

The requirement is applicable when the 

supplier is required to provide Certificate of 

Conformity at product release. An example of 

a suitable form is found in AQAP2070 Annex 

B5. 

The requirement includes how information 

required by the GQAR and/or Acquirer 

should be provided. 

The requirement includes how the supplier 

should perform review, inspection, 

verification, validation and test activities to 

demonstrate product conformity. 

6 Referenced 

Documents 

This section provides the list of QA 

documents supporting the QAP 

6.1 Contractual documents This section provides the list of other plans 

and quality related contractual documents 

that need to be referred: 

 

 

Project Management Plan 

Project Implementation Plan

6.2 Supplier internal 

quality related 

documents 



Risk Management Plan 

Configuration Management Plan 

Development Plan 

Test and Acceptance Plans 

This section provides the list of QA internal 

guidance that the ANWI Contractor used to 

create the QAP ( e.g. the QAP should crossreference 

the contractor’s internal 

mechanisms where functions and processes 

are clearly described) 

6.3 Other documents This section provides the list of any other 

relevant documents such as, related plans, 

interface documents, procedures and 

documents, including those of sub-suppliers 

that contribute to the delivered product as 

specified in the contract 





19.7 APPENDIX 7: Configuration Management Plan (CMP) 


19.7.1-p1 The Configuration Management programme, the ANWI Contractor shall 

create a Configuration Management Plan (CMP) that ensures all required elements 

of Configuration Management are applied in such a manner as to provide a 

comprehensive and overall Configuration Management programme. 

19.7.1-p2 The ANWI Contractor’s Configuration Management programme will 

identify the means by which continuity of effort and understanding is achieved within 

the Contractor’s organization, and between the Contractor and the sub-contractors, 

as well as between the PM and Contractor and internally, for the allocated 

Configuration Items, integrating, interfacing or otherwise related Configuration Items, 

contractor organizations, test and evaluation activities, project documentation and 

managers. 

19.7.2 Scope/Assumprion 

19.7.2-p1 The ANWI Contractor shall produce and maintain a Configuration 

Management Plan (CMP) which shall be used to carry out the Configuration 

Management functions (configuration item identification, configuration control, 

configuration status accounting, and configuration verification) in support of the ANWI 

project. 

19.7.2-p2 The ANWI Contractor’s CMP shall establish the ANWI Contractor’s 

internal Configuration Management requirements for the ANWI contract deliverables 

and defines these procedures in the Contractor’s ANWI CMP. 

19.7.2-p3 The ANWI Contractor shall ensure that an effective CM organisation is 

established and maintained to implement the CMP and apply all necessary CM 

procedures, in accordance with the requirements and guidance applicable for this 

contract, throughout the duration of the contract. 

19.7.2-p4 The ANWI Contractor shall describe the Configuration Management 

programme and CM organisation in the CMP which is referenced by the Project 

Management Plan. 

19.7.2-p5 The ANWI Contractor shall establish a configuration identification 

system for use in the project. 

19.7.2-p6 Configuration Item (CI) Identification 

A. The ANWI Contractor shall designate the set of all management products 

and specialist products as Configuration Items (CIs). 

B. The ANWI Contractor shall create a CI tree structure with NNHQ ANWI 

being the top level CI and show the relationships between the lower level 

CIs. 

C. The ANWI Contractor’s CI system shall provide the ability to easily trace 

higher and subordinate CIs using configuration item identifiers 







D. The ANWI Contractor shall provide an explanation of the rationale and 

criteria used in the process of selecting CIs assuring visibility and ease of 

management throughout the development effort and the support to the 

operational NNHQ ANWI after acceptance (based CI selection criteria on 

ACMP-3) 

E. Every CI shall have a unique identifier. 

F. All Commercial Off The Shelf (COTS), adapted, and developed software 

shall be designated as CIs. 

G. Services as identified in paragraph 2.5.3 shall be identified as CI items 

and form the top of the CI tree structure. 

H. Where COTS can be installed in a modular fashion, the description of the 

CI shallunambiguously identify the complete list of installed components. 

I. All complete hardware elements shall be designated as CIs. 

J. The ANWI Contractor shall maintain and update all project CIs as 

requested through change proposals. 

19.7.2-p7 Configuration Control 

A. The ANWI Contractor shall maintain a version control system as part of its 

CMP. 

B. The ANWI Contractor’s version control system shall allow for the unique 

identification of all changes to the CIs, no matter how minor the change. 

19.7.2-p8 Configuration Status Accounting (CSA) 

A. The ANWI Contractor shall be fully responsible for the CSA for all CIs in 

accordance with ACMP-4 or his equivalent National procedures. 

B. The ANWI Contractor shall prepare CSA reports in a manner, and format 

which shall be proposed by the Contractor in his CMP. 

C. The ANWI Contractor shall deliver CSA reports to the Purchaser both as 

part of management products and specialist products in this contract and 

also as standalone documents at the Purchaser's request. 

D. The ANWI Contractor shall deliver a set of final CSA reports for each CI in 

both hard copy and in electronic media at FSA. 

19.7.2-p9 Configuration Verification 

A. The ANWI Contractor shall, upon request from the Purchaser, support 

configuration audits to demonstrate that the actual status of all CIs 

matches the authorised state of CIs as registered in the CSA reports. 

19.7.2-p10 Baselines 

A. The Purchaser reserves the right to modify the CI structure prior to it being 

baselined. 

B. The CM Plan shall provide the baselining of ICT into a Developmental 

Baseline and a Product Baseline and the maintenance of these baselines 

throughout the duration of the contract. 

C. For the purpose of this project, a Baseline is defined as one (or a 

consistent set of) CI(s) that has been accepted by the Purchaser and that 

can therefore be used as the basis for subsequent project activities by the 

Purchaser and by the Contractor. 

D. This section describes the three baselines defined for this project: the 

Functional Baseline, the Developmental Baseline, and the Product 

Baseline.



E. The ANWI service requirements shall be considered the Functional 

Baseline. 

F. The Developmental Baseline for NNHQ ANWI shall include the NNHQ 

ANWI Design Documentation, the System Test Documentation Package, 

Security Documentation set and any other documentation deemed 

appropriate by the Contractor to ensure NNHQ ANWI requirements are 

reflected in the system during development and integration, can be 

demonstrated through a comprehensive set of tests, and can be delivered 

in the form of the Product Baseline. 

G. The ANWI Contractor shall deliver the Product Baseline which contains 

the configuration documentation of the delivered product CIs at the 

activation of the NNHQ ANWI and at any subsequent releases. 

19.7.2-p11 Configuration Management Tools 

A. The ANWI Contractor shall establish the baselines referred to above using 

automated tools. 

B. The ANWI Contractor shall deliver a version source code control 

programme for any custom software development and COTS software 

customisations. 

C. The ANWI Contractor shall use the version source code control 

programme for any custom software development and COTS software 

customisations. 

19.7.2-p12 The ANWI Contractor shall hand over the configuration 

management tools used to the Purchaser as a part of FSA. 



Annex K Appendix 1for the CMP. 

19.7.3-p2 The ANWI Contractor shall deliver the CMP in accordance with the 


19.7.3-p3 The CMP is a ‘living document’ that the ANWI Contractor shall maintain 

(update and adjust the document, as required) from Effective Date of Contract (ED) 

through Final Operating Capability (FOC). 

19.7.3-p4 The ANWI Contractor shall place all baseline documents under 

Configuration Control prior to providing them to the Purchaser for acceptance. 

19.7.3-p5 Any changes to the Developmental Baseline shall be forwarded to the 

Purchaser for approval. 

19.7.3-p6 The ANWI Contractor shall keep the contents of the Developmental and 

Product Baseline current to reflect the progress of the project activities. 

19.7.3-p7 The ANWI Contractor shall deliver the Product Baseline documentation 

on magnetic media (database) suitable for continued life cycle configuration 

management, in a format agreed by the Purchaser. 

19.7.3-p8 The acceptance of the Product Baseline by the Purchaser signifies only 

that the Purchaser agrees to the ANWI Contractor's approach in meeting the 

requirements. This acceptance in no way relieves the ANWI Contractor from its 

responsibilities to meet the requirements stated in this Contract. 




19.7.4-p1 



The CMP shall be structured according to the format below: 



# 


1.1 Purpose and Scope State the purpose of the CMP and identify the 

materiel to which the plan is to be applied and 

the management/acquisition philosophy to 

which it is tailored 

1.2 Description of the CI This section identifies the CI selection 

process, it shall contain: 

A description of the selection criteria 

and the associated rationale employed 

to select the CI; 

A description of the function of the top 

level CI and its inter-relationship to 

other system functions; and a 

description of applicable Purchaser 

Furnished Equipment/Property; 

A description of key lower level CI 

(hardware and software) including 

training devices and simulators 

showing their relationship to the work 

breakdown structure of the complete 

project 

1.3 Definitions Glossary containing accepted definitions of 

terminology 

1.4 Project Phasing and 

Milestones 

A milestone chart shall be included which 

depicts the CM activities and their relationship 

to the major overall project milestones. The 

relationship between events critical to CM 

and to the schedule / control of the project 

shall be specifically defined. This should 

include the sequencing of design reviews, the 

release of engineering documentation, and 

the start of production, the test programme, 

logistic support and audit events 







# 

1.5 Special Features Addresses major product improvement 

programmes which will result in more than 

one configuration to be supported in the field 

with more than one product baseline, or major 

model differences in systems or weapons 

designed for varying applications; 

preproduction evaluation, use of many 

commercial items, use of existing drawings 

and specifications, or employment of an 

integrating contractor) will be described here. 

Innovations intended to increase the 

effectiveness of the CM programme will also 

be described here 

2 Organization Provides the relationship and integration of 

the contractor's project management and CM 

organizations and describe the organizational 

relationship of the individuals and activities 

involved in the CM programme. The 

responsibilities of each individual or group 

shall be defined as well as the policy 

directives that govern the contractors CM 

programme 

2.1 Project Management 

Structure 

Provides an organization chart, which 

illustrates his project management structure. 

The chart, supplemented by a description or 

flow diagrams, shall illustrate the 

Authority/responsibility of the key 

organizational elements impacted by 


Management Structure 


Management 

Personnel 

contractual requirements for CM. 

Provides charts supplemented by narrative 

descriptions shall define the relationships 

between activities directly involved in the CM 

programme; also identify the 

interrelationships, if applicable, among the 

contractor's software and hardware CM 

organizations. Each activity or individual 

shown on the organization chart(s) shall be 

the subject of a subparagraph, which will 

detail the Authority and responsibility for 

which CM is assigned. 

Describe by title and qualifications the 

positions which shall perform contractor CM 




# 

2.4 Configuration Control 

Board 




Describe the organisational structure of the 

contractor's CC; Interrelationship of CCB if 

there is more than one level or separate 

software CCB; Membership of the CCB by 

organization and functional group; and 

effective date of operational status (the CCB 

shall be in operational status when the 

functional baseline is established). 

2.5 Policy Directives Identify all policy directives directly related to 

CM 

2.6 Reference Documents List only those documents which are referred 

to in the CMP 

2.7 Subcontractor / Vendor 

Control 

3 CM Responsibilities 

Configuration 

Identification and 

Documentation 

3.1 Selection and 

Description of the CI 

Identifies the methods used for the control of 

subcontractors and vendors 

Describe the methods to be used for 

identifying (e.g., naming, marking, numbering) 

documents and physical items (CI); Methods 

to achieve configuration traceability from 

requirements to equipment, components, 

computer software, facility sites and spares 

shall also be described. Requirements for the 

preparation, submission and subsequent 

release of PM approved documentation which 

defines each of the required baselines shall 

also be described in this section. The 

contractor's methods under which the 

documentation will be prepared and released 

internally shall also be described 

The contractor shall select, recommend and 

obtain the approval of the customer for 

potential CI where the CI, or family of CI, shall 

be briefly described and information provided 

in a way to avoid security classification of the 

plan, if possible. Sufficient detail shall be 

presented to permit a basic understanding of 

the CI and their complexities 

3.2 Identification of the CI Issues unique identifiers for the CI and the 

configuration documentation and maintain the 

configuration identification to facilitate 

effective logistics support of items in service 




# 

3.2.1 Hardware CI 

Identification 

3.2.2 Computer Software CI 

Identification (CSCI) 






Describe the plan and procedure for HW CI, 

part identification, and serialisation; list the 

criteria used in applying serial numbers; the 

contractor's plans and identify his procedures 

and capabilities of generating and maintaining 

a record which describes the relationship 

between the "as designed," "as built," and "as 

modified" configurations 

Part/Item Numbering 

NATO Supply Code for Manufactures 

Additional Numbering 

Serial/LOT Numbering 

Each CSCI; The version, release, change 

status, and any other identification details of 

each deliverable item; The version of each 

CSCI to which the corresponding software 

documentation applies; The software 

documentation and the computer software 

media containing code, software 

documentation or both that are placed under 

configuration control; and the specific version 

of software contained on a deliverable 

medium, including all changes incorporated 

since its last release 

Computer Programme Identification 

Software File Identification 

Source File Identification 

Executable File Identification 

Patch Identification 

Build Identification 

Firmware Identification 

3.2.3 Documentation CI Describe the plan and procedure for 

documentation CI, list the criteria used in 

applying versioning; the contractor's plans 

and identify his procedures and capabilities of 

generating and maintaining a record of 

managing the creation, updating and 

review/release process for documents like: 


Project Implementation Plan 

Security Risk Assessment 

… 

3.3 Nomenclature Address the process of nomenclature 

assignment and the requirements for titling 

specifications and drawings







# 

3.4 Product Marking and 

labelling. 

Describe the method to be used for marking 

and labelling CIs 


Documentation 

3.5.1 Document Numbering Describe the assignment of numbers for 

documents and numbering system to be used 

for drawings and specifications are stated 

here 


Baselines 

3.2.1 Functional Baseline 

(FBL) 

3.2.2 Allocated 

(development) 

Baseline (ABL) 

3.2.3 Developmental 

Configuration 

3.2.4 Product Baseline 

(PBL) 

Describe and document the functional 

baseline; outlines the procedure for review 

and release, and the plan for proposing 

changes to the baseline 

Lists of all existing and required specifications 

shall be included in specification tree format; 

and plan for proposing changes to this 

baseline shall be outlined; identify existing 

specifications or specifications that the 

contractor shall prepare for the CI or family of 

CI; identify the drawings and diagrams that 

are a part of or shall be a part of the Allocated 

(development) Baseline. A list of interface 

control drawings for both hardware and 

software shall be described here or in a 

separate appendix 

Describes the developmental configuration 

management process; change and issue 

process and tracking, reporting, and 

recording problems are maintained for the life 

of the contract. 

Describes his plans for preparation, review, 

release and control of the specifications and 

drawings and CSCI code standards; identify 

the hardware and software specifications 

which the contractor shall prepare to establish 

the product baseline and the format to which 

they will be prepared; and define the drawing 

(interface control drawings and the 

identification of interface parameters) 

practices for application to the CI 

3.3 Documentation library. Describes his CI documentation library and 

procedures for controlling the documents 

residing within the documentation library 

3.4 Drawing library. Describes his drawing library and procedures 

for controlling the drawings


# 

3.5 Software Development 

Library. 

3.6 Engineering Release 


3.6.1 Engineering Release 

Record 




Describes his software development library 

(SDL) and the procedures for controlling and 

safeguarding the software residing within the 

SDL 

Describes his plan to ensure that each 

engineering release record (contractor, 

subcontractor, or vendor supplied) shall 

contain: the CI number and serial numbers (if 

applicable) of the items affected; and for each 

document listed, the document number, title, 

NSCM number, number of sheets, date of 

release, revision index and the engineering 

change number, if applicable 

4 Configuration Control Defines the responsibilities and procedures 

used within the contractor's organization for 

configuration control 

4.1 Configuration Control 

Board (CCB) 

4.2 Configuration Changes 

Procedures 

Defines the Authority and responsibility of the 

contractor's CCB 

Describes the processes and submission of 

Engineering Change Proposals (ECP) in 

combination with Notice of Revisions (NOR), 

and Requests For Deviations/ Requests For 

Waivers (RFD/RFW) shall be described; 

procedures for approving changes to 

configuration identification, production, spare 

parts, retrofit and technical publications 

programmes; procedures to ensure feedback 

to the purchaser are described; and how 

changes shall be monitored. 

4.2.1 Processing of 

Engineering change 

proposals. 

4.2.2 Notice of Revision. 

4.2.3 Request for Deviations 

and Waivers. 

4.3 Parts Substitution. Describes the procedure for parts substitution 

and how he will obtain approval by the 

Purchaser – how it will be used for technology 

refresh 

4.4 Interface Management Describes the documentation and control of 

all physical and functional interfaces of 

systems, equipment, software, facilities and 

installation requirements 







# 

4.4.1 Documentation Specifies the documentation to be generated 

as part of the interface control and identifies 

interface parameters on the production 

documentation 

4.4.2 Interface Control 

4.4.3 Interface Control 

Working Group 

(ICWG) 

5 Configuration Status 

Accounting and 

Configuration Data 

Management. 

5.1 Configuration Data 

Handling. 

Describes his methods for collecting, 

recording, processing and maintaining data 

necessary to provide an adequate 

configuration data management and status 

accounting 

5.2 Reporting. Identifies the current approved configuration 

documentation and configuration identifiers 

associated with each CI; Status of proposed 

engineering changes from initiation to 

implementation; Results of configuration 

audits, status, Action items and disposition 

and discrepancies; Status of deviations and 

waivers; traceability of changes from baseline 

documentation of each CI; and effectiveness 

and installation status of configuration 

changes to all CI at all locations 

5.3 Configuration Data 

access 


Management Metrics. 

6 Configuration Audits Describes the plans, procedures and 

documentation, for the conduct of the 

Functional and Physical Configuration Audits; 

the format for reporting results of 

configuration audits; and schedule periods 

and agendas for the conduct of CM audits 

7 Technical Reviews Defines the schedule for and the degree of 

participation of CM personnel in technical 

reviews 

8 Abbreviations List of the abbreviations used in the 

document 




19.8 APPENDIX 8: Test and Acceptance Plan (TAP) 





19.8.1-p1 The purpose of the Test and Acceptance Plan (TAP) is to document the 

policies and procedures that will be used for testing and accepting components and 

services in the ANWI project. 


19.8.2-p1 The ANWI Contractor shall establish and maintain Test and Acceptance 

Plan (TAP) for the project. 

19.8.2-p2 The TAP shall address the Contractor’s overall concept of testing and 

accepting the delivered: ANWI capabilities, ANWI services, and the overall ANWI 

system. 

19.8.2-p3 The ANWI Contractor shall acknowledge in the TAP that testing and 

acceptance are uniquely distinct tasks. 

19.8.2-p4 The ANWI TAP shall define the set of testing activities to verify a 

deliverable’s compliance with the contractual requirements, to demonstrate its 

operational suitability, and to evaluate its performance to establish benchmarks for 

future enhancements. 

19.8.2-p5 The ANWI Contractor shall have the overall responsibility for meeting 

ANWI testing requirements and conducting all related activities; including the 

development of all test documentation required under this contract, the conduct of all 

testing, and the evaluation and documentation of the tests results. 

19.8.2-p6 The ANWI Contractor’s testing approach shall consist of a series of five 

tests to deploy the ANWI: 

1) Capability Acceptance Tests (CATs). The CAT shall demonstrate that a specific 

capability as identified in an appendix meets the operational, functional and 

technical requirements. This testing shall occur in either the ITS or other 

Purchaser approved NNHQ campus location that is physically interconnected to 

the ITS (e.g. the NNHQ server rooms, the NNHQ, the user space, etc) to 

demonstrate the specific capability and successfully concludes with the 

capability / function being “fit for use” for use by a service and/or user. 

2) Proof of Concept Testing (PCT).The PCT shall occur at the ITS and 

concentrates on assessing the service catalogue entries of the ANWI’s SMC, 

UCC, Client Provisioning and CDGW services. This test concludes with the 

definition of the item for the Service Catalogue and a green field accreditation 

review. The conclusion of these test results in the validation and confirmation 

of technical and user-related useability features for the SCT and ANWI Service 

Catalogue input. 

3) Service Certification Tests (SCT). The SCT shall test the system engineering, 

integration, and monitoring of the services as delivered and monitored in the 

NNHQ Network Operations Centre. The successful conclusion of this test 

activates an ANWI service for use in the NNHQ and finalises the Service 

Catalogue entry. 

4) System Activation Testing (SAT). The SAT provides the overall operational 

testing of all ANWI integrated services offered on the NNHQ site. The





successful conclusion of this test defines the integrated back-end, specific CoI 

and supplemental services are “fit for purpose”. 

5) Final Site Testing (FST). FST focuses on the installation of user devices and 

activation of the user’s requested service catalogue choices to the user 

device. 

19.8.2-p7 Before each test session the ANWI Contractor shall ensure that all 

required hardware, software, test equipment, instrumentation, supplies, facilities, 

system test documentation and personnel are available and in place to conduct the 

test session. 

19.8.2-p8 The Purchaser will monitor and inspect the ANWI Contractor’s test 

activities to ensure compliance. 

19.8.2-p9 The ANWI Contractor shall develop the necessary System Test 

Documentation Package for each test. 

19.8.2-p10 The System Test Documentation Package shall comprise the following 

documents: 

1) The Test Plan. 

2) The Security Test and Evaluation Plan (ST&E) 

3) The Security Implementation Verification Procedures demonstrating for the 

local Security Accreditation Authority (SAA) that the capability and service 

complies with the proposed and agreed security configuration and settings. 

4) The System Version Definition Document consisting of: 

a) List of differences between this and the previous System version. 

b) List of capabilities of this System version. 

c) Guidelines on how to install this System version. 

d) Breakdown of the system into configuration items (Cis) and provision of 

accurate identification information for every CI. 

5) The description of the ITS (complete list of system Cis to be installed on the 

ITS, complete description of the test environment, all configuration 

information). 

6) The test procedures consisting of: 

a) The scenario. 

b) ITS objective, by clearly identifying the ANWI requirements to be tested 

(subset of the Requirements Traceability Matrix) by the test procedure. 

c) The NNHQ ANWI Cis and facilities and test equipment involved. 

d) Any conditions which shall be satisfied prior to application of the test. 

e) A block diagram showing the proposed method of meeting the test 

requirements. 

f) The data to be collected. 

g) The sequence of testing steps in the procedure, to a level of detail that 

enables full understanding by the Purchaser of the purpose and effect of 

each test step. 

h) The expected outcome. 

i) The means of measurement or assessment for the test to determine 

success. 

7) Any submitted test waivers together with supporting material. 

8) As needed, an updated system Off-specifications Document



a) Off-specification identification. 

b) Description of the Off-specification. 

c) Related test (if the Off-specification was raised further to a test failure). 

d) Severity (Major if to be corrected before deployment, otherwise Minor). 

e) Cis affected. 

f) Action taken. 

g) Fault Resolution status: 

i) Open=the Off-specification is identified. 

ii) Resolved= remedial action has been taken by the Contractor and 

demonstrated through tests conducted by the Contractor without 

official witnessing by the Purchaser. 

iii) Closed= the resolution was officially demonstrated to the Purchaser. 

h) Comments. 

9) The results of the dry-runs performed by the ANWI Contractor as a 

preparation for the upcoming test session. 

19.8.2-p11 The ANWI Contractor shall request acceptance of a capability, service, 

or system following a successful test, with any and all deficiencies corrected. 

19.8.2-p12 The acceptance of a capability, service, or system closely follows the 

five tests to deploy the ANWI: 

1) Capability Acceptance Test (CAT) acceptance confirms the successful testing 

and approved documentation and concludes that the capability / function is 

agreed “fit for use” by the Purchaser and permits the ANWI Contractor to 

invoice the capability. 

2) Proof of Concept Testing (PCT) acceptance agrees the UCC, Client 

Provisioning and CDM service entries for inclusion on the ICTM Service 

Catalogue and inclusion into the ANWI’s SMC. 

3) Service Certification Test acceptance results in the service being added to the 

Service Catalogue and inclusion into the ANWI’s SMC. 

4) System Activation Testing (SAT) acceptance agrees that all back-end, specific 

CoI and supplemental services are “fit for purpose” and shall permit the ANWI 

Contractor to be able to request the Initial Operating Capability meeting. 

5) Final Site Testing (FST) acceptance permits the ANWI Contractor to request 

the Final Operating Capability meeting. 



Annex K Appendix 1for the TA. 

19.8.3-p2 The ANWI Contractor shall deliver the TAP in accordance with the 


19.8.3-p3 The ANWI Contractor shall update the TAP after each meeting and 

adjust the document throughout the project while the ITS is operational. 

19.8.3-p4 The ANWI Contractor shall review all test reports and have all testing 

deficiencies corrected by FOC. 


19.8.4-p1 

The TAP shall be structured according to the format below: 



Section 

# 

Section Title 








project’s Test and Acceptance concept and 

how the Test and Acceptance Plan (TAP) will 

be applied to the ITS and system 

acceptance. 


1.1. Purpose This section identifies and explains the 

purpose of the TAP. 

1.2 Intended Audience Describes the intended audience of the TAP, 

including the sub-contractor team and 

dependent projects/PFE testing. 





2 Integration Testing 

Service (ITS) 

This section explains the role and 

environment of the ITS, as well as its 

manning and support requirements. 

3 Testing This section identifies the test process from 

component through service to system testing 

as controlled and defined in the configuration 

management process 

3.1 Approach This section identifies the overall test strategy 

and is related to configuration management, 

change management, configurations, metrics, 

tools needed, unique hard/software, 

regression testing, and process 

3.2 Responsibilities This section describes the roles and 

responsibilities of the staff needed to support 

the testing facility’s ITS, testing staff and 

actors involved in the testing process 

(scheduling, de-conflicting, decision making, 

etc)with respect to the suite of ANWI testing 

steps 

3.2.1 Test Manager 

3.2.2 Testing Team 

3.2.3 NATO QAR 

3.2.4 Purchaser Monitor 

3.3 Schedule This section identifies the scheduling process 

and creation of a realistic schedule (showing 

planning, development of test cases, setup, 

testing, etc). Will also address the planning 

impact of schedule slips, failed or stopped 

tests and how these will be resolved to 

minimise the overall impact to the ANWI 

schedule







# 

3.4 Environmental Needs This section identifies any special needs 

(power, space, equipment, software, etc) and 

dependent PFE availability 

3.5 Reports This section defines the reports and records 

developed, produced and maintained as a 

result of the testing process 

3.5.1 Test Items This section identifies all items to be tested 

and implemented in the NNHQ or remote site, 

whether it is a client facing or back-end 

service 

3.5.2 Risk Issues This section identifies the critical areas for 

testing: 

Interfaces 

Security compliance 

COTS products 

Contractor developed integration 

products 

Complex functions (e.g. UCC 

integration) 

Modifications due to changes 

Poorly documented modules 

as well as misunderstanding ANWI original 

requirements. 

3.5.3 Features to be Tested This section lists the user and service 

functions to test based on what the ANWI is 

to do with associated risk level for each 

component , software item, integration aspect 

and service 

3.5.4 Features not to be 

Tested 

This section lists what is not to be tested from 

a configuration management /version control 

view of the component or service or system. It 

will include an explanation why the item is not 

to be tested 

3.5.5 Test Case Reports This section defines how the test cases are to 

be documented and recorded 

This section identifies the need for special 

skills and Purchaser support 

3.6 Staffing and Training 

Needs 

4 Testing Prerequisites This section outlines the requirements to be 

satisfied and implemented prior to testing 

4.1 Quality Assurance Refers to the QAP needs and requirements 

for testing a service 

4.2 Test Cases This section addresses the review and 

acceptance process of the test cases 

4.3 Test Data This section identifies any test data 

requirements and who is responsible for 

providing what data





# 

5 Test Procedures 

5.1 Test Schedule This section identifies the testing periods 

5.2 Planning Risks and 

Contingencies 

This section relates testing to the Risk 

Management Plan and addresses how the 

risks are to be addressed and/or mitigated 

5.2 Test Results This section identifies the documenting of the 

test results 

5.2.1 Item Pass/Fail Criteria This section identifies the completion criteria 

for the service in terms of entrance and exit 

criteria and resolution of test deficiencies 

5.2.2 Suspension Criteria 

and Resumption 

Requirements 

This section explains when a test will be 

paused; specifies what constitutes a 

stoppage; and what is the acceptable level of 

deficiencies/defects that are accepted before 

a test is stopped. This section also explains 

the actions that will take place when testing is 

paused or stopped. 

5.2.3 Test Deliverables This section identifies the test deliverables 

before during and after: 

Test plan 

Test cases 

Test design specification & 

configuration 

Interfaces 

Restore points 

Logs (error and execution) 

Reports (errors, problems, corrective 

actions, successes) 

5.2.4 Remaining Test Tasks This section describes the steps/stages of the 

ANWI testing from components to service to 

integrated system 

5.3 Corrective Actions This section addresses how corrective 

actions will be addressed and processed 

5.4 Acceptance and 

Release 

This section defines the steps needed to 

determine if a component or service has 

passed all tests and is ready for the 

production environment and acceptance by 

the Purchaser 

5.5 Suspend Testing This section identifies the criteria to end 

testing and close the ITS 

5.6 Documentation Provides the comprehensive list of 

documentation defines as the ‘System Test 

Documentation Package’ 







19.9 APPENDIX 9: Integrated Logistics Support Plan (ILSP) 


19.9.1-p1 The purpose of the Integrated Logistics Support Plan (ILSP) is to 

document how the ANWI Contractor will provide logistics, operations and 

maintenance support for the NNHQ. 

19.9.1-p2 The ILSP will address all service models applicable to the ANWI: NATO 

Owned NATO Operated (NONO) NATO Owned Contractor Operated (NOCO) and 

Contractor Owned Contractor Operated (COCO), as COCO services are identified 

and NOCO service selections will be decided based on a combination of Total Cost 

of Ownership (TCO) and NATO’s need to operate the selected service(s). 


19.9.2-p1 The ANWI Contractor shall develop and maintain an ANWI Integrated 

Logistics Support Plan (ILSP). 

19.9.2-p2 The ANWI Contractor provided ILSP shall detail how Integrated 

Logistics Support is provided to the Purchaser. 

19.9.2-p3 The Contractor shall maintain and update the ILSP as required to reflect 

changes in the Project Baselines, in the SOW, or in support arrangements for any 

NNHQ ANWI Configuration Items. 


19.9.3-p1 The ANWI Contractor shall provide the initial version of the ILSP to the 

Purchaser for acceptance. 

19.9.3-p2 The Purchaser’s acceptance of the ILSP only signifies that the 

Purchaser agrees to the Contractor’s approach in meeting the requirements and this 

acceptance in no way relieves the Contractor from its responsibilities to meet the 

requirements stated in this Contract. 


Annex K Appendix 1for the ILSP. 

19.9.3-p4 The ANWI Contractor shall deliver the ILSP in accordance with the 


19.9.3-p5 

FSA. 

19.9.3-p6 

lifetime. 

The ANWI Contractor shall review the ILSP as part of IOC, FOC and 

The ANWI Contractor ILSP shall be provided throughout the contract’s 


19.9.4-p1 

Section 

# 

The PIP shall be structured according to the format below: 

Section Title 




project’s Integrated Logistics Support will be





implemented. 


objective of the ILSP and identifies the major 

activities to be undertaken in supporting the 

ANWI project. 

1.1 Purpose and Scope State the purpose of the ILSP and explicitly 



1.2 Document 

Organization 


ILSP. 



and assertions made in the ILSP 





2 Delivery of equipment This section identifies the physical delivery of 

equipment and processes to ensure that the 

warranty will not become void prior to 

expiration 

3 Supporting 

documentation 

4 System Operations 

and Maintenance 

4.1 NATO Owned NATO 

Operated (NONO) 

4.2 NATO Owned 

Contractor Operated 

(NOCO) 

4.3 Contractor Owned 

Contractor Operated 

(COCO) 

This section identifies the documents that 

shall be provided with the COTS equipment 

(hard/software) 

This section addresses the provision of ANWI 

systems operations and maintenance 

This section addresses the warranty, 

licensing and training requirements of a 

NONO provided service 

This section addresses the warranty and 

licensing requirements of a NOCO provided 

service and how the ANWI Contractor will 

provide the service in accordance with the 

SLA and SLTs 

This section addresses the SLA and SLT 

metrics for the COCO provided service, as 

well as contact information for 

issues/problems 

4.4 Warranty & Licenses This section provides all warranty information 

for NATO owned hard/software, providing 

contact information, terms of agreement, 

effective dates of warranty, etc. 

4.5 Training This section addresses any training provided 

for NATO operated hard/software. It will 

address the training strategy, class modules, 

instructor modules, student/instructor material 

and the right for NATO to reproduce it to train



5 Compliancy with the 

ILS based Service 

Level Targets (SLTs) 

NATO staff without extra cost or limitation 

This section addresses how the SLTs will be 

managed via the Service Desk 




19.10 APPENDIX 10: NATO Material Data Sheet 


Item Description 

1 Contract Line Item Identification Number (CLIN). 

2 NATO Stock Number (NSN, if known). 

3 Item Name. 

4 Expendable or Non-Expendable Code. 

5 True Manufacturer Part Identification. 

6 True Manufacturer code or complete name and address. 

7 Vendor/Contractor Code or complete name and address. 

8 Vendor/Contractor part number. 

9 Quantity ordered. 

10 Order Unit 

11 Serialized item tag. 

12 Serial Number. 

13 Software Revision Level. 

14 Hardware Revision Level. 

15 Other Serial Number Attributes. 

16 Accountable Item Flag. 




19.10.1-p1 The purpose of the NATO Material Data Sheet is to support the 

ANWI and NNHQ inventory process. 


19.10.2-p1 The ANWI Contractor shall ensure the provision of an inventory 

down to the Lowest Replaceable Unit (LRU) level of all the equipment, software, 

training and other documentation supplied. 


19.10.3-p1 The ANWI Contractor shall create a codification numbering system 

(as described in Clause 33 of the NC3O General Provisions) unless an adequate 

COTS manufacturer’s identification numbering system is in place and will be used. 

19.10.3-p2 The ANWI Contractor shall deliver the applicable NATO Material 

Data Sheet not later than ten (10) working days prior to the first shipment of the 

equipment to the Purchaser 

19.10.3-p3 The ANWI Contractor shall deliver the NATO Material Data 

information for each item in Microsoft Excel format. 

19.10.3-p4 

Contractor. 

19.10.3-p5 

portal. 

19.10.4 Data Sheet Structure 

The Purchaser will provide a copy of the template to the ANWI 

The ANWI Contractor shall post a softcopy of the inventory on the 

19.10.4-p1 The NATO Material Data Sheet’s inventory information shall, as a 

minimum, include the following data elements:


17 Currency. 

18 Price. 

19 Warranty Expiration Date. 

20 Receiving/ Inspection Depot 

21 Issue to customer flag 

22 Extended Line Item Description (if applicable). 

23 Part Number of Next Higher Assembly. 

24 Quantity in Next Higher Assembly. 

25 Test 





19.11 APPENDIX 11: Security Risk Assessment 





19.11.1-p1 The purpose of the Security Risk Assessment (SRA) is to identify 

the risks that exist, identify the current security posture of the ANWI’s ICT in respect 

to storing, processing or communicating information, and then assemble the 

information necessary for the selection of effective security countermeasures, based 

upon NATO security policy and supporting directives and guidance. 

19.11.1 -p2 ‘Progressive risk assessment’ is a mainstay of the accreditation 

process and will be delivered as a series of SRAs. The SRA is key to the 

identification of security risks (i.e. the threats, vulnerabilities and associated adverse 

impacts upon the ICT infrastructure). These risk assessments will determine the 

magnitude of residual risk and identify areas that need additional safeguards or 

countermeasures (which, in turn, identify specific security ‘requirements’) to be 

implemented. 


19.11.2-p1 The ANWI Contractor shall produce and maintain the SRA covering 

the scope of the full systems/solutions, from the first design review through final 

operating capability (FOC). 

19.11.2-p2 The SRA shall include a ‘high-level’ assessment of risks associated 

with any of the deployed technologies to be used within the design. Specific 

evaluation of these technologies is needed to ensure that they do not compromise 

the overall design. 

19.11.2-p3 The SRA shall also provide an overall assessment of the ANWI, 

which addresses: 

1) the environment for technical information security measures 

2) The impact of the ANWI upon the electronic security system (ESS), which 

integrates all physical security measures (cameras, intruder detection sensors, 

access control devices) and provides communications between these 

components over a single (connected) IP environment. 

3) the impact of the ANWI upon the AVI and VTC systems, which integrate all 

video cameras, room display devices (projectors, Visual Display Unit, etc.) 

other audio visual equipment and any remote VTC connectivity for meetings 

and provides communications and storage between these components over a 

single (connected) IP environment. 

4) the cross domain modules and influence of NCIRC and NPKI 

5) the ANWI services, and 

6) the arrangements for system management and control (SMC). 



Annex K Appendix 1for the SRA. 

19.11.3-p2 The ANWI Contractor shall deliver the SRA in accordance with the 

Schedule of Supplies and Services.





19.11.3-p3 The ANWI Contractor shall update the SRA after each design 

review and adjust the document throughout the implementation period to FOC. 


19.11.4-p1 The SRA, supported by the risk management processes, will follow 

a structured approach (and may use an automated tool, where appropriate) and will 

include a description of the countermeasures to be implemented, and a description of 

the residual risk. 

19.11.4-p2 

Section 

# 

The SRA shall be structured according to the format below: 

Section Title 




project and an overview of the framework 

used to develop the conceptual ANWI 

design. 

1 Introduction This section explains the overall purpose and 

objective of the SRA identifying what the 

ANWI delivers, the associated risks, and what 

is being done to reduce the risk. 

1.1 Purpose and Scope State the purpose of the SRA and explicitly 


is to be updated as the design evolves and 

the risks and threats change. 

1.2 Document 

Organization 


SRA. 



and assertions made in the SRA 





2 System/Component Identification of the system and associated 

system component(s) that is the subject of 

the risk assessment 

3 Security Relevance Identify whether or not (and if so, how) this 

system/ component: 

1. Enforces or supports a particular security 

mechanism that will be used to provide a 

security service within the NNHQ (if so, what 

security mechanism is involved). 

2. Is intended for use as part of the security 

system and supports information assurance 

3. Uses other security services as part of its 

functionality 

4. Relies upon security mechanisms provided



by others 

5. Provides security mechanisms that are 

used by others 

4 Security-relevant data Identify the nature and classification of data 

that will be processed by or used by the 

system/component 

5 Vulnerability Describe the potential 

vulnerability/vulnerabilities of the solution and 

how this might affect the overall security 

posture of the NNHQ’s ANWI 

6 Probability of 

exploitation 

Assess the likelihood that each vulnerability 

will be exploited and identify any known 

attack mechanisms or methods that might be 

employed 

7 Security Risk Qualitative assessment of the initial risk 

(Low/Medium/ High), with attendant 

justification 

8 Mitigation measures/ 

security ‘requirements’ 

Define any security requirements or 

countermeasures that, if employed, would 

address/mitigate the effects of the security 

risk identified 

9 Residual Risk Re-assess the security risk if the 

countermeasures were to be in place 

(Low/Med/High), explaining how the 

mitigating measures decrease the risk (i.e the 

vulnerability and/or the probability of 

occurrence) 

10 Recommendations Identify any necessary recommendations 

associated with the solution that would 

maintain or enhance the security of the 

system/component in question 

11 Conclusions Present a summary of key findings and 

recommendations that ‘must’ be observed to 

preserve the security posture of the solution 







19.12 APPENDIX 12: Security Test and Evaluation (ST&E) Plan 


19.12.1-p1 The purpose of the Security Test and Evaluation (ST&E) Plan is to 

document the policies and procedures that will be used for the security testing and 

evaluation of components and services in the ANWI project. 

19.12.1-p2 The ST&E is to address the ANWI‘s confidentiality, integrity, and 

availability requirements providing the necessary security protection to secure and 

accredit the system. 

19.12.1-p3 Risk must be considered as those items that will possibility result in 

a negative impact on the project, be it decreased quality, increased cost, delays, or 

failure. 


19.12.2-p1 The ANWI Contractor shall provide and maintain a Security Test 

and Evaluation (ST&E) Plan that details the tests by which he will demonstrate 

compliance with the security requirements of the Certificate Practice Statement 

(CPS), System-specific Security Requirement Statement (SSRS), and System 

Interconnection Security Requirement Statement (SISRS). 

19.12.2-p2 The ST&E shall address the following types of testing. 

A. Demonstration – the evaluation by operation, movement, or adjustment 

under a specific condition to determine the capability to satisfy a stated 

requirement. 

B. Inspection – the physical examination or review of the feature, such as 

review of a configuration file or software version number/patch level. 

C. Test – the collection, analysis, and evaluation through systematic handson 

measurement under appropriate conditions 

D. Develop 

19.12.2-p3 The ANWI shall use appropriate security test procedures to support: 

A. functional testing 

B. system integration testing 

C. stress testing 

D. vulnerability analysis 

19.12.2-p4 The ST&E’s test results shall be sufficient to obtainthe accreditation 

of the ANWI’s design and services; ultimately allowing the ANWI to be implemented 

and made available to users. 



Annex K Appendix 1for the ST&E Plan. 

19.12.3-p2 The ANWI Contractor shall deliver the ST&E Plan in accordance 

with the Schedule of Supplies and Services. 

19.12.3-p3 The ANWI Contractor shall maintain the ST&E Plan throughout the 

contract duration.


19.12.4-p1 

Section 

# 




The ST&E shall be structured according to the format below: 

Section Title 




project’s Security Test and Evaluation 

concept and how the ST&E will be applied to 

the ITS and system acceptance. 

1 Introduction The section identifies that the results in this 

document address the potential 

vulnerabilities, and identification and 

validation of security controls and risk-based 

controls documented in the ANWI’s Security 

Risk Assessment (RSA) 

1.1. Purpose This section identifies and explains that the 

purpose of the ST&E is to verify the 

compliance with security policy guidelines 

and evaluation their effectiveness against 

anticipated threats. 

1.2 Intended Audience Describes the intended audience of the 

ST&E, including the sub-contractor team and 

dependent projects/PFE testing. 





2 Integration Testing 

Service (ITS) 

This section explains the role and 

environment of the ITS, as well as its 

manning and support requirements. 

3 ST&E Requirements This section identifies the criteria that the 

ANWI components and services are to be 

tested against (SRA, certification/ 

accreditation assessments, configuration 

management, system/core information 

integrity, media protection, network access 

controls, identification and authentication, 

audit and accountability, etc) 

4 ST&E Team 

4.1 Composition This section identifies the composition of the 

ST&E team 

4.2 Roles and 


4.3 External (Purchaser) 

Support 

This section provides the responsibilities for 

each team role 

This section identifies what expertise is 

required and when to monitor and approve 

the test results 

5 ST&E Approach This section identifies the test process from 

component through service to system testing 

as controlled and defined in the configuration 


Section 

# 

Section Title 

5.1 Operational Service 

Approach 

5.2 System Tests and 

Protocols 




management process with regard to how well 

the ANWI supports the security requirements 

and identifies any unsupported requirements 

or requirements that are not fully supported 

per the Security Risk Assessment 

This section will address any testing that 

interfaces with a currently operational service 

explaining that the test approach was 

designed to avoid possible disruption to 

ongoing activities and uses a non-intrusive 

set of tests. 

This section addresses the types of test plans 

and that the results will need to be reviewed y 

the Security Accreditation Authority (SAA) 

and that the results & recommendations from 

these tests will be reported 

5.2.1 Operational Tests This section identifies that these type of tests 

focus on demonstrating that operational 

requirements have been met and that a 

mitigation plan has been developed and 

accepted to resolve deficiencies 

demonstrating that the ANWI is operationally 

effective and operationally suitable for use 

and more importantly that the services are 

ready to be certified and accredited. 

5.2.2 Penetration Test This section explains that penetration tests 

will be performed by attempting to circumvent 

the ANWI security features to gain access to 

the services and should be monitored by the 

Purchaser’s SAA 

5.2.3 System Test This section defines the series of tests that 

will verify the ANWI meets its specified 

requirements. Subsets of this test (per NCIA 

testing) are operational tests, integration tests 

and user acceptance tests where each test 

satisfied the functional and non-functional 

requirements associated with the service. 

5.2.4 Vulnerability Test This section addresses how the tester will try 

and identify security vulnerabilities that may 

compromise the ANWI by using an approved 

vulnerability scanning method. These may 

include, but are not limited to, port scans, 

available services, password checks, and 

system patches 

5.3 Testing This section identifies the testing process 







# 

5.3.1 Test Procedures This section addresses the tests to be used to 

verify the ANWI’s compliance with the 

security measures and that each test 

procedure is traceable to a security 

specification and addresses all of the security 

requirements without ambiguous results. 

5.3.2 Corrective Actions This section documents the process and plan 

for corrective actions resulting from an ST&E 

and how the contractor will implement and 

manage the corrective action plan 

5.4 Schedule 

6 ST&E Results This section documents the ST&E results in a 

tabular form based on the security testing 

requirements (e.g. NIST SP 800) 

Annex Vulnerability 

Assessment 

This section provides the result of the 

vulnerability scan 




19.13 APPENDIX 13: Security Documentation Input 

19.13.1 Introduction/pPurpose 

19.13.1-p1 

use. 




The ANWI and its components must be accredited by NATO prior to 

19.13.1-p2 The ANWI accreditation process requires technical information 

supporting the design and implementation to produce the following elements of the 

security Accreditation Document Set (ADS): System Security Requirement Statement 

(SSRS), the System Interconnection Security Requirement Statement (SISRS) and 

Security Operating Procedures (SecOPs).These documents, together with the SRA 

(Annex K, Appendix 11) and ST&E (Annex K, Appendix 12), constitute the “Security 

Documentation Input” for the ANWI 

19.13.1-p3 The Purchaser is responsible for the submission and securing of the 

ANWI’s accreditationwith the System Accreditation Authority (SAA). 

19.13.1-p4 The ANWI Contractor shall provide the above ADS elements, 

containing such technical details as are appropriate to describe the essential 

technical input for the purpose of supporting the accreditation process for the ANWI. 


19.13.2-p1 The Security Risk Assessment (SRA, Annex K Appendix 11) serves 

as the assessment foundation for the security design, in that it identifies residual risks 

and informs the need for mitigation/countermeasures to be fed-back into the design. 

The final SRA, reflecting the implemented design solutions, together with the final 

ST&E are both constituent parts of the final Security Documentation Input. 

19.13.2-p2 The Security Documentation Input document shall provide the 

content for the ANWI’s accreditation based on the ANWI’s security design and 

including the detailed implementation descriptions that address and describe the 

security measures and countermeasures to be implemented in the ANWI. 

A. The SSRS portion of this document identifies the technical implementation 

of security features related to the storing, processing or transmitting of 

NATO classified information within the ANWI, within each of its security 

domains and within each service. It is acceptable to reference established 

& published external documents (technical standards, ‘as built’, design, 

etc.) rather than reproducing or quoting the full source document directly. 

B. The SISRS portion of this document identifies each network/security 

domain interconnection and its technical interconnection requirements 

providing the security agreement between the two parties. 

C. The SecOPs portion of this document specifies the detailed procedures to 

be followed thus ensuring that the ANWI is operated in a secure manner. 

19.13.2-p3 The ANWI contractor is required to provide support to the 

accreditation process (in addition to the technical input to various ADS elements 

described above), as defined within the NNHQ Security Accreditation Directive 

(Reference 1.1.1.7.2) paras 60 – 72. An ANWI Contractor staff with technical 

knowledge of the installation, system, components and services shall attend one (1) 

NATO security meeting a month (1/2 day) to address security matters supporting the 

ANWI’s accreditation.







Annex K Appendix 1for the security documentation. 

19.13.3-p2 The Contractor shall deliver the security document in accordance 

with the Schedule of Supplies and Services. 

19.13.3-p3 The ANWI Contractor shall deliver the appropriate parts of this 

document (Security Documentation Input) immediately after each design session; 

adjust the document, as required, after a service’s testing; and as needed during the 

period Initial Operating Capability (IOC) through Final Operating Capability (FOC). 

19.13.3-p4 

format below: 

The security document input shall be structured according to the 



# 

Executive Summary Provides a managerial description of the 

1 Introduction This section identifies the ANWI and a brief 

description of the overall concept and role of 

the ANWI. 

1.1 Purpose and Scope This section provides the overview of what it 

means for the ANWI to be secure and 

identifies how security is to be achieved; as 

well as stating that this document will be used 

as a reference point for security reviews and 

inspections. 

1.2 Document 

Organization 

1.3 Location of the CIS 

and its Components 

This section describes the organization of this 

document. 

This section identifies in general terms the 

locations of the ANWI and its remote sites 

supported by the ANWI 



and assertions made in the SSRS, SISRS 

and SecOPS 





2 System Security 

Requirement 

Statement (SSRS) 

This section describes the overall security 

profile for the ANWI and defines the security 

profile for each security domain as well as 

provides the specific security design and 

configuration for each service provided in the 

security domain. 

2.1 CIS Description This section describes the ANWI in terms of: 

2.1.1 Role of the ANWI Operational concept in terms of data 

processing, storage, and communications





2.1.2 Information Type, volume and classification of information 

to be stored, processes and transmitted by 

network type 

2.1.3 Architecture Description of hardware, firmware and 

software functional elements of the ANWI 

services and connections/interconnections 

of/to networks 

2.2 Security Requirements This section identifies the security 

requirements as complemented by the 

Security Risk Assessment (SRA) and 

describes the following: 

2.2.1 Minimum Standards Security standards and methods used 

2.2.2 Criticality of 

Information and 

Supporting System 

Services and 

resources 

This section addresses the importance of the 

information and system with respect to the 

loss of: confidentiality, integrity and 

availability are addressed and 

2.3 Security Measures This section describes the implemented 

ANWI security configuration and features to 

support the secure operations of each 

security domain. 

2.3.1 NATO SECRET (NS) This section states the security measures 

which are taken in the NS network/security 

domain to achieve security in terms of: 

access control, identification, authentication, 

accounting, security audit, integrity and 

availability, data exchange/communications, 

and any residual risk from the SRA 

2.3.2 EAPC This section states the security measures 

which are taken in the EAPC network/security 



accounting, security audit, integrity and 



2.3.3 BUSINESS (NR/NU) This section states the security measures 

which are taken in the Business 

network/security domain to achieve security 

in terms of: access control, identification, 

authentication, accounting, security audit, 

integrity and availability, data 

exchange/communications, and any residual 

risk from the SRA 

2.3.4 PUBLIC (Non- 

CLASSIFIED) 

This section states the security measures 

which are taken in each network/security 



accounting, security audit, integrity and

2.3.5 Cross Domain 

Modules 

3 System 

Interconnection 

Security Requirement 

Statement (SISRS) 







This section states the security measures 

which are taken in CDMs to achieve security 

in terms of: access control, identification, 

authentication, accounting, security audit, 

integrity and availability, data 

exchange/communications, and any residual 

risk from the SRA 

This section identifies and describes the 

security criteria governing the elements that 

form the ANWI interconnections 

3.1 NS-Business (NR/NU) The section addresses the technical 

description; operational requirement; security 

modes of operation, and functional 

capabilities; location of the connection points; 

exchange services; protocols; and 

classification/marking for the Cross Domain 

Module 

3.2 NS-EAPC The section addresses the technical 






Module 

3.3 NS-Public (Non- 

CLASSIFIED or NATO 

UNCLASSIFIED 

Releasable to the 

Internet) 

The section addresses the technical 






Module 

3.4 Business-Public The section addresses the technical 






Module 

3.5 NS-NS The section addresses the technical 





classification/marking for the inter-network 

connections





3.6 Business-NR The section addresses the technical 






connections 

3.7 Public-Internet (PIA) The section addresses the technical 






connections 

4 Security Operating 

Procedures (SecOPs) 

4.1 Service Management 

& Control 

This section of the document specifies the 

detailed procedures to be followed thus 

ensuring that the ANWI is operated in a 

secure manner. 

This section addresses the procedures 

needed to securely operate and manage the 

SMC services (service management console, 

user self-services, etc.) as well as the remote 

access and reporting of information ‘up the 

support chain’. 

4.2 Information Assurance This section addresses the procedures to 

securely manage and operate the cross 

domain gateways and internal ANWI security 

capabilities. 

4.3 Infrastructure Services This section addresses the procedures to 

securely manage and operate the ANWI’s 

processing, storage and infrastructure 

services. 

4.4 UCC This section addresses the procedures to 

securely manage and operate the integrated 

UCC service. 

4.5 Client Provisioning This section addresses the procedures to 

securely manage and operate the 

provisioning of client hardware and software 

and control of ports with respect to data loss 

prevention. 


Services 

5 Administration of 

Security 

5.1 Security Risk 

Management 

This section addresses the procedures to 

securely manage and operate the 

supplementary services offered by/through 

ANWI. 

This section provides information on what 

responsibilities 

This section provides about the procedures to 

be followed during the project how security



risk management will be undertaken 

5.2 Configuration Control This section identifies the process to approve 

security changes 

6 Security Risk 

Assessment 

Final version of SRA including mitigation/ 

countermeasures, outstanding vulnerabilities 

and residual risk. 

7 ST&E Final version of ST&E, incorporating results 

and non-conformities. 







19.14 APPENDIX 14: Project Progress Review Meeting (PPRM) 


19.14.1-p1 The purpose of the Project Progress Review Meeting (PPRM) is to 

check whether the project is progressing as planned, to discuss problems, to agree 

on changes etc. in a face-to-face meeting. 


19.14.2-p1 The ANWI Contractor shall coordinate and hold Project Progress 

Review Meetings (PPRMs) with the Purchaser serving as chairman. 

19.14.2-p2 The ANWI Contractor shall schedule the PPRMs in the PIP and, 

when possible, schedule the PPRM with other project related meetings. 

19.14.2-p3 Attendance by key personnel (needed based on the agenda) in 

person is required; by exception key personnel may participate via video or 

telephone conference after prior approval by the Purchaser and when it can be 

arranged by the parties. 


19.14.3-p1 The ANWI Contractor shall hold every other PPRM at his facility 

until the start of the server room installation; thereafter, PPRMs shall be held monthly 

on the NNHQ campus. 

19.14.3-p2 The ANWI Contractor shall provide PPRM information (slides, PSR, 

etc) no later than five (5) working days before the meeting. 

19.14.3-p3 

PPRM. 

The ANWI Contractor shall present the PPRM information at the 

19.14.3-p4 The ANWI Contractor shall provide notes (action items, minutes, 

decisions made, etc) of the meeting per the documentation requirements of this 

SOW. 

19.14.3-p5 The ANWI Contractor shall post a softcopy of the presentation and 

notes on the portal within 48 hours. 

19.14.4 Reporting Structure 

19.14.4-p1 The PPRM shall report the status of the following items, based on 

the PSR, or indicate if there is no change since the last PPRM: 

Item Description Comment 

1 Project Management Plan Status Identify any upcoming changes to 

the PMP 

2 Review of On-Going Action Items Review the status of the project’s 

open action items 

3 Project Schedule: Status of On- Identify the status of the PIP and 

Going Tasks and WBS 

4 Accomplishments &Status of 

Current Contract Deliverables 

state of current activities 

List major tasks/accomplishments 

completed and/or milestones 

achieved since the last meeting



5 Invoices Review of new acceptance 

documents and status of invoices 

6 Testing Status Review testing timeline and 

status of testing 

7 Status of Problems with Delivered 

Capabilities 

Review deliverable and test 

problems/deficiencies and 

corrective action status 

8 Risk Review Review the Risk Register for the 

current phase/stage of the project 

9 Problems and Issues New or potential problems/issues 

for action/decision 

10 Changes Review status of Change 

Requests 

11 Activities for the Next Period Identify major 

tasks/accomplishments to be 

completed and/or milestones to 

achieve before the next meeting 

12 Any Other Business Identify the date of the next 

meeting and any other points for 

discussion 




19.15 APPENDIX 15: Project Status Report (PSR) 





19.15.1-p1 The Project Status Report (PSR) is an ANWI deliverable to support 

the monitoring of the project’s progress outside the PPRM periods. 


19.15.2-p1 

have a PPRM 

The ANWI Contractor shall provide PSRs in the months that do not 

19.15.2-p2 The ANWI Contractor’s PSR shall serve as the replacement of the 

face-to-face PPRM. 

19.15.2-p3 The ANWI Contractor’s PSR shall provide an accurate summary of 

the project’s: 

A. Activities (completed and planned) during the period 

B. Current issues 

C. PIP status 

D. Upcoming potential problems/risks. 


19.15.3-p1 The ANWI Contractor shall provide the PSR by email to the 

Purchaser no later than the fifth (5th) business day of the month. 

19.15.3-p2 The ANWI Contractor PSR shall follow the release, submit and 

review process specified in Annex K 

19.15.3-p3 

The ANWI Contractor shall post a softcopy of the PSR on the portal. 

19.15.3-p4 The ANWI Contractor shall promptly identify and discuss problems 

with the Purchaser’s Project Manager and not wait until the next PPRM 

19.15.4 Reporting Structure 

19.15.4-p1 

The PSR shall provide the following in the report: 

Item Title Section Description 

Header 

Identifies the report identification number, 

author and date of release 

1 Period of Report This section identifies the start and end date 

of the reporting period 

2 Activities This section lists the contractor activities that 

occurred during the reporting period and 

includes the status of current and pending 

tasks/action items 

3 Schedule Impact This section identifies the status of the plan 

and associated deliverables and whether 

they are on time or delayed 

4 Products Completed This section lists the products and 

deliverables with their status (delivered, 

reviewed, approved) as well as invoices



sent 

5 Tests Carried Out This section lists the tests conducted in the 

ITS during the reporting period and their 

status (in progress, tested pass, tested 

failed) 

6 Change Status Summary and status of Change Requests 

requested, pending or approved during the 

period 

7 Actual/Potential Issues and 

Risks 

This section describes any identified 

problems, anomalies and high risk areas with 

proposed solutions or corrective actions 

identified in the reporting period – and linked 

to project issue and/or Risk Register 

8 Next Period’s Planned Work This section identifies the activities 

scheduled for the upcoming reporting period 

(which may be a PPRM) 

9 Upcoming Deliverables This section identifies the Schedule of 

Supplies and Services (SSS) items that will 

be delivered in the upcoming period 




19.16 ANNEX K APPENDIX 16: Migration Plan 





19.16.1-p1 The purpose of the Migration Plan is to document the migration 

concept, methodology and processes needed to migrate the ANWI’s core service 

data (Active Directory, email, Windows Shares, etc) from the current HQ to the 

NNHQ’s appropriate security domains. 


19.16.2-p1 The ANWI Contractor shall produce a Migration Plan (MP) that 

addresses the migration of user and system information and data as identified in 

document structure below. 

19.16.2-p2 The ANWI Contractor shall ensure that the MP complies with the 

ANWI service provisioning and integration requirements. 

19.16.2-p3 The ANWI Contractor Migration Plan shall address: 

A. Migrating user accounts (tool, naming convention, renaming users, Sid) 

B. Delegation of control and role based administration. 

C. Four security classification networks. 

D. User passwords. 

E. Migration tools to be used and a clear statement on what the migration 

restrictions of this tool are. 

F. Options for migration scenario’s, if applicable. 

G. Intermediate situation, where HQ and NNHQ are connected, and services 

from either side can be used by either side. 

H. What bandwidth exist, for migration (and synchronization) of data, if done 

over the network. 

I. Detailed Migration Schedule per ANWI capability services and support to 

migration of services by the other Host Nations. 

J. User data and settings migration. 

K. Bulk data migration. 

L. Data Archiving. 

M. Migration Roll-Back and Disaster Recovery Plan (where and when 

needed). 

N. Operations and Support Plan during migration stage. 

O. Migration QA Process. 

P. Migration Information Assurance aspects. 

Q. Migration Communication Plan. 


19.16.3-p1 The ANWI Contractor shall use the review and acceptance process 

described in Annex K Appendix 1for the MP. 

19.16.3-p2 The ANWI Contractor shall deliver sections of the MP as they apply 

to the ANWI design’s section (e.g. ANWI UCC design will be accompanied by a MP 

section addressing email, voice, collaboration, etc.). 

19.16.3-p3 The ANWI Contractor shall maintain the coherency of the MP 

sections through FOC.


19.16.4-p1 

below: 





The Migration Plan shall be structured according to the format 



# 


Provides a managerial description of the project from 

and an overview of the framework used to develop the 

conceptual ANWI design. 

1 Introduction This section defines the purpose and overall objective of 

the document focusing on delivery, installation, and 

configuration for the various networks and how 

capabilities and services fit together. It also addresses 

the baselines used, service management and the goals 

of the design. 

1.1 Purpose and Scope State the purpose of the ANWI migration plan and 

identify the materials to be applied and the 

management/acquisition philosophy to which it is 

tailored. High level discussion of the migration’s 

deliverables 

1.2 Document Organization This section describes the organization of the migration 

plan. 

1.3 Points of Contact Provides the title and organization of the key points of 

contact for the migration and each subsystem of the 

ANWI that must be migrated. These points of contact 

must also include/identify the project’s: Quality 

Assurance (QA) Manager, Security Manager, and 

Configuration Manager. 

1.4 Glossary Includes a glossary of all terms and abbreviations used 

in this document. If the glossary is several pages in 

length, it may be included as an appendix 

2 Considerations The discussion will address that the initial ANWI concept 

identifies that the ANWI design will be new and 

independent of other activities that recently occurred at 

NATO HQ. The ANWI concept identifies that all 

equipment will be new but may accept (re)used 

equipment if NATO recently purchased new hardware, 

realised during the site survey, and fits into the ANWI 

design. 

2.1 Constraints This section identifies how the ANWI Contractor will 

connect to existing services: 

Joining the Bi-SC AIS AD environment (single 

forest, single domain model). 

Joining the Bi-SC AIS Email organization. 

Interfacing with the existing NEDS directory 

services (On NS level). 

Connecting to the NATO wide voice systems 

Using NGCS for connectivity to NATO 

commands. 

Using the PIA gateway services for Internet 

Access (browsing, remote users, remote 

offices). 

Integrating the services of a commercial IPTV 

provider. 

Connecting with the NATO wide VTC services. 

Connecting with existing web solutions in other



Section 

# 

Section Title 

 


NATO Organizations/Agencies. 

Connecting to and using the NPKI. 

2.2 Restrictions This section identifies how the ANWI Contractor will 

comply with the following policies: 

NCIRC rules 

INFOSEC policies 

Using the following products: 

o Microsoft Windows and Office desktop 

environment. 

o COTS use 

Security roles. 

2.3 Dependencies This section identifies how the ANWI Contractor will 

ensure that projects involved with ICT for the NNHQ: 

PNWI for all passive cabling needs and 

patching. 

Server room design (power/cooling restrictions) 

TER power and cooling design 

ESS interface, switching, storage/archive and 

processing (as needed) 

AVI interface, switching and storage/archive 

BMS – for power reporting and monitoring of 

building 

ICTM Application migration 

2.4 Design considerations This section identifies how the ANWI Contractor will 

ensure that migration addresses/supports: 

Green IT. 

Virtualisation. 

Service Oriented Architecture: 

o Infrastructure as a Service. 

o Standardization. 

o One user experience. 

o IPv6 compatibility. 

Redundancy and high availability of services 

3 ANWI Services 

3.1 Service management This section addresses that this service is a new 

environment for NNHQ but should address migration of 

any current HQ knowledge bases, application/update 

‘push packages’, and reporting services (e.g. asset 

management system). 

3.2 Information Assurance IA is not new but a major consideration in designing and 

migrating data and users from the existing environment, 

it shall address security and the new cross domain 

gateways capabilities. 

3.2.1 Security The section addresses the new environment based on 

NCIRC and INFOSEC policies and how these will be 

applied, noting migration and preservation of access 

rights 

3.2.2 Cross Domain Gateway 

Services 

This section address if any items will be reused and how 

they will fit into the operational support concept: 

CDGW1 – new design, new equipment, 

greenfield situation 






Section 

# 

Section Title 


 

 

 












4 Infrastructure 

4.1 Processing This section addresses the services sub-elements, as 

required. 

4.1.1 Physical servers The physical server environment will be ‘greenfield’ and 

even though no servers, or other hardware, from the 

existing HQ will be reused, unless there are reasons that 

these must be used (continuity of ICT services), the 

ANWI Contractor will address how the service will be 

implemented (with security role adaption). 

4.1.2 Hypervisor The virtual server environment will be completely new 

but will address the settings and security roles and 

movement of VMs from the current HQ. 

4.1.3 Operating systems This section defines how (physical and virtual) servers 

will be “migrated” from current HQ to NNHQ and the 

adaption of security roles to the new OS. 

4.2 Storage services This section is a new design, new equipment, greenfield 

situation must address data migration and how currency 

of data is to be ensured 

4.3 Printing and Scanning 

Services 

4.4 Network Infrastructure 

services 

New design, new equipment, greenfield situation but will 

address how the users will leverage this service; and if 

cross domain printing is offered – how this will be 

provided. 

This section addresses the NNHQ design and its 

migration to the NNHQ 

Active Directory 

o Current Bi-SC AIS AD design 

o Requirements for joining Bi-SC AIS AD 

o Naming convention 

o Depending upon the version of the 

servers, which server versions are 

allowed to join 

 

 

 

 

o Current password policies and future 

password policies 

NTP: Joining Bi-SC AIS AD on NS level with 

PDC = timeservers 

DNS: DNS design Bi-SC AIS 

DHCP: IP number plan from NGCS New design, 

greenfield environment 

NAC/NAP New functionality, new design, 

greenfield 

4.5 LAN services The interconnection between current HQ and NNHQ, will 

be a direct connection (under administration by ICTM) or 

will it be a connection over the NGCS link (still LAN, but 

routable over the NGCS router and administered by 

them) 

 

Wired – new design, new equipment, greenfield 

situation

Section 

# 

Section Title 


 



Wireless – new design, new equipment, 


This section addresses how the current and NNHQ will 

be interconnected while users move between the 2 

buildings 

5 UCC Services 

5.1 Voice This section address how voice services between the 2 

buildings (current and NNHQ) will be provided as well as 

how telephone numbers will be provided and made 

known to voice users. 

 

Insecure Voice 

o Connect to existing voice environment 

o Intermediate period where users located 

in the HQ need to talk to users located 

in the NNHQ. 

o 

o 

Possible issues. 

Roll back, where and when needed. 

5.2 Video This section will explain the connectivity and how the 

users will be provided seamless connectivity while users 

move between the 2 buildings 

Connect to existing NATO wide VTC. 

Connect to commercial IPTV provider 

Intermediate period where users located in the 

HQ need to contact users located in the NNHQ 

Possible issues 

5.3 

19.16.4.1.1 Email 

This section will explain user and system email account 

migration; the connectivity to the AIS email system and 

how the users will be provided seamless connectivity 

while users move between the 2 buildings 

Email and its relation to the Bi-SC AIS’ design. 

Email naming convention. 

Which version of Exchange may connect in the 

existing environment 

Migrate mailbox history. 

Calendar (future appointments and history). 

Rights on other users mailboxes. 

Whether user connects to multiple mailboxes. 

Inbox rules. 

Intermediate situation where users will be 

located in both HQ and NNHQ. 

Naming convention (different from the current 

environment) 

Connectivity on older email addresses, after 

migration. 


Tools used and clear statement on what the 

migration restrictions of this tool are. 

Possible scenarios, pros and cons 

5.4 Other This section will address how these will be migrated if 

already existing in the current HQ and is targeted for 

reuse: 

Presence 









# 

IM 

Collaboration 

6 Client Provisioning Service 

6.1 General This section will address user core service migration 

onto the new footprint 

OS deployment 

App deployment 

Software Client 

Devices 

6.2 Users 

6.2.1 User Migration 

This section will address how fileshare data will be 

copied to/synchronized with the ANWI design, 

specifically addressing: 

 

 

 

 

 

 

 

 

 

 

 

How to migrate fileshare data. 

Roll back, if needed. 

Favorites 

How to migrate this data 

Profile information 

Depending on the final solution, what info to 

migrate or not, if any. 

Possible issues on migrating these settings. 

Roll Back, but probably not needed here. 

Mailbox 

Application dependency 

Needed: Business application list (ICTM). 

6.2.2 User working environment This section addresses the moment a user migrates 

from the current network, to the NNHQ environment, the 

user’s expectation will be that all will be as it was, with 

regards to applications, data and sometimes even user 

settings, like his background or the remembered 

passwords for his favourite web sites. But at the same 

time, users will most probably be located in both the old 

and the new HQ, so there needs to be a working 

environment where users from both buildings can do the 

same work, using the same data set (or there can/will be 

discrepancies in the data). In case all users can be 

moved in a big bang, there will still be an intermediate 

situation with (business) apps located in both 

environments, essentially still the same issue. 

Future functionality for users, on different 

devices (laptop, desktop, VDI, Citrix, diskless 

clients). 

How to handle changes for the users 

(communication, training). 

Home drive 

How to migrate this data. 

Roll back, if needed. 

6.2.3 Local data This section addresses dependencies between 

applications and user groups using these applications. 

Business applications are a driver in the schedule for 

migrating. Groups of user have rights to applications and 

when users are migrated from an old environment to



Section 

# 

Section Title 


something new, access to that application is still needed. 

In the simplest and most straightforward case, when a 

group of users is migrated, all applications are also 

migrated. However, this scenario often isn’t this simple, 

as some of the applications used are more users than 

just those in this one group. With users located on both 

the old and the new network, using the application from 

both sides means that an intermediate situation is 

created, where access to the application is one factor, 

but possibly accessing data from this application, either 

data on a file share, or because data from the 

applications is accessed by another process, which also 

needs to be migrated at some point in time 

(interdependencies between apps). 

How to create an intermediate situation, where 

applications can be used from both 

environments, if needed. 

Scenarios, pros and cons. 


19.16.4.1.2 

6.2.4 File services Info if file services are use, and how. Departmental data, 

or is that located in a document management system? 

Application data, located on file-shares and not in 

databases. 

How to migrate the data. 

How to integrate this in the user migration 

scheduling. 

How to do this in an intermediate situation with 

users on both sides, old and new. 

How to keep the data synchronized, if on 

different networks. 

19.16.4.1.3 

6.2.5 Web browsing This section will address the migration of favourites and 

user access – or reference where this is already 

addressed 

7 Supplementary Services 

7.1 Site Security 


This section shall be provided with the initial security 

domain design. The section will explain how the ANWI 

Contractor will support the migration of TETRA to the 

NNHQ and the period between contract award and the 

Connect to existing Site Security Comms 

Intermediate period where users located in the 

HQ need to talk to users located in the NNHQ. 


7.2 Other Supplementary items This section will address how these will be migrated if 

already existing in the current HQ and is targeted for 

reuse: 

GSM New environment 

GSM Blocking New functionality 

Wireless Blocking New functionality 

IPTV New functionality 







19.17 ANNEX K APPENDIX 17: Service Interface Profile (SIP) 


19.17.1-p1 The purpose of the Service Interface Profile (SIP) is to provide an 

outline for use in the specification of each of the internal or external service’ 

interfaces as identified by the ANWI services annexes through a SIP. 


19.17.2-p1 The ANWI Contractor’s SIP shall be managed as a configuration 

item that falls under formal configuration and change management. In case of any 

changes to any of the internal or external interfaces of a particular ANWI service the 

SIP shall be changed/updated 


19.17.3-p1 The ANWI Contractor shall use the review and acceptance process 

described in Annex K Appendix 1for the SIP. 

19.17.3-p2 The ANWI Contractor shall deliver a SIP for each service of the 

ANWI design’s section. 

19.17.3-p3 

through FSA. 


19.17.4-p1 

Section 

# 

The ANWI Contractor shall maintain the ANWI services’ SIPs 

A SIP shall be structured according to the format below: 

Section Title 



Provides a managerial description of the project 

from and an overview of the framework used to 

develop the conceptual ANWI design. 

1 Introduction This section defines the purpose and overall 

objective of the service being provided 

1.1 Purpose and Scope State that the purpose of the SIP is to provide 

instructions on how to interface with and 

consume the service. 

1.2 Document Organization This section describes the structure of the SIP 

document. 


points of contact for the SIP. 

1.4 Glossary Includes a glossary of all terms and abbreviations 

used in this document. If the glossary is several 

pages in length, it may be included as an 

appendix 

1.5 References Includes a list of references for the service’s SIP 

2 Service Interface (s) 

Description 

This section contains a full identification of the 

systems/services participating in the interface, the 

contractors developing the systems/services, the 

interfacing entities, and the interfaces to which 

this document applies, including, as applicable,

Section 

# 

Section Title 


 

 

 

 

 





identification numbers(s), 

title(s), 

abbreviation(s), 

version number(s), 

release number(s), 

or any lower level version descriptors 

used. 

A separate paragraph should be included for 

each component that comprises the interface 

2.1 Service Standard This section provides an overview of the interface 

and the data exchanged between the services. It 

also identifies the standards used (NATO or 

international). 

2.2 Service Operations This section provides a list of service operations 

2.2.1 Service Operation 

Relations 

2.2.2 Input – Output 

Relationships 

that can be called by a service consumer 

This section describes the service’s 

operation. It should include a diagram of the 

service’s functionality. 

This section describes for each of the service 

operations, as identified above, the inputoutput 

relationship for the service 

2.2.3 Errors This section describes,for each of the service 

operations identified above, the possible error 

states and messages 

3 Interface 

3.1 Data format and data 

types 

This section describesdetailed data 

format/type definition used in/by the service. 

If the format is a composite data type, a XML 

definition should be provided. 

3.2 Protocol This section provides the information or data 

transfer protocol(s) used 

3.3 Physical Interface This section describesthe physical interface 

standard, as applicable. 

4 Service Level Targets This section describesthe availability and 

performance metrics 

5 Security 

5.1 Classification This section Security Classification, security 

domain and releasability conditions for the 

service 

5.2 Service Access This section addresses the Identity and 

Access Method used to achieve authorisation 

to use the services 

6 Services access point If applicable, provide the URI/DNS address 

where the service can be reached/access



Section 

# 

Appendices 

Section Title 


This section allows some information to be 

placed in appendices to the SIP (e.g. charts 

and classified data are typical examples). 

Table 19.17 – SIP Template 




19.18 ANNEX K APPENDIX 18: Service Level Agreement 





19.18.1-p1 The purpose of the SLA is to describe a service’s delivery 

framework and set the expectation for its availability, reliability and performance. 


19.18.2-p1 The SLA shall define the SLT quality criteria, period of the SLA, 

delivery parameters, monitoring and processes a service is to be provided 

19.18.3 Reporting &Provisions 


Annex K Appendix 1for the SLA. 

19.18.3-p2 The Contractor shall deliver the SLAs in accordance with the 


19.18.3-p3 The ANWI Contractor shall review and adjust the SLAs annually 

with the Purchaser. 


19.18.4-p1 The SLA shall be structured according to the outline below: 

A. Name of the IT Service 

B. Clearance information (with location and date) 

1. Service Level Manager 

2. Client representative 

C. Contact persons 

1. Name of the Service Provider 

2. Name of the Service recipient 

3. Contact partners/ persons in charge (on client-side as well as on the 

side of the IT Organization) for 

a. Contractual changes 

b. Complaints and suggestions 

c. Escalations in the case of contractual infringements 

d. Service reviews 

e. Emergencies 

D. Contract duration 

1. Contract start 

2. Contract end 

3. Rules for changes to the SLA 

a. How requests for change are submitted (deletions, additions or 

changes to components of the SLA)? 

b. How are the requests for change and their implementation 

controlled? 

c. Who is responsible for the clearance of the changes? 

4. Rules for termination of the SLA 

E. Service description





1. Short description of Service 

2. Users of the IT Service on the client-side 

3. Breakdown of the offered Service into Service groups, e.g. along 

infrastructure components or IT applications 

4. For each Service group: 

a. Which Services are offered, e.g. 

b. Handling of Service interruptions (by telephone, by remote access, 

on site?) 

c. User Services (user administration, installation, …) 

d. What quality is required of the offered Services, e.g. 

e. Service times 

f. Availability requirements 

g. Number of interruptions allowed 

h. Availability thresholds (xx,xx %) 

i. Downtimes for maintenance (number of allowed downtimes, prenotification 

periods) 

j. Procedure for announcing interruptions to the Service (planned/ 

unplanned) 

k. Performance requirements 

l. Required capacity (lower/upper limit) for the Service 

m. Allowed workload/ usage of the Service 

n. Response times from applications 

o. Reaction and resolution times (according to priorities, definition of 

priorities e.g. for the classification of Incidents) 

p. Requirements for the maintenance of the Service in the event of a 

disaster 

F. Relations to other IT Services 

G. Procedures for requesting the IT Service 

1. Requests possible by telephone/fax/mail, ... (addresses, telephone 

numbers, etc.) 

H. Responsibilities 

1. Of the client (also within the field of IT Security) 

2. Responsibilities and liability of the IT Organization 

I. Quality assurance and Service Level Reporting 

1. Measurement procedures 

a. Which indicators 

b. With which measurement procedures 

c. At which intervals 

d. Collated into which reports 

2. SLA Reviews 

a. Intervals at which SLA reviews are to be held 

J. Service accounting 

1. Costs for the provision of the Service 

2. Accounting method for the Service 

3. Intervals for invoicing 

K. Glossary



SECTION 20. ANNEX L: NATIONS AND PARTNERS 

20.1 Purpose 

20.1-p1 This Annex describes the ANWI deliverables required by the NATO and 

partner nations’ delegations. 

20.1-p2 Nations and NATO partners located in the NNHQ will be given the 

opportunity to use this contract to procure services from the Service Catalogue as 

they deem necessary. 

20.1-p3 The equipment identified in this Annex shall be the same as that defined, 

identified and delivered in accordance with the technical Annexes and Appendices of 

this SOW. 

20.2 NATO Nation 

20.2-p1 The ANWI Contractor shall provide each NATO national delegation two (2) 

NS workstations and two (2) Business workstations with the standard ANWI Office 

Automation configuration; connected to the respective networks. 

20.2-p2 The table below shows the order of magnitude of potential additional 

devices/services that may be purchased over and above the Contract (as Contract 

options). 

ANWI Services 

NS Services 

NS Workstation 636 

NS User account (additional) 25 

NS Network printer 44 

NU/NR Services 

NU/NR Workstation 332 

NU/NR Smartphone 80 

NU/NR User Account (additional) 1 

NU/NR High Volume Network printer 9 

NU/NR Network printer 25 

Services (provided on any network) 

Public Telephone 278 

IPTV Display 63 

Meeting Room VTC kit 8 

Virtual Meeting Room 3 

Potential Additional 

Devices Needed 

Table 20.1 Overview of possible ANWI quantities for NATO nations 





20.2-p3 After contract award, the Purchaser will identify the list of ANWI equipment 

required for installation by each NATO nation’s delegation on the NS and/or Business 

domains as options to the contract. 

20.3 Partner Nations 

20.3-p1 The ANWI Contractor shall provide each partner nation a telephone for 

voice service 

20.3-p2 The ANWI Contractor shall provide each partner nation two (2) client 

devices with the standard ANWI Office Automation configuration and connected to 

the EAPC network. 

20.3-p3 After contract award, the Purchaser will identify the list of ANWI equipment 

required for installation by each partner nation’s delegation on the EAPC domainas 

options to the contract. 





SECTION 21. ANNEX M: REMOTE SITES 

21.1 Purpose 

21.1-p1 This Annex describes the ANWI deliverables required for NATO’s remote 

sites. 

21.2 Remote Sites 

21.2-p1 NATO HQ supports the connection to five (5) remote sites. 

21.2-p2 Each remote site is a ‘long local’ of the NATO Headquarters. 

21.2-p3 RESERVED. 

21.2-p4 Services for remote workers are to be provided at the NATO RESTRICTED 

(NR) level and up to and including the NATO SECRET (NS) level. 

21.2-p5 The ANWI Contractor shall install and configure the hardware and software 

at the remote sites under the supervision of the local NATO staff. 

21.2-p6 The locations of the remote sites are identified below: 

Site 1: Brussels, Belgium 

Site 2: New York City, USA 

Site 3: Kabul, Afghanistan 

Site 4: Moscow, Russia 

Site 5: Kiev, Ukraine 

21.2-p7 The below table identifies the equipment that the ANWI Contractor shall 

deliver, install and configure at each site. 

ANWI Equipment Site 1 Site 2 Site 3 Site 4 Site 5 

ANWI Services 

Cryptographic 

Equipment 

Router 

Small LAN switch 

Device cables 

NS Services 

PFE PFE PFE PFE 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 



TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

PFE 

TBD by 

Contractor 

TBD by 

Contractor 

TBD by 

Contractor 

NS Workstation 5 2 4 2 2 

NS Network printer 

NU/NR Services 

NU/NR 

Workstation 

NU/NR 

Smartphone 

NU/NR Network 

printer 

30 30


Table 21.1: Services in remote locations 


21.2-p8 The ANWI contractor shall provide all ANWI services that are available to 

users in the NNHQ building to users at the remote locations 

21.2-p9 The ANWI Contractor shall coordinate the installations of the remote sites 

through the Purchaser. 

21.2-p10 The ANWI Contractor’s remote site installation staff shall be in 

possession of valid NATO SECRET clearances. 

21.2-p11 The ANWI Contractor shall configure and test the remote site’s 

configuration in the ITS prior to delivery. 

21.2-p12 The ANWI Contractor shall remove, pack and deliver the tested 

equipment to the required sites per the delivery instructions defined in SECTION 5. 

21.2-p13 The ANWI Contractor shall reuse the local cryptographic equipment for 

the remote site’s installation. 

21.2-p14 

The ANWI Contractor shall install and test the configuration. 

21.2-p15 The ANWI Contractor shall remove the packing material per the 

instruction of the local site staff. 

21.2-p16 The local NATO staff will supervise and witness the ANWI Contractor’s 

on-site activities. 

21.2-p17 The ANWI Contractor shall provide user familiarisation for the hardware 

devices installed. 

21.2-p18 The ANWI Contractor shall conduct the remote site acceptance with the 

local NATO staff. 

21.3 Supporting Additional Remote Needs 

21.3-p1 In addition to the locations specified above, the following facilities shall 

deliver all services (up to and including NS) to certain staffs who are working at other 

remote locations for a certain well defined time period such as NATO summits, 

conferences, etc. 

21.3-p2 Figure 21.1. Shows the two additional ad-hoc/deployable architectures that 

ANWI shall provide and support: 

A. Travel Kits 

B. Deployable ICT KIT 





Figure 21.1: Additional Remote Services Architecture Options 

21.3.1 Travel Kits. 

21.3.1-p1 The Private Office of the Secretary General requires 10 ‘travel kits’; the 

composition of these remote user ‘travel kits’ and the provision of their component 

equipment. 

21.3.1-p2 

The travel kit shallbe operated at the NS level. 

21.3.1-p3 The travel kit shall be composed of the following components: 

A. Based on Mobile Desktop (Laptop) compliant with ANWI defined NS 

baseline HW and SW, to include NPKI based smartcard authentication. 

B. HW based NS certified disk encryption 

C. HW based NS level VPN encryption that can setup an encrypted tunnel 

over the Internet/Public Network anywhere in the world. 

D. Integrated portable small form factor printing capability. 

21.3.1-p4 The following backend equipment shall be provided: 

A. NS VPN concentrator Gateway that can support 20 concurrent sessions. 

B. NS VPN concentrator Gateway to be integrated DMZ segment of CDGW1. 

C. A small (DMZ) switch. 





21.3.1-p5 The travel kit operation requires it to be compact and portable 

supported by the following facility: 

A. Purpose build leather business suitcase. 

21.3.1-p6 Unpacking, connection and startup time as well as tear-down time shall 

take no longer than starting up a normal mobile laptop and VPN. 

21.3.1-p7 The communications equipment that would be needed to establish such 

links is within scope. 

21.3.1-p8 The secure communication links (via the Internet) between the NNHQ 

and other locations (using the travel kits) are in scope of the ANWI project. 





SECTION 22. ACRONYMS 

ABL 

ACL 

ACMP 

ACP 

ACT 

AD 

ADS 

AEDC 

AIS 

AMSG 


AP 

API 

AQAP 

AV 

AVI 

AVI 

BE 

Bi-SC 

BMS 

BPC 

CAB 

CACM 

CAM 

CAT 

CC 

CC 

CCB 

CCBS 

CCLM 

CCP 

CDGW 

CDM 

CDR 

CDRL 

CFB 

CFNR 

CFU 

CIS 

CIs 

Allocated (development) Baseline 

Access Control List 

Allied Communication Management Publication 

Allied Communication Publication 

Allied Command Transformation 

Active Directory 

Accreditation Document Set 

After Effective Date of Contract 

Automated Information System 

Allied Military Security Guideline 

Active Network Infrastructure 

Access Points 

Application Programming Interface 

Allied Quality Assurance Publications 

Anti-Virus 

Integrated audio-visual equipment 

Audio Visual Infrastructure 

Backend 

Bi-Strategic Command 

Building Management System 

Boundary Protection Components 

Change Advisory Board 

Core AIS Client Module 

Core AIS Module 

Capability Acceptance Test 

Confrence Center 

Common Criteria 

Configuration Control Board 

Call completion to a busy subscriber 

Core Communications LAN Module 

Configuration Control Plan 

Cross-Domain Gateway 

Cross Domain Module 

Critical Design Review 

Contract Data Requirements List 

Call forwarding busy 

Call forwarding no reply 

Call forwarding unconditional 

Communication and Information Systems 

Configuration Items 





CISOA 

CLIN 

CLIP 

CM 

CMDB 

CMP 

COCO 

CoI 

COLP 

CONF 

CONOPS 

COTS 

CP 

CPS 

CRL 

CSA 

CSF 

CSI 

CSMCS 

CSRS 

CSV 

CUG 

D2D 

DAG 

DB 

DECT 

DHCP 

DML 

DMZ 

DNS 

DPNSS 

EA 

EAPC 

EDC 

EIM 

EIMP 

ELM 

EM 

EMS 

ERM 

ESB 

ESS 

FAT 

CIS Operating Authority 

Contract Line Item 

Calling line identification presentation 

Configuration Management 

configuration management database 

Configuration Management Plan 

Contractor-Owned / Contractor-Operated 

Community of interest 

Connected identification presentation 

Add-on conference call 

Concept of Operations 

Commercial Off The Shelf 

Consolidation Points 

Certificate Practice Statement 

Certificate Revocation Lists 

Configuration Status Accounting 

Critical Success Factors 

Continual Service Improvement 

Central Security Management and Control Services 

Community Security Requirements Statement 

Comma Separated Value 

Closed User group 

Disk to Disk 

Database Availability Group 

Database 

Digital Enhanced Cordless Telecommunications 

Dynamic Host Configuration Protocol 

Definitive Media Library 

demilitarized zone 

Domain Name System 

Digital Private Network Signalling System 

Enterprise Architect 

Euro Atlantic Partnership Council 

Effective Date of Contract 

Enterprise Information Management 

Enterprise Information Management Project 

ELement Management 

Executive Management 

Enterprise Management System 

Enterprise Resource Management 

enterprise service bus 

Electronic Security Systems 

Factory Acceptance Tests 





FC 

FCIP 

FCoE 

FE 

FOC 

FPC 

FSA 

FST 

GAL 

GCC 

GH 

GSM 

GUI 

GW 

HN 

HQ 

HQPO 

HTML 

IA 

IAM 

IATO 

ICD 

ICT 

ICTM 

IDP 

IDS 

IEG 

IERs 

IFB 

II 

ILS 

ILSP 

IM 

IMS 

INFOSEC 

IOC 

IOC 

IOSS 

IP 

iPBX 

IPMT 

IPTV 

IS 

Fibre Channel 

Fibre Channel over IP 

Fibre Channel over Ethernet 

front end 

Final Operating Capability 

Full Packet Capture 

Full Systems Acceptance 

Final Site Testing 

Global Address List 

Global Construction Contract 

Guard House 

Global System for Mobile Communications 

Graphics Unit Interface 

Gateway 

Host Nation 

Headquarters 

NATO Headquarters Programme Office 

Hypertext Mark-up Language 

Information Assurance 

Information Assurance Policies & Management 

Interim approval To Operate 

Interface Control Document 

Information, Communications and Technology 

HN NATO HQ ICT Management 

Intrusion Detection and Prevention 

Intrusion Detection System 

Information Exchange Gateway 

Information Exchange Requirements 

Invitation for Bid 

Industrial Infrastructure 

Integrated Logistics Support 

Integrated Logistics Support Plan 


International Military Staff 

Information Security 

Initial Operating Capability 

Initial Operational Capability 

Integrated Operation Support System 

Internet Protocol 

IP Private Branch Exchange 

Integrated Project Management Team 

IP Television 

International Staff 





ISDN 

ISG 

ISO 

ITIL 

ITS 

ITSM 

ITU 

IV&V 

KEB 

KPI 

KVM 

LAN 

LDAP 

MIB 

MMI 

MP 

MPLS 

MS 

MTBF 

MTTR 

NAC 

NAC/NAP 

NATO 

NC3A 

NC3B 

NCIA 

NCIRC 

NCN 

NCSA 

NCIA SMD 

NEDS 

NGCS 

NISP 

NNHQ 

NOCO 

NONO 

NOS 

NPKI 

NQAR 

NR 

NR2 

NRoI 

Integrated Services Digital Network 

Internet Services Gateway 

International Organization for Standardization 

Information Technology Infrastructure Library 

Integration and Testing Services 

Information Technology Service Management 

International Telecommunication Union 

Independent Verification & Validation 

Known Error Database 

Key Performance Indicators 

Keyboard, Video and Mouse 

Local Area Network 

through Lightweight Directory Access Protocol 

Management Information Base 

Man-Machine Interface 

Migration Plan 

Multiprotocol Label Switching 

Mission Secret 


Mean Time To Replace / Repair 

North Atlantic Council 

Network Access Control/Network Access Protection 

North Atlantic Treaty Organisation 

NATO Consultation, Command and Control (C3)Agency 

NATO Consultation, Command and Control (C3) Board 

NATO Communications and Information Agency 

NATO Computer Incident Response Capability 

NATO Core Network 

NATO CIS Support Agency 

NCIA System Management Division 

NATO Enterprise Directory Services 

NATO General purpose segment Communication 


NATO Interoperability Standards & Profiles 

New NATO Headquarters 

NATO-Owned / Contractor Operated 

NATO-Owned / NATO-Operated 

NATO Office of Security 

NATO Public Key Infrastructure 

National Quality Assurance Representative 

NATO RESTRICTED 

Network Realignment and Robustness 

NATO Restricted over the Internet 





NS 

NSVO 

NTERs 

NU 

NVOS 

O&M 

OLA 

ORs 

OS 

OSI 

OSR 

PBS 

PBX 

PDA 

PDF 

PDR 

PFD 

PFE 

PIA 

PIP 

PM 

PMIC 

PMO 

PMP 

PMP 1 

PMS 

PNWI 

POC 

POP 

PPRMs 

PRM 

PSA 

PSR 

PSTN 

PTERs 

PTP 

PTT 

PVLAN 

PWBS 

QA 

QAP 

QAR 

NATO SECRET 

NATO Secure Voice 

National TERs 

NATO Unclassified 

NATO HQ Voice System 

Operations and Maintenance 

Operational level agreement 

Off-specification Reports 

Operating System 

Open Systems Interconnection 

Off-specification Reports 

Product Breakdown Structure 

Private Branch Exchange 

Personal Digital Assistant 

Portable Document Format 

Preliminary Design Review 

Product Flow Diagram 

Purchaser Furnished Infrastructure & Service 

(Equipment) 

Public Internet Access 

Project Implementation Plan 

Project Manager 

Programme Management and Integration Capability 

Project Management Office 


Project Management Professional 

Project Master Schedule 

Passive Network Infrastructure 

Point of Contact 

Point of Presence 

Project Progress Review Meetings 

Project Review Meeting 

Provisional Site Activation 

Project Status Report 

Public Switched Telephone Network 

Partner TERs 

Project Test Plan 

Postal, Telephone, and Telegraph 

Private Virtual Local Area Network 

Project Work Breakdown Structure 

Quality Assurance 

Quality Assurance Plan 

Quality Assurance Representative 





RA 

RMP 

RPO 

RTO 

RTP 

SA 

SAA 

SACEUR 

SACT 

SAN 

SBC 

SC 

SCCM 

SCIP 

SCOM 

SCT 

SDIP 

SDS 

SECAN 

SECOPS 

SFSD 

SHAPE 

SIDs 

SIOP 

SIP 

SISRS 

SIVP 

SLA 

SLM 

SLT 

SMC 

SMDI 

SOW 

SRA 

SRs 

SRS 

SRTP 

SSC 

SSH 

SSO 

SSRS 

SSS 

Registration Authority 

Risk Management Plan 

Recovery point objective 

Recovery time objective 

Real Time Transfer Protocol 

Site Activation 

Security Accreditation Authority 

Supreme Allied Commander Europe 

Supreme Allied Commander Transformation 

Storage Area Network 

Server Based Computing 

Staff Centre 

System Center Configuration Manager 

Secure Communications Interoperability Protocol 

System Center Operations Manager 

Service Certification Tests 

SECAN Doctrine and Information Publications 

System Design Specification 

Security And Evaluation Agency 

Security Operating Procedures 

Single Forest Single Domain 

Supreme Headquarters Allied Powers Europe 

Service Interface Documents 

Service Interoperability Point 

Service Interface Profile 

System Interconnection Security Requirements 

Statement 

Security Implementation Verification Procedures 

Service Level Agreement 

Service Level Management 


Service Management Capability 

Simplified Message Desk Interface 

Statement of Work 

Security Risk Assessment 

Server Rooms 

Security Requirements Statement 

Secure Real Time Transfer Protocol 

Site Security Centre 

Secure Shell 

Single Sign-On 

System-specific Security Requirements Statement 

Schedule of Supplies and Services 





ST&E 

STANAG 

STP 

TAP 

TBA 

TBD 

TCF 

TCO 

TD 

TER 

TETRA 

TL 

ToIP 

TS 

TSR 

UCC 

UPS 

USM 

VACL 

VDC 

VDI 

VLAN 

VoIP 

VoSIP 

VPLS 

VPN 

vSwitch 

VTC 

WAIT 

WAN 

WBS 

WLAN 

XFER 

XML 

Security Test and Evaluation 

Standards NATO Agreement 

Security Test Plan 

Test & Acceptance Plan 

To Be Advised 

To Be Determined 

Technical Communications Facility 

Total Cost of Ownership 

Test Director 

Terminal Equipment Room 

Terrestrial Trunked Radio 

Technical Lead 

Telephony over IP 

Technical Specification 

Technical Specifications Review 

Unified Communications and Collaboration 

Uninterruptable Power Supply 

User-based Security Model 

VLAN Access Control List 

Virtual Device Context 

Virtual Desktop Infrastructure 

Virtual Local Area Network 

Voice over IP 

Voice over Secure IP 

Virtual Private LAN Service 

Virtual Private Network 

Virtual Switch 

Video TeleConferencing 

Call Wait 

Wide Area Network 

Work Breakdown Structure 

Wireless LAN 

Call transfer 

eXtensible Mark-up Language

ANWI Architecture Initial System and Technical View

Create successful ePaper yourself

Delete template?

Save as template?