SecureVisio w pigułce: Co platforma faktycznie robi i jak jest zbudowana?

Istnieje kategoria platform bezpieczeństwa, która reklamuje się jako „unified”, ale w rzeczywistości jest jedynie zestawem luźno zintegrowanych produktów punktowych pod parasolem jednego dostawcy. SecureVisio stara się być czymś strukturalnie innym: platformą, w której komponenty natywnie współdzielą dane, a reguły korelacji mogą jednocześnie odwoływać się do wyników anomalii UEBA, wyników skanowania podatności, metadanych zasobów CMDB i atrybutów Active Directory – nie poprzez wywołania API między oddzielnymi systemami, lecz jako pełnoprawne dane wejściowe tej samej reguły. Czy to twierdzenie się sprawdza, zależy od szczegółów implementacji. Niniejsza analiza opisuje, co platforma faktycznie robi, jak łączą się jej elementy i gdzie architektura podejmuje świadome decyzje odróżniające ją od bardziej konwencjonalnych podejść.

1. Zunifikowana architektura: Co faktycznie łączy

SecureVisio integruje sześć odrębnych warstw funkcjonalnych w jednym wdrożeniu: silnik SIEM do zbierania logów i korelacji zdarzeń; warstwę UEBA do profilowania behawioralnego użytkowników i podmiotów; moduł SOAR do automatycznych i sterowanych playbookiem reakcji; komponent zarządzania podatnościami; elektroniczny system dokumentacji sieci i usług (opisany jako CMDB i BIA); oraz asystenta AI ukierunkowanego na przepływy pracy SOC. Twierdzenie nie brzmi jedynie, że te komponenty współistnieją w jednym interfejsie, lecz że operują na wspólnych strukturach danych.

Architektoniczne znaczenie tego faktu nie jest kosmetyczne. W środowiskach, gdzie SIEM, UEBA i zarządzanie podatnościami to oddzielne produkty, skorelowanie anomalii behawioralnej ze znanym CVE na dotkniętym hoście wymaga zazwyczaj ręcznego wysiłku analityka lub niestabilnych integracji na zamówienie. W SecureVisio silnik reguł korelacji jest udokumentowany jako zdolny do przyjmowania danych o podatnościach, wyników anomalii UEBA, klasyfikacji zasobów CMDB i dokumentacji sieciowej jako bezpośrednich danych wejściowych – ten sam zestaw reguł, który przetwarza sparsowane pola logów, może jednocześnie sprawdzić, czy host źródłowy posiada krytyczną niezałataną podatność, czy konto użytkownika jest oznaczone jako uprzywilejowane i czy zasób jest sklasyfikowany jako przetwarzający wrażliwe dane osobowe. Tego rodzaju kontekstualne wzbogacanie, dostępne na poziomie oceny reguł bez zewnętrznych wywołań API, jest znaczącą różnicą architektoniczną.

Model wdrożenia jest w pełni on-premises. Wszystkie komponenty – kolektory, analityka, przechowywanie, inferencja AI – działają w infrastrukturze klienta. Dokumentacja wyraźnie odnotowuje możliwość działania w strefach sieciowych izolowanych od internetu. Dostępna jest również opcja dostarczania SIEMaaS. Architektura jest oparta na kolektorach: oddzielne węzły kolektorów obsługują niezależnie pozyskiwanie logów, przetwarzanie korelacji, analitykę, przechowywanie danych, operacje AI i działania reaktywne – z możliwością poziomego skalowania przez dodawanie węzłów bez konsekwencji licencyjnych.

2. Zbieranie i normalizacja logów

