Teslimatı SOC ve SIRT'ye bağlayın
TamamlandıGüvenlik izlemesini, olay devrini, kanıt korumayı ve kurtarma sorumluluklarını tanımlayın. Güvenlik müdahalesini yazılım yaşam döngüsüne bağlı tutun.
Yayımlayan TaigaNasıl yazıyoruz?
Neler öğreneceksiniz?
- SOC izlemesini SIRT olay koordinasyonundan ayırt edin.
- Yararlı bir güvenlik olayı devir kaydı hazırlayın.
- Sınırlamayı, kurtarmayı ve düzeltici mühendisliği birbirine bağlayın.
İsimlerin arkasındaki işlevleri tanımlayın
Güvenlik operasyon merkezi, yani SOC, genellikle güvenlik sinyallerini izler, uyarıları araştırır ve şüpheli olayları ilgili müdahale birimine iletir. Güvenlik olayı müdahale ekibi, yani SIRT, güvenlik olaylarına müdahaleyi koordine eder. CSIRT, bu müdahale işlevi için kullanılan başka bir yaygın addır.
Kuruluşlar bu işlevleri farklı biçimlerde böler. Aynı kişiler her ikisini yapabilir. Dış sağlayıcı hizmetin bir bölümünü sunabilir. Kısaltmadan kapsam veya yetki çıkarmayın. İzleme saatlerini, konuyu üst sorumlulara iletme yollarını, karar haklarını ve müdahale taahhütlerini kaydedin.
FIRST CSIRT çerçevesi, müdahale ekibinin sağlayabileceği hizmetleri açıklar. NIST, olay müdahalesini daha geniş siber güvenlik risk yönetimine bağlar. Sorumluluklarınızı ve arayüzlerinizi tanımlamak için bu kaynakları kullanın. FIRST çerçevesi, NIST olay müdahalesi.
Yapay zekâ geliştirmesini tespit kapsamına dahil edin
Yazılım teslimat sisteminde kimlikler, kod depoları, runner’lar, kayıt depoları, entegrasyonlar ve dağıtım erişim bilgileri vardır. Ajanlar, araç çağrıları ve model sağlayıcısına veri akışları ekler. Bu sınırları güvenlik tasarımına dahil edin.
Tanımlı tespitleri destekleyen olaylar seçin. Beklenmeyen kod deposu erişimi, ayrıcalık değişiklikleri, olağan dışı artefakt yayımlama ve onaylanmamış kimlikten dağıtım buna örnektir. Kayıtları zaman damgaları, işlemi yapan kimlikler, kaynak tanımlayıcıları ve mevcutsa değişmez artefakt özet değerleriyle ilişkilendirin.
Bu kayıtları koruyun. Denetim erişimi, saklama, saat doğruluğu ve veri toplama hataları araştırmayı etkiler. Geliştirme çalıştırma günlüğü ile bulut denetim günlüğü farklı soruları yanıtlar. Hiçbiri otomatik olarak eksiksiz olay kaydı değildir.
Olaydan önce devir hazırlayın
| Devir alanı | Gerekli bilgi |
|---|---|
| Gözlem | Ne oldu, ne zaman ve hangi sistemde? |
| Kesinlik | Doğrulanmış gerçek, çalışma hipotezi veya çözülmemiş soru |
| Kapsam | Kimlikler, kod depoları, ortamlar ve etkilenmiş olabilecek veriler |
| Kanıt | Gizli bilgileri açığa çıkarmadan, korunan konumlar ve toplama ayrıntıları |
| İşlemler | Ne değişti, kim yetki verdi ve gözlenen sonuç neydi? |
| Karar | Adı belirtilmiş müdahale sorumlusu, sonraki işlem ve sonraki güncelleme saati |
Token’ı kimin iptal edebileceğini, runner’ı kimin yalıtabileceğini, dağıtımı kimin duraklatabileceğini veya hizmeti kimin geri yükleyebileceğini tanımlayın. Hizmet sorumluları işletim sonuçlarını açıklar. Güvenlik müdahale görevlileri araştırmayı ve sınırlamayı koordine eder. İlgili gizlilik, hukuk ve iş birimi sorumluları, gerçek durum için bildirim yükümlülüklerini değerlendirir.
Bildirim gereksinimleri olaya ve uygulanabilir yükümlülüklere bağlıdır. Uygun karar sorumlusunu erken dahil edin. Yapay zekâ özetinin bu kararı vermesine veya yerleşik iletim yolunu geciktirmesine izin vermeyin.
Kurgusal bir token olayını adım adım ele alın
14:05 UTC’de SOC, derleme kimliğinin beklenmeyen bir kod deposunu okuduğunu tespit eder. 14:08’de kod deposu sorumlusu, faaliyeti açıklayan onaylı iş olmadığını doğrular. Kaynak kodunun ortam dışına çıkıp çıkmadığı hâlâ bilinmemektedir.
Müdahale ekibi, denetim kayıtlarını ve ilgili runner kanıtını korur. Yetkili sorumlu, etkilenen erişim bilgisini iptal eder ve şüpheli yürütme yolunu durdurur. Bu işlemler kuruluşun müdahale prosedürünü izler ve hizmet etkisini hesaba katar.
Sızan token’ı dosyadan silmek yeterli değildir. Erişim bilgisi başka yerde geçerli kalabilir. Kimlik hâlâ ele geçirilmiş durumdaysa runner’ı yeniden oluşturmak da yeterli değildir. Makul kapsam içinde yayımlanan artefaktları, sonraki sistemlere erişimi ve diğer erişim bilgilerini araştırın.
Teslimatı yeniden başlatmadan önce kimliği, runner’ı, artefaktın kökenini ve gereken erişim sınırlarını doğrulayın. Hâlâ bilinmeyenleri kaydedin. Başarılı derleme tek başına teslimat ortamının güvenilir olduğunu ortaya koymaz.
Bulguları mühendisliğe geri taşıyın
Doğrulanmış nedenleri sorumlusu belirli işe dönüştürün: daha kısa erişim bilgisi ömrü, daha dar erişim, runner yalıtımı, tespit değişiklikleri veya regresyon testi. Düzeltmeyi doğrulayın ve devir sürecini yeniden uygulayın.
Taiga’nın denetim ve teslimat kayıtları, belgelenmiş kapsamları içinde kanıt sağlayabilir. Bunları kuruluşun müdahale sürecine entegre edin. Taiga’yı etkinleştirmenin SOC veya SIRT sorumluluğunu devrettiğini varsaymak yerine, ortak sorumluluk sınırını kontrol edin. Audit log, ortak sorumluluk.
Alıştırmayı yapın
Bu dersteki kurgusal token olayını kullanın. Gerçekleri, belirsizlikleri, etkilenen kimlikleri, korunan kanıtı, sınırlama seçeneklerini ve karar sorumlularını içeren bir devir kaydı yazın. Token değerini eklemeyin.
Çalışma sayfasını indir (Markdown)Anladığınızı kontrol edin
Kaynaklar ve ek okumalar
- NIST: Incident Response Recommendations, SP 800-61 Rev. 3 ↗
- FIRST: CSIRT Services Framework ↗
- Taiga: Shared responsibility ↗
- Taiga docs: Audit log ↗
Taiga'dan ilgili okumalar
Bu seçimi kaldırmak, bu tarayıcıda kaydedilmiş tüm ilerlemeyi siler.
İlerleme bu tarayıcıda kalır. Hesap ve takip yok.