NCSC.nl

1. Giriş

Toplum giderek daha fazla dijitalleşiyor. Günümüzde neredeyse tüm süreçler, cep telefonlarından özel yazılımlara kadar bir noktada bilgisayar kullanımını içeriyor. Bu gelişme birçok yeni fırsat yaratsa da, BT sistemlerindeki güvenlik açıkları büyük bir etki yaratabilir. Sonuç olarak, bu güvenlik açıkları hakkındaki bilgi etkili bir şekilde ele alınmalıdır.

Bir dizi kuruluş, güvenlik açıklarının nasıl bildirileceğine ilişkin politikaları 2013'ün başında yayınlamaya başladı. Bu taraflarla istişareden sonra, Ulusal Siber Güvenlik Merkezi (National Cyber Security Centre, NCSC) gelişmeleri 'Sorumlu Bildirim (Responsible Disclosure) uygulamasına ulaşmak için Yönergeler' ('Leidraad om te komen tot een praktijk van Responsible Disclosure'; 'Yönergeler') biçiminde özetledi. Şirketler bu politika aracılığıyla dış kaynaklı güvenlik açığı raporlarını almaya açık olduklarını belirtir, ön koşullarını tanımlar ve sözler verir. Bu süreç, bildiren tarafların doğrudan bir suç işlemeden güvenlik açıklarını araştırması ve bildirmesi için netlik ve bir ölçüde güvenli bir ortam yarattı. 2016'daki AB üst düzey siber güvenlik toplantısında 29 kuruluş, güvenlik açıklarıyla başa çıkmaya yönelik bir politikanın önemini, CIO Platform Netherlands ve Rabobank tarafından NCSC ile işbirliği içinde başlatılan Koordineli Güvenlik Açığı Bildirimi Manifestosu'nu (Coordinated Vulnerability Disclosure Manifesto)1 imzalayarak yeniden teyit etti.

Koordineli Güvenlik Açığı Bildirimi (Coordinated Vulnerability Disclosure, CVD) kamu ve özel taraflar için büyük önem taşıdığını kanıtladı. Günlük uygulamada bilgi sistemlerinin kesintisiz işleyişine büyük ölçüde bağımlıdırlar. Sistemlerindeki güvenlik açıklarına ilişkin raporlar, son yıllarda bir yandan güvenlik açıklarını gidererek, diğer yandan Hollandalı şirketlerin BT güvenliği konusundaki genel farkındalığına katkıda bulunarak sistemlerin güvenliğini ve sürekliliğini iyileştirmeye yardımcı oldu.

Son yıllarda, bildiren tarafların kuruluşlar tarafından hazırlanan CVD politikasının koşulları içinde çalışmaya hazır olduğu netleşti. Raporlar, bildiren taraflarca kuruluşlara doğrudan veya dolaylı olarak yapılır. Sorumlu bildirim uygulaması, iyi niyetli bildiren tarafların ve savunmasız kuruluşların işbirliği yapmayı ve böylece ağ ve bilgi sistemlerinin güvenliğini artırmada bir sonraki adımı atmayı başardığını gösterdi.

Bu revizyon için, bir kez daha geniş ve çeşitli bir bildiren taraflar grubuyla, özel ve kamu taraflarıyla, ayrıca Kamu Savcılığı ve Ulusal Polis ile görüştük. Bu görüşmeler mevcut uygulamayı doğruladı ve eklemelere ve iyileştirmelere yol açtı. En önemli yeni dikkat noktası, güvenlik açığını bildiren kişi ile kuruluş arasındaki iletişim ve güvenlik açığı giderildikten sonra diğer taraflarla iletişimdir.

Aşağıdaki bölümler CVD'nin tanımını, bir CVD politikasının yapı taşlarını ve iletişim sürecini ele almaktadır.

Not: Önceki Yönergeler, o dönemde bu uygulama için yaygın terim olan 'sorumlu bildirim' (responsible disclosure) terimini kullanıyordu. Bu arada bu terimin, bildiren tarafın sorumluluğuna fazla vurgu yaptığı netleşti, oysa temel ilke, bildiren taraf ile potansiyel olarak savunmasız kuruluşun diyalogda eşit ortaklar olması gerektiğidir. Bu görüş, şu anda yaygın olarak kullanılan 'Koordineli Güvenlik Açığı Bildirimi' (Coordinated Vulnerability Disclosure, CVD) teriminde daha iyi yansıtılmaktadır; bu terim aynı zamanda bu süreçle ilgili ISO 29147 ve 30111 standartlarında da kullanılan addır.

2. Koordineli Güvenlik Açığı

Son 30 yıl boyunca BT sistemlerindeki güvenlik açıklarına ilişkin farkındalığı artırmak için çeşitli yöntemler kullanıldı. Örnekler şunları içerir:

'Tam Bildirim' (Full Disclosure), bir güvenlik açığını tamamen herkese açık hale getirmek;
'Bildirmeme' (Non-disclosure), bir güvenlik açığını satmak veya kendiniz kullanmak;
'Koordineli Güvenlik Açığı Bildirimi' (CVD), bir güvenlik açığının koordineli olarak bildirilmesi.

İkinci uygulama açıkça tercih edilir.

BT topluluğu bilgi ve deneyim paylaşmaya büyük bir istek göstermiştir. Bu toplulukla işbirliği aramak bu nedenle sistemlerin genel güvenliğini iyileştirmeye yardımcı olabilir.

Koordineli Güvenlik Açığı Bildiriminin Amacı

