Środki dotyczące SSDLC (bezpieczny cykl życia oprogramowania)

measures ssdlc

Dowiedz się o różnych środkach bezpieczeństwa do wdrożenia w celu zapewnienia bezpiecznego SDLC lub SSDLC:

Ponieważ technologia szybko się rozwija, wzrosły również zagrożenia związane z bezpieczeństwem związane z włamaniem i kradzieżą zabezpieczonych danych. Nie ma więc wątpliwości, że rozwój technologii stawia wyzwania twórcom oprogramowania, aby zapewnić, że ich oprogramowanie jest mocne i odporne na zagrożenia i luki w zabezpieczeniach.

Oprogramowanie nie może zostać wydane, nawet jeśli działa idealnie zgodnie z zamierzoną funkcjonalnością, chyba że okaże się, że jest wysoce zabezpieczone i spełnia określone i regulowane standardy bezpieczeństwa i prywatności, szczególnie w sektorach takich jak Obrona, Finanse i Opieka zdrowotna, które obejmują dane osobowe i finansowe .

Nie można pozwolić sobie na usterkę bezpieczeństwa produktu podczas jego wdrażania, niezależnie od tego, czy jest to duża czy średnia wada. Dlatego bardzo ważna jest ochrona oprogramowania i danych przed wszelkiego rodzaju atakami, złośliwymi zagrożeniami i lukami oraz zapewnienie wiarygodności oprogramowania dla użytkownika końcowego.

W przeciwieństwie do naszego tradycyjnego tworzenia oprogramowania, testowanie w ostatniej fazie po opracowaniu całego oprogramowania nie jest bardziej skuteczne. Wdrażając koncepcje Agile, DevOps i ShiftLeft, niezbędne jest przeprowadzanie testów na wczesnym etapie, jak również na każdym etapie cyklu życia aplikacji.

Mimo to, bezpieczeństwa oprogramowania nie można zbudować ani nawet przetestować na ostatnim etapie, dlatego należy je budować na każdym etapie, aby zapewnić całkowite bezpieczeństwo oprogramowania.

Czego się nauczysz:

• Środki bezpieczeństwa dla SSDLC
  • # 1) Faza wymagań
  • # 2) Faza planowania
  • # 3) Faza architektury i projektowania
  • # 4) Faza rozwoju
  • # 5) Faza wdrażania
  • 6) Testowanie - faza przed wdrożeniem
• Podsumowanie tabelaryczne dla SSDLC
• Wniosek
  • rekomendowane lektury

Środki bezpieczeństwa dla SSDLC

Poniżej wymieniono różne środki związane z bezpieczeństwem, które można wdrożyć w całym cyklu życia oprogramowania, aby zapewnić bezpieczne SDLC lub SSDLC i, w miarę możliwości, defekty nie mogą zostać przeniesione do następnej fazy.

Istnieją różne analizy i oceny bezpieczeństwa, w których należy budować bezpieczeństwo w fazach SDLC.

1. Faza wymagań
2. Faza planowania
3. Faza architektury i projektowania: Ocena ryzyka bezpieczeństwa na podstawie projektu.
4. Faza rozwoju: Analiza bezpiecznego kodu, statyczna analiza kodu pod kątem bezpieczeństwa.
5. Faza implementacji: Dynamiczna analiza kodu, test bezpieczeństwa aplikacji.
6. Testowanie - faza przed wdrożeniem: Testy penetracyjne i analiza podatności.

# 1) Faza wymagań

• Przede wszystkim w celu zapewnienia, że ​​niezbędne środki bezpieczeństwa są wbudowane w oprogramowanie, Szczegółowe wymagania związane z bezpieczeństwem muszą być jasno ujęte w fazie wymagań, z wystarczającą ilością szczegółów i oczekiwanymi wynikami.
• Identyfikując typowe przypadki użycia i scenariusze biznesowe, jasny zestaw plików Przypadki użycia i scenariusze związane z bezpieczeństwem do celów weryfikacji muszą zostać zidentyfikowane w celu uchwycenia funkcji bezpieczeństwa i zaprojektowania scenariuszy testowania bezpieczeństwa.

Poniżej podano kilka przykładowych przykładów, które ilustrują jawne wymagania związane z zabezpieczeniami, które można uwzględnić.

Sec-Req-01: System musi posiadać środki uwierzytelniania na wszystkich bramach i punktach wejściowych.

Sec-Req-02: System musi zaimplementować uwierzytelnianie za pomocą bezpiecznego ekranu logowania.

Sec-Req-03: DANE OSOBOWE są szyfrowane w stanie spoczynku.

# 2) Faza planowania

Na wysokim poziomie, ale nie tylko do tych, należy zająć się następującymi kwestiami na etapie planowania.

