Tehdit modellemesini DevOps ile tümleştirme

Bu gönderi Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez ve Ben Hanson tarafından yazıldı

Giriş

Tehdit modelleme, bir uygulama veya sistem için en önemli risk azaltmalarını belirlemeye ve önceliklendirmeye yardımcı olan önemli bir güvenlik yöntemidir. Bu makale, tehdit modellemesini daha etkili ve verimli bir şekilde benimsemenin, modern DevOps metodolojileri ve araçlarıyla tümleştirmenin ve Yazılım Geliştirme Yaşam Döngüsü ile ilgili tüm aktörlere sağlanan değere odaklanmanın nasıl mümkün olduğuna ilişkin bazı yansımalar içerir.

Bu kağıt sana mı?

Bu makale, Microsoft'un güvenlik ve tehdit modelleme uzmanlarından oluşan küçük bir ekibin çalışmasının sonucudur ve Microsoft dışındaki en önemli uzmanlardan bazılarının girişlerini ve fikirlerini içerir. Basit ama acil bir soruyu ele almaya çalışır: Kullandığımız tehdit modelleme işleminin Çevik metodolojiler ve DevOps tarafından dayatılan modern gereksinimlere güncelleştirildiğinden emin olmak için ne yapmalıyız, böylece gerekli değeri en düşük maliyetle sağlarız?

Ürün Sahibi, Güvenlik ekibinin üyesi veya yalnızca geliştirme yaşam döngünüzün bir parçası olarak tehdit modellemeyi benimsemeyi düşünen bir geliştiriciyseniz, bu makale size yöneliktir.

Benzer şekilde, tehdit modellemeyi zaten benimsediyseniz sürecinizi geliştirmek için pratik fikirler bulabilirsiniz.

Bununla birlikte, makale geçerli süreçleri iyileştirmeye veya DevOps sürecinizin bir parçası olarak tehdit modellemeyi başarıyla benimsemeye yönelik fikirler tanıtmak için tasarlanmıştır. Gelecekte bazı araçlar veya ürünler tarafından uygulanan bu fikirleri görme umudumuz olsa bile belirli araçları veya ürünleri tanıtmıyor. Bu nedenle, yeni araçların duyurularını veya yaklaşan özelliklerin önizlemelerini burada bulamazsınız.

Tehdit modellemesi neden önemlidir?

Tehdit Modelleme, yazılım çözümlerini güvenli bir şekilde tasarlamaya yönelik birincil yaklaşımlardan biridir. Tehdit Modelleme aracılığıyla bir sistemi analiz ederek saldırı vektörlerini tanımlar ve bu saldırıların getirdiği riskleri azaltmak için eylemler geliştirirsiniz. Uygun şekilde yapılan tehdit modelleme, herhangi bir Risk Yönetimi sürecinin mükemmel bir bileşenidir. Ayrıca tasarım sorunlarını erken tanımlayıp düzelterek maliyetleri azaltmaya da yardımcı olabilir. NIST tarafından yapılan eski bir çalışma, üretim kodundaki bir tasarım sorununu düzeltme maliyetinin, tasarım aşamasında onarılmasından yaklaşık 40 kat daha yüksek olduğunu tahmin ediyordu. Ayrıca, nihai tasarım sorunları için güvenlik olaylarından kaynaklanan maliyetlerden tasarruf sağlar. IBM Security ve Ponemon Institute tarafından sunulan 2022 Veri İhlali Maliyeti Raporu'nun bir veri ihlalinin ortalama maliyetinin 4,35 milyon ABD doları olacağını tahmin ettiğini düşünün. 50 milyondan fazla kaydın güvenliğinin aşılmasıyla ilgili mega ihlaller için ortalama maliyet 387 milyon abd dolarına ulaşıyor!

Tehdit modelleme, çözüm tasarımı üzerinde çalıştığından çözümünüzün güvenliğini sağlamak için yapabileceğiniz ilk etkinliktir. Bu özellik, SDLC'nize uygulayabileceğiniz en etkili güvenlik uygulaması olmasını sağlar.

Microsoft'un tehdit modellemeyle ilgili uzun bir geçmişi vardır. 1999'da iki (sonra) Microsoft çalışanı, Loren Kohnfelder ve Praerit Garg, ürünlerimize yönelik tehditler adlı bir belge yazdı. Bu makalede, Microsoft tehdit modelleme işlemine yönelik bir eş anlamlı olan STRIDE yaklaşımı tanıtıldı.

Tehdit modellemesi evrimsel bir süreçtir

Tehdit modellemesi statik bir işlem değildir; ihtiyaçlar ve teknolojiler değiştikçe gelişir.

• SolarWinds'i hedefleyen en son saldırılar gibi Tedarik Zinciri saldırıları, Tehdit Modellemesi ile geliştirme ve dağıtım dahil olmak üzere çözümün kendisinden daha fazla senaryoyu ele alma gereksinimini göstermektedir.

• Log4j için son kullanılan gibi Açık Kaynak güvenlik açıkları, güvenlik açığına açık bileşenleri taramak için yazılım bileşimi analizi araçlarının benimsenmesi temelinde mevcut yaklaşımın desteklenmesi gerektiğini ve çözümün açığa çıkmasını sınırlandıracak şekilde savunmalı bir şekilde tasarlanması gerektiğini göstermiştir.

• Machine Learning gibi yeni teknolojilerin uygulanması, anlaşılması ve denetlenebilmesi gereken yeni saldırı vektörlerini tanıtır. Örneğin, içinde açıklandığı https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlinigibi yapay zeka hizmetleri tarafından komutların yürütülmesine neden olmak için insan kulaklarının kötü amaçlı olarak hazırlanmış seslerini çalma olasılığını göz önünde bulundurun.

Microsoft'ta farklı ürün grupları, özel güvenlik gereksinimlerine göre farklı tehdit modelleme çeşitlemeleri uygular. Her değişken, uygulandığı senaryolar için yeterli düzeyde güvenlik güvencesi sağlamayı amaçlar, ancak "yeterli" ifadesi belirli bir bağlama bağlı olarak değişir.