Strona pozyskiwania obejmuje solidny zakres protokołów: Syslog, TLS Syslog, NetFlow, Windows Event Forwarding, IMAPS, POP3S i MAPI jako kanały podstawowe; RESTful API, ODBC, agenty odczytujące pliki oraz zapytania WMI/WQL jako źródła dodatkowe. Obsługa Windows Event Forwarding oznacza, że na systemach Windows nie są wymagani agenci do zbierania dzienników zdarzeń – platforma korzysta z natywnego mechanizmu przekazywania Windows, co jest rozsądnym wyborem dla środowisk, gdzie wdrożenie agentów jest operacyjnie trudne.

Silnik normalizacji ujawnia głębię techniczną bardziej wyraźnie. Obsługiwane formaty wejściowe obejmują CEF, LEEF, URI, SYSLOG (RFC 3164), XML, JSON i REGEX – pokrywając większość tego, co spotyka się w praktyce. Dla źródeł niedopasowanych do żadnego standardowego formatu dostępny jest graficzny kreator parserów. Bardziej interesująca jest obsługa wieloetapowej normalizacji: pojedyncze zdarzenie może być przetwarzane sekwencyjnie przez wiele parserów – na przykład CEF, następnie URI, następnie REGEX – aby obsługiwać formaty logów, które osadzają dane strukturalne w danych strukturalnych, co jest powszechne w logach aplikacyjnych owijających payloady HTTP w koperty syslog.

Obsługiwane jest wersjonowanie parserów z możliwością wycofania zmian, co ma istotne znaczenie operacyjne. Zmiany parsera psujące istniejącą logikę wykrywania należą do najbardziej zakłócających zdarzeń konserwacyjnych w operacjach SIEM. Możliwość wdrożenia aktualizacji parsera etapami, przetestowania jej i wycofania bez zakłócania produkcyjnego pozyskiwania danych odpowiada na realny ból operacyjny.

Zdarzenia są automatycznie kategoryzowane według typów semantycznych – logowanie, wylogowanie, zmiana uprawnień, błąd konfiguracji, skanowanie portów, złośliwe oprogramowanie – co upraszcza pisanie reguł korelacji wymagających dopasowywania kategorii zachowań, a nie identyfikatorów zdarzeń specyficznych dla dostawcy. Krok wzbogacania geolokalizacją dołącza podczas normalizacji nazwy i kody krajów na podstawie źródłowych adresów IP, udostępniając ten kontekst dla korelacji dalszych etapów bez dodatkowego przetwarzania.

Interfejs przeglądarki logów obsługuje wyszukiwanie oparte na polach, wyrażenia logiczne, zawężanie zakresu czasowego i filtrowanie źródeł. Zapytania można zapisywać i ponownie wykorzystywać. Filtry można budować klikając bezpośrednio na pola zdarzeń – funkcja użyteczności zmniejszająca tarcie przy budowie zapytań, które spowalnia dochodzenia w systemach wymagających ręcznej konstrukcji SPL lub KQL.

3. Korelacja, UEBA i jak wzajemnie się zasilają

Silnik korelacji działa w czasie pozyskiwania, oceniając zdarzenia w momencie ich rejestrowania, a nie retrospektywnie. Reguły są tworzone przez graficzny interfejs i mogą odwoływać się do szerokiego zestawu danych wejściowych: sparsowanych pól zdarzeń i ich wartości; list referencyjnych (używanych dla list dozwolonych/zabronionych lub kontekstowych wyszukiwań); atrybutów użytkowników i komputerów pobranych z Active Directory; bazy danych IoC; danych zasobów i usług z CMDB i mapy sieci; wyników anomalii UEBA z warstw UBA i EBA; wyników podatności i oceny zgodności konfiguracji; oraz mapowań technik MITRE ATT&CK. Ten ostatni punkt oznacza, że reguły korelacji mogą być otagowane technikami ATT&CK, umożliwiając filtrowanie i raportowanie według kategorii frameworku ataku, a nie tylko według nazwy reguły.

