Σχεδιασμός εφαρμογών HMI/SCADA με γνώμονα την κυβερνοασφάλεια – αρχές που μειώνουν τον κίνδυνο ήδη από το στάδιο του σχεδιασμού

Η ασφάλεια μιας εφαρμογής HMI/SCADA καθορίζεται πολύ νωρίτερα από το στάδιο επιλογής των μηχανισμών προστασίας. Το αν το σύστημα θα είναι ανθεκτικό σε λάθη, καταχρήσεις και ανεξέλεγκτες μεταβολές της κατάστασης της διεργασίας εξαρτάται πρωτίστως από τις παραδοχές που έχουν υιοθετηθεί στον σχεδιασμό: τον διαχωρισμό ρόλων, τα όρια εμπιστοσύνης, το εύρος των λειτουργιών που είναι διαθέσιμες μέσω της διεπαφής, καθώς και τον τρόπο οργάνωσης της συντήρησης και της απομακρυσμένης πρόσβασης. Αν αυτά τα ζητήματα αντιμετωπιστούν ως δευτερεύοντα, η εφαρμογή θα αρχίσει να παγιώνει τον κίνδυνο αντί να τον περιορίζει. Γι’ αυτό ο σχεδιασμός HMI/SCADA με γνώμονα την κυβερνοασφάλεια πρέπει να αντιμετωπίζεται ως έργο μηχανικής: πρώτα να καθορίζεται ποιες λειτουργίες είναι κρίσιμες, ποιες συνέπειες μπορεί να έχουν και ποιος πραγματικά πρέπει να μπορεί να τις εκτελεί, και μόνο στη συνέχεια να σχεδιάζονται οι οθόνες, οι συναγερμοί και η ευχρηστία χειρισμού.

Η κυβερνοασφάλεια ξεκινά από τον σχεδιασμό

Στα συστήματα HMI/SCADA, η κυβερνοασφάλεια δεν είναι ένα πρόσθετο στοιχείο πάνω σε μια έτοιμη οπτικοποίηση. Προκύπτει από αποφάσεις που έχουν ληφθεί νωρίτερα: από την αρχιτεκτονική της εφαρμογής, το μοντέλο δικαιωμάτων, τον τρόπο επικοινωνίας με το σύστημα ελέγχου και τις παραδοχές για τη συντήρηση. Αυτό έχει ιδιαίτερη σημασία, επειδή η εφαρμογή HMI/SCADA αποτελεί ταυτόχρονα σημείο επαφής ανθρώπου, διεργασίας και υποδομής. Επομένως, ένα σφάλμα σχεδιασμού δεν περιορίζεται μόνο σε κίνδυνο πληροφορικής. Μπορεί ταυτόχρονα να επηρεάσει την αντίδραση του χειριστή, τη λειτουργική ασφάλεια, τον επιχειρησιακό κίνδυνο και τη συνέχεια της παραγωγής.

Από τη σκοπιά του σχεδιασμού, το βασικό ερώτημα δεν είναι λοιπόν ποιο μέτρο προστασίας θα προστεθεί στο τέλος, αλλά ποιες αποφάσεις από την αρχή θα περιορίσουν την επιφάνεια επίθεσης. Τα μεγαλύτερα προβλήματα συνήθως δεν προκύπτουν από την απουσία ενός μεμονωμένου μηχανισμού, αλλά από την υπερβολική εμπιστοσύνη που έχει ενσωματωθεί στην εφαρμογή. Στην πράξη αυτό σημαίνει κοινόχρηστους λογαριασμούς χρηστών, ευρεία και μόνιμη πρόσβαση για συντήρηση, έλλειψη διαχωρισμού ρόλων μεταξύ χειριστή, συντήρησης και integrator, καθώς και υπερβολικά ελεύθερη επικοινωνία μεταξύ του επιπέδου χειρισμού και του συστήματος ελέγχου. Στο στάδιο της θέσης σε λειτουργία, τέτοιες λύσεις φαίνονται βολικές, επειδή επιταχύνουν τις εργασίες και διευκολύνουν τη διάγνωση. Αργότερα όμως γίνονται μόνιμο χαρακτηριστικό του περιβάλλοντος και αυξάνουν τον κίνδυνο κατάχρησης, σφάλματος ή ανεξέλεγκτης μεταβολής της κατάστασης της διεργασίας.

