Rodzaje audytu informatycznego

Artur Sierszeń

[e-mail]

http://bzyczek.kis.p.lodz.pl

W praktyce (laboratoryjnej)



Rozróżniamy 3 podstawowe rodzaje

audytu informatycznego:



audyt legalności oprogramowania;



audyt sprzętu;



audyt bezpieczeństwa.

2

Audyt legalności oprogramowania



Audyt legalności oprogramowania służy zestawieniu liczby i typów

posiadanych licencji na oprogramowanie ze stanem faktycznym, czyli z

oprogramowaniem zainstalowanym na wszystkich komputerach

należących do przedsiębiorstwa.



Uzyskuje się dzięki temu informacje o tym, jakich licencji posiada się

zbyt wiele lub zbyt mało. Można również określić jakie oprogramowanie

jest używane nielegalnie.



Aby zapobiegać wszelkim przypadkom nielegalnego użytkowania

oprogramowania należy opracować i wprowadzić w życie system

ewidencjonowania oprogramowania, które jest zainstalowane na

komputerach firmy.



W szczególności zarząd oraz dział IT powinny na bieżąco weryfikować

stan faktyczny z polityką oprogramowania, gdyż im większa wiedza na

temat oprogramowania używanego w firmie, tym mniejsze ryzyko

konsekwencji prawnych w wyniku znalezienia nielegalnego

oprogramowania podczas kontroli.

3

Oprogramowanie



uplook – program umożliwiający sprawdzenie zgodności

oprogramowania z licencjami, zarządzanie licencjami

oprogramowania w przedsiębiorstwie. Dzięki jego wykorzystaniu

audyt oprogramowania na poszczególnych komputerach przestaje

być procesem żmudnym i czasochłonnym.



http://www.uplook.net/

4

Oprogramowanie



System e-Audytor polskojęzyczne narzędzie SAM (Software Asset

Management). Zakłada praktykę biznesową obejmującą

zarządzanie i optymalizację nabycia, instalacji, stosowania, oraz

usuwania oprogramowania w organizacji.

5

Oprogramowanie

6



AuditPro jest profesjonalnym narzędziem do audytu

oprogramowania oraz sprzętu. Zapewnia nie tylko możliwość

audytu komputera pod względem legalności ale również

audytu całej sieci. Dodatkowo zawiera moduły zarządzania

zasobami, możliwość drukowania kodów kreskowych.



Komfort administrowania poprawia możliwość integracji z

aplikacją TWAIN, Denso, ORDraw nowe raporty czy nowe

funkcje w module Zasoby i Monitoringu.



Bardzo rozbudowany funkcjonalnie i jeden z najbardziej

popularnych systemów do audytu oprogramowania w naszym

kraju.

Oprogramowanie



GASP – narzędzie to jest wykorzystywane przez takie organizacje

antypirackie jak: BSA, SIIA oraz CAAST. Służy on do

przeprowadzania audytów oprogramowania i sprzętu w firmach

obejmujących od kilkunastu do kilkuset tysięcy komputerów.



http://www.gasp.com/public/common/index.aspx



Zawiera obszerne bazy danych (SID), unikalny algorytm

identyfikacji, szybko automatyzuje zbieranie, identyfikacja i

przetwarzania PC oparte oprogramowania / sprzetu aktywów

danych.



Posiada bardzo szeroki wachlarz raportowania a także

przystosowania na potrzeby danego klienta.



Program najbardziej wspierany przez organizację BSA natomiast

zaznaczyć należy, że wadą niewątpliwą na naszym rynku jest mała

liczba rozpoznawanego automatycznie rodzimego oprogramowania.

7

Audyt Sprzetu



Audyt sprzętu polega de facto na uruchomieniu na każdym

komputerze programu, który dokładnie opisuje konfigurację

sprzętową komputera. Wyniki takiego postępowania są

zapisywane w centralnej bazie danych, na podstawie której

opracowywane są raporty końcowe.



Wyniki takiego audytu mogą być przydatne dla np. działu

finansowego (weryfikacja danych inwentaryzacyjnych) lub

działu administracyjnego – do śledzenia zmian

konfiguracyjnych poszczególnych stacji.

8

Audyt Bezpieczeństwa



Audyt bezpieczeństwa, zwany również audytem zabezpieczeń

lub audytem bezpieczeństwa informacji, jest de facto

podstawą Polityki Bezpieczeństwa Informacji.



Pozwala on na kontrolowanie i modyfikowanie mechanizmów

ochrony informacji.



Należy pamiętać, że bezpieczeństwo nie jest ciągłe, gdyż

