Güvenlik firmalarındaki programcılar ne yapıyor?


10

Bir istemci sistemlerinin güvenliği konusunda danışmanlık yapan güvenlik firmalarını duydum. Bu alanda tanıdığım herkes ağ mühendisidir, ancak programcıların güvenliğe de dahil olduğunu biliyorum. Denetim / danışmanlık yapan güvenlik programcıları gerçekte ne yapar? Kelimenin tam anlamıyla insanların eski sistemlerindeki her güvenlik açığını bulmak için kod tabanından mı geçiyorlar? Her zaman yaptıklarının bu olduğunu varsaydım, ancak bu son derece güvenilir olmayacak ve sahte bir güvenlik duygusu sağlamaktan daha fazlasını yapmayacak gibi görünüyor. Not: Şifreleme algoritmaları veya bunun gibi bir şey yazan programcılardan bahsetmiyorum, sadece yazılım güvenlik denetimleri / danışmanlığıyla ilgilenenler.


1
Daha fazla güvenlik görevlisi kitlesi için security.stackexchange.com adresine göz atmaktan çekinmeyin!
Rory Alsop

1
^ ne dedi, ikimiz de orada pro moderatörleri vardır.

Yanıtlar:


12

Açıkçası, kod tabanınızdan geçmemeye çalışıyoruz, bunu bizim için yapmak için araçlar yazmaya çalışıyoruz.

İlk olarak, teori. Güvenlik bir yazılım sisteminin bir gereğidir, bu nedenle diğer gereksinimler (işlevsellik, kullanılabilirlik, erişilebilirlik, performans vb.) Gibi, gereksinimlerin bir araya getirilmesinden dağıtım ve bakıma kadar yazılım mühendisliği iş akışının her aşamasında dikkate alınmalıdır. Aslında, bu mümkündür ve yazılım proje ekiplerinin bunu yapmasına yardımcı olmak için rehberlik vardır. Çoğunlukla iOS geliştiricileriyle çalışmama rağmen, "güvenli geliştirme yaşam döngüsü" ile ilgili en sevdiğim açıklama Microsoft Press'ten .

Bu modelde, uygulama güvenliği kullanıcılarımızdan gereksinimleri sağlamaya çalışırken başlar. Güvenlik ve gizlilik endişelerini keşfetmemiz gerekiyor, bu kolay değil çünkü biz uzman değiliz, kullanıcı değiliz ve güvenlik gereksinimlerini anladıklarında onları ifade etmeyi zor bulabilirler. Ayrıca, dağıtım sırasında yazılımın hangi risklere maruz kalacağını ve hangi riskin kabul edilebilir olduğunu da keşfetmeliyiz.

Uygulamamızı bu gereksinimleri göz önünde bulundurarak tasarlıyoruz. Kodu, bu gereksinimleri karşılamaya ve kod düzeyinde güvenlik hatalarıyla ilişkili ek risklerden kaçınmaya dikkat ederek yazıyoruz. Yazılımı, güvenlik modelimizin gerçekten yaptığımızla tutarlı olduğundan emin olmak için test ediyoruz, ardından yazılımı, şeyi tasarlarken çevre hakkında yaptığımız varsayımlara uygun bir şekilde dağıtıyoruz. Son olarak, kullanıcının yazılımı güvenlik gereksinimlerine uygun bir şekilde kullanmasına yardımcı olan ve (ve bizlerin) sunulan risklerdeki yeni değişikliklere tepki vermelerini sağlayan destek ve bakım sağlıyoruz.

Tamam, teori için çok fazla. In Uygulamada , (a teknik olmayan biçimde de olsa) çok iyi açıklanmıştır nedenlerle Geekonomics ve esas yolu yazılım şirketleri motive olmuş bunlar nedeniyle, yukarıdaki şeylerin çoğunu olmaz vardır. Bunun yerine, bunu anlıyoruz. Geliştiriciler:

  • bir sözleşme için teklif verirken, güvenlik "aldıklarını" göstermek için bir güvenlik görevlisi veya gal kiralamak.
  • yazım yazılımı.
  • 2. adımda ortaya çıkan birçok sorunu gidererek, sürümü yayınlamadan önce yazılımı doğrulamak için bir güvenlik görevlisi veya gal işe alın.
  • dağıtımdan sonra her şeyi yama.

