Logo

Pomagamy zapewniać bezpieczeństwo na każdym etapie cyklu wytwórczego.

Więcej o nas:
bezpiecznykod.pl

© 2022 Bezpieczny Kod · Polityka Prywatności

Wszystko co musisz wiedzieć o projektach OWASP Top 10, ASVS i SAMM

22/07/2021 · Andrzej Dyjak

Transkrypcja w formie artykułu pierwszego odcinka podcastu Bezpieczna Produkcja, w którym przybliżyłem flagowe projekty OWASP — Top 10, Application Security Verification Standard (ASVS) oraz Software Assurance Maturity Model (SAMM).

Odcinek możesz przesłuchać poniżej lub na wszystkich większych platformach, m.in. Spotify, Apple Podcasts czy Google Podcasts.

Spis treści

Wprowadzenie

Na samym początku wypadałoby wyjaśnić czym w ogóle jest OWASP.

OWASP, czyli Open Web Application Security Project jest otwartą globalną społecznością działającą formalnie jako organizacja non-profit w Stanach Zjednoczonych. Jej celem jest umożliwienie innym podmiotom na rynku tworzenia, nabywania oraz utrzymywania oprogramowania, któremu można zaufać.

I to tyle, ale wiedząc już czym jest OWASP to na marginesie odniosę się do błędu, który widzę na rynku. Mianowicie często spotykam zapisy mówiące o “metodyce OWASP” no i brzmi to tak samo jakbym powiedział “metodyka Toyota” w odniesieniu do Lean czy Kanbana – specjaliści zrozumieją skrót myślowy, bo znają kontekst natomiast osoby postronne błędnie przyjmą, że OWASP jest metodyką, a tak po prostu nie jest.

Ważne jest też to, że OWASP jako organizacja jest neutralny i nie oferuje certyfikacji. A więc przykładowo jeżeli usługodawca chce wystawiać certyfikację zgodności z OWASP ASVS to robi to “na własną rękę”. OWASP takiego podejścia nie potępia, a wręcz przeciwnie – daje wskazówki usługodawcom jak można takie coś stosować w praktyce, ale jasno odcina się od oficjalnej certyfikacji.

Mała uwaga zanim przejdę do omawiania projektów: Pod koniec odcinka zrobię podsumowanie i podpowiem do czego konkretnie można zastosować te projekty we własnej organizacji, więc warto wysłuchać ten odcinek do końca.

OWASP Top 10

OWASP Top 10 logo

OWASP Top 10 to lista dziesięciu najczęściej wystepujących słabości (weaknesses) w web aplikacjach. To, że jest to lista Top-10 wskazuje na jakiś rodzaj sortowania i rzeczywiście OWASP Top 10 jest posortowany przez ryzyko w kontekście typowej organizacji. Innymi słowy OWASP Top 10 nadaje krytyczność danej słabości dzięki czemu jako odbiorca wiemy, że np. “A1: Wstrzyknięcia” dla typowej organizacji powinien być większym problemem niż “A10: Niewystarczające logowanie i monitorowanie”.

Krótkie wyjaśnienie terminów, bo autorzy dokumentu sami mają z tym problemy i używają ich wymiennie:

Pierwsza wersja OWASP Top 10 została wydana w roku 2003. Ale chwila, chwila, jaka “pierwsza wersja”? Ano taka, że Top 10 zmienia się w czasie – pewne problemy znikają, a na ich miejsce pojawiają się inne np. Cross-Site Request Forgery (CSRF lub C-SURF) znajdowała się na liście Top 10 2013, ale w Top 10 2017 zniknęła.

Najnowsza wersja OWASP Top 10 jest z roku 2017, a w tym roku —czyli roku 2021 kiedy nagrywam ten podcast— ma zostać wydane długo wyczekiwane uaktualnienie 1.

