Ryzyko w biznesie a ryzyko w IT

Firmy przenoszą reguły wypracowane przez zarządzanie ryzykiem biznesowym do IT. Niektórzy analitycy podkreślają słuszność tej idei, inni uważają, że zarządzanie ryzykiem w IT nie ma sensu.

Zaledwie kilka procent niewielkich firm ma formalny program zarządzania ryzykiem, ale wśród korporacji to standard. Niektóre duże przedsiębiorstwa mają nawet specjalne komitety zajmujące się problematyką ryzyka. Zadaniem programu zarządzania ryzykiem jest identyfikacja czynników ryzyka i zmniejszenie ich wpływu na firmę przez działania zapobiegawcze albo zakup ubezpieczenia na wypadek zdarzenia związanego z danym czynnikiem ryzyka.

Przykładem zarządzania ryzykiem jest ochrona przed wzrostem cen paliwa w linii lotniczej. Ponieważ paliwo jest znaczącą częścią kosztów firmy, wzrost jego cen może radykalnie wpłynąć na wynik finansowy, a zatem jest to jeden z czynników ryzyka. Działaniem zapobiegawczym jest terminowy kontrakt paliwowy (fuel hedge), powszechnie wykorzystywany przez linie lotnicze na całym świecie. Innym przykładem jest uruchomienie magazynu i przechowywanie najważniejszych podzespołów przez firmę, która wprowadziła ideę produkcji just-in-time i jest uzależniona np. od dostaw firmy z Tajlandii. Czynnikiem ryzyka może być powódź, która zniszczy fabrykę dostawcy.

Czynniki ryzyka w IT

Każdy program zarządzania ryzykiem wymaga zidentyfikowania obiektów w IT, a następnie przeliczenia związanych z nimi czynników ryzyka. Należy więc stosować wagi zależne od wpływu danego obiektu na obsługę procesów biznesowych. Richard Stiennon, główny badacz-analityk IT-Harvest, uważa, że jest to podejście problematyczne. Tymczasem Steve Schlarman, architekt rozwiązań eGRCw firmie RSA, ma odmienne zdanie. Przedstawiamy oba podejścia.

Richard Stiennon, IT-Harvest: Identyfikacja wszystkich obiektów w IT jest kosztowna i niemal niemożliwa

Chociaż na pierwszy rzut oka identyfikacja zasobów wydaje się prosta, ostatecznie okazuje się niezwykle skomplikowana, gdyż zasoby te obejmują: każdy komputer (desktop, laptop, serwer), każdą aplikację (baza danych, poczta, ERP), każdy zasób danych (lista klientów, dane do produkcji, zasady sporządzania cennika), wiadomości poczty elektronicznej, dokumenty we wszystkich wersjach oraz całą komunikację z VoIP włącznie. Do tego należy dodać urządzenia, które pojawiły się w firmie w związku z konsumeryzacją IT, takie jak: smartfony, iPady, a nawet czytniki książek, razem z danymi znajdującymi się w tych urządzeniach. Skomplikowanie infrastruktury uzupełniają usługi wirtualizacji i chmurowe, które zmieniają się płynnie razem z obciążeniem, włącznie z liczbą pracujących maszyn wirtualnych.

Steve Schlarman, RSA: Zasoby można zidentyfikować

Jednym z pierwszych zadań jest identyfikacja zasobów, by dział IT wiedział, co musi chronić. Jest to zadanie, które na pierwszy rzut oka wygląda na niewykonalne, ale technologia analizy danych umożliwia osiągnięcie celu: wykrycie i zidentyfikowanie przepływu danych w firmie. Do wykonania zadania można zastosować technologię DLP (data loss prevention), która sprawdzi się przy identyfikacji informacji. Czy organizacja będzie miała wtedy listę wszystkich obiektów IT w swoim "firmowym świecie"? Niekoniecznie. Może jednak zidentyfikować miejsca, w których składowane i przetwarzane są istotne dane, np. dane osobowe, kluczowe badania, plany rozwoju i inne. Technologia to umożliwia.

Gdy duża firma z branży technologicznej postanowiła znaleźć informacje o transakcjach kartami kredytowymi, wdrożyła DLP. Odkryto 30 tys. plików rozproszonych w całej międzynarodowej infrastrukturze. Zasoby zostały skatalogowane, zidentyfikowano właścicieli i nawiązano z nimi kontakt, a następnie wprowadzono działania zaradcze, by zasoby zabezpieczyć. Prace trwały kilka tygodni i przyniosły efekt: dobre przygotowanie do ochrony danych. Dzięki doświadczeniom z poszukiwaniem informacji o kartach kredytowych, ludzie nauczyli się w podobny sposób chronić inne zasoby informacji.

Richard Stiennon: Nie da się przypisać wartości do zasobów

Koncepcja zarządzania ryzykiem zakłada przypisanie pewnej wartości do każdego obiektu. Zazwyczaj organizuje się spotkanie grupy roboczej złożonej z pracowników różnych działów w firmie, by ustalić wartość. Ale jaką? Nie wiadomo. Czy to ma być koszt wymiany urządzenia? To sprawdziłoby się raczej w firmie produkcyjnej, przy wymianie maszyny, od której zależy produkcja. Koszt wymiany serwera pocztowego może być niewielki, np. 2000 USD, ale potencjalna szkoda związana z niedostępnością usługi i przestojami w komunikacji może sięgać milionów.