Örneğin, Bu sistemlerin boyutları ve özellikleri çok farklı olduğundan Windows'un güvenliğini sağlamak Azure Bilişsel Hizmetler'in güvenliğini sağlamaktan farklıdır. Tehdit modellemesinin önemli bir yönü, maliyeti bir uygulama için risk toleransı ile dengelemektir. Bu, bazı senaryolarda tehdit modellemesini tamamen önleme kararına neden olsa da, düzgün yapıldığında o kadar etkilidir ki, yazılım geliştirme ve altyapı dağıtım projeleri de dahil olmak üzere yalnızca herhangi bir BT girişimi için bunu benimsemenizi önerebiliriz.

YG'ye odaklanmanın önemi

Son birkaç yılda önemli bir yazılım geliştirme süreci olarak tehdit modellemeye olan ilgi sürekli artmıştır. Bu ilgi, altyapılara ve çözümlere yönelik saldırıların üstel olarak artmasından kaynaklanır. NIST Satıcı veya Geliştirici Kod Doğrulaması için Önerilen En Düşük Standart ve Tehdit Modelleme Bildirimi gibi girişimler, mevcut yaklaşımların bazı sınırlar gösterdiği noktaya talebi daha da artırmıştır. Örneğin, tehdit modellemesinin sonuçları benimsenen işleme ve tehdit modelini kimin gerçekleştirdiğine son derece bağlıdır. Bu nedenle, deneyimden sürekli olarak daha yüksek kalite alma konusunda bir endişe vardır.

Ancak tehdit modelleme için kalite ne anlama gelir? Kalite tehdit modelinin bizim için aşağıdaki özelliklere sahip olması gerekir:

• Saldırılardan kaynaklanan olası kayıpları azaltmak için yapabileceğiniz eyleme dönüştürülebilir risk azaltmaları ve etkinlikleri tanımlaması gerekir. Eyleme dönüştürülebilir, bu azaltmaların iyi tanımlanmış olması gerektiği anlamına gelir; başka bir deyişle bunları uygulamak ve sonra uygulamayı test etmek için yeterli bilgiye sahip olursunuz. Bu aynı zamanda Geliştirme ekibinin kolay kullanımına izin vermek için bunların sağlanması gerektiği anlamına gelir. DevOps ve Çevik ile bu, azaltmaları Kapsam'a aktarmak için kolay bir yol olduğu anlamına gelir.

• Her Azaltma için durumunu tanımlaması gerekir. Bazı azaltmalar yeniyken, diğerleri zaten var. Tehdit modelinin mevcut olanı tanıması ve durumu nasıl iyileştireceklerini belirlemek için geçerli risklere odaklanması gerekir.

• Her Risk Azaltma'nın neden gerekli olduğunu ilgili tehditlere bağlayarak net bir şekilde tanımlaması gerekir.

• Ayrıca, azaltmalar her tehdit için göreli bir güce sahiptir. Örneğin, TLS şifrelemesi aktarımdaki verilerin açıklanma riskinin güçlü bir risk azaltması olabilir ve aynı zamanda sunucunun kimlik sahtekarlığına sahip olma riski için neredeyse eksiksiz bir azaltma olabilir.

• Tehditler güvenilir, iyi tanımlanmış ve çözüme özgü olmalıdır.

• Tehditlerin hem olasılıklarını hem de etkisini dikkate alması gereken ilişkili bir Önem Derecesi olmalıdır. Önem Derecesi makul ve ideal olarak önyargısız olmalıdır.

• Risklere ve bunların nasıl ele alınabileceğine ilişkin kapsamlı bir görünüm elde etmek mümkün olmalıdır. Bu görünüm, Güvenlik ekibiyle ve İş Kararları Verenler ile anlamlı bir konuşma yapılmasında etkili olur ve gereksiz karmaşıklıkları gizlememize olanak sağlar.

Bu listede zaten önemli bir kavram gösterilmektedir: tehdit modellemesi, yazılım yaşam döngüsü sırasında yer alan birçok role değer sağlayabilir, ancak her rolün farklı gereksinimleri ve gereksinimleri vardır. Örneğin, geliştiricilerin neleri uygulaması gerektiği hakkında net bilgi alması ve gerçekleştirdikleri şeyin beklendiği gibi davrandığını nasıl doğrulayacakları hakkında net bilgi alması gerekir. Öte yandan, Güvenlik ekibi genellikle kuruluşun sahip olduğu altyapı ve uygulamalar ekosisteminin genel güvenliğiyle ilgilenir; bu nedenle, kapsamdaki sistemin yeterince güvenli olup olmadığını ve uyumluluk gereksinimlerini karşılayıp karşılamamasına karar vermek için bilgi almaları gerekir. Son olarak, Ürün Sahiplerinin ve İş karar alıcılarının, riski kuruluş için kabul edilebilir hale getirmek için nelerin gerekli olduğunu anlaması gerekir.

Bu tür farklı gereksinimlerin tehdit modeli üzerinde farklı görünümler sağlaması gerekir ve her biri belirli bir kullanım senaryosuna odaklanır.

Tehdit modelleme ile ilgili tipik bir sorun, ne kadar başarılı olursa, bu deneyimden beklenen yüksek kaliteyi sağlamaya devam ederken az sayıda mevcut uzmanın talebi karşılamasının o kadar zor olmasıdır. Sonuç olarak, bazı durumlarda kalite olumsuz etkilenebilir. Tehdit modellemesi yatırımla karşılaştırıldığında önemli bir değer sağlamayı durdurana kadar her şey iyidir. Bu sorun birkaç kuruluştan daha fazla etkileniyor. Maliyet için önemli bir değer sağlayamadığı için tehdit modellemesini sorgulamaya başlayan İş Karar Alıcıları'nın birkaç raporu zaten vardır.

