Şehrin Görünmeyen State Machine’i: Trafik Sinyallerinde Siber Dayanıklılık

Kaldırımdaki Gri Kutu Nedir?

Günlük hayatta trafik ışığı olarak gördüğümüz şey, aslında bir kontrol sisteminin son çıktısıdır. Kırmızı, sarı ve yeşil lambalar karar vermez; karar, yol kenarındaki kabinde bulunan denetleyici, dedektörler, I/O bileşenleri ve güvenlik izleme devreleri tarafından verilir. Bu yüzden kavşağı yalnızca bir lamba seti gibi düşünmek yanıltıcıdır. Daha doğru benzetme şudur: Kavşak, fiziksel dünyaya etkisi olan, zaman kısıtlı bir state machine’dir.

Metin NEMA/NTCIP ekosistemini temel alır. Bu mimari özellikle Kuzey Amerika pratiğinde yaygındır; her ülke, belediye veya üretici aynı denetleyici, protokol profili ya da kabin düzenini kullanmaz. Temel ders coğrafyadan bağımsızdır: denetim mantığı, sensör verisi, saha kabini ve merkezi yönetim birbirine bağlandığında klasik IT’den farklı bir OT saldırı ve savunma yüzeyi ortaya çıkar.

Bu bir saldırı kılavuzu değildir. Gerçek trafik altyapısına erişim veya müdahale hem tehlikeli hem de hukuka aykırıdır. Amaç, yetkili ekiplerin kendi test ortamlarında hangi davranışları izlemesi gerektiğini ve bir sinyalizasyon ağının nasıl daha dayanıklı hâle getirileceğini anlatmaktır.

Terim notu: Metin boyunca controller için denetleyici, detector için dedektör, signal head için sinyal başlığı, load switch için yük anahtarı kullanıyorum. NTCIP, NEMA ve üretici dokümanlarında geçen İngilizce kısaltmalar (CU, BIU/SIU, MMU/SMU/CMU) teknik eşleştirme gerektiğinde korunuyor.

Kabinin İçindeki Roller: Kontrol, Güç, İzleme

Bir trafik denetleyicisi kabininde her parça aynı işi yapmaz. NTCIP 1202’nin tarif ettiği tipik düzen; denetleyici birimi, kabin alt sistemleri, dedektörler, yük anahtarları, flaşörler ve sinyal izleme birimini birlikte ele alır. Signal Monitoring Unit (SMU), NEMA TS 2 terminolojisinde Malfunction Management Unit (MMU) olarak da anılır; kabin içi anormallikte sistemi güvenli yanıp-sönme moduna alabilecek bağımsız bir güvenlik katmanıdır. NTCIP 1202 v03B

Bu ayrım önemlidir. “Denetleyiciye erişen biri her şeyi yapar” cümlesi teknik olarak zayıftır. Fiziksel sinyal çıkışı; denetleyici mantığı, kabin kablolaması, yük anahtarları, güvenlik izleme birimi, yapılandırılmış geçiş süreleri ve saha politikasının birlikte ürettiği sonuçtur. Güvenlik değerlendirmesi de aynı bütünlükte yapılmalıdır.

Bir kabini üç düzlemde okumak faydalıdır:

Süreç düzlemi: Fazlar, sarı/all-red temizleme süreleri, yaya fazları, koordinasyon ve preemption kuralları.
Saha düzlemi: Sinyal başlıkları, dedektörler, pull box’lar, kabin içi I/O ve güç bileşenleri.
Yönetim düzlemi: Merkezden gelen yapılandırma, durum izleme, zaman senkronizasyonu, bakım erişimi ve olay kayıtları.

En sık hata üçüncü düzlemi sıradan bir “network management” servisi saymaktır. Yönetim düzlemi, sonuçta fiziksel davranışı etkileyen bir işletim düzlemidir; bu yüzden erişim modeli, kayıt kalitesi ve değişiklik kontrolü doğrudan güvenlik konusudur.

Kabin anatomisi: hangi parça hangi sorumluluğu taşır?

“Denetleyici” diye tek kelimeyle anlattığımız şey pratikte bir bileşen topluluğudur. NTCIP 1202’nin kabin alt sistemi açıklaması, bu parçaları işlevlerine göre ayırır:

Controller Unit (CU): Faz mantığını, zamanlamayı, çağrıları ve işletim modunu yorumlayan karar katmanı.
Bus/Serial Interface Unit veya Parallel I/O: Denetleyici ile kabin alt sistemleri arasındaki iletişim katmanı. NEMA TS 2 bağlamında BIU, ITS Cabinet Standard bağlamında SIU adıyla görülebilir.
Power distribution: Bileşenlere korumalı enerji dağıtımı yapan katman. Güç kalitesi, kontrol sisteminin sıradan ama kritik bağımlılığıdır.
Load switches: Sinyal göstergilerine, yaya göstergelerine ve yardımcı çıkışlara giden gücü anahtarlayan elemanlar.
Flashers: Güvenli yanıp-sönme işletimini üretmek için kullanılan devre elemanları.
SMU/MMU/CMU: Çatışan göstergeler, hatalı kabin davranışı veya düşük hat gerilimi gibi durumlarda kabini güvenli moda alabilen izleme katmanı.
Detector units: Araç, yaya, bisiklet, toplu taşıma veya acil araç gibi yol kullanıcılarını algılayan giriş katmanı.

Bu ayrım iki sonucu öne çıkarır. Güvenlik testi yalnızca “yazılım zafiyeti” aramaz; güç, kablo, I/O, dedektör sağlığı ve işletim modu da kapsamda olmalıdır. Güvenlik kontrolleri eklenirken denetleyicinin gerçek zamanlı davranışı bozulmamalıdır. Ağ üzerindeki denetim, kabin emniyet fonksiyonunun gecikme veya kullanılabilirlik bütçesini tüketmemelidir. NTCIP 1202 kabin alt sistemleri

MMU’nun rolü neden hem çok önemli hem de sınırlıdır?

MMU/CMU, “her riskten koruyan akıllı kutu” değildir. Görevi, tanımlı kabin ve gösterge arızalarını izlemek; belirli hata koşullarında flaşör üzerinden güvenli bir işletime geçiş sağlamaktır. NTCIP 1202, bu katmanın kısa devre yapan load switch, arızalı güç kaynağı, çatışan sinyal göstergesi veya düşük hat voltajı gibi durumlarda rol oynadığını anlatır. Güç geri geldiğinde denetleyicinin başlatılması için kabini başlangıç flaş durumunda tutması da bu tasarımın parçasıdır.

Fakat MMU; kötü tasarlanmış uzaktan erişim, yanlış zaman planı, hatalı sensör verisi, yetersiz değişiklik onayı veya tedarikçi hesabının denetlenmemesi gibi sorunları çözmez. İyi yayınlarda bu ayrım özellikle önemlidir: fiziksel emniyet katmanı, siber dayanıklılığın yerine geçmez; ona zaman kazandırır ve bazı fiziksel sonuçları sınırlayabilir.

Faz Tabanlı ve Aralık Tabanlı Denetleyiciler: Aynı Işık, Farklı Mantık

Trafik sinyallerinin dışarıdan aynı görünmesi, iç mantıklarının aynı olduğu anlamına gelmez. NTCIP 1202, faz tabanlı ve aralık tabanlı denetleyiciler arasında ayrım yapar. Faz tabanlı denetleyicide, çakışmayan hareketleri yöneten fazlar trafik koşulları ve programlanmış zamanlama kısıtlarına göre çalışır. Tam aktüasyonlu sistemde çağrı olmayan fazlar atlanabilir; yeşil süreleri minimum ve maksimum sınırlar arasında değişebilir. Aralık tabanlı denetleyici ise tekrar eden çevrimde tanımlı ayrık adımları sürer; bazı adımlar koşullara göre gösterilebilir veya atlanabilir. NTCIP 1202 v03B, standart arayüz bakımından faz tabanlı denetleyicileri kapsar. NTCIP 1202 controller types

Bu ayrım bir güvenlik araştırmasının dilini değiştirir. Faz tabanlı ortamda izleme; çağrı, minimum/maksimum, gap, uzatma ve faz atlama davranışına daha çok odaklanır. Aralık tabanlı ortamda ise çevrim, sıra, zaman çizelgesi ve geçiş mantığı ağırlık kazanabilir. Bir sistemi bilmeden “normalde her faz 25 saniye sürer” gibi cümleler kurmak bu nedenle teknik olarak savunulamaz.

Pre-timed, yarı aktüasyonlu, tam aktüasyonlu ve adaptif işletim

Pre-timed işletimde denetleyici önceden tanımlanmış süreleri takip eder. Bu, basit olduğu anlamına gelir; fakat talep değiştiğinde gereksiz bekleme üretebilir.

