W cyberbezpieczeństwie nie powinno być miejsca na kompromisy. Albo dane rozwiązanie jest skuteczne w zwalczaniu zagrożeń, albo nie jest, co potwierdzają testy oprogramowania, które są istotne zarówno dla użytkowników, jak i przedsiębiorstw. Firma Emsisoft poprosiła AVLab o komentarze dotyczące testowania i innych kwestii z tym związanych. Poniżej publikujemy wersję polską, natomiast oryginalne komentarze można znaleźć na blogu Emsisoft.
Czym dokładnie jest testowanie rozwiązań antywirusowych, anty-malware?
Aby nie wracać do metodyk testowania sprzed dekad i nie wchodzić w szczegóły, postaram się to bardzo uprościć i wyjaśnić. W mojej opinii chodzi o testowanie technologii, które zapewniają bezpieczeństwo, jakkolwiek by się one dzisiaj nie nazywały i jakkolwiek nie działały pod spodem. Technologie te są implementowane w rozwiązaniach IT i systematycznie poprawiane przez producentów od dekad. Testowanie zabezpieczeń w różnych scenariuszach może ujawniać ich słabości np. podczas przetwarzania złośliwego oprogramowania przez silnik antywirusowy. Czasami odkrywa się błędy, które niekoniecznie są łatwe do zauważenia w świecie realnym, ponieważ użytkownicy nie są zobligowani do tego, aby dzielić się z producentem szczegółowymi danymi diagnostycznymi, dodatkowo nie generują jednorazowo aż tyle danych diagnostycznych, aby zauważyć igłę w stogu siana. Testowanie z wykorzystaniem algorytmów maszynowego przetwarzania informacji pozwala wyłapać te niuanse. Ważną częścią testowania jest rozmowa z producentem, inżynierami technicznymi, aby wskazać im potencjalny problem. Czasami ów problem należy omówić i w razie konieczności wdrożyć poprawkę, która trafi do użytkowników przy kolejnej aktualizacji oprogramowania. Co ciekawe niekiedy zostają ujawnione błędy w metodologii, które producent wskazuje firmie badawczej. To także jest ważna część ulepszania testowania.
Jak metody testowania zmieniały się na przestrzeni lat?
Testowanie ewoluuje, podobnie jak technologie zabezpieczające. Działamy po tej samej stronie barykady i walczymy z przestępczością, która chce przełamywać te zabezpieczenia.
Na przestrzeni lat testowanie zmieniało się diametralnie, a to za sprawą rozwoju technologii, systemów operacyjnych, aplikacji i narzędzi dla testerów. Dzisiaj większość zadań (nie wszystkie) można zautomatyzować, wykorzystać chmurę obliczeniową, wyodrębnić z danych telemetrycznych więcej precyzyjnych danych niż dawniej. Nastąpiła też znaczna poprawa świadomości dotyczącej cyberbezpieczeństwa, czyli więcej firm i użytkowników wymaga od producenta dobrze przetestowanych usług i produktów. Mogę tylko mówić za nas – w pewnym sensie wynikiem współpracy testerów oraz producentów jest lepsza jakość usług i oprogramowania, które trafia do klienta końcowego i jest instalowane w środowisku produkcyjnym lub w naszych domach.
Niektórzy ludzie są zaniepokojeni, uważają że testy są nieobiektywne, ponieważ zazwyczaj są opłacane przez dostawców oprogramowania. Jak na to odpowiesz?
Rozumiem te wątpliwości, kiedyś też nie wiedziałem, jak testy są przeprowadzane od środka i ilu nakładów finansowych wymagają – począwszy od utrzymania serwerów, opłaty licencyjne i wynagrodzenia współpracowników. Dodatkowo już widzieliśmy kilka poważnych incydentów, gdzie przyłapano producenta na oszustwie, co tylko zadziałało na niekorzyść całej branży testującej. Jest jeszcze druga strona medalu – tak zwane testy sponsorowane – one powinny być transparentnie oznaczane. W mojej opinii zmierza to ku lepszemu za sprawą regulacji prawa prasowego.
To, że producent płaci za przeprowadzenie testu, nie jest niczym złym. Jest to taka sama usługa jak każda inna, może być doregulowana dodatkowymi wymaganiami technicznymi, merytorycznymi. Regulacjami testowania zajmuje się AMTSO (Anti-Malware Testing Standard Organization), chociaż nie trzeba przynależeć do tej organizacji, aby móc testować i wydawać rzeczowe opinie. Jak już wspomniałem, test indywidualny powinien być oznaczony – jest opłacany przez danego producenta, który w zamian oczekuje korzyści marketingowych, lecz zupełnie czymś innym jest oszukiwanie. Nie widzę powodu, aby umówić się, że w przypadku wyniku, który nie będzie satysfakcjonujący dla jednej ze stron, po prostu nie będzie to publikowane. To zrozumiałe, że korzyść i tak zostanie odniesiona z tytułu wskazania błędów w oprogramowaniu i wydania aktualizacji. Podobnie jest z artykułami i recenzjami na blogach, które są przygotowywane odpłatnie.
Inną sytuacją jest, kiedy to laboratorium wybiera lub zaprasza producentów do udziału w teście. Z mojego doświadczenia mogę powiedzieć, że za testy nie pobieramy opłat. Opłaty naliczamy za nasz feedback techniczny, za opracowanie merytoryczne, materiały marketingowe wykorzystane przez producenta (np. certyfikaty, logo, inne pliki). Producent może odmówić udziału w teście, może wnieść swój sprzeciw, dlatego warto mieć wszystko udokumentowane na wypadek takich rozbieżności.
Jeżeli oprogramowanie dobrze wypadło w teście, czy to oznacza, że jest równie dobre w środowisku produkcyjnym?
To zależy. Właśnie po to są różne firmy badawcze, które pod różnym kątem sprawdzają oprogramowanie, więc nie trzeba się zgadzać z jednym, konkretnym laboratorium. Właśnie od tego są różnego rodzaju testy, które dają większy, bardziej kompleksowy obraz tego, co może osiągać dane rozwiązanie w środowisku produkcyjnym. Jeżeli testerom udaje się przechytrzyć zabezpieczenia, to tym bardziej może się to udać atakującym w prawdziwym scenariuszu.
Zwracam tutaj uwagę na niuanse – metodologię. Często po teście przebijają się do prasy informacje złe, że produkt X lub Y uzyskał słaby wynik. Wówczas należy prześledzić metodologię, czy aby na pewno pewna część zabezpieczeń nie była wyłączona? Czasami obserwuję to i rozumiem, kiedy ktoś chce przetestować daną technologię kosztem innej. Zazwyczaj jestem przeciwnikiem takiego rodzaju podejścia do testowania, ponieważ producent nie po to inwestował w rozwój technologii przez całe dekady, aby używać je wybiórczo.
Jak powinno się interpretować testy? Czy jeden negatywny wynik oznacza, że produkt jest. Zły? Na co ludzie powinni zwracać uwagę, kiedy ktoś ocenia produkt?
Jak zawsze diabeł tkwi w szczegółach… Powiem, że to zależy od testu – jak już wspomniałem, należy zwracać uwagę na to, czy w teście wyłączone są niektóre funkcje ochronne i jak dobrze produkt zabezpiecza bez nich. Podkreślam to znowu, ponieważ należy analizować wyniki w zestawieniu ze wszystkimi cechami oprogramowania ochronnego, gdyż zwykle w taki sposób będzie ono działać w systemie produkcyjnym. Dodatkowo poszczególne technologie ochronne producentów mogą się znacząco od siebie różnić i ujawniać mniej lub więcej danych dla administratora, użytkownika. Najlepiej więc patrzeć na produkt lub usługę całościowo lub mieć przygotowane konkretne wymagania minimalne, które produkt musi spełnić.
Zachęcam do indywidualnej analizy testów przy wyborze oprogramowania. Skuteczność ochrony jest bardzo ważna, ważne są też dodatkowe cechy, jak szybka pomoc producenta, wsparcie techniczne, interfejs programu, szybkość działania, wspierane systemy, funkcje w konsoli zarządzającej np. alarmowanie o incydencie, automatyczna naprawa tych incydentów, dodatkowe środki naprawcze, wskazanie podatności w systemach, ujawnienie słabej konfiguracji kont użytkowników, integracja z zewnętrznymi rozwiązaniami np. SIEM, szyfrowanie dysków, tworzenie kopii zapasowej itp.
Czym jest organizacja Anti-Malware Testing Standards Organization (AMTSO), do której należy AVLab?
Ogólnie rzecz biorąc AMTSO zrzesza firmy oraz ekspertów, którzy chcą działać razem na rzecz dobra wspólnego, jakim jest cyberbezpieczeństwo. Wypracowywanymi regulacjami są obłożone organizacje testujące, taka jak nasza.
Jeszcze przed dołączeniem do AMTSO nie byłem zwolennikiem regulacji w testach. Moje zdanie się zmieniło po zetknięciu się z nimi w praktyce. Podoba mi się transparentność, jeżeli firma badawcza chce uzyskać zgodność z wytycznymi AMTSO. Nasze metody testowania ewoluowały w dobrą stronę dzięki AMTSO, ale co interesujące, okazało się, że nieświadomie spełnialiśmy większość technicznych wymagań jeszcze przed złożeniem aplikacji o członkostwo. Obecnie dzięki współpracy z producentami wdrożyliśmy zmiany i systematycznie to robimy, usprawniając nasze narzędzia i procedury. Wiemy już lepiej, na czym zależy producentom – nie na marketingowej sławie, ale by ich produkt ciągle był poprawiany z korzyścią dla klientów końcowych, bez względu na otrzymywane certyfikaty – bo w takiej formie przyjęło się pokazywać ocenę do opinii publicznej, co nie stoi na przeszkodzie, aby iść w innym kierunku, chociaż nikt jeszcze nic lepszego nie wymyślił. Dzięki testom udaje się realizować strategię lepszej ochrony klientów, a mamy już doświadczenie we współpracy z najmniejszymi firmami typu startup, po największych graczy w branży.
W każdym oprogramowaniu prędzej czy później ktoś znajdzie sposób na oszukanie ochrony, znajdzie ten niuans techniczny, który ujawni słabość, podatność. Od tego są testy oraz współpraca na rzecz walki z cyberprzestępczością. Regulacje nie zawsze są dobre, co pokazuje normalne życie, jednak przystępując do danej organizacji musisz trzymać się wyznaczonych zasad. Dobrze, kiedy są to dobre zasady. Tak się składa, że AMTSO na wielu płaszczyznach pomaga testerom: od testowania prostych technologii, po ustalanie standardów dla produktów klasy Enterprise i mam tu na myśli nie tylko rekomendacje dotyczące testowania technologii, które przeciwdziałają przestępczości internetowej. Dzięki AMTSO wyciągnęliśmy wnioski, jak lepiej współpracować z producentami na rzecz wspólnego dobra, to dobro na końcu otrzymuje klient końcowy.
Większość produktów uzyskuje dobre wyniki w testach. Zatem jakie znaczenie mają drobne różnice w testach?
Szczegóły to pieniądz. Powiedzmy, że produkt X poradził sobie z zagrożeniami w 100%, a drugi w 99,99%. W teorii oba wyniki są niemal równe, prawda? Jednakże jeden produkt dopuścił do sytuacji, gdzie wystąpił o 1 incydent za dużo, a w praktyce może to kosztować firmę miliony dolarów. Właśnie dlatego różnice tkwią w szczegółach.
Czy tak zwane ataki typu „living off the land” sprawiły, że wykrywanie i testowanie złośliwego oprogramowania straciło na znaczeniu?
To, czy coś wykonuje złośliwą akcję w systemie, nawet z użyciem legalnych procesów i aplikacji producenta systemu operacyjnego, dowiadujemy się na końcu incydentu. Uwzględniając jak ewoluowały technologie zabezpieczające nie widzę potrzeby spierania się czym jest „tradycyjne malware”, a czym są ataki „living off the land” (fileless, LOLBins), ponieważ malware może wykorzystywać legalne procesy, a za pomocą legalnych procesów można robić to samo w systemie, co robi malware. Dlatego dzisiaj tak samo atakujący, jak i obrońcy, muszą się wysilać. Mają jednak do dyspozycji lepsze narzędzia niż dekadę temu.
Współczesne rozwiązania muszą charakteryzować się większą wielowarstwową ochroną niż dawniej, kiedy tych ataków było mniej, na mniejszą skalę. Jednocześnie rozwiązania powinny być stosunkowo łatwe w obsłudze, co wcale nie jest proste dla działu deweloperów i inżynierów producenta. Rozwiązanie powinno zapewniać natychmiastową identyfikację zdarzeń ze wszystkich punktów końcowych, musi naprawiać problemy z incydentami szybko i łatwo, aby wspierać małe oraz średnie organizacje w procesie bezpieczeństwa. Co bardzo istotne, produkt dzisiaj nie może „męczyć alertami”, aby ważne incydenty nie zostały przegapione na czas przez osoby zajmujące się bezpieczeństwem w działach SOC (Security Operation Center) lub administratorów na pierwszej linii w mniejszych firmach.
W testach odnosicie się na wykrywanie przed i po uruchomieniu próbki oraz obliczacie nawet czas wykrywania. Wytłumacz jakie są różnice i dlaczego to ma znaczenie?
To zależy od rozwiązania, od podejścia danego producenta do bezpieczeństwa – czy jest zorientowany bardziej na ochronę prewencyjną, czy nadal tkwi w tradycyjnej w detekcji? Różnica pomiędzy podziałem wykrywania zagrożeń przed i po uruchomieniu ma znaczenie w kontekście niuansów technicznych:
- Może to być interesujące dla ludzi, którzy odpowiadają za bezpieczeństwo, zwracają uwagę na detale.
- Dla producentów, którzy dowiadują się, gdzie konkurencja ma przewagę, nad czym warto pracować, aby lepiej wyłapywać zagrożenia na bardzo wczesnym etapie.
- Nie zawsze możliwe jest osiąganie świetnych rezultatów blokowania zagrożeń w fazie pre-execution, dlatego jest to kolejna informacja, czy i jak dobrze produkt radzi sobie z zagrożeniami w fazie post-execution. Według mnie to szalenie ważne, ponieważ pokazuje to realną ochronę danego oprogramowanie przed zagrożeniem, które z jakiś powodów przedostało się do systemu i zostało uruchomione. Myślę, że na tym poziomie zaczyna się cała magia i precyzyjność producenta w wykrywaniu zagrożeń 0-day.
Zostawiając testy na boku, na co użytkownicy powinni zwracać uwagę przy wybieraniu oprogramowania bezpieczeństwa?
Oo, to znowu temat rzeka. Powinniśmy wyraźnie rozdzielić dobór rozwiązania dla firm, z kolejnym podziałem w przypadku wielkości danej firmy i złożonej infrastruktury, pracowników zdalnych itp. a pomiędzy oprogramowaniem dla użytkownika indywidualnego. W przypadku użytkownika indywidualnego może on kierować się także testami tego samego producenta produktów biznesowych. Lecz nie zawsze – nie chcę znowu komplikować, bo wchodzimy w szczegóły modułów, które nie są przeznaczone na komputery do zastosowań niekomercyjnych. Oczywiście cechą wspólną nadal są między innymi: wsparcie producenta, jego renoma, osiągane wyniki w testach, dostępność interfejsu w danym języku, dodatkowe moduły dla kluczowych pracowników np. ochrona bankowości, cena rozwiązania oraz wsparcie dla różnych typów systemów operacyjnych: Windows, macOS, Android itp. Dzisiaj każdy z nas może mieć więcej niż jedno, dwa urządzenia, z którego korzystamy, a często chcemy też zabezpieczyć całą naszą rodzinę w gospodarstwie domowym.
Jeśli chodzi o firmy to zwracałbym uwagę na dostępność funkcji w konsoli administratora pod konkretne wymagania infrastruktury serwerowo-komputerowej. Na integrację z dodatkowymi usługami, jak np. SIEM. Na wsparcie ochrony z EDR dla stacji roboczych innych niż Windows – macOS, Linux. W przypadku systemów przemysłowych warto zwrócić uwagę na możliwość custom-implementacji ochrony i pokrywanie protokołów sieciowych z monitorowaniem przepływy danych. Do tego dochodzą możliwości zdalnego zarządzania, izolację komputerów z incydentami, wyszukiwanie śladów włamań, automatyzację zadań administracyjnych i tak dalej. Oczywiście to są tylko przykłady. Szczegółowa analiza zapotrzebowania musi być podyktowana wcześniejszym opracowaniem wymagań dla konkretnej firmy, analizą ryzyka.