Yani çoğu uygulama güvenliği insanının gerçekten yaptığı şey, sizin de dediğiniz gibi, hataları bulmak. Bu gerçekten yüceltilmiş bir kod inceleme ama bu inceleme arıyor hatalar tür uzman olan insanlar tarafından yürütülen son derece odaklanmış bir kod inceleme, bu yüzden hala bunu yaparken dış yardım alma değeri vardır. Bu genel bir kural kuralı, elbette: her zaman bir şeyi yapmakla ilgilenmeyenleri test etmek için başka birini alın.

Yukarıdakileri doğru olarak kabul edersek, o zaman satın alma kararları veren insanların "yetenekli güvenlik görevlisi" ile "çok fazla hata bulur" eşitlemesi muhtemeldir. Bilgisayarları kendileri için işi yapanlar, olmayanlardan daha fazla hata bulacaklar, bu yüzden elbette büyük ölçüde statik analiz araçlarına güveniyorlar ve belirli istemciler için belirli sorunları kodlamaktan daha fazla zaman harcayacaklar. Daha sonra, uygulama güvenliği çalışanlarının kodu okumak için kod yazmak yerine araç yazma olasılıklarının daha yüksek olduğu sonucuna vardık.

** Uyarı: geriye kalan kişisel görüş ve spekülasyon **

Gerçeklik bozuldu. Yazılım güvenliği teorisinin, bir yazılım sistemine güvenme riskini tanımlamak ve buna yanıt vermekle ilgili olduğunu fark edeceksiniz, uygulama ise mümkün olduğunca çok hata bulmakla ilgiliydi. Elbette, bu yine de riski azaltacaktır, ancak sadece bir yan etki olarak. Oyunun amacı oyunu "kazanmaktan" daha az önemli hale geldi, bu yüzden kurallar kazanmayı kolaylaştırmak için değiştirildi.

Bir yazılım geliştiricisi olarak bu konuda ne yapabilirsiniz? Oyunu orijinal kurallarına göre oynayın. Güvenliğinizin önemini anlayan ve bejeezus'u onlardan eğiten ekibinizde bir ekip bulun (tercihen bir yüklenici yerine ekibinizde, hızlı bir kazanç yerine uzun vadeli sonuçlar elde etmek için motive edilir). Bu kişiye, cevabımın başında tanımlanan uçtan uca güvenliği sağlamada ekibi yönlendirmek için sorumluluk verin.

Ayrıca, o kişiye takip etme yetkisi verin . Bir tasarım güvenlik gereksinimlerini ifade etmiyorsa gözden geçirilmelidir. Uygulama güvenlik gereksinimlerini karşılamıyorsa, serbest bırakılmamalıdır . Güvenlik görevliniz karar çağırabilir, ancak bu karar üzerinde hareket etmesine izin verilmelidir. Bunun, "OMFG güvenliği en önemli şey" diyen güvenlik görevlisi gibi göründüğünün farkındayım, ama demek istediğim bu değil. Ürününüz de işlevsellik, kullanılabilirlik veya performans gereksinimlerini karşılamıyorsa, bu şeyi de serbest bırakmamalısınız.

Bunu neden yapmak istiyorsun? Daha ucuz olmalı: Hepimiz kusurları daha pahalı hale getirdiğiniz Kod Komple tablosunu gördük (ve muhtemelen ucuz bir +10 rep için alıntıladık), değil mi? Güvenlik kusurları da kusurlardır. Ben oyunun gerçek dünya kuralları, çoğu bakım gereksinimi sabit sorunları. Bu ucuz mu?

Tamam, şimdi ne olabilir ben kiralık bir güvenlik tabanca bu konuda ne kadar? Değiştirilmiş kurallara göre oynamayı reddedebileceğim ortaya çıkıyor. Geliştiricilere her şeyin riski azaltmakla ilgili olduğunu, bunun her aşamada yapılabileceğini söyleyebilirim ve sonra bunu yapmalarına yardımcı olabilirim.


Pozisyonunuzdaki kişi için, tartışmaya daha fazlasını sunamayacağınıza şaşırdım. Söylediklerini duymakla çok ilgilenirim.
Steven Evers

Haklısın, cevabı yazdığımda yoruldum (jet lag). Biraz doldurmaya çalışacağım.

@snorfus İyi bir cevap vermediğim için özür dilemeliyim. Gerçekten üzgünüm.

@Graham Lee: Bizden gizlenmiş harika bir cevabınız olduğundan şüphelendim :) Düzenlemeleriniz bunu kanıtladı; teşekkür ederim!
Steven Evers

@snorfus Göndermeden önce gerçekten düşünmeliyim. Ve eğer düşünecek durumda değilsem,

