Wprowadzenie do
OWASP ASVS v3
Michał Staruch
Grudzień 2015
OWASP
- Top 10
- Testing Guide
- Application Security Verification Standard
- Software Assurance Maturity Model
- Zed Attack Proxy
Open Web Application Security Project
ASVS
Application Security Verification Standard
- lista konkretnych wymagań
- zrozumiały dla inżynierów
- do wyboru 3 poziomy
- 16 sekcji
- aktywnie rozwijany
- usprawniany na konferencjach AppSec
- wersja 3 ogłoszona 9 X 2015
Zastosowania
- techniczne wytyczne dla architektów IT
- poradnik dla programistów, administratorów
- checklista dla osób weryfikujących zabezpieczenia
- uświadamianie inżynierów o zagrożeniach
- standaryzowanie wymagań w projektach
- zapewnianie zgodności (PCI DSS)
Poziom 1
aplikacje z dostępem do sieci
- finanse, ubezpieczenia
- produkcja, transport, technologie
- energetyka, telekomunikacja
- urzędy, służby, wojsko
- służba zdrowia
- sklepy, katering, hotele
Poziom 2
- przetwarzają dane osobowe
- przetwarzają numery kart płatniczych
- realizują płatności na niewielką skalę
- umożliwiają dostęp do informacji o stanie zdrowia
- umożliwiają dostęp do bazy pracowników
- umożliwiają dostęp do tajemnic przedsiębiorstwa
- umożliwiają dostęp do danych z klauzulą "poufne"
aplikacje, które:
Poziom 3
- umożliwiają dostęp do dużych zbiorów danych osobowych
- realizują płatności na dużą skalę
- pozwalają sterować urządzeniami mogącymi
zagrozić życiu lub zdrowiu człowieka - umożliwiają dostęp do dużych baz transakcji finansowych
- umożliwiają dostęp do danych z klauzulą "tajne"
aplikacje, które:
V1 Architektura
przykłady:
| id | opis | lvl |
|---|---|---|
| 1.1 | wszystkie komponenty aplikacji są znane i potrzebne |
1 |
| 1.3 | aplikacja posiada zdefiniowaną architekturę wysokiego poziomu |
2 |
| 1.7 | mechanizmy kontrolne dot. bezpieczeństwa posiadają scentralizowaną implementację |
3 |
V2 Uwierzytelnianie
przykłady:
| id | opis | lvl |
|---|---|---|
| 2.7 | aplikacja umożliwia stosowanie długich i złożonych haseł |
1 |
| 2.13 | hasła dostępowe są szyfrowane w sposób odporny na ataki typu brute force |
2 |
| 2.29 | tajne dane, klucze API, ani hasła nie są przechowywane razem z kodem źródłowym |
3 |
V7 Kryptografia
przykłady:
| id | opis | lvl |
|---|---|---|
| 7.7 | używane przez aplikację algorytmy kryptograficzne mają certyfikat FIPS 140-2 |
1 |
| 7.12 | dane osobowe są przechowywane i przesyłane w zaszyfrowanej formie |
2 |
| 7.15 | liczby losowe mają odpowiedni poziom entropii, nawet podczas obciążenia aplikacji |
3 |
V8 Obsługa błędów, logi
przykłady:
| id | opis | lvl |
|---|---|---|
| 8.1 | komunikaty błędów nie zawierają informacji ułatwiających atak (np. wersji komponentów) |
1 |
| 8.3 | aplikacja umożliwia logowanie wyników działania mechanizmów bezpieczeństwa |
2 |
| 8.11 | logi dotyczące bezpieczeństwa posiadają mechanizmy weryfikacji integralności | 3 |
V10 Komunikacja
przykłady:
| id | opis | lvl |
|---|---|---|
| 10.3 | wszystkie połączenia, które są uwierzytelniane lub dotyczą wrażliwych danych / funkcji są chronione przez TLS, bez możliwości rezygnacji z TLS |
1 |
| 10.14 | podczas weryfikacji certyfikatów sprawdzany jest status odwołania certyfikatu (OCSP, CRL) |
1 |
| 10.12 | produkcyjny URL aplikacji został zgłoszony na listy HSTS preload |
3 |
V15 Logika biznesowa
przykłady:
| id | opis | lvl |
|---|---|---|
| 15.1 | wykonywane są wyłącznie akcje zgodne ze zdefiniowaną sekwencją procesu, zlecane w realistycznym dla człowieka czasie |
2 |
| 15.2 | ograniczenia biznesowe są narzucane per użytkownik, z konfigurowalnymi alarmami i automatycznymi reakcjami na nietypowe ataki |
2 |
V16 Pliki i zasoby
przykłady:
| id | opis | lvl |
|---|---|---|
| 16.8 | aplikacja nie wykonuje danych otrzymanych z niezaufanych źródeł |
1 |
| 16.9 | aplikacja musi działać w przeglądarkach bez dodatkowych wtyczek (Flash, Java, itp.) |
1 |
V17 Urządzenia mobilne
przykłady:
| id | opis | lvl |
|---|---|---|
| 17.1 | identyfikatory dostępne dla innych aplikacji nie są używane jako tokeny uwierzytelniające |
1 |
| 17.2 | wrażliwe dane nie są zapisywane na współdzielonych magazynach danych, które mogą być nieszyfrowane (np. karta SD) |
1 |
| 17.6 | aplikacja żąda minimalnych uprawnień, które wynikają z założonej funkcjonalności |
2 |
Jak wdrażać?
- Uzyskać poparcie kierownictwa.
- Wyznaczyć opiekuna programu.
- Uświadomić PM-ów, architektów,
leaderów zespołów. - Doprecyzować wymagania ASVS.
- Zacząć od poziomu 1.
- Korzystać z Top 10, Testing Guide.
- Organizować konsultacje, szkolenia.
- Weryfikować zgodność.