Yarı aktüasyonlu işletimde ana hareket sıklıkla servis alırken ikincil yaklaşım veya dönüşler dedektör çağrısıyla devreye girer.

Tam aktüasyonlu işletimde fazlar, dedektör çağrılarına ve süre sınırlarına göre seçilir, uzatılır veya atlanır.

Adaptif işletim ise daha geniş veri akışından yararlanarak zamanlama kararlarını sürekli günceller; tek kavşak yerine koridor veya alan düzeyinde karar üretme eğilimindedir.

Bu modlar birbirinin “güvenli/güvensiz” alternatifi değildir. Her birinin farklı görünürlük ve değişiklik yönetimi ihtiyacı vardır. Örneğin adaptif kontrolün daha fazla sensör ve daha çok veri kullanması, veri kalitesi izleme ihtiyacını büyütür. Sabit zamanlı planın daha az dış girdiye dayanması ise yanlış veya eski bir planın uzun süre fark edilmeden kalması riskini doğurur.

Preemption ile Priority Aynı Şey Değildir

Bu ikisi genellikle aynı kelimeyle anlatılıyor, oysa operasyon etkileri farklıdır. Preemption, normal işletimden özel bir kontrol moduna geçiştir; acil araç, tren veya benzeri yüksek öncelikli durumlarda normal fazlamayı ve koordinasyonu kesebilir. Priority ise çoğunlukla toplu taşıma gibi kullanıcılar için yeşil uzatma veya kırmızı kısaltma gibi daha sınırlı zamanlama ayarlarıyla hizmet vermeyi amaçlar; normal koordinasyonu tamamen ezmek zorunda değildir.

Bu ayrım, tespit mantığını da değiştirir. Preemption olayı için kaynak, yön, giriş/çıkış geçişi, minimum dwell ve geri dönüş durumu anlamlıdır. Priority olayı için ise hangi zamanlama düzeltmesinin hangi performans hedefi adına yapıldığı önemlidir. Her ikisini tek “acil mod” alanında toplamak, hem mühendislik hem güvenlik incelemesini yüzeyselleştirir. FHWA, preemption’ın normal işletimi kesebildiğini; priority’nin ise farklı yöntemlerle zamanlama ayarı yaptığını açıklar. FHWA preemption ve transit priority

Saha açısından en kritik ilke şudur: Gerçek acil durum geçişi güvenlik için bir istisna yaratabilir, ama bu istisnanın kendisi de izlenebilir olmalıdır. İstek geldi, denetleyici güvenli geçişi tamamladı, öncelik verildi, istek kalktı ve sistem koordinasyona döndü: her aşamanın kaydı olmalıdır. “Preemption aktifti” tek başına yeterli olay kaydı değildir.

Phase, Ring ve Barrier: State Machine’in Dili

Kavşak mantığı tek bir zamanlayıcı değildir. Faz, belirli ve birbiriyle çakışmayan hareketlere hizmet veren kontrol birimidir. Ring–barrier modeli ise uyumlu hareketlerin hangi sırayla ilerleyebileceğini tanımlar. Araç çağrısı olan bir fazın uzatılması, çağrısı olmayan bir fazın atlanması, yaya geçişi ve ana arter koordinasyonu aynı state machine içinde değerlendirilir.

Güvenlik açısından “ışık yeşile döndü mü?” sorusu tek başına yeterli değildir. Daha yararlı sorular şunlardır:

Bu faz normalde hangi koşullarda çağrılır, uzar veya sonlanır?
Sarı ve all-red temizleme süreleri politika ile uyumlu mu?
Bir preemption sonrasında denetleyici koordinasyona ne zaman ve nasıl dönüyor?
Yaya çağrıları, dedektör sağlığı ve araç yoğunluğu olay günlükleriyle tutarlı mı?

FHWA, preemption’ın normal sinyal işletimini geçici olarak değiştirdiğini; ancak araç sarı ve all-red temizleme sürelerinin atlanmaması gerektiğini açıkça belirtir. Yani güvenli geçişler “ani yeşil”den daha önemlidir. FHWA Traffic Signal Timing Manual

Sensörler: Kavşağın Gözleri ve En Sessiz Hata Kaynağı

Adaptif veya trafik uyarmalı işletim, kararını girdilerden alır. En klasik örnek indüksiyon döngüsüdür: asfalta gömülü tel halka, araçtaki iletken metalin etkisiyle devrenin indüktansındaki değişimi algılar; kabindeki elektronik birim bunu denetleyiciye araç çağrısı olarak iletir. Döngü, lead-in kablo, pull box ve elektronik birimden oluşan bu zincirin tamamı ölçüm sistemidir. FHWA Traffic Detector Handbook

Kamera, radar, manyetometre ve diğer algılayıcılar farklı hata türleri üretir. Bu nedenle “kamera varsa loop’a gerek yok” veya “radar varsa veri doğrudur” yaklaşımı zayıftır. İşletme açısından asıl soru, verinin inandırıcı değil doğrulanmış olup olmadığıdır.

Örneğin döngü arızası sürekli aktif çağrı yaratabilir. FHWA’nın yüksek çözünürlüklü sinyal performans verisi örneğinde, düşük talep beklenen zamanlarda tekrar eden maksimum yeşil (“max-out”) davranışı dedektör arızası için güçlü bir sinyal kabul edilir. Bu davranışın gerçek yoğunlukla mı, hatalı sensörle mi ilişkili olduğunu kamera, komşu dedektör ve geçmiş zaman serisiyle çapraz doğrulamak gerekir. FHWA detector-health örneği

Savunma açısından dört veri bir arada tutulmalıdır:

Dedektör çağrısı, occupancy ve süre ölçümleri
Faz başlangıç/bitiş ve maksimum süre olayları
Preemption ve öncelik istekleri
Saha gözlemi: kamera, bakım kaydı veya yetkili operatör doğrulaması

Tek bir sensör, tek başına hüküm veren bir güvenlik kaynağı olmamalıdır.

Döngüden kararına: küçük bir elektrik değişimi neden operasyonel olaya dönüşür?

İndüksiyon döngüsü, “yolda araç var / yok” ikiliğinden biraz daha fazlasıdır. Denetleyici, çağrının hangi faza bağlı olduğunu; çağrının ne kadar sürdüğünü; geçiş için minimum sürelerin dolup dolmadığını; başka bir fazın çağrı alıp almadığını ve koordinasyon planının hangi noktasında olduğunu birlikte yorumlar. Aynı sensör olayı, boş bir gece kavşağında fazı hızlıca çağırabilir; sabah pikinde ise yalnızca yeşil uzatma mantığına küçük bir katkı verebilir.

Burada güvenlik ekibinin trafik mühendisliğiyle ortak bir dil kurması gerekir. “Sürekli çağrı gördük” bulgusu tek başına yeterli değildir. Bu çağrının bağlı olduğu hareket, günün saati, yaklaşım yoğunluğu, kavşak geometrisi, yaya talebi ve komşu sinyallerden gelen platoon akışı birlikte incelenmelidir. Bir SOC analisti için anomali olan şey, trafik mühendisi için planlı koordinasyon olabilir. Tersine, normal görünen bir yüksek occupancy değeri, saha ekipmanındaki arızanın ilk işareti olabilir.

Bu nedenle her kavşağın en azından aşağıdaki normal davranış kartı olmalıdır:

Alan	Kayda geçmesi gereken bilgi
İşletim modu	Sabit zamanlı, yarı aktüasyonlu, tam aktüasyonlu veya adaptif çalışma
Faz haritası	Hangi hareketin hangi faz/koruma mantığıyla hizmet aldığı
Süre sınırları	Minimum yeşil, geçiş, yaya temizleme, maksimum yeşil ve all-red değerleri
Sensör bağları	Sensörün konumu, kapsadığı şerit, bağlı olduğu çağrı ve bakım sahibi
Kritik istisnalar	Okul çıkışı, etkinlik, raylı sistem, hastane koridoru veya planlı preemption
Güvenli fallback	İletişim, sensör veya denetleyici arızasında beklenen işletim modu

Bu kart bir dokümantasyon lüksü değildir. Olay anında “hangi davranış normaldi?” sorusuna verilecek en hızlı cevaptır.

Kamera, radar ve video analitiği aynı sorunları çözmez

Üstten bakan kamera sistemleri sınıflandırma ve şerit bazlı bağlam sağlayabilir; fakat lens kirliliği, karşı ışık, yoğun yağış, kar, sis, gölge ve görüş alanı değişimleri bakım disiplinini zorunlu kılar. Radar, görüntü mahremiyeti sorununu azaltabilir ve bazı hava koşullarında daha istikrarlı davranabilir; buna karşılık kurulum açısı, kapsama geometrisi ve metal nesnelerden kaynaklanan yansımalar önemlidir. Yol içi sensörler ise aracın varlığını hassas biçimde algılayabilir, ancak yol kaplaması ve saha kablolamasının yaşam döngüsüne bağlıdır.