Γι’ αυτό, πριν από τον σχεδιασμό των οθονών, αξίζει να καθοριστεί όχι μόνο τι πρέπει να βλέπει ο χρήστης, αλλά κυρίως πού βρίσκονται τα όρια εμπιστοσύνης, ποιες λειτουργίες είναι κρίσιμες και σε ποια σημεία η διεπαφή μπορεί να μετατραπεί σε εργαλείο σφάλματος ή παράκαμψης διαδικασίας. Αυτή η σειρά βοηθά να οργανωθούν οι επόμενες αποφάσεις: αν το HMI θα είναι αποκλειστικά επίπεδο οπτικοποίησης ή και χώρος παραμετροποίησης, διάγνωσης και αλλαγής συνταγών· αν οι λειτουργίες συντήρησης θα είναι διαρκώς ενεργές ή μόνο μετά από συνειδητή ενεργοποίηση· αν ο χειριστής θα έχει πρόσβαση μόνο στη λειτουργία της διεργασίας ή και σε ενέργειες που αλλάζουν παραμέτρους και το ιστορικό δεδομένων.

Το πρακτικό κόστος των παραλείψεων συνήθως γίνεται ορατό μόνο όταν η εφαρμογή έχει ήδη συνδεθεί με συνταγές, συναγερμούς, αναφορές, αρχειοθέτηση και διαδικασίες συντήρησης. Τότε ακόμη και μια φαινομενικά απλή διόρθωση, όπως ο διαχωρισμός λογαριασμών, η αλλαγή της διαδρομής έγκρισης μιας κρίσιμης λειτουργίας ή ο περιορισμός της απομακρυσμένης πρόσβασης σε περιστασιακή χρήση, παύει να είναι απλώς μια αλλαγή στις οθόνες. Απαιτεί ανασχεδιασμό της λογικής, επανέλεγχο του χειρισμού συναγερμών, καθορισμό ευθυνών και συχνά επίσης οργανωτικές αλλαγές στην εγκατάσταση.

Στην πράξη, το πιο λογικό σημείο εκκίνησης είναι ένας λειτουργικός χάρτης των ρόλων χρηστών και των δικαιωμάτων τους σε κρίσιμες λειτουργίες, μια λίστα λειτουργιών που προκαλούν μεταβολή της κατάστασης της διεργασίας, της παραμετροποίησης ή των συνταγών, καθώς και ένας κατάλογος εξωτερικών συνδέσεων που περιλαμβάνει συντήρηση, αναφορές, ανώτερα συστήματα και απομακρυσμένη πρόσβαση. Μόνο πάνω σε αυτή τη βάση μπορεί να σχεδιαστεί με ουσιαστικό τρόπο η αρχιτεκτονική ζωνών και συνδέσεων και να προετοιμαστεί η μεταγενέστερη ανάλυση κινδύνου. Αυτή η προσέγγιση ανταποκρίνεται τόσο στην πρακτική της μηχανικής όσο και στις απαιτήσεις για σαφή κατανομή ευθυνών, διαχωρισμό λειτουργιών και έλεγχο της επικοινωνίας σε βιομηχανικά περιβάλλοντα.

Πού αυξάνονται πραγματικά το κόστος και ο κίνδυνος

Το μεγαλύτερο κόστος και ο κίνδυνος σε μια εφαρμογή HMI/SCADA δεν προκύπτουν αποκλειστικά από το ίδιο το γεγονός της διασύνδεσης συστημάτων, αλλά από τις επιπτώσεις που προκαλούν στη διεργασία και στην οργάνωση οι επιμέρους λειτουργίες της εφαρμογής. Τα πιο ευαίσθητα σημεία είναι εκείνα που επιτρέπουν γρήγορη αλλαγή ρυθμίσεων, εισαγωγή παράκαμψης, σίγαση συναγερμού, αλλαγή συνταγής ή χειροκίνητο έλεγχο χωρίς πλήρες τεχνολογικό πλαίσιο. Αν ο σχεδιασμός επιτρέπει τέτοιες ενέργειες από την οθόνη παραγωγής σε κανονική λειτουργία, ο κίνδυνος αυξάνεται, επειδή μία μόνο απόφαση χρήστη ή μία μόνο παραβιασμένη συνεδρία μπορεί να αλλάξει άμεσα την κατάσταση της διεργασίας.

