Kurulumunuz Denetime Hazır mı?

Bir kurumun kontrolleri iki yerde yaşar: prosedür dosyasında ve sistemin ayar ekranında. Denetim ilkine bakar, gerçek hayat ikincisine göre işler. Aradaki fark açıldığında bunu kimse fark etmez, çünkü ikisini karşılaştıran bir mekanizma yoktur. Bu yazı, o karşılaştırmayı düzenli yapan bir kontrolün neye benzemesi gerektiğini anlatıyor.

Yazılı Olan ile Açık Olan

Prosedürde "onaylayan kişi değişikliği kendisi çalıştıramaz" yazar. Sistemde bunu uygulayan bir parametre vardır ve o parametre kapalıdır. İkisi de doğrudur, sadece birbirinden habersizdir.

Bu, kötü niyetle olmaz. Tipik hikâye şudur: kurulum sırasında parametre kapalı gelir çünkü ekip henüz rollerini tanımlamamıştır. Birkaç hafta sonra roller oturur ama parametreye kimse dönmez. Aradan bir yıl geçer. Denetçi prosedürü okur, sonra bir örnek talep ister ve onaylayanla çalıştıranın aynı kişi olduğunu görür.

O anda ortaya çıkan bulgu "görevler ayrılığı yok" değildir. Daha kötüsüdür: kontrolün varlığına dair yazılı bir iddia var ve iddia doğru değil. Denetçi gözünde bu, hiç kontrol olmamasından daha ağır bir bulgudur, çünkü kurumun kendi durumunu bilmediğini gösterir.

Neden Kimse Bakmıyor

Üç sebep var ve üçü de makul.

Ayarlar dağınıktır. Görevler ayrılığı bir ekranda, parola politikası başka bir ekranda, maskeleme üçüncü bir yerde, denetim izi ayarları dördüncü yerde durur. Hepsini tek tek gezip not almak yarım gün alır ve kimse bunu üç ayda bir yapmaz.

Beklenen değer yazılı değildir. Bir ayarın açık olduğunu görmek yetmez; o ayarın ne olması gerektiğini bilmek gerekir. Beklenen değer çoğu zaman sadece birinin kafasındadır ve o kişi işten ayrıldığında kaybolur.

Değişiklik sessizdir. Bir ayarı kapatmak, bir kullanıcı silmek kadar görünür bir olay değildir. Geçici olarak kapatılıp geri açılması unutulan kontroller, denetimde en sık çıkan bulgu türlerinden biridir. Bunun bilinçli hâli, yani denetim öncesinde gevşetilen kontroller, ayrı bir yazının konusu. Ayar değişikliğinin kendisinin de onaydan geçmesi gerektiğini dört göz kuralı yazısında ele aldık.

Bir Hazırlık Kontrolü Neyi Kapsamalı

Amaç, dağınık ayarları tek ekranda toplamak ve her birinin yanına beklenen değeri yazmaktır. Kapsam yedi başlıkta toplanabilir.

• Görevler ayrılığı. Onaylayan çalıştırabiliyor mu, talebi açan kendi talebini onaylayabiliyor mu, her adımda farklı onaylayan zorunlu mu, onaylayacak yeterli kişi var mı, denetçi rolü atanmış mı.
• Geri alma ve izole deneme. Geri alma planı zorunlu mu, deneme ortamı tanımlı mı.
• Talep disiplini. Bilet numarası zorunlu mu, biçimi doğrulanıyor mu, acil müdahale için ayrı numara isteniyor mu, her sunucunun bir onay politikası var mı, kritik nesneler tanımlı mı.
• Kimlik ve parola. Parola kuralları, ikinci faktör kapsaması, kurulum yöneticisinin varsayılan parolasının değiştirilmiş olması.
• Veri koruma. Maskeleme açık mı, teslim rejimi ne, maskelemeden muaf tutulmuş sunucu var mı, hassas veri desenleri tanımlı mı.
• Denetim ve kanıt. Denetim izi anahtarı tanımlı mı, imzalama açık mı, çapa tazeliği yerinde mi, kayıt ikinci bir yere kopyalanıyor mu, SOC'a akış çalışıyor mu, teslim gecikmesi ne kadar.
• Dış kontroller. Yönetim uçlarının ağ seviyesinde kısıtlanıp kısıtlanmadığının izi, taşıma güvenliği.

