--- title: Anomalie description: Każda polityka, użytkownik, aplikacja i agent AI uczy się własnej linii bazowej, a dzisiejsza aktywność mierzona jest względem niej - z pokrętłem czułości, które przesuwasz i natychmiast widzisz odpowiedź, na swoich prawdziwych danych, bez okresu strojenia. icon: Activity --- # Anomalie (Anomalies) Ekran Anomalii odpowiada na pytanie, które po cichu zadaje sobie każdy zespół bezpieczeństwa: **„Co z tego wszystkiego, co wydarzyło się dzisiaj, jest naprawdę nietypowe - i czy w ogóle bym to zauważył?"** Każda aktywna polityka w Twoim tenancie nieustannie uczy się własnej normy, a gdy dzisiejsza aktywność skacze ponad nią, otwiera się anomalia - bez progów do skonfigurowania, bez reguł do przewidzenia. ## Co Możesz Osiągnąć ## Dzisiaj, Mierzone Względem Twoich Ostatnich 30 Dni Porównanie jest celowo proste do wypowiedzenia: **Dzisiejsza liczba względem mediany z poprzednich 30 dni.** - **Dzisiaj** to dzisiejsza wartość i jest ona _żywa_ - przeliczana wraz z napływającą aktywnością (w ciągu minut od nowego zdarzenia audytowego), nie raz na dobę. Anomalia, która zaczyna się dziś rano, jest na tym ekranie dziś rano, a jej liczby aktualizują się, dopóki skok trwa. - **Linia bazowa** to mediana 30 poprzednich dziennych wartości, **z wyłączeniem dzisiaj** - więc skok nigdy po cichu nie podnosi poprzeczki, którą sam ma przekroczyć. Mediana, nie średnia: jeden szalony dzień w przeszłości nigdy nie zatruwa znaczenia „normy". - **Rozrzut** mierzony jest równie odpornie (medianowe odchylenie bezwzględne), więc „jak bardzo ponad normę" wyrażone jest w Twojej własnej codziennej zmienności, a nie w liczbie, którą ktoś wybrał. - **Dzienny przebieg kontrolny** sprawdza każdy tenant raz na dobę, więc spokojny dzień też zostaje zapisany jako dzień - linia bazowa z dziurami to linia bazowa, której nie można ufać. Detekcja milczy przez pierwsze **14 dni** historii każdego obserwowanego bytu. Czternaście dni to moment, w którym mediana i jej rozrzut zaczynają coś znaczyć; wcześniej 1Security zbiera dane i milczy, zamiast wymyślać alerty z tygodnia obserwacji. Detekcja jest celowo jednostronna: **flagowane są wyłącznie skoki**. Aktywność spada nieustannie z niegroźnych powodów - spokojne dni, porządki, rozwiązane ustalenia - a kolejka pełna spadków zagrzebałaby skok, który naprawdę ma znaczenie. ## Linia Bazowa Per Polityka, Per Użytkownik, Per Aplikacja, Per Agent Same kategorie są cięte według tego, jak ludzie naprawdę się zachowują, a nie według nazw API: usuwanie poczty mierzy się osobno od niszczenia plików, bo skrzynkę opróżnia każdy, a pliki poza kosz czyści prawie nikt - jedna linia bazowa dla obu pozwoliłaby higienie skrzynki nosić ważność niszczenia plików i zagłuszyć sygnał, który się liczy. Ten sam podział widać w ważnościach: nietypowe usuwanie poczty stempluje *niską*, nieodwracalne niszczenie plików i witryn *średnią*, a oba potwierdzają się nawzajem, gdy ruszają razem. Jedna z tych kategorii jest świadomie porównywana z historią, a nie alertowana przy każdym wystąpieniu: **administrator usuwający komuś MFA**. Zdjęcie drugiego składnika zamienia hasło, które atakujący już ma, w działającym logowaniu - a jednocześnie jest codzienną robotą helpdesku dla kogoś, kto zmienił telefon. Jedno i drugie to to samo kliknięcie, więc liczymy to per administrator wobec jego własnej historii, a metody usuwane przez kogoś na własnym koncie nie liczą się w ogóle. Ta sama maszyneria działa na dwóch poziomach. Anomalie **całej polityki** obserwują łączny wynik detektora - „ta polityka dopasowywała 12 rzeczy dziennie przez miesiąc, dziś dopasowała 2000". Anomalie **per byt** obserwują jednego uczestnika względem jego własnej historii - konkretnego użytkownika, konkretną aplikację zewnętrzną albo konkretnego **agenta AI**. To ostatnie z każdym kwartałem waży więcej. Zasięg rażenia agenta wyznaczają jego uprawnienia, nie prompt, a „agent finansowy był dziś czterokrotnie aktywniejszy niż zwykle” to dokładnie ten sygnał, którego nikt inny nie jest w stanie dać - wymaga inwentarza agentów, grafu uprawnień i linii bazowej aktywności w jednym produkcie. Najnowsze linie bazowe per byt obserwują nie tylko, ile dana tożsamość robi, ale czego jej aktywność dotyka. Każdy odczyt pliku i maila jest klasyfikowany już przy pozyskaniu pod kątem tego, czy treść niosła w tym momencie dane wrażliwe lub zastrzeżone - stempel z chwili odczytu przetrwa późniejsze usunięcia i ponowne skany, więc zapis tego, po co naprawdę sięgnięto, pozostaje wiarygodny. Na nim opierają się: - **Anomalny dostęp do danych wrażliwych per użytkownik** flaguje osobę otwierającą znacznie więcej wrażliwych plików i maili niż jej własna norma - wzorzec przygotowań, który poprzedza eksfiltrację i nie zostawia śladu pobrania, gdy dane czytane są na miejscu. - **Anomalny dostęp do danych wrażliwych przez AI per użytkownik** robi to samo dla treści, z których asystent AI użytkownika buduje swoje odpowiedzi; jego bliźniak po stronie agentów obserwuje odczyty każdego agenta AI z osobna. - **Przesunięcie udziału danych wrażliwych** - u agenta AI i w użyciu AI per użytkownik - obserwuje _procent_ interakcji AI dotykających treści wrażliwych względem własnej historii bytu i łapie dzień, w którym lektura AI przesuwa się ku materiałom wrażliwym, nawet gdy łączny wolumen wygląda zupełnie normalnie. Warto wiedzieć przy czytaniu tych epizodów: ich liczby to punkty procentowe, nie liczba zdarzeń. Detektory dostępu do danych wrażliwych wiedzą też, **skąd wrażliwe informacje pochodzą**. Odczyt, którego jedynymi wrażliwymi nośnikami były maile *przychodzące* - nadawca spoza tenanta - trafia do własnych detektorów poczty przychodzącej (dla ludzi i dla AI) z niższą dotkliwością i wyższym progiem, zamiast zawyżać detektory własnych treści: czytanie danych wrażliwych, które przyszły z zewnątrz, to słabszy sygnał niż sięganie po własne dane organizacji, a asystenci i agenci analizują pocztę przychodzącą pod kątem streszczeń i odpowiedzi przez cały dzień. Jeden własny nośnik w zestawie zatrzymuje odczyt w surowszym detektorze. Ponieważ linia bazowa uczona jest per polityka i per byt, „anomalne" zawsze znaczy *anomalne dla tego jednego, w tym tenancie*. Pięćset udostępnień plików może być zwykłym wtorkiem w jednej organizacji i pięcioalarmowym incydentem w innej - ten sam ekran obsługuje oba przypadki bez żadnej konfiguracji. ## Incydenty - Kiedy Jedno Zdarzenie Wystarczy Nie wszystko powinno czekać na linię bazową. Niektóre zdarzenia niosą werdykt w sobie - platforma oflagowała interakcję albo Twoi administratorzy już wcześniej uznali dane za niedostępne - a ich statystyczne ocenianie tylko opóźniłoby alarm. Te detekcje to **incydenty** - pełnoprawny rodzaj obok anomalii: odpalają przy każdym wystąpieniu, nie potrzebują historii, zawsze alertują, a suwak czułości nigdy ich nie dotyczy - werdykt nie jest czymś, co statystyczne pokrętło powinno umieć wyciszyć. Przełącznik **Incydenty / Anomalie** w kolejce rozdziela oba rodzaje, a wiersz incydentu pokazuje, co i ile razy się odpaliło, zamiast wyniku. Detektory incydentów: - **Próby prompt injection** - per użytkownik i u każdego agenta AI: interakcja AI oflagowana jako próba manipulacji, czy to jailbreak wpisany przez kogoś, czy instrukcje ukryte w treści, którą asystent przeczytał. Dla prompt injection nie istnieje niewinna linia bazowa. - **Reguła skrzynki, a po niej seria usunięć** - nowa reguła skrzynki odbiorczej i, w ciągu 48 godzin, nietypowa seria usuniętych maili lub plików: klasyczna sekwencja przejęcia skrzynki. Każdy sygnał osobno to codzienny szum; razem to alarm o wysokiej precyzji. - **Dane zastrzeżone osiągnięte przez AI** - per użytkownik i per agent AI: asystent lub agent AI buduje odpowiedź na treści niosącej typ danych, który Twoi administratorzy jawnie zastrzegli. Zastrzeżenie już mówi, że te dane nie mogą trafiać do AI, więc każde wystąpienie to żywa luka między zadeklarowaną polityką a tym, co AI naprawdę potrafi przeczytać. - **Dostęp do danych zastrzeżonych per użytkownik** - osoba otwiera plik lub mail niosący typ danych uznany za całkowicie niedostępny (zero dostępu dla kogokolwiek). Werdykt pochodzi z tego, co treść niosła w chwili odczytu, więc pozostaje w mocy, nawet jeśli plik zostanie potem usunięty albo ponownie przeskanowany. - **Eskalacja możliwości agenta AI** - pierwsze uprawnienie agenta, które potrafi zmieniać treść, albo jego pierwszy grant obejmujący całą organizację: asystent tylko-do-odczytu staje się piszącym albo wąsko zakrojony zyskuje zasięg na cały tenant. Każdą z tych linii agent przekracza raz, więc każde przekroczenie jest warte spojrzenia. - **Eskalacja źródeł wiedzy agenta AI** - witryna niosąca dane zastrzeżone dołącza do źródeł wiedzy agenta albo jego źródła rozszerzają się na całą organizację. Wychwycone między skanami, zanim jakakolwiek interakcja przeczyta te dane. - **Logowanie wysokiego ryzyka oflagowane przez Microsoft** - Identity Protection ocenia udane logowanie jako wysokiego ryzyka w chwili, gdy się dzieje: wyciekłe poświadczenia, anonimowy lub złośliwy adres IP, niemożliwa podróż. Napastnik już jest w środku, więc każde oflagowane logowanie alertuje - a wszelkie nietypowe pobrania, udostępnienia czy usunięcia tego samego konta tego dnia to ciąg dalszy, który trzeba sprawdzić. - **Ładunek prompt injection podłożony w pliku** - skan treści znalazł ładunek injection *wewnątrz dokumentu*: frazy nadpisujące instrukcje, tekst niewidoczny dla ludzi, ale czytelny dla modeli AI, albo szablon eksfiltracji czekający na wypełnienie. To wyczekująca połowa ataku injection - ładunek leży uzbrojony, aż Copilot lub agent przeczyta plik - wychwycona przez sam skan, zanim dojdzie do jakiejkolwiek interakcji AI. - **Ładunek prompt injection w e-mailu** - te same typy ładunków znalezione w wiadomości: poczta to najtańszy sposób podłożenia instrukcji tam, gdzie przeczyta je asystent AI, więc każde znalezisko alertuje, zanim jakikolwiek asystent go dotknie. - **Password spray na konto** - nieudane logowania z wielu adresów IP, z których konto nigdy się nie loguje, w ciągu jednego dnia. Jedna próba z adresu i setki adresów to kształt zbudowany tak, by nie wywołać blokady per adres - i baseline wolumenowy go nie widzi: im dłużej trwa kampania, tym bardziej wygląda na normę. Krytyczny, gdy próbę zatrzymało dopiero MFA lub Conditional Access (hasło jest znane), wysoki, gdy konto jest włączone bez MFA albo próby idą starszymi protokołami, których MFA nie obejmuje, w pozostałych przypadkach średni. Konta, którym Microsoft już zablokował logowanie, nie podnoszą niczego - żadna próba ich nie otworzy, a kampanię widać po kontach, które faktycznie da się otworzyć. - **Reguła skrzynki przekazuje lub kasuje pocztę** - reguła, która wysyła przychodzącą pocztę poza organizację albo kasuje ją od razu po dostarczeniu. Zwykłe reguły układają wiadomości po folderach; te dwie akcje to sposób, w jaki ktoś, kto przejął skrzynkę, czyta ją z zewnątrz i pilnuje, żeby właściciel się nie zorientował. Outlook desktop i Outlook w przeglądarce raportują tworzenie reguł inaczej - czytamy oba, więc reguła założona w którymkolwiek z nich się liczy. - **Reguła transportowa przekierowuje lub ukrywa pocztę** - reguła na poziomie całej organizacji, która przekierowuje albo kopiuje wiadomości tam, gdzie nie były adresowane, albo wyłącza własne wpisy audytowe. Działa przed dostarczeniem i nie potrzebuje dostępu do żadnej skrzynki, co czyni ją najsilniejszym sposobem przechwytywania poczty w Microsoft 365; reguła, która wycisza własne logowanie, coś ukrywa niezależnie od reszty. - **Phishing dotarł do skrzynki** - Microsoft Defender uznał wiadomość za phishing lub złośliwe oprogramowanie, a ta i tak dotarła: albo została od razu przekierowana poza organizację, albo przepuszczona, bo jeden z Waszych własnych wpisów zaufanego nadawcy lub domeny przebił werdykt. Klasyfikacja jest Microsoftu, więc nie ma tu czego zestawiać z historią - liczy się to, że ochronę udało się obejść. - **Nadawca dodany do listy zaufanych skrzynki** - adres albo cała domena dopisane do zaufanych nadawców skrzynki. Wszystko z tej listy omija filtrowanie spamu i phishingu dla tej skrzynki, więc dopisanie nadawcy, z którego zaraz pójdzie phishing, to najtańsza droga obok Microsoftu - i zwykle to właśnie ten wyjątek stoi za dostarczonym phishingiem. Exchange zapisuje całą listę przy każdej edycji, więc porównujemy ją z poprzednią edycją tej samej skrzynki i liczą się tylko rzeczywiste dopisania. - **Osłabiony Conditional Access** - zmiana w obwodzie logowania, która zdjęła ochronę zamiast ją dołożyć: polityka wyłączona albo usunięta, gdy była włączona, użytkownik, grupa, rola lub aplikacja dopisane do wyjątków, zdjęty wymóg MFA albo zgodnego urządzenia, wpuszczone z powrotem uwierzytelnianie legacy, albo zakres sieci oznaczony jako zaufany, przez co omija polityki wyłączające zaufane lokalizacje. Porównujemy politykę przed i po, więc zwykłe zaostrzenie czy zmiana nazwy niczego nie podnoszą. - **Dodany sekret lub certyfikat aplikacji** - nowy sekret klienta albo certyfikat dopięty do rejestracji aplikacji. Takie poświadczenie loguje się jako *aplikacja*, więc zachowuje wszystkie jej uprawnienia i przeżywa reset hasła, ponowną rejestrację MFA i wyczyszczenie urządzenia - to standardowy sposób, w jaki jedna przejęta sesja zamienia się w trwały dostęp. Microsoft raportuje dodanie i usunięcie klucza pod jedną operacją, więc liczą się tylko zmiany, po których lista kluczy urosła. - **Site otwarty na udostępnianie na zewnątrz** - site collection, któremu poszerzono udostępnianie: włączone linki anonimowe, włączone udostępnianie gościom, zdjęte ograniczenie do już zaproszonych gości albo zgoda na dalsze udostępnianie przez gości. Microsoft zapisuje te ustawienia także za każdym razem, gdy zakłada site - i to jest większość surowego ruchu; te przypadki odsiewamy, więc widzicie człowieka zmieniającego istniejący site. - **Dane wyniesione przed zamknięciem konta** - konto wyłączone albo skasowane po dwóch tygodniach pobierania lub kasowania znacznie ponad własną normę. To kształt odejścia z plikami i da się go zobaczyć tylko wstecz: dopóki osoba była pracownikiem, aktywność wyglądała zwyczajnie, a dopiero offboarding mówi, na który dwutygodnik patrzeć. Porównanie idzie do wcześniejszego zachowania tego samego konta, więc ktoś, kto z racji pracy przerzuca pliki, nie trafia tu tylko dlatego, że odchodzi. Dwa detektory ładunków prompt injection są **napędzane skanem**: pochodzą z własnej analizy treści 1Security, a nie ze strumienia aktywności, więc obejmują atak *zanim* wypali - zatruty dokument jest incydentem w chwili, gdy się pojawia, a nie w chwili, gdy potknie się o niego AI. ## Wynik Anomalii i Twoja Linia Alertu Każda anomalia niesie jeden **wynik** - w przybliżeniu: o ile odchyleń dzisiejsza liczba przewyższa typową zmienność tej polityki lub tego bytu. Płaskie historie dostają wartość statystycznie równoważną (test ogona Poissona dla rzadkich zdarzeń, skok procentowy dla licznych), więc każdy epizod ląduje na jednej porównywalnej skali. Ta jedna skala umożliwia istnienie **linii alertu**: - **Na linii lub powyżej** (domyślnie 3.5) - anomalia jest **Alertowana**: trafia do kolejki i, jeśli tak mówi reguła anomalii tenanta lub nadpisanie, powiadamia swoich odbiorców. - **Między 2.0 a linią** - anomalia zostaje jako **Info**: przechowywana po cichu, nigdy nie powiadamia, dostępna jednym przełącznikiem. - **Poniżej 2.0** - zwykła zmienność; nic nie jest zapisywane. Linia rządzi **wyłącznie anomaliami**. Incydenty niosą werdykt, nie pomiar, więc alertują niezależnie od tego, gdzie stoi linia - rozluźnienie suwaka potrafi uciszyć hałaśliwe detektory wolumenowe, ale nigdy nie przeklasyfikuje oflagowanego prompt injection ani logowania wysokiego ryzyka do cichego poziomu. Aby świadomie wyciszyć detektor incydentów, wycisz go nadpisaniem alertowania. Pod wynikiem działa druga, cichsza kalibracja: minimalna liczba zdarzeń każdej metryki - próg, poniżej którego dzień nie może alertować niezależnie od tego, jak płaska jest historia - jest **rozwiązywana na nowo per tenant** z rozkładu aktywności tego właśnie tenanta, w ramach budżetu alertów: mniej więcej tylu dni-aktorów miesięcznie, ile może przekroczyć próg. Firma na 40 osób i przedsiębiorstwo na 40 000 dostają tę samą *czułość* bez ręcznego mierzenia progów w miarę wzrostu klienta, a próg może się zacieśniać tylko w bezpiecznych granicach - rozpędzona (albo celowo zatruwana) linia bazowa nie oślepi detektora. ## Śledzone Domyślnie - Rejestr Bez Obciążenia Statystyczne anomalie nie tworzą pracy, dopóki o nią nie poprosisz. Każdy epizod anomalii otwiera się w stanie **Śledzone**: zapisany z pełną historią, widoczny pod chipem Śledzone, ograniczony do dotkliwości *Informacyjna* i nigdy nie powiadamia - wstrzymane powiadomienie i tak trafia do dziennika powiadomień z powodem `tracked`, więc zapis jest kompletny. Twój zespół może przeglądać wszystko, co widzi 1Security, nie będąc winnym werdyktu w żadnej sprawie. Eskalacja to świadoma decyzja, na wybranym poziomie szczegółowości: - **Per detektor.** Widok **Ustawienia detektorów** ma przy każdym detektorze przełącznik *Śledzony / Zarządzany*. Ustawienie *Zarządzany* otwiera jego epizody do przeglądu - nowe przychodzą jako Otwarte, obecnie śledzone przechodzą na Otwarte z przywróconą wyliczaną dotkliwością i poziomem, działają powiadomienia. Przełączenie z powrotem odsyła otwarte, nieobsłużone epizody do cichego rejestru. - **Per epizod.** Każdy pojedynczy wiersz można wciągnąć do kolejki, ustawiając mu status Otwarte - od tej chwili eskaluje i powiadamia normalnie, choć jego detektor pozostaje śledzony. Ten sam wybór odsyła epizod z powrotem do Śledzonych. **Incydenty są wyjęte spod tej zasady.** Werdykt - oflagowany prompt injection, logowanie wysokiego ryzyka, sekwencja przejęcia skrzynki - zawsze otwiera się w kolejce i zawsze alertuje; „cichy zapis domyślnie” to polityka dla odchyleń, nie dla potwierdzonych zdarzeń. Śledzone epizody nadal liczą się jako **sygnały korelacji**: śledzony skok pobrań wciąż potwierdza otwarte ryzykowne logowanie tego samego użytkownika - cichy poziom wyostrza głośny, zamiast się przed nim chować. ## Ważność, na Którą Trzeba Zasłużyć Większość produktów wpisuje ważność obok reguły i każde trafienie dziedziczy ją na zawsze - tak „krytyczne" staje się tapetą. Tutaj wpisana ważność detektora jest celowo skromna - z **jednym celowym wyjątkiem, prompt injection**, żaden wbudowany detektor nie stempluje poziomu krytycznego - i jest tylko *punktem wyjścia*. To, co widzisz na epizodzie, to jego **ważność efektywna**, liczona na żywo: - **Statystycznie skrajny wynik ją podnosi.** O jeden poziom, gdy wynik przekracza 6.0, o dwa przy 7.5 - szczyt skali, którego większość epizodów nigdy nie sięga. Detektor średniej ważności, którego epizod ma wynik 7.6, czyta się jako krytyczny, bo dowodem jest *ta liczba*, a nie etykieta, którą ktoś kiedyś wpisał. - **Korelacja ją podnosi.** O jeden poziom, gdy inny detektor trzyma silny otwarty epizod dla tej samej encji, o dwa, gdy robią to dwa lub więcej. Pracowity dzień i przejęcie konta wyglądają tak samo na jednej metryce i zupełnie inaczej na trzech - więc skok pobrań zbieżny z logowaniem wysokiego ryzyka czyta się jako krytyczny, podczas gdy ten sam skok w pojedynkę jako średni. - **Detektory zdarzeniowe czytają się dokładnie tak, jak twierdzą.** Ich epizody niosą wynik-znacznik, nie pomiar, więc nigdy nie eskalują po wyniku: logowanie wysokiego ryzyka jest *wysokie* samo w sobie, a staje się *krytyczne* w chwili, gdy potwierdzi je drugi detektor. Prompt injection to celowy wyjątek - oflagowana manipulacja sesją AI nie ma niewinnego odczytania, więc jest krytyczna sama w sobie, bez drugiego sygnału. - **Twoje nadpisania i werdykty wygrywają.** Domyślna ważność per detektor (ustawiana w widoku Domyślne kolejki), nadpisanie alertowania zakresowane na jedną encję lub kohortę, albo ręczny werdykt per epizod - ostateczne słowo analityka - każde z nich zastępuje wartość obliczoną, a wiersz mówi, która ścieżka dała to, co widzisz. Efekt to kolejka, w której **krytyczne coś znaczy**: statystycznie nadzwyczajne, potwierdzone przez niezależne detektory albo przez człowieka - nigdy „znów odpalił detektor, który ktoś kiedyś nazwał krytycznym". Tę samą ważność efektywną zwraca REST API i narzędzia MCP w polu `severity`, z surowym stemplem obok jako `baseSeverity` i pochodzeniem jako `severitySource` - SIEM kluczujący po ważności widzi dokładnie to, co Twoi analitycy. ## Korelacja - Kolejka Czyta Się Jak Lista Obserwacyjna Każdy epizod niesie dwie liczby korelacji: ile **innych detektorów** trzyma w tej chwili otwarty epizod dla tej samej encji oraz **skumulowane ryzyko** encji - sumę wyników jej otwartych epizodów. Domyślny porządek kolejki stawia encje skorelowane na górze: konto oflagowane naraz przez trzy detektory wyprzedza każdy pojedynczy wyższy wynik, bo to jest wiersz, który analityk powinien otworzyć pierwszy. Te same liczby jadą w API (`details.concurrentEpisodes`, `details.riskSum`), więc zewnętrzne narzędzia mogą rangować tak samo. Korelacja bramkuje też najhałaśliwszą pocztę. Jednometryczne detektory wolumenu - pobrania, udostępnienia, liczba logowań, użycie AI - powiadamiają tylko wtedy, gdy drugi detektor potwierdza encję; same ich epizody zostają w kolejce, a wstrzymane powiadomienie jest logowane z powodem. Detektory o kształcie decyzji (usunięcia, nadania uprawnień, zestaw zdarzeniowy) powiadamiają samodzielnie. ## Od Linii do Skrzynki Odbiorczej - Efektywna Ważność i Nadpisania Przekroczenie linii otwiera epizod; o tym, czy ktoś zostanie *poinformowany* i jak głośno, decydują trzy warstwy - a każda z nich jest widoczna na [ekranie Alertowania](/pl/docs/screens/alerting): - **Reguła anomalii tenanta** - kanał natychmiastowy włączony lub wyłączony, powiadamianie tylko o alertowanych albo także o info, które kształty się liczą (skok, spadek, cisza), odbiorcy, okno schłodzenia, rytm podsumowania. - **Nadpisania** - częściowa reguła dla jednego detektora albo dla jednego użytkownika, aplikacji, agenta AI, urządzenia, witryny lub grupy. Obniż linię dla odchodzącego pracownika na 30 dni, wycisz hałaśliwe konto serwisowe na tydzień, pozwól jednemu detektorowi powiadamiać na poziomie info - każde z powodem i datą wygaśnięcia. Nadpisania stosowane są w chwili oceniania epizodu, w chwili odczytu kolejki i w chwili decyzji o mailu, więc ten ekran i skrzynka odbiorcza nigdy się nie rozjeżdżają. - **Efektywna ważność** - liczba w temacie maila to ta sama obliczana ważność, którą pokazuje kolejka (z eskalacją po wyniku, korelacją, nadpisaniami i werdyktami - patrz wyżej), dodatkowo podniesiona o to, co 1Security już wie o podmiocie: konto uprzywilejowane, tożsamość gościa, zasięg do plików z informacjami wrażliwymi, linki anonimowe, brak MFA; dla aplikacji i agentów - dostęp do plików w całym tenancie, zgoda administratora dla wszystkich użytkowników, niezweryfikowany wydawca, bardzo szeroki zasięg. Toksyczna kombinacja, jak uprzywilejowanie *i* zasięg wrażliwy, podnosi o dwa poziomy, a epizod na poziomie info nigdy nie wysyła maila wyżej niż *niska*. Powody są drukowane w mailu i zapisywane w dzienniku powiadomień - mail może czytać się wyżej niż kolejka, nigdy niżej. Każda decyzja - wysłano, wstrzymano z podaniem powodu albo nieudane - trafia do dziennika powiadomień, więc na *„dlaczego nie dostaliśmy o tym maila"* odpowiada zakładka Wysłane, a nie zgłoszenie do supportu. ## Jedno Pokrętło, Każda Branża - i Zero Okresu Strojenia Wykrywanie anomalii dostajesz zwykle jako czarną skrzynkę. Próg wybrał ktoś inny, nie widzisz go i nie możesz go ruszyć, a wszystko, co pod niego nie podpadnie, jest wyrzucane, a nie zapisywane - więc krytyczna anomalia potrafi przejść bez śladu, że kiedykolwiek istniała. Zostajesz z jednym z dwóch scenariuszy: albo system alarmuje tak często, że zespół przestaje to czytać, albo milczy - i nie masz jak sprawdzić, o czym postanowił Ci nie powiedzieć. Z zewnątrz te dwie porażki są nie do odróżnienia: ekran, na którym nic nie ma. Strojenie też nie jest bezpieczne, bo nowy próg działa dopiero od jutra: jego zmiana to zakład o kolejny kwartał, więc w większości narzędzi nikt go nigdy nie rusza. 1Security rozdziela tę jedną ukrytą decyzję na dwie. **Co jest nietypowe** jest mierzone i zawsze zapisywane, aż do 2 sigma, niezależnie od tego, czy przekracza Twoją poprzeczkę. **Co zasługuje na alert** to linia, którą przesuwasz. Pełna widoczność z jednej strony, kolejka, którą da się realnie czytać, z drugiej - i nic wyrzuconego pomiędzy. Kontrolka **Czułość alertów** stoi otwarcie na górze tego ekranu, a nie schowana w ustawieniach, bo to ustawienie, którego inne narzędzia nigdy nie oddają w Twoje ręce. Przesuń ją, a klasyfikacja przelicza się **w momencie odczytu, względem Twojej prawdziwej historii**: puść suwak, a liczniki Alertowanych i Info obok niego odpowiadają na nowo od razu, razem z przeładowanymi kolejkami. Ma to konsekwencję, którą warto nazwać wprost. Strojenie detekcji zwykle kosztuje kwartał: wybierasz próg, uruchamiasz go w trybie cichym, czekasz, co złapie i czym Cię zaleje, i poprawiasz. Tutaj czekanie znika, bo historia jest już oceniona - obniżenie linii nie zaczyna zbierać inaczej, tylko **przelicza na nowo to, co już zostało złapane**. - **Bank, szpital albo kancelaria** ściąga linię w dół, ku 2.0. Wszystko, co detektor kiedykolwiek uznał za godne uwagi, staje się Alertowane - wstecznie - a audytowe pytanie _„czy byśmy to zobaczyli?"_ rozstrzyga się przez sprawdzenie, nie przez nadzieję. - **Agencja marketingowa albo 30-osobowy startup** przesuwa ją ku swobodnemu końcowi. Kolejka kurczy się do garstki epizodów wartych uwagi człowieka, a nic nie znika: wszystko poniżej linii nadal siedzi w Info na dzień, w którym stanie się istotne. - **Oba przypadki to ten sam tenant, te same dane i ten sam detektor.** Organizacja regulowana i ta swobodna nie używają różnych produktów - używają tego samego, z pokrętłem w innym miejscu. Śledztwo, które to otwiera: *„chyba coś nam umknęło w zeszłym tygodniu"*. Obniż linię, przefiltruj po tym tygodniu i zobacz, co już zostało zapisane poniżej Twojego dawnego progu. Potem podnieś ją z powrotem - przesuwanie pokrętła nigdy nie niszczy danych, w żadną stronę. ## Epizody, Nie Zdarzenia Anomalia to **epizod**: otwiera się, gdy licznik przełamuje linię, śledzi swój szczyt, dopóki skok trwa, i zapisuje moment powrotu metryki do normy. Zakończenie to fakt o metryce, nie werdykt o incydencie - epizod, którego skok się skończył, nadal siedzi w kolejce Otwartych, dopóki człowiek nie wyda werdyktu. **Potwierdź** znaczy „widziane, zajmujemy się tym” - epizod zostaje widoczny, ale nie liczy się jako nowy. **Napraw** zamyka sprawę PRAWDZIWEGO incydentu - potwierdzonego i obsłużonego, akcją reagowania albo poza 1Security - i zostaje w rejestrze jako zapis incydentu; jeśli zachowanie się powtórzy, to nowy epizod, nie wznowienie starego. **Odrzuć** znaczy „nieszkodliwe” - oczekiwane zachowanie albo fałszywy alarm - i epizod przestaje liczyć się jako sygnał potwierdzający inne detekcje tej encji. **Śledź** odsyła epizod z powrotem do cichego rejestru - stanu domyślnego, w jakim anomalie przychodzą - bez udawania, że zapadł werdykt. Jedno powiadomienie na epizod, nie na dzień. Każdy wiersz zaczyna się od **detektora, który zadziałał**, a pod nim stoi dotknięty byt - konkretny użytkownik, aplikacja albo agent AI dla anomalii per byt, typ zasobu dla anomalii całej polityki. Reszta wiersza niesie istotność, 30-dniowy wykres metryki, sam skok (linia bazowa → obecnie i skok procentowy), wynik oraz czas ostatniej detekcji i zakończenia. Przejdź do trendu stojącego za detektorem albo do szuflady szczegółów samego bytu. ## Filtrowanie w Głębi Zawsze widoczne kontrolki tną kolejkę po poziomie (**Alertowane / Info**) i stanie obsługi (**Otwarte / Potwierdzone / Naprawione / Odrzucone / Śledzone**); szuflada filtrów zawęża dalej po **istotności**, **statusie**, **typie zasobu** - pliki, witryny, grupy, użytkownicy, poczta, aplikacje i agenci AI - oraz **zakresie dat detekcji**. Każda opcja niesie żywy licznik dla aktualnie oglądanego poziomu, więc widzisz, ile kryje się za danym cięciem, zanim je wykonasz. Wzorzec śledczy wart zapamiętania: po każdym incydencie gdziekolwiek w tenancie przełącz się na **Info**, przefiltruj po typie zasobu i zakresie dat incydentu - słabe sygnały zapisane w tym czasie to najtańszy materiał dowodowy, jaki posiadasz. Jeśli zasługują na awans, obniż linię alertu, a staną się Alertowane, razem z całą historią.