Jak Jira i Confluence pomagają w zbudowaniu Systemu Zarządzania Bezpieczeństwem Informacji?

Przełom czerwca i lipca 2019 był dla nas intensywny. Ze względu na coraz bardziej dynamiczny rozwój spółek w Grupie Kapitałowej TT, stopniowo stawało się jasne, że w dłuższej perspektywie nie jest możliwe utrzymanie centralnego ZSZ (w którego skład obok standardów ISO9001, ISO20000, OHSAS wchodził także ISO27001). Należało działać.

Zdecydowaliśmy, aby odpowiedzialność za zapewnienie bezpieczeństwa informacji (i innych systemów) spadła odpowiednio na każdą ze spółek, która je wykorzystuje. Dosyć przewrotny pomysł jak na ciepły, leniwy i wakacyjny okres (tak, w tamtym czasie możliwości wyjazdów znacznie wykraczały poza salon, taras i ogródek z czego wielu z nas chętnie korzystało). Zadanie tyle wzniosłe co ambitne. Do dyspozycji był działający system centralny w GKTT oraz cała masa doświadczeń zebranych przez wiele lat jego funkcjonowania. Nic tylko korzystać z tej wiedzy, dokumentacji i wypracowanych już narzędzi… a może jednak lepiej zacząć wszystko od podstaw? Z jakiegoś powodu to pytanie nie dawało nam spokoju.

Ewolucja czy rewolucja?

Odwieczny dylemat. W jednym z moich poprzednich artykułów pt. „Jak skutecznie przeprowadzić transformację cyfrową w swojej firmie?” przekonywałem, że jeśli nie mamy dobrego argumentu za rewolucją, to powinniśmy się trzymać ewolucji. W przypadku błędnej decyzji cofnięcie się o krok lub dwa jest znacznie prostsze. No właśnie – jeśli nie mamy dobrego argumentu. Ogólnie rzecz biorąc, zadanie przed jakim staliśmy wymagało trzech rzeczy:

1. Określenia jakiego zakresu ZSZ potrzebujemy w organizacji – tutaj wybór był prosty, gdyż jako dostawca usług programistycznych skupiamy się przede wszystkim na bezpieczeństwie informacji.
2. Analizy całego ZSZ i wyłuskania z niego dokumentów, procesów, praktyk i sposobów zapewnienia bezpieczeństwa informacji.
3. Zaadaptowania powyższych do naszych potrzeb biznesowych, struktury organizacyjnej i dobrych praktyk.

Krok pierwszy był kwestią kilku minut. Banał. W kroku drugim zaczęły się schody. Zintegrowany System Zarządzania okazał się być rzeczywiście w dużym stopniu zintegrowany. Nie było prostego i szybkiego sposobu aby wyłuskać tylko część związaną z bezpieczeństwem informacji. Jedyną opcją było skatalogowanie wszystkich dokumentów, żmudne ich przeanalizowanie, a następnie przepisanie i dostosowanie do naszych potrzeb. Żadnej drogi na skróty. Ale to zapaliło światełko w tunelu. Skoro nie możemy przyspieszyć sobie pracy w ciemno wchłaniając części systemu to może użyjemy narzędzi, które pozwolą nam wygodniej, szybciej i efektywniej system ten wdrożyć i nadzorować? Właśnie znaleźliśmy argument za rewolucją. Punkt trzeci na naszej liście zaczął nabierać kształtu.

Gdzie Excel nie może tam Jirę pośle

Moją intencją nie jest krytyka Excela. To świetne narzędzie, jednak niekoniecznie pozwala uzyskać poziom wydajności i łatwości utrzymania jakiego wymagamy od SZBI w TTPSC. Co więcej, status Platynowego Partnera marki Atlassian zobowiązuje. Od wielu lat pracujemy w oparciu o systemy Jira i Confluence oraz wykorzystujemy całą plejadę rozszerzeń do nich. Mając już za sobą analizę dokumentacji ZSZ (tak zrobiliśmy to dokument po dokumencie, zdanie po zdaniu😊), strukturę i treść polityk BI jakie będą stosowane w TTPSC, należało się zastanowić nad narzędziami. I tak kolejno:

• Repozytorium dokumentów (Word, Excel, PDF i inne) w Sharepoint, zastąpiliśmy treściami opublikowanymi na stronach Confluence – załatwiło nam to sprawę wersjonowania, dostępu dla pracowników i kontroli nad zmianami. Bazujemy jedynie na wbudowanych mechanizmach dostępnych w standardzie. Zero kodowania. Szybko, efektywnie i bez konieczności wprowadzania dodatkowych narzędzi.

