Integracja SIEM
Co trafia dziś do Państwa SIEM i co jeszcze nie.
Clavitor zapisuje każdą operację na poświadczeniach w ścieżce audytu z łańcuchem skrótów i mogą ją Państwo wyeksportować. Strumień na żywo do Państwa SIEM, z punktem końcowym pull, strumieniowaniem i standardowymi formatami logów, nie jest zbudowany, choć części jego projektu są zdecydowane. Ta strona trzyma te dwie rzeczy osobno, aby mogli Państwo ocenić produkt w postaci, w jakiej jest dziś dostarczany.
Dziś
Prawdziwa ścieżka audytu i CSV do samodzielnego wczytania.
Każdy sejf prowadzi własny dziennik audytu. Każde zdarzenie zawiera czas, operację, wynik (z powodem, tam gdzie jest), wpis, którego dotyczyło, aktora, źródłowy adres IP i swoją pozycję w łańcuchu. Filtrują Państwo dziennik według wpisu, aktora, adresu IP, operacji, wyniku i zakresu dat, a następnie eksportują przefiltrowany widok.
Pola
time · action · outcome · reason · entry · actor · ip · seq
Eksport
Plik CSV przefiltrowanego widoku, pobrany ze strony audytu sejfu Pana/Pani. Zawiera do 500 zdarzeń na eksport; aby dotrzeć do pozostałych, należy zawęzić filtry.
Wprowadzenie do SIEM
Plik jest zwykłym CSV, więc przyjmie go każdy SIEM obsługujący pliki. Sposób załadowania pozostaje po stronie Pana/Pani: Clavitor nie udostępnia dziś konektora, agenta ani dostawy według harmonogramu.
Integralność
Dowód, nie tylko log.
Każde zdarzenie jest dowiązane haszem do poprzedniego, a jedno wywołanie przechodzi łańcuch ponownie i zgłasza, czy jest nienaruszony, czy przerwany, oraz gdzie nastąpiło przerwanie. Pozycja łańcucha każdego sejfu jest też wysyłana do centrali, domyślnie co dziesięć minut, jako świadek poza sejfem; log krótszy niż pozycja potwierdzona przez świadka albo ze zmienionym haszem potwierdzonym przez świadka wywołuje alert operatora. Jak działają łańcuch i świadek →
Jeszcze nie zbudowano
Feed do SIEM.
Nic z poniższego nie istnieje dziś w produkcie. Żaden endpoint na to nie odpowiada, a formatu logu innego niż powyższy CSV nie da się wytworzyć.
Endpoint pull i strumieniowanie
SIEM odpytujący endpoint o nowe zdarzenia albo zdarzenia wypychane do niego w chwili powstania. Oba te mechanizmy opisano w tekście naszego planu; żaden nie istnieje. Wymieniono je tutaj ze statusem nie zbudowano, nie jako obietnicę.
Standardowe formaty logów
Mapowanie feedu audytu na OCSF, CEF lub LEEF dla SIEM Pana/Pani. Zdecydowano jako opcjonalne wyjście węzła logów; nie zbudowano.
Węzeł logów i widok audytu MSP
Dedykowany węzeł logów, który odbiera zdarzenia audytu z sejfów szyfrowanym kanałem Noise, przechowuje je jako natywne rekordy Clavitor (nigdy jako ciągi znaków CEF ani LEEF) i udostępnia wielodzierżawny podgląd audytu dla klientów MSP. Zdecydowano; nie zbudowano. Zdecydowano, że treści zdarzeń audytu pozostają poza centralą.
Reguła prywatności
Reguła, której musi przestrzegać każdy feed.
Jeśli ta sama osoba używa Clavitor w życiu prywatnym i u pracodawcy, SIEM pracodawcy nie może nigdy zobaczyć części prywatnej, nawet nieudanego logowania do konta prywatnego. To zdecydowana, twarda reguła dla każdego feedu: zdarzenia filtruje się według tego, kto jest właścicielem poświadczenia (osoba prywatna albo przedsiębiorstwo), a nie według tego, kim jest użytkownik, i dzierżawy pozostają od siebie odizolowane.
Dziś reguła jest zachowana, bo nic nie jest eksportowane do żadnego SIEM. W kodzie nie ma jeszcze filtra, bo nie ma feedu, którego miałby strzec. Reguła stanie się kodem wraz z feedem i jest warunkiem, który feed musi spełnić.
Potrzebuje Pan/Pani feedu SIEM, aby kupić?
Prosimy podać SIEM, format i oczekiwany sposób dostarczenia zdarzeń. Wolimy zaprojektować to z Panem/Panią, niż żeby ograniczenie wyszło na jaw później.