Project Requirements

Introduction

This document summarizes the requirements and their implementation for running NICE PC systems in control system environments as determined by the CNIC working group. The listed requirements are a based on the 'O/S Support for Control System: 'NICEFC' and 'LINUXFC' document.

Note that the original document refers to Named Set of Controls Computers ('NSCC'), which is generalized in NICE Computer Management Framework as Named Set of Computers ('NSC'), since this Framework will also be used in other non-controls specific environments.

Requirements & Solutions

1. The person responsible for a particular distributed controls application must be able to define a Named Set of Controls Computers ('NSC') and also sub-sets of NSCs with specific configurations.

   The Framework supports Names System Sets (NSS), where several Named Set of Computers can be attached to. More information about the Framework concept (NSS ' NSC & PKG) is available in the 'The NICE Computer Management Framework - Technical Specifications' document.

2. For each NSC, the possibility of installing a defined version of the basic operating system.

   The DianeCD provides a list of centrally supported OS versions, depending on the hardware. Restore from images (snapshots) via the DianeCD will be provided later this year.

3. For each NSC, the possibility of installing a defined set of layered software products or additional system features required for the equipment controlled.

   Covered by group memberships to NSCs which are applied to Packages (PKG).

4. For each NSC, updates and/or patches to the O/S and layered products must be installed only according to an agreed schedule defined by the person responsible.

   Provided by the 'Locally Managed' attribute in NSCs.

5. In certain critical situations, such as the detection of new and exploitable vulnerabilities, an emergency procedure must be available to perform interventions on the NSCs concerned.

   The NSC Admins can unblock the deployment of pending Packages by removing the NSC from the Deny collection(s). It is also possible to create a new PKG defining the emergency procedure.

6. The network operation team must be able to disconnect machines that make denial-of-service attacks or propagate worms in the controlled network.

   This requirement is not part of NICEFC.

7. For each NSC, automatic virus scans must be run according to the schedule of the person responsible for the equipment.

   An anti-virus scan can be launched by the NSC Admin on all members at any time. Centrally managed scan will be disabled on NSCs with 'Locally Managed' attribute set.

8. Zephyr messages should not be broadcast to NSC machines unless specifically agreed by the person responsible for the equipment.

   Can be blocked by denying the installation of the Zephyr PKG for concerned NSC(s).

9. A mechanism will be required to contact the person responsible for a NSC, or their stand-in, in the case that emergency action is required. The contact information must be available through the Netops database.

   The responsible of the NSC will be stored in the Framework and available through a dedicated web page. Other information such as delegated administrators, main NSS responsible and admins will also be available.

10. It should be possible to set-up a single PC with the same profile as the required configuration of the NSC, in order to test that the relevant application will run with a new system version or patch.

    A dedicated NSC, having the test computers as members, is included in the operational NSC and is also applied to the test PKG(s).

11. It should be possible to 'roll-back' to the previous operating system or software version, or remove a down-loaded patch, if it is later discovered that the update causes an application to fail.

    Any deployed PKG can be un-installed by the Framework by removing the NSC from the Applied collection of adding it to the Deny collection, but only if the PKG supports un-installation. Note that not all patches can be uninstalled. In this case, a system snapshot before the installation of each PKG is the only way to support a rollback. The feature is implemented in the 'Snapshot Level' attribute of a NSC.

12. In case of complete failure of a machine, it must be possible to install a new instance of a particular machine (clone) 'automatically'.

    Provided by DianeCD and Framework NSC memberships which are preserved by default during re-installation.

13. Tools must be provided to create and apply (distribute) user defined patches to a NSC, such as patches to the user's application and application configuration files (local databases), etc.

    The Framework provides the creation several types of Packages (PKG) which can be applied to NSCs inside the same NSS. However, the support of creation/design of MSI packages, VB scripts, scheduled tasks in not covered by the Framework.

14. It may be necessary to install and configure local firewalls on machines used for controls applications. Controls must be in place to manage the personal firewall configurations centrally and supervise and audit the firewall log files. On the transport level of TCP/UDP/ICMP, it must be possible to configure the services that the machine offers or requires. On the network (IP) level it must be possible to specify the machines that are allowed to communicate (the network level protection can be implemented between the machines via layer-3 network equipment and is therefore not dependant on the control computers themselves).

    As of Windows XP SP2, the local firewall can be managed through Group Policies, which can be applied to NSCs through a 'Policy settings' PKG type.

15. It will be necessary to make available to the system manager of each NSC, a remote management tool, such as SMS which would, for example, allow them remotely to review system status or even force a reboot of a particular computer. 

    The Remote Desktop on Windows XP provide this feature.

16. A centralised configuration management database must be put in place that shows detailed information for each computer (the OS, patch level, application version, etc).

    The middle layer of the Framework consists of a central database hosting configuration and status information of all Windows clients. Several web pages will provide user-friendly interfaces to this data.

17. It must be possible to audit the set of computers belonging to the NSC against a configuration baseline as defined in a configuration database and identify non-conformities.

    Reporting web pages will make this information available. Data can be retrieved for a simple computer of NSC.

18. All user identification, authentication and authorization management must be performed via centralised authentication servers and services. The person responsible for a system must be able to define access rights and authorizations via centralized services.

    The NICE central services, based on Windows Active Directory, are used as common authentication service. A NSS or NSC administrator will be able to set permissions inside his context. Permissions are delegated as described in the 'The NICE Computer Management Framework - Technical Specifications' document.

Managerial Issues

1. Each NSC must correspond to a recognized service and have a well-defined list of persons responsible for the system. It will be necessary to store the names of the persons responsible for systems as well as their Email addresses and telephone numbers in the Netops database.

   In fact, each NSS (more global than NSC) will correspond to a service, system or domain. A NSS is a collection of several NSCs and PKGs, but they can have their own specific sub-administrators. The NSS is the direct link with the NICE central services, referenced as the master NSS. All information about NSS contact information will be stored in the Framework database and available through web pages.

2. An authorization mechanism will need to be put in place to define who is allowed to request the setting up of a NSC. The agreement of the relevant group leader or domain responsible and some sort of justification would be required. This authorization chain has to be handled electronically.

   As described in the 'The NICE Computer Management Framework - Technical Specifications' document, a NSS can only be created by the NICE central services, after agreement from the people involved. The creation of a NSC inside a NSS is decided by the NSS responsible, who can delegate this action by adding 'Delegated Admins' to the NSS. The newly created NSCs can on their turn being delegated.

3. The persons responsible for a NSC may be required by the CERN Computer Security Officer (CSO) to install upgrades and/or patches at either an agreed date and time, or even immediately, if a sufficiently serious situation develops.

   Most of the OS critical patches will be provided by the master NSS (NICE central services), but a NSC admin can always apply his own packages (PKG) inside his context.

4. The CSO has the full authority to demand disconnection of any machine or device connected to the CERN network that does not comply with the CERN computing rules, or is threatening or is risks to threaten the integrity and availability of the CERN computing and networking infrastructure.

   This requirement is not part of NICEFC.