Yhdistä ohjelmistotoimitus SOCiin ja SIRTiin

Määritä lyhenteiden takana olevat tehtävät

Security operations center eli SOC valvoo tavallisesti tietoturvasignaaleja, tutkii hälytyksiä ja eskaloi epäiltyjä poikkeamia. Security incident response team eli SIRT koordinoi tietoturvapoikkeamien käsittelyä. CSIRT on toinen tällaisesta tiimistä käytetty nimi.

Organisaatiot jakavat tehtävät eri tavoin. Samat ihmiset voivat hoitaa molempia. Ulkoinen toimittaja voi tuottaa osan palvelusta. Älä päättele kattavuutta tai valtuuksia lyhenteestä. Kirjaa valvonta-ajat, eskalointireitit, päätösoikeudet ja reagointilupaukset.

FIRSTin CSIRT-kehys kuvaa response-tiimin mahdollisia palveluja. NIST yhdistää incident responsen laajempaan tietoturvariskien hallintaan. Käytä lähteitä omien vastuiden ja rajapintojen määrittämiseen. FIRSTin kehys, NIST incident response.

Sisällytä AI-kehitys valvonnan piiriin

Ohjelmistotoimituksessa on identiteettejä, repositoryja, runnereita, registryjä, integraatioita ja deployment-tunnuksia. Agentit tuovat mukaan työkalukutsuja ja tietovirtoja mallitoimittajille. Sisällytä nämä rajat tietoturvasuunnitteluun.

Valitse tapahtumat, jotka tukevat määriteltyjä tunnistuksia. Esimerkkejä ovat odottamaton pääsy repositoryyn, käyttöoikeuksien muutos, poikkeava artefaktin julkaisu ja deployment hyväksymättömällä identiteetillä. Yhdistä tietueet aikaleimoilla, toimijatunnisteilla, resurssitunnisteilla ja saatavilla olevilla artefaktien digesteillä.

Suojaa tiedot. Audit-käyttöoikeudet, säilytysajat, kellojen luotettavuus ja keruun virheet vaikuttavat selvitykseen. Kehitysajon log ja pilven audit log vastaavat eri kysymyksiin. Kumpikaan ei automaattisesti ole täydellinen incident-tallenne.

Valmistele handoff etukäteen

Sovi, kuka saa perua tokenin, eristää runnerin, keskeyttää deploymentin tai palauttaa palvelun. Palvelun omistajat arvioivat toiminnalliset seuraukset. Security response koordinoi selvitystä ja rajaamista. Tietosuojan, juridiikan ja liiketoiminnan vastuuhenkilöt arvioivat tilanteeseen soveltuvat ilmoitusvelvollisuudet.

Ilmoitusvaatimukset riippuvat incidentistä ja sovellettavista velvoitteista. Ota oikea päätöksentekijä mukaan ajoissa. AI-yhteenveto ei ratkaise velvollisuutta eikä saa viivästyttää sovittua eskalointia.

Käy läpi kuvitteellinen token-incident

Klo 14.05 UTC SOC havaitsee build-identiteetin lukevan odottamatonta repositorya. Klo 14.08 omistaja varmistaa, ettei mikään hyväksytty job selitä toimintaa. Vielä ei tiedetä, poistuiko lähdekoodia ympäristöstä.

Response-tiimi säilyttää audit-tiedot ja runnerin olennaisen näytön. Valtuutettu omistaja peruu tunnuksen ja pysäyttää epäillyn suoritusreitin. Toimet noudattavat organisaation menettelyä ja huomioivat palveluvaikutuksen.

Vuotaneen tokenin poistaminen tiedostosta ei riitä. Tunnus voi edelleen toimia muualla. Runnerin uudelleenrakennus ei riitä, jos identiteetti on yhä vaarantunut. Selvitä julkaistut artefaktit, jatkopääsy ja muut tunnukset perustellun vaikutusalueen sisältä.

Varmista identiteetti, runner, artefaktien alkuperä ja tarvittavat käyttöoikeusrajat ennen toimituksen palauttamista. Kirjaa avoimet kysymykset. Onnistunut build ei yksin osoita toimitusympäristöä luotettavaksi.

Vie havainnot kehitystyöhön

Muuta varmistetut syyt korjaustehtäviksi ja nimeä vastuuhenkilöt. Tehtäviä voivat olla lyhyempi tunnuksen voimassaolo, rajatummat oikeudet, runnerin eristys, tunnistussäännön muutos tai regressiotesti. Varmenna korjaus ja harjoittele handoff uudelleen.

Taigan audit- ja toimitustiedot voivat tuoda näyttöä dokumentoidun kattavuutensa puitteissa. Liitä ne organisaation response-menettelyyn. Tarkista jaettu vastuu sen sijaan, että olettaisit Taigan käyttöönoton siirtävän SOC- tai SIRT-vastuun. Audit log, jaettu vastuu.