[Warsaw 25.04.2018] - ASVS - Błażej Pabiszczak, YetiForce

Czym jest OWASP
OWASP jest to internetowa organizacja, która
skupia wokół siebie otwartą społeczność tworzącą
bezstronne, praktyczne i opłacalne narzędzia oraz
informacje na temat bezpieczeństwa aplikacji.
Projekt istnieje od 2001 roku, a w 2004 powstała
charytatywna fundacja działająca na terenie USA.

Czym jest OWASP ASVS
ASVS (Application Security Verification Standard)
Standard Weryfikacji Bezpieczeństwa Aplikacji jest
to lista wymagań jakie powinno się stawiać
aplikacjom aby podwyższyć ich poziom
bezpieczeństwa oraz jest to lista testów, jakie
należy zrealizować, aby sprawdzić rzeczywisty
poziom bezpieczeństwa danej aplikacji.

Poziomy OWASP ASVS
Poziom 1
Poziom 2
Poziom 3
Poziom 0
Pobieżny - poziom bezpieczeństwa został zweryfikowany
pośpiesznie a podejście do zakresu jest dość elastyczne i w każdej
organizacji może się znacząco różnić. Poziom ten nie został ujęty w
OWASP ASVS.
Oportunistyczny - poziom bezpieczeństwa, który zapewnia ochronę
przed standardowymi atakami, które są łatwe do wykrycia i można
je znaleźć na różnych listach np.: OWASP TOP 10.
Standardowy - poziom bezpieczeństwa, zalecany dla każdej
aplikacji, która przetwarza istotne transakcje biznesowe. Poziom ten
oznacza, że mechanizmy bezpieczeństwa są wdrożone oraz są
skuteczne.
Zaawansowany - poziom bezpieczeństwa zalecany dla aplikacji,
które realizują funkcje krytyczne, w przypadkach, gdy awaria może
mieć znaczący wpływ na działalność organizacji, a nawet na jej

ASVS - Testowanie i
weryfikacja
Poziom 3
Na poziomie najwyższym,
powinno się mieć dostęp do
konfiguracji systemu,
architektury rozwiązania
pomiędzy użytkownikiem a
aplikacją oraz szczegółowej
dokumentacji
uwzględniającej
modelowanie zagrożeń.
3
Poziom 2
Wymaga, aby osoby
wykonujące testy i
weryfikujące poziom
bezpieczeństwa, miały
dostęp do programistów
aplikacji, dokumentacji,
kodu źródłowego oraz
bezpośredniego dostępu do
aplikacji do każdej z ról.
2
Poziom 1
Do weryfikacji można użyć
narzędzi automatycznych
bez wykonywania testów
manualnych i bez dostępu
do kodu źródłowego.
1

ASVS 3.1 - Pełen zakres
1: Architektura, projektowanie i modelowanie zagrożeń
2: Weryfikacja Wymagań Autoryzacji
3: Weryfikacja Wymagań Zarządzania Sesją
4: Weryfikacja Kontroli dostępu
5: Weryfikacja Obsługi Złośliwych Danych Wejściowych
7: Kryptografia
8: Weryfikacja Obsługi i Rejestrowania Błędów
9: Weryfikacja Ochrony Danych
10: Weryfikacja Komunikacji
13: Złośliwy Kod
15: Weryfikacja Logiki Biznesowej
16: Weryfikacja plików i zasobów
17: Weryfikacja wersji mobilnej
18: API
19: Weryfikacja Konfiguracji
20: Wymagania weryfikacji Internetu Rzeczy

ASVS 3.1 - Słownik
Pierwszy problem z jakim należy
się uporać, to wieloznaczność
słów.

OWASP ASVS 3.1
1: Architektura, projektowanie i
modelowanie zagrożeń

OWASP ASVS 3.1 - Poziomy
Na poziomie 1
Elementy aplikacji są
zidentyfikowane i mają rację
bytu w aplikacji
Na poziomie 3
Architektura i design są
gotowe, używane, i
efektywne
Na poziomie 2
Architektura jest
zdefiniowana, a kod jest
zgodny z architekturą
03
01 02