CVD'nin amacı, güvenlik açıkları hakkındaki bilgiyi paylaşarak BT sistemlerinin güvenliğine katkıda bulunmaktır. CVD'de bilgi, bildiren tarafla işbirliği içinde bulunan güvenlik açığı için ortak bir çözüme ulaşmak amacıyla bir veya daha fazla potansiyel olarak savunmasız kuruluşla paylaşılır. Etkilenen kuruluşların, kayıp veya zararı mümkün olduğunca sınırlamak veya önlemek için herhangi bir güvenlik açığını gidermek veya sistemleri korumak adına yeterli zamana sahip olması önemlidir. Sürecin temel taşı, düzeltmeden sonra güvenlik açıkları hakkındaki bilginin açıklanmasıdır.

CVD'de tüm tarafların bir güvenlik açığının nasıl bildirileceği ve nasıl ele alınacağı konusundaki anlaşmalara uyması esastır. Bir kuruluşun hangi sistemlerin kapsamda olduğu ve ne tür araştırmaların yapılabileceği gibi ön koşulları önceden yayınlaması yardımcı olur. Bu ön koşullar için önemli bir ilke, kuruluşun, araştırma ve bildirim belirlenen koşullar içinde yürütülürse prensip olarak bildiren tarafı ihbar etmeyeceği veya başka yasal adımlar atmayacağıdır. Bu Yönergeler kuruluşlara, CVD ilkelerini somutlaştıran kendi politikalarını hazırlamada rehberlik sağlar.

Adından da anlaşılacağı gibi, CVD'de merkezi olan, kuruluş ile bildiren tarafın birbirleriyle koordine olmasıdır. Bu bağlamda, güvenlik açığını bildiren kişi ile kuruluş içinde sorunu çözmekten sorumlu kişi arasında mümkün olduğunca az halka olmalıdır.

Bir güvenlik açığı birçok sistemi etkiliyorsa, birkaç tarafı aynı anda bilgilendirmek önemli olabilir. Bu durumda, NCSC veya güvenlik topluluğu içindeki diğer taraflar CVD sürecini koordine edici bir rolden destekleyebilir.

3. Sorumluluk alanları

Bir CVD politikası izlemenin amacı, bildiren tarafların ve kuruluşun BT sistemlerindeki güvenlik açıklarını azaltmak için birlikte çalışmasıdır. Bu politikanın uygulanması, bilgi güvenliğine ilişkin mevcut önlemlere bir ek olarak görülmelidir. Çeşitli aktörlerin her birinin kendi rolü ve sorumlulukları vardır. Bunlar aşağıda daha ayrıntılı olarak açıklanmaktadır.

Bir sistemin sahibi/yöneticisi olan kuruluş

Bir sistemin sahibi/yöneticisi olan veya sistemi tedarik eden kuruluş, öncelikle bu sistemin güvenliğinden sorumludur. Başka bir deyişle, kuruluş aynı zamanda bir güvenlik açığı raporunun takibinden de sorumludur.

Kuruluş, bu Yönergeleri kullanarak kendi CVD politikasını hazırlamayı ve bu politikayı olası bildiren taraflarla paylaşmayı seçebilir. Bir CVD politikası yayınlayarak kuruluşlar, güvenlik açıkları hakkında bilgi alma istekliliklerini gösterirler.

Bir CVD politikası belirleyen taraf, politikaya uygulanan kurallara uyulursa polise şikâyette bulunmayacağı ilkesini taahhüt edebilir.

Bildiren taraf bir güvenlik açığını bildirdikten sonra sorumluluk kuruluştadır. Bildiren tarafın çoğu zaman kuruluşun dışından biri olduğunun farkında olmak önemlidir. Bu taraf, bir güvenlik açığı bildirildikten sonra tetiklenebilecek iç süreçlere doğrudan bir görüşe sahip değildir. Sonuç olarak, bildiren taraflar güvenlik açığının çözümündeki gelişmelerden haberdar edilmekten memnun olacaktır. Bu sürekli iletişim, çözümün takibi ve zamanlaması konusunda doğru beklentiler yaratmak için de önemlidir.

Bir güvenlik açığını bildiren taraf

Bildiren taraf, şu veya bu şekilde bir güvenlik açığını tespit edebilmiştir ve bu güvenlik açığının giderilmesini ve muhtemelen daha sonraki bir aşamada herkese açık hale getirilmesini sağlayarak BT sistemlerinin güvenliğine katkıda bulunmak ister. Bildiren taraf, pasif gözlem yoluyla veya BT sistemini aktif olarak test ederek bir şey keşfetmiş olabilir. Elbette bu taraf, kendi eylemlerinden ve güvenlik açığını nasıl keşfettiğinden sorumludur. Bir kuruluşun CVD politikasında belirlediği koşulların farkında olmak bildiren tarafın kendi sorumluluğundadır. Çoğu hükümet ve şirket CVD politikalarını web sitelerinde yayınlamıştır.

Yine de güvenlik açıklarını bulmak yasayı çiğnemeyi içerebilir. CVD bağlamında kuruluş ve bildiren taraf, herhangi bir cezai eylem için ihbarda bulunmayacakları konusunda anlaşabilir. Bu konuda, kuruluş tarafından yayınlanan CVD politikası yol gösterici ilkedir. Taraflar ayrıca hukuk davası açılmayacağı konusunda da anlaşabilir.

