Kod Olarak Tespit İlkeleri

Kod Olarak Tespit (DaC), yazılım mühendisliği disiplinini güvenlik tespitlerine uygular. Analistlerin SIEM konsolunda kuralları elle düzenlemesi yerine tespitler, sürüm denetimindeki metin dosyalarında tutulur ve bir işlem hattı üzerinden yayımlanır.

Faydaları somuttur:

• Çekme istekleri üzerinden incelenebilir değişiklikler
• Ortamlar arasında yeniden üretilebilir dağıtımlar
• Üretime ulaşmadan önce sınanabilir mantık
• Kimin neyi neden değiştirdiğini gösteren denetlenebilir geçmiş

Bir tespit, diğer tüm kodlar gibi farklarını karşılaştırabileceğiniz, geri alabileceğiniz ve mantığını değerlendirebileceğiniz bir ürüne dönüşür.

Her tespit, genellikle YAML veya üreticiye özgü bir sorgu dili kullanılan bağımsız bir dosya olarak saklanır ve bir Git deposuna kaydedilir. Depo yapısı, kapsama alanınızı nasıl düzenlediğinizi yansıtır.

Yaygın bir yapı, kuralları platforma ve taktiğe göre ayırır:

Her yeni veya değiştirilmiş tespit bir çekme isteğinden geçer. İkinci bir mühendis, birleştirilmeden önce mantığı, yanlış pozitif riskini ve ATT&CK eşlemesini inceler.

İnceleyenler şunları sorar:

• Mantık, açıklanan tehditle örtüşüyor mu?
• Hangi meşru etkinlik bunu tetikleyebilir?
• Önem derecesi ve ATT&CK başvurusu doğru mu?
• Doğru ve yanlış pozitifleri kapsayan sınamalar var mı?

Bu yaklaşım, gece saat 2'de SIEM'i düzenleyen tek bir analistin gözden kaçıracağı hataları yakalar.

Bir sürekli tümleştirme işlem hattı her gönderimde otomatik olarak çalışır. Bir kural birleştirilemeden önce kalite kapılarını uygular.

Sigma tabanlı bir depo için tipik sürekli tümleştirme aşamaları:

Birleştirildikten sonra bir dağıtım işi, taşınabilir kuralları hedef sorgu diline dönüştürür ve bunları API aracılığıyla SIEM veya EDR'ye gönderir.

Sigma için genellikle platformunuzla eşleşen bir arka uçla sigma convert gibi bir dönüştürücü çalıştırırsınız (Splunk, Elastic, Microsoft Sentinel). Ardından işlem hattı, oluşturulan kaydedilmiş aramaları veya analitik kuralları yükler.

Hiç kimse sorguları bir konsola elle yapıştırmaz. Dağıtılmış durum her zaman main içinde bulunanla eşleşir.

Sınamaları olmayan bir tespit tahminden ibarettir. DaC, her kuralı sınama verileriyle eşleştirir: onu tetiklemesi gereken günlük örnekleri (doğru pozitifler) ve onu tetiklememesi gereken zararsız örnekler (yanlış pozitifler).

Sınamalar CI'da çalışır; bu nedenle kapsamı bozan veya gürültüyü yeniden oluşturan bir değişiklik, birleştirilmeden önce derlemeyi başarısız kılar. Kuralları büyük ölçekte yeniden düzenlerken güvenin açık ara en büyük kaynağı budur.

Üst verileri birinci sınıf bilgi olarak ele alın. Her tespit, yaşam döngüsünde olgunlaşırken durumunu kaydeder:

• experimental — yeni yazılmış, yakından izlenir
• test — çalışıyor ancak uyarı üretmek için henüz güvenilir değil
• stable — kanıtlanmış, yanlış pozitif oranı düşük
• deprecated — yerini başkasına bırakmış veya kullanımdan kaldırılmış

