Yazılımın güvenlik açığı üzerindeki bir saldırının / aracının Yaşam Döngüsü'nün benzersiz yönleri nelerdir?

Yerel üniversitemde yaklaşık 20 öğrenciden oluşan küçük bir öğrenci bilgi işlem kulübü var. Kulübün mobil geliştirme, robotik, oyun geliştirme ve hack / güvenlik gibi belirli odak alanlarına sahip birkaç küçük takımı var.

Kullanıcı öyküleri, görevlerin karmaşıklığını tahmin etme ve sürüm kontrolü ve otomatik yapımlar / testler için sürekli entegrasyon gibi birkaç takıma bazı çevik geliştirme kavramlarını tanıtıyorum.

Şelale, spiral, RUP, çevik vb.Gibi bazı temel geliştirme yaşam döngülerine aşinayım, ancak güvenliği kesmek / ihlal etmek için bir yazılım geliştirme yaşam döngüsü gibi bir şey olup olmadığını merak ediyorum. Kesinlikle, bilgisayar korsanları bilgisayar kodu yazıyor, ama bu kodun yaşam döngüsü nedir? Bir kez ihlal bulunduğunda ve yamalı olduğu için, bu ihlalden yararlanan kod işe yaramaz olduğu için bakımla çok ilgili olacaklarını sanmıyorum.

Yaşam döngüsünün şöyle olacağını hayal ediyorum:

1. Güvenlikteki boşluğu bulun
2. Güvenlikteki boşluğu kullanın
3. Yük taşıma kapasitesi
4. Yükü kullanın

Ürünün amacı güvenliği ihlal etmek olduğunda yazılımın geliştirme yaşam döngüsü için ne tür farklılıklar (varsa) vardır?

Ne tür bir koddan bahsediyorsun?

Bilgisayar korsanlığı sürecinde kullanılan, nmap , sqlmap , Nessus ve diğerleri gibi tarayıcılar da dahil olmak üzere birçok güvenlik aracı vardır . Diğer uygulamalarla aynı yazılım yaşam döngülerine sahip olduklarını hayal ediyorum.

Öte yandan, istismar kodları vardır. Çok özel bir istismar ve durumdan yararlanmak için yazılan kodlar. Bunların herhangi bir yaşam döngüsüne ihtiyacı olduğundan şüpheliyim. Bununla birlikte, birçok istismar kodu Metasploit gibi daha büyük bir istismar çerçevesiyle de bütünleştirilmiştir .

@AviD ile görüştükten sonra birkaç noktaya eklemek istiyorum.

Belirli durumlar için çok farklı olacaktır.

Sıfır gün düzeltme eki uygulanmadan önce pencereyi dikkate almak için bazı istismar kodları kullanıma sokulabilir. Başka nedenlerle de kod kaldırılabilir. Bakınız: SUÇ - BEAST halefi nasıl yenilir? bunun harika bir örneği. Bir kişi amacını çabucak kanıtlamak için bir parça PoC kodu yazdı. Bu tür kodlar için hiçbir yazılım yaşam döngüsü metodolojisi dikkate alınmaz.

Stuxnet veya FLAME gibi silahlı kötü amaçlı yazılımlar muhtemelen yapar. Metasploit gibi paket yazılımlar yapmak.

Yani doğru cevap ... duruma göre değişir.

Ürünün amacına bağlı olarak neden özellikle farklı bir geliştirme yaşam döngüsü olması gerektiğini anlamıyorum.

Güvenliği ihlal etmek için geliştirilen yazılımlar, diğer herhangi bir yazılım türü kadar uzun ömürlü olabilir ve aynı miktarda bakım ve çalışma gerektirir.

Bu tür yazılımların farklı yaratıcıları, ihtiyaçlarına bağlı olarak farklı yaşam döngüleri benimseyecektir.

Belirttiğiniz geliştirme modelleri tam da budur - geliştirme modelleri. Mühendislik geliştirme yaparken - gereksinimleriniz olduğunda, sistem mimarileri veya bileşen tasarımları oluşturmanız veya değiştirmeniz gerektiğinde, bir ürün ve ilgili testler oluşturmanız veya değiştirmeniz gerektiğinde ve bir müşteriye bıraktığınızda son derece kullanışlıdırlar.

Bu modellerin, soruları yanıtlamaya veya bir sistem (veya özel durumunuzdaki sistemin güvenlik zayıflıkları) hakkında daha fazla bilgi edinmeye çalıştığınız daha araştırmaya yönelik projelere doğrudan uygulanabileceğinden emin değilim.

Çevik yöntemler ve Spiral model gibi yinelemeli / artımlı modellerin bir temel oluşturmak için en yararlı olacağından şüphelenirim. Her bir yinelemede, soruları yanıtlamaya veya üzerinde çalışmak için daha fazla parametre tanımlamaya çalışabilirsiniz; bunlar herhangi bir kod yazmayı da içerebilir veya içermeyebilir. Belki de çeşitli bilimsel araştırma yöntemleri de ilginç bir temel sağlayabilir.

Hacking son zamanlarda para kazanmak amacıyla uzmanlar arasındaki işbirliğine doğru "lulz için" yapan veya ün kazanmak için tek bir bilgisayar korsanından uzakta güçlü bir profesyonelleşme gördü. Sonuç, belirli yazılım zayıflıklarının eklentiler gibi kolayca entegre edilebildiği Blackhole istismar kiti gibi tam teşekküllü ticari "hack kitleri" olmuştur . Bu tür ürünlerin tıpkı diğer yazılım ürünleri gibi geliştirildiğini varsayabilirim.

Görünüşe göre sıfır gün istismarları için gelişmekte olan bir pazar var .

Life-Cyle hiçbir zaman koda bağımlı değildir. Oldukça aşağıdaki gibi diğer faktörlere bağlıdır:

1. zaman
2. Bütçe
3. Müşterinin Niteliği
4. Ürünün Niteliği

Senaryonuzda, Agile Life Cyle metodolojisi en yararlı olacaktır. Nedeni, geliştirme sırasında müşterinizi dahil etmeniz ve ürününüzün kabul edilebilir kalite parametrelerini doğrulamanız gerektiğidir. Çevik Metodolojisi Eğer gayet müşterinizin geri bildirim almanın, daha sonra yavaş yavaş çalışan yoluyla Hacking Yazılım geliştirmeye yardımcı olacağını artan bazında.