Bildiren tarafın yasayı çiğnediğine dair bir şüphe varsa, bir CVD politikası her şeyden önce bildirenin yetkililere ihbar edilmesini önlemeye yardımcı olabilir. Bu prosedür tamamen, bir kuruluşun bildiren taraftan uymasını istediği politikanın ön koşullarına ve bu uyumun sağlanıp sağlanmadığına bağlıdır; taraf politikanın koşulları içinde hareket ettiği sürece, olası olarak buna karşılık gelen cezai şikâyette bulunmama sözüyle birlikte. Polise bir ihbar yapılırsa, bir CVD politikasının varlığı ve buna uyulması Hollanda'da ilgili bir durumdur; Savcı, bir ceza soruşturması başlatıp başlatmamaya ve/veya kovuşturup kovuşturmamaya karar verirken bunu dikkate alacaktır. Prensip olarak, polis ve Kamu Savcılığı (OM), bildiren taraf ilgili kuruluşun CVD politikasının kurallarına açıkça uymuşsa bir ceza soruşturması başlatmayacaktır. Ancak Kamu Savcılığı ve polis, bildiren tarafın eylemlerinde bilerek veya bilmeyerek çok ileri gittiğine ve/veya CVD politikasına uymadığına dair belirtiler varsa davayı daha fazla inceleyebilir. Bu soruşturmaya dayanarak Kamu Savcılığı kovuşturmaya karar verebilir.

Kamu Savcılığı, soruşturma ve/veya kovuşturma kararına ulaşmada önemli olan yönleri daha spesifik olarak ele aldığı bir politika mektubu yayınlamıştır. Örneğin, bildiren tarafın eylemlerinin önemli bir kamu yararına hizmet edip etmediği, tarafın orantısız hareket edip etmediği ve tarafın belki de başka, daha az sert bir şekilde hareket edebilip edemeyeceği. İlgili politika mektubu bu yönleri daha ayrıntılı olarak açıklar.2 2013'ten bu yana ilgili içtihat3, bir kuruluşun CVD politikası yoksa bu yönlerin mahkemede de dikkate alındığını göstermektedir.

4. Koordineli Güvenlik Açığı Bildirimi sürecinin yapı taşları

Kuruluş, bildiren ve NCSC için CVD sürecini şekillendirmedeki yapı taşları aşağıda verilmiştir.

Kuruluş

CVD'yi teşvik etmek, BT sistemlerinin sahibi olan veya bir BT ürünü/sistemi tedarik eden bir kuruluşla başlar. Ne de olsa bu kuruluş, bu BT sistemlerinin bilgi güvenliğinden öncelikle sorumludur. Güvenlik açıklarını çözmek için çeşitli taraflarla etkili bir şekilde çalışmak üzere bir kuruluş, bir CVD politikası hazırlamaya ve yayınlamaya karar verebilir. Kendi CVD politikasını hazırlamak kuruluşun güvenlik açığı raporlarını nasıl ele aldığını göstermesine olanak tanır. Bu şekilde bir kuruluş ayrıca bildirimleri nasıl almak istediğini de şekillendirebilir. Böyle bir süreç şu şekilde düzenlenebilir:

Kuruluş bir CVD politikası oluşturur ve yayınlar.
Bu politikada kuruluş, bildiren tarafların yürütebileceği araştırma için net kurallar sağlar; örneğin hangi tekniklerin izinli olduğu ve hangi sistemlerin kapsam içinde veya dışında olduğu.
Kuruluş, bildiren tarafın rapor yapmasını kolaylaştırır. Bir seçenek, standartlaştırılmış bir bildirim yönteminin kullanılmasıdır; örneğin belirli bir e-posta adresi veya çevrimiçi form. Ayrıca kuruluş, anonim raporları kabul edip etmeyeceğine karar verebilir.
Kuruluş dahili kapasite ayırır ve raporlara yeterli şekilde yanıt vermek için bir süreç kurar. Bulunan güvenlik açıklarının yeterli şekilde giderilebileceği bir süreç kurmak tavsiye edilir. Bu bağlamda raporun kaynağı önemsizdir. Güvenlik açığı örneğin dahili bir çalışan tarafından veya bir test sırasında da tespit edilmiş olabilir.
Pratik deneyim, bir CVD politikasının ilk yayınından sonra kuruluşa güvenlik açıklarını bildirmeye daha fazla ilgi olacağını göstermektedir. Kuruluş, (ek) kapasiteyi planlarken bunu dikkate almalıdır.
Kuruluş güvenlik açığı raporunu aldığında, raporun değerlendirilmesi ve ele alınması için en uygun departmana mümkün olan en kısa sürede ulaşmasını sağlar.
Kuruluş, bildiren tarafa raporun alındığına dair bir onay gönderir; önceliği vurgulamak için tercihen dijital olarak imzalanmış.
Ardından kuruluş, olası bir yayının gerçekleşeceği süreyi belirlemek için bildiren tarafla istişareye girer. Bu süre, güvenlik açığının doğasına ve sistem türüne büyük ölçüde bağlı olacaktır.
Bir kılavuz olarak, yazılım güvenlik açıkları için sıklıkla yaklaşık 60 günlük bir süre kullanılır. Donanımdaki güvenlik açıklarını gidermek daha zordur; 6 aylık bir kılavuz kullanılabilir.
Bu süreyi, güvenlik açığı bildirilen sisteme kaç BT sisteminin bağımlı olduğuna veya güvenlik açığının çözülmesinin daha kolay ya da daha zor olmasına bağlı olarak karşılıklı anlaşmayla uzatmak veya kısaltmak arzu edilebilir.
Bir güvenlik açığının çözülmesi zor veya imkânsız olabilir ya da çözülmesiyle ilgili yüksek maliyetler söz konusu olabilir. Bu gibi durumlarda kuruluş, güvenlik açığını kabul edilmiş bir risk olarak görmeyi ve gidermemeyi, muhtemelen bildiren tarafla istişare ederek kabul edebilir.
Kuruluş, bildiren tarafı sürecin gelişimi hakkında bilgilendirmeye devam edecektir.
Ayrıca kuruluş, bildiren tarafın güvenlik açığını yayınladığı için kamuya açık olarak tanınmasını önerebilir. Dış dünyaya ortak bir bildirimi tercih etmek de mümkündür.
Taraf CVD politikasının kurallarına uymuşsa, sistemlerdeki güvenlik açıklarını bildirdiği için bildiren tarafı ödüllendirmek tercih edilir. Ödülün miktarı raporun kalitesine bağlı olabilir. Bildiren tarafı ödüllendirmek, o taraf ile kuruluş arasında daha iyi bir ilişki yaratabilir ve insanların CVD politikasına uygun olarak yeni raporlar yapma istekliliğini artırabilir.
Bildiren tarafla istişare içinde kuruluş, güvenlik açığının başka yerlerde de bulunması makulse, daha geniş BT topluluğunu güvenlik açığı hakkında bilgilendirmeyi kabul edebilir.
CVD politikasında kuruluş, bildiren taraf politikada belirtilen kurallara uymuşsa polise şikâyette bulunmayacağı ilkesini taahhüt edebilir.

