Showing posts with label IDS. Show all posts
Showing posts with label IDS. Show all posts

Sunday, November 23, 2014

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.

Tuesday, November 11, 2014

Other Links of the Cyber Kill Chain


My blog is in Turkish but as this post was commented on in a rather large English speaking group, I wanted to spare anyone who'd be interested the pain of having to read it using Google translate. This post followed a post introducing the "Cyber Kill Chain" concept. 

Lockheed Martin, the company manufacturing aircrafts such as F-16, F-117 and the F-35 introduced the term "Cyber Kill Chain".

Pic 1: F-35 manufactured by Lockheed Martin

Pic 2: Turkey is one of the countries involved in the F-35 project

The "Cyber Kill Chain" approach introduced by the Incident Response Team at Lockheed Martin can be considered as a list of "unfortunate events" that are required for an attack to be successful.

The steps of a successful attack can be briefly listed as follows:
  1. Information gathering: Gathering information on the target. This step also include "Open Source Intelligence" (gathering information freely and openly available about the target) so the attacker can have a better understanding of the target.  
  2. Weaponization: Preparing the necessary software, backdoor or exploit code for the attack.
  3. Delivery: Sending the weaponized code to the target.
  4. Exploit: Activate the backdoor or exploit code to gain initial access to target systems. 
  5. Installation: Installing persistent backdoors and other code needed to move within the target network.
  6. Taking command: Gaining remote access to target systems and/or network.
  7. The kill: Performing the real attack depending on the needs of the attacker (leaking or deleting data, eavesdropping, etc..) 

Breaking the above mentioned chain in one or several steps will stop the attack or seriously cripple its success. Focusing on breaking this "Cyber Kill Chain" should be considered as a viable and efficient defense technique. However, it should be noted that the step at which we can break the chain will impact the cost and complexity of the defenses required. For example, placing a firewall is easier compared to a complex log gathering and correlation solution that aims to uncover possible malicious movements within the network. 
It would be safe to assume that aiming to break the chain as early as possible will, not only be easier and cheaper, but also provide us with an additional layer of security. There isn't much that can be done about the reconnaissance step as it's relatively hard to control information indexed by third parties. 
Perimeter security measures such as IDS/IPS (Intrusion Detection System / Intrusion Prevention Systems) or firewalls will try to avoid the initial breach. Having different VLANs, controlling LAN traffic with a firewall and monitoring logs we can stop the attacker from moving within the network or installing more backdoors. 
This is where vulnerability management comes into play, as an additional layer of security between the open source intelligence gathering and the attack. 
Vulnerability scanning will give us an overview about how vulnerable our systems and network are to an attacker. One might easily argue that vulnerability scanning won't provide every single attack vector that can be exploited by a skilled attacker and be right. As a strong believer in the "golden mean" or its more understandable version "perfect is the enemy of good", I think we shouldn't dismiss vulnerability scanning as an effective proactive security measure just because "it's not a pentest" or "hackers don't use Nessus" or "they can APT the hell out of you anyway". 
Basically, an attacker can have 3 good attack vectors he can use to gain access to the target system and network. These are; systems that can be reached from the internet, systems that can reach the internet and internal systems with known vulnerabilities. 
Systems that can be reached from the Internet: Knowing what systems are reachable from the Internet is vital. Any attacker worth his/her salt will be able to locate every Internet facing IP in your network. When we hear the words "Internet facing" we tend to think about that web server in our DMZ or such. I wih life was that simple. There have been many times I've found servers and clients open to the internet about which the Admins knew nothing. Regularly controlling all internet facing systems within your IP range will able you to spot these before attackers do (proactive security at its finest). 
Systems that can reach the internet: Basically all your clients. We need to remember that browsers are not the only systems that can reach the internet. Things such as instant messaging solutions and stock market tracking applications should also be taken into account. 
Known vulnerabilities on internal systems: This is the MS08-067 or the unpatched windows we find during penetration tests. They provide a good foothold for any movement within the network. 
These 3 attack vectors provide good opportunities to break the kill chain. 

Pic 3: "Cyber Kill Chain" facing an effective vulnerability management process (representational)

Creating and implementing even a basic vulnerability management process will provide an extra layer of security. Imagine having an invisible layer between the step where the attacker gathers information on your company using Google and the step here he/she is trying to avoid being detected by the IPS. 
A vulnerability management system can even be implemented using an open source vulnerability scanner such as OpenVAS or using a more rounded commercial tool such as Tenable's Security Center. 

Pic 4: Screenshot from Tenable Security Center 

Sunday, August 31, 2014

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.






Sunday, May 4, 2014

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. 

MITRE ATT&CK Gerçek Hayatta Ne İşimize Yarar?

  Rusya kaynaklı siber saldırılar webinarı sırasında üzerinde durduğum önemli bir çalışma vardı. MITRE ATT&CK matrisini ele alıp hangi...