Firefighter AI vs ember: 6:0

Lefújták a hat hónapnyi SAP Firefighter tevékenységet egy valós éles környezetben. Team Human Review: 0. Team AI Agent: 6. A Team AI nem azért nyert, mert gyorsabb volt, mint az emberi oldal. Azért nyert, mert ugyanazon a pályán más játékot játszott.

Ez a cikksorozat végigvezeti az olvasót azon, mi volt ez a hat „gól", hogyan szerezte meg a Team AI, és miért tükrözi az eredmény inkább a folyamat és a megközelítés hibáját, mintsem emberi tévedést.

A sorozatban leírt mérkőzés során az AI ügynökök által szerzett hat „gól":

• 1. gól. Az FF végrehajtó és az auditor viszonya (peer review audit)
• 2. gól. Az FF-tevékenység forrása (technikai fiókok vészhozzáférési címke alatt)
• 3. gól. GDPR-kitettség FF-munkamenet közben (technikai mező)
• 4. gól. Hiányzó adat jóváhagyott FF-munkamenetben (jóváhagyási ítélet)
• 5. gól. Az FF vészhelyzeti fiók tömeges változtatásokra használva
• 6. gól. Az FF-munkamenet felülvizsgálatának minősége (hiányzó kritikus tranzakcióhasználat)

Ez a cikk sorra veszi a hat „gólt", majd a mérkőzés utáni elemzés következik: hogyan épült fel a Team AI, milyen hatrétegű architektúra áll mögötte, milyen validációs fegyelem támogatja, és milyen egyhetes lépéseket tehet a Team Human, hogy hétfőtől ugyanazon a pályán versenyezhessen.

Filip Nowak, GRC Advisory. A háromrészes sorozatban leírt hat jelet egy GRC AI ügynök állította elő a smartGRC LAB-ban egy valós, éles SAP S/4HANA Firefighter telepítés anonimizált kivonatán. A módszertan, a heurisztikák és a szerkesztői felelősség a GRC Advisory tanácsadói csapatánál marad.

Mi ez a sorozat, és mi nem

Ez egy adatmintázat-tanulmány, olvashatóság érdekében három részre bontva. Egy anonimizált, éles méretű SAP Firefighter tevékenységi adatkészletet elemez, és hat kontrolljel-osztályt ír le, amelyek akkor láthatók, ha az adatokat munkamenetek között vizsgáljuk, nem pedig egyszerre egy FF-tevékenységet (ez a hagyományos megközelítés). Ez nem nyilvános auditjelentés. Nem egy konkrét szervezet gyengeségeinek leírása. Nem állítja, hogy az AI helyettesíti az emberi auditorokat.

Amit viszont állít: hogy a klasszikus, munkamenetenkénti Firefighter-felülvizsgálatot nem arra tervezték, hogy munkameneteken, felhasználókon és forrásokon átívelő mintázatokat tárjon fel; hogy ezek a mintázatok normál méretű éles adatokban kvantifikálhatók; és hogy egy megfelelő architektúrával felszerelt GRC AI ügynök elég megbízhatóan tudja kinyerni ezeket a mintázatokat ahhoz, hogy az emberi auditorok validálni és cselekedni tudjanak. Minden jelet ellenőrzött az alapjául szolgáló adatokon egy elszámoltatható GRC biztonsági tanácsadó, mielőtt megjelent volna ebben a sorozatban.

Az ügynök mintázatokat észlel. Az ember dönti el, hogy a mintázat audit szempontjából releváns-e.

A mérkőzés

Két módja van egy Firefighter-munkamenet értelmezésének. A munkamenet-alapú felülvizsgálat azt kérdezi: legitim volt-e ez az adott munkamenet? Erre a kérdésre épül minden klasszikus Firefighter audit-felülvizsgálat. Az FF-felülvizsgáló megnyitja a munkamenetet, elolvassa a foglalás indokát, átfutja a tranzakciónaplót, ellenőrzi a nyilvánvaló rendellenességeket, aláírja. Ez a Team Human játékterve.

Az AI mintázat-alapú elemzés tipikus emberi felülvizsgálatként indul, de ezen túl mélyebb kérdéseket is feltesz: a munkamenetek, felhasználók, források, tranzakciók, audit-státuszok és történelmi alapvonalak elrendezése együtt kirajzol-e egy kockázati mintázatot? Ez olyan adatdomének összevetését igényli, amelyeket a munkamenet-alapú felülvizsgálat nem hoz egyszerre felszínre: kapcsolati gráfok kérelmezők és jóváhagyók között, forrás-host-eloszlások fiókok között, könyvelési bizonylat fejszövegek regex-szerű tartalma, a változási dokumentumok naplózását vezérlő rendszerparaméterek konfigurációja, felhasználónkénti tevékenységkoncentrációs arányok, tranzakció-kockázati osztályonkénti tartózkodási idő eloszlások. Ez a Team AI játékterve.

Ugyanaz az adat. Ugyanaz a játéktér. Két különböző játékterv. A sorozatban leírt jelek csak akkor láthatók, ha többféle és másfajta kérdéseket teszünk fel. A válaszhoz szükséges adatok olyan táblákban léteznek, amelyeket minden SAP és GRC környezet már most is karbantart. Az AI felülvizsgálati felismerés nem létezik a klasszikus munkamenet-felülvizsgálatban. Legalábbis eddig nem. Ez az aszimmetria változtatta a mérkőzést 6:0-s AI-győzelemmé.

A mérkőzés feltételei

Hat hónap folyamatos megfigyelés egy éles SAP S/4HANA környezetben több cégkóddal. Csaknem 600 Firefighter foglalás 11 vészhozzáférési fiókon át, 39 egyedi végfelhasználó. Körülbelül 2,55 millió Security Audit Log bejegyzés. Körülbelül 352 000 törzsadat-változás. Több mint 201 000 könyvelési bizonylat. Körülbelül 14 000 SAP audit-naplóbejegyzés naponta.

Az adatok eredete egyértelmű: az adatkészlet valós éles adat, egy valós SAP S/4HANA Firefighter telepítésből kinyerve, nem szintetikus vagy teszt környezetből. A „LAB-unkra" történő hivatkozások az analitikai környezetre utalnak, amelyben a GRC AI ügynök feldolgozta az anonimizált kivonatot, nem pedig az adatok eredetére. A konkrét azonosítók, fióknevek, országstruktúra és pontos dátumtartományok anonimizálva lettek; a nagyságrendek és a strukturális mintázatok változatlanok.

