Yerel Kurumlar İçin Kapsamlı Endüstriyel Bilişim Denetimleri (IT Audit)

Bir kurumun sunucularının çalışıyor olması, güvenli ve denetlenebilir bir bilişim altyapısına sahip olduğu anlamına gelmez. Sahada uzun yıllardır karşılaştığım en önemli sorunlardan biri, kurumların ancak kesinti, veri kaybı veya güvenlik olayı yaşandıktan sonra gerçek risklerini fark etmesidir. Oysa kapsamlı bir IT Audit çalışması, olay yaşanmadan önce varlıkları, erişimleri, ağları, yedekleri, tedarikçi bağlantılarını ve kritik operasyon bağımlılıklarını görünür hale getirebilir. Özellikle üretim, su, enerji, ulaşım ve benzeri fiziksel operasyonların dijital sistemlerle yönetildiği yapılarda IT ve OT birlikte değerlendirilmelidir. Bu rehberde Yerel Kurumlar İçin Kapsamlı Endüstriyel Bilişim Denetimleri (IT Audit) yaklaşımını teknik kontrol listesinden yönetim raporuna, saha denetiminden 30, 90 ve 180 günlük iyileştirme planına kadar uygulama odaklı biçimde ele alacağız.

Endüstriyel Bilişim Denetimi (IT Audit) Nedir?

Endüstriyel bilişim denetimi, kurumun bilgi teknolojileri ile fiziksel operasyonları destekleyen OT sistemlerinin risk, güvenlik, süreklilik ve yönetişim açısından sistematik biçimde incelenmesidir. Denetim yalnızca güvenlik açığı taraması yapmaz, aynı zamanda hangi varlığın neden kritik olduğunu ve mevcut kontrollerin gerçekten çalışıp çalışmadığını araştırır. Kurum politikaları, teknik yapılandırmalar, kullanıcı yetkileri, yedekleme süreçleri, ağ mimarisi ve tedarikçi erişimleri birlikte değerlendirilir. Endüstriyel bilişim denetimi IT audit nasıl yapılır sorusunun doğru cevabı da bu nedenle tek bir araç veya test değildir. Sağlıklı yaklaşım, iş etkisini teknik kanıtlarla birleştiren risk tabanlı denetim metodolojisidir.

Bilgi Sistemleri Denetimi Nedir?

Bilgi sistemleri denetimi, kurumun teknoloji altyapısının güvenilir, kontrollü ve yönetilebilir biçimde çalışıp çalışmadığını değerlendirir. Sunucular, ağ cihazları, kullanıcı hesapları, uygulamalar, veritabanları ve güvenlik süreçleri denetim kapsamına girebilir. Denetçi yalnızca sistemin var olup olmadığına bakmaz, kontrolün tasarımı ile gerçek uygulama arasındaki farkı da inceler. Örneğin bir yedekleme prosedürü bulunabilir ancak geri dönüş testi yapılmıyorsa kontrol fiilen zayıftır. Bu nedenle iyi denetim doküman ile operasyonel kanıtı birlikte karşılaştırır.

Endüstriyel Bilişim Denetimi Nedir?

Endüstriyel bilişim denetimi klasik IT ortamına ek olarak SCADA, PLC, HMI, historian ve engineering workstation gibi OT varlıklarını da ele alır. Bu sistemlerin güvenlik yaklaşımı ofis bilgisayarlarından farklıdır çünkü yanlış müdahale fiziksel üretimi veya hizmet sürekliliğini etkileyebilir. Denetim sırasında kullanılabilirlik, güvenlik ve safety etkisi birlikte değerlendirilmelidir. Aktif tarama veya agresif test yöntemleri endüstriyel ortamda dikkatli planlanmalıdır. Amaç sistemi zorlamak değil, kontrollü kanıt üzerinden riski doğrulamaktır.

IT Audit ile Siber Güvenlik Denetimi Arasındaki Fark

IT Audit daha geniş bir yönetişim ve kontrol alanını kapsar. Siber güvenlik denetimi ağırlıklı olarak tehdit, koruma, tespit ve müdahale kontrollerine odaklanabilir. IT Audit ise varlık yönetimi, değişiklik yönetimi, yedekleme, erişim, tedarikçi yönetimi ve iş sürekliliği gibi alanları da değerlendirir. İki yaklaşımın önemli ortak noktaları vardır ancak amaç ve kapsamları tamamen aynı değildir. Kurumun ihtiyacına göre siber güvenlik kontrolleri kapsamlı IT Audit programının önemli bir parçası olabilir.

IT Audit ile Penetrasyon Testi Arasındaki Fark

Penetrasyon testi belirlenen hedeflerde güvenlik açıklarının pratik olarak istismar edilip edilemeyeceğini anlamaya çalışır. IT Audit ise yalnızca teknik açık bulmakla kalmaz, riskin neden oluştuğunu ve hangi süreç eksikliğinin tekrarına yol açabileceğini inceler. Örneğin penetrasyon testi zayıf parola bulabilir, denetim ise parola politikasının neden uygulanmadığını, ortak hesap kullanımını ve yetki yönetimini de araştırır. OT ortamında penetrasyon testinin kapsamı ayrıca güvenlik ve operasyon riski nedeniyle sınırlandırılabilir. Bu yüzden iki çalışma birbirinin yerine geçmez.

IT Audit ile Vulnerability Assessment Arasındaki Fark

Vulnerability Assessment sistemlerde bilinen zayıflıkları tespit etmeye odaklanır. Tarama sonucu yüzlerce teknik bulgu ortaya çıkabilir ancak bunların kurumsal etkisi aynı değildir. IT Audit bu bulguları varlık kritiklik derecesi, erişilebilirlik, iş etkisi ve mevcut koruyucu kontrollerle birlikte değerlendirir. Ayrıca taramanın göremediği süreç ve insan kaynaklı riskleri de inceler. Böylece teknik açık listesi iş önceliğine dönüşür.

IT Audit ile Uyum Denetimi Arasındaki Fark

Uyum denetimi belirli standart, mevzuat veya kurumsal politika gereksinimlerine uygunluğu değerlendirir. IT Audit ise uyumun yanında operasyonel güvenilirlik, kontrol etkinliği ve iş riski perspektifini de kullanabilir. Bir kurum bazı maddelere uyumlu olduğu halde pratikte ciddi operasyon riski taşıyabilir. Aynı şekilde bir kontrol standardın açık maddesi olmasa bile kritik hizmet için gerekli olabilir. Bu nedenle kapsamlı denetim yalnızca madde işaretlemek yerine gerçek riski anlamaya çalışmalıdır.

Neden Tek Bir Güvenlik Testi Kapsamlı Denetimin Yerini Tutmaz?

Teknik tarama yalnızca görebildiği sistem ve açıkları değerlendirir. Ortak yönetici hesapları, test edilmemiş yedekler, eski çalışan yetkileri veya kontrolsüz vendor erişimleri araç çıktısında her zaman görünmez. Ayrıca kritik hizmetin hangi sisteme bağımlı olduğu anlaşılmadan bulunan teknik açığın gerçek önceliği belirlenemez. Kapsamlı denetim teknik test, görüşme, doküman incelemesi ve saha gözlemini birlikte kullanır. Böylece kurum yalnızca açık listesini değil uygulanabilir risk yol haritasını elde eder.

Yerel Kurumlar Neden IT Audit Yaptırmalı?

Yerel kurumlar vatandaş hizmeti, üretim, su, enerji, sağlık veya ulaşım gibi kesintiye düşük toleransı olan süreçler yürütebilir. Bu hizmetlerin giderek daha büyük bölümü bilgi sistemlerine bağlı hale gelmektedir. Bir sunucu hatası, fidye yazılımı veya yanlış yetkilendirme doğrudan operasyon kaybına dönüşebilir. Düzenli denetim kurumun görünmeyen bağımlılıklarını ve kontrol eksiklerini ortaya çıkarır. Kurumlar için kapsamlı IT audit ve bilişim denetimi hizmeti bu nedenle yalnızca teknik kontrol değil süreklilik ve yönetişim yatırımıdır.

Dijital Hizmetlerin Kesintisizliği

Vatandaş veya müşteri tarafından kullanılan dijital hizmetlerin kesilmesi kurumun işleyişini doğrudan etkileyebilir. Denetim kritik uygulamaların tek sunucuya veya tek bağlantıya bağımlı olup olmadığını inceler. Alternatif erişim ve failover mekanizmaları değerlendirilir. Bakım ve değişiklik süreçlerinin hizmet kesintisi oluşturma riski kontrol edilir. Amaç kesinti ihtimalini tamamen sıfırlamak değil dayanıklılığı ölçmek ve geliştirmektir.

Kritik Verilerin Korunması

Kurumların kişisel, finansal veya operasyonel açıdan hassas verileri olabilir. Bu verilerin kimler tarafından görüntülenebildiği ve dışarı aktarılabildiği açık biçimde bilinmelidir. Şifreleme, yetkilendirme, loglama ve veri saklama kontrolleri denetlenir. Kritik verinin hangi sistemlerde kopyalandığı da önemlidir. Koruma yalnızca merkezi veritabanına değil tüm yaşam döngüsüne uygulanmalıdır.

Siber Saldırı Riskinin Azaltılması

Denetim internete açık servisleri, zayıf erişim kontrollerini ve güncel olmayan sistemleri görünür hale getirebilir. Ancak amaç yalnızca açık bulmak değildir. Saldırganın hangi zinciri kullanarak kritik varlığa ulaşabileceği değerlendirilmelidir. MFA, segmentasyon ve izleme gibi savunma katmanlarının etkinliği test edilir. Yüksek riskli alanlar öncelikli iyileştirme planına alınır.

Eski Sistemlerden Kaynaklanan Risklerin Belirlenmesi

Yerel kurumlarda uzun yıllardır çalışan ve üretici desteği sona ermiş sistemlerle sık karşılaşılır. Bu sistemlerin hemen değiştirilmesi her zaman mümkün değildir. Denetim EOL riskini ve sistemin kritik hizmetlerle ilişkisini değerlendirir. Patch uygulanamayan varlıklar için segmentasyon veya erişim kısıtı gibi compensating control seçenekleri belirlenebilir. Böylece yenileme kararı iş riskine göre planlanır.

Yetkisiz Erişimlerin Önlenmesi

Yetkisiz erişim yalnızca dış saldırgan anlamına gelmez. Eski çalışan hesabı, paylaşılmış parola veya gereğinden fazla yetki de risk oluşturur. Denetim kullanıcı yaşam döngüsünü ve ayrıcalıklı hesapları inceler. Rol bazlı erişim ve least privilege yaklaşımı değerlendirilir. Kritik sistemlerde erişimin kişiye ve ihtiyaca bağlanması hedeflenir.

Yedekleme ve Felaket Kurtarma Kapasitesinin Ölçülmesi

Yedek almak ile geri dönebilmek aynı şey değildir. Denetimde başarılı backup raporları kadar restore testleri de incelenir. Offline veya immutable kopyaların varlığı fidye yazılımı riskine karşı önemlidir. RTO ve RPO değerleri iş ihtiyacına göre değerlendirilir. Kurum gerçek bir olayda hangi sistemi ne kadar sürede geri getirebileceğini bilmelidir.

Mevzuat ve Kurumsal Politikalara Uyum

Kurumlar kendi sektörlerine göre farklı yasal ve kurumsal gereksinimlere tabi olabilir. Denetim mevcut politika ve prosedürlerle gerçek uygulama arasındaki farkı ortaya çıkarır. Teknik tedbirlerin belgelenmesi ve kanıtlanması önemlidir. Uyum kontrolü yalnızca doküman varlığına indirgenmemelidir. Sürecin gerçekten çalıştığı teknik ve operasyonel kayıtlarla gösterilmelidir.

BT Yatırımlarının Etkinliğinin Ölçülmesi

Kurum önemli güvenlik ürünleri satın almış olabilir ancak bu ürünlerin etkin kullanılmadığı görülebilir. SIEM kurulmuş fakat kritik loglar gelmiyor olabilir. EDR lisansları bulunabilir fakat bütün sunucularda aktif olmayabilir. Denetim yatırımın kapsama ve gerçek kontrole dönüşüp dönüşmediğini ölçer. Böylece yeni ürün almadan önce mevcut yatırımın kullanım seviyesi iyileştirilebilir.

Hangi Yerel Kurumlar Endüstriyel Bilişim Denetimine İhtiyaç Duyar?

Endüstriyel bilişim denetimi yalnızca büyük fabrikalar için gerekli değildir. Fiziksel hizmeti dijital sistemlerle kontrol eden belediye, su idaresi, OSB, enerji altyapısı ve ulaşım sistemi de benzer riskler taşıyabilir. Üniversite, sağlık kuruluşu ve sanayi odalarında ise IT hizmet sürekliliği ve veri güvenliği daha fazla öne çıkar. Tarımsal sulama sistemleri bile uzaktan yönetim ve sensör altyapısı kullandıkça OT güvenliği kapsamına yaklaşır. Denetim ihtiyacını kurum adı değil kritik hizmet ve teknoloji bağımlılığı belirlemelidir.

Belediyeler

Belediyeler çok sayıda vatandaş hizmetini dijital altyapı üzerinden sunabilir. E-belediye sistemleri, ödeme uygulamaları, saha terminalleri ve kurumsal ağlar aynı yapıda bulunabilir. Trafik veya altyapı kontrol sistemleri OT özellikleri de taşıyabilir. Denetim hizmet sürekliliği, veri güvenliği ve üçüncü taraf erişimini birlikte incelemelidir. Çok sayıda birim bulunması kimlik ve varlık yönetimini özellikle önemli hale getirir.

Su ve Kanalizasyon İdareleri

Su yönetiminde SCADA ve uzaktan kontrol altyapıları kritik rol oynayabilir. Pompa, depo ve vana gibi fiziksel süreçler dijital sistemlerden etkilenebilir. IT ve OT arasındaki ağ geçişleri dikkatle değerlendirilmelidir. Uzaktan bakım erişimi ve eski PLC sistemleri özel risk taşıyabilir. Denetimde siber güvenlik ile fiziksel hizmet sürekliliği birlikte ele alınmalıdır.

Organize Sanayi Bölgeleri

OSB yönetimleri enerji, su, güvenlik, altyapı ve kurumsal bilişim hizmetlerini aynı anda yürütebilir. SCADA ve sayaç sistemleri ile klasik IT altyapısı birbirine bağlı olabilir. Vendor sayısı yüksek olduğu için üçüncü taraf erişimleri önemli risk oluşturabilir. Ağ segmentasyonu ve varlık envanteri temel kontrol alanlarıdır. Düzenli denetim bölgedeki kritik altyapı hizmetlerinin güvenilirliğini destekler.

Yerel Üretim Tesisleri

Üretim tesislerinde ERP, MES, SCADA ve PLC sistemleri aynı süreç zincirinde bulunabilir. IT sistemindeki kesinti üretim planını, OT tarafındaki sorun ise fiziksel operasyonu durdurabilir. Eski makineler ve desteklenmeyen işletim sistemleri sık görülen risklerdir. Denetim üretim duruşu ihtimalini iş etkisi olarak değerlendirmelidir. Safety gereksinimleri test yöntemini doğrudan etkiler.

Enerji ve Dağıtım Altyapıları

Enerji sistemlerinde kullanılabilirlik ve uzaktan kontrol güvenliği kritik önemdedir. SCADA, telemetri ve saha cihazları geniş coğrafyaya yayılmış olabilir. Haberleşme altyapısı ve vendor erişimleri incelenmelidir. Fiziksel kesinti riski nedeniyle aktif testler özel planlama ister. Denetim yedeklilik, segmentasyon ve olay müdahale kapasitesine odaklanmalıdır.

Ulaşım ve Trafik Sistemleri

Sinyalizasyon, trafik kontrolü ve saha cihazları merkezi sistemlerle yönetilebilir. Ağ bağlantısındaki problem fiziksel hizmet kalitesini etkileyebilir. Uzaktan erişim ve cihaz güncelleme süreçleri kontrol edilmelidir. Kritik kontrol merkezlerinin fiziksel güvenliği de denetim kapsamındadır. Kesinti senaryoları manuel operasyon prosedürleriyle birlikte değerlendirilmelidir.

Üniversiteler

Üniversitelerde öğrenci, akademisyen ve misafir ağları aynı kurum içinde bulunur. Çok sayıda laboratuvar ve bağımsız sistem Shadow IT riskini artırabilir. Araştırma verileri ve kişisel bilgiler özel koruma gerektirir. Kimlik yönetimi ve ağ segmentasyonu temel alanlardır. Denetim merkezi IT ile fakülte sistemleri arasındaki yönetişim farklarını da görünür hale getirir.

Ticaret ve Sanayi Odaları

Odalar üye kayıtları, ödeme sistemleri ve kurumsal hizmetler için önemli veri tutabilir. Üyelerle iletişim ve proje platformları dış erişime açık olabilir. Tedarikçi tabanlı yazılım kullanımı sık görülebilir. Denetim cloud, SaaS ve üçüncü taraf risklerini değerlendirmelidir. Odanın yerel teknoloji ekosistemindeki rolü nedeniyle kendi güvenlik olgunluğu da örnek teşkil edebilir.

Sağlık Kuruluşları

Sağlık sistemlerinde kişisel veri ile hizmet sürekliliği aynı anda kritiktir. Tıbbi cihazlar ağ bağlantısı taşıyabilir ve klasik IT sistemleriyle iletişim kurabilir. Erişim kontrolü ve loglama büyük önem taşır. Yedekleme ile felaket kurtarma senaryoları düzenli test edilmelidir. Denetim hasta hizmetine etkisini temel risk kriteri olarak kullanmalıdır.

Tarımsal Üretim ve Sulama Sistemleri

Uzaktan sulama, sensör ve pompa kontrol sistemleri giderek daha fazla dijitalleşmektedir. Bu sistemler düşük maliyetli IoT cihazları kullanabilir. Varsayılan parola ve doğrudan internet erişimi riskleri görülebilir. Haberleşme kesintisinde manuel işletme seçeneği değerlendirilmelidir. Yerel denetim tarımsal operasyonun fiziksel sürekliliğini dijital güvenlikle birlikte incelemelidir.

IT, OT ve IoT Arasındaki Fark Nedir?

IT, OT ve IoT aynı ağda bulunabilse de görevleri ve risk profilleri farklıdır. IT bilgi işleme, kullanıcı ve kurumsal uygulamalara odaklanır. OT fiziksel proses ve makinelerin kontrolünü destekler. IoT ve IIoT ise fiziksel cihazlardan veri toplama veya uzaktan etkileşim sağlayan bağlantılı sistemlerdir. Endüstriyel tesislerde bilgi teknolojileri ve OT sistemleri güvenlik denetimi yapılırken bu farklılıkların dikkate alınması test güvenliği ve risk önceliği açısından zorunludur.

Information Technology (IT)

IT ortamı kullanıcı, veri ve kurumsal uygulamalar çevresinde şekillenir. Sunucu, dizüstü bilgisayar, e-posta ve veritabanı sistemleri tipik varlıklardır. Gizlilik ve veri bütünlüğü önemli güvenlik hedefleridir. Yüksek kullanılabilirlik de kritik hizmetlerde önem taşır. IT kontrolleri genellikle standart patch, EDR ve kimlik yönetimi süreçleriyle daha kolay uygulanabilir.

Sunucular

Sunucular uygulama, veri ve kimlik hizmetlerini barındırabilir. İşletim sistemi güncelliği ve güvenli yapılandırma temel kontroldür. Kritik servislerin yedekli çalışması değerlendirilmelidir. Yerel administrator ve service account yetkileri izlenmelidir. Sunucu loglarının merkezi sisteme aktarılması olay tespitini güçlendirir.

Kullanıcı Bilgisayarları

Kullanıcı bilgisayarları phishing ve zararlı yazılım saldırılarının sık giriş noktasıdır. EDR, disk şifreleme ve güncel işletim sistemi kontrolleri önemlidir. Kullanıcıların local administrator olması riski artırabilir. USB ve dış medya politikaları kuruma göre düzenlenebilir. Cihaz envanteri kayıp veya izinsiz sistemlerin bulunmasını sağlar.

Veritabanları

Veritabanları kritik kurumsal verileri tutabilir. Yetkiler rol bazlı ve ihtiyaca göre verilmelidir. Yönetici erişimleri ayrıca izlenebilir. Yedekleme ve şifreleme kontrolleri veri kritikliğine göre uygulanmalıdır. Uygulama hesaplarının gereğinden fazla yetki taşımaması önemlidir.

Kurumsal Uygulamalar

ERP, insan kaynakları ve belge yönetimi gibi uygulamalar kurumun temel süreçlerini destekler. Uygulama yetkileri iş rolüyle uyumlu olmalıdır. Kullanıcı ayrıldığında hesap kapatma süreci çalışmalıdır. Log ve değişiklik kayıtları incelenebilir olmalıdır. Uygulama sağlayıcısının uzaktan erişimi kontrol altında tutulmalıdır.

E-posta Sistemleri

E-posta kullanıcı kimliği ve kurumsal iletişimin merkezinde yer alır. MFA ve anti-phishing kontrolleri temel güvenlik katmanıdır. SPF, DKIM ve DMARC yapılandırmaları etki alanı sahteciliğini azaltabilir. Yetkisiz forwarding kuralları veri kaybı riskine yol açabilir. Admin hesapları normal kullanıcı hesaplarından ayrılmalıdır.

Operational Technology (OT)

OT sistemleri fiziksel süreçleri izler veya kontrol eder. Kullanılabilirlik ve operasyon güvenliği çoğu zaman öncelikli hedeftir. Bazı sistemlerin güncellenmesi üretim duruşu gerektirebilir. Bu nedenle IT'deki standart patch yaklaşımı doğrudan uygulanamayabilir. Denetim OT yaşam döngüsü ve üretici kısıtlarını dikkate almalıdır.

SCADA

SCADA merkezi izleme ve kontrol işlevi sağlar. Sunucular, operatör istasyonları ve saha bağlantıları kritik varlıklardır. Yetkilendirme ve ağ segmentasyonu temel kontrol alanıdır. Vendor erişimleri ayrıca kayıt altına alınmalıdır. SCADA yedeği yalnızca veri değil proje ve konfigürasyonları da kapsamalıdır.

PLC

PLC fiziksel prosesin kontrol mantığını çalıştırabilir. Programlama erişimi sınırlı olmalıdır. Varsayılan parola veya açık programlama portu önemli risk oluşturabilir. PLC firmware güncellemesi üretici prosedürüne göre planlanmalıdır. Program yedeği düzenli alınmalı ve geri yükleme yöntemi bilinmelidir.

DCS

DCS geniş proses kontrol ortamlarında kullanılabilir. Operatör, mühendislik ve kontrol katmanları birlikte değerlendirilmelidir. Ağ tasarımı ve yetki modeli kritik önemdedir. Sistem değişiklikleri change management sürecine bağlı olmalıdır. Yedek ve konfigürasyon kontrolü operasyon sürekliliğini doğrudan etkiler.

HMI

HMI operatörün prosesle etkileşim kurduğu arayüzdür. Ortak hesap kullanımı burada sık görülebilir. Yönetici yetkisi günlük operasyon için gerekli olmayabilir. İşletim sistemi güvenliği ve fiziksel erişim birlikte değerlendirilmelidir. HMI projesinin yedeği düzenli tutulmalıdır.

Engineering Workstation

Engineering Workstation PLC ve kontrol sistemlerinin yapılandırılması için yüksek yetki taşır. Bu nedenle kritik varlık olarak sınıflandırılmalıdır. İnternet erişimi ve genel ofis kullanımından mümkün olduğunca ayrılmalıdır. Yetkili kişiler ve kullanılan yazılımlar envanterde tutulmalıdır. Sistem imajı ve proje dosyaları yedeklenmelidir.

Historian

Historian uzun dönem operasyon verisini saklar. IT ve OT arasında veri aktarım noktası olabilir. Bu nedenle ağ mimarisindeki konumu önemlidir. Veri bütünlüğü ve erişim yetkileri kontrol edilmelidir. Yedek ve retention politikası iş ve teknik ihtiyaçla uyumlu olmalıdır.

IoT ve IIoT Cihazları

IoT cihazları sensör, kamera, sayaç veya gateway biçiminde olabilir. IIoT ise endüstriyel kullanım senaryolarına daha yakın cihaz ve haberleşme yapısını ifade eder. Varsayılan kimlik bilgileri ve güncellenmeyen firmware ciddi risk oluşturabilir. Cihazların hangi bulut servisine bağlandığı bilinmelidir. Envanter ve ağ segmentasyonu IoT denetiminin temelidir.

IT–OT Convergence Nedir?

IT ve OT sistemlerinin veri ve süreç açısından birbirine bağlanmasına IT–OT convergence denir. ERP'nin üretim sisteminden gerçek zamanlı veri alması buna örnek olabilir. Bu entegrasyon operasyonel değer üretirken saldırı yollarını da genişletebilir. Güven sınırları ve veri akışları açıkça tanımlanmalıdır. Denetim IT'den OT'ye hangi erişimlerin gerçekten gerekli olduğunu sorgular.

IT Açığının Fiziksel Operasyonu Etkilemesi Nasıl Mümkün Olur?

IT ağı ile OT arasında kontrolsüz bağlantı varsa ofis tarafındaki saldırı üretim ağına ilerleyebilir. Ele geçirilen yönetici hesabı jump host veya uzaktan erişim sistemi üzerinden OT'ye ulaşabilir. Ransomware doğrudan PLC'yi hedeflemese bile SCADA veya historian sunucularını devre dışı bırakabilir. Bu durum operatör görünürlüğünü ve kontrol yeteneğini azaltır. Segmentasyon, MFA ve izleme bu zincirin kırılmasında temel kontrollerdir.

IT Audit Öncesinde Kurumun Kritik Hizmetleri Belirlenmeli

Denetimin ilk teknik adımı tarama yapmak değil kurumun hangi hizmetleri kritik gördüğünü anlamaktır. Aynı güvenlik açığı farklı kurumlarda tamamen farklı iş etkisi yaratabilir. Kritik hizmetin desteklediği sistemler, insanlar ve dış bağımlılıklar haritalanmalıdır. Business Impact Analysis bu ilişkiyi ölçülebilir hale getirir. Risk tabanlı IT Audit ancak teknik varlıkları gerçek hizmet etkisiyle eşleştirdiğinde anlamlı sonuç üretir.

Kurum Hangi Hizmetleri Sunuyor?

Denetim ekibi kurumun temel hizmetlerini yönetim ve süreç sahipleriyle birlikte listelemelidir. Vatandaş hizmeti, üretim, ödeme, izleme veya kontrol işlevleri ayrı başlık olabilir. Her hizmetin teknoloji bağımlılığı belirlenir. Günlük operasyonun hangi sistemlerle yürüdüğü anlaşılır. Böylece teknik envanter iş perspektifiyle ilişkilendirilir.

Hangi Hizmetler Kesintiye Tahammül Edemez?

Her hizmet aynı kritik seviyede değildir. Bazı uygulamalar birkaç saat bekleyebilirken bazı sistemlerde dakikalar bile ciddi etki yaratabilir. Yönetim kabul edilebilir kesinti süresini belirlemelidir. Bu bilgi RTO hedefinin temelini oluşturur. Yüksek kritiklik taşıyan hizmetler denetimde daha fazla kanıt ve kontrol gerektirir.

Hangi Sistemler Bu Hizmetleri Destekliyor?

Bir hizmet tek uygulamadan oluşmayabilir. Active Directory, DNS, veritabanı, ağ, depolama ve internet bağlantısı aynı hizmetin çalışması için gerekebilir. Denetim bu bağımlılık zincirini çıkarmalıdır. Sadece ana uygulamayı yedeklemek yeterli olmayabilir. Gerçek kurtarma planı destek sistemlerini de kapsamalıdır.

Sistemler Arasındaki Bağımlılıklar Nelerdir?

Bağımlılık haritası tek hata noktalarını görünür hale getirir. Bir uygulamanın farklı görünmesine rağmen aynı veritabanına bağlı olduğu anlaşılabilir. OT ve IT arasında historian veya kimlik sistemi üzerinden bağlantı bulunabilir. Üçüncü taraf servis kesintisi de kritik zincirin parçası olabilir. Denetim bu ilişkileri network ve uygulama diyagramlarıyla doğrulamalıdır.

Kritik İş Etki Analizi Nasıl Yapılır?

İş Etki Analizi kesintinin kurum üzerinde oluşturacağı sonucu belirler. Finansal kayıp tek değerlendirme ölçütü değildir. Operasyon, hukuk, itibar ve fiziksel güvenlik etkileri birlikte ele alınmalıdır. Etki belirli zaman aralıklarında artabilir. Bu analiz risk puanlama ve kurtarma önceliğinin temel girdisi olur.

Finansal Etki

Kesinti doğrudan gelir veya ek maliyet yaratabilir. Fazla mesai, hizmet telafisi ve tedarikçi desteği hesaba katılabilir. Üretim kaybı parasal değere çevrilebilir. Bazı kamu kurumlarında doğrudan gelir yerine hizmet maliyeti dikkate alınır. Finansal etki diğer etki alanlarıyla birlikte değerlendirilmelidir.

Operasyonel Etki

Sistem kesildiğinde hangi operasyonun durduğu belirlenmelidir. Manuel çalışma seçeneği varsa kapasitesi değerlendirilir. Kaç kullanıcı veya tesis etkilendiği ölçülebilir. Kesinti uzadıkça alternatif süreçler yetersiz kalabilir. Operasyonel etki kritik hizmet sıralamasında güçlü sinyal sağlar.

Hukuki Etki

Kesinti veya veri kaybı sözleşme ve yasal yükümlülükleri etkileyebilir. Bildirim süreleri ve kayıt tutma zorunlulukları incelenmelidir. Kritik logların kaybı denetim ve olay incelemesini zorlaştırabilir. Veri ihlali hukuki süreç doğurabilir. Denetim hukuki etkiyi ilgili birim görüşüyle değerlendirmelidir.

İtibar Etkisi

Uzun kesinti kurum güvenini zedeleyebilir. Vatandaş veya müşteri iletişimi bu etkinin büyüklüğünü değiştirir. Tekrarlanan olaylar daha ciddi algı oluşturabilir. Olay iletişim planı bu nedenle iş sürekliliği çalışmasının parçasıdır. İtibar etkisi yönetim perspektifinde ayrıca değerlendirilmelidir.

