2015 trendleri: APT insanın kendine yakışanı giymesidir

Adını son olarak SONY’nin hacklenmesi olayında duyduğumuz Fireeye’ın Mandiant şirketi “2015 trendleri: Ön cepheden görüntü” adıyla bir rapor yayınladı.
Geçtiğimiz senenin öne çıkan güvenlik trendlerinin ve 2015 içerisinde görmemiz muhtemel trendlerin ele alındığı raporun bazı konu başlıklarını toparladım.

Rapora https://www2.fireeye.com/WEB-2015RPTM-Trends.html adresinden ulaşabilirsiniz.

Raporda öne çıkan bazı rakamlar
Saldırıların %31’i kurban tarafından tespit edilebilirken, %69’u dış kaynaklardan öğrenilmiş. Bu istatistik, diğer üreticilerin raporlarında gördüğümüz rakamlara çok yakın olduğu için henüz saldırganları tespit edebilme becerilerimizi geliştirme yönünde almamız gereken çok yol olduğunu görüyoruz.

Saldırganlar (saldırganın kendi bağlantısı veya kullanılan zararlı yazılım) tespit edilmeden önce ortalama 205 gün kurum ağında varlığını korumuş. Özetle, ağımıza biri sızdığında veya bir zararlı yazılım bulaştığında bunu tespit etmemiz ortalama 205 gün sürüyor.  Rapora konu olaylar arasında gözlemlenen en uzun süre 2,982 (yazı ile ikibindokuzyüzsekseniki!) gün olmuş.

Raporda 2015 trendleri olarak 4 konuya yer verilmiş.

Trend 1: Olayın duyulmasıyla başa çıkmak
Yaşanan bir güvenlik ihlali sonrasında hedef olan kurum tarafından yapılacak açıklama kurum imajı ve halkın olayla ilgili algısı bakımından hayati önem taşımaktadır. Kurumun duruma hakim görünmesi ve olayın bütün boyutuyla araştırıldığı mesajının net bir şekilde verilmesi olayların algılanma şeklini doğrudan etkilemektedir. 2014 yılında yaşanan güvenlik ihlalleri halkın bu tür olayların etkileri konusunda önceki yıllarda olduğundan daha bilinçli hale gelmesini sağlamıştır. Önceki yıllarda yapılan ve saldırı tarihi ve dışarı sızan veri türünden ibaret açıklamalar artık basın ve halk tarafından yeterli bulunmamakta, saldırı vektörü ve saldırının arkasında kimlerin olduğu gibi bilgiler de talep edilmektedir.
Yapılacak açıklamalar spekülasyonların önüne geçebilmeli (henüz tamamlanmamış bir araştırmanın verileriyle bunun mümkün olabildiği ölçüde) ve olayın aslından sapmasını engellemelidir. Olay sonrası açıklama yapılmasını neredeyse mecburi hale getiren neden ise olayların çoğunun kurum fark etmeden önce halka duyurulmasıdır (bkz. 2014 yılında 0layların %69’u dış kaynaklardan öğrenilmiştir).

Raporda bu tür bir olay yaşandığında açıklama kaleme alınırken cevaplanmasında fayda olabilecek bazı sorulara yer verilmiş. Bunlar;
Saldırgan içeri nasıl sızdı?
Saldırgan içerideki sistemlerle bağlantısını nasıl kalıcı hale getirdi?
Saldırının adımları nelerdi?
Hangi veriler çalındı?
Saldırı kontrol altına alınıp saldırgan unsurlar temizlendi mi?

Trend 2: Perakendeciler hedefte
2014 yılında çalınan milyonlarca kredi kartı bilgisi pek çok kişiyi kredi kartlarını iptal edip yenilerini çıkartmaya mecbur etmişti. Perakendeciler kredi kartı (dolayısıyla para) işlemlerinin yoğun olduğu yerler oldukları için saldırganların iştahını kabartmaktadırlar. Öyle görünüyor ki hedefleri kolay para kazanmak olan bazı gruplar saldırılarına 2015 yılında da devam edecekler.

Alışveriş veya sanal kasa gibi uygulamaların sanallaştırılması, bir yandan uygulamanın ortamdan bağımsız daha güvenli bir baloncuk içerisinde çalışmasına imkan verirken, diğer yandan saldırganlar için bazı fırsatlar doğurmaktadır. Doğru kurulup konfigüre edildiğinde bu sanal uygulamalar olabildiği ölçüde güvenlidir ancak raporda ele alınan çoğu örnekte basit konfigürasyon hatalarının ve çift kademeli giriş yöntemlerinin kullanıldığı belirtilmiştir. Saldırganların yazarkasa ve POS yazılımlarını hedef alan zararlı yazılımlar geliştirmiş olması da bu noktanın geçerli bir saldırı vektörü haline gelmesine neden olmuştur.

Raporda büyük bir A.B.D.’li perakendecinin yaşadığı olayın adımlarına da yer verilmiş. Saldırının başlıca adımlar aşağıdaki gibi gelişmiş.

1. Saldırgan uygulamaya geçerli kullanıcı adı ve parolalar ile giriş yapmış. Kullanıcı bilgilerinin ne şekilde ele geçirildiği bilinmemektedir. 
2. Saldırgan ağ içerisinde “dolaşmak” için bizim de sızma testlerinde kullandığımız Metasploit yazılımını kullanmış. Metasploit bilinen pek çok istismar kodunu barındıran açık kaynaklı bir yazılımdır. Metaploit ile domain yönetici bilgilerini ele geçiren saldırganlar bu noktadan sonra ağ üzerinde yayılmak için sistem yöneticileri tarafından kullanılan(SysInternals PsExec aracı ve RDP gibi) daha alışılmış yöntemlere geçiş yapmıştır. 
3. Bağlantılarını kalıcı hale getirmek için bir kaç farklı bilgisayara arka kapı yerleştirilmiş. 
4. Ele geçirdikleri domain yetkili kullanıcısının POS cihazlarının olduğu ağ üzerinde de geçerli olması sayesinde saldırganlar POS cihazlarını etkileyecek zararlı yazılımı rahatlıkla ağ geneline kurmuşlar. Bu zararlı yazılım POS cihazları üzerinden kredi kartı numarası gibi bilgileri çalmıştır. 