A volumen-kontextus számít a ~600 FF-munkamenetes adatkészletnél. A szokásos 5-10%-os mintavételezési ráta mellett a legképzettebb és legelkötelezettebb FF naplófelülvizsgálók talán 30-60 munkamenetet vizsgálnak meg részletesen - hatalmas mennyiségű időt és erőfeszítést fordítva a tevékenységre, próbálva minden egyes FF-munkameneten belül megtalálni a visszaélési mintákat. A többi 530-as is csak egy „elfogad" kattintást kap. Az 5-10%-os mintavételezés nem folyamatválasztás - hanem erőforrás-korlát. Bármely nagyobb mintán az auditpopulációt nagyságrenddel kellene bővíteni, és azok a kontrollok (függetlenség, elszámoltathatóság, audit-nyomvonal integritása), amelyek a szűk mintát indokolták, már nem állnák meg a helyüket.

Egyetlen munkamenetenként dolgozó felülvizsgáló sem foghatta volna fel az alább leírt első két mintázatot: ezek csak akkor rajzolódnak ki, ha az egész adatkészleten számolunk. A felülvizsgálat matematikája és szerkezete ezt nem teszi lehetővé. A felülvizsgálatot nem arra tervezték, hogy ezt a kérdést tegye fel. Ez volt az a pálya, amelyen a Team Human játszott.

Az adatkészlet hat hónap alatt 115 munkamenetet mutatott - nagyjából minden negyedik elfogadott munkamenetet - amelyet olyan auditor hagyott jóvá, aki maga is a legintenzívebb Firefighter operátorok közé tartozott. Az esetek többségében mind a kérelmező, mind a jóváhagyó ugyanahhoz az operatív csapathoz tartozott. Minden egyes jóváhagyás külön-külön védhetőnek tűnik. A mintázat csak akkor bukkan elő, ha az összes elfogadott munkamenetre kiszámítjuk a felhasználó-auditor gráfot, és azonosítjuk a zárt hurkokat.

Miért számít ez: egy felülvizsgáló, aki egy csapattársának munkamenetét auditálja, más ösztönzők alatt működik, mint az, aki egy idegenét. A bizalom gyorsabb, mint a kihívás. Egy kolléga munkamenetén való számonkérés két olyan költséget jelent, amelyet a felülvizsgáló nem tud könnyen elviselni. Először, súrlódást a csapaton belül, amelynek továbbra is együtt kell dolgoznia. Másodszor, az ésszerű elvárást, hogy ugyanaz a „részletes" vizsgálat fog visszajönni, amikor az ő saját munkamenete kerül a sorba. A kihívás felfelé hat. Az elfogadás lefelé. A legkisebb ellenállás útja az aláírás és a továbblépés.

Minden egyes jóváhagyás külön továbbra is védhetőnek tűnik. A folyamatot betartották. A kérelmező jogosult a foglalásra. Az auditor jogosult a tisztázásra. A nyomvonal tiszta. A felszínen az egyik személy dolgozik, a másik pedig ellenőriz, ami kontrollnak tűnik. A rendszerszintű kockázat csak az aggregátumban él, ahol azok az emberek, akik a legjobban tudnák egymás munkáját átvizsgálni, egyúttal a legkevésbé motiváltak erre. Ez a kép egyetlen munkamenet-rekordban sem látható.

Hogyan szerezte meg az AI ezt a gólt: abbahagyta az egyedi munkamenet-rekordok nézését, és elkezdte nézni az azokat összekötő hálózatot. Az ügynök az egész audit-ciklusról egy relációs modellt épített. Minden kérelmező egy csomópont. Minden jóváhagyó egy csomópont. Minden elfogadott munkamenet egy irányított él a kérelmezőtől a jóváhagyóig. Ezzel a gráffal a munkamemóriában a zárt hurkok megtalálása, ahol intenzív felhasználók aláírják egymás munkameneteit, egyetlen lekérdezés, nem pedig 481 rekord átvizsgálása. Az AI ügynök ezt a gráfot összekapcsolta két olyan kontextusréteggel is, amelyeket a manuális munkafolyamat külön eszközökben tart: a jogosultsági mátrixszal, amely meghatározza, ki hagyhat jóvá, és a felhasználónkénti tevékenységi alapvonallal, amely azonosítja az intenzív felhasználói populációt. A mintázat másodperceken belül kirajzolódott, mert az ügynök a hálózat szerkezetét vizsgálta, nem az egyes rekordokat. Ez volt az a húzás, amellyel a gólt szerezte. Az FF minősége és az FF-munkamenet alatti tevékenység független felülvizsgálata ennek a kontrollnak az alapja. Minőségi felülvizsgálat nélkül = nincs érvényes kontroll erre a kockázatra.

Miért nem tudott a Team Human munkamenet-alapú játékterve mérkőzni ezzel: a naplóbejegyzések ott vannak a felülvizsgálaton belül, de a munkafolyamatban semmilyen nézet nem teszi lehetővé a felülvizsgálónak, hogy ezeket forrás-host szerint aggregálja a fiókokon át. Az osztályozás fiókonkénti aggregálása és az arány összehasonlítása a vész- versus technikai fiókok alapvonalához igényli a szerepkatalógust és egy heurisztikát arra vonatkozóan, hogy melyik arány utal technikai használatra. Egyik sem része a munkamenetenkénti ellenőrzőlistának. A felülvizsgálónál ott van az adat. Csak a lencséje hiányzik. Az is szükséges, hogy a felülvizsgáló az aktuális ellenőrzőlistán túlmutató módon gondolkodjon, és más típusú kérdést tegyen fel: nemcsak azt, hogy „ez az adott munkamenet indokolt volt-e?", hanem azt is, hogy „milyen mintázat rajzolódik ki, ha ezeket a munkameneteket fiókokon, hostokon és fióktípusokon át hasonlítjuk össze?". Ez sokkal mélyebb analitikai lépés, mint amire a szabványos munkafolyamat ösztönöz. Tisztességes megjegyezni: ez a fajta feladat egy emberi felülvizsgáló számára különösen nehéz, mert órákon át tartó, sokszor ismétlődő, alacsony jel/zaj arányú bejegyzéseket tartalmazó hosszú felülvizsgálati naplók átolvasását jelenti. A munka időigényes, monoton és mentálisan kimerítő. Egy bizonyos pont után a figyelem természetes módon csökken, és a finom mintázatokat könnyű elszalasztani. Egy felülvizsgáló minden egyes bejegyzést helyesen dolgozhat fel, és mégis figyelmen kívül hagyhatja a hasonló munkamenetek között megbúvó szélesebb jelet. Más szóval, a korlát nem az, hogy a felülvizsgálónak nincs hozzáférése a bizonyítékhoz. A korlát az, hogy a bizonyíték egy munkamenetenkénti validálásra optimalizált FF munkafolyamatba van temetve, nem fiókok közötti mintázat-felismerésre. Az adat jelen van, de a felülvizsgálati folyamat nem teszi láthatóvá a releváns mintázatot.