Değerle, sistemin kapsam dahilinde temsil ettiği riskleri anlamak ve uygulanacak uygun risk azaltmaları seçmek için anlamlı bir karar süreci sağlamak için gereken bilgileri sağlayabilme özelliği olan İş değerine başvururuz. Ayrıca değer, Geliştiricilere ve Test Edenlere doğru bilgilerin sağlanmasıyla da ilgilidir. Son olarak değer, artık riskin ilgili tüm taraflara iletilmesiyle ilgilidir. Örneğin, tehdit modelleme sürecinin etkisini ölçerek değeri ölçebiliriz. Her bir tehdit için tanımlanan Önem Derecesi'ne bir sayı atayarak çözümün genel riskini ölçtük diyelim. Bu durumda, tehdit modelinin etkisine göre zaman içinde genel riskin azalmasını bekliyoruz. Genel risk sabit kalırsa veya artarsa bir sorun yaşayabiliriz. Düşüş ne kadar dik olursa tehdit modelinin etkisi o kadar yüksek olur. Elbette, tehdit modeli uygulanan azaltmaları denetlemez. Nelerin uygulanması gerektiğine karar vermek Ürün Sahibinin sorumluluğundadır. Ancak tehdit modelinin etkinliğini azaltmaların gerçek uygulamasıyla ilişkilendirmenin avantajı, çözümün gerçek güvenliği üzerindeki etkisini artırarak tehdit modelinin teorik bir alıştırma olarak kalma riskini azaltmasıdır.

Bunun yerine maliyet, tehdit modelini gerçekleştirmek için gereken etkinliklerle ilgilidir. Bu, tehdit modelini oluşturmak ve tartışmak için tüm ilgili tarafların gerektirdiği süredir.

Bu, şu soruyu akla getirir: İş değerini en üst düzeye çıkarmaya ve maliyeti en aza indirmeye odaklanan bir tehdit modelleme süreci tanımlayabilir miyiz?

DevOps'un önemi

Tehdit modellemesinin DevOps işlemiyle tümleştirilmiş değerli bir uygulama olduğundan emin olmak için ne kadar önemli olduğunu zaten vurguladık. Bu, sürecin genellikle basitleştirilerek ve otomatikleştirilerek tüm ekip üyelerinin kullanımına sunulması gerektiği anlamına gelir. En önemlisi, DevOps için tehdit modellemeye odaklanmak, deneyimin mevcut DevOps işlemleriyle derinlemesine tümleştirildiğinden emin olmamız gerektiği anlamına gelir.

Tehdit modellemesi henüz başka bir yük haline gelmemelidir, ancak bunun yerine güvenlik gereksinimlerinin düzeltilmesi ve toplanması, güvenli çözümlerin tasarımı, etkinliklerin tercihi Görev ve Hata İzleme aracına dahil edilmesi ve çözümün geçerli ve gelecekteki durumu göz önüne alındığında artık riskin değerlendirilmesi için bir varlık olmalıdır.

DevOps ile hizalama

Tehdit modellemesini geçerli DevOps uygulamasıyla uyumlu hale getirmek için çeşitli teknikler kullanabiliriz.

Tehditler ve azaltmalar

İlk olarak, tehdit modelleme işlemine yapılması gerekenlere odaklanmamız gerekir. Saldırı düzenleri ve bunların nasıl gerçekleşebileceği olan tehditler, ekibin neden bir güvenlik denetimi uygulaması gerektiğini açıklamak için gereklidir. Ayrıca, azaltmaların ne zaman uygulanması gerektiğini belirlemede de bir faktördür. Yine de asıl amaç yapılması gerekenleri belirlemektir: risk azaltmaları. Bu nedenle, yaklaşım gerekli azaltmaların hızlı bir şekilde belirlenmesine yol açmalı ve ne zaman ve ne zaman yapılması gerektiğini belirlemenin daha kolay olması için karar sürecini bilgilendirmelidir. Bu karar sürecinin temel teslim edilebilir özelliği, seçilen risk azaltmaların standart sürecin bir parçası haline getirmek için Kapsam'ta yer almaktır. İdeal olarak tehdit modelleme aracı ve görev ve hata izleme aracı, tehdit modelindeki azaltma durumu güncelleştirmelerini yansıtacak şekilde eşitlenmelidir. Bu, sprint Planlama toplantısı gibi benimsenen Çevik metodolojisinin olağan koreografilerinin bir parçası olarak bilinçli kararları desteklemek için çok önemli olan artık riski dinamik ve otomatik olarak düzeltmeye olanak sağlar.

Bugün ne yapabilirsin?

Bir tehdit modelleme uzmanı olarak, eylemleri net bir şekilde belirleyebilen ve bunları seçtiğiniz Görev ve Hata İzleme'ye ekleyebilen bir tehdit modelleme işlemi uyguladığınızdan emin olmalısınız. Bunun bir yolu, bu işlemi otomatikleştirebilecek birçok tehdit modelleme aracından birini benimsemek olabilir.

Geliştirici olarak, gerekli olarak tanımlanan güvenlik denetimlerine odaklanmanız gerekir. İşlem, bunları size başka herhangi bir etkinlik almayı beklediğiniz şekilde sağlayacak şekilde tasarlanmalıdır.

Özellikler, kullanıcı hikayeleri ve görevler