wraz z rozwojem techniki informatycznej pojawiają się coraz

to nowe zagrożenia, zwłaszcza dla danych przetwarzanych

lub przechowywanych w systemach informatycznych.



Należy tutaj wspomnieć, że identyfikacja zagrożeń oraz

analiza ryzyka dla systemów informatycznych są

usankcjonowane prawnie, w postaci odpowiednich zapisów w

Ustawie o ochronie danych osobowych oraz Ustawie o

ochronie informacji niejawnych.

9

Audyt Bezpieczeństwa



Już od połowy lat sześćdziesiątych ubiegłego stulecia

próbowano ustandaryzować zagadnienia związane z

ochroną i oceną bezpieczeństwa informacji w

systemach informatycznych.



Było to związane z pojawieniem się pierwszych

systemów wielodostępowych (UNIX) oraz sieci

komputerowych.



Doprowadziło to w końcu

do opracowania kilku standardów, do najważniejszych

z nich należą:



COBIT



TSSEC



BS 7799

10

COBIT



Opracowany przez ISACA standard COBIT (ang. Control

Objectives for Information and related Technology) jest

zdecydowanie najbardziej preferowany przez instytucje bankowe i

finansowe na całym świecie. Składa się on z następujących

części:



Executive Summary;



Framework;



Control Objectives;



Audit Guidelines;



Implementation Tool Set.



Najważniejsza jest część Control Objectives, która zawiera trzysta

dwa szczegółowe wymagania dotyczące trzydziestu czterech

procesów przebiegających w systemach informatycznych. Dla

każdego procesu w COBIT są zdefiniowane tzw. punkty kontrolne,

dla których audytor musi dokonać oceny ich spełnienia lub

niespełnienia w ramach ocenianej organizacji.

11

TSSEC



TSSEC, opracowany przez Departament Bezpieczeństwa

USA;



Standard TSSEC (ang. Trusted Computer System

Evaluation Criteria) został opublikowany w roku 1983.



Wyróżnia on cztery poziomy kryteriów oceny, oznaczone

literami alfabetu D, C, B, A. Przy czym poziom D jest

najniższą oceną ochrony, poziom A natomiast najwyższą.



Wskazuje on też konkretne środki ochrony, których użycie

jest obligatoryjne dla osiągnięcia określonego poziomu

oceny. Obecnie TSSEC jest wypierany przez znacznie

młodsze ITSEC oraz CC (ang. Common Criteria).

12

BS 7799



BS 7799, opracowany przez Brytyjski Instytut Standaryzacyjny.

Standard ten został po raz pierwszy opublikowany w latach

dziewięćdziesiątych ubiegłego stulecia i nadal jest aktualizowany.



Pierwsza część dokumentu, zatytułowana „Code of practice for

Information Security Management”, zawiera (tak jak COBIT) spis

najlepszych praktyk, które należy stosować podczas budowy

i zarządzania systemami informatycznymi.



Część druga standardu precyzuje 127 wymagań, jakie powinny

spełniać bezpieczne systemy informatyczne.

13

BS 7799



Część druga standardu precyzuje 127 wymagań, jakie powinny

spełniać bezpieczne systemy informatyczne. Są one zgrupowane

w 10 tematów:



Polityka bezpieczeństwa;



Organizacja bezpieczeństwa;



Kontrola i klasyfikacja zasobów;



Bezpieczeństwo a personel;



Bezpieczeństwo fizyczne;



Zarządzanie komputerami i siecią komputerową;



Kontrola dostępu do systemu;



Projektowanie i utrzymywanie systemu;



Planowanie ciągłości procesów biznesowych;



Zgodność z obowiązującymi regulacjami prawnymi.

14

Audyt Bezpieczeństwa



Obecnie, to jest od 1. grudnia 2000 roku wszystkie

zalecenia zawarte w „Code of practice for Information

Security Management” stanowią treść międzynarodowej

normy ISO/EIC 17799:2000. We wrześniu roku 2003 Polski

Komitet Normalizacyjny przyjął ją jako polska norma o

oznaczeniu PN-ISO/EIC 17799:2003.



Na podstawie przepisów zebranych w wyżej wymienionych

standardach można śmiało stwierdzić, że audyt

bezpieczeństwa informatycznego powinien składać się z

czterech następujących faz:



sporządzenie listy sprawdzającej według wybranego

standardu;



wypełnienie listy za pomocą ankiety;



badanie systemów;



raport końcowy.

15

Audyt Bezpieczeństwa



