5651 Sayılı Kanun ve DDoS Saldırılarında Log Yükümlülükleri: Kaydınız Saldırıdan Sağ Çıkıyor mu?

Türkiye’de kayıt yükümlülüğü tartışması genellikle bir satın alma kalemine indirgenir: “5651 uyumlu log cihazı” alınır, rafa takılır, konu kapanmış sayılır. Bu yaklaşım normal günlerde çalışır. Sorun, yükümlülüğün en çok test edildiği günde, yani kurumun ağının saldırı altında olduğu günde ortaya çıkar.

Bir DDoS saldırısı yalnız hizmeti hedef almaz. Hizmete ilişkin kaydı da hedef alır. Bunu bilerek yapmasa bile sonuç aynıdır: saldırı, log üretiminin, log taşınmasının, log yazılmasının ve log zamanlanmasının hepsini aynı anda zorlar. Bu makale, 5651 kapsamındaki yükümlülüğün ne istediğini, saldırı koşullarının bu yükümlülüğü hangi noktalardan kırdığını ve mimari kararın kayıt bütünlüğü üzerindeki etkisini ele alıyor.

Baştan bir uyarı: aşağıdaki bölümler mevzuatın ne dediğini aktarır, hukuki görüş oluşturmaz. Saklama süreleri ve teknik usuller yönetmelik değişiklikleriyle güncellenen konulardır. Kendi kurumunuz için bağlayıcı olan, yürürlükteki güncel metin ve hukuk müşavirinizin değerlendirmesidir.

Yükümlülük tam olarak ne istiyor?

5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi ve Bu Yayınlar Yoluyla İşlenen Suçlarla Mücadele Edilmesi Hakkında Kanun, yükümlülüğü üstlenilen role göre kurar, kurum türüne göre değil. Kanun içerik sağlayıcı, yer sağlayıcı, erişim sağlayıcı ve toplu kullanım sağlayıcı ayrımını yapar. Kayıt yükümlülüğünün kapsamı bu role göre değişir. Piyasada sıkça duyulan “her şirket 5651 logu tutmak zorundadır” cümlesi bu yüzden fazla kabadır. Doğru soru, kurumunuzun hangi rolde olduğudur: misafirlerine ya da personeline internet erişimi sunuyorsanız toplu kullanım sağlayıcı, başkasına ait içeriğe barındırma hizmeti veriyorsanız yer sağlayıcı konumundasınız ve bunlar farklı kayıt setleri gerektirir.

Kanunun tanımlar maddesinde trafik bilgisi, taraflara ilişkin IP adresi, port bilgisi, verilen hizmetin başlama ve bitiş zamanı, yararlanılan hizmetin türü, aktarılan veri miktarı ve varsa abone kimlik bilgilerini kapsayacak biçimde tanımlanır. Bu tanımın içinde port bilgisinin açıkça yer alması, ilerideki bölümler açısından önemlidir; operatörlerin yaygın olarak kullandığı adres paylaşımlı yapılarda bir IP adresi tek başına kimseyi işaret etmez, kaydı anlamlı kılan şey IP ile portun ve kesin zamanın birlikte tutulmasıdır.

Saklama süresi role göre değişir ve somut süre uygulama yönetmeliğinde belirlenir. Kendi rolünüz için geçerli süreyi yürürlükteki konsolide yönetmelik metninden okuyun; bu makale süre vermiyor, çünkü bu yazının argümanı sürenin içinde kaydın hangi nitelikte tutulacağına dayanıyor, sürenin uzunluğuna değil.

Asıl belirleyici olan nitelik şartıdır. Kanun, trafik bilgisinin saklanmasını isterken aynı cümlede bu bilgilerin doğruluğunun, bütünlüğünün ve gizliliğinin sağlanmasını da yükümlülük olarak sayar. Yönetmelik bunu teknik bir usule bağlar: oluşan verilerin dosya bütünlük değerleri, yani özet (hash) değerleri, zaman damgası ile birlikte muhafaza edilir. Zaman damgasının kendisi 5070 sayılı Elektronik İmza Kanunu’nda tanımlıdır ve bir elektronik verinin belirli bir anda o içerikle var olduğunu doğrulayan kayıttır.

Bu üçlü, yükümlülüğün gerçek çekirdeğidir ve mimari tartışmasını başlatan da budur:

