OSSIM Nasıldır?
 |
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ş.