Warto nadmienić, że jednym z celów Top 10 jest bycie zgodnym z rzeczywistością w większości przypadków. I ta “większość przypadków” jest tutaj ważna i wymaga komentarza ponieważ jeżeli będziemy chcieli być bardziej szczegółowi to takich list Top 10 możemy mieć więcej. Czemu? Bo typowe słabości różnią się po pierwsze między stosami technologicznymi (np. w typowej aplikacji PHP znajdziemy inne problemy niż w typowej aplikacji Railsowej) oraz po drugie różnią się również między zespołami (to znaczy, że różne zespoły wytwórcze popełniają różne typowe dla siebie błędy).

Wspominam o tym po części dlatego, żeby dać Ci do myślenia, że OWASP Top 10 nie jest idealny (chociaż dobrze jest mieć Top 10 jako pewnego rodzaju benchmark pasujący do 80% przypadków, czyli reguła Pareto 80:20), ale również dlatego żeby od razu poinformować, że istnieją inne listy OWASP Top 10 – dla przykładu OWASP Top 10 Serverless czy OWASP Top 10 API.

Oryginalnym celem Top 10 był wzrost świadomości wśród deweloperów i menedżerów, ale końcem końców Top 10 stał się niejako standardem rynkowym. Tutaj duża gwiazdka – to nie jest standard per se czego twórcy zresztą nie kryją i jasno mówią, że jeżeli potrzebny jest faktyczny standard to powinno się użyć ASVS. A poza wskazaniem ASVS jako standardu, rekomendują również stworzenie Programu Bezpieczeństwa Aplikacji i tutaj wskazują OWASP SAMM. O obu tych projektach opowiem w dalszej części tego odcinka.

Najnowsza wersja OWASP Top 10 powstała na bazie danych dostarczonych przez społeczność i składa się po pierwsze z danych od ponad 40 firm związanych z cyberbezpieczeństwem oraz po drugie z ponad 500 wypełnionych ankiet przez ludzi związanych z branżą. Łącznie dane te dają wgląd w ponad 100,000 podatności z aplikacji z realnego świata (zarówno w monolitach jak i nowoczesnych mikroserwisach).

Ok, dużo już powiedziałem o tym czym jest OWASP Top 10, ale jeszcze nie wymieniłem najważniejszego, czyli jakie słabości się na tej liście obecnie znajdują. Najnowsza wersja OWASP Top 10 z roku 2017 wygląda następująco:

Pewnym problemem, który mnie osobiście jako praktyka lekko mierzi jest mieszanie poziomów abstrakcji. Czasami autorzy używają konkretnej słabości (np. Cross-Site Scripting), a kiedy indziej używają klasy słabości (np. Wstrzyknięcia), w której zawiera się wiele różnych słabości (w przypadku Wstrzyknięć może to być SQL Injection, Command Injection, ale również i Cross-Site Scripting, który na koniec dnia również polega na wstrzyknięciu kodu). To nie jest duży problem, ale warto być go świadomym jeżeli pełnisz rolę specjalisty do spraw bezpieczeństwa.

Każdy opis słabości zajmuje jedną stronę A4 i zawiera następujące sekcje:

Często przeoczanym dodatkiem do OWASP Top 10 są rozdziały z rekomendacjami podzielonymi na role takie jak: Deweloper, Tester, CISO (Chief Information Security Officer), oraz Menedżer. Postaram się je streścić w kilku punktach.

W poradach dla deweloperów znajdziemy wskazówki odnośnie aspektów takich jak:

W poradach dla testerów znajdziemy wskazówki takie jak:

Następnie porady dla organizacji (czyli roli CISO) - tutaj porady są związane z implementacją programu bezpieczeństwa w procesie wytwórczym i w zasadzie nie wykraczają poza to co można znaleźć w OWASP SAMM, o którym będę dzisiaj jeszcze mówił.

I na sam koniec porady dla menedżerów zawierające cenne wskazówki dla menedżerów aplikacji w sprawie włączenia bezpieczeństwa w procesy takie jak:

Ok, w zasadzie opowiedziałem o najważniejszych aspektach OWASP Top 10. A czy mamy jakieś alternatywy? Tak! Jak najbardziej istnieją podobne listy.

