Bir güvenlik olayının en zor kısmı genellikle olayın kendisi bittikten sonra ortaya çıkar: işletmenin ne olduğunu, olayın ne zaman keşfedildiğini, hangi verilerin etkilendiğini, kimlerin etkilendiğini ve belirli kararların neden alındığını açıklaması gerektiğinde.
Birçok KOBİ için bu kayıtlar eksiksiz bir biçimde mevcut değildir. Ayrıntılar sohbet mesajlarına, gelen kutularına, yardım masası taleplerine, ekran görüntülerine ve ekip üyelerinin anılarına dağılmış olabilir. İşletmeler bir olay sırasında bu dağınık kayıtlarla ayakta kalır, ancak denetim otoriteleri, bir sigortacı, bir müşteri veya bir yönetim kurulu üyesi net bir zaman çizelgesi istediğinde bu kayıtlar sorun haline gelir.
Her büyüklükteki işletmenin kapsamlı bir güvenlik olayı günlüğüne ihtiyacı vardır. Bu günlük, ne olduğunu, olayın nasıl ele alındığını ve yol boyunca alınan kararları hangi kanıtların desteklediğini kaydetmek için tek doğruluk kaynağı olmalıdır.
Bir olayı bildirmeniz gerekmediğinde bile kayıt değerlidir. Güvenlik olayı günlüklerinin işletmeniz için neden yararlı olduğunu ve kendi günlüğünüzü nasıl oluşturacağınızı açıklayacağız.
Güvenlik olayı günlükleri neden önemlidir
Olay günlükleri ile olay müdahale planları
Bir güvenlik olayı günlüğü neleri içermelidir
KOBİ’ler için basit bir olay günlüğü şablonu
Bildirim kararları nasıl kaydedilir
Denetim otoritelerinin güvenlik olayı günlüklerinden beklentileri
Kimlik doğrulama bilgileri erişim günlüğü
Güvenlik olayı günlükleri neden önemlidir
Güvenlik olayı günlükleri, bir işletmenin ayrıntıları takip etmeyi en çok kaybetme olasılığı olan anda hesap verebilirlik yaratır. Bir olay sırasında eylemler hızlı gerçekleşir: parolalar sıfırlanır, hesaplar devre dışı bırakılır, BT sağlayıcılarıyla iletişime geçilir, müşteri verileri kontrol edilir ve yönetim bilgilendirilir. Bu adımlar o anda işletmenin tam olarak ihtiyaç duyduğu şeyler olabilir, ancak her eylemin ne zaman gerçekleştiğini, kimin onayladığını ve kararı hangi kanıtların desteklediğini kimse kaydetmezse sonradan açıklamak çok daha zor hale gelir.
Avrupa’da yerleşik işletmeler için bu yalnızca iyi bir uygulama değildir. Hem Birleşik Krallık’ta hem de AB’de Genel Veri Koruma Yönetmeliği (GDPR) uyarınca kişisel veri ihlallerinin değerlendirilmesi gerekir ve bazılarının ilgili denetim otoritesine bildirilmesi zorunludur.
Birleşik Krallık’ta ICO’nun ihlal bildirimi(yeni pencere) rehberi, kuruluşların kişilerin hak ve özgürlüklerine yönelik olası riski değerlendirmesi ve bu riskin olası olması durumunda ICO’yu bilgilendirmesi gerektiğini açıklar. 33. Madde ayrıca veri sorumlularının, ihlalin ayrıntıları, etkileri ve alınan düzeltici faaliyetler dahil olmak üzere kişisel veri ihlallerini belgelemesini şart koşar. Aynı gereklilikler AB GDPR kapsamında da geçerlidir.
Örneğin ICO, her KOBİ’nin kurumsal düzeyde sistemlere sahip olmasını beklemez, ancak uygun kayıtlar bekler. İhlal müdahalesi ve izleme çerçevesi, kuruluşların kişisel veri olaylarının ve ihlallerinin tespit edilmesini, yönetilmesini ve uygun şekilde kaydedilmesini sağlayacak prosedürlere sahip olması gerektiğini belirtir. Bu, bir olay günlüğünün yalnızca ciddi bir ihlal zaten gerçekleştikten sonra oluşturulmaması gerektiği anlamına gelir. Normal müdahale sürecinin bir parçası olmalıdır.
İyi tutulan kayıtlar sigorta taleplerini de destekler. Siber sigortacılar, olayın ne zaman keşfedildiğine, hangi kontrol altına alma adımlarının atıldığına, hangi hesapların etkilendiğine ve işletmenin olay müdahale sürecini izleyip izlemediğine dair kanıt isteyebilir. İyi tutulmuş bir günlük, işletmenin hızlı ve tutarlı hareket ettiğini gösterebilir.
Ayrıca şirketin öğrenmesine yardımcı olur. Anılar ve sözlü kayıtlar güvenilir değildir, ancak olayın yeniden kullanılmış bir parolayla, eksik çok faktörlü kimlik doğrulama (MFA) ile, satıcı erişimiyle veya gecikmiş çıkış işlemleriyle başladığını gösteren bir kayıt, işletmeye düzeltmesi gereken somut bir şey ve zaman içinde güvenliği güçlendirmek için daha net bir yön verir.
Olay günlükleri ile olay müdahale planları
Güvenlik olayı günlüğü ile olay müdahale planı bağlantılıdır, ancak aynı belge değildir.
Bir olay müdahale planı, bir şeyler ters gittiğinde işletmenin ne yapması gerektiğini açıklar. Rolleri, yükseltme yollarını, kontrol altına alma adımlarını, iletişim sorumluluklarını ve kurtarma prosedürlerini atar. Olay günlüğü ise gerçekte ne olduğunu kaydeder. Belirli bir olay için zaman çizelgesi, kanıt izi, karar kaydı ve takip dosyasıdır.
Bu ayrım önemlidir çünkü iyi bir plan bile belgeleme olmadan başarısız olabilir. Bir işletme doğru adımları izleyebilir ancak yine de bunu sonradan kanıtlamakta zorlanabilir. Günlük, pratik soruları yanıtlamayı mümkün kılmalıdır: ne zaman öğrendik, kim harekete geçti, neyi kontrol altına aldık, hangi veriler risk altındaydı, ne karar verdik ve sonrasında ne değişti?
| Olay müdahale planı: İşletmenizin ne yapması gerekir | Güvenlik olayı günlüğü: Gerçekte ne oldu |
| Müdahaleyi kim yönetir BT, hukuk, sigortacı veya düzenleyicilerle kim iletişime geçer Nasıl kontrol altına alınır, kurtarılır ve iletişim kurulur | Olayın ne zaman keşfedildiği Hangi sistemlerin ve verilerin etkilendiği Hangi eylemlerin, kim tarafından ve ne zaman gerçekleştirildiği |
Bir güvenlik olayı günlüğü neleri içermelidir
Kullanışlı bir olay günlüğü, bir işletmenin olayı sonradan yeniden oluşturabilmesi ve müdahale sırasında alınan kararları açıklayabilmesi için yeterince tutarlı olmalıdır.
Keşif tarihi ve saati
İşletmenin olaydan ilk ne zaman haberdar olduğunu, bunu kimin fark ettiğini ve nasıl keşfedildiğini kaydedin. Saat yaklaşıksa yaklaşık olarak işaretleyin. Keşif zamanı önemlidir çünkü GDPR bildirim süreleri ve sigorta gereksinimleri genellikle işletmenin sorundan ne zaman haberdar olduğuna bağlıdır.
Olayın niteliği
Ne olduğunu sade bir dille açıklayın. Bağlam olmadan “güvenlik sorunu” veya “olası ihlal” gibi belirsiz etiketlerden kaçının. Günlük, hangi sistemlerin etkilendiğini ve olayın kimlik doğrulama bilgilerini, e-postayı, dosyaları, müşteri verilerini, ödeme sistemlerini, uç noktaları veya üçüncü taraf erişimini içerip içermediğini açıklamalıdır.
İlgili veriler
Kişisel veriler etkilenmiş olabilirse, ne tür verilerin dahil olduğunu kaydedin: adlar, e-posta adresleri, telefon numaraları, adresler, hesap ayrıntıları, finansal bilgiler, çalışan kayıtları, müşteri iletişimleri, oturum açma kimlik doğrulama bilgileri veya ilgili diğer kategoriler. Kaç kişinin etkilenmiş olabileceğini tahmin edin ve sayının onaylanmış mı yoksa hâlâ inceleniyor mu olduğunu netleştirin.
Olası neden
Bilinen veya şüphelenilen nedeni, soruşturma hâlâ sürüyor olsa bile kaydedin. Yeni ayrıntılar ortaya çıktıkça günlük “neden bilinmiyor” ifadesinden “kimlik avı e-postası kimlik doğrulama bilgilerinin ele geçirilmesine yol açtı” veya “eski yüklenici hesabı aktif kaldı” ifadesine güncellenebilir. Günlük, işletmenin anlayışının zaman içinde nasıl değiştiğini göstermelidir.
Acil kontrol altına alma eylemleri
Hasarı sınırlamak için neler yapıldığını belgeleyin. Buna parola sıfırlamaları, oturum iptali, MFA zorunluluğu, hesap askıya alma, e-posta kutusu kuralı kaldırma, aygıt izolasyonu, satıcı erişiminin kaldırılması, güvenlik duvarı değişiklikleri veya geçici hizmet kapatmaları dahil olabilir. Mümkün olduğunda her eylem için sorumluyu ve zaman damgasını ekleyin.
Bildirim kararları
İşletmenin ilgili denetim otoritesini (Birleşik Krallık’ta ICO veya AB’nin başka bir yerinde ulusal veri koruma otoritesi), etkilenen kişileri, müşterileri, tedarikçileri, sigortacıları, hukuk danışmanlarını veya kolluk kuvvetlerini bilgilendirip bilgilendirmediğini kaydedin. Bildirmeme kararı alındıysa gerekçeyi belgeleyin. Bu açıklama genellikle bildirimin kendisi kadar önemlidir.
Düzeltme adımları ve zaman çizelgesi
Kontrol altına alma, acil olayı ele alır. Düzeltme, aynı sorunun tekrar yaşanma olasılığını azaltır. MFA’yı zorunlu kılma, paylaşılan kimlik doğrulama bilgilerini kaldırma, erişim ilkelerini güncelleme, çıkış işlemlerini iyileştirme, bir yanlış yapılandırmayı düzeltme veya yedeklerin nasıl korunduğunu değiştirme gibi takip eylemlerini kaydedin.
Çıkarılan dersler
İşletmenin ne öğrendiği ve neyin değişeceğiyle bitirin. Bu, suçlama olarak yazılmamalıdır. Zayıf noktayı, gereken iyileştirmeyi ve takibi kimin üstlendiğini belirtmelidir.
KOBİ’ler için basit bir olay günlüğü şablonu
Olayları belgelemek için özel yazılıma gerek yoktur. Erişim kontrol edildiği ve kayıtlar tutarlı tutulduğu sürece bir hesap tablosu, güvenli dahili form, talep sistemi veya paylaşılan kayıt defteri işe yarayabilir.
Etkili bir olay günlüğü şu alanları içermelidir:
- Olay kimliği: Benzersiz bir referans numarası.
- Keşif tarihi ve saati: İşletmenin olaydan haberdar olduğu zaman.
- Bildiren: Çalışan, sağlayıcı, müşteri, tedarikçi, izleme uyarısı veya harici taraf.
- Olay türü: Kimlik avı girişimi, kötü amaçlı yazılım, kimlik doğrulama bilgilerinin ele geçirilmesi, veri kaybı, yetkisiz erişim, fidye yazılımı, tedarikçi olayı, aygıt kaybı, yanlış adrese gönderilen e-posta veya diğer.
- Özet: Ne olduğu, sade bir dille yazılmış.
- Etkilenen sistemler: İlgili uygulamalar, hesaplar, aygıtlar, veritabanları, gelen kutuları veya üçüncü taraf hizmetleri.
- İlgili veriler: Kişisel verilerin etkilenip etkilenmediği, türü ve kaç kişinin etkilenebileceği.
- Muhtemel neden: Biliniyor, şüpheleniliyor veya araştırılıyor.
- Kontrol altına alma eylemleri: Derhal yapılanlar.
- Bildirim kararı: Denetim otoritesi, bireyler, müşteriler, sigortacı veya gerekçesiyle birlikte bildirim yapılmaması.
- Kanıt bağlantıları: Ekran görüntüleri, destek talepleri, günlükler, e-postalar, erişim kayıtları, dışa aktarma dosyaları veya sağlayıcı raporları.
- Düzeltme eylemleri: Kontrol altına alma sonrasında atılan adımlar.
- Sorumlu: Takibi yürütecek kişi.
- Durum: Açık, izleniyor, kontrol altına alındı, çözüldü, kapatıldı.
- Çıkarılan dersler: Neyin değişmesi gerektiği.
Bildirim kararları nasıl kaydedilir
Bildirim kararları, olaydan sonra sıklıkla incelendiğinden güvenlik olayı günlüğünde ayrı bir yer hak eder.
Birleşik Krallık ve AB GDPR düzenlemeleri kapsamında, kuruluşlar kişisel veri ihlali meydana geldiğinde kişilerin hak ve özgürlüklerine yönelik olası riski değerlendirmelidir. Risk olasıysa, denetim otoritesine (Birleşik Krallık’ta ICO(yeni pencere)‘ya, her AB üye devletinde ulusal veri koruma otoritesine) mümkün olan en kısa sürede ve uygulanabilir olduğunda 72 saat içinde bildirimde bulunulmalıdır. Risk yüksekse, etkilenen bireylere de gecikme olmaksızın bildirimde bulunulmalıdır. Eşikler ve süre her iki tarafta da aynıdır; yalnızca otorite değişir.
İyi bir olay günlüğü, işletmenin bu değerlendirmeyi yaptığını göstermelidir. Kişisel verilerin söz konusu olup olmadığını, ne tür bir zararın ortaya çıkabileceğini, hangi korumaların mevcut olduğunu ve işletmenin neden bildirim yapmaya veya yapmamaya karar verdiğini kaydetmelidir.
Örneğin, açığa çıkmış bir yönetici parolasını içeren bir olay, kişisel verilere erişilip erişilmediğini hemen ortaya çıkarmayabilir. Günlük bu belirsizliği yansıtmalıdır. İlk endişeyi, araştırma adımlarını, hesap etkinliği incelemesini ve kanıtlar mevcut olduğunda nihai sonucu kaydedebilir.
Sürecin bu aşamasında, birçok işletme teknik düzeltmeyi organize etmeye odaklanır ve uyumluluk gerekçesini kaydetmeyi unutur. Parolalar sıfırlanır, hesaplar güvenli hale getirilir ve operasyonlar devam eder. Haftalar sonra işletme, olayın neden bildirilebilir olmadığına karar verdiğini açıklayamaz.
Denetim otoritelerinin kayıtlardan bekledikleri
Denetim otoriteleri yalnızca bir ihlalin bildirilip bildirilmediğine bakmaz. Ayrıca işletmenin şunları nasıl yaptığını sorabilirler:
- Olayı tespit etti
- Riski değerlendirdi
- Bildirimin gerekli olup olmadığına karar verdi
- Atılan adımları belgeledi
İyi bir kayıt, olayın hikayesini baştan sona netleştirmelidir. Ne olduğunu, hangi kişisel verilerin söz konusu olduğunu, ne tür bir zararın ortaya çıkabileceğini, işletmenin sorunu kontrol altına almak için ne yaptığını ve ihlali neden bildirdiğini veya bildirmediğini göstermelidir.
Ayrıntı düzeyi, olayın ciddiyetiyle uyumlu olmalıdır. Yanlış adrese gönderilen bir e-posta, fidye yazılımı saldırısıyla aynı kaydı gerektirmez, ancak yine de işletmenin bunu uygun şekilde değerlendirdiğini göstermek için belgelenmelidir.
Bu kayıtlar da güvenli bir şekilde saklanmalıdır. Olay günlükleri, etkilenen bireyler, açığa çıkmış sistemler, çalışan eylemleri, ekran görüntüleri, erişim günlükleri veya düzeltme adımları hakkında hassas ayrıntılar içerebilir. Erişim, ihtiyaç duyan kişilerle sınırlandırılmalı ve saklama süresi şirketin daha geniş veri saklama ilkesiyle uyumlu olmalıdır.
Kimlik doğrulama bilgilerine erişim günlüğü
Birçok olay kimlik doğrulama bilgilerini içerir: yeniden kullanılan bir parola, paylaşılan hesap, ele geçirilmiş gelen kutusu, açığa çıkmış yönetici oturumu, şüpheli MFA istemi veya çıkış işlemleri düzgün yapılmamış bir çalışan tarafından tetiklenebilirler.
Bu nedenle, kimlik doğrulama bilgilerine erişim kayıtları, siber güvenlik olayı dokümantasyonuna doğrudan girdi sağlayabilir. Bir olay paylaşılan bir oturum açmayı veya hassas bir hesabı içeriyorsa, işletmenin kimin erişimi olduğunu, erişimin nasıl paylaşıldığını, izinlerin değişip değişmediğini ve olaydan sonra kimlik doğrulama bilgisinin yenilenip yenilenmediğini bilmesi gerekir.
Proton Pass for Business gibi bir kurumsal parola yöneticisi, ekiplerin kimlik doğrulama bilgilerini şifrelenmiş kasalarda yönetmesine, benzersiz parolalar oluşturmasına, otomatik doldurmayı kullanmasına, kimlik doğrulama bilgilerini güvenli bir şekilde paylaşmasına, geçiş anahtarlarını yönetmesine ve yerleşik iki adımlı doğrulamayı kullanmasına yardımcı olur. Olay dokümantasyonu için en güçlü değer, kimlik doğrulama bilgileri etrafındaki erişim izidir: paylaşılan kasalara/hesaplara kimin erişimi olduğu, erişimin nasıl yönetildiği, kimin kullandığı ve olaydan sonra neyin değiştiği.
BT ekipleri için bir parola yöneticisi, ilkeler, raporlama, günlükler, rol tabanlı erişim denetimi, SCIM sağlama ve SSO entegrasyonu gibi yönetici özellikleri ekler. Bu özellikler, işletmelerin kimlik doğrulama bilgilerine erişimin nasıl kontrol edildiğini göstermesine ve kimlik doğrulama bilgileriyle ilgili bir olay araştırıldığında kanıt sunmasına yardımcı olabilir.
Bir parola yöneticisi olay günlüğünün, hukuki değerlendirmenin, düzenleyici bildirim sürecinin veya olay müdahale planının yerini alamaz. Ancak bu süreçlere katkı sağlayabilecek kimlik doğrulama bilgisi kanıtları sunar.
Bir kurumsal parola yöneticisi ile kimlik doğrulama bilgilerine erişimin eksiksiz denetim izini tutun.