Trudno określić wartość pojedynczej wiadomości pocztowej. Mało ważne e-maile można wycenić na zero lub 10 centów, ale jedna wiadomość wysłana pod koniec roku rozrachunkowego przez CFO do CEO na temat nieosiągnięcia zysku jest warta o wiele więcej. W przypadku jej nieautoryzowanego rozgłoszenia straty związane ze spadkami cen akcji będą liczone w milionach. Wyjściem z sytuacji jest podział zasobów na mało-, średnio- lub wysokowartościowe, ale w przypadku IT prawie nikt nie określa danego serwera jako mało znaczącego, gdyż to sugeruje, że jest niepotrzebny. Przypisanie wartości jest zatem prawie niemożliwe.

Steve Schlarman: Wartość zasobu można określić

Chociaż w niektórych przypadkach trzeba pozostać przy ogólnym podziale na rzeczy mniej i bardziej ważne, to do niektórych zasobów można przypisać konkretne kwoty w wybranej walucie lub chociaż ich aproksymację. Wymaga to pracy i odpowiedniego podejścia.

Niektóre produkty DLP potrafią określić, ile rekordów danego typu znajduje się w firmowych zasobach. Jeśli koszt utraty jednego rekordu wynosi x dolaró w (w USA prowadzi się nawet formalną "wycenę" utraty takich danych), to przeliczenie wartości zasobu rekordów jest proste. Podobnie baza danych może mieć określoną wartość z perspektywy biznesu, np. odtworzeniową. Kluczowym komponentem jest nie tylko katalog zasobów, ale połączenie z analizą wpływu na biznes i katalogiem obiektów biznesowych rozważanych w związku z bezpieczeństwem. W ten sposób otrzymuje się nie tylko listę sprzętu, ale także informacje o przetwarzanych danych.

Richard Stiennon: Zarządzanie ryzykiem nie przewidzi katastrof

Przy określaniu ryzyka należy określić zagrożenie. Duże data center zlokalizowane na Florydzie przy Zatoce Meksykańskiej korzystało z zarządzania ryzykiem i oprócz typowej listy, zawierającej brak zasilania, problemy z połączeniem czy pożar, wprowadzono także zagrożenie związane ze sztormem o wysokości fal przekraczającej siedem metrów. Ponieważ od 100 lat do dnia oceny nie zanotowano takiego zdarzenia, otrzymało ono ocenę 9, przy czym 10 oznaczało najmniej prawdopodobne. Audytor wskazał jednak, że w całym rejonie w ciągu roku takie zjawisko wystąpiło aż cztery razy, a profilu oceny ryzyka nigdy nie uaktualniano pod kątem zmian środowiskowych.

Nawet w przypadku zagrożeń związanych z internetem należy uwzględniać zmiany. Zasoby, które w 1999 r. nie były interesujące dla trzynastoletniego pasjonata informatyki, mogą być teraz zaciekawić cyberprzestępców lub hakerów pracujących na zlecenie korporacji czy służb wywiadowczych. Nie można przewidzieć, jakimi zasobami zainteresuje się napastnik.

Steve Schlarman: Zarządzanie ryzykiem wskazuje krajobraz zagrożeń

Tradycyjna formuła obliczeń, czyli wartość ryzyka = prawdopodobieństwo x wpływ, umożliwi określenie wartości, jeśli uda się ustalić prawdopodobieństwo. Krajobraz zagrożeń jest zmienny. W niektórych sytuacjach związanych z IT prawdopodobieństwo danego zdarzenia zbliża się do 100%.

Można zmniejszyć prawdopodobieństwo wystąpienia poważnych szkód w wyniku ataku przez inteligentny projekt przeciwdziałania oraz implementację odpowiednich zabezpieczeń. Wpływ na biznes zasobów i powiązanych z nimi zagrożeń jest wyróżnikiem przy projektowaniu zabezpieczeń. Niektóre rozwiązania są niezbędne i firmy od dawna je mają. Bezpieczeństwo IT musi być dostosowywane do zmieniającego się krajobrazu i sytuacji biznesowej.

Richard Stiennon: Zarządzanie ryzykiem przechodzi w "ochronę wszystkiego"

Aby zarządzanie ryzykiem działało, musi być kompleksowe. Firmy wdrażają zatem kompleksowe zabezpieczenia: zapory sieciowe, IPS-y, antywirusy, zarządzanie maszynami wirtualnymi, narzędzia aktualizacji, zarządzanie podatnościami i kontrolę działania. Organizacje wydają na nie dużo pieniędzy, chronią wszystko, a nadal przegrywają z kierowanymi, wysokopoziomowymi atakami wykorzystującymi podatności dnia zerowego. Zarządzanie ryzykiem nie działa w IT.

Steve Schlarman: Ważne są priorytety działania

Priorytety działań obronnych należy ustalić pod kątem zasobów, w których znajdują się najważniejsze informacje. Narzędzia, takie jak szyfrowanie czy kontrola konfiguracji, powinny być analizowane i dostosowane do tego, jakie zasoby chronią. Przy omawianych 30 tys. plików z numerami kart kredytowych działania zapobiegawcze zależały od potrzeb biznesowych. Niektóre pliki usunięto, inne zaszyfrowano, pozostałe, które były wynikiem procesu biznesowego, wymagały dodatkowej uwagi ze strony działu bezpieczeństwa.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200