Αυτό σημαίνει ότι ο κατάλογος των κρίσιμων λειτουργιών πρέπει να αντιμετωπίζεται ως στοιχείο της αρχιτεκτονικής ασφάλειας και όχι αποκλειστικά ως ζήτημα εργονομίας της διεπαφής. Ο ίδιος μηχανισμός ισχύει και για τη λογοδοσία των ενεργειών. Κοινοί λογαριασμοί σύνδεσης, λογαριασμοί που χρησιμοποιούνται από κοινού σε μια βάρδια, έλλειψη διαχωρισμού δικαιωμάτων για ανάγνωση, έλεγχο, παραμετροποίηση και διαχείριση, καθώς και ανεπαρκής καταγραφή συμβάντων, έχουν ως αποτέλεσμα να είναι δύσκολο, μετά από ένα περιστατικό, να διαπιστωθεί αξιόπιστα αν επρόκειτο για λάθος, παράκαμψη διαδικασίας, κατάχρηση πρόσβασης συντήρησης ή μη εξουσιοδοτημένη ενέργεια. Το πρόβλημα δεν περιορίζεται μόνο στη διερεύνηση των αιτίων. Χωρίς αξιόπιστο ίχνος των ενεργειών του χρήστη, δεν είναι επίσης δυνατό να αξιολογηθεί η αποτελεσματικότητα των διαδικασιών, να γίνεται ουσιαστική διαχείριση των δικαιωμάτων ή να τεκμηριώνονται οι επιχειρησιακές αποφάσεις έναντι εσωτερικού ελέγχου, απαιτήσεων πελάτη ή υιοθετημένων πολιτικών ασφάλειας. Στην πράξη, πρόκειται για λογοδοσία ενεργειών και διαδρομή ιχνηλασιμότητας, και όχι μόνο για την απλή καταγραφή συμβάντων.

Ένα επίσης πολύ δαπανηρό σφάλμα σχεδιασμού είναι η μεταφορά στο περιβάλλον παραγωγής εκτεταμένων οθονών συντήρησης και διαγνωστικών, οι οποίες είχαν αρχικά προετοιμαστεί για τις ανάγκες θέσης σε λειτουργία ή υποστήριξης του ολοκληρωτή. Τέτοιες προβολές συχνά παρέχουν ευρεία πρόσβαση σε εσωτερικές μεταβλητές, εξαναγκασμό καταστάσεων, άρση μπλοκαρισμάτων και τροποποίηση παραμέτρων, παρόλο που στην κανονική λειτουργία χρειάζονται το πολύ περιστασιακά. Εάν δεν υπαχθούν σε πρόσθετους περιορισμούς, γίνονται η συντομότερη οδός για παρέμβαση στη διεργασία εκτός της συνήθους διαδρομής του χειριστή. Μια εύλογη λύση είναι ο διαχωρισμός των διαγνωστικών που χρειάζεται η συντήρηση από τις λειτουργίες που επιτρέπουν παρέμβαση στη λογική λειτουργίας, καθώς και η ξεχωριστή απόφαση για το αν τα διαγνωστικά του κατασκευαστή της μηχανής θα είναι διαθέσιμα τοπικά, απομακρυσμένα ή μόνο υπό προϋποθέσεις, μετά από συνειδητή ενεργοποίηση και με πλήρη καταγραφή της συνεδρίας.

Παρόμοια πρέπει να αντιμετωπίζεται και η ενσωμάτωση με βάσεις δεδομένων, αναφορές, απομακρυσμένη υποστήριξη και συστήματα γραφείου. Κάθε τέτοια σύνδεση βελτιώνει την ευκολία εργασίας, αλλά ταυτόχρονα αυξάνει τον αριθμό των εξαρτήσεων, οι οποίες μπορεί να γίνουν οδός εισόδου, πηγή διαταραχών ή αιτία απώλειας της σαφήνειας των ευθυνών. Η αστοχία μιας ενδιάμεσης υπηρεσίας, ο εσφαλμένος συγχρονισμός χρόνου, η ανεξέλεγκτη ανταλλαγή δεδομένων με το ανώτερο σύστημα ή ένα παραμελημένο κανάλι συντήρησης μπορούν να επηρεάσουν όχι μόνο τη διαθεσιμότητα των αναφορών, αλλά και τις αποφάσεις που λαμβάνει ο χειριστής.

