CNIC - PowerPoint PPT Presentation

1 / 24
About This Presentation
Title:

CNIC

Description:

CNIC – PowerPoint PPT presentation

Number of Views:511
Avg rating:3.0/5.0
Slides: 25
Provided by: drst8
Learn more at: https://docdb.fnal.gov
Category:
Tags: cnic | bier

less

Transcript and Presenter's Notes

Title: CNIC


1
CNIC
Computing and Network Infrastructure for Controls
  • CyberThreats on the Horizon
  • The CNIC Mandate
  • CNIC Tools for Control Systems Networks
  • The Impact on You
  • Stefan Lüders IT/COJCOP Team Meeting ? July 7th,
    2005

2
Incidents at CERN
  • New Virus / Nouveau Virus
  • (2005/05/30 MyDoom derivatives)

This morning the CERN network was heavily
disturbed (2004/12/15 Network problems)
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 the Internet (2004/5/3 Sasser Worm)
Insecure computers place site at risk DAILY !
3
Change in Trend
2004 1179 incid. 2003 643 2002 123
  • June 2005 101
  • 25 systems compromised(24 Win, 1 LX, 4 VPN)
  • 5 account compromised (all LX)
  • 6 PCs spreading viruses/worms
  • 61 PCs with unauthorized P2P activity (11 VPN)
  • 4 Privacy exposures

4
How do Intruders Break-in?
  • Poorly secured systems are being targeted
  • Weak passwords, unpatched software, insecure
    configurations
  • Known security holes
  • Unpatched systems and applications are a constant
    target
  • Zero Day Exploits security holes without patches
  • Firewall, application and account access controls
    give some protection
  • Break-ins occur before patch and/or anti-virus
    available
  • People are increasingly the weakest link
  • Attackers target users to exploit security holes
  • Infected laptops are physically carried on site
  • Users download malware and open tricked
    attachments
  • Weak/missing/default passwords
  • Beware of installing additional applications

5
Ways to Mitigate
  • Use managed systems when possible
  • Ensure prompt security updates applications,
    patches, anti-virus, password rules, logging
    configured and monitored,
  • Ensure security protections before connecting to
    a network
  • E.g. Firewall protection, automated patch and
    anti-virus updates
  • Use strong passwords and sufficient logging
  • Check that default passwords are changed on all
    applications
  • Passwords must be kept secret beware of Google
    Hacking
  • Ensure traceability of access (who and from
    where)
  • Password recommendations are at
    http//cern.ch/security/passwords

6
CyberThreats on Controls ?
Era of Modern Information Technology
Current SCADA/PCS Zone of Defense
Era of Legacy Process Control Technology (Securi
ty by Obscurity)
7
Control Systems are NOT safe
  • Adoption of Open Standards
  • TCP/IP Ethernet Increasing integration of IT
    and Controls
  • Windows Control O/S can not always be patched
    immediately
  • OPC / DCOM runs on port 135
  • Controls network is entangled with the Campus
    network
  • Use of exposed infrastructure The Internet,
    Wireless LAN
  • Account passwords are know to several (many?)
    people
  • Automation devices have NO security protections
  • PLCs, SCADA, etc.
  • Security not factored into their designs

8
Aware or Paranoid ?
  • Exchange of network equipment
  • Badly designed TCP/IP stack
  • Wide use of ISO protocol

DoS (110) stops any control
9
CERN Assets at Risk
  • People
  • Personal safety (safety alarms transmitted via
    the Ethernet)
  • Equipment (in order of increasing costs)
  • Controls equipment Time-consuming to re-install,
    configure and test
  • Infrastructure process equipment Very expensive
    hardware
  • Accelerator Experiment 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

10
CNIC Working Group
  • Created by the CERN Executive Board
  • Delegated by the CERN Controls Board
  • with a mandate to propose and enforce that the
    computing and network support provided for
    controls applications is appropriate to deal
    with security issues.
  • Members cover all CERN controls domains and
    activities
  • Service providers (Network, NICE, Linux,
    Security)
  • Service users (AB, AT, LHC Experiments, TS)

11
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 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 SCHRÖDER - IT/ADC
  • Security
  • Denise HEAGERTY - IT/DI
  • Lionel CONS - IT/DI

12
Phase I Specification
III
II
I
Awareness campaign
  • Define rules, policies and management structures
  • Define tools for
  • Controls Network Configuration, Management
    Maintenance
  • Control System Configuration, Management
    Maintenance
  • Investigate technical means and propose
    implementation
  • Stimulate general security awareness

13
Approval of Phase I
https//edms.cern.ch/document/584092/1
  • Security Policy
  • Network Segregation Management
  • Network Domains
  • Control System Configuration Management
  • NICEFC LinuxFC
  • Services, Maintenance Support
  • Approval procedure launched

14
Security Policy
  • Network Domains
  • Physical network segregation Functional
    Sub-Domains
  • Hardware Devices
  • Restricted USB no modems, CD-ROMs, wireless
    access,
  • Operation System
  • Central installation
  • Strategy for security patches
  • Controls Software
  • Development guidelines
  • Central installation
  • Strategies for patching and upgrading
  • Development Testing
  • Outside the Domains
  • Logins and Passwords
  • Traceability, restrictions of generic accounts
  • Following IT recommendations
  • Training
  • Awareness Campaign
  • User training on rules tools
  • Security Incidents and Reporting
  • Reporting and follow up
  • Disconnection if risk for others

15
Networking
Desktop Computing (GPN)
  • Technical Network (TN) and Experiment Networks
    (EN)
  • Domain Manager with technical responsibility
  • Only operational devices
  • Authorization procedure
  • Dependencies
  • DNS, NTP, DB, DFS, DIP,
  • Inter-Domain Communications
  • Application gateways
  • Trusted services
  • NetMon and IDS
  • Performance and statistics
  • Disconnection on breakpoints

16
Networking Use Cases
  • Office or Wireless Connectionto Control System
  • Connection to application gateway
  • Open session to application (e.g. PVSS) with
    connection to controls machines and/or PLCs
  • Vulnerable Devices (e.g. PLCs)
  • Protected against security risks
  • Grouped into Functional Sub-Domains
  • Access only possible from the host system that
    controls them
  • External access to the host system via
    application gateway

17
NICEFC LinuxFC
  • NICEFC and LinuxFC
  • Centrally managed and distributed
  • Also for desktop/office PC the current NICE will
    be replaced
  • Named Set of Control Computers (NSCC)
  • Groups of computers with identical 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 (NICEFC or LinuxFC)
  • User defined software packages (e.g. PVSS, )
  • Rollback to previous version
  • Local firewalls, anti-virus, intrusion detection

18
Services
  • Operation, Support and Maintenance (IT Support)
  • 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

19
Phase II Implementation
III
II
I
Deployment
Training on policy and tools
Awareness campaign
  • Deployment of CNIC policy
  • Implementation of tools forconfiguration,
    management maintenance
  • Installation of Windows Terminal Servers
  • Training

20
Phase II Implementation
21
Phase III Operation
III
II
I
Deployment
Op.
Training on policy and tools
Awareness campaign
Operation
  • Review of Effectiveness of Policies and Methods
  • Under real operation
  • Review Possible Changes
  • Incorporating User feedback
  • Extension of the CNIC Membership
  • Finally full separation of TN and GPN

22
Man Power Situation
III
II
I
Deployment
Op.
Training on policy and tools
Awareness campaign
Operation
  • Tools(development support)
  • 3 FTE assigned to IT
  • last FTE arrives 08/2005
  • But No manpower forpackaging
  • WTS Support
  • Originally not foreseen
  • 1 FTE missing in IT
  • CNIC Operation
  • (administration user support)
  • 1 FTE per domain needed

23
What Does Change for YOU ?
  • New Access Scheme
  • Access via application gateways (like WTS,
    LXPLUS, )
  • For all office PCs and wireless access
  • New Connection Policy
  • Connections must be authorized byDomain Manager
  • Easier Installation Procedures for
  • O/S and controls applications
  • Configuration
  • Transparent Procedures for
  • Security patches und updates
  • Installation scenarios
  • Development Testing
  • Must be possible outside on GPN

24
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 Budget Responsible
  • Collect requirements for security cost
  • Assure funding for security improvements
  • As Technical Responsible
  • Assume accountability in your domain
  • Delegate implementation to system responsible

25
Conclusions
  • Adoption of open standards exposesCERN assets at
    security risk.
  • CNIC provides methods for mitigation.
  • CNIC tools are ready soon.

Do YOU act before or after the incident ?
26
Questions ?
  • Domain Responsible Persons
  • GPN IT/CS
  • TN Uwe Epting Søren Poulsen (TS), Pierre
    Charrue, Alastair Bland Nicolas de
    Metz-Noblat (AB/AT)
  • ALICE EN Peter Chochula
  • ATLAS EN Giuseppe Mornacchi
  • CMS EN Martti Pimia
  • LHCb EN Beat Jost

http//cern.ch/wg-cnic
Security Incidents Computer.Security_at_cern.ch Co
mputer Security Info http//cern.ch/security
Write a Comment
User Comments (0)
About PowerShow.com