Can ve Fiziksel Güvenlik Etkisi

OT ortamında dijital risk fiziksel güvenliği etkileyebilir. Yanlış kontrol komutu veya görünürlük kaybı tehlikeli operasyon koşulu oluşturabilir. Safety sistemleri siber güvenlikten tamamen ayrı düşünülmemelidir. Denetim güvenlik testinin fiziksel riske yol açmamasını sağlamalıdır. Bu etki yüksekse risk seviyesi teknik açıktan bağımsız olarak yükseltilebilir.

Denetim Kapsamı Nasıl Belirlenir?

Denetim kapsamı bütün sistemleri sınırsız biçimde test etmek değildir. Risk, kritik hizmet, fiziksel lokasyon ve teknoloji sınırları dikkate alınarak açık scope hazırlanmalıdır. Hangi sistemlerin dahil ve hariç olduğu yazılı hale getirilmelidir. OT, bulut ve üçüncü taraf hizmetler ayrı biçimde değerlendirilmelidir. Scope dokümanı hem denetim güvenliğini hem de raporun beklenti yönetimini sağlar.

Risk Tabanlı Scope Belirleme

En yüksek iş etkisi taşıyan hizmetler ve varlıklar öncelikli olmalıdır. İnternete açık sistemler ve ayrıcalıklı erişim noktaları ayrıca değerlendirilir. Geçmiş olaylar scope seçiminde veri sağlayabilir. Her varlığı aynı detayda denetlemek gereksiz maliyet yaratabilir. Kaynaklar riskin yüksek olduğu alanlara yönlendirilmelidir.

Fiziksel Lokasyonların Belirlenmesi

Kurum birden fazla bina, tesis veya saha noktasına sahip olabilir. Her lokasyondaki ağ ve fiziksel güvenlik yapısı farklı olabilir. Denetim yapılacak örnek lokasyonlar risk kriterine göre seçilebilir. Kritik kontrol merkezi mutlaka kapsama alınabilir. Lokasyonlar raporda açıkça belirtilmelidir.

Sistem ve Uygulama Sınırlarının Belirlenmesi

Denetlenecek uygulamanın yalnızca ön yüzü değil destek servisleri de tanımlanmalıdır. Veritabanı, kimlik sistemi ve entegrasyon servisleri sınır içinde olabilir. Üçüncü taraf API kullanımı not edilmelidir. Test ortamı ile üretim ortamı ayrıştırılır. Böylece denetim ekibi hangi varlık üzerinde hangi kontrolü uygulayacağını bilir.

OT Tesislerinin Kapsama Alınması

OT ortamının dahil edilmesi özel hazırlık gerektirir. Üretim sorumluları ve safety ekipleri çalışma planına katılmalıdır. Aktif test izinleri açıkça belirlenmelidir. Pasif varlık keşfi mümkün olduğunda tercih edilebilir. Kritik süreçlere dokunmadan yeterli audit evidence toplanması hedeflenmelidir.

Bulut Sistemlerinin Kapsama Alınması

Kurumsal SaaS ve cloud sistemleri kurum veri merkezinin dışında olsa da risk kurumda kalır. Identity, MFA, admin hesabı ve loglama kontrolleri denetlenmelidir. Paylaşılan sorumluluk modeli anlaşılmalıdır. Yedek ve veri saklama seçenekleri incelenmelidir. Cloud envanteri Shadow SaaS tespitini de kapsamalıdır.

Üçüncü Taraf Hizmetlerin Kapsama Alınması

Vendor, bakım firması ve dış yazılım sağlayıcıları kritik sistemlere erişebilir. Sözleşme ve teknik erişim birlikte incelenmelidir. Denetimin hangi üçüncü taraf kanıtlarına erişebileceği önceden belirlenmelidir. Tedarikçi güvenlik sorumlulukları SLA içinde bulunmalıdır. Scope dışında bırakılan vendor bağımlılıkları ayrıca risk olarak not edilebilir.

Denetim Dışı Bırakılan Sistemlerin Belgelenmesi

Her sistem denetlenemeyebilir. Hariç bırakılan varlık ve gerekçesi raporda açıkça belirtilmelidir. Böylece yönetim denetim sonucunu tüm kurum için yanlış biçimde genellemez. Yüksek risk taşıyan ama scope dışında kalan sistemler sonraki faza alınabilir. Bu şeffaflık denetim kalitesini artırır.

Denetim Scope Dokümanı Nasıl Hazırlanır?

Scope dokümanında amaç, lokasyon, sistem, test tipi ve kısıtlar bulunmalıdır. Yetkili iletişim kişileri belirtilmelidir. OT ortamında çalışma pencereleri eklenebilir. Kanıt erişimi ve veri gizliliği kuralları yazılmalıdır. Doküman denetim başlamadan önce ilgili taraflarca onaylanmalıdır.

İlk Adım: Kapsamlı IT ve OT Varlık Envanteri

Denetleyemediğiniz varlığı korumak zordur. Bu nedenle güvenilir envanter IT Audit'in en önemli başlangıç noktalarından biridir. Donanım, yazılım, ağ, kullanıcı, cloud ve OT varlıkları mümkün olduğunca tek veri modeliyle ilişkilendirilmelidir. Envanter yalnızca cihaz adından oluşmamalı, sahibi, kritiklik seviyesi, destek durumu ve bağlantıları da göstermelidir. Özellikle OT ortamında pasif keşif ve saha doğrulaması envanter kalitesini önemli ölçüde artırabilir.

Donanım Envanteri

Sunucu, bilgisayar, switch, firewall ve fiziksel appliance cihazları listelenmelidir. Seri numarası ve lokasyon bilgisi tutulabilir. Cihaz sahibi veya sorumlu birim belirlenmelidir. Aktif olmayan ancak ağda bulunan eski cihazlar ayrıca işaretlenmelidir. Envanter değişiklik süreçleriyle güncel tutulmalıdır.

Yazılım Envanteri

İşletim sistemi, kurumsal uygulama ve kritik yardımcı yazılımlar kaydedilmelidir. Sürüm ve lisans bilgisi önemlidir. EOL veya desteklenmeyen yazılımlar risk olarak sınıflandırılabilir. Uygulamanın sahibi ve tedarikçisi belirtilmelidir. Yazılım envanteri patch yönetimiyle ilişkilendirilmelidir.

Network Envanteri

Switch, router, firewall, access point ve VPN cihazları ağ envanterinde yer almalıdır. Yönetim IP'leri ve firmware sürümleri kaydedilebilir. Cihazların hangi segmenti yönettiği belirtilmelidir. Yedek konfigürasyon durumu kontrol edilmelidir. Ağ diyagramı envanterle uyumlu olmalıdır.

Kullanıcı ve Hesap Envanteri

İnsan kullanıcılar kadar service account ve ayrıcalıklı hesaplar da listelenmelidir. Hesap sahibi ve kullanım amacı bilinmelidir. Son kullanım tarihi eski hesapların tespitini kolaylaştırır. Shared account'lar ayrıca işaretlenebilir. Hesap envanteri insan kaynakları süreciyle düzenli karşılaştırılmalıdır.

Bulut Servisleri Envanteri

Microsoft 365, Google Workspace, IaaS ve diğer SaaS uygulamaları kayıt altına alınmalıdır. Kurum verisinin hangi bölgede veya sağlayıcıda tutulduğu bilinmelidir. Admin hesapları ve entegrasyonlar ayrıca listelenmelidir. Kullanıcıların kişisel kredi kartıyla açtığı Shadow SaaS hizmetleri de risk oluşturabilir. Cloud haritası veri sınıflandırmasıyla ilişkilendirilmelidir.

OT Varlık Envanteri

OT envanteri yalnızca SCADA sunucusundan oluşmaz. PLC, HMI, engineering workstation, historian, sensör ve gateway gibi cihazlar ayrı kayıt edilmelidir. Firmware ve üretici desteği özellikle önemlidir. Fiziksel proses ilişkisi varlık kaydına eklenebilir. Böylece teknik açık gerçek operasyon etkisiyle eşleştirilebilir.

PLC'ler

PLC marka, model ve firmware bilgisi tutulmalıdır. Hangi prosesi kontrol ettiği belirtilmelidir. Program yedeğinin son tarihi kaydedilebilir. Ağ erişimi ve programlama protokolü kontrol edilmelidir. Üretici desteği sona ermiş cihazlar yenileme planına alınmalıdır.

HMI'lar

HMI cihazı ve proje sürümü envanterde yer almalıdır. İşletim sistemi güncelliği kaydedilmelidir. Operatör hesap modeli belirtilmelidir. Hangi PLC veya SCADA ile haberleştiği bilinmelidir. Proje yedeği doğrulanmalıdır.

SCADA Sunucuları

SCADA sunucularının rolü ve yedekli yapısı belirtilmelidir. İşletim sistemi ve uygulama sürümü kaydedilir. Network zone bilgisi envantere eklenebilir. Vendor erişim yöntemi ayrıca gösterilir. Yedek ve lisans bağımlılıkları kritik operasyon bilgisi olarak tutulmalıdır.

Engineering Workstation'lar

Bu sistemler yüksek yetkili araçlara sahiptir. Kimlerin eriştiği envanterde açıkça belirtilmelidir. İnternet ve USB kullanım politikaları not edilebilir. Yüklü mühendislik yazılımlarının sürümleri tutulmalıdır. Golden image veya sistem imajı varlığı kontrol edilmelidir.

Historian Sistemleri

Historian sunucusu hangi OT kaynaklarından veri aldığını göstermelidir. IT tarafında hangi uygulamaların bu veriye eriştiği belirlenmelidir. Veri saklama süresi ve yedekleme durumu kaydedilir. Sistem sahibi tanımlanmalıdır. Network konumu ve güvenlik duvarı akışları envanterle ilişkilendirilebilir.

Sensörler ve Aktüatörler

Kritik sensör ve aktüatörler işleviyle birlikte kayıt altına alınabilir. Özellikle IP tabanlı cihazlar ayrı izlenmelidir. Firmware ve haberleşme protokolü bilinmelidir. Fiziksel arıza ile siber olayın etkisi benzer olabilir. Envanter bakım sistemiyle ilişkilendirildiğinde daha fazla değer üretir.

Industrial Gateway'ler

Gateway cihazları farklı protokoller arasında köprü görevi görebilir. Bu nedenle güven sınırında yer alabilir. Yönetim arayüzü ve kimlik bilgileri kontrol edilmelidir. Cloud bağlantısı varsa hedef servis bilinmelidir. Firmware ve uzaktan güncelleme yöntemi envanterde tutulmalıdır.

Her Varlık İçin Tutulması Gereken Bilgiler

Varlık kaydı yalnızca cihaz adı tutarsa denetim ve risk yönetimi için yetersiz kalır. Sahiplik, adres, üretici, sürüm, lokasyon, kritiklik ve destek durumu temel alanlar olabilir. Network bağlantıları sistemin saldırı yüzeyini anlamayı kolaylaştırır. Bu bilgiler otomatik keşif ve manuel doğrulama ile birleştirilebilir. Envanter değişiklik yönetiminin yaşayan çıktısı olmalıdır.

Varlık Sahibi

Her kritik varlığın iş veya teknik sahibi bulunmalıdır. Sahipsiz sistemlerde patch ve risk kararları gecikebilir. Varlık sahibi kullanım amacını açıklayabilmelidir. Sistem değişikliğinde ilgili kişi bilgilendirilir. Risk kabul kararı doğru role yönlendirilebilir.

IP / MAC

IP ve MAC bilgisi network görünürlüğünü destekler. Dinamik adres kullanılan cihazlarda ilişki dikkatle tutulmalıdır. OT cihazlarında sabit IP yaygın olabilir. Envanter ile network keşfi karşılaştırılabilir. Bilinmeyen adresler Shadow IT tespiti için sinyal sağlar.

Üretici ve Model

Üretici ve model bilgisi güvenlik duyurularının takibini kolaylaştırır. Firmware uygunluğu bu veriye bağlıdır. EOL tarihi üreticiden kontrol edilebilir. Yedek parça ve destek riski değerlendirilebilir. Aynı model cihazların toplu risk analizi yapılabilir.

Firmware / İşletim Sistemi

Sürüm bilgisi vulnerability ve patch değerlendirmesi için gereklidir. Güncellik tek başına yeterli güvenlik ölçüsü değildir. Desteklenen sürüm olup olmadığı kontrol edilmelidir. OT ortamında güncellemenin proses etkisi ayrıca değerlendirilir. Değişiklik sonrası envanter kaydı güncellenmelidir.

Lokasyon

Varlığın fiziksel konumu olay müdahale ve bakım için önemlidir. Uzak saha cihazlarına erişim süresi farklı olabilir. Fiziksel güvenlik seviyesi lokasyona göre değişir. Network odası ve kontrol odası gibi alanlar ayrıca sınıflandırılabilir. Envanter saha koordinatlarıyla gerektiğinde ilişkilendirilebilir.

Kritik Seviyesi

Her varlığın hizmet etkisi aynı değildir. Kritiklik iş etki analizi üzerinden belirlenmelidir. İnternete açık düşük kritik sistem ile izole yüksek kritik sistem farklı risk profiline sahip olabilir. Risk skoru bu değeri kullanabilir. Patch ve backup öncelikleri kritiklik seviyesine göre yönetilebilir.

Destek Durumu

Üretici desteği devam ediyor mu bilinmelidir. EOL varlıklar açıkça işaretlenmelidir. Destek sözleşmesi ve bakım sağlayıcısı kaydedilebilir. Kritik desteksiz sistemler yenileme planına alınır. Yenileme mümkün değilse telafi edici kontroller oluşturulur.

Network Bağlantıları

Varlığın hangi segment ve sistemlerle iletişim kurduğu bilinmelidir. Gereksiz erişimler saldırı yüzeyini artırabilir. Network akışları firewall kurallarıyla karşılaştırılabilir. OT varlığının internet erişimi özel olarak değerlendirilir. Bağlantı haritası zone ve conduit tasarımını destekler.

Shadow IT ve Bilinmeyen Varlıkların Tespit Edilmesi

Kayıtlı envanter çoğu kurumda gerçek ağın tamamını göstermeyebilir. Yetkisiz access point, kişisel bulut hesabı veya unutulmuş yönetim paneli saldırı yüzeyini büyütür. IT ortamında aktif keşif kullanılabilirken OT ortamında pasif yöntemler daha güvenli olabilir. Bulunan varlıklar sahibine ve işlevine göre doğrulanmalıdır. Denetimin değerli çıktılarından biri kurumun “bilmediğini bilmediği” sistemleri görünür hale getirmektir.

Kayıtsız Bilgisayarlar

Ağda bulunan ancak envanterde görünmeyen bilgisayarlar kontrol dışı olabilir. EDR veya patch uygulanmamış olabilir. Cihaz sahibi belirlenmelidir. İş için gerekli değilse ağdan kaldırılabilir. Envanter süreci bu cihazın nasıl kayıt dışı kaldığını da araştırmalıdır.

Yetkisiz Access Point'ler

Kullanıcıların kendi access point cihazını bağlaması ağ segmentasyonunu zayıflatabilir. Kablosuz ağ taraması bu cihazları ortaya çıkarabilir. Yönetim arayüzü ve parola güvenliği bilinmeyebilir. Yetkisiz cihaz kaldırılmalıdır. Kablosuz politika ve teknik kontrol birlikte iyileştirilmelidir.

Kişisel Bulut Servisleri

Çalışanlar kurumsal dosyaları kişisel cloud hesaplarına taşıyabilir. Bu durum veri sınıflandırması ve DLP kontrollerini aşabilir. SaaS keşfi ve kullanıcı görüşmeleri yardımcı olabilir. Onaylı alternatif servis sunmak davranışı azaltabilir. Politika ile gerçek kullanım birlikte değerlendirilmelidir.

Eski Sunucular

Projeden kalan sunucular kapatılmadan yıllarca çalışabilir. Bu sistemler güncelleme ve izleme kapsamının dışında kalabilir. Network taraması ve sanallaştırma envanteri karşılaştırılmalıdır. Veri sahibi belirlenmelidir. İş ihtiyacı yoksa kontrollü biçimde devreden çıkarılmalıdır.

Unutulmuş Yönetim Arayüzleri

Eski firewall, UPS veya uygulama paneli internete açık kalabilir. Varsayılan parola veya eski TLS yapılandırması risk oluşturabilir. Internet exposure analizi bu arayüzleri tespit edebilir. Sistem sahibi doğrulanmalıdır. Yönetim erişimi VPN veya özel network üzerinden sınırlandırılabilir.

Kayıtsız IoT Cihazları

Kamera, sensör ve akıllı cihazlar hızlıca ağa eklenebilir. Cihazın cloud bağlantısı kurum tarafından bilinmeyebilir. Varsayılan parola ve güncel olmayan firmware görülebilir. IoT ayrı network segmentinde tutulmalıdır. Satın alma sürecine güvenlik ve envanter kaydı eklenmelidir.

OT Ortamında Pasif Varlık Keşfinin Önemi

OT cihazları aktif taramaya hassas olabilir. Pasif keşif ağ trafiğini dinleyerek cihaz ve protokol bilgisi çıkarabilir. Böylece üretimi etkilemeden görünürlük kazanılır. Sonuç saha ekipleriyle doğrulanmalıdır. Pasif keşif özellikle eski ve dokümantasyonu eksik tesislerde güçlü yöntemdir.

Ağ Mimarisi Denetimi

Ağ mimarisi denetimi saldırganın veya hatalı bir sistemin ne kadar geniş alana erişebileceğini anlamayı sağlar. Topoloji, VLAN, firewall, DMZ, internet exposure ve wireless yapı birlikte incelenmelidir. Segmentasyon yalnızca VLAN oluşturmak anlamına gelmez, güvenlik kuralları ve gerçek trafik de doğrulanmalıdır. IT ve OT ağları arasında kontrollü geçiş noktaları bulunmalıdır. Gereksiz servis ve portlar azaltıldığında saldırı yüzeyi önemli ölçüde küçülebilir.

Mevcut Network Topolojisinin Çıkarılması

Network diyagramı gerçek ortamla uyumlu olmalıdır. Switch ve firewall bağlantıları doğrulanmalıdır. Kritik sunucu ve OT segmentleri diyagram üzerinde gösterilebilir. İnternet, vendor ve cloud bağlantıları ayrıca işaretlenmelidir. Eski diyagramlar saha gözlemiyle güncellenmelidir.

VLAN Yapılarının İncelenmesi

VLAN'lar farklı güven seviyelerini ayırmak için kullanılabilir. Ancak VLAN tek başına güvenlik kontrolü değildir. Segmentler arası routing ve firewall kuralları incelenmelidir. Kullanıcı, sunucu ve OT ağlarının mantıksal ayrımı doğrulanmalıdır. Yönetim VLAN'ı özel erişim kısıtı taşımalıdır.

Firewall Kurallarının Denetlenmesi

Firewall rule base zaman içinde gereksiz ve geniş kurallarla dolabilir. Any-to-any kurallar özellikle incelenmelidir. Kural sahibi ve iş gerekçesi bulunmalıdır. Kullanılmayan kurallar log verisiyle belirlenebilir. Değişiklik ve periyodik review süreci tanımlanmalıdır.

Network Segmentation

Segmentasyon saldırının yatay hareketini sınırlar. Kullanıcı ağı ile kritik sunucu ağı ayrılabilir. OT için daha katı zone yapısı gerekebilir. Segmentasyon iş akışını engellemeden minimum gerekli erişimi sağlamalıdır. Gerçek network akışıyla düzenli doğrulanmalıdır.

IT ve OT Networklerinin Ayrıştırılması

IT kullanıcı ağı ile OT kontrol ağı arasında doğrudan geniş erişim bulunmamalıdır. Veri aktarımı belirlenen arayüz ve DMZ üzerinden yapılabilir. Yönetim erişimi jump server kullanabilir. Firewall kuralı protokol ve kaynak bazında sınırlandırılmalıdır. Bu ayrım ransomware yayılım riskini azaltır.

DMZ Kullanımı

DMZ farklı güven alanları arasında ara katman sağlar. Historian replikası veya remote access gateway burada konumlandırılabilir. IT'den OT'ye doğrudan servis açmak yerine aracı sistem kullanılabilir. DMZ kendi log ve güvenlik politikasına sahip olmalıdır. Gereksiz çift yönlü erişimler kaldırılmalıdır.

Internet Exposure Analizi

Kurumun dışarıdan görünen IP ve servisleri belirlenmelidir. Unutulmuş VPN, kamera veya yönetim paneli tespit edilebilir. Her servis iş gerekçesiyle doğrulanmalıdır. Kritik yönetim arayüzleri mümkünse doğrudan internete açık olmamalıdır. Exposure sonuçları varlık envanteriyle karşılaştırılmalıdır.

Wireless Network Güvenliği

Kablosuz ağlar kurum içi ve misafir kullanımına göre ayrılmalıdır. Güçlü kimlik doğrulama tercih edilmelidir. Eski şifreleme protokolleri kaldırılmalıdır. Access point yönetim erişimi sınırlandırılmalıdır. Saha taraması rogue access point tespitine yardımcı olabilir.

Network Yönetim Protokolleri

SSH, SNMP ve diğer yönetim protokollerinin güvenli sürümleri kullanılmalıdır. Telnet gibi şifresiz yöntemler kaldırılmalıdır. SNMP community bilgileri varsayılan olmamalıdır. Yönetim erişimi belirli admin networklerinden yapılmalıdır. Network cihaz logları merkezi sisteme gönderilmelidir.

Gereksiz Servis ve Portların Belirlenmesi

Açık servislerin gerçekten iş ihtiyacı taşıyıp taşımadığı doğrulanmalıdır. Gereksiz RDP, SMB veya yönetim portları risk yaratabilir. OT cihazlarında kullanılmayan protokoller üretici imkânlarına göre sınırlandırılabilir. Port kapatma operasyon etkisi test edilmeden yapılmamalıdır. Denetim önerisi kontrollü değişiklik planıyla birlikte ele alınmalıdır.

IT–OT Network Segmentasyonu Nasıl Denetlenir?

IT–OT segmentasyon denetimi yalnızca diyagram kontrolü değildir. Gerçek firewall akışları, erişim yolları, vendor bağlantıları ve internet çıkışları birlikte test edilmelidir. Zone ve conduit yaklaşımı hangi varlığın hangi güven bölgesinde olduğunu netleştirir. Jump server ve izleme kontrolleri yönetim erişimini daha kontrol edilebilir hale getirir. Kritik PLC'lerin doğrudan internetten erişilebilir olmaması temel beklentilerden biridir.

Kurumsal IT'den OT'ye Doğrudan Erişim Var mı?

Kullanıcı bilgisayarından OT ağına doğrudan bağlantı riski artırır. Erişim yalnızca gerekli yönetim noktalarına sınırlandırılmalıdır. Firewall rule export üzerinden akışlar incelenebilir. Test bağlantıları kontrollü biçimde doğrulanabilir. Gereksiz yol bulunduğunda önce iş sahibiyle etkisi değerlendirilmelidir.

OT DMZ Mevcut mu?

OT DMZ IT ve kontrol ağı arasında tampon katman sağlar. Historian veri paylaşımı veya remote access burada sonlandırılabilir. DMZ yoksa doğrudan bağlantıların sayısı artabilir. Mevcutsa güvenlik kuralları ve loglama ayrıca değerlendirilmelidir. DMZ sadece isim olarak değil gerçek trafik politikasında bulunmalıdır.

Zone ve Conduit Yaklaşımı

Benzer güvenlik gereksinimine sahip varlıklar zone altında gruplanabilir. Zone'lar arasındaki kontrollü iletişim conduit olarak tanımlanır. Bu yaklaşım erişim ihtiyacını açık biçimde belgeler. Firewall politikası zone modeline göre tasarlanabilir. Denetim gerçek network ile doküman arasındaki farkı inceler.

Firewall Kuralları Minimum Yetki İlkesine Uygun mu?

Kaynak, hedef, port ve protokol mümkün olduğunca sınırlandırılmalıdır. Geniş network blokları gereksiz erişim oluşturabilir. Yönetim protokolleri yalnızca belirli jump host üzerinden geçebilir. Kullanılmayan kurallar kaldırılmalıdır. Kural review periyodu kurumsal süreç haline getirilmelidir.

OT'den İnternete Gereksiz Çıkış Var mı?

OT cihazlarının çoğu sürekli internet erişimine ihtiyaç duymaz. Güncelleme veya vendor servisi için kontrollü çıkış gerekebilir. Genel internet erişimi zararlı yazılım ve command-and-control riskini artırır. Trafik proxy veya güvenli gateway üzerinden sınırlandırılabilir. Gerçek bağlantılar log analiziyle doğrulanmalıdır.

Kritik PLC'ler İnternetten Görünüyor mu?

PLC'nin doğrudan public IP üzerinden erişilebilir olması ciddi risk oluşturur. Exposure analizi ve firewall kontrolü yapılmalıdır. Uzaktan bakım gerekiyorsa VPN ve jump host gibi katmanlar kullanılmalıdır. Cihaz kimlik doğrulaması üretici desteği dahilinde güçlendirilmelidir. İnternete açık kritik OT cihazı öncelikli bulgu olarak ele alınmalıdır.

Jump Server Kullanımı

Jump server yönetim erişimini tek kontrollü noktada toplar. MFA ve oturum kaydı burada uygulanabilir. Yönetici bilgisayarlarının doğrudan OT'ye bağlanması engellenebilir. Jump host düzenli patch ve EDR kapsamına alınmalıdır. Kullanıcı yetkileri işlem ihtiyacına göre sınırlandırılmalıdır.

Network Akışlarının İzlenmesi

Segmentasyon yalnızca kural oluşturmakla tamamlanmaz. Gerçek trafik düzenli izlenmelidir. Beklenmeyen IT–OT bağlantıları alarm üretebilir. Pasif OT monitoring araçları protokol davranışını görünür hale getirebilir. Baseline oluşturulduğunda anormal akışlar daha kolay fark edilir.

Kimlik ve Erişim Yönetimi Denetimi

Kimlik yönetimi birçok güvenlik olayında merkezi rol oynar. Eski kullanıcı, shared account, gereksiz administrator ve korunmayan service account saldırgan için güçlü fırsat oluşturabilir. Denetim Active Directory, kullanıcı yaşam döngüsü, role-based access ve MFA kapsamını birlikte değerlendirmelidir. Ayrıcalıklı hesaplar normal kullanıcı hesaplarından daha sıkı kontrol edilmelidir. Kurumlar için IT denetimi kontrol listesi ve denetim kriterleri içinde kimlik yönetimi mutlaka ana başlıklardan biri olmalıdır.

Active Directory İncelemesi

Domain yapısı, ayrıcalıklı gruplar ve güven ilişkileri incelenmelidir. Gereksiz Domain Admin üyeleri kaldırılmalıdır. Eski işletim sistemli domain controller'lar risk yaratabilir. Audit policy ve loglama ayarları kontrol edilmelidir. AD yedeği ve recovery prosedürü kritik süreklilik kontrolüdür.

Kullanıcı Hesapları

Her hesabın gerçek bir sahibi olmalıdır. Kullanıcı rolü ile yetkiler uyumlu olmalıdır. Uzun süre kullanılmayan hesaplar incelenmelidir. Parola ve MFA politikası risk seviyesine göre uygulanmalıdır. Kullanıcı listesi insan kaynakları kayıtlarıyla düzenli karşılaştırılabilir.

Eski Çalışan Hesapları

İşten ayrılan kişinin hesabının açık kalması ciddi risk oluşturur. Offboarding süreci belirli süre içinde hesabı kapatmalıdır. VPN, cloud ve uygulama hesapları merkezi olarak kontrol edilmelidir. Yalnızca Active Directory hesabını kapatmak yeterli olmayabilir. Denetim örnek kullanıcılarla sürecin gerçekten çalıştığını test etmelidir.

Ortak Kullanıcı Hesapları

Shared account kullanımı yapılan işlemin kime ait olduğunu belirsiz hale getirir. Operasyon ihtiyacı varsa risk ve gerekçe belgelenmelidir. Mümkün olduğunda kişisel hesap kullanılmalıdır. Ortak hesap parolası değişiklik yönetimiyle korunmalıdır. Kritik sistemlerde oturum kaydı ek kontrol sağlayabilir.

Yetkili Hesaplar

Administrator hesapları günlük e-posta ve internet kullanımı için kullanılmamalıdır. Ayrıcalıklı işlem ayrı hesapla yapılabilir. MFA ve güçlü loglama uygulanmalıdır. Yetki listeleri düzenli review edilmelidir. Gereğinden fazla admin hakkı kaldırılmalıdır.

Privileged Access Management

PAM çözümü kritik hesapların parola ve oturum yönetimini merkezileştirebilir. Parolalar kasada saklanabilir. Oturum açma işlemleri kayıt altına alınabilir. Yetki belirli süre için verilebilir. Ancak PAM satın almak yeterli değildir, kritik hesap coverage oranı düzenli ölçülmelidir.

Role-Based Access Control

Yetkiler kişiye özel rastgele verilmek yerine iş rolüne bağlanmalıdır. Bu yaklaşım onboarding ve role change süreçlerini kolaylaştırır. Rol tanımları periyodik olarak gözden geçirilmelidir. Uygulama yetkileri merkezi kimlik sistemiyle mümkünse entegre edilmelidir. Rol dışı istisnalar ayrıca belgelenmelidir.

Least Privilege

Kullanıcı yalnızca işi için gerekli yetkiye sahip olmalıdır. Yüksek yetki varsayılan olmamalıdır. Denetim kullanıcı ve grup üyeliklerini örnekleyebilir. Yetki kaldırmanın operasyon etkisi ilgili birimle doğrulanmalıdır. Minimum yetki yaklaşımı saldırı sonrası lateral movement etkisini azaltır.

Multi-Factor Authentication

MFA parola ele geçirilse bile ek koruma sağlar. Özellikle VPN, cloud ve admin erişimlerinde yüksek önceliklidir. Coverage oranı ölçülmelidir. Kritik istisnalar risk kabul sürecine bağlanmalıdır. Legacy sistemlerde MFA uygulanamıyorsa alternatif kontrol düşünülmelidir.

Service Account'lar

