Security Blog

Log Yönetim Sistemi neden ve nasıl yapılır?

Bir firmanın log yönetim sistemini tahsis etmek genellikle çok zordur. Belirgin proje hedeflerinin eksikliği ve gerekli hazırlık aşamalarının zayıflığı gibi sebepler bu zorluğun temelini oluşturur.

İki adet ana log yönetim sistemi tipi bulunmaktadır:

  • Bilgi Yönetim Sistemi
  • Olay Yönetim Sistemi

İki sistem için oluşturulmuş hedefler çok farklı

Bir Bilgi Yönetim Sistemi bütünlük, gizlilik ve erişilebilirliklerini koruyabilmek için log dosyalarının oluşturulmuası, toplanması, analiz edilmesi ve depolanmasını sağlayan erişim kontrol çözümüdür. Bir log dosyası işlem yapananın kim olduğu bilgisi, zaman referansı ve yerine getirilen komut ya da sorgunun belirteçlerini taşımaktadır.

Bir Olay Yönetim Sistemi, güvenlik olaylarının tespit edilmesi için gerekli bilginin bulunmasını hedefler. Bu olayların belirlenmesi sırasında ağ cihazları ve sistemleri ile IDS/IPS’lerin kaynak olarak kullanılması sayesinde elde edilen yüksek miktarda veri bulunmaktadır. Bu işlem sırasında zararlı yazılım ya da olası saldırılarla bağlantılı “pattern”leri keşfetmek için veri madenciliği uygulanmaktadır.

Saf teknolojik bir bakış açısıyla, yukarıda sözü edilen kategoriler ortak öğelere sahip olabilir. Yine de her iki görevi belirgin projelerde birbirinden ayırarak adreslemek, daha sonra log toplama, log ayırma gibi ortak bileşenleri tekrar kullanmak faydalı olmaktadır.

Bu makalede, ilk tipe odaklanılacak, başarı elde etmek için gerekli tüm proje aşamaları ele alınacaktır.

Düşülen klasik hatalardan biri de bir log yönetim sisteminin herhangi bir yazılım paketinin kurulması konfigürasyonunun yapılmasından ibaret olduğunu düşünmektir. Ancak projenin arkaplanında yer alan gerçek hedeflerin de bilinmesi gerekmektedir.

Bir Bilgi Yönetim Sistemi iki ana göreve sahiptir:

İç politikalar ve/veya dış regülasyonlarla (bizim açımızdan PCI DSS. Ancak SOX, GDPR vb. da olabilir) uyumluluk.
Çalışanlar ya da üçüncü partiler tarafından gerçekleştirilebilecek, sahtekarlık aktivitelerinden, müşterilerin kişisel bilgilerinin korunması için bilgisayar kanıtlarını saklı tutmak.

Tesis edilecek çözümün, bu hedeflerin tanımına uygun bir şekilde açıkça interkonnekte olması gerekmektedir.

İlk aşama: Hesap Surveyi ve Temizleme

Firma eğer bir Kimlik ive Erişim Yönetimi (Identity and Access Management – IAM) tesis etmişse, iyi bir başlangıç noktası olabilir. Aksi halde kullanıcı hesap survey ve filtreleme oluşturmak için gerekli olmaktadır. Başarılı bir IMS uygulaması için öngereksinimlerden biri de tüm kullanıcıların, kendilerine ait bir ID’ye sahip olmasıdır. Uygulama hesapları da her çalılşan ile bağlantılı olmak durumunda. Kısıtlı hesaplar için bu durum bir ihtiyaç. Böylelikle bu hesaplarla doğrudan erişimin sağlanabilmesi için kullanıcıların, kişisel bilgilerini girmesi ve kendilerini tanıtması gerekmektedir.

İkinci aşama: LOG Üretimi

Log’lar sistemde mevcut değilken, bunların nasıl oluşturulacağının tanımlanması gerekmektedir. Böyle bir aktivitenin, genellikle log yönetimine uygun tasarlanmamış sistemlerde uygulanması faydalı olmaktadır. En iyi çözüm, mevcut sisteme ya da ticari işlemlere herhangi bir zarar vermeden uygulanabilenlerdir.

Bilgisaya rsistemlerinde olası bir log oluşturucuyu yakından incelemeden önce, en azından iki işletim sistemi kategorisine değinmekte fayda bulunmaktadır:

  • Windows
  • Unix/Linux

Windows’tayken öntanımlı izi zayıf, uzaktan erişim ile yapılan aktivititeleri takip etmenin zor olduğu, bilgileri ikili sistemde saklayan bir işletim sistemi ile uğraşmak zorundayız. Burada çözüm olarak genellikle sistem ve dosya sistemi nesnelerine erişebilen, ilgili yazılımları kurmak ve kullanmak olacaktır. Hedef platformdaki uzaktan oturumları kaydeden uygulamalar genellikle iyi bir çözüm oluşturmaktadır.

Unix/Linux daha az probleme sahip. Çözüm üretmek daha kolay; SSH oturumu üzerinden özel bir shell betiği oluşturup, çalıştırmak yeterli.

Üçüncü aşama: Toplama ve Koruma

Log dosyalarının toplanması için, yerelde oluşturulmuşlarsa, iki adet temel mod bulunmaktadır:

  • push modu: Oturum sona erdiğinde, log dosyasını sunucudan merkezi repo’ya gönderir.
  • pull modu: Log dosyasının transferi merkezi olarak kontrol edilir.

Pull modu, daha kolay yönetime sahipken, push modu dosyanın bütünlüğünü daha iyi sağlamaktadır.

Log dosyalarının bütünlüğünden emin olmak ve oluşturulduktan belli bir süre sonra otomatik olarak sistemin log dosyalarını değiştirmesini engellemek için, çeşitli çözümler yer almaktadır. Her log dosyası, kaynak sistemden taşındıktan sonra, şunları yapmalıdır:

  • String hash’in hesaplanması
  • Gelen hesabı, aynı zamanda dijital imza ile işaretleyen merkezi ve senkronize zaman sunucusu ile entegre timestamp’in yazılması

Bu noktada depolamanın üç öğesi mümkün olmaktadır: Log dosyası, string hash ve timestamp. Son ikisi, depolanmış log dosyasının güvenirliğini onaylamayı mümkün kılmaktadır. Tabii ki mahkeme karşısında log kaydı oluşturmak yeterli olmayabilir. Ancak PCI DSS uyumu açısından oldukça faydalı.

  • 24 Solutions AB
  • Smedjegatan 2C
  • SE-13154 Nacka, Sweden
  • +46 (0)8 535 24 100
  • info@24solutions.com