Predefiniowana biblioteka reguł obejmuje ilościowe wykrywanie anomalii na woluminach danych, liczbach pakietów i liczbach procesów; wykrywanie skanowania portów; wykrywanie nowych wartości pojawiających się w określonych polach w zdefiniowanym oknie czasowym (przydatne do wyłapywania po raz pierwszy widzianych nazw hostów lub nazw procesów); oraz wykrywanie sekwencji zdarzeń dla reguł kill-chain wymagających wystąpienia wielu warunków w określonej kolejności.

Anomalie UEBA nie są jedynie wyświetlane na osobnych dashboardach – generują nowe zdarzenia w repozytorium logów i mogą bezpośrednio wyzwalać playbooki. Warstwa behawioralna zasila z powrotem ten sam strumień zdarzeń, na którym operuje silnik korelacji.

Implementacja UEBA jest wielowarstwowa. Oddzielne profile behawioralne są prowadzone dla kont użytkowników (UBA) i podmiotów komputerowych (EBA). W ramach tych kategorii istnieje dalsze rozróżnienie między profilami dla kont uprzywilejowanych i standardowych oraz między stacjami roboczymi, serwerami, serwerami WWW, systemami domenowymi i systemami poza domeną. Ta szczegółowość ma znaczenie, ponieważ normalne zachowanie uprzywilejowanego konta usługowego na kontrolerze domeny strukturalnie różni się od konta użytkownika stacji roboczej. Wbudowana jest również świadomość zakresu czasowego, z oddzielną obsługą aktywności podczas zdefiniowanych godzin pracy i poza nimi.

4. Asystent AI: Kontekst, zakres i integracja z przepływem pracy

Asystent AI jest opisany jako integrujący się zarówno z lokalnymi, jak i publicznymi modelami LLM, co sugeruje, że platforma obsługuje zarówno wdrożenia air-gapped korzystające z lokalnie hostowanych modeli, jak i konfiguracje podłączone do internetu używające komercyjnych API LLM. Asystent nie jest ogólnym interfejsem czatu przypiętym do platformy – jest ukierunkowany na konkretne obszary przepływu pracy, z promptami przypisywalnymi do kontekstów obejmujących obsługę incydentów, zarządzanie podatnościami, przegląd i analizę logów, analizę korelacji, tworzenie parserów i analizę zachowań UEBA.

To ukierunkowanie ma kluczowe znaczenie dla praktycznej użyteczności. Ogólny asystent LLM poproszony o pomoc przy incydencie bezpieczeństwa nie ma świadomości aktualnego stanu platformy. Kontekstowo ukierunkowany asystent, który podczas pracy w kontekście obsługi incydentu ma dostęp do logów powiązanych z tym incydentem, odpowiednich reguł korelacji, które się uruchomiły, wyników behawioralnych UEBA dla zaangażowanych kont, stanu podatności dotkniętych zasobów, dokumentacji sieciowej tych zasobów, mapy usług i bieżącego kontekstu Threat Intelligence – to zupełnie inna propozycja. Dokumentacja opisuje dokładnie to: asystent AI operuje na pełnym kontekście logów, zdarzeń korelacji, danych UEBA, wyników podatności, dokumentacji sieciowej, map usług i Threat Intelligence, aby sugerować konkretne działania i automatyzacje playbooków.

Wersjonowanie promptów jest obsługiwane przez wbudowany edytor, z możliwością tworzenia, modyfikowania i utrzymywania wersjonowanych szablonów promptów oraz pobierania gotowych szablonów z portalu dostawcy. Tryb ciągłej pracy pozwala asystentowi dynamicznie przełączać kontekst w oparciu o to, co analityk aktualnie robi w systemie, bez konieczności jawnego wyboru kontekstu.

5. Dokumentacja sieci, klasyfikacja danych i Threat Intelligence