Service account'lar uygulamalar tarafından kullanılır ve yıllarca değişmeyen parolalara sahip olabilir. Hesabın sahibi ve kullanım amacı bilinmelidir. Interactive login mümkünse engellenmelidir. Parola veya secret yönetimi otomatikleştirilebilir. Gereksiz domain yetkileri kaldırılmalıdır.

Hesap Açma ve Kapatma Süreci

Joiner, mover ve leaver süreçleri yazılı ve ölçülebilir olmalıdır. Yeni kullanıcı yetkileri yönetici onayıyla açılmalıdır. Rol değişiminde eski yetkiler temizlenmelidir. Ayrılışta bütün erişimler belirli süre içinde kapatılmalıdır. Denetim kayıt ve örnek kullanıcı üzerinden süreci doğrulamalıdır.

OT Sistemlerinde Erişim Kontrolü

OT ortamında erişim kontrolü üretim sürekliliği nedeniyle farklı zorluklar taşır. Eski sistemler merkezi kimlik yönetimini desteklemeyebilir ve ortak operatör hesapları kullanılabilir. Buna rağmen kritik programlama ve yönetim yetkileri kişiye ve iş ihtiyacına göre sınırlandırılmalıdır. Vendor ve geçici bakım erişimleri süre sınırlı olmalıdır. Fiziksel erişim ile mantıksal erişim birlikte değerlendirilmeden OT güvenlik resmi tamamlanmaz.

PLC Programlama Yetkileri

PLC programı değiştirebilen kullanıcı sayısı minimum tutulmalıdır. Programlama bilgisayarı özel yetkili cihaz olabilir. Değişiklik öncesi program yedeği alınmalıdır. Yapılan değişiklik kayıt altına alınmalıdır. Yetkisiz program değişimi safety ve operasyon riski yaratabilir.

Engineering Workstation Yetkileri

Engineering workstation yüksek riskli yönetim aracıdır. Normal ofis kullanımıyla karıştırılmamalıdır. Kullanıcılar kişisel hesapla oturum açmalıdır. Yönetici yetkisi yalnızca gerektiğinde kullanılmalıdır. Cihazın fiziksel ve network erişimi birlikte sınırlandırılmalıdır.

SCADA Yönetici Hesapları

SCADA admin hesabı günlük operatör işlemleri için kullanılmamalıdır. Yönetici değişiklikleri loglanmalıdır. Mümkünse kişisel administrator hesapları oluşturulmalıdır. Varsayılan vendor hesapları kapatılmalı veya güvenli hale getirilmelidir. Parola yönetimi kritik sistem prosedürüne bağlanmalıdır.

Ortak Operatör Hesaplarının Riski

Ortak hesap olay sonrası kimin hangi işlemi yaptığını göstermeyi zorlaştırır. Sistem teknik olarak kişisel hesap destekliyorsa geçiş planlanmalıdır. Desteklemiyorsa fiziksel vardiya kayıtları ek kanıt sağlayabilir. Shared hesabın yetkisi minimum tutulmalıdır. Parola değişiklik periyodu operasyon koşuluna göre belirlenmelidir.

Vendor Hesapları

Üretici ve bakım firmalarının hesapları ayrı envanterde tutulmalıdır. Sürekli açık hesap yerine talep üzerine erişim tercih edilebilir. MFA ve VPN kullanılmalıdır. Vendor ayrıldığında erişim kapatılmalıdır. Bağlantı logları denetim kanıtı olarak saklanmalıdır.

Geçici Bakım Yetkileri

Bakım çalışması için verilen yüksek yetki süresiz kalmamalıdır. Yetki belirli zaman penceresinde aktif edilebilir. İş tamamlandığında otomatik veya manuel olarak kaldırılmalıdır. Yapılan işlem kayıt altına alınmalıdır. Acil durum erişimi ayrı süreçle yönetilebilir.

Fiziksel ve Mantıksal Erişimin Birlikte Değerlendirilmesi

PLC kabinine fiziksel erişimi olan kişi mantıksal kontrolleri aşabilir. Kontrol odası ve network odası erişimleri bu nedenle önemlidir. Kartlı geçiş kayıtları teknik hesap loglarıyla gerektiğinde karşılaştırılabilir. Bakım ziyaretçileri refakatli çalışabilir. OT denetimi fiziksel güvenliği ağ güvenliğinden ayrı düşünmemelidir.

Vendor ve Uzaktan Bakım Erişimlerinin Denetimi

Uzaktan bakım kurumların en kritik üçüncü taraf risklerinden biridir. Bakım firmaları güçlü yetkilerle doğrudan SCADA, sunucu veya network cihazlarına bağlanabilir. Denetimde hangi firmanın hangi sisteme erişebildiği, erişimin nasıl açıldığı ve ne kadar süre aktif kaldığı incelenmelidir. VPN, MFA, jump host ve session recording gibi katmanlar güvenli modeli destekler. Doğrudan PLC erişimi mümkün olduğunca sınırlandırılmalıdır.

Hangi Firmalar Sisteme Uzaktan Bağlanabiliyor?

Tedarikçi listesi gerçek network erişimleriyle karşılaştırılmalıdır. Sözleşmesi bitmiş firma hâlâ VPN hesabına sahip olabilir. Bağlanılan sistem ve amaç kayıt altına alınmalıdır. Kritik firmalar risk sınıfına göre değerlendirilebilir. Vendor erişim envanteri düzenli güncellenmelidir.

Vendor Hesap Envanteri

Her vendor hesabının sahibi ve ilişkili firması bulunmalıdır. Shared vendor hesaplarından kaçınılmalıdır. Son giriş tarihi eski hesapları gösterebilir. Yetki kapsamı açıkça belirtilmelidir. Sözleşme sona erdiğinde hesap otomatik kontrol listesine girmelidir.

VPN ve Güvenli Gateway Kullanımı

Uzaktan bakım doğrudan port forwarding ile yapılmamalıdır. VPN veya güvenli erişim gateway'i kullanılabilir. Erişim belirli kaynak ve hedef sistemlerle sınırlandırılır. Güçlü kriptografi ve güncel ürün sürümü önemlidir. VPN logları SIEM'e aktarılabilir.

MFA

Vendor hesabında MFA yüksek öncelikli kontroldür. Parola başka kurumda veya kullanıcıda ele geçirilebilir. İkinci faktör saldırı ihtimalini azaltır. Ortak hesap MFA yönetimini zorlaştırabilir. Bu nedenle kişisel vendor hesapları tercih edilmelidir.

Jump Host

Jump host uzaktan erişimin doğrudan kritik sisteme ulaşmasını engeller. Oturum kontrol ve kayıt noktası sağlar. Vendor yalnızca tanımlanan sistemlere erişebilir. Jump host EDR ve patch kapsamına alınmalıdır. Yönetim erişimi burada merkezileştirilebilir.

Oturum Kaydı

Kritik bakım oturumlarının kaydı olay sonrası inceleme sağlar. Komut veya ekran oturumu kaydedilebilir. Gizlilik ve saklama süresi politikası belirlenmelidir. Kayıtlar yetkisiz değişikliğe karşı korunmalıdır. Yüksek riskli OT bakımında önemli denetim kanıtı oluşturur.

Süre Sınırlı Yetkilendirme

Vendor hesabı sürekli açık olmak zorunda değildir. Bakım talebiyle belirli saatlerde aktif hale getirilebilir. Süre sona erdiğinde erişim otomatik kapanabilir. Acil durum prosedürü ayrıca tanımlanabilir. Bu yöntem kalıcı attack surface'i azaltır.

Bağlantı Sonrası Yetkinin Otomatik Kaldırılması

Bakım tamamlandıktan sonra geçici yetki sistem tarafından kaldırılabilir. Manuel unutma riski azalır. Ticket veya change kaydıyla entegrasyon yapılabilir. Başarısız kapanışlar alarm üretebilir. Denetim bu otomasyonun gerçekten çalıştığını örnek kayıtlarla doğrulamalıdır.

Doğrudan PLC Erişiminin Engellenmesi

Vendor'ın internetten veya VPN'den PLC'ye doğrudan bağlanması yüksek risklidir. Engineering workstation veya jump host üzerinden kontrollü erişim tercih edilmelidir. Firewall kuralı belirli protokolle sınırlandırılabilir. Program değişikliği öncesi yedek alınmalıdır. Erişim yalnızca onaylı bakım penceresinde açılmalıdır.

Vendor Erişim Loglarının Saklanması

Kim, ne zaman ve hangi sisteme bağlandı bilgisi saklanmalıdır. Başarılı ve başarısız girişler izlenebilir. Log retention olay inceleme ihtiyacına göre belirlenir. Kritik vendor oturumları SIEM use case'i oluşturabilir. Log bütünlüğü ayrıca korunmalıdır.

Sunucu ve Sistem Güvenliği Denetimi

Sunucu güvenliği patch seviyesinden çok daha geniş bir kontrol alanıdır. Hardening, gereksiz servisler, local administrator yetkileri, EDR, zaman senkronizasyonu ve güvenli baseline birlikte değerlendirilmelidir. EOL sistemler ayrı risk grubuna alınmalıdır. İyi denetim yalnızca “güncel mi?” sorusunu değil “işlevi için gerçekten gerekli servisler hangileri?” sorusunu da sorar. Sistem yapılandırması belirli kurumsal baseline ile karşılaştırılmalıdır.

İşletim Sistemi Güncelliği

Sunucuların desteklenen işletim sistemi kullanması önemlidir. Kritik patch eksikleri risk bazlı değerlendirilmelidir. Patch'in ne zaman uygulanabileceği bakım takvimine bağlı olabilir. Sistem sahibi ile güvenlik ekibi ortak karar vermelidir. Güncelleme sonrası işlev testi yapılmalıdır.

End-of-Life Sistemler

EOL sistemler yeni güvenlik güncellemeleri alamayabilir. Kritik hizmet bağımlılığı risk seviyesini artırır. Hemen değiştirme mümkün değilse segmentasyon ve erişim kontrolü uygulanabilir. Yenileme hedef tarihi yönetim tarafından belirlenmelidir. EOL envanteri IT yatırım planının parçası olmalıdır.

Hardening

Hardening gereksiz özellik ve zayıf varsayılan ayarları azaltır. Güvenli yapılandırma baseline'ı kullanılabilir. Değişikliklerin uygulama uyumluluğu test edilmelidir. Admin protokolleri sınırlandırılmalıdır. Hardening tek seferlik kurulum değil düzenli kontrol sürecidir.

Gereksiz Servisler

Çalışmayan işlevler için açık servis bırakmak saldırı yüzeyini büyütür. Sunucu rolüne göre gerekli servis listesi hazırlanabilir. Port taraması ve yapılandırma incelemesi birlikte kullanılabilir. Kapatma öncesi uygulama sahibiyle doğrulama yapılmalıdır. Sonuç baseline'a eklenmelidir.

Administrative Share'ler

Administrative share yönetim için gerekli olabilir ancak saldırgan tarafından lateral movement amacıyla kullanılabilir. Erişim yalnızca admin hesaplarına açık olmalıdır. Network segmentasyonu destekleyici kontrol sağlar. Kullanım loglanabilir. Gereksiz sistemlerde devre dışı bırakma değerlendirilebilir.

EDR / Antimalware

EDR coverage oranı tüm kritik sunucular için ölçülmelidir. Agent kurulmuş olsa bile aktif ve güncel olması gerekir. Alarm üretimi ve SOC süreci birlikte incelenmelidir. OT sistemlerinde uyumluluk üreticiyle doğrulanmalıdır. EDR bulunmayan kritik varlıklar risk listesine eklenmelidir.

Local Administrator Yetkileri

Gereksiz local admin yetkisi saldırı etkisini büyütür. Kullanıcı bilgisayarlarında ayrı yönetim hesabı tercih edilebilir. Parola yönetimi merkezi hale getirilebilir. Sunucularda admin grubu periyodik review edilmelidir. Geçici yetki mekanizması kalıcı üyeliği azaltır.

Sistem Saat Senkronizasyonu

Logların doğru korelasyonu için sistem saatleri uyumlu olmalıdır. NTP kaynağı güvenilir ve kontrollü olmalıdır. OT cihazlarında destek kısıtları değerlendirilebilir. Saat farkı olay zaman çizelgesini bozabilir. Denetim log örnekleri üzerinden senkronizasyonu doğrulayabilir.

Güvenli Konfigürasyon Baseline'ları

Baseline kurumun kabul ettiği minimum güvenlik ayarlarını tanımlar. Sistem tipi ve rolüne göre farklı baseline hazırlanabilir. Yapılandırma assessment aracıyla sapmalar bulunabilir. İstisnalar gerekçeli olarak kaydedilmelidir. Baseline değişen tehdit ve teknolojiye göre güncellenmelidir.

Patch ve Vulnerability Management Denetimi

Patch ve vulnerability yönetimi yalnızca aylık güncelleme yapmak değildir. Kurum hangi açığın hangi varlıkta bulunduğunu, riskini ve kapatma süresini izleyebilmelidir. OT sistemlerinde üretici desteği ve operasyon etkisi nedeniyle patch stratejisi daha kontrollü olabilir. Uygulanamayan patch için compensating control oluşturulmalıdır. Risk tabanlı yaklaşım CVSS skorunu varlık kritiklik ve exposure bilgisiyle birlikte değerlendirir.

Patch Politikası

Politika farklı varlık türleri için süre hedefleri belirlemelidir. Kritik güvenlik güncellemeleri daha hızlı ele alınabilir. Test ve üretim aşamaları tanımlanmalıdır. OT patch penceresi ayrı olabilir. İstisna ve risk kabul süreci belgelenmelidir.

Kritik Güncellemelerin Uygulama Süresi

Kritik patch'in çıkışından uygulanmasına kadar geçen süre ölçülmelidir. Tek ortalama yerine SLA uyum oranı izlenebilir. Geciken sistemler nedenleriyle raporlanmalıdır. İnternete açık varlıklar daha yüksek öncelik alabilir. Yönetim dashboard'u patch compliance gösterebilir.

Vulnerability Scan Süreci

Tarama kapsamı ve periyodu açık olmalıdır. Kimlik doğrulamalı taramalar daha doğru sonuç verebilir. OT sistemlerinde aktif tarama üretici ve operasyon onayı gerektirebilir. Sonuçlar risk register'a bağlanmalıdır. False positive bulgular doğrulanmalıdır.

CVE Takibi

Kurum kullandığı ürünler için güvenlik duyurularını takip etmelidir. Üretici ve CISA benzeri kaynaklardan bilgi alınabilir. CVE'nin gerçekten kullanılan sürümü etkileyip etkilemediği doğrulanmalıdır. OT firmware bilgisi envanterde bulunmalıdır. Kritik açıklarda aksiyon sahibi belirlenmelidir.

Risk Bazlı Patch Önceliklendirmesi

Yalnızca CVSS skoruna göre sıralama eksik olabilir. Internet exposure, exploit availability ve varlık kritiklik derecesi eklenmelidir. Compensating control varsa residual risk düşebilir. Kritik hizmeti destekleyen sistem öncelikli olabilir. Risk modeli kurumun iş yapısına göre kalibre edilmelidir.

Patch Uygulanamayan OT Sistemleri

Bazı OT cihazları üretici onayı olmadan güncellenemeyebilir. Güncelleme üretim duruşu gerektirebilir. Bu durumda ağ izolasyonu ve sıkı erişim kontrolü uygulanabilir. Monitoring seviyesi artırılabilir. Yenileme planı risk kabul süreciyle birlikte hazırlanmalıdır.

Compensating Controls

Ana kontrol uygulanamadığında riski azaltan alternatif önlemler compensating control olarak kullanılır. Segmentasyon, allowlist ve jump host buna örnek olabilir. Kontrolün hangi riski ne kadar azalttığı açıklanmalıdır. Geçici çözüm kalıcı unutulmamalıdır. Düzenli review tarihi belirlenmelidir.

Firmware Güncellemeleri

Network ve OT cihazlarının firmware sürümleri takip edilmelidir. Üretici güvenlik bültenleri incelenebilir. Güncelleme öncesi konfigürasyon yedeği alınmalıdır. Test ve rollback planı hazırlanmalıdır. Başarılı işlem envantere işlenmelidir.

EOL Cihazların Yönetimi

Destek dışı cihazlar listelenmelidir. Kritiklik ve exposure bilgisi yenileme önceliğini belirler. Bütçe planına açık hedef tarih eklenmelidir. Yenileme mümkün değilse compensating control güçlendirilir. Yönetim kalan risk hakkında bilgilendirilmelidir.

Yazılım ve Uygulama Güvenliği Denetimi

Kurumsal uygulamalar kimlik, veri ve iş süreçlerinin kesiştiği kritik alanlardır. Web, ERP, mobil uygulama, API ve veritabanı yetkileri birlikte değerlendirilmelidir. Güvenli yazılım geliştirme süreci yalnızca kod taraması değil secret yönetimi, değişiklik kontrolü ve loglamayı da kapsar. Üçüncü taraf uygulamalarda sözleşme ve destek süreci önemlidir. Uygulama güvenliği denetimi teknik zafiyet ile iş mantığı riskini birlikte ele almalıdır.

Kurumsal Web Uygulamaları

Kimlik doğrulama, oturum yönetimi ve yetkilendirme kontrolleri incelenmelidir. İnternete açık uygulamalar düzenli güvenlik testine tabi tutulabilir. Loglar kritik kullanıcı işlemlerini göstermelidir. Güncel framework ve dependency kullanımı önemlidir. Uygulama owner ve destek modeli açık olmalıdır.

ERP Sistemleri

ERP geniş iş yetkileri taşıdığı için rol ayrımı önemlidir. Aynı kullanıcı hem kayıt açıp hem onaylayabiliyorsa görevler ayrılığı riski oluşabilir. Admin ve entegrasyon hesapları ayrıca denetlenmelidir. Veritabanı erişimleri sınırlandırılmalıdır. Vendor remote access kontrol altında tutulmalıdır.

Belediye Bilgi Sistemleri

Vatandaş verisi ve ödeme süreçleri bu sistemlerde bulunabilir. Kullanıcı yetkileri birim rolüne göre ayrılmalıdır. İnternet erişimli modüller ayrı güvenlik testi almalıdır. Veri transferleri loglanmalıdır. Sistem sağlayıcısının destek erişimi kayıt altına alınmalıdır.

Mobil Uygulamalar

Mobil uygulamanın API güvenliği temel risk alanıdır. Token saklama ve sertifika doğrulama kontrolleri değerlendirilmelidir. Hassas veri cihazda gereksiz tutulmamalıdır. Uygulama güncelleme süreci güvenli olmalıdır. Backend ile mobil güvenlik birlikte test edilmelidir.

API Güvenliği

API yalnızca authentication değil authorization açısından da test edilmelidir. Kullanıcı başka kullanıcının verisine erişememelidir. Rate limit ve input validation uygulanabilir. API secret'ları kaynak kod içinde tutulmamalıdır. Loglama kritik işlemleri izlemeyi sağlamalıdır.

Veritabanı Yetkileri

Uygulama hesapları yalnızca gerekli tablo ve işlemlere erişmelidir. DBA hesabı günlük uygulama işlemlerinde kullanılmamalıdır. Audit log kritik değişiklikleri kaydedebilir. Backup ve şifreleme kontrolleri veri kritikliğine göre uygulanır. Kullanılmayan hesaplar kapatılmalıdır.

Uygulama Logları

Başarılı ve başarısız oturum açma olayları kaydedilmelidir. Yetki değişiklikleri ve kritik işlem logları bulunmalıdır. Hassas veri log içine yazılmamalıdır. Log formatı SIEM entegrasyonuna uygun olabilir. Retention süresi olay inceleme ihtiyacına göre belirlenir.

Güvenli Yazılım Geliştirme Süreci

Güvenlik gereksinimleri geliştirme başında ele alınmalıdır. Code review ve dependency kontrolü sürece eklenebilir. CI/CD içinde otomatik güvenlik testleri kullanılabilir. Production değişiklikleri onay ve rollback planıyla yapılmalıdır. Release yönetimi ve müşteri iletişimi konusunda ek yaklaşım için https://www.diyarbakiryazilim.com.tr/posts/bolgesel-teknoloji-ekosistemlerinde-uretim-merkezleri-hub-kurmak adresindeki ilgili içerik de incelenebilir.

Kaynak Kod ve Secret Yönetimi

Kaynak kod erişimi rol bazlı olmalıdır. Repository MFA ile korunabilir. API key, parola ve sertifikalar kod içine gömülmemelidir. Secret manager kullanılabilir. Eski secret'ların rotation süreci tanımlanmalıdır.

Veri Güvenliği Denetimi

Veri güvenliği denetimi kurumun hangi veriyi neden tuttuğunu anlamakla başlar. Sınıflandırılmamış veri için doğru kontrol seviyesini belirlemek zordur. Kişisel bilgiler, operasyon verileri ve kritik yapılandırmalar farklı güvenlik gereksinimi taşıyabilir. Şifreleme, erişim, saklama ve silme politikaları veri sınıfına göre uygulanmalıdır. DLP gibi kontroller yalnızca teknoloji değil veri yönetişimiyle birlikte çalışmalıdır.

Kurum Hangi Verileri Tutuyor?

Veri envanteri sistem, veri sahibi ve kullanım amacı bilgisi içermelidir. Aynı veri farklı uygulamalarda kopyalanabilir. Bulut servislerinde tutulan veriler ayrıca kaydedilmelidir. Gereksiz veri saklama riski artırabilir. Veri sahibi retention ve erişim kararına katılmalıdır.

Veri Sınıflandırması

Sınıflandırma hangi veri için hangi güvenlik kontrolünün uygulanacağını belirler. Basit ve anlaşılır kategori seti tercih edilmelidir. Kullanıcıların etiketi doğru uygulayabilmesi gerekir. Otomatik sınıflandırma bazı sistemlerde destek olabilir. Sınıf değişiklikleri iş gereksinimine göre güncellenmelidir.

Genel

Genel veri kurum dışı paylaşımda düşük risk taşır. Yine de bütünlük ve doğruluk önemli olabilir. Web sitesi içeriği bu sınıfa girebilir. Yayın yetkisi kontrol edilmelidir. Genel veri de resmi kayıt ise değişiklik logu gerekebilir.

Kurum İçi

Kurum içi veri dışarıya açık değildir ancak yüksek hassasiyet taşımayabilir. İç prosedür ve çalışma dokümanları örnek olabilir. Erişim çalışan hesaplarıyla sınırlandırılabilir. Dış paylaşım kontrollü yapılmalıdır. Saklama süresi veri sahibince belirlenebilir.

Gizli

Gizli veri yetkisiz açıklamada ciddi iş etkisi yaratabilir. Sözleşme, kişisel veri veya finansal bilgiler bu gruba girebilir. Şifreleme ve detaylı erişim kontrolü uygulanmalıdır. Dış paylaşım onaya bağlanabilir. Loglama erişim denetimini destekler.

Kritik

Kritik veri fiziksel operasyon veya güvenlik üzerinde doğrudan etki yaratabilir. PLC konfigürasyonu ve ayrıcalıklı hesap secret'ları örnek olabilir. Erişim çok sınırlı tutulmalıdır. Offline veya güvenli yedek gerekebilir. Değişiklik ve görüntüleme kayıtları yüksek önem taşır.

Kişisel Veriler

Kişisel verilerin işlendiği sistemler açıkça belirlenmelidir. Yetki iş ihtiyacına göre verilmelidir. Gereksiz kopyalar azaltılmalıdır. Transfer ve saklama süreçleri mevzuat ve politika açısından değerlendirilir. İhlal senaryosu olay müdahale planında bulunmalıdır.

Endüstriyel Operasyon Verileri

Üretim reçetesi, proses parametresi ve historian verisi ticari veya operasyonel hassasiyet taşıyabilir. Bütünlüğün bozulması yanlış karar oluşturabilir. Erişim ve değişiklik logları önemlidir. IT tarafına aktarılan kopyalar aynı koruma seviyesini korumalıdır. Bulut analitiği kullanılıyorsa veri akışı belgelenmelidir.

Veri Şifreleme

Şifreleme veri ele geçirildiğinde okunabilirliği azaltır. Ancak anahtar yönetimi zayıfsa koruma etkisi düşer. Kullanım alanına göre disk, veritabanı veya uygulama şifreleme seçilebilir. Anahtar erişimleri ayrıcalıklı hesaplardan ayrılabilir. Şifreleme performans ve recovery planıyla birlikte değerlendirilmelidir.

Data-at-Rest Güvenliği

Diskte ve depolama ortamında duran veriler korunmalıdır. Tam disk şifreleme mobil cihazlarda önemli kontroldür. Veritabanı veya backup dosyaları ayrıca korunabilir. Fiziksel disk kaybı senaryosu değerlendirilmelidir. Anahtar recovery prosedürü bulunmalıdır.

Data-in-Transit Güvenliği

Network üzerinden geçen hassas veri güvenli protokoller kullanmalıdır. TLS ve VPN yaygın seçeneklerdir. Eski şifreleme sürümleri kaldırılmalıdır. OT protokollerinde şifreleme desteği sınırlıysa segmentasyon ek kontrol sağlar. Sertifika yönetimi düzenli yapılmalıdır.

Veri Saklama ve Silme Politikası

Veri gereğinden uzun süre tutulmamalıdır. Yasal ve iş ihtiyacı retention süresini belirler. Süre sonunda güvenli silme veya anonimleştirme uygulanabilir. Backup kopyaları da politika kapsamına alınmalıdır. Silme işlemi gerektiğinde kanıtlanabilir olmalıdır.

DLP Kontrolleri

DLP hassas verinin e-posta, web veya cihaz üzerinden çıkışını izleyebilir. Kural seti veri sınıflandırmasına dayanmalıdır. Fazla alarm kullanıcıların sistemi devre dışı bırakmasına yol açabilir. Olayların kim tarafından inceleneceği belirlenmelidir. DLP insan ve süreç kontrollerinin yerine geçmez.

KVKK Perspektifinden IT Audit

KVKK perspektifindeki denetim kişisel veri işleme süreçlerinin teknik ve idari tedbirlerle desteklenip desteklenmediğini değerlendirir. IT Audit hukuki görüşün yerine geçmez ancak teknik uygulamanın gerçek durumunu kanıtlayabilir. Veri envanteri, erişim, loglama, üçüncü taraf ve olay müdahale süreçleri birlikte incelenmelidir. Bulgular kişisel veri riskleriyle eşleştirildiğinde yönetim önceliği daha net hale gelir. Kurumun hukuk, bilgi güvenliği ve operasyon birimleri ortak değerlendirme yapmalıdır.

Kişisel Veri İşleme Envanteri

Hangi kişisel verinin hangi sistemde işlendiği bilinmelidir. Veri sahibi ve işleme amacı kaydedilebilir. Aktarım yapılan üçüncü taraflar belirtilmelidir. Saklama süresi ve silme yöntemi envanterle ilişkilendirilebilir. Teknik sistem envanteri ile veri envanteri mümkünse eşleştirilmelidir.

Teknik Tedbirler

Erişim kontrolü, şifreleme, yedekleme ve loglama teknik tedbirler arasındadır. Tedbir veri riskine göre seçilmelidir. Sadece ürün satın almak yeterli değildir. Konfigürasyon ve kullanım kanıtı incelenmelidir. Teknik tedbirler periyodik olarak test edilmelidir.

İdari Tedbirler

Politika, eğitim ve yetkilendirme süreçleri idari kontrol sağlar. Çalışan sorumlulukları açık olmalıdır. Tedarikçi sözleşmeleri veri yükümlülüklerini içermelidir. İhlal bildirim süreci tanımlanmalıdır. Doküman ile gerçek uygulama arasında uyum aranmalıdır.

Yetki Kontrolleri

Kişisel veriye erişim rol bazlı olmalıdır. Yönetici hesaplarının erişimi ayrıca izlenmelidir. Eski çalışan hesapları kapatılmalıdır. Uygulama içi yetkiler düzenli review edilmelidir. Gereksiz toplu veri erişimleri sınırlandırılmalıdır.

Loglama

Kritik kişisel veri erişimleri gerektiğinde izlenebilir olmalıdır. Loglar kullanıcı ve zaman bilgisi içermelidir. Hassas verinin kendisi gereksiz biçimde loglanmamalıdır. Log bütünlüğü korunmalıdır. Retention süresi politika ve olay ihtiyacıyla uyumlu olmalıdır.

Veri Transferleri

Kurum dışına yapılan veri aktarımları listelenmelidir. Transfer yöntemi ve alıcı sistem güvenliği değerlendirilmelidir. E-posta ile kontrolsüz dosya gönderimi risk yaratabilir. Güvenli dosya paylaşım mekanizmaları tercih edilebilir. Uluslararası transferler için ilgili hukuki değerlendirme ayrıca yapılmalıdır.

Üçüncü Taraf Veri İşleyenler

Cloud ve yazılım sağlayıcıları kişisel veri işleyebilir. Sözleşme güvenlik ve ihlal bildirim maddeleri içermelidir. Teknik erişim düzeyi bilinmelidir. Alt yükleniciler gerekiyorsa değerlendirilmelidir. Hizmet sona erdiğinde veri silme ve erişim kaldırma süreci bulunmalıdır.

İhlal Müdahale Süreci

Olası veri ihlalinde kimlerin devreye gireceği önceden bilinmelidir. Teknik inceleme, hukuk ve iletişim koordinasyonu önemlidir. Delil korunmalıdır. Olay zaman çizelgesi oluşturulabilir. Tatbikat sürecin gerçek hayatta çalışıp çalışmadığını gösterir.

IT Audit Bulgularının KVKK Riskleriyle Eşleştirilmesi

Her teknik bulgu kişisel veri riski oluşturmayabilir. Etkilenen sistemin tuttuğu veri sınıfı belirlenmelidir. Örneğin MFA eksikliği kişisel veri içeren cloud hesabında daha yüksek etki taşıyabilir. Risk register bu bağlantıyı göstermelidir. Böylece teknik düzeltme yönetim ve hukuk açısından daha anlaşılır hale gelir.

Loglama, İzleme ve SIEM Denetimi

Log bulunmayan sistemde olayın nasıl gerçekleştiğini anlamak çok zor olabilir. Denetim hangi sistemlerden log toplandığını ve kritik olayların gerçekten görünür olup olmadığını değerlendirmelidir. Merkezi saklama, zaman senkronizasyonu ve log bütünlüğü temel gereksinimlerdir. SIEM yalnızca log deposu değil alarm ve use case platformu olarak değerlendirilmelidir. OT logları ve network anomalileri de mümkün olduğunda izleme kapsamına alınmalıdır.