• Doğruluk. Kayıttaki bilgi, gerçekten olan şeyi göstermelidir. Kaynak IP alanında gerçek kaynak yerine araya giren bir sistemin adresi yazıyorsa kayıt doğru değildir.
• Bütünlük. Kayıt eksiksiz olmalı ve sonradan değiştirilmemiş olduğu gösterilebilmelidir. Düşen satırlar bütünlüğü bozar. Üstelik en sinsi biçimde bozar, çünkü eksik dosyanın özet değeri de pekâlâ tutarlı çıkar.
• Gizlilik. Kayıt, yetkisiz erişime karşı korunmalıdır. Kaydın nerede tutulduğu ve kimin eriştiği bu yüzden mimari bir sorudur, sadece bir dosya izni sorusu değildir.

Kanun ayrıca kayıtların talep halinde yetkili mercilere verilmesini ve erişim sağlayıcının faaliyetine son vermesi halinde kayıtlarını Kuruma teslim etmesini öngörür. Yükümlülüklerin ihlali halinde idari yaptırım uygulanır. Yaptırım tutarlarını burada yazmıyoruz, çünkü bu tutarlar her yıl yeniden değerleme oranına göre güncellenir ve bir makalede sabitlenmeleri okuyucuyu yanıltır.

“Log tutmak” ile “kaydın ayakta kalması” aynı şey değil

Yükümlülük süreklidir. Mevzuat, kaydın hangi koşullarda tutulacağına dair bir hava durumu maddesi içermez; “yoğun trafikte gevşetilebilir” gibi bir istisna öngörmez. Denetim anında sorulan soru basittir: şu tarih ve saat aralığına ait kayıt nerede?

Bu soruya “o gün saldırı altındaydık” cevabı vermek, teknik olarak açıklayıcı ama hukuken zayıf bir pozisyondur. Kurumun kendi altyapısının kapasite sınırları, mevzuatın öngördüğü kayıt yükümlülüğünü askıya alan bir olgu değildir. Dolayısıyla kayıt mimarisi, tıpkı hizmet mimarisi gibi, en kötü günün koşullarına göre tasarlanmak durumundadır.

Bu, kurumların çoğunda yapılmayan bir tasarım kararıdır. Log altyapısı tipik olarak günlük hacme göre boyutlanır. Saldırı ise saldırı hacmini üretir, günlük hacmi değil. Aradaki fark çoğu zaman birkaç mertebedir, birkaç kat değil.

Saldırı, kayıt hattını hangi noktalardan kırar?

Bir DDoS saldırısı sırasında kayıt zincirinin kırılabileceği yerler bellidir ve hepsi ölçülebilir. Aşağıdaki başlıkların her biri, kendi ortamınızda bir sonraki tatbikatta test edilebilir.

Log üretiminin kendisi çoğalır. Tek bir saldırı paketi, onu gören her cihazda ayrı bir kayıt satırı doğurabilir: sınır yönlendiricide bir akış kaydı, güvenlik duvarında bir reddetme logu, IPS’te bir imza uyarısı, WAF’ta bir kural eşleşmesi, uygulamada bir hata satırı. Bu çoğalmanın maliyet tarafını yerinde cihazın toplam sahip olma maliyeti makalesinde SIEM lisans kademesi üzerinden ele almıştık. Uyum tarafındaki sonucu ise daha sert: aynı mekanizma, mevzuatın istediği kayıtları taşıyan hattı doldurur.

Taşıma katmanı sessizce kaybeder. Kurumsal ortamların büyük bölümünde log taşıması syslog üzerinden ve UDP ile yapılır. UDP’nin teslim garantisi yoktur. Ağ ya da hedef sistem doyduğunda paket düşer ve düştüğüne dair bir kayıt da oluşmaz. Yani kayıp, kaybın kendisini gizler. Saldırı sırasında hem ağ hem log sunucusu baskı altındadır, dolayısıyla kaybın en olası olduğu an tam da kaydın en kritik olduğu andır.

Örnekleme devreye girer. NetFlow, sFlow ve benzeri akış telemetrisi normal koşullarda bile örnekleme oranıyla çalışır. Yüksek paket hızlarında cihazlar örnekleme oranını kendiliğinden düşürebilir ya da akış tablosu taştığı için akışları erken sonlandırıp birleştirebilir. Sonuç, gerçeğin istatistiksel bir temsili olur. İstatistiksel temsil trend analizi için yeterlidir; belirli bir aboneyi belirli bir ana bağlaması gereken bir kayıt için yeterli değildir.