Bildiren taraf

Bildiren taraf, başarılı bir CVD sürecinin anahtarıdır. Bu taraf, şu veya bu şekilde bir güvenlik açığını tespit edebilmiştir ve bu güvenlik açığının bir kuruluş tarafından giderilmesini ve herkese açık hale getirilmesini sağlayarak BT sistemlerinin güvenliğine katkıda bulunmak ister. Bunu yaparak bildiren taraflar, güvenlik açıklarını koordineli bir şekilde ifşa ederek topluma önemli bir katkıda bulunabileceklerini kabul ederler. Başarılı bir CVD sürecine ulaşmak için aşağıdaki yapı taşları bildiren taraf için önemlidir:

Bildiren taraf kendi eylemlerinden sorumludur ve güvenlik açıklarını araştırırken ve bildirirken orantılılık ve yardımcılık (subsidiarity) ilkelerine uymalıdır. Başka bir deyişle, bildiren taraf güvenlik açığını göstermek için gerekenden fazlasını yapmamalı ve güvenlik açığını her zaman önce sistem/bilgi sahibine bildirmelidir.
Bildiren taraf, kötü niyetli tarafların güvenlik açığını keşfedip ondan yararlanmasını önlemek için sorunu mümkün olan en kısa sürede bildirmelidir.
Bildiren taraf, başkalarının bu bilgiye erişmesini önlemek için kuruluşa raporu gizli bir şekilde yapmalıdır.
Bildiren taraf, rapor vermeyi veya daha fazla bilgi sağlamayı ödüle bağlı kılamaz. Bir rapor durumunda ödül verme inisiyatifi, yayınlanan politikasında ön koşulları belirleyebilen alıcı kuruluştadır.
Bildiren taraf ve kuruluş, güvenlik açığının ifşası konusunda net anlaşmalar yapar. Birden fazla kuruluş söz konusuysa, temel ilke, güvenlik açıklarının yalnızca tüm kuruluşlar bunu kabul ederse yayınlanabileceğidir. Bu anlaşmaları erken bir aşamada yapmak tavsiye edilir.
Bildiren taraf ve ilgili kuruluş, daha geniş BT topluluğunu bilgilendirme konusunda anlaşmalar yapabilir. Örneğin bu durum, birden fazla yerde var olduğu bilinen bir güvenlik açığı (zaten bilinsin ya da bilinmesin) için geçerli olabilir. Ulusal Siber Güvenlik Merkezi (NCSC), merkezi hükümetin ve kritik altyapının hedef gruplarını desteklemek veya birçok sistemi etkileyen bir güvenlik açığı durumunda birkaç tarafı bilgilendirmek için bu sürece dahil olabilir.

NCSC

CVD süreci öncelikle kuruluşları ve bildiren tarafları ilgilendiren bir konudur. Bununla birlikte NCSC, bir CVD sürecinin kullanılmasını teşvik edecektir. Bildiren taraf ve kuruluşla istişare ederek NCSC, güvenlik açığından kaynaklanan daha fazla güvenlik riskini sınırlamak için güvenlik açığı hakkındaki bilgiyi hizmet verdiği topluluğuyla paylaşmaya da dahil olabilir.

Güvenlik açığının bildirimi bildiren tarafın beklediği gibi gitmezse veya güvenlik açığını doğrudan kuruluşa bildirmeyi tercih etmezse, NCSC ile iletişime geçebilir.4 Bu durumda NCSC, gerektiğinde arabulucu olarak hareket edebilir.

BT sisteminin sahibi her zaman sistemin güvenliğinden sorumludur. NCSC, sistemin sahibini bir güvenlik açığını gidermeye zorlayamaz ve sahibin bildiren tarafa karşı yasal işlem yapmayacağını da garanti edemez. Sonuç olarak, bildiren taraf bir güvenlik açığını ararken ve bildirirken kuruluşlar ve bildiren taraflar için yukarıda belirtilen yapı taşlarını dikkate almalıdır. Bildiren taraf, NCSC'nin güvenlik açığının giderilmesi için elinden gelenin en iyisini yapmasını ve raporu gizli tutmasını bekleyebilir. NCSC, yasal olarak zorunlu olmadıkça hiçbir kişisel veriyi paylaşmaz.

Mümkünse NCSC, güvenlik açıkları hakkında elde edilen bilgileri, kuruluşlar ve bildiren taraflarla istişare ederek bilginin BT topluluğuyla daha fazla paylaşılması için kullanacaktır. Örneğin bunu, bilginin bir kısmını yayınlayarak, bir bilgi formu (fact sheet) veya teknik rapor (white paper) yazarak ya da güncelleyerek veya belirli kuruluşları bilgilendirerek yapabilir.

