Odkryj wszystkie problemy programu

Jakość musi być wbudowana w produkt. Testy mogą jedynie ujawnić obecność wad produktu. Aby zapewnić jakość, SQA monitoruje zarówno proces rozwoju, jak i zachowanie oprogramowania. Celem nie jest przekazywanie ani certyfikacja oprogramowania; celem jest zidentyfikowanie wszystkich niedoskonałości i problemów w oprogramowaniu, aby można je było naprawić.

CELE ZAPEWNIENIA JAKOŚCI OPROGRAMOWANIA

W słowniku terminologii inżynierii oprogramowania IEEE jakość definiuje się jako „stopień, w jakim system, komponent lub proces spełnia potrzeby lub oczekiwania klienta lub użytkownika”. Zgodnie z tą definicją, oprogramowanie powinno być mierzone przede wszystkim stopniem do których zaspokajane są potrzeby użytkownika. Ponieważ oprogramowanie często wymaga dostosowania do zmieniających się wymagań, powinno być możliwe do dostosowania przy rozsądnych kosztach. Dlatego oprócz troski o poprawność, niezawodność i użyteczność klient jest również zaniepokojony  testowalnością, konserwowalnością, przenośnością i zgodnością z ustalonymi standardami i procedurami dotyczącymi oprogramowania i procesu rozwoju. Zapewnienie jakości oprogramowania (SQA) to element inżynierii oprogramowania, który stara się zapewnić, aby oprogramowanie spełniało akceptowalne standardy kompletności i jakości. SQA pełni funkcję strażnika nadzorującego wszystkie działania związane z jakością związane z tworzeniem oprogramowania. Główne cele SQA to:

* Odkryj wszystkie problemy programu.

* Zmniejsz prawdopodobieństwo, że wadliwe programy wejdą do produkcji.

* Chroń interesy użytkowników.

* Zabezpiecz interesy producenta oprogramowania.

ROZWÓJ OPROGRAMOWANIA I ZAPEWNIENIE JAKOŚCI

Rozwój oprogramowania może mieć wpływ na wszystkie sześć podstawowych zasad bezpieczeństwa informacji opisanych w rozdziale 3 niniejszego Podręcznika, ale najczęstsze problemy powodowane przez słabe oprogramowanie obejmują integralność, dostępność i użyteczność. Pomimo dostępności oprogramowania w pakietach na otwartym rynku, oprogramowanie takie często musi być dostosowywane do specyficznych potrzeb użytkowników. Tam, gdzie nie jest to możliwe, programy muszą być tworzone od podstaw. Niestety, podczas każdego projektu rozwoju oprogramowania, pomimo starannego planowania, nieuchronnie pojawiają się nieprzewidziane problemy. Niestandardowe oprogramowanie i niestandardowe pakiety często są dostarczane z opóźnieniem, są wadliwe i nie spełniają specyfikacji. Ogólnie rzecz biorąc, kierownicy projektów oprogramowania mają tendencję do niedoceniania wpływu trudności technicznych i nietechnicznych. Dzięki temu doświadczeniu rozwinęła się dziedzina inżynierii oprogramowania; jego celem jest znalezienie rozsądnych odpowiedzi na pytania, które pojawiają się podczas projektów rozwoju oprogramowania.

 

Standardy i najlepsze praktyki

Testowanie jest samodzielną dyscypliną inżynierii oprogramowania. Napisano tomy o różnych technikach stosowanych przez inżynierów oprogramowania do testowania i walidacji swoich aplikacji. Podstawowe najlepsze praktyki można zastosować niezależnie od wybranej metodyki testowania.

* Wykonaj automatyczne testy.

* Zrób plan testu.

* Postępuj zgodnie z określoną metodologią.

* Testuj na każdym etapie.

* Przetestuj wszystkie elementy systemu.

Oprócz tych najlepszych praktyk, stosowanie tych standardów może zapewnić dodatkowe zasoby:

*ISO 17799, Technologia informacyjna: Kodeks postępowania w zarządzaniu bezpieczeństwem informacji

* ISO/IEC 15408, Kryteria oceny bezpieczeństwa IT (Wspólne kryteria)

* SSE-CMM, model dojrzałości możliwości inżynierii bezpieczeństwa systemu

* ISO/IEC WD 15443, Technologia informacyjna: Techniki bezpieczeństwa

UWAGI KOŃCOWE

Praktycy bezpieczeństwa komputerowego i menedżerowie najwyższego szczebla muszą zrozumieć, że braki w zarządzaniu IT, pozostawione bez zmian, będą sabotować wysiłki na rzecz ustanowienia i utrzymania skutecznych programów bezpieczeństwa komputerowego. Ponadto na tych, którzy kodują, spoczywa pomoc w kierowaniu projektem i kształcenie kierownictwa w kierunku modelu, który obejmuje bezpieczeństwo w całym cyklu rozwoju. Koszty zaniedbania bezpieczeństwa na początku będą nadal stanowić poważny problem, dopóki bezpieczeństwo oprogramowania nie zostanie w pełni zintegrowane z każdym aspektem cyklu życia oprogramowania. Bezpieczeństwo musi być wbudowane, a budowanie bezpieczeństwa w systemach zaczyna się od zespołów programistycznych, praktyk i technik używanych do tworzenia tych systemów.

