Tüm Detayları ile Risk Tanımlaması Programları ve Bilgi Güvenliği

Risk tanımlaması programları, kurumları veya yatırımları hedeflerine ulaşmaktan alıkoyabilecek risklerin tespit edilme sürecidir. Söz konusu süreç endişelere yönelik belgeleme ve iletişimi içerir.

Arka plan 

Risk tanımlaması, risk yönetim sürecindeki ilk kritik adımı temsil eder. Risk tanımlamasının amacı, gerçekleşmeleri halinde projenin beklenen performansa ulaşmasını veya ulaşılmak istenen hedeflerin yeteneklerini olumsuz etkileyebilecek olayların erken ve daimî tanımlamasıdır. Bu olaylar projenin kendi içinde gerçekleşebilir veya dış etkenlere bağlı olabilir.

Risk değerlendirme türleri çok çeşitlidir: Program risk değerlendirmesi, bir yatırım kararını desteklemek için risk değerlendirmesi, alternatiflerin analizleri ve işlemsel ya da maliyet belirsizliklerinin değerlendirilmesi. Risk tanımlaması, risk bilgilendirmesi yapılan karar verme mekanizması için gereken değerlendirmeyi desteklemelidir. Bir satın alım programı için ilk adım programın amaçlarını ve hedeflerini belirlemektir; böylece programın başarı elde edebilmesi için ekibin tümünde ortak görüş oluşur. Böylece riskin tanımlandığı ve değerlendirildiği bir ölçek ile bağlam arasında izdüşüm oluşur.

Sistem mühendislik programında risklerin tanımlanması 

Riskin birçok kaynağı var. Riskin tanımlanması için proje ekibi programın ölçeğini, maliyet tahminlerini, takvimi (kritik güzergahın değerlendirilmesini içerir), teknik olgunluk, temel performans parametreleri, performans zorlayıcıları, sektör ortaklarının beklentileri ile mevcut planın durumunu, dış ve iç bağımlılıkları, uygulama zorluklarını, entegrasyon, karşılıklı çalışabilirlik, desteklenebilirlik, tedarik zinciri hassasiyetleri, tehditleri engeleyebilme yeteneği, maliyet değişimleri, test olayı beklentileri, güvenlik, san güvenliği ve daha birçok ek konuyu değerlendirmelidir. Ek olarak, benzer projelere ait tarihi bilgiler, hissedar görüşleri ve listeler risk değerlendirmesinde önemli bir derinlik sunar.

Risk tanımlaması tekrarlanan bir süreçtir. Program ilerledikçe, program hakkında daha fazla bilgi elde edilir (örneğin spesifik tasarım) ve risk tanımı mevcut anlayışına göre düzenlenir. Yeni riskler proje yaşam döngüsü ilerledikçe tanımlanmaya devam eder.

Öğrenilen en iyi eylemler ve dersler 

Faaliyet riski: Yeteneklerinizin doğasını ve son kullanıcıların riskini, görevlerini ve operasyon yeteneklerini anlamak. Faaliyet risklerini anlamak, mevcut risklerin boyutunu ve son kullanıcılar üzerindeki olası etkilerini anlamanızı sağlar. Böylece gerçek hayatta operasyon kullanımı esnasında doğabilecek risklerin etkisi analiz edilebilir. İşlevsel kullanıcılar genelde görevlerini tamamlayabilmek için riskleri belli boyutta kabul etse de, mevcut opsiyonları, dengeleri ve alternatifleri değerlendirmeleri ve kabul ettikleri riskleri anlamaları için yardım etmeniz gereklidir.

Teknik olgunluk: Bir çaba için sunulan teknolojileri ve zamanla dönüşümlerini anlamak için sanayi ve akademi ile birlikte çalışılması gereklidir. Bir yöntem, gizlilik anlaşması altında satıcılar ile çalışarak yeteneklerini anlamak, böylece risk değerlendirmesi yapabilmektir.