Γι’ αυτό αξίζει ήδη από το στάδιο του σχεδιασμού να μετρώνται όχι μόνο η διαθεσιμότητα των οθονών, αλλά και απλούστεροι και πιο χρήσιμοι δείκτες: ο αριθμός των κρίσιμων λειτουργιών που είναι δυνατές από το επίπεδο του παραγωγικού HMI, ο αριθμός των ενεργών εξωτερικών συνδέσεων, ο αριθμός των προνομιακών λογαριασμών και το εύρος των συμβάντων που καλύπτονται από το ίχνος ελέγχου. Μια τέτοια επισκόπηση οργανώνει αργότερα την καταγραφή συμβάντων, τον έλεγχο των αλλαγών παραμέτρων και τους κανόνες απομακρυσμένης πρόσβασης.

Η ειδοποίηση συναγερμών απαιτεί ξεχωριστή αντιμετώπιση. Σε αυτόν τον τομέα, η φαινομενική πληρότητα συχνά καλύπτει την πραγματική έλλειψη ελέγχου. Οι κακώς σχεδιασμένοι συναγερμοί και το ιστορικό συμβάντων όχι μόνο υπερφορτώνουν τον χειριστή, αλλά του αφαιρούν και την ικανότητα να διακρίνει τα κρίσιμα σήματα από τον τεχνικό θόρυβο. Αν ένας συναγερμός μπορεί εύκολα να τεθεί σε σίγαση χωρίς αιτιολόγηση, να επιβεβαιωθεί χωρίς αναφορά στην αιτία ή να χαθεί μέσα στη μάζα των διαγνωστικών μηνυμάτων, η εφαρμογή παύει να υποστηρίζει την ασφάλεια της διεργασίας. Γι’ αυτό οι προτεραιότητες των συναγερμών πρέπει να προκύπτουν από την πραγματική επίπτωση στους ανθρώπους, στη μηχανή και στην ποιότητα της παραγωγής και να παραμένουν συνδεδεμένες με τους κανόνες καταγραφής των επιβεβαιώσεων, των παρακάμψεων και των αλλαγών ρυθμίσεων. Αυτή είναι ακριβώς η στιγμή κατά την οποία η ανάλυση κινδύνου παύει να είναι ένα τυπικό έγγραφο και αρχίζει να διαμορφώνει τη διεπαφή.

Πώς να σχεδιάζετε ώστε να περιορίζονται οι συνέπειες του σφάλματος και της κατάχρησης

Το σημείο εκκίνησης είναι απλό: η εφαρμογή HMI/SCADA δεν μπορεί να θεωρεί δεδομένο ότι κάθε χρήστης ενεργεί πάντοτε σωστά και στο κατάλληλο πλαίσιο της διεργασίας. Ο σχεδιασμός πρέπει να ξεκινά από τον διαχωρισμό των λειτουργιών και όχι από τη σχεδίαση των οθονών. Η ομάδα πρέπει πρώτα να καθορίσει τι ο χειριστής πρέπει μόνο να βλέπει, τι μπορεί να επιβεβαιώνει, τι επιτρέπεται να αλλάζει στη συνήθη ροή εργασίας και ποιες ενέργειες πρέπει να μεταφερθούν σε λειτουργία συντήρησης, να υπαχθούν σε πρόσθετη εξουσιοδότηση ή να απομονωθούν πλήρως σε ξεχωριστό εργαλείο ή σταθμό.

Μια τέτοια απόφαση οργανώνει ολόκληρη την αρχιτεκτονική πρόσβασης: τους ρόλους, το εύρος των δικαιωμάτων, τον τρόπο καταγραφής των ενεργειών και τις προϋποθέσεις της απομακρυσμένης υποστήριξης. Στην πράξη, λειτουργεί καλά ένας πίνακας ρόλων που βασίζεται στα πραγματικά καθήκοντα και διακρίνει τον χειριστή, τον επικεφαλής βάρδιας, τη συντήρηση, τον τεχνολόγο, τον integrator και τον διαχειριστή. Αυτό δεν είναι τυπική διαδικασία. Αν οι λειτουργίες συντήρησης παραμένουν στην ίδια οθόνη και κάτω από τον ίδιο λογαριασμό με τη λειτουργία της διεργασίας, η ίδια η εφαρμογή δημιουργεί οδό προς το λάθος, την παράκαμψη της διαδικασίας ή την κατάχρηση δικαιωμάτων.

