Download TU3_1-3O - icalepcs 2005

ICALEPCS 2005
11 Octobre 2005
Best practices in the design of a secure
control system
Søren Poulsen
CERN, TS Department
1
The presentation
Context
Problems
Methods and solutions
Results and conclusion
Perspectives
2
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
3
A typical application
4
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
5
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
6
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!
7
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
8
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)!
9
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 layer’s criticality
 Physical or logical implementation
 Network implementation (e.g. private LAN, DMZ, public LAN)
10
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
11
Layered implementation
12
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 ?
13
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?
14
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
15
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
16
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, 14:40
 and “Controls Systems under Attack?”, S. Lüders, Friday
17
18