Yazma tarafında geri basınç oluşur. Log sunucusunun disk yazma hızı, indeksleme kuyruğu ve alım hattı sınırlıdır. Kuyruk dolduğunda platformların çoğu kendini korumak için olay düşürmeye başlar. Bu, ürünün hatası değil tasarım tercihidir; ama uyum açısından sonucu kayıp kayıttır.

Saat kayması başlar. Zamanın doğruluğu, kayıt yükümlülüğünün görünmez ayağıdır. Saat senkronizasyonu NTP ile yapılır, NTP de UDP üzerinde çalışır. Ağ doyduğunda NTP paketleri de diğerleri gibi düşer. Üstelik NTP altyapısının kendisi klasik bir yansıtmalı saldırı hedefidir. Saatler kaydıkça farklı cihazların ürettiği kayıtlar birbiriyle ilişkilendirilemez hale gelir ve olayın zaman çizelgesi bulanıklaşır. Kaydın “verilen hizmetin başlama ve bitiş zamanını” içermesi gerektiği düşünülürse, saat kayması doğrudan bir mevzuat sorunudur.

Cihazlar kendini korumaya geçer. Durum tutan cihazlar baskı altında oturum kayıtlarını erken düşürür, oturum ömrünü kısaltır ve bağlantı kayıtlarını toplulaştırır. Bu davranışlar cihazı ayakta tutar. Ama tuttukları kaydın çözünürlüğünü düşürür.

Bu altı mekanizmanın ortak özelliği şudur: hiçbiri alarm üretmez. Hepsi sessizce çalışır ve sonuçları ancak aylar sonra, bir kayıt talebi geldiğinde görünür.

Bütünlük değeri, eksik kaydı kurtarmaz

Kurumların çoğu bütünlük yükümlülüğünü “günlük özet değeri alıp zaman damgalatıyoruz” diye kapatır. Bu doğru bir uygulamadır ama neyi ispatladığı konusunda yaygın bir yanlış anlama vardır.

Özet değeri ve zaman damgası, o dosyanın belirli bir anda o içerikle var olduğunu ve sonradan değiştirilmediğini gösterir. Dosyanın eksiksiz olduğunu göstermez. Saldırı sırasında yüzbinlerce satır düştüyse, günün sonunda alınan özet değeri eksik dosyanın özet değeridir ve mükemmel biçimde tutarlıdır. Elinizde bütünlüğü ispatlanmış ama gerçeği eksik anlatan bir kayıt kalır.

Bu ayrım, kaydın delil olarak kullanılacağı durumlarda önemlidir. Hukuk Muhakemeleri Kanunu’nun belge tanımı elektronik ortamdaki verileri de kapsar; yani log kayıtları mahkemede belge olarak ileri sürülebilir. Ancak bir belgenin delil değeri, üretim koşullarının açıklanabilir olmasına bağlıdır. Karşı taraf “bu kayıt saldırı sırasında üretildi ve o sırada sisteminiz kayıt kaybediyordu” diyebiliyorsa, kaydın ikna ediciliği azalır. Bu nedenle olgun kurumlar kaydı tek başına tutmakla yetinmez. Kaydın üretilmeye devam ettiğini gösteren ikinci bir kaydı da tutarlar: log alım hızının, kuyruk derinliğinin ve düşen olay sayacının kendi zaman serisi.

Trafik yukarı akışa devredildiğinde ne oluyor?

Buraya kadar anlatılanlar, saldırının tamamen kendi altyapınızda karşılandığı senaryoya aitti. Trafik olay ortasında yukarı akıştaki bir temizleme katmanına devredildiğinde tabloya yeni ve daha az konuşulan sorunlar eklenir.

Kaynak IP sadakati yönlendirme yöntemine bağlıdır. İki temel yöntem vardır ve kayıt açısından sonuçları farklıdır. BGP duyurusuyla ön ekin yukarı akışa çekildiği ve temiz trafiğin tünelle geri verildiği yapılandırmalarda IP başlığı korunur ve sunucularınıza ulaşan kaynak IP hâlâ gerçek kaynaktır. Buna karşılık DNS yönlendirmesiyle çalışan ve isteği ters vekil sunucu olarak ileten yapılandırmalarda sunucularınızın gördüğü kaynak IP, sağlayıcının kendi ön uç adresidir. Gerçek kaynak yalnızca X-Forwarded-For ya da sağlayıcıya özgü bir başlıkta taşınır.

