Jak AllowGate podejmuje decyzje

Section 2

Dwuetapowa ocena

Ocena przebiega w dwóch odrębnych fazach. Rozdzielenie ich pozwala jednocześnie zachować elastyczność (na poziomie usługi, tenanta i tagów) oraz zapewnić możliwość audytu (jedna efektywna polityka dla każdego CVE, ze stałymi regułami pierwszeństwa).

Faza 1 to ustalenie obowiązującej polityki. Zbierane są wszystkie reguły, których zakres odpowiada danej usłudze, środowisku, projektowi i tagom. Następnie są one walidowane i łączone w jedną efektywną politykę. Reguły nie są hierarchiczne. Reguła obowiązuje tylko wtedy, gdy wszystkie zadeklarowane przez nią pola zakresu pasują do ocenianego obiektu. Nic nie jest niejawnie dziedziczone.

Faza 2 to ocena CVE. Surowy wynik CVSS jest korygowany na podstawie kontekstu zarejestrowanego podczas skanowania (ekspozycja, osiągalność, uprawnienia środowiska uruchomieniowego, zastosowane mechanizmy ograniczające ryzyko, sygnały czasowe). W rezultacie powstaje skorygowany poziom istotności. Następnie jest on oceniany względem efektywnej polityki wyznaczonej w Fazie 1, przy użyciu stałego łańcucha priorytetów. Wynikiem jest jedna z decyzji: allow (zezwól), deny (odrzuć), undetermined (nierozstrzygnięte) lub filtered (odfiltrowanie - gdy zaufana deklaracja VEX mówi, że CVE nie dotyczy tego artefaktu).

To rozdzielenie ma kluczowe znaczenie. Faza 1 obejmuje wyłącznie logikę polityk i nie zależy od żadnego konkretnego CVE. Faza 2 jest jedynym miejscem, w którym sygnały kontekstowe wpływają na ostateczną decyzję.

Section 4

Ryzyko uwzględniające pewność sygnałów

Każdy sygnał kontekstowy niesie poziom pewności. Automatycznie wyprowadzony tag ekspozycji z manifestu runtime ma wysoką pewność. Heurystyka statyczna ze skanu manifestu w czasie buildu - średnią. Ręczna deklaracja operatora - niską. Pewność wynika ze źródła sygnału, nie z deklaracji autora reguły.

Modyfikatory dzielą się na dwie klasy. Twarde modyfikatory (ekspozycja, osiągalność oparta na dowodach, ograniczenie ryzyka przez sandbox, kontekst użycia oraz dane wywiadowcze dotyczące exploitów przekraczające próg danego poziomu) bezpośrednio wpływają na skorygowany poziom ważności (severity). Miękkie modyfikatory (dostępność PoC, ochrona przez WAF, wiek podatności, heurystyki rezydualne) wnoszą wkład podlegający ograniczeniu. Limit narzuca wybrany tier tenanta, a nie pojedyncze reguły.

stotne są tutaj dwa mechanizmy ochronne. Po pierwsze, miękkie modyfikatory nigdy nie mogą obniżyć skorygowanej oceny istotności poniżej minimalnego progu przypisanego do jej pierwotnej klasy; jedynym sposobem na dopuszczenie CVE o istotności przekraczającej ten próg jest jawne nadpisanie w postaci reguły deny override. Po drugie, jeśli którykolwiek z sygnałów składowych miał niską pewność, a jego usunięcie odwróciłoby decyzję, silnik emituje undetermined zamiast po cichu przepuszczać. Wtedy o dalszym postępowaniu decyduje polityka środowiska.

Ten sam mechanizm progu rozszerza się na systemy technologii operacyjnej (OT). Zasób sterujący procesem fizycznym może posiadać atestowaną klasyfikację safety-consequence w zakresie od low do safety_critical. Podnosi ona próg niezależnie od progu IT danego tieru; obowiązującym progiem jest większa z tych dwóch wartości. Jeśli klasyfikacja ma niską pewność, kieruje decyzję do stanu undetermined, zamiast zastosowania zaniżonego progu. Dla działającego zasobu safety-critical odbiorcy decyzji nie mogą interpretować deny jako polecenia zatrzymania, odłączenia ani innego przerwania sterowanego procesu; eskalacja musi odbywać się poza tym mechanizmem. Zasoby IT nie niosą klasyfikacji i zachowują się jak dotychczas.