Az adatkészlet azt mutatta, hogy a Firefighter munkamenetekből származó összes Security Audit Log bejegyzés 53,7%-a, körülbelül 1,37 millió sor, szerver hostnévről származott. Ez a vészhozzáférésnek címkézett fiókok alatt futó automatizáció, nem emberi vészhelyzeti munka. A tizenegy Firefighter fiók közül három olyan forrás-host eloszlást mutatott, amelyet a szerverforgalom dominált, jelezve, hogy de facto technikai fiókként működnek. A strukturális ajánlás: ezt a három fiókot szűken hatókörű technikai fiókokra kell cserélni a Z_BC_* mintázat szerint.

Munkamenet-szinten egyetlen munkamenet sem tárja fel ezt a mintázatot. Mindegyik munkamenet egy foglalást mutat, egy tranzakciólistát és egy audit ítéletet. Az a tény, hogy a munkameneten belüli tranzakciók szerver hostnévről származtak, nem pedig a kérelmező munkaállomásáról, egy olyan oszlopban van eltemetve, amely szerint az audit munkafolyamat soha nem csoportosít. A munkamenetet megnyitó felülvizsgáló legitimnek tűnő tevékenységet lát: a szereptartományba illő tranzakciók, ésszerű időablak, tiszta napló. A strukturális anomália a munkamenet szintjén nem jelenik meg. Csak akkor látható, ha a naplóbejegyzéseket forrás-host szerint osztályozzuk, és az eredményt fiókonként aggregáljuk. Ez az osztályozás nincs a munkamenetenkénti nézetben.

Hogyan szerezte meg az AI ezt a gólt: abbahagyta az audit-napló munkamenet-eseményeinek listájaként való olvasását, és elkezdte dimenzionális adatkészletként olvasni. Az ügynök kiszámította a forrás-host eloszlást mind a 2,55 millió naplóbejegyzésre, Firefighter fiókonként lebontva. Másodperceken belül megvolt a tizenegy fiók táblázata, mindegyikhez a szerver-host és a munkaállomás-tevékenység arányával. Ezután ezt a táblát összevetette két olyan dologgal, amelyeket a manuális munkafolyamat külön helyeken tart: a szerepkatalógussal (melyik fiók milyen típusú) és a SAP iparági heurisztikával (50% feletti szerver-host tevékenység szolgáltatási fiók munkaterhelést jelent, nem vészhozzáférési munkaterhelést). Három Firefighter fiók kiemelkedett, mert álcázott technikai fiókként viselkedett. Az ügynök ezután előállította a strukturális ajánlást: ezt a három fiókot kell átsorolni a Z_BC_* mintázatra szűk hatókörrel, nem pedig „mondják meg a felülvizsgálónak, hogy legközelebb nézze meg közelebbről". Ez volt az a húzás, amellyel a gólt szerezte.

Miért nem tudott a Team Human munkamenet-alapú játékterve mérkőzni ezzel: a naplóbejegyzések ott vannak a felülvizsgálaton belül, de a munkafolyamatban semmilyen nézet nem teszi lehetővé a felülvizsgálónak, hogy ezeket forrás-host szerint aggregálja a fiókok között. Az osztályozás fiókonkénti aggregálása és az arány összehasonlítása a vész- versus technikai fiókok alapvonalával igényli a szerepkatalógust és egy heurisztikát arra vonatkozóan, hogy melyik arány utal technikai használatra. Egyik sem része a munkamenetenkénti ellenőrzőlistának. A felülvizsgálónál ott van az adat. Csak a lencséje hiányzik.

Az AI ügynök adatkészlet-felülvizsgálata 19 olyan könyvelt könyvelési bizonylatot mutatott, amelyekben a BKPF fejszöveg mező lakossági levelezőszolgáltatókon lévő ügyfél e-mail címeket tartalmazott. A pénzügyi bizonylat fejszövegét rendszerhivatkozásokra tervezték: számlaazonosítókra, belső korrelációs kulcsokra, dokumentumlánc-mutatókra. Ügyfél kapcsolati adatok megjelenése itt GDPR aggály. A személyes adat most egy olyan rendszermezőben él, amelynek nincs saját megőrzési politikája, nincs nyilvántartva a szervezet Adatkezelési Tevékenységeinek Nyilvántartásában PII-tárolóként, és rendszeresen exportálódik standard jelentési folyamatokban, beleértve az audit-beküldéseket és a partneradat-megosztásokat.

Mi a tényleges hiba: a BKPF-BKTXT az adatleltárban hivatalosan „technikai hivatkozási mezőként" van besorolva. Ez az osztályozás azt jelenti, hogy a DSAR lekérdezések (GDPR 15. cikk) átugorják, a törlési kérelmek (17. cikk) átugorják, a megőrzési politikák átugorják, és az adatexportok pszeudonimizálási szabályai is átugorják. Tizenkilenc ügyfél e-mail cím most már egy 5+ éves könyvelési rekordba van beágyazva, amelyet senki sem szken személyes adatokra, egy olyan mezőben, amelyet senki sem néz, amikor egy ügyfél adatvédelmi jogait kezeli. A szervezet nem tudja bizonyítani a GDPR 5., 15., 17. vagy 30. cikkének való megfelelést ennél az adatosztálynál, és arról sem tud, hogy nem tudja.

Miért nem kapta el ezt a munkamenetenkénti FF-felülvizsgálat: amikor egy auditor megnyit egy FF-munkamenetet és felülvizsgálja a könyvelt bizonylatokat, a fejszöveget egy stringként látja. Még ha mentálisan regisztrálja is, hogy egy bejegyzés ügyfélkapcsolatnak tűnik, az FF-munkamenet felülvizsgálati ellenőrzőlistájában nincs olyan tétel, amely azt mondaná, hogy „ha PII-formájú stringet látsz a BKPF-BKTXT mezőben, jelents kontroll-megállapítást". A felülvizsgálónak nincs meghatározott követő művelete. A mező technikai hivatkozásként van besorolva, így minden, ami ott megjelenik, alapértelmezésben technikai hivatkozásként kezelt. Az ember nem azért nem azonosította ezt problémaként, mert figyelmetlen volt, hanem mert a felülvizsgálati protokoll nem rendel GDPR-megfelelőségi szkennelést az FF audit lépéshez, és mert annak tudatossága, hogy ez az információ nem szerepelhet könyvelt bizonylatokban, GDPR-tanácsadói tudás, nem pedig a standard FF-felülvizsgáló képzés része.

