IEC 62443-3-3 Güvenlik Seviyeleri: SL-T, SL-C ve SL-A Nasıl Belirlenir?

Zonlar ve kanallar çizildi; şimdi yönetim “bu zon ne kadar güvenli olmalı?” diye soruyor. “Yeterince” bir cevap değildir. IEC 62443-3-3 bu soruya güvenlik seviyesi (Security Level, SL) ve yedi temel gereksinim üzerinden ölçülebilir bir cevap verir. Aşağıda SL-T, SL-C ve SL-A ayrımını, standardın gereksinim yapısının nasıl okunacağını, bir zon için hedef seviye belirlemeyi ve mevcut sistemle boşluk analizini, sahada en sık karıştırılan noktalarla birlikte anlatıyoruz.

IEC 62443-3-3’ün serideki yeri

IEC 62443 serisi dört gruptan oluşur: genel kavramlar (1-x), varlık sahibinin güvenlik programı ve politikaları (2-x), sistem düzeyi gereksinimler (3-x) ve bileşen/ürün geliştirme gereksinimleri (4-x). 3-3, sistem düzeyindeki teknik güvenlik gereksinimlerini ve bunların hangi güvenlik seviyesinde zorunlu olduğunu tanımlar.

Sahada üç doküman birlikte açık durur:

• IEC 62443-3-2: Risk değerlendirmesi, sistemin zon ve kanallara bölünmesi ve her zon için hedef güvenlik seviyesinin belirlenme süreci.
• IEC 62443-3-3: Bir zonun belirli bir güvenlik seviyesini karşılaması için sistemde bulunması gereken teknik yetenekler.
• IEC 62443-4-2: Aynı gereksinimlerin tek tek bileşenlere (PLC, HMI, switch, firewall, sunucu yazılımı) indirgenmiş hali.

Zonların nasıl çizileceği IEC 62443’te zon ve kanal yaklaşımı yazısında anlatıldı; burada o çalışmanın bir sonraki adımı olan seviye atamasına geçiyoruz.

SL-T, SL-C ve SL-A kavramları

Standart güvenlik seviyesini, karşı korunulan tehdidin niteliğine göre tanımlar:

Seviye	Korunulan tehdit
SL 1	Kasıtsız veya tesadüfi ihlal
SL 2	Basit araçlar, düşük kaynak, genel beceri ve düşük motivasyonla kasıtlı ihlal
SL 3	Gelişmiş araçlar, orta düzey kaynak, IACS’e özgü beceri ve orta motivasyonla kasıtlı ihlal
SL 4	Gelişmiş araçlar, geniş kaynak, IACS’e özgü beceri ve yüksek motivasyonla kasıtlı ihlal

Aynı ölçek üç farklı bağlamda kullanılır. Toplantılarda en sık karıştırılan şey de budur:

• SL-T (Target): Risk değerlendirmesi sonucunda bir zon veya kanal için istenen seviye. Bir karardır; varlık sahibi verir.
• SL-C (Capability): Bir sistemin veya bileşenin, doğru yapılandırıldığında sağlayabileceği seviye. Ürün ya da çözüm özelliğidir; üretici veya entegratör beyan eder.
• SL-A (Achieved): Sahada kurulu ve işletilen sistemin gerçekte ulaştığı seviye. Ölçülür ve zamanla değişir. Kapatılmamış bir servis veya panoya yapıştırılmış ortak bir parola SL-A’yı SL-C’nin altına çeker.

SL tek bir sayı değildir. Her biri yedi temel gereksinimden birine karşılık gelen bir vektördür: SL-T(Zon) = {FR1, FR2, FR3, FR4, FR5, FR6, FR7}. Örneğin gizliliğin düşük, bütünlüğün yüksek önem taşıdığı bir kontrol zonu için {2, 2, 3, 1, 2, 2, 2} gibi bir hedef, tek bir “SL 2” etiketinden çok daha fazla şey söyler. Tek sayı ya parayı yanlış yere harcatır ya da açığı gizler.

Yedi temel gereksinim (FR1–FR7)

FR	Ad	OT’deki tipik karşılığı
FR1	Tanımlama ve kimlik doğrulama (IAC)	Kişisel hesaplar, MFA, cihaz kimliği
FR2	Kullanım kontrolü (UC)	Rol bazlı yetki, oturum kilidi, taşınabilir medya
FR3	Sistem bütünlüğü (SI)	Yazılım bütünlüğü, zararlı yazılım koruması, giriş doğrulama
FR4	Veri gizliliği (DC)	Aktarım ve saklamada şifreleme
FR5	Kısıtlı veri akışı (RDF)	Segmentasyon, zon sınırı koruması
FR6	Olaylara zamanında yanıt (TRE)	Denetim kaydı erişimi, sürekli izleme
FR7	Kaynak erişilebilirliği (RA)	DoS dayanımı, yedekleme, kurtarma

