dodany: 14.01.2013 | tagi: , ,

Autor:

Analizy bezpieczeństwa systemów w projektach IT

1

Realizując projekty IT w organizacjach, kierownik projektu skupia się przede wszystkim na dostarczeniu wymaganego rezultatu z odpowiednim zakresem, na czas i zgodnie z budżetem. Są to podstawowe i uniwersalne parametry i mają znaczenie w każdym projekcie, niezależnie od wielkości czy ważności. Oprócz nich jest wiele innych czynników mających wpływ na wynik, ale ich znaczenie ma ścisły związek z rodzajem projektu i jego skalą. Może to być przykładowo zgodność z polityką bezpieczeństwa w firmie, obowiązującymi standardami, czy nawet konieczność specjalnego traktowania wybranej grupy użytkowników.

Często te zagadnienia są ściśle związane z wielkością organizacji. Duże firmy mają zwykle usystematyzowaną działalność i procesy biznesowe, wdrożone rozmaite procedury i standardy (np. ISO, ITIL), które wymuszają wykonywanie dodatkowych zadań w projektach, przygotowanie rozmaitej dokumentacji i dopilnowania kwestii, które mogą być kompletnie obce właścicielom i pracownikom małych firm. Mnogość procedur jest czasem konieczna, a bez nich nie byłaby możliwa sprawne funkcjonowanie organizacji zatrudniającej setki i tysiące pracowników.

Projekty w takich firmach mogą wymagać od zespołu nie tylko przygotowania specyfikacji funkcjonalnych, technicznych i projektu systemu, ale także towarzyszących produktów jak np. umowa SLA (Service Level Agreement), umowa OLA (Operational Level Agreement), BC (Business Case), dokument SLR (Service Level Requirements), dokument zakresu projektu, protokół odbioru, dokument Lessons Learned  i wiele innych. Wszystko zależy od specyfiki, procesów, procedur i wykorzystywanej metodyki projektowej. Wdrażanie w tej sytuacji nowych lub zmienionych rozwiązań może także wymagać dodatkowych czynności i weryfikacji wykonywanych w trakcie i po projekcie – okresy stabilizacji, wiele procedur odbioru systemu, formalne przekazanie do zespołu utrzymaniowego, itd. Może to być także zapewnienie odpowiedniego poziomu bezpieczeństwa w związku z dostarczanym systemem – i nie do końca chodzi tu o sam fakt użycia dobrych zabezpieczeń w rozwiązaniu, ale także o wpływ, jaki będzie on miał na całą firmę i jej otoczenie .

W małych kilkuosobowych firmach nie ma zwykle świadomości jaki właśnie wpływ ma konkretna aplikacja na użytkowników, samą organizację i jej klientów. Instaluje się to, co akurat jest potrzebne, wprowadza się produkty spełniające wymagania, a kierownictwo skupia się na użyciu dobrej i korzystnej finansowo aplikacji. Używane są standardowe lub dostarczane z systemem operacyjnym programy pocztowe czy biurowe i nie istnieje jakakolwiek polityka bezpieczeństwa (o tym zagadnieniu pisałem w jednym z poprzednich artykułów). Z jednej strony to źle, że nie jest to poukładane, z drugiej strony narzucenie procedur i formalności mogłoby bardzo utrudnić działalność i zwyczajnie może to nie być potrzebne.

Im większa firma, tym więcej może być problemów, jeśli nikt nie dba chociażby o standaryzację oprogramowania i sprzętu, a nie ma możliwości, żeby nie było nawet podstawowej polityki bezpieczeństwa. To rzutuje także na podejście do realizacji projektów – jeśli istnieje taka polityka, musi być zapewnione jej stosowanie, także w trakcie dostarczania nowych lub zmienionych systemów. Można to wykonywać na różnych etapach życia systemu:
1. Tworzenie wymagań dla nowego systemu i zmian lub CR’ów (Change Request) dla istniejącego
2. Tworzenie projektu zmian systemu lub nowego wdrożenia
3. Testy rozwiązania
4. Weryfikacja w trakcie wdrożenia
5. Okresowe testy bezpieczeństwa i monitoring w okresie utrzymania systemu