Gelişim-dışı nesneler (NDI): NDI, ticari ve devlet bünyesinde olmayan nesneleri kapsar. Riskleri yönetebilmek için bir NDI tedarikçisinin mevcudiyetini değerlendirin. Bir piyasa oranına sahip mi? Rakiplerine kıyasla belli bir süredir mevcut mu? Tedarikçi yetenek problemlerine nasıl tepki veriyor ve çözüm sunabiliyor mu? Belli bir NDI için kullanıcı tabanı ne durumda? Tedarikçi NDI’ı müşterinizin istediği ayarlar altında sunabiliyor mu? Hükümet bir prototip üretmek için NDI’ı kullanabilir mi? Tüm bu faktörler NDI’ın mevcudiyeti ve tedarikçisine yönelik riskleri değerlendirmenizi sağlayacaktır.

Satın alım iticileri: Özellikle kısıtlı alternatifleri bulunan, kritik yetenekleri mümkün kılan unsurlara odaklanın. Bir satın alımın ana iticilerini değerlendirin ve belirleyin; risk önleme formüllerinin geliştirilmesindeki bağlantılı risklerini değerlendirin. Eğer bir yeteneğin belli bir unsuru başarı için kritik değilse, sunduğu risk değerlendirilmelidir. Öte yandan risk yönetiminin ana unsuru olmamalıdır. Örneğin, önerilen kullanıcı arayüzü ile ilgili bir risk söz konusu ise piyasa da çok sayıda alternatif bulunmaktadır. Kısaca sunulan yaklaşım yeteneğin başarısı üzerinde yüksek bir risk faktörü oluşturmaz. Bir bilişim güvenlik içeriği ise kritik önem taşıyan bir örnektir. Eğer bir alternatif yaklaşım ihtiyacı karşılıyor ise önem verilmelidir. İhtiyaçları ve tasarımları değerlendirerek ana başarı kriterlerini belirleyin; ayrıca mevcut alternatifleri gözden geçirin. Başarı yolunda benzersiz bir çözüm söz konusu mu? Kritik rota analizinin tüm sistem mühendislik döngüsünü içerdiğinden emin olun ve gelişim safhası ile sınırlı kalmayın.

Yetenek evrimini risk yönetimi için kullanım. Eğer belli gereksinimler yeteneklerin uygulanmasını tetikliyor ise kendine özgü gelişim için yüksek risk oluşturabilir. Gereksinimler, kullanıcılar ile gereksinimleri seviyesinde değerlendirilmelidir. Gereksinim ertelenebilir, öte yandan gelişim topluluğu gelecekte ne zaman gerekli olacağı konusunda değerlendirmede bulunmalıdır. Kullanıcılara ve geliştiricilere bir yeteneğin gereksinimler karşısında ne kadar risk oluşturabileceği ve en kısa zamanda en kısa risk yeteneklerini elde edebileceklerini konusunda yardım edin.

Gereksinimlerinizi hazırlarken, teknik uygulanabilirliği ile uygulamanın ilişkili başarısını değerlendirin; geleceğin yerine şu an uygulamanın ortaya koyabileceği riskleri değerlendirin. Yeteneklerinizi ertelerken genel başarı için gözden geçirmeniz gereken çoklu yüksek-risk gereksinimlerini göz ardı ederek sadece yakın dönem kolay başarılara odaklanmayın.

Anahtar Performans Parametreleri (KPPs): KPP’leri belirlemek için kullanıcılar ile yakından çalışın. Program iptalinin genel riski, KPP’leri karşılamak için başarısızlığa merkezlenebilir. Kullanıcılar ile parametrelerin görev ihtiyaçlarına tepki gösterdiğine ve teknik olarak uygulanabilir olduğuna bakın. Parametreler, ne görev gereksinimlerini karşılamayacak kadar kolay elde edilmelidir, ne de aşırı teknoloji kullanımı gerektirerek görevi riske atmalıdır. Geçmişteki operasyonların, deneylerin, performans değerlendirmelerinin ve endüstri uygulamalarının sonuçlarını inceleyin; performans uygulanabilirliğini belirlemeyi kolaylaştırın.

