OT Saldırı Tespiti: Endüstriyel Protokollerde Anomali İzleme

PLC’ye ajan kurulmaz, çoğu saha cihazı log üretmez. OT ağında saldırı tespiti için elinizdeki en değerli sinyal, kablodan geçen endüstriyel protokol komutlarıdır. IT’deki uç nokta ve log merkezli izleme alışkanlığı burada işe yaramaz; mantığı baştan kurmak gerekir. Bu rehberde sensör yerleşimini, normal iletişim haritasını, PLC program ve mod değişikliği tespitini ve bu alarmların SOC’a nasıl aktarılacağını anlatıyoruz. Hedef okur, OT görünürlük altyapısını saldırı tespitine çevirmek isteyen güvenlik ekipleri.

OT izlemesi IT izlemesinden neden farklıdır

IT ağında trafik dağınıktır: kullanıcı her gün yeni hedefe bağlanır, uygulama güncellenir, bulut servisleri değişir. OT ağında iletişim büyük ölçüde deterministiktir; aynı HMI aynı PLC’den aynı register’ları aynı periyotla okur. Bu, izleme için hem avantaj hem sınırlama.

• Avantaj: Normal davranış dar bir alanda tanımlandığı için sapma belirgin olur. Yeni bir IP’nin PLC’ye bağlanması IT’de gürültüdür; OT’de anlamlı bir sinyaldir.
• Sınırlama: Saldırganın komutları meşru mühendislik komutlarıyla aynıdır. PLC’ye program yüklemek tek başına kötü niyet değildir; belirleyici olan kimin, ne zaman ve hangi değişiklik kaydıyla yüklediğidir.
• Müdahale kısıtı: IT’de şüpheli bağlantı otomatik kesilebilir. OT’de yanlış bir otomatik engelleme proses kontrol trafiğini keser, hat durur. Bu yüzden OT izlemesi çoğunlukla pasif tespit ve insan kararıyla müdahale modelinde çalışır.

Sensör yerleşimi ve görünürlük planı

Tespit, sensörün gördüğü trafik kadar iyidir. Varlık keşfi için kurulan toplama noktaları iyi bir başlangıç; OT pasif varlık keşfi rehberindeki SPAN/TAP yerleşimi burada da geçerli. Saldırı tespiti için ayrıca şu akışların görünmesi gerekir:

1. IT/OT sınırı ve OT DMZ: Uzak erişim, historian replikasyonu, dosya aktarımı. Saldırı OT’ye çoğunlukla buradan girer.
2. Mühendislik istasyonu ile PLC arası: Program yükleme, firmware güncelleme ve mod değiştirme komutları bu yoldan geçer.
3. SCADA/HMI ile PLC arası: Set değeri yazma ve komut gönderme.
4. Hücre içi trafik (kritik hatlarda): Hücre switch’ine doğrudan takılan yetkisiz bir dizüstü yalnız burada görünür.

Görünürlük planını tabloya dökün; kör noktalar kendiliğinden ortaya çıkar. Her hücre için üç sütun yeter: “denetim trafiği görülüyor mu”, “hücre içi trafik görülüyor mu”, “mühendislik trafiği hangi noktadan geçiyor”. Görülmeyen yer bilinçli bir risk kararı olarak kayda geçer. Kayda geçmeyen kör nokta, unutulmuş kör noktadır.

Baseline: normal iletişim haritası çıkarmak

Davranış tabanlı tespitin temeli normal iletişimin modelidir. Ticari OT izleme platformlarının çoğu bir öğrenme dönemi kullanır; açık kaynak tarafta aynı haritayı Zeek logları üzerinden çıkarabilirsiniz. Baseline’da şu boyutlar tutulur:

• Kaynak–hedef çiftleri ve kullanılan protokol/port.
• Protokol düzeyinde işlem türü: okuma mı yazma mı, hangi fonksiyon kodları veya CIP servisleri.
• Periyot ve hacim: HMI’ın PLC’yi kaç saniyede bir sorguladığı, tipik paket sayısı.
• Zaman deseni: mühendislik trafiğinin hangi gün ve pencerelerde oluştuğu.

Öğrenme döneminde iki hata tekrar tekrar karşımıza çıkıyor. Birincisi, dönemin yalnız rutin üretimi kapsaması; ardından gelen ilk reçete değişikliği veya planlı bakım yüzlerce alarm üretir ve ekip sensöre güvenini kaybeder. İkincisi, ağın zaten temiz olduğunu varsaymak. Öğrenme bitince baseline operasyon ve otomasyon ekibiyle satır satır okunmalı. “Bu dizüstü neden her gece PLC’ye bağlanıyor?” sorusu genellikle bu toplantıda sorulur.

