Czym jest analiza ryzyka technologicznego (TRR, eng. Technology Risk Review)?

Roman Buczyński – W ITDS pracuje od października 2021 roku, obecnie w zespole inżynierskim Goldman Sachs SFL jako DevOps / SRE engineer. Zapewnia on ciągłą dostępność usług, tworzy nowe wdrożenia i wspiera deweloperów w ich codziennych zadaniach.

Czym jest analiza ryzyka technologicznego?

Gdy firma chce upewnić się, że wszystkie jej aplikacje i usługi są bezpieczne, kompatybilne ze sobą, oraz czy dotrzymują one wyznaczonych standardów, może zdecydować się ona na przeprowadzenie analizy ryzyka technologicznego. Jest to zestaw regulacji połączonych z serią ankiet oraz spotkań, w ramach których postawione zostają pytania mające pomóc w przeprowadzeniu procesu tworzenia aplikacji w taki sposób, by była ona zgodna z wyznaczonymi protokołami.

Pytania mogą dotyczyć:

• Zagrożeń bezpieczeństwa, takich jak ograniczenia dostępu, słabości kodu czy wycieków danych;
• Zagrożeń związanych z zapisem danych – dzienniki aplikacji mogą zawierać zastrzeżone dane / informacje debugowania, takie jak hasła / zawartość bazy danych lub inne informacje, które powinny być kontrolowane;
• Nadmiernych lub kosztownych źródeł użycia;
• Zagrożeń infrastrukturalnych (portów dostępu, użycia usług o niskim bezpieczeństwie).

Dlaczego nie przepadamy za przeglądami technologicznymi?

Analiza ryzyka technologicznego może stać się dłużącą się i z pozoru niepotrzebną procedurą, która wymaga współpracy z zespołem TRR, wysiłku zgromadzenia dokumentacji, a czasem nawet przeprojektowania niektórych segmentów aplikacji. Wymaga to zaangażowania i czasu, a ten – zwłaszcza w oczach dewelopera – może wydać się stracony na coś innego, niż tworzenie kodu aplikacji. Lista trudnych do zaadresowania pytań, serie spotkań online i twarzą w twarz, podczas których powstaje ich jeszcze więcej i tak dalej… Wiadomo, o co chodzi.

Nierzadko istnieje potrzeba wykonania bardziej rozbudowanej, od już istniejącej, dokumentacji projektu, może jednego lub dwóch dodatkowych wykresów. Czasami jest również potrzebne większe poparcie danych w formie wkładu Twoich kolegów – ich odpowiedzi na kilka pytań.

Jak przebiega analiza ryzyka technologicznego?

Może być on nie lada wyzwaniem. Radziłbym nie podchodzić do sprawy samodzielnie. Najczęściej, zespół zajmujący się RT jest dobrze przygotowany, uzbrojony w wiele zawężonych pytań o detale, o których może wcześniej nie pomyślałeś. Nie martw się, jeśli nie zdołałeś odpowiedzieć na nie wszystkie lub byłeś czegoś niepewny – rób notatki i poproś, by zespół dał Tobie czas na zdobycie dokładnych informacji. Nie ma się czego wstydzić, to część procesu.

Dowiedz się więcej o połączeniu rozwoju oprogramowania z analizą biznesową: O wyzwaniach w programowaniu w bankowości i ludzkim obliczu fintechu

Jakie są korzyści analizy ryzyka technologicznego?

Jak wspomniano wcześniej, jest to proces, który może zrodzić pytania, o których wcześniej nie pomyślałeś i na które nie znałeś odpowiedzi – jest to coś pozytywnego, gdyż zwiększa to Twoją wiedzę o samej aplikacji, infrastrukturze, jej otoczeniu (interakcji z innymi aplikacjami). Daje ci on również pewność, że usługa jest kompatybilna z obecnymi standardami i polityką firmy. Możesz dzięki temu być pewny, że stworzyłeś bezpieczną aplikację, a sam proces daje również pewność zespołowi TRR i samej firmie, że wpasuje się ona w standardy organizacji i nie będzie dla niej szkodliwa, przynajmniej w zakresie sytuacji, które są możliwe do przewidzenia.

Jak rozpocząć procedurę przeglądu TR?

W idealnej sytuacji, będziesz potrzebował kilku ważnych składowych:

• Przyjętych polityk firmy, zawierających informacje na temat interakcji mikrousług / bezpieczeństwa danych / polityk komunikacji / autoryzacji i uwierzytelniania, innych potrzebnych informacji w tym zakresie;
• Wyszkolonego personelu, który będzie mógł wziąć udział w wywiadach; ludzi, którzy orientują się w tematyce bezpieczeństwa, myślą kreatywnie i będą w stanie zadawać odpowiednie pytania – przynajmniej na tyle, by przygotować dokumentację dla przeglądów dopasowanych do Twojej firmy;
• Narzędzi oprogramowania potrzebnych do wykonania należytego testowania / testowania penetracyjnego / innych – w zależności od aplikacji.