Bu tür bir saldırının önüne geçebilmek için raporda aşağıdaki tavsiyeler verilmiştir;
Uzak bağlantıların güvenliğinin sağlanması: Sistemlere uzaktan kimin ve hangi şartlarda erişebildiğinin denetlenmesi.
Ödeme aracı bilgilerinin bulunduğu ağın güvenliğinin sağlanması: Bu bilgilerin bulunduğu ağlara erişmek için iki kademeli kimlik doğrulaması gibi araçların kullanılması.
Kritik altyapılarda uygulamaların beyaz listeye alınması: Önemli sunucularda hangi yazılımların çalışabileceğinin belirlenmesi ve bunların dışında hiç bir yazılımın çalışmasına izin verilmemesi.
Yetkili kullanıcı hesaplarının yönetimi: Ağ veya belirli bir sistem genelinde yetkili kullanıcı hesaplarının korunması ve yönetilmesi için gerekli tedbirlerin alınması.

Trend 3: Gelişen saldırı döngüsü
Raporda 2014 yılında saldırganların bir VPN bağlantısını ele geçirip bunu kullandıkları olayların sayısında artış görülmüş. VPN bağlantısını ele geçiren saldırgan sistem üzerinde bir arka kapı açmakla uğraşmadığı gibi yetkili kullanıcılar arasında dikkat çekmeden “işlerini” yürütebilmektedir.
VPN bağlantısının sadece kullanıcı adı ve parola ile kurulduğu durumlarda saldırganlar bu bilgileri kolayca elde ederek VON bağlantısını diledikleri gibi kullanmaya başlamıştır. İki kademeli giriş (kullanıcı adı ve parolaya ek olarak bir güvenlik katmanının daha bulunması) kullanıldığı durumlar arasında ise ikinci kademinin bir dijital sertifika olması, saldırganların bu sertifikayı çalarak bağlantıyı kurmalarına imkan vermiştir.
Saldırganların, çok eski bir yöntem olmasına karşın, “webshell” olarak da adlandırılan web tabanlı arka kapıları rahatlıkla kullanmaya devam ettikleri görülmüştür. Bu arka kapıları HTTPS olarak açan saldırganlar bu sayede şifreli ve bir çok güvenlik çözümü tarafından görülmeyen bir yol bulmuşlardır.

Trend 4: Suçlular ve APT’ler içiçe
Siber suçlu olarak adlandırabileceğimiz ve APT aktörlerine göre daha düşük seviyede bir tehdit olan saldırganların APT’lerde görmeye alışkın olduğumuz yöntemleri kullanması, aynı şekilde de APT olarak sınıflandırılan saldırılarda çok basit ve genel saldırı tekniklerin kullanılması iki saldırı türü arasındaki çizgilerin silinmesine neden olmaktadır. Tekniklerin saldırganlar arasında ortak kullanılması bir saldırıyı değerlendirirken kullanılan tekniklerden çok saldırganın niyetinin anlaşılması gerekliliğini ortaya çıkartmıştır. Özellikle hedefli oltalama (spear phishing) gibi sosyal mühendislik saldırılarının, hedefe özel yazılmış zararlı yazılımların her iki saldırgan grubu tarafından da kullanılması ayrım yapmayı zorlaştırmaktadır.

Raporun özellikle saldırganlar arasında ortak kullanılan saldırı vektörlerinin varlığını kabul etmesi benim için önemli bir gelişmedir. Güvenlik "satan" pek çok üreticinin, sıradan saldırılara karşı yeterli yatırımı yaptığınızı düşündüğü hallerde sorduğu "APT'lere karşı ne yapıyorsunuz?" sorusunun gerçeklikten uzak olduğunu hep savunan biri olarak bu itiraf hoşuma gitti.

Risk seviyesi ve sızma testleri

O: Sen hacker misin?

Ben: (bilmiş bir gülümsemeyle) Evet

O: (Heyecanla) Hadi birilerinin Facebook’unu patlatalım o zaman

Ben: (sinirli bir şekilde) ben saldırmıyorum

O: (biraz şüpheci) nasıl yani?

Ben: (Sıkılmış) hackerların ne yaptığını bilmem kurumları güvenli hale getirmemi sağlıyor

O: (hayal kırıklığına uğramış) Hacker değil misin yani?

Ben: (konuyu değiştirme çabasıyla) Tamagotchi’leri hatırlar mısın?

Buna benzer bir konuşmayı onlarca kişiyle belki yüzlerce kez yaptım. Bilgi güvenliği ile hacking konusunun nasıl bir araya geldiğini, aradaki köprünün ne olduğunu, benim ve meslektaşlarımın neden “hacker” olmadığımızı anlamakta zorlanıyorlar.

Siber suçluların düşünce yapısını anlama çabaları, saldırganlar tarafından kullanılan araç ve yöntemlere hakim olmaktaki amacımız siber saldırılardan doğacak riskleri doğru tespit edip gerekli önlemlerin alınmasını sağlamaktır.

İş hayatımızın ve ulusal güvenliğimizin çok önemli bir parçasını oluşturan bilişim sistemlerinin güvenli olması gerekiyor.  Kurumlarımızın asıl işinin bilişim sistemlerinin güvenliği olmadığını düşünürsek bilgi güvenliği konusunda aslında bir risk yönetimi işidir. 

Siber saldırılara karşı bizi koruyacak binlerce farklı çözüm ve yöntem vardır bunların hepsini alacak bütçeye sahip olmadığımızı düşünürsek bilgi güvenliği konusundaki amacımız siber saldırılardan doğacak riskleri kabul edilebilir seviyeye indirmek olacaktır.

Bilişim sistemlerinin suçluların iştahlarını kabartmalarına neden olan başlıca faktörlerden birisi internet üzerinden işlenen suçların, gerçek dünyada işlenen suçlara göre risk/kazanç oranını daha cazip olmasıdır. Gerçek dünyada bir market soymak isteyecek bir saldırgan yaralanma, ölüm veya yakalanma gibi riskleri göze almak zorundadır. İnternet üzerinden ise, aynı bakkalın sahibinin kredi kartı numarasını almaya çalışmak ise fiziksel risk oluşturmamaktadır. 

