Zarządzanie, alarmy i raporty

Większość aplikacji białych list dostarczana jest z centralną konsola administracyjną. Zazwyczaj jest to konsola przeglądarkowa, zawierająca dostosowywane widoki pulpitu, które pokazują liczby rozprowadzonych klientów, zablokowanych wykonań i największych zagrożeń. W tym segmencie rynku wyraźnie widać tendencję do integracji funkcjonalnej - więksi dostawcy kupują mniejsze firmy zajmujące się białymi listami i uzupełniają ich rozwiązania o dodatkowe cechy. Zazwyczaj integrują produkty białych list i konsole do zarządzania z istniejącymi konsolami do zarządzania obsługującymi inne produkty.

Najlepsze konsole pozwalają na przejście od widoku całego zarządzanego środowiska - na poziom określonych komputerów, programów lub użytkowników. Zdefiniowane wyszukiwania i kontrola specyficznych zasobów przydają się, gdy np. pracownicy wykonują działania nieautoryzowane - można wtedy zablokować takie akcje do czasu, aż zostaną podjęte odpowiednie działania administracyjne.

Nieautoryzowane uruchomienia programów powinny generować alarmy. Nie każde zabronione wykonanie musi generować alarm, ale nieoczekiwane i powtarzające się przypadki, jak np. ustawiczne próby uruchomienia nieznanego pliku - powinny już budzić podejrzenia.

Alarmy mogą być przekazywane za pośrednictwem różnych kanałów: komunikaty w sieci, SMS-em, pocztą elektroniczną, komunikatorem. Dobrze mieć możliwość przydzielania różnych zdarzeń - różnym metodom przekazywania alarmów.

Innym ważnym mechanizmem jest dławienie alarmów, które zapobiega pojawianiu się wielu alarmów w wypadku wielokrotnego wystąpienia pojedynczego, skorelowanego zdarzenia. System bez "dławika" może generować alarm dla każdego wystąpienia, niepotrzebnie absorbując personel IT, a także "zamulając" system alarmów lub sieć.

Raporty mogą być czynnikiem decydującym o wyborze programu białej listy. Niektóre programy mają skromny system raportowania lub raportują informacje do zdecentralizowanych źródeł danych, pozostawiając korelację danych administratorowi. Większość jednak zawiera zestawy predefiniowanych raportów, które mogą być drukowane lub eksportowane z centralnej konsoli. Najlepsze pozwalają na dostosowywanie raportów i ustalanie harmonogramu raportowania.

Strategia wdrażania białych list

Chociaż białe listy oferują potencjalne korzyści, nieodpowiednie ich zaplanowanie i testowanie może je zniwelować. Rzeczywistą przeszkodą dla szerszego wprowadzenia tej techniki są pracownicy, którzy buntują się przeciw blokowaniu przez działy IT oprogramowania na swoich komputerach. Chociaż białe listy mogą chronić przed złośliwym oprogramowaniem i uruchamianiem nieautoryzowanych aplikacji, to jednocześnie utrudniają natychmiastowe użycie aplikacji, której pracownik legalnie potrzebuje. Przeciwnicy tej techniki uważają, iż spowalnia ona wprowadzanie innowacji i obniża efektywność biznesową.

Przy wdrażaniu bardzo ważne jest uzyskanie wsparcia z wyższego szczebla zarządzania jeszcze przed rozpoczęciem projektu kontroli aplikacji. Białe listy oznaczają pewne ograniczenie uprawnień użytkownika końcowego do dokonywania zmian i przeniesienie ich na poziom IT. Bez względu na to, jak dobrze się to zaplanuje i przetestuje, jest to jednak zmiana ugruntowanych przyzwyczajeń. Kiedy użytkownicy sprzeciwiają się idei białych list, to zazwyczaj argumentują to tym, że IT nie będzie dostatecznie szybko reagować na ich potrzeby, obniżając tym samym ich wydajność i kreatywność. Aby tego uniknąć, należy wdrożyć szybki proces zatwierdzania żądań wprowadzenia nowego oprogramowania.

Są chwile w działalności każdej firmy, kiedy istnieje potrzeba natychmiastowej instalacji i użycia nowego oprogramowania. Plan wdrożenia białych list powinien obejmować procesy ratunkowe i ad hoc z odpowiednią procedurą zatwierdzania i sprawdzania. Jeżeli proces zatwierdzenia nowego oprogramowania jest zbyt długi i w praktyce obniża wydajność pracowników, wtedy białe listy mogą nie się nie sprawdzić w organizacji.

Każde wdrożenie białej listy potrzebuje gruntownego przetestowania, w celu upewnienia się, czy osiągnięto cele projektu bez obniżenia wydajności użytkownika końcowego. Rozpocząć trzeba od testów na komputerach nieprodukcyjnych zawierających oprogramowanie, które jest składową systemów produkcyjnych. Użytkownikom końcowym należy umożliwić prowadzenie operacji biznesowych na testowym systemie, aby zobaczyli jak białe listy wpływają na ich normalne działania. W razie potrzeby na tym etapie można wprowadzać odpowiednie korekty.

Kiedy została wykonana część offline testowania, należy przeprowadzić ograniczone testy w środowisku produkcyjnym. Na kolejnym etapie przeprowadza się duże testy produkcyjne na kilku komputerach w każdym dziale. Jedynie po pomyślnym przebiegu tej fazy powinno nastąpić pełne wdrożenie.

Każdy etap wdrożenia powinien zaczynać się tylko audytem - nie egzekwowaniem. Włączyć należy planowane reguły wymuszania, ale program powinien działać tylko w trybie audytu. Na podstawie wyników audytu i raportów należy modyfikować reguły stosownie do potrzeb. Takie postępowanie powinno być regułą na każdym nowym etapie wdrażania.

Przez lata desktopy w pełni kontrolowane przez użytkownika końcowego, co prowadziło do nieumyślnego obniżania bezpieczeństwa i wydajności. Białe listy to przekazanie istotnej części sprawowania tej kontroli z powrotem do działu IT. Ważne jednak, by dobrać odpowiednie oprogramowanie i procesy, które złagodzą nadmierny opór ze strony użytkowników.

Opracowano na podstawie "Info-World Whitelisting Deep Dive".