Stuxnet ve İran olayı: Bir yazılım fiziksel prosesi nasıl etkiledi?

Merhaba dostlar,

Stuxnet, 2010 yılında kamuoyunun gündemine giren ve endüstriyel sabotaj amacıyla incelenen bir zararlı yazılım ailesidir. Teknik araştırmalar, hedeflenen prosesin İran’daki Natanz uranyum zenginleştirme tesisiyle ilişkisini ortaya koymuştur. Konunun otomasyon açısından önemi, bir bilgisayar enfeksiyonunun PLC’nin kontrol işlevlerine uzanabilmesidir.

Bu olay, endüstriyel siber güvenliği yalnızca dosyaları koruma meselesi olarak düşünemeyeceğimizi gösterir. Bir tesiste veri bütünlüğü, üretim sürekliliği ve fiziksel proses güvenliği birlikte değerlendirilmelidir.

Bilgisayar ile PLC arasındaki güven ilişkisi

Stuxnet’in bilinen mekanizmalarından biri, mühendislik bilgisayarındaki Siemens STEP 7 ortamını etkilemekti. PLC programlama yazılımı üzerinden yapılan iletişime müdahale ederek denetleyiciye kod ekleyebiliyor, kod bloklarının okunması sırasında bu değişiklikleri gizleyebiliyordu. Dolayısıyla PLC programının görünürde doğru olması, kontrol zincirinin bütünüyle güvenilir olduğunu göstermiyordu.

Burada iki farklı konuyu ayırmak gerekir: WinCC veritabanındaki sabit kodlanmış parola, raporlarda bilgisayarlara yayılmayla ilişkili bir mekanizmadır. PLC koduna müdahale ise STEP 7 iletişim katmanının ele geçirilmesiyle açıklanır. Olayı “veritabanı şifresi bulundu ve PLC programı değiştirildi” şeklinde özetlemek bu ayrımı kaybettirir.

USB, ağ ve internetten ayrılmış sistemler

İncelenen Windows sürümleri çıkarılabilir ortamlar ve ağ üzerinden yayılma yöntemleri kullanıyordu. Microsoft’un analizinde, savunmasız Windows sistemlerinde özel hazırlanmış kısayol simgelerinin görüntülenmesinin bile çalıştırmayı tetikleyebildiği açıklanır. Ancak bilinen bir yayılma yöntemi, Natanz’a ilk girişin kesin kanıtı değildir.

Stuxnet 0.5 için STEP 7 proje dosyaları üzerinden yayılma raporlanmıştır. Bu nedenle “internete bağlı değil” ifadesi, bakım bilgisayarları ve dosya aktarımları bulunan bir tesis için tek başına güvenlik güvencesi sayılmaz. Endüstriyel haberleşme değerlendirilirken dosyanın ve cihazın tesise nasıl girdiği de sorulmalıdır.

Her bulaşan bilgisayar fiziksel saldırının hedefi miydi?

Hayır. Bilgisayara bulaşma ile belirli bir prosese yönelik zararlı işlevin devreye girmesi farklı durumlardır. Analizler, belirli donanım ve proses koşullarının arandığını gösterir. Hız kontrolüne yönelik bileşenlerde PROFIBUS haberleşmesi ve Vacon ile Fararo Paya üretimi belirli frekans konvertörleri öne çıkar.

Kontrol zincirini anlamak için PLC CPU’sunu, giriş ve çıkış modüllerini, haberleşmeyi ve bağlı ekipmanı birlikte düşünün. Yazılım komutu, bu zincir üzerinden motorun veya vananın gerçek davranışına dönüşür.

Hız müdahalesi ile vana ve basınç müdahalesi aynı değildir

Bu ayrım, PLC’nin endüstriyel otomasyondaki rolünü de hatırlatır: aynı kontrol teknolojisi farklı proseslerde farklı fiziksel sonuçlar üretebilir.

Ekrandaki “normal” görüntü neden yeterli değildi?

Kod değişikliğini gizlemek ile proses değerlerini yanıltmak ayrı mekanizmalardır. Langner’in vana ve basınç saldırısına ilişkin analizinde, kaydedilmiş normal sensör değerlerinin tekrar sunulması açıklanır. Bu bulguyu bütün Stuxnet sürümlerine aynı şekilde uygulamak doğru değildir.

SCADA ekranı, aldığı veriyi gösterir. Bu nedenle PLC ile SCADA arasındaki veri ilişkisi önemlidir. Örneğin bir PID kontrolünde ekrandaki ölçüm, komut ve fiziksel tepki birbiriyle tutarlı mı? Bir veri kaydedici aynı şüpheli veri kaynağını kullanıyorsa, ek bir kayıt bağımsız doğrulama sağlamayabilir.

PLC güvenliği için uygulanabilir dersler

Erişimi ve aktarımı kontrol edin: NIST’in OT güvenliği rehberi; ağların bölümlenmesini, gerekli iletişimin sınırlandırılmasını ve yetkisiz çıkarılabilir ortamların engellenmesini önerir. Ethernet ağı üzerindeki bağlantılar ve IoT bağlantıları bu kapsamda değerlendirilmelidir.

Geri dönüşü hazırlayın: Korunan yedekler oluşturun, geri yüklemeyi sınayın ve program değişikliklerini izleyin. PLC sistemlerinde güvenlik, bakım ve değişiklik yönetiminin de parçasıdır.

Güncellemeyi prosese göre planlayın: Koruma yazılımlarını ve güncellemeleri üretici önerilerine göre, operasyon üzerindeki etkilerini değerlendirerek uygulayın. PLC’de hata ayıklama sırasında program, alarm ve fiziksel ölçüm arasındaki tutarsızlıkları da araştırın.

Örnek kontrol sorusu: Bakım bilgisayarı değiştiğinde kimlik ve yetkiler yeniden kontrol ediliyor mu? Son program yüklemesinin nedeni kayıtlı mı? Şüpheli ekran değerini doğrulayacak ölçüm gerçekten bağımsız mı? Bu sorular, tesisin kendi risk değerlendirmesine somut başlangıç noktaları sağlar.

Olayın siyasi boyutu ve izleme önerisi

Teknik bulgular, saldırının çalışma biçimi ve hedeflenen proses hakkında bilgi verir. Saldırının kime atfedildiği ise ayrı bir kanıt değerlendirmesidir; bu sayfa teknik analizden hareketle bir devletin sorumluluğunu kesinleştirmez. Bağlamı keşfetmek için Alex Gibney’in Zero Days (2016) belgeseli izlenebilir. Belgesel anlatımı ile teknik raporun kanıt kapsamı birbirinden ayrılmalıdır.

Teknik kaynaklar

PLC iletişimi ve hedef tespiti için Symantec W32.Stuxnet Dossier; eski sürümün farkları için Stuxnet 0.5: The Missing Link; proses analizi için Ralph Langner: To Kill a Centrifuge incelenebilir. Windows tarafı için Microsoft Stuxnet analizi, korunma yaklaşımı için NIST SP 800-82 Rev. 3 kullanılabilir.