Buradaki hedef “en iyi sensörü” seçmek değil, kritik kavşaklarda tek ölçüm türüne bağımlılığı azaltmaktır. Farklı veri kaynakları birbirini doğrulamalıdır. Örneğin kamera araç kuyruğunu gösterirken loop çağrısı kesintisiz açık kalıyorsa, olay ağ veya güvenlik alarmı olarak kalmamalı; bakım önceliği de almalıdır. Radar sıfır hızda uzun kuyruk bildirirken görüntüde akış görünüyorsa kalibrasyon veya yerleşim incelenmelidir.

Zamanlama, Koordinasyon ve Güvenli Geçiş: Neden Milisaniyeler Önemlidir?

Trafik sinyal güvenliğinin bir boyutu da zamandır. Denetleyicinin her kararı; sürücünün algılama ve tepki süresi, aracın yavaşlama dinamiği, yaya geçiş mesafesi ve kavşak geometrisiyle ilişkilidir. Kontrol sistemindeki gecikme, paket kaybı, saat sapması veya yanlış sırada uygulanan bir güncelleme, kurumsal IT sistemlerindeki bir hatadan farklı fiziksel sonuçlar doğurabilir.

FHWA’nın zamanlama rehberi, araç yeşil aralığı, sarı değişim aralığı, kırmızı temizleme aralığı ve yaya zamanlamasını birbirinden ayrı parametreler olarak ele alır. Bu ayrım yazılımın “faz değiştir” demesinden daha önemlidir: güvenli hareket aktarımı, birbirini izleyen zaman aralıklarıyla üretilir. FHWA temel sinyal parametreleri

Koridor koordinasyonu: tek kavşak doğruyken şehir neden yanlış davranabilir?

Bir kavşak kendi başına düzgün çalışıyor olabilir; fakat koridorun geri kalanıyla koordinasyon kaybedildiyse sürücüler her blokta durur, kuyruklar geri taşar ve kavşak kapasitesi düşer. Koordinasyonda çevrim süresi, split ve offset gibi parametreler birlikte çalışır. Bunlardan biri beklenmeyen biçimde değiştiğinde, ilk belirti çoğu zaman kabin içindeki hata değil, saha performansındaki bozulmadır: araçların platoon hâlinde kırmızıya yakalanması, belirli yaklaşımda olağandışı kuyruk veya koridor boyunca artan dur-kalk.

Bu, loglama için iki seviyeli tasarımı gerekli kılar:

Kabin seviyesi telemetri: Faz, çağrı, plan, iletişim, preemption ve hata olayları.
Koridor seviyesi performans: Seyahat süresi, duraklama sayısı, kuyruk, yeşil bant başarısı ve kavşaklar arası zaman ilişkisi.

Sadece kabin loglarıyla bakan ekip, yerel olarak geçerli ama sistemsel olarak kötü bir durumu gözden kaçırabilir. Sadece trafik kamerasına bakan ekip ise kök nedeni ayıramaz. Dayanıklılık, iki görünümü aynı olay çizelgesinde birleştirmektir.

Saat senkronizasyonu bir konfor özelliği değildir

Kavşakların zaman tabanlı planları veya koridor koordinasyonu varsa doğru zaman, güvenlik ve işletim girdisidir. Saat sapması; yanlış zaman dilimi planı, yanlış olay korelasyonu ve komşu kavşaklarda bozulmuş offset olarak görünür. Bu nedenle zaman kaynağı, erişim denetimi, değişiklik günlüğü ve sapma alarmı OT işletim standartlarının parçası olmalıdır.

Olay müdahalesinde de aynı kural geçerlidir: denetleyici saati, merkez kayıtları, video zaman damgası ve bakım iş emri aynı referansa oturmuyorsa güvenilir bir zaman çizelgesi kurulamaz. Bir yapılandırma değişikliğinin mi, saha arızasının mı yoksa acil durum işletiminin mi önce geldiğini bilmek, ancak bu korelasyonla mümkündür.

NTCIP 1202: Protokolü Doğru Anlamak

NTCIP 1202, aktüasyonlu sinyal denetleyicileri ile yönetim istasyonu arasındaki veri nesnelerini ve işlevsel gereksinimleri tanımlar. Nesneler SNMP biçiminde tanımlanabilir; bu gerçek, her kavşağın SNMPv2c kullandığı, tüm nesnelerin yazılabilir olduğu veya bütün üreticilerin aynı yönetim işlevlerini etkinleştirdiği anlamına gelmez.

Standart bu noktada nettir: “NTCIP 1202 uyumluluğu”, kurumun kendi şartnamesinde seçmediği isteğe bağlı yeteneklerin bulunduğu anlamına gelmez. Bir kurum, kullanacağı işlevleri, profilleri ve destek seviyesini ihale/tedarik şartnamesinde açıkça seçmelidir. NTCIP’nin uygunluk açıklaması

Bu nedenle araştırma veya envanter çalışmasında şu ayrımı koruyun:

Varsayım	Sağlam yaklaşım
“NTCIP var, bütün OID’ler aynıdır.”	Ürünün MIB’i, conformance dokümanı ve kurum profili incelenir.
“SNMP kullanılıyorsa şifresizdir.”	Sürüm, kimlik doğrulama, şifreleme, ACL ve yönetim ağı doğrulanır.
“Bir yönetim değişikliği doğrudan sinyal çıkışıdır.”	Denetleyici mantığı, güvenlik geçişleri ve kabin korumaları birlikte değerlendirilir.
“Özel üretici nesnesi standarttır.”	Tedarikçi nesneleri açıkça etiketlenir ve dokümante edilir.

NIST, SNMPv1/v2’nin yapılandırma için şifrelenmemiş parolalara dayandığını; mümkünse bu trafiğin ayrı ve korumalı bir yönetim ağında sınırlandırılması gerektiğini, SNMPv3’ün ise daha güvenli seçenek olduğunu belirtir. NIST SP 800-82 Rev. 3

Standart ile saha gerçekliği arasındaki boşluk

NTCIP gibi birlikte çalışabilirlik standartları, kurumları üreticiye bağımlı tekil çözümlerden uzaklaştırmak için değerlidir. Fakat standardın varlığı otomatik güvenlik sağlamaz. Gerçek bir kurulumu anlamak için en az beş belge gerekir: cihazın model ve firmware bilgisi, kurumun işlev şartnamesi, desteklenen protokol/özellik listesi, ağ topolojisi ve değişiklik/bakım prosedürü.

Bu belgeler olmadığında iki karşıt hata ortaya çıkar. Birincisi, her cihazın kolayca yönetilebildiğini varsayan gereksiz korkudur. İkincisi, “standart uyumlu” etiketini güvenlik sertifikası sanan rehavettir. İkisi de doğru değildir. NTCIP 1202, kurumlara proje gereksinimlerini seçme sorumluluğu yükler; isteğe bağlı yeteneklerin kurum şartnamesinde zorunlu hâle getirilmesi gerektiğini açıkça söyler. NTCIP 1202 uygunluk bölümü

İyi bir güvenlik değerlendirmesi bu yüzden cihazdan başlayıp sisteme gider:

Cihaz ne destekliyor? Standart ve üreticiye özgü nesneler, firmware, etkin servisler, kayıt yeteneği.
Kurum neyi etkinleştirdi? İşletim modu, yönetim profili, erişim listesi, merkez entegrasyonu.
Kim erişebiliyor? Operatör, bakım yüklenicisi, ağ yöneticisi, saha teknisyeni ve tedarikçi.
Hangi yol üzerinden? Ayrı yönetim VLAN’ı, modem, hücresel gateway, kablolu omurga, jump host veya yerel servis portu.
Değişiklik nasıl kanıtlanıyor? Onay, zaman damgası, config yedeği, audit log ve geri alma prosedürü.

Bu beş cevap yoksa “güvenli” veya “savunmasız” hükmü teknik bir değerlendirme değil, tahmin olur.

NTCIP 1218 ile NTCIP 1202 aynı belge değildir

Saha yazılarında sık rastlanan bir karışıklık, NTCIP numaralarının birbirinin güncel sürümü gibi sunulmasıdır. NTCIP 1202, aktüasyonlu sinyal denetleyicisi arayüzünü ele alır. NTCIP 1218 ise yol kenarı üniteleri (RSU) için nesne tanımlar ve bağlı araç/altyapı bağlamında farklı bir probleme hizmet eder. Numaralar yakın olsa da kapsamları aynı değildir. NTCIP 1218 RSU çalışma grubu

Bu ayrım, gelecekteki bağlı kavşak mimarileri için daha da önemlidir. Klasik denetleyici yönetimi, merkezi trafik yönetimi ve RSU üzerinden gelen bağlı araç mesajları farklı güven sınırlarına sahip olabilir. Birinin riskini diğerinin varsayımlarıyla değerlendirmek doğru tasarım üretmez.

