HomeRail NewsUnderstanding Cyber Security

Understanding Cyber Security

Listen to this article

Much continues to be written about cyber security, the threats that exist and the precautionary measures that should be taken. The problem is very real and cyber-attacks take many forms, ranging from critical systems being disabled with implications for safety, through to ransom attacks that demand monetary payments for service to be restored, down to the nerd in the bedroom who finds it fun to use his/her knowledge to get into networks which are supposed to be secure.

At best it is inconvenient; at worst it can put an entire business at risk.

Even now, there is a casual attitude to the threats by some businesses, with a few still believing “it can’t happen to us”. They are wrong, as the correct thinking is “it will happen to us, we just don’t know when or in what form”. Part of the problem is that preventative measures cost money and senior management has a reluctance to spend that money on things they don’t properly understand.

Instead, the cyber security situation is often addressed by in-house IT experts who produce information documents, written in IT-speak that further baffles the directors. A means of making it all simpler would be to the benefit of all.

The rail industry is diverse and cyber intrusions have been noticed in many disciplines. A recent talk given to the Institution of Railway Signal Engineers by Alzbeta Helienek (known as Betty) and Mathijs Arends, both from Ricardo Rail based in Holland, explained a means of making cyber security more understandable to people who need to make decisions on what to do.

Betty also sits on the UK Cyber Security Council so has much wider experience than just the railway and signalling industry.

Cyber security and rail

An opening remark by the IRSE President was salutary; in 1963, the then British Rail experienced the Great Train Robbery, where a mail train from Glasgow to London was ambushed en route with several million pounds being stolen. To stop the train, the gang false-fed a signal to red, having gained some insider knowledge. The incident was reported worldwide and has achieved an element of notoriety. In those days, IT had barely been invented, but it demonstrates what can be achieved by those with intent on malice.

Nowadays, the railway has an interconnected infrastructure to produce efficient operations and needs a geographically wide intelligent device network. Many factors emerge from this, including the all-important safety implications, the opportunities for remote control, predictive maintenance activities and a whole host of economic factors. It introduces the concept of OT (operational technology) to sit alongside the IT (information technology) requirements.

Such a structure will inevitably result in cyber attacks and it begs the question as to whether rail can be insecure but still safe, with the answer being a definite “No”. Incidents can cause the destruction of equipment and risk to lives.

In the past, incidents have occurred in Florida (2003), Poland (2008), Iran (2010) and Germany in 2017, this latter being a ransomware attack on passenger information systems (PIS). Some incidents occur where the affected organisation is not the intended target – the German PIS attack was aimed at the Polish power network. It only emphasises the interconnected nature of data networks globally. Making it all understandable is a real challenge.

Developing the idea

The starting point has to be examination of standards and directives which already exist. As would be expected, there are many of them. At the highest level are the ISO 27000 series, followed by ISA/IEC 62443. The latter is aimed at automation and control systems but is very much IT-expert orientated.

Next are the EU Directives, including GDPR (General Data Protection Regulations), which set out a legal framework for compliance. This has caused much confusion within organisations, big and small, as to the steps needed to comply and the penalties for not doing so.

Then there are national and industrial guidelines, including some produced by the Department for Transport and Network Rail in the UK. Is it small wonder that people are confused by all of this with the risk of ‘eyes glazing over’?

There is a general consensus that the problem has to be progressed in five steps:

Identify > Protect > Detect > Respond > Recover

But this is too bland to be practically understood and OWASP (Open Web Application Security Project) listed the progression in a different manner:

Governance > Design > Implementation > Verification > Operations

Aimed primarily at focussing on a suitable management structure, this is also considered too technical and is aimed primarily at IT professionals.

Focussing on Rail

Nothing appropriate was found that would be easily applicable to rail engineers and managers. Looking, therefore, at the five-level structure, this needs to take account of:

  • improvements needed within the organisation covering management and documentation
  • improvements in scope to recognise the need for greater coverage and better tooling, and
  • a combination of both these.
  • This results in:
  • Recognise the problems
  • Set out basic principles
  • Define a strategy
  • Capture knowledge of what is going on in the network
  • Produce an active organisation to defend against attack including associated safety risk.