Dobrym przykładem jest HackerOne Top 10, czyli Top 10 tworzone przez największą na świecie platformę Bug Bounty, przez którą rocznie przelatuje prawie 200,000 raportów faktycznych podatności. I teraz ciekawy fakt: Pokrycie pomiędzy najnowszym HackerOne Top 10, a OWASP Top 10 2017 jest duże, ale różnice występują (np. lista HackerOne zawiera zarówno CSRF oraz SSRF, a nie zawiera XXE).

Warto również zwrócić uwagę na liczby: OWASP Top 10 budowany jest na podstawie ok. 100,000 podatności, a HackerOne Top 10 prawie 200,000. Co więcej źródła danych również mają tutaj znaczenie – udział w programach Bug Bounty jest typowy dla pewnego rodzaju firm (według statystyk HackerOne najczęściej są to firmy technologiczne), a to znowu ma wpływ na to jakie technologie są używane pod spodem (i stąd może wynikać na przykład brak XML External Entities typowego dla Javy używanej w dużych korporacjach, a nietypowego dla np. Pythona używanego w firmach jednorożcach z doliny krzemowej).

Inną dobrze znaną na rynku listą typowych słabości jest CWE Top 25. Jej dużym plusem jest przywiązywanie uwagi do poziomu abstrakcji – każda słabość wylistowana w CWE Top 25 jest osobnym bytem (nie jak w przypadku OWASP Top 10, gdzie czasem to osobny byt, a czasem klasa). Z kolei minusem jest wrzucenie do worka wszystkich słabości niezależnie od typu aplikacji, więc przykładowo w najnowszym CWE Top 25 (który również zmienia się w czasie) znajdziemy np. Use-After-Free, i ta słabość jest typowa dla aplikacji pisanych w językach niskopoziomowych takich jak przeglądarki.

I to by było na tyle o OWASP Top 10. Najważniejsze informacje zostały przekazane i możemy iść dalej do OWASP ASVS!

OWASP Application Security Verification Standard

Application Security Verification Standard (w skrócie ASVS) to zestaw wymagań i kontroli bezpieczeństwa —zarówno funkcjonalnych jak i niefunkcjonalnych— które mogą zostać użyte podczas fazy projektowania, implementacji i weryfikacji web aplikacji w celu zapewnienia odpowiedniego poziomu bezpieczeństwa.

Pierwsza wersja ASVS została wydana w roku 2009. ASVS od tego czasu jest aktywnie rozwijany, a jego najnowsza wersja —czyli wersja 4— została wydana w roku 2019 i jest wyrównana z tym w jaki sposób działają obecne aplikacje (np. architektura oparta o mikroserwisy versus monolit).

Najnowsza wersja ASVS jest zgodna ze standardem NIST 800-63-3, który jest obszernym standardem uwierzytelniania. Co więcej wymagania i kontrolki zawarte w ASVS są w dużej mierze zmapowane do CWE, czyli listy która enumeruje typowe słabości występujące w oprogramowaniu i o której pobieżnie wspomniałem omawiając Top 10.

Aktualna wersja standardu podzielona jest na 14 obszarów i są nimi kolejno:

W obrębie każdego z tych obszarów znajdziemy sekcję określającą cel oraz referencje. Poza tym każdy obszar zawiera kontrolki i wymagania bezpieczeństwa, które zgrupowane są w mniejsze podobszary, dzięki czemu łatwo jest go używać w różnych przypadkach. Przykładowo obszar API i Web Serwisy podzielony jest na podobszary:

I teraz, jeżeli w danej aplikacji korzystamy z REST, a nie korzystamy z SOAP to możemy SOAP pominąć i dalej otrzymujemy po pierwsze pewne generyczne wymagania dla API, po drugie specyficzne wymagania dla API opartych o REST oraz po trzecie wymagania dla GraphQL i innych warstw danych.

Na początku mówiąc o tym czym jest ASVS wspomniałem o “zapewnianiu odpowiedniego poziomu bezpieczeństwa” i ma to tutaj znaczenie. Każde wymaganie ASVS należy do jednego z 3 poziomów weryfikacji, gdzie każdy kolejny poziom ma za zadanie podnosić bezpieczeństwo w coraz większym stopniu. Przykładowo:

Wchodząc bardziej szczegółowo w poszczególne poziomy możemy określić pewne ich właściwości.

ASVS poziom 1 (L1)

Wymagania ASVS na poziomie 1 rekomendowane są dla projektów z niskim zapotrzebowaniem na bezpieczeństwo. Ten poziom to takie niezbędne minimum. Co więcej poziom 1 można w dużej mierze —ale nie 100%— testować automatycznie.

Wymagania na poziomie 1 pokrywają całość OWASP Top 10 z roku 2017 (za wyjątkiem A10, czyli logowania) oraz OWASP Proactive Controls 2018. Oznacza to tyle, że jeżeli zaadaptujemy ASVS już na poziomie 1 jako standard w procesie bezpiecznego wytwarzania (np. jako podstawę testów bezpieczeństwa) to będziemy mieć z głowy praktycznie cały Top 10.

Dodatkowo ASVS na poziomie 1 jest nadzbiorem sekcji 6.5 standardu PCI DSS w wersji 3.2.1 (sekcja ta zawiera szereg wymagań odnośnie zapobiegania podatnościom w aplikacjach podczas procesu wytwórczego).

Ważną uwagą jest to, że jedynie poziom 1 jest możliwy do przetestowania podejściem black-box (to jest bez dostępu do dokumentacji, kodu źródłowego czy deweloperów i architektów) 3.

Autorzy otwarcie krytykują podejście black-box z czym się w 100% zgadzam. W realnym świecie występuje asymetria – atakujący ma tyle czasu ile potrzebuje, a tester bezpieczeństwa zawsze jest ograniczony czasem przewidzianym na ocenę. Z tego powodu podczas fazy testowania powinno się dołożyć wszelkich starań do tego żeby tester otrzymał tyle informacji ile może. Natomiast testowanie bezpieczeństwa podejściem black-box, które często wykonywane jest w pośpiechu na samym końcu procesu wytwórczego (albo w ogóle) – takie testowanie po prostu nie daje rady pokonać asymetrii pomiędzy cyberprzestępcami, a bezpiecznikami.

Zresztą wyobraźmy sobie sytuację, gdzie zewnętrzny audytor finansowy wchodzi do organizacji i ma ją ocenić pod kątem machlojek ale jednocześnie nie ma dostępu do dokumentów podatkowych czy ludzi odpowiedzialnych za kontroling. No brzmi śmiesznie, ale dokładnie taka sytuacja jest na porządku dziennym podczas testowania bezpieczeństwa aplikacji.

I właśnie dlatego autorzy mocno zachęcają do testowania bezpieczeństwa podejściem hybrydowym łącząc testy bezpieczeństwa z audytem kodu, dostępem do deweloperów i architektów, oraz dokumentacji.

Uwaga: Tutaj nie chodzi o podejście white-box – podejście hybrydowe to co innego, wyjaśnię różnicę w przyszłych odcinkach podcastu 3.

ASVS poziom 2 (L2)

Wymagania ASVS na poziomie 2 kierowane są do aplikacji wykonujących ważne operacje biznesowe (np. przetwarzanie danych osobowych w kontekście RODO). Ten poziom jest rekomendowany dla większości aplikacji.

Spełnienie ASVS na poziomie 2 zapewnia, że w aplikacji są obecne kontrole bezpieczeństwa skutecznie broniące przed większością podatności.

ASVS poziom 3 (L3)

Natomiast ASVS na poziomie 3 —czyli najwyższym— rekomenduje się dla aplikacji krytycznych, na przykład:

Mówiąc ogólnie ten poziom jest dla aplikacji i systemów IT, które wymagają najwyższego poziomu zaufania. W związku z tym aplikacja spełniająca wymagania poziomu 3 musi stać na najwyższym poziomie nie tylko w kwestii implementacji (a więc wykazać się brakiem skomplikowanych podatności), ale również ogólnego projektu architektury (to znaczy powinny być stosowanie zasady bezpiecznej architektury takie jak Defense in Depth, Principle of Least Privilege, i tym podobne).

Skuteczne testowanie aplikacji pod kątem poziomu 3 wymaga ścisłej współpracy z zespołami wytwórczymi.

Wybór poziomu ASVS zależy od kontekstu danej organizacji (tj. profilu ryzyka, profilu zagrożeń, itp.) oraz konkretnej aplikacji i danych jakie przetwarza.

Trzeba również uwypuklić fakt, że ponad połowy kontroli zawartych w ASVS nie da się przetestować automatami więc wymagają podejścia manualnego.

OWASP ASVS można używać w wielu kontekstach:

ASVS nie ma odpowiedników branżowych, ale istnieją standardy pokrewne:

No i dobrnęliśmy do końca tej sekcji. Teraz kiedy już wiesz czym jest Top 10 oraz ASVS, pora dowiedzieć się czym jest OWASP SAMM.

OWASP Software Assurance Maturity Model

Software Assurance Maturity Model (w skrócie SAMM) jest frameworkiem pozwalającym organizacjom na ocenę lub stworzenie i implementację własnej strategii bezpieczeństwa aplikacji.

Opisując SAMM-a skupię się głównie na wersji 1.5 pomimo tego, że najnowszą wersją jest wersja 2. Robię to z trzech powodów: po pierwsze z wersją 1.5 mam więcej doświadczenia, po drugie różnice pomiędzy wersją 1.5 a wersją najnowszą nie wpływają na zrozumienie fundamentów, a po trzecie łatwiej ją skontrastować z innym narzędziem o którym wspomnę dzisiaj i opowiem szerzej w kolejnych odcinkach.

Wracając do opisu – ważne, że SAMM to model dojrzałości, a nie lista wymagań. Dzięki temu pozwala ocenić stopień w jakim realizujemy daną aktywność, a nie tylko zero-jedynkowo stwierdzić czy dana aktywność jest spełniona czy nie.

SAMM jako framework pasuje zarówno do małych, średnich jak i dużych organizacji. Dodatkowo można go aplikować wyrywkowo w obrębie organizacji, konkretnej linii biznesowej, a wyrywkami nawet w ramach konkretnego projektu.

Budując SAMM-a autorzy oparli się o kilka fundamentalnych zasad:

Wersja 1.5 SAMM-a, składa się z 4 funkcji biznesowych: Nadzoru, Konstruowania, Weryfikacji i Operacji. Każda z nich zawiera w sobie aktywności zachodzące podczas procesu wytwórczego. Mówiąc inaczej – każda firma tworząca oprogramowanie posiada wszystkie te funkcje oraz realizuje poszczególne aktywności w jakimś stopniu.

Wysokopoziomowe spojrzenie na SAMM 1.5

Nie mając przed oczami dokumentu 4 można się trochę pogubić w tym co powiedziałem. W praktyce natomiast wygląda to następująco:

Tutaj warto uwypuklić, że taka edukacja musi zostać podzielona na poziomy, bo czym innym jest szkolenie z bezpieczeństwa aplikacji dla menedżerów i liderów, czym innym szkolenie z etycznego hackingu dla testerów QA, a jeszcze czym innym szkolenie z bezpieczeństwa dla deweloperów i architektów (notabene dlatego w Bezpieczny Kod mamy różne rodzaje szkoleń).
Tutaj muszę jasno uwypuklić, że Testy Penetracyjne nie grają pierwszych skrzypiec. To ocena podatności wnosi dużo więcej wartości pod kątem bezpieczeństwa do procesu wytwórczego niż pentesty, które z racji tego co i jak testują muszą odbywać się praktycznie na samym końcu znacznie wydłużając pętlę zwrotną 5.

Wcześniej powiedziałem, że SAMM posiada 3 poziomy dojrzałości, ale będąc skrupulatnym można wyszczególnić 4 poziomy dojrzałości, jeżeli zaczniemy od poziomu zero, który wskazuje na totalny brak aktywności w danym zakresie. Kolejne poziomy to:

A jak te poziomy wyglądają w praktyce? Zobrazuję to na dwóch przykładach praktyk: Edukacji oraz Testowania Bezpieczeństwa.

W przypadku praktyki Edukacja poziomy i wymagania wyglądają następująco:

Natomiast w przypadku praktyki Testowanie Bezpieczeństwa:

Na początku wspomniałem, że najnowsza wersja SAMM to wersja 2, a omawiając skupiłem się na wersji 1.5. A więc jakie są różnice pomiędzy nimi? Główną zmianą względem starej wersji jest dodanie całkowicie nowej funkcji biznesowej Implementacja (Implementation), która zawiera praktyki związane z zapewnianiem bezpieczeństwa sposobu w jaki wytwarzamy software (np. bezpieczeństwo potoku CICD – i tutaj ważne, że nie mówimy o bezpieczeństwie W POTOKU tylko bezpieczeństwie potoku (np. aktualna i zabezpieczona instancja Jenkinsa)). Dodatkowo funkcje biznesowe Weryfikacja oraz Operacje lekko się zmieniły oraz dodane zostały strumienie – każda praktyka bezpieczeństwa podzielona jest na 2 strumienie.

Niestety wersja 2 dalej —po prawie półtora roku— jest bardziej minimalistyczna niż wersja 1.5. Dokumentacja wersji 1.5 jest po prostu przyjemniejsza w odbiorze. Dodatkowo dla wersji 1.5 istnieją dodatkowe dokumenty pomocnicze, które do tej pory nie zostały przełożone do wersji 2.

Na zakończenie zobaczmy jak sprawa ma się z alternatywami dla SAMM-a. Najbliższym zamiennikiem jest Building Security In Maturity Model znany również jako BSIMM, o którym opowiem szerzej w kolejnych odcinkach, ale już teraz wskażę jedną fundamentalną różnicę względem SAMM-a. Tak jak mówiłem wcześniej, SAMM jest modelem nakazowym (prescriptive) opisującym jak bezpieczny proces powinien wyglądać z perspektywy eksperta. Natomiast BSIMM jest modelem zbudowanym na obserwacji tego jak sprawy faktycznie wyglądają w firmach, które wytwarzają oprogramowanie (to znaczy, że wzięta jest próbka praktyk i aktywności z wielu różnych firm, następnie wyciągnięte są elementy wspólne i na koniec następuje ich ważenie).

Podsumowanie

Teraz kiedy już wiesz czym jest Top 10, ASVS i SAMM masz już pewnie własne pomysły, gdzie można te narzędzia wykorzystać. Jeżeli nie to moje propozycje są następujące:

A już zupełnie na marginesie ASVS pomaga również usługodawcom z rynku cyberbezpieczeństwa —takim jak moja firma Bezpieczny Kod— ułatwiając nam oferowanie usług wyrównanych z tym czego potrzebują klienci.

Warto również zauważyć, że omawiając te 3 flagowe projekty przechodziliśmy od szczegółu do ogółu. Mam tutaj na myśli to, że Top 10 jest najbliżej implementacji, ASVS wychodzi poza samą implementację zahaczając o fazy projektowania i testowania. Natomiast SAMM ma coś do powiedzenia w każdej aktywności związanej z procesem wytwórczym.

  1. Najnowsze wydanie OWASP Top 10 w wersji 2021 jest już dostępne. ↩

  2. O projektach OWASP Proactive Controls i Cheat Sheet Series możesz posłuchać w odcinku drugim. ↩

  3. O podejściach black-box, white-box, gray-box czy hybrydzie możesz posłuchać w odcinku piątym. ↩

  4. Forma artykułu na blogu pozwala na dodanie obrazka, a więc został on dołączony powyżej. ↩

  5. O ocenie podatności możesz posłuchać w odcinku siódmym, a o testach penetracyjnych w odcinku ósmym. ↩

Referencje

Omawiane projekty OWASP:

Inne wspomniane projekty OWASP-owe i nie tylko:

Definicje i koncepty:

Podobne posty: