Granica IT/OT w przedsiębiorstwie użyteczności publicznej nie jest wyraźną linią na schemacie sieci. To przepuszczalna membrana, przez którą dane przepływają w obu kierunkach: programy wsadowe w języku COBOL generujące pliki konfiguracyjne nastaw wykorzystywane przez sterowniki PLC, programy RPG odczytujące dane z systemu SCADA do celów rozliczeniowych i sprawozdawczości regulacyjnej, starsze mosty C tłumaczące dane wyjściowe z komputerów mainframe na formaty zrozumiałe dla rozproszonych systemów sterowania, strumienie zadań JCL, które planują i sekwencjonują wymianę danych przez granicę w oparciu o harmonogram, od którego zależą procesy operacyjne. Oprogramowanie zarządzające tym przepływem nie jest ani czysto IT, ani czysto OT. To tkanka łączna umożliwia funkcjonowanie przedsiębiorstw użyteczności publicznej i jest to kategoria kodu, którą zespoły modernizacyjne są najmniej przygotowane do analizy na początku programu transformacji.
Sektor energetyczny przechodzi jedną z największych transformacji cyfrowych w swojej historii. W miarę jak przedsiębiorstwa użyteczności publicznej modernizują swoją infrastrukturę, wprowadzając inteligentne sieci elektroenergetyczne, połączone podstacje, systemy ICS i zaawansowaną automatyzację, sieci OT stają się bardziej połączone niż kiedykolwiek wcześniej. To połączenie nie eliminuje starszej warstwy kodu, ale wręcz ją zwiększa, ponieważ każdy nowy punkt końcowy inteligentnej sieci elektroenergetycznej i platforma analityki w chmurze są zależne od źródeł danych pochodzących z aplikacji napisanych dekady temu. Modernizacja tych aplikacji bez zrozumienia ich roli w łańcuchu danych operacyjnych nie jest modernizacją, lecz zaburzeniem, którego konsekwencje wykraczają poza centrum danych i obejmują infrastrukturę fizyczną.
Znajdź każdy zakodowany na stałe parametr operacyjny
SMART TS XL lokalizuje każdą stałą UE, limit alarmowy i adres protokołu osadzone w Twoim dotychczasowym portfolio kodów.
DOWIEDZ SIĘ WIĘCEJ…Co tak naprawdę oznacza „obok SCADA”
Termin „pokrewny SCADA” odnosi się do oprogramowania IT, które łączy się z systemami technologii operacyjnej, a nie do samego oprogramowania SCADA, oprogramowania układowego PLC ani kodu wbudowanego RTU, lecz do warstwy aplikacji biznesowej, która przesyła dane do tych systemów i odbiera je z nich. Ta kategoria jest obszerna, niedostatecznie analizowana i autentycznie różni się od reszty portfolio aplikacji korporacyjnych.
W typowym środowisku narzędziowym kod powiązany ze SCADA obejmuje:
Programy do obliczania nastaw i parametrów obciążenia. Programy w językach COBOL i PL/I obliczające nastawy obciążenia, docelowe napięcia, progi ciśnienia i limity operacyjne, dostarczane do systemów SCADA w postaci plików konfiguracyjnych lub bezpośrednich źródeł danych. Programy te kodują wymagania dotyczące zgodności z przepisami, specyfikacje techniczne i fizyczne limity bezpieczeństwa. Nieprawidłowe obliczenie nie generuje błędnej wartości w raporcie, lecz generuje nieprawidłową nastawę operacyjną, na podstawie której działa system sterowania.
Odbiorcy danych historycznych. Programy RPG i COBOL, które odczytują dane operacyjne z baz danych historycznych SCADA w celu rozliczeń, raportowania regulacyjnego i analizy wydajności. Programy te zależą od określonych formatów danych, konwencji znaczników czasu i definicji jednostek inżynieryjnych generowanych przez historyka. Zmiana formatu danych wyjściowych historyka lub zmiana w programie odbiorczym po stronie IT może dyskretnie zakłócić obliczenia rozliczeniowe lub zgłoszenia regulacyjne.
Programy mostów protokołów. Niestandardowe programy w języku C, które tłumaczą między formatami wyjściowymi komputerów mainframe a interfejsami plikowymi lub sieciowymi, z których korzystają systemy DCS (Distributed Control System) i SCADA. Mosty te implementują określone protokoły, takie jak Modbus, DNP3, IEC 61850, zastrzeżone formaty dostawców, i mają zakodowane na stałe założenia dotyczące struktury komunikatów, kolejności bajtów i synchronizacji, których nie ma w dokumentacji.
Ścieżki danych wsadowych do czasu rzeczywistego. Strumienie zadań JCL, które planują i sekwencjonują wymianę danych między IT/OT w określonych oknach czasowych. Nocne przetwarzanie wsadowe w zakładzie może generować dane konfiguracyjne, które muszą być dostępne dla systemu SCADA przed rozpoczęciem porannych operacji. Zależność czasowa jest domyślnie zawarta w konfiguracji harmonogramu i oczekiwaniach operacyjnych centrum sterowania, nieudokumentowana w żadnym miejscu kodu aplikacji.
Programy przetwarzania alarmów i zdarzeń. Programy, które odbierają rekordy alarmów z systemów SCADA, stosują logikę klasyfikacji i routingu, generują zlecenia robocze i generują zapisy zgodności z przepisami. Logika klasyfikacji alarmów, określająca, które zdarzenia wymagają określonych raportów regulacyjnych i w jakich ramach czasowych, jest często osadzona w kodzie programu, który przez dekady podlegał zmianom w przepisach.
To kod, którym kontrolują się inżynierowie i programiści IT, częściowo posiadający go i nie do końca rozumiejący. Kiedy program modernizacyjny pyta: „co możemy zmienić?”, odpowiedź dla kodu bliskiego SCADA brzmi prawie zawsze: „mniej niż myślisz i dopiero po dokładniejszej analizie niż planowałeś”.
Dlaczego standardowa analiza modernizacji zawodzi w tym przypadku
Większość frameworków analizy modernizacji przedsiębiorstw zakłada, że analizowany kod kontroluje jedynie dane i logikę biznesową, a zmiana w programie generuje inne dane bez wpływu na świat fizyczny. Kod powiązany z systemem SCADA łamie to założenie na cztery konkretne sposoby.
Konsekwencje fizyczne błędów danych
W standardowej aplikacji do fakturowania, nieprawidłowe obliczenie skutkuje błędną fakturą. Błąd jest wykrywalny, odwracalny i ma ograniczony zakres. W kodzie pokrewnym SCADA, nieprawidłowe obliczenie może skutkować nieprawidłową wartością zadaną, czyli wartością docelową, na którą system sterowania reaguje, dostosowując parametry fizyczne: ciśnienie, napięcie, natężenie przepływu i temperaturę. Konsekwencją nie jest błędna wartość w bazie danych. Jest to proces fizyczny przebiegający poza zamierzonymi parametrami, którego konsekwencje wahają się od nieefektywności, przez uszkodzenie sprzętu, po incydenty bezpieczeństwa.
Ta asymetria między błędem danych a jego fizycznymi konsekwencjami jest fundamentalnym powodem, dla którego kodu zbliżonego do SCADA nie można analizować z taką samą tolerancją ryzyka, jak standardowego kodu biznesowego. Zmiana, która „działa poprawnie” z punktu widzenia generowania prawidłowych wyników, może nadal generować wyniki niepoprawne operacyjnie, mieszczące się w zakresie dozwolonym dla danego typu danych, poprawne składniowo, ale fizycznie niepoprawne w kontekście operacyjnym, który reprezentuje.
Zależności czasowe, których analiza statyczna nie jest w stanie modelować
Programy informatyczne powiązane z systemami SCADA często mają ograniczenia czasowe, które są istotne z punktu widzenia operacyjnego, ale niewidoczne dla narzędzi do analizy statycznej. Program generujący dane konfiguracyjne musi się zakończyć, zanim cykl odpytywania systemu SCADA je odczyta. Zadanie wsadowe agregujące dane historyczne musi zakończyć się przed upływem znacznika czasu końca interwału, wymaganego przez przepisy. Program pomostowy, który przekazuje alarmy, musi przetwarzać zdarzenia w czasie reakcji określonym w procedurach operacyjnych sterowni.
Te ograniczenia czasowe występują w procedurach operacyjnych narzędzia, w konfiguracji harmonogramu oraz w dorozumianym rozumieniu programistów, którzy napisali programy, a nie w kodzie źródłowym. Narzędzia do analizy statycznej, które koncentrują się na strukturze kodu i przepływie danych, nie mają wglądu w wymagania czasowe istniejące poza samym kodem.
Konsekwencja praktyczna: analiza modernizacji kodu powiązanego ze SCADA musi wyraźnie dokumentować kontekst czasowy dla każdego programu w zakresie. Wymaga to wiedzy operacyjnej, wywiadów z operatorami sterowni, przeglądu harmonogramów zgodności z przepisami, analizy zależności zadań harmonogramu, a nie tylko analizy kodu.
Identyfikacja funkcji bezpieczeństwa
Normy IEC 61511 (bezpieczeństwo funkcjonalne w sektorach przemysłu przetwórczego) i IEC 61508 (bezpieczeństwo funkcjonalne elektrycznych/elektronicznych/programowalnych elektronicznych systemów bezpieczeństwa) definiują wymagania certyfikacyjne dla oprogramowania realizującego funkcje bezpieczeństwa. Kod certyfikowany zgodnie z tymi normami to nie tylko starszy kod, który można zrefaktoryzować w celu zapewnienia łatwości utrzymania. Certyfikacja dotyczy konkretnych artefaktów kodu, konkretnej wersji konkretnego pliku binarnego, który został oceniony przez jednostkę certyfikującą. Zmiana kodu, nawet w celu naprawienia problemu z jakością, który nie stanowiłby problemu w aplikacji biznesowej, unieważnia certyfikację i wymaga ponownej certyfikacji przed wdrożeniem zmienionego kodu w funkcji bezpieczeństwa.
Wiele zakładów użyteczności publicznej korzysta z programów powiązanych ze SCADA, które wykonują obliczenia związane z bezpieczeństwem, wykrywają nadciśnienie, obliczają nastawy zabezpieczeń transformatorów, logikę wyłączania awaryjnego, a które mogą podlegać wymogom certyfikacji bezpieczeństwa bez wiedzy zespołu ds. modernizacji IT. Pierwsze pytanie analityczne dotyczące kodu powiązanego ze SCADA brzmi: czy którykolwiek z tych kodów pełni funkcję bezpieczeństwa? Jeśli tak, to jakie funkcje, w ramach jakiego certyfikatu i czego wymaga jego zmiana?
Sprzężenie sprzętu i protokołów
Programy mostów protokołów i kod wbudowanego interfejsu mają bezpośrednie zależności od implementowanych wersji sprzętu i protokołu. Program implementujący Modbus RTU z określonymi kodami funkcji, mapami rejestrów i wartościami limitu czasu dla konkretnego modelu RTU od konkretnego dostawcy nie implementuje Modbusa w sposób ogólny, lecz implementuje tę konkretną kombinację, z założeniami, które mogą nie być spełnione w przypadku żadnej innej konfiguracji.
Analiza tego kodu pod kątem modernizacji ujawnia zależność nie tylko od kodu źródłowego w COBOL-u lub C, ale także od modelu urządzenia RTU, wersji oprogramowania sprzętowego, fizycznej topologii okablowania i konfiguracji sieci. Zmiany w którymkolwiek z tych elementów mogą uszkodzić interfejs, nawet jeśli kod źródłowy programu pozostał niezmieniony. Zmiany w kodzie źródłowym programu mogą również uszkodzić interfejsy, które wydają się niepowiązane, ponieważ most został napisany w celu skompensowania specyficznych dla dostawcy osobliwości protokołu, które nie są nigdzie udokumentowane.
Granica IT/OT: gdzie znajduje się kod
Model Purdue (ISA-99 / IEC 62443) definiuje architekturę koncepcyjną sieci systemów sterowania przemysłowego na pięciu poziomach, od procesów fizycznych na poziomie 0 do systemów biznesowych przedsiębiorstwa na poziomie 4. Kod starszej generacji powiązany ze SCADA w środowiskach użyteczności publicznej zwykle znajduje się na poziomach 3 i 4, w operacjach produkcyjnych i strefach sieci przedsiębiorstwa, ale przepływy jego danych przekraczają poziom 2 (warstwę nadzoru SCADA) w obu kierunkach.
Granica IT/OT między poziomami 3 i 2 to obszar, gdzie ryzyko bezpieczeństwa i operacyjne jest najwyższe. Podmioty działające na poziomie państwowym instalują się w sieciach OT na miesiące przed aktywacją, podczas gdy grupy atakujące ransomware wdrażają obecnie pakiety obsługujące systemy ICS, zaprojektowane w celu blokowania interfejsów HMI i wstrzymywania produkcji. Najczęstszym punktem wejścia nie jest wbudowane oprogramowanie SCADA, lecz warstwa graniczna IT/OT, gdzie kod IT i systemy OT wymieniają dane za pośrednictwem interfejsów zaprojektowanych z myślą o niezawodności operacyjnej, a nie o bezpieczeństwie adwersarzy.
Zrozumienie dokładnego zestawu programów, które przekraczają tę granicę, oraz ich funkcji, jest warunkiem wstępnym zarówno planowania modernizacji, jak i poprawy bezpieczeństwa. Program odczytujący dane z rejestratora SCADA i zapisujący wyniki do bazy danych rozliczeniowych przekracza tę granicę w jednym kierunku. Program obliczający nastawy i zapisujący je do katalogu konfiguracyjnego odczytywanego przez sterownik PLC, przekracza ją w drugim kierunku. Oba programy są powiązane z systemem SCADA. Żaden z nich nie pojawia się w wynikach skanowania sieci SCADA ani w inwentaryzacji aplikacji IT, dlatego są systematycznie niedostatecznie analizowane.
Wzorce kodu specyficzne dla programów powiązanych ze SCADA
Kod obliczeniowy jednostki inżynierskiej
Obliczenia w jednostkach inżynieryjnych (EU) konwertują surowe wartości z czujników, zazwyczaj liczby całkowite z przetworników analogowo-cyfrowych, na pomiary fizyczne o określonych jednostkach, zakresach i precyzji. Pętla prądowa 4-20 mA z przetwornika ciśnienia generuje surowe wartości; obliczenia EU konwertują je na PSI lub bary z prawidłową kalibracją zera i zakresu.
Ten kod obliczeniowy ma cechy, które odróżniają go od standardowej logiki biznesowej:
kobol
CALCULATE-PRESSURE-EU.
* RAW-COUNT ranges 0-4095 (12-bit ADC)
* SENSOR-ZERO-OFFSET = 819 (4mA = 20% of 4095)
* SENSOR-SPAN = 3276 (16mA span = 80% of 4095)
* RANGE-LOW-PSI = 0
* RANGE-HIGH-PSI = 500
COMPUTE EU-PRESSURE-PSI =
(RAW-COUNT - SENSOR-ZERO-OFFSET) /
SENSOR-SPAN *
(RANGE-HIGH-PSI - RANGE-LOW-PSI)
+ RANGE-LOW-PSI
IF EU-PRESSURE-PSI < RANGE-LOW-PSI OR
EU-PRESSURE-PSI > RANGE-HIGH-PSI
MOVE 'RANGE-VIOLATION' TO ALARM-STATUS
PERFORM GENERATE-ALARM
END-IF.Stałe w tym obliczeniu, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSI, odpowiadają specyfikacji instrumentu fizycznego. Jeśli są one zakodowane na stałe (jak to często bywa w starszych wersjach kodu), zmiana w instrumencie fizycznym wymaga zmiany kodu. Jeśli są błędne (z powodu ponownej kalibracji instrumentu, wymiany lub pierwotnej błędnej konfiguracji), wartość EU jest systematycznie niepoprawna dla każdego rekordu wygenerowanego przez program. Analiza statyczna pozwala określić, gdzie te stałe są zdefiniowane; jedynie walidacja operacyjna może potwierdzić, czy są one poprawne dla bieżącej konfiguracji instrumentu.
Logika generowania i klasyfikacji alarmów
Kod generowania alarmów jest jednym z najbardziej wrażliwych pod względem regulacyjnym kodów SCADA w środowiskach użyteczności publicznej. Normy NERC CIP (Ochrona Infrastruktury Krytycznej) dla przedsiębiorstw energetycznych, wymagania NRC dla obiektów jądrowych oraz wymagania EPA dotyczące raportowania dla przedsiębiorstw wodociągowo-kanalizacyjnych określają, które zdarzenia muszą generować alarmy, jakie informacje muszą one zawierać oraz w jakich ramach czasowych muszą zostać zgłoszone.
kobol
CLASSIFY-ALARM.
EVALUATE TRUE
WHEN EU-PRESSURE-PSI > HIGH-HIGH-LIMIT
MOVE 'HH' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
WHEN EU-PRESSURE-PSI > HIGH-LIMIT
MOVE 'HI' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LIMIT
MOVE 'LO' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LOW-LIMIT
MOVE 'LL' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
END-EVALUATE.Limity alarmowe w tym kodzie, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMIT, to parametry operacyjne o znaczeniu regulacyjnym. Zmiany tych limitów wpływają zarówno na zachowanie operacyjne systemu sterowania, jak i na obowiązki sprawozdawcze przedsiębiorstwa użyteczności publicznej. Każdy program modernizacyjny, który dotyczy kodu klasyfikacji alarmów, musi zostać objęty kontrolą regulacyjną w ramach procesu kontroli zmian, a nie tylko zatwierdzeniem technicznym.
Implementacje mostów protokołów
Starsze programy mostów protokołowych należą do najtrudniejszych do modernizacji kodów powiązanych ze SCADA, ponieważ ich zależności są najtrudniejsze do wyliczenia. Program implementuje określoną wersję protokołu dla konkretnego urządzenia, a nieudokumentowane zachowania specyficzne dla dostawcy są kompensowane w kodzie.
c
/* Legacy Modbus RTU bridge -- written for Modicon 984 PLCs, circa 1998 */
/* NOTE: 984 series uses 1-based register addressing, not 0-based */
/* Function code 03 only -- 984 does not support FC 04 */
/* Max 60 registers per request -- 984 firmware limitation */
#define MODBUS_FC03_READ_HOLDING 0x03
#define MAX_REGS_PER_REQUEST 60 /* 984 firmware limit, not Modbus spec */
#define REGISTER_OFFSET 1 /* 984 uses 1-based addressing */
int read_holding_registers(int start_reg, int count, uint16_t *buffer) {
/* Compensate for 984 1-based addressing */
uint16_t adjusted_start = (uint16_t)(start_reg + REGISTER_OFFSET);
if (count > MAX_REGS_PER_REQUEST) {
/* 984 will return error if count exceeds 60 */
/* Split into multiple requests silently */
return read_registers_chunked(adjusted_start, count, buffer);
}
/* ... */
}Ten kod zawiera cztery założenia dotyczące konkretnego modelu sterownika PLC, które nie są częścią specyfikacji Modbus: adresowanie rejestrów w oparciu o 1, tylko kod funkcji 03, maksymalnie 60 rejestrów oraz blokowanie większych żądań. Żadne z nich nie pojawia się w dokumentacji Modbus. Są to specyficzne dla dostawcy zachowania Modicon 984, udokumentowane w instrukcji obsługi sprzętu z 1998 roku, która może być już niedostępna. Jeśli ten most zostanie zmodernizowany bez zrozumienia tych założeń lub jeśli sterownik PLC zostanie wymieniony na nowszy model, który wykorzystuje standardowe adresowanie w oparciu o 0, każdy odczyt rejestru zwróci wartość błędną o dokładnie jedno przesunięcie adresu rejestru.
Analiza przedmodernizacyjna: co należy wyprodukować
Zanim jakikolwiek kod związany ze SCADA zostanie zmodyfikowany, przebudowany lub zastąpiony, analiza musi wygenerować zestaw wyników wykraczających poza to, co zapewnia standardowa analiza modernizacji przedsiębiorstwa.
Inwentaryzacja funkcji operacyjnych. Każdy program powiązany ze SCADA musi być sklasyfikowany według funkcji operacyjnej: obliczenia EU, dostarczanie wartości zadanych, odbiornik danych historycznych, generowanie alarmów, most protokołów, ścieżka wsadowa do czasu rzeczywistego. Ta klasyfikacja określa, kto musi być zaangażowany w proces zmian: sami inżynierowie IT, czy zespół międzyfunkcyjny, w którego skład wchodzą inżynierowie automatyki, personel operacyjny i dział zgodności z przepisami.
Mapa przekraczania granic IT/OT. Każdy przepływ danych przekraczający granicę IT/OT musi być udokumentowany: który program generuje dane, w jakim formacie i według jakiego harmonogramu; który system OT je przetwarza; oraz jakie są konsekwencje, jeśli dane są nieprawidłowe, opóźnione lub niedostępne. Ta mapa stanowi profil ryzyka operacyjnego dla warstwy przyległej do SCADA.
Identyfikacja funkcji bezpieczeństwa. Każdy program musi zostać oceniony pod kątem spełniania funkcji bezpieczeństwa zgodnie z normami IEC 61511, IEC 61508, NERC CIP lub innymi obowiązującymi normami. Programy zidentyfikowane jako kod funkcji bezpieczeństwa wymagają oddzielnej kontroli zmian, powiadomienia o regulacjach i potencjalnej ponownej certyfikacji. Harmonogram modernizacji tych programów zasadniczo różni się od harmonogramu standardowego kodu biznesowego.
Rejestr parametrów operacyjnych zakodowany na stałe. Każda stała zakodowana na stałe, reprezentująca parametr operacyjny, wartości kalibracji czujnika, limity alarmowe, ograniczenia protokołu, progi czasowe, musi zostać zidentyfikowana, udokumentowana wraz z jej znaczeniem operacyjnym i zweryfikowana pod kątem aktualnych specyfikacji urządzenia. Rejestr ten staje się danymi wejściowymi do procesu zarządzania konfiguracją, który zastępuje stałe zakodowane na stałe konfiguracją zarządzaną zewnętrznie.
Dokumentacja zależności czasowych. Kontekst czasowy każdego programu, okna operacyjne, w których musi on zostać ukończony, zależności harmonogramu wymuszające te okna oraz procedury operacyjne zależne od jego ukończenia muszą być wyraźnie udokumentowane. Ta dokumentacja stanowi specyfikację, zgodnie z którą zmodernizowana implementacja musi zostać zweryfikowana.
Specyfikacja protokołu i interfejsu. Każdy program mostu protokołu musi zostać przeanalizowany pod kątem zachowań specyficznych dla dostawcy, założeń dotyczących wersji protokołu oraz kompensacji specyficznych dla urządzenia. Wynikiem jest dokument specyfikacji, który można wykorzystać do walidacji implementacji zastępczej, potwierdzając, że wszystkie zachowania kompensacyjne są zachowane, nawet te, których nie było w oryginalnej specyfikacji.
Podejścia modernizacyjne, które działają i te, które nie działają
Schemat Stranglera, stosowany ostrożnie. Wzorzec Stranglera, polegający na budowaniu nowej funkcjonalności równolegle ze starą, trasowaniu przyrostowym i stopniowym wycofywaniu z eksploatacji, jest odpowiedni dla kodu powiązanego ze SCADA, który przetwarza dane po stronie IT (odbiorcy danych historycznych, obliczenia rozliczeniowe). Stary program kontynuuje działanie podczas przejścia; nowa implementacja generuje równoległe dane wyjściowe, które są weryfikowane pod kątem równoważności przed wycofaniem starego programu.
Rysunek Stranglera nie ma zastosowania do ścieżek w czasie rzeczywistym. W przypadku programów znajdujących się na ścieżce danych w czasie rzeczywistym, gdzie nie ma bezpiecznego sposobu równoległego uruchamiania starych i nowych, ponieważ generowałyby one sprzeczne efekty operacyjne, przejście musi nastąpić natychmiast i zostać zweryfikowane w trybie offline przed jakimkolwiek przełączeniem produkcyjnym. Uruchomienie równoległego programu obliczającego wartości zadane, który generuje inne wartości niż program bieżący, spowodowałoby wysłanie sprzecznych wartości zadanych do systemu sterowania.
Eksternalizacja konfiguracji przed zmianami w kodzie. W przypadku programów z zakodowanymi na stałe parametrami operacyjnymi, najbezpieczniejszym pierwszym krokiem modernizacji jest eksternalizacja tych parametrów do pliku konfiguracyjnego lub bazy danych bez zmiany logiki obliczeniowej. Dzięki temu parametry stają się widoczne, łatwe w zarządzaniu i audytowane bez konieczności ingerencji w kod obliczeniowy o znaczeniu operacyjnym. Ryzyko eksternalizacji parametrów jest znacznie niższe niż refaktoryzacja logiki obliczeniowej.
Kod funkcji bezpieczeństwa: analiza i dokumentacja, a nie refaktoryzacja. Kod certyfikowany pod kątem bezpieczeństwa powinien być analizowany i dokumentowany na etapie planowania modernizacji, ale wprowadzanie w nim zmian powinno być odroczone do czasu przemyślanego programu ponownej certyfikacji, koordynowanego z przepisami, a nie w ramach ogólnej inicjatywy modernizacyjnej. Ryzyko unieważnienia certyfikatu bezpieczeństwa podczas szeroko zakrojonej modernizacji nie jest uzasadnione żadną typową korzyścią wynikającą z modernizacji.
W jaki sposób SMART TS XL Obsługuje analizę starszego kodu w środowisku SCADA
SMART TS XL'S statyczna analiza kodu Dotyczy to obszaru IT w obszarze przyległym do SCADA, czyli programów w językach COBOL, JCL, RPG, PL/I i C, które działają na komputerach mainframe i systemach klasy midrange oraz generują, przetwarzają lub przetwarzają dane przesyłane do środowisk OT. W przypadku tego kodu analiza strukturalna generuje inwentarz funkcji operacyjnych i zakodowany na stałe rejestr parametrów, które są wymagane w analizie przedmodernizacyjnej.
Mapowanie zależności aplikacji tworzy mapę przekraczania granic IT/OT: każdy program zapisujący dane do interfejsu plikowego używanego przez system SCADA, każdy krok zadania JCL generujący dane o znaczeniu czasowym dla operacji, każdy program na ścieżce danych historycznych od źródła OT do odbiorcy IT. Gdy program rozliczeniowy COBOL w przedsiębiorstwie użyteczności publicznej odczytuje dane historyczne przez pośredni most C, mapa zależności reprezentuje zarówno zależność COBOL-C, jak i zależność C-historian jako połączony łańcuch, dzięki czemu pełne przekraczanie granic IT/OT jest widoczne, a nie możliwe do wykrycia jedynie poprzez incydent operacyjny.
Możliwość analizy wpływu jest szczególnie istotna w przypadku kodu powiązanego ze SCADA, ponieważ wylicza promień rażenia każdej proponowanej zmiany przed jej wprowadzeniem. Modyfikacja programu obliczeniowego EU, który jest współdzielony (za pośrednictwem kopii) z kodem generowania alarmów, kodem dostarczania wartości zadanych i kodem zapisu historii, wymaga zrozumienia wszystkich trzech wtórnych skutków przed rozpoczęciem obliczeń. W standardowym kodzie biznesowym nieprawidłowa zmiana generuje błędne dane. W kodzie powiązanym ze SCADA generuje ona błędne parametry operacyjne.
Możliwość rozszerzenia JCL ujawnia strukturę czasową i sekwencyjną warstwy wsadowej: które zadania są wykonywane w jakiej kolejności, które dane wyjściowe z zestawu danych zasilają kolejne kroki oraz które strumienie zadań są ograniczone czasowo przez wymagania operacyjne. Stanowi to strukturalną bazę dowodową dla dokumentacji zależności czasowych, której wymaga modernizacja w systemie SCADA.
Funkcja wyszukiwania w przedsiębiorstwie umożliwia skalowalność zakodowanego rejestru parametrów: znajdź każde wystąpienie określonej stałej jednostki inżynieryjnej, każdą wartość graniczną alarmu, każdy zakodowany na stałe adres protokołu w każdym artefakcie COBOL, C, RPG i JCL w środowisku, w ciągu kilku sekund, w milionach wierszy kodu. Dla przedsiębiorstw zarządzających setkami tysięcy wierszy starszego kodu, zbliżonego do SCADA, ta funkcja wyszukiwania stanowi różnicę między ręcznym audytem trwającym miesiące a zautomatyzowaną inwentaryzacją trwającą godziny.
Dla zespołów planujących modernizacja dziedziczna systemów użytkowych, SMART TS XL Zapewnia analizę strukturalną po stronie IT, która umożliwia zespołowi modernizacyjnemu efektywną współpracę z inżynierami kontroli po stronie OT, którzy rozumieją kontekst operacyjny. Granica IT/OT nie jest bezpiecznie przekraczana przez zespoły IT ani przez zespoły OT. Jest ona bezpiecznie przekraczana, gdy obie strony dysponują dokładną wiedzą strukturalną na temat zawartości swoich systemów.
Dlaczego ten kod wymaga innego rodzaju uwagi
Przedsiębiorstwa użyteczności publicznej modernizujące swój starszy kod powiązany z systemem SCADA nie tylko aktualizują stare oprogramowanie. Zmieniają warstwę oprogramowania, która pośredniczy między systemami biznesowymi a infrastrukturą fizyczną. Konsekwencje błędów nie ograniczają się do błędów danych, przerw w świadczeniu usług czy strat finansowych, ale obejmują również systemy fizyczne, które służą ludziom zależnym od przedsiębiorstw użyteczności publicznej.
Cechy, które czynią ten kod wyjątkowym, fizyczne konsekwencje błędów danych, zależności czasowe niewidoczne dla analizy statycznej, ograniczenia certyfikacji bezpieczeństwa, sprzężenie sprzętowe i protokołowe, nie są argumentami przeciwko jego modernizacji. Są argumentami za jego pełnym zrozumieniem przed wprowadzeniem jakichkolwiek zmian. Ramy analizy zawarte w tym przewodniku pozwalają na takie zrozumienie. Wynikający z tego program modernizacji jest bezpieczniejszy, ponieważ zakres zmian jest definiowany na podstawie dowodów, a nie założeń, zależności czasowe są udokumentowane, a nie domniemane, kod funkcji bezpieczeństwa jest identyfikowany, a nie przypadkowo modyfikowany, a przekroczenia granic IT/OT są mapowane, a nie odkrywane w wyniku incydentów operacyjnych po wdrożeniu.
