Następnie trzeba dokonać archiwizacji wszelkich danych na stacji roboczej administratora - do późniejszej analizy. Należy też jak najszybciej dokonać audytu wszystkich kont systemowych, ze szczególnym uwzględnieniem tych, które mają uprawnienia administracyjne oraz kont nieużywanych, których ważność została wygaszona. Wszystkie hasła do takich kont muszą zostać zmienione, ponieważ nie wiadomo, czy administrator przed odejściem nie dokonał deszyfrowania haseł, których nie znał. Trzeba by jeszcze uruchomić zaawansowany audyt dostępu do kont systemowych, działając inaczej, niż nakazuje standardowa procedura, a zapisy logów kopiować automatycznie na wspomnianą stacje audytową.

W celu podwyższenia bezpieczeństwa administratorzy często korzystają z tokenów. Są to rozwiązania stosunkowo bezpieczne, ale wystarczy wykraść plik ASC zawierający dane obliczeniowe dla serwera tokenów i bezpieczeństwo dramatycznie spada. Mając do niego dostęp, dzięki odpowiedniemu oprogramowaniu, np. CAIN, możliwe jest obliczenie aktualnych wskazań tokenów. Skorzystanie z niego wymaga pewnych przygotowań, niemniej jest możliwe. Plik ASC powinien więc być szczególnie strzeżony. Najlepiej wszystkim zarejestrowanym w systemie tokenom skasować PIN i wymusić ustawienie nowego. Gdy istnieje podejrzenie, że administrator mógł skopiować plik ASC, należy wymienić wszystkie tokeny.

Gdy wszystko jest gotowe, rozsądne wydaje się jeszcze dokonanie zmiany statycznych kluczy szyfrujących, np. w mechanizmie WEP czy kluczy szyfrujących do łączy VPN, a także kluczy prywatnych serwerów. Wypadałoby również zmienić wszystkie karty chipowe i hasła dostępowe do systemów bankowości elektronicznej firmy. Dopiero teraz przychodzi czas na audyt systemów zabezpieczeń, w szczególności zapór sieciowych i systemów IDS/IPS.

Równolegle trzeba zmienić wszystkie hasła dla łączy dial-up, przełączników, centrali telefonicznej i wszelkich innych styków firmy z sieciami zewnętrznymi. Do czasu zakończenia audytu należy wyłączyć sieć WLAN, chyba że jest niezbędna do pracy firmy. W takim przypadku trzeba dokonać szczegółowego audytu bezpieczeństwa tej sieci.

Na koniec, last but not least, należy zablokować kartę identyfikacyjną umożliwiającą wejście na teren firmy.

Powyższe czynności wykonuje się szybko, dlatego można (i raczej trzeba) to uczynić jeszcze w trakcie rozwiązywania z administratorem umowy o pracę. Ponadto ważne jest wykonanie wszystkich tych czynności z zachowaniem ich kolejności. Takie podejście sprawia, że dostęp do infrastruktury firmy staje się znacznie utrudniony i zapobiega łatwemu "powrotowi", gdy administrator nie jest już pracownikiem firmy.

Litania zmian

Pozostałe działania mają na celu wykrycie i dezaktywację pozostałych "tylnych drzwi", które mógł (choć nie musiał) pozostawić nieuczciwy administrator. Na początek trzeba wykonać audyt systemów operacyjnych wszystkich serwerów. Audyt ten należy wykonywać w następującej kolejności: (1) serwery dostępne z Internetu, widoczne dla każdego (poczta elektroniczna, WWW, publiczny VPN, SSH, serwer terminalowy, DNS, inne usługi); (2) serwery dostępne za pomocą łączy dial-up; (3) serwery dostępowe sieci radiowej (WLAN); (4) zapora główna, a potem zapory dodatkowe i ponownie zapora główna; (5) serwery działające w strefie DMZ; (6) serwery dostępne w sieci lokalnej firmy.