Jak widać powyżej, jest wiele okazji do konfrontacji wymagań z funkcjonalnościami systemu. Najlepiej jest pamiętać o wymogach i standardach już od pierwszego etapu, aby uniknąć niespodzianek np. w trakcie testów aplikacji, które wykazują, że zgodnie z polityką nie powinna ona w ogóle być używana. Może wtedy dojść do trudnych lub kosztownych do wykonania w tym momencie wymaganych zmian, aby być w zgodzie ze standardami. Jak jednak określić co powinien robić ten system, a co jest groźne i czego należy unikać? Jakie są kryteria, zagadnienia, które musimy uwzględnić, żeby upewnić się że system jest dobry i zgodny z wytycznymi?

Na te pytania odpowiada właśnie polityka bezpieczeństwa, która powinna jasno definiować nakazy, zakazy, standardy i wytyczne. Jest to jednak zbiór faktów i często kilkudziesięciostronicowy dokument, analizowanie którego w każdym projekcie mijałoby się z celem. Dlatego stosuje się jeszcze jedno zadanie projektowe, które może być różnie nazywane w zależności od danej organizacji, ale cel ma jeden – przeanalizowanie architektury rozwiązania i opisanie wpływu jego uruchomienia (lub wdrożenia zmian) na jego otoczenie – użytkowników, firmę, klientów itp. Można to zadanie w skrócie nazwać analizą bezpieczeństwa systemu. Oprócz różnych jego nazw, rozmaite mogą być także sposoby jego realizacji w różnych firmach. Najprostsze podejście może polegać na tabeli, w której jest lista zagadnień i zwyczajnie weryfikujemy kolejno, czy dany system spełnia wymagania, czy też konieczne są jakieś zmiany. Może to też być żmudna i szczegółowa analiza wszystkich zagadnień krok po kroku wraz z sugestiami rozwiązań, jeżeli napotkano jakiekolwiek niezgodności. Zależy to od metodyki projektowej i stosowanych w danej firmie procedur.

Sam proces analizy może Wam się wydać prosty – w sumie nad czym tu się zastanawiać? Mało bezpieczne hasło oznacza potencjalne włamanie, kradzież danych, straty – żadna filozofia – po co zatem kompleksowa analiza? Rzeczywiście na pierwszy rzut oka zagrożenia są łatwe do zidentyfikowania i w 15 minut wielu z Was pewnie poda kilkanaście przykładów dla dowolnej aplikacji. Trzeba jednak mieć świadomość, że jest wiele zagadnień, które nie tylko są powiązane ze sobą, ale mają wpływ na bardzo szerokie otoczenie systemu, także poza firmą. I tu widać przyczynę, dla której takie analizy są konieczne.

Jak już wspomniałem powyżej, analiza może być robiona na różne sposoby, mniej lub bardziej skomplikowane. Tak samo lista badanych zagadnień może być różna i bardziej lub mniej rozbudowana. Bazując na standardzie ITIL (IT Infrastructure Library) można przytoczyć najbardziej typowe punkty widzenia na zagadnienia bezpieczeństwa – będące określane także jako kluczowe zasady bezpieczeństwa – CIA (Confidentiality, integrity, Availability):
1. poufność – dostęp do danych jest możliwy tylko przez uprawnione zasoby
2. integralność – modyfikacja danych jest możliwa tylko przez uprawnione zasoby
3. dostępność – dane są dostępne zawsze wtedy, gdy jest to konieczne zgodnie z ustalonymi warunkami
Więcej informacji na temat zagadnień znajdziecie np. na anglojęzycznej stronie wiki, a mogą one być rozszerzane kolejnymi, zależnie od potrzeb.

Same kryteria są na tyle ogólne, że nie dają na razie pojęcia o potencjalnym wpływie na otoczenie czy możliwych zagrożeniach. Jeżeli jednak skonfrontujemy je z drugą listą, która wymieni wszystkie możliwe skutki (które są już zdefiniowane w polityce bepieczeństwa, lub stworzymy je sami), wtedy powinniśmy już być blisko.

Załóżmy, że zastanowimy się nad następującymi kategoriami:
1. Finanse- opóźnione wpływy, straty, kary, zmiany kursu akcji firmy, odszkodowania
2. Wizerunek – utrata dobrego postrzegania firmy, zaburzenia opinii
3. Działanie – niemożliwość funkcjonowania firmy, przestoje w pracy
4. Życie/zdrowie – szkody osobowe, wypadki
5. Prawo – procesy karne, ściganie przez instytucje
Można wymieniać dalej i jeszcze bardziej uszczegóławiać – jeśli jest taka potrzeba. Myślę jednak, że na razie wystarczy do dalszych prac.