Ένα καλό HMI/SCADA περιορίζει τη δυνατότητα εκτέλεσης μιας επικίνδυνης λειτουργίας κατά λάθος, αλλά δεν επιβραδύνει άσκοπα τις ενέργειες ρουτίνας. Αυτό απαιτεί σαφές πλαίσιο εργασίας: ο χρήστης πρέπει να βλέπει σε ποιο αντικείμενο εργάζεται, σε ποια κατάσταση βρίσκεται η διεργασία, αν λειτουργεί τοπικά ή απομακρυσμένα και αν το σύστημα βρίσκεται σε αυτόματη, χειροκίνητη ή λειτουργία συντήρησης. Οι επιβεβαιώσεις πρέπει να είναι ανάλογες με τον κίνδυνο και όχι ίδιες για όλες τις ενέργειες. Εκεί όπου η συνέπεια του σφάλματος είναι αναστρέψιμη και περιορισμένη, συνήθως αρκεί μία μόνο εξουσιοδότηση. Οι κρίσιμες λειτουργίες απαιτούν πρόσθετο έλεγχο: δεύτερη επιβεβαίωση, εκ νέου ταυτοποίηση, εξάρτηση από την κατάσταση της διεργασίας ή φυσική μετάβαση σε απομονωμένη διεπαφή.

Σημαντικό ρόλο παίζουν και οι υπό όρους κλειδώσεις. Αν η εφαρμογή επιτρέπει αλλαγή ρύθμισης, εξαναγκασμό σήματος ή μετάβαση σε χειροκίνητη λειτουργία ανεξάρτητα από την κατάσταση του εξοπλισμού, τότε ο κίνδυνος μεταφέρεται από τον σχεδιασμό στον χειριστή. Εδώ φαίνεται καθαρά ότι ο σωστός σχεδιασμός διεπαφής δεν αφορά μόνο την ευχρηστία, αλλά και τον περιορισμό των συνεπειών του σφάλματος μέσω ενσωματωμένων φραγμών. Σε πολλές περιπτώσεις, αυτή η λογική είναι κοντά στον τρόπο με τον οποίο λειτουργεί το Poka-Yoke στις γραμμές παραγωγής.

Ο πολυεπίπεδος σχεδιασμός πρόσβασης πρέπει να καλύπτει και τον τρόπο χρήσης των δικαιωμάτων με την πάροδο του χρόνου. Οι ατομικοί λογαριασμοί είναι απαραίτητοι παντού όπου απαιτείται ιχνηλασιμότητα ενεργειών. Ένας κοινόχρηστος λογαριασμός αφαιρεί τη δυνατότητα να διαπιστωθεί ποιος έλαβε πραγματικά μια απόφαση. Η ελάχιστη έκταση δικαιωμάτων σημαίνει ότι ο χρήστης λαμβάνει μόνο τις λειτουργίες που χρειάζεται για την τρέχουσα εργασία του, ενώ η ανύψωση δικαιωμάτων γίνεται προσωρινά και υπό ελεγχόμενες συνθήκες. Αυτό αφορά ιδιαίτερα τη συντήρηση, τον ενοποιητή και την απομακρυσμένη υποστήριξη του κατασκευαστή. Μια μόνιμη, ανοιχτή διαδρομή συντήρησης είναι μόνο φαινομενικά βολική, επειδή καταργεί το φυσικό όριο εμπιστοσύνης μεταξύ λειτουργίας και τεχνικής υποστήριξης. Ασφαλέστερο μοντέλο είναι η πρόσβαση που ενεργοποιείται κατόπιν αιτήματος, έχει χρονικό περιορισμό, αντιστοιχίζεται σε συγκεκριμένο άτομο και καταγράφεται στο ιστορικό συμβάντων. Αυτή η προσέγγιση ευθυγραμμίζεται καλά με την αρχή των ελάχιστων δικαιωμάτων και την τμηματοποίηση της πρόσβασης.