Dış ve iç bağımlılıklar: Kurumsal bakış açısına sahip olmak satın alıcılar, program yöneticileri, geliştiriciler, bütünleyiciler ve kullanıcılar için bir geliştirme çabasında bağımlılıklardan doğan risklerin anlaşılmasını sağlar. Hizmet odaklı yaklaşımların ortaya çıkması ile bir program erişilebilirliğinden ve başkaları tarafından program geliştirme çabalarına katkı sağlaması istenen hizmet faaliyetlerinden daha bağımlı hale gelecektir. Gelişim programı ekibi ile birlikte çalışarak mevcut hizmetleri değerlendirin; kalitesini ve bir programı kullanırken hizmete dayalı riskini değerlendirin. Üretilen hizmetlerin kalitesini doğrulamak için geliştiricilerle çalışın ve bu hizmetlerin bakım ve evrimi için gerekli yaklaşımı gösterin. Hizmeti oluşturmayla bağlantılı risk mevcut olduğu gibi bir diğer kurumsal çaba altında hizmetleri kullanmamanın da riski söz konusudur. Risklerin ve potansiyel faydaların belirlenmesine yardım edin. Bunu, gelecekte kurumsal kullanım için kullanılabilecek bir iç hizmet oluşturarak yapın.

Entegrasyon ve iç faaliyet gösterebilme (I&I): I&I her zaman büyük bir risk faktörü olacaktır. Bütünleştirme ve içten faaliyet gösterme eylemlerinin değerinin uyumlu riskleri aşabildiği bağımlılıklar söz konusudur. Kurumsal federasyon mimarisi, talep üzerine bir araya getirilebilecek yetenekler ve tasarım desenleri hükümet planlarının gerçekleştirilmesine yardım ederek I&I risklerinin kılavuzluğunun yapılmasını sağlayabilir.

Bilgi güvenliği: Bilgi güvenliği neredeyse her türlü gelişimde risk temsil eder. Bu risklerin bir kısmı hükümet taleplerinin kendilerine özgü olması ve bu alandaki taleplere bağlı olarak belirir. Bazıları ise siber saldırılara karşı koyarken ortaya çıkan zorluklardır. Belli türdeki saldırılara karşı güvenlik yetenekleri oluşturmak zorlayıcı ve risklidir. Hükümetin direnç yaklaşımları oluşturmasına yardım edilmesi gerekir. Koalisyon operasyonlarında iç aktörler ile bilgi paylaşımını mümkün kılmak, gelişim safhasında teknik zorluklar ile güvenlik politikası sorunları doğurabilir. Tedarik zinciri ile bağlantılı bilgi güvenliği hususları geniş ve karmaşık olduğu gibi tehditlere karşı sürekli hazır bulunmak çok büyük bir zorluktur.

Yetenek seviyesi: Geliştiricilerin, bütünleyicilerin, devletlerin ve sektördeki diğer aktörlerin yetenek seviyesi risklere neden olabilir. Yetenek açığı olan noktaları yamamak için iş birliğine gidin. Aynı zamanda kurumsal bilgileri öne çıkararak devlet çalışanlarının eğitimine katkıda bulunun.

Maliyet riskleri: Programlar nihayetinde hükümetin riskleri değerlendirmesine ait maliyeti çıkaracaktır. Bir programın teknik ve diğer risklerini gözden geçirirken, bağlantılı maliyetler kendini göstermelidir. Maliyet tahmini sadece tek seferlik bir eylem değildir.

Risk tanımlamasında arşiv bilgilerinin kullanılması. Benzer hükümet programlarından bilgileri kullanmak risklere ışık tutabilir. Farklı operasyonlardan öğrenilen tecrübelere ait bilgilere erişin, aynı zamanda tepki sonrası raporlara, deney sonuçlarına bakın. Müşteriler bu bilgilere belli erişim yeteneklerine sahipken, hükümet liderleri normalde stratejik ihtiyaçlarını ve zorluklarını iletirler. Müşterilerinizin en önemli yetenek ihtiyaçlarını değerlendirerek risk değerlendirmesinin tabanı yapın.

Riskleri değerlendirmek için kullanılabilecek tarihi bilgiler, geçmişteki performans değerlendirmelerine ve satın almalar ile müteahhitlere yönelik tecrübelerden sıkça edinilebilir. Birçok vakada, hükümeti belli bir satın alımda performans bilgisine hazırlamakta MITRE ekibi görev almaktadır. AF, bir Geçmiş Performans Değerlendirme Kılavuzu’na (PPEG) sahiptir. Kılavuz, hükümetin gelecekteki kaynak seçiminde kullanılacak bilgilerin tanımlanması için kullanılabilir. Arşivlerdeki bilgiler geçmişte yaşanan zorlukları anlamaya yardım edebilir ve gelişim sürecindeki faaliyetlerde ve belli müteahhit ilişkilerine bağlı olarak yeniden baş gösterebilir.

