Jakie są unikalne aspekty cyklu życia oprogramowania ataku / narzędzia w przypadku luki w zabezpieczeniach oprogramowania?

Na moim lokalnym uniwersytecie działa niewielki studencki klub komputerowy złożony z około 20 studentów. W klubie działa kilka małych zespołów o określonych obszarach, takich jak tworzenie aplikacji mobilnych, robotyka, tworzenie gier oraz hakowanie / bezpieczeństwo.

Przedstawiam kilka podstawowych koncepcji zwinnego programowania w kilku zespołach, takich jak historie użytkowników, szacowanie złożoności zadań oraz ciągła integracja do kontroli wersji oraz automatycznych kompilacji / testowania.

Znam kilka podstawowych cykli rozwojowych, takich jak wodospad, spirala, RUP, zwinny itp., Zastanawiam się jednak, czy istnieje coś takiego jak cykl rozwojowy oprogramowania służący do hakowania / naruszania bezpieczeństwa. Z pewnością hakerzy piszą kod komputerowy, ale jaki jest cykl życia tego kodu? Nie sądzę, aby zbytnio zajmowali się konserwacją, ponieważ po wykryciu i załataniu naruszenia kod, który wykorzystał to naruszenie, jest bezużyteczny.

Wyobrażam sobie, że cykl życia byłby mniej więcej taki:

1. Znajdź lukę w bezpieczeństwie
2. Wykorzystaj lukę w bezpieczeństwie
3. Zamów ładunek
4. Wykorzystaj ładowność

Jakie różnice (jeśli występują) występują w cyklu rozwojowym oprogramowania, gdy celem produktu jest naruszenie bezpieczeństwa?

O jakim kodzie mówisz?

Istnieje wiele narzędzi bezpieczeństwa używanych w procesie hakowania, w tym skanery, takie jak nmap , sqlmap , Nessus i wiele innych. Wyobrażam sobie, że mają taki sam cykl życia oprogramowania, jak każda inna aplikacja.

Z drugiej strony istnieją kody exploitów. Kody napisane w celu wykorzystania bardzo specyficznego exploita i sytuacji. Wątpię, czy w ogóle potrzebują one cyklu życia. Jednak wiele kodów exploitów jest również zintegrowanych z większymi ramami exploitów, takimi jak Metasploit .

Po dyskusji z @AviD chciałbym dodać kilka punktów.

Będzie to zupełnie inne w określonych sytuacjach.

Niektóre kody exploitów mogą zostać wyrzucone, aby uwzględnić okno przed załataniem zerowego dnia. Kod może zostać wyrzucony również z innych powodów. Zobacz: PRZESTĘPSTWO - Jak pokonać następcę BEAST? na świetny przykład tego. Osoba napisała kawałek kodu PoC, aby szybko udowodnić swoją rację. W przypadku takich kodów nie bierze się pod uwagę metodologii cyklu życia oprogramowania.

Prawdopodobnie robią to złośliwe oprogramowanie, takie jak stuxnet lub FLAME. Oprogramowanie spakowane jak Metasploit.

Tak więc właściwa odpowiedź brzmi ... to zależy.

Nie rozumiem, dlaczego powinien istnieć jakikolwiek inny cykl rozwojowy w zależności od przeznaczenia produktu.

Oprogramowanie opracowane z myślą o naruszeniu bezpieczeństwa może mieć tyle samo żywotności co każdy inny rodzaj oprogramowania i wymagać będzie takiej samej ilości konserwacji i pracy.

Różni twórcy takiego oprogramowania będą przyjmować różne cykle życia w zależności od ich potrzeb.

Modele programistyczne, które określisz, to po prostu - modele programistyczne. Są one niezwykle przydatne, gdy wykonujesz prace inżynieryjne - gdy masz wymagania, gdy musisz tworzyć lub modyfikować architekturę systemu lub projekty komponentów, kiedy musisz zbudować lub zmodyfikować produkt i powiązane testy, a także kiedy wydasz klientowi.

Nie jestem pewien, czy modele te można bezpośrednio zastosować do projektów bardziej ukierunkowanych na badania, w których próbujesz odpowiedzieć na pytania lub dowiedzieć się więcej na temat systemu (lub słabości zabezpieczeń systemu, w konkretnym przypadku).

Podejrzewam, że modele iteracyjne / przyrostowe, takie jak metody zwinne i model spiralny, byłyby najbardziej przydatne do stworzenia podstawy. W każdej iteracji możesz pracować nad odpowiedzią na pytania lub zdefiniowaniem większej liczby parametrów do pracy, które mogą, ale nie muszą obejmować pisania dowolnego kodu. Być może różne metody badań naukowych mogą również stanowić interesujący fundament.

Hacking ostatnio doświadczył silnej profesjonalizacji, od pojedynczych hakerów robiąc to „dla lulz” lub w celu zdobycia sławy, w kierunku współpracy między specjalistami w celu zarabiania pieniędzy. W rezultacie powstały pełnoprawne komercyjne „zestawy hakerskie”, takie jak zestaw exploitów Blackhole, w którym można łatwo zintegrować określone słabości oprogramowania, takie jak wtyczki. Zakładam, że takie produkty są opracowywane prawie dokładnie tak, jak inne programy.

Najwyraźniej istnieje również rozwijający się rynek exploitów zero-day .

Life-Cyle nigdy nie jest zależny od kodu. Jest raczej zależny od innych czynników, takich jak:

1. Czas
2. Budżet
3. Charakter klienta
4. Charakter produktu

W twoim scenariuszu najbardziej przydatna byłaby metodologia Agile Life Cyle . Powodem jest to, że musisz zaangażować klienta podczas projektowania i zweryfikować dopuszczalne parametry jakościowe swojego produktu. Metodologia zwinna pomogłaby Ci ogromnie ulepszyć swoje oprogramowanie hakerskie, zbierając opinie klientów, a następnie stopniowo pracując stopniowo .