Rozdział 4.
Powiązanie mechanizmów zabezpieczających

W tym miejscu połączymy ze sobą wszystkie informacje dotyczące zespołu Tiger Team z poprzednich rozdziałów w celu sformułowania najlepszych zasad bezpieczeństwa, strategii, która pomoże Ci wykonać kolejne kroki. Tak jak w przypadku skutecznej zmiany platformy, integracji infrastruktury lub implementacji ważnego oprogramowania, konieczne będzie przygotowanie wstępnej dokumentacji planowania. Poświęcenie czasu na opracowanie szkicu zawierającego kolejne procedury do wykonania pomoże uniknąć ogromnej liczby błędów i niekonsekwencji. Pamiętając o tym, przyjrzyjmy się rekomendowanym programom przedstawionym w tej części i zastosujmy te, które odnoszą się do naszych wymagań w czasie tworzenia własnej polityki zabezpieczeń.

Zasady bezpieczeństwa

Zasady bezpieczeństwa technologii informatycznej są w centrum zainteresowania wielu osób zarówno w sektorze publicznym, jak i prywatnym. Każdy chce zabezpieczyć siebie i swoje informacje przed coraz częściej zdarzającymi się atakami hakerów. Mocne zasady bezpieczeństwa stanowią podstawę skutecznej obrony w tej dziedzinie. Pierwsza część tego rozdziału zawiera wyjątki z jednego z najważniejszych dokumentów poświęconych zapewnianiu bezpieczeństwa, aby pomóc Ci w utworzeniu własnych zasad. Jest to napisany w 1998 roku przez Marianne Swanson, specjalistkę w Dziale Bezpieczeństwa Komputerów, dla Państwowego Instytutu Standaryzacji i Technologii (National Institute of Standards Technology — NIST) Przewodnik po tworzeniu planów zabezpieczeń systemów technologii informatycznej (Guide to Developing Security Plans for Information Technology Systems). Biorąc pod uwagę konieczność zabezpieczenia państwowych tajnych informacji, usług i infrastruktury, te zalecenia mogą być uważane za cenne zasady, w oparciu o nie należy utworzyć plan lub politykę dla dowolnej organizacji.

Opisane w tym dokumencie i przedstawione tutaj elementy polityki zabezpieczeń obejmują:

• tworzenie planu,

• analizy,

• procedury niezbędne do wdrożenia opracowanej polityki zabezpieczeń.

Przewodnik po tworzeniu planów zabezpieczeń systemów technologii informatycznej został napisany dla pracowników amerykańskich agencji rządowych, ale ten materiał może być z powodzeniem wykorzystany w innych sektorach.

Ten rozdział powinien być traktowany jako zbiór wszystkich informacji przedstawionych dotąd w obu tomach tej książki.

Zasady bezpieczeństwa

Celem opracowania zasad bezpieczeństwa systemu jest poprawienie zabezpieczeń zasobów technologii informatycznej (IT). Wszystkie systemy rządowe i większość korporacyjnych cechuje pewien poziom wrażliwości i dlatego wymagają zabezpieczeń, które stanowią część polityki dobrego zarządzania. Zabezpieczenie systemu musi być udokumentowane w planie zabezpieczeń systemu.

Celem jest zapewnienie informacji o ogólnych wymaganiach bezpieczeństwa systemu oraz opisanie środków, które są już wykorzystywane lub będą użyte w celu spełnienia tychże wymagań. Schemat zabezpieczeń systemu przedstawia również dane o odpowiedzialności poszczególnych osób oraz oczekiwane zachowania wszystkich mających dostęp do systemu. Opis zabezpieczeń powinien być traktowany jako dokumentacja strukturalnego procesu planowania niezbędnych i efektywnych pod względem kosztów zabezpieczeń systemu. W planie powinny znaleźć się sugestie różnych menedżerów, których obowiązki są związane z systemem, włączając w to właścicieli informacji, operatora systemu oraz menedżera zabezpieczeń systemu. Możliwe jest dołączenie do podstawowego opracowania dodatkowych informacji oraz zmiana jego struktury i organizacji w zależności od potrzeb firmy, pod warunkiem jednak, iż główne części dokumentu są wyczerpujące i łatwe do odnalezienia. Aby plany w wystarczającym stopniu odzwierciedlały zabezpieczenia zasobów, przedstawiciel kierownictwa musi autoryzować system w celu umożliwienia obróbki informacji lub działania. Taka autoryzacja zapewnia bardzo ważną kontrolę jakości. Przez autoryzację procesu w systemie menedżer akceptuje powiązane z nim ryzyko.

Autoryzacja kadry zarządzającej powinna być oparta o ocenę kontroli kierowniczej, operacyjnej oraz technicznej. Ponieważ plan zabezpieczeń ustanawia i dokumentuje kontrolę zabezpieczeń, powinien stać się podstawą do autoryzacji, uzupełnioną w razie potrzeby dodatkowymi badaniami. Oprócz tego, okresowy przegląd kontroli powinien mieć wpływ na podobną autoryzację w przyszłości. Ponowna autoryzacja powinna mieć miejsce przed znaczącą zmianą w obróbce danych, ale nie rzadziej niż trzy razy do roku. Powinna odbywać się częściej w przypadku stwierdzenia większego ryzyka lub możliwości wystąpienia znaczących szkód.

Wprowadzenie

Szybko zmieniające się środowisko techniczne zmusza organizacje do adaptacji minimalnego zestawu kontroli kierowniczej w celu zabezpieczenia własnych zasobów technologii informatycznej (IT). Ta kontrola kierowana jest na poszczególnych użytkowników IT w celu odzwierciedlenia dystrybuowanej natury współczesnej technologii. Kontrola techniczna i operacyjna uzupełnia kontrolę kierowniczą. Wszystkie te rodzaje kontroli muszą ze sobą współgrać, aby były efektywne.

Plany dla głównych aplikacji i systemu ogólnego wsparcia

Plany systemu zabezpieczeń muszą obejmować wszystkie aplikacje i systemy, które mają znaleźć się w kategorii „głównych aplikacji” lub „systemu ogólnego wsparcia”. Konkretne plany zabezpieczeń dla pozostałych aplikacji nie są wymagane, ponieważ kontrola zabezpieczeń dla tych programów i aplikacji będzie zapewniana przez systemy ogólnego wsparcia, na których działają. Na przykład używany w całym dziale system zarządzania finansami będzie aplikacją główną, wymagającą własnego planu zabezpieczeń. Lokalny program, zaprojektowany do śledzenia wydatków i ich porównywania z budżetem biura, nie musi być uważany za aplikację główną, a jego obsługą zajmie się plan systemu ogólnego wsparcia dla systemu automatyzacji biura lub sieci lokalnej LAN. Standardowe oprogramowanie komercyjne (takie jak edytor tekstu, program do poczty elektronicznej, różnego rodzaju narzędzia i programy do ogólnego stosowania) zwykle nie jest traktowane jako główna aplikacja, dlatego obejmuje je plan systemu ogólnego wsparcia, na którym jest zainstalowane.

Cele planu zabezpieczeń

Celem planu systemu zabezpieczeń jest:

• zapewnienie przeglądu wymagań w stosunku do zabezpieczeń systemu oraz opis odbywających się lub zaplanowanych kontroli w celu spełnienia tych wymagań,

• opisanie odpowiedzialności i oczekiwanego zachowania wszystkich osób, które mają dostęp do systemu.

Odpowiedzialność w planie zabezpieczeń

Właściciel systemu jest odpowiedzialny za przygotowanie planu zabezpieczeń oraz jego wprowadzenie i monitorowanie skuteczności. W planie zabezpieczeń powinny znaleźć się sugestie różnych osób, których odpowiedzialność jest związana z systemem, włączając w to końcowych użytkowników, właścicieli informacji, administratora systemu oraz menedżera zabezpieczeń systemu.

Rekomendowany format

Ten dokument został opracowany tylko jako wzór i nie powinien być uważany za jedyny możliwy format. Standardowe podejście jednak nie tylko ułatwia tworzenie planu, udostępniając przykłady, ale i pomaga przy jego sprawdzaniu. Poziom szczegółów zamieszczonych w planie powinien odpowiadać znaczeniu oraz wartości systemu dla misji organizacji (oznacza to, iż bardziej szczegółowy plan jest wymagany w systemach krytycznych dla pracy organizacji). Plan zabezpieczeń powinien w pełni identyfikować i opisywać obecnie odbywające się i zaplanowane kontrole dla systemu. Taki plan powinien również zawierać zasady zachowania.

Porady i komentarz do planu

Przed realizacją planu zabezpieczeń należy zebrać niezależne porady i komentarze na jego temat. Takie uwagi mogą pochodzić od osób pracujących w organizacji lub poza nią, które nie są odpowiedzialne za tworzenie, implementację lub obsługę systemu. Tacy doradcy nie powinni należeć do grona osób tworzących raporty dla właściciela systemu; wymagana jest również odpowiednia wiedza lub doświadczenie, co zapewnia ujęcie w planie niezbędnych informacji, a także spełnienie wymagań i standardów polityki bezpieczeństwa firmy. Wybrane osoby to na przykład menedżer programu zabezpieczeń IT w firmie, menedżerowie IT innych systemów, współpracownicy z zewnątrz lub pracownicy z innych organizacji rządowych.

Odbiorcy

Ten przewodnik może być wykorzystany na dwa różne sposoby. Po pierwsze, powinien być używany przez osoby odpowiedzialne za bezpieczeństwo IT na poziomie systemu oraz poziomie organizacyjnym. Dokument ma być przewodnikiem w czasie tworzenia planów zabezpieczeń i jest napisany konkretnie dla osób, które mają mało doświadczenia w zakresie bezpieczeństwa komputerowego. Może być również używany jako dokument kontrolny przez rewidentów, menedżerów i specjalistów zajmujących się bezpieczeństwem IT. Przedstawiono tu ogólne koncepcje, które można zastosować w firmach sektora prywatnego i publicznego.

Analiza systemu

Po utworzeniu plan zabezpieczeń będzie zawierał informacje techniczne o systemie, jego wymaganiach pod względem zabezpieczeń, a także kontrole prowadzone w celu ochrony przed ryzykiem i wrażliwością systemu. Zanim zostanie utworzony plan, należy wybrać jego typ odpowiedni dla danego systemu. Ta część rozdziału przeprowadzi czytelnika przez analizę systemu w celu ustalenia zakresu i typu systemu.

Granice systemu

Zdefiniowanie „systemu” dla potrzeb tego przewodnika wymaga analizy zakresu systemu i odpowiedzialności w organizacji. System to otoczone logicznymi granicami zestawy procesów, komunikacji, przechowywania danych oraz powiązanych zasobów. Elementy te stanowią pojedynczy system, który wymaga planu zabezpieczeń. Każdy element systemu musi:

• znaleźć się w tym samym zakresie bezpośredniej kontroli kierowniczej,

• mieć tę samą funkcję lub cel misji,

• mieć praktycznie taką samą charakterystykę działania oraz potrzeby pod względem zabezpieczeń,

• znajdować się w tym samym ogólnym środowisku operacyjnym.

Wszystkie elementy systemu nie muszą być ze sobą fizycznie połączone (na przykład grupa wolnostojących komputerów osobistych w biurze; grupa pecetów umieszczonych w domach pracowników, które podlegają określonym zasadom programu zdalnej pracy; grupa przenośnych komputerów, które są używane przez osoby wymagające w swej pracy mobilności; system z wieloma identycznymi konfiguracjami, które są zainstalowane w miejscach z identycznymi zabezpieczeniami oraz w takim samym środowisku).

Kategoria systemu

Kolejnym krokiem jest umieszczenie każdego systemu w kategorii „głównej aplikacji” lub „systemu ogólnego wsparcia”. Wszystkie aplikacje powinny być objęte planem zabezpieczeń. Może to być konkretny plan, jeśli dana aplikacja została oznaczona jako główna, lub plan zabezpieczeń ogólnego systemu wsparcia. System może być oznaczony jako główna aplikacja, nawet jeśli jest również obsługiwany przez system oznaczony jako system ogólnego wsparcia. Na przykład sieć LAN może być określona jako system ogólnego wsparcia i mieć własny plan zabezpieczeń. System księgowy może być oznaczony jako główna aplikacja, nawet jeśli jest obsługiwany przez zasoby komputerowe i komunikacyjne sieci LAN. W tym przykładzie główna aplikacja wymaga dodatkowych zabezpieczeń ze względu na wrażliwość informacji, jakie przetwarza. Jeśli dla głównej aplikacji, która jest obsługiwana przez system ogólnego wsparcia, wymagany jest własny plan zabezpieczeń, konieczna jest koordynacja obu planów.

Główne aplikacje

Wszystkie aplikacje rządowe i większość korporacyjnych stanowią wartość dla ich właściciela, dlatego wymagają pewnego poziomu zabezpieczeń. Niektóre aplikacje wymagają specjalnego nadzoru kierownictwa ze względu na przetwarzane lub przesyłane informacje, a także z powodu ich znaczenia dla organizacji.

Organizacje powinny rozwijać swoje umiejętności w zakresie ustalania głównych aplikacji oraz upewnić się, czy wymagania zabezpieczeń dla pozostałych aplikacji zostały omówione jako część planu zabezpieczeń dla właściwego systemu ogólnego wsparcia.

Główne aplikacje to systemy wykonujące jasno zdefiniowane funkcje, dla których można zidentyfikować warunki i potrzeby dotyczące zabezpieczeń (na przykład system elektronicznego przesyłania przelewów). Główna aplikacja może składać się z wielu oddzielnych programów i urządzeń oraz komponentów telekomunikacyjnych. Te komponenty mogą być pojedynczym programem lub kombinacją sprzętu i oprogramowania, której głównym celem jest obsługa konkretnej funkcji związanej z pracą firmy. Aplikacja główna może także składać się z wielu oddzielnych aplikacji, jeśli wszystkie z nich są związane z jedną funkcją (na przykład obsługa wynagrodzeń lub danych pracowników). Jeśli system jest zdefiniowany jako aplikacja główna, która działa na innym systemie ogólnego wsparcia w organizacji:

• powiadom właściciela systemu, że aplikacja ma krytyczne znaczenie lub zawiera wrażliwe informacje, a także udostępnij konkretne wymagania pod względem zabezpieczeń,

• udostępnij operatorowi systemu ogólnego wsparcia kopię planu zabezpieczeń głównej aplikacji,

• poproś o kopię planu zabezpieczeń systemu ogólnego wsparcia i upewnij się, czy zapewnia on właściwe zabezpieczenia dla aplikacji i informacji,

• do części Środowiska systemu planu zabezpieczeń systemu ogólnego wsparcia dołącz informacje zawierające unikalną nazwę oraz identyfikator.

System ogólnego wsparcia

System ogólnego wsparcia składa się z połączonych zasobów informacyjnych, znajdujących się w zakresie tej samej bezpośredniej kontroli kierowniczej, które oferują tę samą funkcjonalność. System ogólnego wsparcia zwykle obejmuje osprzęt, oprogramowanie, informacje, dane, aplikacje, komunikację oraz ludzi, a także zapewnia obsługę wielu użytkowników lub aplikacji. Dla przykładu system ogólnego wsparcia to:

• sieć LAN, włączając w to inteligentne terminalne, które obsługują biuro oddziału,

• sieć szkieletowa infrastruktury,

• sieć komunikacji,

• centrum obróbki danych działu, włączając w to system operacyjny i narzędzia,

• usługa obróbki współdzielonych informacji w organizacji.

Główna aplikacja może działać w systemie ogólnego wsparcia. Plan dla takiego systemu powinien zawierać informacje o planach głównych aplikacji w części Ogólny opis i cele.

Tworzenie planu

Pozostała część tego dokumentu ma pomóc w tworzeniu planu zabezpieczeń. Wszystkie plany zabezpieczeń powinny być oznakowane, traktowane i kontrolowane co najmniej na poziomie wrażliwości zależnym od polityki firmy. Oprócz tego, wszystkie plany zabezpieczeń powinny zawierać datę ostatniej modyfikacji w celu prostego śledzenia i zatwierdzania zmian. Umieszczenie powyższych danych na każdej stronie planu zabezpieczeń może być przydatne, jeśli aktualizacje mają być dokonywane przez wymianę stron. Wszystkie plany rozpoczynają się od poniższej części o nazwie Identyfikacja systemu.

Identyfikacja systemu

Pierwsza część planu udostępnia podstawowe informacje identyfikujące system. Musi ona zawierać ogólne dane o osobie odpowiedzialnej za system, celach systemu oraz poziomie wrażliwości systemu.

Nazwa systemu

Plan rozpocznij od podania nazwy systemu lub aplikacji. Każdy system i aplikacja powinny otrzymać unikalną nazwę lub identyfikator w celu upewnienia się, czy spełnione są właściwe wymogi pod względem zabezpieczeń w oparciu o unikalne wymagania dla systemu, a także czy odpowiednio zastosowano przydzielone zasoby. Identyfikator może stanowić kombinację liter i cyfr; można go także używać w połączeniu z nazwą systemu lub aplikacji. Unikalna nazwa lub identyfikator powinien pozostać bez zmian przez cały okres życia systemu, dzięki czemu organizacja może śledzić wypełnianie wymagań dotyczących zabezpieczeń.

Odpowiedzialna organizacja

W tej części podaj oddział organizacji, który jest odpowiedzialny za system. Jeśli dana funkcja jest wypełniana przez firmę zewnętrzną, należy tu podać jej dane oraz opisać powiązania. Konieczne jest podanie pełnych informacji, włączając w to adresy zewnętrznej firmy.

Informacje kontaktowe

Podaj tu nazwisko, stanowisko, nazwę organizacji oraz numer telefonu jednej lub więcej osób, które mogą udzielić informacji na temat systemu. Jedna z tych osób powinna być wyznaczona jako właściciel systemu. Podane tu osoby muszą mieć wystarczającą wiedzę na temat systemu, aby w razie potrzeby podać dodatkowe informacje.

Przydział odpowiedzialności za zabezpieczenia

Należy wybrać osobę, która będzie odpowiedzialna za zapewnienie wystarczającego poziomu bezpieczeństwa aplikacji lub systemu ogólnego wsparcia. Aby działania takiej osoby były skuteczne, musi ona mieć wystarczającą wiedzę na temat środków kontroli kierowniczej, operacyjnej i technicznej, niezbędnych do zabezpieczenia systemu. W tej części należy umieścić nazwisko, stanowisko oraz numer telefonu osoby odpowiedzialnej za bezpieczeństwo systemu.

Status operacyjny systemu

Należy wskazać jeden lub więcej poniższych statusów operacyjnych systemu. Jeśli wybrano więcej niż jeden status, należy podać części systemu, jakie obejmuje dany status.

• Operacyjny — system działa.

• W konstrukcji — system jest w trakcie planowania, tworzenia lub wdrażania.

• Przechodzi poważną modyfikację — system jest właśnie modyfikowany lub zmieniany.

Jeśli system jest w fazie konstrukcji lub poważnej modyfikacji, należy przedstawić informacje o metodach zapewnienia wymagań zabezpieczeń. W odpowiednich częściach planu należy także umieścić konkretne informacje zależne od położenia systemu w cyklu życia zabezpieczeń.

Ogólny opis i cele

W tej części powinien znaleźć się krótki opis (od jednego do trzech akapitów) funkcji i celu systemu (na przykład wskaźnik ekonomiczny, obsługa sieci w organizacji, analiza danych firmowych).

Jeśli jest to system ogólnego wsparcia, przedstaw listę wszystkich aplikacji obsługiwanych przez ten system. Należy tu również podać, czy dana aplikacja jest aplikacją główną, a także dołączyć unikalne nazwy i identyfikatory. Trzeba opisać też funkcję każdej aplikacji oraz przetwarzane przez nią informacje, a także dołączyć listę użytkowników w organizacji z podziałem na użytkowników wewnętrznych i zewnętrznych (z punktu widzenia właściciela systemu) oraz ogólny opis typu informacji i sposobu przetwarzania. Poproś właścicieli aplikacji o niezbędne dane (a także o kopie planów zabezpieczeń dla głównych aplikacji) w celu spełnienia ich wymagań.

Środowisko systemu

Dołącz tu krótki (od jednego do trzech akapitów) ogólny opis techniczny systemu. Powinny się w nim znaleźć wszystkie czynniki środowiskowe lub techniczne, które budzą pewne zastrzeżenia pod względem zabezpieczeń, takie jak:

• system jest przyłączony do Internetu,

• system znajduje się w trudnym środowisku lub w innym kraju,

• oprogramowanie jest szybko wdrażane,

• oprogramowanie znajduje się w otwartej sieci, która jest dostępna dla wszystkich użytkowników,

• aplikacja jest obsługiwana w miejscu, które nie jest pod kontrolą organizacji,

• główny system ogólnego wsparcia ma linie modemowe.

Opisz używaną główną platformę komputerową (na przykład komputer mainframe, komputer biurkowy, sieć lokalna LAN lub rozległa WAN). Dołącz także ogólny opis podstawowych komponentów systemu, włączając w to osprzęt, oprogramowanie oraz zasoby komunikacyjne. Opisz typ przyłączy komunikacyjnych (na przykład linia dedykowana, komutowana, publiczna sieć danych lub głosowa, Internet). We właściwych częściach dokumentu opisz sposoby kontroli używane do zabezpieczania linii komunikacyjnych.

Dołącz także informacje o wszystkich programach chroniących system i informacje. Określ ogólnie stosowany typ zabezpieczeń (kontrola dostępu do platformy komputerowej oraz przechowywanych plików na poziomie systemu operacyjnego albo dostęp do rekordów danych w aplikacji). Powinieneś zamieścić tu informacje tylko o tych typach kontroli, które zostały wdrożone lub są planowane, a nie pełną listę kontroli dostępnych w oprogramowaniu. Dostępne, ale niezaimplementowane typy kontroli nie zapewniają bezpieczeństwa.

Połączenia systemu i współdzielenie informacji

Połączenie systemu oznacza bezpośrednie połączenia systemów w celu współdzielenia zasobów informacyjnych. Jeśli takie połączenie nie jest właściwie zabezpieczone, to zagrożone są wszystkie przyłączone systemy oraz przechowywane, obrabiane i transmitowane przez nie dane. Bardzo ważne jest, aby operatorzy systemu, właściciele informacji oraz menedżerowie uzyskali jak najwięcej informacji o słabych stronach połączeń systemu i współdzielenia informacji, a także o potrzebie zwiększonej kontroli w celu wyeliminowania niebezpieczeństwa. Plan zabezpieczeń systemu często powoduje rozpoczęcie wymiany informacji o zabezpieczeniach oraz pozwala kadrze kierowniczej na podejmowanie decyzji dotyczących redukcji ryzyka.

W planie zabezpieczeń musi znaleźć się opis zasad zabezpieczeń dla połączonych systemów oraz współdzielonych danych (zajrzyj do części Zasady zachowania). W tej części należy udostępnić informacje dotyczące autoryzacji połączeń z innymi systemami lub współdzielenia danych. Należą do nich:

• lista połączonych systemów (włączając w to Internet),

• unikalne identyfikatory systemów (jeśli stosowane),

• nazwy systemów,

• organizacja, do której należą inne systemy,

• typ połączenia (TCP/IP, komutowane, SNA itp.),

• krótkie omówienie głównych kwestii i zastrzeżeń związanych z połączeniami,

• nazwa i stanowisko menedżera odpowiedzialnego za autoryzację,

