Dlaczego oprogramowanie od producenta X i Y nie jest uwzględnione w danym porównaniu bezpieczeństwa? O czym to świadczy? Czasami o to pytacie, dlatego śpieszę z wyjaśnieniem zagadnienia oraz kilku innych problemów, z którymi musimy się zmagać podczas przeprowadzania porównawczych testów oprogramowania ochronnego. Na pewno interesujące będą też inne właściwości testowania. Weźmy za przykład ogólne koszty infrastruktury oraz czynniki, które sprawiły, że jesteśmy na III miejscu wśród laboratoriów testujących w Europie i na świecie, ustępując tylko dwóm największym firmom z tej branży (AV-Comparatives i AV-Test). Po przeczytaniu tego artykułu będziesz mieć wiedzę o tym, jak powinno się testować oprogramowanie do zabezpieczania urządzeń końcowych oraz dowiesz się, jakiej metodologii oraz infrastruktury używamy w AVLab.
Problem 1: Jak dobieramy produkty do testów i jakie są ogólne koszty?
To zależy od rodzaju testu. Jeżeli jest to porównanie oprogramowania klasy EDR dla firm, musimy dobierać produkty do metodologii, bo nie wszystkie rozwiązania posiadają funkcjonalność rejestrowania wskaźników zagrożeń (IoC), które ułatwiałyby automatyzację pracy zespołu IT w Security Operation Center.
Podobnym przykładem jest test bankowości internetowej. Warto testować te rozwiązania, które posiadają specjalne moduły do zabezpieczenia sesji bankowej przed atakami i ukierunkowanym w bankowość złośliwym oprogramowaniem. Zwykle testujemy pakiety klasy Internet Security albo Total Security. Na upartego moglibyśmy testować darmowe oprogramowanie antywirusowe, ale posiada ono mniej potrzebnych funkcji do takich testów w związku z tym nie nadaje się do zabezpieczenia przelewów internetowych. Wyjątkiem od tej reguły jest Comodo Internet Security.
Decyzja producenta ma wpływ na wybór rozwiązania do testów. Nie zawsze jest możliwe szybkie skontaktowanie się z dostawcą oprogramowania. Wiecie… Korporacje i procedury. Innym przykładem jest brak zainteresowania z powodu metodologii (zbyt rygorystyczna?) lub odmowa bez podawania przyczyny.
Niektóre testy wymagają opłaty od producentów w zamian za opracowanie wyników oraz feedback techniczny. Korzyści z takiej współpracy jest wiele, ponieważ jako użytkownik końcowy masz pewność załatania znalezionych błędów w oprogramowaniu.
Czas pracowników AVLab musi kosztować. To normalna sprawa, bowiem ponosimy szereg opłat związanych z serwerami i wsparciem IT, usługami prawnymi, wsparciem merytorycznym oraz tłumaczeniami raportów na język angielski. Przy okazji, jeżeli chcecie, aby powstawało więcej testów i recenzji oprogramowania dla firm lub dla domu – także bezpłatnego oprogramowania – możesz nas o to poprosić, uznając naszą pracę dobrowolną wpłatą finansową na konto Fundacji AVLab dla Cyberbezpieczeństwa. Szczegóły do przelewu są dostępne w zakładce „O nas”: https://avlab.pl/o-nas/
Problem 2: Jakie są koszty utrzymania infrastruktury do testów?
W badaniu z cyklu „Advanced In The Wild Malware Test” wykonywanym co drugi miesiąc (w marcu 2022 robimy już 17. edycję testu) posiłkujemy się dedykowanym serwerem z łączną ilością 32 rdzeni procesora. Maszyny wirtualne lubią pamięć RAM, dlatego optymalnym obecnie wyborem jest 128GB na cały serwer, w tym konieczność posiadania superszybkich dysków NVMe. Odczyt i zapis danych z dysków jest kluczowy, aby wydajność maszyn wirtualnych pozwalała na komfortową pracę.
Do ogólnych kosztów należy doliczyć:
1. Większość kosztów to prace programistyczne i integracja narzędzi do testów. Czyli wszelaka automatyzacja wszystkiego. Począwszy od najniższego poziomu: API Vmware, NodeJS, logi Sysmon i baza danych, po web-aplikację do wizualizacji wyników, aby po teście szybko przesłać producentom dane techniczne do weryfikacji. Koszt roczny programowania może wynieść od kilkunastu do kilkudziesięciu tysięcy złotych w zależności od zmian w metodologii oraz adaptacji do nowych narzędzi, w tym uwzględnienie zmian w systemie Windows.
2. Licencja na program do wirtualizacji oraz licencje Microsoft Office 365 (uruchamianie szkodliwych dokumentów Word i Excel).
3. Sieć serwerów-honeypotów w różnych lokalizacjach na świecie, które są pułapkami do zbierania szkodliwego oprogramowania używanego podczas ataków. Łączny koszt serwerów przekracza ładnych kilka tysięcy złotych miesięcznie i niestety za serwery trzeba płacić niezależnie od tego, czy są włączone. Rozwiązanie chmurowe o podobnym zapotrzebowaniu na wydajność z rozliczeniem godzinowym pomnożyłoby tę kwotę kilka razy. Sprawdzaliśmy to na przykładzie chmury Oktawave, ale to nie jest najlepsze dla nas rozwiązanie, ponieważ pojawia się problem zagnieżdżonej wirtualizacji i spadku wydajności (nested virtualization).
Podsumowując, koszty związane z przeprowadzaniem testów są bardzo duże.
Trzeba uwzględnić, że w jednym czasie musi być uruchomiona określona ilość maszyn wirtualnych. Jeżeli przebrniesz przez naszą metodologię testów, dowiesz się, że jest konieczne, aby testy przeprowadzać dokładnie w tej samej chwili dla wszystkich rozwiązań ochronnych. Powody są różne, ale najważniejsze jest to, że malware musi być dostarczone do wszystkich maszyn w tej samej sekundzie, aby zachować zasadę równości, dając producentom taką samą szansę na detekcję ataku bądź szkodliwego oprogramowania.
Chcąc robić testy profesjonalnie, musisz liczyć się z opłatami, ponieważ bez współpracy z producentami nie możesz udźwignąć kosztów mocy obliczeniowej, zasobów serwerowych, programowania oraz opracowania merytorycznego.
Problem 3: Dlaczego Windows 10, a nie Windows 11?
Tymczasowo seria badań „Advanced In The Wild Malware Test” jest przeprowadzana w Windows 10 ze względu na dobrą stabilność tego systemu.
W najnowszym teście bankowości internetowej użyliśmy Windows 11, lecz jego stabilność i wydajność przemilczymy. Obecnie odkładamy w czasie migrację do Windows 11.
W aspekcie technicznym różnice pomiędzy systemami są nieznaczne. Te same są uprawnienia UAC, ta sama technologia MOTW (mark-of-the-web), to samo zainstalowane narzędzie Sysmon do zbierania logów oraz ta sama i zawsze najnowsza przeglądarka Google Chrome.
Czasowo pozostajemy przy Windows 10. Migracja na Windows 11 będzie szybka i łatwa, ale zależy nam na stabilności systemu, ponieważ seria badań „Advanced In The Wild Malware Test” przeprowadzana jest automatycznie.
Problem 4: Jakie stosujemy ustawienia Windows i konfigurację antywirusów?
Najlepiej wyjaśnia to metodologia w punkcie 7. Aktualizacje Windows są wykonywane ręcznie, aby Windows nie zaczął się samoczynnie aktualizować podczas testu. Ustawienia programów ochronnych są zwykle domyślne, ale też zależy od rodzaju testu.
Kontrolę konta użytkownika UAC mamy wyłączoną ze względu na omijanie komunikatu systemowego – sprawdzanie ochrony oprogramowania bezpieczeństwa wymaga, aby malware było uruchamiane niezależnie od decyzji użytkownika. Celem testów jest sprawdzanie skuteczność ochrony, a nie reagowanie na komunikaty systemowe.
Pozostałe ustawienia są domyślne! Niczego systemowo nie wyłączamy, co jest ważnym komunikatem dla ciebie jako odbiorcy takiego testu. Masz bowiem pewność, że testujemy zgodnie ze sztuką i robimy to profesjonalnie.
Problem 5: Metodologia
Metodologię (link tutaj) podzieliliśmy na 3 etapy:
- Jak pozyskujemy i klasyfikujemy malware do testów?
- Jakim narzędziem zbieramy logi z testów?
- Jak to wszystko działa krok po kroku?
Wszystkie podane w metodologii informacje wyczerpują aż nadto postępowanie zaprogramowanych skryptów według naszych wymagań, jak i użytych narzędzi do testów. Stawiamy na maksymalną transparentność, dlatego podajemy te wszystkie dane do publicznej wiadomości! Doceniają to nasi czytelnicy, którzy sprawili, że jesteśmy wśród liderów zaufanych laboratoriów testujących w Europie i na świecie. Dziękujemy!
Problem 6: Zrozumienie publikowanych wyników Advanced In The Wild Malware Test
Najważniejsze jest zrozumienie tak zwanych „poziomów” L1, L2 i L3 dla blokowanego malware.
POZIOM 1 (Level 1): To poziom przeglądarki, tzn. wirus został zatrzymany przed lub zaraz po pobraniu w przeglądarce.
POZIOM 2 (Level 2): Poziom systemu, tzn. wirus został pobrany, ale nie zezwolono na jego uruchomienie. Chociaż próbowano – na przykład antywirus zablokował plik i nie zezwolił na jego uruchomienie.
POZIOM 3 (Level 3): Poziom analizy, tzn. wirus został uruchomiony i zablokowany przez testowany produkt. Poziom ten reprezentuje najgroźniejszą sytuację, a zarazem plik 0-day dla oprogramowania ochronnego, gdyż za pomocą tradycyjnej ochrony sygnaturowej malware nie zostało wcześniej zatrzymane.
FAIL: Niepowodzenie, tzn. wirus nie został zablokowany i zainfekował system.
Chcesz więcej danych z testów?
Mamy więcej ciekawych i technicznych aspektów związanych z testowaniem. Można by wymienić np.:
- techniczną klasyfikację malware,
- odrzucanie niepoprawnych próbek i niedziałających za pomocą reguł Yara,
- dobieranie poprawnych malware za pomocą logów Sysmon,
- konfigurację systemu Windows,
- zaawansowaną konfigurację i reguł dla Sysmon.
Jeżeli takie tematy są dla ciebie interesujące, to daj znać w komentarzu! Przy okazji zachęcamy do uznania naszej pracy wpłatami na konto Fundacji AVLab dla Cyberbezpieczeństwa (link tutaj). Nie po to, „abyśmy mogli się rozwijać”, lecz jeśli chcesz za darmo otrzymywać więcej interesujących treści, daj nam o tym znać!