Hangi Sistemlerden Log Toplanıyor?

Kritik varlık listesi log kaynaklarıyla karşılaştırılmalıdır. Firewall, Active Directory, VPN ve kritik uygulamalar önceliklidir. OT sistemlerinde desteklenen log türleri ayrıca incelenir. Kaynak coverage oranı dashboard'a eklenebilir. Log gelmeyen kritik sistemler risk olarak kaydedilir.

Kritik Sistemlerin Logları Eksiksiz mi?

Log göndermek tek başına yeterli değildir. Başarısız oturum, yetki değişikliği ve admin işlemleri gibi önemli olaylar gerçekten kaydedilmelidir. Audit policy örnek sistemlerde kontrol edilmelidir. Fazla log depolama maliyeti yaratabilir. İhtiyaç duyulan olay türleri risk bazlı seçilmelidir.

Loglar Merkezi Olarak Saklanıyor mu?

Yerel log saldırgan tarafından silinebilir. Merkezi log sunucusu veya SIEM bu riski azaltır. Network kesintisinde buffer mekanizması değerlendirilebilir. Kritik sistemlerin log aktarımı şifreli yapılabilir. Merkezi platforma erişim ayrıca sınırlandırılmalıdır.

Log Bütünlüğü

Logların sonradan değiştirilememesi veya değişikliğin tespit edilebilmesi gerekir. Yetki ayrımı uygulanabilir. Immutable storage seçenekleri değerlendirilebilir. Hash veya güvenli arşiv yöntemleri kullanılabilir. Log bütünlüğü olay incelemesinin güvenilirliğini artırır.

Zaman Senkronizasyonu

Farklı cihazların saatleri uyumsuzsa olay korelasyonu zorlaşır. Ortak NTP kaynakları kullanılabilir. OT cihazları için güvenli ve desteklenen yöntem seçilmelidir. Saat farkları düzenli izlenebilir. Denetim örnek log timestamp'lerini karşılaştırabilir.

Retention Süreleri

Her log türünün aynı süre saklanması gerekmez. Olay inceleme, politika ve düzenleme ihtiyacı belirleyicidir. Depolama maliyeti de değerlendirilmelidir. Kritik güvenlik logları daha uzun tutulabilir. Retention otomatik silme politikasıyla uygulanmalıdır.

Alarm Kuralları

SIEM'de çok fazla alarm gerçek olayların kaçırılmasına yol açabilir. Use case'ler kurum riskine göre önceliklendirilmelidir. Başarısız admin girişleri veya anormal VPN erişimi örnek olabilir. Alarm sahibi ve eskalasyon süreci bulunmalıdır. False positive oranı düzenli gözden geçirilmelidir.

SIEM Use Case'leri

Use case gerçek saldırı veya kötüye kullanım senaryosuna dayanmalıdır. Gerekli log kaynakları tanımlanmalıdır. Alarmın hangi eşiğe göre oluşacağı açıklanmalıdır. Test verisiyle düzenli doğrulama yapılabilir. Çalışmayan use case raporda görünür hale getirilmelidir.

OT Loglarının İzlenmesi

SCADA ve OT cihazları sınırlı log üretebilir. Buna rağmen operator login, config change ve network bağlantıları mümkün olduğunca izlenmelidir. Pasif network monitoring ek görünürlük sağlayabilir. Protokol anomalileri tespit edilebilir. OT alarmı operasyon ekibiyle birlikte değerlendirilmelidir.

Anomali Tespiti

Normal davranış baseline'ı oluşturulduğunda sıra dışı aktiviteler daha kolay fark edilir. Anomali her zaman saldırı değildir. Yeni bakım aktivitesi veya sistem değişikliği de alarm oluşturabilir. Teknik ekip bağlamı doğrulamalıdır. Öğrenilen olaylar alarm kalibrasyonunu iyileştirir.

Yedekleme Denetimi

Yedekleme kurumların en sık “var” kabul ettiği ancak pratikte eksik çalışan kontrollerinden biridir. Backup job başarı mesajı gerçek kurtarma garantisi değildir. Offline, immutable ve off-site kopyalar fidye yazılımı ve fiziksel afet riskini azaltabilir. Erişim yetkileri ve şifreleme ayrıca kontrol edilmelidir. Restore testi yapılmayan yedekler yönetim açısından doğrulanmamış kapasite olarak görülmelidir.

Hangi Sistemler Yedekleniyor?

Kritik sistem listesi backup scope ile karşılaştırılmalıdır. Yeni sunucu otomatik olarak backup politikasına eklenmeyebilir. SaaS verilerinin sağlayıcı tarafından yeterince yedeklendiği varsayılmamalıdır. OT konfigürasyonları ayrıca kapsama alınmalıdır. Coverage oranı düzenli raporlanabilir.

Backup Başarı Raporları

Başarılı ve başarısız job'lar düzenli izlenmelidir. Sürekli başarısız kalan job için ticket açılmalıdır. Capacity veya repository sorunu erken fark edilebilir. Rapor yalnızca teknik ekibin e-postasında kalmamalıdır. Kritik backup hataları eskalasyon sürecine bağlı olmalıdır.

Offline Backup

Offline kopya aktif network üzerinden doğrudan erişilemez. Ransomware saldırısında ek koruma sağlar. Kopyanın ne sıklıkla güncellendiği önemlidir. Fiziksel saklama güvenliği sağlanmalıdır. Restore prosedürü düzenli test edilmelidir.

Immutable Backup

Immutable backup belirli süre boyunca silinemeyen veya değiştirilemeyen kopya sağlar. Yetkili hesabın ele geçirilmesine karşı koruma sunabilir. Retention süresi iş ihtiyacına göre belirlenmelidir. Yönetim hesabı güvenliği yine önemlidir. Gerçek restore testi olmadan tek başına yeterli kabul edilmemelidir.

Off-Site Backup

Veri merkezi kaybı senaryosunda aynı lokasyondaki backup etkilenebilir. Farklı fiziksel veya cloud lokasyonu kullanılabilir. Veri transfer güvenliği değerlendirilmelidir. Recovery süresine etkisi test edilmelidir. Kritik sistemler için alternatif bağlantı ihtiyacı planlanabilir.

Yedeklerin Şifrelenmesi

Backup dosyaları üretim verisinin tam kopyasını içerebilir. Yetkisiz erişimde büyük veri ihlali oluşturabilir. Depolama ve transfer sırasında şifreleme değerlendirilebilir. Anahtar yönetimi ayrı tutulmalıdır. Anahtar kaybı recovery'yi imkânsız hale getirmemelidir.

Yedeklere Erişim Yetkileri

Backup admin yetkisi çok güçlüdür. Kullanıcı backup silme veya restore etme hakkına sahip olabilir. Yetki minimum kişiye verilmelidir. MFA uygulanabilir. İşlem logları merkezi olarak izlenmelidir.

Restore Testleri

Restore testi backup verisinin gerçekten kullanılabilir olduğunu gösterir. Dosya seviyesinde ve tam sistem seviyesinde farklı testler yapılabilir. Kritik uygulama için bağımlılıklar birlikte doğrulanmalıdır. Sonuç ve süre kaydedilmelidir. Hedef RTO ile karşılaştırılmalıdır.

Son Başarılı Geri Dönüş Testi Ne Zaman Yapıldı?

Bu soru yedekleme denetiminin en güçlü sorularından biridir. Kurum backup aldığını söyleyebilir ancak yıllardır restore denememiş olabilir. Son test tarihi ve sonucu kanıtla doğrulanmalıdır. Kritik sistemlerde planlı periyot belirlenmelidir. Başarısız test düzeltici faaliyet oluşturmalıdır.

OT Yedekleme Stratejisi

OT yedekleme yalnızca SCADA veritabanı almak değildir. PLC programları, HMI projeleri, engineering workstation imajları, firmware ve konfigürasyon dosyaları ayrıca korunmalıdır. Golden image kritik sistemin hızlı geri dönüşünü destekleyebilir. Change management ile backup süreci entegre edildiğinde değişiklik öncesi ve sonrası sürüm korunur. OT restore tatbikatı teorik yedeğin gerçek operasyon kapasitesine dönüşmesini sağlar.

PLC Programlarının Yedeklenmesi

Her kritik PLC'nin güncel programı güvenli repository'de tutulmalıdır. Programın hangi fiziksel cihaza ait olduğu açık olmalıdır. Değişiklik sonrası yeni sürüm kaydedilmelidir. Eski sürümler rollback için korunabilir. Dosyanın gerçekten açılabilir olduğu dönemsel kontrol edilmelidir.

SCADA Konfigürasyonları

SCADA ekran, tag ve iletişim yapılandırmaları kritik operasyon verisidir. Yalnızca sunucu imajına güvenilmemelidir. Uygulama seviyesinde proje backup'ı alınmalıdır. Lisans ve dependency bilgisi recovery dokümanına eklenmelidir. Restore senaryosu test ortamında doğrulanabilir.

HMI Projeleri

HMI proje dosyasının en güncel sürümü merkezi olarak saklanmalıdır. Sahadaki gerçek cihazla repository sürümü karşılaştırılabilir. Değişiklik yetkili kullanıcı tarafından yapılmalıdır. Versiyon bilgisi proje notunda bulunmalıdır. Yeni HMI cihazına yükleme prosedürü belgelenmelidir.

Engineering Workstation İmajları

Mühendislik bilgisayarında özel driver ve lisanslar bulunabilir. Sistem kaybı hızlıca yeniden kurulamayabilir. Golden image veya full disk backup kullanılabilir. İmaj düzenli güncellenmelidir. Recovery testi lisans ve cihaz bağlantılarını da doğrulamalıdır.

Firmware ve Konfigürasyon Dosyaları

Network ve OT cihaz konfigürasyonları düzenli yedeklenmelidir. Firmware dosyası üretici portalından her zaman erişilebilir olmayabilir. Kritik sürümler kontrollü repository'de tutulabilir. Hash ile bütünlük doğrulanabilir. Kullanım ve lisans koşulları dikkate alınmalıdır.

Golden Image

Golden image güvenli ve doğrulanmış sistem şablonudur. Yeni veya arızalı workstation hızlı kurulabilir. Patch ve güvenlik ayarları belirli baseline'a sahip olur. İmaj eski kaldığında yeni açıklar taşıyabilir. Güncelleme ve test periyodu belirlenmelidir.

Backup ile Change Management'ın Entegrasyonu

Kritik değişiklik öncesinde mevcut konfigürasyon yedeklenmelidir. Change ticket backup referansını içerebilir. Değişiklik başarısız olursa rollback dosyası hazır olur. Son durum başarılıysa yeni baseline saklanır. Bu entegrasyon bilinmeyen sürüm sorununu azaltır.

OT Restore Tatbikatları

OT restore tatbikatı gerçek üretimi etkilemeden uygun ortamda yapılmalıdır. PLC programı, HMI ve SCADA recovery adımları test edilebilir. Süre ölçülür. Eksik lisans veya dosya bağımlılığı ortaya çıkabilir. Sonuç prosedür ve yedekleme stratejisini iyileştirir.

İş Sürekliliği ve Felaket Kurtarma Denetimi

İş sürekliliği denetimi yalnızca DR dokümanının varlığına bakmaz. Kritik sistem, RTO, RPO, iletişim ve tatbikat sonuçları birlikte değerlendirilmelidir. Elektrik, internet, veri merkezi ve ransomware senaryoları farklı kurtarma gereksinimleri doğurur. Alternatif iletişim kanalları teknik sistemler çalışmadığında bile yönetim koordinasyonunu sürdürmelidir. DR planı gerçek tatbikatlarla düzenli doğrulanmalıdır.

Business Impact Analysis

BIA hangi hizmetin ne kadar kritik olduğunu belirler. Kesinti süresine göre etki artışı değerlendirilir. Sistem ve insan bağımlılıkları kaydedilir. RTO ve RPO bu analizden türetilmelidir. BIA eskiyse yeni sistem ve süreçleri yansıtmayabilir.

Kritik Sistem Listesi

Kritik sistem listesi yönetim tarafından onaylanmalıdır. Uygulama, altyapı ve OT sistemleri birlikte değerlendirilebilir. Sıralama recovery planını belirler. Birinci seviye uygulamanın bağımlı olduğu DNS veya storage unutulmamalıdır. Liste yılda en az belirlenen periyotta review edilmelidir.

Recovery Time Objective — RTO

RTO hizmetin kabul edilebilir geri dönüş süresidir. Teknik ekibin istediği değer değil iş biriminin ihtiyacı olmalıdır. Daha düşük RTO daha yüksek yatırım gerektirebilir. Tatbikat sonucuyla gerçek recovery süresi karşılaştırılmalıdır. Hedef ve kapasite arasındaki fark risk olarak raporlanmalıdır.

Recovery Point Objective — RPO

RPO kabul edilebilir veri kaybı süresini ifade eder. Bir saatlik RPO ile günlük backup uyumlu değildir. Uygulama ve veri tabanı mimarisi hedefe göre tasarlanmalıdır. OT historian veya konfigürasyon verisinde farklı RPO gerekebilir. İş birimi veri kaybının etkisini açıkça değerlendirmelidir.

Disaster Recovery Plan

DR planı rol, iletişim, teknik adım ve bağımlılıkları içermelidir. Yalnızca sistem yöneticisinin bildiği sözlü prosedür yeterli değildir. Vendor ve lisans iletişim bilgileri güncel tutulmalıdır. Plan offline erişilebilir olmalıdır. Tatbikat sonrası güncellenmelidir.

Alternatif İletişim Kanalları

Kurumsal e-posta kesildiğinde ekip nasıl iletişim kuracağını bilmelidir. Telefon zinciri veya güvenli alternatif platform hazırlanabilir. Kişisel uygulama kullanımı veri riski açısından değerlendirilmelidir. İletişim listesi güncel tutulmalıdır. Tatbikatta alternatif kanal test edilmelidir.

Elektrik Kesintisi Senaryosu

UPS ve jeneratör kapasitesi kritik sistemleri desteklemelidir. Yakıt ve bakım durumu operasyon planına dahildir. Uzun süreli kesintide hangi sistemlerin kontrollü kapatılacağı bilinmelidir. OT sahalarında enerji geri geldiğinde güvenli startup prosedürü önemlidir. Tatbikat teknik ve tesis ekipleriyle yapılmalıdır.

İnternet Kesintisi Senaryosu

Cloud ve remote access bağımlılığı internet kesintisinde görünür hale gelir. İkinci bağlantı veya farklı operatör kullanılabilir. OT sisteminin yerel çalışmaya devam edip edemediği değerlendirilmelidir. Kritik SaaS uygulamalarına alternatif prosedür bulunabilir. DNS ve VPN bağımlılıkları ayrıca incelenmelidir.

Veri Merkezi Kaybı

Yangın veya ciddi altyapı arızası tüm lokasyonu kullanılamaz hale getirebilir. Off-site recovery kapasitesi değerlendirilmelidir. Kritik network ve kimlik hizmetleri alternatif ortamda çalışabilmelidir. Veri kopyası kadar konfigürasyon ve lisans da gereklidir. Tam DR tatbikatı bu senaryoyu doğrular.

Ransomware Senaryosu

Ransomware klasik felaketten farklı olarak yedekleri de hedefleyebilir. Immutable veya offline kopya önem kazanır. Kimlik sistemi ve admin hesapları olay planına dahil edilmelidir. Temiz ortamda restore prosedürü bulunmalıdır. İletişim ve delil koruma adımları teknik recovery ile birlikte yürütülmelidir.

DR Tatbikatları

Plan tatbikat yapılmadan doğrulanmış sayılmamalıdır. Tabletop, teknik restore ve tam failover gibi farklı seviyeler kullanılabilir. Hedef ve gerçekleşen süre kaydedilir. Eksik bağımlılıklar bulguya dönüştürülür. Her tatbikat sonrası plan güncellenmelidir.

Endüstriyel Operasyon Sürekliliği Denetimi

Endüstriyel süreklilikte dijital sistem kaybı fiziksel üretimin nasıl devam edeceği sorusuyla birlikte ele alınmalıdır. SCADA olmadan operasyonun manuel devam edip edemediği değerlendirilmelidir. PLC, haberleşme, sensör ve merkezi sistem kaybı ayrı senaryolar olarak çalışılabilir. Safety ve cybersecurity arasındaki ilişki göz ardı edilmemelidir. Denetim gerçek operasyon ekibinin kriz anında ne yapacağını bilip bilmediğini test etmelidir.

SCADA Kaybında Operasyon Devam Edebilir mi?

SCADA görünürlüğü kaybolduğunda saha operasyonu nasıl etkileniyor bilinmelidir. Yerel HMI veya manuel kontrol imkânı olabilir. Operatörlerin alternatif prosedürü bilmesi gerekir. Bu modda ne kadar süre güvenli çalışılabileceği belirlenmelidir. Tatbikat kontrollü koşullarda yapılabilir.

Manuel İşletme Prosedürleri

Otomasyon kaybında uygulanacak manuel adımlar yazılı olmalıdır. Personel periyodik eğitim almalıdır. Kritik parametre sınırları prosedürde bulunmalıdır. Yetki ve iletişim zinciri tanımlanmalıdır. Doküman elektronik sistem dışında da erişilebilir olmalıdır.

PLC Arızası Senaryosu

Yedek PLC veya hızlı değişim prosedürü bulunabilir. Program yedeği ve firmware uyumluluğu kontrol edilmelidir. Değişimi yapacak yetkili personel belirlenmelidir. Kritik spare part stok durumu değerlendirilmelidir. Recovery süresi RTO ile karşılaştırılmalıdır.

Haberleşme Kesintisi

Field network veya WAN bağlantısı kesildiğinde sistem davranışı bilinmelidir. PLC'ler güvenli local modda çalışmaya devam edebilir. Operatör görünürlüğü azalabilir. Alternatif haberleşme yöntemi gerekebilir. Alarm ve safety davranışı üretici dokümantasyonuyla doğrulanmalıdır.

Sensör Verisi Kaybı

Kritik sensörün kaybı yanlış otomatik karar oluşturabilir. Sistem fail-safe davranışa geçmelidir. Redundant sensör bazı proseslerde kullanılabilir. Operatör alarmı açık olmalıdır. Denetim sensör kaybı senaryosunun kontrol mantığında nasıl ele alındığını inceler.

Merkezi Sistem Kaybı

Merkezi SCADA veya historian kaybı saha cihazlarını tamamen durdurmayabilir. Mimari bu ayrımı desteklemelidir. Yerel kontrol mümkünse avantaj sağlar. Merkezi server restore süreci ayrı test edilmelidir. Veri kaybı ve operasyon kaybı farklı risk olarak ele alınmalıdır.

Safety ile Cybersecurity Arasındaki Bağlantı

Siber güvenlik değişikliği safety kontrolünü etkileyebilir. Firewall kuralı kritik haberleşmeyi kesmemelidir. Security testleri safety owner bilgisi olmadan yapılmamalıdır. Tehdit modeli fiziksel sonuçları içermelidir. Ortak review iki disiplin arasındaki boşluğu azaltır.

Fiziksel Güvenlik Denetimi

Bilişim sistemleri yalnızca network üzerinden korunmaz. Server room, network odası ve OT kontrol alanlarına fiziksel erişim de kritik güvenlik katmanıdır. Elektrik, soğutma, yangın ve çevresel izleme kesinti riskini doğrudan etkiler. Kartlı geçiş, kamera ve ziyaretçi yönetimi fiziksel olayların izlenebilirliğini sağlar. Denetim teknik altyapının fiziksel dayanıklılığını da değerlendirmelidir.

Server Room

Sunucu odası kontrollü erişime sahip olmalıdır. Kritik sistemler açık ofis ortamında tutulmamalıdır. Yetkili personel listesi düzenli review edilmelidir. Fiziksel düzen kablo ve bakım riskini azaltmalıdır. Çevresel sensörler sıcaklık ve nemi izleyebilir.

Network Odaları

Dağıtım switch'leri ve patch paneller fiziksel olarak korunmalıdır. Ortak kullanım alanındaki açık kabinet risk oluşturur. Kapı veya rack erişimi sınırlandırılabilir. UPS desteği kritik network cihazları için değerlendirilmelidir. Lokasyon listesi envanterde bulunmalıdır.

OT Kontrol Odaları

Kontrol odasına erişim yalnızca gerekli personele verilmelidir. Ziyaretçiler refakatli olabilir. Engineering workstation fiziksel olarak korunmalıdır. USB ve taşınabilir cihaz politikası uygulanabilir. Kamera kaydı kurum politikasına göre ek kontrol sağlayabilir.

Elektrik ve UPS

UPS kapasitesi ve akü sağlık durumu düzenli test edilmelidir. Kritik sistemlerin tahmini çalışma süresi bilinmelidir. Alarm sistemi aktif olmalıdır. Bakım kaydı denetimde kanıt olarak kullanılabilir. UPS tek başına uzun süreli kesinti çözümü değildir.

Jeneratör

Jeneratör kritik hizmeti uzun süre destekleyebilir. Yakıt kapasitesi ve bakım periyodu belirlenmelidir. Otomatik devreye girme testi yapılmalıdır. Elektrik yükü gerçek senaryoya göre hesaplanmalıdır. Tatbikat sonucunda sorunlar kayıt altına alınmalıdır.

Klima ve Çevresel İzleme

Sunucu odasında soğutma kaybı kısa sürede sistem arızasına yol açabilir. Sıcaklık ve nem alarmı bulunmalıdır. Kritik odalarda yedek klima değerlendirilebilir. Alarmın kimlere gittiği test edilmelidir. Çevresel izleme logları bakım planını destekler.

Yangın Algılama ve Söndürme

Yangın algılama sistemi düzenli test edilmelidir. Söndürme çözümü elektronik ekipmana uygun seçilmelidir. Tahliye ve acil kapatma prosedürü bilinmelidir. Sistem bakımları kayıt altına alınmalıdır. Veri merkezi kaybı senaryosu DR planıyla ilişkilendirilmelidir.

Kartlı Geçiş

Kritik odalara giriş kayıtlı olmalıdır. Eski çalışan kartları iptal edilmelidir. Yetki rol ve lokasyona göre verilebilir. Acil erişim prosedürü bulunmalıdır. Geçiş logları olay incelemesinde kullanılabilir.

Kamera Sistemleri

Kamera kritik fiziksel alanları izleyebilir. Retention süresi ve erişim yetkileri belirlenmelidir. Kamera sistemi kendi siber güvenlik riskini de taşır. Varsayılan parolalar değiştirilmelidir. Network segmentasyonu uygulanabilir.

Ziyaretçi Yönetimi

Vendor ve ziyaretçi girişleri kayıt altına alınmalıdır. Kritik teknik alanda refakat gerekebilir. Geçici kartlar çıkışta teslim alınmalıdır. Ziyaret amacı ve süre bilgisi saklanabilir. Fiziksel ve remote vendor erişim süreçleri birlikte değerlendirilebilir.

Üçüncü Taraf ve Tedarikçi Güvenliği

Kurumun güvenliği yalnızca kendi sistemleriyle sınırlı değildir. Cloud sağlayıcısı, bakım firması veya yazılım tedarikçisi kritik erişim ve veri işleme yetkisine sahip olabilir. SLA, siber güvenlik maddeleri ve gizlilik yükümlülükleri sözleşmede açık olmalıdır. Tedarikçi ayrıldığında hesap ve erişimler kaldırılmalıdır. Vendor risk yönetimi procurement sürecinden hizmet sonuna kadar devam eden yaşam döngüsü olmalıdır.

Kritik Tedarikçilerin Belirlenmesi

Her tedarikçi aynı riskte değildir. Kritik veri veya sistem erişimi olan firmalar ayrı sınıflandırılmalıdır. Hizmet kesildiğinde kurum üzerindeki etki değerlendirilmelidir. Kritik vendor için güvenlik kanıtı istenebilir. Risk sınıfı review sıklığını belirleyebilir.

SLA'lar

SLA yalnızca hizmet süresini değil güvenlik ve olay bildirim beklentisini de içerebilir. Kritik arıza yanıt süreleri açık olmalıdır. Backup ve recovery sorumlulukları tanımlanabilir. Uyum ve denetim hakkı değerlendirilebilir. SLA performansı periyodik ölçülmelidir.

Siber Güvenlik Maddeleri

Tedarikçinin temel güvenlik sorumlulukları sözleşmede yer almalıdır. MFA, olay bildirimi ve veri koruma şartları örnek olabilir. Alt yüklenici kullanımı kontrol edilebilir. Güvenlik açığı tespitinde düzeltme sorumluluğu tanımlanmalıdır. Sözleşme teknik ekip ve hukuk tarafından birlikte değerlendirilmelidir.

Gizlilik Yükümlülükleri

Tedarikçi kurumun hassas verisine erişebilir. Gizlilik şartları çalışan ve alt yüklenicileri kapsamalıdır. Veri kullanım amacı sınırlandırılmalıdır. Hizmet sonunda veri iade veya silme süreci tanımlanmalıdır. İhlal halinde bildirim yükümlülüğü açık olmalıdır.

Vendor Remote Access

Uzaktan erişim güvenli gateway üzerinden yapılmalıdır. Kişisel vendor hesabı tercih edilmelidir. MFA ve oturum kaydı yüksek riskli sistemlerde uygulanabilir. Süre sınırlı erişim attack surface'i azaltır. Erişim logları düzenli review edilmelidir.

Cloud Sağlayıcıları

Cloud ortamında güvenlik sorumluluğu tamamen sağlayıcıya geçmez. Kurum identity, veri ve konfigürasyon alanında önemli sorumluluk taşır. Sağlayıcı sertifikaları ve hizmet şartları incelenebilir. Backup ve log seçenekleri kurum tarafından etkinleştirilmelidir. Data residency ihtiyacı değerlendirilmelidir.

Bakım Firmaları

Bakım firmaları yüksek teknik yetkiye sahip olabilir. Sahada fiziksel ve uzaktan erişim kuralları uygulanmalıdır. Kullanılan laptop ve USB cihazlar risk oluşturabilir. Değişiklik sonrası konfigürasyon yedeği alınmalıdır. İş tamamlanınca geçici hesaplar kapatılmalıdır.

Yazılım Tedarikçileri

Kaynak kod, destek ve güncelleme modeli değerlendirilmelidir. Kritik uygulamada güvenlik açığı yönetimi SLA içinde bulunabilir. Vendor'ın admin erişimi kontrol edilmelidir. Ürün EOL politikası yatırım kararını etkiler. Açık API ve veri taşınabilirliği bağımlılık riskini azaltabilir.

Tedarikçi Ayrıldığında Yetkilerin Kaldırılması

Sözleşme sona erdiğinde tüm hesaplar aynı gün kapatılmalıdır. VPN, uygulama ve fiziksel kartlar kontrol listesine eklenmelidir. Paylaşılan parolalar değiştirilebilir. Vendor tarafından tutulan veri iade veya silme sürecine girmelidir. Closure evidence saklanmalıdır.

Cloud ve SaaS Denetimi

Cloud ve SaaS kullanımı hızlı büyüdüğü için kurumun gerçek dijital varlıklarının önemli bölümü kendi veri merkezinin dışında olabilir. Microsoft 365, Google Workspace, IaaS ve diğer SaaS hizmetlerinin kimlik, admin, backup ve loglama kontrolleri denetlenmelidir. Shadow SaaS kurum verisinin kontrol dışına çıkmasına yol açabilir. Cloud identity ve MFA en yüksek öncelikli alanlardandır. Paylaşılan sorumluluk modeli denetim planında açık biçimde anlaşılmalıdır.

Microsoft 365

Admin rolleri minimum kişiye verilmelidir. MFA ve conditional access değerlendirilebilir. E-posta güvenlik politikaları kontrol edilmelidir. Audit log retention ve erişim ayarları incelenmelidir. Harici paylaşım ve uygulama izinleri ayrıca gözden geçirilmelidir.

Google Workspace

Admin hesapları günlük kullanıcı hesabından ayrılabilir. MFA coverage ölçülmelidir. Harici dosya paylaşımı politika ile sınırlandırılabilir. OAuth uygulama izinleri kontrol edilmelidir. Audit loglar olay tespitinde kullanılmalıdır.

IaaS

Cloud network, security group ve public exposure denetlenmelidir. Root veya owner hesapları yüksek koruma gerektirir. Storage bucket ve snapshot erişimleri kontrol edilmelidir. Infrastructure as Code kullanılıyorsa repository güvenliği önemlidir. Cloud log ve monitoring etkinleştirilmelidir.

SaaS Uygulamaları

Her SaaS'ın veri türü ve business owner'ı bilinmelidir. SSO ve MFA mümkünse kullanılmalıdır. Admin rolleri düzenli review edilmelidir. Kullanıcı offboarding merkezi süreçle entegre olmalıdır. Export ve backup seçenekleri anlaşılmalıdır.

Cloud Identity

Cloud kimlik sistemi saldırgan için güçlü hedef olabilir. Legacy authentication kapatılmalıdır. MFA ve risk tabanlı erişim politikaları uygulanabilir. Admin hesapları özel korunmalıdır. Identity logları merkezi SIEM'e aktarılabilir.

MFA

Cloud erişiminde MFA temel kontrol olmalıdır. Coverage eksikleri düzenli raporlanabilir. Servis ve legacy protokoller için istisnalar ayrıca değerlendirilmelidir. Phishing dirençli faktörler yüksek riskli kullanıcılar için düşünülebilir. Admin hesaplarında daha güçlü politika uygulanabilir.

Admin Hesapları

Global admin veya root yetkisi minimum sayıda kullanıcıda olmalıdır. Günlük iş için kullanılmamalıdır. Break-glass hesap ayrı kontrol altında tutulabilir. Her admin işlemi loglanmalıdır. Yetki review periyodik yapılmalıdır.

Cloud Backup

SaaS sağlayıcının availability taahhüdü kurumun backup ihtiyacını tamamen karşılamayabilir. Silinen veya şifrelenen verinin geri dönüş seçenekleri anlaşılmalıdır. Kritik veri için bağımsız backup değerlendirilebilir. Restore testi yapılmalıdır. Retention iş ve mevzuat ihtiyacıyla uyumlu olmalıdır.

Loglama

