2 years ago

A step towards achieving greater security

  • Text
  • Achieving
  • Cybersecurity
  • Auvesy
  • Backups
  • Automation
  • Maintenance
  • Copyright
  • Fichtenstrasse
  • Landau
  • Pfalz
  • Technical

A step

A step towards achieving greater security 3. Configuration data is important for customised production. It can be extracted from receptors and energy values. This type of data is often specific to the customer 4. Device logic is the fourth part that makes up a complete backup. In order for disaster recovery to be effective the system (firmware) and the program both need to be compatible. Fig. 1: How a complete backup taken from production can be used for disaster recovery (restoration of a previous version) Classifying data backups is important for documentation. Generally, backups should be always be checked for completeness and accuracy each time data is transported. To be doubly sure, you can also compare checksum of the file(s). A checksum is a value that is derived from the sum of the correct digits in a piece of stored or transmitted data [3]. Checksums can also be used to detect errors in the data. Depending on how complex the rules for calculating checksums are, errors may be detected or ignored. If checksums are equal then the program has remained unchanged. When changes are documented, the version number, time and date, who made the changes, when and why are all included. This is standard practice in production. However, it is often carried out manually by a technician, who goes from machine to machine, performing backups and comparisons of data, and making documentation. WHO changed WHAT, WHEN, WHERE, and WHY, are all questions which those who are involved in maintenance have to ask on a daily basis. In doesn’t matter whether something has been changed between shifts, if a new machine has been integrated, or if a controller on a production line is being fine-tuned. The fact remains that each change that is not documented can lead to uncertainty, regardless of whether the change was authorised or not. It is thus of great importance to ensure the different data types used by a controller are completely and consistently backed up. If they are not, it is not possible to perform rapid disaster recovery. How does disaster recovery work? In order to get a better idea about the challenges involved in disaster recovery, we need look no further than a production facility. The maintenance department is almost always responsible for carrying out disaster recovery. That being said, maintenance is often treated as being separate from office IT, because it requires specific knowledge of how the machine code of a manufacturer works. The maintenance staff member goes Copyright AUVESY GmbH · Fichtenstrasse 38 B · 76829 Landau in der Pfalz Date: 04.06.2018 Page 4 of 6

A step towards achieving greater security around with their programming notebook in hand, which they use to connect to the many and varied components involved in production. As a rule, the data taken from the last data backup is stored in the network, where it is only accessible to those who have been assigned the required rights. Fig. 2: Overview of a backup taken from production for disaster recovery. It is divided into parts based on content, storage and means of identification. In instances where disaster recovery is required, the maintenance staff member copies the last unchanged version, and checks it for consistency, completeness. They also check to see WHO changed WHAT, WHERE, WHEN, and WHY (see Fig. 2). The maintenance staff member then connects to an automation device and downloads the version to the device. Whereupon they compare the version on the device with the last backup on the server. If both versions are identical, then the maintenance staff member knows that everything is as it should be and they document this. If both versions are not identical, differences will be displayed, which will have an effect on production (see Fig. 3). Despite all precautions, some errors do occur that are easy to explain, for instance: a physical defect or a battery outage. Undocumented changes can be the result of human error or, in the worst case scenario, the result of manipulated data. If all lines of defence have been breached, performing a restoration from a backup can help To be able to exploit the vulnerabilities of a system, on the scale of a zero-day threat, is an extraordinarily difficult and thus exceedingly rare task. Nevertheless, the cyberattacks that have occurred in the recent years, which targeted production facilities and critical infrastructures, have shown us just how dangerous such attacks have the potential to be. To safeguard data against such attacks will require a multi-modal cybersecurity strategy. No one single solution has as yet proven to be capable of achieving this. No virus scanner is capable of protecting production in real-time. No software update can be carried out, without the danger of data being manipulated. Copyright AUVESY GmbH · Fichtenstrasse 38 B · 76829 Landau in der Pfalz Date: 04.06.2018 Page 5 of 6

versiondog Factsheets collection

© Copyright 2020 AUVESY GmbH - All rights reserved.