Azaltmaların DevOps tümleştirmesi ile ilgili tehdit modeli tarafından üretilen en önemli yapıtı temsil ettiğini zaten belirttik. Bu nedenle, seçtiğiniz Görev ve Hata İzleme aracında bu risk azaltmalardan oluşturulan nesnelerin türünü net bir şekilde tanımlamak önemlidir. Bazı azaltma işlemleri Sprint'ten daha uzun sürebilir. Bu nedenle, bunları Özellik olarak oluşturmak en iyisi olabilir. Ancak çoğu daha kolaydır ve tek bir Sprint'te uygulanabilir; bu nedenle, bunları kullanıcı hikayeleri veya görevler olarak temsil etmek mümkün olabilir. Farklı iş öğesi türleri oluşturmak mümkün olsa da, bu hatalara ve karışıklığa neden olabilecek karmaşık bir işleme neden olabilir. Bu nedenle, tek bir iş öğesi türüne bağlı kalmak daha pratik görünüyor. Azaltmaların kullanıcı hikayelerinin alt öğeleri olarak kabul edilebileceği göz önünde bulundurulduğunda, bunları Görevler olarak temsil etmeyi düşünebilirsiniz; bu da söz edilen iş öğesi türünün tek bir Sprint'te yürütülmesi gereksinimini hafifletmek anlamına gelir.

Bugün ne yapabilirsin?

Tehdit modeli tarafından tanımlanan azaltmaların kapsam içinde temsil edildiklerinden emin olun. Bunları açıkça temsil etmenin bir yolunu belirleyin.

Kullanıcı hikayeleri

Risk azaltmalar, tehdit modelinin görev ve hata izleme aracınızdakilerle uyumlu olabilecek ve hizalanması gereken tek yapıtlar değildir. Örneğin, tehditleri de temsil etmek isteyebilirsiniz. Bu hedefe, bir WITHOUT yan tümcesi eklenerek kullanıcı hikayelerinin her zamanki "[Kimim] olarak [ne istiyorum] olmasını istiyorum, böylece [bir şey yapabilirim]" şeklinde genişletilerek elde edilebilir. Örneğin: "Kullanıcı olarak, kredi kartımın çalındığı veriler çalınmadan bazı ürünler satın alabilmem için kredi kartımla ödeme yapmak istiyorum". WITHOUT yan tümcesi bir veya daha fazla tehditle eşlenebilir ve bazen Güvenlik Gereksinimlerini ifade edebilir. Tehditler ve WITHOUT yan tümceleri arasındaki bu hizalamanın tehdit modelinde açıkça belirtildiğinden emin olarak, olası risklerin kullanıcı hikayelerinin bir parçası olarak dahil edildiğinden ekip tarafından yansıtılmasını ve ilgilenilmesini sağlayabiliriz. Bu ilişkiyi, kullanıcı hikayelerinin bir parçası olarak tanımlanan her Güvenlik Gereksinimini en az bir tehditle eşlemek için de kullanabilirsiniz.

Bilmek güzel

WITHOUT yan tümcesi, bu sayfayı oluşturan ekip tarafından özgün bir fikir değildir. Bunu ilk kimin tanıttığı hakkında emin değiliz, ancak bu fikri kullanan kişiye minnettarız.

Şekil 1: Gereksinimleri hizalama

Örneğin, önceki resimde aşağıdaki durumlar gösterilmektedir:

• Tehdit A, 1 OLMADAN yan tümcesi aracılığıyla Kullanıcı Hikayesi 1'e bağlanır.

• Threat B, 2 OLMADAN yan tümcesi aracılığıyla Kullanıcı Hikayesi 2'ye bağlanır.

• Tehdit B, Kullanıcı Hikayesi 3'e de bağlıdır. Ancak Kullanıcı Hikayesi 3, WITHOUT yan tümcesine atanmadı. Neden? Araştırmanız gereken olası bir anomaliyi temsil eder.

• Tehdit B, Kullanıcı Hikayesi 1'e de bağlıdır. Kullanıcı hikayelerinin birden fazla tehditle bağlantılı olmasına izin vermemiz gerekip gerekmediği henüz net değildir.

• Threat C, 3 ve 4 OLMADAN ilişkili Olan Kullanıcı Hikayesi 4'e bağlıdır. Birden fazla WITHOUT yan tümcesine izin vermemiz gerekip gerekmediği henüz net değildir.

• Tehdit D hiçbir kullanıcı hikayesine bağlı değildir. Kullanıcı hikayesi mi yoksa WITHOUT yan tümcesi mi eksik?

• Kullanıcı Hikayesi 5, WITHOUT yan tümcesine bağlıdır, ancak ilişkili bir tehdidi yoktur. Bir tehdidi mi yoksa yalnızca kullanıcı hikayesiyle tehdit arasındaki bağlantıyı mı kaçırıyoruz?

Güvenlik Gereksinimlerini tehdit modelinin bir parçası olarak nadiren tanımlarız. Bu nedenle WITHOUT yan tümcesi, tehdit modellerini Güvenlik Gereksinimleri ile genişleterek ve bunları ilgili kullanıcı hikayeleriyle bağlayarak deneyimi daha fazla tümleştirme fırsatı sunar. Bu yaklaşım, tehdit modelleme deneyiminin zaman içinde tekrarlanan bir değerlendirmeden DevOps için güvenlik tasarımı aracı haline gelmesine kadar gelişmesinde önemli bir rol oynar.

Bugün ne yapabilirsin?

Kullanıcı hikayelerinizde WITHOUT yan tümcesini kullanmaya başlayın.

Tanımladığınız tehditleri WITHOUT yan tümceleri ile kullanıcı hikayeleriyle eşleyin ve tam tersi de geçerlidir.

Tümleşik bir deneyim

Aynı fikri diğer senaryolara da uygulayabilirsiniz. Örneğin, tehdit modeli Güvenlik Gereksinimleri'ni tehdit modelinin içindeki yapıtlarla (tehditler ve risk azaltmalar gibi) ve İzleme ve Hata İzleme aracındaki yapıtlarla ilişkilendirebilir. Örneğin, sürmekte olan saldırıları tanımlamak için izleme uygulama gereksinimi, izlemeyle ilgili tüm bu risk azaltmalarıyla ve ardından Görev ve Hata İzleme aracındaki ilgili yapıtlarla eşlenmelidir. Sonuç olarak, bir Güvenlik Gereksiniminin gerçekleşmediği durumları tanımlamak kolay olacaktır: aslında hiçbir şeye bağlı olmaz.