• data autoryzacji,

• system zapisywania (jeśli stosowany),

• poziom wrażliwości każdego systemu,

• interakcja między systemami,

• kwestie zabezpieczeń oraz zasady zachowania innych systemów, które należy wziąć pod uwagę przy zabezpieczaniu tego systemu.

Wrażliwość obsługiwanych informacji

Ta część zawiera opis typów informacji, jakie są obsługiwane przez system, a także analizę ważności tych danych. Wrażliwość i ważność informacji przechowywanych, przetwarzanych lub przesyłanych przez system stanowi podstawę do ustalenia wartości systemu i jest jednym z głównych czynników zarządzania ryzykiem. Informacje w tym opisie zostaną udostępnione różnym użytkownikom, włączając w to:

• analityków i programistów, którzy użyją tych informacji do zaprojektowania odpowiednich kontroli zabezpieczeń,

• wewnętrznych i zewnętrznych rewidentów, którzy badają środki zabezpieczające system,

• menedżerów podejmujących decyzje o właściwościach środków zabezpieczających.

W tej części musi być opisana natura wrażliwości i ważności informacji. Taki opis musi zawierać informacje o prawie, regulacjach i zasadach, które mają wpływ na system, a także ogólny opis wrażliwości danych, co przedstawiono poniżej.

Prawo, regulacje i zasady mające wpływ na system

Umieść tu listę wszystkich praw, regulacji i zasad, które ustanawiają konkretne wymagania dotyczące poufności, integralności i dostępności informacji i danych w systemie.

Ogólny opis wrażliwości

Zarówno informacje, jak i systemy informatyczne mają różne cykle życia. Bardzo ważne jest zbadanie stopnia wrażliwości informacji przez rozważenie wymagań dotyczących dostępności, integralności i poufności informacji. Taki proces powinien odbywać się na początku cyklu życia systemu informatycznego, a następnie powtarzać się w czasie każdego etapu cyklu.

Takie zbadanie wymagań dotyczące zabezpieczeń we wczesnej fazie cyklu powoduje uniknięcie kosztownego, wstecznego procesu wprowadzania zabezpieczeń. Jednakże takie wymagania mogą zostać wprowadzone w dowolnym etapie. Celem tej części jest przegląd wymagań systemu pod względem potrzeb związanych z dostępnością, integralnością i poufnością. Wykonując tę analizę, ustalamy wrażliwość systemu, która jest jednym z głównych czynników w zarządzaniu ryzykiem. System może wymagać zabezpieczeń z poniższych przyczyn:

• poufność — system zawiera informacje, które wymagają ochrony przed nieautoryzowanym dostępem,

• integralność — system zawiera informacje, które wymagają ochrony przed nieautoryzowaną, nieoczekiwaną lub przypadkową modyfikacją,

• dostępność — system zawiera informacje lub zapewnia usługi, które muszą być dostępne w określonym czasie w celu spełnienia wymagań firmy lub uniknięcia poważnych strat.

Należy tu ogólnie opisać informacje obsługiwane przez system, a także konieczność wprowadzenia środków ochronnych. Te informacje muszą się odnosić do wszystkich trzech podstawowych wymagań — dostępności, integralności i poufności. Dołącz tu ocenę szacowanego ryzyka oraz wielkość strat spowodowanych przez utratę, niewłaściwe użycie, nieautoryzowany dostęp lub modyfikację informacji w systemie. Opisz także szczegółowo ten wpływ na koszty, niemożność wykonania obowiązkowych funkcji, czas itp. Dla każdej z trzech kategorii wskaż, czy wymagania dotyczące zabezpieczeń są:

• wysokie, mające krytyczne znaczenie dla systemu,

• średnie, o wysokim znaczeniu, ale niekoniecznie znajdujące się na szczycie listy priorytetów organizacji,

• niskie, gdzie wymagany jest minimalny poziom zabezpieczeń, niższy niż w powyższych dwóch kategoriach.

Kontrola kierownicza

W tej części należy opisać środki kontroli kierowniczej (mające miejsce lub zaplanowane), które mają spełniać wymagania głównej aplikacji lub systemu ogólnego wsparcia pod względem zabezpieczeń. Kontrola kierownicza koncentruje się na zarządzaniu systemem zabezpieczeń komputerów i zarządzaniu ryzykiem systemu. Typy środków kontroli powinny być zgodne z potrzebami ochrony głównej aplikacji lub systemu ogólnego wsparcia. Aby pomóc czytelnikowi, poniżej zamieszczono krótkie wyjaśnienie różnych środków kontroli kierowniczej.

Ocena i zarządzanie ryzykiem

Metody używane do zbadania natury i poziomu ryzyka dla systemu powinny obejmować rozważenie głównych czynników w zarządzaniu ryzykiem — wartości systemu lub aplikacji, zagrożeń, słabych stron oraz skuteczności obecnych i proponowanych środków zabezpieczających. Opis każdej używanej metody powinien mieć długość co najmniej jednego akapitu. Na przykład, czy wybrana metodologia oceny ryzyka identyfikuje zagrożenia, słabości i dodatkowe środki zabezpieczające wymagane do minimalizacji lub wyeliminowania wpływu tych zagrożeń i słabych stron na system i jego zasoby? Nie zapomnij o wstawieniu daty wykonania oceny ryzyka systemu. Wyjaśnij, jak zidentyfikowane niebezpieczeństwa odnoszą się do wymagań systemowych dotyczących dostępności, integralności i poufności.

Jeśli dla danego systemu nie wykonano oceny ryzyka, należy dołączyć datę (miesiąc i rok) zaplanowanego wykonania takiej analizy. Jeśli ocena ryzyka jest starsza niż trzy lata lub w systemie dokonano znaczących zmian, należy dołączyć docelową datę (miesiąc i rok) dokonania nowej oceny ryzyka lub zaktualizowania ostatniej. Taka analiza powinna być ciągłym procesem, tak aby identyfikowano nowe zagrożenia i słabe strony, a także wdrożono odpowiednie środki zabezpieczające.

Przegląd środków kontroli zabezpieczeń

Należy tu opisać typ i wyniki przeglądów, jakie zostały wykonane w ciągu ostatnich trzech lat w systemie ogólnego wsparcia lub głównej aplikacji. Dołącz informacje o ostatniej niezależnej kontroli systemu, a także o osobie, która ją przeprowadzała. Omów tutaj wyniki kontroli oraz rekomendacje, a także załącz informacje dotyczące naprawienia nieprawidłowości lub zastosowania się do zaleceń. W tej części należy także wskazać, czy przeprowadzono zewnętrzną inspekcję lub przegląd systemu.

Przeglądy, oceny i badania zabezpieczeń systemu mogą być przeprowadzane przez zewnętrzne lub wewnętrzne organizacje i grupy. Takie badania obejmują przeglądy wykonywane w biurze przez specjalistów od fizycznych zabezpieczeń z innych oddziałów organizacji, inspekcje systemu lub program kontroli zabezpieczeń przeprowadzany przez współpracujące firmy. Takie kontrole mogą badać bezpieczeństwo całego systemu lub jego logicznego segmentu albo podsystemu. Jeśli takie badanie było dokładne, opis systemu i wyniki badania oraz rekomendacje można potraktować jako niezależną kontrolę, która dostarcza informacji pomocnych w ocenie ryzyka i zarządzaniu. Jeśli wykonywano inne rodzaje badań zabezpieczeń, należy dołączyć informacje o osobach, które je wykonywały, czasie i celu badania, wynikach oraz czynnościach wykonywanych w efekcie badania.

Przegląd lub inspekcja powinna być niezależna od menedżera odpowiedzialnego za aplikację główną lub system ogólnego wsparcia. Niezależne inspekcje mogą być wewnętrzne lub zewnętrzne, ale powinny być przeprowadzane przez osobę lub organizację, która nie cechuje się żadnymi osobistymi lub zewnętrznymi czynnikami, które mogłyby wpłynąć na jej ocenę (na przykład jeśli są to osoby, które zaprojektowały badany system). W przypadku niektórych systemów wysokiego ryzyka, związanych z szybko zmieniającą się technologią, trzy lata przerwy między badaniami mogą być zbyt długim okresem; w takim przypadku kontrole powinny być przeprowadzane częściej. Celem takich przeglądów jest weryfikacja, czy wybrane i zainstalowane środki kontroli zapewniają poziom zabezpieczeń zgodny z akceptowalnym poziomem ryzyka dla systemu. Takie oszacowanie poziomu ryzyka musi odnosić się do wymagań systemu pod względem poufności, integralności i dostępności, a także brać pod uwagę zidentyfikowane zagrożenia.

Bezpieczeństwo systemu może degradować się w czasie ze względu na zmiany technologiczne, rozwój systemu oraz zmiany w personelu i procedurach. Okresowe przeglądy gwarantują, iż kontrole kierownicze, operacyjne, ludzkie i techniczne funkcjonują skutecznie i zapewniają właściwy poziom zabezpieczeń.

Typ i rygor przeglądów lub inspekcji powinien odpowiadać akceptowalnemu poziomowi ryzyka, który został ustalony przez zasady systemu; należy także wziąć pod uwagę prawdopodobieństwo poznania użytecznych informacji, które pomogą zwiększyć bezpieczeństwo. Narzędzia techniczne, takie jak skanery antywirusowe, programy do oceny słabych stron (które wyszukują znane dziury w zabezpieczeniach, błędy w konfiguracji oraz sprawdzają fakt zainstalowania najnowszych poprawek dla oprogramowania i sprzętu) oraz próby penetracji systemu mogą pomóc w ciągłym procesie badania środków zabezpieczających system. Takie narzędzia nie mogą jednak zastąpić formalnej kontroli kierownictwa, którą należy przeprowadzać co najmniej raz na trzy lata.

Zasady zachowania

Do załącznika dokumentu należy dodać zasady zachowania dla systemu ogólnego wsparcia lub głównej aplikacji. Z kolei w tej części należy umieścić odnośnik do tego załącznika lub przedstawić zasady zachowania. Dla każdego systemu należy stworzyć odrębny zestaw zasad zachowania. Bezpieczeństwo wymagane przez te zasady jest wystarczająco surowe, aby zapewnić odpowiedni poziom zabezpieczeń dla systemu i przechowywanych przez niego informacji. W czasie ustalania zasad zachowania jako podstawę należy wykorzystać akceptowalny poziom ryzyka. Takie zasady powinny jasno przedstawiać odpowiedzialność i oczekiwane zachowanie wszystkich osób, które uzyskują dostęp do systemu. Należy w nich zawrzeć informacje o konsekwencjach niewłaściwego zachowania lub nieprzestrzegania zasad, które powinny mieć formę pisemną i stanowić podstawę szkoleń dotyczących bezpieczeństwa.

Zasady zachowania powinny obejmować również wymagane limity połączeń z innymi systemami oraz definiować priorytety udostępniania i przywracania usług. Powinny omawiać również takie kwestie, jak praca w domu, dostęp przy pomocy łączy telefonicznych, połączenie z Internetem, korzystanie z zastrzeżonych materiałów, nieoficjalne wykorzystanie mienia państwowego, przydział i ograniczenia przywilejów systemowych oraz tworzenie poszczególnych kont. Zasady powinny odzwierciedlać środki administracyjnej i technicznej kontroli bezpieczeństwa systemu. Na przykład zasady dotyczące haseł powinny być zgodne z technicznymi cechami systemu dotyczącymi obsługi haseł. Mogą również obejmować ograniczenia modyfikacji informacji, przeszukiwania baz danych oraz ujawniania informacji. Zasady zachowania mogą być wymuszone przez sankcje administracyjne związane bezpośrednio z systemem (na przykład utrata przywilejów w systemie) lub ogólniejsze sankcje, które są stosowane w przypadku naruszenia innych reguł postępowania.

Zasady zachowania powinny być udostępnione wszystkim użytkownikom przed uzyskaniem dostępu do systemu. Zaleca się, aby zasady zawierały stronę z podpisami, na której użytkownik musi je zaakceptować.

Planowanie zabezpieczeń w cyklu życia

Chociaż plan zabezpieczeń komputera może być utworzony w dowolnym punkcie cyklu życia systemu komputerowego, zalecane jest utworzenie takiego planu na samym początku. Stwierdzono, iż w niektórych przypadkach system może być jednocześnie w wielu fazach cyklu życia. Dla przykładu duży system do zarządzania personelem może być w fazie operacyjnej, podczas gdy starszy podsystem wprowadzania danych może być właśnie zastępowany przez nowy, dystrybuowany system z interaktywnym interfejsem użytkownika. W takim przypadku fazy cyklu życia tego systemu to: faza usuwania (dane i urządzenia) związana z wymianą starego systemu transakcji, faza inicjacji i przejęcia powiązana z wprowadzeniem nowego systemu interaktywnego oraz faza działania i obsługi dla całego systemu.

W tej części należy ustalić fazę (fazy) cyklu życia systemu lub jego części. Należy także zbadać, jak stosowano zabezpieczenia w poszczególnych fazach cyklu. Poniżej przedstawiono opis wszystkich faz cyklu życia, zawierający także pytania, które mogą pomóc czytelnikowi w identyfikacji zastosowanych zabezpieczeń w danej fazie cyklu życia głównej aplikacji lub systemu ogólnego wsparcia. Istnieje wiele modeli cyklu życia systemu IT, ale większość z nich zawiera pięć podstawowych faz: inicjacja, rozwój i przejęcie, implementacja, działanie oraz usuwanie.

Faza inicjacji

W czasie fazy inicjacji przedstawiane są potrzeby dotyczące systemu oraz tworzona jest jego dokumentacja. Można w niej wykonać ocenę wrażliwości samego systemu oraz informacji, jakie będą na nim przetwarzane. Jeśli system lub jego część znajduje się w fazie inicjacji, należy umieścić odnośnik do oceny wrażliwości znajdującej się w części Wrażliwość przechowywanych informacji.

Faza rozwoju i przejęcia

W czasie tej fazy system jest projektowany, kupowany, programowany lub tworzony. Często składa się ona z innych zdefiniowanych cykli, takich jak cykl tworzenia systemu lub cykl przejęcia.

W pierwszej części fazy rozwoju i przejęcia wymagania wobec zabezpieczeń powinny być tworzone w tym samym czasie, co definiowanie wymagań systemu przez planistów. Te wymagania mogą być wyrażone w postaci funkcji technicznych (na przykład kontrola dostępu), zapewnień (na przykład system sprawdza w tle obecność twórców systemu) lub zasad operacyjnych (na przykład szkolenia lub zwiększenie świadomości). Jeśli system lub jego część znajduje się w tej fazie, należy dołączyć ogólny opis wszystkich używanych specyfikacji oraz informację o tym, czy są stosowane. Należy też odpowiedzieć na następujące pytania.

• Czy w czasie projektowania systemu zidentyfikowano wymagania dotyczące bezpieczeństwa?

• Czy przed dostarczeniem systemu utworzono odpowiednie kontrole zabezpieczeń wraz z powiązanymi procedurami badania i testowania?

• Czy dokumenty ofertowe (na przykład zapytanie ofertowe) zawierały wymagania dotyczące zabezpieczeń oraz procedur badawczych i testowych?

• Czy te wymagania umożliwiają aktualizację w razie pojawienia się nowych zagrożeń i słabych punktów oraz w przypadku wdrożenia nowych technologii?

• Jeśli zakupiono komercyjną aplikację lub aplikacja zawiera typowe komercyjne programy, to czy zidentyfikowano i dołączono do specyfikacji przejęcia ich wymagania w zakresie zabezpieczeń?

Faza implementacji

W fazie implementacji powinny zostać skonfigurowane i włączone funkcje zabezpieczeń systemu. Kolejnym krokiem jest przetestowanie i zainstalowanie systemu, który następnie otrzymuje autoryzację działania (opis tego wymogu znajdziesz w części Autoryzacja działania). Przed rozpoczęciem działania systemu należy wykonać przegląd projektu oraz testy systemowe w celu upewnienia się, czy spełnia on specyfikacje zabezpieczeń. Oprócz tego, jeśli dodano nowe środki kontroli do aplikacji lub systemu wsparcia, obowiązkowe jest przeprowadzenie dodatkowych testów tychże środków. Dzięki temu mamy pewność, iż nowe środki kontroli są zgodne ze specyfikacjami zabezpieczeń oraz nie powodują konfliktów lub wyłączenia już istniejących środków. Wyniki przeglądów projektu oraz testów systemowych powinny być w pełni udokumentowane, aktualizowane w czasie wykonywania dodatkowych testów lub przeglądów, a także zachowane w oficjalnej dokumentacji organizacji.

Jeśli system lub jego część znajduje się w fazie implementacji, zapisz kto i kiedy przeprowadzał przegląd projektu oraz testy systemowe. Dodaj także informacje o dodatkowych przeglądach projektu i testach, które zostały wykonane dla nowych środków kontroli po zakończeniu testów niezbędnych do wstępnej akceptacji. Zaznacz także, czy dokumentacja tych przeglądów i testów była aktualna oraz zachowana w dokumentach firmy.

Faza działania i obsługi

W czasie tej fazy system wykonuje swoje zadania. System jest prawie cały czas modyfikowany przez dodawanie nowych urządzeń i programów, a także ze względu na wiele innych zdarzeń. Jeśli system przechodzi modyfikacje, należy ustalić fazę cyklu życia, w jakiej znajdują się te modyfikacje, a następnie opisać czynności zabezpieczające, który zostały przeprowadzone lub zaplanowane dla tej części systemu. W przypadku systemu w fazie działania i obsługi plan zabezpieczeń dokumentuje czynności zabezpieczające. W odpowiednich częściach planu zabezpieczeń należy opisać poniższe, najważniejsze elementy.

• Administracja i czynności zabezpieczające. Działanie systemu wymaga wielu czynności zabezpieczających. Przykładem może być archiwizacja, prowadzenie szkoleń, zarządzanie kluczami szyfrowania, administracja użytkownikami i przywilejami dostępu oraz aktualizacja programów zabezpieczających.

• Zapewnienie działania. Ta czynność jest związana z badaniem, czy system jest obsługiwany zgodnie z obecnymi wymogami zabezpieczeń. Obejmuje to zarówno czynności wykonywane przez osoby, które obsługują lub wykorzystują system, jak i działanie środków kontroli technicznej. Przedstawiciel kierownictwa musi pisemnie autoryzować użycie systemu w oparciu o wdrożony plan zabezpieczeń. (Opis tego wymagania znajdziesz w części Autoryzacja działania).

• Kontrola i monitorowanie. Organizacje wykorzystują dwie podstawowe metody, aby zapewnić działanie systemu — kontrole systemu i monitorowanie. Oba te określenia są swobodnie używane przez osoby zajmujące się zabezpieczeniami; ich znaczenie często się pokrywa. Kontrola systemu to jednorazowe lub okresowe zdarzenie, polegające na zbadaniu zabezpieczeń. Monitorowanie odnosi się do ciągłego procesu, który bada zarówno system, jak i użytkowników. Ogólnie mówiąc, jeśli jakieś zdarzenie występuje w czasie rzeczywistym, to można zakwalifikować je do kategorii monitorowania.

Faza usuwania

Faza usuwania w cyklu życiu systemu IT jest związana z pozbyciem się informacji, osprzętu i oprogramowania. Jeśli system lub jego część znajduje się w końcowej fazie cyklu życiu, należy w tej części opisać sposób usunięcia występujących w nim elementów.

• Informacje. Informacje mogą być przeniesione do innego systemu, zarchiwizowane, usunięte lub zniszczone. W czasie archiwizacji informacji należy zastanowić się nad sposobem ich odzyskania w przyszłości. Choć dane w postaci elektronicznej są łatwiejsze do zapisania, użyta do tego celu technologia może nie być dostępna w przyszłości. Należy się także przygotować do ewentualnego przyszłego wykorzystania zaszyfrowanych danych — konieczne jest zapewnienie długoterminowego przechowania kluczy szyfrowych. W czasie demontażu systemów IT konieczne jest również wzięcie pod uwagę wymagań prawnych dotyczących usuwanych danych.

• Czyszczenie nośników. Usunięcie informacji z nośnika (takiego jak dysk twardy czy taśma) jest nazywane czyszczeniem. Różne sposoby czyszczenia zapewniają konkretne poziomy ochrony. Należy odróżnić wykasowanie informacji (wtedy dane nie mogą być ponownie odczytane za pomocą typowych poleceń) od zniszczenia (kiedy dane nie mogą być przywrócone nawet przy użyciu specjalnych metod). Istnieją trzy główne metody całkowitego zniszczenia danych — nadpisanie, rozmagnesowanie (tylko w przypadku nośników magnetycznych) i fizyczne zniszczenie.

Autoryzacja działania

Określenie „autoryzacja działania” oznacza autoryzację kierownictwa, która pozwala systemowi na przetwarzanie informacji. Zmusza to menedżerów i pracowników technicznych do uzyskania jak najwyższego bezpieczeństwa, biorąc pod uwagę ograniczenia techniczne i operacyjne, a także wymogi misji. Przez autoryzację działania systemu menedżer akceptuje ryzyko z tym związane. Do tej części planu należy dołączyć datę autoryzacji oraz nazwisko i stanowisko menedżera. Jeśli nie uzyskano autoryzacji, należy podać nazwisko i stanowisko menedżera, który prosi o zgodę na działanie oraz datę tej prośby.

Zarówno osoba odpowiedzialna za bezpieczeństwo, jak i menedżer udzielający autoryzacji mają własne obowiązki związane z zabezpieczeniem systemu. Osoba odpowiedzialna za bezpieczeństwo jest bardziej związana z codziennymi operacjami systemu oraz kieruje, wykonuje i monitoruje zadania zabezpieczeń. Menedżer jest zwykle ogólnie odpowiedzialny za organizację obsługiwaną przez system. Autoryzacja nie jest decyzją, która powinna być podejmowana przez personel odpowiedzialny za zabezpieczenia. Formalizacja procesu autoryzacji systemu redukuje możliwość umieszczenia systemu w środowisku produkcyjnym przed przeprowadzeniem należnego przeglądu kierowniczego.

Autoryzacja kierownictwa musi opierać się o ocenę środków kontroli kierowniczej, operacyjnej i technicznej. Ponieważ plan zabezpieczeń powoduje powstanie wymogów zabezpieczeń systemu oraz dokumentuje kontrole zabezpieczeń w systemie, powinien stać się podstawą dla autoryzacji. Autoryzacja jest zwykle wspomagana przez badanie techniczne lub badanie zabezpieczeń, ocenę ryzyka, plan awaryjny oraz podpisane zasady zachowania.

Poniżej znajduje się lista środków kontroli zapewniających minimalne bezpieczeństwo, które muszą być wykonane przed udzieleniem autoryzacji działania. Poziom kontroli powinien być zgodny z poziomem wrażliwości zawartości systemu.

• Zakończenie badania technicznego oraz badania zabezpieczeń.

• Przeprowadzenie oceny ryzyka.

• Ustanowienie zasad zachowania oraz podpisanie ich przez użytkowników.

• Utworzenie i przetestowanie planu awaryjnego.

• Opracowanie, aktualizacja i przegląd planu zabezpieczeń.

• Sprawdzenie, czy system spełnia wszystkie prawa, przepisy, zasady i standardy.

• Sprawdzenie, czy zainstalowane i zaplanowane środki zabezpieczające są odpowiednie dla systemu.

• Ustalenie, czy zainstalowane środki zabezpieczające działają zgodnie z zamierzeniami.