İlgili kuruluşa ve tespit edilen güvenlik açığının niteliğine bağlı olarak NCSC, güvenlik açığını ilgili kuruluşun dikkatine sunmak için çaba gösterecektir. Ancak söz konusu BT sisteminin sahibi sistemden sorumlu olmaya devam eder.
Mümkün ve gerekli olduğunda NCSC, ilgili kuruluşa güvenlik açığının nasıl giderileceği konusunda tavsiye verecektir.
NCSC raporları gizli tutacak ve bir yasal yükümlülükten kaynaklanmadıkça bildiren tarafların veya alıcı kuruluşun kişisel verilerini onay olmadan paylaşmayacaktır.
Mümkün olan her yerde NCSC, kuruluşla temastaki ve güvenlik açığının giderilmesindeki gelişmeler konusunda bildiren tarafı bilgilendirmeye devam edecektir.
NCSC'ye bir rapor yapılan durumlarda, NCSC bildiren tarafı veya olası bildiren tarafı ve kuruluşu birbiriyle temasa geçirmeye çalışacaktır.

Örneğin bir bildiren taraf bir yazılım ürününde bir güvenlik açığı veya birçok farklı sistemi etkileyen bir güvenlik açığı bulduysa, bildiren taraf NCSC'den güvenlik açığının giderilmesini ve ifşasını koordine etmesini isteyebilir.

NCSC, bildiren taraf, ortaklar, geliştiriciler ve/veya yazılım geliştiricileri ile diğer güvenlik ekipleriyle birlikte güvenlik açığını analiz etmeye, gidermeye veya giderilmesini sağlamaya, koordine etmeye ve kontrollü bir şekilde ifşa etmeye yardımcı olacaktır. Bu sürecin tamamı, güvenlik açığını bulan bildiren tarafla yakın istişare içinde gerçekleşir.

Bir CVD politikası, önlem alınabilmesi için güvenlik açıklarını mümkün olan en kısa sürede ifşa etmenin önemi ile hem geliştiricilerin hem de tedarikçilerin güvenlik açığını gidermek için yeterli zamana sahip olmasının önemi arasında bir denge kurmaya çalışır. Bu süreç için NCSC, rapor ile kamuya ifşa arasında 60 günlük standart bir süre kullanır. Ancak bu süreyi uzatmaya veya kısaltmaya karar verilebilecek koşullar olabilir.

NCSC, güvenlik açığı hakkındaki bilgiyi üçüncü taraflarla yalnızca bildiren tarafla istişare ettikten sonra paylaşacaktır. Bu bağlamda NCSC'nin işbirliği yapması ve bu nedenle güvenlik açığı hakkındaki bilgiyi paydaşlarla paylaşması, bir güvenlik açığını koordineli bir şekilde ifşa etmek için esastır. Bunu yaparken NCSC, doğru tarafların güvenlik açığını gidermek için çalışabilmesini, herhangi bir kayıp veya zararı sınırlamaya yardımcı olunmasını ve bulunan güvenlik açığına dikkat çekilmesine yardımcı olunmasını sağlayacaktır.

5. İletişim ve ifşa süreci

Beş yıllık uygulama, net iletişimin başarılı bir CVD sürecinin temel taşı olduğunu göstermiştir. CVD sürecinde, öncesinde ve sonrasında dikkat edilmesi gereken noktalar vardır.

İfşa süreci hakkında iletişim

Bir CVD politikası yayınlamak, süreç hakkında iletişim kurmanın ilk adımıdır. Bir politikayı herkese açık olarak yayınlayarak bildiren taraflar, bulunan güvenlik açıklarını kuruluşa bildirmeye davet edilir.

Bir yandan kuruluş, güvenlik açıklarını keşfetmek için yapılan araştırma ve iletişim kurulma biçimi için koşullar belirleyebilir. Diğer yandan kuruluş, politikanın kurallarına uyulursa polise şikâyette bulunmayacağı ilkesini taahhüt edebilir. Bu yaklaşım, bildiren tarafın konumunu korur.

Bir CVD politikası daha sonraki bir tarihte değiştirilebilir veya güncellenebilir. Bu konuda değişiklikler hakkında net olmak önemlidir. Bildiren tarafların neyin ne zaman değiştirildiğini bilmekte çıkarı vardır. Örneğin değişiklikler, CVD politikasının başına bir yayın tarihi ekleyerek, CVD politikasının altında bir değişiklik özeti tanımlayarak veya CVD politikasının eski sürümlerinin bir arşivini tutarak açıklığa kavuşturulabilir.

CVD politikası, süreç sırasında nasıl iletişim kurulacağına dair yönergeler sağlayabilir; örneğin e-posta veya bir web portalı aracılığıyla düzenli güncellemeler belirtmek gibi. Ayrıca CVD politikası, bir bildirenin bir güncellemede anılarak, bir şeref listesine (hall of fame) alınarak veya başka herhangi bir ödül biçimiyle nasıl tanınabileceğini açıklayabilir.

İfşa süreci sırasında iletişim

Bildiren taraf, kuruluşa bir mesaj göndererek bir CVD sürecini başlatır. Bu mesajda bildiren taraf, keşfedilen güvenlik açığının net bir açıklamasını verir. Önemli unsurlar, etkilenen sistemin IP adresi veya URL'si ve güvenlik açığını yeniden üretmek için gerekli adımlardır.

Kuruluşun, süreçle ilgili beklentilerin net olması için bildiren tarafla net bir şekilde iletişim kurması önemlidir.

Bunu, ilk veya sonraki esaslı yanıtın hangi süre içinde gönderileceğine dair bir gösterge içeren (otomatik veya başka türlü) bir alındı onayı göndererek şimdiden yapabilir.

Bu süreyi açık bırakmak ve raporun içeriğini değerlendirdikten sonra sürenin ilk göstergesini vermek de mümkündür. Bir çözümün hangi süre içinde sağlanabileceği konusunda mümkün olan en kısa sürede net olmak tavsiye edilir. Bu şekilde bildiren, bir sonucun ne zaman beklenebileceğini bilir.