Yönetim düzlemi için altın kural: görünür olmayan erişim, kabul edilmemiş erişimdir

Sinyal kontrol sistemlerinde en tehlikeli erişim modeli, “bakım için ara sıra lazım oluyor” diye kalıcılaştırılmış ve izlenmeyen erişimdir. Hücresel modem, saha gateway’i, eski VPN hesabı, ortak kullanılan tedarikçi hesabı veya yönetim ağına yanlış açılmış kural; tek tek küçük görünebilir. Birlikte ise envanter dışı bir yönetim yüzeyi oluştururlar.

Bu yüzden erişim tasarımında aşağıdaki prensipler uygulanmalıdır:

Üretim kabinlerine doğrudan İnternet’ten yönetim erişimi verilmez.
Her uzaktan oturum kişiye bağlanır; paylaşımlı hesaplar istisna değil, kapatılması gereken borçtur.
Yetki süreli verilir; bakım bittiğinde erişim otomatik düşer.
Kural değişiklikleri ve cihaz yapılandırmaları sürüm kontrollü biçimde saklanır.
Başarısız oturumlar, reddedilen yönetim denemeleri ve beklenmeyen kaynak IP’leri izlenir.
Güvenlik kontrolleri devreye alınmadan önce laboratuvarda gecikme ve kullanılabilirlik etkisi test edilir.

CISA’nın OT için önerdiği segmentasyon, MFA, izlenen uzak erişim ve envanter yaklaşımı bu mantığın kurum çapındaki karşılığıdır. CISA OT/ICS sertleştirme önerileri

NTCIP mesajından fiziksel lambaya: kontrol akışının tamamı

Bir yönetim isteğini yalnızca “merkezden kontrolöre giden bir paket” diye düşünmek eksik bir modeldir. Trafik sinyali davranışı, farklı sorumluluklara sahip katmanların art arda karar vermesiyle oluşur:

Traffic Management Center
            │
            │  NTCIP yönetim trafiği / durum telemetrisi
            ▼
      Network Edge
   (ACL, VPN, jump host)
            │
            ▼
   Controller Unit (CU)
 (faz mantığı, plan, saat)
            │
       Cabinet I/O
      ┌─────┴─────┐
      ▼           ▼
 Detector      MMU / SMU / CMU
 interface     (emniyet gözetimi)
      │           │
      └─────┬─────┘
            ▼
       Load Switch
            │
            ▼
       Signal Head

Merkez; plan, durum ve bazı yönetim parametrelerini iletir. CU bu girdileri faz mantığı, minimum/maksimum süre, koordinasyon ve preemption kurallarıyla değerlendirir. Dedektör arayüzü sahadaki ölçümü mantığa taşır. MMU/SMU/CMU gibi bileşenler, belirli elektriksel veya sinyal kombinasyonlarının güvenli flaş gibi bir duruma alınmasını gözetir. Son fiziksel çıkış load switch üzerinden signal head’e ulaşır.

Bu akışta kritik nokta şudur: Her katman aynı kararı vermez. CU’nun “fazı değiştir” kararı ile load switch’in elektriksel çıkışı arasında emniyet kontrolleri vardır; fakat bu kontrollerin varlığı, merkez hesabının ele geçirilmesini, yanlış sensör verisini veya kötü belgelenmiş bakım erişimini otomatik olarak çözmez. Bir olayın etkisini anlamak için “hangi paket gönderildi?” kadar “hangi katman bu kararı kabul etti, hangisi sınırladı ve hangi kayıt bunu kanıtlıyor?” soruları da sorulmalıdır.

Bir kavşağın gerçek saldırı yüzeyi

Sinyalizasyon sisteminin saldırı yüzeyi yalnızca IP adreslerinden oluşmaz. Güvenlik değerlendirmesi, uzaktan erişimden asfalt altındaki döngü kablosuna ve bakım iş akışındaki insan hesabına kadar uzanan bir varlık haritası çıkarmalıdır:

Katman	Varlık / yol	Tipik risk	Kanıtlanacak kontrol
Remote	VPN, hücresel modem, saha gateway’i	Yetkisiz veya kalıcı uzaktan erişim	Süreli yetki, MFA, oturum kaydı
Network	VLAN, ACL, routing, firewall	Merkez dışından yönetim yoluna erişim	Allowlist, segmentasyon, akış logu
Management	NTCIP/SNMP, merkezi yazılım, API	Kimlik doğrulamasız değişiklik, zayıf bütünlük	Sürüm, rol, imza/şifreleme, değişiklik alarmı
Controller	CU firmware’i, plan ve konfigürasyon	Yetkisiz firmware veya parametre değişikliği	İmzalı güncelleme, onaylı config, rollback
Cabinet	BIU/SIU, I/O, load switch, MMU	Fiziksel sabotaj veya bakım hatası	Kilit, mühür, kablolama kontrolü, test kaydı
Sensor	Loop, radar, kamera, dedektör arayüzü	Sürekli çağrı, kayıp veri, sahte yoğunluk	Sağlık durumu, çapraz doğrulama, kalibrasyon
Physical	Kabin, pull box, enerji ve haberleşme kablosu	Yetkisiz saha erişimi veya kesinti	Erişim kaydı, alarm, yedekli iletişim/enerji
Human	Operatör, bakım yüklenicisi, tedarikçi hesabı	Paylaşımlı hesap, sosyal mühendislik, acil durum istisnası	Kişiye bağlı hesap, dört göz onayı, iş emri

Bu tablo bir “her şey saldırılabilir” listesi değildir. Ama her satır için varlık sahibi, normal davranış, güvenlik kontrolü ve olay kanıtı tanımlanmıyorsa envanter eksiktir. Özellikle kabin içi bir bakım portu, eski bir modem veya sürekli aktif bırakılmış tedarikçi hesabı; ağ taramasında görünmeyen fakat sonuçları doğrudan sahaya ulaşan bir yönetim yolu oluşturabilir.

Tehdit Modeli: Hangi Sınırlar Gerçekten Korunuyor?

Bir kavşak için tehdit modeli “birileri ışığı değiştirir” cümlesinden başlayamaz. Önce hangi varlıkların korunacağı, hangi başarısızlığın kabul edilemez olduğu ve hangi rolün hangi yetkiye sahip olduğu yazılmalıdır. Trafik yönetiminde üç etkiden biri öne çıkar:

Emniyet etkisi: Güvenli geçiş dizisinin bozulması, yaya güvenliğinin tehlikeye girmesi veya acil durum trafiğinin olumsuz etkilenmesi.
Kullanılabilirlik etkisi: Kavşağın güvenli işletimden çıkması, uzun kuyruklar, koridor koordinasyonunun kaybı veya saha ekibi gerektiren arıza.
Bütünlük etkisi: Zamanlama planı, sensör verisi, olay kaydı, erişim kaydı veya yapılandırma bilgisinin güvenilirliğini yitirmesi.

Gizlilik de önemlidir; örneğin altyapı topolojisi, bakım kimlik bilgileri ve saha iletişim envanteri hassastır. Fakat OT bağlamında gizlilik bulgusu çoğu zaman daha büyük bir bütünlük ya da kullanılabilirlik zincirinin ilk halkasıdır.

Dört güven sınırı

1. Merkez–saha sınırı. Trafik yönetim merkezi ile kabin arasında geçen komut, durum ve telemetri trafiği. Bu sınırda ağ segmentasyonu, kimlik doğrulama, şifreleme, allowlist ve izleme değerlendirilir.

2. Kabin–saha sınırı. Kontrolörün yük anahtarları, dedektör girişleri, güç bileşenleri ve sinyal başlıklarıyla ilişkisi. Bu sınır; fiziksel erişim, kablolama, bakım kalitesi ve fail-safe davranışı içerir.

3. İnsan–iş akışı sınırı. Operatör, bakım yüklenicisi, acil hizmet, ağ ekibi ve üretici desteği arasındaki onay akışı. Sosyal mühendislik, paylaşımlı hesap ve acil durum istisnaları burada önem kazanır.

4. Veri–karar sınırı. Sensör ölçümü, model/algoritma, plan seçimi ve denetleyici çıktısı arasındaki ilişki. Yanlış veya kalitesiz veri, doğru çalışan yazılımın yanlış karar üretmesine yol açabilir.

Bu çerçeve olay müdahalesini de sadeleştirir. Bir anomali görüldüğünde ekipler önce “hangi sınır geçildi veya hangi veri güvenilmez hâle geldi?” sorusunu sorar. Böylece kamera arızası ile yetkisiz yapılandırma değişikliği aynı alarm kuyruğunda kaybolmaz.