OT altyapısında FR’ler eşit ağırlıkta değildir. Bir dolum hattında reçete verisinin gizliliği (FR4) çoğu zaman düşük önceliklidir; setpoint bütünlüğü (FR3) ve hattın erişilebilirliği (FR7) ise doğrudan üretim ve emniyet sonucudur. Vektör yaklaşımı bu farkı kâğıda dökmeye yarar.

SR ve RE yapısı nasıl okunur

Her FR numaralı sistem gereksinimlerine (SR) ayrılır; her SR’nin bir temel gereksinimi ve isteğe bağlı gereksinim iyileştirmeleri (RE) vardır. Bir SL’ye ulaşmak için o seviyede işaretli temel gereksinim ve RE’lerin tamamı karşılanmalıdır. Biri eksikse seviye tutmaz. Okuma mantığını üç örnek yeter:

Gereksinim	SL 1	SL 2	SL 3	SL 4
SR 1.1 İnsan kullanıcı tanımlama ve kimlik doğrulama	Temel	+ RE1 tekil (kişiye özgü) tanımlama	+ RE2 güvenilmeyen ağlardan MFA	+ RE3 tüm ağlarda MFA
SR 5.1 Ağ segmentasyonu	Temel	+ RE1 fiziksel segmentasyon	+ RE2 kontrol dışı ağlardan bağımsızlık	+ RE3 kritik ağların mantıksal ve fiziksel izolasyonu
SR 5.2 Zon sınırı koruması	Temel	+ RE1 varsayılan ret, istisnayla izin	+ RE2 ada modu, RE3 kapalı konumda arıza (fail close)	Aynı

Tablodan iki pratik sonuç çıkar. Birincisi, “paylaşılan operatör hesabı” kullanılan bir HMI, SR 1.1 RE1 yüzünden FR1’de SL 2’yi karşılayamaz; sahada boşluk analizinin ilk kırmızı satırı genellikle budur. İkincisi, SR 5.2 RE3 (fail close) SL 3 hedefli bir zonda bypass özellikli firewall kullanımını sorgulatır; yerleşim modu ve bypass kararı için hücre seviyesinde firewall: transparan mı routed mı yazısına bakabilirsiniz. Bazı SR’ler SL 1’de hiç istenmez; örneğin sürekli izleme (SR 6.2) SL 2’den itibaren zorunludur.

Bir zon için SL-T belirleme adımları

Standart, risk değerlendirmesinden SL-T’ye giden hazır bir formül vermez; IEC 62443-3-2 süreci tarif eder, eşikleri ve matrisleri varlık sahibi tanımlar. Sahada işleyen yöntem şu:

1. Zonun sonuç profilini çıkarın. Zondaki sistemler ele geçirilirse veya durursa ne olur? Emniyet, çevre, üretim kaybı, kalite ve yasal yükümlülük başlıklarında en kötü gerçekçi sonucu yazın.
2. Tehdit profilini belirleyin. Zona kim, hangi kanaldan ulaşabilir? İnternet bağlantılı bir uzaktan erişim kanalı olan zon ile hiçbir dış kanalı olmayan zon aynı profile sahip değildir.
3. Kuruluşun eşleme matrisini uygulayın. Sonuç ciddiyeti ve tehdit profilini SL’ye eşleyen bir matris tanımlayın; matris kuruluş genelinde tek olmalı ve onaylanmalıdır. Her tesisin kendi matrisi olursa seviyeler karşılaştırılamaz.
4. FR bazında ayarlayın. Genel seviyeyi her FR için ayrı değerlendirin: gizliliği önemsiz zonda FR4’ü düşürmek, emniyet fonksiyonu taşıyan zonda FR3 ve FR7’yi yükseltmek gibi.
5. Kanalları ayrıca değerlendirin. Kanalın SL-T’si, bağladığı zonlardan yüksek olanın gereksinimlerini taşıyabilmelidir. Uzaktan erişim kanalı çoğu zaman zonların kendisinden yüksek hedef ister.
6. Belgeleyin ve onaylatın. SL-T vektörü, gerekçesi ve varsayımlar zon kaydına yazılır, varlık sahibi imzalar.

Sonuç ve tehdit analizinin güvenlik operasyonu tarafı OT siber güvenlik risk değerlendirmesi rehberinde ayrıca işleniyor.

SL-C ile boşluk analizi örnek tablosu

SL-T belirlendikten sonra zondaki sistemin SL-C’si FR bazında çıkarılır. Bileşenlerin üretici beyanları (varsa IEC 62443-4-2 uyum beyanı veya sertifikası) sistemin neyi yapabileceğini gösterir. Mevcut bir tesiste aynı tabloya sahadaki gerçek yapılandırmadan çıkan SL-A tahminini ayrı sütun olarak eklemek işe yarar: yetenek var ama kullanılmıyorsa boşluk SL-A’da görünür. Aşağıdaki tablo bir paketleme hattı hücresi için örnek bir boşluk analizidir:

FR	SL-T	SL-C	Boşluk ve önlem
FR1	2	1	HMI’de ortak hesap; kişisel hesaplara geçiş veya atlama sunucusunda kişisel hesap
FR2	2	1	PLC’de rol ayrımı yok; mühendislik erişimi tek istasyona sınırlanır
FR3	2	2	Boşluk yok; PLC koruma seviyesi devrede tutulur
FR4	1	1	Boşluk yok
FR5	2	1	Düz ağ; hücre firewall’u ile varsayılan ret politikası
FR6	2	1	Log toplanmıyor; firewall ve HMI logları merkezi sisteme
FR7	2	2	Boşluk yok; PLC proje yedekleri doğrulanır

Boşluk tablosunun her satırı sorumlusu ve hedef tarihi olan bir aksiyona dönüşmelidir. Sahibi olmayan satır kapanmaz. Kimlik tarafındaki boşluklar için mimari seçenekler OT için ayrı Active Directory yazısında karşılaştırılıyor.

Telafi edici önlemler ve sınırları

Sahadaki PLC’lerin çoğu FR1 ve FR2’de düşük SL-C’ye sahiptir ve bu, ürünü değiştirmeden düzelmez. IEC 62443-3-3 bu durumda telafi edici önlemlere izin verir: bileşenin karşılayamadığı gereksinim, zon veya kanal düzeyinde başka bir kontrolle karşılanır. Tipik örnekler:

• Kimlik doğrulaması olmayan PLC’ye erişimin yalnız MFA’lı atlama sunucusu üzerinden ve firewall kuralıyla sınırlanması.
• Log üretemeyen saha cihazlarının trafiğinin pasif izlemeyle kayda alınması.
• Yama alamayan sunucunun ayrı bir alt zona alınıp yalnız gerekli akışlara açılması.

Sınırlarını da açıkça yazın. Zon sınırında uygulanan bir telafi, zonun içinden gelen tehdide karşı koruma sağlamaz: hücreye fiziksel erişimi olan biri ya da hücre içindeki ele geçirilmiş bir HMI, kimlik doğrulamasız PLC’ye yine yazabilir. Bu yüzden telafi edici önlemle ulaşılan SL-A, varsayımlarıyla birlikte (örneğin “hücre panosuna fiziksel erişim kontrollüdür”) kaydedilir. Telafi kalıcı çözüm değildir. Ürün yenileme planında SL-C’si yeterli bileşen seçimi şartnameye yazılmalıdır.

SL-A’yı zaman içinde korumak için kontrol listesi:

• Zon kaydında SL-T vektörü, gerekçe ve onay tarihi var mı?
• Her boşluk için aksiyon, sorumlu ve hedef tarih tanımlı mı?
• Telafi edici önlemlerin varsayımları yazılı mı ve periyodik olarak doğrulanıyor mu?
• Firewall kuralı, hesap ve servis değişiklikleri SL-A üzerindeki etkisi açısından değişiklik sürecinde değerlendiriliyor mu?
• Yeni bileşen alımlarında hedef zonun SL-T’si şartnamede yer alıyor mu?

Standardın kapsamı ve güncel bölümleri için ISA/IEC 62443 seri sayfası birincil kaynaktır. Mevcut tesiste zon ve boşluk analizini sahadan başlatmak için fabrika OT altyapı keşfi, uygulama tarafı için OT siber güvenlik ve segmentasyon sayfalarımıza bakabilirsiniz.

Sık sorulan sorular

Bir zonun SL-T değeri tek bir sayı olarak verilebilir mi?

Kısaltma olarak verilebilir, ama standardın yaklaşımı yedi temel gereksinim için ayrı değerlerden oluşan bir vektördür. Tek sayı, gizlilik gibi düşük öncelikli bir alanda gereksiz yatırıma, bütünlük gibi kritik bir alanda eksik korumaya yol açabilir.

Üreticinin SL 2 sertifikalı PLC’si zonu otomatik olarak SL 2 yapar mı?

Hayır. Sertifika bileşenin SL-C değerini gösterir; zonun SL-A değeri bu bileşenin sahada nasıl yapılandırıldığına, zondaki diğer sistemlere ve işletme uygulamalarına bağlıdır. Ortak parola veya kapatılmamış bir servis SL-A’yı düşürür.

SL 3 veya SL 4 hedefi hangi tesisler için uygundur?

Ele geçirilmesi emniyet, çevre veya geniş çaplı hizmet kesintisi sonucu doğurabilecek ve hedefli saldırgan profiline açık tesislerde bu seviyeler gündeme gelir. Karar kuruluşun risk matrisiyle ve somut sonuç analiziyle verilir; sektöre bakılarak otomatik atanmaz.

Telafi edici önlemlerle SL-T’ye ulaşmak kabul edilir mi?

IEC 62443-3-3 telafi edici önlemlere izin verir. Ama önlemin hangi gereksinimi, hangi varsayımla karşıladığı belgelenmeli ve zon içinden gelen tehditlere karşı sağlamadığı koruma açıkça kayda geçirilmelidir.