Endüstriyel Kontrol Sistemlerini güncellemek için IT çalışanları sistemleri devre dışı bırakıyorlar. Fakat ICS’lerin servis süresini azaltmak, hatta belirli bir süre için devre dışı bırakmak çok ciddi sorunlar ortaya çıkartabilir.
Bütün dünyada bulunan endüstriyel kontrol sistemleri eskiden birbirlerinden izole bir biçimde kullanılıyordu fakat iletişim teknolojilerinin gelişmesi ile bu sistemler artık birbirleri ile çok daha ilişkilendirilmiş biçimdeler. Artık kolayca birbirlerine bağlanan bu sistemler ekonomik olarak da birbirlerine bağımlılar. Geçmişte, bu tür sistemlerde bir sorun olduğunda, sorun izole edilip, kolayca tamir edilebiliyordu fakat günümüzde ICS’lerde oluşan bir hata, birbiriyle iletişim halinde olan bir çok başka sistemi etkilemektedir. Bu sebeple hataları bulmak ve diğer sistemleri etkilemeden izole etmek gün geçtikçe daha da zorlaşmaktadır. Aynı zamanda oluşan tek bir hata, iletişim protokolleri sayesinde genel sistemin başka bir bileşeninde hataya ve hatta izinsiz erişime yol açabilmektedir.
Bazı sektörlerde ICS’ler toplam çalışma sürelerinin %99,99’unu hizmet sağlayarak geçirmelidir. Bu oran sistemlere yılda 5 dakika ile 35 saniye aralığında bir aksama süresi tanıyor. Bu zorunluluktan dolayı planlanmamış güncellemeler söz konusu bile değildir. ICS’lerde yeni güncelleme yayınlamak sistemin bütünlüğü açısından çok önemlidir. Bu görevi yapabilmek için güncelleme yönetim programı tanımlanmalı ve uygulanmalıdır. Bu süreci belirlerken ilk kritik adım olan sistemden sorumlu kişilerin arasındaki iletişim kanallarını belirlemektir. Çünkü bir zafiyet anında sistemdeki sorunun çözülmesi için ilk bu kişiler çalışacaktır.
Güncelleme Yönetim Programı
İyi bir güncelleme yönetim programı aşağıdaki planları içerir:
(1) Kurulum Yönetimi Planı
(2) Güncelleme Yönetim Planı
(3) Yama test süreci
(4) Yedekleme ve arşivleme süreci
(5) Olay Müdahale Planı
(6) Felaket Kurtarma Planı
1. Kurulum Yönetimi Planı
– Yazılımların en son ve istikrarlı versiyonları kullanılmalıdır.
– Donanımların envanteri her zaman güncellenmeli ve sadece yetkili kişiler ulaşabilmelidir.
– Ağ elementlerinin (kablolar, switchler vs.) güncel haritası tutulmalıdır.
2. Güncelleme yönetim planı
– Hassasiyet ve maruz kalma testleri sistemi bilen kişiler tarafından yapılmalı ve bu incelemeler sistemden sorumlu olan diğer kişiler ile paylaşılmalıdır. Bu kişiler acil durumlarda sisteme müdahale yetkisine sahip olmalıdır.
– Aciliyet incelemeleri, sistemde oluşabilecek hataların, o anda devam eden operasyonlara ne kadar zarar verebileceğini belirlemelidir.
– Güncellemelerin yayınlanmaları veya sistem üzerinde yapılan başka modifikasyonlar ICS’nin garantisini etkileyebilir. Bu yüzden bu tip güncellemeler yapılmadan önce satıcı ile iletişime geçilmesi tavsiye edilir.
3. Yama Test Süreci
Üretilen güncellemeler sistem üzerinde aktifleştirilmeden önce test edilmelidir. Bu testlerde, yeni güncellemenin olan sorunlara çözüm sağladığı ve daha önceden bulunan uygulamalarla tutarsızlık göstermediği doğrulanmalıdır.
4. Yedekleme ve Arşivleme Süreci
Sistem üzerinde herhangi bir güncelleme işlemi yapılmadan önce canlı sistemin en güncel ve çalışan hali yedeklenip arşivlenmelidir.
Ayrıca bu plan sistemin ne kadar sıklıkla yedekleneceğini, bu yedeklerin doğrulamasını ve yedeklerin fiziksel olarak nerede, nasıl ve ne kadar süre ile tutulacağını belirtmelidir.
5. Olay Müdahale Planı
ICS’de oluşabilecek yeni açıkları tarama ve tanıma süreci tanımlamalı ve oluşan sorunları varolan çözümleri kullanarak çözümlemeyi hedefler. Aynı zamanda keşfedilen açığı, sistem ile ilgilenen yetkili kişilere haber vermelisini öngören bir süreç tanımlanmalıdır.
6. Felaket Kurtarma Planı
Sisteme karşı gerçekleştirilen bir saldırı sonucu oluşan hasarı veya doğal afetler gibi fiziksel olaylardan oluşan hasarları eski haline döndürmek için yapılan plandır.
Bunun için önerilen bir çözüm, sistemin donanımsal ve yazılımsal olarak bir kopyasını test ortamı olarak hazırlayıp, ana sistemden farklı bir yerde tutulmasıdır. Bir diğer tavsiye ise; önceden alınan sistem yedeklerinin, ne kadar sürede tekrar çalışır hale getirme süresinin belirlenmesidir.
Bu gibi durumlarda, en ideal kurulum, aynı ünitelerden bazıları çalışır, diğerleri ise beklemede ya da yedek olarak tutularak kullanılmalıdır. Böylelikle olası bir hasar halinde en kısa sürede yedek sistemler kullanılarak tekrar servis sağlanabilir ve yedek sistemler devredeyken ana sistem onarılabilir.
Güncelleme Analizi
Analizleri yapan kişiler genelde IT çalışanları ve kurum yöneticileridir ve bu iki grup durumu farklı perspektiflerden inceler. Bu incelemeler koordineli bir şekilde yapılıp, riskin seviyesi ve kurumun bu riske karşı olan dayanıklılığı belirlenmelidir. Bu analiz sürecine dahil olan herkes fikirlerini açıkça belirtmelidir ki kontrol komitesi ortak bir paydada buluşabilsin.
Hassasiyet Analizi
Sisteme erişim hakkı olan bir takım kurulup, bu kişiler sistemi varolan ve tanımlanmış güvenlik zaafiyetlerine karşı taramalıdırlar. Yapılan taramaların sonucunda, sistemin açıkları derlenip, bütün açık noktalar için hassasiyet şeması oluşturulmalıdır. Bu işleme hassasiyet analizi denir.
Hassasiyet şeması 4 subjektif ve ana elementten oluşur. Bunlar etki, teşhir, canlıya alma ve basitliktir. Bu 4 elementin karo şeklinde grafiksel olarak gösterimine hassasiyet şeması denir. Bu grafiksel gösterim ne kadar büyükse sistem o kadar hassastır.
Etki : Yapılan saldırının sisteme etkisini belirlemek için kullanılır.
Teşhir : Sistemde olan açığın bilinirliğini ölçer. Eğer herkes tarafından bilinen bir zafiyet ise bu değer yüksek olur.
Basitlik : Bulunan açığı kullanma becerisi ne kadar az ise bu değer o kadar yüksek olur.
Canlıya Alma : Bilinen bir açığın canlı sistemde kullanması durumunda bunun sistemin genelinde yaratabilecek etkiyi ve riski belirlemek için kullanılır
Hassasiyet Şema
Örneği
Güncelleme
Karar Süreci.