Hogyan szerezte meg az AI ezt a gólt: tartalom-mintázat szkennelést futtatott, amelyet a manuális FF felülvizsgálat nem tartalmaz. Az ügynök vette a teljes BKPF-BKTXT értékkészletet az FF-en posztolt bizonylatokból, tízezer stringet, és alkalmazott egy regex mintázatkönyvtárat, amely lefedi az e-mail címeket, telefonszámokat, azonosító számokat és más személyes adatformátumokat. Másodperceken belül 19 bizonylat volt megjelölve. Ezután alkalmazott egy GRC tanácsadói heurisztikát, amelyet a standard ellenőrzőlista nem kódol: amikor a személyes adat olyan mezőkben jelenik meg, amelyek nincsenek PII-tárolóként nyilvántartva, hozza ezt felszínre kontroll-résként és kapcsolja össze az azt posztoló FF-munkamenettel. Az ügynök ezután a megállapítást összekapcsolta a GDPR 5. cikkével (adatminimalizálás), 15. cikkével (hozzáférési jog), 17. cikkével (törléshez való jog) és 30. cikkével (adatkezelési tevékenységek nyilvántartása), nem csak tizenkilenc bizonylatot produkálva, hanem egy védhető kontroll-állítást, amelyet egy belső auditor a DPO-hoz vihet. Ez volt az a húzás, amellyel a gólt szerezte. A PII-kezelés FF alatt egy olyan kontrollterület, amelyet a GDPR-megfelelő működéseknek bizonyíthatóan kezelniük kell. Szabadszöveges mezők célzott szkennelése nélkül nincs bizonyíték arra, hogy ez a kontroll működik.

Miért nem tudott a Team Human gólt szerezni ezzel szemben: egyetlen emberi auditor sem futtat egyenként FF-munkameneteket felülvizsgálva regex-egyezést PII-mintákra a BKPF fejszöveg mezőjén át, és a munkamenetenkénti felülvizsgálat egyedi stringeket hoz felszínre, de nem aggregálja őket szkennelésre. A heurisztika, amely azt mondja, hogy „amikor a személyes adat rendszerhivatkozásokra szánt mezőkben jelenik meg, jelezd kontroll-résként", a senior GRC tanácsadói gyakorlat része, konkrét GDPR-cikkekre képezve le, nem pedig a standard FF audit-ellenőrzőlista része. A felülvizsgáló előtt ott vannak a stringek. Nincs viszont meg a szkenner, a PII-mintázatkönyvtár vagy a GDPR-cikkek leképezése, amelyek a stringeket megfelelőségi megállapítássá tennék cselekvőképessé.

Az adatkészlet azt mutatta, hogy a legmagasabb volumenű FF-felhasználó által végrehajtott körülbelül 297 000 anyagtörzs-változtatásnál a CDPOS változási dokumentum bejegyzések részletek mezője üres volt. Nem részleges. Nem hibás. Üres. Ennek a résnek a standard értelmezése az, hogy a tömeges adatműveletek nem hoznak létre mezőszintű változási dokumentumokat, és így a részletszintű ellenőrzés utólag lehetetlen.

Mi a tényleges hiba: az ITGC-keretek (SOX, ISO 27001 A.12.4) megkövetelik, hogy a pénzügyi eredményt befolyásoló adatok változásai mezőszinten nyomon követhetők legyenek. 297 000 „nem ellenőrizhető"-ként naplózott változás nem részleges rés; ez a mezőszintű változáskontroll teljes hibája a ciklus legnagyobb egybefüggő törzsadat-tevékenysége felett. Egy auditor nem tudja megállapítani egy olyan kontroll működési hatékonyságát, amelyen 297 000 értékelési bejegyzés „nem ellenőrizhető"-t ad vissza. Mégis a munkamenetenkénti felülvizsgálat minden bejegyzést ismert korlátozásként kezel, a munka-megjegyzés „nem ellenőrizhető" marad, és a kumulatív megállapítás soha nem kerül felszínre platform szinten.

A mélyebb értelmezés, amely az elemzés visszacsatolási hurokjának egy átfutása során bukkant elő, az, hogy ez nem felhasználói szintű naplózási viselkedési probléma. Ez platformszintű rendszerparaméter-konfigurációs probléma. A tömeges MM02 és LSMW frissítésekre vonatkozó mezőszintű változási dokumentum rögzítését vezérlő SAP paraméter valószínűleg nincs engedélyezve a környezetben. A megoldás nem az, hogy „mondjuk meg az auditoroknak, hogy figyelmesebben vizsgáljanak". A megoldás a SAP konfigurációban van. Senki sem vette észre vagy kérte, mert ennek kérése egy már most is lehetetlen felülvizsgálati feladatot tenne nehezebbé. Olyan körülmények között, amikor 300 000 bejegyzés vár a sorban, a felülvizsgálat minősége önmagában a volumen miatt csökken. Még 24/7 dolgozva sem lehet befejezni az ellenőrzést. Nehéz elvárni bárkitől, hogy még több adat rögzítését kérje ott. Könnyebb „elfogadni" a felülvizsgálatot a réssel és továbblépni a következő munkamenethez.

Hogyan szerezte meg az AI ezt a gólt: újrakeretezte a problémát egy visszacsatolási hurok-átfutás segítségével. Az első adatkészlet-átfutáson az ügynök az üres részletek mezőt ellenőrzési résként jelölte meg - ugyanolyan értelmezéssel, amelyre egy emberi felülvizsgáló is jutna. Egy későbbi átfutáson, amikor a heurisztikai réteget egy GRC tanácsadói korrekció bővítette, az ügynök más kérdést tett fel: ha a rés strukturális (egy felhasználó 297 000 változtatásán át ismétlődik), milyen platformszintű beállítás vezérli a mezőszintű változási dokumentum rögzítését tömeges MM02 és LSMW műveletekre? Összevetette a SAP Basis konfigurációs paramétereit, amelyeket a manuális FF felülvizsgálat nem tartalmaz az ellenőrzőlistájában, és azonosította, hogy a releváns paraméter valószínűleg nincs engedélyezve. Az ügynök ezután összekapcsolta a megállapítást a SOX ITGC és ISO 27001 A.12.4 naplózási követelményeivel, nem csak munkamenet-szintű megjegyzést produkálva, hanem platformszintű kontroll-megállapítást, amelyet a belső audit a Basis csapathoz továbbíthat orvoslásra. Ez volt az a húzás, amellyel a gólt szerezte. Az FF audit nem tudja demonstrálni a tömeges adatváltozás-kontrollok működési hatékonyságát anélkül, hogy a mezőszintű rögzítés engedélyezve lenne. Nincs konfiguráció = nincs auditbizonyíték = nincs védhető kontroll.

