Denetçinin Perspektifi: Bir BT Denetçisi Gibi Düşünmek

Bir BT denetçisi bir sistemdeki her hatayı veya yanlış yapılandırmayı bulmak için işe alınmaz. İş daha dar kapsamlı ve dürüst söylemek gerekirse daha zordur: mevcut kontrollerin işletmeye yönelik risklerin yönetilmesi hakkında makul güvence sağlayıp sağlamadığını belirlemek. Bu ayrım, bir güvenlik duvarı kural setini okumaktan bir sistem sahibiyle görüşmeye kadar neredeyse her görevi nasıl yaklaştığınızı değiştirir.

Risk önce, teknoloji sonra

Bir penetrasyon test uzmanı "bunu kırabilirim mi?" sorusunu sorar. Bir denetçi "bu önemli mi ve başarısız olursa işletmeye ne olur?" sorusunu sorar. Tek bir kontrole dokunmadan önce, bir denetçi sistemin ne yaptığını, hangi verilere dokunduğunu ve gizlilik, bütünlük veya erişilebilirlik tehlikeye atılırsa ne olacağını anlamaya çalışır. Denetim programlarının genellikle bir güvenlik açığı taramasıyla değil bir risk değerlendirmesi veya detaylı incelemeyle başlamasının sebebi budur.

Örneğin: bir bordro sisteminin erişim kontrollerini denetlerken, ilk soru "MFA etkinleştirildi mi?" değildir. "Yetkisiz birinin maaş verilerini değiştirmesi veya KVB görmesi durumunda etki nedir?" sorusudur. Etkiyi bildikten sonra, mevcut kontrollerin (MFA, onay iş akışları, görev ayrılığı) uygun olup olmadığını değerlendirebilirsiniz.

İddiadan ziyade kanıt

Sistem sahipleri size işlerin yolunda gittiğini söyleyecektir. Bir denetçinin görevi doğrulamak, güvenmek değildir. Bu yapıtlar istemeyi gerekli kılar: bir yapılandırma ekranının ekran görüntüsü, kullanıcı erişim haklarının dışa aktarması, onay zaman damgalarıyla bir değişiklik bileti, bir kontrolün gerçekten çalışmasını gösteren log girişleri. Birisi "erişimi üç ayda bir gözden geçiririz" derse, denetçi sadece politikayı değil son üç inceleme kaydını görmeyi ister.

Bu kanıta dayalı alışkanlık, bir denetim bulgusu ile bir koridordaki konuşmanın ayrıştırılmasını sağlar. Bir bulgu incelemeyi kaldırmalıdır: ne test edildi, hangi nüfus örneklendu, hangi kriterler kullanıldı ve aslında ne gözlemlendi? "Kontroller yeterli görünüyor" gibi belirsiz ifadeler, yönetimin ve düzenleyicilerin okuyacağı bir raporda geçerli olmaz.

Tasarım ve işletim etkinliği

Bu alandaki en yararlı zihinsel ayrımlardan biri kontrol tasarımını kontrol işletim etkinliğinden ayırmaktır. 14 karakter gerektiren ve MFA kullanan bir parola politikası kağıt üzerinde iyi tasarlanmıştır. Ama son erişim incelemesi 11 ay önce yapıldıysa veya hizmet hesapları belgeleme olmaksızın hariç tutulduysa, kontrol amaçlandığı gibi çalışmıyor. Denetçiler her ikisini de test ederler: kontrol açıklandığı gibi var mı ve günlük olarak gerçekten uygulanıyor mu?

Örneklemenin önemli olmasının sebebi budur. Bir kullanıcının erişimini test etmek çok bilgi vermez. 25 işten ayrılmış çalışanın bir örneğini çekerek hesaplarının SLA penceresi içinde (diyelim 24 veya 48 saat) devre dışı bırakılıp bırakılmadığını kontrol etmek size savunulabilir bir sonuç temeli verir.

Görev ayrılığı yinelenen bir tema olarak

Denetim bulgularının büyük bir kısmı görev ayrılığı (SoD) hatasından kaynaklanır: değişikliği isteyen kişi aynı zamanda onu onaylar veya bir geliştirici üretim veritabanı erişimine sahiptir ve dağıtım haklarını da elinde bulundurur. Denetçiler bu örtüşmeleri sürekli ararlar, çünkü SoD başarısızlıkları dolandırıcılık ve istem dışı hataların ikinci bir göz olmadan kayıp gitmesine neden olur.

Bir ortamı gözden geçirirken sorun: bir eylemi başlatan kimdir, onu onaylayan kimdir ve onu yürüten kimdir? Bir kişi kompanse edici bir kontrol olmaksızın iki veya daha fazla rolü sahipse (örneğin başkası tarafından gözden geçirilen ayrıntılı günlük), bu belgelenmeye değer bir boşluktur.

Düzeltilen bulgular yazma

Teknik olarak doğru ama kimsenin harekete geçmediği bir bulgu israf edilmiş bir denetimdir. İyi bulgular koşulu (gözlenleni), kriterleri (ihlal ettiği politika veya standartu), nedenini (neden olduğunu) ve etkisini (hangi riski oluşturduğunu) belirtir — birçok denetim şirketinin kullandığı klasik 4C yapısı. "Erişim kontrolleri iyileştirilmeli" gibi belirsiz bulgular göz ardı edilir. "Örneklenen 25 işten ayrılmış çalışanın 14'ü, politika SEC-014'teki 24 saatlik hizmet dışı bırakma SLA'sını ihlal ederek ayrılış tarihinden sonra 5 günden fazla VPN erişimine sahip kaldı" gibi spesifik bulgular düzeltilir çünkü sahip tam olarak ne düzeltleyeceğini bilir.

Alışkanlığı geliştirme

Bu perspektifi resmi katılımlar değil sıradan sistemler üzerinde pratik yaparak geliştirirsiniz. Günlük olarak kullandığınız bir uygulamayı seçin ve sorun: başarısız olursa risk nedir, hangi kontroller var ve nasıl çalıştığını kanıtlarım? Bunu yeterince çok kez yaparsanız denetçinin içgüdüsü — şüphecilik ile kanıt talebinin birleşimi — otomatik hale gelir.

Bu tür kontrol ve risk düşüncesi ilginizi çekiyorsa, teknik olarak daha derinlemesine bir anlamlandırma için Korra Studio'nun erişim kontrol modelleri ve güvenlik yönetişimi çerçeveleri üzerine bölümlerini göz atın.