Cloud audit loglarının retention süresi kontrol edilmelidir. Kritik identity ve admin olayları SIEM'e aktarılabilir. Log export kapasitesi lisans seviyesine bağlı olabilir. Denetim gerçek log örneklerini incelemelidir. Zaman senkronizasyonu sağlayıcı tarafından yönetilse de olay korelasyonu doğrulanmalıdır.

Shadow SaaS

Kullanıcılar onaysız cloud uygulamalarına veri yükleyebilir. Web proxy, CASB veya harcama analizi yardımcı olabilir. Bulunan uygulama önce iş ihtiyacı açısından değerlendirilmelidir. Güvenli kurumsal alternatif sunulabilir. Shadow SaaS politikası satın alma süreciyle entegre edilmelidir.

E-Posta Güvenliği Denetimi

E-posta kimlik avı ve hesap ele geçirme saldırılarında sık kullanılan giriş noktasıdır. MFA, SPF, DKIM, DMARC ve anti-phishing kontrolleri birlikte değerlendirilmelidir. Forwarding kuralları ele geçirilmiş hesaplarda veri sızdırmak için kullanılabilir. Admin hesapları daha sıkı güvenlik politikasına sahip olmalıdır. Kullanıcı farkındalığı teknik kontrollerin etkisini tamamlar.

MFA

E-posta hesabında MFA parola sızıntısına karşı güçlü koruma sağlar. Coverage bütün kullanıcılar için ölçülmelidir. Admin ve finans kullanıcıları önceliklendirilebilir. Legacy protokoller MFA'yı bypass ediyorsa kapatılmalıdır. İstisnalar risk kabul sürecine alınmalıdır.

SPF

SPF hangi sunucuların kurum adına e-posta gönderebileceğini tanımlar. Yanlış veya geniş kayıt sahteciliği önlemeyi zorlaştırır. Yetkili servisler düzenli gözden geçirilmelidir. Eski vendor kayıtları kaldırılmalıdır. SPF tek başına tam e-posta doğrulaması sağlamaz.

DKIM

DKIM mesajın kriptografik imza ile doğrulanmasını sağlar. Anahtar uzunluğu ve rotation süreci önemlidir. Kullanılan üçüncü taraf servisler doğru yapılandırılmalıdır. Eski selector kayıtları gözden geçirilebilir. DMARC ile birlikte daha güçlü koruma sağlar.

DMARC

DMARC SPF ve DKIM doğrulamasının politika ile uygulanmasını sağlar. Başlangıçta raporlama moduyla geçiş yapılabilir. Yetkili gönderenler doğrulandıktan sonra daha sıkı politika uygulanabilir. Raporlar sahte gönderim kaynaklarını gösterebilir. Sürekli bakım gerektirir.

Anti-Phishing

Kimlik avı filtresi domain benzerliği ve zararlı bağlantıları tespit edebilir. VIP kullanıcı koruması eklenebilir. Kullanıcı raporlama butonu olay sürecini hızlandırır. False positive düzenli incelenmelidir. Teknik filtre farkındalık eğitimiyle birlikte kullanılmalıdır.

Zararlı Ek Kontrolleri

E-posta ekleri sandbox veya güvenlik motoruyla analiz edilebilir. Riskli dosya türleri sınırlandırılabilir. Makro politikaları endpoint tarafında destekleyici kontrol sağlar. Şifreli arşivler özel prosedüre ihtiyaç duyabilir. Olay logları SIEM'e aktarılabilir.

Admin Hesapları

E-posta admin hesabı normal e-posta için kullanılmamalıdır. MFA ve daha güçlü conditional access uygulanabilir. Oturumlar ayrı cihazdan yapılabilir. Admin activity loglanmalıdır. Break-glass hesap düzenli test edilmelidir.

Forwarding Kuralları

Yetkisiz otomatik yönlendirme veri sızıntısı göstergesi olabilir. Dış forwarding kurum politikasına göre sınırlandırılabilir. Yeni rule oluşturulduğunda alarm üretilebilir. Mevcut kurallar düzenli taranmalıdır. Kullanıcı ayrıldığında forwarding ihtiyacı kontrollü yöntemle yönetilmelidir.

Kullanıcı Farkındalığı

Çalışan phishing belirtisini tanıyabilmelidir. Eğitim kısa ve düzenli yapılabilir. Simülasyon sonuçları cezalandırma için kullanılmamalıdır. Riskli gruplara ek eğitim verilebilir. Kullanıcı şüpheli e-postayı kolayca raporlayabilmelidir.

Siber Olay Müdahale Kapasitesinin Denetlenmesi

Olay müdahale kapasitesi yalnızca incident response dokümanının varlığı değildir. Roller, sınıflandırma, eskalasyon, delil koruma ve iletişim pratikte test edilmelidir. Ransomware ve OT olayları için ayrı playbook gerekebilir. Tabletop exercise ekiplerin gerçek olayda birlikte nasıl çalışacağını gösterir. Denetim önceki olaylardan alınan derslerin prosedüre aktarılıp aktarılmadığını da değerlendirmelidir.

Incident Response Plan Var mı?

Plan olayın tespitinden kapanışına kadar temel adımları açıklamalıdır. İletişim ve teknik roller bulunmalıdır. Plan offline erişilebilir olmalıdır. Güncel iletişim bilgileri düzenli kontrol edilmelidir. Tatbikat sonrası revizyon yapılmalıdır.

Roller ve Sorumluluklar

Kim teknik lider, kim yönetim iletişim sorumlusu bilinmelidir. Hukuk ve insan kaynakları gerektiğinde sürece dahil olabilir. OT olayında proses sahibi ayrıca bulunmalıdır. Rol yedeği tanımlanabilir. Olay anında sorumluluk tartışması zaman kaybettirmemelidir.

Olay Sınıflandırması

Her alarm aynı incident seviyesine sahip değildir. Severity kriterleri iş ve teknik etkiye göre tanımlanmalıdır. Kritik sistem etkisi seviye yükseltebilir. Veri ihlali özel sınıf olabilir. Sınıflandırma eskalasyon süresini belirler.

Eskalasyon Süreci

Hangi seviyede kimin bilgilendirileceği açık olmalıdır. Kritik olayın saatlerce yerel ekipte kalması riski büyütebilir. Yönetim ve dış destek iletişimi tanımlanmalıdır. Otomatik alarm sistemi destek sağlayabilir. Tatbikat eskalasyon süresini ölçebilir.

Delil Koruma

Olay sırasında log veya disk verisinin korunması önemlidir. Yanlış müdahale delili bozabilir. Chain of custody gerekiyorsa prosedür tanımlanmalıdır. Kritik sistemde imaging operasyon etkisi nedeniyle dikkatli yapılmalıdır. Forensic uzmanlık gerektiren durumlar önceden planlanabilir.

İletişim Planı

Çalışan, yönetim, vatandaş veya müşteri iletişimi ayrı mesaj gerektirir. Teknik ekip tek başına kamu açıklaması yapmamalıdır. Onay süreci önceden belirlenmelidir. E-posta kesintisine alternatif kanal bulunmalıdır. Yanlış veya gecikmiş bilgi itibar etkisini artırabilir.

Kurum Dışı Bildirimler

Bazı olaylar düzenleyici veya iş ortaklarına bildirim gerektirebilir. Hangi olayda hangi birimin karar vereceği belirlenmelidir. İletişim bilgileri hazır tutulmalıdır. Bildirim zaman çizelgesi olay kaydında yer alabilir. Hukuki değerlendirme teknik olay yönetimiyle koordine edilmelidir.

Ransomware Playbook

Ransomware için izolasyon, kimlik kontrolü ve recovery adımları hazırlanmalıdır. Yedeklerin etkilenip etkilenmediği kontrol edilir. Domain hesaplarının ele geçirilme ihtimali değerlendirilir. Temiz ortamda recovery planlanır. Tatbikat gerçek teknik ve yönetim kararlarını test etmelidir.

OT Incident Response Playbook

OT olayında sistemi kapatmak her zaman güvenli çözüm değildir. Operasyon ve safety ekibi karar sürecine katılmalıdır. Ağ izolasyonu fiziksel proses etkisiyle birlikte değerlendirilir. Vendor iletişimi önceden tanımlanmalıdır. Delil toplama yöntemi üretim sürekliliğini korumalıdır.

Tabletop Exercise

Tabletop teknik değişiklik yapmadan senaryoyu masa başında çalıştırır. Farklı birimlerin karar ve iletişim akışı görülür. Bilinmeyen bağımlılıklar ortaya çıkar. Sonuç aksiyon listesine dönüştürülür. Düzenli tekrar kurumun olay refleksini güçlendirir.

IT Audit İçin Kullanılabilecek Temel Çerçeveler

Tek bir standart bütün kurumların denetim ihtiyacını eksiksiz karşılamaz. ISO/IEC 27001 yönetim sistemi perspektifi sunarken COBIT yönetişim ve kontrol yaklaşımı sağlar. NIST Cybersecurity Framework ve NIST SP 800-82 siber güvenlik ve OT tarafında güçlü referans oluşturabilir. ISA/IEC 62443 endüstriyel otomasyon güvenliğinde önemli yapı sunar. ISO 27001 uyumlu IT audit risk analizi ve siber güvenlik denetimi yapılırken kurum ve sektör özel düzenlemeleri de ayrıca dikkate alınmalıdır.

ISO/IEC 27001

ISO/IEC 27001 bilgi güvenliği yönetim sistemini risk tabanlı biçimde ele alır. Politika, risk, kontrol ve sürekli iyileştirme yapısı sunar. IT Audit için yönetişim ve kontrol referansı olabilir. Sertifika sahibi olmak bütün teknik risklerin ortadan kalktığı anlamına gelmez. Denetim gerçek uygulama kanıtını ayrıca değerlendirmelidir.

ISO 19011

ISO 19011 yönetim sistemi denetimlerinin planlanması ve yürütülmesi için rehberlik sağlar. Denetim programı, kanıt ve raporlama yaklaşımında kullanılabilir. Denetçi yetkinliği ve bağımsızlığı önemli konulardır. Teknik kontrol çerçevesinin yerine geçmez. Metodoloji tarafında destekleyici referans olabilir.

COBIT

COBIT bilişim yönetişimi ve yönetimi için süreç perspektifi sunar. Yönetim hedefleri ile teknoloji kontrolleri arasında ilişki kurabilir. IT Audit kapsamını yönetişim ve performans alanlarına genişletebilir. Her kontrolün aynen uygulanması gerekli değildir. Kurum bağlamına göre ilgili hedefler seçilmelidir.

NIST Cybersecurity Framework

NIST CSF güvenlik faaliyetlerini yapılandırılmış fonksiyonlar etrafında ele alır. Kurum mevcut ve hedef profil oluşturabilir. Risk ve olgunluk konuşmasını yönetim seviyesine taşımaya yardımcı olur. Teknik detay için başka standartlarla birlikte kullanılabilir. Sürekli iyileştirme programını destekler.

NIST SP 800-82

NIST SP 800-82 endüstriyel kontrol sistemleri güvenliği için önemli teknik rehberlerden biridir. OT mimarisi, threat ve güvenlik kontrolleri konusunda referans sağlar. IT kontrolünün OT'ye doğrudan uygulanmasının risklerini açıklar. Network segmentation ve remote access konularında yararlıdır. Kurum kendi teknoloji ve safety koşuluna göre uyarlamalıdır.

ISA/IEC 62443

ISA/IEC 62443 endüstriyel otomasyon ve kontrol sistemleri için kapsamlı güvenlik yaklaşımı sunar. Asset owner, service provider ve product supplier sorumluluklarını ayırır. Zone ve conduit modeli network segmentation için güçlü araçtır. Security Level yaklaşımı risk tabanlı hedef belirlemeyi destekler. OT Audit programında önemli referans olarak kullanılabilir.

CISA OT Cybersecurity Guidance

CISA tarafından yayımlanan OT güvenlik rehberleri pratik kontrol ve risk perspektifi sağlayabilir. Varlık görünürlüğü, segmentasyon ve erişim konuları sık vurgulanır. Kurum bu rehberleri kendi standart setiyle birlikte değerlendirebilir. Güncel tavsiyeler değişen tehditlere göre takip edilmelidir. Tek kaynak yerine çoklu referans yaklaşımı daha güçlüdür.

Bilgi ve İletişim Güvenliği Rehberi

Türkiye'deki kurumlar için ilgili ulusal rehberler ayrıca değerlendirilmelidir. Kurumun tabi olduğu yükümlülük ve kapsam açıkça belirlenmelidir. Teknik kontroller yerel düzenleme ihtiyacıyla eşleştirilebilir. Denetim compliance matrix hazırlayabilir. Güncel sürüm ve kapsam resmi kaynak üzerinden doğrulanmalıdır.

Kuruma ve Sektöre Özel Düzenlemeler

Enerji, sağlık veya kamu gibi alanlarda ilave gereksinimler bulunabilir. Denetim başlangıcında yükümlülük envanteri çıkarılmalıdır. Hukuk ve compliance birimleri sürece katılmalıdır. Teknik kontrol aynı anda birden fazla gereksinimi karşılayabilir. Matrix yaklaşımı tekrar eden denetim maliyetini azaltır.

ISA/IEC 62443 Perspektifinden Endüstriyel Denetim

ISA/IEC 62443 yaklaşımı OT güvenliğini yalnızca firewall veya PLC kontrolünden daha geniş görür. Asset owner, service provider ve product supplier sorumlulukları farklıdır. Security program, zone, conduit ve Security Level kavramları sistematik risk yönetimi sağlar. Yaşam döngüsü boyunca güvenlik tasarım, işletme ve bakım aşamalarında sürdürülmelidir. Endüstriyel denetim bu rolleri ve kontrolleri kurumun gerçek operasyon modeliyle eşleştirmelidir.

Industrial Automation and Control Systems

IACS fiziksel süreçleri izleyen ve kontrol eden sistemlerin bütününü ifade eder. PLC, SCADA ve ilgili network bu yapının parçasıdır. Denetim yalnızca cihazları değil sistem ilişkilerini incelemelidir. Kullanılabilirlik ve safety gereksinimleri önemlidir. Kontrol seçimi proses etkisine göre yapılmalıdır.

Asset Owner

Asset owner sistemin güvenli işletiminden temel sorumluluğu taşır. Güvenlik politikası ve risk hedefleri belirlenmelidir. Vendor'a görev devredilse bile risk sahipliği tamamen kaybolmaz. Yetki ve bakım süreçleri kontrol altında tutulmalıdır. Denetim asset owner sorumluluklarının gerçekten yerine getirilip getirilmediğini inceler.

Service Provider

Service provider entegrasyon, bakım veya yönetim hizmeti sunabilir. Yetkinlik ve güvenli çalışma prosedürü değerlendirilmelidir. Uzaktan erişim kuralları sözleşmede bulunmalıdır. Yapılan değişiklikler kayıt altına alınmalıdır. Asset owner güvenlik şartlarını tedarikçiye açık biçimde aktarmalıdır.

Product Supplier

Ürün sağlayıcısı cihaz veya yazılımın güvenlik özelliklerinden sorumludur. Güvenlik duyuruları ve patch desteği önemlidir. EOL politikası kurum riskini etkiler. Default configuration güvenli olmalıdır. Denetim ürün risklerini vendor belgeleriyle birlikte değerlendirebilir.

Security Program

OT güvenliği tek proje değil sürekli program olmalıdır. Politika, risk yönetimi, olay müdahale ve yetkinlik geliştirme birlikte ele alınır. Yönetim desteği gereklidir. KPI ve denetim döngüsü programı ölçülebilir hale getirir. Program IT güvenliğiyle koordineli çalışmalıdır.

Zone ve Conduit

Zone benzer güvenlik ihtiyacı olan varlıkları gruplar. Conduit zone'lar arasındaki kontrollü iletişim yoludur. Model network ve güvenlik mimarisini anlaşılır hale getirir. Firewall kuralları bu tasarıma göre oluşturulabilir. Denetim gerçek trafik ile hedef modeli karşılaştırır.

Security Level Yaklaşımı

Security Level farklı tehdit kapasitesine karşı hedef dayanıklılığı ifade eder. Her varlık aynı seviyeyi gerektirmez. Risk analizi hedef seviyeyi belirlemelidir. Teknik ve süreç kontrolleri buna göre planlanır. Denetim mevcut seviye ile hedef arasındaki farkı gösterebilir.

OT Yaşam Döngüsü Boyunca Güvenlik

Güvenlik sistem satın alındıktan sonra başlamamalıdır. Tasarım, procurement, devreye alma, bakım ve devreden çıkarma aşamalarında kontrol uygulanmalıdır. Yeni vendor seçimi güvenlik şartlarını içermelidir. Değişiklikler risk değerlendirmesine bağlı olmalıdır. Denetim yaşam döngüsündeki kopuk noktaları görünür hale getirir.

IT Audit Nasıl Yapılır? Uçtan Uca Metodoloji

IT Audit iyi planlanmadığında çok sayıda kontrol yapılıp az değer üreten projeye dönüşebilir. Sağlıklı metodoloji ön görüşme, scope, envanter, risk analizi, saha çalışması, kanıt ve raporlama aşamalarını açık biçimde tanımlar. Bulgular yönetimle doğrulanmalı ve risk puanına göre önceliklendirilmelidir. Nihai rapor son adım değildir, remediation ve follow-up audit süreciyle devam etmelidir. Endüstriyel bilişim denetimi IT audit nasıl yapılır sorusunun uygulanabilir cevabı uçtan uca bu döngüdür.

Aşama 1 — Ön Görüşme

Kurumun hizmetleri, riskleri ve beklentileri anlaşılır. Yönetim ve teknik ekip ayrı perspektif sunabilir. Önceki olay ve denetim bulguları incelenebilir. Kritik sistemler hakkında ilk liste oluşturulur. Bu görüşme sonraki scope kararını destekler.

Aşama 2 — Scope Belirleme

Lokasyon, sistem, OT ve cloud kapsamı yazılı hale getirilir. Test kısıtları belirtilir. Kritik sistemler risk tabanlı öncelik alır. Hariç bırakılan alanlar belgelenir. Scope ilgili taraflarca onaylanır.

Aşama 3 — Doküman Talebi

Politika, diyagram, envanter ve raporlar önceden istenebilir. Belgelerin güncelliği kontrol edilir. Eksik doküman ayrıca bulgu olmayabilir ancak yönetişim riski gösterebilir. Teknik çalışma belge sonuçlarıyla yönlendirilir. Hassas dosyalar güvenli yöntemle paylaşılmalıdır.

Aşama 4 — Varlık Envanteri

Mevcut envanter gerçek ortamla karşılaştırılır. IT ve OT varlıkları doğrulanır. Shadow IT araştırılır. Kritiklik ve sahip bilgisi eklenir. Eksik coverage sonraki teknik testleri etkiler.

Aşama 5 — Risk Analizi

Tehdit, zafiyet ve iş etkisi birlikte değerlendirilir. Kritik hizmet bağımlılıkları dikkate alınır. Internet exposure ve vendor erişimi öncelik sinyali sağlar. Risk modeli kurumla paylaşılır. Test planı yüksek riskli alanlara odaklanır.

Aşama 6 — Saha Çalışması

Fiziksel lokasyon ve gerçek sistem kullanımı gözlemlenir. Kontrol odası, server room ve network yapısı incelenir. Kullanıcılarla süreç görüşmeleri yapılır. Doküman ile operasyon arasındaki fark görünür hale gelir. OT çalışma güvenliği sürekli korunur.

Aşama 7 — Teknik Kontrol Testleri

Firewall, identity, patch, backup ve loglama gibi alanlar teknik kanıtlarla test edilir. Test yöntemi scope ve risk kısıtlarına uymalıdır. OT sistemlerinde aktif test sınırlı tutulabilir. Araç çıktıları manuel doğrulamayla desteklenir. Her test beklenen kontrol kriterine bağlanmalıdır.

Aşama 8 — Kanıt Toplama

Konfigürasyon, log, ekran görüntüsü ve raporlar kanıt olarak saklanabilir. Kanıt tarih ve sistem bilgisi içermelidir. Hassas bilgiler korunmalıdır. Yalnızca görüşmeye dayalı bulgu mümkün olduğunda teknik kanıtla desteklenmelidir. Kanıt izlenebilir biçimde dosyalanmalıdır.

Aşama 9 — Bulguların Doğrulanması

İlk bulgular sistem sahibiyle görüşülür. False positive veya eksik bağlam giderilir. İş etkisi doğrulanır. Mevcut compensating control varsa risk yeniden değerlendirilir. Bu aşama nihai raporun güvenilirliğini artırır.

Aşama 10 — Risk Puanlama

Olasılık ve etki temel parametrelerdir. Varlık kritiklik, exposure ve exploitability eklenebilir. Mevcut kontrol residual risk'i etkiler. Fiziksel safety etkisi ayrıca ağırlıklandırılabilir. Model tutarlı biçimde bütün bulgulara uygulanmalıdır.

Aşama 11 — Yönetim Görüşmesi

Yönetim teknik detaydan önce en kritik iş risklerini görmelidir. Hızlı kazanımlar ve yatırım gerektiren maddeler ayrılır. Risk kabul kararı gereken noktalar belirtilir. Yönetim öncelik ve kaynak kararı verebilir. Görüşme nihai roadmap'in şekillenmesini sağlar.

Aşama 12 — Nihai Rapor

Rapor executive summary ve teknik bulguları ayrı seviyede sunmalıdır. Kanıt, risk ve öneri açık biçimde yazılmalıdır. Hedef tarih ve sorumlu birim eklenebilir. Compliance matrix gerekiyorsa rapora dahil edilir. Eklerde envanter ve diyagramlar bulunabilir.

Aşama 13 — Remediation

Kurum bulguları risk önceliğine göre düzeltir. Kritik açıklar önce ele alınır. Her aksiyon için owner ve hedef tarih belirlenir. Risk kabul edilen maddeler ayrıca onaylanır. İlerleme dashboard üzerinden takip edilebilir.

Aşama 14 — Follow-Up Audit

Kapatıldığı bildirilen bulgular yeniden test edilir. Closure evidence tek başına yeterli olmayabilir. Kontrolün gerçekten çalıştığı doğrulanır. Tekrar eden bulgular kök neden açısından incelenir. Follow-up döngüsü denetimi sürekli iyileştirmeye bağlar.

Denetimde Hangi Kanıtlar Toplanmalı?

Denetim bulgusu görüşe değil doğrulanabilir kanıta dayanmalıdır. Sistem konfigürasyonu, firewall export, kullanıcı listesi, log, backup raporu ve politika belgeleri en sık kullanılan kanıt türlerindendir. Ekran görüntüsü yardımcı olabilir ancak değiştirilebilir veya bağlamsız olmamalıdır. Görüşme notları teknik kanıtı destekler. Değişiklik kayıtları kontrolün geçmişte nasıl işletildiğini göstermesi açısından değerlidir.

Sistem Konfigürasyonları

Gerçek sistem ayarları kontrolün fiilen nasıl uygulandığını gösterir. Export mümkünse ekran görüntüsünden daha güçlü kanıt olabilir. Hassas secret bilgileri rapordan çıkarılmalıdır. Tarih ve sistem adı kaydedilmelidir. Baseline ile karşılaştırma yapılabilir.

Firewall Rule Export'ları

Firewall export gerçek erişim politikasını gösterir. Any-to-any ve kullanılmayan kurallar analiz edilebilir. Rule hit count varsa değerlendirmeye yardımcı olur. Kural sahibi ve açıklaması ayrıca kontrol edilmelidir. Export güvenli ortamda saklanmalıdır.

Network Diyagramları

Diyagram sistem ve segment ilişkisini gösterir. Gerçek network ile karşılaştırılmalıdır. İnternet ve vendor bağlantıları açıkça işaretlenmelidir. OT zone'ları ayrı gösterilebilir. Güncellik tarihi diyagram üzerinde bulunmalıdır.

Kullanıcı Yetki Listeleri

Admin grup üyelikleri ve uygulama rolleri analiz edilebilir. Kullanıcı listesi insan kaynakları kayıtlarıyla karşılaştırılabilir. Shared ve service account'lar ayrı sınıflandırılır. Son login bilgisi eski hesapları bulmaya yardımcı olur. Hassas kişisel veriler minimum tutulmalıdır.

Log Örnekleri

Log örneği kontrolün gerçekten kayıt ürettiğini gösterir. Timestamp ve olay türü doğrulanmalıdır. Başarılı ve başarısız örnekler seçilebilir. Merkezi sistemde göründüğü ayrıca kontrol edilebilir. Logun hassas içerik taşımadığı incelenmelidir.

Backup Raporları

Backup job sonuçları coverage ve başarısızlık trendini gösterir. Yalnızca son gün değil belirli dönem incelenmelidir. Kritik sistemler listeyle karşılaştırılır. Backup repository erişimi ayrıca değerlendirilir. Başarılı rapor restore kanıtıyla desteklenmelidir.

Restore Test Sonuçları

Restore sonucu geri dönüş kapasitesinin en güçlü kanıtıdır. Test tarihi, sistem ve süre kaydedilmelidir. Hedef RTO ile karşılaştırma yapılabilir. Başarısızlık nedeni belgelenmelidir. Sonraki düzeltici faaliyet takip edilmelidir.

Patch Raporları

Patch compliance oranı sistem gruplarına göre incelenebilir. Kritik eksikler listelenir. Gecikme nedeni not edilmelidir. EOL sistemler ayrı raporlanmalıdır. Patch politikası ile gerçek sonuç karşılaştırılır.

Vulnerability Scan Sonuçları

Tarama sonucu teknik açık için başlangıç kanıtı sağlar. False positive doğrulanmalıdır. Varlık kritiklik bilgisi eklenmelidir. OT taramalarında güvenli yöntem ve onay belgelenmelidir. Sonuç doğrudan nihai risk skoru olarak kullanılmamalıdır.

Politika ve Prosedürler

Doküman kurumsal beklentiyi gösterir. Güncellik ve onay bilgisi kontrol edilmelidir. Çalışanların gerçekten uygulayıp uygulamadığı örneklemle test edilir. Prosedür çok genel ise operasyonu yönlendirmeyebilir. Gerçek kontrol davranışı teknik kanıtla doğrulanır.

Ekran Görüntüleri

Ekran görüntüsü belirli ayarı hızlı kanıtlayabilir. Sistem adı ve tarih görünür olmalıdır. Gereksiz kişisel veya secret veri maskelenmelidir. Kritik bulgu mümkünse export veya log ile desteklenmelidir. Dosya isimlendirmesi standardize edilebilir.

Görüşme Notları

Görüşmeler kontrolün nasıl işletildiğini anlamayı sağlar. Katılımcı rolü ve tarih kaydedilmelidir. Tek kişinin ifadesi kritik bulgu için yeterli olmayabilir. Farklı ekiplerin görüşleri karşılaştırılabilir. Notlar teknik kanıtla ilişkilendirilmelidir.

Değişiklik Kayıtları

Change kayıtları sürecin geçmişte uygulanıp uygulanmadığını gösterir. Onay, test ve rollback bilgisi incelenebilir. Acil değişiklikler ayrı değerlendirilebilir. OT değişikliklerinde backup bağlantısı aranabilir. Örneklem yaklaşımı kullanılabilir.

İyi Audit Evidence Nasıl Olmalı?

İyi denetim kanıtı aynı sonuca bağımsız biçimde ulaşmayı mümkün kılmalıdır. Güncel, ilgili ve doğrulanabilir olması gerekir. Sistem ve tarih bağlamı bulunmalıdır. Politika ile gerçek uygulamayı karşılaştırmaya izin vermelidir. Kanıtın güvenilirliği bulgunun güvenilirliğini doğrudan etkiler.

Doğrulanabilir

Kanıt başka denetçi tarafından kontrol edilebilmelidir. Kaynağı açık olmalıdır. Teknik export veya log güçlü örneklerdir. Sadece sözlü bilgi zayıf kalabilir. Hassas veri korunarak doğrulama yapılmalıdır.

Tekrarlanabilir

Aynı kontrol tekrar test edildiğinde benzer sonuç vermelidir. Test adımı dokümante edilmelidir. Kullanılan filtre ve sorgu kaydedilebilir. Araç sürümü önemliyse belirtilmelidir. Bu özellik follow-up denetimi kolaylaştırır.

Güncel

Eski konfigürasyon mevcut durumu yansıtmayabilir. Kanıt denetim dönemine yakın olmalıdır. Policy ve network diyagramının güncellik tarihi kontrol edilmelidir. Tarihi belirsiz belge zayıf kanıt sayılabilir. Kritik bulgu mümkün olduğunca anlık doğrulanmalıdır.

İlgili Kontrolü Doğrudan Destekleyen

Kanıt incelenen kontrolle açık ilişki taşımalıdır. Genel sunum dosyası teknik ayarı kanıtlamaz. MFA coverage için gerçek kullanıcı veya policy çıktısı gerekir. Backup policy restore başarısını göstermez. Her kontrol için uygun evidence tipi belirlenmelidir.

Tarih ve Sistem Bilgisi İçeren

Kanıtın hangi sistemden ve ne zaman alındığı bilinmelidir. Özellikle ekran görüntüsünde bağlam kaybolabilir. Dosya metadata veya not eklenebilir. Varlık adı rapor bulgusuyla eşleştirilmelidir. Bu yaklaşım kanıt zincirini güçlendirir.

Politika ile Gerçek Uygulamayı Karşılaştırabilen

Politika teorik beklentiyi gösterir. Kanıt gerçek davranışı gösterir. İkisi arasında fark varsa bulgu oluşabilir. Örneğin politika üç ayda restore testi isterken son test bir yıl önce yapılmış olabilir. Denetim bu farkı açık biçimde raporlamalıdır.

Risk Puanlama Modeli Nasıl Kurulur?

Risk puanlama modeli teknik severity skorunu doğrudan kopyalamamalıdır. Olasılık, etki, varlık kritiklik, internet exposure ve exploit edilebilirlik birlikte değerlendirilebilir. Mevcut compensating control residual risk'i azaltabilir. OT ortamında fiziksel güvenlik etkisi ayrıca hesaba katılmalıdır. Model basit, anlaşılır ve tutarlı uygulanabilir olmalıdır.

Olasılık

Riskin gerçekleşme ihtimali değerlendirilir. Tehdit aktivitesi ve exposure bilgi sağlar. İnternete açık servis daha yüksek olasılık taşıyabilir. İç tehdit senaryosu ayrıca ele alınabilir. Skala açık tanımlarla desteklenmelidir.

