Koncepcja 'dobrych robaków' zrodziła się z przekonania, że skuteczność dystrybucji złośliwego kodu można wykorzystać do obrony przed zagrożeniami płynącymi z sieci. Realizacja tej wizji w praktyce napotyka wiele problemów - na tyle poważnych, że nie należy nastawiać się na rychłą rewolucję architektury systemów zabezpieczeń.

W1988 r. Robert T. Morris junior zapoczątkował nową erę. Nie spodziewał się, że to, co rozpoczął, po prawie dwudziestu latach stanie się jedną z największych bolączek światowego Internetu - większą nawet niż bolączka komputerowych wirusów. Nie mógł się również spodziewać, że termin, w jakim zostanie opisane jego programistyczne dzieło, stanie się synonimem internetowego zła początku XXI w.

Drugiego listopada 1988 r. samo propagujący się program o nieznanym dotąd sposobie działania zaczął paraliżować systemy należące do ówczesnego Internetu. I chociaż udało mu się dostać na zaledwie 5% z istniejących wtedy w globalnej sieci 60 tys. komputerów, nietypowy sposób działania oraz problemy, jakie spowodował w działaniu sieci sprawiły, że zyskał miano pierwszego w historii Internetu "robaka", nazwanego od nazwiska twórcy The RTM Worm.

Na przestrzeni lat robaki wykręciły wiele spektakularnych "numerów", ale zasada działania programów tego rodzaju nie predestynuje ich automatycznie do tego, co złe. W ostatnim czasie wraca dyskusja o koncepcji "dobrych robaków", których zadaniem jest co prawda wykorzystywanie tych samych słabości systemów (i ludzi), ale w celach "pozytywnych" i pod kontrolą. Mówiąc krótko, taki robak byłby zautomatyzowanym agentem (dla odróżnienia od "złych robaków") testującym bezpieczeństwo środowiska informatycznego. Czy to realne?

Zły, być może dobry

Zasada działania robaków-agentów w ogólności ma być taka jak robaków złośliwych. Zainicjowane przez administratora "zarażenie" może nastąpić na wiele sposobów (poczta, folder sieciowy itp.). Gdy to już się stanie, program rozprzestrzenia się w sieci, wykorzystując standardowe dla robaków mechanizmy replikacji. Na każdym zarażonym hoście agent wykonuje skanowanie dostępnych na nim usług. Gdy stwierdzi, że określona usługa istnieje i jest podatna na zawarte w bazie agenta eksploity, agent instaluje się lokalnie i postępuje zgodnie z zaprogramowaną w nim procedurą.

Ścieżek postępowania po wykryciu błędu lub podatności może być wiele. Agent może poinformować administratorów, wysyłając komunikat do odpowiedniej konsoli, lub też połączyć się z działającym w firmie skanerem luk bezpieczeństwa. W jego bazie może sprawdzić, czy z określonym problemem ma prawo rozprawić się automatycznie, czy też powinien czekać na dalsze instrukcje.

W przypadku systemów serwerowych automatyczne działanie jest wysoce ryzykowne, dlatego wątpliwe, by ktokolwiek o zdrowych zmysłach zdecydował się na taką konfigurację. Poza tym działania dotyczące zmian w konfiguracji muszą zazwyczaj zostać skonsultowane z administratorem aplikacji lub usługi, i to zarówno z przyczyn formalnych, jak i czysto społeczno-koleżeńskich.

Automatyzm można zastosować w przypadku mniej znaczących stacji roboczych, a i to z dużą ostrożnością.

Na pierwszy rzut oka temat taki mógłby się wydawać wart zainteresowania. Po weekendowym buszowaniu agentów w sieci administrator bezpieczeństwa ma możliwość pozbycia się najpoważniejszych luk w stacjach roboczych i otrzymania odpowiednio posortowanej listy problemów dotyczących serwerów. Wizja jest piękna, ale, niestety, nie całkiem realistyczna.