Bu ikinci durumda kaydınızın doğruluğu artık bir yapılandırma detayına bağlıdır: uygulama sunucunuz o başlığı okuyup kaydediyor mu, hangi başlığı güveniyor, zincirdeki hangi adresi gerçek kaynak sayıyor? Yanlış yapılandırılmış bir ortamda erişim kaydınızdaki bütün istekler avuç içi kadar bir adres kümesinden geliyormuş gibi görünür. Kayıt vardır, süre tutmuştur, özet değeri alınmıştır ve hiçbir işe yaramaz, çünkü doğruluk şartını karşılamaz.

Engellenen trafik sizin kaydınızda hiç yer almaz. Temizleme katmanının işi, kötü trafiği size ulaşmadan durdurmaktır. Bu, hizmet sürekliliği açısından tam olarak istenen şeydir. Ancak saldırıya ilişkin kayıt, doğal olarak yalnızca sağlayıcının tarafında oluşur. Saldırganlar hakkında suç duyurusunda bulunmak istediğinizde, ki DDoS eylemleri Türk Ceza Kanunu’nun bilişim sistemini engelleme ve bozma hükümleri kapsamında değerlendirilir ve nitelendirme takdiri soruşturma makamına ve mahkemeye aittir, kaynak bilgisi elinizde değildir. Sözleşmenizde bu kayıtları talep etme hakkı, teslim formatı ve teslim süresi tanımlı değilse, pratikte bu kayıtları alamazsınız.

Delil zinciri üçüncü tarafa uzar. Kendi cihazınızın ürettiği ve kendi zaman damgası hizmetinizle mühürlediğiniz bir kayıt ile, aylar sonra yurt dışındaki bir sağlayıcıdan elektronik posta ekinde gelen bir CSV dosyası aynı ağırlıkta değildir. İkincisinin üretim koşulları sizin denetiminizde değildir, saat kaynağı sizin saat kaynağınız değildir ve saklama süresi sizin saklama sürenizle aynı olmak zorunda değildir.

Kişisel veri boyutu ayrıca doğar. Kayıtlar kişisel veri içerir ve yurt dışındaki bir katmanda işlendiğinde KVKK’nın yurt dışına aktarım rejimi devreye girer. Bu makale o konuyu tekrar etmiyor; ayrıntısı KVKK ve veri yerelliği açısından DDoS koruması makalesindedir. Burada altı çizilmesi gereken tek nokta, iki yükümlülüğün birbirini zorlamasıdır: 5651 kaydı belirli bir süre saklamanızı isterken, KVKK aynı kaydı amaç dışı tutmamanızı ister. İkisi arasındaki dengeyi kuran şey, kaydın nerede tutulduğunun ve ne kadar süreyle tutulduğunun yazılı olarak belirlenmiş olmasıdır.

Satır içi yerinde cihaz neyi değiştiriyor?

Yerinde ve satır içi çalışan bir azaltma cihazının kayıt yükümlülüğü açısından iki somut katkısı vardır. Bunları abartmadan, ama net biçimde yazmak gerekiyor.

Birincisi, çöp trafik log satırına dönüşmeden düşer. Cihaz sınırdadır; anomali trafiğini güvenlik duvarına, IPS’e, WAF’a ve uygulamaya ulaşmadan atar. Arkadaki cihazlar hiç görmedikleri trafiği loglamaz. Böylece yukarıdaki çoğalma mekanizması, mevzuatın istediği kayıtları taşıyan hattı doldurmadan önce kaynağında kesilir. Kayıt hattı, sözleşmenin ve tasarımın yapıldığı hacim aralığında çalışmaya devam eder.

İkincisi, kayıt kurumun kendi altyapısında kalır. Trafik incelemesi kendi donanımınızdadır, kaydı üreten sistem sizin sisteminizdir, saat kaynağı sizin saat kaynağınızdır ve bütünlük değerini mühürleyen zaman damgası hizmetini siz seçersiniz. Delil zinciri kurumun sınırları içinde kalır. Sonradan bir üçüncü taraftan kayıt talep etme ihtiyacı doğmaz.