Miért nem tudott a Team Human gólt szerezni ezzel szemben: az auditorok a munkajegyzeteikben „nem ellenőrizhető"-ként naplózták az üres részletek mezőt számos munkamenetben. Ennek a megfigyelésnek a mezőszintű audit-naplózást vezérlő SAP konfigurációs paraméterrel való korrelálása mind SAP Basis szakértelmet, mind audit-kontroll keretezést igényel. Mindkettő a tanácsadói heurisztika rétegben ül, nem a munkamenetenkénti felülvizsgáló ellenőrzőlistájában. A felülvizsgáló előtt ott van a tünet. Nincs azonban meg a Basis tudás és a keretezés, hogy a „nem tudom ellenőrizni"-t átkonvertálja arra, hogy „a konfigurációs választás a kontroll-rés, és íme a paraméter".

A megoldás nem az, hogy „mondjuk meg az auditoroknak, hogy figyelmesebben vizsgáljanak". A megoldás a rendszerkonfigurációban van.

Az adatkészlet azt mutatta, hogy egyetlen felhasználói profil felelős az összes Firefighter Security Audit Log bejegyzés 36%-áért, az összes FF törzsadat-változás 85%-áért (299 017 rekord) és az összes FF-en posztolt könyvelési bizonylat 99,8%-áért (201 413 a 201 840-ből). Az FF tevékenység három független mérőszáma, mind ugyanarra a profilra mutat. A matematika nem finom.

Mi a tényleges hiba: az FF definíció szerint vészhozzáférés. Kivételes. Időkorlátos. Foglalás-alapú. Ha egy profil hat hónap alatt végrehajtja az összes FF könyvelési tevékenység 99,8%-át, akkor a hozzáférés nem vészhelyzeti annál a profilnál. Ez álcázott állandó emelt szintű hozzáférés. A „FF egyenlő kivétellel" feltételezésre épülő kompenzáló kontroll abban a pillanatban megszűnik kontroll lenni, amikor az FF egyenlővé válik a rutinnal. A felhasználó normál szerepében lévő SoD-korlátok már nem vonatkoznak a tényleges munkaterhelésre, mert a tényleges munkaterhelés az FF-úton fut. A SOX és ITGC audit a „rutinműveletekhez használt vészhozzáférést" automatikus kontroll-hiányosságként kezeli. Az ISO 27001 A.9.2.5 (Felhasználói hozzáférési jogok felülvizsgálata) megköveteli, hogy a privilegizált fiókokat a tényleges igénnyel szemben felülvizsgálják. Egy profil, amely a könyvelési bizonylatok 99,8%-át generálja FF alatt, egyértelműen állandó hozzáférést igényel, nem vészhozzáférést, de a felülvizsgálati folyamatnak nincs mechanizmusa arra, hogy ezt az igényt állandó szerep-allokációs döntéssé alakítsa.

Maga a munkamintázat is köteg-interfész aláírásnak felel meg, nem emberi power-user aláírásnak. Magas volumen több százezer tranzakción át. Ismétlődő tranzakciókódok szűk tartományon belül. Nincsenek felderítő kattintások. Nincsenek tranzakciós hibabejegyzések. Megjósolható végrehajtási ablakok. Vagy egy ember kézzel hajt végre 200 000+ tranzakciót, ami fizikailag lehetetlen, vagy valamilyen automatizáció fut e mögött az emberi hitelesítő adat mögött az FF-hozzáférésen keresztül. Mindkét értelmezés kontroll-rés. A szervezet vagy nem tudja, hogy köteg-automatizációt futtat vészhozzáférésen át, vagy tudja, és elfogadta, hogy a vészhozzáférés az egyik legaktívabb felhasználó napi operatív útja.

Miért nem került ez a koncentráció soha napirendre: senki nem tervezte. Évek alatt halmozódott fel, hónapról hónapra. Az első évben ez a felhasználó talán a törzsadat-munka 30%-át végezte, mert ő volt a legtapasztaltabb. A második évben 50%, mert az újabb csapattagok rá hivatkoztak. A harmadik évben 85%, mert addigra senki más nem emlékezett rá, hogyan kell csinálni. Mire valaki ránéz a hat hónapos aggregátumra, a koncentráció egy egyetlen ponton függő hely, szakértőnek álcázva. A csapat ezt a személyt pótolhatatlan senior munkatársnak címkézi. Az auditpopuláció intenzív felhasználónak címkézi, helyesen felülvizsgálva. Az FF felülvizsgálati folyamatban nincs „a ciklus volumenéből való részesedésed" nevű metrika, és nincs jelzés, amely azt mondaná, hogy ez a koncentráció matematikailag inkonzisztens egy emberi power-user profilollal. A sodródás láthatatlan egyetlen felülvizsgálati ciklusban sem, és a „ő a törzsadat szakértőnk" társadalmi keretezés megóvja attól, hogy megkérdőjelezzék.

Hogyan szerezte meg az AI ezt a gólt: koncentrációs arányokat számított az FF-tevékenység több dimenziójában (naplóbejegyzések felhasználónként, törzsadat-változások felhasználónként, könyvelési bizonylatok felhasználónként), és a kapott eloszlást egy operatív aláírás-könyvtárral hasonlította össze. Másodperceken belül megvolt egy rangsor, amely ezt az egy profilt 36%-on, 85%-on és 99,8%-on helyezte el a három mérőszám között. Ezután alkalmazott egy GRC tanácsadói heurisztikát, amelyet a manuális FF felülvizsgálat nem kódol: amikor egy profil eloszlása köteg-interfész aláírást (magas volumen, szűk tranzakciótartomány, ismételhető kadencia, közel nulla hibaarány, megjósolható ablakok) mutat, sorolja át szolgáltatási fiók jelöltként, ne intenzív felhasználóként. Az ügynök előállította a strukturális ajánlást: építsenek egy állandó technikai szerepet Z_BTC_* szűk hatókörrel, és migrálják ezt a munkaterhelést teljesen ki az FF-ből. Összekapcsolta a megállapítást a SOX ITGC-vel (rutinműveletekhez használt vészhozzáférés hiányosság), az ISO 27001 A.9.2.5-tel (privilegizált hozzáférés felülvizsgálata) és az ISO 22301-gyel (üzletmenet-folytonosság, mivel egy személytől való függés a könyvelési átbocsátóképesség 99,8%-ánál dokumentált folytonossági kockázat). Ez volt az a húzás, amellyel a gólt szerezte. Három kontrollkeret ugyanarra a megoldásra mutat: vegyék le ezt a munkaterhelést az FF-ről, tegyék állandó technikai szerepre, állítsák vissza az FF-et a kivételes útjára.

