Poradnik CERT: bezpieczeństwo nie kończy się na wydaniu produktu

CERT Polska udostępnił w poniedziałek 25 maja poradnik dobrych praktyk zarządzania bezpieczeństwem oprogramowania. Dokument w wersji 1.0 jest skierowany do producentów oprogramowania i produktów z elementami cyfrowymi. Proponujemy czytać go przez jedno pytanie, które dotyczy także firm kupujących takie produkty: kto odpowiada za bezpieczeństwo produktu po dniu wydania.

Wyobraź sobie budynek oddany do użytku z kompletem odbiorów, w którym nikt nie ma klucza do kotłowni. Pierwszej zimy protokół odbioru nikogo nie ogrzeje. Z oprogramowaniem może być podobnie: projekt ma kierownika, wydanie ma datę, a utrzymanie ma budżet zapisany jako „w razie potrzeby”. Pytanie o to, kto przyjmie zgłoszenie podatności w trzecim roku życia produktu, łatwo odłożyć do chwili, gdy takie zgłoszenie już czeka w skrzynce. Materiał opublikowany przez CERT Polska i NASK daje okazję, by zadać je wcześniej. Ten tekst nie streszcza poradnika i nie omawia obowiązków wynikających z CRA, do którego odwołują się tytuły komunikatów CERT Polska z 25 maja. Proponujemy kierunek rozmowy dla dwóch stron tej samej umowy: producenta i nabywcy.

Data wydania zamyka projekt, ryzyko zostaje w produkcie

Tytuł dokumentu CERT Polska i NASK brzmi „Dobre praktyki zarządzania bezpieczeństwem oprogramowania”. Słowo „zarządzanie” sugeruje proces, który trwa, a proces potrzebuje kogoś, kto go prowadzi. Projekt ma natomiast początek i koniec. Jeśli odpowiedzialność za bezpieczeństwo przypisano projektowi, to wraz z jego zamknięciem może ona zniknąć z każdego planu pracy, choć produkt nadal działa u klientów.

Mechanizm jest prosty i nie wymaga złej woli. Zespół przechodzi do kolejnego zadania, wiedza o zależnościach i decyzjach projektowych pozostaje w głowach kilku osób, a zgłoszenie dotyczące starszej wersji trafia do tego, kto akurat odbierze wiadomość. Każdy z tych kroków z osobna wygląda rozsądnie. Razem dają produkt, który formalnie jest utrzymywany, a w praktyce nie ma adresata.

Dlatego tezę tego tekstu formułujemy wprost: proces bezpieczeństwa oprogramowania wymaga właściciela przez cały okres utrzymania produktu. Nazwa stanowiska jest sprawą drugorzędną. Ważne, żeby dało się wskazać osobę i datę, do której jej odpowiedzialność obowiązuje.

Bezpieczeństwo produktu potrzebuje właściciela, który pozostaje przy nim po dniu wydania.

Procedura opisuje utrzymanie, skrzynka zgłoszeń pokazuje praktykę

Poradnik ma numer wersji 1.0. To drobny szczegół, ale wygodny punkt wyjścia do rozmowy w firmie. Dokument procesowy, podobnie jak kod, ma wersje, a każda wersja potrzebuje kogoś, kto ją przejrzy i podniesie numer. Procedura bez daty ostatniego przeglądu i bez nazwiska autora zmian zachowuje się jak biblioteka bez opiekuna: działa, dopóki nikt nie zapyta o jej stan.

Rozjazd między papierem a praktyką najłatwiej zobaczyć na jednej konkretnej sprawie. Opis procesu może zakładać, że zgłoszenie podatności trafia do zespołu produktu, który je ocenia i zamyka poprawką. Ostatnia obsłużona sprawa pokaże, czy tak się stało, kto zdecydował i gdzie to zapisano. Jeśli zapisu nie ma, nie oznacza to automatycznie, że nikt nic nie zrobił. Oznacza tyle, że firma nie potrafi tego wykazać.