• Zgłaszanie incydentów, działań i innych zdarzeń istotnych z punktu widzenia utrzymania SZBI – na szczęście jest to punkt łączący wszystkie normy jakie wchodziły w skład ZSZ. Przez lata funkcjonowania ZSZ udało się wypracować w GK TT bardzo dobry mechanizm oparty o Jira do zgłaszania i zarządzania zdarzeniami. Każde zgłoszenie ma swój typ (Incydent, Potencjał doskonalenia, Niezgodność, Działanie) oraz szereg atrybutów pomagających w klasyfikacji zdarzenia, co potem pozwala na bardzo precyzyjną analitykę i monitorowanie. Zgłoszenia posiadają swój cykl życia, możliwość delegowania ich określonym osobom, zapewniają zapisy z działań, pozwalają na grupowanie i łączenie, a także wiele innych rzeczy, osiągalnych za pośrednictwem podstawowych funkcji Jira. Jest to kluczowy element systemu.

• Monitorowanie efektywności i pomiar realizacji celów – zgłoszenia incydentów czy działań w usystematyzowanej formie to podstawa. Ich ręczna analiza czy raportowanie wyników pomiarów w excelu byłoby herezją. Musi to być w zautomatyzowane, czytelne i dostępne online z zachowaniem odpowiednich uprawnień. Brzmi skomplikowanie. Nic bardziej mylnego – z pomocą przychodzą również wbudowane mechanizmy Jira i Confluence oraz bardzo wysoki stopień integracji obu systemów. Dzięki temu, w każdej chwili mamy dostęp do najważniejszych wskaźników i stopnia realizacji celów, nie wykonując choćby jednej operacji, zapytania do bazy danych czy makra w excelu. Używamy jedynie filtrów, raportów, makr i widgetów.

• Macierz ryzyk. Na koniec zostawiłem najlepsze. W sieci znajdziemy setki szablonów w excelu z propozycjami organizacji macierzy ryzyk. Wszystkie one mają jedną wspólną cechę – brak możliwości integracji z innymi częściami SZBI. Co to powoduje? To, że przy 30 i więcej ryzykach excel taki staje się kompletnie niezarządzalny. Zaglądamy do niego z niechęcią. Trudno się czyta zawartość pól. Jeszcze trudniej odtworzyć powiązania między nimi. Natomiast kompletną abstrakcją i akrobatyką mentalną jest śledzenie działań w ramach ryzyk. Niewykonalne? A jednak. Z pomocą przyszedł nam doskonały dodatek do Jira – Big Picture. O samym dodatku można napisać niejeden artykuł, ale na nasze potrzeby nieoceniony okazał się moduł do zarządzania ryzykami. Pozwala on na stworzenie (i zwizualizowanie!) macierzy, łatwe przenoszenie ryzyk pomiędzy sekcjami macierzy, a ponieważ każde ryzyko jest zadaniem w Jirze – możemy korzystać z metadanych, powiązań, cyklów życia i historii zmian. Wisienką na torcie jest to, że ryzyka dają się łatwo powiązać z ich źródłem (analiza projektu, wdrożenie systemu, incydent) a także filtrować i tworzyć na ich podstawie zaawansowane raporty. Szybko, prosto i skutecznie.

Warto nadmienić, że o ile analiza dokumentacji zajęła nam tygodnie, to stworzenie powyższych narzędzi do zarządzania SZBI okazało się kwestią… kilku dni. Dla jednej osoby. Kombinacja dobrych praktyk, jeszcze lepszych narzędzi i przeczucia, że utarte schematy da się zastąpić czymś świeżym, lepszym i bardziej wydajnym zaowocowała osiągnięciem wyjątkowych rezultatów.

A to dopiero początek…

Skoro tak, to co dalej? Integracja. Coraz szersza. Do Jiry i Confluence dołączamy dedykowane systemy analizujące raporty od partnerów i dostawców. Wyniki zgłaszane są automatycznie jako działania, incydenty lub inne zdarzenia, a te w konsekwencji zasilają nam wskaźniki i raporty. Unifikacja narzędzi do komunikacji i współpracy pozwala na większą kontrolę nad przetwarzanymi danymi. Analiza wymagań normy ISO pod kątem monitorowania efektywności SZBI popycha nas coraz dalej do wdrażania rozwiązań opartych na digitalizacji procesów w Jira. Dopóki w tych działaniach kierujemy się bezpieczeństwem, standaryzacją oraz automatyzacją i integracją danych, system mimo że z każdym miesiącem obejmuje kolejne obszary, to nie wymaga dodatkowego wysiłku do obsługi i zarządzania. W końcu, nie chodzi o to żeby stworzyć system, którego działanie będzie samo w sobie zagadką i będzie jedynie utrudniał pracę działów produkcyjnych. Chodzi o to, żeby opracowane przez nas rozwiązania stwarzały warunki, w których ryzyko utraty integralności, poufności i dostępności danych przetwarzanych przez pracowników stawało się coraz mniejsze. I to jak najmniejszym kosztem.