Miért nem tudott a Team Human gólt szerezni ezzel szemben: minden munkamenet, amelyet ez a felhasználó nyitott meg, izoláltan felülvizsgálva legitim operatív munkának tűnik. A tranzakciók illeszkednek a szereptartományhoz. A foglalási indokok valós ticketekre hivatkoznak. Az audit ítélete „elfogadás". Egyetlen munkamenetben sem derül ki, hogy ugyanaz a személy felelős az adatkészletben szereplő összes FF könyvelési bizonylat 99,8%-áért. A koncentrációs arányok az egész adatkészlet tulajdonságai, nem egy adott munkameneté. A munkamenet-napló nem hordozza, hogy „a ciklus összevont volumenéhez való hozzájárulásod 99,8%". Még ha a felülvizsgálók intuitíven tudják is, hogy ez a személy „mindig az FF-en van", ennek az intuíciónak a kvantifikálása több tevékenységi dimenzióban felhasználónkénti részesedés-metrikák számítását és az eredmény köteg-interfész aláírás-könyvtárral való összehasonlítását igényli. Egyik sem része a munkamenetenkénti felülvizsgálatnak. A felülvizsgáló látja a volument. Nem látja a koncentrációs arányt, és nincs meg a mintázat-könyvtár, hogy megkülönböztesse az intenzív felhasználói volument az automatizáció-formájú volumentől.

A megoldás nem az, hogy „vizsgálják az intenzív felhasználót figyelmesebben". A megoldás az, hogy felismerjük a köteg-interfész munkaterhelést annak, ami, és teljesen eltávolítjuk az FF-ről.

Az adatkészlet kilenc olyan munkamenetet mutatott, amely F110 tranzakciót hajtott végre (Payment Run, amely valós banki fizetési megbízásokat generál, és aznap mozgatnak ki pénzt a cégtől). Ezekből kilencből hat hetekkel vagy hónapokkal a munkamenet zárása után még mindig PENDING audit-státuszban volt. Ebben az adatkészletben az F110 minta egy pénzügyi profil körül koncentrálódott. F110 végrehajtások összesen a kilenc munkamenetben: 23. Ezek közül a 23 közül független felülvizsgálatot kapottak száma az elemzés időpontjában: nulla. A szélesebb adatkészleten a magas kockázatú tranzakciók PENDING állapotban töltött tartózkodási ideje meghaladta az alacsony kockázatúakét - az ellenkezője annak, amit egy audit-politika szándékozna.

Mi a tényleges hiba: az F110 az a SAP tranzakció, amely valós banki fizetési megbízásokat generál. Minden végrehajtás egy kimenő fizetést engedélyez, amely ugyanazon a banki munkanapon hagyja el a cég számláját. Az ITGC-keretek (SOX, COBIT) a fizetési engedélyezést elsődleges kontrollként sorolják be. Az ISO 27001 A.9.4.4 kifejezetten foglalkozik a privilegizált segédprogramok feletti kontrollal, és az F110 ennek tankönyvi példája. Huszonhárom F110 végrehajtás nulla független felülvizsgálattal azt jelenti, hogy a négyszemközti elv a kimenő fizetések körül nem működik. A papíron lévő kontroll azt mondja: „az F110 munkamenetek időben történő független felülvizsgálatot igényelnek". A gyakorlatban a kontroll azt mondja: „az F110 munkamenetek hosszabb ideig ülnek PENDING-ben, mint a rutin munkamenetek, mert senki sem vállalkozik arra, hogy második pár szem legyen egy valós banki fizetésen".

Miért engedte a munkamenetenkénti FF felülvizsgálat, hogy a magas kockázatú munkamenetek tovább üljenek: ez egy kockázatkerülési paradoxon. Az F110 munkamenet tisztázásának mentális költsége aszimmetrikus. Egy tévesen tisztázott F110 felülvizsgálat az auditor nevét egy olyan valós banki fizetéshez kapcsolja, aminek nem kellett volna megtörténnie. Egy elhalasztott F110 felülvizsgálat semmilyen látható költséget nem jelent. Az ésszerű egyéni reakció, tekintettel erre az aszimmetriára, az, hogy halasszunk addig, „amíg lesz időm rendesen csinálni". De minden felülvizsgáló ugyanazt a számítást végzi el, ugyanazon a napon, ugyanarra a fajta munkamenetre. A kohorsz viselkedése egy fordított SLA-t eredményez anélkül, hogy a kohorszban bárki ezt szándékozta volna. Tegyük hozzá az operatív igazságot, hogy az F110 munkamenetek felülvizsgálata tovább tart, mert az elemzés nehezebb (több tranzakció, több összeg, több számla-hivatkozás ellenőrzendő), így tovább maradnak. És a sor nem hozza felszínre a kohorsz-hatást egyetlen egyedi felülvizsgáló számára sem.

Hogyan szerezte meg az AI ezt a gólt: korrelálta a tranzakció kockázati osztályát a felülvizsgálati státusz időtartamával az egész hátralékon át. Az ügynök egy „PENDING-ben töltött napok" eloszlást épített, amely a munkamenetben szereplő legmagasabb kockázatú tranzakció (F110, SE38, SU01, SM30, mind ismert magas kockázatú kódok) szerint van szegmentálva, és összehasonlította a rutin munkamenetek eloszlásával. Az eredmény az inverzió volt: a magas kockázatú munkamenetek átlagosan hosszabb tartózkodási időt mutattak, mint az alacsony kockázatúak. Ezután az ügynök alkalmazott egy GRC tanácsadói heurisztikát, amelyet a manuális ellenőrzőlista nem kódol: a magas kockázatú tranzakcióknak rövidebb SLA-juk kell legyen PENDING-ben, nem hosszabb. Az ügynök előállította a strukturális ajánlást: egészítsék ki a FF felülvizsgálati sor rendezését egy tranzakció-kockázati-osztály mezővel, automatikusan eszkalálják a magas kockázatú kódokat tartalmazó munkameneteket egy négyszemközti felülvizsgálati sávra meghatározott SLA-val, irányítsák ki őket az alapértelmezett PENDING sorból, és külön jelentsék az SLA-megfelelést. Összekapcsolta a megállapítást a SOX ITGC-vel (fizetési engedélyezés kontroll), az ISO 27001 A.9.4.4-gyel (privilegizált segédprogramok) és a négyszemközti elvvel. Ez volt az a húzás, amellyel a gólt szerezte. Az FF alatt végrehajtott banki fizetések időben történő független felülvizsgálat nélkül pontosan az a kontrollhiba, amelyet az auditorok külső értékelésen keresnek. Nincs kockázati-osztály szerinti útvonalválasztás = az F110 ugyanabban a sorban ül, mint az F-04, és a legmagasabb kockázatú tevékenység kapja a legkevesebb időt.

Miért nem tudott a Team Human gólt szerezni ezzel szemben: minden munkamenetet akkor vizsgálnak felül, amikor egy auditor megnyitja. A felülvizsgálati sor nem közli az auditorral, hogy ez a munkamenet többé vagy kevésbé időkritikus-e, mint a többi a sorban, és azt sem, hogyan néz ki a kohorsz-szintű SLA mintázat. A tartózkodási idő eloszlása nem látható egyetlen munkameneten belül, ez a sor tulajdonsága, és a sor nem hozza felszínre. Még ha egy egyedi felülvizsgáló tudja is, hogy az F110 munkamenetek általában túl sokat várnak, nincs kvantitatív jele az eszkalációhoz, és nincs mechanizmusa, hogy az F110 sort másképp irányítsa, mint a rutin sort.