Riskin kazançtan büyük olduğu fiziksel dünyada suç işlemek yerine benzer maddi kazançlar sağlayacak suçu, kazancın alınan riskten büyük olduğu, internet ortamında işlemek çok daha caziptir.

Suçluların iştahını kabartan bilişim sistemlerimizi korumak ise zordur. Bütün sistemlerin hacklenebilir olması sadece bütçe kısıtlarında kaynaklı bir durum değildir. 

Tipik Hollywood hackerını ele alırsak karşımıza çıkacak görüntü aşağı yukarı şöyledir:

Resim 1: Hollywood hackerini Powerpoint'ta çizdim :)

Karanlık bir oda, siyah fon üzerine yeşil yazıların aktığı 3-4 monitör, gece gündüz demeden klavyede bir şeyler yazan saldırgan. Siber suçlularla ilgili bu karikatür bir bakıma güvenliği sağlamamakta karşılaştığımız temel bir soruna atıfta bulunmaktadır. Sistem yöneticileri gün içerisinde onlarca kullanıcının farklı sorunlarıyla ilgilenmektedir. 

Bilgi güvenliği konusunda uzmanlaşmış ve buna odaklı çalışsak bile güvenlik duvarından antivirüse kadar geniş bir yelpazede ürünlerin günlük olarak işletilmesi ve yönetilmesi görevini üstlenmekteyiz. Buna karşılık saldırgan sadece sizinle ilgilenmektedir. Savunma tarafı onlarca belki de yüzlerce problem ve bileşenden oluşan bir bulutun içerisinde her gün mücadele ederken saldırganın bu buluta sızmasını sağlayacak tek bir yol bulması yeterlidir. 

Resim 2: Savunma bulutu ve Hacker

Matematiksel olarak, savunmanın her seferinde kazanarak en düşük oranda %100 başarı sağlaması gerekirken saldırgan tek bir sefer, biraz önce tanımladığımız buluta sızmasını sağlayacak bir zafiyet bulması yeterlidir.

Savunmayı zora sokan bir diğer etken de zamandır. Yapacağımız bir çalışma sonucunda ağ ve sistemlerinizin bugün bilinen bütün zafiyetlerden arındırılması, bugünün istismar kodlarına karşı güvende olmasını sağlamak mümkündür. Bu güvenli noktadan saniyeler sonra bulunacak bir zafiyet bile ağ ve sistemleri bu çalışma öncesindeki güvensiz durumlarına geri getirecektir. Zaman geçtikte sistemler üzerinde tespit edilen zafiyetlerin sayısı artmaktadır. 

Her fırsatta düzenli olarak yapılmasını tavsiye ettiğimiz güncellemeler güvenlik seviyemizi belli bir noktada tutmamızı sağlayacaktır. Bazı durumlarda bu güvenlik güncellemelerinin (yamaların) çıkması sistemleri tehlikeye atmaktadır. Yazılım üreticilerinin güncellemelerle birlikte yayınladıkları dokümanlarda hangi zafiyetleri giderdikleri açıkça bellidir. Saldırganların bir kısmı bu güncellemelerin yayınlanmasını bekler ve güncelleme dokümanlarında anlatılan zafiyeti hedef alan saldırıları geliştirirler. Bu sayede güncellemenin yayınlandığı gün ile sistemlerin güncellendiği tarih arasındaki süre boyunca sistemlere karşı kullanabilecekleri ve geçerli bir saldırıya sahip olurlar.

Resim 3: Güncelleme ve risk seviyesi ilişkisi

Yukarıdaki grafikte zamanla değişen risk seviyemizi görebiliriz. Güncelleme yapılana kadar artan risk seviyemiz saldırgan açısından bakıldığında saldırgana fazladan avantaj sağlayan bir ortam oluşmasına neden olmaktadır.

Güncellemelerin yapılması savunma için firewall kurallarının denetlenmesi, IPS/IDS imzalarının güncellenmesi ve lisanssız yazılım kullanılmaması gibi temel bir hijyen kuralıdır. Günümüzün siber tehditleriyle başa çıkabilmek için savunma düşünce yapısı yeterli değildir. 

Sadece aldığımız önlemlere odaklanmak ve bunların işlerini doğru yaptıklarını varsaymak bilgi güvenliği açısından yapabileceğimiz ölümcül bir hata. Sistemlerimizi ne kadar koruyabildiğimizi anlamak, nerelerde iyileştirmeler yapmamız gerektiğini görmek ve, o ana kadar hiç aklımıza gelmemiş, saldırı vektörlerini belirlemek için saldırganların düşünce yapısını anlamalıyız. 

Benim gibilerin yaptığı çalışmalar kapsamında saldırı vektörlerini ortaya koyarak, kullanabilecek yöntemleri ve araçları kullanarak kurumsal ağ ve sistemlere sızmaya çalışmak kurumların mevcut güvenlik seviyesine bir saldırganın gözüyle bakmamıza imkan veriyor.

Bilgi Güvenliğinin 8 Temel Kuralı

Bilgi güvenliği konusunda karar vermek zordur. Yapacağımız değişiklik mevcut güvenlik önlemlerimizi devre dışı bırakmamalı veya mevcutta olmayan bir güvenlik açığına neden olmamalıdır.

Resim 1: Bilgi Güvenliğinin 8 Kuralı (temsili)

Genel olarak bilgi güvenliğini etkileyebilecek bir konuda karar verirken uyulması gereken 8 temel kural sayesinde hata yapma ihtimalimizi en aza indirebiliriz. Göreceğiniz gibi bu kurallar bilgi güvenliği alanında uzun yıllardır çalışanlar tarafından tecrübe yoluyla öğrenilmiş ve uygulanmaktadır. Kevin Day “Inside the Security Mind” kitabında bu 8 kurala uzun uzadıya değinmektedir. Bu yazıda her kuralı kısaca ele alacağım.