Kontrola operacyjna

Począwszy od tej części aż do Kontroli technicznej, przedstawiane są dwa formaty i powiązane z nimi porady; pierwszy z nich dla aplikacji głównych, a drugi dla systemów ogólnego wsparcia. Jest to spowodowane faktem, iż istnieje poważna różnica między środkami kontroli dla aplikacji i systemów ogólnego wsparcia.

Aplikacja główna — kontrola operacyjna

Kontrola operacyjna odnosi się do metod zabezpieczeń, które koncentrują się na mechanizmach wdrażanych i wykonywanych przez ludzi, a nie przez systemy. Te środki kontroli są stosowane w celu poprawy bezpieczeństwa konkretnego systemu (lub grupy systemów) i często wymagają doświadczenia technicznego lub specjalistycznego. Takie środki często opierają się również o działania kadry zarządzającej oraz kontrolę techniczną.

W tej części należy opisać środki kontroli operacyjnej (istniejące lub zaplanowane), które mają spełnić wymogi bezpieczeństwa głównej aplikacji.

Bezpieczeństwo personelu

Największe zagrożenie i szkody powodują w systemie celowe i przypadkowe działania użytkowników. O wiele za często systemy przeżywają awarie, uszkodzenia, utratę danych lub inne groźne sytuacje, spowodowane często przez osoby, które mają prawo do korzystania lub obsługi systemu (na przykład programista, który wprowadza jedną drobną zmianę, a następnie instaluje program w działającym środowisku bez przeprowadzenia testów).

W tej części należy zamieścić szczegółowe informacje o poniższych środkach chroniących przed działaniami pracowników. Zaleca się dołączenie większości z tych środków do zasad zachowania. Jeśli to zrobisz, umieść informację o tym w odpowiedniej części.

• Czy wszystkie stanowiska zostały zbadane pod kątem poziomu wrażliwości? Jeśli jeszcze tak się nie stało, należy podać zaplanowaną datę zakończenia analizy wrażliwości stanowisk.

• Czy dołączono oświadczenie, według którego wszyscy użytkownicy zostali przeszkoleni odpowiednio do zajmowanego stanowiska? Jeśli nie, należy podać zaplanowane daty przeprowadzenia wszystkich szkoleń.

• Czy przed przeprowadzeniem szkolenia dla użytkowników opisano warunki, na jakich te osoby mogą uzyskać dostęp do systemu? Należy też opisać środki kontroli użyte do zminimalizowania powiązanego z tym ryzyka.

• Czy uprawnienia dostępu użytkowników do plików danych, funkcji przetwarzania danych i peryferii oraz typ dostępu (na przykład odczyt, zapis, wykonanie, usunięcie) zostały ustawione na minimalny poziom wymagany do wykonania zadania?

• Czy krytyczne funkcje zostały rozdzielone pomiędzy różne osoby (podział obowiązków), dzięki czemu żadna nie ma wystarczających uprawnień lub informacji, które mogłyby doprowadzić do niebezpiecznego zachowania?

• Czy istnieje system zamawiania, zakładania, wydawania i zamykania kont użytkowników?

• Jakie mechanizmy zastosowano, aby użytkownicy byli odpowiedzialni za swoje postępowanie?

• Jakie są procedury przyjaznego i nieprzyjaznego zakończenia procesu?

Ochrona fizyczna i środowiskowa

Środki kontroli zabezpieczeń fizycznych i środowiskowych są wdrażane w celu zabezpieczenia struktur przechowujących zasoby systemowe i sam system oraz struktur używanych do obsługi jego operacji. Program zabezpieczeń organizacji powinien obejmować siedem następujących kwestii.

Wyjaśnienie bezpieczeństwa fizycznego i środowiskowego

W tej części należy krótko opisać środki kontroli fizycznej i środowiskowej dla głównej aplikacji.

• Kontrola dostępu. Środki kontroli fizycznego dostępu ograniczają wejście i wyjście pracowników (a także ruch urządzeń i nośników danych) z danego obszaru, takiego jak budynek biurowy, biuro, centrum danych lub pokój zawierający serwer sieci lokalnej LAN. Kontrola dostępu nie powinna stosować się tylko do pomieszczeń zawierających urządzenia systemowe, ale także musi obejmować miejsca z okablowaniem użytym do połączenia elementów systemu, usługami obsługi (na przykład zasilanie), nośnikami zapasowymi, a także z innymi elementami, które są wymagane do fizycznego działania systemu. Bardzo ważne jest zbadanie skuteczności kontroli fizycznego dostępu na poszczególnych obszarach zarówno w godzinach roboczych, jak i poza nimi, kiedy w danym miejscu może nie być nikogo.

• Czynniki ryzyka pożarowego. Pożary budynków są wyjątkowym zagrożeniem dla bezpieczeństwa ze względu na możliwość całkowitego zniszczenia urządzeń i danych, ryzyko dla ludzkiego życia, a także trwałość zniszczeń. Dym, trujące gazy i wysoka wilgotność mogą zniszczyć systemy w całym budynku. Dlatego też konieczne jest zbadanie bezpieczeństwa pożarowego budynków, w których są umieszczone.

• Awaria systemów obsługi. Systemy i obsługujące je ludzie wymagają określonego środowiska pracy, które można kontrolować w pewnym zakresie. Awaria zasilania, systemu grzewczego i klimatyzacji, kanalizacji i innych systemów zwykle powoduje przerwanie funkcjonowania usługi oraz może uszkodzić sprzęt. Z tego powodu organizacje powinny upewnić się, czy te systemy, włączając w to ich różne aspekty, działają poprawnie.

• Zawalenie się budynku. Organizacje powinny zdawać sobie sprawę, iż budynek może zawalić się pod obciążeniem większym, niż zostało to przewidziane. Najczęściej dzieje się tak z powodu trzęsienia ziemi, obciążenia dachu śniegiem, eksplozji, która niszczy elementy nośne, lub pożaru osłabiającego strukturę budynku.

• Awarie kanalizacji. Chociaż takie awarie nie zdarzają się codzienne, mogą spowodować poważne skutki. Firma powinna poznać położenie rur kanalizacyjnych, które mogą zagrozić urządzeniom systemowym, oraz podjąć odpowiednie kroki w celu przeciwdziałania ryzyku (na przykład przeniesienie urządzeń lub rur kanalizacyjnych, a także odnalezienie zaworów odcinających).

• Przechwycenie danych. W zależności od typu danych przetwarzanych przez system może wystąpić znaczące ryzyko w przypadku przechwycenia. Organizacje powinny znać trzy sposoby przechwycenia informacji, a są nimi: bezpośrednia obserwacja, przechwycenie transmisji danych oraz przechwycenie elektromagnetyczne.

• Systemy mobilne i przenośne. Analizy i zarządzanie ryzykiem muszą zwykle zostać zmodyfikowane, jeśli system jest zainstalowany na wózku lub jest systemem przenośnym, na przykład laptopem. System na wózku jest obciążony takim samym ryzykiem jak wózek, włączając w to wypadki i kradzież, a także ryzyko regionalne i lokalne. Organizacje powinny:

• przechowywać w bezpiecznym miejscu nieużywane komputery przenośne,

• szyfrować pliki danych na nośnikach, jeśli jest to opłacalne; jest to sposób pozwalający na uchronienie informacji w przypadku kradzieży lub zagubienia laptopa.

Kontrola produkcyjna oraz kontrola wejścia i wyjścia

W tej części należy przedstawić opis stosowanych procedur, które obsługują działanie aplikacji. Poniżej znajduje się kilka przykładów tematów, które powinny zostać omówione.

• Obsługa użytkowników. Czy istnieje komórka lub grupa ludzi zajmująca się pomocą dla użytkowników, która potrafi udzielić porady lub zareagować na naruszenie bezpieczeństwa w określonym terminie? Czy istnieją procedury, takie jak opisane poniżej, które dokumentują sposób rozpoznawania, rozwiązywania i raportowania takich zdarzeń lub problemów? Dodatkowe pytania znajdują się w części Możliwość zgłaszania wypadków naruszenia bezpieczeństwa.

• Procedury, dzięki którym nieautoryzowane osoby nie mogą odczytać, skopiować, zmienić ani ukraść wydrukowanych lub elektronicznych informacji.

• Procedury, dzięki którym tylko autoryzowani użytkownicy mogą pobrać, odebrać lub dostarczyć informacje wejściowe i wyjściowe oraz nośniki.

• Śledzenie odbioru ważnych danych wejściowych i wyjściowych.

• Procedury ograniczające dostęp do urządzeń wyjściowych.

• Procedury i środki kontroli przy transporcie lub wysyłce nośników i wydruków.

• Zewnętrzny lub wewnętrzny system znakowania wrażliwości informacji.

• Zewnętrzny system znakowania z instrukcjami dotyczącymi sposobu traktowania (na przykład identyfikatory dziennika lub inwentarza, kontrolowany dostęp, specjalne instrukcje dotyczące przechowywania, data wysłania lub zniszczenia).

• Kontrola śladów w celu zarządzania inwentarzem.

• Procedury i środki kontroli fizycznej i środowiskowej ochrony miejsca przechowywania nośników i biblioteki.

• Procedury czyszczenia nośników elektronicznych w celu ponownego użycia (na przykład nadpisanie lub rozmagnesowanie nośników elektronicznych).

• Procedury kontrolowanego przechowywania, obsługi i zniszczenia uszkodzonych nośników lub takich, które nie mogą być wyczyszczone w celu ponownego użycia.

• Procedury fizycznego niszczenia wydruków, które nie są już potrzebne.

Planowanie awaryjne

Wymagane są procedury, które pozwolą organizacji na kontynuację podstawowych funkcji, jeśli przerwane zostanie działanie systemu IT. Takie procedury (plany zapasowe, plany w przypadku przerwania funkcjonowania firmy oraz plany ciągłości działania) powinny zostać skoordynowane z planami archiwizacji, planami na wypadek sytuacji awaryjnej oraz planami przywracania wszystkich systemów ogólnego wsparcia, włączając w to sieci używane przez aplikację. Plany na wypadek sytuacji awaryjnej powinny zapewnić identyfikację połączonych systemów oraz koordynację planów na wypadek katastrofy.

Należy tu krótko opisać procedury (plan zapasowy), które należy wykonać, aby aplikacja kontynuowała działanie w przypadku niedostępności obsługujących ją systemów IT. Szczegółowe plany powinny być dołączone jako załącznik. W tym opisie należy także zamieścić odpowiedzi na poniższe pytania.

• Czy istnieją przetestowane plany zapasowe, które zapewnią działanie funkcji krytycznych dla organizacji w przypadku wystąpienia groźnego zdarzenia?

• Czy istnieją przetestowane plany przywrócenia po katastrofie wszystkich obsługujących systemów IT i sieci?

• Czy formalne procedury ratunkowe zostały wysłane lub rozmieszczone w postaci pisemnej tak, aby umożliwić ich wykonanie w sytuacji awaryjnej?

• Jak często są testowane plany awaryjne na wypadek katastrofy i ratunkowe?

• zy wszyscy pracownicy zostali przeszkoleni w zakresie swoich ról i odpowiedzialności pod względem planów awaryjnych, ratunkowych i na wypadek katastrofy?

Należy także dołączyć opis następujących środków kontroli:

• wszystkie umowy na obsługę archiwizacji (na przykład kontrakt z komercyjnym dostawcą usług),

• udokumentowane procedury archiwizacji, włączając ich częstotliwość (codziennie, tygodniowo, miesięcznie) oraz zakres (pełna kopia awaryjna, kopia przyrostowa lub różnicowa),

• miejsce przechowywania kopii zapasowych (w biurze lub poza nim),

• liczba utrzymywanych generacji kopii zapasowych,

• zasięg procedur archiwizacji (na przykład, co jest archiwizowane).

Kontrola obsługi oprogramowania

Te środki kontroli są używane do monitorowania instalacji lub aktualizacji oprogramowania, aby upewnić się, czy aplikacje działają zgodnie z oczekiwaniami oraz w celu utworzenia historii zmian w oprogramowaniu. Dzięki temu można upewnić się, czy w systemie są zainstalowane tylko autoryzowane aplikacje. Takie środki kontroli mogą obejmować zasady konfiguracji oprogramowania, które wymagają zgody kierownictwa (ponowna autoryzacja działania) na modyfikacje, a także wymuszają dokumentację zmian. Inne środki kontroli obejmują programy i procedury używane do kontroli lub uniemożliwienia nielegalnego użycia programów typu shareware lub objętych prawami autorskimi. Procedury obsługi oprogramowania mogą również służyć do kontroli wersji i zarządzania zmianami lub konfiguracją. Poniższe pytania są przykładami kwestii, które powinny być poruszone w tej części.

• Czy oprogramowanie zostało napisane w firmie lub na zamówienie?

• Czy oprogramowanie należy do organizacji?

• Czy oprogramowanie zostało otrzymane z innego biura, ale należy ono do Twojej organizacji?

• Czy oprogramowanie jest produktem komercyjnym, objętym prawami autorskimi, lub typu shareware?

• Czy aplikacja jest produktem komercyjnym, objętym prawami autorskimi (lub typu shareware)? Czy zakupiono wystarczająco dużo licencji dla wszystkich systemów, na których będzie wykorzystywana ta aplikacja?

• Czy istnieje formalny proces kontroli zmian dla aplikacji; jeśli tak, czy wymaga on przetestowania i zatwierdzenia wszystkich zmian w oprogramowaniu, zanim zostanie ono wdrożone do użycia?

• Czy dane testowe były danymi rzeczywistymi, czy spreparowanymi?

• Czy wszystkie zmiany w oprogramowaniu są udokumentowane?

• Czy uaktywniono wszystkie „tylne drzwi” na wypadek awaryjnej naprawy danych?

• Czy wszystkie wyniki testów zostały udokumentowane?

• Czy zainstalowano wszystkie niezbędne poprawki?

• Czy zasady organizacji nie pozwalają na nielegalne użycie oprogramowania objętego prawami autorskimi lub typu shareware?

• Czy wykonywane są okresowe kontrole komputerów użytkowników pod kątem instalacji tylko legalnych kopii programów, na które posiadana jest licencja?

• Jakie programy i procedury są wykorzystywane w celu zabezpieczenia przed nielegalnym użyciem oprogramowania?

• Czy istnieje zarządzanie gwarancjami na oprogramowanie w celu minimalizacji kosztu aktualizacji, uzyskania zwrotu kosztów lub wymiany wadliwych produktów?

Kontrola ważności i integralności danych

Środki kontroli integralności danych są stosowane w celu ochrony danych przed przypadkową lub celową zmianą albo zniszczeniem, a także, by zagwarantować użytkownikowi, iż informacje spełniają oczekiwania pod względem jakości i nie zostały zmienione. Środki kontroli ważności odnoszą się do testów i badań wykonywanych w celu ustalenia zgodności ze specyfikacjami i wymogami zabezpieczeń.

W tej części należy opisać wszelkie środki kontroli, które gwarantują użytkownikowi, iż informacje nie zostały zmienione, a sam system funkcjonuje w oczekiwany sposób. Poniższe pytania to przykłady kilku środków kontroli, które zastosujemy w tej kategorii.

• Czy zainstalowano oprogramowanie do wykrywania i eliminacji wirusów? Jeśli tak, to czy istnieją procedury:

• aktualizacji plików zawierających definicje wirusów,

• automatycznego lub ręcznego skanowania antywirusowego (automatyczne skanowanie podczas logowania do sieci, automatyczne logowanie po włączeniu zasilania stacji roboczej i serwera, automatyczne skanowanie po włożeniu dyskietki, automatyczne skanowanie po pobraniu danych z niezabezpieczonego źródła, na przykład z Internetu, skanowanie w poszukiwaniu wirusów w makrach),

• usuwania wirusów i tworzenia raportów.

• Czy stosowane są przez system procedury kontrolne — na przykład sumy kontrolne, sumy hash i liczniki rekordów? Należy dołączyć opis działań podjętych w celu usunięcia wszelkich niezgodności.

• Czy używane są narzędzia do sprawdzania i łamania haseł?

• Czy aplikacje korzystają z programów do weryfikacji integralności w celu wyszukania dowodów na manipulację danymi, błędów oraz pominięć? Te techniki obejmują kontrolę i potwierdzanie konsystencji i sensowności danych w czasie wprowadzania i przetwarzania. Należy opisać używane w systemie środki kontroli integralności.

• Czy w systemie zainstalowano narzędzia do wykrywania włamania? Należy opisać używane narzędzia, typ wykrywanych i raportowanych procesów, a także procedury traktowania takich włamań (należy umieścić odnośnik do części Kontrola produkcyjna oraz kontrola wejścia i wyjścia, jeśli takie procedury zostały już opisane).

• Czy używana jest funkcja monitorowania wydajności systemu w celu analizy dzienników wydajności systemu w czasie rzeczywistym, wyszukiwania problemów z dostępnością (włączając w to aktywne ataki) oraz awarii lub spowolnienia pracy systemu i sieci.

• Czy w systemie są wykonywane testy penetracji? Jeśli tak, to jakie procedury są stosowane w celu zapewnienia prawidłowego wykonywania takich testów?

• Czy aplikacja używa funkcji uwierzytelniania wiadomości w celu upewnienia się, czy nadawca wiadomości jest znany, a wiadomość nie została zmieniona w czasie transmisji? Należy zaznaczyć, czy procedura uwierzytelniania została sprawdzona pod kątem stosowności dla systemu. Jeśli tak, opisać metodologię.

Dokumentacja

Dokumentacja jest środkiem kontroli zabezpieczeń, używanym do wyjaśnienia sposobu użycia urządzeń lub oprogramowania; formalizuje również procedury zabezpieczeń i działania dla danego systemu. Dokumentacja systemu obejmuje opisy sprzętu i programów, zasady, standardy, procedury oraz akceptacje odnoszące się do bezpieczeństwa zautomatyzowanego systemu informatycznego (aplikacja oraz system obsługi, na którym jest ona wykonywana). Należy tu także dołączyć opis procedur archiwizacji oraz planu zapasowego.

Dokumentacja powinna zostać skoordynowana z menedżerem systemu ogólnego wsparcia lub z menedżerem sieci, aby upewnić się, czy istnieje właściwa dokumentacja aplikacji i instalacji w celu zapewnienia ciągłości działania. Należy tu zamieścić listę istniejącej dokumentacji aplikacji.

Znajomość zabezpieczeń i szkolenia

Każdy użytkownik musi być wprowadzony w akceptowane zasady zachowania dla aplikacji, zanim uzyska dostęp do systemu. W czasie programu szkoleń należy także poinformować użytkowników o sposobie uzyskania pomocy w przypadku wystąpienia trudności w czasie używania systemu. Konieczne jest także wyjaśnienie procedur dotyczących zgłaszania przypadków naruszenia zabezpieczeń.

Dostęp dla członków publicznych powinien być ograniczony za pomocą środków kontroli w aplikacji; należy przeprowadzić szkolenie w zakresie tej kontroli, choć może się to ograniczyć tylko do odpowiedniego zawiadomienia w momencie uzyskiwania dostępu.

W tej części planu należy zamieścić następujące informacje:

• program świadomości aplikacji (plakaty, foldery i inne),

• typ i częstotliwość szkoleń w zakresie obsługi danej aplikacji, przeprowadzanych dla pracowników oraz osób współpracujących (seminaria, warsztaty, zajęcia w klasach, grupy dyskusyjne, odgrywanie ról oraz szkolenie w trakcie pracy),

• typ i częstotliwość szkoleń w zakresie obsługi danego systemu ogólnego wsparcia, przeprowadzanych dla pracowników oraz osób współpracujących (seminaria, warsztaty, zajęcia w klasach, grupy dyskusyjne, odgrywanie ról oraz szkolenie w trakcie pracy),

• procedura sprawdzania, czy pracownicy i osoby współpracujące przeszły niezbędne szkolenia.

Aplikacja główna — kontrola techniczna

Kontrola techniczna koncentruje się na środkach kontroli zabezpieczeń stosowanych przez system komputerowy. Te środki mogą zapewnić zautomatyzowaną ochronę przed nieautoryzowanym dostępem lub niewłaściwym użyciem, umożliwiają wykrycie naruszeń zabezpieczeń, a także zaspokajają wymogi zabezpieczeń dla aplikacji i danych. Wdrożenie środków kontroli technicznej zawsze wymaga poważnych analiz operacyjnych oraz zachowania zgodności z zarządzaniem bezpieczeństwem w organizacji.

W tej części należy opisać środki kontroli technicznej (stosowane lub zaplanowane), które mają spełniać wymogi zabezpieczeń głównej aplikacji.

Identyfikacja i uwierzytelnianie

Identyfikacja i uwierzytelnianie jest techniczną metodą uniemożliwiania dostępu do systemu IT nieautoryzowanym osobom (lub nieautoryzowanym procesom). Kontrola dostępu zwykle wymaga możliwości identyfikacji i odróżniania użytkowników przez system. Dla przykładu kontrola dostępu jest często oparta o minimalne przywileje, co oznacza przyznanie użytkownikowi tylko takiego dostępu, jaki jest wymagany do wykonywania swoich obowiązków. Obsługa kont użytkowników wymaga często powiązania funkcji systemu IT z konkretnymi użytkownikami, co w efekcie stwarza konieczność identyfikacji użytkowników przez system.

Identyfikacja

Identyfikacja to sposób przedstawienia systemowi przez użytkownika swojej tożsamości. Najczęściej spotykaną formą identyfikacji jest identyfikator użytkownika.

W tej części planu należy krótko opisać sposób identyfikacji dostępu do systemu przez główną aplikację.

• Unikalna identyfikacja. Organizacja powinna wymagać od swoich użytkowników unikalnej identyfikacji, zanim uzyskają oni prawo do wykonywania jakichkolwiek operacji w systemie, chyba że anonimowość użytkowników lub inne kwestie nakazują inne postępowanie.

• Powiązania działań z użytkownikami. System powinien zarządzać wewnętrznie tożsamościami wszystkich aktywnych użytkowników, a także mieć możliwość powiązania działań z konkretnymi użytkownikami (zobacz sekcję Śledzenie śladów).

• Obsługa identyfikatorów użytkowników. Wszystkie identyfikatory użytkowników w organizacji powinny należeć do użytkowników autoryzowanych w danym momencie. Należy zapewnić aktualność informacji identyfikacyjnych przez dodawanie nowych użytkowników i usuwanie starych.

• Nieaktywne identyfikatory użytkowników. Identyfikatory użytkowników, które są nieaktywne w systemie przez określony czas (na przykład trzy miesiące) powinny być wyłączane.

Uwierzytelnianie

Uwierzytelnianie jest sposobem potwierdzania ważności własnej tożsamości użytkownika w systemie. Istnieją trzy sposoby uwierzytelniania tożsamości użytkownika, które mogą być stosowane oddzielnie lub razem: może to być coś, co użytkownik zna (coś tajnego — na przykład hasło, osobisty numer identyfikacyjny PIN lub klucz szyfrowy); coś, co należy do użytkownika (token — na przykład karta bankomatowa lub karta elektroniczna) lub coś, czym użytkownik jest (cechy biometryczne — na przykład próbka głosu, ręczne pismo lub odcisk palca).

W tej części należy opisać mechanizmy kontroli uwierzytelniania używane przez aplikację główną. Omawiamy je niżej.

• Opisz metodę uwierzytelniania użytkowników (hasło, token lub cechy biometryczne).

