Bir yazılım tedarikçisiyseniz ve müşteriniz EU NIS2 direktifi kapsamındaysa, siz de etkilenebilirsiniz.
Michael Rask Christensen, CISSP, CSSLP, Kopenhag’daki NNIT A/S’de
Merkezi Danimarka’nın Kopenhag kentinde bulunan ve yakın zamanda Avrupa Konseyi tarafından kabul edilen NIS2 direktifi herkesin konuştuğu konuların başında geliyor. Aslında NIS2, Avrupa Birliği’ndeki BT güvenlik uzmanları arasında gündemin başında yer alıyor. Şirketler ve kuruluşlar, işletmeler üzerindeki etkinin tam olarak ne olacağını tartışıyorlar?
NIS2 nedir?
NIS2, bir düzenleme olan GDPR’nin aksine bir direktiftir. Aradaki fark, bir direktifin doğrudan yasal etkisinin olmaması, bunun yerine üye devletler tarafından yerel mevzuata dönüştürülmesinin gerekmesidir. Yönergenin uygulanması için son tarih Ekim 2024’tür. NIS2 yönergesi, siber güvenlikleri denetlenecek olan uzun bir kritik ve önemli sektörler listesini etkiler. Bu hem prosedürler hem de gerçek teknik uygulamalardır.
NIS2’nin amacı, direktifin önkoşul metinlerinden birinde özetlenebilir. Madde (77) diyor (vurgu bana ait): “Ağ ve bilgi sisteminin güvenliğini sağlama sorumluluğu büyük ölçüde temel ve önemli kuruluşlara aittir. Risk değerlendirmelerini ve karşılaşılan risklere uygun siber güvenlik risk yönetimi önlemlerinin uygulanmasını içeren bir risk yönetimi kültürü teşvik edilmeli ve geliştirilmelidir.” Ama sonuçta, NIS2 direktifi bir kültür değişikliğinden başka bir şeyi amaçlamıyor!
Bu NIS2 yönergesi pek çok içeriği kapsar – yönergeyi EUR-Lex web sitesinden PDF olarak indirirseniz 73 sayfa. HTML sürümüne https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555 adresinden erişilebilir. Hukuk danışmanları bile muhtemelen tüm detayları öğrenmek için kitabı birden fazla kez okumak zorunda kalmışlardır. Bu makale, bu ayrıntılardan birine odaklanacaktır – AB dışındaki yazılım tedarikçilerini bile etkileyecek zincirleme sorumluluk.
NIS2’de zincir sorumluluğu
Doğrudan NIS2 tarafından kapsanan iş türleri, NIS2 direktifinin Ek I ve II’sinde oldukça iyi tanımlanmıştır. Yüksek kritikliğe sahip sektörler örneğin şunlardır: Enerji, ulaşım, bankacılık, sağlık, dijital altyapı ve kamu yönetimi. Listede daha çok şey var, ancak kuruluşunuz AB’deyse ve bu alanlardan birinde faaliyet gösteriyorsa, NIS2’den doğrudan etkilenir ve güvenlik önlemlerinden doğrudan sorumlu tutulur.
Elbette direktif, kuruluşların güvenlik önlemlerini nasıl uygulamaları gerektiğini tam olarak belirtmiyor. Bu, yasa koyucuların yetki alanı dışındadır. Ancak “Siber güvenlik risk yönetimi önlemleri” başlıklı 21. Madde, temel ve önemli kuruluşların BT sistemlerini korurken kapsaması gereken alanları listeler. Yönerge, “tüm tehlikelere yönelik bir yaklaşım” terimini kullanır.
21. Maddenin 3. paragrafında ayrıca, “Üye Devletler, bu Maddenin 2. paragrafının (d) bendinde atıfta bulunulan hangi önlemlerin uygun olduğunu değerlendirirken, kuruluşların her bir doğrudan tedarikçiye özgü güvenlik açıklarını dikkate almasını sağlayacaktır. ve hizmet sağlayıcı ve güvenli geliştirme prosedürleri dahil olmak üzere tedarikçilerinin ve hizmet sağlayıcılarının genel ürün kalitesi ve siber güvenlik uygulamaları. Paragraf 2, nokta (d) tedarik zincirini listeler
tüm tehlikeler yaklaşımına dahil edilmesi gereken önlemlerden biri olarak, her bir kuruluş ile onun doğrudan tedarikçileri veya hizmet sağlayıcıları arasındaki ilişkilere ilişkin güvenlikle ilgili hususlar da dahil olmak üzere güvenlik.
Tedarik zinciri güvenliği söz konusu olduğunda direktif, AB içinde ve birlik dışında ikamet eden tedarikçiler arasında ayrım yapmaz. NIS2 kapsamına giren şirketlerin tümü, tüm tedarikçilerinin güvenliğini sağlamakla yükümlüdür.
Kopenhag Havalimanları CIO’su geçtiğimiz günlerde bir NIS2 konferansında bir konuşma yaptı. SaaS sağlayıcılarından birinden müşteri verilerini nasıl yedeklediklerini ve testleri nasıl geri yüklediklerini anlatan bir hesap yazmasını istediklerini söyledi. SaaS sağlayıcısının yanıtı, “Bulut içindeyiz, bu nedenle yedekleme ve geri yükleme yapmamıza gerek yok” oldu. Korkarım ki bu, SaaS teklifi sağlayıcıları arasında yaygın bir yanılgıdır!
Kamu ihaleleri bir süredir, özel uygulama geliştiricisi olarak teklifin bir parçası olarak güvenli geliştirme prosedürlerimizi ayrıntılı olarak belgelememiz gereken özel gereksinimler içermektedir. NIS2 ile bu, yalnızca AB üye devletlerindeki kamu sektörü için bir gereklilik olmayacak, aynı zamanda NIS2 gerekliliklerine göre denetlenen şirketler için de gerekli olacaktır. Örneğin, su arıtma tesisi tasarım yazılımı geliştirme işindeyseniz, müşterileriniz
Şirketinizin merkezi ABD’de mi yoksa AB’de mi olsun, AB size bunları soracaktır.
Güvenli geliştirme prosedürleri
Güvenli geliştirme prosedürleri, yazılıma güvenlik özellikleri eklemekle ilgili değildir. Bunlar zaten işlevsel gereksinimler olmalı ve buna göre test edilmelidir. Ancak güvenlik özellikleri, güvenli geliştirme süreci nedeniyle gereksinim haline gelebilir.
Güvenli bir geliştirme prosedürü, uygulamanın güvenli hale gelmesinin nasıl sağlanacağına odaklanır. Bir tehdit modeliyle başlar:
- Yazılım çözümünü modelleyin.
- Saldırı yüzeylerini tanımlayın. Bu, birinin bir kullanıcı arabirimi veya bir API aracılığıyla uygulama eterimle etkileşime girebileceği her yerdir.
- Açık kaynak kitaplıkları dahil olmak üzere harici bileşenlere olan bağımlılıkları belirleyin.
- Veri modelini analiz edin ve korunması gereken verileri belirleyin. Bu, kişiyi tanımlayan veriler veya fikri mülkiyet olabilir.
- İlgili tüm tehditleri listeleyin.
Tespit edilen tehditlere dayalı olarak, tehditleri azaltan gereksinimleri tanımlayın. Bunları uygulayın ve uygulamayı koruyup korumadıklarını test edin.
Güvenli yazılım geliştirme için önerilen bir çerçeve, Microsoft Güvenlik Geliştirme Yaşam Döngüsü’dür (SDL). Bazılarımız Windows’un 20 yıl önce bilgisayar korsanlarının cenneti olarak anıldığını hatırlıyor. Redmond’da gündemin başında güvenlik değil, yeni süslü işlevler görünüyordu. 2004 yılında SDL, Microsoft’un geliştirme sürecinin ayrılmaz bir parçası haline geldi. Microsoft, SDL uygulamalarını https://www.microsoft.com/en-us/securityengineering/sdl adresinde herkesin kullanımına sunmuştur. SDL on iki ana uygulamadan oluşur:
Alıştırma 1: Eğitim: Güvenlik sadece bir avuç güvenlik uzmanının sorumluluğu değildir. Geliştirme sürecindeki tüm kişiler, SDL uygulamaları ve standartları konusunda eğitilmelidir.
Uygulama 2 – Güvenlik Gereksinimleri: Risk değerlendirmesinin sonucu güvenlik gereksinimleridir.
Uygulama 3 – Metrikler ve Uyumluluk Raporlaması: Ölçülemeyen şey genellikle unutulur!
Uygulama 4 – Tehdit Modelleme: Microsoft, tehdit modellemesi yapmak için bazı ücretsiz araçlara sahiptir. Tehdit modelleme, güvenlik gereksinimlerine girdi oluşturan güvenlik açıklarını ve riskleri belirleyecektir.
Uygulama 5 – Tasarım Gereksinimleri: Tasarıma güvenlik özellikleri eklendiğinde, özelliklerin neden ve hangi güvenlik açıklarını ele alması gerektiğini tam olarak bilmek önemlidir.
Uygulama 6 – Kriptografi Standartları: Hangi kriptografi standartlarının nerede ve neden kullanıldığı. Bu noktada, endüstri tarafından genel kabul görmüş kütüphanelerin ve yöntemlerin kullanılmasının önemini vurgulamak da önemlidir. Ve bugünün güvenli kriptografi standardının yarının güvensiz standardı olduğunu unutmayın. Tasarım, yeni standartları karşılayacak kadar esnek olmalıdır. ABD’den 128 Kbit şifreleme yazılımının ihracatının yasaklandığı zamanı kişisel olarak hatırlıyorum çünkü
hükümet bunu kırmanın çok zor olduğunu düşündü (o zamanki işverenimin VPN’i aracılığıyla 128 Kbit’lik bir Netscape tarayıcısı indirdim, ama bu başka bir hikaye).
Uygulama 7 – Üçüncü Taraf Bileşenlerini Kullanmanın Güvenlik Riskini Yönetin: Neredeyse hiç kimse her şeyi aşağıdan yukarıya kodlamıyor. Tüm profesyonel yazılımlar, çerçeveler üzerine kuruludur ve üçüncü taraf kitaplıkları ve hizmetleri içerir. Bu bileşenleri yazılım çözümünüze dahil ettiğinizde, bu bileşenlerin güvenliği uygulamanızın güvenliğini doğrudan etkiler.
Alıştırma 8 – Onaylanmış Araçları Kullanın: Hangi derleyiciler ve derleyici ayarları kullanılmalıdır? Kod her zaman güncel derleyicilerle en son onaylanmış yamalarla derlenmelidir.
Uygulama 9 – Statik Analiz Güvenlik Testi – Statik analiz güvenlik testi gerçekleştirmek için uzun bir araç listesi vardır. Kendi şirketimde, tüm üçüncü taraf kitaplıklarının da analiz edilmesini sağlamak için ikili dosyalar üzerinde analiz yapan bir tane kullanıyoruz.
Uygulama 10 – Dinamik Analiz Güvenlik Testi: Dinamik analiz güvenlik testi, uygulamayı çalıştırma sırasında test edecektir. Bu, web taramasını içermelidir ancak örneğin arabellek taşmalarının doğru bir şekilde ele alınıp alınamayacağını görmek için uygulamanın kullanıcı arabirimlerine ve API’lerine aşırı verilerle erişildiği bulanıklaştırmayı da içerebilir.
Alıştırma 11 – Sızma Testi: Yetenekli bir penetrasyon testçisi aslında “Karanlık Taraf” için değil, sizin için çalışan bir bilgisayar korsanıdır. Sızma testi genellikle yukarıda belirtilen diğer testlerle birlikte yapılır, ancak başka türlü bulunmayan güvenlik açıklarını ortaya çıkarabilir.
Uygulama 12 – Standart Olay Müdahale Süreci: Notepad++ gibi nispeten basit bir uygulamada bile şu anda bilinen beş güvenlik açığı vardır: https://cve.report/vendor/notepad-plus-plus – bunlardan ikisi yüksek önem derecesine sahiptir. Tüm yazılım satıcılarının standart bir olay müdahale süreci geliştirmesi gerekir. Yazılım ürününüzdeki güvenlik olaylarını nasıl ele alacağınızı, müşterilerinizi nasıl bilgilendireceğinizi ve sorunu nasıl çözeceğinizi önceden planlamanız gerekir.
ISO standartları
NIS2 yönergesi, belgeyle ilgili olarak çeşitli ISO standartlarına atıfta bulunur. Güvenlik açığı ifşası ve güvenlik açığı yönetimi ile ilgili süreci kapsayan ISO 30111 ve ISO 29147’ye atıfta bulunur. Bunlar, yukarıda bahsedilen Uygulama 12, “Standart Olay Müdahale Süreci”ni kapsamak için iyi birer ilham kaynağıdır.
ISO 27001 ve ilgili standartlar (bkz. https://www.iso.org/isoiec-27001-information-security.html) genel olarak NIS2 gereksinimlerini karşılayan bir güvenlik organizasyonu oluşturmak için iyi bir çerçevede anılır. Şirketinizin ISO 27001 sertifikasına sahip olması, NIS2 tarafından kritik bir varlık olarak tanımlanan bir müşteri ile aranıza güven aşılamak için genellikle iyi bir başlangıç noktasıdır. Ancak, elbette, tüm doğru politikaların yürürlükte olması sadece iyi bir başlangıçtır. Politikaların kendileri, kimsenin sistemlerinizi hacklemesini engellemez! Genellikle ISO standartlarını 18 CIS denetimiyle birleştirmeniz önerilir: https://www.cisecurity.org/controls/cis-controls-list.
Çözüm
Şirketinizin herhangi bir şirket veya kuruluşa NIS2 direktifi tarafından kritik veya önemli görülen yazılım veya yazılım hizmeti vermesi durumunda, dolaylı olarak aynı rejime tabi olursunuz. Bunu bir tehdit veya zaten harika olan ürün veya hizmetinizi artırmanın olası bir yolu olarak görebilirsiniz. ABD’de ikamet ediyorsanız, kritik altyapıyı korumak için benzer önlemlerin er ya da geç benimseneceğine bahse girerim!