Etki

Etki finansal, operasyonel ve hukuki boyut içerebilir. Kritik hizmet kesintisi skoru yükseltebilir. Veri kaybı ve fiziksel güvenlik ayrıca değerlendirilmelidir. Yönetim etki kriterlerinin belirlenmesine katılmalıdır. Teknik ekip tek başına iş etkisini tahmin etmemelidir.

Varlık Kritiklik Derecesi

Kritik varlık daha yüksek iş sonucu taşır. Aynı açık test sisteminde düşük, üretim sisteminde yüksek risk olabilir. Kritiklik BIA ile ilişkilendirilmelidir. Varlık owner bu sınıfı doğrulamalıdır. Envanter bu alanı güncel tutmalıdır.

Internet Exposure

Doğrudan internet erişimi saldırı fırsatını artırabilir. Public IP ve erişilebilir portlar belirlenmelidir. VPN arkasındaki servis farklı risk taşır. Geçici exposure bile kontrol edilmelidir. Exposure değişiklik süreciyle izlenebilir.

Exploit Edilebilirlik

Açığın istismar edilme kolaylığı riski etkiler. Public exploit bulunması önceliği yükseltebilir. Kimlik doğrulama gereksinimi olasılığı değiştirebilir. OT sisteminde exploit testi yapmak güvenli olmayabilir. Değerlendirme kanıt ve tehdit bilgisiyle yapılmalıdır.

Mevcut Compensating Controls

Segmentasyon veya allowlist açığın gerçek etkisini azaltabilir. Kontrolün gerçekten çalıştığı kanıtlanmalıdır. Kâğıt üzerindeki kontrol risk skorunu otomatik düşürmemelidir. Residual risk açık biçimde belirtilmelidir. Kontrol kalkarsa risk yeniden değerlendirilmelidir.

Fiziksel Güvenlik Etkisi

OT açığı fiziksel ekipman veya insan güvenliğini etkileyebilir. Safety etkisi risk skoruna ek ağırlık katabilir. Kontrol değişikliği de safety riski doğurabilir. Değerlendirme proses mühendisiyle birlikte yapılmalıdır. Kritik fiziksel etki yönetim seviyesinde ele alınmalıdır.

Risk Skoru Hesaplama

Basit olasılık çarpı etki modeli başlangıç olabilir. İlave faktörler ağırlıklandırılabilir. Model aşırı matematiksel hale getirilmemelidir. Aynı girdiler benzer sonuç üretmelidir. Yönetim skoru kolayca anlayıp öncelik kararına çevirebilmelidir.

IT Audit Bulguları Nasıl Sınıflandırılmalı?

Bulgu sınıflandırması yönetimin hangi riske önce kaynak ayıracağını anlamasını sağlamalıdır. Critical, High, Medium ve Low seviyeleri açık kriterlerle tanımlanmalıdır. Observation doğrudan risk olmayan gelişim alanlarını gösterebilir. Positive Finding iyi çalışan kontrolleri görünür hale getirir. Böylece rapor yalnızca sorun listesi değil mevcut güçlü alanları da gösteren dengeli değerlendirme olur.

Critical

Critical bulgu çok yüksek iş etkisi ve yüksek istismar ihtimali taşır. Doğrudan internete açık kritik OT cihazı örnek olabilir. Hızlı aksiyon ve yönetim eskalasyonu gerektirir. Geçici mitigation hemen uygulanabilir. Kapatma sonrası retest zorunlu tutulabilir.

High

High bulgu ciddi risk taşır ancak acil fiziksel etki seviyesi daha düşük olabilir. MFA olmayan kritik admin erişimi örnek olabilir. Kısa hedef tarih belirlenmelidir. Compensating control değerlendirilebilir. Yönetim düzenli ilerleme takibi yapmalıdır.

Medium

Medium risk daha sınırlı etki veya olasılık taşıyabilir. Yine de birikmesi kurum güvenlik seviyesini düşürebilir. Planlı iyileştirme programına alınmalıdır. Kök neden benzer diğer bulgularla ilişkilendirilebilir. Hedef tarih makul operasyon takvimine göre belirlenir.

Low

Low risk doğrudan büyük etki yaratmayabilir. Baseline uyumsuzluğu veya iyileştirme alanı olabilir. Kaynak uygun olduğunda kapatılabilir. Tekrar eden düşük riskler sistematik problem gösterebilir. Toplu çözüm maliyeti azaltabilir.

Observation

Observation açık güvenlik zafiyeti olmadan gelişim fırsatını gösterebilir. Süreç henüz risk oluşturmuyor ancak ileride sorun yaratabilir. Yönetimin dikkatine sunulur. Zorunlu closure hedefi olmayabilir. Olgunluk çalışmasında değerli girdi sağlar.

Positive Finding

İyi çalışan kontrollerin raporda görünmesi önemlidir. Ekiplerin güçlü uygulamaları kurum içinde yaygınlaştırılabilir. Positive finding denetimin yalnızca hata bulma aracı olmadığını gösterir. Yönetim doğru yatırımların sonucunu görür. Olgunluk değerlendirmesinde güçlü alanlar referans olur.

Her Denetim Bulgusunda Bulunması Gerekenler

İyi bulgu kısa ama eksiksiz olmalıdır. Etkilenen varlık, mevcut durum, teknik kanıt, risk ve iş etkisi açık biçimde yazılmalıdır. Kök neden ve düzeltici faaliyet yalnızca semptomu değil sorunun kaynağını hedeflemelidir. Owner ve hedef tarih closure sürecini takip edilebilir hale getirir. Risk sahibi teknik birimden farklı olabilir ve yönetim kararı gerektirebilir.

Bulgu Başlığı

Başlık problemi açıkça ifade etmelidir. “Firewall sorunu” yerine belirli risk yazılmalıdır. Teknik olmayan yönetici de anlam çıkarabilmelidir. Severity başlıkta ayrıca gösterilebilir. Benzer bulgular standardize isimlendirmeyle raporlanabilir.

Etkilenen Varlık

Hangi sistem veya lokasyonun etkilendiği açık olmalıdır. Çok sayıda varlık varsa liste eklenebilir. Asset ID kullanmak izlenebilirliği artırır. Scope dışı varlık yanlışlıkla eklenmemelidir. Varlık owner closure sürecine dahil edilir.

Mevcut Durum

Bulgunun gözlenen mevcut hali objektif biçimde açıklanmalıdır. Yorum ve varsayım azaltılmalıdır. Tarih ve konfigürasyon bilgisi eklenebilir. Mevcut control varsa belirtilmelidir. Okuyucu kanıtı görmeden durumu anlayabilmelidir.

Teknik Kanıt

Kanıt bulguyu doğrudan desteklemelidir. Screenshot, log veya export kullanılabilir. Hassas bilgi maskelenmelidir. Kanıt referans numarası eklenebilir. Follow-up sırasında aynı kontrol tekrar test edilebilir.

Risk

Risk teknik açığın olası sonucunu açıklar. Saldırganın ne yapabileceği veya hangi hata oluşabileceği belirtilir. Aşırı felaket senaryosu yazılmamalıdır. Olasılık mevcut koşulla uyumlu olmalıdır. Residual risk varsa ayrıca ifade edilir.

İş Etkisi

Teknik riskin hizmet veya operasyon sonucuna dönüşümü açıklanmalıdır. Kesinti, veri kaybı veya fiziksel süreç etkisi olabilir. Yönetim önceliği bu bilgiyle belirler. Varsayım varsa açıkça belirtilmelidir. İş owner ile doğrulanması faydalıdır.

Kök Neden

Kök neden yalnızca “patch yapılmamış” olmayabilir. Varlık envanterinde görünmediği için patch kapsamına girmemiş olabilir. Süreç ve yönetişim sorunu belirlenmelidir. Aynı neden başka varlıklarda benzer risk yaratabilir. Düzeltici faaliyet kök nedeni hedeflemelidir.

Önerilen Düzeltici Faaliyet

Öneri uygulanabilir ve riskle orantılı olmalıdır. Tek ürün adı vermek yerine kontrol hedefi açıklanmalıdır. Kısa ve uzun vadeli seçenekler ayrılabilir. OT ortamında operasyon güvenliği belirtilmelidir. Kurum kendi teknoloji tercihini yapabilmelidir.

Sorumlu Birim

Her aksiyon belirli owner'a atanmalıdır. “IT ekibi” gibi geniş tanım bazı durumlarda yetersiz olabilir. Network, uygulama veya iş birimi ayrımı yapılabilir. Birden fazla birim varsa lead owner belirlenir. Sorumlu birim ilerlemeyi raporlar.

Hedef Tarih

Hedef tarih risk seviyesine göre belirlenmelidir. Critical bulgu için aylarca beklemek uygun olmayabilir. Change window ve bütçe gereksinimi dikkate alınır. Geçici mitigation tarihi ayrıca eklenebilir. Geciken aksiyonlar yönetim dashboard'unda görünmelidir.

Risk Sahibi

Risk sahibi teknik düzeltmeyi yapan kişi olmak zorunda değildir. İş etkisini kabul etme yetkisine sahip yönetim rolü olabilir. Risk acceptance kararı burada verilir. Owner değişirse kayıt güncellenmelidir. Böylece açık risk sahipsiz kalmaz.

30–90–180 Günlük İyileştirme Yol Haritası

Denetim raporu yüzlerce bulgu üretip hangi sırayla ilerlenmesi gerektiğini söylemezse kurum için zor yönetilir hale gelir. İlk 30 gün internet exposure, varsayılan parola, kritik admin ve backup sorunları gibi acil risklere ayrılabilir. İlk 90 günde envanter, MFA, patch, segmentasyon ve loglama temel kurumsal kontrole dönüşür. 180 günlük dönemde PAM, SIEM, OT monitoring ve DR olgunluğu geliştirilebilir. Bu yaklaşım kurumlar için kapsamlı IT audit ve bilişim denetimi hizmeti sonrasında somut uygulama planı oluşturur.

İlk 30 Gün — Kritik Açıkları Kapatmak

İlk dönemde saldırı veya hizmet kaybı riski yüksek maddeler ele alınmalıdır. Hızlı kazanımlar bütçe beklemeden uygulanabilir. Yönetim kritik risklerin günlük veya haftalık durumunu takip edebilir. Büyük mimari değişiklik gerektiren maddeler için geçici control uygulanabilir. Her closure retest ile doğrulanmalıdır.

Internet Exposure

Gereksiz public servisler kapatılmalıdır. Kritik yönetim panelleri VPN arkasına alınabilir. Public IP envanteri güncellenmelidir. Kullanılması zorunlu servisler hardening ve monitoring kapsamına alınır. Değişiklik sonrası dışarıdan yeniden doğrulama yapılmalıdır.

Varsayılan Parolalar

Default credential bulunan cihazlar öncelikli değiştirilmelidir. Özellikle network ve OT cihazları kontrol edilmelidir. Yeni parola güvenli kasada tutulabilir. Vendor destek hesabı ayrıca değerlendirilmelidir. Procurement sürecine parola değişimi kontrolü eklenmelidir.

Kritik Yönetici Hesapları

Admin hesaplarına MFA uygulanmalıdır. Gereksiz grup üyelikleri temizlenmelidir. Shared administrator kullanımına geçiş planı hazırlanmalıdır. Admin activity loglanmalıdır. Break-glass hesap ayrıca kontrol edilmelidir.

Backup Sorunları

Başarısız backup job'lar düzeltilmelidir. Kritik sistem coverage eksikleri giderilmelidir. Offline veya immutable kopya planı oluşturulur. En az bir kritik restore testi yapılmalıdır. Sonuç yönetimle paylaşılmalıdır.

Kritik Firewall Kuralları

Any-to-any ve doğrudan IT–OT erişimleri öncelikli review edilmelidir. İş gerekçesi olmayan kurallar kapatılır. Vendor erişimi sınırlandırılır. Değişiklik kontrollü window içinde yapılır. Trafik logları sonrası etkiler doğrulanır.

İlk 90 Gün — Temel Kontrolleri Kurumsallaştırmak

İlk kritik aksiyonlar sonrasında süreç tabanı kurulmalıdır. Envanter, MFA, patch, segmentasyon ve loglama bireysel proje olmaktan çıkarılıp düzenli operasyon haline gelmelidir. Policy ve teknik uygulama birlikte güncellenir. KPI ölçümü başlatılabilir. Bu aşama tekrar eden riskleri azaltır.

Asset Inventory

Tek ve güncel envanter kaynağı belirlenmelidir. IT ve OT varlık sahipleri atanır. Otomatik keşif ve manuel doğrulama birlikte kullanılır. Yeni varlık onboarding sürecine eklenir. Coverage oranı ölçülür.

MFA

VPN, cloud ve admin erişimlerinde MFA coverage artırılır. Legacy istisnalar listelenir. Alternatif kontroller planlanır. Kullanıcı kayıt süreci standardize edilir. Dashboard coverage oranını gösterir.

Patch Management

Patch SLA'ları varlık kritikliğine göre belirlenir. EOL sistemi ayrıca raporlanır. Vulnerability sonuçları patch süreciyle entegre edilir. OT patch penceresi planlanır. Compliance metriği düzenli raporlanır.

Network Segmentation

Kullanıcı, sunucu ve OT zone'ları netleştirilir. Firewall kuralları yeni modele göre düzenlenir. DMZ ve jump host ihtiyaçları uygulanır. Network diyagramı güncellenir. Trafik monitoring ile gerçek akış doğrulanır.

Loglama

Kritik log kaynakları merkezi sisteme alınır. Saat senkronizasyonu sağlanır. Retention belirlenir. İlk önemli SIEM use case'leri uygulanır. Log coverage dashboard'a eklenir.

İlk 180 Gün — Olgunluk Seviyesini Artırmak

Temel kontroller oturduğunda daha gelişmiş güvenlik ve yönetişim uygulamalarına geçilebilir. PAM, SIEM, OT monitoring ve DR testleri bu aşamada olgunlaştırılabilir. Tedarikçi risk yönetimi kurumsal sürece bağlanır. Sürekli denetim için metrik ve otomasyon altyapısı kurulabilir. Hedef yalnızca açık kapatmak değil kontrol sürekliliği sağlamaktır.

PAM

Kritik privileged hesaplar PAM kapsamına alınabilir. Parola kasası ve session recording uygulanabilir. Yetki süre sınırlı verilebilir. Coverage ve kullanım oranı ölçülür. İstisna hesaplar ayrıca risk listesinde tutulur.

SIEM

SIEM use case'leri kurum tehdit modeline göre genişletilir. Alarm tuning yapılır. OT ve cloud kaynakları eklenebilir. Incident response süreci SIEM ile entegre edilir. Use case etkinliği düzenli test edilir.

OT Monitoring

Pasif network monitoring OT görünürlüğünü artırabilir. Asset ve protokol baseline oluşturulur. Anormal bağlantılar alarm üretir. Operasyon ekibi false positive değerlendirmesine katılır. Monitoring üretim sistemine minimum etkiyle uygulanmalıdır.

DR Testleri

Tabletop'tan teknik restore ve failover testine geçilebilir. Kritik sistemler sıra ile denenir. RTO ve RPO sonuçları ölçülür. Eksik dependency'ler düzeltilir. Yönetim sonuçları yıllık risk review'da kullanır.

Tedarikçi Yönetimi

Vendor sınıflandırma modeli oluşturulur. Kritik tedarikçiler için güvenlik assessment uygulanır. Remote access politikası standart hale gelir. Sözleşme şartları güncellenir. Offboarding kontrolü düzenli denetlenir.

Sürekli Denetim

Bazı kontroller otomatik olarak sürekli ölçülebilir. MFA coverage, patch compliance ve backup success günlük raporlanabilir. Kritik sapmalar ticket oluşturabilir. Yıllık audit bu veriyi kullanır. Böylece denetim tek dönemlik fotoğraf olmaktan çıkar.

Finding Closure Süreci

Bulgunun sistemde “kapalı” yazılması gerçek riskin kapandığını kanıtlamaz. Düzeltici faaliyet tamamlandıktan sonra closure evidence toplanmalı ve gerektiğinde retest yapılmalıdır. Kontrol başarılıysa bulgu kapatılır. Kurum düzeltmemeyi seçerse yetkili risk sahibi tarafından risk acceptance verilmelidir. Tekrar eden bulgular kök neden ve yönetişim açısından ayrıca değerlendirilmelidir.

Düzeltici Faaliyetin Tamamlanması

Sorumlu ekip aksiyonu uyguladığını kaydetmelidir. Yapılan değişiklik change record ile ilişkilendirilebilir. Operasyon etkisi doğrulanmalıdır. Teknik doküman gerekiyorsa güncellenmelidir. Sadece planlama closure sayılmamalıdır.

Closure Evidence

Yeni konfigürasyon, log veya test sonucu kanıt olarak sunulabilir. Kanıt bulgunun önerilen kontrolünü doğrudan göstermelidir. Tarih ve sistem bilgisi bulunmalıdır. Hassas veri korunmalıdır. Denetçi evidence kalitesini değerlendirir.

Retest

Kritik ve high bulgular yeniden test edilmelidir. İlk test adımı mümkün olduğunca tekrarlanır. Sonuç artık riskin bulunmadığını göstermelidir. Yeni kontrol başka problemi oluşturmuş mu kontrol edilir. Retest sonucu kayıt altına alınır.

Başarılı Kapatma

Bulgu ancak risk hedeflenen seviyeye indiğinde kapanır. Closure tarihi kaydedilir. Owner ve evidence referansı sistemde tutulur. Dashboard closure oranını günceller. Öğrenilen ders gerekiyorsa standart sürece eklenir.

Risk Acceptance

Bazı riskler teknik veya ekonomik nedenle kapatılamayabilir. Yetkili risk sahibi kalan riski açıkça kabul etmelidir. Gerekçe ve süre sınırı yazılmalıdır. Kalıcı acceptance yerine review tarihi belirlenebilir. Koşullar değişirse risk yeniden değerlendirilir.

Exception Süreci

Politika veya baseline istisnası kontrollü süreçle verilmelidir. Sistem, gerekçe ve risk açıkça belirtilir. Compensating control eklenebilir. İstisna süresi sınırlı olmalıdır. Süre sonunda yeniden onay veya closure yapılır.

Tekrar Eden Bulguların Takibi

Aynı bulgu her denetimde geri dönüyorsa lokal düzeltme yetersizdir. Kök neden süreç veya sorumluluk eksikliği olabilir. Yönetim seviyesi aksiyon gerekebilir. Tekrar oranı dashboard metriği yapılabilir. Kalıcı kontrol tasarımı yeniden ele alınmalıdır.

IT Audit Olgunluk Modeli

Olgunluk modeli kurumun yalnızca mevcut açıklarını değil kontrol süreçlerinin gelişim seviyesini gösterir. Seviye 0 kontrolün bulunmadığı, Seviye 1 olay sonrası reaksiyon verilen yapıyı temsil edebilir. Daha üst seviyelerde süreçler tanımlanır, ölçülür ve sürekli iyileştirilir. Hedef bütün alanları aynı anda Seviye 5 yapmak değildir. Kritik risk alanlarında kuruma uygun hedef seviye belirlenmelidir.

Seviye 0 — Kontrol Yok

Süreç ve kontrol tanımlı değildir. Faaliyet kişisel bilgiye bağlı olabilir. Envanter ve sorumluluk görünürlüğü düşüktür. Olaylar sürpriz olarak yaşanır. İlk hedef temel sahiplik ve minimum kontrol oluşturmaktır.

Seviye 1 — Reaktif

Kontroller genellikle olay sonrası uygulanır. Bazı ekiplerin iyi uygulamaları olabilir ancak standardize değildir. Bilgi kişilere bağlıdır. Dokümantasyon sınırlıdır. Kurum tekrar eden olaylardan sistematik öğrenemeyebilir.

Seviye 2 — Temel Kontroller

Envanter, patch ve backup gibi temel süreçler bulunmaktadır. Coverage henüz tam olmayabilir. Roller kısmen tanımlıdır. Teknik kontroller belli sistemlerde uygulanır. Hedef kurumsal standardizasyonu artırmaktır.

Seviye 3 — Tanımlı Süreçler

Politika ve prosedürler kurum genelinde tanımlıdır. Roller ve sorumluluklar açıktır. Kontroller düzenli uygulanır. İstisnalar kayıt altına alınır. Denetim kanıtı tutarlı biçimde üretilebilir.

Seviye 4 — Ölçülen ve Yönetilen

KPI'lar kontrol etkinliğini gösterir. MFA coverage ve patch compliance örnek metriktir. Yönetim risk trendini düzenli görür. Sapmalar otomatik veya manuel eskale edilir. Veri iyileştirme kararında kullanılır.

Seviye 5 — Sürekli İyileştirilen

Kontroller tehdit ve iş değişimine göre düzenli geliştirilir. Otomasyon ve sürekli monitoring kullanılır. Tatbikat ve audit sonuçları sürece hızlı yansıtılır. Kök neden analizleri tekrar riskini azaltır. Güvenlik kurumsal karar sisteminin doğal parçası olur.

Yönetim İçin IT Audit Dashboard

Yönetim dashboard'u teknik log ekranına dönüşmemelidir. Toplam bulgu, kritik risk, closure oranı, patch, MFA, backup ve OT visibility gibi göstergeler karar seviyesinde sunulmalıdır. Trend bilgisi tek dönem rakamından daha değerlidir. Tekrar eden bulgular kontrol sisteminin kalitesini gösterir. Dashboard yönetimin hangi alana kaynak ve karar gerektiğini hızlı biçimde anlamasını sağlamalıdır.

Toplam Bulgu Sayısı

Toplam sayı genel hacmi gösterir ancak tek başına risk seviyesi değildir. Yüz düşük bulgu bir critical bulgudan daha az önemli olabilir. Severity dağılımı yanında gösterilmelidir. Yeni ve eski bulgular ayrılabilir. Trend süreç kalitesini anlamayı kolaylaştırır.

Critical ve High Risk Sayısı

Yönetim öncelikle yüksek riskleri görmelidir. Açık ve gecikmiş critical bulgular ayrı gösterilebilir. Hedef kapanma süresi ölçülmelidir. Risk acceptance verilen maddeler ayrıca işaretlenir. Bu gösterge yönetim aksiyonuna doğrudan bağlanabilir.

Kapatılan Bulgu Oranı

Closure oranı remediation ilerlemesini gösterir. Severity bazında ayrı hesaplanmalıdır. Sadece kolay düşük riskleri kapatmak oranı yükseltebilir. Critical closure daha yüksek ağırlıkla yorumlanabilir. Retest edilmiş closure ayrı gösterilebilir.

Ortalama Kapatma Süresi

Bulgunun açılışından doğrulanmış closure'a kadar süre ölçülebilir. Severity bazında hedef oluşturulabilir. Gecikme nedenleri sınıflandırılmalıdır. Procurement veya vendor bağımlılığı ayrıca görülebilir. Trend süreç verimliliğini gösterir.

Patch Compliance

Desteklenen sistemlerin patch SLA uyum oranı ölçülür. Kritik patch ve genel patch ayrı olabilir. EOL cihazlar bu oranı yanıltmamalıdır. İşletim sistemi ve uygulama sınıfı ayrılabilir. Hedef değer risk profiline göre belirlenir.

MFA Coverage

Toplam kullanıcı ve kritik erişimlerin ne kadarında MFA aktif olduğu gösterilir. Admin, VPN ve cloud ayrı kategoriler olabilir. İstisnalar listelenir. Coverage artışı zaman içinde izlenir. Teknik olarak aktif olsa bile bypass yolları ayrıca denetlenmelidir.

Asset Inventory Coverage

Keşfedilen varlıkların ne kadarının envanterde tanımlı olduğu ölçülebilir. Sahip ve kritiklik bilgisi eksik kayıtlar ayrıca görülebilir. OT coverage bağımsız gösterilebilir. Yeni unknown asset sayısı risk sinyalidir. Yüksek coverage diğer güvenlik kontrollerinin temelidir.

Backup Success Rate

Başarılı job oranı günlük operasyon sağlığını gösterir. Kritik sistemler ayrı hesaplanmalıdır. Tekrarlayan hata oranı ayrıca görünmelidir. Coverage eksikleri bu metrikten ayrı tutulmalıdır. Restore başarısı olmadan tam güvence sağlamaz.

Restore Test Başarı Oranı

Planlanan restore testlerinin ne kadarının başarıyla tamamlandığı ölçülebilir. RTO hedefini karşılayan test oranı daha güçlü metriktir. Başarısızlık nedenleri sınıflandırılır. Kritik sistem coverage görünür olur. Bu metrik gerçek recovery kapasitesini gösterir.

OT Visibility

OT ağındaki varlıkların ne kadarının bilindiği ve izlendiği ölçülebilir. Pasif monitoring coverage gösterilebilir. Unknown cihaz sayısı ayrıca izlenir. Kritik PLC ve SCADA için yüzde yüz görünürlük hedeflenebilir. Visibility segmentasyon ve olay müdahale kalitesini etkiler.

Tekrar Eden Bulgular

Önceki denetimden tekrar açılan bulgu sayısı izlenmelidir. Yüksek oran kök neden çözülmediğini gösterir. Policy veya sahiplik eksikliği olabilir. Yönetim sistematik aksiyon başlatabilir. Sürekli denetim olgunluğunu ölçmek için güçlü göstergedir.

Denetim Otomasyonu ve Açık Kaynak Araçlar

Denetim otomasyonu varlık, konfigürasyon ve log verisini daha hızlı toplamayı sağlayabilir. Ancak araç çıktısı tek başına denetim sonucu değildir. Asset discovery, vulnerability ve network monitoring araçları teknik kanıt üretirken insan değerlendirmesi risk bağlamını oluşturur. Açık kaynak araçlar maliyet ve özelleştirme avantajı sunabilir. Bunun yanında bakım, güvenlik ve yanlış yapılandırma riskleri ayrıca yönetilmelidir.

Asset Discovery

Otomatik keşif IT ortamında cihaz görünürlüğünü artırır. Agent veya network tabanlı yöntem kullanılabilir. Sonuç mevcut envanterle karşılaştırılır. OT için pasif discovery tercih edilebilir. Bulunan varlığın sahibi manuel olarak doğrulanmalıdır.

Configuration Assessment

Sistem ayarları baseline ile otomatik karşılaştırılabilir. Windows, Linux veya cloud politikaları kontrol edilebilir. Sapmalar bulgu adayı oluşturur. İş gereksinimine bağlı istisnalar manuel değerlendirilmelidir. Otomasyon tekrarlanabilir audit evidence üretir.

Vulnerability Management

Tarama sonuçları merkezi risk listesine aktarılabilir. Asset owner ve kritiklik verisi eklenebilir. SLA takibi otomatikleştirilebilir. False positive doğrulaması insan kontrolü gerektirir. OT aktif tarama özel izinle yapılmalıdır.

Log Analysis

Büyük log hacmi otomasyon olmadan incelenemez. SIEM ve sorgu araçları anomali veya belirli kontrol olaylarını bulabilir. Denetçi örnek user ve tarih aralığıyla doğrulama yapabilir. Script tekrarlanabilir analiz sağlar. Sonuç kontrol bağlamıyla yorumlanmalıdır.

Network Monitoring

Trafik akışları segmentasyonun gerçek durumunu gösterebilir. Beklenmeyen IT–OT bağlantıları tespit edilebilir. Pasif network izleme OT için uygundur. Baseline ve anomaly yaklaşımı kullanılabilir. Monitoring sonucu firewall ve envanter verisiyle ilişkilendirilmelidir.

Open Source Araçların Avantajları

Açık kaynak araçlar maliyet ve özelleştirme esnekliği sağlayabilir. Kaynak kodun incelenebilmesi güvenlik değerlendirmesini kolaylaştırabilir. Yerel ekip kendi entegrasyonunu geliştirebilir. Vendor bağımlılığı azalabilir. Topluluk sağlığı ve bakım düzeni yine değerlendirilmelidir.

Open Source Araçların Riskleri

Her açık kaynak proje aktif bakım almıyor olabilir. Güvenlik açığı veya dependency sorunu oluşabilir. Yanlış konfigürasyon risk yaratabilir. Kurum update ve support sorumluluğunu üstlenmelidir. Kritik kullanımda proje sürekliliği ve teknik kapasite değerlendirilmelidir.

Araç Çıktısının Tek Başına Audit Evidence Sayılmaması

Scanner sonucu sistemin iş bağlamını bilmez. False positive ve yanlış öncelik oluşabilir. Denetçi çıktıyı asset ve control bilgisiyle doğrulamalıdır. Araç test yönteminin sadece bir parçasıdır. Nihai bulgu insan değerlendirmesi ve doğrulanabilir kanıtla oluşturulmalıdır.

IT Audit Otomasyonunda Hangi Teknik Yetkinlikler Kullanılır?

IT Audit otomasyonu tek programlama diline bağlı değildir. Python veri işleme ve API entegrasyonunda, PowerShell Windows ortamında, Bash Linux sistemlerinde güçlü olabilir. SQL raporlama ve veri doğrulama için sık kullanılır. Network ve log analizi teknik dil bilgisinden daha temel yetkinlikler olabilir. Tek bir “en iyi programlama dili” yerine kullanım amacına uygun araç seçmek daha sağlıklı yaklaşımdır.

Python

Python API ve log işleme için geniş kütüphane desteği sunar. Asset verileri birleştirilebilir. Basit compliance kontrol script'leri yazılabilir. Raporlama otomasyonu yapılabilir. Kod güvenli ve versiyon kontrollü tutulmalıdır.

PowerShell

Windows ve Active Directory denetiminde PowerShell güçlü araçtır. Grup üyelikleri ve policy bilgisi alınabilir. Microsoft servisleriyle otomasyon kolaydır. Script execution güvenlik politikasıyla kontrol edilmelidir. Çıktı tarih ve sistem bilgisiyle saklanabilir.

Bash

Linux sistemlerinde hızlı kontrol ve veri toplama sağlar. Dosya izinları, servis ve log sorguları otomatikleştirilebilir. Script küçük ve anlaşılır tutulmalıdır. Root yetkisi gerektiren işlemler sınırlandırılmalıdır. Denetim ortamında değişiklik yapmayan read-only komutlar tercih edilmelidir.

SQL