Agenty różnej proweniencji

Z działaniem agentów wiąże się potencjalnie sporo problemów. Na pierwszy plan wysuwa się kwestia zaufania do autorów. Nie ulega wątpliwości, że tylko niewielka liczba firm dysponuje na tyle wykwalifikowanym personelem w działach informatycznych, by programy agenckie mogły być tworzone lokalnie. Pozostałe organizacje z konieczności musiałyby wykorzystywać agenty tworzone przez wyspecjalizowane firmy zewnętrzne i to najprawdopodobniej bez możliwości wglądu w kod. Choć z drugiej strony, większość dużych firm zdecydowanie bardziej woli zapłacić za taką aplikację renomowanej firmie antywirusowej, niż "grzebać w kodzie", choćby nie wiadomo jak przejrzystym.

W takich warunkach bezpieczeństwo opiera się na zaufaniu, na wierze w dobrą wolę producenta rozwiązania oraz jego pracowników. Nie ma innego wyjścia jak ufać, że agent nie będzie wykonywał dodatkowej "kreciej" roboty, jak wysyłanie zaszyfrowanych informacji o stanie naszej sieci i oprogramowania do autora, lub co gorsza, instalował bez wiedzy klienta "tylnych wejść". Ale sygnowanie aplikacji przez dużą i znaną firmę w dziedzinie bezpieczeństwa niewiele znaczy. Doskonałym przykładem jest niedawno odkryta dziura w przetwarzaniu plików WMF w systemie Windows - specjaliści orzekli, ze dziura najprawdopodobniej nie powstała przypadkiem, a jest konsekwencją celowego działania.

Załóżmy jednak, że wszystko jest w porządku. Intencje twórców są jak najlepsze, a program agenta nie zawiera żadnych wbudowanych niespodzianek. Co będzie, jeśli na skutek strategii produktowej producent zechce uczynić moduły agenckie możliwie najbardziej uniwersalnymi i przenośnymi między platformami? Złożoność systemów operacyjnych warstw pośrednich i aplikacji jest tak duża, że trudno przewidzieć wszystkie możliwe zachowania takiego agenta w sieci i jego reakcje w przypadku napotkania sytuacji, która twórcom nie przyszła na myśl.

W takim przypadku może się okazać, że agent mający jak najlepsze intencje powoduje nieprzewidziane błędy i, paradoksalnie, wywołuje skutki, których spodziewać się można raczej po robakach-złośliwcach. Może prowadzić do de facto ataków DoS, zwiększania wykorzystania łączy WAN i styku z Internetem, może wykorzystywać zbyt dużo mocy obliczeniowej, powodując wydłużenie czasów odpowiedzi kluczowych dla firmy aplikacji albo paraliżować na wiele godzin komputery użytkowników, których praca jest dla firmy szczególnie cenna.

Gdy coś takiego się stanie, dział odpowiedzialny za utrzymanie bezpieczeństwa zbierze nie sympatię i uznanie dla innowacyjnego podejścia, lecz cięgi za utrudnianie ludziom pracy, a może nawet za spowodowanie wymiernych strat. Nawet gdyby działanie agentów ograniczyć do wydzielonych podsieci, nadając im ograniczone uprawnienia, nie ma pewności, czy nie wymkną się spod kontroli. Proszę sobie wyobrazić sytuację, w której do firmowej podsieci WLAN włącza się gość nieświadomy, że w sieci działają programy-agenci, a za jego pośrednictwem przenosi się do sieci innych firm.

To już nie są żarty, lecz realne zagrożenie odpowiedzialnością cywilno-prawną za szkody i problemy wyrządzone w innych sieciach. Rzeczywiste lub tylko domniemane - już bowiem fakt ujawnienia możliwości zagrożenia może być podciągnięty pod "usiłowanie" wykonania określonych działań, takich jak sabotaż czy szpiegostwo gospodarcze.