Με το ίδιο σκεπτικό πρέπει να αποφασιστεί αν οι λειτουργίες συντήρησης θα είναι διαθέσιμες από το παραγωγικό HMI ή αποκλειστικά από ξεχωριστό σταθμό, καθώς και αν θα επιτρέπονται αφαιρούμενα μέσα και τοπική εισαγωγή ή εξαγωγή δεδομένων από το πάνελ χειριστή. Οι αποφάσεις αυτές δεν είναι δευτερεύουσες. Από αυτές εξαρτάται αν η συντηρησιμότητα του συστήματος θα υλοποιείται με ελεγχόμενο τρόπο ή μέσω πρόχειρων παρακάμψεων.

Από την οπτική ενός συμβάντος ή μιας διαφοράς κατά τη λειτουργία, η ίδια η διεπαφή δεν αρκεί. Η εφαρμογή πρέπει να αφήνει τεκμήρια που να επιτρέπουν την ανασύνθεση της ακολουθίας των αποφάσεων. Το ιστορικό συμβάντων, τα αρχεία καταγραφής συστήματος και η καταγραφή αλλαγών πρέπει από κοινού να απαντούν όχι μόνο στο τι συνέβη, αλλά και στο ποιος, πότε, από ποιο σημείο και σε ποια κατάσταση της διεργασίας εκτέλεσε την ενέργεια. Το ελάχιστο εύρος συμβάντων που συνήθως αξίζει να καταγράφεται περιλαμβάνει τη σύνδεση, την αλλαγή δικαιωμάτων, την αλλαγή παραμέτρων, τη μετάβαση σε χειροκίνητη λειτουργία, την επιβεβαίωση συναγερμού και την εισαγωγή διαμόρφωσης. Καθοριστικής σημασίας είναι η σύνδεση της καταγραφής με το τεχνολογικό πλαίσιο, επειδή η απλή πληροφορία ότι έγινε μια αλλαγή, χωρίς την κατάσταση του εξοπλισμού, μπορεί να αποδειχθεί άχρηστη.

Ένα καλό παράδειγμα, τυπικό για πολλές υλοποιήσεις, είναι το εξής: η αλλαγή του ορίου συναγερμού από τον τεχνολόγο μπορεί να είναι επιτρεπτή, αλλά μόνο μετά την είσοδο στον προβλεπόμενο τρόπο λειτουργίας, με καταγραφή του χρήστη, του σταθμού, του χρόνου, της προηγούμενης και της νέας τιμής, καθώς και με επιβεβαίωση ότι ο εξοπλισμός δεν βρισκόταν σε κρίσιμη κατάσταση. Ένα τέτοιο ίχνος είναι σημαντικό τόσο για την ασφάλεια όσο και για τη διαχείριση αλλαγών σε βιομηχανικές εφαρμογές.

Το τελευταίο επίπεδο είναι η συντηρησιμότητα χωρίς παράκαμψη των μέτρων προστασίας. Αν η ενημέρωση, η επαναφορά διαμόρφωσης ή η διάγνωση απαιτούν απενεργοποίηση του ελέγχου πρόσβασης, χρήση κοινόχρηστου κωδικού ή εργασία χωρίς ίχνος ελέγχου, τότε το πρόβλημα βρίσκεται στον σχεδιασμό και όχι στην πειθαρχία του προσωπικού. Η εφαρμογή πρέπει να διαθέτει προβλεπόμενη ροή αλλαγής: αίτημα, αξιολόγηση επιπτώσεων, δοκιμή, υλοποίηση, επιβεβαίωση και σχέδιο επαναφοράς. Πρέπει επίσης να διαχωρίζει το παραγωγικό από το περιβάλλον συντήρησης τουλάχιστον σε λογικό επίπεδο και, όπου αυτό δικαιολογείται, και σε οργανωτικό και τεχνικό επίπεδο. Τα αντίγραφα διαμόρφωσης πρέπει να μπορούν να δημιουργούνται και να επαναφέρονται με ελεγχόμενο τρόπο, χωρίς πρόχειρη εξαγωγή «για παν ενδεχόμενο» από το πάνελ. Μια τέτοια προσέγγιση είναι συνεπής με την αρχή των ελάχιστων δικαιωμάτων στο OT και με τις απαιτήσεις για έλεγχο πρόσβασης, ιχνηλασιμότητα ενεργειών και διαχείριση αλλαγών, με την προϋπόθεση ότι η έκτασή τους πρέπει πάντα να εξετάζεται σε σχέση με την αρχιτεκτονική του συστήματος και τον υιοθετημένο επιμερισμό ευθυνών.