• Jeśli stosowany jest system haseł, podaj następujące informacje:

• dozwolony zestaw znaków,

• długość hasła (minimalna i maksymalna),

• okres upływu ważności hasła oraz sposób wymuszania jego zmiany,

• liczba niedozwolonych generacji starych haseł,

• procedury zmiany hasła,

• procedury obsługi zagubionych haseł,

• procedury obsługi naruszenia systemu haseł.

• Opisz procedury szkolenia użytkowników oraz użyte materiały.

• Wskaż częstotliwość zmiany haseł, opisz sposób wymuszenia zmiany hasła (na przykład przez program lub administratora systemu) oraz podaj osobę, która zmienia hasło (użytkownik, system lub administrator systemu).

• Opisz stosowane sposoby kontroli cech biometrycznych. Należy dołączyć opis sposobu implementacji tych sposobów w systemie.

• Opisz używane przez system środki kontroli tokenów oraz sposób ich implementacji. Należy odpowiedzieć na poniższe pytania.

• Czy wymagane są specjalne czytniki sprzętowe?

• Czy użytkownik musi podać unikalny osobisty numer identyfikacyjny (PIN)?

• Kto wybiera PIN, użytkownik czy administrator systemu?

• Czy token używa generatora haseł do utworzenia jednorazowego hasła?

• Czy do utworzenia hasła jest używany protokół typu „wezwanie-odpowiedź”?

• Opisz poziom wymuszania mechanizmu kontroli dostępu (sieć, system operacyjny lub aplikacja).

• Opisz sposób obsługi poszczególnych kont i kontroli śladów (na przykład, czy hasła są powiązane z identyfikatorem użytkownika, który jest przydzielony tylko dla jednej osoby) przez mechanizm kontroli dostępu.

• Opisz techniki własnego zabezpieczenia mechanizmu uwierzytelniania użytkownika (na przykład, czy hasła są przesyłane i przechowywane z użyciem jednokierunkowego szyfrowania tak, że nikt, włączając w to administratora, nie może odczytać haseł w czystym tekście; czy hasła są generowane automatycznie; czy hasła są porównywane ze słownikiem niedozwolonych haseł; czy hasła są szyfrowane w czasie przesyłania).

• Podaj liczbę nieudanych prób dostępu, jaka może wystąpić dla danego identyfikatora użytkownika lub miejsca dostępu (terminal lub port), a także opisz działania, jakie zostaną podjęte po przekroczeniu limitu.

• Opisz procedurę weryfikacji, czy zostały zmienione wszystkie domyślne hasła administratorów, które zostały ustawione przez system.

• Opisz procedury ograniczania skryptów dostępowych z dołączonym hasłem (na przykład, czy skrypty z dołączonym hasłem są zabronione lub dozwolone tylko dla aplikacji wsadowych).

• Opisz wszystkie zasady, które pozwalają na pominięcie wymagań dotyczących uwierzytelniania użytkownika, technologie „pojedynczego podpisu” (na przykład bezpośrednie połączenie dwóch komputerów, serwery uwierzytelniania, identyfikator „użytkownik do hosta” oraz identyfikatory grup użytkowników), a także wszystkie środki kontroli naruszenia uwierzytelniania.

Logiczna kontrola dostępu (Kontrola uwierzytelniania i dostępu)

Logiczna kontrola dostępu to mechanizmy systemowe używane do wskazania osoby (lub procesu), która ma uzyskać dostęp do konkretnego zasobu systemowego z odpowiadającymi mu uprawnieniami.

W tej części należy omówić środki kontroli, które są stosowane do autoryzacji lub ograniczenia działalności użytkowników lub personelu systemowego w ramach aplikacji. Opisz funkcje sprzętu lub oprogramowania, które zostały opracowane w celu umożliwienia tylko autoryzowanego dostępu do aplikacji lub wewnątrz niej, do ograniczenia działań użytkowników tylko do autoryzowanych transakcji i funkcji, a także do wykrywania nieautoryzowanych działań (na przykład listy kontroli dostępu ACL). Wykonaj też poniższe czynności.

• Opisz formalne zasady definiujące przywileje, które zostaną przyznane każdemu użytkownikowi lub klasie użytkowników. Należy zaznaczyć, czy te zasady są zgodne z ideą minimalnych przywilejów, co wymaga identyfikacji funkcji związanych z pracą użytkownika, ustalenia minimalnego zestawu przywilejów wymaganych do wykonania tych funkcji, a także ograniczenia użytkownika tylko do domeny z tymi przywilejami. Należy dołączyć tu procedury przyznawania dostępu nowym użytkownikom oraz te, które są stosowane w przypadku zmiany przez użytkownika roli lub pracy.

• Podaj, czy zasady obejmują oddzielenie wymuszenia obowiązków, aby uniemożliwić danej osobie dostęp lub ograniczyć ujawnienie informacji, które umożliwiłyby zabronione działania bez możliwości wykrycia.

• Opisz możliwość utworzenia przez aplikację listy kontroli dostępu lub zarejestrowania przez nią użytkowników oraz dostępnych dla nich typów dostępu.

• Wskaż, czy stosowana jest ręczna lista ACL.

• Zaznacz, czy oprogramowanie zabezpieczające pozwala właścicielom aplikacji na ograniczenie praw dostępu do aplikacji, danych i plików innym użytkownikom aplikacji, administratorowi systemu ogólnego wsparcia lub operatorom.

• Opisz sposób, w jaki ogranicza się użytkownikom dostęp do systemu operacyjnego, innych aplikacji lub innych zasobów systemowych, które nie są wymagane przy wykonywaniu przez nich swoich obowiązków.

• Podaj, jak często przeglądane są listy ACL w celu identyfikacji i usunięcia użytkowników, którzy opuścili organizację lub ich obowiązki nie wymagają już uzyskania dostępu do aplikacji.

• Opisz środki kontroli używane do wykrywania nieautoryzowanych prób transakcji przez autoryzowanych lub nieautoryzowanych użytkowników.

• Opisz zasady lub logiczne środki kontroli dostępu, które regulują sposób, w jaki użytkownicy mogą przekazywać uprawnienia dostępowe lub wykonywać kopie plików i informacji dostępnych dla innych użytkowników. Taka poufna kontrola dostępu może być odpowiednia dla niektórych, ale nie wszystkich aplikacji. Należy udokumentować wszelkie badania, które usprawiedliwiają użycie poufnej kontroli dostępu.

• Wskaż, po jakim okresie braku aktywności użytkownika system automatycznie oczyszcza wyświetlany obraz, a po jakim czasie system automatycznie odłącza nieaktywnych użytkowników lub wymaga od nich ponownego podania unikalnego hasła w celu przyłączenia się do systemu lub aplikacji.

• Opisz wszystkie ograniczenia, które uniemożliwiają użytkownikom uzyskanie dostępu do systemu lub aplikacji poza normalnymi godzinami pracy lub w czasie weekendów. Należy opisać zastosowane ograniczenia.

• Wskaż, czy do uniemożliwienia nieautoryzowanego dostępu do wrażliwych plików jest stosowane szyfrowanie jako część procedur kontroli dostępu do systemu lub aplikacji (jeśli szyfrowanie jest używane głównie do uwierzytelniania, informację o tym należy umieścić w poprzedniej części). Jeśli szyfrowanie jest używane jako część środków kontroli dostępu, należy dołączyć informacje o poniższych kwestiach.

• Jakiej metodologii szyfrowania użyto (na przykład klucz tajny lub publiczny)? Jeśli używany jest konkretny program, podaj jego nazwę.

• Omów procedury zarządzania kluczem szyfrowym w zakresie generowania, dystrybucji, przechowywania, wprowadzania, używania, niszczenia i archiwizacji kluczy.

• Jeśli dana aplikacja działa w systemie połączonym z Internetem lub inną siecią rozległą WAN, należy omówić dodatkowe środki kontroli sprzętowej lub technicznej, jakie zostały zainstalowane i wdrożone w celu zapewnienia ochrony przed nieautoryzowaną penetracją systemu i innymi zagrożeniami związanymi z Internetem.

• Opisz wszystkie używane typy bramek i firewalli, włącznie z ich konfiguracją (na przykład fakt skonfigurowania na ograniczenie dostępu do krytycznych zasobów systemowych lub uniemożliwienie obsługi przez system określonego typu ruchu).

• Przedstaw informacje dotyczące wszystkich urządzeń chroniących porty, które są używane do wymuszenia autoryzacji dostępu do konkretnych portów komunikacyjnych, włączając w to opis konfiguracji takich urządzeń. Należy także podać, czy są wymagane dodatkowe hasła lub tokeny.

• Wskaż, czy są używane wewnętrzne etykiety zabezpieczeń w celu kontroli dostępu do konkretnych typów informacji i plików, a także, czy takie etykiety podają niezbędne środki ochronne lub dodatkowe instrukcje obsługi.

• Wskaż, czy używana jest funkcja uwierzytelniania w oparciu o hosta (jest to metoda kontroli dostępu, która przyznaje dostęp w oparciu o tożsamość hosta wysyłającego żądanie, a nie o tożsamość danego użytkownika).

Kontrola dostępu publicznego

Jeśli aplikacja organizacji promuje lub umożliwia dostęp publiczny, wymagane są dodatkowe środki kontroli zabezpieczeń w celu ochrony integralności aplikacji oraz budowania zaufania użytkowników publicznych do aplikacji. Takie środki kontroli obejmują segregację informacji, które zostały udostępnione użytkownikom.

Systemy publicznego dostępu cechują się większym zagrożeniem związanym z atakami z zewnątrz. W przypadku takich systemów użytkownicy są często anonimowi, a także nieprzeszkoleni w zakresie obsługi systemu i odpowiedzialności. Ataki na systemy publicznego dostępu mogą mieć znaczący wpływ na reputację organizacji oraz poziom zaufania publicznego. Również zagrożenia ze strony wewnętrznych użytkowników są większe (na przykład błędy popełniane celowo przez niezadowolonych użytkowników lub przypadkowe pomyłki nieprzeszkolonych użytkowników).

Jeśli osoby z zewnątrz uzyskują dostęp do głównej aplikacji, należy opisać zastosowane dodatkowe środki kontroli. Poniższa lista sugeruje typy kontroli, jakie powinny zostać wdrożone w celu zapewnienia bezpieczeństwa w systemach publicznego dostępu, a także pewne kwestie do rozważenia (nie jest polecane dołączenie wszystkich możliwych środków kontroli).

• Wprowadź pewną formę identyfikacji i uwierzytelniania (może to być trudne).

• Zaimplementuj kontrolę dostępu w celu ograniczenia danych, jakie użytkownik może czytać, zapisywać, modyfikować lub usuwać.

• Zainstaluj środki kontroli, aby uniemożliwić użytkownikom z zewnątrz modyfikację informacji w systemie.

• Używaj podpisów cyfrowych.

• Przygotuj CD-ROM z informacjami, które mają być dystrybuowane na zewnątrz.

• Umieść w oddzielnym systemie kopie informacji do publicznego dostępu.

• Zabroń osobom z zewnątrz dostępu do działających baz danych.

• Sprawdzaj, czy udostępniane na zewnątrz programy i informacje są wolne od wirusów.

• Opisz kontrolę śladów oraz poufność użytkowników.

• Opisz dostępność systemu i danych.

• Przedstaw analizę prawną.

Śledzenie śladów

Funkcja śledzenia śladów zachowuje zapis aktywności systemu z podziałem na procesy systemu i aplikacji lub według aktywności użytkownika. W połączeniu z odpowiednimi funkcjami i procedurami funkcja śledzenia może zapewnić środki, które pozwolą na osiągnięcie wielu celów związanych z bezpieczeństwem, włączając w to obsługę poszczególnych kont, rekonstrukcję zdarzeń, wykrywanie włamań i identyfikację problemów.

W tej części należy opisać wykorzystywane mechanizmy śledzenia śladów. Odpowiedz na poniższe pytania.

• Czy funkcja śledzenia śladów współpracuje z funkcją obsługi kont, dzięki czemu można uzyskać zapis działań użytkownika?

• Czy funkcja śledzenia śladów umożliwia zbadanie „po fakcie”, w jaki sposób, kiedy i dlaczego przerwano normalne działanie?

• Czy funkcja śledzenia śladów została zaprojektowana i wdrożona w celu zapisywania niezbędnych informacji, które mogą pomóc w wykrywaniu włamania?

• Czy funkcja śledzenia śladów jest używana jako narzędzie online, aby pomóc zidentyfikować problemy inne niż włamania?

• Czy funkcja śledzenia śladów obejmuje wystarczająco dużo informacji, aby ustalić typ zdarzeń i ich sprawcę? Mówiąc ogólnie, zapis zdarzeń powinien obejmować:

• typ zdarzenia,

• kiedy wystąpiło zdarzenie,

• identyfikator użytkownika powiązanego ze zdarzeniem,

• program lub polecenie użyte do rozpoczęcia zdarzenia.

• Czy dostęp do dzienników funkcji śledzenia jest ściśle kontrolowany?

• Czy istnieje podział obowiązków między osobami zajmującymi się zabezpieczeniami, które administrują funkcją kontroli dostępu oraz tymi, które administrują funkcją śledzenia śladów?

• Czy zapewniona jest poufność informacji funkcji śledzenia śladów, jeśli na przykład są zapisywane osobiste dane użytkowników?

• Jak często są przeglądane dane funkcji śledzenia śladów? Czy istnieją zasady takiego przeglądu?

• Czy funkcja śledzenia śladów może być przeszukiwana pod kątem identyfikatora użytkownika, identyfikatora terminala, nazwy aplikacji, daty i czasu lub innego zestawu parametrów w celu utworzenia raportów z wybranymi informacjami?

• Czy właściwy administrator na poziomie systemu lub aplikacji przegląda dane funkcji śledzenia śladów, badając znany problem systemu albo aplikacji, znany przypadek naruszenia istniejących wymagań przez użytkownika lub niewyjaśniony problem związany z systemem lub użytkownikiem?

• Czy organizacja korzysta z wielu typów narzędzi, które zostały zaprojektowane w celu redukcji liczby informacji zawartych w zapisach funkcji śledzenia śladów, a także do uzyskania użytecznych informacji z surowych danych? Narzędzia do analizy, takie jak te oparte o redukcję danych, definicje ataków i technikę wariancji, mogą być używane w czasie rzeczywistym lub prawie rzeczywistym.

System ogólnego wsparcia — kontrola operacyjna

Kontrola operacyjna odnosi się do metod zabezpieczeń, które koncentrują się na mechanizmach wdrażanych i wykonywanych przez ludzi, a nie przez systemy. Te środki kontroli są stosowane w celu poprawy bezpieczeństwa konkretnego systemu (lub grupy systemów) i często wymagają doświadczenia technicznego lub specjalistycznego. Takie środki zwykle opierają się również o działania kadry zarządzającej oraz kontrolę techniczną.

W tej części należy opisać środki kontroli operacyjnej (istniejące lub zaplanowane), które mają spełnić wymogi bezpieczeństwa systemu ogólnego wsparcia.

Bezpieczeństwo personelu

Największe zagrożenie i szkody powodują w systemie celowe i przypadkowe działania użytkowników. O wiele za często systemy przeżywają awarię, uszkodzenie, utratę danych lub inne groźne sytuacje, spowodowane przez mające dobre intencje osoby, które mają prawo do korzystania lub obsługi systemu (na przykład programista, który wprowadza jedną drobną zmianę, a następnie instaluje program w działającym środowisku bez przeprowadzenia testów).

W tej części należy zamieścić szczegółowe informacje o poniższych środkach chroniących przed działaniami pracowników. Zaleca się dołączenie większości z tych środków do zasad zachowania. Jeśli to zrobisz, umieść informację o tym w odpowiedniej części.

• Czy wszystkie stanowiska zostały zbadane pod kątem poziomu wrażliwości? Jeśli jeszcze tak się nie stało, należy podać zaplanowaną datę zakończenia analizy wrażliwości stanowisk.

• Czy dołączono oświadczenie, według którego wszyscy użytkownicy otrzymali szkolenie odpowiadające zajmowanemu stanowisku? Jeśli nie wszyscy użytkownicy przeszli takie szkolenie, należy podać zaplanowaną datę przeprowadzenia wszystkich szkoleń.

• Czy przed przeprowadzeniem szkolenia dla użytkowników opisano warunki, na jakich te osoby mogą uzyskać dostęp do systemu? Należy też opisać środki kontroli, jakie zostaną użyte do zminimalizowania powiązanego z tym ryzyka.

• Czy uprawnienia dostępu użytkowników do plików danych, funkcji przetwarzania danych i peryferii oraz typ dostępu (na przykład odczyt, zapis, wykonanie, usunięcie) zostały ustawione na minimalny poziom wymagany przez daną osobę do wykonania swojego zadania?

• Czy krytyczne funkcje zostały rozdzielone między różne osoby (podział obowiązków), dzięki czemu żadna z nich nie ma wystarczających uprawnień lub informacji, które mogłyby doprowadzić do niebezpiecznego zachowania?

• Czy istnieje system zamawiania, zakładania, wydawania i zamykania kont użytkowników?

• Jakie mechanizmy zastosowano, aby użytkownicy byli odpowiedzialni za swoje postępowanie?

• Jakie są procedury przyjaznego i nieprzyjaznego zakończenia procesu?

Ochrona fizyczna i środowiskowa

Środki kontroli zabezpieczeń fizycznych i środowiskowych są wdrażane w celu zabezpieczenia struktur przechowujących zasoby systemowe i sam system oraz struktur używanych do obsługi jego operacji. Program zabezpieczeń organizacji powinien obejmować siedem następujących kwestii.

Wyjaśnienie bezpieczeństwa fizycznego i środowiskowego

W tej części należy krótko opisać środki kontroli fizycznej i środowiskowej dla systemu ogólnego wsparcia.

• Kontrola dostępu. Środki kontroli fizycznego dostępu ograniczają wejście i wyjście pracowników (a także ruch urządzeń i nośników danych) z danego obszaru, takiego jak budynek biurowy, biuro, centrum danych lub pokój zawierający serwer sieci lokalnej LAN. Kontrola dostępu nie powinna stosować się tylko do pomieszczeń zawierających urządzenia systemowe, ale także do miejsc z okablowaniem użytym do połączenia elementów systemu, usługami obsługi (na przykład zasilanie), nośnikami zapasowymi, a także z innymi elementami, które są wymagane do fizycznego działania systemu. Bardzo ważne jest zbadanie skuteczności kontroli fizycznego dostępu na poszczególnych obszarach zarówno w godzinach roboczych, jak i poza nimi, kiedy w danym miejscu może nie być nikogo.

• Czynniki ryzyka pożarowego. Pożary budynków są wyjątkowym zagrożeniem dla bezpieczeństwa ze względu na możliwość całkowitego zniszczenia urządzeń i danych, ryzyko dla ludzkiego życia, a także trwałość zniszczeń. Dym, trujące gazy i wysoka wilgotność mogą zniszczyć systemy w całym budynku. Dlatego też konieczne jest zbadanie bezpieczeństwa pożarowego budynków, w których umieszczone są systemy.

• Awaria systemów obsługi. Systemy i obsługujące je ludzie wymagają określonego środowiska pracy, które można kontrolować w pewnym zakresie. Awaria zasilania, systemu grzewczego i klimatyzacji, kanalizacji i innych systemów zwykle powoduje przerwanie funkcjonowania usługi oraz może uszkodzić sprzęt. Z tego powodu organizacje powinny upewnić się, czy te systemy, włączając w to ich różne aspekty, działają poprawnie.

• Zawalenie się budynku. Organizacje powinny zdawać sobie sprawę, iż budynek może zawalić się pod obciążeniem większym, niż zostało to przewidziane. Najczęściej dzieje się tak z powodu trzęsienia ziemi, obciążenia dachu śniegiem, eksplozji, która niszczy elementy nośne, lub pożaru, który osłabia strukturę budynku.

• Awarie kanalizacji. Chociaż takie awarie nie zdarzają się codzienne, mogą spowodować poważne skutki. Organizacja powinna poznać położenie rur kanalizacyjnych, które mogą zagrozić urządzeniom systemowym, oraz podjąć odpowiednie kroki w celu przeciwdziałania ryzyku (na przykład przeniesienie urządzeń lub rur kanalizacyjnych, a także odnalezienie zaworów odcinających).

• Przechwycenie danych. W zależności od typu danych przetwarzanych przez system może wystąpić znaczące ryzyko, jeśli zostaną one przechwycone. Organizacje powinny być świadome trzech sposobów przechwycenia informacji, a jest to mianowicie bezpośrednia obserwacja, przechwycenie transmisji danych oraz przechwycenie elektromagnetyczne.

• Systemy mobilne i przenośne. Analizy i zarządzanie ryzykiem muszą zwykle zostać zmodyfikowane, jeśli system jest zainstalowany na wózku lub jest systemem przenośnym, na przykład laptopem. System na wózku jest obciążony takim samym ryzykiem jak wózek, włączając w to wypadki i kradzież, a także ryzyko regionalne i lokalne. Organizacje powinny:

• przechowywać w bezpiecznym miejscu nieużywane komputery przenośne,

• szyfrować pliki danych na nośnikach, jeśli jest to opłacalne; jest to sposób pozwalający na uchronienie informacji w przypadku kradzieży lub zagubienia laptopa.

Kontrola produkcyjna oraz kontrola wejścia i wyjścia

W tej części należy przedstawić opis stosowanych procedur, które obsługują działanie systemu ogólnego wsparcia. Poniżej znajduje się kilka przykładów tematów, które powinny zostać omówione.

• Obsługa użytkowników.

• Procedury, dzięki którym nieautoryzowane osoby nie mogą odczytać, skopiować, zmienić ani ukraść wydrukowanych lub elektronicznych informacji.

• Procedury, dzięki którym tylko autoryzowani użytkownicy mogą pobrać, odebrać lub dostarczyć informacje wejściowe i wyjściowe oraz nośniki.

• Śledzenie odbioru ważnych danych wejściowych i wyjściowych.

• Procedury ograniczające dostęp do urządzeń wyjściowych.

• Procedury i środki kontroli przy transporcie lub wysyłce nośników i wydruków.

• Zewnętrzny lub wewnętrzny system znakowania wrażliwości informacji.

• Zewnętrzny system znakowania z instrukcjami dotyczącymi sposobu traktowania (na przykład identyfikatory dziennika lub inwentarza, kontrolowany dostęp, specjalne instrukcje dotyczące przechowywania, data wysłania lub zniszczenia).

• Kontrola śladów w celów zarządzania inwentarzem.

• Procedury i środki kontroli fizycznej i środowiskowej ochrony miejsca przechowywania nośników i biblioteki.

• Procedury czyszczenia nośników elektronicznych w celu ponownego użycia (na przykład nadpisanie lub rozmagnesowanie nośników elektronicznych).

• Procedury kontrolowanego przechowywania, obsługi i zniszczenia uszkodzonych nośników lub takich, które nie mogą być wyczyszczone w celu ponownego użycia.

• Procedury fizycznego zniszczenia wydruków, które nie są już potrzebne.

Planowanie awaryjne (kontynuacja obsługi)

Systemy ogólnego wsparcia wymagają istnienia właściwych planów zapasowych, archiwizacyjnych oraz awaryjnych. Takie plany powinny być regularnie testowane w celu zapewnienia działania systemu w przypadku wystąpienia awarii. Plany muszą być również znane użytkownikom, a także powinny zostać skoordynowane z odpowiednimi planami dla aplikacji.