Kritik olaylar: PLC yazma, firmware ve mod değişikliği

Anomali modelinden bağımsız olarak bazı olaylar her koşulda alarm üretmeli. Bunlar proses üzerinde doğrudan etki yaratabilen komutlar:

Protokol	İzlenecek işlem	Neden kritik
Modbus TCP	FC 5, 6, 15, 16 (yazma), FC 22–23; FC 8 alt fonksiyon 4 (Force Listen Only)	Çıkış ve register değiştirir; FC 8/4 cihazı haberleşmeden düşürebilir
S7comm	Download (0x1A–0x1C), PLC Stop (0x29), PI servisleri (0x28), blok silme	Program değiştirir, CPU’yu durdurur veya başlatır
EtherNet/IP / CIP	Identity nesnesine Reset servisi, Set_Attribute istekleri, firmware yükleme	Cihazı yeniden başlatır veya yapılandırmasını değiştirir
DNP3	Select/Operate, Direct Operate, Cold/Warm Restart (FC 13/14)	Saha çıkışlarını sürer veya cihazı yeniden başlatır

Bu alarmların değeri bağlamla birlikte gelir: komutu gönderen kaynak onaylı bir mühendislik istasyonu mu, saat bir bakım penceresine denk geliyor mu, bu PLC için açık bir değişiklik kaydı var mı? Bağlamsız alarm, analistin önüne düşen bir IP adresinden ibarettir. Yeni nesil Siemens S7-1200/1500 CPU’larının kullandığı S7comm-plus protokolünde ve şifreli oturumlarda içerik çözümlemesi sınırlıdır; o durumda “mühendislik oturumu açıldı” düzeyinde tespit ile CPU tanılama tamponunun periyodik kontrolü birlikte kullanılır.

Açık kaynak tarafında Suricata, Modbus için uygulama katmanı anahtar kelimeleri sunar. Aşağıdaki örnek kural, onaylı mühendislik istasyonları dışından gelen Modbus yazma işlemlerinde alarm üretir:

# suricata.yaml: app-layer.protocols.modbus.enabled: yes olmalı
# address-groups: EWS_HOSTS ve PLC_NET tanımlı olmalı

alert modbus !$EWS_HOSTS any -> $PLC_NET 502 (msg:"OT - Onaysiz kaynaktan Modbus yazma"; \
    modbus: access write; classtype:policy-violation; sid:9000101; rev:1;)

alert modbus any any -> $PLC_NET 502 (msg:"OT - Modbus FC8 diagnostik istegi"; \
    modbus: function 8; classtype:attempted-dos; sid:9000102; rev:1;)

Sahada en sık gördüğümüz kurulum hatası şu: Modbus ayrıştırıcısı Suricata’nın varsayılan yapılandırmasında kapalı gelir, kural yüklenir ama hiçbir zaman eşleşmez. Sessiz kural güvenlik hissi verir, koruma vermez. Kuralları canlıya almadan önce kaydedilmiş trafik (pcap) üzerinde suricata -r ile deneyin; hem eşleşmeyi hem gürültüyü önceden görürsünüz.

İmza ve anomali tabanlı tespitin sınırları

Yaklaşım	Güçlü yanı	Sınırlaması
İmza tabanlı	Bilinen zararlı araç, exploit ve IT kökenli tehditleri net tanır	Meşru komutla yapılan saldırıyı görmez; OT’ye özgü imza sayısı sınırlı
Politika/kural tabanlı	“Bu kaynak bu PLC’ye yazamaz” gibi kesin kurallar, az gürültü	Kuralları yazmak için iyi envanter ve süreç bilgisi gerekir
Davranış/anomali	Bilinmeyen yöntemleri sapma olarak yakalar	Plansız ama meşru değişikliklerde gürültü; baseline kalitesine bağımlı
Proses değeri izleme	Fiziksel olarak imkânsız veya tehlikeli set değerlerini fark eder	Proses bilgisi ve otomasyon ekibiyle ortak çalışma gerektirir

Endüstriyel siber güvenlik izlemesinde işe yarayan, bu yaklaşımları katmanlamaktır. IT kökenli tehditler (fidye yazılımı yayılımı, uzak erişim araçları, kimlik bilgisi saldırıları) OT sınırında imza ve davranış tespitiyle yakalanır. OT’ye özgü manipülasyon ise politika kuralları ve kritik olay listesiyle. Tek katman yetmez. Tespit kapsamını MITRE’nin ATT&CK for ICS matrisi üzerinde işaretlemek, hangi tekniklerin hiç görülemediğini somut olarak gösterir.

