OT Olay Müdahale Planı: Üretimi Güvenle Kontrol Altına Almak

Fabrikada siber olay başladığında ilk soru “hangi sistem etkilendi” değil, “proses güvenli mi” olmalı. IT için yazılmış olay müdahale planları bu soruyu sormaz. Sunucuyu ağdan ayırmak, hesabı kilitlemek, makineyi yeniden kurmak gibi refleks adımlar OT’de üretimi, ekipmanı ve insan güvenliğini doğrudan etkileyebilir. Bu rehberde mevcut IT planına eklenecek OT bölümünü nasıl yazdığımızı anlatıyoruz: roller, izolasyon kararı, delil toplama, kurtarma ve tatbikat.

IT ve OT olay müdahalesinin farkları

Konu	IT yaklaşımı	OT’de dikkat edilecek nokta
Öncelik	Veri gizliliği ve bütünlüğü	İnsan ve çevre güvenliği, ardından proses sürekliliği
İzolasyon	Şüpheli sistemi hemen ağdan ayır	Ayırmanın prosese etkisi önce değerlendirilir
Kapatma	Gerekirse sistem kapatılır	HMI kapanırsa operatör prosesi göremez; kontrollü duruş gerekebilir
Delil	Disk ve bellek imajı	PLC programı, tanılama tamponu, proses verisi; bellek imajı her cihazda mümkün değil
Kurtarma	İmajdan yeniden kurulum	Doğrulanmış proje dosyası, firmware ve devreye alma testi
Karar sahibi	BT / güvenlik ekibi	Üretim ve proses güvenliği sorumlusu ile ortak karar

Bu farkların ortak sonucu basit: OT planı, güvenlik ekibinin tek başına uygulayabileceği bir doküman değildir. Yazımına üretim müdürü, bakım şefi, otomasyon mühendisi ve İSG/proses güvenliği sorumlusu katılmalı. Masada üretim yoksa plan kâğıtta kalır.

Roller ve karar yetkisi: üretim, bakım, güvenlik

Olay sırasında en çok zaman kaybettiren şey teknik sorun değil, kimin hangi kararı verebileceğinin belirsizliğidir. Telefonlar dolaşır, herkes bir başkasının onayını bekler. Aşağıdaki matris bir başlangıç şablonu (K: karar verir, U: uygular, D: danışılır, B: bilgilendirilir):

Karar	Güvenlik	Üretim	Bakım/Otomasyon
Olayın ilanı ve önem seviyesi	K	D	D
IT/OT bağlantısının kesilmesi	U	K	D
Hattın durdurulması veya manuel moda geçiş	D	K	U
PLC programının geri yüklenmesi	D	B	K / U
Delil toplama	K / U	B	U (PLC/HMI tarafı)
Üretime dönüş onayı	D	K	D

Matriste iki noktayı mutlaka netleştirin. Birincisi gece ve hafta sonu vardiyası: bu kararları o saatte kim veriyor, vekilleri kim? İsimler ve telefonlar planda yazılı olmalı. İkincisi makine üreticisi (OEM) ve sistem entegratörünün rolü: hangi durumda çağrılacakları, hangi erişimle çalışacakları, olay sırasında uzaktan bağlanmalarına izin verilip verilmeyeceği. Bu son soru olay anında tartışılırsa saatler gider.

Tespit ve ilk değerlendirme

OT olayı farklı kapılardan gelir: OT izleme platformunun alarmı, IT’de başlayan bir fidye yazılımı olayı, operatörün “HMI kendi kendine değer değiştiriyor” bildirimi ya da açıklanamayan bir proses arızası. OT saldırı tespiti ne kadar iyi kurulmuş olursa olsun ilk sinyalin sahadan gelme ihtimali yüksektir. Operatörün şüpheli durumu kime ve nasıl bildireceği planda tanımlı olmalı; aksi halde bildirim arıza olarak bakıma gider, orada kalır.

İlk değerlendirmede yanıtlanacak sorular kısa bir kontrol listesiyle sabitlenir:

• Proses şu anda güvenli durumda mı? Emniyet sistemleri (SIS) normal çalışıyor mu?
• Operatör prosesi görebiliyor ve kontrol edebiliyor mu (HMI görüntüsü güvenilir mi)?
• Olay IT kaynaklı mı, OT içinde mi başladı? Etkilenen zon ve hücreler hangileri?
• Son 24 saatte onaylı bir değişiklik, bakım veya uzaktan erişim oturumu var mı?
• Olay yayılıyor mu (yeni etkilenen HMI, sunucu veya hücre)?

“Operatör prosesi göremiyor” ya da “HMI’daki değerlere güvenilmiyor” yanıtı olayı doğrudan en üst önem seviyesine taşır. O andan sonra konu bir siber güvenlik sorusu olmaktan çıkar, proses güvenliği prosedürlerine geçer.

İzolasyon karar ağacı: ağ kesme, manuel moda geçiş

İzolasyon seçenekleri en az etkiliden en etkiliye sıralanır ve her birinin hangi hatta ne sonuç doğuracağı önceden bilinir. Basitleştirilmiş karar ağacı:

1. Proses güvenliği riski var mı? Evet ise proses güvenliği prosedürü devreye girer: kontrollü duruş veya güvenli duruma alma. Siber adımlar bundan sonra gelir.
2. Olay yalnız IT tarafında mı? Evet ise IT/OT sınırındaki bağlantı kesilir, OT “ada modunda” çalıştırılır. Ön koşul, üretimin IT servisleri olmadan ne kadar sürdürülebileceğinin önceden bilinmesi; bu bağımlılık analizi fidye yazılımının OT’ye yayılma yolları rehberinde ele alınıyor.
3. Olay OT DMZ veya seviye 3 sistemlerinde mi? Historian, uzak erişim sunucusu veya patch sunucusu gibi sistemler OT’den ayrılır; HMI ve PLC trafiği devam eder.
4. Olay belirli HMI veya mühendislik istasyonlarında mı? Hücrede yedek HMI veya yerel operatör paneli varsa etkilenen istasyon ağdan ayrılır. Yoksa hat manuel moda alınır, operatör kontrolü sahaya kayar.
5. PLC programı veya set değerleri değiştirilmiş mi? Hat durdurulur, PLC tanılama bilgisi ve mevcut program alınır, doğrulanmış program geri yüklenir.

Her adımda “kim karar verir” matristen, “nasıl uygulanır” teknik eklerden okunur. Hangi switch portunun ya da firewall kuralının kapatılacağı olay anında aranmaz; önceden yazılmış ve bakım duruşunda denenmiş olmalı. Sahada en sık gördüğümüz eksik tam olarak bu: kesme kararı hızlı çıkar, ama hangi kablonun veya kuralın kesileceğini kimse bilmez.

OT’de delil toplama ve kayıt

OT’de delil toplama kurtarmayla yarışır. Üretim bir an önce başlamak ister; oysa PLC programı geri yüklendiği anda değiştirilmiş program kaybolur. Geri yüklemeden önce asgari delil seti alınmalı:

• PLC: Mevcut programın çevrim içi yedeği (upload), CPU tanılama tamponu (Siemens’te diagnostic buffer), mod ve çalışma durumu, firmware sürümü. Alınan program doğrulanmış referans proje dosyasıyla karşılaştırılır.
• HMI ve mühendislik istasyonu: Windows tabanlı sistemlerde bellek ve disk imajı, olay günlükleri, HMI uygulamasının alarm ve denetim kayıtları.
• Ağ: OT sensörünün olay öncesi ve sırasındaki paket veya oturum kayıtları, firewall ve switch logları.
• Proses verisi: Historian’daki ilgili tag’ler; set değeri ve çıkış değişikliklerinin zaman çizelgesi.

OT cihazlarında saat senkronizasyonu çoğu zaman zayıftır; NTP’ye hiç bağlanmamış PLC az değildir. Her delilin yanına cihazın o anki saatinin referans saatle farkını not edin, yoksa zaman çizelgesi kurulamaz. Delillerin hash değerinin alınması ve kimin ne zaman aldığının kaydı IT’deki gözetim zinciri uygulamasıyla aynıdır; ayrıntılar siber olay sonrası adli delil koruma rehberinde.

Kurtarma: PLC programı ve HMI geri yükleme