Należy tu krótko opisać procedury (plan zapasowy), które należy wykonać, aby zapewnić kontynuację obsługi przez system wszystkich krytycznych aplikacji w przypadku wystąpienia sytuacji awaryjnej. Szczegółowe plany powinny być dołączone jako załącznik. W tym opisie należy także zamieścić odpowiedzi na poniższe pytania.

• Czy istnieją przetestowane plany zapasowe, które zapewnią działanie funkcji krytycznych dla działania firmy w przypadku wystąpienia groźnego zdarzenia?

• Czy istnieją przetestowane plany przywrócenia po katastrofie wszystkich systemów wsparcia IT i sieci?

• Czy formalne procedury ratunkowe zostały wysłane lub rozmieszczone w postaci pisemnej, tak aby umożliwić ich wykonanie w sytuacji awaryjnej?

• Jak często są testowane plany awaryjne na wypadek katastrofy i ratunkowe?

• Czy wszyscy pracownicy zostali przeszkoleni w zakresie swoich ról i odpowiedzialności pod względem planów awaryjnych, ratunkowych i na wypadek katastrofy?

Należy także dołączyć opis następujących środków kontroli:

• wszystkie umowy na obsługę archiwizacji (na przykład kontrakt z komercyjnym dostawcą usług),

• udokumentowane procedury archiwizacji, włączając ich częstotliwość (codziennie, tygodniowo, miesięcznie) oraz zakres (pełna kopia awaryjna, kopia przyrostowa lub różnicowa),

• miejsce przechowywania kopii zapasowych (w biurze lub poza nim),

• liczba utrzymywanych generacji kopii zapasowych,

• zasięg procedur archiwizacji (na przykład co jest archiwizowane).

Kontrola obsługi sprzętu i oprogramowania systemowego

Te środki kontroli są używane do monitorowania instalacji lub aktualizacji sprzętu, systemu operacyjnego lub innego oprogramowania, aby upewnić się, czy funkcje sprzętu i oprogramowania działają zgodnie z oczekiwaniami oraz w celu utworzenia historii zmian w apli­ka­cjach. Te kontrole mogą być również używane do sprawdzania, czy w systemie są zainstalowane tylko autoryzowane aplikacje. Takie środki kontroli mogą obejmować zasady konfiguracji oprogramowania i sprzętu, które wymagają zgody kierownictwa (ponowna autoryzacja działania) na modyfikacje, a także wymuszają dokumentację zmian. Inne środki kontroli obejmują programy i procedury używane do kontroli lub uniemożliwienia nielegalnego użycia programów typu shareware lub objętych prawami autorskimi.

W tej części należy dokładnie opisać zastosowane lub planowane środki kontroli obsługi sprzętu i oprogramowania systemowego. Poniższe pytania są przykładami kwestii, które powinny być poruszone w tej części.

• Czy są stosowane procedury, dzięki którym obsługa oraz naprawa systemu odbywa się bez naruszenia bezpieczeństwa systemu? Należy omówić następujące kwestie.

• Restrykcje oraz środki kontroli osób, wykonujących obsługę lub naprawę systemu.

• Specjalne procedury pozwalające na zapewnienie odpowiedniej wydajności naprawy i obsługi.

• Zarządzanie gwarancjami na oprogramowanie i sprzęt oraz polityką aktualizacji w celu maksymalnego wykorzystania tychże dla minimalizacji kosztów.

• Procedury stosowane dla elementów serwisowanych na miejscu oraz poza organizacją (na przykład towarzyszenie serwisantom, oczyszczanie nośników zabieranych z biura).

• Procedury stosowane do kontroli usług zdalnej obsługi, kiedy procedury diagnostyczne lub serwisowe są wykonywane przez media telekomunikacyjne.

• Jakie są procedury zarządzania konfiguracją systemu? Należy omówić następujące kwestie.

• Kontrola wersji, która pozwala na powiązanie komponentów systemu z właściwą wersją systemu.

• Procedury testowania i zatwierdzania komponentów systemu (system operacyjny, inny system, narzędzia i aplikacje) przed przekazaniem do użytku.

• Analizy wpływu efektu proponowanych zmian na istniejące środki kontroli zabezpieczeń, co obejmuje także wymagane szkolenia zarówno dla techników, jak i użytkowników, odnoszące się do proponowanej zmiany w oprogramowaniu lub sprzęcie.

• Procedury zmiany identyfikacji, akceptacji i dokumentacji.

• Procedury pozwalające upewnić się, czy plany zapasowe i powiązana dokumentacja jest aktualizowana wraz ze zmianami systemu.

• Czy dane testowe były danymi rzeczywistymi, czy spreparowanymi?

• Jak stosowane są poprawki ratunkowe?

• Jakie istnieją zasady obsługi programów shareware i objętych prawami autorskimi? Należy omówić następujące kwestie.

• Czy te zasady organizacji nie pozwalają na nielegalne użycie programów shareware i objętych prawami autorskimi?

• Czy w zasadach organizacji znajdują się informacje dotyczące odpowiedzialności i obsługi kont użytkowników oraz kadry kierowniczej, włączając w to informacje o karach?

• Czy wykonywane są okresowe kontrole komputerów użytkowników pod kątem instalacji tylko legalnych kopii programów, na które posiadana jest licencja?

• Jakie programy i procedury są wykorzystywane w celu zabezpieczenia przed nielegalnym użyciem oprogramowania?

• Czy istnieje zarządzanie gwarancjami na oprogramowanie w celu minimalizacji kosztu aktualizacji, uzyskania zwrotu kosztów lub wymiany wadliwych produktów?

Kontrola integralności

Środki kontroli integralności są używane w celu ochrony systemu operacyjnego, aplikacji i informacji w systemie przed przypadkową lub celową zmianą lub zniszczeniem, a także, by zagwarantować użytkownikowi, iż informacje spełniają oczekiwania pod względem jakości i nie zostały zmienione.

W tej części należy opisać wszelkie środki kontroli, które gwarantują użytkownikowi, iż informacje nie zostały zmienione, a sam system funkcjonuje w oczekiwany sposób. Poniższe pytania to przykłady kilku środków kontroli, które zaliczono do tej kategorii.

• Czy zainstalowano oprogramowanie do wykrywania i eliminacji wirusów? Jeśli tak, to czy istnieją procedury dla:

• aktualizacji plików zawierających definicje wirusów,

• automatycznego lub ręcznego skanowania antywirusowego (automatyczne skanowanie przy logowaniu do sieci, automatyczne logowanie po włączeniu zasilania stacji roboczej i serwera, automatyczne skanowanie po włożeniu dyskietki, automatyczne skanowanie po pobraniu danych z niezabezpieczonego źródła, na przykład z Internetu, skanowanie w poszukiwaniu wirusów w makrach),

• usuwania wirusów i tworzenia raportów.

• Czy stosowane są przez system procedury kontrolne — na przykład sumy kontrolne, sumy hash i liczniki rekordów? Należy dołączyć opis działań podjętych w celu usunięcia wszelkich niezgodności.

• Czy używane są narzędzia do sprawdzania i łamania haseł?

• Czy aplikacje korzystają z programów do weryfikacji integralności w celu wyszukania dowodów na manipulację danymi, błędów oraz pominięć? Te techniki obejmują kontrolę i potwierdzanie konsystencji i sensowności danych w czasie wprowadzania i przetwarzania. Należy opisać używane w systemie środki kontroli integralności.

• Czy używana jest funkcja monitorowania wydajności systemu w celu analizy dzienników wydajności systemu w czasie rzeczywistym, wyszukiwania problemów z dostępnością, włączając w to aktywne ataki oraz awarie lub spowolnienia i zawieszenie pracy systemu oraz sieci.

• Czy aplikacja używa funkcji uwierzytelniania wiadomości w celu upewnienia się, czy nadawca wiadomości jest znany, a wiadomość nie została zmieniona w czasie transmisji? Należy zaznaczyć, czy procedura uwierzytelniania została sprawdzona pod kątem stosowności dla systemu. Jeśli tak, opisz metodologię.

Dokumentacja

Dokumentacja jest środkiem kontroli zabezpieczeń, używanym do wyjaśnienia sposobu użycia urządzeń lub oprogramowania; formalizuje również procedury zabezpieczeń i działania dla danego systemu. Dokumentacja systemu obejmuje opisy sprzętu i programów, zasady, standardy, procedury oraz akceptacje odnoszące się do automatyzacji bezpieczeństwa systemu IT w systemie ogólnego wsparcia, włączając w to procedury archiwizacji oraz plan zapasowy, a także opisy procedur dla użytkowników i operatora.

W tej części należy przedstawić istniejącą dokumentację dla systemu ogólnego wsparcia.

Znajomość zabezpieczeń i szkolenia

Każdy użytkownik musi być wprowadzony w akceptowane zasady zachowania dla systemu, zanim uzyska do niego dostęp. W czasie programu szkoleń należy także poinformować użytkowników o sposobie uzyskania pomocy w przypadku wystąpienia trudności w czasie używania systemu. Konieczne jest także wyjaśnienie procedur dotyczących zgłaszania przypadków naruszenia zabezpieczeń.

Dostęp dla członków publicznych powinien być ograniczony za pomocą środków kontroli aplikacji; należy przeprowadzić szkolenie w zakresie tej kontroli, choć może się to ograniczyć tylko do odpowiedniego zawiadomienia w momencie uzyskiwania dostępu.

W tej części planu należy zamieścić informacje dotyczące poniższych kwestii:

• program świadomości aplikacji (plakaty, foldery i inne),

• typ i częstotliwość szkoleń w zakresie obsługi systemu, przeprowadzanych dla pracowników oraz osób współpracujących (seminaria, warsztaty, zajęcia w klasach, grupy dyskusyjne, odgrywanie ról oraz szkolenie w trakcie pracy),

• procedura sprawdzania, czy pracownicy i osoby współpracujące przeszły niezbędne szkolenia.

Możliwość zgłaszania wypadków naruszenia bezpieczeństwa

Naruszenie bezpieczeństwa komputera to niepomyślne zdarzenie w systemie komputerowym lub sieci, spowodowane przez awarię mechanizmu zabezpieczeń lub podjętą próbę naruszenia tego mechanizmu. Takie zdarzenia stają się coraz powszechniejsze, a ich skutki są bardzo rozległe. W przypadku wystąpienia takiego zdarzenia organizacja powinna być w stanie szybko na nie odpowiedzieć w sposób, który ochroni zarówno własne informacje, jak i informacje innych stron, które mogą ucierpieć.

W tej części należy opisać procedury obsługi wypadków naruszenia bezpieczeństwa, które są stosowane dla systemu ogólnego wsparcia. Poniżej przedstawiono zagadnienia, które powinny zostać rozważone.

• --> Czy [Author:s] istnieje formalna komórka (zarówno wewnątrz, jak i na zewnątrz organizacji), która jest odpowiedzialna za reakcję na naruszenie zabezpieczeń? Jeśli nie ma takiej komórki, czy istnieje dział obsługi, który może pomóc użytkownikom?

• Czy procedury zgłaszania naruszeń bezpieczeństwa są obsługiwane przez personel organizacji lub zewnętrzny?

• Czy istnieją procedury rozpoznawania takich zdarzeń i reakcji na nie (na przykład, które pliki i dzienniki powinny być zachowane, z kim i kiedy należy się skontaktować)?

• Kto odbiera sygnały i odpowiada na alarmy i informacje o poprawkach oprogramowania lub o zbadanych słabych punktach?

• Jakie stosuje się środki zabezpieczające:

• narzędzia do wykrywania włamania,

• zautomatyzowane dzienniki kontroli,

• testy penetracji.

System ogólnego wsparcia — kontrola techniczna

Kontrola techniczna koncentruje się na środkach kontroli zabezpieczeń stosowanych przez system komputerowy. Te środki mogą zapewnić zautomatyzowaną ochronę przed nieautoryzowanym dostępem lub niewłaściwym użyciem, umożliwić wykrycie naruszeń zabezpieczeń, a także zaspokoić wymogi zabezpieczeń dla aplikacji i danych. Wdrożenie środków kontroli technicznej zawsze wymaga jednak poważnych analiz operacyjnych oraz zachowania zgodności z zarządzaniem bezpieczeństwem w organizacji.

W tej części należy opisać środki kontroli technicznej (stosowane lub zaplanowane), które mają spełnić wymogi zabezpieczeń systemu ogólnego wsparcia.

Identyfikacja i uwierzytelnianie

Identyfikacja i uwierzytelnianie jest techniczną metodą uniemożliwiania dostępu do systemu IT nieautoryzowanym osobom (lub nieautoryzowanym procesom). Kontrola dostępu zwykle wymaga możliwości identyfikacji i odróżniania użytkowników przez system. Dla przykładu kontrola dostępu jest często oparta o minimalne przywileje, co oznacza przyznanie użytkownikowi tylko takiego dostępu, jaki jest wymagany do wykonywania obowiązków. Obsługa kont użytkowników wymaga często powiązania funkcji systemu IT z konkretnymi użytkownikami, co w efekcie stwarza konieczność identyfikacji użytkowników przez system.

Identyfikacja

Identyfikacja to sposób przedstawienia systemowi przez użytkownika swojej tożsamości. Najczęściej spotykaną formą identyfikacji jest identyfikator użytkownika.

W tej części planu należy krótko opisać sposób identyfikacji dostępu do systemu przez system ogólnego wsparcia.

• Unikalna identyfikacja. Organizacja powinna wymagać od swoich użytkowników unikalnej identyfikacji, zanim uzyskają oni prawo do wykonywania jakichkolwiek operacji w systemie, chyba że anonimowość użytkowników lub inne kwestie nakazują inne postępowanie.

• Powiązania działań z użytkownikami. System powinien zarządzać wewnętrznie tożsamościami wszystkich aktywnych użytkowników, a także mieć możliwość powiązania działań z konkretnymi użytkownikami (zobacz sekcję Śledzenie śladów).

• Obsługa identyfikatorów użytkowników. Wszystkie identyfikatory użytkowników w organizacji powinny przynależeć do użytkowników autoryzowanych w danym momencie. Należy zapewnić aktualność informacji identyfikacyjnych przez dodawanie nowych użytkowników i usuwanie starych.

• Nieaktywne identyfikatory użytkowników. Identyfikatory użytkowników, które są nieaktywne w systemie przez określony czas (na przykład trzy miesiące) powinny być wyłączane.

Uwierzytelnianie

Uwierzytelnianie jest sposobem potwierdzania ważności własnej tożsamości użytkownika w systemie. Istnieją trzy sposoby uwierzytelniania tożsamości użytkownika, które mogą być stosowane oddzielnie lub razem: może to być coś, co użytkownik zna (coś tajnego — na przykład hasło, osobisty numer identyfikacyjny PIN lub klucz szyfrowy); coś, co należy do użytkownika (token — na przykład karta bankomatowa lub karta elektroniczna) lub coś, czym użytkownik jest (cechy biometryczne — na przykład próbka głosu, ręczne pismo lub odcisk palca).

W tej części należy opisać mechanizmy kontroli uwierzytelniania używane przez aplikację główną. Omawiamy je niżej.

• Opisz metodę uwierzytelniania użytkowników (hasło, token lub cechy biometryczne).

• Jeśli stosowany jest system haseł, podaj następujące informacje:

• dozwolony zestaw znaków,

• długość hasła (minimalna i maksymalna),

• okres upływu ważności hasła oraz sposób wymuszania jego zmiany,

• liczba niedozwolonych generacji starych haseł,

• procedury zmiany hasła,

• procedury obsługi zagubionych haseł,

• procedury obsługi naruszenia systemu haseł.

• Opisz procedury szkolenia użytkowników oraz użyte materiały.

• Wskaż częstotliwość zmiany haseł, opisz sposób wymuszenia zmiany hasła (na przykład przez program lub administratora systemu) oraz podaj osobę, która zmienia hasło (użytkownik, system lub administrator systemu).

• Opisz stosowane sposoby kontroli cech biometrycznych. Należy dołączyć opis sposobu implementacji tych sposobów w systemie.

• Opisz używane przez system środki kontroli tokenów oraz sposób ich implementacji. Należy odpowiedzieć na poniższe pytania.

• Czy wymagane są specjalne czytniki sprzętowe?

• Czy użytkownik musi podać unikalny osobisty numer identyfikacyjny (PIN)?

• Kto wybiera PIN, użytkownik czy administrator systemu?

• Czy token używa generatora haseł do utworzenia jednorazowego hasła?

• Czy do utworzenia hasła jest używany protokół typu „wezwanie-odpowiedź”?

• Opisz poziom wymuszania mechanizmu kontroli dostępu (sieć, system operacyjny lub aplikacja).

• Opisz sposób obsługi poszczególnych kont i kontroli śladów (na przykład, czy hasła są powiązane z identyfikatorem użytkownika, który jest przydzielony tylko dla jednej osoby) przez mechanizm kontroli dostępu.

• Opisz techniki własnego zabezpieczenia mechanizmu uwierzytelniania użytkownika (na przykład, czy hasła są przesyłane i przechowywane z użyciem jednokierunkowego szyfrowania tak, że nikt, włączając w to administratora, nie może odczytać haseł w czystym tekście; czy hasła są generowane automatycznie; czy hasła są porównywane ze słownikiem niedozwolonych haseł; czy hasła są szyfrowane w czasie przesyłania).

• Podaj liczbę nieudanych prób dostępu, jaka może wystąpić dla danego identyfikatora użytkownika lub miejsca dostępu (terminal lub port), a także opisz działania, jakie zostaną podjęte po przekroczeniu limitu.

• Opisz procedurę weryfikacji, czy zostały zmienione wszystkie domyślne hasła administratorów, które zostały ustawione przez system.

• Opisz procedury do ograniczania skryptów dostępowych z dołączonym hasłem (na przykład, czy skrypty z dołączonym hasłem są zabronione lub dozwolone tylko dla aplikacji wsadowych).

• Opisz wszystkie zasady, które pozwalają na pominięcie wymagań w zakresie uwierzytelniania użytkownika, technologie „pojedynczego podpisu” (na przykład bezpośrednie połączenie dwóch komputerów, serwery uwierzytelniania, identyfikator „użytkownik do hosta” oraz identyfikatory grup użytkowników), a także wszystkie środki kontroli naruszenia uwierzytelniania.

Logiczna kontrola dostępu (Kontrola uwierzytelniania i dostępu)

Logiczna kontrola dostępu to mechanizmy systemowe używane do wskazania osoby lub procesu, który ma uzyskać dostęp do konkretnego zasobu systemowego, a także dozwolonego typu dostępu.

W tej części należy omówić środki kontroli, które są stosowane do autoryzacji lub ograniczenia działalności użytkowników lub personelu systemowego w ramach aplikacji. Opisz funkcje sprzętu lub oprogramowania, które zostały utworzone w celu umożliwienia tylko autoryzowanego dostępu do aplikacji lub wewnątrz niej, do ograniczenia działań użytkowników tylko do autoryzowanych transakcji i funkcji, a także do wykrywania nieautoryzowanych działań (na przykład listy kontroli dostępu ACL). Wykonaj też poniższe czynności.

• Opisz formalne zasady definiujące przywileje, które zostaną przyznane każdemu użytkownikowi lub klasie użytkowników. Należy zaznaczyć, czy te zasady są zgodne z ideą minimalnych przywilejów, co wymaga identyfikacji funkcji związanych z pracą użytkownika, ustalenia minimalnego zestawu przywilejów wymaganych do wykonania tych funkcji, a także ograniczenia użytkownika tylko do domeny z tymi przywilejami. Należy dołączyć tu procedury przyznawania dostępu nowym użytkownikom oraz te, które stosowane są w przypadku zmiany przez użytkownika roli lub pracy.

• Podaj, czy zasady obejmują oddzielenie wymuszenia obowiązków, aby uniemożliwić danej osobie dostęp lub ograniczyć informacje dostępowe, które umożliwiłyby zabronione działania bez możliwości wykrycia.

• Opisz możliwość utworzenia przez aplikację listy kontroli dostępu lub zarejestrowania przez nią użytkowników oraz dostępnych dla nich typów dostępu.

• Wskaż, czy stosowana jest ręczna lista ACL.

• Zaznacz, czy oprogramowanie zabezpieczające pozwala właścicielom aplikacji na ograniczenie praw dostępu do aplikacji, danych i plików innym użytkownikom aplikacji, administratorowi systemu ogólnego wsparcia lub operatorom.

• Opisz sposób, w jaki ogranicza się użytkownikom dostęp do systemu operacyjnego, innych aplikacji lub innych zasobów systemowych, które nie są wymagane przy wykonywaniu przez nich swoich obowiązków.

• Podaj, jak często przeglądane są listy ACL w celu identyfikacji i usunięcia użytkowników, którzy opuścili organizację lub których obowiązki nie wymagają już uzyskania dostępu do aplikacji.

• Opisz środki kontroli używane do wykrywania nieautoryzowanych prób transakcji przez autoryzowanych lub nieautoryzowanych użytkowników.

• Opisz zasady lub logiczne środki kontroli dostępu, które regulują sposób, w jaki użytkownicy mogą przekazywać uprawnienia dostępowe lub wykonywać kopie plików i informacji dostępnych dla innych użytkowników. Taka poufna kontrola dostępu może być odpowiednia dla niektórych, ale nie wszystkich aplikacji. Należy udokumentować wszelkie badania, które usprawiedliwiają użycie poufnej kontroli dostępu.

• Wskaż, po jakim okresie braku aktywności użytkownika system automatycznie oczyszcza wyświetlany obraz, a po jakim czasie system automatycznie odłącza nieaktywnych użytkowników lub wymaga od nich ponownego podania unikalnego hasła w celu przyłączenia się do systemu lub aplikacji.

• Opisz wszystkie ograniczenia, które uniemożliwiają użytkownikom uzyskanie dostępu do systemu lub aplikacji poza normalnymi godzinami pracy lub w czasie weekendów. Należy opisać zastosowane ograniczenia.

• Wskaż, czy do uniemożliwienia nieautoryzowanego dostępu do wrażliwych plików jest stosowane szyfrowanie jako część procedur kontroli dostępu do systemu lub aplikacji (jeśli szyfrowanie jest używane głównie do uwierzytelniania, informację o tym należy umieścić w poprzedniej części). Jeśli szyfrowanie jest używane jako część środków kontroli dostępu, należy dołączyć informacje o poniższych kwestiach.

• Jakiej metodologii szyfrowania użyto (na przykład klucz tajny lub publiczny)? Jeśli używany jest konkretny program, podaj jego nazwę.

• Omów procedury zarządzania kluczem szyfrowym w zakresie generowania, dystrybucji, przechowywania, wprowadzania, używania, zniszczenia i archiwizacji kluczy.

• Jeśli dana aplikacja działa w systemie połączonym z Internetem lub inną siecią rozległą WAN, należy omówić dodatkowe środki kontroli sprzętowej lub technicznej, jakie zostały zainstalowane i wdrożone w celu zapewnienia ochrony przed nieautoryzowaną penetracją systemu i innymi zagrożeniami związanymi z Internetem.

• Opisz wszystkie używane typy bramek i firewalli, włącznie z ich konfiguracją (na przykład fakt skonfigurowania na ograniczenie dostępu do krytycznych zasobów systemowych lub uniemożliwienie obsługi przez system określonego typu ruchu).