OT alarmlarının SOC’a entegrasyonu ve triyaj

OT sensörü alarmı üretir; gece vardiyasında o alarmı değerlendirecek SOC analisti ise çoğu zaman PLC’nin ne yaptığını bilmez. Entegrasyonun üç bileşeni var:

1. Zenginleştirme: Alarm SIEM’e varlık adı, hat/hücre, kritiklik ve sorumlu kişiyle gelmeli. Yalnız IP adresiyle gelen OT alarmı triyajı uzatır.
2. Değişiklik kaydı korelasyonu: PLC yazma veya program yükleme alarmı aynı zaman aralığında onaylı bir değişiklik kaydı veya bakım iş emriyle eşleşiyorsa öncelik düşer; eşleşmiyorsa yükselir.
3. Eskalasyon yolu: SOC’un OT’de doğrudan müdahale yetkisi olmamalı. Analistin işi, alarmı doğrulayıp vardiya mühendisine veya OT güvenlik sorumlusuna tanımlı bir senaryo üzerinden iletmek.

Örnek triyaj akışı: Gece 02.40’ta bir PLC’ye S7 download işlemi tespit edilir. Analist önce kaynağa bakar; kaynak onaylı mühendislik istasyonu listesinde yoksa olay yüksek önceliğe çıkar. Sonra değişiklik kaydı kontrol edilir; kayıt yoksa vardiya mühendisi aranır ve hattın durumunu kontrol etmesi istenir. Mühendis değişikliği tanımıyorsa olay, OT olay müdahale planındaki izolasyon karar sürecine devredilir. Bu akışın her adımı SOC playbook’unda yazılı olmalı. Yazılı değilse gece 02.40’ta kimse ne yapacağını bilmez.

OT izlemesini mevcut SOC hizmetine bağlamayı planlayan kurumlar için SOC ve MDR danışmanlığı, sensör tasarımı ve kural seti için OT/ICS güvenlik hizmeti başlangıç noktası. Firewall tarafında protokol düzeyinde engelleme kuralları için endüstriyel sitedeki Modbus ve S7 derin paket inceleme rehberi tamamlayıcıdır.

Ölçülmesi gerekenler

• Görünürlük kapsamı: sensörle izlenen hücre sayısının toplam hücre sayısına oranı.
• Kritik olay alarmlarının değişiklik kaydıyla eşleşme durumu: eşleşmeyen her alarm ya bir süreç açığıdır ya bir güvenlik açığı.
• Triyaj süresi: alarmın oluşmasından vardiya mühendisinin geri bildirimine kadar geçen süre.
• Periyodik test: bakım penceresinde onaysız bir istasyondan zararsız bir okuma/yazma denemesi yapılır ve alarmın SOC’a ulaştığı doğrulanır. Test edilmeyen alarm zinciri çalışıyor sayılmaz.

Sık sorulan sorular

OT ağında IPS ile otomatik engelleme yapılmalı mı?

Proses kontrol trafiğinin geçtiği yerde otomatik engellemeye temkinli yaklaşın; tek hatalı eşleşme üretimi durdurabilir. Yaygın yaklaşım: OT sınırında IT kökenli tehditleri engellemek, hücre içinde ise tespit edip insan kararıyla müdahale etmek.

Baseline öğrenme dönemi ne kadar olmalı?

Süreden çok kapsam belirleyici. Öğrenme dönemi vardiya değişimlerini, ürün veya reçete değişikliklerini ve en az bir planlı bakımı içermeli. Sonra öğrenilen ilişkiler operasyon ekibiyle tek tek gözden geçirilmeli.

Şifreli PLC protokollerinde tespit mümkün mü?

İçerik düzeyinde tespit daralır; ancak bağlantının kaynağı, zamanı, oturum açılması ve hacim değişimi yine görünür. Bu bilgi PLC tanılama tamponu ve proje dosyası karşılaştırmasıyla birleştirilince yetkisiz değişiklik yakalanabilir.

SOC analisti OT alarmında ne yapmalı?

Analist alarmı varlık bilgisi ve değişiklik kayıtlarıyla doğrular, tanımlı eskalasyon yolundan vardiya mühendisine veya OT güvenlik sorumlusuna iletir. OT sistemine doğrudan müdahale kararı operasyon ekibiyle birlikte verilir.