najlepsze mobilne oprogramowanie szpiegowskie dla Androida

• Silny, Dedykowany zespół ds. Bezpieczeństwa , funkcjonujący poza PMO (biuro zarządzania projektami) zespołu programowego, w skład którego wchodzą Oficer bezpieczeństwa, architekci bezpieczeństwa, testerzy bezpieczeństwa mają być powołane do prowadzenia i zarządzania wszystkimi działaniami programu związanymi z bezpieczeństwem w sposób bezstronny. Dla każdej z tych ról zdefiniowano jasne RnR (role i obowiązki) oraz RACI.
• Każdy eskalacje, niejasności związane z kwestiami bezpieczeństwa muszą być obsługiwane przez PSO (Product Security Officer), aby zespół bezpieczeństwa działał sprawnie i pomagał w podejmowaniu właściwych decyzji.
• Solidny Strategia testowania bezpieczeństwa określenie, jak wdrożyć wymagania związane z bezpieczeństwem, jak, kiedy i co testować, jakich narzędzi należy użyć na każdym etapie.
• Włączenie programu Punkt kontaktowy dotyczący bezpieczeństwa za wszystkie dyskusje techniczne / przeglądowe związane z programem, tak aby zespół bezpieczeństwa był świadomy wszelkich zmian zachodzących w programie.

# 3) Faza architektury i projektowania

Poświęcenie większej uwagi aspektom bezpieczeństwa na wczesnym etapie fazy projektowania pomoże zapobiegać zagrożeniom bezpieczeństwa i zmniejszyć znaczne wysiłki związane ze zmianami projektu w późniejszym etapie SDLC.

Podczas projektowania oprogramowania i infrastruktury, na której oprogramowanie będzie hostowane, wszystko jest możliwe Implementacje projektów zabezpieczeń muszą być dobrze zaprojektowane przy zaangażowaniu architektów bezpieczeństwa.

Wszelkie niejasności i konflikty między funkcjonalnymi i niefunkcjonalnymi aspektami projektowania i architektury należy rozwiązywać podczas burzy mózgów z udziałem odpowiednich interesariuszy.

Na tym etapie szczegółowa ocena ryzyka bezpieczeństwa produktu, która jest czasami nazywana „Ocena statyczna” musi zostać przeprowadzone przez zespół ekspertów ds. bezpieczeństwa.

Ocena ryzyka bezpieczeństwa obejmuje przegląd programów z punktu widzenia bezpieczeństwa na wstępnym etapie projektowania / architektury w celu zidentyfikowania wad związanych z bezpieczeństwem z punktu widzenia projektowania i odpowiedniego podniesienia produktu Zagrożenia bezpieczeństwa do zespołu projektowego, aby zająć się nimi i uniknąć przejścia do kolejnej fazy.

Oceny te są przeprowadzane w oparciu o wytyczne, standardy i kontrole organizacyjne / przemysłowe dotyczące bezpieczeństwa określone w tych dokumentach. Na przykład. UXW 00320, UXW 030017

Podczas Oceny Ryzyka Bezpieczeństwa Produktu:

• Wymagania, funkcje, historie użytkowników i ich dokumenty projektowe są przeglądane na podstawie szczegółów, artefaktów udostępnionych przez zespół projektowy, Na przykład. Dokumenty projektowe (HLDD i LLDD). Oceny obejmują również dyskusje z odpowiednimi członkami zespołu projektowego w przypadku braku dokumentów lub wyjaśnienie wszelkich wątpliwości.
• Luki są identyfikowane podczas mapowania wymagań bezpieczeństwa programu w stosunku do ustalonych standardów i innych najlepszych praktyk. Czasami modele zagrożeń są również opracowywane na podstawie zidentyfikowanych luk.
• Luki te są identyfikowane jako potencjalne zagrożenia bezpieczeństwa, obejmują również sugerowanie możliwych środków zaradczych dla wdrożenia, są podnoszone i zarządzane.
• Gdy te Ograniczenia zostaną wdrożone przez zespół projektowy, są one weryfikowane pod kątem zamknięcia za pomocą odpowiednich przypadków testowych zaprojektowanych przez zespół Testów Systemowych.
• Matryca zarządzania ryzykiem, która zapewnia identyfikowalność, jest przygotowana do śledzenia tych zagrożeń. Zatwierdzenie i podpisanie z ryzykiem szczątkowym zostanie podjęte przez architekta bezpieczeństwa i PSO.

Typowe wzorce zagrożeń, które są identyfikowane na etapie projektowania, są związane z walidacją danych wejściowych, zarządzaniem audytem / dziennikiem, konfiguracjami i szyfrowaniem. Identyfikacja zagrożeń obejmuje atakowanie luk w zabezpieczeniach, takich jak słabe hasła, proste ataki brute force itp.