A megoldás nem az, hogy „mondjuk meg az auditoroknak, hogy gyorsabban tisztázzák az F110 munkameneteket". A megoldás az, hogy irányítsuk ki őket az alapértelmezett sorból egy négyszemközti sávba meghatározott SLA-val.

Hat gól bekerült. Mielőtt rátérnénk a mérkőzés utáni elemzésre, hogy hogyan épült fel valójában a Team AI, érdemes egyértelmű lenni abban, mit nem hozott szándékosan felszínre az ügynök.

A gólok, amelyeket a Team AI nem szerzett

Érdemes felszínre hozni, mit nem hozott felszínre az ügynök. Nem jelölt meg egyetlen munkamenetet sem csalárdként. Az adatkészlet nem tartalmazott bizonyítékot rosszhiszemű szereplőkre. Nem talált ki meg nem lévő megfelelőségi megállapításokat. Nem javasolt olyan javításokat, amelyeket az irányelvi réteg nem támogat. Annak ellenére, hogy egy olyan modellen futott, amely teljes mértékben képes hallucinációra, nem hallucinált tranzakciókat, bizonylatszámokat vagy felhasználói tevékenységet. A sorozatban szereplő számok azért jelennek meg, mert az ügynök közvetlenül számolta őket a CDPOS, BKPF és hasonló táblákból, nem pedig becsülte.

Ez a gyakorlati válasz az AI audit-kontextusokban való szokásos kifogására. A hallucináció akkor történik, amikor egy modellt arra kérnek, hogy olyasvalamiről gondolkodjon, amelyhez nincs megalapozott adata.

Az ügynöknek ebben a kísérletben megalapozott adata volt mindenhez, amit mondott. A heurisztika réteg megmondta, mit keressen. Az eszközréteg lehetővé tette, hogy ellenőrzött számokat húzzon ki az alapul szolgáló platformról. A korábbi futások visszacsatolási rétege korrigálta az elfogultságait. Amit az ügynök nem tudott megalapozni az adatokban, nem hozta felszínre.

Ez nem ugyanaz, mint a hallucinációmentes garancia. Ez ellenőrizhetőségi garancia: minden szám, amelyet az ügynök felszínre hozott, reprodukálható, ha ugyanazt a lekérdezést újrafuttatjuk ugyanazokon a táblákon.

A modell az AI ügynök legkisebb része az auditban. A körülötte lévő architektúra határozza meg, hogy a kimenet védhető-e.

Hogyan edz a Team AI: módszertan és validáció

A heurisztika réteget, amelyen az ügynök gondolkodik, 15+ éves SAP audit-tapasztalattal rendelkező senior GRC tanácsadók írták, kollégái felülvizsgálták a cég audit-képzési anyagával szemben, és verzió-kontrollált. Minden heurisztikának hivatkoznia kell egy dokumentált audit-kontroll indoklásra, mielőtt bekerül az ügynök gondolkodási könyvtárába. A heurisztikákat nem prompt-iterációval adják hozzá, hanem ugyanazzal a folyamattal, amellyel egy tanácsadói cég új belső kontrollt írna.

Az ügynök által előállított minden jelet egy emberi GRC tanácsadó vizsgálta felül, mielőtt megjelent volna ebben a sorozatban. Két jelölt jelet a korábbi elemzési átfutásokból elutasítottak a felülvizsgálatban: az egyik hamis pozitív volt hiányos szerepkatalógus-adatokra alapozva (az ügynök egy rutin SoD-újratervezés előtti elavult pillanatképpel dolgozott), a másik pedig egy valós anomália volt, amelynek nem volt audit szempontjából releváns vonzata, és inkább zajt termelt volna, mint jelet. A hat publikált jel mind átment ezen az emberi felülvizsgálaton.

A hamis pozitív arány az összes elemzési átfutáson körülbelül 8%-on futott. Minden tizenkettedik ügynök által megjelölt tételt kb. elutasított az emberi felülvizsgáló, akár hiányos kontextusra alapozva, akár jóindulatú kiugró értékként. Az ügynök bizalmi pontszáma korrelál a felülvizsgáló elfogadásával, de nem helyettesíti a felülvizsgálatot. Minden jel ebben a sorozatban ellenőrzött az alapul szolgáló adatokon egy elszámoltatható GRC tanácsadó által. Egyetlen jelet sem mutatunk be véglegesként emberi aláírás nélkül.

A munkamegosztás az alapelv. Az ügynök olyan léptékben és olyan adatdoméneken át észlel mintázatokat, amelyeket az emberi felülvizsgálat nem érhet el: mintázatészlelés 600 munkameneten át, aránszámítás 2,55 millió naplóbejegyzésen át, kereszthivatkozás több adatdomén között. Az ember dönti el, hogy a mintázat audit szempontjából releváns-e, hogy a keretezés helyes-e, és hogy publikálható-e kontrollállításként. Egyik sem helyettesíti a másikat.

Hogyan áll fel a Team AI: a hatrétegű architektúra

Eszközréteg: a GRC platform minden funkciója jól tipizált API-ként van kitéve, amelyet az ügynök hívhat anélkül, hogy az argumentumait hallucinálná. Minden művelet határolt, típus-ellenőrzött és visszafordítható.

Irányelvréteg: Firefighter szabályok, SoD szabálykészlet, tranzakció-kockázati osztályok, audit-megjegyzés sablonok, négyszemközti útvonalválasztási szabályok. Mind egy strukturált formátumban, amelyet az ügynök lekérdez, nem pedig szabadszövegben, amelyet a modellnek értelmeznie kellene.

Történeti kontextusréteg: minden múltbeli audit ítélet a megjegyzésével együtt, minden foglalási indok a kimenetelével, indexelve és lekérdezhetően.

Heurisztika réteg: a GRC tanácsadói know-how a valós anomáliák és a jóindulatú kiugró értékek megkülönböztetésére. A legnehezebb réteg felépíteni, mert a szerzők senior tanácsadók, nem LLM mérnökök.

Visszacsatolási réteg: a korábbi futásokból származó korrekciók, amelyek a következő átfutáson igazítják az ügynök elfogultságát.

És mindezek tetején egy determinisztikus ellenőrzési lépés, amely újrafuttatja minden számot, amelyet az ügynök előállít, így a kimenet végponttól végpontig reprodukálható igény szerint.