Kurtarmanın hızını olaydan önceki hazırlık belirler. Olay anında “son çalışan proje dosyası hangisi” diye aranıyorsa kurtarma saatlerce, bazen günlerce uzar. Mühendislik dizüstüsünde, bir USB bellekte ve OEM’in e-postasında üç farklı sürüm bulunur; hangisinin sahadakiyle aynı olduğunu kimse söyleyemez. Hazırlık şunları kapsar:

• Her PLC için doğrulanmış, sürümlü ve OT ağından bağımsız bir konumda saklanan proje dosyası ve hash değeri.
• HMI, SCADA ve mühendislik istasyonları için güncel sistem imajları, lisans dosyaları ve lisans anahtarlarının nasıl taşınacağının bilgisi.
• Firmware dosyaları ve üreticinin geri yükleme prosedürü.
• Temiz bir mühendislik istasyonu: kurtarma sırasında PLC’ye bağlanacak bilgisayarın etkilenmemiş olduğu kesin olmalı.

Geri yüklemeden sonra hat doğrudan üretime alınmaz. Otomasyon ekibi I/O kontrollerini, emniyet fonksiyonlarının testini ve kısa bir deneme çalışmasını içeren devreye almayı yapar; üretime dönüş onayını matristeki karar sahibi verir. Test edilmemiş geri yükleme, ikinci olaydır. IT tarafındaki kurtarma hazırlığının genel çerçevesi için fidye yazılımına karşı kurtarma hazırlığı rehberi bu bölümü tamamlar.

Plan doğrulama ve tatbikat

Yazılı plan ancak tatbikatla sınandığında güvenilir hale gelir. OT için önerdiğimiz sıra:

1. Masa başı tatbikat: Üretim, bakım, güvenlik ve yönetimle bir senaryo üzerinden karar akışı konuşulur. Hedef, karar yetkisi ve iletişim boşluklarını bulmak.
2. Teknik doğrulama: Bakım duruşunda IT/OT bağlantısını kesme adımı gerçekten uygulanır; üretimin hangi servislere bağımlı olduğu gözlenir. Lisans sunucusu, zaman sunucusu ve dosya paylaşımları bu testte sık sık sürpriz çıkarır.
3. Geri yükleme testi: Test ortamında veya bakım penceresinde bir PLC programı ve bir HMI imajı yedekten geri yüklenir; süre ölçülür.

Her tatbikatın çıktısı somut olmalı: güncellenen iletişim listesi, düzeltilen karar matrisi, eksik bulunan yedekler. Çıktısı olmayan tatbikat toplantıdır. Plan yapısı için NIST’in olay müdahale rehberi SP 800-61 Rev. 3, OT’ye özgü hususlar için SP 800-82 Rev. 3 başvuru kaynaklarıdır. Planın OT bölümünü hazırlamak ve ilk tatbikatı yürütmek için olay müdahale hazırlığı ve tatbikat hizmeti, OT tarafındaki teknik ön hazırlık için OT/ICS güvenlik hizmeti kullanılabilir.

Sık sorulan sorular

Mevcut IT olay müdahale planı OT için yeterli mi?

Çoğu zaman değil. IT planı izolasyonu ve kapatmayı varsayılan adım sayar; OT’de bu adımlar proses güvenliğini etkileyebilir. IT planının iskeleti korunur, üzerine OT’ye özgü roller, izolasyon karar ağacı ve kurtarma ekleri yazılır.

Olay anında IT/OT bağlantısını kesme kararını kim vermeli?

Kesmeyi teknik olarak güvenlik veya ağ ekibi uygular; üretime etkisi nedeniyle kararı üretim sorumlusuyla birlikte verir. Bu yetki ve vekilleri planda önceden yazılı olmalı.

PLC programını hemen geri yüklemek neden sorun olabilir?

Geri yükleme, değiştirilmiş programı ve tanılama bilgisini siler. Önce mevcut programın yedeği ve tanılama tamponu alınır, doğrulanmış referans programla karşılaştırılır, geri yükleme ondan sonra yapılır.

OT olay müdahale tatbikatı ne sıklıkla yapılmalı?

Sabit bir kural yok. Yaygın yaklaşım en az yılda bir masa başı tatbikat ve büyük organizasyon veya altyapı değişikliğinden sonra plan güncellemesidir. Teknik geri yükleme testleri planlı bakım duruşlarına bağlanabilir.