Bir güvenlik olayının ilk saatlerinde, ne olduğuna dair teknik bir bütünlük oluşturamazsınız. Ekibiniz hâlâ hangi hesabın ele geçirildiğini, hangi verilere erişildiğini, saldırganın ne kadar ilerlediğini veya olayın hâlâ devam edip etmediğini anlamaya çalışıyor olabilir.
Soruşturmanızın yanı sıra, harekete geçme baskısı hemen başlar. Çalışanlar parçalar duyar ve ne yapmaları gerektiğini bilmek ister. Bu arada müşteriler hizmet kesintisi, şüpheli etkinlik veya olağandışı parola sıfırlama istekleri fark edebilir. İş ortakları sistemlerinin veya verilerinin olaya dahil olup olmadığını sorabilir ve yönetimin kimin konuşacağına, neyin onaylanabileceğine ve sessizliğin ne zaman başlı başına bir risk haline geleceğine karar vermesi gerekir.
Güvenlik olayı iletişimi zordur çünkü bir işletme her yanıtı almadan şeffaf olmak, ancak tahmin yürütmeyecek kadar da bilgi sahibi olmak zorundadır. Çok erken gönderilen iletiler kafa karışıklığı yaratabilir, ancak çok geç gönderilirse güveni zedeleyebilir, koruyucu önlemleri yavaşlatabilir ve düzenleyici soruları gündeme getirebilir.
Küçük ve orta ölçekli işletmelerin olay müdahale planını oluşturmuş veya prova etmiş olması pek olası değildir ve bu ek kaosa neden olabilir. Planı olan daha büyük işletmeler için bile teknik adımlar belgelenmiş olabilir: olayı kontrol altına al, erişimi sıfırla, kanıtları koru, sistemleri geri yükle. İletişim ise sonraya bırakılabilir ta ki olay aniden tırmanana ya da değişene kadar.
Bir olaya hazırlanmanın bir parçası, sizden kimin haber alması gerektiğini, neyi bilmeleri gerektiğini, iletiyi kimin onaylayacağını ve soruşturma devam ederken gerçeklerin nasıl açıkça iletileceğini bilmektir.
İletişim planlaması olay müdahalesinin içinde yer alır
Duyuruyla değil, hedef kitleyle başlayın
Dahili olarak nelerin iletileceği
Bir ihlalde müşterilere nasıl bildirim yapılır
Düzenleyici kurumlara ne zaman bildirim yapılır
İletileri ihtiyaç duymadan önce hazırlayın
Proton Pass for Business nasıl yardımcı olabilir
İletişim planlaması olay müdahalesinin içinde yer alır
Olay müdahalesi genellikle teknik bir süreç olarak tanımlanır, ancak gerçek bir olay hızla işlevler arası bir hal alır. BT ekipleri tehdidi kontrol altına alabilir, ancak yönetim, hukuk, müşteri desteği, insan kaynakları, iletişim ve operasyon birimlerinin hepsi neler olduğunu ve ne söyleyebileceklerini bilmek zorundadır.
NCSC’nin bir siber olayda etkili iletişim(yeni pencere) konusundaki rehberi — Birleşik Krallık dışında da geçerli olan genel en iyi uygulamalar — bu noktayı açıkça ortaya koyuyor: kuruluşlar genellikle teknik yanıta öncelik verir ve iletişimi arka plana iter, oysa iletişim kriz sırasında personelin, müşterilerin, paydaşların ve medyanın kuruluşu nasıl algıladığını şekillendirir.
Her olay kamuoyu açıklaması gerektirmez. Ancak işletme, neyin iletileceğine kimin karar vereceğini, dış iletileri kimin onaylayacağını, müşterilerle kimin konuşacağını ve düzenleyici bildirimi kimin yürüteceğini önceden bilmelidir.
Güçlü bir veri ihlali müdahale planının bir iletişim katmanı içermesi gerekir. Bu katman pratik ayrıntıları kapsamalıdır:
- İletişim listeleri
- Taslak şablonlar
- Onay akışları
- Hukuki inceleme
- Müşteri desteği konuşma noktaları
- Düzenleyici bildirim sorumlulukları
- Neyin, ne zaman ve kime gönderildiğinin kayıtları.
Yanıtınız için iki hatlı yapı
Olay müdahalesi iki hat gerektirir: teknik yanıt ve iletişim yanıtı. Birbirlerine paralel ilerler ve olay lideri/yanıt sahibi ikisini de birbirine bağlar.
| Sol hat: Teknik yanıt | Sağ hat: İletişim yanıtı |
| Olayı kontrol altına alın | Dahili ekibi güncelleyin |
| Etkilenen hesapları koruyun | Etkilenen müşterileri veya ortakları bilgilendirin |
| Kanıtları koruyun | Düzenleyici bildirimini değerlendirin |
| Sistemleri geri yükleyin | Gerçekler değişirken iletileri tutarlı tutun |
Bu, yanıtınızı yapılandırmanızı ve ekip üyeleri farklı görevler üstlenirken işbirliğinin devam etmesini sağlar.
Duyuruyla değil, hedef kitleyle başlayın
Güvenlik olayı iletişimi, tek bir ileti herkese hizmet etmeye çalıştığında başarısız olur. Çalışanlar, müşteriler, ortaklar ve düzenleyici kurumlar farklı kararlar vermeleri gerektiğinden farklı düzeylerde ayrıntıya ihtiyaç duyar.
Dahili ekibinizin önce netliğe ihtiyacı var
Her ayrıntıya ihtiyaçları yok — özellikle soruşturma sürerken — ancak neyin onaylandığı, şu anda ne yapılması gerektiği ve yanıtı kimin yönettiği konusunda netliğe ihtiyaçları var. Bu da hangi sistemlerden veya hesaplardan kaçınmaları gerektiğini, hangi eylemin hemen alınacağını ve hangi soruların hâlâ açık olduğunu bilmek anlamına gelir.
Çalışanlar ne yapmamaları gerektiğini de bilmelidir. Örneğin:
- Olayı kamuya açık şekilde tartışmayın
- Onaylı süreç dışında kimlik doğrulama bilgilerini sıfırlamayın
- Müşterilerle doğaçlama açıklamalarla iletişime geçmeyin
- Şüpheli iletileri yönlendirme olmadan iletmeyin.
Müşteriler ve ortaklar nasıl etkilendiklerini bilmek ister
Verilerinin, erişimlerinin, ödemelerinin, hizmetlerinin veya operasyonlarının etkilenip etkilenmediğini bilmek isterler. İyi bir müşteri bildirimi şunları açıklamalıdır:
- Neyin bilindiği
- Hangi tür verilerin söz konusu olabileceği
- İşletmenin ne yaptığı
- Müşterilerin şimdi ne yapması gerektiği, eğer bir şey yapmaları gerekiyorsa
- Güncellemeleri nereden alabilecekleri.
Üslup sade ve doğrudan olmalıdır. Müşterinin adli ayrıntılara da ihtiyacı yoktur, yalnızca kendini korumak için yeterli bilgiye ihtiyacı vardır.
Düzenleyici kurumlar olgusal bir kayda ihtiyaç duyar
İlgili denetim otoritesine (Birleşik Krallık’ta ICO(yeni pencere), her AB üye devletinde ulusal veri koruma otoritesi) yapılan bir GDPR ihlal bildirimi bir pazarlama iletisi ya da müşteri güvencesi notu değildir. Bunun yerine, ne olduğunun, kimin etkilendiğinin ve bu konuda ne yaptığınızın olgusal bir kaydı olması gerekir. Aşağıda düzenleyici kurumları bilgilendirme bölümünde tam olarak nelerin yer alması gerektiğini ele alıyoruz.
Dahili olarak nelerin iletileceği
Olay ekibinde yer almasalar bile çalışanlarınız müdahalenin bir parçasıdır. Kafası karışmış bir ekip yanlışlıkla daha fazla gürültü yaratabilir, yanlış bilgi paylaşabilir veya kontrol altına alma sürecini yavaşlatabilir. Öte yandan, iyi bilgilendirilmiş bir ekip hesapların korunmasına yardımcı olabilir, müşterileri doğru kanala yönlendirebilir ve spekülasyonların büyümesini önleyebilir.
Dahili bir güvenlik olayı duyurusu şunları kapsamalıdır:
- Şu ana kadar nelerin doğrulandığına dair sade bir dille net bir özet
- Hangi sistemlerin, hesapların, ekiplerin veya verilerin potansiyel olarak etkilendiği
- İşletmenin şu anda ne yaptığı
- Çalışanların derhal ne yapması gerektiği
- Dışarıyla kimin iletişim kurmasına izin verildiği
- Güncellemelerin nerede yayınlanacağı
- İlgili şüpheli faaliyetlerin nasıl bildirileceği
Dahil edilmemesi gereken hususlar vardır: bir olay sürerken saldırı vektörleri, kök neden analizi ve belirli güvenlik açıkları genellikle dahili olarak paylaşılmaz ve çoğu zaman sonrasında da paylaşılmaz, çünkü bu ayrıntılar diğer saldırganlara yardımcı olabilir, hukuki risk yaratabilir veya henüz kapatılmamış açıkları ortaya çıkarabilir.
İlk dahili iletinin her soruyu yanıtlaması gerekmez, düzen oluşturması gerekir. Örneğin, çalışanların parolaları yalnızca onaylanmış bir süreç aracılığıyla sıfırlaması, belirli bir sistemi kullanmaktan kaçınması, şüpheli e-postaları saklaması veya müdahale ekibi incelemeyi tamamlayana kadar paylaşılan kimlik doğrulama bilgilerini kullanmayı bırakması gerekebilir.
Mevcut erişim kontrollerinizi parola yönetimi en iyi uygulamaları doğrultusunda değerlendirmek de önemlidir. Bir olay sırasında, güncelliğini yitirmiş veya resmi olmayan kimlik bilgisi paylaşımı, nelerin açığa çıktığını anlamayı zorlaştırabilir.
Proton’un veri ihlali koruması ve işletmeler için veri ihlali önleme rehberleri, katmanlı kontrollerin bir ihlal meydana gelmeden önce maruziyeti nasıl azalttığını açıklar. Güvenli kimlik bilgisi yönetimi bu katmanlardan biridir çünkü işletmenin hangi hesapların var olduğunu, bunlara kimin erişebileceğini ve nelerin hızla değiştirilmesi gerektiğini bilmesine yardımcı olur.
Bir ihlali müşterilere nasıl bildireceğiniz
Müşterilere yapılan bir veri ihlali bildirimi daha zordur çünkü itibar ve hukuki ağırlık taşır. İnsanlar kimlik hırsızlığı, hesap ele geçirme, mali dolandırıcılık veya güvenli bilgilerin açığa çıkması konusunda endişelenebilir. Ayrıca şirketin olayı önleyememiş olmasından dolayı hayal kırıklığına uğrayabilirler.
İyi bir müşteri iletisi endişe verici olmadan dürüst olmalıdır. Teknik jargondan kaçınmalı ancak net olmalıdır. Müşteriler hangi verilerin söz konusu olduğunu, bunun ne gibi bir risk oluşturduğunu ve bundan sonra ne yapmaları gerektiğini anlamalıdır.
Faydalı bir yapı şudur:
- Müşteriler için uygun düzeyde ayrıntıyla ne olduğu
- İşletmenin ne zaman haberdar olduğu
- Hangi bilgilerin veya hizmetlerin etkilenebileceği
- İşletmenin hangi adımları attığı
- Müşterilerin şimdi ne yapması gerektiği
- İşletmenin güncellemeleri nasıl sağlayacağı
- Müşterilerin sorularıyla kiminle iletişime geçebileceği
Soruşturma hâlâ sürüyorsa bu açıklanmalıdır. Doğruluk ve şeffaflık güveni geri kazanmaya yardımcı olur. Etki konusunda açık olmak, birinin saldırıyı tekrarlamasına yardımcı olacak teknik ayrıntıların açıklanmasını gerektirmez.
Ciddi olaylarda müşterilerin pratik talimatlara ihtiyacı olabilir: parola değiştirmek, MFA’yı etkinleştirmek, kimlik avı e-postalarına karşı dikkatli olmak, bankalarıyla iletişime geçmek ve resmi bir kanaldan gelmediği sürece şirketten geldiğini iddia eden iletileri yok saymak. Bildirim bu adımları anlaşılması kolay hale getirmelidir.
Düzenleyici kurumlara ne zaman ve nasıl bildirimde bulunulacağı
Her güvenlik olayının denetim otoritelerine bildirilmesi gerekmez. Birleşik Krallık ve AB GDPR kapsamında bildirilebilir bir ihlal, kişisel veri ihlalinin kişilerin hak ve özgürlükleri için risk oluşturma olasılığına bağlıdır.
ICO’nun kişisel veri ihlali rehberi(yeni pencere), hem Birleşik Krallık hem de AB GDPR için ortak bir gerekliliği yansıtır: kuruluşlar, bildirilmesi gereken bir ihlali gereksiz gecikme olmadan ve ihlalin farkına vardıktan sonra en geç 72 saat içinde bildirmelidir. Geç bildirim için gecikmenin nedenlerinin belirtilmesi gerekir.
Bu 72 saatlik süre, özellikle soruşturma hâlâ tamamlanmamışken baskı yaratabilir. GDPR, kuruluşların ilk 72 saat içinde her ayrıntıya sahip olmayabileceğini kabul eder, bu nedenle gereksiz gecikme olmadan ek güncellemeler sağlandığı sürece bilgiler aşamalı olarak verilebilir.
İlgili denetim otoritesine (Birleşik Krallık’ta ICO veya AB’de ulusal veri koruma otoritesi) yapılan bir bildirim genellikle şunları içermelidir:
- Kişisel veri ihlalinin niteliği
- Etkilenen bireylerin kategorileri ve yaklaşık sayısı
- Etkilenen kişisel veri kayıtlarının kategorileri ve yaklaşık sayısı
- DPO’nun veya başka bir irtibat noktasının adı ve kişi bilgileri
- İhlalin muhtemel sonuçları
- İhlali ele almak için alınan veya önerilen önlemler
ICO ayrıca ihbar etmek(yeni pencere) ve kuruluşları uygun bildirim sürecine yönlendirmek için merkezi bir sayfa sunar.
Etkilenen bireyler için eşik farklıdır. Kişisel veri ihlalinin kişilerin hak ve özgürlükleri için yüksek risk oluşturma olasılığı varsa, kişiler gereksiz gecikme olmadan bilgilendirilmelidir. Bu, küçük bir işletmede bile hukuk, gizlilik ve yönetim ekiplerinin erken dönemde dahil edilmesi gereken bir durumdur.
İletileri ihtiyaç duymadan önce hazırlayın
Bir iletişim süreci tasarlamak için en kötü zaman bir olayın yaşandığı andır. Güncellenmesi ve değiştirilmesi gereken açıklamalar veya yönergeler yayınlamak faydalı olmaz.
Bu nedenle, iletilerinizin yapısını ihtiyaç duymadan önce hazırlamak faydalıdır. Nihai ifadeyi değil, çünkü her olay farklı olacaktır, yapısını: iletiyi kimin onaylaması gerektiği, hangi ayrıntıların dahil edilmesi gerektiği, güncellemelerin nerede kaydedileceği ve her hedef kitle için kimin sorumlu olduğu.
İlk saatin daha az kaotik geçmesi için basit bir iletişim seti yeterlidir. Şunları içerebilir:
- Dahili olay duyuru şablonu
- Müşteri bildirim şablonu
- İş ortağı veya tedarikçi güncelleme şablonu
- Müşteri desteği konuşma noktaları
- Denetim kurumu bildirim kontrol listesi
- Onaylı sözcü listesi
- Hukuk, BT, gizlilik, yönetim ve iletişim için eskalasyon kişileri
- Tüm güncellemelerin ve kararların kaydedileceği bir yer
Hazırlık, hız ve doğruluğun birlikte önemli olduğu durumlarda ekibe güvenli bir başlangıç noktası sağlar. Hazır bir şablon, olayın gerçeklerine daha fazla dikkat ayırmanızı sağlar: ne oldu, kimler etkilendi, şimdiye kadar neler yapıldı ve insanların bundan sonra ne yapması gerekiyor.
Proton Pass for Business nasıl yardımcı olabilir
Güvenlik olayı iletişimi gerçeklere dayanır. Bir işletme bir olay öncesinde erişimi ne kadar net yönetirse, ne olduğunu, nelerin etkilenebileceğini ve nelerin değiştirildiğini açıklamak o kadar kolay olur.
Proton Pass for Business gibi bir iş parola yöneticisi, ekiplerin kimlik doğrulama bilgileriyle ilgili maruziyeti azaltmasına yardımcı olur. Çalışanlar güçlü parolalar oluşturabilir, bunları şifrelenmiş parola kasalarında saklayabilir, otomatik doldurmayı kullanabilir, kimlik doğrulama bilgilerini güvenli şekilde paylaşabilir, geçiş anahtarlarını yönetebilir ve yerleşik iki adımlı doğrulamayı kullanabilir. Yöneticiler parola ilkeleri uygulayabilir, etkinlik günlüklerini inceleyebilir, role dayalı kontrollerle erişimi yönetebilir ve SCIM ve SSO entegrasyonları aracılığıyla sağlama desteği verebilir.
Bir olay sırasında bu özellikler işletmelerin daha güvenle hareket etmesine yardımcı olabilir. Bir çalışan hesabı ele geçirilirse, yöneticiler erişimi inceleyebilir, döndürülmesi gerekebilecek paylaşılan kimlik doğrulama bilgilerini belirleyebilir, daha güçlü kimlik doğrulamayı zorunlu kılabilir ve sohbet veya hesap tabloları üzerinden kopyalanan parolalara bağımlılığı azaltabilir.
Bir ihlal yaşanmadan önce bir iş parola yöneticisi ile yanıt vermeye hazır olun.