• Przedstaw informacje dotyczące wszystkich urządzeń chroniących porty, które są używane do wymuszenia autoryzacji dostępu do konkretnych portów komunikacyjnych, włączając w to opis konfiguracji takich urządzeń. Należy także podać, czy są wymagane dodatkowe hasła lub tokeny.

• Wskaż, czy są używane wewnętrzne etykiety zabezpieczeń w celu kontroli dostępu do konkretnych typów informacji i plików, a także, czy takie etykiety podają niezbędne środki ochronne lub dodatkowe instrukcje obsługi.

• Wskaż, czy używana jest funkcja uwierzytelniania w oparciu o hosta. Jest to metoda kontroli dostępu, która przyznaje dostęp w oparciu o tożsamość hosta wysyłającego żądanie, a nie o tożsamość danego użytkownika.

Śledzenie śladów

Funkcja śledzenia śladów zachowuje zapis aktywności systemu z podziałem na procesy systemu i aplikacji lub według aktywności użytkownika. W połączeniu z odpowiednimi funkcjami i procedurami ta funkcja śledzenia może zapewnić środki, które pozwolą na realizację wielu celów związanych z bezpieczeństwem, włączając w to obsługę poszczególnych kont, rekonstrukcję zdarzeń, wykrywanie włamań i identyfikację problemów.

W tej części należy opisać wykorzystywane mechanizmy śledzenia śladów. Odpowiedz na poniższe pytania.

• Czy funkcja śledzenia śladów współpracuje z funkcją obsługi kont, dzięki czemu można uzyskać zapis działań użytkownika?

• Czy funkcja śledzenia śladów umożliwia zbadanie „po fakcie”, w jaki sposób, kiedy i dlaczego przerwano normalne działanie?

• Czy funkcja śledzenia śladów została zaprojektowana i wdrożona w celu zapisywania niezbędnych informacji, które mogą pomóc w wykrywaniu włamania?

• Czy funkcja śledzenia śladów jest używana jako narzędzie online, aby pomóc zidentyfikować problemy inne niż włamania?

• Czy funkcja śledzenia śladów obejmuje wystarczająco dużo informacji, aby ustalić typ zdarzeń i ich sprawcę? Mówiąc ogólnie, zapis zdarzeń powinien obejmować:

• typ zdarzenia,

• kiedy wystąpiło zdarzenie,

• identyfikator użytkownika powiązanego ze zdarzeniem,

• program lub polecenie użyte do rozpoczęcia zdarzenia.

• Czy dostęp do dzienników funkcji śledzenia jest ściśle kontrolowany?

• Czy istnieje podział obowiązków między osobami zajmującymi się zabezpieczeniami, które administrują funkcją kontroli dostępu oraz tymi, które administrują funkcją śledzenia śladów?

• Czy zapewniona jest poufność informacji funkcji śledzenia śladów, jeśli na przykład są zapisywane osobiste dane użytkowników?

• Jak często są przeglądane dane funkcji śledzenia śladów? Czy istnieją zasady takiego przeglądu?

• Czy funkcja śledzenia śladów może być przeszukiwana pod kątem identyfikatora użytkownika, identyfikatora terminala, nazwy aplikacji, daty i czasu lub innego zestawu parametrów w celu utworzenia raportów z wybranymi informacjami?

• Czy właściwy administrator na poziomie systemu lub aplikacji przegląda dane funkcji śledzenia śladów, badając znany problem systemu albo aplikacji, znany przypadek naruszenia istniejących wymagań przez użytkownika lub niewyjaśniony problem związany z systemem lub użytkownikiem?

• Czy organizacja korzysta z wielu typów narzędzi, które zostały zaprojektowane w celu redukcji liczby informacji zawartych w zapisach funkcji śledzenia śladów, a także do uzyskania użytecznych informacji z surowych danych? Narzędzia do analizy, takie jak te oparte o redukcję danych, defincje ataków i technikę wariancji, mogą być używane w czasie rzeczywistym lub prawie rzeczywistym.

Szablony zasad bezpieczeństwa

W dodatku B umieszczono szablony zasad zabezpieczeń, które zostały utworzone zgodnie z wcześniej przedstawionymi zaleceniami. Te szablony są przykładami tylko dla jednego punktu widzenia, należy więc je zmodyfikować zgodnie z własnymi lub firmowymi zasadami działania.

Analiza zabezpieczeń

„Zapomnij o wszystkim, czego dowiedziałeś się o przestępczości technologicznej; zapomnij o nastoletnich hakerach, zagranicznych szpiegach, zorganizowanych grupach przestępczych i o oszustach produkujących fałszywe banknoty studolarowe na kserokopiarkach. Największym zagrożeniem dla najcenniejszych klejnotów intelektualnych każdej firmy — sekretów handlowych, planów rozwoju, cenników i informacji o klientach — są inne firmy amerykańskie”.

Forbes Magazine, 1996

Większość firm nie ma czasu albo dostępnych zasobów, aby prawidłowo zaprojektować i wdrożyć system zabezpieczeń lub chronić swoje sieci przed zagrożeniami płynącymi z Internetu. Analiza zabezpieczeń może stać się przewodnikiem podczas tworzenia i wdrażania praktycznych rozwiązań zarówno w domu, jak i firmie.

Wraz z rozrostem Internetu oraz ciągłym postępem technologicznym coraz powszechniejsze stają się próby włamań. Zagrożenia zewnętrzne są prawdziwym światowym problemem zarówno dla użytkownika domowego, jak i dla firm, które mają połączenia internetowe. Aby zapewnić bezpieczeństwo zdalnego dostępu i systemu, a także, aby zbadać poprawność zasad zabezpieczeń, należy regularnie wykonywać inspekcje zabezpieczeń. Niezależnie od tego, czy komputery firmowe lub domowe są dopiero podłączane do sieci, czy też już od dłuższego czasu wykorzystujesz Internet lub infrastrukturę sieciową, prawidłowa analiza pomoże stwierdzić, czy jesteś właściwie zabezpieczony przed włamaniem. Ta część rozdziału przedstawia propozycję oceny bezpieczeństwa obecnie stosowanych środków, a także opis szczegółowej inspekcji zabezpieczeń. Poniżej omawiamy następujące tematy.

• Skanowanie lokalizacji w celu przetestowania warstwy portów i aplikacji pod względem wewnętrznych środków zabezpieczających.

• Zdalna inspekcja w celu sprawdzenia usług zewnętrznych (na przykład usługi dostawcy Internetu, serwery i okablowanie).

• Testy penetracji w celu sprawdzenia zabezpieczeń internetowych.

• Testy podszywania się pod adres IP i pocztę oraz testy na rozsyłanie spamu w celu zabezpieczenia się przed tym narastającym problemem.

• Inspekcja połączeń wykorzystujących linie telefoniczne w celu zapewnienia bezpieczeństwa dostępu w ten sposób przy użyciu programów takich jak PC Anywhere, Reachout lub Citrix.

Inspekcja zewnętrzna powinna być wykonywana zdalnie, to znaczy z innej lokalizacji lub na zewnątrz urządzeń lub programów zabezpieczających, na przykład firewalla. Taka inspekcja powinna być wykonywana najpierw „na ślepo”, co oznacza brak szczegółowej wiedzy na temat infrastruktury.

Po zakończeniu pierwszej fazy test penetracji (z wykorzystaniem wiedzy o infrastrukturze) pomoże ustalić zakres i ryzyko (jeśli występuje) zewnętrznego ataku. Taka inspekcja jest cenna przy testowaniu konfiguracji mechanizmów zabezpieczających, usług internetowych, FTP i pocztowych oraz innych. Takie skanowanie i symulowany atak są wykonywane zdalnie przez Internet. Zalecane jest, aby ta faza była wykonywana bez zdradzania informacji o niej (z wyjątkiem wybranego kierownictwa) w postaci nieplanowanej oceny zewnętrznej penetracji.

Testy penetracji powinny być przeprowadzane pasywnie, tak aby w żaden sposób nie zakłócić działania organizacji. Takie testy mogą opcjonalnie obejmować atak i ocenę połączeń modemowych oraz bezpieczeństwo fizyczne. Jest to wykonywane przy użyciu procedury skanowania i wykrywania źle skonfigurowanych połączeń telefonicznych i serwerów terminala, a także szpiegujących lub nieautoryzowanych modemów.

Jeśli inspekcja ma na celu witryny internetowe, należy wykonać również inspekcję kodów źródłowych CGI, Java, JavaScript i ActiveX. W czasie wykonywania badania należy zapewnić utworzenie szczegółowych i oznakowanych datą dzienników wszystkich działań. Taki dziennik będzie używany w dalszych testach dotyczących istniejących funkcji tworzenia dzienników przez stację roboczą — zostanie dokonane porównanie dziennika inspekcji oraz dziennika celu ataku. Jeśli wykonujesz inspekcję w celach innych niż osobiste, bardzo ważne jest otrzymanie pisemnego upoważnienia na papierze firmowym od właściwego urzędnika badanej organizacji.

Siedem faz analizy

Inspekcja zabezpieczeń powinna być wykonywana regularnie. W oparciu o techniki, narzędzia i programy różnych firm, omówione w pierwszym tomie tej książki, można dokonać podziału właściwej analizy na siedem następujących faz.

Faza 1: Ślepe testy

Ta faza odnosi się do zdalnego testowania bez znajomości szczegółowej infrastruktury badanego obiektu.

Skanowanie lokalizacji

Ten test obejmuje:

• zbieranie informacji o sieci,

• skanowanie wszystkich portów zidentyfikowanych w czasie zbierania informacji,

• skanowanie aplikacji w celu identyfikacji usług systemowych, które są powiązane ze zbadanymi portami,

• testy przepustowości w celu zmierzenia poziomu wykorzystania portów, co pozwala na wykrycie słabych punktów,

• dokumentowanie.

Zdalna inspekcja

W czasie zdalnej inspekcji należy wykonać następujące czynności:

• testowanie konfiguracji, stabilności i wrażliwości środków zabezpieczających, zewnętrznych usług dostawcy Internetu oraz wszystkich innych usług sieciowych, które przechodzą przez firewall lub proxy,

• przygotowanie dokumentacji.

Testy penetracji

W celu przeprowadzenia testów penetracji należy wykonać następujące czynności:

• atak i ocenę zabezpieczeń fizycznych, mające na celu spenetrowanie wszystkich elementów zidentyfikowanych przez skanowanie lokalizacji i zdalną inspekcję,

• inspekcję kodu źródłowego CGI, JavaScript i ActiveX,

• inicjację przechwycenia ODBC (bazy danych),

• wykonanie testów przepełnienia IP,

• inicjację standardowych narzędzi do łamania zabezpieczeń IOS systemów NT, Novell i UNIX,

• próbę podszycia się pod DNS,

• inicjalizację pasywnej próby podsłuchu (sniffer) w celu przechwycenia ruchu,

• przygotowanie dokumentacji.

Podszywanie się pod adres IP i pocztę oraz testy spamu

Testy podszywania się pod adres IP i pocztę oraz testy na rozsyłanie spamu wymagają wykonania następujących czynności:

• wykonania ataków penetracji w celu zmuszenia urządzeń infrastruktury do tworzenia szkodliwych wyrażeń lub udostępniania wrażliwych informacji (na przykład haseł),

• przetestowania możliwości wymuszenia poczty elektronicznej, uzyskania kontroli nad serwerami SMTP, POP3 i IMAP4 oraz wykorzystanie przepustowości klienta przez wysłanie dużej ilości zewnętrznych wiadomości,

• przygotowania dokumentacji.

Faza 2: Penetracja z wykorzystaniem zdobytych informacji

Ta faza obejmuje testy wykorzystujące wcześniej zdobytą wiedzę na temat infrastruktury celu, takie jak:

• schemat adresowania IP/IPX,

• protokoły,

• schematy translacji adresów sieciowych i portów,

• informacje o połączeniach wykorzystujących linie telefoniczne (użytkownicy, numery dostępowe, metody dostępu itp.),

• konfiguracja systemu operacyjnego urządzeń sieciowych,

• uprzywilejowane punkty dostępowe,

• szczegółowa konfiguracja zewnętrzna (dostawca Internetu, obsługa witryny itp.),

• dokumentacja,

• skanowanie lokalizacji, które obejmuje:

• zbieranie informacji o sieci,

• skanowanie wszystkich portów zidentyfikowanych w czasie zbierania informacji,

• skanowanie aplikacji w celu identyfikacji usług systemowych, które są powiązane ze zbadanymi portami,

• testy przepustowości w celu zmierzenia poziomu wykorzystania portów, co pozwala na wykrycie słabych punktów,

• dokumentowanie,

• zdalna inspekcja, która wymaga następujących czynności:

• testowania konfiguracji, stabilności i wrażliwości środków zabezpieczających, zewnętrznych usług dostawcy Internetu oraz wszystkich innych usług sieciowych, które przechodzą przez firewall lub proxy,

• testy penetracji, na które składają się następujące działania:

• atak i ocena zabezpieczeń fizycznych, mające na celu spenetrowanie wszystkich elementów zidentyfikowanych przez skanowanie lokalizacji i zdalną inspekcję,

• inspekcja kodu źródłowego CGI, JavaScript i ActiveX,

• inicjacja przechwycenia ODBC (bazy danych),

• wykonanie testów przepełnienia IP,

• inicjacja standardowych narzędzi do łamania zabezpieczeń IOS, systemów NT, Novell i UNIX;

• próba podszycia się pod DNS,

• inicjalizacja pasywnej próby podsłuchu (sniffer) w celu przechwycenia ruchu,

• przygotowanie dokumentacji,

• Testy podszywania się pod adres IP i pocztę oraz testy spamu, obejmujące następujące czynności:

• wykonanie ataków penetracji w celu zmuszenia urządzeń infrastruktury do tworzenia szkodliwych wyrażeń lub udostępniania wrażliwych informacji (na przykład haseł),

• przetestowanie możliwości wymuszenia poczty elektronicznej, uzyskania kontroli nad serwerami SMTP, POP3 i IMAP4 oraz wykorzystanie drogiego pasma klienta przez wysłanie dużej ilości zewnętrznych wiadomości,

• przygotowanie dokumentacji.

Faza 3: Usługi internetowe

W czasie fazy 3. przeprowadzane są testy penetracji, które obejmują:

• atak i ocenę zabezpieczeń fizycznych, mające na celu spenetrowanie wszystkich elementów zidentyfikowanych przez skanowanie lokalizacji i zdalną inspekcję,

• inspekcję kodu źródłowego CGI, JavaScript i ActiveX,

• inicjację przechwycenia ODBC (bazy danych),

• wykonanie testów przepełnienia IP, HTTP i ICMP,

• próbę podszycia się pod DNS,

• przygotowanie dokumentacji.

Faza 4: Inspekcja połączeń wykorzystujących linie telefoniczne

Inspekcja połączeń wykorzystujących linie telefoniczne obejmuje:

• użycie procedur skanowania i wykrywania źle skonfigurowanych połączeń telefonicznych i serwerów terminala (PC Anywhere, Reachout lub Citrix), a także szpiegujących lub nieautoryzowanych modemów,

• dokumentację procedur.

Faza 5: Inspekcja lokalnej infrastruktury

Inspekcja lokalnej infrastruktury jest kompilacją raportów z każdej części, w której powinny znaleźć się następujące informacje.

• Raport o problemach użytkowników — obejmuje takie kwestie jak: długi czas startu komputera, problemy z plikami i drukowaniem, mała dostępność pasma oraz samoczynne przypadki przerwania połączenia.

• Podział ruchu według rodziny protokołów — procentowy podział ruchu według protokołów używanych w czasie okresu przechwytywania. Każda ramka jest umieszczana w odpowiedniej rodzinie protokołu. Jeśli do ramki odnosi się więcej niż jeden protokół, jest ona umieszczana w kategorii zależnej od najwyższego analizowanego protokołu, na przykład ramka TCP/IP kapsułkowana przez Frame Relay zostanie oznaczona jako TCP/IP, a wszystkie bajty w tej ramce zostaną wliczone do procentu TCP/IP.

• Segmenty i stacje sieciowe a symptomy — jest to podział według stacji sieciowych i wykrytych objawów, włączając w to informację o liczbie błędów lub objawów dla każdej stacji. Niektóre z wykrywanych symptomów to:

• zamrożone klatki — wskazują zawieszoną aplikację lub niedziałającą stację roboczą,

• retransmisja pliku — wskazuje, iż cały plik lub jego część musi zostać ponownie przesłany; dzieje się tak zwykle w przypadku aplikacji, która nie wykorzystuje efektywnie sieci,

• niska przepustowość — obliczona w oparciu o średnią przepustowość w czasie transmisji plików,

• przekierowanie hosta — wskazuje stacje otrzymujące komunikat ICMP redirect message, co oznacza, iż bramka lub router wysłał ten komunikat, aby poinformować stacje o istnieniu lepszej trasy lub o braku dostępności wybranej trasy.

• Wykorzystanie pasma — wskazuje całkowite pasmo wykorzystane przez stacje w czasie sesji analizy. Na podstawie tych danych możliwe jest przedstawienie rekomendacji, które pozwolą na zwiększenie przepustowości i produktywności.

Faza 6: Inspekcja sieci rozległej WAN

Faza 6. jest kompilacją raportów z każdej części, w której powinny znaleźć się następujące informacje.

• Zebrane informacje o urządzeniach sieciowych — spis aktualnego osprzętu sieciowego, włączając w to przełączniki, routery, firewalle i proxy.

• Alarmy i progi — ta funkcja śledzi w czasie rzeczywistym cały ruch HTTP, FTP, POP3, SMTP i NNTP, a także samodzielnie zdefiniowane informacje o dostępie do lokalizacji. Inne monitorowane dane obejmują w formie podsumowania obciążenie sieci, liczbę oraz częstotliwość dostępu każdego użytkownika, a także odrzucone próby dostępu.

• Dzienniki alarmów i zdarzeń — znajdują się tu wyjątki z rzeczywistych plików dzienników, zapisanych w czasie sesji analizy.

Faza 7: Raportowanie

Ta faza jest kompilacją raportów z każdej części, w której powinny znaleźć się następujące informacje:

• szczegółowa dokumentacja wszystkich zebranych informacji,

• diagramy i zrzuty ekranowe każdego zdarzenia,

• rekomendowane rozszerzenia zabezpieczeń w oparciu o techniki zespołu Tiger Team,

• lista wymaganych i opcjonalnych poprawek dla słabych punktów, które cechują się dużym zagrożeniem.

Wyniki końcowe analizy zabezpieczeń

Wyniki końcowe analizy zabezpieczeń powinny zawierać wszystkie funkcje przedstawione w czasie zebrania dotyczącego przeglądu projektu. Wyniki końcowe powinny mieć formę raportu szczegółowego, podzielonego na następujące części: skanowanie, podszywanie, spamowanie, przepełnianie, inspekcje, penetracje, zebrane informacje, informacje o sieci, informacje o systemie, ocena wrażliwości oraz rekomendacje pozwalające na zwiększenie bezpieczeństwa sieciowego (wymagane i opcjonalne). Należy poświęcić czas na odpowiednie pogrupowanie wyników końcowych, gdyż pozwoli to na podjęcie odpowiednich kroków zaradczych.

Pozostała część rozdziału to przedstawienie niektórych ważnych komponentów fazy raportowania w formie rzeczywistego przykładu. Do raportu możesz także dołączyć wyniki pochodzące ze skanerów wrażliwości, takich jak TigerSuite, CyberCop Scanner firmy Networks Associates lub NetRecon firmy Axent. Ten konkretny raport został utworzony na podstawie analizy naszej firmy o nazwie XYZ, Inc.

Zbieranie informacji

Opierając się na informacjach uzyskanych w trakcie pasywnego badania hostów w tej sieci, można wyprowadzić następujące wnioski dotyczące ogólnego bezpieczeństwa sieci. Te urządzenia odkryto bez wcześniejszej znajomości infrastruktury sieci (patrz rysunek 4.1).

Rysunek 4.1. Dane o infrastrukturze zebrane w fazie zbierania informacji

Sieć rozległa WAN obejmuje grupę Frame Relay ze stałymi kanałami wirtualnymi (Permanent Virtual Circuit — PVC) do Chicago, Milwaukee, Phoenix i Orlando (tabela 4.1). Frame Relay daje wielu sieciom możliwość współdzielenia sieci WAN i dostępnego pasma. Frame Relay kosztuje zwykle mniej niż dwupunktowe łącza dzierżawione. Bezpośrednie łącza dzierżawione cechują się kosztem zależnym od odległości między dwoma punktami końcowymi, podczas gdy abonenci Frame Relay są obciążani kosztami zależnymi od alokacji wymaganej przepustowości. Abonent Frame Relay współdzieli z innymi abonentami router, jednostkę obsługi danych (Data Service Unit — DSU) oraz przepustowość sieci szkieletowej, co redukuje koszty użytkowania. Kanały PVC umożliwiają sesje komunikacyjne wykorzystywane do częstej transmisji danych między urządzeniami DTE przez Frame Relay. Pojedyncze, dedykowane, dwupunktowe łącze dzierżawione T1 zapewnia dostęp do Internetu z centrali firmy w Chicago (patrz rysunki 4.2 i 4.3).

Tabela 4.1. Przykładowe dane o sieci WAN (patrz rysunek 4.3)

	Router	Serwer WWW/DNS	Proxy/Firewall	SMTP
Chicago
Adres IP	xxx.xxx.xxx.xx	xxx.xxx.xxx.xxx (witryna internetowa)	xxx.xxx.xxx.xxx (na zewnątrz)	xxx.xxx.xxx.xxx
Bramka	xxx.xxx.xxx.xxx	xxx.xxx.xxx.xxx	xxx.xxx.xxx.xxx
DNS	xxx.xxx.xxx.xxx	xxx.xxx.xxx.xxx	xxx.xxx.xxx.xxx
Użytkownicy
Adres IP	xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx
Bramka	xxx.xxx.xxx.xxx
DNS	xxx.xxx.xxx.xxx
Milwaukee
Użytkownicy
Adres IP	xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx
Bramka	xxx.xxx.xxx.xxx
DNS	xxx.xxx.xxx.xxx
Phoenix
Użytkownicy
Adres IP	xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx
Bramka	xxx.xxx.xxx.xxx
DNS	xxx.xxx.xxx.xxx
Orlando
Użytkownicy
Adres IP	xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx
Bramka	xxx.xxx.xxx.xxx
DNS	xxx.xxx.xxx.xxx
WYNIKI
Całkowita liczba słabych punktów	93
Wysokie ryzyko	3
Średnie ryzyko	10
Niskie ryzyko	80

Rysunek 4.2. Ogólny widok z zebranymi danymi o infrastrukturze sieci WAN

Rysunek 4.3. Szczegółowy widok z zebranymi danymi o infrastrukturze sieci WAN

Analiza hosta

W oparciu o informacje zebrane podczas pasywnego badania hosta można przedstawić poniższe konkluzje na temat jego ogólnego zabezpieczenia.

• Główne zagrożenia — istnieją bardzo poważne słabe punkty, które mają wpływ na integralność systemu, obsługę kont, uwierzytelnianie oraz dostępność.

• Implementacja — wrażliwość tego hosta jest spowodowana głównie problemami z wdrożeniem oprogramowania. Należy przyjrzeć się temu komputerowi, aby upewnić się, czy są zainstalowane wszystkie niezbędne poprawki zabezpieczające producentów oprogramowania.