Kural 1: En düşük yetki kuralı

Kural 2: Değişiklik kuralı

Kural 3: Güven kuralı

Kural 4: En zayıf halka kuralı

Kural 5: Ayrım kuralı

Kural 6: 3 aşamalı süreç kuralı

Kural 7: Önleyici faaliyet kuralı

Kural 8: Anında ve doğru tepki kuralı

Kural 1: En düşük yetki kuralı

En önemli ve en yaygın olarak uygulanan kuraldır. Kullanıcı ve/veya sistem yetkilerinin sadece personelin ve/veya sistemin işini yapabileceği kadarıyla sınırlandırılmasıdır. Bu kuralı uygulamaya koymak için kullanıcıya veya sisteme hiç yetki vermeyip, kademeli olarak işini yapmasını sağlayacak kadar yetkinin verilmesidir. Böylece kullanıcının sadece işini yapacak kadar yetkiye sahip olması sağlanır.

Kimin, hangi şartlarda, hangi sistemlere ulaşabileceğini belirlemek ve bu sayede doğru yetkileri belirlemek için aşağıdakilere benzer basit şablonlar kullanılabilir.

Kullanıcı: Sıradan ofis kullanıcısı

Erişime izin verilen saatler: Mesai saatleri içinde

Yetki: Çalıştığı birim ekranları

İnternet erişimi: Var

Lokal admin: Hayır (kendi bilgisayarı üzerinde uygulama çalıştıramaz)

Dışarıdan erişim yetkisi: Yok

VPN Kullanıcısı: Yok

Kullanıcı: Yönetici

Erişime izin verilen saatler: Mesai saatleri içinde ve dışında

Yetki: Çalıştığı birim ekranları

İnternet erişimi: Var

Lokal admin: Hayır (kendi bilgisayarı üzerinde uygulama çalıştıramaz)

Dışarıdan erişim yetkisi: Yok

VPN Kullanıcısı: Var

Kullanıcı: Bilgi İşlem Personeli

Erişime izin verilen saatler: Mesai saatleri içinde ve dışında

Yetki: Genel

İnternet erişimi: Var

Lokal admin: Evet

Dışarıdan erişim yetkisi: Var

VPN Kullanıcısı: Var

Kural 2: Değişiklik kuralı

Değişim daimidir. Bu bilişim sistemleri için de geçerlidir. Bilişim sistemlerini etkileyecek değişikliklerin doğru yönetilmesi, koordine edilmesi ve güvenlik açısından değerlendirilmesi önemlidir. Burada anahtar kelime “yönetim”dir, değişim yönetilmelidir. Yönetilmediği takdirde kurumsal ağın güvenlik düzeyinin korunması mümkün olmayacaktır.  Değişim yönetmek için kullanılabilecek bazı yöntemler aşağıdadır.

Değişiklileri denetleyin: Neye göre değişiklik yapacağız? Değişiklikleri kim denetleyecek? Gibi basit soruların yanıtlanmasını sağlayacak bir yöntem geliştirilmelidir.

Etkili bir yöntem geliştirilmelidir: Değişiklik yönetimi ancak kimseye yük olmadan kullanılabilirse işe yarar. Aksi takdirde kimsenin uygulamayacağı ve etkili olmayacak bir süreç olarak atıl kalır.

Her durumda uygulanmalıdır: Bu sürece uyulmadan hiç bir değişiklik yapılmamalıdır. Ufak bir güncelleme için bütün izin prosedürünün uygulanması şart olmayabilir ama bu güncellemenin kaydının tutulması şarttır.

Güvenlik konusunda değişiklikler dikkatle ele alınmalıdır: En küçük firewall kuralı değişikliği bile izin sürecine uygun olarak yapılmalıdır. Güvenlik konusundaki değişiklikler tek bir kullanıcının kararına bırakılmamalı, mümkünse bir kaç kişinin birlikte vereceği kararla yapılmalıdır.

İstemciler de dahil edilmelidir: Önceden onaylanmış bazı değişikliklerin bir listesinin oluşturulmasında fayda var. Buna örnek olarak Windows ve antivirüs güncellemeleri verilebilir.

Deneme tahtası olmayın: Yeni çıkan yazılım ve donanımlarda bazı sorunlar olabilir. Bunun önüne geçmek için “1 yıldan kısa süredir piyasada olan ürünler ağa bağlanmaz” gibi basit kurallar konulabilir. Güncellemeler konusunda bu kadar uzun süre beklemek doğru olmayacaktır, ancak bazı güncellemelerin sorun yarattığı da görülmüştür. Bu konuda karar sizindir, en kötü senaryo olarak bütün sistemi baştan yüklemek zorunda kalabileceğinizi düşünerek bir karar verebilirsiniz

Standartlaştırın: Tek bir üreticinin showroomu haline gelmek zorunda değilsiniz tabii ki ama kurumsal ağınızda bulunan cihaz ve yazılım türlerini sınırlandırmanın güvenlik açısından faydaları olduğu kadar yönetim işlerini de kolaylaştıracağı ortadadır.

Kural 3: Güven kuralı

Kimseye güvenmeden yaşayabilsek biz güvenlikçilerin işi çok kolay olurdu. Ne yazık ki kurumsal ağımız ve bilgilerimiz konusunda güvenmek zorunda olduğumuz pek çok farklı kişi ve sistem var. Örneğin ağımıza erişim verdiğimiz personelimize güvenmek zorundayız, bazı tedarikçilerimize veya iş ortaklarımıza güvenmek zorundayız. Bu nedenle kime nasıl güveneceğimize karar vermemiz gerekmektedir.

Kime güvenebileceğimiz konusunda karar verirken önyargılarımıza kurban olmamamız lazım. Örneğin aşağıda soldaki resim çoğumuzun “hacker” dendiğinde gözünde canlanan kişi iken, sağdaki resimde banka memuru gibi duran Gary McKinnon 2002 yılında A.B.D. ordusuna ait 97 bilgisayara sızan gerçek bir saldırgandır. Caner Koroğlu’na fotoğraf için teşekkür ederim.

Resim 2: "Hacker" fikri ve gerçek "hacker"