Güvenlik etkinliklerinin önceliklendirilmesini kolaylaştırmak için Görev ve Hata İzleme aracındaki yapıtlar ile tehdit modeli tarafından tanımlanan tehditler ve azaltmalar arasında aynı bağlantıları kullanabilirsiniz. Güvenlik genellikle en son uygulanır, bazen bazı araçlar veya Sızma Testi tarafından tanımlanan reaktif güvenlik açıklarını gidermek için. Tam tersine, ilgili kullanıcı hikayeleri veya özellikleriyle birlikte risk azaltmaları uygulamak en etkili olacaktır. Kredi kartı ayrıntılarını ilgili ödeme işlevleriyle birlikte uygulamanız gerekirken neden denetimleri uygulamak için bekleyin? Tehdit modeli bu ilişkileri vurgulamalı ve Sprint sırasında bazı özelliklerin uygulanması için ilgili bazı güvenlik özelliğinin uygulanmasının ne zaman gerekli olduğunu belirlemek için basit bir yol sağlamalıdır. Bu bilgiler, örneğin Sprint Planlama toplantısı sırasında anlamlı bir tartışma yapmak ve bilinçli bir öncelik belirleme sağlamak için kullanılabilir. Mekanizma basittir. Üzerinde çalıştığımız bir projenin Ürün Sahibi'nin bir sonraki Sprint için bir kullanıcı hikayesi planlamaya karar vereceğini varsayalım. Söz konusu kullanıcı hikayesinin tehditle bağlantılı bir WITHOUT yan tümcesi vardır. Tehdit modeli, aynı tehdit için çeşitli risk azaltmaları tanımlar. Bu nedenle, tanımlanan risk azaltmalarından birini veya daha fazlasını önceliklendirmemiz gerektiğini hemen belirtebiliriz.

Şekil 2: Güvenliği önceliklendirme

Örneğin, yukarıdaki resimde Kullanıcı Hikayesi 1'in tehdit 1'e bağlandığını ve bunun da A ve B azaltmalarına bağlandığını görebiliriz. Bu nedenle, bu risk azaltmalardan birini veya her ikisini de uygulamayı göz önünde bulundurmalıyız.

Bugün ne yapabilirsin?

Başvuru olarak tehdit modelini kullanarak kullanıcı hikayelerini WITHOUT yan tümceleriyle seçili azaltmalara karşılık gelen iş öğelerine bağlayın. Sonraki Sprint'i planlarken, WITHOUT yan tümceleriyle bu kullanıcı hikayelerinden birini uygularken bağlantılı güvenlik etkinliklerine öncelik eklediğinizden emin olun.

Yanlış hizalamaları vurgulamak için tümleştirme

Tehdit modelini oluşturan yapıtları Görev ve Hata İzleme aracındaki yapıtlarla nasıl ilişkilendirebileceğimizi düşünmeye başladığımızda, her ikisinin kalitesini artırma fırsatlarını belirlemek daha kolay hale gelir. Önemli olan, tutarsızlıkları vurgulamak için ilişkilerinden yararlanmak ve diğerinde bulunanları desteklemek, tümleştirmek ve yorumlamak için birinde bulunan bilgilerden yararlanmaktır. Yukarıda açıklandığı gibi, ekibin zaten nasıl çalıştığını önemli ölçüde etkilemeden bunu yapabilirsiniz. Bunun nedeni, yaklaşımın mevcut bilgilere dayalı olması ve çeşitli dünyalardaki çeşitli nesneler arasında ilişkiler oluşturmasıdır. Bu nedenle Tehdit Modeli, çözümün güvenliği için gerçek kaynağı olacaktır. Aynı zamanda Kapsam, çözümün durumuyla sürekli olarak hizalanır.

Bugün ne yapabilirsin?

WITHOUT yan tümceleri olan eşlenmemiş tehditler veya kullanıcı hikayeleri olmadığını düzenli olarak doğrulayın.

Tehdit modelleme ve işlemler

Tüm bu fikirler temelde DevOps'un geliştirme tarafına odaklanır. İşlemleri iyileştirmek için de bir şeyler yapabilir miyiz? Biz öyle düşünüyoruz. Örneğin, güvenlik açısından sistemin kapsamlı bir görünümünü sağladığından ve bu nedenle bazı saldırıların etkilerini daha iyi anlayabilmek için Kök Neden Analizi'ni kolaylaştırmak için tehdit modellemeyi bir araç olarak kullanmak mümkün olabilir. Bunu başarmak için tehdit modelinin seçilen İzleme araçlarından gelen mevcut akışlarla tümleştirilmesi gerekir. Bu yaklaşım, seçilen SIEM için bir tamamlayıcıyı temsil edebilir.

Tehdit modellemesini İşlemler ile tümleştirmeye yönelik bir diğer fikir de, ikincisinin nasıl gerçekleşebileceğine ilişkin tasarımı yönlendirmek için ilkini kullanmaktır. Bunun bir örneği, çözüme yönelik olayların tasarımıdır. Tehdit modelleme olası saldırıları tanımlar ve bu bilgileri, bu saldırılar başarısız olduğunda kapsamda çözümün oluşturabileceği olayları belirlemek için kullanabiliriz. Katı giriş doğrulaması yaparsanız, kötü amaçlı bir saldırganın başarılı olmadan önce birkaç deneme yapması gerekir. Başlangıçta, denemeler başarısız olur ve bunlardan biri sonunda başarılı olur. Her hata için olaylar oluşturup bazı eşiklere ulaşıldığında uyarıları tetikleyerek saldırıları algılayabilir ve bunları düzeltmek için eylemler gerçekleştirebilirsiniz. Altyapıyı izlemekle sınırladığınızda bu durumlar nadiren algılanır. Bu nedenle, SOC'nin bunları kullanabilmesi için ekibin tasarlaması ve uygulaması gereken özel olayları dahil etmek gerekir.