Bazı durumlarda bir yayın tarihinin bildiren tarafça zaten net olması mümkün olabilir; örneğin bir konferanstaki sunum nedeniyle veya bildiren taraf kendi süresini belirlediği için. Bu durumda da bildiren tarafın bu zaman çizelgesini net bir şekilde iletmesi, mümkün olan en erken zamanda belirtmesi ve bu tarihin ertelenmesinin mümkün/imkânsız olduğu konusunda net olması önemlidir.

Bildiren taraf genellikle kuruluşun dışından biridir ve bir raporun tetikleyebileceği iç süreçlere dair hiçbir kavrayışı yoktur. Kuruluşlar, düzenli güncellemelerle bildiren tarafı sürecin gelişmelerinden haberdar edebilir. Bu yaklaşım bildiren tarafa bir çözüm üzerinde çalışıldığını açıkça gösterir. Gerektiğinde kuruluş, süreç sırasında açıklama isteyebilir veya bir çözümü test etmeyi talep edebilir.

Bir kuruluş ilk çözüm son tarihini karşılayamazsa, bunun ertelenmesi bildirenle görüşülebilir. Düzenli iletişim, bu durumu bildirene daha erken bir aşamada netleştirebilir.

CVD'nin temel amacı güvenlik açığını hafifletmektir, ancak bildiren taraf sürecin çok uzun süreceğini düşünürse, güvenlik açığının 'tam bildirimi' (full disclosure) her zaman bir seçenektir. Bu önlem, bildiren tarafın elindeki meşhur 'büyük sopa'dır (big stick). Doğal olarak bu durum mümkün olduğunca önlenmelidir.

İfşa sürecinden sonra iletişim

Bir bildiren tarafın güvenlik açıkları araması ve ardından CVD süreci aracılığıyla kuruluşlara bildirmesi için birçok olası neden vardır. Çok sayıda bildiren taraf için önemli bir teşvik (kamuya açık) takdirdir.

Bildiren taraflar, bir güncellemedeki teşekkür veya bir şeref listesine (hall of fame) alınma yoluyla kamusal takdir alır. Ancak kamusal takdir ihtiyacı tüm bildiren taraflar için geçerli değildir; bazıları aslında halk tarafından bilinmek istemez. Kuruluş tarafından iletişim kurulması durumunda, bu nedenle bildiren tarafın adını anmak için onayını almak tavsiye edilir.

Ayrıca bildiren taraflar, CVD sürecinin tamamlanmasından sonra bir rapor hakkında iletişim kurmaya da karar verebilir. Örneğin bildiren taraf, keşif sürecini tanımlayabilir veya başkalarını güvenlik açığı konusunda uyarabilir. Bir bildiren, yayını bilgilendirme amacıyla bir kuruluşa sunmaya karar verebilir. CVD süreci prensip olarak güvenlik açığının kaldırılmasından sonra tamamlandığından, bildiren taraf, politikada veya süreç sırasında ek anlaşmalar yapılmadıkça bundan sonra bu konuda iletişim kurmakta serbesttir.

Liste

İfşa süreci hakkında iletişim

CVD politikasının web sitesinde yayınlanması
Kısıtlamalar hakkında net olmak (farklı yaklaşımlar için bölüm 6'ya bakın)
Araştırma yöntemlerindeki kısıtlamalar
İletişim hakkında yönergeler
Olası ödüller hakkında yönergeler: Şeref listesi (Hall of fame), mali ödül, tişört vb.
Değişikliklerin tarihi dahil olmak üzere CVD politikasındaki güncellemeler hakkında net olmak

İfşa süreci sırasında iletişim

Bildiren, keşfedilen bir güvenlik açığı hakkında kuruluşla iletişime geçer.
Kuruluş, ilk teknik yanıt için yanıt süresi gibi beklentileri yönetir
Kuruluş ve bildiren, beklenen çözüm süresi konusunda birbirlerine netlik sağlar
Kuruluş sık sık bir (süreç) güncellemesi sağlar
Gerektiğinde bildiren ve kuruluş, diğer ilgili kuruluşlarla iletişime geçmeyi görüşür

İfşa sürecinden sonra iletişim

Bildirenin (kamusal) takdiri ve ödüllendirilmesi hakkında görüşmek
Güvenlik açığı hakkındaki bilginin nasıl yayınlanacağını, örneğin araştırma aşamasını veya diğer kuruluşların bilgilendirilmesini düzenlemek

6. Koordineli Güvenlik Açığı Bildirimi politikası örnekleri

Koordineli Güvenlik Açığı Bildirimi üzerine birçok farklı politika metni biçimi vardır. Yayınlanan CVD politikası olası bildiren taraflar için bir yol gösterici işlevi gördüğünden, bu politikanın biçiminin kuruluşun politikası ve stratejisiyle uyumlu olduğundan emin olun.

Bir CVD politikasında aşağıdaki unsurlar önemlidir:

güvenli iletişim için iletişim yöntemi;
bildiren taraflar için ön koşullar;
bir raporun ele alınması için net beklentiler;
bir raporu ödüllendirme yöntemi;
sürüm numarası ve son revizyon tarihi.

Aşağıda üç örnek bulunmaktadır: Hollanda'daki birçok kuruluş ResponsibleDisclosure.nl'in temel örneğinden yararlanmıştır. Diğer kuruluşlar ek ön koşullar içerir, bkz. Fox IT'nin politikası. Yine diğer kuruluşlar hedef kitleleriyle uyum sağlamak için daha serbest bir biçim uygular, bkz. Bits of Freedom'ın politikası.

Örnek: ResponsibleDisclosure.nl

Bu metin Floor Terra tarafından yazılmıştır ve Creative Commons Attribution 3.0 Unported lisansı ile yayımlanmıştır.

Acme Corporation'da sistemlerimizin güvenliğini birinci öncelik olarak görüyoruz. Ancak sistem güvenliğine ne kadar çaba harcarsak harcayalım, yine de güvenlik açıkları bulunabilir.

Bir güvenlik açığı keşfederseniz, bunu mümkün olan en kısa sürede ele almak için adım atabilmemiz amacıyla haberdar olmak isteriz.

Müşterilerimizi ve sistemlerimizi daha iyi korumamıza yardım etmenizi rica ediyoruz.

Lütfen aşağıdakileri yapın:

Bulgularınızı cert@example.com adresine e-posta ile gönderin. Bu kritik bilginin yanlış ellere geçmesini önlemek için bulgularınızı PGP anahtarımızla şifreleyin,
Keşfettiğiniz güvenlik açığından veya sorundan faydalanmayın; örneğin güvenlik açığını göstermek için gerekenden fazla veri indirerek veya başkalarının verilerini silerek ya da değiştirerek,
Sorun çözülene kadar bunu başkalarına açıklamayın,
Fiziksel güvenliğe yönelik saldırılar, sosyal mühendislik, dağıtık hizmet reddi, istenmeyen posta veya üçüncü tarafların uygulamalarını kullanmayın ve
Sorunu yeniden üretmek için yeterli bilgi verin, böylece sorunu mümkün olan en kısa sürede çözebiliriz. Genellikle etkilenen sistemin IP adresi veya URL'si ile güvenlik açığının bir açıklaması yeterli olur, ancak karmaşık güvenlik açıkları ek açıklama gerektirebilir.

Neyi vaat ediyoruz:

Raporunuza 3 iş günü içinde, raporun değerlendirmesi ve beklenen çözüm tarihiyle yanıt vereceğiz,
Yukarıdaki talimatları izlediyseniz, rapor konusunda size karşı hiçbir yasal işlem yapmayacağız,
Raporunuzu sıkı bir gizlilikle ele alacağız ve kişisel bilgilerinizi izniniz olmadan üçüncü taraflara iletmeyeceğiz,
Sorunun çözümüne yönelik ilerleme hakkında sizi bilgilendireceğiz,
Bildirilen sorunla ilgili kamuya açık bilgilerde, (aksini istemediğiniz sürece) sorunu keşfeden kişi olarak adınızı belirteceğiz ve
Yardımınız için bir teşekkür göstergesi olarak, henüz bilmediğimiz her güvenlik sorunu raporu için bir ödül sunuyoruz. Ödülün miktarı, sızıntının ciddiyetine ve raporun kalitesine göre belirlenecektir. Asgari ödül 50 € değerinde bir hediye çeki olacaktır.

Tüm sorunları mümkün olan en kısa sürede çözmeye çalışıyoruz ve sorun çözüldükten sonra konuyla ilgili nihai yayında aktif bir rol oynamak istiyoruz.

Örnek: Fox-IT

Fox-IT'de sistemlerimizin, ağımızın ve ürünlerimizin güvenliğini son derece önemli görüyoruz. Güvenlik konusunda gösterdiğimiz büyük özene rağmen, zayıf noktalar yine de kalabilir. Böyle bir zayıflık bulduysanız, uygun önlemleri mümkün olan en kısa sürede alabilmemiz için bunu en kısa zamanda öğrenmek isteriz.

Zayıf noktalar iki şekilde keşfedilebilir: dijital bir ortamın normal kullanımı sırasında tesadüfen bir şeye rastlayabilirsiniz ya da onları bulmak için açıkça elinizden geleni yapabilirsiniz.

Sorumlu bildirim politikamız, zayıf noktaları keşfetmek için iş ağımızı aktif olarak taramaya yönelik bir davet değildir. İş ağımızı kendimiz izliyoruz. Bu, bir taramanın tespit edilme ve Güvenlik Operasyon Merkezimiz (Security Operation Center, SOC) tarafından bir soruşturma yürütülme olasılığının yüksek olduğu anlamına gelir; bu da gereksiz maliyetlere yol açabilir. Bununla birlikte, ürünlerimizdeki güvenlik açıklarını çevrimdışı, üretim dışı bir ortamda aktif olarak aramaya ve bulgularınızı bize bildirmeye davetlisiniz. Müşterilerimize karşı sorumluluğumuz, niyetimizin onların altyapısına yönelik korsanlık girişimlerini teşvik etmek olmadığı anlamına gelir; ancak güvenlik açıkları bulunursa, bunları yeterli şekilde çözebilmemiz için sizden en kısa sürede haber almak isteriz.

Müşterilerimizi ve sistemlerimizi daha iyi koruyabilmek için sizinle çalışmak isteriz.

Sizden şunları rica ediyoruz:

Bulgularınızı en kısa sürede security-alert@fox-it.com adresine e-posta ile gönderin.
Güvenlik açığını kötüye kullanmayın; örneğin veri indirerek, düzenleyerek veya silerek. Raporunuzu her zaman ciddiye alacağız ve kanıt olmasa bile bir güvenlik açığına dair her şüpheyi araştıracağız.
Sorun çözülene kadar bunu başkalarıyla paylaşmayın.
Fiziksel güvenliğe yönelik saldırılar, sosyal mühendislik veya güvenlik açığı tarayıcıları gibi korsanlık araçları kullanmayın.
Sorunun yeniden üretilebilmesi için yeterli bilgi verin, böylece mümkün olan en kısa sürede çözebilelim. Genellikle etkilenen sistemin IP adresi veya URL'si ile güvenlik açığının bir açıklaması yeterlidir, ancak daha karmaşık güvenlik açıkları için daha fazla bilgi gerekebilir.

Neyi vaat ediyoruz:

Raporunuza üç iş günü içinde, raporun değerlendirmesi ve beklenen çözüm tarihiyle yanıt vereceğiz.
Raporunuzu gizli olarak ele alacağız ve kişisel bilgilerinizi izniniz olmadan üçüncü taraflarla paylaşmayacağız. Buna istisna, kovuşturma durumunda veya bilgi talep edilmesi halinde polis ve yargıdır.
Sorunun çözümündeki ilerleme hakkında sizi bilgilendireceğiz.
Bildirilen sorunla ilgili iletişimde, isterseniz adınızı sorunu keşfeden taraf olarak belirteceğiz.
Ne yazık ki size karşı hiçbir yasal işlem yapılmayacağını önceden garanti etmek mümkün değildir. Her durumu ayrı ayrı değerlendirebilmeyi umuyoruz. Zayıflığın veya verilerin kötüye kullanıldığından ya da zayıflık bilgisini başkalarıyla paylaştığınızdan şüphelenirsek, sizi bildirmeyi ahlaki olarak zorunlu görüyoruz. Çevrimiçi ortamımızda tesadüfen yapılan bir keşfin kovuşturmaya yol açmayacağından emin olabilirsiniz.
Yardımınız için teşekkür olarak, bize bilinmeyen her güvenlik sorunu raporu için bir ödül sunuyoruz. Ödülün değerini, ihlalin ciddiyetine ve raporun kalitesine göre belirliyoruz.

Tüm sorunları mümkün olan en kısa sürede çözmeye, ilgili tüm tarafları bilgilendirmeye çalışıyoruz ve sorun çözüldükten sonra konuyla ilgili herhangi bir yayına dahil olmak isteriz.

Örnek: Bits of Freedom

Dijital altyapıya bağımlılığımız giderek artıyor. Bu, bir bütün olarak toplum için olduğu kadar bizim için de geçerlidir. Bu nedenle, hükümetlerin ve kuruluşların (bizimki dahil) dijital altyapımızı güvence altına almaya güçlü bir şekilde bağlı olması gerektiği kanaatindeyiz. En iyi niyetlerimize ve en büyük özenimize rağmen sistemlerimizde güvenlik açıkları bulunabileceğinin farkındayız. Bu zayıflıklardan birini bulursanız, sorunu çözebilmemiz için sizden haber almaktan memnuniyet duyarız.

Sizden beklentilerimiz

Sistemlerimizden birini incelerken saldırının orantılılığını göz önünde bulundurun. Web sitemizi internet tarihindeki en büyük DDoS saldırısına maruz bıraktığınızda sitenin erişilemez hale gelebileceğini göstermenize gerek yok. Bunu biliyoruz. Ayrıca ofisimize bir buldozerle girerseniz muhtemelen dizüstü bilgisayarlarımızdan birini kapabileceğinizi de anlıyoruz.
Bu orantılılık ilkesi, güvenlik açığının kendisini göstermede de geçerlidir. Bulgunuzun geçerliliğini doğrulamak için kesinlikle gerekenden fazla veriyi incelememeli veya değiştirmemelisiniz. Örneğin ana sayfamızı değiştirebiliyorsanız, sayfanın tamamını ele geçirmek yerine oraya tek bir tartışmasız kelime ekleyin. Bir veritabanına erişim sağlayabiliyorsanız, içindeki tabloların bir listesini veya belki bu tablolardan birinin ilk kaydını göstermeniz yeterlidir.
Sistemlerimizden birindeki bir güvenlik açığı, mümkün olan en kısa sürede security@bof.nl adresine e-posta gönderilerek bildirilmelidir. Mesajınızı tercihen OpenPGP kullanarak şifrelemelisiniz. Sorunu yeniden üretip araştırabilmemiz için lütfen yeterli bilgi verin.
security@bof.nl için genel OpenPGP anahtarı
Biz sorunu ele almadığımız ve sorunu bildirdiğinizden bu yana hâlâ makul bir süre içinde olduğumuz sürece, güvenlik açığı hakkındaki bilginizi başka taraflarla paylaşmayacaksınız.
Soruşturmanız sırasında elde ettiğiniz tüm gizli bilgileri, güvenlik açığını çözer çözmez sileceksiniz.

Bizden beklentileriniz

Raporunuza üç gün içinde ayrıntılı bir şekilde yanıt vereceğiz. Sorunu ele almak için gerekli süreye dair bir tahmin ekleyeceğiz. Elbette ilerlememiz hakkında sizi düzenli olarak bilgilendireceğiz.
Güvenlik açığını mümkün olan en kısa sürede çözeceğiz. Burada da orantılılık önemlidir: bir güvenlik açığını düzeltmek için gereken süre, ele alınan sorunun ciddiyeti ve karmaşıklığı dahil birkaç faktöre bağlıdır.
Burada ortaya konan yönergelere uyarsanız, raporunuz nedeniyle size karşı yasal işlem yapmayacağız.
Yaptığınız şey için size - isterseniz - itibar kazandırmak bizim için önemlidir. Adınızı güvenlik açığıyla ilgili bir yayında yalnızca siz kabul ederseniz anacağız.
Sistemlerimizi daha iyi korumamıza yardım ettiğiniz için bir teşekkür olarak, o sırada bilmediğimiz her güvenlik açığı raporunu ödüllendirmek isteriz. Ödül, güvenlik açığının ciddiyetine ve raporun kalitesine bağlı olacaktır.
Kullandığımız üçüncü taraf yazılımda bir güvenlik açığı bulursanız ve bu açık bir hata ödül (bug bounty) programı kapsamındaysa, bu ödülü biz talep etmeye çalışmayacağız; bunu siz yapmalısınız.