Satıcı ürünlerinin risklerini değerlendirmek ve çeşitli ürünlerin mevcudiyetini anlamak için çeşitli teknik değerlendirmeler yapılabilir. MITRE bağlantılı bir kaynak değerlendirme aracı, analitik araçlar üzerinde kılavuzluk sunan Analysis Toolshed’dir. Deneylerde ve prototiplerde bu tür araçların kullanılması ve tecrübesi bulunanların bilgilerine başvurulması belli bir çabadaki riskleri azaltacaktır.

Bir risk nasıl yazılır – en iyi uygulama: Bir risk açıklamasının yazılmasında en iyi uygulama protokolü Şart-Eğer-Sonrasında yapısıdır. Bu protokol, neredeyse her türlü çevre için tasarlanmış risk yönetim süreçleri için uygulanabilir. Doğası geresi bir riskin ortaya çıkabilme olasılığının farkına varılır ve gerçekleşmesi halinde neden olabileceği sonuçlar değerlendirilir.

Şart-Eğer-Sonrasında yapısı nasıldır?

Şart, bugün bilinenleri temsil etmektedir. Tanımlanmış risk olayının kök sebebidir. Böylece, Şart gerçekleşmiş ve halen gerçekleşen bir olaydır. Veya mutlaka gerçekleşecektir. Risk olayları, Şart mevcut olduğu için gerçekleşecek eylemlerdir.

Eğer, mevcut olan Şart ile bağlantılı risk olayıdır. Eğer ve Şartı bir ikili olarak tanımlamak önemlidir. Risk olayının altında yatan köke (Şart) doğrudan müdahale edebilecek veya gereği kazandırabilecek yöntemler olabileceği gibi bu olayların gerçekleşmesi halindeki sonuçlar, projeyi daha fazla tehdit edemez. Eğer, risk değerlendirmesinin olasılık değerini temsil eder.

Sonrasında, sonuç veya bir dizi sonuçları temsil etmektedir. Eğer risk olayı gerçekleşirse, mühendislik sistemini etkileyecek sonuç veya sonuçları içerir.

Ekipleri riskleri tanımlamak konusunda cesaretlendirin. Bazı hükümet projelerinin kültürü veya programların türü risklerin tanımlanması konusunda cesaret kırıcı olabilir. Risk yönetimi faaliyetlerini temsil eden takip, denetleme ve risk önleme çok yüklü ve anlamsız olarak görülebilir. Bu durumda ekipler ile faydalar hakkında konuşmak ve riskleri tanımlayarak nasıl yönetilebileceklerini anlatmak, öncelikleri belirlemek, kimin görev alması gerektiğini açıklamak ve riskli eylemlerin engellenmesini sağlamak için çaba gösterilmelidir.

Yönetim yatırımında devlet ekiplerinin desteklenmesi, projenin sonucundaki değerin artmasını sağlayacaktır. Genelde, iyi bir denge projenin ölçeği, takvimi ve maliyet hedefleri karşılandığında veya aksiyon olayları ile başarıyla sağlandığında, proje ekibi risk yönetim faaliyetlerinin gerçek bir değer verdiğini görecektir. Takımlararası sunum zorunluluk olarak belirirken, riskler bir birey tarafından veya sadece sistem mühendisliği ekibi tarafından belirlenmemelidir.

Organizasyonel ve çevresel faktörleri değerlendirin. Organizasyonel, kültürel, politik ve diğer çevresel faktörler, bir projeye sadece teknik faktörlerin dışında daha fazla risk oluşturabilir. Bu riskler projenin hayatı boyunca aktif olarak tespit edilmeli ve engellenmelidir. Önleme faaliyetleri yasal zorunlulukların denetlenmesi veya program veya proje görevini etkileyebilecek acil durum değişimleri olabilir. Bu değişimler kullanıcı gereksinimlerini veya yeteneklerin kullanılabilirliğini değiştirebilir, hatta politik yaklaşımı etkileyerek projenin finansal kaynaklarını etkileyebilir. Her türlü durumda, program için geçerli riskleri değerlendirin ve sektör ortakları ile değerlendirme yaparak eylem opsiyonlarını gözden geçirin.

