Zasada naczyń połączonych, czyli jak testować aby nie zwariować cz. 2/2

Przeprowadzenie analizy ryzyka
z zastosowanych technologii, na pierwszy rzut oka wydaje się być dość proste. Jeżeli jednak rzucimy tym okiem dalej może okazać się, że niekoniecznie. Powodów jest kilka. Jednym z nich jest znajomość danej technologii, jej możliwości i ograniczeń. Drugim jest znajomość (dobra) własnej infrastruktury jej potrzeb i zagrożeń, przed którymi się bronimy.

Obrazowym przykładem jest w tym miejscu dobór smartphone’ów – jeżeli nasza infrastruktura wymaga stosowania antywirusa, to nie możemy dobrać takich urządzeń, dla których systemów nikt nie napisał jeszcze stosownego oprogramowania, bo jest to sprzeczne z zasadami przyjętymi w organizacji PBI. Ale w zakresie sprzętu to w sumie nie jest trudne. Co natomiast
z oprogramowaniem?

Tu w pierwszej kolejności pojawiają się na pozór banalne elementy, takie, jak wymagania stricte użytkowe z zakresu: „do czego będę tego używał”. Inne będą wymagania do przetwarzania danych osobowych, inne – do przetwarzania informacji poufnych. Czyli już na początku powinienem umieć określić czy dany element pozwala mi zachować ten zakres bezpieczeństwa, jaki nakłada na mnie prawo i zasady użytkowania.

Kolejna kwestia to technologia – są zwolennicy starych rozwiązań – bo pewne
i przetestowane, są miłośnicy nowinek. Są też tacy, co lubią „środek”. Każdy z nich,
w określonych warunkach, będzie miał rację, ale…

Znam firmę, która nagle postanowiła oszczędzić na drodze obrażenia się na Microsoft i przeszła na Linuksy, także dla użytkowników. Gdyby dokonali analizy ryzyka, to stwierdziliby co następuje:

1. Nie mamy specjalisty od Linuksa i nie wiemy co i jak się potoczy jak nam coś wysiądzie
2. Współpracujemy z zewnętrznymi firmami a OpenOffice;y nie są w 100% kompatybilne z MS Office
3. Itp.

Z wnioskiem na końcu – czy to nie będzie, że klasyczna zamiana siekierki na kijek i czy nie wygeneruje to dodatkowego kosztu?

Inny przykład. Firmie zaproponowano przejście z oprogramowania instalowanego na dzierżawione. W wyniku oceny działania (stabilności) łącza władze doszły do wniosku, że ryzyko braku dostępu do systemu jest zdecydowanie większe i groźniejsze niż
w razie awarii czekanie na serwis.

Każdy z tych elementów pokazuje inny zakres ryzyk i inne spojrzenie wynikające wprost z potrzeb i środowiska, w jakim funkcjonują. Bez tej wiedzy naprawdę trudno
o jednoznaczną odpowiedź. Dlatego też należałoby zacząć od rzetelnego opisania zbioru ryzyk i sposobu szacowania (oceniania) nowych lub rozwijanych elementów IT.

A co Wy o tym sądzicie? Jakieś doświadczenia? Przemyślenia?

Jacek Rembikowski