Delivery को SOC और SIRT से जोड़ें

नामों के पीछे के काम तय करें

Security operations center, या SOC, आम तौर पर security signals monitor करता है, alerts जाँचता है और suspected incidents escalate करता है। Security incident response team, या SIRT, security incidents के response का समन्वय करती है। CSIRT इस response function का दूसरा प्रचलित नाम है।

संगठन ये काम अलग-अलग तरीके से बाँटते हैं। वही लोग दोनों काम कर सकते हैं। External provider service का कुछ हिस्सा दे सकता है। Acronym से coverage या अधिकार का अनुमान न लगाएँ। Monitoring hours, escalation प्रक्रिया, निर्णय के अधिकार और response commitments दर्ज करें।

FIRST का CSIRT framework response team की संभावित services बताता है। NIST incident response को व्यापक cybersecurity risk management से जोड़ता है। जिम्मेदारियाँ और interfaces तय करने के लिए ये references इस्तेमाल करें। FIRST framework, NIST incident response।

Detection के दायरे में AI development शामिल करें

Software delivery system में identities, repositories, runners, registries, integrations और deployment credentials होते हैं। Agents tool calls और model-provider data flows जोड़ते हैं। Security design में ये सीमाएँ शामिल करें।

तय detections में मदद करने वाले events चुनें। उदाहरण हैं अप्रत्याशित repository access, privilege changes, असामान्य artifact publication और अस्वीकृत identity से deployment। जहाँ उपलब्ध हों, timestamps, actor identities, resource identifiers और immutable artifact digests से records जोड़ें।

इन records की रक्षा करें। Audit access, retention, clocks की गुणवत्ता और collection failures जाँच को प्रभावित करते हैं। Development run log और cloud audit log अलग प्रश्नों के उत्तर देते हैं। कोई भी अपने आप पूरा incident record नहीं है।

Incident से पहले handoff तैयार करें

तय करें कि token कौन revoke कर सकता है, runner कौन isolate कर सकता है, deployment कौन रोक सकता है या service कौन restore कर सकता है। Service owners संचालन का असर समझाते हैं। Security responders जाँच और containment का समन्वय करते हैं। संबंधित privacy, legal और business जिम्मेदार लोग वास्तविक स्थिति में notification के दायित्व जाँचते हैं।

Notification की जरूरत incident और लागू दायित्वों पर निर्भर है। उचित निर्णयकर्ता को जल्दी शामिल करें। AI summary को वह निर्णय न लेने दें या तय escalation में देरी न करने दें।

काल्पनिक token incident पर काम करें

14:05 UTC पर SOC को build identity एक अप्रत्याशित repository पढ़ती दिखती है। 14:08 पर repository owner पुष्टि करता है कि कोई approved job उस गतिविधि को नहीं समझाती। Source code environment से बाहर गया या नहीं, यह अभी अज्ञात है।

Response team audit records और संबंधित runner evidence सुरक्षित रखती है। अधिकृत जिम्मेदार व्यक्ति प्रभावित credential revoke करता है और संदिग्ध execution path रोकता है। ये कार्रवाइयाँ संगठन की response प्रक्रिया और service पर असर के अनुसार होती हैं।

File से leaked token हटाना पर्याप्त नहीं। Credential कहीं और valid रह सकता है। Identity compromised रहे तो runner rebuild करना भी पर्याप्त नहीं। संभावित दायरे के issued artifacts, downstream access और दूसरे credentials जाँचें।

Delivery बहाल करने से पहले identity, runner, artifact provenance और जरूरी access boundaries जाँचें। जो अज्ञात है वह दर्ज करें। अकेला सफल build यह सिद्ध नहीं करता कि delivery environment भरोसेमंद है।

Findings को engineering में लौटाएँ

पुष्टि किए कारणों को जिम्मेदारी वाले काम में बदलें: credentials की छोटी अवधि, सीमित access, runner isolation, detection में बदलाव या regression test। सुधार जाँचें और handoff का फिर अभ्यास करें।

Taiga के audit और delivery records अपने documented दायरे में प्रमाण दे सकते हैं। उन्हें संगठन की response प्रक्रिया से जोड़ें। यह मानने के बजाय कि Taiga enable करने से SOC या SIRT की जिम्मेदारी चली जाती है, shared-responsibility सीमा जाँचें। Audit log, Shared responsibility।