Dług technologiczny

Obserwując rozwój nowoczesnych technologii z perspektywy działań na rzecz zapewnienia bezpieczeństwa informacji nie można oprzeć się wrażeniu, że pogoń za funkcjonalnościami nie idzie w parze z jakością ich zaprojektowania, wykonania i eksploatacji. Nie ma tygodnia by nie pojawiały się doniesienia o kolejnych znacznych awariach czy wyciekach danych. Kilka lat temu wprowadzono już nawet do statystyk kategorię "megawycieków" by lepiej wyróżniać te przypadki, gdzie ujawniono powyżej 10 milionów nielegalnie przejętych zestawów danych. Pojawia się pytanie jak to możliwe, że systemy zabezpieczające potężne firmy - często międzynarodowych gigantów, można skompromitować w trywialny niekiedy sposób. Odpowiedzią na to jest zjawisko "długu technologicznego".

Pogoń działów biznesowych ku "nowinkom", które pozwolą wyprzedzić konkurencję (choć niestety czasami również zupełna ignorancja) coraz częściej nie pozwala na adekwatne zabezpieczenie oferowanych technologii. Przyjmuje się założenie, że organizacje, we właściwym czasie, nadrobią zaległości. Wpierw kierownictwo chce się jednak upewnić, że pomysł biznesowy się sprawdzi - a gdy przychody osiągną zadowalający poziom, wtedy organizacje zatroszczą się o szczegóły technologiczne. Rozumowanie to - nie pozbawione sensu - prowadzi niekiedy do wyjątkowo złych skutków. Zdarza się, że takie organizacje, w kwestii bezpieczeństwa, nie robią praktycznie nic. Inaczej nie można bowiem interpretować przypadków ujawniania milionów nazw użytkowników wraz z nie zaszyfrowanymi hasłami, czy stosowania haseł administracyjnych (niekiedy trywialnych) zapisanych jawnym tekstem w kodzie źródłowym, nie wspominając już nawet o wynikach solidnie przeprowadzonych analiz bezpieczeństwa.
Na załączonej przykładowej grafice pokazałem schematycznie dług technologiczny. Założyłem (może przewrotnie), że początkowo aplikacja pisana jest zgodnie z arkanami bezpieczeństwa i "jest bezpieczna". Na wersji 1.0 jednak zakończone są prace programistyczne i nie są wprowadzane poprawki dla nowy wykrywanych podatności, a od wersji 1.1 organizacja koncentruje się na nowych funkcjonalnościach. Zabezpieczenia doskonalone są dopiero w wersji 2.0, ale i tak wyłącznie do poziomu luk definiowanego lukami z wersji 1.0. A aplikacja cały czas jest rozwijana, więc dług technologiczny narasta.

Zapewnienie (w tym zweryfikowanie) wysokiego poziomu bezpieczeństwa aplikacji kosztuje. Nie są to pomijalne kwoty, z drugiej jednak strony trzeba podkreślić, że są zupełnie realne dla organizacji, którym zależy na stworzeniu produktu wysokiej jakości. Chciałbym jednak podkreślić, że wytwórcy aplikacji (jak również zamawiający) mogą zrobić bardzo dużo dobrego bez ponoszenia nadmiernych kosztów. Kluczowe błędy - te, których wykorzystanie jest trywialne i doprowadza do urzeczywistnienia się najgorszych scenariuszy ryzyka, zależą zazwyczaj od odpowiedniego zorganizowania projektu.

Przede wszystkim konieczne jest poprawne zdefiniowanie "co" dana aplikacja powinna przygotowywać. Może brzmieć do banalnie, ale wiele, nawet wielomilionowych systemów, nie udało się przygotować, gdyż nie udało się zdefiniować zamkniętego zbioru funkcjonalności. Bez kierownika projektu, który będzie realizować konkretną(!) wizję właściciela biznesowego, system może zostać rozdmuchany do niebotycznych rozmiarów, lub też może zawierać niewystarczającą liczbę funkcjonalności. Tak zwane "przypadki użycia" są uporządkowaną listą wszystkich funkcjonalności, które powinna realizować aplikacja. Dodam od razu, że powinna ona bezpośrednio przekładać się na tak zwane "scenariusze testowe", by podczas odbioru zamawiający miał szansę potwierdzić, czy dostarczony produkt jest tym, którego potrzebował. Dla dostawców jest to sposób na potwierdzenie, że praca została zakończona, niezależnie od dalszych, pojawiających się w ostatniej chwili, życzeń zamawiającego. Warto w tym momencie zareklamować stosunkowo rzadko wykorzystywaną, a bardzo przydatną normę ISO 25010, która pozwala opisać jakość systemów informatycznych w sposób kompletny.

Następnym elementem są kwestie organizacyjne związane z tym:
    • jak zapewnia się brak błędów (często np. stosuje się weryfikację wpisywanego kodu przez inną osobę oraz integruje systemy deweloperskie z automatycznymi narzędziami),
    • skąd pochodzą gotowe moduły (programiści często wykorzystują do prac gotowe moduły, nie zawsze potwierdzając czy nie łamią tym samym praw autorskich, a niekiedy takie moduły zawierają potężne błędy),
    • jak zapewnia się kompletność prac (prace programistyczne często prowadzone są w wielu tzw. gałęziach, dlatego przed kompilacją nowej wersji należy upewnić się, że wszystkie istotne elementy pozostały zakończone.

Dopiero kolejnym z elementów jest zapewnienie by sam kod był bezpieczny. A i tutaj wiele dobrego można zrobić samemu, pilnując by w wymaganiach dla nowotworzonego systemu znajdowała się konieczność spełniania wymagań regulacyjnych (np. RODO czy standardy branżowe), a sam kod by był pisany zgodnie z międzynarodowymi standardami, jak np. wspomniany już kiedyś przez mnie OWASP Application Security Verification Standard. Innymi prostymi elementami, które często się pomija, a których brak mści się po jakimś czasie są poprawnie przeprowadzone testy odbioru i rzetelna dokumentacja.

Dług (również technologiczny) ma to do siebie, że spłaca się go razem w odsetkami. Przybierają one postać dodatkowych kosztów (im później wdraża się elementy bezpieczeństwa, tym są one droższe) lub też bezpośrednich strat (np. odszkodowań lub kar umownych). Może się nawet zdarzyć, że te "odsetki" przeważą o upadku całej organizacji.
Istotę zarządzania ryzykiem dla bezpieczeństwa informacji stanowi rozpoznanie różnicy pomiędzy nakładami na zabezpieczanie systemów a określaniem potencjalnej straty. Koszty można łatwo policzyć, ale apeluję - poświęćmy też chwilę by poznać potencjalne konsekwencje i dopiero później - ewentualnie, by je świadomie zaakceptować.