Koble leveransen til SOC og SIRT

Definer funksjonene bak navnene

Et security operations center, eller SOC, overvåker vanligvis sikkerhetssignaler, undersøker varsler og eskalerer mistenkte hendelser. Et security incident response team, eller SIRT, samordner responsen på sikkerhetshendelser. CSIRT er et annet vanlig navn på denne responsfunksjonen.

Organisasjoner fordeler disse funksjonene ulikt. De samme personene kan utføre begge. En ekstern leverandør kan levere en del av tjenesten. Ikke utled dekning eller fullmakter fra en forkortelse. Dokumenter overvåkingstider, eskaleringsveier, beslutningsrettigheter og responsforpliktelser.

FIRSTs CSIRT-rammeverk beskriver tjenester et responsteam kan tilby. NIST knytter hendelsesrespons til bredere styring av cybersikkerhetsrisiko. Bruk disse kildene til å definere ansvar og grensesnitt. FIRST-rammeverket, NISTs hendelsesrespons.

Ta AI-utvikling med i deteksjonsomfanget

Et programvareleveransesystem har identiteter, repositories, runners, registre, integrasjoner og påloggingsopplysninger for utrulling. Agenter tilfører verktøykall og dataflyter til modellleverandører. Ta disse grensene med i sikkerhetsdesignet.

Velg hendelser som støtter definerte deteksjoner. Eksempler er uventet repository-tilgang, endringer i rettigheter, uvanlig publisering av artefakter og utrulling fra en ikke-godkjent identitet. Knytt registreringer sammen med tidsstempler, aktøridentiteter, ressursidentifikatorer og uforanderlige artefaktdigests der de finnes.

Beskytt disse registreringene. Tilgang til revisjonsdata, oppbevaring, klokkekvalitet og innsamlingsfeil påvirker undersøkelsen. En utviklingskjøringslogg og en revisjonslogg fra skyen svarer på ulike spørsmål. Ingen av dem er automatisk en fullstendig hendelsesregistrering.

Forbered overleveringen før hendelsen

Definer hvem som kan tilbakekalle et token, isolere en runner, stanse utrulling eller gjenopprette en tjeneste. Tjenesteeiere forklarer driftskonsekvenser. Sikkerhetsansvarlige samordner undersøkelse og begrensning. Relevante ansvarlige for personvern, jus og virksomhet vurderer varslingsplikter i den faktiske situasjonen.

Varslingskrav avhenger av hendelsen og gjeldende forpliktelser. Involver riktig beslutningseier tidlig. Ikke la et AI-sammendrag avgjøre dette eller forsinke en etablert eskaleringsvei.

Gå gjennom en fiktiv tokenhendelse

Klokken 14:05 UTC oppdager SOC at en byggeidentitet leser et uventet repository. Klokken 14:08 bekrefter repository-eieren at ingen godkjent jobb forklarer aktiviteten. Det er fortsatt ukjent om kildekode forlot miljøet.

Responsteamet bevarer revisjonsregistreringer og relevante bevis fra runneren. En autorisert eier tilbakekaller de berørte påloggingsopplysningene og stanser den mistenkte kjøreveien. Handlingene følger organisasjonens responsprosedyre og tar hensyn til tjenestepåvirkning.

Det er ikke nok å slette det lekkede tokenet fra en fil. Påloggingsopplysningene kan fortsatt være gyldige andre steder. Det er heller ikke nok å bygge en runner på nytt hvis identiteten fortsatt er kompromittert. Undersøk utstedte artefakter, videre tilgang og andre påloggingsopplysninger innenfor det sannsynlige omfanget.

Før leveransen gjenopprettes, må dere verifisere identitet, runner, artefaktenes opprinnelse og nødvendige tilgangsgrenser. Registrer hva som fortsatt er ukjent. Et vellykket bygg alene fastslår ikke at leveransemiljøet er til å stole på.

Før funnene tilbake til utvikling

Gjør bekreftede årsaker til arbeid med tydelige eiere: kortere levetid for påloggingsopplysninger, snevrere tilgang, runner-isolasjon, endrede deteksjoner eller en regresjonstest. Valider rettingen, og øv på overleveringen igjen.

Taigas revisjons- og leveranseregistreringer kan bidra med bevis innenfor sitt dokumenterte omfang. Integrer dem i organisasjonens responsprosess. Kontroller grensen for delt ansvar i stedet for å anta at det å ta Taiga i bruk overfører eierskapet til SOC eller SIRT. Audit log, delt ansvar.