CNIC

1
CNIC
Computing and Network Infrastructure for Controls

• Why CNIC?
• Technical Propositions.
• Impact on you !?
• Use Cases Examples

• Pierre Charrue AB/CO

2
Goals of this presentation

• Explain why CNIC was created
• Describe CNIC mandate
• Propose technical proposals and deployment
  schedule
• Explain what will change for the users
• Get some feedback from the users

3
Incidents at CERN
This morning the CERN network was heavily
disturbed. (2004/12/15 Network problems)

• A new virus is spreading on computers as of 22
  October
• (2004/10/22 Virus W32.Bagz.E_at_mm)

It has been confirmed that the network problems
during the week-end were due to a security
break-in. (2004/6/7 General network problem)
A major worm (similar to Blaster) is spreading
on Internet (2004/5/3 Sasser Worm)
4
CyberThreats at CERN

• May 2005 81 incidents
• 36 Windows systems compromised (4 using VPN)
• One account compromised (used to originate a DoS
  attack)
• 6 PCs spreading viruses/worms
• 38 PCs with unauthorized P2P activity (9 via VPN)

• January 2005 91 incidents
• 23 systems compromised (22 Windows, 1 Linux)
• 1 CERN account compromised
• 14 PCs at CERN spreading viruses/worms
• 53 PCs with unauthorized P2P activity (9 via VPN)

• February 2005 83 incidents
• 20 systems compromised (18 Windows, 1 Linux, 1
  VPN)
• 2 CERN accounts compromised
• 4 PCs at CERN spreading viruses/worms
• 57 PCs with unauthorized P2P activity (11 via VPN)

• March 2005 70 incidents
• 15 systems compromised (12 Windows, 3 Linux)
• 2 CERN accounts compromised
• 2 PCs at CERN spreading viruses/worms
• 51 PCs with unauthorized P2P activity (13 via VPN)

• April 2005 67 incidents
• 19 systems compromised (17 Windows, 2 Linux)
• 1 CERN account compromised
• 9 PCs at CERN spreading viruses/worms
• 38 PCs with unauthorized P2P activity (7 via VPN)

5
Control Systems are NOT safe

• O/S can not always be patched immediately
• Account passwords are known to several/many
  people and not changed
• Automation devices (PLCs, SCADA) have NO security
  protections
• The Controls network is entangled with the
  general office network (Campus network)

6
CERN Assets at Risk

• People
• Personal safety (safety alarms transmitted via
  the communication network)
• Equipment (in order of increasing costs)
• Controls equipment Time-consuming to re-install,
  configure and test
• Infrastructure process equipment Very expensive
  hardware
• Accelerator hardware Difficult to repair
• Process
• Many interconnected processes (e.g. electricity
  and ventilation)
• Very sensitive to disturbances
• A cooling process PLC failure can stop the
  particle beam
• A reactive power controller failure can stop the
  beam
• Difficult to set up
• Requires many people working, possibly
  out-of-ordinary hours

7
Goals of this presentation

• Explain why CNIC was created
• Describe CNIC mandate
• Propose technical proposals and deployment
  schedule
• Explain what will change for the users
• Get some feedback from the users

8
The CNIC Working Group

• Delegated by the CERN Controls Board
• Mandate covers control systems only, not office
  computing
• Definition of
• Security policy
• Networking aspects
• Operating systems (Windows and Linux)
• Services and support
• Members cover all CERN controls domains and
  activities
• Service providers (Network, NICE, Linux,
  Security)
• Service users (AB, AT, LHC Experiments, TS)

9
CNIC Members
TS Uwe EPTING - TS/CSE Soren POULSEN -
TS/EL AB Pierre CHARRUE - AB/CO Mike LAMONT -
AB/OP Patrick LIENARD - AT/MAS IT/CO Bruce
FLOCKHART - IT/CO Stefan LUEDERS -
IT/CO Experiments Beat JOST - PH-LBC Guiseppe
MORNACCHI - PH/ATD Martti PIMIA - PH/CMC Peter
CHOCHULA - PH/AIT
Network David FOSTER - IT/CS Jean-Michel
JOUANIGOT - IT/CS Nils HOIMYR - IT/CS Nuno
CERVAENS COSTA - IT/CS NICEFC Alberto PACE -
IT/IS Ivan DELOOSE - IT/IS LINUXFC Jan IVEN -
IT/ADC Matthias SCHROEDER - IT/ADC Security Denis
e HEAGERTY - IT/DI Lionel CONS - IT/DI
10
CNIC Mandate

• Define tools for system maintenance (NICEFC and
  LINUXFC).
• Define tools for setting up and maintaining
  differentControls Network domains.
• Designate person to have overall technical
  responsibility.
• Rules, policies and authorization procedure for
  what can be connected to a domain.
• Ground rules, policies and mechanisms for
  inter-domain communications and communications
  between controls domains and the Campus Network.
• Investigate technical means and propose
  implementation plan.
• Stimulate general security awareness.

11
Goals of this presentation

• Explain why CNIC was created
• Describe CNIC mandate
• Propose technical proposals and deployment
  schedule
• Explain what will change for the users
• Get some feedback from the users

12
CNIC Phases
Design, Setup and Operation of theCERN Control
System Environment Description of
concepts Definition of terms Definition of
policies
Main Chapters - Security Policy - Networking
- Operating System and Tools - Services
Deliverables and Milestones Definition concrete
deliverables, responsibilities, and dates
13
Security Policy

• Network Domains
• Physical network segregation Functional
  Sub-Domains
• Hardware Devices
• No USB, modems, CD-ROMs, wireless access
• Operation System
• Central installation of Windows or Linux
• Strategy for security patches
• Software
• Development guidelines, installation, patching
  and test procedures

14
Security Policy (contd)

• Logins and passwords
• Traceability, no generic accounts
• Following IT password recommendations
• Training
• Awareness Campaign (this presentation !)
• User training (rules, tools)
• Security Incidents and Reporting
• Reporting and follow up
• Disconnection if risk for others

15
Networking

• General Purpose Network (GPN)
• For office, mail, www, development,
• No formal connection restrictions by CNIC
• Technical Network (TN) and Experiment Network
  (EN)
• For operational equipment
• Formal connection and access restrictions
• Limited services available (e.g. no mail server,
  no external web browsing)
• Authorization based on MAC addresses
• Network monitored by IT/CS

16
Operating Systems Tools

• NICEFC and LINUXFC
• Centrally managed and distributed
• Named Set of Control Computers (NSCC)
• Groups of computers with identical basic
  configuration
• Responsible persons will be contacted in case
• of emergency, or
• if e.g. security patches need to be applied.
• Configuration
• Version management database
• Operating System (LINUXFC or NICEFC)
• User defined software packages (e.g. PVSS, )
• Rollback to previous version
• Local firewalls

17
Services

• Operation, Support and Maintenance
• Standard equipment
• Network connections (24h/d, 365d/year)
• Operating System installation
• Security patches
• Test Environment
• Vulnerability Tests (e.g. TOCSSiC)
• Integration Tests (one test bench per domain)
• Hardware Support
• Standard (office) PCs
• Industrial PCs

18
Activities and Deliverables

• Define and deploy LINUXFC and NICEFC
• Deploy and setup Application Gateways
• Select and implement real use case with Users
• Prepare the TN and EN separation
• In the middle of 2006, when all proposed
  technical solutions and support are available and
  supported, disable the GN to TN/EN connectivity

19
Goals of this presentation

• Explain why CNIC was created
• Describe CNIC mandate
• Propose technical proposals and deployment
  schedule
• Explain what will change for the users
• Get some feedback from the users

20
What Does Change for YOU ?

• Connection policy
• Connections must be authorized by domain
  responsible person
• Installation procedure
• O/S to be installed
• Configuration
• No direct access from office to control systems
• Access via application gateways (WTS, lxplus, )
• Tests Development
• Must be possible outside operation (on GPN)
• Procedures for
• Security patches
• Installation scenarios
• Generic accounts restrictions

21
Use Cases
Office Connection to Control System Connection
to application gateway Open session to
application (e.g. PVSS) with connection to
controls machine and/or PLCs
22
Use Cases
Sensitive Equipment Vulnerable devices (e.g.
PLCs) must be protected against security risks
from the network Grouped into Functional
Sub-Domains Access only possible from the host
system that controls them External access to the
host system via application gateway
23
What do YOU have to do ?

• As hierarchical supervisor
• Make security a working objective
• Include as formal objectives of relevant people
• Ensure follow up of awareness training
• As technical responsible
• Assume accountability in your domain
• Delegate implementation to system responsible
• As budget responsible
• Collect requirements for security cost
• Assure funding for security improvements

24
Next Actions in AB Controls

• Have an Application Gateway installed in 513
  end of June 2005
• Install some client software (PVSS client, PLC
  software, JAVA JRE, ) July 2005
• Run real application for the HWC via this
  Application Gateway Mid-July 2005 onwards
• Make tests from wireless laptops from the LHC
  tunnel to access equipment via this Application
  Gateway mid-July 2005

25
Goals of this presentation

• Explain why CNIC was created
• Describe CNIC mandate
• Propose technical proposals and deployment
  schedule
• Explain what will change for the users
• Get some feedback from the users

26
Questions ?

• Domain responsibles
• GPN IT/CS
• TN Uwe Epting Søren Poulsen (TS), Pierre
  Charrue, Alastair Bland Nicolas de
  Metz-Noblat (AB/AT)
• ALICE EN Peter Chochulat
• ATLAS EN Giuseppe Mornacchi
• CMS EN Martti Pimia
• LHCb EN Beat Jost

Incidents Computer.Security_at_cern.ch
http//cern.ch/wg-cnic