Prehľad témy

  • Zajęcia organizacyjne. Wprowadzenie do przedmiotu.

  • 19-05-2021 Programy antywirusowe typu klient/chmura.

    Tradycyjne programy antywirusowe oparte są na rozpoznawaniu sygnatur odbywającym się na urządzeniach końcowych. Ta strategia nie jest skuteczna z kilku powodów:

    Liczba rozpoznanych zagrożeń wzrosła tak bardzo, iż bezcelowe stało się aktualizowanie sygnatur na urządzeniach końcowych, jako że nie są one w stanie porównywać plików ze wszystkimi znanymi sygnaturami.

    Hakerzy i cyberprzestępcy wykorzystują rozmaite techniki oraz sieci bonet do przeprowadzania ataków typu zero-day, zanim sygnatury zostaną zaktualizowane na urządzeniach końcowych.

    W sytuacji, kiedy cyberatak wymierzony jest w konkretną jednostkę lub organizację, prawdopodobne jest, że sygnatura w ogóle nie istnieje. Hakerzy wykorzystują takie techniki jak szyfrowanie złośliwych kodów, polimorfowanie po stronie serwerów oraz testowanie QA, których rozpoznanie na podstawie sygnatur jest niemożliwe.

    W obliczu tego rodzaju zagrożeń, większość ekspertów zajmujących się bezpieczeństwem informacji zgadza się, iż tradycyjne produkty antywirusowe, oparte na rozpoznawaniu sygnatur nie są w stanie skutecznie zapobiegać atakom najnowszego i najbardziej niebezpiecznego złośliwego oprogramowania.

    Architektura typu klient / chmura

    Architektura „ciężkiego klienta” tradycyjnych produktów antywirusowych oparta jest na modułach zajmujących bardzo dużą przestrzeń pamięci dyskowej urządzeń końcowych. Rozwiązanie to umożliwia porównywania podejrzanych plików z sygnaturami zagrożeń, jednak stwarza jednocześnie kilka zasadniczych problemów:

    skanowanie w poszukiwaniu złośliwego oprogramowania oraz porównywanie sygnatur spowalnia działanie komputerów, zmniejsza efektywność pracy, irytuje użytkownika i, w niektórych przypadkach, zmusza go do wyłączenia oprogramowania antywirusowego,

    z powodu konieczności przesyłania do urządzeń końcowych tysięcy nowych sygnatur (często nawet 5MB na każdy z nich dziennie), przepustowość łącza zostaje ograniczona, a cały proces musi być monitorowany przez administratora systemu.

    ponieważ aktualizacja bazy sygnatur jest często możliwa jedynie po podłączeniu do sieci korporacyjnej za pomocą VPN, użytkownicy zdalni oraz ci korzystający z roamingu są narażeni na ataki typu zero-day.

    Architektura typu klient/chmura całkowicie zmienia tę sytuację, jako że na urządzeniu końcowym potrzebny jest jedynie ultralekki klient, który odnajduje nowe pliki i tworzy ich znaczniki (hashe). Hash wysyłany jest do ulokowanego w chmurze serwera i porównywany z bardzo rozbudowaną bazą sygnatur, a wyniki przesyłane są z powrotem do urządzenia końcowego.

    Architektura typu klient/chmura ma ogromną przewagę nad tradycyjnymi produktami antywirusowymi:

    jako że bardzo niewielka część zadań wykonywana jest w obrębie urządzenia końcowego, jego wydajność nie zmniejsza się;

    przepustowość łącza i działanie sieci nie są osłabione, ponieważ tylko kilka haszy w danym systemie jest wymienianych w obrębie sieci (zwykle ok. 120 KB dziennie), podczas gdy w przypadku tradycyjnych programów antywirusowych codziennie przesyłanych jest kilka tysięcy sygnatur;

    systemy działające w chmurze dysponują niezwykle rozbudowaną bazą sygnatur, a porównywanie wzorów odbywa się na ogromnych serwerach, co zwiększa skuteczność działania i w zdecydowany sposób przyspiesza cały proces;

    otrzymują one również w czasie rzeczywistym informacje źródłowe dotyczące pojawiających się unikalnych kodów złośliwego oprogramowania od laboratoriów testowych, zewnętrznych producentów rozwiązań bezpieczeństwa, tysięcy przedsiębiorstw oraz milionów użytkowników, dzięki czemu zagrożenia typu zero-day mogą być natychmiast rozpoznawane i blokowane;

    połączenie z siecią Internet wystarcza, aby chronić użytkowników zdalnych oraz tych korzystających z roamingu przed atakami typu zero-day. - Administratorzy systemów nie muszą instalować „ciężkich klientów” ani aktualizować bazy sygnatur na urządzeniu końcowym.

    Produkty antywirusowe typu „ciężki klient” są całkowicie przestarzałe, a architektura typu chmura/klient jest jedynym rozwiązaniem, dzięki któremu dopasowywanie sygnatur w czasie rzeczywistym będzie wydajne i skuteczne.

    Rozpoznawanie zachowań

    Nawet najszybsze i najpełniejsze porównywanie sygnatur nie zapobiegnie jednak atakom typu zero-day czy atakom kierowanym, wymierzonym w konkretne komputery. Ich sygnatury po prostu nie istnieją.  Najważniejszą innowacją w obliczu konieczności walki z tego rodzaju zagrożeniami jest metoda rozpoznawania zachowań, w połączeniu z architekturą typu klient / chmura.

    Technologie identyfikacji zachowań pozwalają programom na działanie w bezpiecznym środowisku typu sandbox i rozpoznawanie zachowań typowych dla złośliwego oprogramowania, takich jak: edytowanie kluczy rejestru, uzyskiwanie dostępu do mailowych list dystrybucyjnych czy próby dezaktywowania pakietów antimalware na urządzeniach.

    Proces ten nie jest jednak tak prosty, jak może się to pierwotnie wydawać, gdyż wzory zachowań wyróżniające te złośliwe mogą być bardzo złożone. Muszą być one rozpoznane i porównane z ogromną bazą zachowań złośliwych kodów, a aby proces mógł być skuteczny konieczne jest nieustanne aktualizowanie bazy.

    W niniejszym procesie:

    Nieznane aplikacje i pliki wykonywalne przetwarzane są w środowisku typu sandbox na urządzeniu końcowym.

    Otwieranie plików, odczytywanie i zapisywanie, zmiany rejestru klucza i inne działania są rejestrowane, a ich charakterystyka (lista działań) wysyłane do serwera umieszczonego w chmurze.

    Charakterystyka zachowania jest porównywana z ogromną bazą wzorów złośliwych zachowań i analizowana w odniesieniu do zastawu zasad (heurystyki), co pozwala ustalić, czy zachowania są złośliwe, czy nie.

    Wyniki przesyłane są z powrotem do systemu urządzenia końcowego i wskazują, które programy powinny zostać poddane kwarantannie, a którym można zezwolić na działanie.

    W ten sposób możliwe jest wykrywanie złośliwego oprogramowania na podstawie sposobu jego działania, nawet w przypadku braku sygnatury, a dzięki temu, iż analiza wzorów i reguł odbywa się w chmurze, nie wpływa ona w żaden sposób na wydajność pracy urządzeń końcowych oraz umożliwia dostęp do ogromnej bazy danych niebezpiecznych zachowań.

    Co więcej, charakterystyka nowych zagrożeń jest pozyskiwana natychmiast ze źródeł zewnętrznych, a nowopoznane wzory mogą być wykorzystane dla ochrony wszystkich użytkowników.

    System księgowania i przywracania systemu

    Identyfikacja zachowań nie wystarczy, jeśli będzie miała wyłącznie krótkoterminowy charakter. Twórcy złośliwego oprogramowania są w stanie zaprojektować je w taki sposób, aby po zainfekowaniu urządzenia końcowego zaczynało funkcjonować z opóźnieniem, a co za tym idzie, nie trafiało od razu do środowiska typu sandbox.

    W związku z tym konieczne jest wprowadzenie trzeciego elementu składowego nowego antywirusa, długoterminowej analizy zachowań, połączonej z systemem księgowania i przywracania systemu.

    Po jego wprowadzeniu programy mogą działać, jednak modyfikacje plików, kluczy rejestru, miejsc pamięci i tym podobne zmiany są księgowane, co pozwala oprogramowaniu na tworzenie obrazu „przed” i „po” każdej zmiany.

    Jeśli analiza zachowania ujawni złośliwość oprogramowania, może ono zostać usunięte, a wszystkie wprowadzone przez niego zmiany – cofnięte do ostatniego dobrego stanu.

    To rozwiązanie:

    minimalizuje szkodliwe działanie złośliwego oprogramowania, którego nie udało się wykryć ani w procesie dopasowywania sygnatur, ani skróconej identyfikacji zachowań.

    eliminuje ogromne nakłady pracy, które należałoby zaangażować do czyszczenia i ponownego zapisu zainfekowanego systemu (badania pokazują, że zajmuje to nawet do jednej trzeciej czasu pracowników pomocy technicznej).

    pozwala na rozpoznanie tego samego zagrożenia w innych systemach i w innych miejscach.

    Przykład - Webroot Secure Anywhere Business:

    Rozwiązania te wykorzystano w SecureAnywhere™ Business - Endpoint Protection. Webroot SecureAnywhere Business - Endpoint Protection używa agenta, który zajmuje mniej niż 700 KB pamięci na urządzeniu końcowym, a czas jego instalacji wynosi mniej niż sześć sekund (dane uzyskane na podstawie niezależnych testów przeprowadzonych przez Pass Mark Software), co stanowi wyraźny kontrast z konkurencyjnymi rozwiązaniami opartymi na systemach agentowych wykorzystujących duże ilości pamięci i zasobów systemu, których średni czas instalacji wynosi często trzy minuty lub więcej.

     

    Rys.1. Przykład Webroot SecureAnywhere Business - Endpoint Protection

     

    Wyniki testów jasno pokazują, że dzięki zastosowaniu rozwiązania typu klient/chmura znacząco zmniejsza się wpływ oprogramowania antywirusowego na funkcjonowanie i wydajność systemu.

    Testy ośmiu popularnych programów antywirusowych pozwoliły stwierdzić, iż proces skanowania w programie Webroot, z jego architekturą typu klient / chmura, przebiega bez porównania najszybciej.

    Pełne pierwsze skanowanie systemu zajęło jedynie pięćdziesiąt sekund, co stanowiło mniej niż 50% czasu potrzebnego na tę samą operację produktowi, który w przeprowadzonych testach zajął drugie miejsce i jedynie 40% średniego czasu, który wynosi dwie minuty i cztery sekundy. Podczas wstępnego skanowania Webroot wykorzystuje 12MB pamięci, jedynie 21% zapotrzebowania programu, który zdobył kolejną najlepszą ocenę, a jednocześnie zaledwie 10% średniego zużycia (120MB). Wykorzystanie pamięci w trybie bezczynności systemu wynosi 4MB i stanowi jedynie 6% średniej wartości.

    Elementem chmury SecureAnywhere Business - Endpoint Protection jest Webroot Intelligence Network, która dysponuje ponad 75 TB sygnatur, zachowań, złych adresów URL i tym podobnych danych, które można zakwalifikować, jako zagrażające bezpieczeństwu, co stanowi o cały rząd wielkości więcej niż potencjał analityczny produktów typu „gruby klient” na urządzeniach końcowych. Oznacza to, iż Webroot jest w stanie zarówno wykryć znacznie większą liczbę potencjalnych zagrożeń, jak również efektywnie wykorzystać i metodę rozpoznawania zachowań.

    Webroot Intelligence Network jest nieustannie aktualizowana dzięki danym przekazywanym przez 25tys. partnerów i klientów biznesowych oraz miliony klientów indywidualnych. Oznacza to, że zarówno użytkownicy pracujący w oddziałach i zdalnych lokalizacjach, jak w głównej siedzibie firmy, mają natychmiastowy dostęp do bazy wirusów w momencie, kiedy jest ona aktualizowana.

    Webroot Intelligence Network wykorzystuje zasoby światowej chmury w celu dostarczenia najwyższego poziomu bezpieczeństwa z jak najmniejszym opóźnieniem.

    Źródła:

    Materiały informacyjne firmy Bakotech

    https://bakotech.pl/vendor/webroot/

    https://bakotech.pl/product/webroot-for-home/

    https://www.crn.pl/artykuly/vademecum/webroot-odkrywa-antywirusa-na-nowo

    https://www.crn.pl/artykuly/rynek/antywirus-w-chmurze-nowe-uslugi

    https://www.crn.pl/artykuly/prawo-i-zarzadzanie/kaspersky-a-sprawa-polska-1

     


    • Metody szacowania ryzyka

      W teorii i praktyce stosowanych jest kilkadziesiąt metod szacowania i oceny ryzyka bezpieczeństwa informacji. Ogólnie można je podzielić na 3 grupy:

      metody ilościowe,

      metody jakościowe,

      metody mieszane.

      Metody jakościowe

      Jakościowe szacowanie ryzyka jest najczęściej subiektywną oceną, opartą na dobrych praktykach i doświadczeniu. Wynikiem takiego szacowania są listy zagrożeń wraz z relatywnym rankingowaniem ryzyka (niskie, średnie, wysokie). Metody te są bardzo elastyczne i otwarte na wszelkiego typu modyfikacje. Umożliwiają dzięki temu dostarczenie organizacji szybko i kosztowo efektywne wyniki w zakresie identyfikacji zagrożeń i stosowania zabezpieczeń. Jednak dzięki właśnie tej elastyczności, zakres i koszt szacowania może się bardzo różnić. Dlatego w zależności od dostępnych środków przewidzianych w budżecie, zakres szacowania ryzyka może się zmieniać w czasie.

      W metodach jakościowych określanie ryzyka zachodzi w oparciu o wiedzę ekspercką oraz doświadczenie wykonujących je osób. Ryzyko przedstawiane jest w sposób opisowy, bez wykorzystania charakterystyki liczbowej. Jednak opis ryzyka może być bardzo szczegółowy, co umożliwia dokładniejsze jego oszacowanie. W metodach jakościowych zwykle wyróżnia się trzy poziomy ryzyka: niskie, średnie i wysokie lub bardziej precyzyjnie: nieistotne, niskie, średnie, wysokie, bardzo wysokie. Metody jakościowe są ogólne, ale dzięki temu bardzo elastyczne i w łatwy sposób można dostosować je do warunków występujących w badanej organizacji. Inną zaletami metod jakościowych jest brak konieczności wyrażania parametrów ryzyka w liczbach co czyni te metody tanimi i przystępnymi dla każdej firmy.

      Korzyści z użycia metod jakościowych:

      kalkulacje i obliczenia (jeżeli występują) są proste i zrozumiałe;

      w większości nie jest konieczna wycena informacji (jej dostępności, poufności, integralności);

      nie jest konieczne ilościowe określenie skutków i częstotliwości wystąpienia zagrożeń;

      nie jest konieczne, aby szacować koszt rekomendowanych sposobów postępowania z ryzykiem i wyliczać potencjalny zysk (stratę);

      ogólne wskazanie znaczących obszarów ryzyka, na które konieczne jest zwrócenie uwagi;

      możliwość rozpatrywania i uwzględnienia przy szacowaniu takich aspektów, jak np. wizerunek firmy, kultura organizacyjna itp.;

      możliwość zastosowania przy braku konkretnych informacji i danych ilościowych lub zasobów, które mogłyby być potrzebne przy metodach ilościowych.

      Przykłady metod jakościowych:

      The Microsoft Corporate Security Group Risk Management Framework


      Ocena ryzyka:

      Definiowanie polityk

      Wdrożenie mechanizmów kontrolnych:

      - ludzie, proces i technologia

      - analiza nakładów i wyników (ang. cost/benefit analysis)

       

      Audyt i pomiar - monitorowanie, audyt, pomiar i kontrola środowiska z perspektywy efektywności rozwiązań

      NIST SP 800-30

      Metodyka opracowana przez National Institute of Standards and Technology. Special Publication 800–30 – Risk Management Guide for Information Technology Systems.

      Metodyka definiuje proces zarządzania ryzykiem systemów informatycznych w odniesieniu do całego cyklu życia systemu SDLC (ang. System Development Life Cycle).

      Etapy procesu zarządzania ryzykiem systemów informatycznych wg NIST SP 800–30:

      - ocena ryzyka (9 kroków)

      - ograniczanie ryzyka

      - monitorowanie i reagowanie na zmiany

      Simple Technique for Illustrating Risk – STIR

      Celem tej metody jest zapewnienie technik wspomagających wizualizację i dokumentację aktywów, zagrożeń i zabezpieczenia. STIR to proces dwustopniowy. Pierwszy krok polega na zobrazowaniu aktywów, zagrożeń i zabezpieczeń w formie graficznej. Tworzy się diagram ATS (STIR Asset-Threat-Safeguard). Ten schemat rozszerza standardowy diagram przypadków użycia UML, dodając niestandardowe znaczniki do definiowania zasobów, zagrożenia i zabezpieczenia. Reprezentacja ta pomaga w dyskusji między właścicielami aktywów i specjalistów ds. bezpieczeństwa i pozwala na określenie aktywów, potencjalnych zagrożenia i zabezpieczeń. Ponadto zastosowanie w tym celu narzędzi oprogramowania UML ułatwia elastyczne raportowanie.

      Drugi krok polega na przejrzeniu wypełnionej ilustracji w celu wyszukania czegoś niezwykłego lub nieoczekiwanych wzorców. Wzorce te mogą być następnie przedmiotem dalszych, szczegółowych dyskusji i analiz ryzyka.

      Główne zalety tej ilustracji to:

      - Niezabezpieczone zasoby można łatwo zidentyfikować.

      - Można łatwo zidentyfikować wspólne zabezpieczenia chroniące wiele aktywów.


      Ta technika może być używana do łączenia opartej na wiedzy analizy ryzyka z
      ilościowa/jakościową analizą ryzyka. Oba te kroki są opcjonalne. Diagram ATS staje się "dokumentem projektowym" dla kolejnej analizy ryzyka.

      Facilitated Risk Analysis Process – FRAP

      Proces uproszczonej analizy ryzyka (ang. Facilitated Risk Analysis Process, FRAP) to skuteczny proces oceny ryzyka związanego z bezpieczeństwem informacji w działalności gospodarczej. Proces obejmuje analizę jednego systemu, aplikacji, lub segment działalności biznesowej na raz. FRAP analizuje jeden system, aplikację lub segment procesów biznesowych naraz. FRAP zakłada, że ​​dodatkowe wysiłki zmierzające do opracowania dokładnie określonych ilościowo zagrożeń nie są opłacalne, ponieważ:

      takie szacunki są czasochłonne;

      dokumentacja dotycząca ryzyka staje się zbyt obszerna do praktycznego wykorzystania;

      konkretne szacunki strat na ogół nie są potrzebne do ustalenia czy potrzebne są kontrole.

      Po zidentyfikowaniu i kategoryzacji ryzyka, zespół identyfikuje kontrole, które mogą zmniejszyć ryzyko. Decyzja o tym, jakie kontrole są potrzebne, należy do kierownika biznesowego. Wnioski zespołu dotyczące tego, jakie zagrożenia istnieją i jakie kontrole są potrzebne, są dokumentowane wraz z powiązanym planem działania dotyczącym wdrażania kontroli.

      Trzy z najważniejszych zagrożeń, na jakie napotyka firma programistyczna, to nieoczekiwane zmiany w przychodach, nieoczekiwane zmiany w kosztach w stosunku do budżetowanych oraz specjalizacja oprogramowania. Ryzyko, które wpływa na przychody, może być: nieoczekiwaną konkurencją, prywatnością, problemami związanymi z własnością intelektualną i sprzedażą jednostkową, która jest mniejsza niż przewidywana. Nieoczekiwane koszty rozwoju powodują również ryzyko, które może mieć formę większej liczby przeróbek niż przewidywano, luk w zabezpieczeniach i inwazji prywatności.

      Metody ilościowe

      Są to metody badawcze, w których określa się parametry liczbowe (w odpowiednich jednostkach), charakteryzujące badane zjawisko lub obiekt badań. W tej grupie metod szacowania ryzyka najważniejsze jest, aby określić dwa podstawowe parametry opisujące ryzyko: wartość skutku zagrożenia powodującego ryzyko i prawdopodobieństwo wystąpienia zagrożenia.  Określenie skutków odbywa się przez ocenę wyników zdarzeń i wniosków wyciągniętych z sytuacji niebezpiecznych z przeszłości. Konsekwencje wystąpienia zagrożenia można odnieść do różnych kategorii: pieniężnych, technicznych, operacyjnych oraz zasobów ludzkich. Skutek wystąpienia zagrożenia można określić jako:

      Krytyczny - wystąpienie zagrożenia na pewno powoduje wystąpienie niekorzystnego efektu biznesowego, wysoki koszt, utratę wizerunku firmy, brak możliwości realizacji zadań,

      Średni - wystąpienie zagrożenia może mieć efekt biznesowy lub stanowi duże utrudnienie w pracy,

      Pomijalny - wystąpienie zagrożenia nie powoduje wystąpienia żadnego efektu biznesowego lub jest on marginalny,

      Nie dotyczy - wystąpienie zagrożenia nie ma wpływu na aktywa firmy.

      Natomiast prawdopodobieństwo wystąpienia ryzyka określa się jako:

      Wysokie - występuje często (np. raz w miesiącu) lub regularnie z ustaloną częstotliwością,

      Średnie - wystąpiło w ostatnim roku lub zdarza się nieregularnie,

      Pomijalne - nie wystąpiło ani razu w ciągu ostatniego roku.

      W podejściu ilościowym przy szacowaniu ryzyka najważniejsze jest określenie dwóch podstawowych parametrów, tj. wartości skutku i prawdopodobieństwa wystąpienia danego ryzyka. Skutki mogą być określone przez ocenę wyników zdarzeń lub przez ekstrapolację na podstawie danych z przeszłości. Konsekwencje mogą być wyrażone w różnych kategoriach (pieniężnie, technicznie, operacyjnie, zasoby ludzkie). Jakość całej analizy zależy od dokładności wskazanych wartości i statystycznej walidacji użytego modelu.

      Korzyści z użycia metod ilościowych:

      szacowanie i wyniki są obiektywne i przez to mogą być porównywalne;

      wartość informacji (dostępność, integralność, poufność) wyrażana jest w pieniądzu;

      wyniki szacowania ryzyka są określane w języku zarządu, mają swój wymiar finansowy i procentowy.

      Ograniczenia metod ilościowych:

      kalkulacje są wykonywane całościowo, jeżeli nie zostały zrozumiane i wytłumaczone kierownictwo może nie ufać wynikom z szacowania ryzyka, traktując je jako rezultat tzw. czarnej skrzynki;

      stosowanie metod ilościowych jest niepraktyczne i nieefektywne, kiedy nie używane są zautomatyzowane narzędzia czy aplikacje informatyczne;

      konieczne jest gromadzenie wymiernych informacji na temat środowiska IT, zabezpieczeń, zasobów.

      Przykłady metod ilościowych:

      - metoda Courtneya

       

      - P – prawdopodobieństwo wystąpienia określoną ilość razy z ciągu roku, zdarzenia

      powodującego stratę dla organizacji

      - C – strata dla danej organizacji będąca wynikiem pojedynczego wystąpienia

      zdarzenia powodującego stratę

      Metoda Fishera

      Metoda Fishera [1984] jest rozwinięciem metody Courtney’a w kompletną metodykę projektowania rozwiązań bezpieczeństwa systemów informatycznych. W celu prawidłowego zastosowania metody Fishera wymagane jest, aby w danej organizacji była wprowadzona polityka bezpieczeństwa.

      Proces zarządzania ryzykiem systemów informatycznych według Fishera:

      - Faza 1 – Zebranie informacji

      - Faza 2 – Identyfikacja zagrożeń

      - Faza 3 – Ocena ryzyka

      - Faza 4 – Projektowanie mechanizmów kontrolnych

      - Faza 5 – Ocena ekonomicznej opłacalności mechanizmów

      Metody mieszane

      Zarówno metody ilościowe, jak i metody jakościowe mają swoje słabe strony: są zbyt ogólne, niedokładnie identyfikują wszelkie potrzeby w zakresie bezpieczeństwa informacji, nie dostarczają informacji na temat analizy kosztowej w zakresie wprowadzenia nowych zabezpieczeń. Z tego względu większość przedsiębiorstw wykorzystuje kombinację tych dwóch podejść. Stosowane są analizy jakościowe oparte na metodach scenariuszowych do identyfikowania wszystkich obszarów ryzyka i skutków, przy równoczesnym użyciu ilościowej analizy do określenia kosztów skutków wystąpienia ryzyka.

      Szacowanie ryzyka wg ISO/IEC TR 13335-3  

      Norma ISO/IEC 27001 nie określa dokładnie, z jakiej metody najlepiej skorzystać, ale podaje metody szacowania ryzyka omówione w ISO/IEC TR 13335-3, Information technology – Guidelines for the  Management of IT Security – Techniques for the management of IT Security [1].

      Metoda OCTAVE

      Operationally Critical Threat, Asset and Vulne-rability Evaluation (OCTAVE), czyli ocena luk i zasobów krytycznych dla działania, to wytyczne powstałe w roku 2001 na Uniwersytecie Carnegie Mellon. Metoda stosowana jest m.in. przez armię USA i zdobywa popularność w wielu innych, najczęściej dużych organizacjach.

      Metoda OCTAVE określa ryzyko oparte na strategicznym szacowaniu i planowaniu technik bezpieczeństwa. Kierowana jest do wszystkich typów organizacji. Metoda opiera się na założeniu, że pracownicy organizacji ponoszą odpowiedzialność za ustanawianie organizacyjnej strategii bezpieczeństwa. Wdrażanie jej założeń powinno odbywać się poprzez nieduży, interdyscyplinarny zespół ludzi (3–5 pracowników organizacji), którzy będą zbierać i analizować informacje, wyznaczać strategię stosowania zabezpieczeń i plany postępowania oparte na organizacyjnym ryzyku bezpieczeństwa. Aby wdrożyć metodę OCTAVE efektywnie, zespół musi mieć szeroką wiedzę na temat działalności biznesowej organizacji i procesów bezpieczeństwa.

      Metoda realizowana jest w trzech etapach. Etap pierwszy polega na całościowej analizie zasobów organizacji, identyfikacji aktualnych praktyk, przeglądzie wymogów dotyczących bezpieczeństwa, diagnozie luk organizacyjnych i istniejących zagrożeń. Etap drugi ma na celu zidentyfikowanie luk technologicznych. Etap trzeci oparty jest na wypracowaniu strategii ochrony i planu postępowania z ryzykiem.

      Analiza skutków potencjalnych błędów – FMEA

      Failure Mode and Effect Analysis (FMEA) jest metodą wspierającą zarządzanie jakością, jednak koncepcja i zasady szacowania ryzyka (organizacyjnego i technicznego) mogą być z powodzeniem przeniesione na grunt szacowania ryzyka bezpieczeństwa informacji.

      W początkowym okresie FMEA miała zastosowanie w Stanach Zjednoczonych w latach 60 do produkcji na potrzeby astronautyki i motoryzacji. Metoda weryfikowała projekty różnych elementów statków kosmicznych i miała przede wszystkim zapewnić bezpieczeństwo uczestnikom wyprawy. Sukces tej metody w NASA spowodował, że znalazła ona zastosowanie w innych branżach. W latach 70 i 80 metoda ta zadomowiła się w Europie i znalazła nowe zastosowania w przemyśle chemicznym, elektronicznym, a także samochodowym, gdzie zaobserwowano największą dynamikę jej zastosowania. W latach 90 została zaadaptowana w ramach normy ISO 9000, a w szczególności w QS 9000 (ISO/TS 16949) przeznaczonej dla przemysłu samochodowego.

      Metoda polega na analitycznym ustalaniu związków przyczynowo-skutkowych powstawania potencjalnych wad produktu oraz uwzględnieniu w analizie czynnika krytyczności (ryzyka). Jej celem jest konsekwentne i systematyczne identyfikowanie potencjalnych wad produktu/procesu, a następnie ich eliminowanie lub minimalizowanie ryzyka z nimi związanego.

      Szacowanie ryzyka według tej metody oparte jest na oszacowaniu czynników ryzyka. FMEA wymienia trzy kryteria, które wartościowane są punktami od 1 do 10. W przypadku szacowania ryzyka bezpieczeństwa, określić je można w następujący sposób:

      znaczenie dla firmy / lub Klienta;

      prawdopodobieństwo utraty integralności, dostępności i poufności;

      skutki utraty jakiejś z cech bezpieczeństwa informacji (poufność, integralność, dostępność).

      W odniesieniu do umownie zdefiniowanej granicy (liczby punktów), konieczne jest przygotowanie i wykonanie planu postępowania z ryzykiem. Powinien on obejmować zadania, czas realizacji, osobę odpowiedzialną oraz szacunek ryzyka – zakładający skuteczność wykonania wskazanych działań.

      Metoda CRAMM

      CCTA Risk Analysis and Management Method (CRAMM) jest metodą analizy ryzyka rozwiniętą przez brytyjską organizację rządową CCTA (Central Communication and Telecommunication Agency), która obecnie zmieniła nazwę na OGC (Office of Government Commerce). Integralną częścią metody jest specjalne narzędzie informatyczne do szacowania ryzyka (CRAMM). Korzystanie z metody bez oprogramowania jest utrudnione.

      Pierwsze wydanie CRAMM (metody i narzędzia) opierało się na dobrych praktykach organizacji brytyjskiego rządu. Obecnie CRAMM jest preferowaną metodą do szacowania ryzyka przez rząd brytyjski, ale również jest wykorzystywane przez organizacje z innych państw. Metoda jest szczególnie przydatna dla dużych organizacji, takich jak organizacje rządowe czy przemysłu.

      CRAMM to metoda realizująca wymagania norm poprzez: analizę luk i opracowywanie programu poprawy bezpieczeństwa, tworzenie rejestru zasobów informacji, definiowanie zakresu zarządzania bezpieczeństwem informacji oraz poprzez tworzenie dokumentacji wdrożonych środków zabezpieczeń. Spośród jej zalet można wymienić:

      obszerną bazę szczegółowych pytań;

      generator różnych szablonów raportów, rodzajów wykresów i schematów, dokumentów;

      zgodność z wymaganiami pierwszego i drugiego arkusza ISO/IEC 27001;

      jest użyteczna dla dużych organizacji o różnych profilach;

      jest narzędziem poleconym przez największe korporacje w Anglii, tworzonym przy współudziale inspektorów i administratorów bezpieczeństwa dużych banków i korporacji.

      Praktycy jej stosowania zwracają też uwagę na słabe strony:

      nie ma możliwości analizowania poprawności zastosowanego algorytmu obliczeniowego,

      z wyjątkiem CRAMM Expres (prosty moduł służący do analizy konkretnej aplikacji) CRAMM V5 nie jest ogólnie dostępny i jest trudny w użytkowaniu,

      licencja jednostanowiskowa plus obowiązkowe szkolenia CRAMM V5 są bardzo kosztowne.

      Metoda COBRA

      Control Objectives for Risk Analysis (COBRA) to pełna metoda analizy ryzyka, zaprojektowana dla zarządu i kierownictwa organizacji do całościowej oceny profilu ryzyka związanego z prowadzoną działalnością, ze szczególnym uwzględnieniem bezpieczeństwa wizerunku jednostki, zgodności z obowiązującymi regulacjami prawnymi i ustawodawczymi oraz do wewnętrznych mechanizmów kontrolnych.

      Struktura metody COBRA składa się z 6 podstawowych obszarów:

      1. Ingerent Risk (ryzyko wrodzone);

      2. Control Activities & Procedures (czynności i procedury kontrolne);

      3. Human Resources Risk (ryzyko związane z działalnością człowieka);

      4. Security Risk (zagrożenie);

      5. Financial Statement Compliance (zgodność bilansu finansowego);

      6. Disaster Readiness (przygotowanie do katastrofy).

       

      Dodatkowo obejmuje ta metoda 33 podkategorie oraz 429 pytań kontrolnych.

      Metoda MARION

      Methodology of Analysis of Computer Risks Directed by Levels (MARION) została opracowana i ostatnio zaktualizowana w 1998 r. przez CLUSIF (Club de la Sécurité de l'Information Français). Obecnie CLUSIF już nie finansuje rozwoju i nie promuje metody, ponieważ środki zostały przesunięte na korzyść nowo rozwijanej innej metody – MEHARI. Jednakże MARION jest nadal używana przez wiele organizacji.

      Podejście to wykorzystuje metodę prowadzenia audytu. Prowadzi ona do oceny stopnia ryzyka zabezpieczeń IT poprzez odpowiednio do tego skonstruowany kwestionariusz ankietowy dający wskazówki w postaci zapisów na tematy związane z bezpieczeństwem. Celem metody jest ustalenie stopnia bezpieczeństwa, który określany jest w oparciu o 27 zagadnień (pytań) pogrupowanych w 6 tematów. Każde zagadnienie jest oceniane w skali od 0 do 4. Ocena na poziomie 3 dla danego zagadnienia oznacza, że procedury / zabezpieczenia funkcjonujące w organizacji są wystarczające i akceptowalne.

      Metoda MEHARI

      Methode Harmonisee d’Analyse de Risque (MEHARI) została opracowana przez ekspertów bezpieczeństwa z CLUSIF. Podejście to oparte jest na definiowaniu mierników redukcji ryzyka odpowiednich dla celów organizacji. Metoda dostarcza:

      modelu szacowania ryzyka,

      ujęcia modułowego modelu (jego komponentów i procesów),

      narzędzi do analizowania incydentów,

      podejścia do identyfikowania podatności poprzez narzędzie audytu,

      podejścia do identyfikacji zagrożeń i charakterystyki podatności,

      zasady optymalnego wyboru działań korekcyjnych.

      MEHARI realizuje zalecenia norm ISO/IEC 27001:2005 i ISO/IEC TR 13335 przy użyciu jednolitego systemu oszacowania ryzyka, prawidłowo dobranych zabezpieczeń i lokalizacji zasobów.

      Można wymienić jej zalety:

      jest nieskomplikowana i prosta w użyciu;

      odpowiednia dla małych i średnich organizacji wykorzystujących technologie informatyczne;

      algorytm obliczeniowy, baza pytań i scenariuszy ryzyka są ogólnie dostępne;

      istnieje możliwość rozbudowania tej metody o pytania, scenariusze itp.

       

      Wady: metody to ubogi generator szablonów raportów i rodzajów wykresów. Dodatkowo nie jest w pełni zgodna z ISO/IEC 27001:2005. Analiza kosztów nie uwzględnia związków z innymi scenariuszami.

      Standardy ISACA

      Standardy Information Systems Audit and Control Association (ISACA) dotyczące audytu systemów informatycznych podają kilka metod oceny ryzyka systemów informatycznych. Jedną z nich jest wykorzystanie ośmiu kluczowych zmiennych przy zastosowaniu liczbowych wartości ryzyka z przedziału od 1 (niski) do 5 (wysoki). Rezultaty takiego rankingu są następnie mnożone przez wagi z przedziału od 1 (niski) do 10 (wysoki), dając wartość zwiększoną. Wartość łączną otrzymuje się po dodaniu do siebie wszystkich wartości zwiększonych. Wartość łączna pozwala uszeregować poszczególne obszary audytu według ryzyka.

      Metody autorskie

      Norma ISO/IEC 27001 nie określa dokładnie, z jakiej metody najlepiej skorzystać, dlatego też możliwe jest stosowanie przez organizacje również własnych metod opracowanych na postawie wiedzy branżowej i doświadczenia. Takie podejście jest właściwe dla dużych organizacji, które posiadają odpowiednie struktury organizacyjne do tego, aby tę metodę opracować i zwalidować.

      Źródła:

      Jacek Łuczak, Metody szacowania ryzyka – kluczowy element systemu zarządzania bezpieczeństwem informacji ISO/IEC 2700,  Scientific Journals Maritime University of Szczecin,  2009, 19(91) pp. 63–70

      Metodyka zarządzania ryzykiem cyberprzestrzeni w systemach zarządzania bezpieczeństwem informacji podmiotów rządowych, Warszawa 2015 r.

      Uchwała nr 210/2015 Rady Ministrów z dnia 2 listopada 2015 r. w sprawie przyjęcia Narodowego Programu Ochrony Infrastruktury Krytycznej z uwzględnieniem Uchwały nr 61/2016 Rady Ministrów z dnia 1 czerwca 2016 r. zmieniającej uchwałę w sprawie przyjęcia Narodowego Programu Ochrony Infrastruktury Krytycznej.

      Jerzy Stanik, Maciej Kiedrowicz, Metoda analizy i szacowania ryzyka zasobu informacyjnego. 

      • Serwerownia/Data center jako przykład IK

        Fizyczna Infrastruktura Sieciowa o znaczeniu krytycznym (NCPI – Network-Critical Physical Infrastructure) to fundament, na którym opierają się technologia informatyczna oraz sieci telekomunikacyjne.

        Składniki NCPI:

        zasilanie,

        chłodzenie,

        okablowanie strukturalne,

        monitorowanie i zarządzanie,

        bezpieczeństwo fizyczne i ochrona przeciwpożarowa.

        filary działu IT i całej organizacji: procedury i normy, dokumentacja.

        serwis

        Przykładem NCPI jest serwerownia/Data center.  Serwerownia to wydzielone pomieszczenie będące środowiskiem pracy komputerów pełniących rolę serwerów, a także aktywnych i pasywnych elementów sieci komputerowych. Urządzenia te są umieszczane najczęściej w szafach stelażowych (rackowych) wewnątrz serwerowni.


        Wybrane cechy charakterystyczne:

        - specyficzny mikroklimat (wilgotność (45%) i temperatura powietrza (20 °C).
        - dwa (lub więcej) źródła zasilania serwerowni
        - systemy zasilania awaryjnego UPS.
        - kilka łączy do różnych dostawców internetu (serwery internetowe)

        Serwerownie często wyłożone są specjalnymi dywanami i matami zapobiegającymi gromadzeniu się ładunków elektrostatycznych, a dostęp do serwerowni jest ograniczony przez różne systemy kontroli dostępu. Stosowane są również podłogi technologiczne (podniesione, modularne) ułatwiające prowadzenie okablowania do szaf rack. Duże serwerownie często posiadają autonomiczne systemy przeciwpożarowe.


        Zabezpieczenie IK obejmuje:

        1. Bezpieczeństwo fizyczne

        • usytuowanie Data Center w wydzielonej części budynku, chronionej przez system alarmowy i system telewizji przemysłowej budynkowej, nadzorowane przez firmy wyspecjalizowane w zakresie ochrony (system alarmowy – autonomiczny) oraz drugi autonomiczny system telewizji przemysłowej wewnątrz Data Center;
        • dostęp do pomieszczeń tylko dla upoważnionych osób, rejestracja wejść/wyjść przez system kontroli dostępu z rejestracją dostępu w oparciu o karty magnetyczne i kody PIN;
        • wydzielone fizycznie strefy Data Center zamykane drzwiami o odporności ogniowej 60 minut i wyposażone w mechanizmy samozamykające.

        2. Bezpieczeństwo energetyczne

        • zasilanie energetyczne z dwóch niezależnych zewnętrznych źródeł oraz dodatkowo awaryjne zasilanie  z agregatów prądotwórczych;
        • system samoczynnego załączenia rezerwy, monitorujący parametry zasilania, przełączając na właściwe w razie awarii;
        • ciągłość działania urządzeń IT zabezpieczona przez zestawy UPS-ów, pracujących w układzie n+1;
        •dedykowane rozdzielnie energetyczne.

        3. Klimatyzacja i systemy przeciwpożarowe

        • system przeciwpożarowy monitorowany przez Państwową Straż Pożarną;
        • stałe urządzenia gaśnicze gaszące gazem obojętnym, oddzielne dla każdej serwerowni (FM-200);
        • ściany i drzwi Data Center gwarantujące co najmniej 60 minutową odporność ogniową;
        • mikroklimat pomieszczeń kontrolowany za pomocą zdublowanych klimatyzatorów precyzyjnych (temperatura i wilgotność) i instalacji wentylacyjnej;

        4. Bezpieczeństwo systemowe

        • co najmniej dwa zasilacze (w przypadku systemów Blade Center - cztery) we wszystkich krytycznych serwerach;
        • podłączenie do dwóch niezależnych obwodów zasilających;
        • wpięcie do sieci LAN za pomocą co najmniej dwóch kart sieciowych we wszystkich krytycznych serwerach;
        • zdublowanie wszystkich połączeń światłowodowych do macierzy dyskowej;
        • zdublowanie wszystkich części macierzy dyskowej;
        • wykorzystanie systemów klastrowych.

        5. Bezpieczeństwo sieciowe

        - pełna redundantność szkieletu sieci w Data Center;

        - zabezpieczenie i monitorowanie wszystkich portów sieciowych przed nieautoryzowanym podłączeniem do sieci;

        - podział sieci Data Center na kilka stref i przypisanie serwera do strefy ze względu na rodzaj spełnianej funkcji oraz grupy Klientów;

        - ochrona  wszystkich stref  wydajnymi, sprzętowymi zaporami sieciowymi (firewall-e);

        - monitorowanie anomalii sieciowych za pomocą systemu IPS (Intrusion Prevention System);

        - wykorzystywanie urządzeń VPN do tworzenia wirtualnych sieci prywatnych łączonych z zasobami zlokalizowanymi w Data Center ;

        - podłączenie do kilku operatorów telekomunikacyjnych za pomocą światłowodu lub radiolinii.


        • Chłodzenie jako element IK

          Systemy chłodzenia są ważną częścią infrastruktury fizycznej służącą zapewnieniu właściwych parametrów środowiskowych, takich jak temperatura, wilgotność, czystość powietrza, wymaganych przez pracujący przez 24 godziny na dobę sprzęt teleinformatyczny.

          W pomieszczeniu serwerowni powinna być utrzymywana stała temperatura, mieszcząca się w przedziale pomiędzy 18° a 20° C, która gwarantuje prawidłową pracę wszystkich urządzeń teleinformatycznych.


        • Charakterystyka systemów zasilania serwerowni

          Podstawowym elementem, który decyduje o niezawodności działania i dostępności systemu IT jest zasilanie gwarantowane.

          W serwerowniach w powszechnym zastosowaniu wykorzystywane są UPS’y.

          Najbardziej strategiczne systemy stawiają na zasilanie gwarantowane wygórowane wymagania wynikające z wymaganych wskaźników dostępności systemów IT.



          Klasyfikacja The Uptime Institute

           

          The Uptime Institute (UI) zdefiniował klasyfikację systemów zasilania serwerowni wg poziomu dostępności.

           

          Poziom I (Tier I) składa się z pojedynczej linii dystrybuującej zasilanie bez nadmiarowych komponentów, zapewniający 99,671% dostępności.

          Poziom II (Tier II) składa się z pojedynczej linii dystrybuującej zasilanie z nadmiarowymi komponentami zapewniający dostępność 99,741% dostępności.

          Poziom III (Tier III) składa się z wielu aktywnych instalacji zasilających, lecz tylko jedna z nich ma elementy zapewniające redundancję oraz jest utrzymywana konkurencyjnie – zapewnia 99,982% dostępności.

          Poziom IV (Tier IV) składa się z wielu aktywnych instalacji zasilających, posiada komponenty nadmiarowe i jest odporna na uszkodzenia, zapewnia 99,995% dostępności.

           

          Obecnie, według informacji udostępnianych przez producentów systemów zasilania gwarantowanego osiągane są znacznie wyższe poziomy dostępności niż wymaga to klasyfikacja UI. Np. firma APC dla Poziomu I osiąga dostępność 99,92%, dla Poziomu II – 99,93%, dla Poziomu IV – 99,99997%.

          Kategorie odbiorów zasilania

          Struktura systemu zasilania uzależniona jest również od kategorii zasilanych odbiorów. Rozróżnia się:

          odbiory I kategorii zasilania – odbiory krytyczne wymagające bezprzerwowego zasilania (UPS, agregat prądotwórczy)

          odbiory II kategorii zasilania – odbiory mniej krytyczne, które dopuszczają krótkie przerwy zasilania np. do kilkunastu sekund, mogą być zabezpieczone rezerwowym źródłem zasilania przez agregat prądotwórczy.

          odbiory III kategorii zasilania – odbiory niewymagających ciągłości zasilania, które zwykle nie są zabezpieczane rezerwowym źródłem zasilania


          Systemy komputerowe serwerowni należą do odbiorów I kategorii zasilania.

          System klimatyzacji i wentylacji serwerowni zalicza się do odbiorów II kategorii zasilania.

           

          Pojęcia wykorzystywane w projektowaniu systemów zasilania:

          MTBF (Mean Time Between Failure) – uśredniony czas międzyawaryjnej pracy

          MTTR (Mean Time To Repair) – uśredniony czas naprawy

          Dostępność, dyspozycyjność (ang. Availability) A=MTBF / (MTBF + MTTR)



        • Planowanie ciągłości działania systemów krytycznych