Przykład audytu systemu informatycznego[1].pdf

(240 KB) Pobierz
Przykład audytu systemu informatycznego
Założenia
Na wykonanie zadań z zakresu audytu systemów informatycznych zarezerwowano w planie rocznym
audytu 60 dni roboczych. Stanowi to 480 godzin, z których 40 godzin jest przeznaczonych na prace
przygotowawcze, a 40 godzin - na sporządzenie raportu końcowego. Przyjęto, że w zarezerwowanym
limicie czasu można przeprowadzić cztery audyty. Wybrane przez audytora obiekty audytu, dla
których zostanie ocenione ryzyko, są ukazane w tabeli.
Obiekty audytu informatycznego
Numer obiektu
Obiekt 1
Obiekt 2
Obiekt 3
Obiekt 4
Obiekt 5
Obiekt 6
Obiekt 7
Obiekt 8
Obiekt 9
Obiekt 10
Rozwiązanie
W celu wyboru obiektu audytu została wykorzystana macierz ryzyka, w której:
a) określono wagi dla najistotniejszych kategorii ryzyka,
b) przyznano poszczególnym kryteriom według osądu audytora punkty w skali od 1 do 5,
c) wytypowano obiekty audytu o największym ryzyku w wyniku przemnożenia poszczególnych wag
przez liczbę punktów dla każdej kategorii i dla każdego rodzaju decyzji; przy czym dla
uśrednienia wartość tę podzielono przez 15 (3 rodzaje decyzji x 5-stopniowa skala punktów).
Z przeprowadzonych obliczeń wynika, że audytor przeprowadzi badanie dla czterech obiektów audytu
o największym ryzyku, co jest wykazane w macierzy ryzyka przedstawionej w tabeli . Do obiektów
tych należą:
obiekt 10 „Ocena zarządzania kosztami przedsięwzięć informatycznych",
obiekt 2 „Ocena zgodności działania systemów informatycznych z przepisami prawa",
obiekt 1 „Ocena zakupu sprzętu i oprogramowania",
obiekt 3 „Ocena bezpieczeństwa danych w systemach informatycznych".
Temat zadania audytowego
Ocena procedur zakupu sprzętu i oprogramowania
Ocena zgodności działania systemów informatycznych z przepisami prawa
Ocena bezpieczeństwa danych w systemach informatycznych
Ocena zarządzania projektami informatycznymi
Ocena technik dokumentowania systemów informatycznych
Ocena zarządzania kadrą obsługującą systemy informatyczne
Ocena funkcjonowania infrastruktury informatycznej
Ocena zarządzania ryzykiem informatycznym
Ocena funkcjonowania systemów operacyjnych i sieci
Ocena zarządzania kosztami przedsięwzięć informatycznych
Tabela Macierz ryzyka służąca do wyboru obiektów audytu
Obiekty
audytu
Kategorie ryzyka
Krótkoterminowe
Zewnętrzne
Operacyjne
Finansowe
Finansowe
Średnioterminowe
Kontrola
wewnętrzna
Zewnętrzne
Operacyjne
Długoterminowe
Jakość
zarządzania
0,3
5
5
4
3
3
2
2
2
1
1
Zewnętrzne
Finansowe
Ocena
końcowa po
uwzględnieniu
kryteriów
ryzyka
Wagi
10
2
1
3
4
8
6
7
5
9
0,5
5
5
4
4
4
3
3
2
1
1
0,3
5
4
4
3
3
2
2
1
1
1
0,2
5
3
4
3
3
3
3
3
2
1
0,3
5
5
4
3
3
3
2
2
1
1
0,3
5
4
3
3
3
3
2
1
1
1
0,2
5
4
3
3
3
3
2
2
3
1
0,2
5
3
4
3
3
2
2
2
2
1
0,4
5
3
3
3
2
2
2
2
1
1
0,3
5
4
4
4
3
3
3
2
2
1
%
100,0
83,3
74,0
67,0
60,7
52,0
46,7
39,3
27,3
20,0
Poziom ryzyka w 5-stopniowej skali: 1 - niski, 2 - średni, 3 - ponadśredni, 4 - wysoki, 5 - bardzo
wysoki
Źródło: Opracowanie własne.
Aby prawidłowo funkcjonować, przykładowa jednostka powinna opracować jednoznaczną politykę w
zakresie analizy ryzyka. Wymaga to wyznaczenia:
• celów organizacji dotyczących zarządzania ryzykiem systemów informatycznych,
• akceptowanego poziomu ryzyka w zakresie systemów informatycznych,
• zasad i metodyki oceny ryzyka,
• osób odpowiedzialnych za zarządzanie ryzykiem,
• mechanizmów eliminowania ryzyka.
Po zakończeniu etapu wstępnego audytor przeprowadza badanie właściwe systemów informatycznych
według faz, takich jak:
• ocena skuteczności mechanizmów kontrolnych w odniesieniu do systemów informatycznych,
• określenie zgodności faktycznych działań z ustalonymi mechanizmami kontrolnymi,
• przeprowadzenie testów oceny efektywności mechanizmów kontroli,
• sformułowanie wniosków o skuteczności i efektywności systemu kontroli.
Rozpoczynając badanie, należy przeprowadzić analizę problemów związanych z projektowaniem,
wdrażaniem i użytkowaniem systemów informatycznych. Czynności audytorskie w tym zakresie
powinny sprowadzać się do zebrania informacji na temat strategii i planów w zakresie technologii
informacyjnej, polityki i procedur bezpieczeństwa systemów, przechowywania danych, zasad
nabywania i wdrażania systemów, praw autorskich oraz zasad zarządzania zasobami. Następnie
audytor powinien ustalić obowiązki właścicieli poszczególnych zasobów informatycznych i ocenić
sposób ich wykorzystania w aspekcie zgodności z przepisami państwowymi lub branżowymi. Do
zadań audytora należy również ocena wykorzystania umiejętności informatyków zatrudnionych w
jednostce. Wszelkie oceny stanu rzeczywistego są dokonywane za pomocą testów przeglądowych i
testów zgodności, które stwarzają podstawy do sformułowania pozytywnej lub negatywnej oceny
efektywności zarządzania systemami informatycznymi oraz stosowanych dla nich procedur
kontrolnych. Jak już wspomniano w rozdziale 5, przy przeprowadzaniu testów zgodności stosuje się
określone techniki, takie jak: obserwacja, rozmowa, analiza, weryfikacja, powtórzenie czynności czy
badanie dokumentów. Typowe dokumenty wykorzystywane w audycie systemów informatycznych są
przedstawione w tabeli.
Tabela Dokumenty stosowane w audycie informatycznym
Grupy dokumentów
Rodzaje dokumentów
Obserwacja procesów i Spis zewnętrznych nośników danych i sposób ich przechowywania
inwentaryzacja zasobów Działania podejmowane przez ochronę budynku
materialnych
Obserwacja ruchu osobowego
System bezpieczeństwa pomieszczeń komputerowych podczas działania
Dowody
Protokoły usunięcia danych
dokumentacyjne
Zapisy transakcji
Wydruki treści programów
Dokumenty magazynowe, przewozowe, faktury
Wyciągi z rejestrów kontrolnych, dziennika operacji użytkownika
Dokumentacja systemu
Świadectwa
Opisy stosowanych polityk i procedur informacyjnych
reprezentujące
Schematy systemu informatycznego
Pisemne lub ustne oświadczenia dotyczące funkcjonowania systemu
informatycznego
Analizy
Analizy porównawcze kosztów dz>łania struktur informatycznych w sto-
sunku do podobnych rozwiązań stosowanych w innych organizacjach
Porównanie wskaźników błędów między aplikacjami czy transakcjami
Analiza trendów wydajności systemów informatycznych
Zródlo: Opracowanie na podstawie: M. Forystek, Audyt informatyczny, InfoAudit, Warszawa 2005, s.
196.
Po przeprowadzeniu testów wszelkie informacje o nieskutecznych lub nie-wydajnych strukturach lub
mechanizmach kontrolnych wraz z rekomendacjami usprawnień powinny znaleźć się w końcowym
raporcie z audytu.
Przykład realizacji zadania audytowego w zakresie bezpieczeństwa systemów
informatycznych
Przykład
Założenia
W szkole wyższej audytor wewnętrzny w celu wyboru zadania audytowego przeprowadził
analizę ryzyka w zakresie systemów informatycznych. W wyniku przeprowadzonej oceny
stwierdził, iż największym zagrożeniem dla prawidłowego funkcjonowania tych systemów
jest nieprzestrzeganie zasad utrzymania ich bezpieczeństwa. Świadczą o tym głównie braki w
zakresie:
• pisemnych procedur dotyczących fizycznego i logicznego dostępu do danych,
• planów awaryjnych na wypadek wystąpienia zagrożeń.
Rozwiązanie przykładu
Dla realizowanego zadania audytor opracował program, którego struktura została
zaprezentowana w tabeli .
W programie audytu został wyznaczony termin narady otwierającej, której zadaniem jest
przedstawienie pracownikom jednostki celu audytu oraz założeń organizacyjnych w zakresie
jego realizacji. Po odbyciu narady otwierającej został opracowany protokół, którego
zawartość w zakresie zadania audytowego jest przedstawiona w tabeli.
Tabela Program zadania audytowego
„Ocena bezpieczeństwa systemów informatycznych"
Program audytu
Nr ref.....................
Informacje wstępne o zadaniu audytowym
Temat zadania audytowego
Bezpieczeństwo systemów informatycznych w jednostce
Numer zadania audytowego
10/07 ASI
Nazwa audytowanej jednostki Dział Informatyki Dział Księgowości Dział Kadr
Pozostałe działy administracyjne przedsiębiorstwa
Budżet czasowy
90 dni roboczych
Planowany termin rozpoczęcia Narada otwierająca 15.01.2007
audytu
Planowany termin przedsta-
20.04.2007 - sprawozdanie wstępne 5.05.2007 -
wienia sprawozdania
sprawozdanie końcowe
wstępnego i końcowego
Podpis Kierownika Jednostki
Informacje szczegółowe o zadaniu audytowym
Cel audytu
Ocena bezpieczeństwa zasobów informacyjnych w systemach
informatycznych jednostki oraz opracowanych planów awaryjnych
Zakres audytu
Analiza ryzyka
I. Fizyczne i logiczne bezpieczeństwo systemów
• plany w zakresie zabezpieczeń fizycznych i logicznych systemów,
• analiza ryzyka w zakresie bezpieczeństwa fizycznego i logiczne-
go,
• ocena funkcjonowania środków związanych z bezpieczeństwem
fizycznym,
• ocena funkcjonowania środków związanych z dostępem
logicznym,
• ocena wyszkolenia personelu w zakresie bezpieczeństwa,
• ocena prawidłowości przyporządkowania zasobów informatycz-
nych do odpowiednich właścicieli i stosowania tych zaleceń.
II. Plany awaryjne
• analiza ryzyka związana z funkcjonowaniem jednostki,
• ocena wpływu zagrożeń na bezpieczeństwo informacji w
systemie,
• plan gwarantujący ciągłość działania systemu,
• opracowane procedury odtwarzania systemów.
I. Fizyczne i logiczne bezpieczeństwo systemów
• możliwość kradzieży sprzętu i oprogramowania z powodu
niewystarczających zabezpieczeń,
• brak procedur ochrony przeciwpożarowej,
• brak procedur zabezpieczania mienia przed kradzieżą,
• brak ochrony przed zalaniem lub wilgocią,
• brak procedur i planów ochrony sprzętu,
• zbyt szeroki lub nieuprawniony dostęp do danych,
• zbyt łatwy dostęp do systemu,
• możliwość utraty jego zasobów,
• utrata integralności, poufności i dostępności danych,
• brak procedur w zakresie transmisji danych,
• błędy w katalogowaniu i przechowywaniu danych,
• brak ochrony antywirusowej,
• brak systemu wykrywania prób dostępu do danych przez
niepowołane osoby,
• brak likwidacji uprawnień dostępu do danych po zmianie
stanowiska lub rezygnacji z pracy.
II. Plany awaryjne
• błędne strategie postępowania w sytuacjach kryzysowych,
• brak opracowanych procedur postępowania w sytuacjach
kryzysowych,
• brak jasnego sformułowania zadań osób zaangażowanych w
wykonywanie planu awaryjnego,
• nieaktualne plany awaryjne,
• brak identyfikacji nowego ryzyka,
• brak testowania planów awaryjnych,
• brak ekonomicznej oceny przedsięwzięć dotyczących
sposobów zabezpieczeń na wypadek awarii,
• błędy w klasyfikacji systemów,
• brak aktualnego spisu sprzętu i oprogramowania,
• brak pisemnych procedur wykonania kopii zapasowych oraz
harmonogramu ich wykonania,
Zgłoś jeśli naruszono regulamin