Kime güvenebileceğimize karar verirken kullanabileceğimiz basit bazı prensipler şunlardır:

Kontrol edemediğinize güvenmeyin: Tedarikçiler, iş ortaklarınız, danışmanlarınız gibi kontrol edemediğiniz ve kurumunuzun güvenlik politikalarına uymayan hiç bir şeye güvenmeyin.

Aslında kime güvendiğinizi bilin: Güzel bir atasözümüz “söyleme sırrını dostuna, o da söyler dostuna” der. Kurumsal dünyada da geçerlidir, siz X şirketine güvenirsiniz, X şirketinin de Y şirketine güvendiğini düşünürsek, siz de hiç tanımadığınız Y şirketine güvenmiş olursunuz.

Politikalarınızı uygulayın: Güvenlik politikaları her durumda uygulanmalıdır, söyleyecek fazla bir şey yok, uygulanmalıdır.

Örneğin bir tedarikçiniz toplantı sırasında laptopuyla kurumsal ağınıza bağlanmak istiyor. Bu durumda cevaplanması gereken bazı sorular şunlardır;

Cihaz bizim güvenlik politikalarımıza uyuyor mu?

Cihazın güvenliği sağlanıyor mu? (Laptop’ta lisanslı ve güncel bir antivirüs var mı?

Gerek olursa cihazın loglarına erişebilir miyim?

Gerek olursa cihazın güvenlik seviyesini ölçebilir miyim?

Laptop’un bilinen bir güvenlik zafiyeti var mı? (örneğin Windows XP mi?)

Kural 4: En zayıf halka kuralı

“Zincir en zayıf halkası kadar güçlüdür” klişesinden ötesi var aslında. Saldırganlar gelişmiş iletişim algoritmanızı kırmakla veya yeni aldığınız güvenlik cihazını atlatmakla uğraşmazlar. Onun yerine kullanıcılarınıza yönelik bir sosyal mühendislik saldırısı yaparlar. Zincirin zayıf olduğu soyut bir düşüncenin ötesine geçmemiz ve saldırganların kimsenin bilmediği güncellenmemiş sunucunuzu bulabileceği gerçeğini kabullenmemiz lazım.

Resim 3: Zincir en zayıf halkası kadar güçlü

Güvenlik duvarımıza 20.000 TL, sızma tespit ve engelleme sistemimize 15.000 TL ve antivirüse hiç para yatırmadıysak (yoksa) kurumsal güvenliğimize yaptığımız toplam yatırım 0 TL’dir ve güvende değiliz.

Zafiyet taraması ve sızma testleri yaptırarak zayıf halkayı saldırganlardan önce bulmak bu nedenle çok önemlidir.

Yaygın olarak görülen bazı “zayıf halkalar” aşağıdadır:

Default kurulumlar: Sunucuları, cihazları ve hatta güvenlik cihazlarını fabrika yaralarında bırakmak bu sistemler üzerinde bilinen zafiyetlerin kurumsal ağınıza girmesine neden olur.

Zayıf parola kullanımı: Diyelim ki kurumsal ağınızda 1.000 adet güçlü (güçlü parola konusunda bir yazıma http://www.alperbasaran.com/2012/12/parola-guvenligi.html adresinden ulaşabilirsiniz) ve 2 adet zayıf (123qwe veya 456asd gibi) parola var. Bütün ağınızın güvenliği 123qwe parolasına bağlıdır.

Yetersiz loglama ve izleme: Logları izlememek ve anlamlandırmamak saldırıları farketmenizi zorlaştıracağından bütün ağınızı tehlikeye atar.

Yetersiz yedek alma: Yedekleri alınmayan bilgiler ve cihaz konfigürasyonları hem veri kaybına hem de iş kaybına yol açar.

Demo amaçlı kurulumlar: Denemek için kurulan cihaz ve sistemler anlık olarak zafiyet seviyenizi arttırır.

Güncel olmayan antivirüs ve IPSler: Güncel olmayan antivirüs yazılımları sizi belirli saldırılara ve zararlı yazılımlara karşı korumasız bırakacağından hiç faydaları olmayacaktır.

Kural 5: Ayrım kuralı

Güvenliğin başlıca amacı korumamız gereken sistemleri tehdit ortamından ayırmak olduğunu düşünürsek bu kuralın ne kadar önemli olduğu bellidir. Bu kuralı uygularken sadece tehdit ortamından ayırmayı değil, sistemleri de birbirlerinden ayırmamız gerektiğini hatırlamalıyız.

Aynı sunucu üzerinden birden fazla sistemin çalışması sunucu kaynaklarının verimsiz kullanımı sonucunda sorunlar yaratabileceği gibi güvenlik seviyesini de olumsuz etkiler. Diyelim ki aynı sunucu üzerinde web, eposta ve FTP sunucularımız çalışıyor. Web sunucumuz zaten dünyanın kalanıyla paylaşmak istediğimiz internet sayfamızı barındırıyor. Eposta sunucumuz ise şirkete ait kritik bilgileri de barındıran eposta iletişimimizi tuttuğumuz yer. Biraz önce tarif ettiğim yapı ile web sunucumuzu ele geçiren bir saldırganın epostalarımızı okuyabileceği bir ortam yaratmış oluyoruz.

Ayrım kuralını uygularken aşağıdakilere dikkat etmeliyiz:

Kritik sistem ve verileri ayırın: Ayrım sadece sistemlerle sınırlı kalmamalı, önemli veya gizli verilerinizi de ayırmanızda fayda var.

Saldırıya açık sistemleri ayırın: Saldırı alması daha muhtemel olan veya bilinen zafiyetleri olan sistemleri ayırın.

Güvenlikle ilgili olanları ayırın: Güvenlik cihazlarınızı ve sistemlerinizi ayırın.

Benzerleri gruplayın: Benzer sistemleri veya aynı güvenlik seviyesinde tutmak istediğiniz sistemleri ve verileri gruplayın.

Kural 6: 3 aşamalı süreç kuralı

Yeni alınacak güvenlik çözümleri 3 aşamalı bir süreç olarak değerlendirilmelidir. Böylece satınaldığımız ama bir türlü kurulumunu tamamlayamadığımız veya istediğimiz kadar iyi çalışmayan sistemlere para harcamaktan kurtuluruz.

Değerlendirmemiz gereken 3 aşama; kurulum, izleme ve bakımdır.

Kurulum: Yeni ürün alımı detaylı bir analiz sürecinden sonra yapılmalıdır. “Şu anda nasıl bir güvenlik seviyemiz var?” sorusunu cevapladığımız ve eksik gördüğümüz yerleri iyileştirmek için bir çözüm düşündüğümüz aşamadır. Bu aşamanın sonucunda bir ürün almaya karar verebiliriz.

İzleme: Kurulan cihazı kimin yöneteceğine karar verilmesi, bu cihaza ilişkin nelerin takip edileceği, cihazın işletim sisteminin ne zaman ve nasıl güncelleneceğinin belirlenmesi gereklidir. Güvenlik cihazları aktif cihazlardır ve etkili şekilde kullanılmaları da buna uygun bir modelin oluşturulması ile mümkündür.

Bakım: Genel olarak güncellenmemiş güvenlik cihazları bir süre sonra saldırıları (özellikle son güncellemeden sonra çıkanları) tespit edemeyeceğinden işlevlerini yitirirler. Bunun farkında olmamak bizde sahte bir güven duygu yaratacağı için güvenlik cihazının hiç olmaması kadar tehlikeli bir durumdur.

Kural 7: Önleyici faaliyet kuralı

Büyük ihtimalle uygulaması en zor kuraldır. Güvenlik konusunda proaktif önlem almak için yönetime başvurduğumuzda net veya bilinen bir sorunu adreslemediğimiz için derdimizi anlatmamız zor olabiliyor. Bu nedenle de proaktif tedbirleri almak genelde zordur.

Ağınızdaki sistemlerin bilinen zafiyetlerini yakından takip etmek, düzenli kontroller yapmak ve 3 aşama kuralının sağlıklı bir şekilde işletilmesi proaktif güvenlik konusunda atılabilecek en temel adımlardır.

Düzenli olarak sızma testi yaptırmak ve bulguları adresleyerek çözüm bulmak ise proaktif bilgi güvenliği süreçlerinin oturmasını sağlayacaktır.

Kural 8: Anında ve doğru tepki kuralı

Kabul edin veya etmeyin saldırı altındasınız. Şu ana kadar bir saldırı tespit edememiş olmanız saldırı tespiti ve dolayısıyla önlenmesi konusunda yetersiz bir yapınızın olduğunun kanıtıdır. Biraz iddialı bir cümle oldu ama ne yazık ki gerçek bu.

Saldırıları tespit etmek için gerekli ve etkili bir sistem kurulması şarttır, sekizinci kuralın işletilmesi de buna bağlıdır.

Saldırı tespit edildiğinde yapılması gereken şeylerin bazıları aşağıdadır;

Paniklememek: Güvenlik ihlali dünyanın sonu değildir, paniklemeyin, sadece süreci işletin.

Müdahale sürecinizi belirleyin: Çok uzun ve sayfalar dolusu formun doldurulmasını gerektiren bir süreç olması gerekmez. Tutarlı ve etkili bir plan olması yeterlidir.

Kime haber vereceğimizi bilelim: Güvenlik ihlali tespit eden veya güvenlik ihlali olmasından şüphelenenlerin kime ve nasıl haber vermesi gerektiği belli olmalıdır.

Herkes plana uymalıdır: Panik durumunu veya olayın aslından daha da yıkıcı hale gelmesini engellemek için herkesin plana uyması şarttır.

Olay sonrası: Olayın gerçek büyüklüğü anlaşılmalıdır. Önceki örneklerden gidersek; web sunucusuna sızıldıysa buradan eposta sunucunuza geçilmediğinden emin olmalısınız. Olay iyi anlaşılmalı, tekrarlanmaması için önlemler alınmalı ve her şey kayıt altına alınmalıdır.

Boşa giden 250 milyon dolar

250 Milyon Dolar… Fikir vermesi için bu rakam JP Morgan Chase bankasının sadece 2014 yılında bilgi güvenliğine yaptığı yatırımdır. 
Bu ölçekte güvenlik yatırımları yapan bir bankanın hacklenmesi tek başına kötü bir haber iken, FBI’ın bu olayın 5 diğer küresel bankayı da hedef alan daha geniş kapsamlı ve planlı bir saldırının parçası olup olmadığını araştırıyor.

JP Morgan’da ne oldu?
Aklımıza ilk gelen soru sadece güvenliğe 250 milyon dolar harcayan bir yerin nasıl hacklenmiş olabileceğidir. 
Herşeyden önce bilmemiz gereken şey saldırının bir anda olmadığıdır. Filmlerden alışkın olduğumuz şekilde gecenin karanlığında klavyesinde birşeyler yazan siyah giyimli ve önünde terminal ekranı olan bir kişinin saldırısı değil. Yayınlanan raporlardan gördüğüm kadarıyla saldırganlar JP Morgan Chase sistemlerinde 2 aydan fazla süre tespit edilmeden dolaşmışlar. 

Saldırının başlangıcı ve hackerların banka sistemlerine ilk sızdıkları noktanın bankanın internet sayfası olduğu düşünülüyor. Web sayfasında bulunan bir zafiyet istismar edilerek web sayfasının bulunduğu sunuculara erişim sağlayan saldırganlar veri merkezinde bulunan diğer sunuculara sızmışlardır
.
Saldırının 5 önemli adıma bakarak aşağıdaki saldırı sürecini çıkartabiliriz.

Adım 1: Saldırganlar bankaya ait internet sitesinde bir güvenlik açığı tespit ediyor

Adım 2: Bu güvenlik açığından faydalanan saldırganlar web sitesinin barındırıldığı sunucuyu ele geçiriyor

Adım 3: Bankanın sunucu havuzu içerisinde yatay hareket

Adım 4: Bankacılık işlemlerinin tutulduğu sunuculara sızıyorlar

Adım 5: Ele geçirdikleri hassas verileri aralarında Brezilya ve Rusya’nın da olduğu çeşitli ülkelerde bulunan sunuculara gönderiyorlar. 

Saldırıların her aşamasında “0-day” güvenlik açıklarından ve istismar kodlarından faydalanılmış olması saldırganların bilgi ve beceri seviyesinin oldukça yüksek olduğunun bir kanıtıdır. “0-day” (sıfırıncı gün) açıkları bulunmuş ancak henüz üretici veya kamuoyu tarafından bilinmeyen güvenlik açıklarıdır. Bu güvenlik açıkları uluslararası ticarete konu olmaktadır ve önemli açıklar milyonlarca dolara varan fiyatlarla satılmaktadır. Bu olaydaki saldırganlar ya teknik kaynakları olduğu için açıkları kendileri tespit etmiş, veya finansal güçlerini kullanarak bu açıkları piyasadan satınalmışlardır.

Saldırının başarıya ulaşmış olması ise bize saldırganların bu işe zaman ve kaynak ayırdıklarını gösteriyor. Öncelikle bankanın gelişmiş sızma tespit ve önleme sistemleri özel olarak geliştirilmiş zararlı yazılımlar ve istismar kodları kullanılarak atlatılmıştır. Bu ukodları yazmak ve bankanın kullandığı güvenlik sistemleri hakkında bilgi toplamak teknik bilgi, zaman ve birden fazla alanda beceri gerektiren bir süreçtir. İkinci aşamada ise 1 aydan fazla sürede banka sistemlerinden dışarıya gönderilen gigabaytlarca verinin aktarımının bankanın veri sızdırma (Data Loss Prevention – DLP) sistemlerini atlatacak şekilde yapılması yine saldırganların sıradan kişiler olmadığını kanıtlamaktadır. 

Yıllık bütçe raporunda “2014 yılının sonuna kadar bilgi güvenliğine 250 milyon dolar yatırım yapacağız ve bilgi güvenliği kadromuzu 1000 kişiye çıkartacağız” diyen bir bankanın bile hacklenmesi bu kadar kolayken daha küçük ölçekli finans kuruluşları ve özel şirketler kendilerini nasıl korur? Öncelikle bu saldırıdan gerekli dersleri çıkarttığımızdan emin olmalıyız.

JP Morgan Chase olayından çıkartılacak dersler

İlk ders, her zamanki gibi, güvende olmadığınız gerçeğini kabul etmektir. Yeni aldığınız firewall veya laptoplarınızdaki antivirüsler size güvenlik sağlamaz. Güvende olmak için cihazların ve yazılımların ötesine geçerek genel güvenlik seviyesi ele alınmalıdır. Mesela firewall’un sadece port engelleme yaptığını ve insanların web sayfanıza ulaşabilmeleri için 80.portu açık tutmanız gerektiğini ve büyük ihtimalle IPS/IDS’in (sızma tespit ve engelleme sistemi) iyi yazılmış bir SQL injection kodunu yakalayamayacağını kabul etmeniz gerekir. 
Ders 1: 250 milyon Amerikan Doları bile harcasanız hacklenebilirsiniz

Saldırının nispeten önemsiz gibi görünebilecek bir yerden başladığına dikkat etmek lazım. Öyle ya, banka bile olsa internet sayfalarında müşteri hesap bilgilerini tutmayacaktır. İnternete açık her sistemin, güvenlik kameraları, POS cihazları, cep telefonları, sıra matikler dahil olmak üzere, saldırıya uğrayabileceğini bilmek gerekir. İnternete açık bir şey için şu cümlerlerden birini kullanıyorsanız yakın zamanda başınıza kötü bir şey gelebilir; “kimse bununla uğraşmaz”, “IP var sadece, bunu bulamazlar” veya “şifreyi bilmeyen giremez”…
Ders 2: Bir şey internete açıksa birileri bulur ve saldırır. 

JP Morgan Chase saldırısının 5 temel adımdan oluştuğunu gördük. Daha küçük hedeflere yönelik saldırılar da aynı şekilde birden fazla adımdan oluşan bir zincir ile gerçekleştirilmektedir. Yukarıdaki senaryoda saldırganların web sayfasının bulunduğu sunucuları ele geçirdikten sonra diğer sunuculara erişemediğini varsayalım. Bu durumda Bankanın başına gelebilecek en kötü şey web sayfalarına “h4ck3d by l33tsec” türü yazı eklenmesi olacaktı. Benzer şekilde saldırganlar sistem sunucularından müşteri işlemlerinin tutulduğu sunuculara geçemeseydi müşteri verilerine ulaşamayacaklardı. Son olarak da ulaştıkları verileri dışarı gönderemeselerdi yine sorun büyük ölçüde azalacaktı. Zafiyetleri ve potansiyel saldırı vektörlerinin ortaya çıkartılmasının yanında, risk analizleri sırasında önem verdiğim noktalardan birisi de bu tür “kâbus zincirlerini” ortaya çıkartmaktır. Bulduğum her zinciri birden fazla yerinden kopartarak benzer senaryoların yaşanmasını önlemeye çalışıyorum. Böylece saldırgan sisteme sızsa bile sistemden bilgi sızdıramayacak veya sızdığı sistemden bir diğerine atlayamayacaktır. 
Ders 3: Başınıza gelebilecek en kötü şey için bir araya gelmesi gerekenleri bulun ve bir araya gelmediklerinden emin olun. 

Yapılan saldırıların ürettiği logları düşünürsek daha küçük ölçekli bir bankada veya herhangi bir Türk bankasında dikkat çekecek kadar garipler. Özellikle dışarı bilgi gönderildiği aşamada Brezilya ve Rusya’da bulunan sunuculara yapılan veri transferi basit bir scriptle bile kolayca ortaya çıkartılabilecektir. Sadece sızdırılan bilgiler değil, zararlı yazılımların komuta sunucuları ile olan iletişimi de bu şekilde yakalanabilir.
Ders 4: Ağınızdan çıkan trafiği izlemeniz çok önemli.

Diğer öneriler
Bu olaydan almamız gereken derslerin devamı olarak bazı basit önerilerim olacak;

Web sayfanızı dışarıda tutun: Hayır, DMZ’de değil, tamamen dışarıda. Bir hosting hizmeti alacak şekilde dışarıda.

Güvenlik analizleri yaptırın: Sızma testlerinin dışında da bu tür saldırı senaryolarının ortaya çıkartılacağı çalışmalar yaptırın

Sistemlerinizin kendi aralarında ne konuştuklarını takip edin: Örneğin web sunucunuz ile dosya sunucunuzun iletişim kurmasını gerektirecek bir neden olup olmadığını araştırın. 

Hata loglarını takip edin: Ne kadar iyi olursa olsun hacker hata loglarına neden olacaktır. Bunları tespit etmek, saldırıyı ve saldırganı tespit etmek için hayati önem taşır.

Güvenlik duvarı (firewall) yönetimi ipuçları

Kurumsal bilgisayar ağlarının önemli bir kısmının ilk savunma hattını güvenlik duvarları (firewall) oluşturuyor. Gözümüzde Çin Seddi gibi canlandırdığımız bu cihazların kullanımı ve yönetimi konusunda bazı genel ipuçlarını toparlamak istedim. Unutmayalım ki en gelişmiş güvenlik çözümleri bile onu yönetenlerin imkan tanıdığı ölçüde bizleri koruyabilir.

Güvenlik duvarı algısı (temsili)

Dokümantasyon

ISO kalite standartları dünyasında “yaptığını yaz, yazdığını yap” diye bir cümle vardır. Güvenlik duvarları içinse bu konu hayati önem taşımaktadır. Güvenlik duvarının kurulduğu topoloji (tek hat üzerinde, iç/dış güvenlik duvarı olarak veya 3 bacaklı topoloji) ve üzerindeki kuralların yazıya dökülmelidir. Bundan sonra da yapılacak her topoloji veya kural değişikliği, yazılı olarak kayıt altına alınmalıdır.

ANY sadece DROP kapsamında kullanılmalıdır

Kurumsal ağlarda “TCP ANY ANY ACCEPT” kuralını her gördüğümde bir kumbaraya 50TL atsaydım şimdiye kadar iyi para biriktirmiştim. Bu kuralı kimse bilerek girmiyor tabii ki ama bir test yapılırken veya bir sorunun kaynağı araştırılırken bu kural giriliyor ve orada unutuluyor.

Prensip olarak güvenlik duvarı kuralının her hangi bir yerinde ANY varsa ve bu dünyaya açık bir web sunucusu vs değilse kural mutlaka DROP ile yazılmalıdır.

Bazı durumlarda, tek bir trafik yönlendirmesi için, birden fazla kural yazmanız gerekebilir ama bu ağınıza birilerinin sızmasından iyidir.

Kural değişiklikleri

Güvenlik duvarına kural eklerken veya mevcut kuralları değiştirirken bunu neden yaptığımızı bilmemiz şarttır. Güvenlik duvarları aslında kurumsal bilgi güvenliği politikalarının (veya genel olarak kabul görmüş güvenlik önlemlerinin) gerçek dünyaya bir yansımasıdır. Yapılan değişikliklerin güvenliğimizi arttırması veya en azından mevcut güvenlik seviyemizi kötüleştirmemesi şarttır. Kural değişiklik talebinin nereden geldiği ve neden gerekli olduğu anlaşılmalıdır. Bundan bir süre önce bir kamu kurumunda gözlerimin önünde güvenlik duvarı kuralları “XXX entegratör firmadan gelen teknisyenin” talebi üzerine anında yapılıvermişti. Hatırladıkça tüylerim diken diken olur. Entegratör firmanın teknik elemanın yaptığı/yapacağı bir demo için güvenlik duvarında 15 – 20 port açtırması kabul edilebilir birşey değildir.

Vedalaşmayı bilin

Artık geçerli olmayan veya kullanılmayan kuralların silinmesi gerekir. Kural silme sürecinin de tıpkı yeni kural girişi gibi belgelenmesi önemlidir. Güvenlik duvarı kurallarını yazanların yeni alımlar, güncellemeler ve devreden çıkartmalar konusunda bilgilendirilmesi gerekmektedir.

Senede 1 gün

Yılda en az bir sefer güvenlik duvarının mevcut durumu analiz edilmeli ve gerekli iyileştirmelerin hızlıca yapılması gerekmektedir. Bu analiz sırasında sızdırmazlık testlerinin, güvenlik duvarı işletim sistemi güncellemelerinin kontrolünün ve topoloji değerlendirilmesi yapılmalıdır.

Diğer ipuçları:

• Kullanılan servisler dışındaki kapatın
• Güvenlik duvarını yetkili kullanıcı dışında bir kullanıcı ile çalıştırın
• Fabrika çıkışı ayarlanmış kullanıcıları/parolaları değiştirin
• Sadece paket filtrelemeye güvenmeyin
• Güvenlik duvarı bir yazılımsa mutlaka sıkılaştırılmış bir işletim sistemi üzerinde çalıştırılmalıdır
• İç ağdaki trafiği de güvenlik duvarından geçirin
• Güvenlik duvarı loglarını düzenli olarak inceleyin
• Güvenlik loglarını düzenli olarak yedekleyin
• Güvenlik duvarı üreticisinin güvenlik uyarılarını yayınladığı mail listelerini takip edin
• Kurallara isim verirken belirli bir yöntem kullanın
• Benzer kuralları alt alta toplayın
• Geçici kurallar için “notlar” kısmına devreden çıkartma tarihi yazın
• Güvenlik duvarının yönetim arayüzüne erişmek için en güvenli yolu tercih edin
• Güvenlik duvarı üzer,nde açılması gereken "tehlikeli" bir servis varsa, bunların da güvenli alternatifi tercih edilmelidir (Telnet yerine SSH gibi)

Güvenlik duvarının sizi sadece sınırlı sayıda tehdide karşı koruduğunu hatırlamak gerekir. Bunlarla birlikte bir sızma tespit ve engelleme sisteminin veya eposta güvenliğini sağlayacak bir çözümün konumlandırılmasında fayda vardır.