Risk önceliklendirmesi: en çok cihaz değil, en çok sonuç

Varlık sayısı yüksek olan koridor her zaman ilk öncelik değildir. Öncelik; hastane rotası, raylı sistem etkileşimi, okul geçidi, tünel yaklaşımı, kritik lojistik düğüm, büyük etkinlik alanı veya uzun süreli kesinti hâlinde alternatif rotası sınırlı bölge gibi sonuç faktörleriyle belirlenir.

Basit bir öncelik matrisi kullanılabilir:

Soru	Düşük öncelik	Yüksek öncelik
Fiziksel sonuç	Yerel, kontrollü gecikme	Yüksek yoğunluklu veya kritik rotalı kesişim
Uzaktan erişim	Kayıtlı, süreli, ayrıştırılmış	Kalıcı, geniş veya belgesiz erişim
Görünürlük	Faz, sensör ve değişiklik logları birlikte	Sadece merkez alarmı veya hiç telemetri yok
Kurtarma	Test edilmiş fallback ve görevli ekip	Belgesiz, kişiye bağımlı müdahale
Tedarik bağımlılığı	Güncel destek ve belgeli firmware	EOL bileşen, belirsiz destek, kapalı bilgi

Bu matriste bir “yüksek” alan, otomatik kriz demek değildir. Ancak o kavşağın envanter, erişim kontrolü ve tatbikat programında öne alınması gerektiğini söyler.

Dört Dayanıklılık Senaryosu: Saldırı Değil, Tespit ve Kurtarma Egzersizi

Buradaki senaryolar yetkili laboratuvar veya masa başı tatbikat için tasarlanmıştır. Her biri, “saldırgan ne yazdı?” sorusundan çok “operasyon ekibi hangi işareti gördü ve ne yaptı?” sorusuna odaklanır.

1. Beklenmeyen uzun all-red

Operasyonel belirti: Kavşakta akış durur; kısa sürede kuyruk komşu bağlantılara taşar.

Tespit sinyali: Normal üst sınırı aşan all-red süresi, çok sayıda kullanıcı şikâyeti, kamera üzerinde hareket yokluğu veya kontrolör olay günlüğünde beklenmeyen mod değişimi.

Yanıt: Merkezi operatör, olay kaydı ile görüntüyü karşılaştırır; bakım ekibi gönderilmeden önce son yapılandırma değişikliği, güç/iletişim alarmları ve MMU durumu incelenir. Kritik hedef, akışı körlemesine geri getirmek değil, güvenli işletimi bozan nedeni ayırmaktır.

2. Faz açlığı ve sıra dışı maksimum yeşil

Operasyonel belirti: Bir yaklaşım tekrar eden şekilde beklerken karşı yaklaşım beklenenden uzun hizmet alır.

Tespit sinyali: Faz sürelerinin saat, gün ve talep profiline göre sapması; az trafik döneminde sürekli max-out; ilgili dedektörün sürekli çağrıda kalması.

Yanıt: Sinyal planı, dedektör sağlığı ve kamera görüntüsü birlikte kontrol edilir. Amaç, sensör hatası, yanlış plan, bakım sonrası değişiklik ve yönetim düzlemi olayı arasındaki farkı kanıtlamaktır.

3. Olağandışı preemption yoğunluğu

Operasyonel belirti: Kavşak sık sık öncelik moduna girer, koordinasyon bozulur ve toparlanma uzar.

Tespit sinyali: Kaynak, yön, süre ve tekrar oranıyla ilişkilendirilmemiş preemption olayları; aynı koridorda tekrarlayan başarısız dönüş; olayla uyumsuz kamera kaydı.

Yanıt: Preemption talebini doğrulayan sistem, denetleyici olay günlüğü ve saha gözlemi aynı zaman çizelgesine yerleştirilir. Gerçek acil durum trafiğine zarar vermemek için kurallar, kurumun trafik operasyon merkezi ve acil hizmet birimleriyle birlikte belirlenmelidir.

4. Sensör bütünlüğü kaybı

Operasyonel belirti: Boş yaklaşımda sürekli çağrı, anormal occupancy ya da fiziksel talep ile uyuşmayan faz uzatmaları.

Tespit sinyali: Sensör verisinin kamera/ikincil sensörle tutarsızlığı; bakım kaydında yakın dönem kablo, asfalt veya dolap işlemi; tek bir sensörde kalıcı davranış değişimi.

Yanıt: Sensörü “kapatarak” başlamak yerine güvenli fallback planı, yaya ihtiyaçları ve kavşak konfigürasyonu değerlendirilir. Sonrasında fiziksel yol, kabin bağlantıları ve elektronik birim yetkili bakım prosedürüyle kontrol edilir.

Bu dört senaryoda ortak olan şey nedir?

Hepsinde ilk problem “kimin yaptığı” değildir. İlk problem, hangi fiziksel davranışın beklenen zarftan çıktığıdır. Ekiplerin tespit mimarisini kullanıcı kimliğine veya tek bir ağ alarmına bağlaması bu nedenle yetersizdir. Kullanılabilir bir olay kaydı; kontrolörün ne yaptığını, sensörün ne söylediğini, merkezin ne gönderdiğini ve sahanın ne gösterdiğini aynı olay kimliği altında birleştirmelidir.

Bir örnek zaman çizelgesi şu alanları içerebilir:

Zaman	Kanıt	Sorulacak soru
T-10 dk	Son onaylı plan/config sürümü	Olaydan önce bilinçli bir değişiklik var mı?
T-2 dk	Ağ oturumu ve kimlik kaydı	Yönetim düzleminde beklenmeyen erişim oldu mu?
T0	Kontrolör olay kaydı	Hangi mod, faz veya hata durumu değişti?
T+30 sn	Sensör ve video karşılaştırması	Fiziksel talep dijital kayıtla uyumlu mu?
T+5 dk	Operatör kararı ve fallback kaydı	Müdahale güvenli ve yetkili miydi?
T+24 sa	Kök neden ve düzeltme kaydı	Aynı olay tekrar oluşabilir mi?

Bu düzen hukuki ve operasyonel hesap verebilirlik sağlar. Olayın siber saldırı, konfigürasyon hatası, donanım arızası veya saha hasarı olduğu daha sonra netleşse bile ilk müdahalede toplanan kanıtın düzeni korunur.

Detection engineering: alarm değil, kanıt zinciri

Trafik sinyalinde iyi bir alarm yalnızca “faz beklenenden uzun sürdü” demez. Olayı yeniden kurmaya yarayan bağlamı da toplar. Minimum korelasyon zinciri şöyle kurulabilir:

Management Event
      ↓
Configuration / phase change
      ↓
Controller state and detector health
      ↓
Telemetry + cabinet / MMU status
      ↓
Traffic outcome (queue, delay, service ratio)
      ↓
SIEM alert and operator playbook

Örneğin beklenmeyen bir faz uzamasında SIEM aynı pencere içinde şu soruları cevaplayabilmelidir: Değişiklik kim tarafından yapıldı? Bir bakım iş emri var mıydı? Dedektör çağrısı gerçekten var mıydı? Komşu kavşaklarda aynı anda saat veya iletişim sorunu görüldü mü? MMU güvenli duruma geçti mi? Kamera ve telemetri aynı fiziksel davranışı doğruluyor mu?

Örnek tespit kuralları

Üreticiye özgü OID veya komut vermeden, kurumun kendi alan adlarına uyarlanabilecek davranış temelli kurallar yazılabilir:

Kural	Sinyal	Bağlam	İlk doğrulama
Yetkisiz değişiklik	Çalışma saatleri dışında plan/faz parametresi değişti	İş emri veya onay yok	Kimlik, kaynak ağ, önce/sonra config
Uzun maksimum yeşil	Aynı yaklaşım art arda max-out oluyor	Dedektör sağlığı normal görünmüyor	Fiziksel çağrı, sensör hata biti, kamera
Sürekli all-red	Kısa aralıkta tekrar eden güvenli duruma geçiş	MMU/enerji/iletişim olayları eşlik ediyor	Kabin logu, saha enerjisi, bakım kaydı
Preemption anomalisi	Kısa sürede olağandışı acil öncelik sayısı	Beklenen rota veya araç kaydı yok	Kaynak, süre, ilgili kurum teyidi
Telemetri körlüğü	Faz değişiyor fakat yönetim kaydı gelmiyor	Ağ yolu veya saat senkronu bozuk olabilir	Son başarılı heartbeat, saat sapması

Bu kuralların amacı otomatik olarak kavşağı kapatmak değil, operatöre güvenli bir karar vermesi için yeterli kanıtı hızlı sunmaktır. Emniyet açısından kritik bir çıkışın doğrudan SIEM kuralıyla uzaktan değiştirilmesi yerine, önceden onaylanmış fallback ve saha prosedürleri kullanılmalıdır.