Having got the headings, these now need to be turned into meaningful disciplines and specialisms that can be understood:

  • People – probably the most vulnerable threat, as this not only includes lax work ethics (careless email activity, computers and CDs left unattended, poor record keeping) but also insider criminal and bribery opportunities;
  • Risk – training employees to recognise where risks will occur and what to look for will result in a much better appreciation of cyber threats and their impact on safety critical systems;
  • Technical countermeasures – putting in place technology that can both detect and counteract cyber attacks may make use of proprietary systems, but will often require specialist detection software to be designed;
  • Integration with Safety – there is often a tension between safety and security interests as the precautionary measures for these may be very different. Safety measures tend to be based on well proven designs to prevent what was always known as ‘wrong side failures’. Security threats are uncontrollable in how they will appear and in what form. The now universal use of solid state interlockings and data-driven distribution of signalling information still creates unease amongst traditional signal engineers and security threats only add to this. The possibility that train services might be adversely affected makes matters worse.
  • Incident Management – acceptance that no countermeasures will ever be 100% perfect is a pragmatic approach, as attacks will always happen. From this, do not try and build ‘Fort Knox’, but be in a state of readiness to observe a problem and take the appropriate remedial action to minimise or eliminate the impact which may include shutting down systems for a short period of time.

Matrix

Taking all these factors into account, the adjacent 5×5 matrix has been developed with 25 questions – all of which can be answered ‘Yes’ or ‘No’ – to give a check list on where an organisation is.

Somewhat similar to the well-known risk assessment matrix, it would be possible to score 25 if all answers are ‘Yes’. However, not all organisations will need to have a Yes to every box and a first step might be to decide what is applicable and what is not. A company not engaged in manufacturing or deploying safety-related products or systems may not need to consider these aspects. The most important thing is to have a security training programme in place, as attacks can occur very quickly and need to be picked up straight away.

The matrix has been tested in a few organisations and most have welcomed it. Some responses indicate that there remains work to do – ‘I don’t know where to start’, ‘It seems like a lot of extra work and just adds to the cost’, ‘I put everything in the cloud and they look after it for me’.

To combat this negativity and/or ignorance, organisations are encouraged to try the matrix out as a managerial directive and produce some feedback. This should determine some priorities and where to focus next. Maybe a question to ask is ‘How can I improve security in the next six months or year?’

One question already asked is ‘Can it be applied to projects?’ and of course the answer is ‘Yes’. It is expected that the matrix will go through a number of iterations and will thus be updated from time to time, so any comments, suggestions or criticism would be welcomed by Rail Engineer; we will pass these to the authors.

Remember that, whilst this talk was aimed at a signalling audience, it is equally applicable to rolling stock, operational planning and all other infrastructure elements.

Clive Kessell
Clive Kessellhttp://therailengineer.com
SPECIALIST AREAS Signalling and telecommunications, traffic management, digital railway Clive Kessell joined British Rail as an Engineering Student in 1961 and graduated via a thin sandwich course in Electrical Engineering from City University, London. He has been involved in railway telecommunications and signalling for his whole working life. He made telecommunications his primary expertise and became responsible for the roll out of Cab Secure Radio and the National Radio Network during the 1970s. He became Telecommunications Engineer for the Southern Region in 1979 and for all of BR in 1984. Appointed Director, Engineering of BR Telecommunications in 1990, Clive moved to Racal in 1995 with privatisation and became Director, Engineering Services for Racal Fieldforce in 1999. He left mainstream employment in 2001 but still offers consultancy services to the rail industry through Centuria Comrail Ltd. Clive has also been heavily involved with various railway industry bodies. He was President of the Institution of Railway Signal Engineers (IRSE) in 1999/2000 and Chairman of the Railway Engineers Forum (REF) from 2003 to 2007. He continues as a member of the IRSE International Technical Committee and is also a Liveryman of the Worshipful Company of Information Technologists. A chartered engineer, Clive has presented many technical papers over the past 30 years and his wide experience has allowed him to write on a wide range of topics for Rail Engineer since 2007.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.