Raport dla hosta 172.29.44.5 Poniżej znajduje się raport dla hosta 172.29.44.5 z diagramu na rysunku 4.3 oraz tabeli 4.1. Ostrzeżenie! Ten host jest w sieci całkowicie zagrożony! Odkryto, iż poniższy host (172.29.44.5) charakteryzuje się wrażliwością o wysokim ryzyku, co ma wpływ na integralność systemu (patrz tabela 4.2). Jest całkiem prawdopodobne, iż zdalny napastnik może przejąć całkowitą kontrolę nad tym systemem i wykorzystać go do uzyskania dostępu do innych zasobów w sieci. Wiele znaczących słabych punktów tego systemu można łatwo wykorzystać, co oznacza, iż napastnik nie musi wkładać w to dużo wysiłku. Niektóre zidentyfikowane słabe punkty są popularne, dlatego mogą być z łatwością wykryte przez automatyczne programy skanujące wykorzystywane przez hakerów internetowych.
	Tabela 4.2. Słabe punkty hosta
		Host	Sieć
	Wysokie ryzyko	2 słabe punkty	3 słabe punkty
	Średnie ryzyko	2 słabe punkty	10 słabych punktów
	Niskie ryzyko	9 słabych punktów	80 słabych punktów

Analiza wrażliwości

Badanie wskazuje, iż ten system cechują następujące słabe punkty. Podzielono je na klasy, reprezentujące różne usługi oraz możliwe skutki wielu różnych problemów.

Zbieranie informacji, 1001:Finger
Sprawdzanie kontroli dostępu

Finger to sieciowa usługa informacyjna, która dostarcza danych o użytkownikach systemu. Dane przedstawiane przez tę usługę są często wrażliwe i mogą być użyte przez napastnika w celu lepszego skoncentrowania ataku wykorzystującego monitorowanie osób pracujących w systemie. Czynnik ryzyka: niski i średni.

• Stopień trudności naprawy: łatwy.

• Popularność ataku: popularny.

• Skomplikowanie ataku: niskie.

• Przyczyna wystąpienia: implementacja.

• Wpływ ataku: szpiegostwo.

Rozszerzony opis. Funkcja sprawdzania kontroli dostępu próbuje się skontaktować z demonem finger w docelowym systemie w celu uzyskania listy zalogowanych użytkowników.

Kwestie związane z bezpieczeństwem. Usługa finger może dostarczyć osobom z zewnątrz wielu informacji, takich jak:

• prawdziwe nazwiska i numery telefonów użytkowników,

• katalog macierzysty użytkownika i powłoka logowania,

• okres bezczynności użytkownika,

• kiedy użytkownik po raz ostatni odczytał pocztę,

• zdalny host, z którego zalogował się użytkownik.

Oprócz odkrycia prywatnych lub potencjalnie wrażliwych informacji niektóre dane zebrane za pomocą usługi finger mogą być użyte przez napastnika do wysnucia wniosków o relacjach zaufania między hostami w Twojej sieci, zebrania nazw użytkowników w celu wykonania próby odgadnięcia hasła, uzyskania numerów telefonicznych w celu przeprowadzenia ataków z wykorzystaniem inżynierii społecznej, a także do monitorowania aktywności Twojego systemu.

Sugestie

Jeśli demon usługi finger nie jest wymagany, możesz go wyłączyć, edytując plik konfiguracyjny /etc/inetd.conf oraz oznaczając właściwą linię jako komentarz. Kolejnym krokiem jest zrestartowanie inetd z nowymi informacjami konfiguracji przy użyciu poniższego polecenia:

# /bin/kill -HUP <identyfikator PID inetd>

Jeśli nie chcesz całkowicie wyłączać usługi finger, możesz zastąpić program fingerd inną wersją, która ogranicza zakres udostępnianych informacji.

Wiele instalacji używa fingera jako sposobu sprawdzania systemów oraz ustalania niezbędnych informacji. W takiej sytuacji lub w przypadku dowolnego programu, który ma być uruchamiany z demona inetd, dobrym pomysłem jest instalacja osłon TCP (TCP wrappers — patrz rozdział 1.). Osłony pozwalają na ograniczanie (w zależności od adresu IP lub nazwy hosta) osób, które mają możliwość pytania demona finger. W czasie skanowania ten port zostanie pokazany jako aktywny, ale jeśli dany host nie może uzyskać dostępu do tej usługi, port odrzuci połączenie, nie udostępniając żadnych informacji. Osłony TCP zapewniają także o wiele bardziej szczegółowe informacje dla usługi syslog niż normalny demon. Dlatego też warto zainstalować osłony TCP na każdej usłudze, którą chcesz uruchamiać z inetd.

Zbieranie informacji, 1006: Telnet
Obecny baner (wizytówka) usługi

Rozszerzony opis. Moduł banera usługi Telnet uzyskuje i wyświetla baner Telnetu, uzyskany z docelowego hosta w czasie łączenia się z usługą Telnet.

Kwestie związane z bezpieczeństwem. Jeśli twój baner Telnetu zawiera informacje identyfikujące system operacyjny, może to być użyte do przeprowadzenia ataków na konkretny system.

Sugestie

Jeśli jesteś zaniepokojony informacjami wyświetlanymi przez komunikaty Telnetu, dokonaj edycji poniższych plików w celu zmiany zawartości tychże komunikatów:

/etc/issue

/etc/issue.net

/etc/gettytab

/bin login sources

Dodatkowo, jeśli udostępniasz usługę Telnet, powinieneś umożliwić dostęp tylko tym lokalizacjom, z których oczekujesz zdalnego logowania. Możliwa jest konfiguracja osłon TCP w celu ograniczenia dostępu demona internetowego tylko dla zaakceptowanych zdalnych hostów; możesz tego dokonać, edytując zasady dostępu w poniższych plikach:

/etc/host.allow

/etc/host.deny

Wynik:

UNIX System V Release 3.2 (scosysv.tigertools.net) (ttyp0)

Zbieranie informacji, 1024: Trasowanie
Odczytana tabela

Rozszerzony opis. Tabela trasowania została odczytana z demona trasowania docelowego hosta. Ta usługa wykorzystuje protokół Routing Information Protocol (RIP) do utrzymania aktualnej listy tras oraz informacji o trasowaniu dla hosta, na którym została uruchomiona.

Kwestie związane z bezpieczeństwem. Zewnętrzny dostęp do tabeli trasowania ujawnia znaczącą liczbę informacji o wewnętrznej strukturze sieci, co może być użyte do przygotowania ataku na Twoje systemy.

Sugestie

Filtruj wszystkie żądania do demona trasowania w bramie internetowej. Zabezpieczy to także Twoją sieć przed hakerami, którzy próbują dopisać fałszywe wpisy trasowania do Twoich hostów.

Wynik:

RIPv1 24 bytes

172.29.44.0 metric 1

Skanowanie portu sieciowego, 21001: Skanowanie portu TCP

Rozszerzony opis. Ta funkcja skanuje docelowy host pod kątem nasłuchujących portów TCP.

Kwestie związane z bezpieczeństwem. Na podstawie Twojej tabeli trasowania hakerzy mogą zidentyfikować dodatkowe sieci lub węzły, które mogą być wrażliwe na próby ataku.

Sugestie

Skaner zwróci informacje o nasłuchujących portach TCP. Sprawdź te porty, aby potwierdzić, czy działają na nich zaakceptowane usługi. Jeśli dowiesz się, że są na nich uruchomione nieudokumentowane usługi lub usługi, których nie potrzebujesz, możesz je wyłączyć. Wiele systemów operacyjnych instaluje się z ogromną liczbą usług, które nie są wymagane do normalnego działania. W niektórych przypadkach te usługi mogą zawierać znane lub nieznane problemy z zabezpieczeniami. Należy wyłączyć wszystkie funkcje, które nie są wymagane.

Wynik:

TCP Port 7 (echo) active

TCP Port 9 (discard) active

TCP Port 13 (daytime) active

TCP Port 19 (chargen) active

TCP Port 21 (ftp) active

TCP Port 23 (telnet) active

TCP Port 25 (smtp) active

TCP Port 37 (time) active

TCP Port 79 (finger) active

TCP Port 512 (exec) active

TCP Port 513 (login) active

TCP Port 514 (cmd) active

Inspekcja lokalnej infrastruktury

Ta część przedstawia wyjaśnienie, które wspomaga analizę segmentu sieci LAN między dwoma segmentami Token Ring i Ethernet. Ten proces analizy sieci, jeśli jest używany z różnymi adresami, protokołami i filtrami wzorców danych, umożliwia szybkie i efektywne wychwycenie zdarzeń powodujących problemy sieciowe.

Ten proces jest związany z zapisywaniem pakietów do plików w czasie rzeczywistym. W tym przykładzie pliki spowodowały wygenerowanie około 85 MB danych. Na podstawie tych plików oraz analizy zgromadzono podane informacje.

Zbieranie informacji

Główne wykryte jednostki, które wzięły udział w tej sesji analizy IP, obejmują adresy IP od 172.29.44.1 aż do 172.29.44.253. Zbadane urządzenia to m.in. serwery, drukarki, stacje robocze, AS400 oraz router (patrz rysunek 4.4).

Podział ruchu według rodziny protokołów

Wykres z podziałem ruchu według rodziny protokołów został przedstawiony na rysunku 4.5. w postaci procentowego rozbicia według protokołów używanych w czasie okresu przechwytywania. Każda ramka jest umieszczana w odpowiedniej rodzinie protokołu. Jeśli do ramki odnosi się więcej niż jeden protokół, jest ona umieszczana w kategorii zależnej od najwyższego analizowanego protokołu; dla przykładu ramka TCP/IP kapsułkowana przez Frame Relay zostanie oznaczona jako TCP/IP, a wszystkie bajty w tej ramce zostaną wliczone do procentu TCP/IP.

Rysunek 4.4. Zbieranie informacji w czasie sesji lokalnej
Rysunek 4.5. Podział ruchu według rodziny protokołów

W oparciu o wykres na rysunku 4.6 dokonano procentowego rozbicia protokołów, co pokazano w tabeli 4.3.

Rysunek 4.6. Rozbicie procentowe wykorzystywanych protokołów

Tabela 4.3. Rozbicie procentowe wykorzystywanych protokołów

TCP/IP	IPX	NETBEUI	Błędne
48,2	43,4	4,8	3,6

Akceptowalny poziom błędnych pakietów to około 5 procent. Niektóre z wykrytych błędnych pakietów to:

• zamrożone klatki — wskazują zawieszoną aplikację lub niedziałającą stację roboczą,

• retransmisja pliku — wskazuje, iż cały plik lub jego część musi zostać ponownie przesłany, dzieje się tak zwykle w przypadku aplikacji, która nie wykorzystuje efektywnie sieci,

• niska przepustowość — wskazuje, iż średnia przepustowość w czasie transferu plików to 22 kb/s,

• przekierowanie hosta — wskazuje stacje otrzymujące komunikat ICMP redirect message, co oznacza, iż bramka lub router wysłał ten komunikat, aby poinformować stacje o istnieniu lepszej trasy lub o braku dostępności wybranej trasy.

Całkowite wykorzystanie pasma

Ta część obejmuje rozbicie całkowitego wykorzystania pasma według monitorowanych segmentów w czasie okresu analizy (patrz rysunek 4.7). Na podstawie zebranych danych uzyskano informację o wielkości transakcji w megabajtach, co pokazano w tabeli 4.4.

Rysunek 4.7. Całkowite wykorzystanie pasma

Tabela 4.4. Transakcje w megabajtach

Okres	7:00 - 10:00	10:00 - 13:00	13:00 - 16:00	16:00 - 19:00
Prędkość transferu (w Mb/s)	271,8	483,2	510,8	134,9
Procent	19,5%	34,4%	36,5%	9,6%

Przeciętne wykorzystanie pasma

Wykres na rysunku 4.8 przedstawia przeciętne pasmo wykorzystane przez monitorowane łącze sieci LAN w czasie sesji analizy. Na podstawie tych danych można zalecić zwiększenie przepustowości i produktywności. Ten wykres pozwala także na obliczenie przeciętnego wykorzystania pasma — wartość ta wynosi około 78 procent. Warto wspomnieć, iż zalecane przeciętne wykorzystanie pasma powinno mieścić się w zakresie od 45 do 55 procent. Zapewnia to wystarczająco dużą przestrzeń na zwiększony, błędny i skalowalny ruch (uwaga: dane zebrane do celów tego rozbicia nie obejmują procentu dla błędnego ruchu).

Rysunek 4.8. Przeciętne wykorzystanie pasma

Procent wykorzystania pasma przekroczył próg o 28 punktów procentowych, osiągając wartość 78 procent. Rekomendowane przeciętne wykorzystanie pasma powinno mieścić się w zakresie od 45 do 55 procent.

Alarmy i progi

Wykres na rysunku 4.9 wskazuje jednostki, które przekroczyły progi, co spowodowało wywołanie alarmów przeciążenia.

Alarmy wskazują tych użytkowników i urządzenia infrastruktury, które z powodu niemożności użycia wymagają segmentacji i kontroli kolidujących domen.

Błędy pakietów

Błąd pakietów sygnalizuje, iż występuje błąd sygnalizacji w okablowaniu sieci. Jest to typowy problem, często spowodowany przez uszkodzone lub niewłaściwe kable, instalowane przez „profesjonalistów” bez odpowiednich certyfikatów. Wystąpienie błędu pakietów jest przedstawione na wykresie na rysunku 4.10.

		Błędy pakietów są bardzo poważne, dlatego też należy rozwiązać problem tak szybko, jak to jest możliwe. Głównym źródłem kłopotów jest serwer.
Rysunek 4.9. Alarmy i progi

Rysunek 4.10. Błędy pakietów

Limity czasu i kolizje

Kolizja jest wynikiem podjęcia przez dwa lub więcej węzłów próby użycia w tym samym czasie nośnika segmentu Eethernetu. Kiedy zdarza się kolizja, wszystkie jednocześnie transmitujące stacje robocze kontynuują przesyłanie przez krótki okres czasu (wystarczająco długi, aby wysłać od 4 do 6 bajtów). To opóźnienie jest niezbędne, aby wszystkie stacje dowiedziały się o powstaniu kolizji. Wszystkie stacje w sieci wywołują następnie algorytm usuwania kolizji, który generuje losową liczbę. Ta liczba określa czas, przez jaki stacje nie podejmują transmisji. Dla każdej stacji sieciowej wylosowany czas powinien się różnić. Wykres przedstawiający wystąpienie kolizji jest przedstawiony na rysunku 4.11.

Rysunek 4.11. Kolizje

Błędy wewnętrzne: sieć i symptomy

Błąd wewnętrzny odnosi się do stacji zgłaszającej wewnętrzny błąd, który można naprawić. Jeśli dana stacja zgłasza wiele błędów wewnętrznych, uznaje się ją za marginalną. Wykres błędów wewnętrznych jest przedstawiony na rysunku 4.12.

Rysunek 4.12. Wewnętrzne błędy według sieci i symptomów

W tej części należy dokonać podziału według stacji sieciowych i symptomów zbadanych w okresie analizy, włączając w to liczbę błędów lub symptomów. Niektóre z wykrytych symptomów obejmują:

• zamrożone klatki — wskazują zawieszoną aplikację lub niedziałającą stację roboczą,

• retransmisja pliku — wskazuje, iż cały plik lub jego część musiał zostać ponownie przesłany, dzieje się tak zwykle w przypadku aplikacji, która nie wykorzystuje efektywnie sieci,

• niska przepustowość — wskazuje, iż średnia przepustowość w czasie transferu plików to 22 kb/s,

• przekierowanie hosta — wskazuje stacje otrzymujące komunikat ICMP redirect message, co oznacza, iż bramka lub router wysłał ten komunikat, aby poinformować stacje o istnieniu lepszej trasy lub o braku dostępności wybranej trasy.

Rekomendacje dotyczące infrastruktury

Na podstawie zebranych danych zaleca się wykonanie strategicznej alokacji jednostek sprawiających problemy w każdym segmencie, ustanawiając odpowiednie priorytety. Takie balansowanie obciążaniem spowoduje poprawną alokację użytkowników oraz dystrybucję wykorzystywanego pasma w równych częściach dla poszczególnych segmentów. Aby zminimalizować przeciążenie IP/IPX, które powoduje około 78 procent zgłaszanych problemów, należy użyć nowego schematu adresowania IP oraz przebudować stos protokołów. Powinno to spowodować usunięcie problemów z przeciążeniem w segmentach sieciowych. Zalecana jest również optymalizacja routera między segmentami Ethernet i Token Ring przy użyciu trasowania AppleTalk.

Rekomendowana konfiguracja stacji sieciowych obejmuje:

• IP (DHCP),

• IPX/SPX,

• NetBIOS przez IPX/SPX,

• domyślną bramę,

• usługi nazw domen.

Szczegółowe badanie prowadzi do przedstawienia rekomendacji dla demona serwera DNS na serwerze NT, a także szczegółowego zakresu DHCP. Zaleca się również przebudowanie demona SQL serwera NT oraz stosu protokołów, a także implementację poprawki rejestru w celu usunięcia wycieków z pamięci oraz zabezpieczenia przed potencjalnym zawieszeniem pamięci wirtualnej.

Poniższa lista stanowi podsumowanie raportu analizy, przedstawiając zalecenia dotyczące rozwiązania problemów.

Serwer NT

• Przebudowa demona SQL serwera NT.

• Poprawka rejestru IPX serwera NT.

• Przebudowa stosu protokołów serwera NT.

• Konfiguracja usługi nazw domen DNS (do 25 stacji).

1. Utworzenie strefy głównej.

2. Dodanie wpisów adresów aliasów stacji.

3. Przeładowanie tabeli zapełnienia DNS.

Konfiguracja zakresu DHCP (do 25 stacji)

1. Utworzenie głównego zakresu.

4. Konfiguracja nowego schematu IP.

5. Konfiguracja rezerwacji dla stacji:

• nazwa stacji,

• adres IP,

• adres MAC.

Router

• Optymalizacja trasy.

1. Konfiguracja nowego schematu IP.

6. Weryfikacja i modyfikacja tras IP.

• Konfiguracja AppleTalk.

1. Konfiguracja trasowania AppleTalk.

7. Utworzenie stref.

8. Weryfikacja i modyfikacja tras.

Sieć

Tworzenie schematu IP dla sieci Ethernet i Token Ring.

• Utworzenie schematu IP oraz właściwej podsieci:

• alokacja schematu IP,

• kształtowanie ruchu i priorytety IP.

• Konfiguracja serwerów, routerów i przełączników dla priorytetów Token Ring.

Stacje robocze

Implementacja nowej konfiguracji na 25 stacjach sieciowych, co obejmuje:

• IP (DHCP),

• IPX/SPX,

• NetBIOS przez IPX/SPX,

• domyślną bramę,

• usługi nazw domen.

Inspekcja sieci rozległej WAN

Poniższy raport przedstawia usługi wykonywane w czasie inspekcji sieci rozległej WAN. Sesja monitorowania sieci WAN badała segment WAN z lokalizacji A do lokalizacji B oraz łącze zewnętrzne do Internetu. Taki proces monitorowania, zastosowany przy użyciu różnych adresów, protokołów i filtrów usług, pozwala na dokładne i skuteczne wychwycenie wszystkich obszarów powodujących problemy sieciowe wraz z alarmami warstwowymi. Taki proces pozwala na monitorowanie w czasie rzeczywistym. Lokalne i zdalne oprogramowanie do zarządzania umożliwia niezbędne monitorowanie i rozwiązywanie problemów związanych z urządzeniami sieciowymi LAN i WAN.

Zbieranie informacji

Odkryto następujące główne jednostki, które wzięły udział w sesji monitorowania: adresy IP pomiędzy 206.12.15.232 a 206.12.15.238, a także NS1, NS2, IIS1, IIS2, IIS3, C6400, SQL1, EXCH2, IIS4, SQL3 oraz routery i przełączniki NetScreen, Cisco i Cabletron. Wykryte urządzenia to serwery, przełączniki i routery.

Alarmy i progi

Funkcja monitorowania śledzi w czasie rzeczywistym cały ruch HTTP, FTP, POP3, SMTP i NNTP, a także samodzielnie zdefiniowane informacje o dostępie do lokalizacji. Inne monitorowane dane obejmują w formie podsumowania obciążenie sieci, liczbę oraz częstotliwość dostępu każdego użytkownika, a także odrzucone próby dostępu.

Analiza wywołanych alarmów, przedstawionych na liście na kolejnych stronach, obejmuje restartowanie serwera, optymalizację serwera (wydajność i procesor), zwiększenie bufora routera, resetowanie interfejsów oraz zastąpienie połączonych ze sobą w sieć hubów przez przełącznik Cisco Catalyst. Takie zmiany infrastruktury wyeliminowały około 80 procent krytycznych alarmów.

• Host nie odpowiada — wskazuje wyłączony serwer lub interfejs.

• Usługa nie odpowiada — wskazuje, iż wyłączony, nadmiernie wykorzystywany, niezoptymalizowy lub zawieszony demon serwera usług korzysta z zarezerwowanych portów.

• Zamrożenie klatek — wskazuje zawieszoną aplikację lub niedziałającą stację.

• Retransmisja pliku — wskazuje, iż cały plik lub jego część musi zostać ponownie przesłany, dzieje się tak zwykle w przypadku aplikacji, która nie wykorzystuje efektywnie sieci.

• Niska przepustowość — wskazuje, iż średnia przepustowość w czasie transferu plików to 22 kb/s.

• Przekierowanie hosta — wskazuje stacje otrzymujące komunikat ICMP redirect message, co oznacza, iż bramka lub router wysłał ten komunikat, aby poinformować stacje o istnieniu lepszej trasy lub o braku dostępności wybranej trasy.

• Przeciążenie sieci LAN — wskazuje przeciążenie zwykle spowodowane przez kolizje i połączone ze sobą lub nadmiernie wykorzystywane huby (patrz rysunek 4.13).

Rysunek 4.13. Przeciążenie sieci LAN