Bulguyu araştırma formatında yazmak

Test sonucu, “çalıştı” notundan ibaret kalmamalı; gözlem tekrarlanabilir bir bulguya dönüştürülmelidir. Her laboratuvar veya saha değerlendirmesi aşağıdaki şablonla kaydedilebilir:

Finding: Unverified Detector State

Impact: Medium / High — kavşak kritikliğine göre
Affected layer: Detection → Control Logic
Observed behavior: Dedektör çağrısı uzun süre değişmeden kaldı;
                   bağımsız doğrulama üretilmedi.
Expected behavior: Sağlık biti, zaman aşımı ve ikinci bir veri kaynağı
                   ile çağrının geçerliliği sınanmalı.
Security implication: Yanlış veri, doğru çalışan faz mantığını
                      yanlış girdiye göre karar vermeye zorlayabilir.
Operational impact: Gereksiz kuyruk, koordinasyon kaybı veya bakım
                     ekibinin yanlış kök nedene yönelmesi.
Detection: Sürekli çağrı + sensör sağlık alarmı + kamera/telemetri
           tutarsızlığı korelasyonu.
Mitigation: Sensör zaman aşımı, çapraz doğrulama, fiziksel kontrol,
            değişiklik günlüğü ve test edilmiş fallback.
Validation: Kontrollü SUMO senaryosu, saha kabul testi ve yeniden
            ölçüm sonucu.

Bu format, trafik mühendisinin operasyonel etkisini, güvenlik ekibinin bütünlük değerlendirmesini ve bakım ekibinin doğrulama adımını aynı kayıtta buluşturur. Ayrıca “yüksek önem” etiketinin neden verildiğini sonradan açıklamayı kolaylaştırır.

Olay Müdahalesi: Trafiği Yeniden Akıtmak ile Kanıtı Korumak Arasındaki Denge

Kritik altyapıda olay müdahalesi incelemeyle sınırlı değildir. Operasyon ekibi, insanları ve trafiği etkileyen bir durumu güvenli işletime döndürürken güvenlik ekibi kayıtları, konfigürasyonu ve zaman çizelgesini korur. İyi playbook bu iki ihtiyacı aynı akışta ele alır.

İlk 15 dakika için rol ayrımı

Trafik operasyon merkezi: Saha etkisini doğrular, güvenli işletim kararını verir, gerektiğinde alternatif planı veya bakım ekiplerini devreye alır.

OT/ICS güvenlik ekibi: Yönetim erişimi, ağ anomalileri, kimlik olayları, konfigürasyon farkı ve korelasyon verisini toplar.

Saha bakım ekibi: Kabin durumu, güç, MMU/CMU göstergeleri, fiziksel bütünlük ve dedektör sağlığı hakkında doğrulanabilir gözlem sağlar.

Acil hizmet/kurum koordinasyonu: Preemption, raylı sistem veya yüksek riskli rota etkisi varsa operasyon kararına bağlam sağlar.

Her rolün tek bir iş sahibi olmalıdır. “IT baksın” veya “saha halleder” yaklaşımı iki ayrı kanıt zinciri üretir ve olayın ortasında ekipler birbirini bekler.

Güvenli müdahale sırası

Emniyeti doğrula. Sinyal durumunun fiziksel etkisini doğrula; gerekiyorsa kurum prosedüründeki güvenli işletim moduna geç.
Uçucu kanıtı koru. Aktif oturumlar, son yapılandırma farkı, olay günlükleri ve zaman damgaları alınır.
Erişim yüzeyini daralt. Şüpheli uzaktan erişim varsa kalıcı geniş kesinti yerine onaylı yönetim noktalarına geçici allowlist uygulanır.
Saha ve merkez verisini karşılaştır. Video, kontrolör, sensör, iletişim ve bakım kaydı zaman çizelgesine yerleştirilir.
Kök nedeni sınıflandır. Siber olay, konfigürasyon hatası, donanım/enerji arızası, sensör sorunu veya birleşik olay.
Kontrollü geri dönüş yap. Normal plana dönüş, denetimli olarak ve başarı ölçütleriyle gerçekleştirilir.
Retest ile kapat. Aynı koşul güvenli ortamda yeniden üretilir; alarm, kayıt ve fallback davranışının beklenen şekilde çalıştığı kanıtlanır.

NIST’in OT güvenlik yaklaşımında da güvenlik kontrollerinin kullanılabilirlik, güvenilirlik ve emniyet ihtiyaçlarıyla birlikte uyarlanması vurgulanır. Bu, “ağı kapatmak” ile “hiç dokunmamak” arasındaki olgun karar alanıdır. NIST Operational Technology Security

Sonradan yapılan en pahalı hata: sessiz normalleşme

Bir kavşak birkaç dakika sonra yeniden çalışmaya başladı diye olay kapanmış sayılmamalıdır. Sinyal planındaki geçici değişiklik kalıcılaşmış olabilir, sensör arızası dönemsel olarak tekrarlayabilir veya yetkisiz erişim sadece ilk belirtisini vermiş olabilir. Olay sonrası inceleme en az şu soruları kapatmalıdır:

Son bilinen iyi yapılandırma yedeği var mı ve mevcut durumla karşılaştırıldı mı?
İlgili erişim hesapları, oturumlar ve ağ kuralları incelendi mi?
Aynı firmware, modem, merkezi servis veya bakım prosedürü başka kavşaklarda da var mı?
Alarm eşiği olayı ne kadar hızlı yakaladı; kaç yanlış pozitif üretti?
Operatörler, saha teknisyenleri ve güvenlik ekibi aynı zaman çizelgesinde hemfikir mi?

Bu soruların cevabı bulunmadan yapılan “kapatma”, sadece alarmın kapanmasıdır; riskin değil.

Güvenli Laboratuvar: SUMO ile Ne Test Edilebilir?

Eclipse SUMO, trafik akışını ve sinyal mantığını üretimden tamamen ayrı bir ortamda modellemek için uygun bir araçtır. TraCI arayüzüyle dışarıdaki bir Python denetleyicisi simülasyondaki sinyal durumunu okuyabilir ve test senaryosu kapsamında değiştirebilir; SUMO ayrıca indüksiyon döngüsü verisini modelleyebilir. SUMO trafik ışığı eğitimi, SUMO indüksiyon döngüsü dokümantasyonu

İyi bir laboratuvarın başarısı “ışığı değiştirdim” değildir. Başarı ölçütü aşağıdaki sorulara kanıt üretebilmesidir:

Hangi süre eşiğinde olay alarmı üretiliyor?
Alarm, sensör ve kamera/doğrulama kaynağıyla kaç saniyede ilişkilendiriliyor?
Operatör güvenli fallback moduna geçmek için hangi yetkiyle karar veriyor?
Normal koordinasyona dönüş ne kadar sürüyor; yaya ve acil durum kuralları korunuyor mu?
Tatbikat sonrası hangi kayıtlar denetime hazır kalıyor?

Laboratuvarda yönetim düzlemini temsil eden soyut olaylar kullanılabilir: yetkisiz yapılandırma değişikliği, beklenmeyen faz süresi, sensör tutarsızlığı veya preemption anomali olayı. Gerçek kurumların IP bilgileri, üreticiye özgü yönetim nesneleri, varsayılan kimlik bilgileri ya da çalıştırılabilir müdahale komutları bu çalışmanın parçası olmamalıdır.

Gerçekten iyi bir SUMO senaryosunun bileşenleri

Basit bir dört kollu kavşak, arayüzü göstermek için yeterlidir; fakat dayanıklılık sorularını cevaplamak için tek başına yetersizdir. Faydalı bir dijital ikiz, en azından aşağıdaki katmanları içerir:

Ağ geometrisi: Şerit sayısı, dönüş cepleri, yaya geçitleri, otobüs durağı, bağlantı yolları ve komşu kavşaklar.
Talep modeli: Gün içi akış değişimi, platoon gelişleri, yaya çağrıları, toplu taşıma ve istisnai yoğunluklar.
Kontrol modeli: Faz haritası, minimum/maksimum süreler, sarı/all-red, koordinasyon ve fallback davranışı.
Algılama modeli: Hangi şeritlerde hangi sensörün ne ölçtüğü, kayıp veri ve tutarsız ölçüm durumları.
Operasyon modeli: Alarm eşiği, operatör doğrulaması, saha bakım süresi ve normal işletime dönüş kriteri.

Bu beş katman ayrılmadığında simülasyon çok hızlı “güzel bir animasyon”a dönüşür. Ayrıldığında ekip aynı olayın farklı nedenlerini karşılaştırabilir. Örneğin uzun kuyruk; artan talep, yanlış faz planı, arızalı dedektör veya koordinasyon kaybından hangisiyle oluştu? Gerçek değer, bu soruyu kontrollü değişkenlerle cevaplayabilmektir.

