3813100976

•    identyfikacji specyficznych komponentów środowisk potrzebnych, gdy robiona jest rezerwacja środowisk testowych,

•    rozwiązywaniu problemu wykluczających się rezerwacji poprzez dyskusję i osiąganie konsensusu z zaangażowanymi grupami,

•    zdefiniowaniu harmonogramu rezerwacji środowiska na nadchodzący okres, którego ostateczna postać wynika z dostępności środowiska w danym czasie, a jeśli jest zajęte - priorytetów testów do przeprowadzenia,

•    użyciu środowiska np. przez danego testera, jeśli jest zarezerwowane na niego,

•    prawidłowym zamknięciu środowiska po użyciu - co sprowadza się do pozostawienia środowiska w stanie sprzed użycia i usunięciu plików testowych.

Raportowanie i zarządzanie incydentami środowiska testowego [Veen09] (ang. Report and manage test emironment incidents) odzwierciedla problemy, które występują przy użyciu środowiska testowego i są traktowane jako incydenty. Powstaje tu raporty incydentów środowiska oraz raporty ze spotkania, na którym podejmuje się decyzje odnośnie znalezionych incydentów. Do tych wyników dochodzi się przeprowadzając:

•    logowanie występującego incydentu środowiska od razu gdy problem zostanie zauważony,

•    formalne raportowanie incydentu z użyciem schematu klasyfikacji incydentów, zawierającego podział incydentów przykładowo według ich priorytetów,

•    zarządzanie incydentami środowiska w celu ich rozwiązania i zamknięcia (po weryfikacji poprawności poprawki).

5. Podsumowanie

Na Rys. 1 zaprezentowano środowisko testowania opracowane w ramach europejskiego projektu badawczego „Diadem Firewall" służącego do wykonywania testów zachowania rozproszonego systemu bezpieczeństwa (różne elementy w poszczególnych organizacjach) przy występowaniu ataku zalewania pakietami TCP SYN. Jest to przykład implementacji środowiska.

W praktyce najtrudniejsze było:

•    wdrożenie środowiska testowego, które odpowiadałoby funkcjom dopiero co powstałej platformy rozproszonych zapór ogniowych mających na celu wykrycie i likwidację ataków odmowy usług zbudowanej z kilku warstw elementów sieciowych,

•    opracowanie danych testowych przedstawiających rzeczywisty ruch sieciowy przed i w trakcie ataku.

Jako testerzy musieliśmy wykazać się umiejętnościami komunikacyjnymi przy pozyskiwaniu zastrzeżonych danych ruchu sieciowego operatora, które próbowaliśmy częściowo zastąpić modelami teoretycznymi powstałymi w ramach innych projektów badawczych, następnie ustawiliśmy sprzętowy generator/analizator ruchu sieciowego według uzyskanych wartości.

Oczywiście środowiska testowe powstają również bez tego typu problemów, gdy chociażby w danym projekcie jest ono ustanowione wiele lat wcześniej i prostsze w budowie, czy testowany system nie zmienia się znacznie - wtedy model TMMi stosujemy do ewentualnego jego wzbogacenia, na przykład o kwestie związane z logowaniem i późniejszym raportowaniem incydentów takiego środowiska. Są to tylko przykłady - stopień wykorzystania modelu TMMi zależy oczywiście od danego projektu i poziomu dojrzałości organizacji testowania.