OT güvenlik programlarının neredeyse hepsi aynı noktadan başlar: varlık envanteri. Segmentasyon, zafiyet yönetimi, anomali tespiti, olay müdahalesi ve uyumluluk raporları; doğru ve güncel bir envantere dayanır. Envanter yoksa bu çalışmalar tahmine dönüşür.
Neden OT’de envanter farklı?
- Cihaz çeşitliliği yüksektir: PLC’ler, RTU’lar, HMI’lar, sürücüler, güvenlik duvarları, anahtarlar, Windows tabanlı sunucular ve mühendislik istasyonları.
- Birçok cihaz ömrünü uzun yıllar sürdürür; eski yazılım ve işletim sistemleri yaygındır.
- Bazı cihazlar aktif taramaya duyarlıdır: beklenmeyen paketler yanıt vermemeye veya yeniden başlamaya yol açabilir.
- Duruş pencereleri kısıtlıdır; envanter çalışması üretimi etkilememelidir.
Hangi bilgiler tutulmalı?
| Alan | Neden önemli? |
|---|---|
| Cihaz türü, üretici, model | Zafiyet eşleştirmesinin temeli |
| Yazılım (firmware) ve yazılım sürümleri | Hangi zafiyetlerin geçerli olduğunu belirler |
| İşletim sistemi ve yüklü yazılımlar | Windows/Linux tabanlı sistemlerde yama durumu |
| Ağ adresi ve konuştuğu protokoller | Segmentasyon ve anomali tespiti için temel çizgi |
| Konum ve bölge (zone) | Risk ve sorumluluk eşlemesi |
| Kritiklik ve sahibi | Önceliklendirme ve iletişim |
| Yapılandırma (konfigürasyon) yedeği | Değişiklik tespiti ve kurtarma |
Envanter nasıl çıkarılır?
- Pasif ağ izleme: Ağ trafiği dinlenerek (örneğin bir ayna port üzerinden) cihazlar ve protokoller çıkarılır; cihazlara paket gönderilmez.
- Kontrol sisteminden mevcut verinin toplanması: Kontrol sistemlerinin kendi yönetim arayüzlerinden, yedeklerinden ve sistem kayıtlarından güvenle veri çekmek; üretimi etkilemeden zengin yapılandırma bilgisi sağlar.
- Kontrollü aktif sorgulama: Yalnızca test edilmiş ve kabul edilen cihaz sınıfları için, planlı pencerelerde.
- Elle/CMDB girişi: Sahadaki fiziksel sayımla ve mevcut kayıtlarla çapraz doğrulama.
Çoğu olgun programda bu yöntemler birleştirilir. Kritik nokta, aktif taramaya körü körüne başvurmamaktır.
Envanterden zafiyet yönetimine
Envanter hazır olduğunda, her varlığın üretici/model/sürüm bilgisi bilinen zafiyetlerle eşleştirilebilir. Kamuya açık kaynaklar arasında CVE kayıtları ve ICS danışma bültenleri (örneğin CISA ICS Advisories) bulunur. Ancak OT’de zafiyet yönetimi, BT’deki “yamala ve yeniden başlat” döngüsünden farklıdır:
- Yama her zaman mümkün değildir. Üretici onayı, test ve planlı duruş gerekebilir; bazı cihazlar için yama hiç yayımlanmamış olabilir.
- Önceliklendirme bağlam ister. Yalnızca CVSS puanı yetmez; cihazın ağdan erişilebilirliği, kritikliği ve mevcut telafi edici kontroller (segmentasyon, erişim kısıtı) risk düzeyini değiştirir.
- Telafi edici kontroller değerlidir. Yama yapılamıyorsa erişimi sınırlamak, hizmeti kapatmak veya izlemeyi artırmak da geçerli bir yanıttır. (Segmentasyon)
Süreklilik: envanter bir kez çıkarılan bir liste değildir
Bir envanter, ancak değişiklikleri izlenirse değerlidir: yeni cihazlar, değişen yazılım sürümleri, kaldırılan sistemler ve yapılandırma değişiklikleri. Yapılandırma temel çizgisi (baseline) ile sapmaları karşılaştırmak, yetkisiz değişiklikleri erken yakalamanın en pratik yoludur.
Uyumluluk ile ilişkisi
IEC 62443, NIST ve NERC CIP gibi çerçeveler varlık envanteri, yapılandırma yönetimi ve zafiyet/yama yönetimini ayrı gereksinimler olarak ele alır. Doğru envanter, uyumluluk kanıtlarını elle derlemek yerine otomatik üretmeyi mümkün kılar.
Industrial Defender ASM
Industrial Defender ASM, endüstriyel kontrol sistemlerinden mevcut veriyi güvenli biçimde toplayarak OT varlık envanteri ve yapılandırma takibi, gerçek zamanlı anomali tespiti, zafiyet yönetimi ve IEC 62443, NIST, NERC CIP ile ISO 27001 uyumluluk şablonları sunar. Ürünü ve kullanım senaryolarını Industrial Defender sayfamızda, programın tamamını ise OT/ICS siber güvenliği çözüm sayfamızda bulabilirsiniz.