Okuma anahtarı: kaynaklı gerçek ile laboratuvar hipotezini ayırmak

İçerikte iki farklı bilgi türü yan yana duruyor. NTCIP, FHWA, NIST ve CISA bağlantılarıyla verilen bölümler standart, mühendislik kılavuzu veya kurumların yayımladığı saha bilgisini özetler. SUMO laboratuvarı, tespit kuralları ve LAB-01–LAB-04 senaryoları ise güvenli test tasarımıdır; belirli bir belediyenin veya üreticinin gerçek kurulumunda gözlenmiş bulgu olarak okunmamalıdır. Bir senaryo üretimde doğrulanacaksa kurumun cihaz dokümanı, konfigürasyonu, işletim prosedürü ve yetkili kabul testi ayrıca gerekir.

Lab metodolojisi: baseline, anomali, ölçüm, kabul

Her senaryoyu aynı dört aşamayla yürütmek, ekran görüntüsü toplamaktan daha güvenilir sonuç verir. Önce normal davranış kaydedilir; sonra tek bir değişken kontrollü biçimde bozulur; etkisi ölçülür; en son algılama ve geri dönüş kriteri doğrulanır.

LAB-01 — Sensör bütünlüğü

Baseline: Normal trafik talebi, beklenen occupancy aralığı, faz süreleri, max-out sıklığı ve sensör sağlık durumu kaydedilir.

Anomali: Bir dedektör sürekli çağrıda kalır, veri akışı kesilir veya occupancy ile araç üretimi arasında tutarsızlık oluşturulur. Bu yalnızca simülasyon girdisiyle yapılır; gerçek sensör hattına sinyal enjekte edilmez.

Ölç: Alarm gecikmesi, yanlış pozitif oranı, faz sapması, 95. yüzdelik kuyruk uzunluğu ve normal işletime dönüş süresi.

Araştırma sorusu: Sistem, “gerçekten yoğun yaklaşım” ile “sağlıksız veya doğrulanmamış sensör” durumunu ayırabiliyor mu?

LAB-02 — Yönetim düzlemi bütünlüğü

Baseline: Son onaylı plan sürümü, beklenen bakım penceresi ve normal yönetim oturumları tanımlanır.

Anomali: Gerçek cihaza bağlanmadan, bir yapılandırma değişikliği olayı ve beklenmeyen kaynak kimliği üretilir. Simülasyon, değişiklikten sonra controller state, telemetri ve trafik sonucunu kaydeder.

Ölç: Değişiklik ile alarm arasındaki süre, önce/sonra config farkının doğruluğu, olayın doğru varlıkla ilişkilendirilme oranı ve operatörün karar süresi.

Management Event → Config Change → Controller State → Telemetry
             → SIEM Correlation → Operator Decision

Araştırma sorusu: Bir konfigürasyon değişikliğini fiziksel etki oluşmadan önce tespit edebiliyor muyuz?

LAB-03 — Preemption ve toparlanma

Baseline: Tanımlı acil durum rotası, beklenen preemption süresi, sarı/all-red geçişleri ve koordinasyona dönüş süresi ölçülür.

Anomali: Yetkili test girdisiyle art arda veya rotayla uyumsuz öncelik olayları simüle edilir. Amaç gerçek acil durum hizmetini taklit ederek saha sistemini etkilemek değil, kayıt ve karar zincirini sınamaktır.

Ölç: Olayların kaynağı ve süresi, normal koordinasyona dönüş, komşu kavşaklarda kuyruk etkisi ve operatör doğrulama adımları.

Araştırma sorusu: Sistem gerçek acil durumu geciktirmeden olağandışı öncelik desenini görünür kılabiliyor mu?

LAB-04 — Haberleşme kaybı ve güvenli fallback

Baseline: Merkez-kabin heartbeat aralığı, yerel plan ve beklenen iletişim kaybı davranışı belgelenir.

Anomali: Yalnızca simülasyon ağı üzerinde telemetri gecikmesi veya bağlantı kesintisi oluşturulur.

Ölç: Fallback’e geçiş süresi, yerel planın bütünlüğü, alarm üretimi, saat sapması ve bağlantı geri geldiğinde güvenli yeniden senkronizasyon.

Araştırma sorusu: Yönetim düzlemi yokken kavşak güvenli ve öngörülebilir bir duruma geçebiliyor mu?

Bu dört laboratuvarın her birinde deney konfigürasyonu, kullanılan veri seti, beklenen sonuç, gözlenen sonuç ve tekrar çalıştırma adımları saklanmalıdır. Böylece test; tek seferlik bir demo değil, tedarikçi kabulünde ve periyodik tatbikatta yeniden kullanılabilir bir kontrol hâline gelir.

Ölçülmesi gereken metrikler

Bir saldırı gösterisi yerine deney tasarımı yapmak için metrikleri baştan seçmek gerekir. Tavsiye edilen çekirdek set:

Metrik	Neyi gösterir?	Tek başına neden yetmez?
Yaklaşım başına ortalama gecikme	Kullanıcı deneyimi ve kapasite baskısı	Kısa ortalama, küçük grupta ağır kuyruk saklayabilir
95. yüzdelik kuyruk uzunluğu	Kötü durum davranışı	Fiziksel gözlemle doğrulanmalıdır
Faz hizmet oranı	Hangi hareketin ne kadar hizmet aldığını	Talep ve yaya gereksiniminden bağımsız okunamaz
Max-out sıklığı	Faz/sensör/yoğunluk anormalliği	Planlı platoon akışı benzer iz bırakabilir
Preemption toparlanma süresi	Normal koordinasyona dönüş kalitesi	Acil olayın öneminden bağımsız hedef konulamaz
Alarm gecikmesi	Görünürlük başarısı	Yanlış pozitif oranıyla birlikte okunmalıdır
Operatör kararı süresi	Playbook kullanılabilirliği	İnsan eğitimi ve yetki modelinden etkilenir

Metriklerin amacı ekipleri cezalandırmak değil, “hangi kontrol gerçekten çalışıyor?” sorusuna sayısal yanıt üretmektir. Bir alarmın beş saniyede üretildiği ama operatöre hiçbir bağlam vermediği sistem, iki dakikada olay zaman çizelgesi üreten bir sistemden daha iyi olmayabilir.

Kabul testini siber güvenlik testinden ayırmayın

Bir kavşak veya merkezi sistem devreye alınırken yapılan kabul testleri, genellikle fonksiyonun çalıştığını doğrular: fazlar dönüyor mu, dedektör çağrısı geliyor mu, merkezden durum görünüyor mu? Siber dayanıklılık kabulü buna ek sorular koymalıdır:

Yetkisi olmayan ağ segmentinden yönetim hizmetine ulaşılabiliyor mu?
Uzak bakım hesabının zamanı, rolü ve oturum kaydı var mı?
İletişim kaybında kavşak tanımlı fallback davranışına dönüyor mu?
Son onaylı yapılandırma geri alınabiliyor mu?
Alarmdan sonra operatör hangi ekranda hangi kanıtı görüyor?
Saha müdahalesi üretim trafiğini veya yaya emniyetini bozmadan nasıl kayıt altına alınıyor?

Bu soruların cevapları, güvenlik ekibinin sonradan eklediği denetim maddeleri değil; sistem kabul kriterlerinin kendisi olmalıdır.

Tedarikçi, Firmware ve Yaşam Döngüsü: “Kurduk, Bitti” Neden Yanlış?

Trafik sinyali sistemleri çoğu zaman uzun ömürlüdür. Cihazın yıllarca sahada çalışması; eski firmware, yavaş güncelleme penceresi, azalan üretici desteği ve unutulmuş yönetim hesapları riskini de taşır. OT’de güncelleme, masaüstü yazılım güncellemesi gibi ele alınamaz: yeni sürümün zamanlama, protokol uyumluluğu, merkezi yazılım ve saha çalışma koşulları üzerindeki etkisi laboratuvarda doğrulanmalıdır.

İyi tedarik sözleşmesi şunları açıkça ister:

Desteklenen firmware ve güvenlik güncelleme politikası
Güvenlik açığı bildirim kanalı, hedef yanıt süreleri ve sorumlu ekip
Donanım/firmware yaşam sonu tarihi ve geçiş planı
Konfigürasyon, MIB ve entegre servislerin eksiksiz dokümantasyonu
Yerel ve uzaktan bakım erişiminin teknik şartları
Olay loglarına kurumun erişim hakkı ve dışa aktarım biçimi
Güncelleme öncesi test, geri alma ve güvenli operasyon prosedürü

NTCIP 1202 uyumluluğu iddiası olan cihazlarda, üreticiye özgü veya kurum özelindeki nesnelerin anlamlı açıklamalar içeren MIB dokümantasyonuyla teslim edilmesi standardın uygunluk yaklaşımının parçasıdır. Bu, güvenlik açısından küçümsenmemelidir: belgesiz özel nesne, olay anında “bilinmeyen kontrol yüzeyi” demektir. NTCIP 1202 conformance notu