Sekizinci bir başlık daha eklenmelidir ve günlük kontrollerden ayrı okunmalıdır: sırların yerleşimi. Parolalar, anahtarlar ve bağlantı dizeleri yapılandırma dosyasında mı duruyor, yoksa ortam değişkeninde mi. Bu, üretime çıkmadan önce kapatılacak bir listedir, süregelen bir yönetişim kontrolü değil.

İki Durum Yetmez: Üçüncü Hal

Böyle bir ekranı kurarken yapılan en yaygın hata, her satırı geçti ya da kaldı diye işaretlemektir. Bazı ayarların doğru cevabı yoktur; kuruma göre değişir ve o kurumun bilinçli tercihidir.

Örnek: maskelemeden muaf tutulmuş bir sunucu. Bu bir hata olabilir, ama test ortamı olduğu için bilinçli bir tercih de olabilir. Bunu "kaldı" diye işaretlemek yanlış alarm üretir; "geçti" diye işaretlemek gerçek bir açığı gizler.

Doğru tasarım üç durumludur: uygun, dikkat ve karar verin. Üçüncüsü şunu söyler: burada bir tercih var, tercihin kendisi yanlış değil, ama tercih edildiğinin farkında olmalısınız. Denetçiye verilecek cevap da budur; "böyle olması gerekiyordu" değil, "bunu bilerek böyle bıraktık, gerekçesi şu".

Sayının Kendisi Kanıt Değildir

Böyle bir ekran çalıştırıldığında ortaya bir sayı çıkar: şu kadar kontrol uygun, şu kadarı dikkat istiyor. Bu sayıyı bir puan gibi kullanmak cazip gelir ve yanlıştır.

Sebebi şu: kontroller eşit ağırlıkta değildir. Denetim izi anahtarının tanımsız olması ile bir sunucunun kritik nesne listesinin boş olması aynı şey değildir. Yirmi küçük maddeyi kapatıp bir kritik maddeyi açık bırakan bir kurulum, sayı olarak iyi görünür ve gerçekte kötüdür. Bir yönetişim ölçüsünde doğru yaklaşım, ortalama almak değil en kötü maddeye bakmaktır. Aynı mantık tek bir değişikliğin riskini belirlerken de geçerlidir; risk bandı yazısında bunun neden ortalama olmaması gerektiğini anlattık.

Sayının gerçek değeri eğilimdedir. Üç ayda bir alınan ölçümde dikkat isteyen madde sayısı artıyorsa, bir şey gevşiyor demektir. Denetime kanıt olarak sunulacak şey de tek bir fotoğraf değil, bu ölçümün düzenli alındığının kaydıdır.

Bu Kontrolü Kim Çalıştırmalı

Ekranı kuran ekip ile onu okuyan ekip aynı olmamalıdır. Sistem yöneticisi kendi kurulumunun durumunu görmek için çalıştırır; bu operasyonel bir ihtiyaçtır. Ama aynı çıktıyı iç denetim veya bilgi güvenliği tarafının da bağımsız olarak görebilmesi gerekir.

Çalıştırma sıklığı için makul bir ritim, üç ayda bir ve her büyük sürüm sonrasıdır. Bir de kaçırılmaması gereken an vardır: denetim tarihinin hemen öncesi. O dönemde alınan ölçümün bir öncekiyle karşılaştırılması, denetim öncesinde gevşetilmiş bir kontrol varsa onu yakalar.