Yetki ve uygulama verileri veritabanından analiz edilebilir. Denetçi read-only hesap kullanmalıdır. Sorgular tekrar edilebilir biçimde saklanabilir. Büyük kullanıcı listelerinde tutarsızlık bulunabilir. Hassas veri gereksiz çekilmemelidir.

API Kullanımı

Cloud ve güvenlik ürünleri API üzerinden veri sağlayabilir. Envanter, MFA coverage veya alarm bilgisi otomatik çekilebilir. Token'lar güvenli saklanmalıdır. Rate limit ve yetki kapsamı dikkate alınır. API sonucu insan değerlendirmesiyle yorumlanmalıdır.

Log Analizi

Regex, sorgu dili ve SIEM bilgisi denetimi hızlandırır. Admin işlemleri veya başarısız girişler filtrelenebilir. Zaman aralığı açıkça belirtilmelidir. Normal davranış bilinmeden anomali yorumu yapılmamalıdır. Sonuç evidence formatında saklanabilir.

Network Temelleri

IP, subnet, routing, VLAN ve firewall bilgisi IT Audit için temeldir. Özellikle IT–OT segmentation değerlendirmesi bu bilgiyi gerektirir. Protokol davranışı anlaşılmalıdır. Packet capture dikkatle kullanılmalıdır. Network bilgisi olmadan scanner çıktısı kolayca yanlış yorumlanabilir.

Tek Bir “En İyi Programlama Dili” Yerine Kullanım Amacına Göre Seçim

Windows ağırlıklı audit PowerShell gerektirebilir. Veri işleme Python ile daha hızlı olabilir. Linux kontrolü Bash ile sade çözülebilir. Her şeyi tek dile taşımak gereksizdir. Denetçi problemi ve güvenlik sınırını anlayarak uygun aracı seçmelidir.

IT Audit veya OT Security Uzmanı Olmak İçin Ne Yapmalı?

IT Audit ve OT Security uzmanlığı yalnızca sertifika ezberlemekle gelişmez. Network, sistem yönetimi, güvenlik, risk, log ve kimlik alanlarında güçlü temel gerekir. OT tarafında SCADA ve PLC çalışma mantığı ayrıca öğrenilmelidir. ISO 27001, COBIT ve ISA/IEC 62443 gibi çerçeveler kontrol bakışını destekler. Gerçek veya kontrollü laboratuvar senaryolarında pratik yapmak teorik bilgiyi denetim yetkinliğine dönüştürür.

Network Temellerini Öğrenmek

Routing, switching ve firewall mantığı anlaşılmalıdır. VLAN ve subnet tasarımı bilinmelidir. TCP/IP protokolleri saldırı ve kontrol değerlendirmesini destekler. Packet capture temel seviyede yorumlanabilmelidir. OT protokollerine geçmeden önce klasik network temeli güçlendirilmelidir.

Windows ve Linux Sistem Yönetimi

Denetçi sistem ayarını anlayabilmelidir. Kullanıcı, servis, log ve patch yönetimi temel alanlardır. Windows Group Policy ve Linux permission modeli öğrenilmelidir. Backup ve recovery pratiği yapılabilir. Yönetim bilgisi denetim bulgusunun uygulanabilir olmasını sağlar.

Bilgi Güvenliği Temelleri

Gizlilik, bütünlük ve kullanılabilirlik temel kavramlardır. Authentication, authorization ve cryptography anlaşılmalıdır. Threat ve vulnerability farkı bilinmelidir. Defense-in-depth yaklaşımı öğrenilmelidir. Teknik açık iş etkisine bağlanabilmelidir.

Risk ve Kontrol Mantığı

Her açık otomatik yüksek risk değildir. Olasılık ve etki değerlendirmesi yapılmalıdır. Preventive, detective ve corrective control farkı anlaşılmalıdır. Residual risk kavramı önemlidir. Denetim dili teknik problemden yönetim kararına geçebilmelidir.

Log Analizi

Windows, Linux, firewall ve uygulama logları okunmalıdır. Olay zaman çizelgesi kurulabilmelidir. SIEM sorguları faydalıdır. Timestamp ve time zone farkları bilinmelidir. Logun neyi kanıtlamadığı da anlaşılmalıdır.

Active Directory

AD kurumsal kimlik yönetiminin merkezinde olabilir. Group, OU, GPO ve privileged role kavramları öğrenilmelidir. Kerberos ve authentication temel seviyede anlaşılmalıdır. Güven ilişkileri ve service account riskleri önemlidir. Audit script'leri kontrollü laboratuvarda denenebilir.

SCADA ve PLC Temelleri

OT uzmanı fiziksel proses mantığını anlamalıdır. PLC programı ve HMI iletişimi temel seviyede bilinmelidir. Modbus ve OPC UA gibi protokoller öğrenilebilir. Safety ve kullanılabilirlik önceliği unutulmamalıdır. Aktif testlerin riski teoriden önce anlaşılmalıdır.

ISO 27001 ve COBIT

Bu çerçeveler kontrol ve yönetişim düşüncesini geliştirir. Madde ezberlemek yerine neden uygulandığını anlamak önemlidir. Risk assessment ve audit evidence kavramları çalışılmalıdır. Kurum bağlamına uyarlama yapılmalıdır. Teknik kontrolün yönetişim bağlantısı görülür.

ISA/IEC 62443

Zone, conduit ve security level kavramları OT güvenliği için değerlidir. Asset owner ve service provider sorumlulukları anlaşılmalıdır. Yaşam döngüsü yaklaşımı öğrenilmelidir. Laboratuvar topolojisiyle uygulama yapılabilir. Standardın güncel ve lisanslı içeriği uygun kanaldan kullanılmalıdır.

Gerçek Denetim Senaryolarıyla Pratik Yapmak

Kontrollü lab ortamı ideal başlangıçtır. Örnek firewall, AD ve OT segmentasyonu incelenebilir. Kanıt toplama ve rapor yazma pratiği yapılmalıdır. Teknik bulgu iş etkisine çevrilmelidir. Mentor geri bildirimi öğrenme hızını artırır.

Diyarbakır'da Yerel IT Audit Yetkinliği Nasıl Geliştirilebilir?

Diyarbakır'da yerel IT Audit yetkinliği üniversite, kurum, özel sektör ve yazılım topluluklarının ortak programlarıyla geliştirilebilir. Kontrollü IT ve OT laboratuvarları öğrencilere güvenli denetim pratiği sunabilir. Yerel kurumlarla pilot denetimler gerçek saha ihtiyacını eğitim programına taşır. Mentor havuzu teknik ve raporlama deneyimini aktarabilir. Diyarbakır Yazılım Topluluğu gibi yapılar çalışma grubu ve açık teknik içeriklerle bu ekosistemin koordinasyonuna katkı sağlayabilir.

Üniversite–Kurum–Topluluk İşbirliği

Üniversite teorik ve akademik altyapı sağlayabilir. Kurumlar anonim senaryo ve gerçek problem sunabilir. Topluluk teknik mentor ve proje koordinasyonu sağlayabilir. Ortak laboratuvar öğrenmeyi uygulamalı hale getirir. İş birliği tek etkinlik yerine dönemsel programa dönüştürülmelidir.

Siber Güvenlik Çalışma Grupları

Network, cloud, AD ve OT odaklı alt gruplar kurulabilir. Katılımcılar belirli senaryolar üzerinde çalışabilir. Öğrenilen dersler ortak dokümana dönüştürülebilir. Yerel kurumlar ihtiyaçlarını gruba aktarabilir. Düzenli teknik oturumlar yetkinliği sürdürülebilir kılar.

IT Audit Laboratuvarları

Sanallaştırılmış Windows ve Linux ortamları kurulabilir. Active Directory, firewall ve SIEM senaryoları uygulanabilir. Katılımcılar kanıt toplayıp rapor hazırlayabilir. Hata yapmak gerçek sisteme zarar vermez. Eğitim doğrudan denetim pratiğine dönüşür.

OT/SCADA Test Ortamları

PLC simülatörü ve HMI ile küçük OT lab kurulabilir. Network segmentation ve jump host senaryoları denenebilir. Pasif monitoring araçları kullanılabilir. Aktif testin güvenli sınırları öğretilir. Safety bakışı teknik eğitime dahil edilir.

Yerel Kurumlarla Pilot Denetimler

Kapsamı sınırlı gönüllü audit programları uygulanabilir. Örneğin yalnızca asset ve backup kontrolü seçilebilir. Mentor gözetiminde ekipler kanıt toplar. Kurum somut iyileştirme raporu alır. Katılımcılar gerçek iletişim ve raporlama deneyimi kazanır.

Mentor Havuzu

Sistem, network, güvenlik ve denetim deneyimine sahip kişiler mentor olabilir. Mentor yalnızca teknik çözüm vermemelidir. Kanıt ve risk düşüncesini öğretmelidir. Genç uzman rapor yazma pratiği yapar. Program sonunda yeni mentorlar yetiştirilebilir.

Üniversite Öğrencilerinin Denetim Projelerine Katılması

Öğrenciler anonim veya laboratuvar verileriyle audit projesi yapabilir. Bitirme projeleri asset discovery veya log analizi üzerine kurulabilir. Gerçek kurum verisi kullanılıyorsa gizlilik kuralları açık olmalıdır. Mentor gözetimi şarttır. Başarılı çalışmalar staj ve istihdam fırsatına dönüşebilir.

Diyarbakır Yazılım Topluluğunda IT Audit Çalışma Grubu

Diyarbakır Yazılım Topluluğu bünyesinde gönüllü teknik çalışma grubu oluşturulabilir. Network, sistem, cloud ve OT başlıkları ayrı oturumlarda ele alınabilir. Topluluk projelerine https://www.diyarbakiryazilim.com.tr/projects adresinden ulaşılabilir. Topluluk yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about sayfası incelenebilir. Yerel uzmanların düzenli teknik üretimi bölgedeki denetim kapasitesini zaman içinde güçlendirebilir.

Yerel Uzman ve Yazılımcılar Nasıl Değerlendirilmeli?

IT Audit uzmanını yalnızca sertifika sayısıyla değerlendirmek doğru değildir. Network, sistem, otomasyon, kanıt toplama ve raporlama yetkinliği birlikte görülmelidir. OT ortamında güvenli çalışma bilinci özellikle önemlidir. Etik ve bağımsızlık denetimin güvenilirliğini doğrudan etkiler. Uygulamalı senaryo ve örnek rapor, kişinin gerçek yetkinliğini anlamak için güçlü yöntemdir.

Sertifika Yerine Uygulamalı Yetkinlik

Sertifika temel bilgi kanıtı olabilir. Ancak sistem üzerinde nasıl kanıt toplandığını tek başına göstermez. Adaya örnek denetim senaryosu verilebilir. Risk ve öneri yazması istenebilir. Gerçek düşünme süreci daha görünür hale gelir.

Network Bilgisi

Subnet, VLAN ve firewall anlaşılmadan network audit yapmak zordur. Aday topoloji okuyabilmelidir. Basit packet flow açıklayabilmelidir. IT–OT segmentasyon senaryosunu değerlendirebilmelidir. Teknik bilgi araç kullanımından daha temel önemdedir.

Sistem Yönetimi Bilgisi

Windows ve Linux servisleri anlaşılmalıdır. Patch, account ve log yapılandırması incelenebilmelidir. Sistem değişikliğinin operasyon etkisi bilinmelidir. Backup ve recovery bilgisi önemlidir. Denetçi uygulanamayacak öneri yazmamalıdır.

Kodlama ve Otomasyon Yeteneği

Script yazabilmek büyük veri setlerinde denetimi hızlandırır. Python, PowerShell veya Bash kullanılabilir. Kod read-only ve güvenli çalışmalıdır. Sonuç tekrar üretilebilir olmalıdır. Otomasyon insan değerlendirmesinin yerine geçmemelidir.

Denetim Kanıtı Toplama Yetkinliği

Aday hangi kanıtın hangi kontrolü doğruladığını bilmeli. Screenshot ile export arasındaki farkı anlamalıdır. Kanıt tarih ve sistem bilgisi içermelidir. Hassas veri koruma bilinci gerekir. Evidence zinciri düzenli tutulmalıdır.

Raporlama Becerisi

Teknik bulgu yönetim diline çevrilebilmelidir. Risk ve iş etkisi açık yazılmalıdır. Gereksiz jargon azaltılmalıdır. Öneri uygulanabilir olmalıdır. Executive summary teknik rapordan farklı seviyede hazırlanmalıdır.

OT Ortamında Güvenli Çalışma Bilinci

OT sisteminde agresif taramanın riskini bilmek gerekir. Production değişikliği denetçi işi olmamalıdır. Safety ve proses owner ile koordinasyon şarttır. Pasif yöntemler tercih edilebilir. Denetçi “test edebiliyorum” ile “test etmek güvenli” arasındaki farkı anlamalıdır.

Etik ve Bağımsızlık

Denetçi eriştiği hassas bilgiyi korumalıdır. Bulgu sonucunu ticari ürün satışı için yönlendirmemelidir. Çıkar çatışması açıklanmalıdır. Kanıt olmadan iddia yazılmamalıdır. Güvenilir audit için etik teknik yetkinlik kadar önemlidir.

Yerel Kurumlar Arasında Siber Güvenlik İşbirliği

Yerel kurumlar benzer tehditlerle karşılaşabilir fakat çoğu zaman ayrı ayrı öğrenir. Ortak tehdit bilgisi, eğitim ve tabletop çalışmaları bölgesel dayanıklılığı artırabilir. Üniversite ve topluluklar laboratuvar ve yetkinlik katkısı sunabilir. Açık kaynak araçlar ortak ihtiyaçlara göre geliştirilebilir. Yerel siber güvenlik yetkinlik havuzu kritik olaylarda kurumların uygun uzmana daha hızlı ulaşmasını sağlayabilir.

Ortak Tehdit Bilgisi Paylaşımı

Şüpheli IP, phishing kampanyası veya kullanılan zararlı örnekleri kontrollü biçimde paylaşılabilir. Hassas kurum bilgileri anonimleştirilmelidir. Paylaşım formatı standardize edilebilir. Doğrulanmamış bilgi yayılmamalıdır. Ortak tehdit resmi hazırlık süresini azaltır.

Ortak Eğitim Programları

Kurumların ayrı ayrı aynı eğitimi satın alması yerine ortak program düzenlenebilir. Network, incident response ve OT gibi konular ele alınabilir. Gerçek yerel senaryolar kullanılabilir. Katılımcı kurumlar kendi deneyimlerini paylaşır. Eğitim maliyeti ve bilgi transferi açısından avantaj sağlar.

Incident Response Tatbikatları

Birden fazla kurum ortak ransomware veya altyapı kesintisi senaryosu çalışabilir. İletişim ve dış destek akışı test edilir. Hangi kurumun hangi teknik kapasiteye sahip olduğu görülür. Tatbikat sonrası ortak iyileştirme listesi çıkarılır. Bölgesel kriz koordinasyonu güçlenir.

Ortak Teknik Laboratuvar

IT ve OT güvenlik laboratuvarı birden fazla kurum tarafından kullanılabilir. Eğitim ve test için güvenli ortam sağlar. Üniversite öğrencileri programa dahil edilebilir. Yeni güvenlik kontrolü production öncesi denenebilir. Ortak yatırım teknik kapasiteyi büyütür.

Üniversite ve Topluluk Katılımı

Akademisyenler araştırma ve metodoloji desteği sağlayabilir. Topluluk gönüllü teknik üretim ve mentorluk sunabilir. Kurumlar gerçek ihtiyaçları tanımlar. Ortak projeler açık kaynak veya eğitim çıktısına dönüşebilir. Yerel yetenek kurumlarla daha erken temas eder.

Açık Kaynak Araçların Ortak Geliştirilmesi

Basit asset inventory veya audit reporting aracı ortak geliştirilebilir. Her kurum kendi verisini ayrı tutabilir. Ortak kod bakım maliyetini paylaşır. Güvenlik review süreci oluşturulmalıdır. Yerel geliştiriciler gerçek kullanım senaryosunda deneyim kazanır.

Yerel Siber Güvenlik Yetkinlik Havuzu

Network, sistem, OT ve forensic uzmanlıkları ayrı kategoride tutulabilir. Kişilerin gerçek proje deneyimi kayıt altına alınabilir. Acil olayda uygun uzman daha hızlı bulunur. Havuz kamuya açık hassas bilgi içermemelidir. Mentorluk ve eğitim planları bu haritadan üretilebilir.

Yıllık IT Audit Programı Nasıl Oluşturulur?

Yıllık program tüm kontrolleri tek ayda test etmeye çalışmak yerine risk alanlarını dönemlere bölebilir. İlk çeyrek asset ve risk, ikinci çeyrek identity ve network, üçüncü çeyrek OT ve süreklilik, son çeyrek follow-up için kullanılabilir. Kritik değişiklik veya siber olay sonrasında ek audit yapılabilir. Program yönetim kurulu tarafından risk iştahıyla uyumlu onaylanmalıdır. Sürekli KPI verileri yıllık denetimin girdi kalitesini artırır.

Q1 — Asset ve Risk Audit

Yılın başında envanter ve BIA güncellenebilir. Kritiklik sınıfları kontrol edilir. Shadow IT keşfi yapılabilir. Risk register yenilenir. Yıllık audit planı bu veriye göre ayarlanır.

Q2 — Identity, Network ve Vulnerability Audit

Admin hesapları ve MFA coverage incelenir. Firewall ve segmentation test edilir. Vulnerability ve patch sonuçları değerlendirilir. Internet exposure güncellenir. Önceki bulguların closure durumu kontrol edilir.

Q3 — OT, Vendor ve Business Continuity Audit

OT envanteri ve remote access incelenir. Vendor sözleşme ve erişimleri kontrol edilir. Backup restore ve DR testleri yapılabilir. OT segmentation ve monitoring değerlendirilir. Safety etkisi ilgili ekiplerle birlikte ele alınır.

Q4 — Follow-Up ve Olgunluk Değerlendirmesi

Yıl boyunca açılan bulgular yeniden test edilir. Maturity score güncellenir. Tekrar eden riskler analiz edilir. KPI trendleri yönetimle paylaşılır. Sonraki yıl yatırım ve audit planı hazırlanır.

Kritik Değişiklik Sonrası Ek Denetimler

Yeni veri merkezi, cloud geçişi veya büyük OT projesi yeni risk oluşturabilir. Yıllık takvimi beklemek doğru olmayabilir. Değişiklik sonrası targeted audit yapılabilir. Scope yalnızca değişen alanla sınırlandırılabilir. Sonuç risk register'a eklenir.

Siber Olay Sonrası Özel Denetim

Ciddi olay sistemik kontrol zayıflığını gösterebilir. Root cause ve kontrol etkinliği tekrar değerlendirilmelidir. Olay sırasında görünmeyen varlık veya log eksikleri ortaya çıkabilir. Özel audit lessons learned sürecini doğrular. Aynı saldırının tekrar ihtimali azaltılır.

Yerel Kurumlar İçin Örnek IT Audit Kontrol Listesi

Kontrol listesi denetimin hatırlatma aracıdır, nihai amacı değildir. Yönetim, asset, network, identity, endpoint, server, application, database, backup ve OT alanları birlikte değerlendirilebilir. Her kontrol için evidence ve risk kriteri tanımlanmalıdır. Kurumun boyutuna göre bazı başlıklar daha derin incelenebilir. Risk tabanlı yaklaşım kontrol listesinin mekanik kullanılmasını önler.

Yönetim ve Yönetişim

Politika, rol ve risk sahipliği kontrol edilir. Yönetimin güvenlik performansını ne sıklıkla gördüğü incelenir. Bütçe ve aksiyon süreçleri değerlendirilir. İstisna ve risk kabul modeli bulunmalıdır. Audit sonuçları yönetim kararına dönüşmelidir.

Asset Management

Donanım, yazılım ve OT varlıkları güncel mi kontrol edilir. Owner ve kritiklik bilgisi bulunmalıdır. Shadow IT süreci değerlendirilir. EOL varlıklar listelenir. Yeni varlık onboarding süreci doğrulanır.

Network

Topoloji, VLAN ve firewall kuralları incelenir. Internet exposure doğrulanır. IT–OT segmentation değerlendirilir. Yönetim protokolleri kontrol edilir. Wireless güvenliği kapsama alınır.

Identity

AD, kullanıcı ve admin hesapları incelenir. MFA coverage ölçülür. Eski çalışan hesapları test edilir. Shared ve service account'lar kontrol edilir. Joiner, mover ve leaver süreci doğrulanır.

Endpoint

EDR, patch ve disk şifreleme coverage kontrol edilir. Local admin yetkileri incelenir. USB ve application control değerlendirilebilir. Kayıp cihaz süreci bulunmalıdır. Envanterle agent coverage karşılaştırılır.

Server

OS güncelliği ve hardening değerlendirilir. EOL sunucular listelenir. Admin erişimi incelenir. Backup ve monitoring kontrol edilir. Güvenli baseline sapmaları belirlenir.

Application

Kimlik, yetki ve loglama incelenir. Güvenli development süreci değerlendirilir. Vendor erişimi kontrol edilir. API ve secret yönetimi test edilir. Production change süreci gözden geçirilir.

Database

DBA ve uygulama hesap yetkileri incelenir. Şifreleme ve backup kontrol edilir. Audit log etkinliği doğrulanır. Direct access minimum tutulmalıdır. Kritik veri sınıflandırmasıyla eşleştirilir.

Backup

Coverage, başarı ve restore testleri incelenir. Offline veya immutable kopya kontrol edilir. Yetkiler değerlendirilir. Şifreleme ve off-site yapı gözden geçirilir. RTO ve RPO ile uyum ölçülür.

Business Continuity

BIA ve kritik sistem listesi güncel mi kontrol edilir. DR planı ve alternatif iletişim incelenir. Tatbikat sonuçları doğrulanır. RTO ve RPO gerçek testle karşılaştırılır. Ransomware senaryosu ayrıca değerlendirilir.

Logging

Kritik log kaynakları merkezi sisteme geliyor mu kontrol edilir. Zaman senkronizasyonu test edilir. Retention ve bütünlük değerlendirilir. SIEM alarm use case'leri incelenir. OT log coverage ayrıca ölçülür.

Incident Response

Plan, roller ve eskalasyon incelenir. Playbook'lar güncel olmalıdır. Tatbikat kanıtı istenir. Delil koruma prosedürü değerlendirilir. Olay sonrası lessons learned süreci kontrol edilir.

Cloud

Cloud asset ve admin hesapları incelenir. MFA ve loglama kontrol edilir. Public exposure değerlendirilir. Backup ve veri saklama seçenekleri test edilir. Shadow SaaS araştırılır.

Vendor

Kritik vendor listesi ve risk sınıfı bulunmalıdır. Sözleşme güvenlik maddeleri incelenir. Remote access ve MFA kontrol edilir. Offboarding süreci test edilir. Vendor logları saklanmalıdır.

Physical Security

Server room ve network odası erişimleri değerlendirilir. UPS, jeneratör ve klima kontrolleri test edilir. Yangın koruması incelenir. Ziyaretçi ve kart kayıtları kontrol edilir. OT kontrol odası özel kapsama alınır.

OT / SCADA

OT envanteri ve segmentation doğrulanır. PLC, HMI ve SCADA erişimleri incelenir. Vendor bağlantıları kontrol edilir. Backup ve restore prosedürü değerlendirilir. Aktif test güvenliği özel olarak yönetilir.

Compliance

İlgili standart ve mevzuat gereksinimleri matrise alınabilir. Policy ve teknik control eşleştirilir. Eksikler riskle ilişkilendirilir. Hukuki değerlendirme gereken maddeler ilgili birime yönlendirilir. Compliance sonucu teknik audit bulgularını tamamlar.

Denetimde En Sık Karşılaşılan Kritik Bulgular

Kurumların yapısı farklı olsa da bazı bulgular tekrar tekrar karşımıza çıkar. Güncel olmayan envanter, varsayılan parola, MFA eksikliği ve geniş firewall kuralları temel risklerdir. OT tarafında segmentasyon eksikliği, vendor erişimi ve internete açık cihazlar daha ciddi sonuç yaratabilir. Backup var olduğu halde restore testinin yapılmaması da sık görülen önemli eksikliktir. Incident Response Plan bulunmaması teknik olayın yönetim krizine dönüşmesine yol açabilir.

Güncel Olmayan Varlık Envanteri

Envanter eksikse patch ve EDR coverage ölçülemez. Unknown cihazlar kontrol dışında kalır. Owner atanamaz. Risk değerlendirmesi hatalı olur. İlk remediation adımı gerçek asset discovery olmalıdır.

Varsayılan Parolalar

Network, IoT ve OT cihazlarında görülebilir. İnternete açık cihazda risk çok yükselir. Default credential hızlıca değiştirilmelidir. Procurement ve devreye alma sürecine kontrol eklenmelidir. Vendor bakım hesabı ayrıca değerlendirilmelidir.

MFA Eksikliği

VPN ve cloud erişiminde ciddi risk oluşturur. Admin hesabında etki daha büyüktür. Coverage hızlıca artırılabilir. Legacy istisnalar kayıt altına alınmalıdır. Alternatif control uygulanmalıdır.

Ortak Yönetici Hesapları

İşlem izlenebilirliği azalır. Parola birden fazla kişi tarafından bilinir. Personal admin hesaplarına geçiş yapılmalıdır. Oturum logları tutulmalıdır. PAM uzun vadeli çözüm olabilir.

Eski İşletim Sistemleri

EOL sistemler patch alamayabilir. Kritik uygulama bağımlılığı nedeniyle yenileme gecikebilir. Network izolasyonu uygulanabilir. Migration planı yönetim bütçesine eklenmelidir. Risk kabul süresi sınırlı tutulmalıdır.

Geniş Firewall Kuralları

Any-to-any erişimler lateral movement riskini artırır. Kural sahibi bilinmeyebilir. Trafik logları kullanım ihtiyacını doğrulayabilir. Minimum kaynak ve hedef tanımlanmalıdır. Periyodik rule review süreci kurulmalıdır.

Test Edilmemiş Yedekler

Başarılı backup mesajı recovery garantisi değildir. Restore testinde bozuk dosya veya eksik dependency çıkabilir. Kritik sistemler düzenli test edilmelidir. RTO ölçülmelidir. Sonuç yönetim dashboard'una yansıtılmalıdır.

Log Eksikliği

Olayın kök nedeni belirlenemez. Admin işlemleri görünmez kalabilir. Kritik sistemler log source listesine eklenmelidir. Merkezi storage kullanılmalıdır. Retention ve time sync uygulanmalıdır.

IT–OT Segmentasyon Eksikliği

Office malware kontrol ağına yayılabilir. Firewall veya DMZ eksikliği risk oluşturur. Zone ve conduit modeli uygulanabilir. Jump host yönetim erişimini sınırlar. Değişiklik proses güvenliğiyle birlikte yapılmalıdır.

Kontrolsüz Vendor Erişimi

Sürekli açık VPN hesabı ve shared parola sık görülebilir. MFA ve süre sınırlı erişim uygulanmalıdır. Oturum loglanabilir. Sözleşme bitiminde erişim kaldırılmalıdır. Vendor account inventory tutulmalıdır.

Doğrudan İnternete Açık OT Cihazları

Kritik PLC veya HMI'nın public erişimi çok yüksek risklidir. Acil biçimde erişim kapatılmalıdır. Remote maintenance güvenli gateway'e taşınabilir. Cihaz credential değiştirilebilir. Exposure dışarıdan yeniden test edilmelidir.

Güncel Olmayan PLC ve SCADA Konfigürasyon Yedekleri

Arıza sonrası eski program yüklenmesi operasyon problemi yaratabilir. Her change sonrası backup alınmalıdır. Repository sürüm ve cihazla eşleştirilmelidir. Restore prosedürü test edilmelidir. Golden copy tanımlanmalıdır.

Incident Response Plan Eksikliği

Olay anında kim ne yapacağını bilemeyebilir. Teknik ekip ve yönetim koordinasyonu gecikir. Plan basit ve uygulanabilir hazırlanmalıdır. Ransomware ve OT senaryoları eklenmelidir. Tabletop ile test edilmelidir.

IT Audit Sırasında Yapılmaması Gerekenler

Denetim güvenlik seviyesini ölçerken üretimi veya kritik hizmeti riske atmamalıdır. Özellikle OT ortamında kontrolsüz tarama ve exploit denemesi ciddi fiziksel sonuç oluşturabilir. Konfigürasyon değişikliği denetim ile düzeltme sorumluluğunu birbirine karıştırabilir. Kanıt olmadan bulgu yazmak denetimin güvenilirliğini zedeler. Safety sistemleri bütün teknik testlerin üzerinde koruma önceliğine sahip olmalıdır.

Üretim Sistemlerini Kontrolsüz Tarama

Eski PLC ve cihazlar yoğun taramaya hassas olabilir. Önce üretici ve operasyon ekibiyle risk değerlendirilmelidir. Pasif yöntem tercih edilebilir. Test penceresi gerekiyorsa planlanmalıdır. Denetçi availability riskini teknik meraktan üstün tutmalıdır.

OT Sistemlerinde İzinsiz Aktif Test

Aktif test açık scope ve onay olmadan yapılmamalıdır. Hangi cihaz ve protokolün test edileceği belirlenmelidir. Safety owner bilgilendirilmelidir. Geri dönüş planı bulunmalıdır. Test sonucu kadar testin güvenli yapılması da denetim kalitesidir.

Canlı Sistemde Kontrolsüz Exploit Denemesi

Exploit sistem çökmesine veya proses etkisine neden olabilir. IT tarafında bile production exploitation özel onay gerektirir. OT'de risk çok daha yüksektir. Vulnerability kanıtı farklı yöntemlerle doğrulanabilir. Proof gerektiğinde kontrollü lab kullanılabilir.

Yedek Olmadan Konfigürasyon Değiştirme

Denetçi çoğu zaman değişiklik yapmamalıdır. Düzeltme zorunluysa change prosedürü uygulanmalıdır. Mevcut konfigürasyon yedeklenmelidir. Rollback adımı hazır olmalıdır. Değişiklik sahibi kurum ekibi olmalıdır.

Safety Sistemlerini Riske Atmak

Safety logic ve cihazlarına test çok dikkatli yaklaşmalıdır. Denetim scope'unda açık izin olmalıdır. Proses mühendisi sürece katılmalıdır. Aktif müdahale yerine doküman ve konfigürasyon review tercih edilebilir. İnsan güvenliği hiçbir audit hedefinden daha düşük öncelikte değildir.