W praktyce oznacza to, że sygnał o niskiej pewności nigdy nie może niepostrzeżenie zmienić decyzji z deny na allow. Albo nie wpłynie na wynik, albo wymusi jawne podjęcie decyzji.

Section 6

Wynik: łańcuch uzasadnienia

Każdej decyzji towarzyszy łańcuch uzasadnienia. To nie jest wpis w logu. To ustrukturyzowany zapis, który wskazuje nadrzędną regułę decyzyjną, reguły pasujące, lecz nadpisane, poziom ryzyka przed i po jego korekcie, wersje polityk i ustawień tenanta, które doprowadziły do podjęcia decyzji, snapshoty źródeł danych CVE oraz katalogu KEV obowiązujących w danym momencie, sygnaturę kontekstu oraz listę rekomendowanych dalszych działań.

To właśnie taki materiał dowodowy jest najczęściej wymagany przez audytorów. SOC 2 CC7.1 wymaga udokumentowanych procedur wykrywania i oceny podatności. ISO 27001 A.8.8 wymaga możliwego do prześledzenia procesu zarządzania podatnościami technicznymi. PCI DSS 6.3 wymaga klasyfikacji wykrytych podatności oraz dokumentowania zastosowanych działań naprawczych. DORA RTS w zakresie zarządzania ryzykiem ICT wymaga, aby decyzje związane z ryzykiem były możliwe do jednoznacznej identyfikacji i śledzenia. Łańcuch uzasadnienia spełnia wszystkie te wymagania, eliminując potrzebę utrzymywania oddzielnego procesu gromadzenia materiału dowodowego.

{
  "decision": "deny",
  "decision_confidence": "high",
  "winning_rule": {
    "type": "scoped_deny",
    "scope": { "service": "payments-api" }
  },
  "matched_rules": [
    { "type": "threshold", "scope": { "service": "payments-api" }, "value": 5.0 },
    { "type": "threshold_override", "scope": { "service": "payments-api" } },
    { "type": "scoped_deny", "scope": { "service": "payments-api" } }
  ],
  "overridden_rules": [],
  "justification": [
    "severity: raw=9.8, sum_hard=0, sum_soft=0, adjusted=9.8",
    "floor: floor=7 not applied (pre_floor=9.8)",
    "step3: scoped_deny matched -> deny"
  ],
  "next_actions": [
    "exception_invalid_ack_level: required=executive, actual=security"
  ]
}

Section 8

Dostarczane jako SaaS w modelu multi-tenant

AllowGate to usługa hostowana. Silnik, pakiet reguł systemowych i definicje tierów są utrzymywane i nadzorowane przez nas; Twój zespół jest tenantem korzystającym z platformy.

Reguły funkcjonują na dwóch warstwach. Warstwa platformowa (reguły systemowe, globalne hard deny oraz definicje tierów) leży po stronie AllowGate i z założenia obowiązuje wszystkich tenantów. Warstwa tenanta (Twoje bazowe progi, scoped deny, wyjątki oraz wybór tieru) jest własnością Twojego zespołu, a każda reguła jest oznaczona identyfikatorem tenanta. Silnik wymusza izolację zapisów na poziomie polityk: żaden tenant nie może utworzyć reguły działającej dla innego, żaden nie może utworzyć globalnego hard deny, a także nie może zmienić klasyfikacji modyfikatora w celu obejścia miękkiego limitu przypisanego do jego tieru.

Tiery są zestawami parametrów opracowanymi i zarządzanymi przez AllowGate. Obejmują maksymalny limit progowy, limit miękkich modyfikatorów, wagi pewności oraz minimalny poziom istotności. Wybierasz tier, ale go nie definiujesz. Dzięki temu regulowany tier pozostaje rzeczywiście regulowany, a każda aktualizacja platformy (np. nowa reguła systemowa lub zaostrzenie limitów) może zostać wdrożona jednocześnie dla wszystkich tenantów, bez konieczności samodzielnego przepisywania polityk przez każdy zespół.