Satın alma tarafında bu, tek bir teknik soruya indirgenebilir: cihaz, azalttığı saldırıyı paket başına mı yoksa olay başına mı raporluyor? Düşürdüğü her paket için bir log satırı üreten bir cihaz, sorunu çözmemiş yalnızca bir adım öteye taşımıştır. Doğru davranış, saldırıyı sessizce azaltıp tek bir özetlenmiş olay kaydı üretmek ve ayrıntıyı cihaz üzerinde tutmaktır. Tespiti tamamen cihaz üzerinde çalıştıran, bulut bağımlılığı olmayan çözümler bu davranışı yapısal olarak gösterme eğilimindedir. Yine de bu, kabul edilecek değil kanıt istenecek bir özelliktir: deneme kurulumunda saldırı üretin ve SIEM’inize düşen olay sayısını ölçün.

Dürüst sınır: hat doyduğunda kayıt da susar

Bu makalenin ikna edici olabilmesi için sınırı açıkça yazmak gerekir. Yerinde bir cihaz, erişim hattınızı doyuran bir saldırıyı durduramaz. Hattınız 10 Gbps ise ve 40 Gbps geliyorsa, hat cihazdan önce dolar.

Bunun kayıt tarafındaki sonucu özellikle can sıkıcıdır. Hattı doymuş bir kurumda erişim kaydı boş görünmez, yanlış görünür: meşru kullanıcıların bağlantıları hiç kurulamadığı için kayıtta yoktur ve o saat aralığı sanki kimse hizmeti kullanmamış gibi okunur. Bir denetimde ya da bir uyuşmazlıkta bu boşluğu açıklamak, kayıt kaybını açıklamaktan kolay değildir.

Dolayısıyla doğru kurgu, uyum tarafında da mimari tarafında da aynıdır: gündelik trafiğin tamamı yerinde katmanda işlenir ve kaydı yerinde üretilir. Yukarı akış katmanı yalnızca hat kapasitesi aşıldığında ve sözleşmeyle tanımlanmış koşullarda devreye girer. Böylece kaydın üçüncü tarafa bağımlı hale geldiği durum, süreklilik arz eden bir hal olmaktan çıkıp istisnai, tanımlı ve belgelenebilir bir olaya dönüşür.

Şartnameye ve teknik tasarıma girmesi gerekenler

Aşağıdaki maddeler, kayıt yükümlülüğünün saldırı koşullarında da karşılandığını gösterebilmek için asgari settir. İlk beşi sizin tasarımınıza, sonraki beşi sağlayıcı sözleşmesine aittir.

1. Kayıt hattının saldırı hacmine göre boyutlandırılması. Log alım kapasitesini gözlemlediğiniz en yüksek olay hızına göre belirleyin, günlük ortalamaya göre değil. Bu varsayımı yazılı hale getirin.
2. Güvenilir taşıma. Mevzuat kapsamındaki kayıtların syslog üzerinden UDP ile taşınmasından vazgeçin; TCP ya da TLS üzerinden taşıyın ve teslim edilemeyen kaydın kuyruğa alınmasını sağlayın.
3. Kayıp görünür olsun. Düşen olay sayacını, kuyruk derinliğini ve alım gecikmesini ölçün, eşik alarmı tanımlayın ve bu ölçümleri kaydın kendisiyle aynı süre boyunca saklayın. Kaydın üretilmeye devam ettiğini gösteren şey budur.
4. Saat mimarisi. Birden fazla bağımsız saat kaynağı kullanın, iç ağda katmanlı bir yapı kurun ve saat kaymasını sürekli izleyin. Saat kaynaklarını saldırı yüzeyinizin bir parçası olarak değerlendirin.
5. Bütünlük mühürlemesinin sıklığı. Bütünlük değerini gün sonuyla sınırlamayın; daha sık aralıklarla alın. Böylece kaybın hangi zaman diliminde gerçekleştiği daraltılabilir ve kaydın tamamı yerine yalnızca ilgili dilim tartışmalı hale gelir.
6. Yönlendirme yöntemi. Sağlayıcının devretme yönteminin BGP tabanlı mı yoksa vekil sunucu tabanlı mı olduğunu ve kaynak IP’nin korunup korunmadığını sözleşmeye yazdırın.
7. Başlık davranışı. Vekil sunucu tabanlı bir yapı varsa gerçek kaynak adresin hangi başlıkta taşınacağını, hangi adreslerin güvenilir sayılacağını ve bu başlığın uygulama tarafında nasıl kaydedileceğini belgeleyin.
8. Sağlayıcı kayıtlarına erişim. Olaya ilişkin kayıtları talep etme hakkını, teslim süresini, formatını ve sağlayıcının bu kayıtları ne kadar süreyle sakladığını sözleşmeye koyun. Kontrol panelinden dışa aktarılabilen bir grafik, kayıt değildir.
9. Sağlayıcı tarafındaki saat ve bütünlük. Sağlayıcının kayıtlarını hangi saat kaynağıyla damgaladığını ve bütünlük garantisi sunup sunmadığını sorun. Cevap yoksa, bu kayıtların delil değerini buna göre değerlendirin.
10. Devretme koşulları. Yukarı akış katmanının hangi eşikte devreye gireceğini, ne kadar kalacağını ve geri dönüş koşulunu tanımlayın. Bu, kayıt açısından tutarsızlık penceresinin ne zaman açılıp kapandığını bilmek demektir.

