Prezentacja z konferencji SEMAFOR 2014. Prezentacja ma na celu przedstawienie standardu weryfikacji bezpieczeństwa aplikacji ASVS (Application Security Verification Standard). Standard ten można stosować już na etapie definiowania wymagań w celu ustalenia wymagań dotyczących zabezpieczeń (również niefunkcjonalnych). Na etapie weryfikacji umożliwia on sprawdzenie czy są stosowane zasady dobrej praktyki i pozwala audytorowi na wypowiedzenie się o tym co jest poprawne a nie tylko na koncentrowanie się na błędach, jak to ma miejsce przy nieustandaryzowanych testach bezpieczeństwa. Ponadto stosowanie ASVS powoduje sprecyzowanie zakresu testów bezpieczeństwa a co za tym idzie sprowadzenie porównywanych ofert na testy weryfikacyjne do wspólnego mianownika. Warto również podkreślić, że ASVS ma formę listy kontrolnej podzielonej na poziomy w zależności od ryzyka, w związku z tym zakres weryfikacji może być dobrany adekwatnie do specyfiki aplikacji. Standard ten został stworzony w roku 2009 roku w ramach projektu OWASP (Open Web Application Security Project) i został przetłumaczony na kilkanaście języków, w tym polski. W tym roku ukazuje się nowa aktualizacja standardu ASVS i na tej nowej wersji będzie skupiona prezentacja.

1. Application Security
Verification Standard
Wojciech Dworakowski,
SecuRing

2. login: Wojciech Dworakowski
• OWASP Poland Chapter Leader
• OWASP = Open Web Application Security Project
• Cel: Podnoszenie świadomości w zakresie
bezpieczeostwa aplikacji
• Testowanie i doradztwo dotyczące
bezpieczeostwa aplikacji i systemów IT
• od 2003 roku / ponad 300 systemów i aplikacji

3. Agenda
• Bezpieczeostwo aplikacji – Wyzwania
– Definiowanie wymagao
– Zakres testów bezpieczeostwa
• Przedstawienie ASVS
• Case study
• Podsumowanie

4. BEZPIECZEŃSTWO
APLIKACJI -
WYZWANIA

5. „Wishful thinking”
Sponsor projektu
• To jasne że ma byd
bezpiecznie!
• Mamy dobry zespół
• Wykonawcą jest
doświadczoną firmą, z
pewnością wiedzą co
robią
Project Manager
• Zatrudniamy
doświadczonych
programistów
• Nie otrzymaliśmy
żadnych
szczegółowych
wytycznych
• Pewnie ryzyko będzie
ograniczone innymi
metodami
Programista
• Bezpieczeostwo
zapewnia framework
• Ja nie zajmuje się
bezpieczeostwem tylko
programowaniem

6. Hipotetyczny przykład
Aplikacja płatności mobilnych
• Transmisja jest zabezpieczona SSL-em
• …ale certyfikat serwera nie jest weryfikowany
• Czy może to wykorzystad intruz, który ma
dostęp do tej samej sieci WiFi?
• Jaki będzie koszt poprawienia tego błędu?

7. Przykład 2
• Historia transakcji przechowywana offline, w
postaci szyfrowanej
• Zarówno do odblokowania offline jak i do
uwierzytelnienia online służy 4-cyfrowy PIN
• Aplikacja mobilna blokuje się po 3 próbach
• Czy może to wykorzystad intruz który
„pożyczył” telefon?
• Jaki będzie koszt poprawienia tego błędu?

8. Definiowanie
• Identyfikacja
ryzyka
• Do kluczowych
ryzyk są
dobierane
zabezpieczenia
• Zdefiniowanie
wymagao
Projektowanie
• Wymagania są
weryfikowane w
projekcie
Wykonanie
• Testy jednostkowe
zabezpieczeo i
poprawności kodu
(według
przyjętych
wymagao)
Wdrażanie
• Testy odbiorcze –
w zakresie
odpowiadającym
przyjętym
wymaganiom
Wymagania
Software Security Development
Lifecycle

9. Jak definiowad wymagania?
• Najlepiej na podstawie analizy ryzyka
– Modelowanie zagrożeo
• Czy istnieje „droga na skróty”?
– Można oprzed się na ogólnych wytycznych
(„zasadach dobrej praktyki”)
– Trzeba pamiętad że są one dobre w ogólnym
przypadku
– …a każda aplikacja ma swoją specyfikę

10. Zakres testów bezpieczeostwa
• Testy „ad hoc”
• Znaleziono N podatności
ale…
• Czy znaleziono wszystkie istotne podatności?
• Czy testy objęły wszystkie istotne zagrożenia?
• Czy szukano tam gdzie trzeba?
• Czy test symuluje realne zagrożenie (atak)?


11. Definiowanie zakresu testów
bezpieczeostwa
• Najlepiej – w oparciu o wymagania lub ryzyko
– Więcej: http://www.slideshare.net/wojdwo/testowanie-
bezpieczestwa-jak-dostosowa-zakres-do-realnych-zagroe-i-budetu
• Droga na skróty
– Checklista ogólnych „zasad dobrej praktyki”
– Dostosowana do specyfiki aplikacji

12. APPLICATION SECURITY
VERIFICATION STANDARD

13. ASVS
• Projekt fundacji OWASP
– Wersja 1: w 2007 (tłumaczenie na polski)
– Wersja 2: 2013
https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Projec
t#tab=Downloads
• Lista kontrolna typowych zabezpieczeo
• Pogrupowana na zakresy (uwierzytelnienie,
autoryzacja, walidacja, …)
• Kilka poziomów

14. Poziomy ASVS
• 2007: W zależności od metody badania
• 2013: W zależności od profilu ryzyka
Dobór metody badania:
tak żeby osiągnąd cel

15. Poziomy ASVS
• Level 0 (Cursory) – aplikacja przeszła jakiś
(nieuporządkowany) rodzaj weryfikacji.
• Level 1 (Opportunistic) – odpowiednio chroni się przed
podatnościami które są łatwe do wykrycia.
• Level 2 (Standard) – j.w. + odpowiednio chroni się przed
powszechnymi podatnościami, których istnienie powoduje
średnie lub wysokie ryzyko.
• Level 3 (Advanced) – j.w. + odpowiednio chroni się przed
wszystkimi zaawansowanymi podatnościami oraz wykazuje
zasady dobrego projektowania.

16. Grupy wymagao (rozdziały)
• V1. Authentication
• V2. Session Management
• V3. Access Control
• V4. Input Validation
• V5. Cryptography (at Rest)
• V6. Error Handling and
Logging
• V7. Data Protection
• V8. Communication Security
• V9. HTTP Security
• V10. Malicious Controls
• V11. Business Logic
• V12. Files and Resources
• V13. Mobile

19. Który poziom?
• Zależy od ekspozycji aplikacji na ryzyko
• Ściąga w dodatku A

20. ASVS trzeba dostosowad do specyfiki
aplikacji
• Nie wszystkie wymagania zawsze mają sens
• Nie jest to lista kompletna dla każdej aplikacji,
tylko zbiór uniwersalnych zasad dobrej
praktyki

21. Podsumowanie
• ASVS pomaga uporządkowad bezpieczeostwo
aplikacji
– Definiowanie wymagao (w tym niefunkcjonalnych)
– Określenie zakresu testów bezpieczeostwa
• Baza, punkt wyjściowy
• Listę wymagao / sprawdzeo trzeba
dostosowywad do specyfiki aplikacji