Wykonanie powyższych audytów jest czasochłonne, ale stanowią jedyną możliwość eliminacji tylnych wejść pozostawionych na serwerach przez nieuczciwego administratora. Aby poprawnie wykonać audyt należy:

Przy pracującym serwerze sprawdzić za pomocą dowolnego skanera sieci (np. nmap) otwarte porty i porównać to z założeniami konfiguracji serwerów i zapisami polityki bezpieczeństwa.

Sprawdzić wszystkie procesy i usługi systemowe. Do tego celu można użyć narzędzi, o których wiadomo na pewno, że nie podlegały modyfikacji i pokazują wszystkie działające procesy. W przypadku systemów typu Unix w miarę możliwości trzeba wykorzystać programy ps, ifconfig, netstat, vmstat i kompilować je z oryginalnego kodu źródłowego oraz linkować statycznie. Najczęściej "trojanowanym" programem bywają /bin/login oraz powłoki systemowe (/bin/sh, /bin/csh). W przypadku systemów Windows należy użyć narzędzi pokazujących więcej informacji niż prymitywny task manager, np. pobrać je z witrynyhttp://www.sysinternals.com . W razie jakichkolwiek wątpliwości trzeba utworzyć środowisko testowe na osobnej maszynie i porównać.

• Sprawdzić usługi katalogowe w poszukiwaniu "wysp uprawnień", czyli kont o uprawnieniach systemowych mieszczących się w kontenerze, do którego ograniczono dostęp dla "legalnych" administratorów. Można to porównać za pomocą narzędzi do analizy bazy usług katalogowych. W przypadku serwerów NetWare dostępne są specjalne narzędzia do odzyskiwania dostępu do "wysp".

• Sprawdzić konta wszystkich baz danych.

• Sprawdzić uprawnienia plików w systemie, szczególnie dotyczy to programów z opcją setuid i setgid. Integralność takich programów należy bezwzględnie sprawdzić.

• Sprawdzić uprawnienia, na których pracują wszystkie usługi systemowe i zmienić hasła do kont, na których działają te usługi. Szczególnie dotyczy to np. Microsoft SQL Server, który często pracuje na koncie o uprawnieniach administratora domeny Windows. Korzystając z popularnego błędu, można dokonać włamania poprzez tę usługę i ustawić nowe hasło użytkownika, na którym pracuje SQL Server. Podobne włamanie może być zrealizowane za pomocą niezaktu-alizowanej starszej wersji bazy Oracle, dlatego szczególną wagę należy przywiązać do zmiany WSZYSTKICH haseł.

• Obliczyć sumy kontrolne md5 (lub mocniejsze) wszystkich plików systemu operacyjnego serwera i porównać je z listą kontrolną zawartą w kopiach bezpieczeństwa. Jedna kopia nie jest wystarczająca, konieczne jest porównanie przyrostowe. Trzeba uwzględniać zapisy dziennika o dokonanych aktualizacjach. Nie polegać na dotychczasowych programach do audytu, gdyż mogły zostać zarażone koniem trojańskim.

• Sprawdzić aktualność oprogramowania, często administratorzy celowo nie dokonują aktualizacji jednego lub więcej mniej ważnych systemów, by móc skorzystać potem z błędów w oprogramowaniu i eskalować zdobyte uprawnienia na pozostałe komputery.

Dmuchać na zimne

Wykonanie powyższych czynności nie zapewnia 100-proc. bezpieczeństwa, ale wskazuje kierunek działań, które trzeba wykonać. W większości przypadków zagrożenie jest mało prawdopodobne, niemniej - możliwe. Przy projektowaniu założeń polityki bezpieczeństwa należy koniecznie uwzględnić dobrze przemyślane procedury zmiany osób odpowiedzialnych za jej realizację. Skonsultowanie tych akurat procedur z zewnętrzną firmą to raczej konieczność.