Jeszcze kilka lat temu do ochrony sieci z powodzeniem wystarczyła zapora oraz system detekcji intruzów, który wychwytywał pierwsze symptomy niepokojącego ruchu. W tym czasie większość ataków przychodziła z zewnątrz, zatem wystarczyło zablokowanie ich na zaporze sieciowej. Obecnie większość ataków, które mają na celu zdobycie informacji, wykonywane jest od wewnątrz, przy pomocy złośliwego oprogramowania instalowanego w wielostopniowym procesie drive-by. Z kolei ataki z zewnątrz kierowane są głównie przeciw aplikacjom webowym, wykorzystując błędy takie jak SQL Injection i Cross-Site Scripting.

Ochrona jest zbyt daleko

Zapora sieciowa, nawet wyposażona w system detekcji intruzów, nie ochroni całego środowiska w dostateczny sposób. Aby ochrona była optymalna, należy dostosować ją do każdej z aplikacji z osobna. W typowym rozwiązaniu wiąże się to z bardzo skomplikowaną listą reguł, gdy cały ruch z wielu maszyn miałby być filtrowany w jednym miejscu. Jednym z poważniejszych błędów jest korzystanie z pojedynczego interfejsu sieciowego po stronie serwera dla wielu maszyn wirtualnych bez tagowania VLAN.

Polityka powinna iść za maszyną

Środowisko wirtualizowane wiąże się z przenoszeniem maszyn między fizycznymi serwerami, często także między centrami przetwarzania danych zlokalizowanymi w różnych miejscach. Niekiedy przeniesienie maszyny wiąże się ze zmianą założeń polityki bezpieczeństwa. Taką zmianę, po pierwsze, należy uwzględnić, po drugie, firma musi posiadać środowisko, które wymusi nowe założenia tej polityki. Wymaganą elastyczność bardzo trudno zapewnić tradycyjnymi metodami, gdyż ochrona za pomocą zapór i systemów sieciowego DLP znajduje się zbyt daleko od chronionych zasobów.

Obszar na dysku

Maszyny wirtualne, w odróżnieniu od serwera pracującego bezpośrednio na sprzęcie, posiadają więcej niż jeden stan, w którym można wpływać na ich zawartość. Gdy serwer pracujący bezpośrednio na sprzęcie jest wyłączony, z nielicznymi wyjątkami dostęp do niego jest niemożliwy. Dla porównania, wyłączona maszyna wirtualna to kilka plików lub zestaw bloków na współdzielonych dyskach. Jeśli nie stosuje się odpowiednich procedur i narzędzi kontroli, taką maszynę w stanie wyłączenia można zmodyfikować. Podobna zmiana w przypadku tradycyjnej infrastruktury wymagałaby wizyty intruza w serwerowni. W środowisku wirtualnym może to umożliwić trywialny błąd administratora związany z ustawieniem uprawnień. Wynika stąd konieczność opracowania procedur oraz założeń polityki bezpieczeństwa - maszyny wirtualne należy kontrolować przed każdym uruchomieniem.

Tymczasowe łatanie dziury

Dzisiejsze ataki charakteryzują się dużą szybkością - niejednokrotnie od opublikowania informacji o luce do ataków upływają zaledwie godziny. Z drugiej strony, aplikacje biznesowe nie zawsze mogą być aktualizowane tak szybko, dlatego powstaje rozziew między możliwościami aktualizacji a potrzebami zapewnienia bezpieczeństwa. Chociaż systemy detekcji intruzów potrafią chronić podatne aplikacje przed atakami, nie zawsze mogą to zrobić w optymalny sposób. Ideałem jest ochrona, która sama rozpoznaje podatności danego systemu (na przykład, sprawdzając jego stan aktualizacji), a następnie odpowiednio dostosowuje swoją ochronę. Gdy cała procedura związana z wdrożeniem łaty zostanie wykonana, system stwierdzi, że dla danego systemu nie jest już potrzebna ochrona przed lukami, które ta łata usuwała. Ma to kolosalne znaczenie, gdy w tym samym wirtualizowanym środowisku pracuje wiele systemów o różnym stopniu aktualizacji i podatności. Niekiedy firma może stać przed ważną decyzją związaną z koniecznością eksploatacji aplikacji, w której luki w bezpieczeństwie są już powszechnie znane, ale nadal nie można zaaplikować odpowiednich łat. Wtedy narzędzia ochronne, które potrafią selektywnie blokować ataki, dają szansę na bezpieczną eksploatację aplikacji do czasu jej aktualizacji.