Typowe przeglądy obejmują zagrożenia związane z dostępem do danych osobowych, dostępem do ścieżek audytu, umieszczaniem na czarnej liście podmiotów umieszczanych na białej liście, czyszczeniem danych i czynnościami usuwania.

Przykładowe scenariusze testów obejmują:

• Wrażliwość na przepełnienie bufora: Aby upewnić się, że poprzez ręczne wymazywanie parametrów nie powinno być możliwości spowolnienia serwera i wymuszenia na nim braku odpowiedzi (odmowa usługi).
• Sanityzacja danych: Zapewnienie prawidłowego oczyszczenia danych dla każdego wejścia i wyjścia, aby osoba atakująca nie mogła wstrzyknąć i przechowywać złośliwej zawartości w systemie.

# 4) Faza rozwoju

Bezpieczna analiza kodu jest Ocena kodu statycznego metoda używana do oceny Kod bezpieczeństwa różnych funkcji oprogramowania za pomocą zautomatyzowanego narzędzia skanującego. Przykład: Ufortyfikować.

Analiza ta jest przeprowadzana przy każdym wpisaniu / kompilacji kodu w celu zeskanowania wygenerowanego kodu pod kątem zagrożeń bezpieczeństwa. Ta ocena jest zwykle wykonywana na poziomie historii użytkownika.

• Skany w trybie Fortify za pomocą wtyczek muszą być zainstalowane na maszynach Dewelopera.
• Fortify musi być zintegrowane z szablonem kompilacji.
• Wszystkie kompilacje będą codziennie przeprowadzane zautomatyzowane skanowanie.
• Wynik skanowania zostanie przeanalizowany przez zespół ds. Bezpieczeństwa pod kątem fałszywych alarmów.
• Defekty zidentyfikowane w tej ocenie są podnoszone i zarządzane aż do zamknięcia, dzięki czemu wyciek jest zminimalizowany / zerowany do następnego poziomu.

Przykładowe scenariusze testów obejmują:

• Zapewnienie, że dane wrażliwe nie są przesyłane zwykłym tekstem podczas transmisji danych.
• Aby zapewnić bezpieczną transmisję danych, zewnętrzne interfejsy API muszą być wdrożone w kanale HTTPS.

# 5) Faza wdrażania

Dynamiczna analiza kodu to nic innego jak testowanie bezpieczeństwa aplikacji, które jest również nazywane testowaniem OWASP (Open Web Application Security Project). Analiza podatności i testy penetracyjne (VAPT) należy przeprowadzić na etapie wdrażania / testowania.

Ta analiza ocenia pliki binarne i niektóre konfiguracje środowiska i dodatkowo wzmacnia kod pod kątem wymagań bezpieczeństwa.

pytania do rozmowy kwalifikacyjnej analityka ds. zapewnienia jakości

W ramach tej analizy Dynamiczne zachowanie lub funkcjonalność różnych funkcji programów jest analizowana pod kątem luk w zabezpieczeniach. Zastrzeżone przypadki użycia i scenariusze biznesowe są również wykorzystywane do przeprowadzania dynamicznej analizy kodu.

Ta czynność jest wykonywana na Kompilacje testowe przy użyciu różnych narzędzi bezpieczeństwa z podejściem automatycznym i ręcznym.

• Narzędzia HP WebInspect, Burp Suite, ZAP i SOAP UI są zwykle używane do sprawdzania luk w standardowych bazach danych luk w zabezpieczeniach ( Przykład: OWASP Top 10 )
• Ta aktywność jest jednak głównie zautomatyzowana, ze względu na pewne ograniczenia narzędzi, do selekcji fałszywych alarmów może być wymagana pewna praca ręczna.
• Najlepiej byłoby to zrobić w oddzielnym środowisku (System Testing Environment), w którym wdrażane jest oprogramowanie gotowe do testów.
• Luki w zabezpieczeniach muszą zostać podniesione i zamknięte za pomocą sugerowanych środków zaradczych.

Typowe wzorce zagrożeń zidentyfikowane podczas tej analizy są związane z walidacją danych wejściowych, nieprawidłowym uwierzytelnianiem i zarządzaniem sesjami, narażeniem na wrażliwe dane, XSS i zarządzaniem hasłami.

Przykładowe scenariusze testów obejmują:

• Zarządzanie hasłami: Aby upewnić się, że hasła nie są przechowywane w postaci zwykłego tekstu w plikach konfiguracyjnych ani w dowolnym miejscu w systemie.
• Wyciek informacji o systemie: Aby upewnić się, że informacje systemowe w żadnym momencie nie wyciekną, informacje ujawnione przez printStackTrace mogą pomóc przeciwnikowi w zaplanowaniu ataku.