Πρακτική υλοποίησης και αναφορά στις απαιτήσεις

Τη μεγαλύτερη αξία δεν την έχει η προσθήκη διαδοχικών μηχανισμών προστασίας στο τέλος του έργου, αλλά η συστηματική ανασκόπηση της εφαρμογής πριν από την παραλαβή ή τον εκσυγχρονισμό. Αυτή είναι η στιγμή κατά την οποία μπορεί ακόμη, με σχετικά χαμηλό κόστος, να διορθωθεί ο τρόπος λειτουργίας του συστήματος, αντί αργότερα να καλύπτονται λανθασμένες παραδοχές με πρόσθετες διαδικασίες. Μια τέτοια ανασκόπηση πρέπει να πραγματοποιείται από μικτή ομάδα: σχεδιασμός, συντήρηση, λειτουργία, μηχανικός αυτοματισμού και τα άτομα που είναι υπεύθυνα για την ασφάλεια.

Αντικείμενο της αξιολόγησης δεν είναι μόνο η τεχνική διαμόρφωση, αλλά και το αν η εφαρμογή πράγματι διαχωρίζει ρόλους, προστατεύει κρίσιμες λειτουργίες, περιορίζει την απομακρυσμένη πρόσβαση στις δικαιολογημένες περιπτώσεις, εξασφαλίζει σαφή διαχείριση συναγερμών, διατηρεί ιστορικό αλλαγών και επιτρέπει την εκτέλεση αντιγράφων και διαδικασιών έκτακτης ανάγκης χωρίς παράκαμψη των μέτρων προστασίας. Ακριβώς από μια τέτοια ανασκόπηση πρέπει να προκύπτει η λίστα για το FAT/SAT καθώς και οι απαιτήσεις που εντάσσονται στην παραλαβή, στο πλάνο συντήρησης και στην τεκμηρίωση όπως υλοποιήθηκε.

Αυτή η προσέγγιση μετατοπίζει το επίκεντρο από τη συζήτηση για τα ίδια τα μέτρα προστασίας στις σχεδιαστικές αποφάσεις, οι οποίες στη συνέχεια καθορίζουν τη συμπεριφορά ανθρώπων και εξοπλισμού. Αν ήδη στο στάδιο του σχεδιασμού δεν έχει καθοριστεί ποιος μπορεί να αλλάζει τις παραμέτρους των συνταγών, ποιος εγκρίνει τη λειτουργία συντήρησης, πώς καταγράφεται η παρέμβαση του integrator και υπό ποιες προϋποθέσεις επιτρέπεται η πρόσβαση εκτός εγκατάστασης, τότε μετά τη θέση σε λειτουργία το σύστημα θα βασίζεται σε εξαιρέσεις και προφορικές συνεννοήσεις.

Για τον ίδιο λόγο, αξίζει να αποφασιστεί αν η αξιολόγηση της εφαρμογής θα γίνει στο πλαίσιο εκσυγχρονισμού μηχανής ή γραμμής ή ως ξεχωριστή ανασκόπηση OT. Η πρώτη προσέγγιση συνδέει καλύτερα την ασφάλεια με τη λειτουργία της διεργασίας, ενώ η δεύτερη διευκολύνει τον εντοπισμό εξαρτήσεων μεταξύ συστημάτων και τον επιμερισμό ευθυνών για λογαριασμούς, δικαιώματα και καταγραφή ενεργειών. Αυτό είναι επίσης το φυσικό σημείο για μια αρχική ανάλυση κινδύνου: τον εντοπισμό κρίσιμων λειτουργιών, των ορίων εμπιστοσύνης και των συνεπειών από σφάλμα χειριστή ή κατάχρηση. Στην πράξη, χρήσιμη αποδεικνύεται και η ανάλυση κινδύνου στο πλαίσιο του έργου.

• οι ρόλοι και ο τρόπος σύνδεσης των χρηστών,
• οι κρίσιμες λειτουργίες και οι κανόνες επιβεβαίωσής τους,
• η απομακρυσμένη πρόσβαση και οι λειτουργίες συντήρησης,
• οι συναγερμοί, η καταγραφή αλλαγών και η ιχνηλασιμότητα των ενεργειών,
• τα αντίγραφα, η αποκατάσταση και οι διαδικασίες έκτακτης ανάγκης.

