Dayıoğlu Günlüğü

Zaman zaman karşılaştığımız sertifika zaman aşımı problemi bu kez LinkedIn‘i vurmuş gibi görünüyor. LinkedIn’in bir yıllık ssayısal sertifikası bugün sonra eriyormuş ve bir şekilde yenilenmemiş.

Daha önce Türkiye’de bankaların ve büyük e-ticaret sitelerinin bile başına sertifikanın zaman aşımına uğraması ile ilgili sıkıntılar gelmişti. Sanırım genel problem iki temel noktadan kaynaklanıyor; birincisi sayısal sertifikalar çok ucuz ve küçük ticari metalar olduğundan kuruluşlar bunu sürekliliği takip edilecek kontrat ya da lisans gibi ele almıyorlar ve yenilemesini sistematik takip etmiyorlar. İkincisi, hafızam beni yanıltmıyorsa en azından Thawte, Comodo ve Verisign gibi sertifika sağlayıcılar bir iki ay öncesinden hatırlatma mesajı göndermemekte ısrar ediyorlar.

İkincisi için kuruluşların yapabileceği çok bir şey yok ama en azından sertifikaların da kontrat ya da lisans gibi geçerlilik süresinin takip edildiğini ikinci bir kez kontrol etmekte ve işi sistematiğe bindirmekte ciddi bir fayda var. Yoksa Allah göstermesin bir gün LinkedIn’in başına geldiği gibi pazar pazar sertifikasız kalıp Thawte peşinde koşturmak zorunda kalabilirsiniz.

Bir süredir Security Information and Event Management (SIEM) alanında çözüm önerdiğimiz kuruluşlardan OSSIM’i de bir seçenek olarak değerlendirdiklerini duyuyorum. Daha önce incelemediğim bu ürünün LinkedIn’de de nasıldır? diye sorulduğunu görünce bir cevap yazmıştım. Hala çevremde OSSIM nasıldır? diye soranlar olduğundan genişletilmiş bir değerlendirmeyi buraya da yazmaya karar verdim.

Benim baktığım yerden OSSIM aşağıda vereceğim gerekçeler ile kurumsal ölçekte kullanılabilir bir durumda değil. Altyapınız çok büyük ağırlık ile özgür yazılımlardan oluşuyorsa ve az sayıda sisteminiz/sunucunuz varsa kullanmayı deneyebilirsiniz ama heterojenlik arttıkça, ticari ürün kullanımınız arttıkça ve bilgi işlem altyapınız büyüdükçe OSSIM kullanılabilir olmaktan uzaklaşıyor. İşte bence gerekçeleri:

• Parser’ları son derece kısıtlı ve ağırlıklı olarak özgür yazılımlar için parser var. Bu durum, ticari ürünlerden log toplasanız bile (ki az sayıda ticari ürün için - Realsecure, Cisco IDS vb. destekleniyor) logları kolayca anlamlı hale getiremeyeceğiniz anlamına geliyor. Rakip ticari ürünlerin yüzlerce farklı log türü için parser’ı ile karşılaştırıldığında epey zorlayıcı olabilir. Eğer yanlış bilmiyorsam uygulama sunucuları ve veritabanı sunucuları için parser’lar yok.
• Pek çok ajan (ya da collector) doğrudan syslog üzerinden log toplama ve loglarla çalışmaya yönelik olarak geliştirilmiş. Bu nedenle (neredeyse) tüm log altyapınızı syslog üzerinden çalışacak hale getirmeniz gerekiyor ki büyük kurumsal yapılarda pek tercih edilebilir olduğunu düşünmüyorum. Ürünlerin doğal (native) iletişim protokolleri ile log toplayabilmek pek çok kez bir dizi avantaj ile geliyor ki OSSIM kullanıcıları bundan faydalanamıyorlar.
• Ürünün README belgesinde açıkça ifade edildiği gibi, OSSIM’in hedefi özgür yazılım güvenlik ve ağ izleme yazılım portföyünü desteklemek; bu alandaki ticari ürünlerde gördüğümüz gibi her tür log kaynağından bilgi toplayıp güvenlik alarmları üretmek ve güvenliği merkezi izlemek değil.
• Doğrudan ilişkisel veritabanı yönetim sistemleri üzerinde çalışıyor ve MySQL ya da PostgreSQL destekliyor. Üst uçta log toplayacak ve yönetecek sistemlerin performans, veri hacmi büyümesi (veritabanı indeksleri, kolon fazlalıkları vb.) gibi gerekçeler ile ilişkisel veritabanları üzerinde değil özel tasarlanmış depolama altyapıları ile çalışmaları genellikle tercih ediliyor. Performans testi yapmadım ama saniyede 3-5 bin log’dan daha fazlasını işleyebilecek yapıda olduğunu sanmıyorum. Pek çok raporu alabilmek için çok sayıda destek script’i var ki raporları almak için bu script’ler ile veritabanı view’larının oluşturulması gerekiyor. Bunların hepsinin ciddi performans problemlerine neden olmasını beklemek hiç şaşırtıcı olmaz.
• Pek çok şey kodun içine gömülü (hardcoded) durumda ve veritabanı/kural güncellemeleri ile yenilenebilir durumda değil. Yazılımı güncellemediğiniz sürece (kodların yenisi gelmiyorsa) pek çok parser ayarı ve logları anlamlı olaylara eşleyen veritabanı kayıtları hiç bir şekilde güncellenmiyor. Sürekli bir güncelleme mekanizmasının olmaması yeni log anlamlandırma kuralları, tanımlar, korelasyon kuralları vb.’ni alamayacağınız anlamına geliyor. Oysa esas konu logları toplayıp tek bir havuza topladıktan sonra başlıyor; logları anlamlandırmak ve loglar arasında ilişki kurmak için “güncel bilgiye” ihtiyaç var.
• OSSIM daha önce ACID olarak bildiğim bir yazılımı geliştirerek üretilmiş. ACID 2000-2002 arasında Snort loglarını analiz etmek için kullandığımız bir web arayüzüydü ve yüksek lisans tezimi yazdığım dönemde epeyce kullanmıştım. ACID’in tüm veri yapısı ağ olaylarını (network events) işlemek üzere geliştirilmiş; OSSIM veritabanı da büyük oranda aynı şekilde duruyor. Dolayısı ile tutacağınız loglar IP adresi, port numarası vb. içeriyorsa güzelce parçalanıp veritabanında saklanması mümkün ama (örneğin) uygulama sunucusu kayıtlarını saklamak için ideal bir veri yapısı olduğunu söylemek mümkün değil. Basitçe, OSSIM sistem olaylarını (host events) analiz etmek üzere tasarlanmamış.
• Yazılımın kaynak koduna göz atarken en az beş farklı noktada koda gömülü veritabanı parolaları gördüm, averaj bir sistem yöneticisinin bu parolaların hepsini değiştirmesi (ve hata yapmaması) kolayca mümkün değil. İyi derecede programlama bilen bir sistem yöneticisi lazım olabilir. Aksi durumda ön tanımlı parolalar ile yıllarca birlikte yaşamak zorunda kalabilirsiniz.
• Kodun içerisinde gezerken yüzün (100) üzerinde noktada FIXME (beni tamir et) notları gördüm; bu da yazılımın içerisinde üreticisi tarafından bilinen çok sayıda hata olduğu gösteriyor. Hatta korelasyon ile ilgili kodların hemen üzerinde “We have to re-think this” (bunu tekrar düşünmemiz lazım) yazıyordu; yorumlamaya lüzum var mı bilmiyorum.
• NAT’lı adresler ile çalışamıyor, eğer logu toplanıp izlenecek sistemlerinizin bazıları NAT arkasındaysa onları izleyemeyebilirsiniz.
• Korelasyon hemen her zaman IP adresleri ve port numaraları ile yapılıyor. İstatistiksel korelasyon, kural tabanlı korelasyon gibi gerçek korelasyon özellikleri yok. Bu da aslında aralarında anlamlı ilişki olan logları bir arada görmenin pratikte mümkün olmayacağı anlamına geliyor. Bir korelasyon var ama bundan bir şey beklemek çok haksızlık olur.
• Eğer 200-300 sistemden daha fazlasından log toplayacaksanız denememelisiniz; çalışmayacağı README belgesinde yazıyor.
• Parser’lar konfigürasyon değişikliklerinde otomatik olarak yeni konfigürasyonu yüklemiyorlar; durdurup tekrar başlatmanız gerekiyor.

Özetle, os-sim-0.9.9rc5.tar.gz ve ossim-agent-0.9.9rc5.tar.gz paketlerini inceledimde gördüklerim hiç de iç açıçı şeyler değiller. Diğer taraftan OSSIM’in kullanılmasına da hiç karşı değilim, yılların Linux’çusu olarak pek çok özgür yazılımı büyük bir keyifle kullanıyor ve kullandırıyorum ama bu yazılım bana göre henüz pişmemiş.

Amerikan Savunma Bakanlığı’na bağlı bir birim olan Bilgi Güvencesi Teknoloji Analiz Merkezi (IATAC) geçtiğimiz yılın ortasında yazılımlarda güvenlik güvencesi (software security assurance) ile ilgili bir Ulaşılan Son Durum Raporu (State of the Art Report) yayınlamış. Benim rapordan iki ay önce haberim oldu, heyecanla bastırıp masama koymama rağmen daha yeni okumayı tamamlayabildim. Raporun bir kopyasına buradan ulaşabilirsiniz.

Rapor yazılım geliştirme süreçlerinin/ortamlarının sağladığı güvence, bunun Amerikan kamu ve savunma sektörleri için önemi ve teknoloji ve süreçler açısından bugün ulaşılan durumu harika özetlemiş. Konuya Amerika’daki tarihsel gelişimi çerçevesinde de bakabildiği için konunun nasıl yıllar içerisinde yükselip bu günün en önemli güvenlik konularından biri haline geldiği de çok net görülebiliyor. Yazılım güvenliği konusuna meraklıysanız, teknolojinin derinliklerine de gömülmeden, konuya geniş bir perspektiften bakabilen bu rapora göz atmanızı öneririm.

