Twitter Olayından Çıkartılabilecek Dersler

Olayın özeti: Twitter bazı kullanıcı parolalarının açık haliyle loglara yazıldığını tespit etmiş. 

Olayın magazin boyutu: “Twitter bile hackleniyorsa sizin bu yeni nesil firewall’a ihtiyacınız var” 🙂

Olayın basın yansımaları:
http://www.iha.com.tr/istanbul-haberleri/8-karakterden-kisa-parolanin-kirilmasi-icin-2-saat-yeterli-istanbul-2004787/

Olaydan çıkartılabilecek dersler:

Açığı Twitter kendisi tespit etmiş

Twitter kendi güvenlik seviyesini düzenli olarak gözden geçiriyor. Her ölçekti kuruluşun düzenli olarak zafiyet taraması yapması gerektiği yıllardır ortada zaten ancak bu olaydaki açık bir zafiyet tarama yazılımı tarafından tespit edilemezdi. Bu açık, içeride kullandıkları sunucuların loglarının incelenmesi sırasında tespit edilmiş, dolayısıyla ancak bir analistin gözle yapacağı inceleme sonucunda ortaya çıkabilirdi. Zafiyet taramasının, gerçek güvenlik seviyemizi anlamak için, tek başına yeterli olmadığı da bir kez daha anlaşılmıştır. Güvenlik seviyemizi anlamak için sadece sistemler üzerinde tespit edilebilecek zafiyetleri değil, güvenlik mimarimizi ve uygulamalarımızı da gözden geçirmek lazım. 

Logların önemi

Loglar sadece saldırı tespiti için incelenmemeli, bu olayda olduğu gibi hassas verilerin, biz farkında olmadan, kayıt altına alınıp alınmadığını tespit etmek için de gözden geçirilmelidir. Güvenlik analizi hizmetleri sırasında TC kimlik no, telefon numarası hatta parolaların loglandığı örnekler gördük daha önce. Bu nedenle eleştirel bir gözle loglarınızı, özellikle kendi geliştirdiğiniz uygulamalar varsa, gözden geçirip tutulmaması gereken bir verinin tutulmadığından emin olmakta fayda var.

DLP projesi gözüyle

DLP projeleri zordur, meşakatlidir ve evet, DLP çözümleri atlatılabilir. Bunun yanında, özellikle Kişisel Verilerin Korunması Kanunu kapsamında, belli bir ölçeğin üzerindeki firmalar için gerekli hale gelmiş çözümlerdir. DLP (Data Loss Protection – Veri Kaybı Önleme sistemlerine verilen isim) personelin yanlışlıkla veri sızdırmasını önlemeyi amaçlar ve bu çerçevede başarı sağlayabilir ancak veriyi sızdırmayı hedefleyen bir saldırgan veya zararlı yazılımı da engellemeleri pek mümkün değildir. Kuruluştan veri sızdırılmasını önlemek üzere bir progje yapıyorsanız logları da bu kapsamda değerlendirmekte fayda var. 

Gerçek bir örnek

Benim de başıma gelir arada…  Bir giriş ekranı olur ve ben ezbere kullanıcı adımı yazıp TAB tuşuna basıp parolamı yazıp ENTER tuşuna basarım. Bazı sitelerde TAB tuşu beni bir alt kutucuğa götürmek yerine “beni hatırla” kutucuğuna götürür ve ben de parolamı bakmadan yazdığım için sonuçta; kullanıcıadımveparolamınbirlikteyazıldığı ve parola kısmını boş bıraktığım bir kullanıcı ile giriş denemesinde bulunmuş olurum. (Bkz. Şekil 1-A)

Genellikle başarısız giriş denemelerinde sadece denenen kullanıcı adı loglara yazılır. Bunun nedeni parolasını yanlış yazmış birinin parolasının loglara bakılarak tahmin edilmesini engellemektir. Örneğin: parolası “Parola1!” olan kullanıcının “Parola11” ile yaptığı başarısız giriş denmesi loguna bakan birinin “evet, SHIFT tuşuna basamış, demek ki parolası Parola1!” demesini engellemek. Aşağıda görüldüğü gibi parola yanlış yere yazılırsa olduğu gibi loglanabilir. Loglar üzerinde çalışırken kullanıcı girişlerine ilişkin logları bu nedenle hassas veri içerebilecekmiş gibi ele almakta, gerekiyorsa şifreli olarak saklamakta her zaman fayda vardır.