Hol tűnik el egy VPN-felhasználónév a naplófolyamatból?

A munkamenetek megjelennek az irányítópulton, miközben a felhasználónév oszlop üresen marad, és az első ösztön az, hogy az elemzőt hibáztassuk. Ez az ösztön kihagy három korábbi szakaszt, ahol az érték elveszhetett. Az átjáró szabályzat alapján elrejtheti az identitást, egy betöltési szabály törölheti az indexelés előtt, és egy kereséskori kinyerés egyszerűen elmulaszthatja megnevezni. A javítás attól függ, melyik határt tudja bizonyítottan felelősnek, ezért a hasznos munka az összehasonlítás, nem a konfigurálás.

Egyetlen eseményből induljon ki, ne az irányítópultból

Válasszon egyetlen hitelesítési eseményt, és írja le, mi azonosítja: az átjáró modellje és kiadása, a hitelesítési módszer, az eseményazonosító, az időbélyeg és a forráscím. Adja hozzá a felhasználónevet pontosan úgy, ahogy a személy beírta, kis- és nagybetűkkel együtt, mert egy kis- és nagybetűre érzékeny keresés elrejthet egy létező mezőt. Tekintse ezt az eseményt referenciának minden későbbi összehasonlításhoz.

Az eseménytípusok nem osztoznak egyetlen sémán. Egy sikertelen kísérlet, egy ügyfél nélküli sikeres bejelentkezés és egy alagút-újracsatlakozás különböző mezőket eredményezhet, és néhány átjáró elhagyja az identitást, ha a kísérlet soha nem érte el a felhasználói hitelesítést. Ezért egy üres oszlop egy eseménytípuson gyenge bizonyíték a folyamat hibájára.

Jóváhagyott tesztidentitással dolgozzon valódi munkatársi fiók helyett, és tartsa az összehasonlítást a naplóadatokat már szabályozó hozzáférési szabályokon belül. A részletes hitelesítési naplózás széles körű bekapcsolása csak egy minta kedvéért megváltoztatja a mérni kívánt rendszert.

Hasonlítsa össze a négy határt sorrendben

Az érték négy pont egyikén tűnhet el. Minden pontnak más a gazdája és más a javítása.

Álljon meg az első határnál, ahol az érték eltűnik. Az eszköz nézete és a nyers másolat közötti eltérés szállításra vagy gyűjtőkonfigurációra utal; ott egyezés, de az indexelt eseményből hiányzó érték átalakításra utal; az indexelt eseményben meglévő, de az irányítópultról hiányzó érték kinyerésre vagy a lekérdezésre utal.

Ez a sorrend azért számít, mert minden későbbi szakasz csak veszíthet információt, soha nem állíthatja vissza. Egy reguláris kifejezés nem tud visszahozni egy karakterláncot, amelyet egy korábbi szakasz helyőrzővel helyettesített, és egy adatvédelmi beállítás nem magyarázhat meg egy soha el nem küldött értéket.

A forrásnál való elrejtés szabályzat, nem elemzőhiba

A Cisco ASA-naplózási dokumentációja a felhasználónév elrejtését konfigurálható viselkedésként írja le, beleértve azt is, hogyan jelennek meg az érvénytelen vagy ismeretlen felhasználónevek. A forráseseményben elrejtett identitás tehát pontosan az lehet, amit az adatvédelmi szabályzat megkövetel, és elemzési hibaként kezelése olyan kéréshez vezet, amely gyengíti a vezérlőt.

A pontos megjelenítés a kiadástól és az üzenettípustól függ. Az egyik esemény helyőrzőt hordozhat, a másik teljesen elhagyhatja a mezőt, és egy hitelesítési hiba soha nem tartalmazhat nevet. Ellenőrizze az adott esemény dokumentált viselkedését, ahelyett hogy egy régi hibajelentést alkalmazna minden hiányzó identitásra.

Amikor az elrejtés szándékos, a kérdés arról, hogyan állítható vissza a mező, átvált arra, hogy az auditkövetelmény más módon teljesíthető-e. A munkamenet-azonosítók, egy kisebb csoport által kezelt ellenőrzött identitástérkép, vagy egy szűkebb engedélyezett eseményfolyam gyakran kielégítik az igényt anélkül, hogy minden kipróbált felhasználónevet minden naplóolvasó elé tennének.

Az indexelés előtti anonimizálás nem vonható vissza

A Splunk eseményfeldolgozási dokumentációja az anonimizálást sed-kifejezésekkel és olyan átalakításokkal írja le, amelyek az adatokat az indexelés előtt átírják vagy eltávolítják. Pontosan ez a hely a lényeg: a nyers esemény a beérkezéskor megváltozik, így a kereséskori kinyerésnek nem marad mit megtalálnia.

Az indexeléskori szerkesztés és a kereséskori mezőkinyerés különböző problémákat old meg. A szerkesztés korlátozza, ki láthatja egyáltalán az értéket; a kinyerés csak arról dönt, melyik nevet használja a lekérdezés. A hashelés köztes lehetőség, amely megőrzi a korrelációt, de egy kis felhasználónévtér feletti stabil hash még mindig azonosít, ha valaki jelöltneveket tud rajta tesztelni.

Ha a tárolt esemény még tartalmazza az identitást, a probléma lejjebb van: forrástípus, sörtörés, elválasztókezelés, mezőaliasok vagy maga a lekérdezés. Ezek hétköznapi elemzési javítások, és nem érintik az adatvédelmi határt.

Válassza a határhoz illő javítást

Három feltétel dönt a válaszról. Először, szándékozik-e az adatvédelmi szabályzat kizárni az identitást? Másodszor, az audit- vagy vizsgálati folyamatnak az identitásra, egy álnévre vagy csak a munkamenetre van szüksége? Harmadszor, melyik határon kell az érték — gyűjtés, tárolás vagy megjelenítés?

Ha a szabályzat kizárást szándékozik, a követelményt vagy a megjelenítést változtassa meg, ne a vezérlőt. Ha a szabályzat engedi az identitást, de a gyűjtés eldobja, javítsa a gyűjtőt és igazolja a nyers eseményt. Ha a tárolás ép, javítsa a kinyerést, és tesztelje a kezdetben rögzített jóváhagyott esemény ellen.

Zárja le a vizsgálatot a határ megnevezésével a változási rekordban: a forrásnál elrejtve, a betöltés során eltávolítva, vagy a kinyerés által kihagyva. Ez az egy mondat megmondja a következő mérnöknek, hol nézzen először, és megakadályozza, hogy egy irányítópult-panasz csendesen letiltott adatvédelmi funkcióvá váljon.