Redakcja Asseco News
e-mail: [email protected]
Rozbudowa systemów IT niesie za sobą szereg potencjalnych zagrożeń i ryzyka. O tym, w jaki sposób przeprowadzać takie procesy umiejętnie, zwłaszcza w przypadku kluczowych systemów informatycznych w państwie, opowiada Maciej Michalski, Zastępca Dyrektora Pionu Ubezpieczeń Społecznych w Asseco Poland.
Zintegrowana infrastruktura informacyjna państwa jest obecnie coraz bardziej osadzona w sieci powiązanych ze sobą systemów informatycznych. Czy narzuca to dodatkowe ryzyka i obowiązki związane z ich utrzymaniem?
Wysoki poziom integracji systemów zapewnia ich synergię funkcjonalną, ale równocześnie sprawia, że ewentualne niepowodzenia tworzą nie tylko turbulencje w obszarze działalności danego systemu, ale także w rozwiązaniach, z którymi współpracuje. Jest to czynnik ryzyka, który będzie narastał, gdyż z jednej strony zwiększamy liczbę interfejsów między systemami, czyli zagęszczamy tą sieć, a z drugiej strony – zwiększamy dynamikę zmian jej elementów. Jeżeli popatrzymy na resortową mapę systemów, które podlegają rozwojowi w poszczególnych ministerstwach, to trzeba zdać sobie sprawę, że jest to nieustający plac budowy, na którym ciągle coś się dzieje. Jesteśmy w trakcie permanentnych zmian, które choć są równoległe, to odbywają się niezależnie, bez niezbędnej koordynacji. Dlatego konieczna jest wymiana informacji dotyczących modyfikacji realizowanych w poszczególnych systemach. Czas zacząć zarządzać zmianą zintegrowanej infrastruktury informacyjnej państwa, a nie tylko jej elementami.
Czy to ryzyko nie jest wyolbrzymione? Przecież budowy tych systemów się kiedyś zakończą.
Wręcz przeciwnie, jest to bardzo realne ryzyko. Bieżący obraz informatyki na świecie jest dokładnie odwrotny. Wynika to z jej rosnącej roli w sferze gospodarczej oraz społecznej, ale również z obserwowanego wyścigu technologii, który wymusza ciągły rozwój lub modyfikację rozwiązań. Choć będą realizowane działania ograniczające częstotliwość zmian, w tym konsolidacja systemów w sferze technicznej, to jednak na dużą konsolidację funkcjonalną na razie nie można liczyć. Dlaczego? Głównie z powodu resortowej specjalizacji obowiązków i kompetencji wynikającej bezpośrednio z ustaw. A to oznacza, że musimy przyzwyczaić się i nauczyć funkcjonować w stanie permanentnej zmiany systemów i w konsekwencji całej infrastruktury informacyjnej państwa. Paradoksalnie, szczególnie niebezpieczne nie są zmiany funkcjonalne, tylko projekty o charakterze niefunkcjonalnym lub konserwacyjnym, które realizowane są w trakcie działania systemu. Żeby lepiej zobrazować ryzyko związane z ich wprowadzeniem, możemy je porównać do wymiany podwozia w jadącym samochodzie, którym podróżuje komplet pasażerów.
Ryzyko istnieje, ale czy inicjatywy w obszarze cyberbezpieczeństwa nie adresują tego problemu?
Bieżące inicjatywy w obszarze cyberbezpieczeństwa skupiają się wyłącznie na zagrożeniach zewnętrznych. To jest bezspornie ważne, natomiast równolegle powinniśmy budować również tarczę przed zagrożeniami wewnętrznymi. Przecież nieumiejętne przeprowadzenie zmian rodzi takie samo zagrożenie, jak cyberatak.
Czy takie porównanie nie jest przesadą?
Zdecydowanie nie. Haker skupia się na poufności danych, ich integralności lub dostępności, a cyberatak ma za zadanie zniszczyć jedną lub kilka tych cech. Takie same skutki może mieć nieudana zmiana w systemie, ponieważ w jej trakcie możemy unieruchomić system, zniszczyć dane lub je ujawnić. Wniosek jest taki, że wszyscy jesteśmy potencjalnymi hakerami.
Czyli powinniśmy zarządzać ryzykiem wprowadzania zmian w infrastrukturze informacyjnej państwa, które będzie rosło wraz ze wzrostem integracji i rolą biznesową systemów IT? W jaki sposób można to realizować?
Po pierwsze trzeba wypracować mechanizmy koordynacji zmian systemów składowych. Nie musimy ich tworzyć od nowa, możemy skorzystać z istniejących i sprawdzonych rozwiązań, jak np. metodyka zarządzania zmianą ITIL (ang. Information Technology Infrastructure Library), będąca zbiorem dobrych praktyk na temat efektywnego i skutecznego utrzymywania systemów informatycznych w ruchu. Wystarczy, że będziemy ją stosować na poziomie infrastruktury państwa, a nie tylko na poziomie poszczególnych systemów.
Równocześnie powinny zostać uruchomione procesy komplementarne, jak np. zarządzanie konfiguracją, projektami, czy ciągłością usług. W języku potocznym, oznacza to, że musimy wiedzieć z jakich systemów się składa nasza sieć, czy i kiedy planowane są zmiany, jakie są powiązania między systemami, a także poznać ich ograniczenia czasowe oraz wydajnościowe. Niestety brakuje nam takich informacji na poziomie krajowym.
Trzecim elementem potrzebnym do skutecznego zarządzania zmianą jest stworzenie ujednoliconych mechanizmów szacowania ryzyka dla wszystkich systemów składających się na infrastrukturę informacyjną państwa.
Jakie więc konsekwencje niesie za sobą brak odpowiednich mechanizmów zarządzania zmianą?
To przede wszystkim potencjalna niedostępność usług IT – a w efekcie usług publicznych. A te niestety wiążą się z kosztami. Wynikają one z przestoju organizacji, utraconego przychodu, kosztu przywracania systemu do pracy oraz likwidacji ewentualnych szkód. Należy też uwzględnić tzw. czynniki nieuchwytne, jak choćby utrata prestiżu czy zaufania do marki. Żeby sprawdzić wysokość ewentualnych strat, przeprowadziliśmy w Asseco symulację kosztów jakie wiążą się ze wstrzymaniem pracy niektórych systemów z sektora publicznego. Na potrzeby naszych wyliczeń dodatkowo wykorzystaliśmy opracowanie Roberta Kaplana, które redefiniuje utracony przychód dla organizacji sektora publicznego na tzw. „lost customer value” – czyli koszt klientów związany z niedostępnością usługi publicznej.
W kalkulacji ryzyka uwzględniliśmy pięć głównych czynników, które znacznie wpływają na prawdopodobieństwo i koszt wystąpienia awarii: biznesowa rola usług IT, ich złożoność, architektura systemu, wielkość danych oraz technologia. Analizie poddaliśmy cztery systemy informatyczne: KSI Zasiłki, stanowiącego 10 % całego systemu KSI ZUS, eRecepta, KRS oraz Bezpieczny Autobus, dla których obliczyliśmy koszty związane z wystąpieniem trwającej 30 dni awarii. Z naszych kalkulacji wynika, że w przypadku KSI Zasiłki to strata w wysokości ponad 70 mln zł, a miesięczna niedostępność systemu eRecepta to ponad 60 mln zł. Natomiast taki sam przestój działania systemu Bezpieczny Autobus niesie za sobą nieporównywalnie mniejsze straty, które wynoszą ok. 11 tys. zł. Powyższe obliczenia pokazują, jak poszczególne systemy różnią się od siebie skalą ryzyka.
Kontrast pomiędzy tymi systemami pokazują także nasze obliczenia dotyczące prawdopodobieństwa wystąpienia awarii. W tej analizie przyjęliśmy skalę punktową bazującą na czterech cechach: złożoność funkcjonalna i technologiczna, architektura systemu (monolityczność) oraz wielkość danych operacyjnych. Wykazała ona, że ponownie względne prawdopodobieństwo wystąpienia awarii było trzykrotnie większe dla KSI Zasiłki niż np. KRS. A po uwzględnieniu kosztów niedostępności rozwiązania, różnice związane z ryzykiem wystąpienia awarii wyniosły nawet kilka tysięcy procent.
Czy w takim razie powinniśmy dzielić systemy na strategiczne i niestrategiczne z punktu widzenia funkcjonowania państwa?
Powinna to być raczej segmentacja wielopoziomowa. Przykładem dobrej praktyki w tym zakresie jest opracowany przez Amerykański Departament Obrony „Orange Book”, który stworzył 9-cio stopniową klasyfikację systemów informatycznych z punktu widzenia bezpieczeństwa informacji. Kryteria są tu jednoznaczne i wspólne – nie ma tam miejsca na uznaniowość. Dlatego podobne rozwiązanie powinno zostać przyjęte w Polsce, przynajmniej w stosunku do systemów wchodzących w skład zintegrowanej infrastruktury informacyjnej państwa. Punktem wyjścia dla takiej segmentacji może być skala ryzyka oszacowana w jednolity sposób. Jednak sama kilkustopniowa klasyfikacja nie wystarczy – przy tak dużej dysproporcji skali ryzyka, potrzebne są różne procedury realizacji projektów informatycznych – również w zakresie prawa zamówień publicznych.
Bo na przykład jeżeli pojawi się awaria aplikacji Bezpieczny Autobus to użytkownik nie będzie miał możliwości sprawdzenia ważności badań technicznych pojazdu, którym podróżuje jego dziecko. Natomiast jeżeli będzie to awaria systemu Zasiłki KSI ZUS, to 450 tys. osób nie otrzyma terminowo wypłaty świadczeń. Skoro te systemy tak bardzo różnią się skalą ryzyka, to nasuwa się pytanie: czy chcemy rozbudowywać te systemy w oparciu o te same wymagania kompetencyjne? Czy powinny je obowiązywać takie same procedury? Oczywiście, że nie, ponieważ one diametralnie różnią się od siebie. A skoro tak, to powinny dla nich zostać stworzone oddzielne polityki prowadzenia projektów.
Jakie więc powinny być polityki rozwoju tych systemów – w szczególności systemów wysokiego ryzyka?
Polityki rozwoju systemów wysokiego ryzyka powinny być konstruowane w oparciu o wymagania z przynajmniej trzech obszarów. Pierwszym z nich są kompetencje wykonawcy i dostępność personelu, które niewątpliwie minimalizują ryzyko wystąpienia awarii. Z tego właśnie powodu systemów o najwyższej skali ryzyka nie powinno się realizować personelem wynagradzanym wg stawki „młodszy programista Java”. A taka stawka dominuje obecnie przy projektach w administracji publicznej. Są to realizacje, których nie da się zrealizować z sukcesem bez doświadczenia i wysokich umiejętności zespołu. Niezależnie czy stosujemy bardziej czy mniej zwinną metodykę prac.
Drugim obszarem, jaki powinien zostać zdefiniowany są wymagania konstrukcyjne jak np. RTO (ang. recovery time objective) – czyli czas w jakim należy przywrócić system do działania. Oznacza to, że rozwiązania, których awarie mogą generować wielomilionowe straty, powinny mieć narzucony krótki czas powrotu do działania. Podnosi to co prawda koszt inwestycji, ale pozwala skrócić czas uruchomienia systemu np. 4 dni do 15 minut. Jest to element, który np. w przypadku systemu eRecepta, może stanowić o życiu bądź zdrowiu pacjenta.
Trzecia grupa to wymagania proceduralne, które powinny np. określić limity czasu reakcji na błędy oraz termin, w jakim wykonawca ma doprowadzić do całkowitej sprawności systemu. Ich konstrukcja powinna wykluczać sytuację, w której jako najkorzystniejsza może zostać wybrana najtańsza oferta, o najdłuższym czasie reakcji na błędy, co w przypadku ważnych systemów wiąże się z wysokimi stratami finansowymi. Dlatego zamawiający powinien jasno określić wymogi w tym zakresie i brać pod uwagę ofertę tylko takiego wykonawcy, który jest w stanie je zagwarantować. W innym wypadku nie będzie pewności, że ten system krytyczny będzie serwisowany w należytym terminie.
Dlaczego więc w Polsce nie funkcjonują odrębne polityki dla projektów o różnym poziomie ryzyka?
Zapewne dlatego, że ich wypracowanie stanowi duże wyzwanie, które wymaga uzgodnień międzyresortowych. Jednak stworzenie odpowiednich procedur jest bardzo ważne, ponieważ obecne zamówienia publiczne w obszarze IT w niewystarczającym stopniu adresują ryzyko. Dzieje się tak, ponieważ nie ma odpowiednich mechanizmów kontroli i weryfikacji zrealizowanych projektów. Jest to sytuacja, która nie byłaby akceptowana w przypadku innych branż inżynieryjnych, takich jak np. branża budowlana. Ten sektor regulują ustawy i szereg norm, które muszą być przestrzegane. Dlaczego więc nie dzieje się tak w przypadku projektów IT, które są tak ważną częścią prawidłowego funkcjonowania państwa? Dlaczego istniejące przepisy pilnują wyłącznie procesu udzielania zamówienia , a nie wykonanie projektu?
Zmiany w tym obszarze mają bardzo duże znaczenie, ponieważ pozwolą one na poprawę skuteczności projektów informatycznych. Dzięki temu będziemy mogli uniknąć takich sytuacji jak np. opóźnienie projektu CEPIK czy fiasko pierwszej fazy projektu P1, której budowa kosztowała ok. 460 mln zł.
Dlatego powinniśmy starać się nadrobić tą zaległość inżynierii informatycznej w stosunku do pozostałych branż i formalizować proces dostarczania oraz zmiany systemów IT. Zacznijmy od ich klasyfikacji, a następnie policzmy ryzyko. Porównajmy systemy i stwórzmy zasady, które uchronią strategiczne z punktu widzenia państwa rozwiązania informatyczne przed brakiem kompetencji oraz odpowiedzialności wykonawców. Wyeliminujmy możliwość udzielenia zamówienia wykonawcy, który jest zupełnie nieprzygotowany i nawet nie ma świadomości swojej niekompetencji. Bo tak jak wspomniałem, koszty niedostępności mogą być duże, a sumaryczny rachunek płacimy wszyscy.