Durumu dosyada izlemek, eski mantığın üretimde sürüklenmesine izin vermek yerine kuralları bilinçli biçimde üst seviyeye çıkarmanızı, alt seviyeye indirmenizi ve kullanımdan kaldırmanızı sağlar.

DaC'nin temel kazanımlarından biri, tespit mantığını üreticiden bağımsız bir biçimde bir kez yazıp birçok arka uç için derleyebilmektir. Sigma, günlük tabanlı tespitler için fiilî standarttır.

Aynı kural dosyası, işlem hattına özgü alan eşlemeleri aracılığıyla Splunk SPL, Elastic Lucene/EQL, Microsoft Sentinel KQL ve diğerlerini hedefleyebilir. Aynı fikri beş kez yeniden yazmaktan ve üretici bağımlılığından kaçınırsınız.

Farklı günlük kaynakları aynı veriyi farklı adlandırır. Bir Sysmon işlem oluşturma olayı Image alanını kullanırken bir Windows Güvenlik günlüğü NewProcessName alanını kullanabilir. İşleme işlem hatları bu farkı kapatır.

İşlem hatları, genel Sigma alan adlarını verilerinizin kullandığı tam alanlara dönüştürür; böylece tek bir mantıksal kural, SIEM'in aldığı şema ne olursa olsun düzgün biçimde eşlenir. İşlem hatlarını merkezi olarak sürdürmek, bir şema değişikliğinin kural başına değil, yalnızca bir kez düzeltilmesini sağlar.

Uygulama kodu gibi tespitler de üretime ulaşmadan önce ortamlardan geçer. Tipik akış, geliştirme ortamından hazırlık ortamına, oradan da üretim ortamına ilerler.

• Geliştirme — CI'da birim sınamalarını oluşturma ve çalıştırma
• Hazırlık — gerçek telemetrinin bir kopyası üzerinde denetim modunda dağıtma
• Üretim — yanlış pozitif oranı kabul edilebilir olduğunda üst ortama alma

Üst ortama alma, birleştirmenin tesadüfi sonucu değil, kuralın yaşam döngüsü durumuna bağlı, bilinçli ve incelenmiş bir adımdır. Bu aşamalı dağıtım, satır içi tespitlerde kullanılan önce uyar, sonra engelle disiplinini yansıtır.

Tespitler kod olduğundan kapsamı program aracılığıyla ölçebilirsiniz. Her kuralı MITRE ATT&CK teknikleriyle ilişkilendirin ve neleri kapsayıp neleri kapsamadığınızı gösteren bir ısı haritası oluşturun.

Zaman içinde izlenebilecek yararlı ölçümler:

• Tehdit modelinizde kapsanan tekniklerin toplam teknik sayısına oranı
• Kural başına yanlış pozitif oranı
• Kural fikrinden üretime geçişe kadar geçen ortalama süre
• Her yaşam döngüsü durumundaki kural sayısı

Bu sayılar, tespit mühendisliğini kişisel gözlemlerden çıkarıp yönetilen bir programa dönüştürür.

Kod Olarak Tespit temellerini anlayıp anlamadığınızı sınayın.

Kod Olarak Tespit, tespitlere yazılım mühendisliği titizliği kazandırır:

• Kurallar Git'te sürümlendirilmiş dosyalar olarak tutulur
• Değişiklikler çekme isteği incelemesinden geçer
• CI, kod biçimi denetimini yapar, doğrular ve testleri otomatik olarak çalıştırır
• Birleştirilen kurallar, üretim ortamını ana dalla eşzamanlı tutacak şekilde işlem hattı aracılığıyla dağıtılır
• Testler, yanlış pozitiflere ve gerilemelere karşı koruma sağlar
• Taşınabilirlik (Sigma + işlem hatları), tek bir kuralın birçok arka ucu hedeflemesini sağlar
• Meta veriler, yaşam döngüsü ve ölçümler, tespiti yönetilen bir programa dönüştürür

Sonraki adımda, taşınabilir kuralların kendisini Sigma ile yazacaksınız.