ASVS 3.1 - 1: Architektura, projektowanie i
modelowanie zagrożeń
1.1: Upewnij się, że wszystkie elementy aplikacji są zidentyfikowane i konieczne.
1.2: Kontrola bezpieczeństwa nigdy nie jest egzekwowana tylko po stronie klienta, ale na odpowiednich zdalnych
punktach końcowych.
1.3: Architektura wysokiego poziomu dla aplikacji i wszystkich połączonych usług zdalnych została zdefiniowana,
a bezpieczeństwo zostało rozwiązane w tej architekturze.
1.4: Dane uważane za poufne w kontekście aplikacji są jasno określone.
1.5: Wszystkie składniki aplikacji są definiowane pod względem funkcji biznesowych i / lub funkcji
bezpieczeństwa, które zapewniają.
1.6: Opracowano model zagrożenia dla aplikacji i powiązanych usług zdalnych, który identyfikuje potencjalne
zagrożenia i środki zapobiegawcze.
1.7: Wszystkie kontrole bezpieczeństwa mają scentralizowaną implementację.
1.8: Upewnij się, że elementy są oddzielone od siebie za pomocą określonej kontroli bezpieczeństwa, np
segmentacji sieci, reguł zapory lub grup zabezpieczeń opartych na chmurze.
1.9: Istnieje mechanizm wymuszania aktualizacji aplikacji.
1.10: Bezpieczeństwo jest adresowane we wszystkich częściach cyklu rozwoju oprogramowania.
1.11: Wszystkie komponenty aplikacji, biblioteki, moduły, frameworki, platformy i systemy operacyjne są wolne od
znanych luk bezpieczeństwa.
1.12: Istnieją wyraźne zasady dotyczące zarządzania kluczami kryptograficznymi (jeśli istnieją) i egzekwowaniem
cyklu życia kluczy kryptograficznych. Najlepiej postępuj zgodnie ze standardami
zarządzania kluczami, takimi jak NIST SP 800-57.

OWASP ASVS 3.1 [Interpretacja YetiForce]
1.1: Upewnij się, że wszystkie elementy aplikacji są zidentyfikowane i
konieczne.
Architektura i design są gotowe,
używane, i efektywne03
● Identyfikacja wszystkich ekranów[??]
● Stworzenie tablicy [macierzy] łączącej ekrany z
elementami aplikacji.
● Czy potrzebna jest tablica [macierz] elementów
aplikacji na kod [konkretne foldery/pliki] [??]
Architektura jest zdefiniowana, a kod
jest zgodny z architekturą02
● Przełożenie zidentyfikowanych elementów
bezpośrednio do narzędzia służącego do
modelowania
● Weryfikacja kodu pod względem zgodności z
architekturą.
Elementy aplikacji są zidentyfikowane
i mają rację bytu w aplikacji01
● Stworzenie pełnej listy elementów aplikacji i ich
opisanie.
● Opisanie każdego elementu biznesowo [cel,
zastosowanie, powiązanie z innymi elementami]

1.2: Kontrola bezpieczeństwa nigdy nie jest egzekwowana tylko po
stronie klienta, ale na odpowiednich zdalnych punktach końcowych.
● Stworzenie tablicy w której mapujemy ekrany na
sposoby kontroli dla każdego z ekranów.
● Weryfikacja, czy wstępnie dla każdego ekranu
kontrola jest poprawna [??]
● Przełożenie zidentyfikowanych miejsc w których
otrzymujemy dane od klienta do narzędzia służącego
do modelowania systemu.
● Dodanie sposobów kontroli bezpieczeństwa, dla
każdego z tych miejsc i stworzenie wspólnej tablicy
[matrix]
● Opisanie elementów w których następuje
przekazywanie danych przez klienta.
● Opisanie sposobu kontroli danych dla każdego
miejsca w którym przyjmuje się dane - weryfikacja,
czy w każdym miejscu następuje na pewno
weryfikacja danych po stronie aplikacji.