Dahası, ikincisi çözüm hakkında çok fazla bilgi edinmeyebilir. Bu nedenle SOC, giriş doğrulaması başarısız olduğunda nasıl tepki olacağını belirleyemeyebilir. Ne yazık ki bir veri ihlali oluştuğunda, doğrudan hasarı ve nihai para cezalarının olasılığını ve varlığını azaltmak için hızlı tepki vermek zorunludur.

Bu nedenle, izlenmesi gerekenleri, hangi koşullar altında bir sorun olabileceğimizi ve bu olduğunda ne yapmamız gerektiğini önceden planlamamız gerekir. Bu olayları tanımlamanın en iyi yolu bir tehdit modeline güvenmektir. Bu nedenle, İzleme ve Denetim'i yönlendirmek ve Olay Yanıtını kolaylaştırmak için gerekli yapılandırmaların uygulanmasını yönlendirmek ve hızlandırmak için standartlaştırılmış yapıtlar oluşturmak için bu yapıtlardan yararlanmak yararlı olacaktır.

Bugün ne yapabilirsin?

Her tehdit için oluşturabileceğiniz olayları belirlemek için tehdit modelini etkin bir şekilde kullanın. Bu olaylar altyapı veya uygulamanın oluşturması gereken bir şey tarafından sağlanabilir. Bu olayların uygulandığından emin olmak için kapsamınıza iş öğelerini ekleyin.

Olayların uyarı oluşturup Güvenlik Olaylarını tanımlamak için kullanılabilmesini sağlamak için SOC ekibi de dahil olmak üzere operasyon ve güvenlik ekiplerinizle etkin bir şekilde çalışın.

Yatırım getirisi üzerindeki etkisi

Bu tekniklerin tehdit modelleme yatırım getirisini neden olumlu yönde etkileyeceğini merak ediyor olabilirsiniz. Bizim bakış açımızdan, DevOps ekipleri için tehdit modellemesinin değerini artırmak için çok önemlidir. Sürekli gördüğümüz sorun, bu ekiplerin güvenliği sınırlı değer sağlayan ve çok fazla öngörülemeyen çalışma gerektiren bir maliyet olarak algılamalarıdır. Bazen, güvenliği düzeltmek için zamanlarının çoğunu neden bu kadar harcamaları gerektiği net değildir. Sonuç olarak, güvenlik bir fırsat yerine bir sorun haline gelir. Güvenlik uygulama nedenleri sağladığından tehdit modellemesi bu sorunların üstesinden gelme potansiyeline sahiptir. Ayrıca geliştirme sürecinin erken aşamalarında başlatılabilir ve yakında algılanmaması durumunda pahalıya mal olabilecek tasarım hatalarından kaçınılabilir. Yukarıdaki teknikler tehdit modellemesini DevOps ile daha iyi tümleştirmeyi hedefler. Bu, iş karar alıcılarının ve geliştiricilerin tehdit modellemeyi geliştirme ve operasyon sürecine doğal bir tamamlayıcı olarak algılamasını sağlar. Bu nedenle tehdit modellemesi benimsenerek alınan değer artar ve kullanımda olan çeşitli araçlarla tümleştirme nedeniyle maliyetleri düşer.

Tehdit modelleyicileri için çalışmayı basitleştirme

Tehdit modellemenin yatırım getirisini geliştirmek için gereken bir diğer önemli unsur da maliyetini düşürmek ve daha homojen kalite düzeylerini korurken bunu sunabilen kişi sayısını artırmaktır.

Yetkin insanların eksikliğini gidermeye yönelik birçok girişim vardır. Bazıları, tehdit modelleme alıştırmasında tüm DevOps ekibinin etkin katılımını temel alır. Fikir, girişim liderini tanımlamaktır. Bu, süreç hakkında ara bilgi sahibi olan ancak uzman olması gerekmeyen bir kişidir ve diğer ekip üyeleri arasında tartışmalara onun liderlik etmesini sağlamaktır. Bu yaklaşım, Tehdit Modelleme Bildirimi'nin imzalayanları tarafından etkin bir şekilde onaylanır.

Bu yaklaşımın iyi bir değer elde etmeye olanak sağladığını ve mevcut durum üzerinde bir gelişmeyi temsil ettiğini kabul ediyoruz. Ayrıca iyi içgörüler sağlar ve ekibin güvenlik kültürünü büyütmesini sağlar. Bununla birlikte, olumsuz yanı olmadan olmaz, çünkü çok fazla şey bırakarak sadece birkaç sorunu kapsar. Bu bir tutarlılık sorunu oluşturur çünkü tavşan deliğinden aşağı inmek ve önemli olanları eksik olan ikincil sorunlarda değerli zaman harcamak çok kolay olacaktır. Liderin deneyimi, bu durumların oluşmasını önlemede önemli bir rol oynar. Ayrıca bu yaklaşım, tüm ekip üyelerinin her sorunu tartışmak için çok zaman gerektirmektedir.

Bu nedenle, bu alıştırma için Sprint başına birkaç saat harcamak bile önemli bir yatırımı temsil edebilir. Herkes çoğu ekibin herkesi kapsayan büyük toplantılarda zaman kaybetme eğiliminde olduğunu ve bu tehdit modelleme oturumlarının bir istisna yaratmayacağını bilir. Yine de bu yaklaşım, ekibin bir dizi üst düzey üyeden oluştuğu küçük ürünler için mükemmeldir.

Farklı bir yaklaşım

Önceki yaklaşımın sınırlamaları göz önünde bulundurulduğunda toplantı sayısını, bunların uzunluğunu ve katılımcı sayısını sınırlamayı tercih ediyoruz. Bu nedenle, tehdit modelleyicinin sorumluluğu daha önemli olacaktır: yalnızca görüşmelere liderlik etmek değil, aynı zamanda tehdit modelinin kendisini oluşturmak ve korumak da. Bu yaklaşım daha önemli yetkinlikler ve uzmanlık gerektirir. Tehdit modelleyicileri Güvenlik Şampiyonları veya iç Güvenlik ekibinin üyeleri tarafından temsil edilebilir. Güvenlik ekibi genellikle tamamen rezerve edildiğinden çoğu kuruluş birinciye gider.