Publikacja CERT Polska nie rozstrzyga, jak ten proces wygląda w konkretnej organizacji. Daje natomiast producentom wspólny punkt odniesienia, z którym mogą porównać własny opis i własne wykonanie.

Zarząd decyduje, kto podpisuje się pod utrzymaniem

Dla zarządu pytanie o właściciela bezpieczeństwa produktu jest pytaniem o odpowiedzialność, a dopiero potem o technikę. Ryzyko w okresie utrzymania przybiera trzy postaci: niezałatana podatność u klienta, spór o to, kto miał zareagować, i brak dowodów, że ktokolwiek zareagował. Tę trzecią najtrudniej naprawić po fakcie.

Koszt przypisania właściciela w konkretnej firmie pozostaje nieznany, dopóki nie wiadomo, ile produktów jest utrzymywanych i jak długo. Tej liczby nie da się wyczytać z poradnika ani z komunikatu z 25 maja. Można ją natomiast policzyć we własnym portfelu produktów, i to jest pierwszy krok, zanim padną deklaracje o budżecie.

Druga decyzja dotyczy dowodów. Zarząd, który ma przed sobą wyłącznie deklarację „produkt jest bezpiecznie utrzymywany”, podpisuje się pod czymś, czego nie widzi. Zarząd, który ma przed sobą zapis z ostatniej obsłużonej sprawy, wie przynajmniej, o co pytać.

Deklaracja utrzymania jest obietnicą; zapis z ostatniej obsłużonej sprawy jest dowodem.

Polski nabywca dostaje wspólny język do rozmowy z dostawcą

Poradnik CERT Polska jest skierowany do producentów, ale jego publikacja ma znaczenie także dla polskich firm, które oprogramowanie i produkty z elementami cyfrowymi kupują. Nabywca rzadko widzi proces bezpieczeństwa dostawcy od środka. Może jednak zapytać o jego właściciela, posługując się nazwą dokumentu, który obie strony mogą otworzyć: „Dobre praktyki zarządzania bezpieczeństwem oprogramowania”, wersja 1.0, CERT Polska i NASK.

Takie pytanie zadajmy spokojnie, bez tonu kontroli. Dokument ma w nazwie dobre praktyki, więc nie traktujmy go w rozmowie z dostawcą jako katalogu wymagań, których nie sprawdziliśmy u źródła. Obowiązki prawne, w tym te związane z CRA, wymagają osobnej analizy. Pytanie o właściciela bezpieczeństwa w okresie utrzymania ma tę zaletę, że dostawca może na nie odpowiedzieć jednym nazwiskiem i jedną datą. Brak takiej odpowiedzi też jest informacją.

Co z tym zrobić w poniedziałek

Otwórz PDF poradnika w wersji 1.0 i wybierz jeden produkt, własny albo kupowany. Zapisz, kto dziś odpowiada za jego bezpieczeństwo po wydaniu i do jakiej daty ta odpowiedzialność obowiązuje. Puste pole w tej notatce też jest wynikiem.
Jeśli jesteś producentem, prześledź ostatnie zgłoszenie dotyczące najstarszej utrzymywanej wersji produktu: kto je przyjął, kto zdecydował o reakcji i gdzie to zapisano. Rozbieżności z opisem procesu zanotuj jako pytania do zespołu, bez szukania winnych.
Jeśli jesteś nabywcą, wyślij dostawcy produktu, od którego firma najbardziej zależy, jedno pytanie: kto po jego stronie odpowiada za bezpieczeństwo produktu do końca okresu utrzymania i jak dowiecie się o zmianie tej osoby. Odpowiedź dołącz do dokumentacji umowy.

Wydanie produktu kończy pracę zespołu projektowego, ale ryzyko nie znika u klienta, dopóki produkt działa. Poradnik CERT Polska z 25 maja jest dobrym pretekstem, by przypisać to ryzyko konkretnej osobie po obu stronach umowy. Firma, która potrafi wskazać właściciela i pokazać zapis jego ostatniej decyzji, ma o czym rozmawiać z zarządem i z klientem.

Źródła

Redakcja cyberinsight.pl.