1. 3 Architektura wysokiego poziomu dla aplikacji i wszystkich
połączonych usług zdalnych została zdefiniowana, a bezpieczeństwo
zostało rozwiązane w tej architekturze.
● Uzupełnienie w narzędziu do modelowania ekranów,
opisów dla usług i poszczególnych elementów
architektury a następnie weryfikacja poprawności
działania każdego z elementów względem architektury.
● Przełożenie architektury wysokiego poziomu do
narzędzia służącego modelowaniu.
● Stworzenie tablicy [matrix] mapującej usługi,
architekturę i bezpieczeństwo aby zdefiniować pokrycie
tego co jest w kodzie na to co jest w architekturze..
● Opisanie każdego elementu architektury wysokiego
poziomu oraz opisanie wszystkich elementów
zewnętrznych łączących się z aplikacją
● Opisanie mechanizmów bezpieczeństwa które
występują na wysokim poziomie [np. szyfrowanie].

1. 4 Dane uważane za poufne w kontekście aplikacji są jasno określone.
● Weryfikacja ekranów i miejsc w których użytkownik ma
dostęp do danych poufnych, weryfikacja, czy dane te są
prawidłowo chronione.
● Stworzenie tablicy [matrix] miejsc gdzie dane poufne są
wyświetlane i sposobu ich ochrony.
● Przełożenie wszystkich zidentyfikowanych elementów
[danych poufnych] do narzędzia modelowania i
weryfikacja tych elementów na poziomie zgodności z
kodem.
i mają rację bytu w aplikacji01 ● Opisanie elementów które są poufne.

1.5 Wszystkie składniki aplikacji są definiowane pod względem funkcji
biznesowych i / lub funkcji bezpieczeństwa, które zapewniają.
● Weryfikacja ekranów i miejsc w których użytkownik ma
dostęp do funkcji biznesowych, sprawdzenie ich pod
kątem praktycznym oraz weryfikacja czy są realizowane
funkcje biznesowe.
● Stworzenie tablicy [matrix] ekranów i funkcji
biznesowych jakie są realizowane w ramach ekranu.
● Uzupełnienie wszystkich opisów biznesowych w
narzędziu modelującym.
● Uzupełnienie wszystkich funkcji bezpieczeństwa w
narzędziu modelującym.
● Stworzenie tablicy [matrix] jakie funkcje bezpieczeństwa
występują dla jakich elementów biznesowych.
● Opisanie elementów aplikacji pod względem
biznesowym [czyli jaką pełnią rolę biznesową w tym
również powiązania do innych elementów o ile
występują]
● Opisanie funkcji bezpieczeństwa dla każdego z
elementów aplikacji.

1.6: Opracowano model zagrożenia dla aplikacji i powiązanych usług
zdalnych, który identyfikuje potencjalne zagrożenia i środki
zapobiegawcze.
● Stworzenie tablicy [matrix] ryzyk dla każdego ekranu,
oraz weryfikacja środków zapobiegawczych czy działają
skutecznie w opisanym zakresie.
● Wprowadzenie ryzyk i środków zapobiegawczych do
narzędzia modelującego i stworzenie tablicy [matrix] dla
elementów aplikacji oraz usług zewnętrznych.
● Weryfikacja ryzyk na warstwie kodu [czy kod jest
tworzony zgodnie z dobrymi praktykami]
● Opisanie ryzyk dla elementów aplikacji oraz
zdefiniowanie środków zapobiegawczych.
● Opisanie ryzyk dla usług zdalnych oraz zdefiniowanie
środków zapobiegawczych.

1.7: Wszystkie kontrole bezpieczeństwa mają scentralizowaną
implementację.
● Stworzenie tablicy [matrix] który weryfikuje, czy cały
system [elementy aplikacji, usługi zewnętrzne, ekrany]
przechodzą przez scentralizowany mechanizm kontroli.
● Wprowadzenie mechanizmu kontroli na widok niskiego
poziomu razem z opisem jego działania.
● Weryfikacja mechanizmu na warstwie kodu
i mają rację bytu w aplikacji01 ● Opisanie scentralizowanego mechanizmu kontroli
bezpieczeństwa

