Czym jest OWASP OpenSAMM? Czyli jak zwiększyć bezpieczeństwo tworzonego oprogramowania

OWASP OpenSAMM (Open Software Assurance Maturity Model) to otwarty framework pozwalający na sprawne opracowanie i wdrożenie strategii dot. bezpieczeństwa oprogramowania rozwijany przez OWASP.

OpenSAMM do tematu bezpieczeństwa oprogramowania podchodzi systematycznie i całościowo, definiując 12 praktyk bezpieczeństwa pogrupowanych w 4 podstawowe funkcje biznesowe: Governance, Construction, Verification and Deployment. Strukturę tą widać na rysunku:

Każda praktyka posiada 3 poziomy zaawansowania i dla uproszenia oznaczana jest nazwą skróconą. Przykładowo praktyka Security Testing z grupy Verification oznaczona jest jako ST, a poziomy jej zaawansowania jako ST1, ST2, ST3.

Na początek najlepiej zapoznać się z praktyką, w której czujemy się najlepiej. W tym artykule skupimy się na Security Testing (ST). Informacje na temat wszystkich praktyk, w wygodnej do przeglądania formie znaleźć można na stronie OWASP OpenSAMM.

Praktyka ST, jak każda inna w OpenSAMM, podzielona jest na 3 poziomy zaawansowania:

ST1:

• Tworzenie scenariuszy testów w oparciu o wymagania bezpieczeństwa.
• Przeprowadzanie testów penetracyjnych dla każdego wydania oprogramowania.

ST2:

• Stosowanie narzędzi automatyzujących testy bezpieczeństwa.
• Testy bezpieczeństwa zintegrowane z procesem tworzenia oprogramowania.

ST3:

• Stosowanie narzędzi automatyzujących testy bezpieczeństwa dopasowanych do testowanej aplikacji.
• Ustalenie warunków bezpieczeństwa, które muszą być spełniane przed każdym releasem.

Każdy poziom praktyki, oprócz wyżej wymienionych „haseł”, opisany jest także krótkim tekstem. I tak, praktyka ST1 bardziej szczegółowo definiowana jest następująco:

Testy powinny być przeprowadzane w oparciu o zdefiniowane scenariusze stworzone na podstawie wymagań bezpieczeństwa. Scenariusze takie powinny być przygotowane na etapie tworzenia architektury lub wymagań. Testowana powinna być zarówno logika biznesowa aplikacji jak i sama aplikacja (oraz jej architektura) pod kątem typowych podatności (XSS, SQL Injection itp.). Na podstawie takich scenariuszy przed każdym releasem powinny być wykonywane testy penetracyjne, a ich wyniki przeglądane i akceptowane.

Dodatkowo, każdy poziom praktyki ma określone spodziewane rezultaty, przypisane metryki, koszty i wymagany personel. Przykładowo, dla omawianej ST1 rezultatami będą niezależna weryfikacja bezpieczeństwa oraz rozbudowa (lub stworzenie) zestawu testów. Metryki to co najmniej połowa projektów posiadająca scenariusze testów bezpieczeństwa aktualizowane w ciągu ostatniego roku oraz co najmniej połowa interesariuszy świadoma statusu testów bezpieczeństwa w ciągu ostatnich 6 miesięcy. Koszty są trzy, tj. stworzenie scenariuszy testów bezpieczeństwa, licencje związane z narzędziami, które mogą być użyte do testów oraz narzut związany z uruchamianiem testów i weryfikacją wyników. Wymagany personel podawany przez OWASP to: tester QA (1-2 dni/rok), audytor bezpieczeństwa (1-2dni/rok), programiści (1dzień/rok), architekci (1 dzień/rok), właściciel (1 dzień/rok).

Oczywiście nie każda firma musi implementować wszystkie praktyki, czy też wszystkie ich poziomy. O tym, które praktyki powinny być realizowane decyduje specyfika organizacji, branża w której operuje, jej tolerancja ryzyka itp.

Jak zacząć używać OpenSAMM?

Są 3 kroki:

1. Oceń stan praktyk bezpieczeństwa w rozumieniu OpenSAMM.
2. Określ cel (tzn. pożądany poziom każdej praktyki) i stwórz plan realizacji.
3. Zrealizuj plan ;)

Ocena stanu praktyk bezpieczeństwa

Ocenę stanu praktyk bezpieczeństwa można przeprowadzić na podstawie samego wywiadu lub wywiadu w połączeniu z faktycznym sprawdzeniem czy deklarowane praktyki są realizowane. OWASP udostępnia SAMM Tool Box zawierający szablon do przeprowadzenia wywiadu. W dokumencie tym, znaleźć możemy także arkusz wyliczający scorecard. Scorecard liczbowo określa stopień zaawansowania każdej praktyki bezpieczeństwa. Ważne, aby podczas przeprowadzania wywiadu nie skupiać się na określaniu 0/1, ale raczej starać się zrozumieć co jest robione, notować to w arkuszu a później oceniać, czy dana praktyka jest realizowana. Należy przy tym pamiętać, że aby można było uznać praktykę za realizowaną, muszą być spełnione wszystkie wymagania wylistowane w arkuszu w obrębie danej praktyki.

Po przeprowadzeniu wywiadu (i opcjonalnie weryfikacji) można określić poziomy realizacji każdej praktyki bezpieczeństwa i przejść do określenia celu i planu.

Cel i plan

Określenie, które praktyki i na jakim poziomie chcemy realizować wchodzi w zakres jednej z pierwszych praktyk, a dokładniej praktyki SM1. Wymaga ona udziału osób odpowiedzialnych za strategię organizacji i zarządzenie ryzykiem. Sprowadza się do spotkania lub serii spotkań, których wynikiem powinien być dokument określający – na podstawie specyfiki branży i stopnia tolerancji ryzyka – jakie poziomy praktyk bezpieczeństwa mają być docelowo realizowane. Warto zauważyć, że jeśli organizacja wcześniej nie korzystała z OpenSAMM, może już realizować praktykę SM1 w mniej oczywisty sposób. Jeśli tylko istnieje jakakolwiek strategia dotycząca bezpieczeństwa, dużo łatwiej będzie ją zaadoptować czy rozbudować do wytycznych SM1 niż tworzyć od nowa.

Wiedząc, jakie poziomy chcemy osiągnąć oraz jakie aktualnie realizujemy, możemy przeprowadzić tzw. gap analysis, czyli określić czego nam brakuje to założonego stanu. Następnym krokiem jest stworzenie tzw. roadmapy, czyli planu w jakiej kolejności i czasie będziemy dążyć do wyznaczonego celu.

OWASP udostępnia kilka przykładowych roadmap dla wybranych typów organizacji (rządowa, finansowa, software house itp.). Przykładową roadmapę zalecaną przez OWASP dla instytucji rządowej przedstawia rysunek:

Widać na nim 5 etapów (phase 1-5). Celem każdego etapu roadmapy jest realizacja wybranych praktyk bezpieczeństwa na wybranych poziomach. I tak, w naszym przykładzie, po pierwszym etapie zakładamy wdrożenie SM1, PC1, ED1, SR1, SA1, ST1 i EH1. Wdrożenie większości poziomów praktyk bezpieczeństwa, wg OWASP powinno zajmować 3-6 miesięcy na praktykę. Jeśli nie jesteśmy pewni jak zrobić własną roadmapę, warto skorzystać z przykładu dla podobnej organizacji (nawet jeśli nie do końca przystaje on do naszej gap analysis) i dostosować go do swoich potrzeb.

Podsumowanie

OWASP OpenSAMM to kompleksowy i praktyczny framework pozwalający na uporządkowane i przyrostowe podejście do zapewniania bezpieczeństwa na etapie tworzenia oprogramowania. Z OpenSAMM warto się zapoznać nawet jeśli nie mamy zamiaru go wdrażać, choćby po to, aby ocenić stan praktyk bezpieczeństwa w naszej organizacji z być może innego punktu widzenia niż jest to zwykle wykonywane.

Marcin Teodorczyk, pracuje w:
intive. We turn ideas into digital reality.