Ένα καλό αποτέλεσμα σε μια εγκατάσταση σπάνια προκύπτει από την ταυτόχρονη υλοποίηση πολλών εργαλείων. Συνήθως μεγαλύτερη σημασία έχει η εξάλειψη λίγων συστημικών κινδύνων που επί χρόνια θεωρούνταν πρακτικοί. Ο εκσυγχρονισμός της εφαρμογής HMI/SCADA μπορεί να ξεκινήσει από την κατάργηση κοινών λογαριασμών, τον διαχωρισμό των λειτουργιών συντήρησης από τις λειτουργίες χειριστή, τον περιορισμό των εξωτερικών συνδέσεων σε ελεγχόμενες διαδρομές και την ενεργοποίηση ίχνους αλλαγών παραμέτρων με αντιστοίχιση σε συγκεκριμένο άτομο ή ρόλο. Μια τέτοια αλλαγή δεν χρειάζεται να επιβαρύνει τη λειτουργία της συντήρησης ούτε του integrator, εφόσον από την αρχή έχουν προβλεφθεί λειτουργία συντήρησης, κανόνες εξουσιοδότησης και αναπαραγώγιμη πορεία των τροποποιήσεων.

Κατά τη λειτουργία, αξίζει στη συνέχεια να μετρώνται όχι αφηρημένα επίπεδα ασφάλειας, αλλά επιχειρησιακά χρήσιμοι δείκτες: ο αριθμός των κοινών λογαριασμών που παραμένουν στο σύστημα, η έκταση της ενεργής απομακρυσμένης πρόσβασης, η πληρότητα των αρχείων καταγραφής αλλαγών, ο χρόνος αποκατάστασης της διαμόρφωσης και ο αριθμός των παρεμβάσεων που εκτελούνται εκτός της τυπικής διαδικασίας. Τέτοιοι δείκτες επιτρέπουν να αξιολογηθεί αν το έργο περιόρισε πράγματι τον κίνδυνο ή απλώς τον μετέφερε στην καθημερινή πρακτική.

Στην ελληνική και ευρωπαϊκή πραγματικότητα γίνεται όλο και πιο δύσκολο να υποστηριχθεί η προσέγγιση σύμφωνα με την οποία η κυβερνοασφάλεια HMI/SCADA αποτελεί αποκλειστική υπόθεση του τμήματος IT. Η ευθύνη κατανέμεται μεταξύ σχεδιασμού, λειτουργίας, συντήρησης, προμηθευτών και integrators, ενώ οι απαιτήσεις του κλάδου και των συμβάσεων αποκτούν σημασία μόνο όταν ο οργανισμός μπορεί να δείξει συγκεκριμένα στοιχεία: ποιες σχεδιαστικές αποφάσεις ελήφθησαν, πώς αποδίδονται τα δικαιώματα, ποιο είναι το ίχνος ενεργειών και ποιος ελέγχει τις αλλαγές. Οι απλές αναφορές σε πρότυπα, πολιτικές ή συμβατικές διατάξεις δεν υποκαθιστούν την απόδειξη ότι η εφαρμογή σχεδιάστηκε και παραλήφθηκε με τρόπο που επιτρέπει την ασφαλή λειτουργία.

Το σημαντικότερο συμπέρασμα είναι πρακτικό. Η οικονομικότερη και αποτελεσματικότερη στιγμή για τον περιορισμό του κινδύνου παραμένει ο σχεδιασμός και η παραλαβή της εφαρμογής. Τότε είναι που, με το μικρότερο κόστος, καθορίζονται τα όρια εμπιστοσύνης, οι ρόλοι, οι όροι πρόσβασης, το ίχνος ενεργειών και ο τρόπος διαχείρισης των αλλαγών. Αν αυτές οι απαιτήσεις μετατραπούν σε επαληθεύσιμα κριτήρια για τον προμηθευτή και τον ολοκληρωτή, το HMI/SCADA παύει να είναι ένα βολικό αλλά υπερβολικά έμπιστο περιβάλλον διεπαφής και γίνεται εργαλείο ασφαλούς λειτουργίας της διεργασίας.