Testy penetracyjne oprogramowania

Testy penetracyjne od wielu lat są powszechną techniką testowania bezpieczeństwa sieci i są również znane jako testy czarnej skrzynki i etyczne hakowanie. Jak opisano w podejściu czarnej skrzynki, testy penetracyjne to zasadniczo testowanie działającej aplikacji (bez znajomości wewnętrznego działania aplikacji) w celu zidentyfikowania luk w zabezpieczeniach. W testach penetracyjnych cały system oprogramowania jest środowiskiem „na żywo”. Zazwyczaj zespół penetracyjny miałby dostęp do aplikacji jak typowi użytkownicy. Testerzy zachowują się wtedy jak atakujący, próbując znaleźć i wykorzystać potencjalne luki w zabezpieczeniach. Testy penetracyjne powinny koncentrować się na aspektach zachowania systemu, interakcji i podatności, których nie można zaobserwować za pomocą innych technik testowania wykonywanych poza żywym środowiskiem. Oznacza to, że penetracja powinna narazić system na wyrafinowane wielowzorcowe ataki mające na celu wywołanie złożonych zachowań w poszczególnych składnikach systemu. Ponadto testy powinny próbować znaleźć problemy z bezpieczeństwem, które mogą pochodzić z architektury i projektu, a nie wady kodowania, ponieważ tego typu problem jest często pomijany przez inne techniki testowania. Oznacza to również, że plan testów powinien zawierać najgorsze scenariusze, które odtwarzają wektory zagrożeń uważane za wysoce szkodliwe, takie jak scenariusz zagrożenia wewnętrznego. Wiele osób używa testów penetracyjnych aplikacji jako podstawowej techniki testowania i chociaż ma to miejsce w programie testowym; nie należy jej uważać za podstawową lub jedyną technikę testowania. Testy penetracyjne mogą potencjalnie prowadzić do fałszywego poczucia bezpieczeństwa. Tylko dlatego, że aplikacja przeszła test penetracyjny, nie oznacza to, że jest wolna od luk w zabezpieczeniach. Podobnie, jeśli aplikacja nie powiedzie się, jest to silna wskazówka, że ​​są z nią poważne problemy. Jednak skoncentrowane testy penetracyjne, czyli testy mające na celu wykorzystanie luk wykrytych w poprzednich testach, mogą być przydatne w wykrywaniu, czy te luki zostały rzeczywiście naprawione w kodzie.

Skanowanie podatności

Automatyczne skanowanie podatności to zautomatyzowana technika skanowania oprogramowania na poziomie aplikacji, a także serwerów internetowych, systemy zarządzania bazami danych i niektóre systemy operacyjne. Narzędzia skanują oprogramowanie aplikacji w poszukiwaniu danych wejściowych i wyjściowych znanych wzorców powiązanych ze znanymi lukami w zabezpieczeniach. Wzorce lub sygnatury luk w zabezpieczeniach są podobne do sygnatur używanych przez skanery antywirusowe lub konstrukcji kodowania wyszukiwanych przez automatyczne skanery kodu źródłowego, dzięki czemu skaner luk w zabezpieczeniach jest zasadniczo narzędziem do automatycznego dopasowywania wzorców. Niektóre skanery luk w zabezpieczeniach aplikacji sieci Web dodatkowo próbują przeprowadzić zautomatyzowaną ocenę stanu przy użyciu symulowanych wzorców ataków rozpoznawczych i technik rozmycia w celu wykrycia znanych lub powszechnych luk w zabezpieczeniach. Jak każdy skaner oparty na sygnaturach, skanery luk w zabezpieczeniach mogą zgłaszać fałszywe alarmy. W rezultacie tester musi mieć wystarczającą wiedzę w zakresie oprogramowania i bezpieczeństwa, aby sensownie zinterpretować wyniki skanera, aby ograniczyć liczbę fałszywie pozytywnych lub negatywnych wyników, aby zapobiec stworzeniu incydentu, w którym nie istnieje. Dlatego ważne jest, aby zastosować podejście warstwowe i połączyć różne techniki testowe w celu zbadania oprogramowania pod kątem luk w zabezpieczeniach. Luki w oprogramowaniu są często maskowane przez zabezpieczenia środowiskowe, takie jak zapory sieciowe i na poziomie aplikacji. Ponadto warunki środowiskowe mogą tworzyć unikalne luki w zabezpieczeniach, których nie można znaleźć za pomocą narzędzia opartego na sygnaturach, ale wykorzystującego kombinację innych testów czarnoskrzynkowych, w szczególności testów penetracyjnych wdrożonego oprogramowania w rzeczywistym środowisku docelowym. Skanery luk w zabezpieczeniach są najskuteczniejsze w ramach:

* Oceny bezpieczeństwa komponentów binarnych;

