Siber güvenlik ekipleri ile geliştiriciler arasında her zaman doğal bir gerilim olacaktır. Sonuçta “geliştirmek” geliştiricinin rolüdür. Kuruluşu ileriye taşımaya yardımcı olacak yeni uygulamalar ve özellikler oluşturmak ve sunmak istiyorlar ve bunun için para alıyorlar. Bununla birlikte, yeni yazılım dağıtıldığında, veri ihlali yaşanması veya savunmasız yazılım nedeniyle iş hizmetlerinin kullanılabilirliğinin kaybedilmesi gibi kötü olayların yaşanmamasını sağlamak güvenliğin görevidir.
Bu dinamik, iki rol arasında doğal bir gerginlik yaratsa da benim deneyimim, bunun bu şekilde olması gerekmediği yönünde. İki grup arasındaki anlayışı artırmak için uygun adımlar atılırsa hayır.
Ne yazık ki pek çok kuruluş uygun adımları atmıyor ve bu da geliştirme ekibinin güvenlik ekiplerini aşılması gereken bir “barika”, yani aşılması gereken bir engel olarak görmesine yol açıyor. Benzer şekilde, güvenlik ekibinin geliştirme ekiplerine yönelik düşmanlığı, geliştiricilerin “güvenliği yeterince ciddiye almadığını” gördükçe artıyor.
Geliştiriciler ve güvenlik ekipleri arasındaki ilişkinin nasıl geliştirilebileceği hakkında çok şey yazıldı. Ve son on yılda bu gerilimi hafifletmeyi amaçlayan DevOps uygulamalarının hızla yaygınlaştığına tanık olduk. Bana göre bir miktar başarı elde edildi ama yeterli değil. Bu nedenle, büyük bir telekomünikasyon şirketinin uygulama güvenlik ekibini yöneterek geliştiriciler ve güvenlik arasındaki gerilimi dengeleme konusunda bir miktar başarı elde ederek öğrendiklerimi paylaşmaya karar verdim.
Bütün organizasyonlar farklıdır. Bazı geliştirme ve güvenlik ekipleri öncelikle şirket içinde çalışırken, diğerleri büyük ölçüde uzaktan çalışıyor ve diğerleri hala her ikisinin bir karışımı. Bazı ekiplerde çok deneyimli uygulama güvenliği uzmanları bulunurken bazılarında yoktur. Çalıştığım ekip çoğunlukla sahadaydı. Ve bizim için işe yarayan şey herkes için işe yaramayabilir. Yine de bu anahtarları bir araya getirenlerin, güvenlik ve geliştirme ekipleri arasındaki kritik ilişkiyi geliştireceklerine inanıyorum.
Bir numaralı anahtar: Eğitimi vurgulayın
Uygulama güvenliği, uygulama güvenliği ekibi liderliğindeki her yeni geliştiriciye, geliştiricilerin saygı duyacağı yeterli geliştirme deneyimine sahip bir kişiyle uygulama güvenliği eğitimi sağladı. Geliştirme deneyimi olan AppSec uzmanları, güvenlik ekiplerinin ideal olmayan yollarla iletişim kurduğunda geliştiricilerin karşılaştığı sorunları ve hayal kırıklıklarını anlıyor.
Bu aynı zamanda genel olarak AppSec ekibi için de geçerlidir. Yalnızca geliştirmede hiç çalışmamış güvenlik kişilerinden oluşan bir AppSec ekibiniz olduğunda, bu durum muhtemelen iki grup arasında sürtüşmeye neden olacaktır çünkü muhtemelen her zaman iki dil konuşacaklardır. Ve hiçbir grup diğer takımın karşılaştığı sorunları ve zorlukları anlamıyor. Önceki geliştiricileri içeren bir AppSec ekibiniz olduğunda ekipler arasında çok farklı bir ilişki göreceksiniz.
İkinci anahtar: AppSec eğitiminde, geliştirme ve güvenlik ekiplerinin şirket içinde bulduğu gerçek dünyadan örnekleri kullanın
Tüm AppSec eğitimlerinde eğitmenler, enjeksiyon kusurları, siteler arası komut dosyası oluşturma ve zayıf erişim kontrolleri gibi güvenlik açıklarının koda nasıl dahil edildiğini tartışacaktır. Ayrıca bu güvenlik açıklarının uygulama ve veri güvenliği açısından ne anlama geldiğini açıklayacaklar. Bu sunum doğru olsa da aynı zamanda oldukça yavan.
İşleri biraz daha renklendirmek ve dikkat çekmek için, güvenlik ekibinin şirket içinde güvenlik kontrolleri yaparken bulduğu uygulama açıklarını ekleyerek başarıyı yakaladık. Bu, AppSec eğitimini kişiselleştirmek anlamına gelmez. Bireysel geliştiricilere kesinlikle çağrılmamalı.
Bu konuları birlikte öğrenmekle ilgilidir. Bu, geliştiricilerin güvenliğe değil, iş mantığına ve oluşturdukları uygulamanın işleyişine odaklandıklarını göstermekle ilgilidir. Bazen güvenlik akıllarının gerisinde kalır ve bu anlaşılabilir bir durumdur. Ancak şirket içinde bulunan ve kuruluşun güvenliğini etkileyen yaygın güvenlik açıklarından birkaç örnek alarak onların dikkatini ve ilgisini çekeceksiniz.
Üç numaralı anahtar: Güvenlik açığı keşfi damgasını kaldırın
Sunumumuzun başında, kişinin kodunda güvenlik açıklarının bulunduğu damgasını ortadan kaldırmaya yardımcı olan bir slayt sunduk. Duyurunun ardındaki ismi açıklamayacağım ancak slaytta tanınmış bir güvenlik profesyoneli yer alıyordu. Açık kaynak olarak yayınlanan güvenlik yazılımı geliştiriyor. Kendi yarattığı ve açık kaynak olarak yayınlanan yazılımda bir güvenlik açığı vardı. Ve bu çok kritik bir güvenlik açığıydı.
Eğer bu kişi kritik güvenlik açıklarına sahip bir yazılım yayınlayabilirse, her geliştirici aynı hataları yapabilir. Uygulama güvenliği konusunda çok deneyimli biri için bile kodda güvenlik kusurlarının olmasının normal olduğunu onlara göstermek için bu slaydı sunduk. Önemli olan bunları bulup ortadan kaldırmaktır.
Dördüncü anahtar: Güvenlik açıklarının gerçek etkisini öğretin
Ayrıca yalnızca şirket içinde ortaya çıkardığımız güvenlik açıklarını da sunmadık. Ayrıca güvenlik açıklarından da yararlandık. Geliştiricilere bu güvenlik açığından nasıl yararlanılabileceğini ve bir saldırganın bu güvenlik açığıyla neler yapabileceğini göstermeliyiz.
İlk eğitim oturumlarından birinde bir geliştirici, siteler arası komut dosyası çalıştırma hakkında yorum yaptı ve bu tür güvenlik açıklarının o kadar da zararlı olamayacağını iddia etti. Onlara, bir saldırganın siteler arası komut dosyası çalıştırma saldırısıyla kurbanın kimliğine bürünme, hassas verilere erişme, oturum ele geçirme, keylogging, kötü amaçlı yazılım yayma ve daha fazlası gibi neler yapabileceğini gösterdik.
Bu çok göz açıcıydı. Ve aslında bunun AppSec ile ilgili bir sorun olduğunu düşünüyorum. Geliştiriciler güvenlik açıklarının etkisini anlamadıklarında, onları düzeltme veya uygulamalarında bunlardan kaçınma konusunda motive olmazlar. Etkilerini anlamadıklarında riskleri görmezden gelmek insan doğasıdır. Bu nedenle gerçek riski göstermenin bu kadar büyük etkisi olabilir. Bunu eğitimimize eklemek, geliştiricilerle ilişkimizi büyük ölçüde geliştirmemize yardımcı oldu.
Beş numaralı anahtar: Güvenlik ekiplerinin neyin makul olduğunu anlaması gerekiyor
Bu iki ekip arasındaki sürtüşmenin genellikle güvenlik ekibinin tamamlanması mantıksız olan görevler istemesinden kaynaklandığını keşfettim. Eğitim sırasında geliştirme ekibine güvenlik ekibiyle en iyi şekilde nasıl çalışabileceklerini öğretmek çok önemlidir, orası kesin. Ancak güvenlik ekibinin taleplerinin makul olduğundan emin olması da aynı derecede önemlidir.
Bazen, güvenlik ekibinin gerçek sorun olmayan şeylerin düzeltilmesini istemesi nedeniyle mantıksız talepler olabilir. Bu durum, bir uygulama güvenlik açığı tarayıcısını çalıştırdıklarında ve tarayıcının var olmayan bir güvenlik açığını bildirdiğinde veya gerçek bir riski ortaya çıkardığında meydana gelir. Güvenlik ekibi bunu körü körüne düzeltmeleri için geliştiricilere aktardı. Bunu sık sık yaptığınızda geliştiriciler sinirlenecek ve sizi görmezden gelecektir.
Ayrıca güvenlik ekiplerinin, güvenlik açıklarını gidermek için yeterli süre ve karmaşık güvenlik açıklarını düzeltmek için daha fazla zaman sağlamak gibi beklentileri konusunda makul olmaları gerekir.
Altıncı anahtar: Geliştiricilere güç veren doğru araçları kullanın
Doğru değerlendirme araçlarının seçildiğinden emin olmak çok önemlidir çünkü bu tür araçlar belirlenen sorunlara ilişkin net açıklamalar sağlar, uygun önem düzeyleri atar ve güvenlik açıklarının çözümüne yönelik rehberlik sunar.
Bu, geliştiricilerin mevcut sorunları nasıl çözeceklerini anlamalarına yardımcı olacaktır. Geliştiricilerin kullanması için tasarlanmış araçlar sağlamak daha da iyidir çünkü bu, geliştiricilerin bağımsız çalışmasına olanak tanır.
Güvenlik ve geliştirme ekipleri arasındaki gerilimler her zaman bir dereceye kadar var olacak ve kuruluşların bu gerilimleri azaltmak için sürekli çaba harcaması gerekecek olsa da, birkaç basit adım atarak bu ekipler arasındaki anlayışı ve empatiyi geliştirmenin uzun bir yol kat ettiğini gördük. bu ilişkileri geliştirmeye yöneliktir.