Komponent dokumentacji sieci funkcjonuje jednocześnie jako repozytorium CMDB i Business Impact Analysis. Prowadzi centralny rejestr komponentów infrastruktury z definiowalnymi przez użytkownika parametrami obejmującymi atrybuty takie jak krytyczność systemu i typy przetwarzanych danych. Nie jest to pasywny inwentarz zasobów – to ta sama struktura danych zasilająca silnik korelacji i logikę priorytetyzacji podatności. Zasoby tu udokumentowane stają się kontekstem, na podstawie którego reguły korelacji oceniają przynależność do strefy bezpieczeństwa, wrażliwość danych i krytyczność usług.

Interaktywna mapa sieci wizualizuje strefy bezpieczeństwa, urządzenia, serwery i stacje robocze. Obsługuje definiowanie dozwolonych wzorców komunikacji między zasobami i mapowania nazw usług na zasób. Platforma zawiera automatyczne reguły dokumentacyjne, które wykrywają nowe zasoby, usługi i połączenia w miarę ich pojawiania się w danych logów; po weryfikacji przez operatora automatycznie aktualizują elektroniczną dokumentację. Adresuje to jedno z trwałych operacyjnych niepowodzeń tradycyjnych podejść CMDB, gdzie dokumentacja staje się nieaktualna, ponieważ infrastruktura zmienia się szybciej niż manualne procesy aktualizacji są w stanie nadążyć.

Klasyfikacja danych jest wbudowana w warstwę dokumentacji. Można definiować niestandardowe schematy klasyfikacji – dane osobowe, własność intelektualna, dokumenty finansowe lub dowolna taksonomia odpowiadająca wymogom zgodności organizacji. Lokalizacje danych są mapowane na mapę sieci, a zasoby powiązane z usługami biznesowymi i kontami użytkowników. Ta klasyfikacja propaguje do priorytetyzacji podatności i kontekstu reguł korelacji, co oznacza, że reguła wykrywania może traktować incydent inaczej w zależności od tego, czy dotknięty zasób przetwarza dane sklasyfikowane.

Baza danych IoC obsługuje kompleksowy zakres typów wskaźników: FQDN, adresy e-mail, nazwy plików, ścieżki plików, skróty, adresy IP, klucze rejestru i ciągi poleceń. Integracja z MISP i innymi platformami Threat Intelligence zapewnia automatyczną synchronizację list wskaźników i danych referencyjnych, w tym list złośliwych adresów IP, czarnych list domen i list węzłów wyjściowych Tor.

6. Zarządzanie podatnościami: Architektura priorytetyzacji

Zarządzanie podatnościami w SecureVisio wykracza poza importowanie wyników skanowania i przypisywanie wyników CVSS. Logika priorytetyzacji jest wielowymiarowa i opiera się na tych samych danych kontekstowych, które zasilają korelację i UEBA. Podatność jest priorytetyzowana według wielu czynników:

• strefy bezpieczeństwa, w której znajduje się dotknięty zasób;
• ocenianego prawdopodobieństwa, że atakujący jest już obecny w środowisku;
• typu i krytyczności zasobu;
• typu i wrażliwości danych przetwarzanych przez zasób;
• usług działających na zasobie;
• parametrów CVSS samej podatności;
• statusu zgodności konfiguracji zasobu;
• oraz szacowanego prawdopodobieństwa udanego włamania ze strefy bezpieczeństwa aktualnie zajmowanej przez zasób.

Ta architektura generuje wynik priorytetyzacji kontekstowo wrażliwy w sposób, którego surowe wyniki CVSS nie zapewniają. Podatność o wysokim CVSS na izolowanym serwerze deweloperskim bez wrażliwych danych i zewnętrznej łączności nie stanowi tego samego ryzyka operacyjnego co podatność o średnim CVSS na kontrolerze domeny z bezpośrednim dostępem do hurtowni danych. Strefowe szacowanie prawdopodobieństwa włamania próbuje modelować pozycję atakującego względem zasobów, tak aby podatności na zasobach bardziej dostępnych z prawdopodobnych punktów wejścia atakującego były ważone wyżej niezależnie od poziomu CVSS.