Saldırı sonrası: elinizde ne olmalı?

Bir DDoS olayı kapandıktan sonra kurumun elinde bulunması gereken kayıt seti, mevzuatın istediğinden biraz daha geniştir ve bunu olay öncesinde tanımlamak gerekir. Asgari olarak: olayın başlangıç ve bitiş zamanı, kurumun kendi saat kaynağına göre; azaltma katmanının ürettiği özet olay kaydı ve uygulanan azaltma kararları; olay süresince kayıt hattının sağlık ölçümleri; devretme yapıldıysa devretme ve geri dönüş anları; ve mevzuat kapsamındaki trafik bilgisinin kesintisiz olarak üretildiğini gösteren bütünlük mühürleri.

Bu setin varlığı iki ayrı soruyu birden cevaplar. Denetim tarafında, yükümlülüğün saldırı koşullarında da yerine getirildiğini gösterir. Adli tarafta, suç duyurusunun dayanacağı maddi zemini oluşturur.

Bu setin yokluğunda ise kurum, hem hizmeti kesilmiş hem de kesintiyi açıklayacak kaydı üretememiş olur. İkinci kayıp genellikle birincisinden daha uzun süre yaşar.

Kaynaklar ve ileri okuma

Aşağıdaki kaynaklar doğrudan erişilebilir ve doğrulanabilir metinlerdir. Saklama süreleri ve teknik usuller değişebildiği için, karar vermeden önce yürürlükteki güncel metni ve hukuk müşavirinizin görüşünü esas alın.

Mevzuat.

• 5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi ve Bu Yayınlar Yoluyla İşlenen Suçlarla Mücadele Edilmesi Hakkında Kanun — Mevzuat Bilgi Sistemi
• İnternet Ortamında Yapılan Yayınların Düzenlenmesine Dair Usul ve Esaslar Hakkında Yönetmelik — Mevzuat Bilgi Sistemi
• İnternet Toplu Kullanım Sağlayıcıları Hakkında Yönetmelik — WIPO Lex
• 5070 sayılı Elektronik İmza Kanunu — Mevzuat Bilgi Sistemi
• 6698 sayılı Kişisel Verilerin Korunması Kanunu — Mevzuat Bilgi Sistemi
• 5271 sayılı Ceza Muhakemesi Kanunu ve 5237 sayılı Türk Ceza Kanunu — Mevzuat Bilgi Sistemi

Düzenleyici kurumlar.

• Bilgi Teknolojileri ve İletişim Kurumu (BTK)
• Kişisel Verileri Koruma Kurumu (KVKK)
• Erişim Sağlayıcıları Birliği

Teknik standartlar ve rehberler.

• Syslog protokolü ve güvenilir taşıma: RFC 5424, RFC 6587 ve TLS üzerinden taşıma için RFC 5425
• Zaman damgası protokolü: RFC 3161
• Ağ zaman senkronizasyonu: RFC 5905
• Adres paylaşımlı yapılarda kayıt ve port bilgisi: RFC 6302 ve RFC 6888
• Olay müdahalesi ve kayıt yönetimi: NIST SP 800-92 ve NIST SP 800-61