Propojte dodávku se SOC a SIRT

Definujte činnosti za názvy

Security operations center neboli SOC obvykle monitoruje bezpečnostní signály, vyšetřuje upozornění a eskaluje podezření na incidenty. Security incident response team neboli SIRT koordinuje reakci na bezpečnostní incidenty. Dalším běžným názvem této funkce je CSIRT.

Organizace si tyto činnosti rozdělují různě. Stejní lidé mohou dělat obojí. Část služby může poskytovat externí dodavatel. Ze zkratky nevyvozujte pokrytí ani pravomoci. Zaznamenejte dobu monitoringu, eskalační postupy, rozhodovací práva a závazky reakce.

Rámec FIRST pro CSIRT popisuje služby, které může tým reakce poskytovat. NIST propojuje reakci na incidenty s širším řízením kybernetických rizik. Pomocí těchto referencí definujte odpovědnosti a rozhraní. Rámec FIRST, reakce na incidenty podle NIST.

Zahrňte vývoj s AI do rozsahu detekce

Systém dodávky softwaru má identity, repozitáře, runnery, registry, integrace a přihlašovací údaje k nasazení. Agenti přidávají volání nástrojů a datové toky poskytovatelů modelů. Tyto hranice zahrňte do bezpečnostního návrhu.

Vyberte události, které podporují definované detekce. Patří mezi ně neočekávaný přístup do repozitáře, změny oprávnění, neobvyklé publikování artefaktů a nasazení neschválenou identitou. Záznamy propojujte časovými údaji, identitami aktérů, identifikátory prostředků a dostupnými neměnnými digesty artefaktů.

Tyto záznamy chraňte. Přístup k auditu, uchování, kvalita hodin a výpadky sběru ovlivňují šetření. Log vývojového běhu a cloudový auditní log odpovídají na jiné otázky. Ani jeden automaticky není úplným záznamem incidentu.

Připravte předání před incidentem

Definujte, kdo může odvolat token, izolovat runner, pozastavit nasazování nebo obnovit službu. Osoby odpovědné za služby vysvětlují provozní následky. Bezpečnostní tým koordinuje šetření a omezení škod. Příslušné osoby odpovědné za soukromí, právní a obchodní záležitosti posuzují oznamovací povinnosti pro skutečnou situaci.

Požadavky na oznámení závisejí na incidentu a příslušných povinnostech. Odpovědnou osobu pro rozhodnutí zapojte včas. Nenechte toto posouzení provést shrnutí AI ani jím nezdržujte zavedený eskalační postup.

Projděte fiktivní incident s tokenem

Ve 14:05 UTC SOC zjistí, že identita sestavení čte neočekávaný repozitář. Ve 14:08 vlastník repozitáře potvrdí, že aktivitu nevysvětluje žádná schválená úloha. Zda zdrojový kód opustil prostředí, zůstává neznámé.

Tým reakce zachová auditní záznamy a příslušné důkazy z runneru. Oprávněná odpovědná osoba odvolá dotčený přihlašovací údaj a zastaví podezřelý postup provádění. Tyto akce následují postup reakce organizace a zohledňují dopad na službu.

Smazání uniklého tokenu ze souboru nestačí. Přihlašovací údaj může zůstat platný jinde. Ani nové vytvoření runneru nestačí, pokud identita zůstává kompromitovaná. Prozkoumejte vydané artefakty, navazující přístupy a další přihlašovací údaje v rozsahu, který mohl být dotčen.

Před obnovením dodávky ověřte identitu, runner, původ artefaktů a požadované hranice přístupu. Zaznamenejte, co zůstává neznámé. Samotné úspěšné sestavení neprokazuje důvěryhodnost prostředí dodávky.

Vraťte zjištění do vývoje

Potvrzené příčiny převeďte na práci s odpovědnou osobou: kratší platnost přihlašovacích údajů, užší přístup, izolaci runneru, změny detekce nebo regresní test. Nápravu ověřte a předání znovu procvičte.

Auditní záznamy a záznamy dodávky Taigy mohou v doloženém rozsahu přispívat důkazy. Zapojte je do procesu reakce organizace. Prověřte hranici sdílené odpovědnosti, místo abyste předpokládali, že zprovoznění Taigy převádí odpovědnost za SOC nebo SIRT. Audit log, sdílená odpovědnost.