Przy sporządzaniu listy należy najpierw wybrać metodykę jaką

posłużymy się podczas audytu. Często jest ona wybierana już na

etapie zamówienia na audyt lub przy podpisywaniu umowy

dotyczącej wykonania audytu. Dla metodyki COBIT lista będzie

składała się z 302 punktów, dla TSSEC ze 134, a dla BS 7799 lista

będzie obejmowała 127 zagadnień. Wszystkie one powinny być

przypisane do jednej z następujących klas oceny:



„spełnione”



„nie spełnione”



„spełnione częściowo”



„nie dotyczy”.



Listę wypełniamy na podstawie ankiety, wywiadów środowiskowych,

analizy dokumentacji przechowywanych w przedsiębiorstwie oraz

badań i testów.

16

Badanie



Badanie systemów odbywa się przy użyciu wysoko

wyspecjalizowanych narzędzi, które nierzadko są

uzupełniane testami penetracyjnymi.



Należy tutaj pamiętać, że same testy penetracyjne nie

są audytem.



Są one prowadzone w celu określenia podatności

danego systemu informatycznego na wrogie ataki z

wewnątrz lub zewnątrz.

17

Badanie - testy



testy typu

black box

- są najbardziej zbliżone do

autentycznych ataków przeprowadzanych przez

hackerów i crackerów.



Wszystkie szczegółowe informacje, jak wersje systemu

operacyjnego, infrastruktura sieciowa oraz

wykorzystywane oprogramowanie są niewiadomą dla

audytora.



Może on znać przybliżone informacje, jak np. nazwa

domeny używana przez audytowaną firmę.



Testy mają charakter ciągłej improwizacji, gdyż nie

można jasno określić kolejności działań jakie podejmuje

osoba przeprowadzająca test.



Tego typu testy są wykorzystywane zazwyczaj do

symulacji ataków z zewnątrz – z Internetu.

18

Badanie - testy



test z ograniczonym dostępem do informacji – istotą

takiego testu jest odgórne założenie, że intruz posiada

już jakieś informacje na temat atakowanego systemu.



Można tutaj również przyjąć założenie, że agresor

przejmie kontrolę nad jedną ze stacji roboczych

należących do przedsiębiorstwa i za jej pomocą

będzie zbierał informacje potrzebne do

przeprowadzenia właściwego ataku, również za

pomocą zainfekowanej stacji roboczej.



Audytor musi w takiej sytuacji zasymulować takie

wrogie przejęcie i przeprowadzić atak z Intranetu.

19

Badanie - testy



test z ograniczonym dostępem do informacji – istotą

takiego testu jest odgórne założenie, że intruz posiada

już jakieś informacje na temat atakowanego systemu.



Można tutaj również przyjąć założenie, że agresor

przejmie kontrolę nad jedną ze stacji roboczych

należących do przedsiębiorstwa i za jej pomocą

będzie zbierał informacje potrzebne do

przeprowadzenia właściwego ataku, również za

pomocą zainfekowanej stacji roboczej.



Audytor musi w takiej sytuacji zasymulować takie

wrogie przejęcie i przeprowadzić atak z Intranetu.

20

Badanie - testy



weryfikacja polityki bezpieczeństwa – ten rodzaj testów

polega na wyrywkowym testowaniu tylko tych

mechanizmów bezpieczeństwa, które są sprecyzowane

w dokumencie polityki bezpieczeństwa. Zaletą tego rodzaju

testów jest skupienie się tylko na wybranym fragmencie

łańcucha zabezpieczeń. W szczególności taki test może

dotyczyć np. :



reguł firewalla;



mechanizmów autoryzacji i autentykacji;



dostępu do pomieszczeń serwerowni.

21

Badanie - testy



Przy przeprowadzaniu dwóch pierwszych rodzajów testów należy

ustalić jak daleko może posunąć się tester po znalezieniu luki.



Należy sprecyzować, czy ma wykorzystać lukę tylko do

nielegalnego pozyskania informacji, czy też ma za jej pomocą

doprowadzić do całkowitego unieruchomienia systemu i

zniszczenia danych w nim przechowywanych.



Dobrą praktyką jest raportowanie występujących luk w systemie i

dopiero na życzenie klienta wykonanie próby pozyskania

informacji lub zniszczenia za ich pomocą systemu.



Sporządzony raport po audytowy powinien zawierać jak wyniki

wszystkich postępowań audytowych oraz wnioski z nich płynące.



Każdy raport powinien być podpisany przez wszystkich członków

zespołu audytowego, którzy w ten sposób gwarantują rzetelność i