1.8: Upewnij się, że elementy są oddzielone od siebie za pomocą
określonej kontroli bezpieczeństwa, np.: segmentacji sieci, reguł
zapory lub grup zabezpieczeń opartych na chmurze.
● Stworzenie tablicy [matrix] która weryfikuje czy elementy
kontroli bezpieczeństwa mają zastosowanie dla każdego
elementu aplikacji, usługi zewnętrznej, ekranu.
● Wprowadzenie wszystkich elementów infrastruktury do
narzędzia modelującego i wizualizacja ich z
uwzględnieniem rzeczywistej konfiguracji.
● Wprowadzenie do narzędzia modelującego reguł
bezpieczeństwa i stworzenie tablicy [matrix] pokrycia
reguł dla każdego elementu infrastruktury.
● Opisanie wszystkich elementów sieci, serwerów,
systemów które są konieczne do poprawnego
uruchomienia aplikacji.
● Opisanie reguł bezpieczeństwa dla każdego
elementu infrastruktury.

1.9: Istnieje mechanizm wymuszania aktualizacji aplikacji.
● Wdrożenie centralnego monitorowania dla wszystkich
komponentów z informacją o bieżącej wersji i aktualnie
dostępnej wersji.
● Wdrożenie mechanizmów, które pozwolą w sposób
automatyczny informować o nowej wersji systemu.
i mają rację bytu w aplikacji01 ● Opisanie mechanizmu aktualizacji oprogramowania.

1.10: Bezpieczeństwo jest adresowane we wszystkich częściach cyklu
rozwoju oprogramowania.
używane, i efektywne03 ● Monitorowanie i wizualizacja testów bezpieczeństwa,
jakości wydajności za pomocą automatycznych narzędzi.
● Dodanie do narzędzia służącego do modelowania, listę
cyklu oprogramowania i zaadresowanie dla każdego z
nich reguł bezpieczeństwa jakie mają być realizowane.
● Wdrażanie efektów [audyty, testy jednostkowe,
wydajność] w kod systemu przed wydaniem kolejnej
wersji systemu.
i mają rację bytu w aplikacji01 ● Opisanie reguł bezpieczeństwa dla danego cyklu
rozwoju oprogramowania.

1.11: Wszystkie komponenty aplikacji, biblioteki, moduły, frameworki,
platformy i systemy operacyjne są wolne od znanych luk
bezpieczeństwa.
● Zbudowanie centralnego monitorowania dla aplikacji,
które będzie weryfikować informacje o istniejących
lukach na poziomie aplikacji i środowiska w którym
aplikacja jest uruchomiona.
● Centralizacja komponentów np. za pomocą Composer,
Yarn, i automatyczna weryfikacja podatności za pomocą
zewnętrznych narzędzi np. https://snyk.io/
i mają rację bytu w aplikacji01 ● Stworzenie listy wszystkich komponentów i ręczne
monitorowanie aktualności każdego z nich.

1.12: Istnieją wyraźne zasady dotyczące zarządzania kluczami kryptograficznymi
(jeśli istnieją) i egzekwowaniem cyklu życia kluczy kryptograficznych. Najlepiej
postępuj zgodnie ze standardami zarządzania kluczami, takimi jak NIST SP 800-
57.
używane, i efektywne03 ● S
jest zgodny z architekturą02 ● Wprowadź mechanizm do narzędzia modelującego
i mają rację bytu w aplikacji01 ● Opisanie logiki działania mechanizmów szyfrujących
oraz zasad przechowywania kluczy.

Materiały źródłowe
1. https://public.yetiforce.com/pdf/OWASP-architektura-bezpieczenstwa-
aplikacji.pdf
2. https://public.yetiforce.com/pdf/OWASP_3.1_EA.pdf (Early Access]
3. https://www.owasp.org/images/d/d1/OWASP_Application_Security_Verification_St
andard_3.0.1_PL.pdf

Czas na pytania :)
YetiForce Sp. z o.o.
ul. Marszałkowska 111
00-102 Warszawa, Polska
www.yetiforce.com
info@yetiforce.com
+48 22 2742937

[Warsaw 25.04.2018] - ASVS - Błażej Pabiszczak, YetiForce

Recommended

Recommended

More Related Content

Similar to [Warsaw 25.04.2018] - ASVS - Błażej Pabiszczak, YetiForce

Similar to [Warsaw 25.04.2018] - ASVS - Błażej Pabiszczak, YetiForce (20)

More from OWASP

More from OWASP (20)

[Warsaw 25.04.2018] - ASVS - Błażej Pabiszczak, YetiForce

Editor's Notes