Computing and Network Infrastructure for Controls CNIC

1
Computing and Network Infrastructure for
ControlsCNIC

• Context?
• Why CNIC?
• What is CNIC?
• CNIC Phases and Definitions
• CNIC Status and Manpower
• Conclusion

Uwe Epting on behalf of the CNIC-WG
2
Context

• Control Systems
• Increasing use of standard IT equipment
• Before
• Specific hard- and software solutions
• Today
• Workstations and PCs
• Windows or Linux operating systems
• Increasing use of standard networks (Ethernet,
  TCP/IP)
• Before
• Private networks and fieldbuses
• Today
• Large use of Ethernet and remote monitoring also
  for control systems

3
Why CNIC?

• Security problems
• Increasing risk of virus infections
• Instabilities due to port scans or denial of
  service attacks (DOS)
• Access and equipment manipulation by error (e.g.
  wrong IP address)
• Old unsecure equipment
• No security implemented
• Security updates not available
• Time constraints
• Equipment stop not always possible for applying
  patches
• Important number of equipment needs to be updated
  at the same time
• Beam and physics operation relies on a stable and
  secure environment

4
What is CNIC?

• Working Group delegated by the CERN Controls
  Board
• Mandate covers only control systems, not office
  computing
• Working group for the definition of
• CERN wide security policy
• CERN wide networking aspects
• Operating systems configuration (Windows and
  Linux)
• Services and support
• Members should cover all CERN controls domains
  and activities
• Service providers (mainly IT department)
• Service users (mainly Accelerator and Technical
  Departments)

5
CNIC mandate

• Tools for system maintenance (NICEFC and
  LINUXFC).
• Tools for setting up and maintaining many
  different Controls Network domains. A domain is
  defined to be a collection of systems under a
  single management responsibility.
• Rules and policies for what can be connected to a
  domain and an authorization procedure. For
  example, this should cover wireless
  communications and portable computers.
• Ground rules, policies and mechanisms for
  inter-domain communications.
• Ground rules, policies and mechanisms for
  communications between controls domains and the
  Campus Network (and hence the Internet).
• Document all domains of use and in each case
  obtain from the group(s) concerned the name of
  the person designated to have technical
  responsibility, the person with hierarchical
  responsibility for giving the necessary
  authorization and their backups.
• Investigate with help from IT/CS what technical
  means could be provided to ensure the defined
  policies are complied with, and propose an
  implementation plan.

6
CNIC Phases
Requirements and Definitions Operating
System Network
Implementation
Operation
I
II
III
09/2004
01/2005
07/2005
01/2006

• Phase I - CNIC policy
• DESIGN, SETUP AND OPERATION OF THE CERN CONTROL
  SYSTEM ENVIRONMENT
• Description of concepts
• Definition of terms
• Definition of policies

Main Chapters - Security Policy - Networking
- Operating System and Tools - Services
7
Security Policy

• Network Domains
• Physical network segregation Functional
  Sub-Domains (FSD)
• Hardware Devices
• No USB, modems, CDs, wireless
• Operation System
• Central installation Strategy for security
  patches
• Software
• Development guidelines, installation and test
  procedures
• Logins and passwords
• Traceability, no generic accounts, strong
  passwords
• Training
• Security Incidents and Reporting

8
Networking

• General Purpose Network (GPN)
• Desktop Computing, testing, access from outside,
  
• Technical and Experiment Network (TN and EN)
• Only operational devices
• Authorization procedure
• Inter domain communications
• Application Gateways Trusted services
• Network monitoring and intrusion detection
• Performance and statistics
• Disconnection on breakpoints
• Testing
• TOCSSiC (hostile network environment)

9
Operating System and Tools

• NICEFC and LINUXFC
• Centrally managed and distributed
• Today Windows XP SP2 (NICE XP), Scientific Linux
  CERN 3 (SLC3)
• Named Set of Computers (NSC)
• Groups of computers with identical basic
  configuration