Kanıt Toplamadan Bulgu Yazmak

Varsayıma dayalı bulgu güven kaybı yaratır. Görüşme bilgisi mümkün olduğunda teknik evidence ile doğrulanmalıdır. Kanıt yoksa observation olarak yazılabilir veya ek çalışma istenir. False positive kurumun remediation kaynaklarını boşa harcar. Denetçi bulgunun her cümlesini savunabilmelidir.

Denetim ile Düzeltme Sorumluluğunu Karıştırmak

Denetçi riski bağımsız değerlendirmelidir. Aynı kişinin bütün düzeltmeyi yapması bağımsızlığı azaltabilir. Danışmanlık ve audit rolleri açık biçimde ayrılabilir. Kurum kendi risk kararını vermelidir. Denetim closure'ı sonradan tarafsız retest ile doğrulamalıdır.

IT Audit Projesinin Teslimatları Neler Olmalı?

Kapsamlı bir denetim yalnızca PDF rapor teslimiyle bitmemelidir. Executive Summary, teknik rapor, varlık envanteri, network diyagramı, risk ve findings register birlikte güçlü çıktı seti oluşturur. Compliance Matrix ve 30, 90, 180 günlük roadmap yönetim uygulamasını kolaylaştırır. Yönetim sunumu risk kararını hızlandırır. Follow-Up Plan closure sürecini denetim projesinin devamı haline getirir.

Executive Summary

Yönetim için en kritik riskleri sade biçimde anlatmalıdır. Teknik detay minimum tutulur. İş etkisi ve yatırım ihtiyacı öne çıkar. Hızlı kazanımlar ayrıca gösterilir. Karar gereken maddeler açıkça yazılır.

Teknik Denetim Raporu

Her bulgu kanıt ve risk bilgisiyle yer alır. Sistem ve kontrol detayı yeterli olmalıdır. Severity kriteri tutarlı uygulanır. Öneri vendor-neutral yazılabilir. Eklerde gerekli teknik çıktılar bulunabilir.

Asset Inventory

Denetim sırasında doğrulanan varlık listesi teslim edilebilir. Owner ve kritiklik bilgisi eklenebilir. IT ve OT ayrı filtrelenebilir. Unknown asset'ler işaretlenir. Kurum envanteri yaşayan süreç olarak devam ettirmelidir.

Network Diagram

Güncel fiziksel veya mantıksal diyagram teslim edilebilir. IT, OT ve DMZ zone'ları gösterilir. Internet ve vendor bağlantıları işaretlenir. Kritik sistemler görünür hale gelir. Diyagramın gizlilik seviyesi belirlenmelidir.

Risk Register

Risk, owner, skor ve aksiyon bilgisi bulunmalıdır. Bulgular risklerle ilişkilendirilir. Residual risk ayrıca gösterilebilir. Hedef tarih takip edilir. Yönetim düzenli review yapmalıdır.

Findings Register

Tüm bulgular tek takip tablosunda tutulabilir. Severity, owner ve closure bilgisi bulunur. Evidence referansı eklenebilir. Follow-up sonuçları aynı kayıt üzerinde güncellenir. Tekrar eden bulgular kolayca görülebilir.

Compliance Matrix

Kontroller ilgili standart maddeleriyle eşleştirilebilir. Aynı evidence birden fazla gereksinimi destekleyebilir. Uyum durumu ve gap gösterilir. Hukuki yorum gereken alanlar ayrılır. Matrix gelecek denetimleri hızlandırabilir.

30–90–180 Günlük Roadmap

Bulgular uygulanabilir sıraya dönüştürülür. İlk 30 gün kritik açıklar, 90 gün temel kontroller ve 180 gün olgunluk yatırımları ele alınır. Bağımlılık ve bütçe notları eklenebilir. Her madde owner ve KPI taşır. Yönetim kaynak planını bu yol haritasıyla yapabilir.

Yönetim Sunumu

Sunum teknik raporun kopyası olmamalıdır. En kritik risk, iş etkisi ve karar ihtiyacı vurgulanmalıdır. Risk trendi ve hızlı kazanımlar gösterilebilir. Yönetim soruları için kanıt hazır tutulmalıdır. Toplantı sonunda aksiyon sahipliği netleşmelidir.

Follow-Up Plan

Hangi bulgunun ne zaman yeniden test edileceği belirlenir. Closure evidence formatı açıklanır. Critical ve High için daha kısa takip döngüsü uygulanabilir. Risk acceptance review tarihi eklenir. Follow-up plan denetimi tek seferlik çalışmadan çıkarır.

Yönetim Kurulu İçin Executive Summary Nasıl Hazırlanmalı?

Yönetim kurulu teknik kontrol listesini değil kurumun hangi hizmetinin hangi risk nedeniyle etkilenebileceğini görmek ister. En kritik 10 risk, iş etkisi, tahmini seviye ve gerekli yatırım açık biçimde sunulmalıdır. Hızlı kazanımlar ile bütçe gerektiren dönüşümler ayrılmalıdır. Karar gerektiren konular son bölümde netleştirilmelidir. Executive Summary teknik raporun sadeleştirilmiş özeti değil yönetim karar dokümanı olmalıdır.

En Kritik 10 Risk

Yüzlerce bulgu arasından en yüksek iş etkisi taşıyanlar seçilir. Aynı kök nedenden gelen bulgular gruplanabilir. Risk başlığı anlaşılır olmalıdır. Owner ve hedef aksiyon belirtilebilir. Liste kurum risk iştahına göre hazırlanmalıdır.

Kurumsal Etki

Kesinti, veri kaybı ve hizmet etkisi açık anlatılmalıdır. Finansal tahmin varsa aralık kullanılabilir. Hukuki ve itibar etkisi ayrıca gösterilebilir. Teknik açık yönetim diliyle bağlanmalıdır. Aşırı korkutucu dil kullanılmamalıdır.

Kritik Hizmetlere Etki

Her riskin hangi hizmeti etkilediği belirtilmelidir. Örneğin AD kesintisi çok sayıda uygulamayı aynı anda etkileyebilir. OT riski fiziksel operasyona bağlanabilir. Bağımlılık haritası görsel destek sağlayabilir. Yönetim önceliği bu ilişkiye göre belirler.

Tahmini Risk Seviyesi

Risk skoru açıklanabilir modelle gösterilmelidir. Critical veya High etiketi tek başına yeterli değildir. Olasılık ve etki özeti verilebilir. Compensating control varsa belirtilmelidir. Residual risk yönetim kararına temel olur.

Öncelikli Yatırımlar

MFA, segmentation veya backup yatırımı birden fazla riski azaltabilir. Yatırım önerileri risk reduction etkisiyle sıralanabilir. Ürün adı yerine kontrol hedefi sunulabilir. Tahmini süre ve bağımlılık belirtilir. Yönetim bütçe kararını daha kolay verir.

Hızlı Kazanımlar

Bazı riskler düşük maliyetle hızla azaltılabilir. Default parola değiştirmek veya gereksiz internet erişimini kapatmak örnektir. Bu aksiyonlar ilk 30 güne alınabilir. Etki ve sorumlu ekip belirtilir. Erken ilerleme program güvenini artırır.

Yönetim Kararı Gerektiren Konular

Risk kabulü, büyük sistem yenilemesi veya budget kararı yönetim yetkisi gerektirir. Teknik ekip bu kararları tek başına veremez. Seçenekler ve risk farkları açık sunulmalıdır. Hedef karar tarihi belirtilir. Karar sonrası risk register güncellenir.

IT Audit Başarısı Nasıl Ölçülür?

Denetim başarısı bulunan açık sayısıyla ölçülmemelidir. Kapsanan varlık, kapatılan kritik risk, remediation süresi ve kontrol coverage daha anlamlı göstergelerdir. Restore, MFA, patch ve OT visibility gerçek kontrol etkinliğini gösterir. Vendor access ve incident response tatbikat sonuçları yönetişim olgunluğunu destekler. Başarı, riskin ölçülebilir biçimde azalıp azalmadığı üzerinden değerlendirilmelidir.

Denetlenen Varlık Oranı

Scope içindeki varlıkların ne kadarının gerçekten test edildiği ölçülür. Unknown asset'ler coverage kalitesini etkiler. OT ve IT oranları ayrı gösterilebilir. Kritik varlık coverage daha yüksek hedeflenmelidir. Eksik alan sonraki audit planına alınır.

Kritik Risklerin Kapanma Oranı

Critical ve High bulguların closure oranı temel göstergedir. Retest edilmiş closure ayrı takip edilmelidir. Risk acceptance kapatma olarak sayılmamalıdır. Gecikmiş bulgular yönetimle paylaşılır. Trend program etkinliğini gösterir.

Ortalama Remediation Süresi

Risk seviyesine göre ayrı ölçüm yapılmalıdır. Critical bulgu daha kısa hedef taşımalıdır. Vendor ve procurement gecikmeleri ayrıca sınıflandırılabilir. Uzayan ortalama süreç sorunu gösterebilir. Owner ve management support değerlendirilmelidir.

Tekrar Eden Bulgu Oranı

Önceki audit bulgusunun yeniden çıkması kalıcı çözüm eksikliğini gösterir. Kök neden analiz edilmelidir. Süreç veya policy değişikliği gerekebilir. Oranın azalması olgunluk göstergesidir. Yönetim seviyesinde takip edilebilir.

Backup Restore Başarı Oranı

Planlanan restore testlerinin başarısı ölçülür. Sadece backup success kullanılmamalıdır. RTO hedefini karşılama oranı eklenebilir. Kritik sistem coverage ayrıca gösterilir. Başarısız test remediation oluşturur.

MFA Coverage

Admin, VPN ve cloud kullanımında coverage ölçülebilir. İstisnalar ayrıca raporlanır. Yüzde yüz coverage bazı legacy ortamlarda mümkün olmayabilir. Compensating control görünür olmalıdır. Trend risk azalmasını gösterir.

Patch Compliance

Kritik patch SLA uyum oranı izlenir. EOL sistemler ayrı sınıfta tutulur. OT patch uygunluğu farklı hedef kullanabilir. Gecikme nedenleri kategorize edilir. Vulnerability risk trendiyle birlikte değerlendirilir.

OT Asset Visibility

Bilinen ve izlenen OT cihaz oranı ölçülür. Pasif monitoring coverage eklenebilir. Unknown device sayısı takip edilir. Kritik zone'larda hedef daha yüksek olmalıdır. Visibility incident response kapasitesini doğrudan etkiler.

Vendor Access Compliance

Vendor hesaplarının ne kadarında MFA ve süre sınırlı erişim bulunduğu ölçülür. Sözleşmesi bitmiş aktif hesap olmamalıdır. Session logging coverage gösterilebilir. İstisnalar risk owner'a bağlı olmalıdır. Trend tedarikçi güvenlik olgunluğunu gösterir.

Incident Response Tatbikat Başarısı

Tatbikatta tespit, eskalasyon ve karar süreleri ölçülebilir. Rol belirsizliği bulguya dönüştürülür. Teknik recovery hedefleri karşılaştırılır. İletişim zinciri test edilir. Sonraki tatbikatta iyileşme görülmelidir.

Yerel Kurumlar İçin 12 Aylık IT–OT Güvenlik Dönüşüm Planı

Bir kurum bütün IT ve OT risklerini tek ayda kapatamaz. İlk iki ay envanter ve risk haritası, sonraki aylarda kritik açıklar, identity, network, OT, backup ve vendor alanları sırayla ele alınabilir. On ikinci ay follow-up audit ve olgunluk ölçümü yapılabilir. Program gerçek kaynak ve bakım takvimine göre uyarlanmalıdır. Amaç kontrol listesi bitirmek değil kalıcı operasyon kapasitesi kurmaktır.

Ay 1–2 — Envanter ve Risk Haritası

IT ve OT asset listesi doğrulanır. BIA ve kritik hizmet haritası hazırlanır. Internet exposure ve vendor erişimleri ilk kez görünür hale gelir. Risk scoring modeli oluşturulur. İlk critical aksiyonlar ayrıca başlatılabilir.

Ay 3–4 — Kritik Açıkların Kapatılması

Default credential ve public exposure sorunları çözülür. Kritik admin hesapları güçlendirilir. Backup ve restore eksikleri ele alınır. EOL riskleri planlanır. Closure retest ile doğrulanır.

Ay 5–6 — Identity ve Network Güvenliği

MFA coverage genişletilir. Shared ve eski hesaplar temizlenir. Segmentation ve firewall kuralları iyileştirilir. Jump host modeli uygulanabilir. Identity ve network logları SIEM'e alınır.

Ay 7–8 — OT Segmentasyonu ve Monitoring

Zone ve conduit modeli netleştirilir. OT DMZ ve vendor erişimi uygulanır. Pasif asset visibility geliştirilir. Kritik network akışları izlenir. OT change ve backup süreçleri standardize edilir.

Ay 9 — Backup ve Disaster Recovery

Kritik sistem restore testleri yapılır. Offline veya immutable backup doğrulanır. RTO ve RPO güncellenir. OT program yedekleri kontrol edilir. DR planı teknik sonuçlarla revize edilir.

Ay 10 — Incident Response Tatbikatı

Ransomware veya OT kesintisi senaryosu seçilebilir. Yönetim ve teknik ekip birlikte çalışır. İletişim ve eskalasyon test edilir. Recovery kararları değerlendirilir. Aksiyon listesi sonraki aya taşınır.

Ay 11 — Vendor ve Supply Chain Audit

Kritik tedarikçiler sınıflandırılır. Remote access ve contract kontrolleri incelenir. Offboarding ve MFA eksikleri kapatılır. Cloud sağlayıcı riskleri değerlendirilir. Tedarikçi KPI ve review periyodu oluşturulur.

Ay 12 — Follow-Up Audit ve Olgunluk Ölçümü

Yıl içindeki bulgular yeniden test edilir. Maturity score güncellenir. Tekrar eden riskler analiz edilir. Yönetim dashboard trendi değerlendirilir. Sonraki yıl audit ve yatırım planı hazırlanır.

Sık Sorulan Sorular

IT Audit konusunda en fazla karışıklık denetim, sızma testi, OT güvenliği ve standartların rolü etrafında oluşur. Denetim tek ürün veya tek tarama değildir. Kapsam, risk, kanıt ve follow-up birlikte ele alınmalıdır. Aşağıdaki sorular uygulamada sık karşılaşılan temel konuları özetler. Kurumun gerçek ihtiyaçları için kapsam ve kritik hizmet analizi ayrıca yapılmalıdır.

IT Audit nedir?

IT Audit bilgi sistemlerinin kontrol, güvenlik ve yönetişim açısından değerlendirilmesidir. Teknik ve süreç kontrolleri birlikte incelenir. Kanıt üzerinden bulgu oluşturulur. Risk iş etkisiyle ilişkilendirilir. Sonuç remediation ve follow-up planına dönüşür.

Bilgi sistemleri denetimi nasıl yapılır?

Önce scope ve kritik hizmetler belirlenir. Varlık envanteri doğrulanır. Risk analizi ve teknik test yapılır. Evidence toplanır ve bulgular yönetimle doğrulanır. Nihai rapor sonrası closure süreci işletilir.

IT Audit ile sızma testi arasındaki fark nedir?

Sızma testi teknik istismar olasılığına odaklanır. IT Audit süreç, kontrol ve yönetişimi de değerlendirir. Penetrasyon testi audit'in bir girdisi olabilir. Her denetimde exploit testi gerekli değildir. OT ortamında aktif test ayrıca sınırlandırılmalıdır.

OT Audit nedir?

OT Audit endüstriyel kontrol sistemlerinin güvenlik ve sürekliliğini değerlendirir. PLC, SCADA, HMI ve engineering workstation kapsama girebilir. Network segmentation ve vendor erişimi önemlidir. Safety etkisi test yöntemini belirler. Pasif evidence yöntemleri sık kullanılır.

SCADA sistemleri nasıl denetlenir?

SCADA sunucu ve istemci envanteri çıkarılır. Kimlik, network, backup ve loglama kontrolleri incelenir. Vendor erişimleri değerlendirilir. Proje ve konfigürasyon yedekleri doğrulanır. Aktif test üretim güvenliği dikkate alınarak yapılır.

PLC güvenliği nasıl kontrol edilir?

PLC model, firmware ve network erişimi belirlenir. Programlama yetkileri incelenir. Varsayılan parola ve public exposure kontrol edilir. Program backup'ı doğrulanır. Aktif test yerine üretici ve konfigürasyon bilgisiyle güvenli değerlendirme tercih edilebilir.

IT ve OT arasındaki fark nedir?

IT bilgi ve uygulama süreçlerine odaklanır. OT fiziksel prosesleri izler veya kontrol eder. OT'de availability ve safety etkisi daha belirgindir. Patch ve test yöntemi farklı olabilir. Convergence iki alanın ortak denetlenmesini gerekli hale getirir.

Belediyelerde IT Audit nasıl yapılır?

Vatandaş hizmetleri ve kritik uygulamalar belirlenir. Identity, network, cloud, vendor ve backup kontrolleri değerlendirilir. Trafik veya altyapı OT sistemleri ayrıca kapsama alınabilir. KVKK ve yerel yükümlülükler incelenir. Sonuç hizmet sürekliliği üzerinden raporlanır.

OSB'lerde hangi bilişim sistemleri denetlenmelidir?

Kurumsal IT, enerji, su, SCADA ve sayaç sistemleri kapsama alınabilir. Vendor ve uzaktan bakım erişimleri önemlidir. Network segmentation değerlendirilmelidir. Backup ve fiziksel güvenlik incelenir. Kritik altyapı bağımlılıkları BIA ile ilişkilendirilir.

IT Audit ne kadar sürer?

Süre scope ve kurum büyüklüğüne bağlıdır. Küçük bir targeted audit birkaç hafta içinde tamamlanabilir. Çok lokasyonlu IT–OT denetimi daha uzun sürebilir. Evidence erişimi ve saha planı süreyi etkiler. Başlangıçta çalışma takvimi açıkça belirlenmelidir.

IT Audit ne sıklıkla yapılmalıdır?

Yıllık program birçok kurum için temel yaklaşım olabilir. Kritik alanlar daha sık kontrol edilebilir. Büyük sistem değişikliği sonrasında ek audit yapılabilir. Ciddi siber olay da özel denetim gerektirebilir. Sürekli KPI izleme yıllık audit arasındaki boşluğu azaltır.

Bir IT Audit raporunda neler bulunmalıdır?

Executive summary, scope ve metodoloji bulunmalıdır. Bulgular kanıt, risk ve öneri içermelidir. Risk register ve findings register eklenebilir. 30, 90 ve 180 günlük roadmap yönetim için değerlidir. Follow-up plan raporu tamamlar.

ISA/IEC 62443 nedir?

Endüstriyel otomasyon ve kontrol sistemleri için güvenlik standart ailesidir. Zone, conduit ve security level gibi kavramlar sunar. Asset owner ve service provider rollerini ayırır. OT yaşam döngüsü boyunca güvenliği ele alır. Denetimde önemli referans olarak kullanılabilir.

NIST SP 800-82 nedir?

Endüstriyel kontrol sistemlerinin güvenliği için teknik rehberdir. OT mimarisi ve güvenlik risklerini açıklar. Network segmentation ve remote access konularında yardımcıdır. IT kontrollerinin OT'deki uygulama farklarını ele alır. Kurumun kendi safety ve operasyon koşuluyla birlikte kullanılmalıdır.

IT Audit için ISO 27001 yeterli midir?

ISO 27001 güçlü yönetim sistemi çerçevesidir ancak her teknik detayı tek başına kapsamayabilir. OT için ISA/IEC 62443 ve NIST SP 800-82 gibi kaynaklar ek değer sağlar. COBIT yönetişim perspektifi sunabilir. Sektör özel düzenlemeleri ayrıca değerlendirilmelidir. Denetim çoklu referansı risk bazlı kullanabilir.

OT cihazlarında vulnerability scan yapılabilir mi?

Her OT cihazında aktif scan güvenli olmayabilir. Üretici desteği ve operasyon riski değerlendirilmelidir. Pasif keşif tercih edilebilir. Aktif tarama gerekiyorsa açık onay ve bakım penceresi kullanılmalıdır. Safety riski her zaman önceliklidir.

Yedeklerin var olması yeterli midir?

Hayır. Yedek restore edilmeden güvenilir sayılmamalıdır. Kritik sistem için RTO ve RPO testi yapılmalıdır. Offline veya immutable kopya değerlendirilmelidir. Erişim ve şifreleme kontrolleri incelenmelidir. OT konfigürasyon yedekleri ayrıca tutulmalıdır.

Vendor uzaktan erişimleri nasıl denetlenir?

Vendor hesap envanteri çıkarılır. VPN, MFA ve jump host kullanımı kontrol edilir. Oturum logları ve süre sınırlı erişim değerlendirilir. Sözleşme biten hesaplar kapatılmalıdır. Doğrudan kritik OT erişimi mümkün olduğunca sınırlandırılmalıdır.

IT Audit uzmanı olmak için ne yapmalı?

Network ve sistem yönetimi temelleri öğrenilmelidir. Güvenlik, risk ve kontrol mantığı anlaşılmalıdır. AD, cloud ve log analizi pratiği yapılmalıdır. OT hedefleniyorsa SCADA ve PLC temelleri öğrenilmelidir. Kontrollü lab ve gerçek senaryo deneyimi önemlidir.

IT Audit otomasyonu için hangi programlama dili kullanılmalı?

Tek bir doğru dil yoktur. PowerShell Windows için, Bash Linux için güçlüdür. Python veri ve API otomasyonunda faydalıdır. SQL denetim verisi analizinde kullanılabilir. Kullanım amacı ve ekip yetkinliği seçimi belirlemelidir.

Açık kaynak araçlarla IT Audit yapılabilir mi?

Evet, discovery, log ve configuration kontrolünde açık kaynak araçlar kullanılabilir. Ancak sonuç tek başına bulgu değildir. Araç güvenliği ve bakım durumu değerlendirilmelidir. OT ortamında aktif kullanım güvenli olmalıdır. Denetçi çıktıyı kanıt ve iş bağlamıyla doğrulamalıdır.

Sonuç — IT Audit Bir Kontrol Listesi Değil, Sürekli Risk Yönetimi Döngüsüdür

Yerel Kurumlar İçin Kapsamlı Endüstriyel Bilişim Denetimleri (IT Audit) yaklaşımının temel amacı daha uzun kontrol listesi oluşturmak değildir. Gerçek amaç kritik hizmeti, varlığı, kontrolü ve iş riskini aynı yönetim sisteminde birleştirmektir. IT ve OT varlıkları görünür hale getirildikten sonra teknik evidence ile kontrol etkinliği doğrulanabilir. Bulgular risk seviyesine göre yol haritasına dönüştürülmeli ve düzeltmeler retest edilmelidir. Denetim bu döngüyle tek seferlik proje olmaktan çıkarak kurumun sürekli güvenlik ve dayanıklılık mekanizmasına dönüşür.

Önce Kritik Hizmet Belirlenir

Teknik sistemden önce iş hizmeti anlaşılmalıdır. Hangi hizmetin ne kadar kesintiye dayanabildiği belirlenir. BIA iş etkisini görünür hale getirir. Sistem bağımlılıkları bu hizmete bağlanır. Denetim önceliği gerçek kurumsal riske dayanır.

Sonra IT ve OT Varlıkları Haritalanır

Envanter olmadan güvenilir coverage ölçülemez. IT, OT, cloud ve vendor sistemleri birlikte görülmelidir. Owner ve kritiklik bilgisi eklenir. Network ilişkileri haritalanır. Unknown asset'ler ayrıca risk olarak ele alınır.

Kontroller Teknik Kanıtlarla Test Edilir

Policy tek başına yeterli değildir. Firewall, log, kullanıcı ve backup kayıtları incelenir. Kanıt doğrulanabilir ve güncel olmalıdır. OT test güvenliği sürekli korunur. Sonuç gerçek uygulamayı göstermelidir.

Riskler İş Etkisine Göre Önceliklendirilir

Teknik severity iş etkisiyle birleştirilir. Kritiklik ve exposure dikkate alınır. Safety etkisi ayrıca değerlendirilir. Compensating control residual risk'i değiştirebilir. Yönetim hangi riske önce kaynak ayıracağını görür.

Bulgular 30–90–180 Günlük Yol Haritasına Dönüştürülür

Critical açıklar ilk dönemde ele alınır. Temel süreçler 90 günlük planda kurumsallaştırılır. Daha gelişmiş kontroller 180 günlük döneme alınabilir. Owner ve hedef tarih belirlenir. Yönetim ilerlemeyi düzenli takip eder.

Düzeltmeler Yeniden Test Edilir

Closure evidence doğrulanmalıdır. Critical ve High bulgular retest edilir. Kontrolün gerçekten çalıştığı gösterilir. Risk kabulü ayrı kayıt altına alınır. Tekrar eden bulgular kök neden açısından değerlendirilir.

Denetim Tek Seferlik Değil Sürekli İyileştirme Döngüsü Haline Getirilir

Yıllık audit programı ve sürekli KPI izleme birlikte kullanılabilir. Yeni sistem ve olaylar risk profilini değiştirir. Maturity score periyodik güncellenir. Yerel uzmanlık ve kurumsal ekipler birlikte gelişir. Kurum güvenliği satın alınan ürünlerden çok yaşayan kontrol sistemine dönüşür.

Yerel kurumlar için kapsamlı bilişim denetimi (IT Audit) nasıl yapılır?

Yerel kurumlar için kapsamlı bilişim denetimi kritik hizmet ve kapsam belirleme ile başlamalıdır. IT, OT, cloud ve vendor varlıkları envantere alınmalı, ardından identity, network, backup, loglama ve iş sürekliliği gibi kontroller teknik evidence ile test edilmelidir. Riskler yalnızca teknik severity üzerinden değil iş etkisi, varlık kritiklik ve exposure bilgisiyle değerlendirilmelidir. Bulgular owner ve hedef tarih içeren 30, 90 ve 180 günlük remediation planına dönüştürülmelidir. Son aşamada closure evidence doğrulanmalı ve follow-up audit ile riskin gerçekten kapandığı gösterilmelidir.

Kurumsal IT denetiminde hangi bilgi sistemleri, güvenlik kontrolleri ve iş süreçleri incelenir?

Kurumsal IT Audit kapsamında network, sunucu, endpoint, veritabanı, uygulama, cloud, kimlik ve backup sistemleri incelenebilir. OT kullanan kurumlarda SCADA, PLC, HMI ve engineering workstation ayrıca değerlendirilmelidir. Teknik alanların yanında incident response, change management, vendor, iş sürekliliği ve fiziksel güvenlik süreçleri de kapsama girebilir. Kontrol listesi kurumun kritik hizmetlerine ve risk profiline göre derinleştirilmelidir. Böylece denetim yalnızca teknik cihaz sayımı değil gerçek kurumsal kontrol değerlendirmesine dönüşür.

IT Audit kapsamında ISO 27001, COBIT ve diğer bilişim standartlarına uygunluk nasıl değerlendirilir?

Önce kurumun tabi olduğu standart ve düzenlemeler belirlenir. Kontroller ISO/IEC 27001, COBIT, NIST veya OT için ISA/IEC 62443 gibi referanslarla eşleştirilebilir. Compliance Matrix her kontrol için evidence, mevcut durum ve gap bilgisini gösterebilir. Ancak standarda uyum gerçek iş riskinin tamamen ortadan kalktığı anlamına gelmez. Denetim uyum sonucunu teknik risk ve operasyon etkisiyle birlikte yorumlamalıdır.

Bilişim denetimi sonucunda tespit edilen siber güvenlik ve operasyonel riskler nasıl raporlanır?

Her bulgu mevcut durum, teknik evidence, risk, iş etkisi, kök neden ve düzeltici faaliyet içermelidir. Critical, High, Medium veya Low sınıflandırması tutarlı risk modeliyle yapılmalıdır. Executive Summary yönetim için en kritik riskleri ve yatırım ihtiyacını sade biçimde göstermelidir. Teknik detay Findings Register ve ayrıntılı raporda tutulabilir. Remediation owner, hedef tarih ve follow-up sonucu raporlama sisteminin ayrılmaz parçası olmalıdır.

Kurumlar için IT Audit ve bilişim denetimi hizmeti yakınımda nerede bulunur?

Endüstriyel IT audit ve bilişim denetimi firması yakınımda şeklinde arama yaparken yalnızca otomatik vulnerability scan sunan ekiplerle kapsamlı denetim metodolojisi kullanan yapıları ayırmak önemlidir. Denetim ekibinin network, sistem, cloud, identity ve gerekiyorsa OT ortamında gerçek uygulama deneyimi bulunmalıdır. Kanıt toplama, risk puanlama ve yönetim raporlama yaklaşımı seçim kriterine dahil edilmelidir. Diyarbakır Yazılım Topluluğu'nun yerel teknoloji ekosistemi ve projeleri hakkında https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr/projects adreslerinden bilgi alınabilir. Kurumlar için kapsamlı IT audit ve bilişim denetimi hizmeti değerlendirilirken teknik bağımsızlık, etik, OT güvenliği ve follow-up kapasitesi mutlaka birlikte sorgulanmalıdır.

Kapsamlı IT Audit İçin Sonraki Adım

Yerel Kurumlar İçin Kapsamlı Endüstriyel Bilişim Denetimleri (IT Audit) konusunda ilk adım pahalı bir güvenlik ürünü satın almak değil, hangi kritik hizmetin hangi teknolojiye bağımlı olduğunu görünür hale getirmektir. Kurumlar için IT denetimi kontrol listesi ve denetim kriterleri ancak bu bağlamdan sonra gerçek değer üretir. IT, OT, IoT, cloud ve vendor erişimleri aynı risk haritasında değerlendirildiğinde güvenlik yatırımlarının önceliği daha doğru belirlenebilir. Yerel teknoloji ekosistemlerinin teknik üretim ve uzmanlık kapasitesini geliştirmeye yönelik çalışmalar hakkında https://www.diyarbakiryazilim.com.tr/posts/bolgesel-teknoloji-ekosistemlerinde-uretim-merkezleri-hub-kurmak içeriğini inceleyebilirsiniz. Diyarbakır Yazılım Topluluğu'nun çalışmaları ve proje yaklaşımı için https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr/projects adresleri üzerinden toplulukla bağlantı kurabilirsiniz.