Güncelleme penceresi için üç ortam kuralı

Simülasyon/dijital ikiz: Plan ve algoritma değişikliğinin trafik performansı, kuyruk ve fallback üzerindeki etkisi ölçülür.
Entegrasyon ortamı: Merkezi sistem, protokol profili, kimlik doğrulama ve telemetri akışı üretime benzer biçimde denenir.
Kontrollü saha yayılımı: Düşük riskli örnek noktada izlenir; başarı eşiği sağlanmadan koridora/geniş filoya yayılmaz.

Bu üç aşama mükemmel güvenlik garantisi vermez. Ancak bir değişikliğin hem siber erişim kontrolünü hem fiziksel işletimi hem de operatör ekranlarını etkileyebileceğini kabul eden gerçekçi bir süreç sağlar.

Savunma Mimarisi: Kabine Antivirüs Kurmak Değil

Trafik denetleyicileri gecikme, erişilebilirlik, güvenlik ve fiziksel emniyet kısıtlarıyla çalışır. Bu nedenle kurumsal endpoint yaklaşımını doğrudan sahaya taşımak her zaman doğru değildir. Doğru model; ayrıştırma, görünürlük, kontrollü yönetim ve güvenli geri dönüş katmanlarını birlikte kurmaktır.

1. Envanter ve mülkiyet

Her kabin, denetleyici, iletişim modülü, dedektör, UPS, bakım bağlantısı ve merkezi yönetim yolu bir sahip ile kayıt altına alınmalıdır. CISA, OT ortamlarında donanım, yazılım ve destek altyapısı dahil varlık envanteri tutulmasını temel pratiklerden biri olarak vurgular. CISA ICS önerileri

2. Ayrı yönetim yolu

Saha denetleyicileri, ofis ağı veya İnternet’ten doğrudan yönetilmemelidir. Yönetim erişimi, allowlist/ACL, güvenlik duvarı ve gerekiyorsa DMZ arkasında tanımlı merkezlerden gelmelidir. NIST, kontrol ağı ile kurumsal ağ arasındaki DMZ’nin doğrudan yolları azaltabildiğini; CISA ise kritik OT ağlarında segmentasyon ve izlenen erişimi önerir. NIST OT ağ mimarisi, CISA Internet Exposure Reduction

3. Kimlik doğrulama ve süreli bakım erişimi

İnternet üzerinden doğrudan cihaz yönetimi kabul edilebilir bir varsayılan değildir. Uzak bakım gerekiyorsa jump host, MFA, kayıt, rol tabanlı yetki ve süreli erişim kullanılmalıdır. CISA, mümkün olduğunda MFA’nın jump host düzeyinde dahi uygulanmasını ve giriş/çıkış trafiğinin izlenmesini önerir. CISA uzaktan erişim rehberi

4. Değişiklik kanıtı

Plan, faz parametresi, firmware, yetkili hesap veya ağ profili değiştiğinde; “kim, neyi, hangi gerekçeyle, hangi onayla değiştirdi?” sorusu cevaplanabilmelidir. NTCIP 1202, başarılı SNMP GET/SET istekleri ve kimlik doğrulama hataları için izleme nesneleri tarif eder; bu kabiliyetin olay yönetiminde gerçekten kullanılabilmesi ise kurumun toplama ve saklama tasarımına bağlıdır. NTCIP 1202 SNMP gereksinimleri

5. Fiziksel bakım ve veri bütünlüğü

Pull box, saha kabloları, kabin kilidi, bakım portu ve dedektör elektroniği de varlık envanterinin parçasıdır. Fiziksel erişim kontrolü ile elektronik değişiklik kaydı ayrılmaz bir çift olmalıdır. Bir sensör hatası, bir kablo sorunu veya kötü kalibrasyon; siber olayla aynı operasyonel sonucu üretebilir. Bu yüzden olay müdahalesi hem OT güvenlik hem trafik bakım disiplinidir.

Türkiye Bağlamı: Sinyalizasyon Zaten Veriyle Çalışıyor

Bu konu teorik değildir. KGM’nin 2024 faaliyet raporu, devlet ve il yollarında trafik uyarmalı sinyalizasyonla çalışan yüzlerce kavşağı ve genişleyen haberleşme altyapısını bildiriyor. İBB ise bağlantı yollarındaki sensör verisine göre sinyal sürelerini ayarlayan çevrimiçi kavşak kontrolü kullandığını açıklıyor. Bu kaynaklar, herhangi bir kurumun güvenlik duruşu hakkında çıkarım yapmaya yetmez; ancak sensör, merkez ve saha kabini arasındaki veri akışının ülkemizde de gerçek bir operasyon konusu olduğunu gösterir. KGM 2024 Faaliyet Raporu, İBB çevrimiçi kavşak kontrolü

Bu nedenle yerel kurumlar için doğru başlangıç “hangi yabancı marka kullanılıyor?” sorusu değil; “hangi veri hangi ağ üzerinden hangi yetkiyle sinyal planını etkileyebiliyor?” sorusudur.

Tedarik ve Denetim İçin 12 Soruluk Kontrol Listesi

Kavşak, denetleyici, iletişim modülü ve dedektör envanteri güncel mi?
Her varlığın teknik ve operasyonel sahibi belirli mi?
Yönetim trafiği üretim dışı ağlardan ayrılmış mı?
Uzak erişim MFA, jump host ve oturum kaydı olmadan mümkün mü?
Kullanılan SNMP sürümü, kimlik doğrulama ve şifreleme profili belgeli mi?
Tedarikçi MIB’i, desteklenen nesneler ve isteğe bağlı NTCIP yetenekleri teslim edilmiş mi?
Yapılandırma değişiklikleri onay, zaman damgası ve geri alma planıyla kaydediliyor mu?
Faz süresi, max-out, preemption ve iletişim kaybı için tanımlı alarmlar var mı?
Dedektör verisi en az bir bağımsız operasyonel kaynakla doğrulanabiliyor mu?
MMU/CMU ve güvenli flaş modunun periyodik test kaydı var mı?
Arıza durumunda yaya, toplu taşıma ve acil durum operasyonu için fallback prosedürü var mı?
Tatbikat sonrası kanıtlar—olay günlüğü, karar kaydı, zaman çizelgesi ve düzeltme planı—saklanıyor mu?

Son Söz

Trafik sinyali güvenliği, “gri kutu internete açık mı?” sorusundan büyüktür. Asıl mesele; normal davranışı bilen, değişikliği kanıtlayabilen, sensör verisini doğrulayabilen ve güvenli şekilde geri dönebilen bir işletim modelidir.

Modern kavşak, bir lambadan çok daha fazlasıdır: fiziksel emniyet kuralları, insan hayatı, zamanlama politikaları ve ağ yönetimi aynı state machine’de buluşur. Bu yüzden iyi savunma da tek ürün değildir. Doğru envanter, ayrı yönetim ağı, güçlü kimlik doğrulama, olay görünürlüğü, sensör sağlığı ve eğitimli operasyon ekibinin birlikte çalışmasıdır.

Sık Sorulan Sorular

NTCIP 1202 kullanan her kavşak SNMPv2c ile mi çalışır?

Hayır. NTCIP 1202, sinyal denetleyicileri için veri ve işlev tanımlar. Kullanılan taşıma ve güvenlik profili; denetleyici, üretici, kurum şartnamesi ve kurulum kararlarına bağlıdır. Sürüm, erişim kontrolü ve ağ ayrıştırması doğrulanmadan güvenlik sonucu çıkarılamaz.

Conflict monitor veya MMU bütün siber riski engeller mi?

Hayır. MMU/CMU, belirli kabin arızalarında güvenli duruma geçiş için çok değerlidir. Ancak yetkisiz yönetim erişimi, yanlış yapılandırma, sensör tutarsızlığı, zayıf loglama veya operasyonel kurtarma eksikliği gibi riskleri tek başına çözmez.

SUMO ile yapılan test gerçek kavşağın aynısı mıdır?

Hayır. SUMO, trafik akışı ve kontrol mantığını güvenli biçimde modellemek için güçlü bir simülasyon aracıdır. Gerçek donanımın tedarikçi özellikleri, saha kablolaması, emniyet sertifikaları ve kurum prosedürleri ayrıca değerlendirilmelidir.

İlk yatırım nereden başlamalı?

Önce varlık ve erişim envanterinden. Hangi kabinlerin hangi merkezlerden yönetildiği, hangi kimliklerin bakım yetkisi olduğu ve hangi sensör verisinin hangi planı etkilediği bilinmiyorsa, daha gelişmiş izleme ürünleri de güvenilir sonuç vermez.