Sektör ortaklarını risk tanımlamasına dahil edin. Projeler ve programlar, sonuçlara birçok farklı riskin etken olabileceği çok sayıda sektör ortağının katılımını gerektirir. Proje ve programlar yeni sistemlerin altından kalkmakla mücadele eden operatörler; iyi eğitim almamış veya mesleklerine yönelik korkuları bulunan kullanıcılar; otoritelerini azalttığını düşündükleri yeteneklere karşı endişe duyan yöneticiler; ve yasal uygulamaların maliyetleri konusunda korkuları bulunan politika belirleyicileri içerir. Sertifikasyon ve akreditasyon otoriteleri dahil tüm sektör ortaklarını dahil etmek, programın devamında büyük riskler doğurabilecek gözardı etme ihtimalini ortadan kaldırır. Sektör aktörleri çeşitli çevrese faktörlerden haberdar olabilirler. Bunlar arasında projeye risk oluşturabilecek yasal veya politik programlar bulunabilir. Devlet veya MITRE proje ekibi tarafından bilinmeyen bu riskler, tüm sektör aktörlerinin dahil edilmesi ile tespit edilebilir.

Anlaşılır risk tanımlamaların yazılması. Şart-Eğer-Sonrasında formatını kullanmak, risk tanımının iletişimi ve değerlendirmesinin yanu sıra bir önleme stratejisinin geliştirilmesinde de rol oynar. Kök sebep, riskin ortaya çıkmasını sağlayan altında beliren Şarttır. Eğer, olasılığı yansıtır. Sonrasında ise programın ortaya koyacağı etkileri iletir. Tasarım yaklaşımı, olasılık değerlendirmesi ve destek test süreci için artan kaynaklar her üç unsur için sırasıyla örnek gösterilebilecekken, risk önleme stratejisi her zaman açıkça tanımlanmış riskler karşısında daha başarılıdır.

Risk değerlendirme ve önleme stratejisi geliştirildikçe risk tanımında da değişimler yaşanabilir. Ekibin ortaya çıkabilecek etkiyi değerlendirmesinin ardından risk tanımlamalarının yapılması normaldir. Olası risk etkisini (maliyet, takvim, teknik…) değerlendirirken, riskin tanımı ve anlayışı değişebilir. Örneğin bir yazılım takviminin değişiminin oluşturacağı risk değerlendirilirken, risk tanımlaması belirlenen tarihin önemini öne çıkarmalı ve olası etkileri açıklamalıdır (yazılım Mart 2022’de teslim edilmezse, olası faydaları ve performansını test etmek için yeterli zaman bulunmayacaktır).

Risk tanımında risk önleme tanımını eklemeyin. Risk önleme tanımın, risk tanımında yer alması tuzağına düşmeyin. Bir risk, olumsuz sonuç olasılığı bulunan bir belirsizliktir. Önlenmesi gereken riski tanımlamak yerine riski önleme sonucuna atlamak, riskin bir alt-optimal tasarım yaklaşımı gibi gösterilmesine neden olur. Eğer müteahhit test için XYZ kullanmıyorsa, test başarısız olacaktır. Eğer müteahhit testi analiz için ölçülebilir sonuçlar ile gerçekleştirmezse, program limitli kullanıcı testini geçemeyebilir. XYZ’nin kullanılması, yeterlilik riskini azaltmak için bir risk önleme opsiyonu olarak kullanılabilir.

Risk olasılığı ve etkisini değerlendirmeden risk önleme stratejisini tanımlamayın. Bir risk gelecekteki analizlere göre yeniden değerlendirilebilir ve değişebilir. Böylece en etkili olabilecek risk önleme yöntemini etkileyebilir. Mühendisler her ne kadar her zaman sonuca atlamaya meyilli olsa da, ilk olarak risk etkisi değerlendirmesi ve önceliklerine yönelik analiz yaparak problemi anlamak gereklidir. Nihayetinde bu yaklaşım endişeleri karşılayan bir stratejinin hazırlanmasını sağlayacaktır.