Pasywna analiza podatności jest obsługiwana obok integracji z aktywnym skanerem. Podejście pasywne wykorzystuje dane Common Platform Enumeration (CPE) z dokumentacji zasobów do wyszukiwania powiązanych CVE bez konieczności aktywnego skanowania, co jest przydatne dla zasobów, gdzie aktywne skanowanie jest operacyjnie ograniczone. Integracja ze skanerami innych firm umożliwia inicjowanie skanowania, import wyników i usuwanie skanów z poziomu interfejsu SecureVisio. Obsługa podatności jest zarządzana przez ten sam framework playbook co incydenty, z planowaniem remediacji, powiązaniem incydentów, śledzeniem SLA i eskalacją.

7. Model licencjonowania i dlaczego ma implikacje architektoniczne

Licencjonowanie SecureVisio nie nakłada żadnych limitów na zdarzenia na sekundę (EPS), wolumen logów ani liczbę jednocześnie działających operatorów. Warto to technicznie przeanalizować, nie tylko komercyjnie, ponieważ licencjonowanie oparte na wolumenie tworzy presję architektoniczną kształtującą sposób wdrażania i użytkowania platform.

W wdrożeniach z ograniczonym wolumenem operatorzy stają przed praktycznym wyborem między kompleksowym pozyskiwaniem logów a kosztami. Typową reakcją jest agresywne filtrowanie na warstwie zbierania, odrzucające źródła logów lub typy zdarzeń uznane za niski priorytet. To filtrowanie pogarsza jakość korelacji w sposób, który nie zawsze jest przewidywalny w czasie zbierania – znaczenie źródła logów często staje się jasne dopiero podczas dochodzenia w incydencie, nie podczas planowania pojemności.

Usunięcie ograniczeń wolumenu zmienia rachunek wdrożeniowy. Operatorzy mogą pozyskiwać wszystkie dostępne źródła logów bez filtrowania z powodów kosztowych, zasilać pełny strumień zdarzeń i prowadzić kompletne historyczne rejestry do dochodzenia kryminalistycznego bez zarządzania warstwowym przechowywaniem w celu kontroli kosztów. Dokumentacja wyraźnie odnotowuje, że telemetria UEBA nie jest ograniczona wolumenem licencyjnym. To samo dotyczy liczby jednocześnie działających operatorów, co na platformach z ograniczonym wolumenem czasami tworzy rywalizację podczas intensywnej reakcji na incydenty, gdy wielu analityków potrzebuje jednoczesnego dostępu.

W praktyce nieograniczone licencjonowanie wolumenu przenosi koszt z konsumpcji na możliwości. Architektura kolektora per-węzeł oznacza, że skalowanie wydajności (dodawanie kolektorów w miarę wzrostu wolumenu pozyskiwania) ma koszt infrastrukturalny, ale jest on liniowy i przewidywalny, zamiast korelować z wolumenem zdarzeń bezpieczeństwa w sposób tworzący przewrotne zachęty do ograniczania logowania.

Architektura SecureVisio przedstawia spójny argument techniczny. Decyzja o zbudowaniu korelacji, UEBA, zarządzania podatnościami i dokumentacji zasobów na wspólnym modelu danych – zamiast integrowania oddzielnych produktów – ma realne konsekwencje dla tego, co analitycy mogą robić na poziomie oceny reguł. Przekazywanie wyników warstwy behawioralnej do repozytorium logów (zamiast utrzymywania oddzielnych dashboardów UEBA) to konkretna decyzja projektowa umożliwiająca wyniKom UEBA uczestnictwo w korelacji i automatycznej reakcji bez niestandardowej pracy integracyjnej. Logika priorytetyzacji zarządzania podatnościami odzwierciedla rozumienie, że wyniki CVSS są konieczne, ale niewystarczające, i że ryzyko jest funkcją kontekstu środowiskowego w równym stopniu jak ciężkości podatności.