5

Küçük ve son derece büyük uygulamalara, ortamlara, sistemlere vb. Karşı 15 yıllık güvenlik güvencesi programları çalıştırdığından her şeyin bir kısmı olduğunu söyleyebilirim. Takımlarımda her zaman hardcore kodlayıcı olan birkaç tane var.

Ayrıntılı düzeyde, bazıları çok derinlemesine kod incelemesine iniyor - örnek olarak şu anda multi milyon satır kod tabanı üzerinde çalışıyorum, olası sorunları daraltmak için araçlar kullanıyorum ve her birine kategorize.

(Kuşkusuz, sorunun neden bir risk oluşturmadığını açıklamak veya bana açıklamak için geliştiricilere teslim ediyorum)

Ancak bu, risk profilinin bu tür kaynak yoğun işleri yürütmek için mantıklı olduğu özel bir katılımdır.

Çok daha standart ve çok daha uygun maliyetli, kuruluşun risk profilini anlamaya ve yukarıdan aşağıya risklere odaklanmaya çalışmaktadır, örneğin:

  • Risk İştahı - işletmeye etki, tehdit modelleme
  • Yönetişim - mevzuata uygunluk, raporlama vb.
  • Politikalar - yönetişim çerçevesinin etkili olmasını sağlayacak tanımlar
  • Teknik ve insan süreçleri
  • Standartlar - her güvenlik kontrolü için tanımlar
  • Uygulama - Nasıl Yapılır

Programlama tarafı, kod inceleme ve özel penetrasyon testi ile gerçekten sadece son ikisine giriyor. Bazı kuruluşlar için çok düşük bir öneme sahiptir, örneğin, zaten kapsamlı bir şekilde gözden geçirilmiş katmanlı güvenlik denetimleriniz varsa (çeşitli şifreleme türleri, örneğin), uygulamanızı kontrol ederken, genellikle tüm denetimleri yeniden denetlemezsiniz. kodunu daha önce yapılmış gibi yapın.


2
Ben + 1d, ama dikkat "ya da bana neden sorunun bir risk oluşturmadığını açıklamak için". Geliştiriciler genellikle yaptıkları şeyi (geliştirici olarak konuşmak) değiştirmekten kaçınmak için neden bulurlar ve ayrıca müşterilerin risklerini anlamayabilirler. Sonuçta, Windows 98 ;-)

@Graham - Sen adlandırılmayacağını söyledi :-) Ve ben yeni uzun sürüm cevabınızı seviyorum! +1
Rory Alsop

oh, doğru. Bunu kasten söyledim, çünkü 98 ama üç yıl önce pencereleri adlandırmak istemedim.

1

Bitmiş projelere karşı mimari / en iyi uygulamaları belirsiz bir şekilde tartışmak ve / veya saldırı / fritzing / istisna testi paketlerini çalıştırmaktan çok daha ileri gidecek bir şeyle hiç karşılaşmadım.

Neredeyse tüm durumlarda, saldırı vektörleri tarafından hangi araçları kullandıklarını ve denetimden birinin mevcut bir sistemden geçtikten sonra saldırının nasıl yapıldığını bile söyleyebilirim.

Aslında kodu incelemek ve bazı inceleme / beyaz kutu testleri yapmak için zaman ayıran birkaç tane olduğunu hayal ediyorum, ancak henüz gerçek hayatta bunlarla karşılaşmadım.


sürekli çalıştığınız şirket gibi görünüyor ve iyi bir oyun konuşan ama gerçekten anlamayan hack'leri alıyor. Kendim ve buradaki diğer yanıtlayıcıların yanı sıra, doğru yapan birçok kişi ile çalıştım ve eğittim. Kuşkusuz, muhtemelen seninle daha fazla tanıştım ...
AviD

@avid Olumsuz demek istemedim. En iyi doları öderseniz, yeterince rakip firma bulabileceğinizden eminim, ancak bunu yaptığınızda bile, bir şey satın almak / uygulamak konusunda tavsiyede bulunmaktan çok daha fazla öneri alma eğilimindesiniz. İyi bir güvenlik kaydına sahip bilinen bir ürünü kullanmak sorun alanı için uygun olduğunda daha iyi bir şey değildir. OP özellikle DENETİMDEN bahsetti ve yıllık 3. taraf denetiminiz için ödediğiniz aralıkta, Rory'nin 4. puanının 2., 3. ve 1/2'sinden geçiyorsunuz.
Bill
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.