Warden - withdrawn a resolved stavy hlášení?¶
Proč nezahrnovat do systému Warden stavy jednotlivých hlášení - konkrétně 'resolved' a 'withdrawn'?
Příklad 1¶
- V ORG1 je kompromitovaný webmailový účet, z něhož se šíří phishing.
- ORG2 detekuje tento phishing a nahlásíi na Warden server.
- ORG1 vyřeší problém.
Jak realizovat withdrawal/resolution?
- ORG1 'stáhne' hlášení (změní na 'resolved') z Wardenu, přestože toto hlášení formálně patří ORG2. Zde ale nastává problém s důvěryhodností ORG2, jelikož ona je vedena jako ohlašovatel problému, nicméně o zásahu do stavu hlášení nemá tušení nebo nemá, jak tomu zabránit. Bylo by možné rozšířit databázi i o atributy 'resolved by' či 'withdrawn by', což jde ale proti jednoduchosti a efektivitě uvedené v samotné specifikaci (nároky na klienta: co dělat s 'vyřešenými' incidenty? nároky na server: jak korelovat mezi 'resolved' a 'not-resolved' incidenty?).
- ORG1 informuje ORG2, že problém je vyřešen a že může hlášení zrušit (resolve). Zde je ale opět problém s jednoduchostí: je třeba postranní kanál nebo rozšířit funkcionalitu Wardenu i o komunikační rozhraní, což je opět v rozporu se specifikací. V podstatě už bychom tvořili distribuovaný RT. Navíc je problém s důvěryhodností hlášení. Opět za incident formálně zodpovídá ORG2, která ale nemá jak ověřit, jestli ORG1 skutečně problém vyřešila. Ohrožen je ale predevším kredit ORG2.
PH: Můj názor: V případě vyřešení pešek. Zneplatnit či označit událost za
vyřešenou by měl mít možnost jen ten, kdo ji detekoval. Nemá-li (a nemá
možnost získat věrohodnou) informaci o vyřešení, nebude o něm posílat
informaci. ORG1 (napadená, řešící) musí případné konsekvence řešit běžnými
kanály mimo Warden.
Pro událost zneplatnění scénář těžko nastane - jedná se o chyby na straně
detekujícího, tj. zneplatnění přímo posílá původce události = autorita.
Příklad 2¶
- V ORG1 je kompromitovaný webmailový účet, z něhož se šíří phishing.
- ORG1 detekuje (a opraví) problém jako první, umístí hlášení do Wardenu a označí jako 'resolved'.
- ORG2 detekuje phishing později.
Co má ORG2 v dané situaci dělat?
- ORG2 hlášení na Warden nepošle, protože ORG1 již totožný problém označila jako vyřešený. Vyvstává opět problém důvěryhodností. ORG2 detekovala hrozbu a pouze na základě tvrzení ORG1 by neměla problém hlásit. Jinými slovy rozhodnutí ORG1 ovlivňuje důvěryhodnost ORG2. Navíc nastává problém timeoutu onoho 'resolved' nebo 'withdrawn' stavu. Detekuje-li ORG2 hrozbu měsíc po updatu stavu ORG1 na 'resolved', jedná se o týž incident detekovaný se zpožděním, nebo jde již o novou hrozbu?
- ORG2 hlášení na Warden pošle (aby predešla problémům z bodu 1). Nastává ale problém na straně serveru: co s dvěma totožnými incidenty, z nichž jeden je vyřešen a druhý aktivní?
PH: Můj názor: V případě vyřešení opět pešek. Obecně, události jsou (zatím)
nekorelované, detekuje-li tedy více zdrojů událost na jedné IP, stejně se
jedná o jednotlivé samostatné události. Aby IP byla z pohledu odběratelů
čistá, tyto samostatné události musí být tedy označeny detektory jako
vyřešené všechny. Pokud na IP zbývá alespoň jedna nevyřešená událost, IP
stejně v blacklistech zůstane.
Pro událost zneplatnění scénář těžko nastane.
Shrnutí¶
Stavy 'withdrawn' a 'resolved' je vhodnejší do systému Warden nezahrnovat. Jejich implementace by vyžadovala tvorbu výrazně komplexnějšího systému, naproti tomu reálně očekávatelný efekt by byl minimální. Každý příjemce služby Warden si nastaví vlastní politku, jak k externím hlášením přistupovat (např. jestli a jak dlouho blokovat, ...).
RO: Výše uvedený argument, že každý příjemce služby Warden si nastaví vlastní politku, jak k externím hlášením přistupovat (např. jestli a jak dlouho blokovat, ...) je samořejmě správný. Důvod pro zařazení TIMEOUTu by mohl být ten, že především zadavatel hlášení má nejvíce informací o dané události a proto je pro něho snažší stanovit nejen mandatorní ZÁVAŽNOST, ale i dobu, po jakou bude událost aktuální/aktivní/platná - TIMEOUT. Konzument události se nemusí rozhodnovat o době platnosti události, protože může jednoduše převzít navrhovanou dobu platnosti přímo z hlášení. Stejně tak tomu je i v případě závažnosti. Položku TIMEOUT bych do jednotlivých hlášení přidal. Při brainstormingu byl návrh označení položky za nemandatorní, takže bude na uvážení zadavatelů a konzumentů, zda položku zadají/využijí. Pokud by byla položka TIMEOUT mandatorní, byla by pak na straně konzumenta událostí znažší implementace automatizovaných akcí - položka XZY ve vygenerovaném seznamu bude platná do RRRR-MM-DD, protože tvůrci nového hlášení důvěřujeme a není třeba o době platnosti pochybovat. V případě používání blacklistů se dělá to samé - spoléhá se na dobu platnosti záznamu, kterou stanoví provozovatel.
PH: Diskuse odvolávacích stavů¶
Premisy: Warden šíří události, jejich interpretace je na odběratelích. Z
větší části to ale zatím vypadá, že informace budou v cílových sítích
použity na tvorbu blacklistů - událost spouští proces s nedefinovaným časem
ukončení.
Příjemci mohou na zprávy reflektovat, nemusí. Stejně jako ostatní zprávy,
rozesílané Wardenem příjemcům, jsou tyto jen informativní a příjemci na
základě nich mohou podnikat akce podle svého uvážení.
Zneplatnění (Withdrawal)¶
Motivací je možnost opravy chybně odeslaného záznamu. Předpoklad je, že
půjde o výjimečnou událost.
Příklad: díky špatné konfiguraci senzoru se mezi spamující IP dostane i
hlavní mailserver organizace a promptně bude protlačen přes Warden
odběratelům. Na řadě míst začne SpamAssassin větší část pošty z postiženého
stroje směrovat uživatelům do spamové složky. Odesílatel chybné zprávy neví,
jak se příjemci zachovali a kde všude nastává problém. Zneplatňující zpráva
dává možnost informovat stejné (a všechny) odběratele, kteří dostali původní
zprávu, a ti mohou chybný záznam vyřadit.
Vyřešení (Resolution)¶
Motivací je možnost označení záznamu jako neaktuálního po vyřešení problému
u kritických služeb. Opět je předpoklad, že jde o výjimečnou událost.
Příklad: díky krátkodobé špatné konfiguraci opět hlavního poštovního serveru
se tento dostane mezi spamující IP. Důsledky stejné jako předchozí. Proč
nepoužít také zneplatnění? Jedná se o jinou akci - není to chyba,
neplatnost, překlep, ale skutečná náprava. Příjemci se tedy mohou rozhodnout
chovat jinak - například IP z blacklistů nevyřadit, ale snížit timeout, nebo
stroj přesunout z blacklistu na greylist.
Timeout +0 (zrušení pomocí nulování doby platnosti)¶
Timeout +0 znamená efektivně zneplatnění zprávy, tj. může suplovat
zneplatnění/vyřešení. Ovšem jen v případě, že dovolíme opakované posílání
zprávy se změnou parametrů (což je k diskusi). To je komplikace, která se
promítne do složitosti klientů. S možností změny klienti potřebují udržovat
zpětně čitelnou databázi přijatých/aktivních zpráv a mít možnost řízený
backend (blacklist) modifikovat.
Speciální události mohou (nemusí!) u příjemců dopadnout tak, že se nebudou zpracovávat
automaticky, ale správce si je přesměruje na místo, které prochází lidskou
revizí. To je v případě jasně odděleného typu zpráv jednoduché. V případě
timeoutu +0 je třeba konzultovat databázi uložených zpráv.
"Přetěžování" jednoho pole znamená také ztrátu informace pro příjemce -
zneplatnění je něco, co je potřeba vykonat hned, jedná se o nápravu chyby
detekce, zatímco informace o vyřešení je záhodno brát s rezervou.
Shrnutí¶
Osobně za nejdůležitější považuji informaci o chybě a možnost její opravy
(zneplatnění). Vyřešení je jenom rozšíření - pokud možnost zneplatnění bude,
dříve nebo později ji někdo využije i jako vyřešení ("my potřebujeme, aby ta
pošta došla, no"), a je lepší dát k dispozici takovou možnost přímo.
Timeout +0 je trochu hack, přetěžování, který potřebuje podporu na straně
klientů, párování událostí a možnost opakovaného posílání zpráv se změnou
parametrů.
Alternativa¶
Konvenční list, kam budou zařazeny kontaktní údaje zodpovědných osob v
generujících i přijímajících organizacích, a kteří budou schopni na ně
reagovat lidským vstupem. Vzhledem k tomu, že půjde o výjimečné události,
opožděná doba reakce vzhledem k lidskému vstupu nemusí být kritická.
Nevýhoda listu - delší doba reakce, špatná udržovatelnost. V případě
CESNETí sítě s funkčními abuse@ kontakty by nemusel být problém.
Závěr¶