Ezt jelenti az AI egy GRC platformon belül mint termékkategória. Nem ChatGPT-doboz hozzáadva a felhasználói felülethez. Ugyanazok az audit funkciók, amelyekkel a platform már rendelkezik, ügynök-eszközként kitéve, üzleti-audit logika és történeti kontextus rétegei alatt, amelyek strukturálisan korlátozzák a hallucinációt, és minden ügynök-állítást ellenőrizhetővé tesznek.

Egy másik szállító GRC platformja (SAP GRC, mások ebben az osztályban) felépíthetné ugyanezt az architektúrát. A mi implementációnkban ezeket a képességeket a smartGRC smartAccess moduljában szállítjuk. Az architektúra platform-független.

Az a fegyelem, hogy az ügynököt ellenőrizhető adatokon tartjuk megalapozva, nem pedig a hallucinációs problémát marketingeljük el, fogja meghatározni a SAP GRC következő öt évét.

Hogyan tér vissza a Team Human a játékba

Mérje meg a saját pályáját

A jelek reprodukálhatók. Olyan adatokban élnek, amelyekkel a szervezete már rendelkezik, olyan táblákban, amelyeket a GRC platformja már lekérdez. A következő kérdéseket meg lehet válaszolni az Ön saját Firefighter adatkészletén ugyanazzal az eszközréteggel, amelyet az ügynök ebben a kísérletben használt: változási dokumentum táblák, könyvelési bizonylat fejlécek, audit-naplóbejegyzések, foglalási előzmények, szerepkatalógusok. A kapcsolati jelhez: az utolsó ciklusban elfogadott Firefighter munkamenetek mekkora hányadát hagyta jóvá az intenzív felhasználók felső decilisének egy tagja?

A kapcsolati jelhez (1. gól): építsen egy irányított gráfot az FF foglalásokról, ahol minden kérelmező egy csomópont, minden jóváhagyó egy csomópont, és minden elfogadott munkamenet egy él a kérelmezőtől a jóváhagyóig. Az elfogadott munkamenetek mekkora hányada alkot zárt hurkokat, amelyekben intenzív FF-felhasználók egymás munkameneteit írják alá?

A tevékenység-forrás jelhez: Firefighter fiókonként mi az audit-naplóbejegyzések aránya, amelyek szerver hostnévről származnak, szemben a felhasználói munkaállomásokkal? Mely fiókok lépik át azt a küszöböt, amely szolgáltatási fiók munkaterhelést sugall?

Az adatelhelyezési jelhez: egy regex keresés a BKPF fejszövegen át az elmúlt hat hónapra. Hány bizonylat tartalmaz e-mail címeket vagy más személyes adat formátumokat?

A naplózás-teljesség jelhez: a mezőszintű változási dokumentum rögzítését tömeges MM02 és LSMW műveletekre vezérlő SAP rendszerparaméter engedélyezve van-e az Ön környezetében?

A koncentráció jelhez: Firefighter felhasználói profilonként mi az ő részesedésük az összes könyvelési bizonylatból és törzsadat-változásból?

A felülvizsgálati prioritás jelhez (6. gól): a jelenlegi PENDING sorában mi az F110, SE38, SU01 vagy SM30 tranzakciókat tartalmazó munkamenetek tartózkodási idő eloszlása a rutin munkamenetek tartózkodási idejéhez képest?

Ezek a lekérdezések mindegyike egyhetes feladat egy kompetens SAP/GRC elemző számára. Az általuk felszínre hozott mintázatok, ha vannak ilyenek, nem ugyanazok a számok lesznek, mint ebben a sorozatban. Különböző környezetek különböző eloszlásokat termelnek. A kérdések ugyanazok.

Három egyhetes lépés

A jelek konkrét egyhetes lépésekké fordíthatók a GRC működés különböző szerepkörei számára, függetlenül bármilyen strukturális, többéves változási programtól.

Egy CISO rendeljen egy tevékenység-forrás auditot a szervezet saját Firefighter fiókjain. Egy egynapos lekérdezés a Security Audit Log-on ugyanolyan típusú százalékot fog produkálni, mint a 2. gól, vagy mást. Ha a szám magas, néhány vészhelyzeti fiók álcázott technikai fiókként működhet.

Egy GRC vezető egészítse ki az audit munkafolyamat PENDING sor rendezését egy tranzakció-kockázati osztály mezővel, leképezve a 6. gólt egy felülvizsgálati-sor konfigurációs változásra, nem pedig projektre. A Firefighter politika, amelyet Ön írt, már magas kockázatúként osztályozza az F110-et; a munkafolyamatnak olvasnia kell ezt a besorolást.

Egy belső auditor kérje a SAP Basis csapattól annak megerősítését, hogy a mezőszintű változási dokumentum paraméter (4. gól) engedélyezve van-e a környezetben, és kezelje a választ kontrollértékelési megállapításként mindkét esetben.

Ezek mindegyike egyhetes lépés, nem többéves program.

A nagyobb mérkőzés

A kérdés nem az, hogy be kell-e tenni az AI-t a GRC-be. A kérdés az, hogy a GRC platformok audit funkcióikat ügynök-eszközként fogják-e kitenni, ahogy tíz évvel ezelőtt emberi felhasználói felületekként tették ki, és hogy a GRC tanácsadók fejében hordott heurisztikákat egy olyan kontextusrétegbe kódolják-e, amelyen egy ügynök konzisztensen gondolkodhat. Az első szállítók, akik ezt megteszik, azzal a fegyelemmel, hogy az ügynököt ellenőrizhető adatokon tartsák, és ne a hallucinációs problémát marketingeljék el, fogják meghatározni, hogyan néz ki a SAP GRC következő öt éve.

Az, hogy az Ön audit-ciklusa megtalálja-e ezeket a mintázatokat, mielőtt egy külső auditor jelentésében megjelennek, teljes mértékben attól függ, hogy milyen eszközöket ad azoknak az embereknek, akik felelősek a megtalálásukért. A sorozatban szereplő jelek voltak az ügynök első leszállítandó eredménye. A strukturális javítások, amelyekre rámutatnak, most már mindenki problémája megoldani.

A sorozatról. Az ebben a cikkben elemzett adatkészlet egy valós, éles SAP S/4HANA Firefighter telepítésből származik; az elemzést a GRC Advisory smartGRC LAB-ja végezte ennek az adatnak egy anonimizált kivonatán. A cikk nem nevez meg, nem azonosít és nem tulajdonít elemzést egyetlen konkrét szervezetnek sem. Ha Ön nagy léptékben üzemelteti a SAP Firefighter-t, és szeretne hasonló elemzés futtatásáról beszélgetni a saját adatain, az elérhetőségek és egy élő UX előnézet a smartgrc.eu oldalon találhatók. Ez az 1., 2. és 3. részként korábban közzétett háromrészes sorozat konszolidált kiadása.