Analiza czynników, które sprzyjają cyberatakom na przemysłowe systemy sterowania i systemy SCADA, pomoże zaplanować strategię ochrony przed tego typu zagrożeniami. Tym bardziej, że stają się one powszechne.
Osoby zajmujące się określaniem ryzyka bezpieczeństwa cybernetycznego zwyczajowo dzielą je na dwie kategorie:
- ryzyko występujące w prostym, niezabezpieczonym systemie sterowania działającym w powszechnie stosowanym, standardowym systemie operacyjnym podłączonym bezpośrednio do Internetu (rys. 1),
- ryzyko występujące w wysoce zabezpieczonym systemie sterowania wyposażonym w wielopoziomowe zabezpieczenia (rys. 2).
Pierwsza z prezentowanych sytuacji przedstawia system SCADA pracujący w niezabezpieczonej ani firewallami, ani programami antywirusowymi sieci podłączonej do Internetu. Taki system zostanie prawdopodobnie po krótkim czasie zaatakowany przez wirusy, a po upływie kilku godzin w pełni unieruchomiony. Niewątpliwie tego typu rozwiązania otrzymują najwyższą możliwą ocenę ryzyka i należy ich unikać w każdych okolicznościach. W takiej sytuacji druga kategoria systemów jest właściwszą dla systemu SCADA. W tym układzie ryzyko związane jest raczej z planowym atakiem, niż przypadkowym zainfekowaniem systemu wirusami błąkającymi się po sieci. Jednym ze sposobów określenia poziomu potencjalnych zagrożeń jest analiza zdarzeń historycznych. Włączając w to zarówno te dotyczące bezpośrednio danej firmy, jak też całego sektora przemysłu. Jeśli dysponujemy takimi danymi, grupa oceniająca ryzyko będzie mogła przeanalizować i odpowiednio zinterpretować dotychczasowe doświadczenia do oceny prawdopodobieństwa zaistnienia podobnych sytuacji w przyszłości. Większość firm nie dysponuje własnymi danymi pozwalającymi dokonać realnej oceny prawdopodobieństwa ryzyka. Dlatego w większości przypadków ocena musi bazować na danych zewnętrznych, czyli zdarzeniach mających miejsce w podobnych przedsiębiorstwach. Należy jednak przy tym pamiętać, że ogólny stopień zagrożenia stale rośnie. Nie należy ulegać złudzeniom zakładając, że w naszym przypadku pozostanie na dotychczasowym poziomie. Zawsze zakładajmy, że historyczny obraz zdarzeń jest niepełny, a aktywność hakerów stale wzrasta.W środowisku osób zajmujących się bezpieczeństwem cybernetycznym nie ma zgodności co do liczby i częstotliwości zdarzeń zagrażających bezpieczeństwu pracy systemów SCADA. Pewne źródła wskazują na ich niewielką liczbę, podczas gdy inne znacznie wyższą. Poziom rozbieżności zmusza inżynierów do określenia sposobów właściwej interpretacji danych.Zrozumieć cyberniebezpieczeństwo
Szczegółowo udokumentowane incydenty zagrażające bezpieczeństwu systemu są niezwykle rzadkie. Ofiary, co zrozumiałe, opierają się przed ujawnianiem detali, a eksperci nie lubią gloryfikacji i zachęcania cyberprzestępców. W skutek tego w literaturze stale opisywane są te same specyficzne, ale możliwe do sprawdzenia incydenty, naruszające bezpieczeństwo systemów SCADA:
- wypuszczenie ścieków do parków, rzek i hoteli (kwiecień 2000 r., Maroochy Shire, Queensland, Australia),
- hakerskie włamanie do jednej z sieci komputerowych i nieudana penetracja układów sterowania (maj 2001 r., California Independent System Operator),
- zainfekowanie systemu sterowania amerykańskiej elektrowni jądrowej przez wirusa komputerowego (styczeń 2003 r.),
- publikacja raportu CIA na temat cyberkryminalistów, którzy włamali się i zatrzymali pracę jednego z zakładów energetycznych poza granicami USA (styczeń 2008 r.).
Literatura przytacza znacznie więcej tego typu zdarzeń. Byres i Lowe z British Columbia Institute of Technology (BCIT) zebrali i stworzyli bazę incydentów związanych z bezpieczeństwem cybernetycznym począwszy od 1995 aż do 2003 roku. Stworzona baza zawiera opis 41 zdarzeń. W latach 1995-2000 dochodziło od jednego do trzech ataków rocznie. Począwszy jednak od 2001 roku ich liczba stale rosła: cztery w roku 2001, sześć w 2002 i dziesięć w 2003.
Pomimo różnic w ocenie częstotliwości występowania zagrożeń bezpieczeństwa systemów SCADA eksperci są zgodni co do jednego: liczba incydentów jest niedoszacowana. Wynika to przede wszystkim z faktu, że firmy nie są skłonne ujawniać informacji, które stawiają ich w złym świetle. Ponadto brakuje uregulowań prawnych oraz instytucji wymagających raportowania tego typu problemów. Ilościowa ocena prawdopodobieństwa wystąpienia incydentu specyficznego dla danego przedsiębiorstwa jest zadaniem skomplikowanym. Tym bardziej, że prowadzona analiza jest zawsze bardzo subiektywna. W sytuacji braku konkretnych i weryfikowalnych gróźb każda analiza musi rozpocząć się od odpowiedzi na pewne potencjalnie trudne pytania:
- czy możemy stać się obiektem ataku z wewnątrz, dokonanego przez niezadowolonego pracownika, tak jak to miało miejsce w przypadku wypuszczenia ścieków w Maroochy?
- czy zupełnie przypadkowo nie staniemy się obiektem ataku przez hakera szukającego dobrej zabawy lub rozgłosu?
- czy błąkające się wirusy mogą prześliznąć się przez nasze zabezpieczenia?
- czy możliwe jest, aby haker włamujący się do systemu robił to dla szantażu (np. pobudek finansowych)?
- czy możliwy jest atak terrorystyczny wynikający z pobudek politycznych lub religijnych?
- na ile jesteśmy atrakcyjnym celem dla hakerów?
Każda firma, która przechodzi przez proces oceny ryzyka, musi podjąć próbę ustalenia indywidualnego wskaźnika poziomu zagrożenia. Pewne jest to, że prawdopodobieństwo będzie z pewnością większe od zera. Kolejnym krokiem po analizie prawdopodobieństwa wystąpienia incydentu zagrażającemu bezpieczeństwu systemu jest ustalenie skali zagrożenia i konsekwencji, jakie może wywołać udany atak.
Zrozumienie poziomu zagrożenia
Wypracowanie skali poziomu potencjalnych zagrożeń jest zadaniem skomplikowanym z racji dużej rozpiętości możliwych efektów ataku na system. Niską ocenę konsekwencji otrzymałoby zdarzenie, w którym haker włamuje się do systemu, ale nie udaje mu się przejąć kontroli nad układami sterowania i nie powoduje w nim jakichkolwiek szkód. Przykładem takiego incydentu jest wspominany wyżej atak na Independent System Operator w Kalifornii. Na drugim końcu skali znajdują się zdarzenia powodujące katastrofalne efekty, takie jak utrata życia, poważne zanieczyszczenie środowiska czy takie, które mogą spowodować wypadnięcie firmy z rynku.
Przewidywanie możliwych scenariuszy rozwoju sytuacji musi zawierać również przypadki najgorsze, takie jak:
- potencjalne zagrożenie eksplozją,
- przerwanie możliwości nadzoru procesu,
- zniszczenia produktów wynikające ze zmian w recepturach,
- uwolnienie produktu, półproduktu lub innych substancji używanych w produkcji do środowiska,
- zniszczenia urządzeń,
- strata obecnych i historycznych danych procesowych,
- ograniczenie możliwości produkcyjnych podczas napraw i konserwacji urządzeń,
- zagrożenia specyficzne dla danego sektora przemysłu.
Następnym krokiem po zidentyfikowaniu zagrożeń i określeniu poziomu możliwych konsekwencji jest uszeregowanie ich pod względem ważności. Może to być zadanie trudne, w szczególności gdy przyjdzie nam porównywać np. straty spowodowane brakiem surowców z możliwymi uszkodzeniami urządzeń. Tym bardziej, że rozpatrywane różnorodne skutki potencjalnych ataków mogą zostać złagodzone tymi samymi środkami zaradczymi. Tak czy inaczej, przypisanie poziomów ryzyka (bazujące na określonych poziomach ryzyka danego ataku) i możliwych skutkach dostarcza osobom podejmującym decyzje zestaw wskazówek do określenia planu rozwoju systemu zabezpieczeń.
Nieuchronność problemów
Udany cyberatak może spowodować mocno odczuwalne przerwy w dostawie energii. Podobne do tych, jakie miały miejsce 14 sierpnia 2003 roku na północno-wschodnim obszarze Stanów Zjednoczonych czy też braki innych istotnych surowców, jak na przykład ropy i gazu. Pomimo że zdarzenia z 14 sierpnia 2003 roku nie były spowodowane przez cyberatak, pokazały one jasno, jak wielki wpływ na gospodarkę mogą mieć systemy SCADA. Przytaczany incydent wpłynął na życie co najmniej 50 milionów ludzi i spowodował straty szacowane na co najmniej 6 miliardów USD.
Każda firma musi określić poziom potencjalnego zagrożenia cyberatakiem swojego systemu SCADA oraz spodziewane efekty dla przedsiębiorstwa, jego klientów i współpracowników. Szacunkom powinny zostać poddane również koszty, jakie należałoby ponieść w ramach programu zabezpieczeń. Rzetelna ocena pozwoli na wzrost efektywności i redukcję strat w następstwie ataku.
M. Henrie
P. Liddell
M. Henrie jest adiunktem w University of Alaska, P. Liddell jest nadzorcą systemu SCADA w Alyeska Pipline Sernice.
Artykuł pod redakcją dra inż. Pawła Dworaka, adiunkta w Zakładzie Automatyki Instytutu Automatyki Przemysłowej Politechniki Szczecińskiej. Pierwszą część artykułu opublikowaliśmy w listopadowym wydaniu Control Engineering Polska (?Przetrwać sezon na wirusy?).