Router internetowy natknął się na 701 328 kolizji oraz 672 przypadki przeciążenia sieci LAN w czasie pięciodniowej sesji inspekcji, co pokazano na poniższej liście. Odkryto następujące główne jednostki, które wzięły udział w sesji monitorowania: adresy IP pomiędzy 206.12.15.232 a 206.12.15.238, a także NS1, NS2, IIS1, IIS2, IIS3, C6400, SQL1, EXCH2, IIS4, SQL3 oraz routery i przełączniki NetScreen, Cisco i Cabletron. Wykryte urządzenia to serwery, przełączniki i routery.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/29/00 23:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:53	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 23:53	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:53	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:53	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 23:43	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 23:43	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 23:40	3	Router lost connection to 10.15.0.5.Packet send from 10.15.0.1
Acked	11/29/00 23:33	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 23:33	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:33	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:33	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 23:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:23	1	Host 206.12.15.234's HTTP(WWW) service failed to respond.
Acked	11/29/00 23:23	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 23:23	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 23:23	1	Host 206.12.15.232's HTTP(WWW) service failed to respond.
Acked	11/29/00 23:23	1	Host iis2(10.15.1.54)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 23:23	1	Host iis1(10.15.1.55)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 23:13	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:13	1	Host 206.12.15.234's HTTP(WWW) service failed to respond.
Acked	11/29/00 23:13	1	Host 206.12.15.236's SMTP service failed to respond.
STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/29/00 23:13	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 23:13	1	Host 206.12.15.232's HTTP(WWW) service failed to respond.
Acked	11/29/00 23:13	1	Host iis2(10.15.1.54)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 23:13	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:13	1	Host iis1(10.15.1.55)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 23:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:03	1	Host 206.12.15.234's HTTP(WWW) service failed to respond.
Acked	11/29/00 23:03	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 23:03	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 23:03	1	Host 206.12.15.232's HTTP(WWW) service failed to respond.
Acked	11/29/00 23:03	1	Host iis2(10.15.1.54)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 23:03	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 23:03	1	Host iis1(10.15.1.55)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 22:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 22:53	1	Host 206.12.15.234's HTTP(WWW) service failed to respond.
Acked	11/29/00 22:53	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 22:53	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 22:53	1	Host 206.12.15.232's HTTP(WWW) service failed to respond.
Acked	11/29/00 22:53	1	Host iis2(10.15.1.54)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 22:53	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 22:53	1	Host iis1(10.15.1.55)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 22:43	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 22:43	1	Host 206.12.15.234's HTTP(WWW) service failed to respond.
Acked	11/29/00 22:43	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 22:43	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 22:43	1	Host 206.12.15.232's HTTP(WWW) service failed to respond.
Acked	11/29/00 22:43	1	Host iis2(10.15.1.54)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 22:43	1	Host iis1(10.15.1.55)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 22:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4648. Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4648. Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	1	Host 206.12.15.236's SMTP service failed to respond.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4648. Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	1	Host 206.12.15.236's FTP service failed to respond.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4648.Packet sent from 10.250.1.13.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4648.Packet sent from 10.250.1.13.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4648.Packet sent from 10.250.1.13.
STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4640.Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	1	Host 206.12.15.232's HTTP(WWW) service failed to respond.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4640.Packet sent from 10.250.1.13.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4641.Packet sent from 10.250.1.13.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4641.Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4641.Packet sent from 10.250.1.13.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4640.Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4641.Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4640.Packet sent from 208.0.121.2.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4640.Packet sent from 10.250.1.13.
Acked	11/29/00 22:33	3	10.15.0.1 does not listen at port 4640.Packet sent from 10.250.1.13.
Acked	11/29/00 22:33	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 22:33	1	Host iis2(10.15.1.54)'s HTTP(WWW) service failed to respond.
Acked	11/29/00 22:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 22:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 21:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 21:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 21:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 21:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 20:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 20:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 20:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 20:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 19:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/29/00 19:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 19:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 19:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 18:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 18:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 18:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 18:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 17:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 17:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 17:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 16:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 16:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 15:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 15:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 15:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 15:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 14:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 14:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 14:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 14:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 13:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 13:46	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 13:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 13:32	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 13:29	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 13:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 13:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 12:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 12:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 12:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 12:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 11:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 11:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 11:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 11:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 10:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 10:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 10:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 10:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 9:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 9:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/29/00 9:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 8:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 8:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 8:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 8:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 7:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 7:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 7:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 7:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 6:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 6:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 6:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 6:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 5:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 5:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 5:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 5:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 4:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 4:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 4:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 4:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 3:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 3:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 3:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 3:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 2:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 2:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 2:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 2:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 1:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 1:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 1:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 1:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 0:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 0:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 0:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/29/00 0:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 22:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 23:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 23:35	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.0.139.83 is dropped because router 10.15.0.1 cannot deliver to 206.0.139.83.
STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.0.139.83 is dropped because router 10.15.0.1 cannot deliver to 206.0.139.83.
Acked	11/28/00 23:31	1	Host NS1(208.0.121.2) failed to respond.
Acked	11/28/00 23:31	1	Host 206.12.15.234 failed to respond.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.234 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.234.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 208.0.121.2 is dropped because router 10.15.0.1 cannot deliver to
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 208.0.121.2 is dropped because router 10.15.0.1 cannot deliver to 208.0.121.2.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 208.0.121.2 is dropped because router 10.15.0.1 cannot deliver to 208.0.121.2.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 208.0.121.2 is dropped because router 10.15.0.1 cannot deliver to 208.0.121.2.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.234 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.234.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.234 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.234.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.237 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.237.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.236 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.236.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.237 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.237.
Acked	11/28/00 23:31	1	Host 206.12.15.237 failed to respond.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.237 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.237.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.237 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.237.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.234 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.234.
Acked	11/28/00 23:31	1	Host 206.12.15.236 failed to respond.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.238 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.238.
Acked	11/28/00 23:31	1	Host site1.targetsite.com(206.12.15.238) failed to respond.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.236 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.236.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.236 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.236.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.236 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.236.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.12.15.238 is dropped because router 10.15.0.1 cannot deliver to 206.12.15.238.
Acked	11/28/00 23:31	3	Packet sent from 10.15.0.1 to 206.0.139.83 is dropped bacause router 10.15.0.1 cannot deliver to 206.0.139.83.
Acked	11/28/00 23:31	1	Host 206.12.15.232 failed to respond.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/28/00 23:30	1	Host fastfrog.com(206.12.15.233) failed to respond.
Acked	11/28/00 23:21	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 23:20	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 23:20	1	Host NS1(208.0.121.2) failed to respond.
Acked	11/28/00 23:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 23:05	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 22:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 22:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 22:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 22:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 21:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 21:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 21:37	3	10.15.0.1 does not listen at port 161.Packet sent from 10.1.1.45.
Acked	11/28/00 21:37	3	10.15.0.1 does not listen at port 161.Packet sent from 10.1.1.45.
Acked	11/28/00 21:37	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 21:25	1	Host site1.targetsite.com(206.12.15.238) failed to respond.
Acked	11/28/00 21:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 20:55	1	Host NS1(208.0.121.2) failed to respond.
Acked	11/28/00 20:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 20:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 20:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 19:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 19:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 18:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 18:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 18:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 18:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 17:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 17:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 17:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 17:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 16:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 16:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 16:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 16:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 15:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 15:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 15:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 15:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 14:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/28/00 14:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 14:25	1	Host compaq6400(10.15.1.81) failed to respond.
Acked	11/28/00 14:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 13:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 13:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 13:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 13:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 12:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 12:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 12:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 12:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 11:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 11:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 11:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 11:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 10:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 10:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 10:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 10:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 9:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 9:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 9:25	1	Host NS1(208.0.121.2) failed to respond.
Acked	11/28/00 9:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 8:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 8:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 8:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 8:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 7:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 7:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 7:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 7:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 6:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 6:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 6:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 6:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 5:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 5:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 5:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 5:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 4:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 4:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/28/00 3:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 3:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 3:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 3:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 2:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 2:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 2:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 2:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 1:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 1:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 1:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 1:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 0:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 0:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 0:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/28/00 0:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 23:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 23:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 23:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 23:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 22:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 22:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 22:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 22:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 21:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 21:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 21:36	3	10.15.0.1 does not listen at port 161.Packet sent from 10.1.1.45.
Acked	11/27/00 21:36	3	10.15.0.1 does not listen at port 161.Packet sent from 10.1.1.45.
Acked	11/27/00 21:36	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 21:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 21:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 20:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 20:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 20:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 20:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 19:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 19:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 19:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 19:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 18:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/27/00 18:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 18:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 18:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 17:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 17:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 17:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 17:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 16:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 16:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 16:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 16:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 15:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 15:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 15:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 15:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 14:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 14:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 14:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 14:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 13:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 13:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 13:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 13:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 12:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 12:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 12:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 12:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 11:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 11:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 11:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 11:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 10:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 10:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 10:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 10:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 9:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 9:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 9:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 9:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 8:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 8:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/27/00 8:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 8:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 7:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 7:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 7:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 7:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 6:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 6:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 6:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 6:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 5:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 5:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 5:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 5:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 5:07	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 5:07	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 5:07	1	Host NS1(208.0.121.2) failed to respond.
Acked	11/27/00 4:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 4:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 4:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 4:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 3:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 3:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 3:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 3:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 2:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 2:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 2:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 2:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 1:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 1:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 1:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 1:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 0:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 0:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 0:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/27/00 0:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 23:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 23:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 23:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 23:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/26/00 23:04	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:57	1	Host iis1(10.15.1.55)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 22:56	1	Host 206.12.15.234's HTTP(WWW) service failed to respond.
Acked	11/26/00 22:56	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:56	1	Host iis1(10.15.1.55)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 22:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:51	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:38	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:35	3	10.15.0.1 does not listen at port 1986.Packet sent from 10.250.1.13.
Acked	11/26/00 22:35	3	10.15.0.1 does not listen at port 1986.Packet sent from 208.0.121.2.
Acked	11/26/00 22:35	3	10.15.0.1 does not listen at port 1986.Packet sent from 10.250.1.13.
Acked	11/26/00 22:35	3	10.15.0.1 does not listen at port 1986.Packet sent from 208.0.121.2.
Acked	11/26/00 22:26	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:26	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:26	1	Host sq(10.15.1.61) failed to respond.
Acked	11/26/00 22:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:19	3	10.15.0.1 does not listen at port 1986.Packet sent from 208.0.121.2.
Acked	11/26/00 22:19	3	10.15.0.1 does not listen at port 1986.Packet sent from 208.0.121.2.
Acked	11/26/00 22:19	3	10.15.0.1 does not listen at port 1986.Packet sent from 10.250.1.13.
Acked	11/26/00 22:19	3	10.15.0.1 does not listen at port 1986.Packet sent from 10.250.1.13.
Acked	11/26/00 22:19	3	10.15.0.1 does not listen at port 1986.Packet sent from 10.250.1.13.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 209.67.45.225.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 209.67.45.225.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 209.67.45.225.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.32.132.110.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.32.132.110.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.32.132.110.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.32.173.226.Packet sent from 10.15.0.1 to 206.0.139.67.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.32.173.226.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.32.173.226.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.33.64.84.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.33.64.84.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.33.64.84.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	206.12.15.226 does not listen at port 137.Packet from 10.15.0.1.
Acked	11/26/00 22:18	3	206.12.15.226 does not listen at port 137.Packet from 10.15.0.1.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.12.15.226.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.12.15.226.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	206.12.15.226 does not listen at port 137.Packet from 10.15.0.1.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 216.12.15.226.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 10.251.0.2.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 10.251.0.2.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 10.251.0.2.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 10.15.0.1.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 10.15.0.1.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:18	3	10.15.0.1 does not listen at port 137.Packet sent from 10.1.1.45.
Acked	11/26/00 22:18	3	TTL expired when packet arrived at 10.15.0.1.Packet sent from 10.15.0.1 to 206.0.139.67.
Acked	11/26/00 22:12	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 22:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 21:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 21:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 21:38	3	10.15.0.1 does not listen at port 161.Packet from 10.1.1.45.
Acked	11/26/00 21:38	3	10.15.0.1 does not listen at port 161.Packet from 10.1.1.45.
Acked	11/26/00 21:38	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 21:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 21:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 20:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 20:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/26/00 20:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 20:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 19:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 19:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 19:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 19:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 18:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 18:49	1	Host iis4(10.15.1.62) failed to respond.
Acked	11/26/00 18:46	1	Host site1.targetsite.com(206.12.15.238) failed to respond.
Acked	11/26/00 18:46	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 18:46	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 18:46	1	Host iis4(10.15.1.62)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 18:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 18:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 18:10	1	Host site1.targetsite.com(206.12.15.238)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 18:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 17:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 17:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 17:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 17:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 16:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 16:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 16:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 16:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 15:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 15:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 15:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 15:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 15:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 14:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 14:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 14:38	1	10.15.0.1 LAN overload.
Acked	11/26/00 14:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 14:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:39	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:28	3	10.15.0.1 does not listen at port 4933.Packet sent from 208.0.121.2.
Acked	11/26/00 13:28	3	10.15.0.1 does not listen at port 4933.Packet from 10.250.1.13.
Acked	11/26/00 13:28	3	10.15.0.1 does not listen at port 4920.Packet from 10.250.1.13.
STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/26/00 13:28	3	10.15.0.1 does not listen at port 4920.Packet sent from 208.0.121.2.
Acked	11/26/00 13:28	3	10.15.0.1 does not listen at port 4918.Packet from 10.250.1.13.
Acked	11/26/00 13:28	3	10.15.0.1 does not listen at port 4918.Packet sent from 208.0.121.2.
Acked	11/26/00 13:27	3	10.15.0.1 does not listen at port 4916.Packet sent from 208.0.121.2.
Acked	11/26/00 13:27	3	10.15.0.1 does not listen at port 4916.Packet from 10.250.1.13.
Acked	11/26/00 13:27	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:15	1	Host 206.12.15.238 failed to respond.
Acked	11/26/00 13.15	1	Host iis4(10.15.1.62) failed to respond.
Acked	11/26/00 13:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:06	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:06	1	Host 206.12.15.238's HTTP(WWW) service failed to respond.
Acked	11/26/00 13:05	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 13:05	1	Host iis4(10.15.1.62)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 12:58	1	Host site1.targetsite.com(206.12.15.238)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 12:56	1	Host 206.12.15.238's HTTP(WWW) service failed to respond.
Acked	11/26/00 12:55	1	Host iis4(10.15.1.62)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 12:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 12:46	1	Host 206.12.15.238's HTTP(WWW) service failed to respond.
Acked	11/26/00 12:45	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 12:45	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 12:45	1	Host iis4(10.15.1.62)'s HTTP(WWW) service failed to respond.
Acked	11/26/00 12:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 12:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 12:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 11:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 11:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 11:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 11:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 10:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 10:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 10:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 10:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 9:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 9:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/26/00 9:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 9:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 9:09	3	207.239.35.80 does not listen at port 137.Packet from 10.15.0.1.
Acked	11/26/00 9:09	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:57	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:46	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:35	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 8:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 7:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 7:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 7:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 7:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 6:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 6:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 6:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 6:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 5:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 5:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 5:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 5:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 4:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 4:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 4:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 4:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 3:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 3:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 3:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 3:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 2:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 2:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 2:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 2:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 1:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 1:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 1:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 1:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 0:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/26/00 0:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 0:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/26/00 0:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 23:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 23:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 23:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 23:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 22:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 22:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 22:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 22:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 21:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 21:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 21:37	3	10.15.0.1 does not listen at port 161.Packet from 10.1.1.45.
Acked	11/25/00 21:37	3	10.15.0.1 does not listen at port 161.Packet from 10.1.1.45.
Acked	11/25/00 21:36	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 21:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 21:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 20:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 20:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 20:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 20:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 19:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 19:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 19:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 19:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 18:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 18:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 18:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 18:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 17:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 17:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 17:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 17:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 16:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 16:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 16:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 16:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 15:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 15:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 15:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

STATUS	LOG TIME	LEVEL	DESCRIPTION
Acked	11/25/00 15:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 14:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 14:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 14:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 14:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 13:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 13:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 13:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 13:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 12:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 12:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 12:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 12:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 11:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 11:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 11:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 11:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 10:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 10:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 10:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 10:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 9:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 9:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 9:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 9:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 8:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/25/00 6:58	1	Host 10.15.0.5 failed to respond.
Acked	11/24/00 23:18	1	10.15.0.1 LAN overload
Acked	11/24/00 23:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/24/00 22:55	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/24/00 22:40	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/24/00 22:25	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.
Acked	11/24/00 22:10	3	Router lost connection to 10.15.0.5. Packet sent from 10.15.0.1.

Wdrożenie zabezpieczeń

Dotarliśmy do końca książki. Omówiliśmy techniczne informacje (zarówno te dobrze znane, jak i sekretne), które tworzą podstawę technologii hakerskiej; odkryliśmy także słabe punkty osprzętu i oprogramowania, które sprawiają, iż są one wrażliwe na ataki hakerów. Omówiliśmy również techniki zespołu Tiger Team, które pozwalają na zastosowanie środków zabezpieczających przed takich atakami. Kolejnym krokiem było zbadanie zaleceń w zakresie tworzenia efektywnych zasad zabezpieczeń. Była to z pewnością ekscytująca podróż, ale prawdziwa przygoda ma się dopiero zacząć.

Nadszedł teraz czas na wykorzystanie poznanej wiedzy w praktyce, co oznacza wdrożenie własnych zabezpieczeń. Jeśli tylko interesuje Cię bezpieczeństwo domowych lub firmowych stacji roboczych i sieci, możesz użyć opisanych w tej książce technik do utworzenia zwycięskiego planu zabezpieczeń.

Przegląd analizy zabezpieczeń

Ślepe testowanie

Rozpoczniemy od tak zwanych ślepych testów, co oznacza zdalne testowanie bez szczegółowej wiedzy na temat infrastruktury celu. Ten etap obejmuje wymienione niżej kroki.

• Skanowanie lokalizacji. Przeprowadź fazę zbierania informacji, przeskanuj wszystkie zidentyfikowane porty, przeskanuj aplikacje w celu zidentyfikowania usług systemowych, które są powiązane w wykrytymi portami, a także zbadaj poziom wykorzystania portów, aby poznać słabe punkty.

• Zdalna inspekcja. Przetestuj konfigurację, stabilność i wrażliwość środków zabezpieczających, zewnętrznych usług dostawcy Internetu oraz wszystkie inne usługi sieciowe, które prowadzą przez firewall i proxy.

• Testy penetracji. Zaatakuj i oceń bezpieczeństwo fizyczne, mając na celu penetrację wszystkich elementów zidentyfikowanych w czasie skanowania lokalizacji, zdalnej inspekcji i inspekcji kodu źródłowego CGI, JavaScript i ActiveX. Zainicjuj próbę przechwycenia ODBC (bazy danych), wykonaj testy przepełniania IP oraz zainicjuj standardowe próby złamania zabezpieczeń IOS w systemach NT, Novell i UNIX. Wykonaj próbę podszycia się pod DNS oraz rozpocznij pasywną próbę podsłuchu w celu przechwycenia ruchu.

• Testy podszywania się pod adres IP i pocztę oraz testy na rozsyłanie spamu. Wykonaj atak przez penetrację w celu zmuszenia urządzeń infrastruktury do tworzenia szkodliwych wyrażeń lub udostępniania wrażliwych informacji (na przykład haseł), przetestuj możliwość wymuszenia poczty elektronicznej, uzyskania kontroli nad serwerami SMTP, POP3 i IMAP4 oraz wykorzystania pasma do wysłania dużej ilości zewnętrznych wiadomości.

Nie zapomnij, że należy dokumentować wszystkie etapy analizy zabezpieczeń!

Penetracja z wykorzystaniem wiedzy

Penetracja z wykorzystaniem wiedzy odnosi się do testów ze znajomością infrastruktury celu. Ta faza obejmuje następujące testy.

• Inspekcja schematów infrastruktury. Schemat adresowania IP/IPX, protokoły, schematy translacji adresów sieciowych i portów, informacje o połączeniach wykorzystujących linie telefoniczne (użytkownicy, numery dostępowe, metody dostępu itp.), konfiguracja systemu operacyjnego urządzeń sieciowych (IOS), uprzywilejowane punkty dostępowe, szczegółowa konfiguracja zewnętrzna (dostawca Internetu, obsługa witryny itp.).

• Skanowanie lokalizacji. Przeprowadź fazę zbierania informacji, przeskanuj wszystkie zidentyfikowane porty, przeskanuj aplikacje w celu zidentyfikowania usług systemowych, które są powiązane w wykrytymi portami, a także zbadaj poziom wykorzystania portów, aby poznać słabe punkty.

• Zdalna inspekcja. Przetestuj konfigurację, stabilność i wrażliwość środków zabezpieczających, zewnętrznych usług dostawcy Internetu oraz wszystkie inne usługi sieciowe, które prowadzą przez firewall i proxy.

• Testy penetracji. Zaatakuj i oceń bezpieczeństwo fizyczne, mając na celu penetrację wszystkich elementów zidentyfikowanych w czasie skanowania lokalizacji, zdalnej inspekcji i inspekcji kodu źródłowego CGI, JavaScript i ActiveX. Zainicjuj próbę przechwycenia ODBC (bazy danych), wykonaj testy przepełniania IP oraz zainicjuj standardowe próby crackowania IOS w systemach NT, Novell i UNIX. Wykonaj próbę podszycia się pod DNS oraz rozpocznij pasywną próbę podsłuchu w celu przechwycenia ruchu.

• Testy podszywania się pod adres IP i pocztę oraz testy na rozsyłanie spamu. Wykonaj atak przez penetrację w celu zmuszenia urządzeń infrastruktury do tworzenia szkodliwych wyrażeń lub udostępniania wrażliwych informacji (na przykład haseł), przetestuj możliwość wymuszenia poczty elektronicznej, uzyskania kontroli nad serwerami SMTP, POP3 i IMAP4 oraz wykorzystania pasma do wysłania dużej ilości zewnętrznych wiadomości.

Usługi internetowe

W przypadku usług internetowych należy wykonać następujące testy.

• Wykonaj testy penetracji oraz zaatakuj i oceń bezpieczeństwo fizyczne, mając na celu penetrację wszystkich elementów zidentyfikowanych w czasie skanowania lokalizacji, zdalnej inspekcji i inspekcji kodu źródłowego CGI, JavaScript i ActiveX.

• Zainicjuj wywołania ODBC ze zidentyfikowanych baz danych.

• Wykonaj testy przepełnienia IP, HTTP i ICMP, a także próbę podszycia się pod DNS.

Inspekcja połączeń wykorzystujących linie telefoniczne

W czasie tej fazy wykonaj następujące czynności.

• Wykonaj inspekcję punktów dostępowych.

• Użyj procedur skanowania i wykrywania źle skonfigurowanych połączeń telefonicznych i serwerów terminala (PC Anywhere, Reachout lub Citrix), a także szpiegujących lub nieautoryzowanych modemów.

Inspekcja lokalnej infrastruktury

Inspekcja lokalnej infrastruktury jest kompilacją raportów poszczególnych części. Na podstawie tych danych można zarekomendować zwiększenie przepustowości i produktywności. Co najważniejsze, dzięki tej fazie powstaje raport o problemach użytkowników, który obejmuje takie kwestie, jak długi czas startu komputera, problemy z plikami i drukowaniem, małą dostępność pasma oraz samoczynne przypadki przerwania połączenia, a także podział ruchu według rodziny protokołów oraz wykryte stacje sieciowe wraz z informacjami o liczbie błędów lub objawów dla każdej stacji.

Inspekcja sieci rozległej WAN

Podobnie jak inspekcja lokalnej infrastruktury, inspekcja sieci WAN jest kompilacją raportów poszczególnych części. Znajdują się tu zebrane informacje o urządzeniach sieciowych, alarmach i progach (które śledzą w czasie rzeczywistym cały ruch HTTP, FTP, POP3, SMTP i NNTP, a także samodzielnie zdefiniowane informacje o dostępie do lokalizacji). Inne monitorowane dane obejmują w formie podsumowania obciążenie sieci, liczbę i częstotliwość dostępu każdego użytkownika, odrzucone próby dostępu, a także dzienniki alarmów i zdarzeń (wyjątki z rzeczywistych plików dzienników, zapisanych w czasie sesji analizy).

258 Hack Wars. Tom 2. Na tropie hakerów

Rozdział 4. ♦ Powiązanie mechanizmów zabezpieczających 259

258 C:\Biezace\Hack Wars\hack wars 2\9 makieta\04.doc

C:\Biezace\Hack Wars\hack wars 2\9 makieta\04.doc 259

C:\Biezace\Hack Wars\hack wars 2\9 makieta\04.doc 257

sprawdzic

---