Mając kryteria i kategorie skutków możemy zastanowić się, jakie będą punkty styku pomiędzy nimi, a dodatkowo można zejść głębej i przeprowadzić dochodzenie nie tylko dla całego systemu, ale dla poszczególnych funkcjonalności. Chwila przemyślenia każdego z nich da Wam na pewno ciekawe wyniki.

Zróbmy teraz dla ćwiczenia analizę jednej z wymyślonych przeze mnie funkcjonalności:

“System X wspiera działalność stacji pogotowia ratunkowego. Jedną z funkcji jest prezentacja adresu powiązanego z identyfikowanym numerem telefonu osoby dzwoniącej.”

Na pierwszy rzut oka wszystko wydaje się proste – wyświetla się adres, karetka jedzie, ratuje istnienie ludzkie.
Teraz załóżmy, że nie jest dostępny system udostępniający adresy na podstawie podanego numeru telefonu – nie wyświetla się żaden adres, czyli nie jest zapewniona dostępność informacji. Osoba dzwoniąca w szoku odruchowo podaje nie ten adres co powinna i karetka jedzie w przeciwnym kierunku.

Zastanawiając się nad skutkami, przejdźmy przez listę:
1. Finanse – jest wpływ – kurs karetki kosztuje i pojechała pod błędny adres
2. Wizerunek – także jest wpływ – zła opinia o stacji pogotowia rozchodzi się błyskawicznie
3. Działanie – niewielki wpływ, ale jest – ta karetka może być potrzebna gdzie indziej
4. Życie lub zdrowie – jest wpływ – w końcu stan zdrowia pacjenta może się pogorszyć.
5. Prawo – identycznie jak powyżej – pacjent może zgłosić się do sądu z roszczeniami

Przykład obrazuje pozornie niewielką funkcjonalność, która może mieć ogromny wpływ nie tylko na finanse, ale także może zagrozić ludzkiemu życiu. Wszystko przez niewielki błąd, który być może prześliznął się przez testy, ale dzięki skrupulatnie przeprowadzonej analizie bezpieczeństwa może ta i inne równie krytyczne funkcje będą bardziej szczegółowo potraktowane. Możliwe jest także dokładne monitorowanie poszczególnych modułów i wychwytywanie każdej niedostępności lub błędów działania.

Takie analizy mają bardzo duże znaczenie w dużych firmach, gdzie wpływ na otoczenie może być czasem ogromny, a straty mogą być milionowe lub wyższe. Wyobraźcie sobie, co może się stać jeżeli zawiesi się system nadzorujący chłodzenie reaktora elektrowni jądrowej, a w trakcie projektowania zapomniano zaprojektować zapasowego chłodzenia. Są właśnie takie sytuacje czy firmy, w których szczegółowe weryfikacje są niezbędne i są częścią obowiązkowych procesów.

Analizy bezpieczeństwa pozwalają stwierdzić, czy systemy są zaprojektowane dobrze, ale także, gdzie są pola do poprawy. Dlatego tak ważne jest zrobienie ich na samym początku projektu, nawet jeszcze w fazie zbierania wymagań – wtedy łatwiej jest zmienić projekt i dostosować system do wyników analizy – w przeciwnym razie może się okazać, że niepozorna zmiana, która jest konieczna, będzie się wiązała z dużymi kosztami i przesunięciem wdrożenia w czasie.

Oczywiście nie można też popadać w paranoję – wszystko musi być wyważone i dostosowane do sytuacji i potrzeb. W przeciwnym razie funkcjonowanie biznesu może być paradoksalnie zagrożone – przygotowanie długich i złożonych analiz jak dla elektrowni jądrowej np. dla gry na urządzenie mobilne będzie raczej absurdalne.

Jeżeli jesteście zainteresowani tematem takich analiz – zapraszam do kontaktu ze mną lub poszukiwań w sieci. Warto rozpocząć od podawanej przeze mnie wcześniej strony na wiki, można także zapoznać się z dobrymi praktykami ITIL, które porządkują zagadnienia bezpieczeństwa w firmie.

avatar

M S

Jedna odpowiedź do “Analizy bezpieczeństwa systemów w projektach IT”

  1. avatar box.com pisze:

    I savor, lead to I found just what I used to bbe looking for.
    You have ended myy 4 day long hunt! God Bless you man. Have a great day.
    Bye

    My website seo Leighton Bzzard (box.com)

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *