---

tester_87 - 30 cze 2008, o 06:56
http://sjsi.hostdmk.net/wg/pliki/sjsi/doc/sjsi20031218.pdf
Interesująca prezentacja o testach bezpieczeństwa.

---

dsuch - 10 mar 2009, o 19:00
Prezentacja jest interesująca, choć traktuje temat ogólnie (ale to tylko
prezentacja, zapewne w trakcie jej rzucania jest czas na sporo ciekawych dyskusji).

Najważniejszymy rzeczami do zapamiętania na pewno są

1. 'Bezpieczeństwo musi być zaprojektowane, nie da się go "wtestować"'
2. 'Błędy bezpieczeństwa są często niskiego poziomu'
3. 'Niezbędny dostęp na niskim poziomie - planować niezbędne narzędzia'

Z 1. wypływa 2. i 3. - jeśli bezpieczeństwo musi być zaprojektowane, to znaczy,
że istnieje na niskim poziomie, ponieważ jest integralnym składnikiem produktu -
trudno jest utworzyć oprogramowanie, które potem otoczy się magiczną barierą
bezpieczeństwa. Być może bezpieczeństwo jest składnikiem modularnym, z możliwością
zmiany implementacji w zależności od okoliczności, ale jeśli jest 1. to mamy niski
poziom, więc 2. i 3. obowiązują.

Mam na myśli oprogramowanie, zapewne zupełnie inaczej będzie to wygladało
przy testach, np. urządzeń do aerobiku ale trzeba pamiętać, że w organizacjach
bezpieczeństwo prędzej czy później odchodzi od IT. To nadal jest informatyka,
ale rządzi się już innymi prawami, czasem wyodrębniając się ze struktur IT
także na poziomie przepisowo-formalno-proceduralnym. Wynika z tego też to, że dostęp
do aktualnych informacji o wymaganiach bezpieczeństwa bywa utrudniony i bywa,
że trzeba sporo zabiegów, aby je uzyskać. Często stosowana jest też technika,
według której informacje o wymaganiach dla bezpieczeństwa nie mogą zostać przedstawione
"ze względu na bezpieczeństwo". Potrzebna jest więc jeszcze większa cierpliwość
i empatia.

Z innej jeszcze strony, trzeba pamiętać, że nie ma czegoś takiego jak
"zapewnienie bezpieczeństwa", można jedynie eliminować ryzyka, które powinny
być jasno postawione - tu jest podobnie jak z testami funkcjonalności, nie można
po prostu powiedzieć, że oprogramowanie "ma zapewnić poprawne działanie".
Czasem trzeba też klientowi/odbiorcy pomóc w zrozumieniu tego, jakie właściwie
istnieją ryzyka. Zdarza się, że klient życzy sobie żeby n i k t nie miał dostępu
do danych i wydaje się, że w ten sposób zdefiniował odpowiednio zakres
osób/grup, przed którymi trzeba zabezpieczyć się. Przez "nikogo" klient/odbiorca
oczywiście nie rozumie całego świata tylko pewien krąg osób - niesolidnych pracowników,
konkurencję, script kiddies itd. Trzeba więc umieć pokazać przed kim - przed jakimi
działaniami - trzeba i należy zabezpieczyć się. Pomijam tu oczywiście rozmaite
normy obowiązujące w określonych obszarach, normy trzeba po prostu spełnić,
tu nie ma dyskusji.

Jeszcze inną kwestią jest to, że ludzie biznesowi przyjmują bezpieczeństwo (tak jak
i wysoką wydajność) za sprawę oczywistą. Tak samo jak ludzie na ulicy najczęściej
nie oglądają się nerwowo i nie sprawdzają dokładnie każdego przechodnia, ponieważ
wiedzą, że większość społeczeństw nie składa się z rewolwerowców, podobnie
użytkownicy oprogramowania często nie rozumieją problemów bezpieczeństwa, ponieważ
to nie jest ich sprawą, myślenie o tym nie pomaga im w pracy, a większość software'u
jest "mniej więcej" zabezpieczona, czyli tak naprawdę oznacza to tyle, że nie znalazła
się jeszcze osoba zdeterminowana na tyle, aby tym konkretnym użytkownikom pokazać,
że zabezpieczenia "mniej więcej" nie istnieją.

Trzeba też pamiętać, że skoro mówimy o ryzykach to trzeba umieć akceptować ryzyka,
jeśli ktoś faktycznie nie potrzebuje takich a nie innych zabezpieczeń i mamy pewność,
że wie o czym mówi (a mamy pewność, ponieważ dobrze znamy daną domenę),
to znaczy, że takie ryzyko akceptuje i nie ma co naciskać.

Proponowałbym więc

1. Bezpieczeństwo i zabezpieczenia muszą istnieć w projekcie od początku
2. Przygotowanie się na trudny dostęp do informacji o wymaganiach o bezpieczeństwie
i zabezpieczeniach
3. Przygotowanie się na to, że odbiorcy końcowi przyjmują bezpieczeństwo
i zabezpieczenia za sprawę oczywistą
4. Przygotowanie się na kompromisy przy akceptacji ryzyk

PS. Celowo pomijam cała klasę oprogramowania pisanego z myślą o zabezpieczeniach,
ale to już inna historia.