Choose timezone
Your profile timezone:
Powered by Indico
v3.3.2-pre
Since Stuxnet in 2010, attacks against industrial control systems are regularly reported in the media; new vulnerabilities are regularly published and exploited; and politicians become more and more concerned about the resilience of the control systems controlling a nations critical infrastructure...
Modern accelerator and detector control systems do not differ significantly from the control systems used in industry or devices being part of the "Internet-of-Things" (IoT). Modern Information Technologies (IT) are commonly used, control systems are based more and more on common-of-the-shelf hardware/software (VME, PLCs, VxWorks, LynxOS, network switches, networked controls hardware, SCADA, commercial middleware, etc.) or Windows/Linux PCs. Furthermore, due to the academic freedom in the High Energy Physics community, control systems are produced in a wide, decentralized community, which leads to heterogeneous systems and often necessitates remote access. However, with this adoption of modern IT standards, control systems are also exposed to the inherent vulnerabilities of the corresponding hardware and software. The consequences of a security breach in an accelerator or detector control system might be severe, and attackers won't ignore HEP systems just because it's HEP.
Presentations by several HEP institutes worldwide on the application of Cyber-Security in Control Systems were given at the 5th ICALEPCS conference. This new (CS)2/HEP workshop is intended to continue sharing and discussing counter-measures, to review configuration and development procedures for secure control systems, and to review the progress since the last (CS)2/HEP workshop.
Potential Keywords and topics are:
The Trickle Down Effect: Protecting SCADA systems at the high energy physics lab, SLAC, by minimizing human error through phishing training policy and best practices
Preventing another Stuxnet-like attack means first leveraging training to familiarize staff with what common attacks look like. Stanford’s high energy physics lab, SLAC, recently roll out a simulation phishing exercise and security policy to test and improve real-time responses to phishing emails, familiarize employees with phishing emails, and to raise awareness on the growing impact of phishing. Training was administered through an email that imitates a phishing email. In this presentation and paper, we discuss the important link of phishing training and security training policy to protecting industrial systems in an academic environment that requires flexibility for scientific innovation, the role of the ever-growing Internet of Things (IoT) in securing systems at scientific/government labs, how we notified our user community, how we gained management buy-in, and some of the tips and learnings we discovered along the way to run an interactive, engaging, successful, well-received campaign.
Accelerator control system networks host computing devices and infrastructure vital to the achievement of a research lab's mission. This presentation will outline common issues affecting the computer security of those networks and describe techniques and recommendations which may be applied to allow access to those resources to be regulated, while remaining compatible with working methods within a control system environment.
SOLEIL is a synchrotron facility near Paris, France, opened since 2006.
SOLEIL covers fundamental research needs in physics, chemistry, material sciences, life sciences, earth sciences, and atmospheric sciences.
29 beamlines are currently open to users, with approximately 6300 hours of beamtime and 2500 users per year.
Accelerators and beamlines equipment are controlled using the Tango distributed Object Oriented framework
The talk will present SOLEIL IT teams operational practices to manage cyber security on its Control Systems. In particular the following items will be addressed during the talk:
• Security policies and organisational rules
• Control Systems Overview
• TCP/IP networks topologies and firewalling rules
• Expert connections to the control systems for daily operation
• End users access and authentication rules and practices
• Connection of PCs and network controlled objects to control systems
• Software development cycle and system configuration management
Being conscious that Cybersecurity is (and will be) a major concern in the future, we will also present our short term actions to enhance the present situation , trying to keep a good balance between security and operational needs.
This presentation shows how we protect accelerator networks from unauthorized access and how we pass data to the outside world.
The main purpose of Personnel Safety Systems (PSS) at ESS is to protect workers from the facility’s ionising radiation hazards. Since only proven-in-use COTS components are used in implementing PSS’ safety functions, the software will be developed in accordance with IEC 61511, whilst the system development life-cycle follows a general functional safety standard; IEC 61508. Normal risk assessment processes recommended in these standards are not sufficient to address security threats to PLC-based safety systems. Therefore, some additional measures and solutions are required to improve the system’s security, but these need to be applied in the correct way not to compromise system’s safety.
PSS software configuration management ensures that appropriate methods are implemented for traceability of software elements (including their use, change/modification and destruction) and separate risk assessment based on IEC 62443 standard is being carried out for addressing the information security. This risk assessment will provide additional software requirements (including the software architecture and interfaces with other systems), which shall be implemented as security measures and tested regularly. This session/presentation will cover some of these measures.
Usually in organizations there is often a CISO who is in charge of the IT
security of the company. CISOs are not a member of any particular section
of the company. IT security in practice can be seen from different points
of view depending on the people involved in a specific project. Even in
security by default, section interests may collide. In ALBA there is an
inter-section group called IT Security Coordination group that tries to
gather all the different aspects of the security from the different
sections of the Computing Division and to propose the measures to be
deployed.
The European Organization for Particle Physics (CERN) faces today dif-
ferent types of hardware that gets integrated into the accelerator complex.
While integrating Internet of Things (IoT) devices in mission-critical net-
works with industrial control systems, it puts their directly controlled
assets at risk and possibly endanger the whole connected facility.
IoT devices introduce vulnerabilities, either by malicious intention or by
wrong configuration. For this reason, we scan for IoT devices on CERN
networks on a regular base. We detected unprotected ports for changing
the configuration for printers or thermometers and several web-cams of
the same model that are prone to remote code execution. Attackers can
use remote code execution to gain access to the internal network from the
outside and dig further while operating on a trustworthy device. Based on
these findings, we suggest to run regular scans on any network to detect
IoT devices and check their configurations properly.
Manufacturers and companies distributing COTS devices don’t necessarily give cyber security a high priority, or for small outfits, may not have the expertise to make sure their devices are ‘cyber safe’. As more and more controls devices now come with Ethernet interfaces and many come with some sort of embedded operating system, making sure these devices are ‘safe’ to connect to our networks is becoming a more and more overwhelming task. In this round table discussion, we will share our experiences with COTS devices that were either found to contain malware, act as malware portals (attempt to connect to some sever), or are suspected to be portals for cyber espionage. We will share methods we use to cope with such devices and brainstorm on possible ways to improve our security around them.
RHIC Control System is based on the Accelerator Device Object (ADO) model, and it uses RPC protocol over TCP/IP transport level. The access to any device is managed by corresponding ADO Manager, a C++ or Python program, running on a workstation or a front-end controller. All wired networking equipment is isolated from the rest of the lab behind the strictly maintained department firewall. Each new device, before being wired to the network, passes rigorous certification process. The device access policy is based mainly on access monitoring rather than on the access control. Most of the released client applications provided with a 'Set History' feature, which logs the setting of each ADO parameter into a central database, the user logins are also tracked. The 'Set History' monitoring is attached to the central alarm monitor. In addition, some of the equipment is protected with software locks, based on a file access properties. The 'Set History' monitoring was very useful in investigation of very complex machine failures.
To further improve the access security we began to implement additional features like password protection and lockout-tagout.
Scientific control systems are generally deployed in trusted network environments with passwords, SSH keys, database connection strings, account keys, encryption keys and other secrets stored in a variety of locations such as source code, configuration management systems, and company wikis. Due to the “trust” they are often distributed via insecure methods of communication such as email, instant messaging and word of mouth. Managing secrets is an essential component of a control system with a wide impact. Including: detection of and response to security breaches; enforcement of security policies; management of infrastructure security; granting third party access; and even the effort required to open source a software package. This talk will briefly discuss some of the issues we have come across as we continue to develop the control system for the MeerKAT radio telescope, a precursor to the Square Kilometre Array project. The main focus is an overview of the tool recently selected to manage our secrets: HashiCorp Vault. We are still learning.
How many times you were in a meeting with a sales person and you start to sweat when you hear "yes the system will be fully integrated with your SSO"? How many times have you searched on internet for "SSO" and you closed your browser after the second click? SAML, OAUth, ws-fed... which of these is the right protocol? Shibboleth, OpenAM, ADFS2, CAS... do I need all of them? Do I need them at all? Which is the right solution to my application? How to protect my APIs? This session wants to cover the most popular SSO scenarios and it will guide you in the sometimes obscure path to the "login once and access all" grail.
Potential topics:
* Dealing contractors and sub-contractors (maintenance operations, use of portable devices...)
* USB devices (used for PLCs and system upgrade)... Any specific test protocol before using inside the ICS ?
* Wireless connected plants, wireless communications, device monitoring using wireless systems and security protocols
* How to apply security rules?
* Information security management systems, ISO27001 standards, and risk assessment