Kartlı ödeme altyapılarında kullanılan uygulamalar için geliştirilen Payment Applications Data Security Standard (PA-DSS) artık resmiyet kazandı. Raftan alınıp satılacak ödeme uygulamalarının bundan böyle PA-DSS standardına uygun olması gerekecek

Standart, denetim prosedürü ve diğer destekleyici belgelere https://www.pcisecuritystandards.org/tech/pa-dss.htm adresinden erişebilirsiniz.

Bu hafta duyduğum en önemli teknoloji haberlerinden birisi Türk Telekom’un Maliye Bakanlığı ile anlaşarak faturalarını bundan sonra kağıdın yanında elektronik ortamda da işleyeceğiydi. Türk Telekom’un kendi duyurusuna buradan erişebilirsiniz.

Faturaların elektronik ortama taşınabilmesi için yasal zemin daha önce hazırlanmıştı ama bildiğim kadarı ile uygulamaya geçen kuruluş henüz yoktu. Türk Telekom bu hamle ile 20M+ abonesi için bastığı faturaların (yasal zorunluluk olan) kendisinde saklayacağı kopyasını elektronik ortama taşıyacak, dileyen müşterilerine de kağıtta değil ama elektronik ortamda fatura gönderecek. Doğal olarak hepimizin en kısa zamanda Telekom faturalarımızı elektronik hale dönüştürmemizde çevre koruma açısından fayda var.

Bu konunun bence en ilginç noktalarından birisi yazımın başlığına da taşıdığım gibi PTT’nin bu konuda ne tür açılımlar sağlayacağı. Bildiğim kadarı ile fatura dağıtımı PTT’nin şu andaki en büyük işi, bu işin bir biçimde ortadan kalkması (ya da ciddi biçimde daralması durumunda) PTT’nin çok hızlı bir dönüşüm göstermesi gerekecek. İnşallah PTT yönetimi bu konunun kuruluşlarının varlık gerekçesini ciddi zorlayacak bir gelişme olduğunun farkındadır; dönüşüm ve açılımlarının ne yönde olacağını merakla bekliyorum.

Türkiye temsilciliğini yürüttüğümüz Fortify Software yazılım kalite güvence testlerini kolayca güvenlik testlerini de kapsayacak şekilde geliştiren yeni bir çözümü ürün haline getirdi.

Patent vs. süreçleri tamamlansın diye bir süredir beklediğimiz bu teknoloji sayesinde yazılım ürünlerinin geliştirme sürecindeki kalite güvence testlerine kolaylıkla güvenlik testlerinin eklenmesi mümkün olacak. Yazılım binary’lerinin (java ve .net için) içine gömülen bu teknoloji ile kodun içerisindeki tüm akışlar test süreçleri boyunca takip edilebiliyor ve güvenlik problemlerinin ortaya çıkartılması sağlanabiliyor. Ayrıntılı bilgilere buradan göz atabilirsiniz. Gerçekten yaklaşım olarak oldukça ilginç, bildiğim kadarı ile bir benzeri de (en azından şimdilik) yok.

Bu logoyu ve ardındaki firmayı hatırlayanlarınız mutlaka olacaktır. 1990′ların sonunda kurulan @stake yıllarca bilişim güvenliği sektörünün danışmanlık alanındaki lider firması olarak hizmet verdikten sonra 2005′te Symantec tarafından satın alınmıştı.

Hizmet verdiği dönemde bilişim güvenliği sektörünün bugün herkesin çok yakından tanıdığı pek çok ismini bünyesinde barındıran @stake’in öyküsünü okurken çok keyif aldım. SearchSecurity eski @stake’cilerden Chris Wysopal, Christien Rioux ve Chris Eng ile çok keyifli bir sohbet yapmış. Okumanızı öneririm, metin burada.

ABD’nin bir tür yasak kararı için “darısı başımıza” diyeceğim hiç aklıma gelmezdi, bu da oldu. 1 Şubat’ta geçerli olacak yeni bir düzenlemeye ilişkin haberi az önce DarkReading‘de gördüm. Habere göre Federal Hükümet Çekirdek PC Konfigürasyon Standardı belgesi sıradan kullanıcıların Windows XP ve Vista’larını Administrator olarak kullanmalarını yasaklamış, böylece yalnızca sistem yöneticileri Administrator yetkisi ile giriş yapabilecekler.

Bu düzenlemenin bir benzerinin Türkiye’de kamu için acilen çıkartılmasını talep ediyorum. Biz de en az bilgi işlemciler kadar biliyoruz bu işi diyen kamu personeli ve onların kamu bilgi işlemcilerine çektirdikleri azabı gören herkesin aynı şeyi düşüneceğini tahmin ediyorum. Dediğim gibi, darısı başımıza…