* Lub przed testami penetracyjnymi (w celu wyeliminowania konieczności uruchamiania scenariuszy testów penetracyjnych dla typowych luk w zabezpieczeniach).

Fuzzing

Testowanie rozmyte lub fuzzing to technika często zautomatyzowana lub półautomatyczna, która polega na dostarczaniu nieprawidłowych, nieoczekiwanych lub losowych danych do danych wejściowych programu komputerowego. Program jest następnie monitorowany pod kątem wyjątków, nieudanych wbudowanych potwierdzeń kodu lub znalezienia potencjalnych wycieków pamięci. Istnieją dwie formy fuzzingu, oparte na mutacjach i oparte na pokoleniu, które można zastosować w ramach testów białej, czarnej lub szarej skrzynki. Ideą testowania fuzz jest poszukiwanie interesującego zachowania programu, które wynika z wstrzykiwania szumu i może wskazywać na obecność luk lub błędów. Aplikacje fuzzujące, fuzzery, są zazwyczaj specyficzne dla określonego typu danych wejściowych i napisane w celu przetestowania określonego programu; nie można ich łatwo ponownie wykorzystać, ale formaty plików i protokoły sieciowe są najczęstszymi celami testowania. Dowolny typ danych wejściowych programu może zostać zamazany, w tym elementy, które normalnie nie są uważane za „dane wejściowe” (np. bazy danych, pamięć współdzielona itp.). Wartość tkwi w specyfice, co oznacza, że ​​fuzzing często może ujawnić luki w zabezpieczeniach, których ogólne narzędzia testujące, takie jak skanery podatności i wstrzykiwacze błędów, nie są w stanie. Z drugiej strony, całkowicie losowe fuzzing jest zazwyczaj nieefektywnym sposobem wykrywania problemów w aplikacji, w wyniku czego technologia fuzzingu ewoluowała, obejmując bardziej inteligentne techniki.

Błąd wstrzykiwania

Istnieją dwie podstawowe kategorie wstrzykiwania błędów: kod źródłowy lub binarne wstrzykiwanie błędów. Wstrzyknięcie usterki służy do wywołania stresu w oprogramowaniu, tworzyć problemy ze współdziałaniem między komponentami, symulować błędy w środowisku wykonawczym, a tym samym ujawniać błędy zagrażające bezpieczeństwu, które nie są widoczne przy użyciu tradycyjnych technik testowania. Bezpieczeństwo rozszerza standardowe wstrzykiwanie błędów, dodając wstrzykiwanie błędów, umożliwiając testerom analizę wpływu zachowań na bezpieczeństwo i zmiany stanu wynikające z wystawienia oprogramowania na zmiany w danych środowiskowych. Te zmiany danych mają na celu symulację rodzajów błędów, które mogą wystąpić podczas niezamierzonych błędów użytkownika lub celowych ataków na oprogramowanie za pośrednictwem jego środowiska, w tym ataków na samo środowisko. Zmiana danych to po prostu zmiana danych, które środowisko wykonawcze przekazuje do oprogramowania lub między składnikami oprogramowania. Wstrzykiwanie błędów ujawnia zarówno wpływ błędów bezpieczeństwa na zachowanie poszczególnych komponentów, jak i zachowanie systemu jako całości. Binarne wstrzykiwanie błędów jest przydatne, gdy jest wykonywane w ramach testów penetracyjnych, aby umożliwić testerowi uzyskanie bardziej całościowego obrazu reakcji oprogramowania na ataki. Jednak błędy nie powinny ograniczać się do symulacji ataków w świecie rzeczywistym. Scenariusze wstrzykiwania błędów powinny być zaprojektowane tak, aby zapewnić pełne zrozumienie wpływu na bezpieczeństwo, jaki mają zachowania, stany i właściwości aplikacji we wszystkich możliwych warunkach pracy. Główne wyzwania w testowaniu wstrzykiwania usterek polegają na określeniu najbardziej znaczącej kombinacji i ilości usterek do wstrzyknięcia oraz, jak w przypadku wszystkich testów, interpretacji wyników. Co więcej, tylko dlatego, że wstrzykiwanie błędów nie powoduje, że oprogramowanie zachowuje się w sposób niezabezpieczony ani nie działa w stanie niezabezpieczonym, nie można tego interpretować w ten sposób, że oprogramowanie będzie działać tak samo, gdy zostanie wystawione na bardziej złożone dane wejściowe, które zwykle otrzymuje podczas wykonywania.

Podejście mieszane z szarą skrzynką

Testowanie szarej skrzynki to technika testowania oprogramowania, która wykorzystuje kombinację testowania czarnej skrzynki i testowania białej skrzynki. Testowanie szarej skrzynki nie jest testowaniem czarnej skrzynki, ponieważ tester zna niektóre wewnętrzne działanie testowanego oprogramowania. W testach szarej skrzynki tester stosuje ograniczoną liczbę przypadków testowych do wewnętrznego działania testowanego oprogramowania. W pozostałej części testowania szarej skrzynki tester stosuje podejście czarnej skrzynki, wprowadzając dane wejściowe do testowanego oprogramowania i obserwując dane wyjściowe.