6) Testowanie - faza przed wdrożeniem

Testy penetracyjne , Pen Test w skrócie i Infra VAPT (analiza podatności i testy penetracyjne) , to kompleksowy test całościowy z pełne rozwiązanie i konfiguracje (łącznie z siecią), najlepiej wykonaną na przedprodukcyjnym lub produkcyjnym środowisku.

Jest to wykonywane głównie w celu zidentyfikowania luk w zabezpieczeniach bazy danych i luk w zabezpieczeniach serwera, a także wszelkich innych luk w zabezpieczeniach. To ostatni etap testów bezpieczeństwa, które zostaną przeprowadzone. Dlatego obejmuje to również weryfikację wcześniej zgłoszonych usterek i zagrożeń.

• Narzędzia takie jak Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP, które są dostępne na rynku, służą do przeprowadzania testów pióra.
• Skanowanie aplikacji internetowych przy użyciu zautomatyzowanych narzędzi i eksploatacji w celu dalszej weryfikacji odbywa się podczas tych testów. Testowanie ma na celu symulację zachowania prawdziwego napastnika i dlatego może obejmować również kilka testów negatywnych.
• Podatność infrastruktury ocena obejmuje skanowanie, analizę i przegląd konfiguracji bezpieczeństwa infrastruktury (sieci, systemów i serwerów) w celu zidentyfikowania luk i sprawdzenia odporności na ataki ukierunkowane.
• Odbywa się to w środowisku przedprodukcyjnym lub podobnym do produkcji, gdzie oprogramowanie gotowe do wdrożenia jest testowane, a tym samym symuluje środowisko czasu rzeczywistego.
• Luki są identyfikowane zarówno przy użyciu skanerów, jak i technik ręcznych, aby wyeliminować fałszywe alarmy. Ponadto podczas testów ręcznych zostaną przeprowadzone scenariusze biznesowe w czasie rzeczywistym.
• Zostanie sporządzony raport końcowy z całej analizy bezpieczeństwa przeprowadzanej dla całego programu, podkreślający status pozycji wysokiego ryzyka, jeśli takie istnieją.

Przykładowe scenariusze testów obejmują:

• Aby zapewnić, że podatne metody HTTP nie są włączone.
• Aby zapewnić, że poufne informacje innych użytkowników nie będą widoczne w postaci zwykłego tekstu w sieci.
• Aby zapewnić walidację, zaimplementowano przesyłanie plików, aby uniknąć przesyłania złośliwego pliku.

Podsumowanie tabelaryczne dla SSDLC

Poniższa tabela podsumowuje różne aspekty analizy bezpieczeństwa, które zostały wyjaśnione powyżej.

Wniosek

W związku z tym, dzięki wdrożeniu wszystkich tych aspektów związanych z bezpieczeństwem, zintegrowanych na różnych etapach SDLC, pomaga organizacji zidentyfikować defekty bezpieczeństwa na wczesnym etapie cyklu i umożliwia organizacji wdrożenie odpowiednich środków zaradczych, unikając w ten sposób Wady bezpieczeństwa wysokiego ryzyka w systemie na żywo.

Z badania wynika również, że większość defektów bezpieczeństwa jest wywoływana w oprogramowaniu na etapie jego rozwoju, tj Faza kodowania , gdzie kodowanie nie zajęło w wystarczającym stopniu wszystkich aspektów bezpieczeństwa, z jakichkolwiek powodów.

W idealnym przypadku żaden programista nie chciałby napisać złego kodu, który zagraża bezpieczeństwu. Dlatego, aby pomóc programistom napisać Bezpieczne oprogramowanie, omawiamy nadchodzący samouczek Najlepsze praktyki i wytyczne dotyczące kodowania dla programistów, aby zapewnić lepsze bezpieczeństwo oprogramowania.

Mamy nadzieję, że ten samouczek dotyczący Secure SDLC lub SSDLC był pomocny !!

rekomendowane lektury

• Fazy, metodologie, proces i modele SDLC (cyklu życia oprogramowania)
• 10 najlepszych narzędzi do testowania bezpieczeństwa aplikacji mobilnych w 2021 r
• 19 potężnych narzędzi do testowania penetracji używanych przez profesjonalistów w 2021 r
• Wytyczne dotyczące testowania bezpieczeństwa aplikacji mobilnych
• Testowanie bezpieczeństwa sieci i najlepsze narzędzia bezpieczeństwa sieci
• Testowanie bezpieczeństwa (kompletny przewodnik)
• Najlepsze 4 narzędzia testowania bezpieczeństwa Open Source do testowania aplikacji internetowych
• Podręcznik testowania zabezpieczeń aplikacji internetowych