Profil raz, poproszę

W związku z tym, że kod złośliwy powstaje szybciej, niż jesteśmy w stanie ochronić system różnymi metodami, coraz więcej zwolenników zyskują techniki whitelistingu, tzw. białej listy. Ich stosowanie nie wymaga aż takiego wysiłku jak konfiguracja GPO czy ograniczanie praw administracyjnych. Technika ta - według szefa firmy Bit9 Patricka Morleya - w ciągu najbliższych dwóch lat zagości w mniejszym lub większym zakresie na każdej stacji roboczej. Chodzi tutaj o wyselekcjonowanie takiego oprogramowania, co do którego mamy pewność, że jest "dobre", oraz zablokowanie całej reszty. W ten sposób możliwe jest stworzenie tzw. stacji idealnej.

Koncepcji implementacji białych list jest kilka. Wspomniany już przed chwilą Bit9 jako źródło wiedzy o aplikacjach stosuje własną bazę danych. Możliwe jest również zezwolenie na wykonywanie aplikacji pochodzących od określonego producenta, np. Microsoft czy Adobe. Silnik Bit9 wykorzystywany jest np. w produktach Symanteca czy w nowej wersji ePO McAfee. Podobne mechanizmy stosuje Check Point, z tym jednak, że dzięki usłudze Program Advisor, która zawiera listy plików oprogramowania złośliwego, łączy także funkcjonalność blacklistingu. Nieco inne podejście do tematu whitelistingu ma np. Lumension. Tutaj funkcjonalność ta realizowana jest na poziomie reguł polityki, które wskazują dozwolone aplikacje (można skorzystać z gotowych szablonów). Następnie są one przypisywane do grup użytkowników pobieranych np. z AD.

Istnieją dwie główne metody prowadzące do celu, jakim jest stworzenie białej listy. Pierwsza to instalacja systemu oraz wszelkiego oprogramowania dozwolonego przez korporację. Następnie wykonanie "zdjęcia" takiego obrazu, najczęściej poprzez sporządzenie sum kontrolnych wszystkich plików wykonywalnych (także bibliotek dynamicznych) oraz tych, które mają być objęte ochroną np. pliku hosts. Do sum kontrolnych mogą być również dołączane pełne ścieżki do plików tak, aby np. notepad.exe mógł być wykonany jedynie z katalogu c:\windows oraz c:\windows\system32. W zależności od produktu możliwe jest wskazanie zaufanych źródeł aktualizacji, z których użytkownicy mogą pobierać poprawki. Pliki pobrane w ten sposób będą wówczas automatycznie dołączane do listy aplikacji zaufanych. Niektórzy producenci (np. CoreTrace) pozwalają na umieszczenie modułu weryfikującego uruchamiane oprogramowanie już na poziomie jądra.

Druga metoda to profilowanie stacji typowych dla różnych departamentów już w trakcie ich normalnej pracy. Podejście to jest korzystne wówczas, jeżeli nie mamy sztywno wytyczonych wzorców stacji dla każdego stanowiska. Wiąże się z nim ryzyko, że zanim utwardzimy stację, coś może zdążyć ją zainfekować.

Gdy szukamy darmowego źródła informacji o typowych plikach występujących w systemie operacyjnym, czy związanych z konkretną aplikacją, to warto zajrzeć na stronę NIST-u (National Institute of Standards and Technology). Utrzymuje on i systematycznie aktualizuje taką bazę w ramach projektu NSRL (National Software Reference Library) -http://www.nsrl.nist.gov . Ostatni update pochodzi z lipca tego roku.

Bez zapory nie da rady

Poza kontrolą aplikacji i ochroną antywirusową nieodłącznym elementem bezpiecznej stacji roboczej jest zapora ogniowa. Podejścia do tego elementu znowu różnią się między sobą. Niezbędnym minimum jest firewall z kontrolą stanów. Powinien dawać możliwość centralnego budowania zasad polityki bezpieczeństwa za pomocą reguł tworzonych według wielu kryteriów. Dobry firewall umożliwia administratorowi wskazanie nie tylko źródła i celu połączenia, portów i protokołów, lecz także aplikacji, która takie połączenie może zrealizować. Powinien również umożliwiać przypisanie karty sieciowej do reguły. Dobre produkty działają tak jak zapory brzegowe, przetwarzając reguły w kolejności ich występowania na liście. Ułatwia to diagnostykę i optymalizację. Nie może też zabraknąć możliwości logowania i powiadamiania. Niektóre rozwiązania umożliwiają logowanie jedynie faktu naruszenia reguły, inne dodatkowo potrafią zapisać cały pakiet (jak w Etherealu). W niektórych przypadkach przydatna jest możliwość ograniczenia czasowego działania niektórych reguł, np. w wypadku komputerów stacjonarnych włączonych 24/7, blokowanie całego ruchu przychodzącego poza godzinami pracy. Nie zaszkodzi również, jeżeli będziemy mogli ustawić dodatkowe bariery dla atakującego, utrudniające identyfikację systemu operacyjnego czy przeglądarki.

W pewien sposób z firewallem wiąże się inny problem, który odnosi się do komputerów mobilnych. Polityka firmy może różnicować poziom ochrony, jaki otrzymuje stacja w zależności od lokalizacji, w której się znalazła. Jej wykrywanie powinno być realizowane bez udziału użytkownika. Kryteria wykrywania zmiany lokalizacji mogą być różne, np. adresacja podsieci, dostępność określonej maszyny w sieci itp. Polityka taka może być wymuszana jedynie na poziomie sieciowym, ale też może odnosić się do wszelkich innych parametrów - w tym kontroli urządzeń czy aplikacji. Zastanawiając się nad koncepcją bezpiecznej stacji, można w tym pierwszym przypadku wykorzystać to, co mamy. Dysponując np. firewallem Check Pointa realizującym funkcje terminatora VPN, możemy wymusić odpowiednie reguły polityki dla klientów zdalnych. Część rozwiązań ma specjalnie wydzielony moduł kontrolujący komunikatory internetowe. Niestety praktyka pokazuje, że producentom nieszczególnie zależy na rynku polskim - są MSN, Yahoo!, AIM, ale Gadu-Gadu szukać ze świecą.

Projektując bezpieczną stację, trzeba zastanowić się również nad implementacją mechanizmów NAC. Tutaj też koncepcji jest co najmniej kilka. Są rozwiązania potrafiące realizować pełny NAC, co wymaga dodatkowej infrastruktury sieciowej (przełączników zgodnych z 802.1x, odpowiednich punktów kontroli reguł polityki), a więc znowu (jak w przypadku kontroli stron WWW) wykraczamy poza obszar samej stacji. Są też rozwiązania quasi-NAC, które polegają tylko i wyłącznie na oprogramowaniu stacji. Mogą więc sprawdzać aktualność skanera AV, obecność poprawek systemowych czy konkretnych aplikacji. Na tej podstawie generują raport o zgodności stacji. W zależności od producenta ten quasi-NAC może przyjmować różne nazwy, np. cooperative enforcement czy self enforcement.