Türkiye’de belediyeler ve üniversiteler gibi kamu kurumlarındaki siber güvenlik uzmanı açığı, bilgisayar sistemlerindeki zafiyetlerin uzun süre fark edilmemesine yol açıyor. Dışardan zafiyeti bulanlara ise sembolik hediyeler verilerek durum geçiştiriliyor.
Zafiyetler de siber tehdit aktörlerinin kolay saldırı düzenlemesine ve büyük veri ihlallerine sebep oluyor.
Sakarya Akyazı Belediyesi de bu durumun yaşandığı kamu kurumlarından biri.
Bize e-posta yoluyla ulaşan lise öğrencisi Tunahan Yanıkoğlu durumu Siber Bülten’e şöyle aktardı:
“Belediyenin internet sitesinde aralık ayının ilk günlerinde bir arkadaşımla zafiyet taramaları yaptık ve 1 adet SQL Injection, 1 adet doğrulanmış XSS ve 83 adet doğrulanmamış XSS zafiyeti tespit ettik.
SQL Injection zafiyeti, istismar edildiğinde saldırganların tüm veri tabanına erişmesine olanak tanıyor.
Konuyu belediyeye e-posta yoluyla bildirdik ama aradan günler geçmesine rağmen yetkililer geri bildirimde bulunmadı. Ardından belediyenin çözüm hattını arayıp güvenlik açığı hakkında bilgi verdim.
Yetkililer konuyla ilgileneceklerini söyledi ama yine herhangi bir geri dönüş alamadık. Geçtiğimiz haftalarda belediyeden bir yetkiliye telefon ettim ve konu hakkında gelişme olup olmadığını sordum.
BİLGİ İŞLEM: “ÖNEMLİ BİR ŞEY ŞEY YOK SORUNU ÇÖZDÜK”
“Konuyla ilgilenmesi için bilgi işlem müdürlüğünün kurulduğunu ve bilgi işlem ekibinin ‘önemli bir şey olmadığını ve sorunu çözdüklerini’ söylediklerini bana iletti.
Veri tabanında 350’den fazla vatandaşın bütün kişisel verileri yer alıyordu ve bunun göz ardı edilmemesi gerekiyordu. Güvenlik açığının halen mevcut olduğunu kendilerine ilettiğimde bizi belediye binasına çağırdı.
Belediye binasına gittiğimizde bilgi işlem müdürü bizi ofislerine götürdü. Ofise girdiğimizde bilgi işlem personeli film izliyordu.Bilgi İşlem ofisinde biraz tartıştıktan sonra başkan yardımcısının ofisine geçtik. Başkan yardımcısına durumu açıkladık ve bilgi işlem ekibine açığı derhal kapatmalarını ve ardından beni arayıp kontrol ettirmeleri talimatını verdi.
BELEDİYENİN BUG BOUNTY ÖDÜLÜ: KAHVE FİNCANI SETİ
Birkaç gün sonra bilgi işlem müdürü gerekli kontrolleri sağlamam için beni aradı ve kontrolleri yaptıktan sonra açığın halen kapanmadığını farkettim. Dosya yapısı aşırı kötüydü ve zaten siteyi tamamen yenileme planları vardı.
Ben de bu sebeple SQL İnjection zafiyetini barındıran dosyayı silmelerinin en iyi çözüm olacağını söyledim. Birkaç kez daha açığı kapatmayı denediler fakat bir işe yaramadı.
En sonunda önerdiğim şekilde dosyayı sildiler ve açık kapandı. Ama XSS açıkları hala saldırganların istismarına açık.. Bize ödül olarak ne verdiler dersiniz? Kahve fincanı seti…
Veeam’in Ürün Stratejisinden Sorumu Kıdemli Direktör Rick Vanover
Siber güvenlik sektöründeki önemli firmalardan Veeam’in Ürün Stratejisinden Sorumu Kıdemli Direktörü Rick Vanover ve Kurumsal Stratejiden Sorumlu Başkan Yardımcısı Dave Russell Siber Bülten için hızla dönüşen siber güvenlik kavramı ve felaket kurtarma planlarında ortaya çıkan açıklara ilişkin bir makale kaleme aldı:
Pandeminin başlangıcından bu yana, BT birimleri siber güvenlik alanındaki kolektif odaklanmalarını artırdılar. Bilgisayar korsanlarının veri çalmasını ve rekor sayıda fidye yazılımı saldırısı başlatmasını önlemek için koruyucu önlemleri ikiye katladılar. Bu süreçte birçok ekip, bir siber saldırı kadar zarar verebilecek diğer tehditleri göz ardı etmiş olabilir.
Bunlardan biri olan insan hatası, veri kaybının en yaygın nedeni olmaya devam ediyor. Araştırmalar, şirketlerin kötü niyetli olaylarla kıyaslandığında yanlışlıkla silme ve üzerine yazma yoluyla veri miktarının yaklaşık beş katını kaybettiğini gösteriyor.
ÇALIŞAN EĞİTİMİNE YATIRIM YAPMAK GEREKİYOR
Yanlışlıkla gerçekleşen yapılandırma, uygulama ve kullanıcı yönetimi hataları da sistemleri çökertebilir, verileri silebilir ve maliyetli kesintilere neden olabilir. Bunların yanı sıra, doğal afetler de gideren büyüyen bir sorun. Örneğin son iki yılda rekor sayıda tropik fırtına ABD’yi vurdu ve uzmanlar iklim değişikliğinin giderek daha fazla hasara yol açmasını bekliyor. Yalnızca son Ida Kasırgası’nın finansal etkileri işletmelere, tüketicilere ve topluluklara maliyeti 100 milyon dolara yaklaşıyor.
Siber saldırılara daha fazla önem verilse kuruluşların günümüzün başka afetleri de kapsayan gerçek tehdit ortamını karşılamak için Felaket Kurtarma (DR) stratejilerini yeniden önceliklendirmeleri gerekiyor. Çalışan eğitimine yatırım yapmaları, DR sürecindeki işlevleri otomatikleştirmeleri ve DR planlarının ve süreçlerinin iş sürekliliğini tehdit eden ani, öngörülemeyen olaylarla başa çıkmaya hazır olduklarından emin olmaları gerekiyor.
Bunları yapmayan işletmelerin, operasyonları zarar göreceği bir gerçek. Yapılan araştırmaya göre, büyük bir veri kaybı yaşayan şirketlerin %94’ü hayatta kalamıyor; %43’ü asla yeniden açılmıyor ve %51’i iki yıl içinde kapanıyor.
Veeam Kurumsal Stratejiden Sorumlu Başkan Yardımcısı Dave Russell
Veeam 2021 Veri Koruma Raporu’na göre, işini sürdürenler gelir ve üretkenlik kaybından saatte 84.650 dolarlık zarara uğruyor. İşin aslı maddi zarardan fazlasını kaybediyorlar:
– Müşteri güveninin zedelenmesi ve markanın zarar görmesi dahil olmak üzere dış etkiler
– Çalışanların motivasyonu ve kaynakların saptırılması gibi dahili etkiler
– Şirket değerlemesi üzerinde olumsuz bir etki bırakabilecek davalar, regülasyonlar gibi diğer faktörler
Başlamak için en iyi yer, çalışan eğitimidir. Pandemi sırasında çalışanlar için yeni bir siber güvenlik eğitim turu uygulamayan bir işletme, bunu birincil önceliği haline getirmeli.
Çalışan eğitimi, takip eden olay bildirim prosedürlerinden
güçlü parolalar seçmeye, kimlik avı dolandırıcılıklarından kaçınmaya kadar olağan örnek uygulamaları içermelidir.
Ancak eğitim, BT operatörlerini de kapsamalıdır. Bir dizi örnek uygulama izlenerek yapılandırma hataları azaltılabilir. Bunlar, tek bir yapılandırma kaynağı oluşturmayı, yapılandırma değişikliklerini izlemenin kolay bir yolunu sağlamayı ve tüm hizmetler için DNS Hizmet Adlarını kullanmayı içerir. Akla gelebilecek her koşulu test etmenin bir yolu olmadığından uygulama hataları olacaktır. Ancak test prosedürlerinin düzenli olarak gözden geçirilmesi ve güncellenmesi, performansın
artmasını ve günlük uygulamalarda dikkatsiz hataların azaltılmasını sağlar.
Otomasyon da pandemiden çıkarken en önemli öncelik olmalıdır. Günlük süreçlerdeki insan hatalarını azaltmakla kalmaz, aynı zamanda çalışanlara daha stratejik, daha üst düzey görevleri yerine getirmeleri için daha fazla zaman sağlar. Bu, ofistekiler için olduğu kadar BT için de geçerlidir.
Kuruluşlar, son iki yılda otomasyon teknolojilerine yatırımlarını artırdı. Üretkenliği artırmak ve daha yüksek güvenlik seviyeleri sağlamak için de bunu yapmaya devam etmeliler. Özellikle felaket kurtarma sürecini otomatikleştirmek zamandan tasarruf sağlayabilir ve genel müdahaleyi iyileştirebilir.
Günümüzün uygulamaları ve veri kümeleri, her zamankinden daha büyük ve daha karmaşık, dağıtılmış ve birbirine bağımlı. Bu, tek bir uygulamanın bile başarılı bir şekilde kurtarılmasını – tüm ortamlardan bahsetmiyorum bile – inanılmaz derecede zorlaştırır. Aynı zamanda da kurtarma süreçlerinin düzenlenmesini vazgeçilmez bir araç haline getirir.
Kuruluşların, yüksek riskler göz önüne alındığında, hızlı bir şekilde uygulamaya hazır olduklarından emin olmak için DR planlarına ve prosedürlerine daha yakından bakmaları için iyi bir zaman. İşte bazı ipuçları:
Ayrıntıları kontrol edin: Bir şirketin belirli iş ihtiyaçları için güncel ve doğrulanmış bir plana sahip olması çok önemlidir. Pandemi başladığından beri ihtiyaçlar muhtemelen değişti. Planınızı bir yıldan fazla bir süredir tekrar gözden geçirmediyseniz, bu bir öncelik olmalıdır.
Dokümanlarınızı gözden geçirin: Sistem geri yüklemeleri sırasında takip edilmesi kolay, kapsamlı dokümanlara sahip olmak zaman kazandırabilir ve stresi önleyebilir. Bunları oluşturmak yoğun zamanınızı alır ve sürekli olarak gözden geçirilmesi gerekir. Özellikle belgeleri kullanmak zorunda kalacak kişilerin bu belgelerin sık sık tozlarını alması işleri kolaylaştıracaktır.
Kimlik erişimlerini güncelleyin: Hizmet tüketimindeki değişikliklerle birlikte, kimlik doğrulamada boşlukların
oluşması olağandır. Sistemlerin kapalı olduğu, zamana duyarlı bu dönemde kritik sistem işlevlerini
gerçekleştirmek için doğru kişilerin yetkilendirildiğinden emin olun.
DR/dayanıklılık planlarını gözden geçirin: Harici cihazların artan kullanımıyla birlikte, kuruluşlar planlarını iş
gücünden uç noktaya kadar uçtan uca korumayı dahil edecek şekilde rasyonalize etmelidir.
Hızlandırma testi: Temel metriklerinizi karşıladığınızdan emin olmak için her uygulamayı ayrı ayrı test edin –
özellikle Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedeflerini(RPO).
Kısaca bağlamamız gerekirse; siber saldırılar artıyor ve kuruluşların dikkatini bu alana kaydırması önemli ancak felaketler farklı şekillerde de olabilir.
BT departmanları, işletmeleri korumayı sağlamak için kurtarma planlarının ve prosedürlerinin yürürlükte olduğundan emin olmalıdır.
Son yıllarda hayatımıza girmiş bir kavram olan Key Block konusunu Cyberwise Siber Güvenlik Firmasının Veri Güvenliği Takım Lideri Onay Küçükesin Siber Bülten için ayrıntılı olarak anlattı:
Key Block Diğer adı ile ANSI TR-31, 2014 yılında yayımlanan bültenle 2018 yılı itibariyle kullanıma geçmesi planlanmış bir şifreleme formatı. Ancak altyapı hazırlıklarının uzun sürmesi ve firmalar arası uyumun kolay sağlanabilmesi için 2019 yılından itibaren 3 faza ayrılmış süreçle kullanıma geçilmesine karar verildi.
Bu sürecin Haziran 2021’de başlayacak ikinci fazı Zone’lar arası keyblock formatı uygulaması da Kovid-19 nedeni ile Ocak 2023 tarihine ertelendi.
Şu anda kullanılan format olan ANSI X9.17, basit olarak anahtarın, belirli algoritmalarla şifrelenmiş halinin saklanması temeline dayanıyor.
3DES bir anahtarı örnek alırsak, 24 Byte olan bu anahtarın X9.17 formatında şifrelenmiş hali de yine 24 Byte bir veri olarak görünüyor. Aşağıdaki tabloda görüldüğü gibi bu formatta anahtarın şifreli hali, anahtarın kullanım amacıyla da ilgili tipi gibi özelliklerini belirten bir alan bulunmuyor.
Anahtarın ne amaçla kullanılacağı, anahtarı oluştururken girilen bilgilere bağlı oluyor ve bu bilgiler kaybedilirse süreçle ilgili sorunlara neden olabiliyor. Ek olarak belirli bir kontrol mekanizması olmadığı için, anahtar zafiyet oluşturabilecek farklı amaçlarla kullanılabiliyor ve güvenlik riski yaratıyor.
Keyblock formatı işte tüm bu sorunlara çözüm olacak yeni özellikler getiriyor. Bu özellikleri inceleyebilmek için örnek bir Anahtar üzerinden yola çıkarabiliriz.
X9.17 formatındaki anahtar ile aynı boyutta yani 24 Byte olan bu anahtarın keyblock formatındaki gösterilişi çok daha uzun. Bu şekilde uzun olmasının sebebi ise keyblock formatına eklenen özellikleri anahtar ile birlikte taşıyan ek bölümlerinin olması. Anahtarımızı bu bölümlere ayırarak ilerlersek, karşımıza aşağıdaki örnekte görüldüğü gibi 5 ana bölüm çıkıyor.
Keyblock’un başındaki S harfi; anahtarın Keyblock formatında olduğu gösterir ve sabittir.
En önemli ana bölüm olan Keyblock Header; anahtar ile birlikte taşınacak özelliklerini barındırır. Birazdan bu bölüm ile ilgili detaylı bir inceleme yapacağız.
Optional Header; anahtar ile birlikte taşınmasını istediğimiz, önceden belirlenmiş ya da bizim seçeceğimiz bilgiler barındırır.
Key Status alanı; anahtarın hangi durumda olduğunu gösterir. Bunlar Live, Pending, Revoked, Expired ve Test olabilir ve uygulama tarafından mevcut anahtar üzerinde değiştirilebilirler. Bu alandaki bilgilere göre HSM anahtarlarının kullanılıp kullanmaması gerektiğine karar verir. Start Date ve End Date; anahtarın kullanılabilir olacağı tarih ve saat aralığını belirlememizi sağlar. Text alanı ise okunabilir karakterler ile yazacağımız bilgilerin anahtar ile birlikte taşınması için kullanılabilir. Örneğimizde anahtarın hangi amaçla kullanıldığını belirtmek için bir değer girildiği görülebilir. Bir sonraki alan, anahtarın gerçek uzunluğu ve anahtarın şifrelenmiş halinden oluşur. Bu değer tüm keyblock’a özgü olacağından ayrıca alınıp kullanılamaz.
Son olarak Authentication Block Bu bölüm anahtar üzerinde yapılacak herhangi bir değişiklikte farklılık gösterecek hash alanıdır ve anahtarın yaratıldığı ya da import edildiği LMK değeriyle birlikte hesaplanır. Bu nedenle hem anahtarda değişiklik yapıldığında kullanılır hem de farklı bir LMK altında kullanılmasını engelleyen bir mekanizma sağlar. Şimdi tüm bu alanların içerisindeki özellikleri tek tek inceleyelim:
KEYBLOCK HEADER NEDİR?
Header içerisindeki ilk karakter 0 ya da 1 olabilir ve Anahtarın 0 için DES, 1 için AES olduğunu belirtir.
Sıradaki 4 karakterlik alan, başındaki S karakteri dışındaki tüm Keyblock’un uzunluğunu byte cinsinden gösterir. Optional header uzunluğu değişiklik gösterebileceğinden bunu anahtarın uzunluğu ile karıştırmamak gerekir.
Üçüncü alan, 2 karakterden oluşur ve Key Usage alanıdır. Bu alanda girilen değer anahtar oluşturulurken belirlenir ve daha sonra değiştirilemez. Bu alandaki değer, Anahtarın kullanım amacını belirtir. Örneğin ZMK oluştururken bu alan K0 olarak, ZPK oluştururken ise P0 olarak verilmelidir.
Dördüncü alan tek kararter içerir ve anahtarın kullanılabileceği algoritmayı belirtir. Bunlar şu an için AES, DES, RSA ve HMAC’ken gelecekte yeni algoritmalar eklenebilir.
Sıradaki alan yine tek karakter içerir ve anahtarın kullanım amacına göre değişiklik gösterir. Anahtar bir encryption key ya da wrapper key ise işlevi Encryption ya da decryption ile sınırlandırılabilir ya da ikisine de izin verilebilir. Eğer anahtar bir RSA anahtar ise bu durumda işlevi Sign ya da verify olarak sınırlandırılabilir ya da her ikisine de izin verilebilir. Bu alanın doğru kullanılması güvenlik konusunda ciddi katkılar sağlamaktadır. Bu konuyu detaylı bir şekilde inceleyeceğiz.
Sıradaki alan Versiyon numarasını içerir. Bu alan anahtar oluşturulurken verilir ve anahtarların takibi konusunda uygulamaya ve anahtar sahiplerine kolaylık sağlar.
Exportability alanı, anahtarın sadece güvenli olan keyblock formatında mı yoksa mümkün olan tüm formatlarda mı export edilebileceğini ya da hiç export edilemeyeceğini belirtir. Özellikle import edildikten sonra yeniden export edilme ihtiyacı olmayan anahtarlar için export işlemine izin verilmeyecek şekilde import işlemi yapılmalıdır.
OPTIONAL HEADER NEDİR?
Bu bölüm block sayısını belirtir. Eğer optional header block eklenmeyeceksse “00” olarak girilmelidir. Girilecekse bu durumda kaç adet farklı optional header block ekleneceği bu alanda belirtilmelidir. Son alan ise anahtarın yaratıldığı LMK ID’sini içerir. Bu alan anahtar yaratılırken girilmez, HSM tarafından otomatik olarak eklenir. İç kullanım amaçlı anahtarların authentication block ile doğrulanması için gereklidir. Anahtarın export edilmesi durumunda bu alan HSM tarafından FF olarak değiştirilir ve böylece her LMK ile import edilebilir olur.
Mevcut anahtarlarımızı Keyblock formatına geçirirken ya da keyblock formatında yeni bir anahtar oluştururken, tüm bu alanların doğru bir şekilde belirlenmesi gerekir. Tecrübelerimizde, anahtarların bu özelliklerinin netleştirilmesi ek çalışma gerektirdiğinden, en hızlı ve kolay yöntem olan mümkün olan en serbest özelliklerin kullanıldığını gördük. Bu şekilde yaratılan anahtarlar görevini yerine getirse de, keyblock geçişi ile sağlanması beklenen güvenlik seviyesini sağlayamadığından güvenlik riskleri oluşturabilir ve gelecekte yeniden değiştirilmesi gerekeceğinden ek operasyon gücü harcanmasına neden olacaktır.
Bu durumu basit bir örnekle inceleyelim:
A firması, ödeme bilgisi oluşturan ve bu bilgiyi şifreleyerek B firmasına ödemenin işlenmesi için gönderiyor olsun. İki firmanın data encryption Key’i en serbest özellikler ile yaratması durumunda anahtarımız data encryption ve decryption yapabilecek ve export edilebilecektir. Anahtar bu şekilde görevini yerine getirecek ve A firmasında encrypt edilen veri, B firması tarafından decrypt edilerek işlenebilecektir. Bu noktada güvenlik açısından A firmasının gözünden bakarsak, A firması kendi anahtarının güvenliğini sağlayacak önlemleri almış ve ödeme verisinin sadece yetkili uygulamaları tarafından oluşturulabileceğini garantilemiştir. Ancak B firmasındaki güvenlik standartları konusunda söz sahibi değildir.
B firmasına erişimi olan Rogue bir uygulamanın olduğunu düşünelim. Bu uygulamanın A firmasına ait anahtarı HSM’den export etmesi ya da anahtarın tutulduğu Database’den edinmesi durumunda, sahte bir ödeme verisi oluşturup, bu veriyi A firmasına ait anahtar ile encrypt ederek işleme alınması için sisteme gönderebilir. Bu senaryoda A firmasının bu süreçte hiçbir kontrolü olmaz.
Yapımızı güvenli hale getirmek için, aynı anahtarın A firmasında sadece encryption yapabilmesi ve B firmasında sadece Decrytion yapabilmesi aynı zamanda export edilememesi sağlanabilir.
Bu durumda Rogue Uygulamamız B firmasına ulaştığında, anahtara ulaşmak için HSM üzerinden export etmeyi deneyebilir, ancak anahtar exportable olmadığından bunu başaramaz.
Anahtarı Database’den aldığını düşünelim. Bu durumda da anahtarın encryption yapma özelliği olmadığı için sahte ödeme verisini encrypt edemez ve dolayısı ile sisteme sahte veri gönderemez.
Böylece A firması kendi sisteminde Anahtarlarının güvenliğini sağladığı sürece, kendisi adına sahte ödeme verisi gönderilemeyeceğinden emin olur.
Anahtarların ağırlıklı olarak tutulduğu database tabloları üzerinde, anahtar uzunluğundaki değişime uygun değişiklikler yapılması gerekecek. Sabit uzunluktaki sütunların serbest uzunluğa dönüştürülmesi yeterli olacaktır.
Geçişe hazırlanırken HSM ve anahtarlar ile ilgili yapılması gereken işlemler olacaktır. Öncelikle HSM üzerinde keyblock formatında bir Master Key oluşturulması gerekecektir. Bu anahtarın AES olması gelecekte yeniden değişiklik gerektirmemesi için önemlidir.
AES LMK oluşturulacak ise HSM’in AES algoritmasını destekleyen lisanslara sahip olduğundan emin olmak gerekir. Hali hazırda kullanılan anahtarların listesinin oluşturulması, hangi amaçla kullanıldıklarının ve keyblock formatında hangi özellikleri almaları gerektiğinin belirlenmesi gerekecektir. Mevcut key tipi bilinmeyen anahtarların Keyblock formatına dönüştürülmesi mümkün olmakla birlikte ek efor gerektirecektir. Çalışan sistemin yapısına bağlı olarak, anahtarlar geçiş öncesi ya da geçiş sırasında Keyblock formatına dönüştürülebilirler. Bu geçişin kesintisiz yapılabilmesi mümkündür, ancak ek uygulama geliştirme efor gerektirir. Keyblock formatına geçişte yazılım üzerinde değişiklikler gerekecektir.
HSM’e gönderilen tüm komutlar incelenmeli, keyblock formatındaki anahtarları ve verileri kabul edecek şekilde değiştirilmelidir. Fazlı geçiş nedeni ile yazılım üzerinde mevcutta olmayan HSM fonksiyonlarına ihtiyaç olacaktır. Fazlı geçiş sırasında anahtar paylaşımı X9.17 formatında yapılırken, bu anahtarın kullanımının Keyblock ile olması gerekebilir. Bu durumda iki formatı da destekleyecek bir HSM ile iki format arasında geçişi sağlayacak ek fonksiyonlar oluşturulmalıdır. Oluşturulacak bu ek fonksiyonların hangi durumlarda kullanılacağının belirlenmesini sağlayacak kontroller oluşturulmalıdır. Örneğin Keyblock formatında anahtar paylaşımını destekleyen bir firma ile bu şekilde paylaşım yapabilecek, desteklemeyen bir firma ile X9.17 formatında anahtar paylaşımı yapabilecek bir kontrol mekanizması gerekecektir.
Henüz mecburi olmayan ancak gelecekte 3DES anahtarların yerini alacağını düşündüğümüz AES anahtarları kullanabilmek için keyblock geçişinde AES master key yaratılması tavsiye edilmektedir.Keyblock formatındaki hiçbir anahtar X9.17 formatına dönüştürülemez.DES bir anahtar, X9.17 formatında paylaşıldığında, alıcı firma tarafından import sırasında Keyblock formatına dönüştürülebilir. Ancak aynı durum AES anahtarlar için geçerli değildir.
AES anahtarlar sadece Keyblock formatında export edilip bu formatta iletildiğinde import edilebilir. Keyblock formatını desteklemeyen bir HSM ile export edilmiş bir AES anahtar, keyblock formatını destekleyen bir HSM’e import edilemeyeceğinden, AES anahtar ihtiyacı olan sistemlerde anahtar paylaşımı konusunda tüm partilerin ortak bir format ya da HSM tipi belirleyerek ilerlemesi gerekecektir. Keyblock geçişi sancılı olacağı kadar anahtar ve veri güvenliği açısından faydalı bir değişim olacaktır. Her ne kadar faz iki ertelenmiş olsa da geçiş hazırlıklarına mümkün olduğu kadar erken başlanılması gerektiğini vurgulamak isteriz.
Hepimiz temel önlemleri biliyoruz aslında: güçlü şifreler, iki katmanlı onaylama vb. Fakat son zamanlardaki güvenlik ve mahremiyet ihlali içeren saldırılara baktığımızda, bu saldırıların kötü seçilmiş şifrelerle ilgili değil, daha çok sosyal mühendislike ilgili olduğunu görüyoruz. Şimdi hep birlikte sosyal mühendisliğin ne olduğuna, nasıl gerçekleşebileceğine ve kendinizi nasıl koruyacağınıza bakalım.
Sosyal Mühendislik Nasıl Çalışır?
Sosyal mühendislik, güvenlik sistemlerini – ya da herhangi bir sistemi – aşmayı amaçlayan bir saldırıdır. Bu saldırı, sistemin içindeki sistem zaafiyetlerini kullanarak değil de, sistemin içindeki insanların zaafiyetlerini kullanır. Sistemin içine sızmak ya da şifre kırmak yerine, bir teknoloji destek uzmanını şifreyi değiştirtip size vermesini sağlayarak, veya elinizdeki bilgileri kullanıp onaylı bir kullanıcı gibi davranarak sistemi kandırarak içine girmek gibi.
Sosyal mühendislik, temelinde, bir hacking türüdür. Masum şakalar için kullanılabilmesi mümkün olduğu gibi, kimlik bilgileri çalmak için, insanların mahremiyetlerini ihlal etmek için veya sistemlere zarar vermek için kullanılabilmektedir. Son günlerde de ünlülerin mahrem fotoğraflarının internete sızdırılmış olması da, brute force saldırılarından veya gevşek güvenlik önemlerinden dolayı değil, sosyal mühendislik kullanılarak gerçekleştirilmiştir. Sosyal mühendislik konusunda asıl korkutucu olansa, hedef hakkında biraz araştırma yaparak kolaylıkla bu tür saldırıların gerçekleştirilebilmesidir.
Sosyal mühendisliğin bir kaç çeşidi vardır. Hedef kullanıcıyı ikna ederek ondan bilgi almak kullanılan yöntemlerden biridir. En başarılı olan yöntemse, hedefinizin sizin kim olduğunuzu anlamamasını sağlamaktır.
Sosyal Mühendislik Saldırılarına Neden Dikkat Etmeliyiz?
Sosyal mühendislik saldırılarına karşı korunmada en önce şifre güvenliği gelmektedir. Kolay tahmin edilemeyecek şifre seçimi ve iki katmanlı onayla giriş yapmak çok önemlidir. Şifre güvenliğine önem verilmeli, fakat unutulmaması gereken başka bir mesele de artık hackerların sadece tek bir şifreyle ya da hesapla zaman kaybetmek istemedikleri gerçeği. Bundan dolayı, fazlaca değerli gördükleri hedeflerin hesapları hackerlar için daha cazip görünüyor.
Sosyal Mühendislik Saldırılarından Nasıl Korunuruz?
The Washington Post gazetesinde çıkan bir yazıda, bir kullanıcının iCloud hesabındaki güvenlik sorularının nasıl aşılabileceği ve bunun ne kadar kolay olduğu anlatılıyor. Ünlülerin mahrem fotolarının sızdırıldığı son saldırıda da bu şekilde bir yöntem kullanıldığı düşünülüyor. Hedef hakkında biraz araştırma yapmak bu tür gerekli bilgileri saldırganlara kolayca sağlıyor. Peki bu durumda, bu tür saldırılardan korunmak için neler yapabiliriz?
Kesinlikle gizli bilgilerinizi başkalarına vermeyin. Sosyal medyada sizi arkadaş olarak ekleyerek bir dostunuzmuş gibi yapan kullanıcılar ile herhangi bir bilginizi paylaşmayın. Tanımadığınız insanların arkadaşlık tekliflerini kabul etmeyin. Sizi bankanızdan aradıklarını söyleyen aramalara güvenmeyin.
Çalıştığınız kurumun IT departmanından aradıklarını söyleyen veya sisteminizde bir hatayı gidermek üzere görevlendirildiğini söyleyerek sizden herhangi bir bilgi talep eden kişi veya kişilere karşı dikkatli olun ve talep ettikleri bilgiyi asla vermeyin. Unutmayın, gerçek sistem uzmanları asla kişisel bilgileri sormazlar.
Kendiniz hakkında önemsiz olduğunu düşündüğünüz bilgileri bile koruyun. Özellikle güvenlik soruları, “Anne doğum yeri” veya “ilk evcil hayvan adı” gibi tahmin edilmesi son derece kolay cevaplardan oluşur. Hesap sahibi kullanıcılar da, cevapları kolay hatırlayabilecekleri soruları seçerler, ama bu sorular sadece kendileri için kolay değildir. Eğer güvenlik sorusu kullanacaksanız, en muğlak ve dengeli cevabı vermeye çalışın. Unutacağınızdan korkuyorsanız da bu cevabı kriptolayarak bilgisayarınızda muhafaza edin.
Güvenlik sorularına yalan cevaplar verin ve bu yalanları devamlı hatırlayın. Doğum yeriniz konusunda, örneğin, Cincinnati yerine Little Rock’da doğduğunuzu yazabilirsiniz. Ya da kendiniz bir cevap uydurabilirsiniz. Bu durumda önemli olan, burada verdiğiniz cevapları daha sonra hatırlayabilmenizdir.
Her şifre resetleme emailini şüpheyle karşılayın. Güvenli gibi görünen emailleri bile dikkatle inceleyin. Saldırganlar, bir taraftan şifrenizi değiştirmeye çalışırken, bir taraftan da size şifre değiştirme uyarıları gönderildiğinin farkındadırlar. Fakat bu uyarılarda, “Eğer bu talebi siz yapmadıysanız herhangi bir işlem yapmanıza gerek yoktur.” kısmı, sizi hiç bir şey yapmamaya itmesin. En azından kullandığınız servisin müşteri hizmetlerine ulaşmaya çalışarak, hesap şifre işlemlerinin dondurulmasını talep edebilirsiniz.
Hesabınızı ve hesap hareketlerinizi takip edin. Şifre işlemlerini takip ettiğiniz gibi, hesap işlemlerinizi de kontrol edin. Örneğin, hesabınızın nerelere bağlı olduğunu görmek için Google Dashboard’u inceleyebilirsiniz. Bulut bilişim hizmetleri, sosyal medya hesapları ve email sağlayıcılardaki hesaplarınız için bu kontrolleri gerçekleştirin. Finansal hesaplarınızı da kontrol edin, sadece bankanızın sağladığı sistem girişi ile online bankacılık kullanın.
Şifrelerinizi, önemli hizmet bilgilerinizi ve güvenlik sorularınızı mutlaka çeşitlendirin. Aynı şifreyi kesinlikle birden fazla platformda kullanmayın. Aynı güvenlik sorularına aynı cevapları vermeyin. Bu durumlarda, tek bir hesabınızı hacklemeyi başaranların, bütün internet hayatınızı bitirebileceğini unutmayın. Bir saldırıya uğrasanız bile, bu saldırının kısıtlı kalması sizin elinizde.
Sosyal mühendisliklere karşı bu gibi durumlar dışında da dikkatli olmak gerekiyor. Online oyun sitelerinde, chat odalarında veya benzeri internet platformlarında mutlaka dikkatli olmak şart. Çünkü sosyal mühendislik, en temel insan zaafiyeti üzerinden ilerliyor, yani, ikna edilebilirlik.
30 Ağustos – 5 Eylül 2014 tarihleri arasında TÜBİTAK tarafından düzenlenen Siber Güvenlik Yaz Okulu, bu yıl 3. defa gerçekleştirildi. Bir hafta süren yaz okulunda bu yıl ben de vardım.
Ankara’nın yaklaşık bir saat dışında, Büyük Anadolu Oteli adında bir termal otelde gerçekleştirilen yaz kampı, bu yıl da geçen yılki gibi, hem genç mühendislik öğrencilerini, hem de sosyal bilimler öğrencilerini ağırladı. TÜBİTAK Siber Güvenlik Enstitüsü uzmanları tarafından verilen eğitimler, en öncelikle, genç arkadaşlarda siber güvenlik konusunda bir bilinç ve farkındalık yaratmayı hedefliyor. İkinci olarak da, şimdiden siber güvenlik konusunda temel oluşturarak, ileride hem profesyonel hem de akademik hayatlarında siber güvenliğe yönelerek, ülkemizin siber güvenlik kabiliyetlerine katkıda bulunmaları planlıyor.
Yaz okuluna katılan öğrencilerde, bu alanda ciddi bir heyecan göze çarpıyordu. Henüz lisans yıllarında bulunmalarına karşın, bir çok arkadaşın siber güvenlik konusuyla özel olarak ilgilendiklerini, kendi imkanlarıyla kendilerini geliştirmeye çalıştıklarını gözlemlemek mümkün. Bu açıdan, siber güvenlik yaz okulunun da siber güvenlik birikimlerine önemli ölçüde katkıda bulunacağına inançları tamdı.
Yaz okulu mühendislik okuyan öğrenciler ve sosyal bilimler okuyan öğrenciler için gerçekleştirildi. Uluslararası ilişkiler kökenli olduğum için ben de sosyal bilimler için düzenlenen derslere katıldım. Bu derslerde, ilk olarak internet altyapısının özellikleri anlatıldı. Daha sonra siber saldırı tehditleri, bu tehditlerin tüm özellikleri ve şiddet dereceleri, teknik detaylarıyla birlikte sunuldu. Daha sonra uzmanlar ülkelerin siber alan kullanımları, siber kabiliyetleri ve bu alana yaptıkları yatırımları değerlendirdi. Bilgi güvenliği ve ISO 27001 konusunda da dersler bulunmaktaydı. Tüm bu derslerde özellikle üzerinde durulan konu, sosyal bilimler öğrencilerinin siber dünyadan ve siber güvenlik konularından korkmamaları gerektiğiydi. ABD gibi kimi ülkelerde siber güvenlik politikalarını düzenleyen bürokratların, teknik kökenli değil sosyal bilimler kökenli olmaları, özellikle üzerinde durulan örneklerdendi.
Sosyal bilimciler için siber güvenlik ve siber dünya eğitimlerinde genel olarak teknik eğitimden farklı bir metot izlenmelidir. Örneğin, siberalanı sosyal bilimci öğrencilere anlatmayı amaçlayan Jefferson’s Moose: The Notes on the State of Cyberspace kitabında siberalanın temel teknik detayları, analojiler/benzetmeler yoluyla anlatılır. Kitapta, internet altyapısı ve bu ağ altyapısının temel iletişim protokolü olan TCP/IP, telefon ağının iletişimi ile benzetmeler veya farklılıklar kurularak açıklanır. DNS’ten bahsedilirken, bunun bir telefon defterine benzediği, ağ protokollerinin, kullanıldığımız dillere benzediği gibi anaolojiler yoluyla, okuyucunun temel kavramlara hakim olması sağlanmaya çalışılır. Yaz okulundaki sosyal bilimler derslerinde de aynı şekilde eğitimciler benzetmelere sıkça başvurdular. Fakat gözlemleyebildiğim kadarıyla, teknik dilin daha da yumuşatılarak, meselenin detaylarından ziyade özünün verilmesi adına daha fazla günlük dil kullanılmasına ihtiyaç bulunuyor. Dahası, siber dünyanın özelliklerinin teknik detaylarından ziyade, hukuki veya politik önemlerinin daha fazla zikredilmesi, hem sosyal bilimler öğrencileri için daha fazla faydalı olacaktır, hem de teknik ve sosyal bilimci uzmanların ortak bir dil geliştirebilmeleri adına sağlam adımlar atılması mümkün olabilecektir.
Teknik eğitimdeki öğrenciler, eğitimlerine ek olarak, “Capture The Flag” yarışmalarıyla ve film gösterimleriyle sosyalleşme ve öğrendiklerini uygulama imkanları buldular. Aldıkları dersler çoğunlukla, güvenlik açıkları, dijital adli analiz, mobil güvenlik, APT ve zararlı yazılım analiz yöntemleri gibi temel siber güvenlik konularını içeriyordu.
Siber güvenlik yaz okullarını başarıyla sürdürerek ülkede siber güvenlik konusunda belki de en önemli farkındalık artırıcı etkinliğe imza atan TÜBİTAK Siber Güvenlik Enstitüsü, sosyal bilimlerde siber güvenliğin önemini en erken farkedenlerdendi ve dünya ile birlikte Türkiye’de de bu çalışmaların sürdürülmesi için var gücüyle çalışıyor. Programın (sosyal bilimciler için olan kısmı) için bir kaç öneri sıralamak gerekirse, analojilerden daha fazla yararlanılması, teknik detayların azaltılarak, bu teknik meselelerin dış dünyada karşılıklarının ne olabileceğinin anlatılması faydalı olacaktır. Örneğin DDoS saldırılarının teknik detaylarıyla birlikte, bir de bu saldırıların hukuki ve politik boyutu nedir, dünyada hangi bağlamda tartışılmaktadır, belli başlı teknik konular sosyal bilimcilerce nasıl ele alınmış gibi noktalar, derslerde muhakkak yer bulmalı. Buna ek olarak, bu alanda dünyada halihazırda yazılan kitap ve makalelere de kısaca değinmek faydalı olacaktır. Örneğin son yıllarda artış kazanan siber alanda devlet eşitliği gibi konularda ICAAN’ın rolü, BRICS ülkelerinin kendi fiber altyapılarını kurmak istemeleri ve NATO’nun siber saldırıları 5. madde kapsamında değerlendirme çabalarına değinilmeli, köşeyazılarındaki ve makalelerdeki trendler öğrencilerle paylaşılmalı. Bu eksiklikler, Siber Güvenlik Enstitüsü’nün eksikliği olmaktan ziyade, daha çok siber güvenliğin henüz yeni oluşan bir bilimsel alan olmasından ve de sosyal bilimlerde öneminin çok yeni zamanlarda farkedilmesinden kaynaklanmakta.
İlerleyen yıllarda, gerek yaz okulunda gerekse sosyal bilimler siber güvenlik çalışmalarında bu eksikliklerin giderileceği, ve dünyanın belli başlı ülkeleri ile birlikte Türkiye’de de interdisipliner siber güvenlik çalışmalarının devam edeceği, su götürmez bir gerçek.