Güvenlik Şampiyonları, güvenlikle ilgili belirli bir ilgi alanı olan DevOps ekiplerinin üyeleridir. Hiçbir şekilde uzman değildirler, ancak temel bir bilgiye ve ekiplerinin güvenlik duruşunu geliştirmeye isteklidirler. Burada amaç Güvenlik Şampiyonları ile iç Güvenlik ekibi arasında ayrıcalıklı bir bağlantı oluşturmaktır. Böylece ilk ekip, ekiplerine doğru şeyi yapma konusunda yardımcı olabilirken, Güvenlik ekibi iş yükünü azaltabilir. Tehdit modelleme ile Güvenlik Şampiyonları tehdit modelleyicisi olarak görev yapacak ve iç Güvenlik ekibi onlara yol gösterme ve çalışmalarını gözden geçirme sorumluluğuna sahip olacaktır.

Bugün ne yapabilirsin?

Bir Güvenlik Şampiyonları programı benimseme olasılığını araştırın ve Güvenli Yazılım Geliştirme Yaşam Döngüsü'nüzü daha da güçlendirmek için bu programdan yararlanın.

bilgi bankası rolü

Tehdit modellemeyle ilgili önemli bir sorun, tehdit modelini kimin gerçekleştirdiğinin önemine bakılmaksızın deneyimin kalitesinin ve DevOps ekibinin değerinin yüksek olmasını sağlamaktır. Güvenlik Şampiyonları ile bu sorun daha da acil hale gelir. Bu sorunu gidermeye yönelik bir fikir, tehdit modelinin oluşturulmasını sağlamak için bilgi bankası sağlamaktır. Tehdit modellemeye yönelik Bilgi Bankaları belirli bir bağlamla ilgili bilgi paketleridir: bu bağlamla ilgili varlıkların tanımını, bu varlıklar üzerindeki olası saldırı düzenlerini ve uygulanabilecek standart risk azaltmalarını içerir. Bilgi bankaları, tehdit modelleyicilerine açıklayıcı bir şekilde yol gösteren başvuru malzemelerini temsil ettiğinden kuruluşun daha iyi ve daha tutarlı sonuçlar almasını sağlar. Bilgi bankalarının, bir sisteme otomatik olarak tehditleri ve risk azaltmaları uygulamamıza olanak sağlayan kuralları olmalıdır. Bu otomasyon, bazı tehdit modelleyicilerinin bir tehdidin uygulanması gerekip gerekmediğini veya bir azaltmanın etkili olup olmadığını belirlemek için gereken deneyime sahip olmayabileceği gerçeğini aşmamıza olanak sağlar.

Bilgi bankaları yeni bir fikir değildir: Mevcut tehdit modelleme araçlarının çoğu bunları zaten bir biçimde desteklemektedir. Ancak birçok geçerli uygulamanın önemli dezavantajları vardır. Örneğin, bilgi bankası kolayca koruyabilmeniz gerekir. Bakımları hala çözümlenmemiş bir sorundur. Örneğin, bunları oluşturmak için kullanılacak en iyi bilgi kaynaklarını belirlemek kolay değildir. Ayrıca, bakım genellikle el ile yapılır. bilgi bankası oluşturulması ve bakımı kuruluşun iç Güvenlik ekibinin sorumluluğunda olmalıdır. Şirketlerin gelecekte müşterilerinden gelen bazı yükleri kaldırmak için en yaygın tehdit modelleme araçları için bilgi bankası sağlamaya başlayacağını umuyoruz. Bu bilgi bankası, söz konusu bilgi bankası uygulamalarına, politikalarına ve düzenlemelerine uyarlaması gereken en olgun kuruluşlar tarafından bile desteklenmeleri ve benimsenmelerini kolaylaştırma konusunda esnek olmalıdır.

Bugün ne yapabilirsin?

Tehdit modellemesini hızlandırmak için çeşitli geliştirme ekipleri tarafından kullanılabilecek bilgi bankası geliştirmek için merkezi Güvenlik Ekibi'nin çabasının bir kısmını ayırma olasılığını göz önünde bulundurun.

bilgi bankası kullanma

bilgi bankası'lerle ilgili bir diğer sorun da bazen tüketemeyecek kadar karmaşık olmalarıdır. Bunların çoğu temel ve daha az kritik sorunları dahil ederek kapsamlı olmaya çalışır. Ne yazık ki, bunların tümü tüm sistemler için gerekli değildir. Analiz ettiğiniz sistem küçük olduğunda ve hassas verileri işlemediğinde daha basit bir yaklaşım benimsemek istersiniz. Tam tersine, sistem karmaşıksa ve PII ile yüksek İş değeri verilerini işliyorsa daha ayrıntılı bir şekilde devam etmek istersiniz. Bu nedenle, bağlama bağlı olarak bilginin farklı sürümlerini uygulamak veya bazı saldırı düzenlerini ve ilişkili risk azaltmaları "TOP" olarak işaretlemek mümkün olmalıdır. Sonuç olarak, tehdit modelleyicileri kapsamlı bir deneyim isteyip istemediklerine veya kolay bir şekilde gidip gerekli işi en aza indirmelerine karar verebilecektir.

Verimlilik demişken, gerekli iş miktarını azaltmak için etkinliklerin mümkün olduğunca kolay ve otomatik hale getirildiğinden emin olmak zorunludur. Ortalama boyutlu bir çözümün Tehdit Modelini gerçekleştirmek için uygun bir noktanın tehdit modelleyici için 1 günlük bir çalışma olması gerektiğini düşünüyoruz. Bu tür sonuçlar, yalnızca seçim aracının gereken süreyi kesmeye izin verecek hızlandırıcılar sağlaması durumunda mümkündür. Örneğin, araç 100 farklı yerde 20 farklı risk azaltma türü uygularsa ve her biri için durumlarını belirtmeniz istenirse, ikinci yerine ilkine odaklanarak 5 kat daha verimli olursunuz. Tercih eden araç, gerektiğinde daha kapsamlı bir iş yapma olanağı sağlarken bu özelliği sağlamalıdır.

