Share
Pojęcie długu bezpieczeństwa
Według Simo Huopio, który jest autorem publikacji pt. „A Quest for Indicators of Security Debt” [1] pojęcie długu bezpieczeństwa / zadłużenia w zakresie bezpieczeństwa (ang. „Security Debt”, „SD”) zostało wprowadzone do obiegu przez Chrisa Wysopala w 2011r. [2], a następnie szerzej dyskutowane – w kontekście samego oprogramowania – przez Davida Conway [3] oraz duet Whitehouse i Vaughn [4]. W skrócie oraz w nawiązaniu do istniejącego już wcześniej pojęcia „długu technologicznego” dług bezpieczeństwa można określić jako:
„wszystkie te prace mające na celu ograniczenie ewentualnych skutków wystąpienia zidentyfikowanych lub niezidentyfikowanych problemów związanych z bezpieczeństwem (np. w ramach danego systemu, oprogramowania, produktu, platformy lub usługi), które nie zostały przeprowadzone w odpowiednim czasie (np. wynikającym z harmonogramu danego projektu).”
Źródła długu bezpieczeństwa
Dług bezpieczeństwa powstaje w wyniku działań lub zaniechań własnych organizacji, a także jej dostawców i podwykonawców, a także jakichkolwiek innych osób trzecich, których produkty (np. oprogramowanie) są przez nią wykorzystywane. Co istotne, powstaje on także w wyniku nakładania na organizację ustawowych lub umownych nowych obowiązków prawnych w zakresie bezpieczeństwa.
Skutki istnienia długu bezpieczeństwa
W praktyce zatem niemal każda organizacja (np. przedsiębiorstwo), a w szczególności operatorzy usług kluczowych (OUK) w rozumieniu Ustawy o krajowym systemie cyberbezpieczeństwa [5] zaciąga określony dług bezpieczeństwa, który wcześniej lub później będzie należało spłacić poprzez wdrożenie mniej lub bardziej stopniowych lub wręcz skokowych zmian mających na celu podniesienie poziomu bezpieczeństwa danego systemu, oprogramowania, produktu, platformy lub usługi.
Jednocześnie należy pamiętać o tym, że w zależności od tego jak duży dług zaciągnięto (np. w wyniku zaniedbań lub ograniczania wydatków), jego spłata (tj. zmniejszenie długu) może być związana z większymi lub mniejszymi kosztami.
Nie bez znaczenia pozostaje także fakt, że im większy dług organizacji w zakresie bezpieczeństwa oraz mniej uzasadniona przyczyna jego zaistnienia (np. zaniedbania) tym wyższa ekspozycja organizacji na ryzyko ponoszenia odpowiedzialności odszkodowawczej wobec kontrahentów, w tym klientów końcowych, a także ryzyko nałożenia odpowiednich administracyjnych kar finansowych ze strony właściwych organów nadzorczych (np. organy właściwe ds. cyberbezpieczeństwa). W określonych przypadkach członkowie zarządu danej organizacji mogą także ponosić odpowiedzialność karną.
Skutki istnienia długu bezpieczeństwa stanowią także wszelkiego rodzaju zdarzenia mogące spowodować lub powodujące naruszenie poufności, integralności, dostępności, a także autentyczności danych oraz związanych z nimi usług jakie są oferowane z wykorzystaniem systemów informacyjnych danej organizacji.
Mierzenie i ocena długu bezpieczeństwa
W konsekwencji niezwykle ważna jest zdolność organizacji do mierzenia i oceny wysokości zaciąganego (np. w trakcie zamawiania/zakupu danego produktu, usługi lub systemu) lub już zaciągniętego długu w zakresie bezpieczeństwa. Do powyższego służy cały szereg instrumentów o charakterze techniczno – organizacyjno-prawnym, które określa się mianem „Security Debt Indicator Framework” (SDIF) co w wolnym tłumaczeniu oznaczałoby Ramowe Wskaźniki Długu Bezpieczeństwa (RWDB) [6].
W przypadku zamawiania nowych produktów lub usług instrumentami, które mogą pomóc przy mierzeniu zaciąganego przez zamawiającego długu w zakresie bezpieczeństwa mogą być zatem informacje i analizy na temat [7]:
- wewnętrznych wymogów dostawcy co do zamawianego produktu/usługi (np. zakres i okres oferowanego przez dostawcę wsparcia i rozwoju produktu);
- wewnętrznego procesu zapewniania przez dostawcę bezpieczeństwa produktów/usług (np. wdrożone w organizacji dostawcy normy i standardy, a także zakres i częstotliwość przeprowadzanych testów);
- zarządzanie przez dostawcę długiem technologicznym (np. monitorowanie długu technologicznego i narzędzia do tego wykorzystywane);
- wymogi zamawiającego wobec produktów/usług (np. SLA dot. czasu i zakresu reagowania na incydenty bezpieczeństwa lub usuwania nieprawidłowości);
- zdolności zamawiającego do analizy bezpieczeństwa (np. możliwość komunikowania błędów do dostawcy, dostęp do kodu źródłowego);
- zdolności zamawiającego do prowadzenia bezpiecznych operacji w ramach np. danego systemu (np. trening personelu, monitorowanie zmian w systemie, zabezpieczenia fizyczne, korzystanie z usług SOC).
Część z powyższych instrumentów może zostać wdrożona poprzez zawarcie odpowiednich wymogów w dokumentacji przetargowej oraz umowie zawieranej z dostawcą.
Nie można również zapominać o tym, że przekazanie zamawiającemu przez dostawcę części z w/w informacji może być związane z ujawnieniem przez niego i/lub jego podwykonawców i innych kontrahentów tajemnicy przedsiębiorstwa. Z tego też względu część wskazanych powyżej instrumentów nie będzie możliwa do realizacji lub związana z dodatkowymi obostrzeniami nałożonymi przez dostawcę.
W przypadku gdyby byli Państwo zainteresowani odbyciem rozmowy w sprawie tego jak zarządzić prawnie długiem bezpieczeństwa w ramach realizowanego Projektu prosimy o kontakt z Pawłem Gruszeckim pod adresem: pawel.gruszecki@dzp.pl.
[1] Simo Huopio, A Quest for Indicators of Security Debt w: The Cyber Defense Review (CDR), 23 Marzec, 2020;
[2] D. Geer, C. Wysopal, For Good Measure – Security Debt. ;login: 2013, 38 no. 4, 62-64;
[3] D. Geer, D. Conway, Foor Good Measure – The Price of Anything Is the Foregone Alternative, login: 2013, 38 no. 3, 58-60;
[4] Ollie Whitehouse, James Vaughan, Software Security Austerity – Software security debt in modern software development, Rexc Whitepaper 2012, 1;
[5] Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U.2018.1560 ze zm.);
[6] ] Simo Huopio, A Quest for Indicators of Security Debt w: The Cyber Defense Review (CDR), 23 Marzec, 2020;
[7] ] Simo Huopio, A Quest for Indicators of Security Debt w: The Cyber Defense Review (CDR), 23 Marzec, 2020.