półprofesjonalność wystawionej oceny.

22

Badanie - oprogramowanie



Podczas wykonywania testów penetracyjnych audytor może

wesprzeć się kilkoma ogólnodostępnymi programami, które

pozwalają na uzyskanie informacji istotnych

dla wyników postępowania audytowego.



Do tych programów można zaliczyć



sniffery

,



skanery portów



skanery podatności (ang.

vulnerability scaners

).

23

testery podatności



Programy komputerowe służące do wykrywania i raportowania

słabych punktów (podatnych na atak) aplikacji i systemów

operacyjnych.



Działanie takiego skanera można opisać w czterech krokach:



W tym kroku skaner zazwyczaj wykrywa aktywne adresy IP w sieci,

wykrywa otwarte porty, rozpoznaje system operacyjny oraz usługi

na nim uruchomione.



Ten krok jest często pomijany, gdyż w nim powinien zostać

wygenerowany wstępny raport. Zazwyczaj przechodzi się od razu

do kroku 3.



Na tym etapie skaner określa dokładną wersję systemu

operacyjnego oraz aplikacji nasłuchujących na otwartych portach.



W tym kroku następuję dokładne sprawdzenie, czy system jest

podatny na

exploity

zdefiniowane w skanerze.

24

testery podatności



Podział skanerów podatności



przyjazne



nieprzyjazne



Przyjazne skanery to te, które kończą swoje działanie na 3

etapie.



Nieprzyjazne natomiast przeprowadzają pełny proces

testowania podatności.

25

NESSUS



Najbardziej znanym testerem podatności jest projekt

Nessus. Wykorzystywany jest przez przeszło 75000

organizacji zajmujących się bezpieczeństwem informacji.



Projekt Nessus zapoczątkował w roku 1998 Renaud

Deraison.



Miał służyć Internautom do wyszukiwania luk w systemach

IT.



Obecnie pieczę nad projektem Nessus sprawują

programiści z firmy Tenable.



Od samego początku był dystrybuowany na zasadach

licencji GPL.

26

NESSUS



Niestety wiele firm wykorzystywało kod źródłowy Nessus w

swoich projektach komercyjnych i nie wnosiło nic w rozwój

samego Nessusa.



Z tego powodu od wersji 3.0 Nessus stał się projektem w

pełni komercyjnym. J



est dostępny dla wielu platform systemowych, takich jak



Linux,



BSD,



MS Windows,



Mac OS,



Solaris.

27

NESSUS



Jego obecny (wersja 3.2) system licencjonowania jest podzielony na 2

stopnie:



Home Feed

- jest to wersja Nessus, która jest przeznaczona do użytku

niekomercyjnego. Dostępne są tutaj wszystkie wtyczki GPL. Ta wersja

wymaga bezpłatnej rejestracji. Wszystkie wtyczki komercyjne są

dostępne w tej wersji dopiero po jakimś czasie od publikacji (od 2

tygodni, do 6 miesięcy).



Professional Feed

- jest to w pełni komercyjna wersja Nessus. Kosztuje

ona 1200 USD. Zawiera pełne wsparcie dla użytkowników końcowych i

co najważniejsze

– dostęp do wszystkich komercyjnych wtyczek natychmiast po ich

wydaniu. Dodatkowo wersja ta może być w pełni legalnie

wykorzystywana do wykonywania komercyjnych audytów.

28

NESSUS



Sam Nessus ma konstrukcję klient – serwer.



Część serwerowa jest odpowiedzialna za przeprowadzanie skanów oraz

zbieranie ich wyników.



Z części serwerowej serwerowej są również przeprowadzane

symulowane ataki.



Część kliencka jest odpowiedzialna za komunikację z użytkownikiem.

Ma ona bardzo przejrzyste GUI, które bardzo ułatwia pracę z

programem.



W części klienckiej definiuje się cele ataku (mogą to być nazwy

domenowe, zakresy IP oraz całe podsieci), wtyczki używane przy

skanowaniu.



Tutaj są również generowane raporty na podstawie danych zebranych

przez serwer.

29

NESSUS



Wszystkie wtyczki Nessus są napisane w jego wewnętrznym języku

skryptowym NASL (ang.

Nessus Attack Scripting Language

).



Zawierają one pełny opis zagrożenia, dokładny algorytm testowania, a

także wszystkie zalecane środki zaradcze i naprawcze, mające na celu

eliminację zagrożenie.



W bazie Nessus znajduje się obecnie ponad 11 000 wtyczek.

30

Rodzaje audytu informatycznego

K O N I E C