Bugün ne yapabilirsin?

Bugün kullandığınız bilgi bankası "TOP" tehditleri ve risk azaltmaları kavramını desteklemiyorsa, yalnızca gerçekten önemli olan şeylere odaklanmaya izin vermek için nadiren gerekli veya yararlı olanı kaldırma olasılığını göz önünde bulundurun.

Bazen sorun, benimsenen bilgi bankası genel olmaya çalışması ve birden çok senaryoyu kapsamasıdır. Bunları uzmanlaştırarak durumu geliştirebilirsiniz.

Doğru soruları sorma

Analizimiz sırasında, analizin ilk aşamalarını yönlendirmek için sorular çerçevesini desteklemek için bir araç kullanma olasılığını değerlendirdik. Deneyimsiz tehdit modelleyicilerinin çoğunun analiz için gerekli bilgileri almak için doğru soruları soramadığını fark ettik. Uzmanlarımızdan bazıları kapsam dahilindeki bir sistem diyagramına göre bazı önemli soruları belirlemenin mümkün olduğunu gösterdi. Bu sorular, bazı oluşturma kurallarıyla otomatik olarak da uygulanabilir. Sorun, bu yaklaşımın söz verdiği değeri sağlayamayabilir. Bunun nedeni, her sorunun arkasındaki mantığı anlamanız gerektiğidir. Aksi takdirde, yanıtı değerlendiremez ve tatmin edici olup olmadığını saptayamazsınız. Yine de otomatik sorular oluşturma, daha az uzman tehdit modelleyicilerine önemli bir değer sağlayarak kapsam içindeki sistemleri anlamalarını sağlayabilir.

Bugün ne yapabilirsin?

Soru sormak için yapılandırılmış bir yaklaşım benimseyin. Örneğin ekibimiz, Microsoft STRIDE'ı referans olarak benimseyerek iyi sonuçlar elde etti. Aşağıdaki gibi çözüm sorularının her bir bileşenini isteyerek bunu yapabilirsiniz:

• Kimlik sahtekarlığına: Bileşen, kullandığı hizmetler ve kaynaklar için nasıl kimlik doğrulaması yapar?

• Kurcalama: Bileşen aldığı iletileri doğrular mı? Doğrulama gevşek mi yoksa katı mı?

• İnkar: Bileşen bir denetim günlüğündeki etkileşimleri günlüğe kaydederek mi?

• Bilgilerin Açığa Çıkması: Gelen ve giden trafik bileşeni şifreleniyor mu? Hangi protokollere ve algoritmalara izin verilir?

• Hizmet Reddi: Bileşen yüksek kullanılabilirlik içinde yapılandırıldı mı? DDoS saldırılarına karşı korunuyor mu?

• Ayrıcalık Yükseltme: Kullanıcılara gereken en düşük ayrıcalıklar atanıyor mu? Çözüm, yüksek ayrıcalıklı kullanıcılar için normal kullanıcılara hedeflenen kodu bu kodla karıştırır mı?

Bunun gibi teknikler öğretilebilir ve deneyimle geliştirilebilir. Bu nedenle, öğrenmeleri toplamak ve bunları kuruluşa yaymak için tasarlanmış bir Sürekli Öğrenme yaklaşımı uygulamak önemlidir.

Yatırım getirisi üzerindeki etkisi

Sonuç olarak, tehdit modelleme deneyiminin verimliliğini, kalitesini ve sonuçta yatırım getirisini artırmak için birçok fikri tanımlamak mümkündür. Ancak bu çabanın, uygulamanın sürekli iyileştirilmesine yönlendirilmesi gereken devam eden bir süreç olarak kabul edilmesi gerekir.

Sonuçlar

Tehdit modelleme, kuruluşunuzun güvenliğini geliştirmek için mükemmel bir metodolojidir. Doğru şekilde yapılırsa, çok makul bir maliyet için değer sağlayabilir. Aşağıdakiler dahil olmak üzere modern çözümlerin güvenliğini sağlamak için tehdit modellemesinin değerini geliştirmek için gerekli olabilecek çeşitli teknikleri zaten belirledik:

• Tehdit modelini DevOps uygulamanızla uyumlu hale getirme

  • Risk azaltmalara odaklanma

  • Azaltmaları kullanıcı hikayeleri ile bağlama

  • Tehdit modeli ile kapsam arasındaki tutarsızlıkları vurgulama

  • Güvenlik için daha kapsamlı bir izleme ve denetim sağlamak için tehdit Modelini kullanın

• Tehdit modellerinin oluşturulmasını basitleştirme ve sonuçların tutarlılığını artırma

  • Güvenlik Şampiyonlarına Güven

  • Tehditlerin tanımlanmasını ve risk azaltmalarını otomatikleştirmek için bilgi bankası'leri benimseme

  • Daha iyi bilgi bankası oluşturma

  • Otomasyon tarafından desteklenen bir soru çerçevesi sağlama

Umalım ki, bazıları tercih edilen tehdit modelleme aracınızda zaten bulunabilir. Diğerleri gelecekte dahil edilecek. Tehdit modellemesi için yatırım getirisini en üst düzeye çıkarmanın henüz sahip olmadığımız yanıtları gerektiren uzun vadeli bir çaba olduğunu biliyoruz. Bazı soruların hala bilinmediğini de biliyoruz. Bu makale, düşünmek için biraz yiyecek sağlamalıdır ve umarım tehdit modellemesini geliştirme konusunda size yardımcı olabilir. Sizin ve bizim için bir deniz feneri olmasını ve gelecek yıllar için çabalarımızı yönlendirmenin yararlı olacağını umuyoruz.