ICALEPCS 2005 11 Octobre 2005

1
ICALEPCS 2005 11 Octobre 2005

• Best practices in the design of a secure control
  system

Søren Poulsen CERN, TS Department
2
The presentation

• Context
• Problems
• Methods and solutions
• Results and conclusion
• Perspectives

3
Context - 1

• Technical infrastructure provisioning
• Services for accelerators and experimental areas
  (LHC)
• Cooling
• Ventilation
• Fluid distribution
• Control system examples in the TS
  Cooling/Ventilation group
• Control of production and distribution of chilled
  water for LHC experiments or control of
  air-handling units
• Covers more than 40000 process variables for LHC
  start
• Control and supervision system technologies
• SCADA (PC/Unix-based monitoring and control) -
  50 systems
• PLCs exceeding 200 PLCs for LHC start
• Networking (Ethernet, TCP/IP) and field-buses

4
A typical application
5
Context - 2

• Classic control systems
• Few functions (e.g. an electro-mechanical
  protection relay)
• Functions implemented in hardware rather than
  software
• Stand-alone and proprietary technology (hardware,
  field-bus)
• New controls system architectures
• Distributed software systems
• Network integration
• Integration of process control with general data
  processing
• New technologies and products
• Modular platforms (hardware/OS/application)
• Implemented via standard office modules (e.g. MS
  Office)
• Ethernet/IP replacing field-bus

6
New problems

• Expectations to a control system
• Stable and  Available  (information and
  process available)
• High level of integrity system reflects and
  controls accurately the status of a critical
  process
• Emerging IT security problems and control system
  threats
• Classic security problems and specific to
  control equipment
• In-house threats User errors, malfunctions,
  abuse and theft
• See dedicated talk on Friday Control Systems
  under Attack?
• General solutions for IT security not always
  effective
• Not fit for control systems in general
  (anti-virus?)
• Not fit for existing systems installed for the
  lifetime of the LHC
• Not known by the control system designers or
  manufacturers

7
Solutions The Approach

• Identify problems
• Risk management
• Define objectives
• Availability
• Integrity
• Use what is available
• IT management frameworks
• Security standards ISO/IEC 17799 (not control
  oriented)
• Security models and architectures
• Technologies
• People!

8
Strategies - 1

• Standardising
• Less technologies and less equipment types
• Less versions (NT, Windows 2000, XP)
• Proliferation unavoidable (e.g. operating
  systems)
• Life-cycle of software and process control very
  different
• Objectives and advantages
• Less to learn (configure, operate) training is
  essential
• Less to analyse for potential vulnerabilities and
  stay current
• Consolidating
• Reducing hardware and OS platforms
• Some redundancy unavoidable but at the right
  level
• Objectives and advantages
• Less to maintain and verify in particular when
  no standards

9
Strategies - 2

• Minimizing
• Prioritize functions and user requirements
• Exclude non-essential from core process control
• Keep core functions stable and task-oriented
• Provide new functions outside the core (scope
  creep!)
• Maintaining
• Think about maintenance from the outset (i.e.
  budgets)
• Organize with supplier maintenance contract
• Make internal (automatic) change management
  procedures
• High-availability and patching ?
• Patch when it fits the process and the users
• Protect the system without patching (design)!

10
Architecture

• Modular and distributed
• Map function or tasks to individual modules
• Implement modules via the most secure components
  (PLC)
• Connect over networks and field-buses
• Use private and shared as appropriate (beware of
  shared!)
• Create an architecture of layers, such as
• Core functions
• Non-essential functions
• Optional functions
• How to use layers
• Separation and protection according to layers
  criticality
• Physical or logical implementation
• Network implementation (e.g. private LAN, DMZ,
  public LAN)

11
Layered example

• Core functions (in the PLC)
• I/O
• Process safety (emergency stops) SIL levels ?
• Minimal user interactions (start, stop, verify
  state)
• Redundant/backup functions also available via
  other means
• Non-essential functions (in the SCADA)
• Process visualisation (schematic panels)
• Presentation of states and measurements
• Short-term trending and alarm lists
• Optional functions
• Connections to maintenance management
• Interface to logging database

12
Layered implementation
13
Access control

• What are the requirements?
• Separation and protection between layers
• Physical access control
• Essential to the process and to the users
• Accepted and used Keys, badges
• Logical access control
• Access to terminals and operator displays
• Access to network resources such as Web
  interfaces
• Balance between security/criticality and
  convenience
• Future tools
• Integrate physical and logical access control ?
  Badges ?

14
User management

• What are the requirements ? Linked to access
  control
• Refer to main objectives (e.g. integrity)
• Traceability and least-privilege/Need-to-know
• Define the model
• User role Operator, engineer, administrator
• Access-modes and situations local, remote, web
• Authorizations e.g. rights for local vs. remote
  operation
• Accounts for individual users vs. generic
  accounts?
• Easy answer No but many systems do not support
  users
• Future tools
• Integrate with IT user management
  (authentication) systems?

15
Non-technical issues

• People is more important than all the technology
• Many errors are un-intentional
• Many errors committed by in-house personnel
• People and users is a resource the most
  effective
• but need to see what they can gain with security
• but need training and information to gain
  awareness
• but need clear roles and responsibilities
• Management is the key issue
• Must decide on appropriate security level for
  process
• Must decide on the management tools in place
• Must provide the resources

16
Conclusion

• Important real changes based on these principles
• have been implemented on existing systems
• other changes are planned
• Results obtained so far
• Less interruptions, incidents and time spent on
  maintenance
• More user time spent on operation of process and
  less on solving control system problems
• The real return is the problems that do not
  appear!
• In the future
• Consider these issues during the design/deployment

17
Perspectives

• IT Security is more than technology
• Management and organisation must be in place
• People at all levels must be involved
• IT Security is more than an IT issue
• Also an issue for systems outside the classic
  domains of administrative/office IT
• CERN has taken broader organisation-wide
  initiatives
• Look forward to CNIC presentation, U. Epting,
  today, 1440
• and Controls Systems under Attack?, S. Lüders,
  Friday

18
(No Transcript)