Leerpad 05Les 6 / 8

Verbind softwarelevering met het SOC en SIRT

Definieer beveiligingsmonitoring, incidentoverdracht, bewijsbewaring en herstelverantwoordelijkheden. Verbind beveiligingsrespons met de softwarelevenscyclus.

Gevorderd12 minGereviewd

Gepubliceerd door Hoe we schrijven

Wat u leert

  • Onderscheid SOC-monitoring van incidentcoördinatie door het SIRT.
  • Bereid een bruikbare overdracht van een beveiligingsincident voor.
  • Verbind indamming, herstel en corrigerend engineeringwerk.

Definieer de functies achter de namen

Een security operations center, of SOC, bewaakt doorgaans beveiligingssignalen, onderzoekt meldingen en escaleert vermoedelijke incidenten. Een security incident response team, of SIRT, coördineert de respons op beveiligingsincidenten. CSIRT is een andere gangbare naam voor deze responsfunctie.

Organisaties verdelen deze functies verschillend. Dezelfde mensen kunnen beide uitvoeren. Een externe provider kan een deel van de dienstverlening verzorgen. Leid dekking of bevoegdheid niet af uit een afkorting. Leg monitoringuren, escalatieroutes, beslissingsrechten en responstoezeggingen vast.

Het CSIRT-framework van FIRST beschrijft diensten die een responsteam kan leveren. NIST verbindt incidentrespons met breder cybersecurityrisicobeheer. Gebruik deze bronnen om uw verantwoordelijkheden en interfaces te definiëren. FIRST-framework, NIST-incidentrespons.

Neem AI-ontwikkeling op in de detectiescope

Een softwareleveringssysteem bevat identiteiten, repositories, runners, registries, integraties en deploymenttoegangsgegevens. Agents voegen toolaanroepen en gegevensstromen naar modelproviders toe. Neem deze grenzen op in het beveiligingsontwerp.

Kies gebeurtenissen die gedefinieerde detecties ondersteunen. Voorbeelden zijn onverwachte repositorytoegang, gewijzigde rechten, ongebruikelijke publicatie van artefacten en deployment door een niet-goedgekeurde identiteit. Verbind registraties met tijdstempels, identiteiten van uitvoerders, resource-ID’s en waar beschikbaar onveranderlijke artefactdigests.

Bescherm die registraties. Audittoegang, bewaartermijnen, klokkwaliteit en verzamelfouten beïnvloeden het onderzoek. Een log van een ontwikkelrun en een cloudauditlog beantwoorden verschillende vragen. Geen van beide is automatisch een volledig incidentdossier.

Bereid een overdracht voor vóór het incident

OverdrachtsveldBenodigde informatie
WaarnemingWat gebeurde, wanneer en in welk systeem
ZekerheidGeverifieerd feit, werkhypothese of onbeantwoorde vraag
ReikwijdteIdentiteiten, repositories, omgevingen en mogelijk getroffen gegevens
BewijsBeschermde locaties en verzamelgegevens, zonder secrets bloot te stellen
ActiesWat is gewijzigd, wie gaf toestemming en wat was het waargenomen resultaat
BeslissingBenoemde responsverantwoordelijke, volgende actie en tijdstip van de volgende update

Definieer wie een token mag intrekken, een runner mag isoleren, deployment mag pauzeren of een service mag herstellen. Serviceverantwoordelijken leggen de gevolgen voor het beheer uit. Beveiligingsresponders coördineren onderzoek en indamming. De relevante verantwoordelijken voor privacy, juridische zaken en de bedrijfsvoering beoordelen meldplichten voor de werkelijke situatie.

Meldvereisten hangen af van het incident en de toepasselijke verplichtingen. Betrek de juiste beslissingsbevoegde vroeg. Laat een AI-samenvatting die beslissing niet nemen of een bestaande escalatieroute vertragen.

Doorloop een fictief tokenincident

Om 14:05 UTC detecteert het SOC dat een buildidentiteit een onverwachte repository leest. Om 14:08 bevestigt de repositoryverantwoordelijke dat geen goedgekeurde job deze activiteit verklaart. Of broncode de omgeving heeft verlaten, blijft onbekend.

Het responsteam bewaart auditregistraties en relevant bewijs van de runner. Een bevoegde verantwoordelijke trekt de getroffen toegangsgegevens in en stopt het verdachte uitvoeringspad. Deze acties volgen de responsprocedure van de organisatie en houden rekening met de gevolgen voor de service.

Het gelekte token uit een bestand verwijderen is onvoldoende. De toegangsgegevens kunnen elders geldig blijven. Ook een runner opnieuw opbouwen is onvoldoende als de identiteit gecompromitteerd blijft. Onderzoek gepubliceerde artefacten, verdere toegang en andere toegangsgegevens binnen de plausibele reikwijdte.

Controleer vóór het hervatten van de levering de identiteit, runner, herkomst van artefacten en vereiste toegangsgrenzen. Leg vast wat nog onbekend is. Alleen een geslaagde build toont niet aan dat de leveringsomgeving betrouwbaar is.

Breng de bevindingen terug naar engineering

Zet bevestigde oorzaken om in werk met een verantwoordelijke: kortere geldigheid van toegangsgegevens, beperktere toegang, runnerisolatie, aangepaste detectie of een regressietest. Valideer de correctie en oefen de overdracht opnieuw.

De audit- en leveringsregistraties van Taiga kunnen binnen hun gedocumenteerde reikwijdte bewijs leveren. Integreer ze in het responsproces van de organisatie. Controleer de grens van gedeelde verantwoordelijkheid in plaats van aan te nemen dat Taiga activeren de verantwoordelijkheid voor SOC of SIRT overdraagt. Audit log, gedeelde verantwoordelijkheid.

Maak de oefening

Gebruik het fictieve tokenincident in deze les. Schrijf een overdracht met feiten, onzekerheden, getroffen identiteiten, bewaard bewijs, opties voor indamming en beslissingsbevoegden. Neem geen tokenwaarde op.

Werkblad downloaden (Markdown)

Controleer uw begrip

Het SOC ziet ongebruikelijk gebruik van een buildidentiteit, maar het team kan nog geen gegevenstoegang aantonen. Welke overdracht is het nuttigst?

Bronnen en verder lezen

Gerelateerd leesmateriaal van Taiga