• Responsible persons will be contacted in case
• of emergency and
• if security patches etc. need to be applied.
• Configuration
• Version management database
• Operating System (LINUXFC or NICEFC)
• User defined software packages (e.g. PVSS, )
• Rollback to previous version possible

10
Services

• Operation and Maintenance
• IT support for
• Standard equipment
• Network connections (24h/d, 365d/year)
• Operating System installation
• Security patches
• Test Environment
• Vulnerability Tests (TOCSSiC)
• Integration Tests (test bench per domain
  necessary)
• Hardware Support
• Standard PCs (e.g. office)
• Industrial PCs (a few models should cover most
  requirements)

11
Phase II Implementation
III
II
I
Deployment
Training on policy and tools
Awareness campaign
WTS

• Deployment of CNIC policy

• Implementation of tools forconfiguration,
  management maintenance

• Installation of Windows Terminal Servers

• User Training

12
CNIC Manpower
Tools - development, support Proposal IT 3
persons assigned to IT .
Tools - development, support Proposal IT 3
persons assigned to IT .
Tools - development, support Proposal IT 3
persons assigned to IT .
CNIC policy
approval

• CNIC operation
• - administration
• user support
• Proposal domains
• Foresee 1 person/domain

Awareness campaign
Spec NETWORK tools
Spec LINUXFC tools
Spec NICEFC tools
develop NETWORK

• Packaging support
• - NICEFC
• LINUXFC
• Proposal IT
• 1 person (missing)

develop LINUXFC
develop NICEFC
pilot NETWORK
NETWORK tools operational
pilot LINUXFC
LINUXFC tools operational
pilot NICEFC
NICEFC tools operational
Install
pilot
operation
WTS
WTS Installation, support Proposal IT 1 person
(planned)
TRAINING CNIC policy and tools
deploy CNIC policy
CNIC policy in operation
13
Conclusion

• Awareness and acceptance for changes is very
  important
• Investment vs. advantages
• Decisions and proposals must be backed up by
  management
• Availability of manpower and resources
• Very constructive attitude in the CNIC-WG
• Once people understood the reasons
• Many technical questions and reservations from
  the users
• Treated as Use Cases
• Must be answered with real/practical solutions !
• Difficult to get acceptance
• before tools and examples can be shown.

14
Questions ?
?
Check the CNIC website for more
information http//cern.ch/wg-cnic
15
CNIC members

• TS
• Uwe EPTING - TS/CSE
• Søren POULSEN - TS/EL
• AB
• Pierre CHARRUE - AB/CO
• Mike LAMONT - AB/OP
• Patrick LIENARD - AT/MAS
• IT/CO
• Bruce FLOCKHART - IT/CO
• Stefan LÜDERS - IT/CO
• Experiments
• Beat JOST - PH-LBC
• Guiseppe MORNACCHI - PH/ATD
• Martti PIMIÄ - PH/CMC
• Peter CHOCHULA - PH/AIT

• Network
• David FOSTER - IT/CS
• Jean-Michel JOUANIGOT - IT/CS
• Nils HØIMYR - IT/CS
• Nuno CERVAENS COSTA - IT/CS
• NICEFC
• Alberto PACE - IT/IS
• Ivan DELOOSE - IT/IS
• LINUXFC
• Jan IVEN - IT/ADC
• Matthias SCHRÖDER - IT/ADC
• Security
• Denise HEAGERTY - IT/DI
• Lionel CONS - IT/DI

16
Computing and Network Infrastructure for
ControlsCNIC
Uwe Epting on behalf of the CNIC-WG
17
Use Case 1 - Office connection

• Connection to controls monitoring system (e.g.
  PVSS) from office PC
• Connection to application gateway (e.g. Windows
  Terminal Server).
• Open session to application (e.g. PVSS) with
  connection to controls machine and PLCs.

18
Use Case 2 - Sensitive equipment

• Vulnerable devices (e.g. PLCs) must be protected
  against security risks from the network
• Group them in Functional Sub-Domains (FSD)
• Access only possible from the host system that
  controls them
• External access
• to the host system
• via application
• gateway