Jednym z problemów przed którym staje manager bezpieczeństwa lub kierownik projektu, który chce sprawdzić bezpieczeństwo systemu informatycznego to właściwy dobór zakresu testów bezpieczeństwa. Z jednej strony test zbyt ogólny może nie wykryć wielu istotnych słabości, z drugiej strony – dogłębne testy i analizy bezpieczeństwa nie mają ekonomicznego uzasadnienia dla każdego systemu i aplikacji eksploatowanej w firmie. Czas specjalistów, zarówno zewnętrznych jak i wewnętrznych, kosztuje i jest ograniczony, natomiast czas potencjalnych intruzów – nie. Tym bardziej istotne jest optymalne wykorzystanie czasu i budżetu przeznaczonego na testy bezpieczeństwa. Celem prezentacji jest zachęcenie do dyskusji nad tym jak właściwie dobrać zakres testów bezpieczeństwa. Prezentacja z konferencji SEMAFOR 2013, 5-6 marca 2013

1. TESTOWANIE
BEZPIECZEŃSTWA
JAK DOSTOSOWAD ZAKRES DO
REALNYCH ZAGROŻEŃ I BUDŻETU?
Wojciech Dworakowski

2. login: Wojciech Dworakowski
• Testowanie i doradztwo dotyczące
bezpieczeostwa aplikacji i systemów IT
• Działamy od 2003 roku
• Zbadaliśmy bezpieczeostwo ponad 200 systemów
i aplikacji
 Od 2011 – OWASP Poland Chapter Leader

3. Agenda
• Dlaczego testy bezpieczeostwa bywają
nieefektywne?
• Jak zoptymalizowad test bezpieczeostwa?
– Przygotowanie
– Wykonanie
– Raportowanie

4. Czy testy bezpieczeostwa są
efektywne?

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

6. Czy znaleziono wszystkie istotne podatności?
• Np.: Podatności w bibliotekach i frameworkach
• Zazwyczaj nie są uaktualniane
• Bardzo często są pomijane w analizie bezpieczeostwa
• Przykład:
– Podatności frameworków Struts i Spring z 2010
– możliwośd wykonania własnego kodu na serwerze
aplikacji

7. Czy szukano tam gdzie trzeba?
• Aplikacja finansowa
• Raport: XSS, CSRF, …
• ale pominięto
– Błędy kontroli dostępu do danych
– Możliwośd obejścia logiki biznesowej

8. Testy automatem
• Są powtarzalne
• ale mogą wykryd tylko czubek góry lodowej
• Niektórych (nowych) aplikacji nie da się
testowad automatami
• Przykład: Aplikacja GWT. Specjaliści musieli
„udawad” automat

9. False positives
• 1,5 mln linii kodu
• Skaner uruchomiony metodą „fire and forget”
• 100+ podatności o znaczeniu critical / high
• Weryfikacja false positives
– kilka podatności
– o znaczeniu „medium”
• Koszt weryfikacji: 20 man-days

10. Czy test symuluje realne zagrożenia?
Przykład:
• Duży system, wiele ról
• Do testów została wyznaczona rola
„call center”
• Okazało się że do tej roli należy 1 użytkownik

11. Brak planowania
• wrzesieo 2012
• Urząd miasta Tulsa, Oklahoma, USA
• Testy bezpieczeostwa
– Zlecone, okresowe, black-box, bez powiadomienia
zleceniodawcy
• Personel urzędu zidentyfikował te działania jako
„cyber-atak”

12. Brak planowania
The city's website was offline for more than two weeks as an investigation was
conducted and additional security measures were taken. Some website functions, such as
the public meeting agenda postings, are still not working.
90,000 letters had been sent to people who had applied for city jobs or made crime
• wrzesieo 2012
reports online over the past decade, warning them that their personal identification
information might have been accessed.
•The mailing cost the city $20,000, officials said. The letters encouraged those contacted
Urząd miasta Tulsa, Oklahoma, USA
to closely monitor their credit reports for suspicious activity.
•Based on the information available at the time, the city proceeded with the mailings to
Testy bezpieczeostwa
– Zlecone, okresowe, black-box, bez powiadomienia
comply with state notification laws, officials said.
City spokeswoman Michelle Allen said she didn't know why SecurityMetrics wasn't
zleceniodawcy
contacted immediately by city information technology workers after the suspected network
• Personel urzędu zidentyfikował te działania jako
breach. "We are still trying to figure that out," she said, adding that the IT Department
will be having a personnel and organization review.
„cyber-atak”
Tulsa's chief information officer, Tom Golliver, was placed on paid administrative
leave Monday after it was revealed that the city's website hadn't been hacked after all.
Źródło: Tulsa World (http://www.tulsaworld.com/news/article.aspx?subjectid=334&articleid=20121002_11_A1_CUTLIN325691)

13. Jak zoptymalizowad test
bezpieczeostwa?
Właściwie dobrad zakres testów

14. Rosnące koszty usuwania podatności
Utrzymanie
Wdrażanie Testy w trakcie
Wytwarzanie
eksploatacji
Projektowanie Testy odbiorcze
Testy jednostkowe mechanizmów
Definiowanie zabezpieczających
Testowanie koncepcji
(modelowanie zagrożeń)

15. W idealnym świecie
Definiowanie Projektowanie Wykonanie Wdrażanie
• Identyfikacja • Założenia są • Testy jednostkowe • Testy odbiorcze –
ryzyka weryfikowane w zabezpieczeo i w zakresie
• Do kluczowych projekcie poprawności kodu odpowiadającym
ryzyk są dobierane (według przyjętych przyjętym
zabezpieczenia założeo) założeniom
• Zdefiniowanie
założeo

16. Szara rzeczywistośd
Definiowanie Projektowanie Wykonanie Wdrażanie
• Identyfikacja • Założenia są • Testy jednostkowe • Testy odbiorcze –
ryzyka weryfikowane w zabezpieczeo i w zakresie
• Do kluczowych projekcie poprawności kodu odpowiadającym
ryzyk są dobierane (według przyjętych przyjętym
zabezpieczenia założeo) założeniom
• Zdefiniowanie •Brak założeo
założeo
•Brak kwestii niefunkcjonalnych
(SQLi, XSS, CSRF, kontrola dostępu, logika, …)
•Brak uwzględnienia realnych scenariuszy ataku

17. Testy bezpieczeostwa
Zakres
Czas, Budżet

18. Intruz vs Tester
Nieograniczony czas Ograniczony czas
Wiele grup Jeden zespół
Duża motywacja ?

19. Jak zoptymalizowad test
bezpieczeostwa?
Zaplanowanie Wykonanie Raportowanie
• Identyfikacja • Wykonanie w • Jakie scenariusze
ryzyka kolejności od były wykonane?
• Ranking ryzyk najistotniejszych • Kompatybilny z
• Scenariusze ataku • Greybox procesem
usuwania błędów

20. Co zyskujemy?
• Możliwośd (prawie) dowolnego ograniczania
czasu / budżetu
• Jednocześnie – zarządzanie jakością testu
• Zawsze zostaną sprawdzone najistotniejsze
scenariusze
• Koncentracja testujących na konkretnych
celach

21. Zaplanowanie
• Identyfikacja ryzyka
Kto? chciałby atakowad nasz system (Zagrożenia)
Po co? ktoś chciałby atakowad nasz system (Skutki)
• Ranking ryzyk (ekspozycja, motywacja, skutki, …)
• Scenariusze ataku
Jak? zagrożenia mogą osiągnąd cele
== scenariusze testowe == zakres testów bezpieczeostwa

22. O czym trzeba pamiętad?
• Niektóre scenariusze ataku mogą wymagad
sprawdzenia całej funkcjonalności aplikacji
– podatności mogą istnied w dowolnym miejscu
– skutki są zawsze takie same
– Przykłady: SQL injection, XSS, kontrola dostępu, …
• Chyba że stosujemy spójne i weryfikowalne
mechanizmy dla całego systemu
• Optymalizacja = sprawdzenie w kodzie

23. Definiowanie zakresu testów
bezpieczeostwa
Wyjście od ryzyka
• Przedstawid kluczowe ryzyka,
które powinny byd zbadane
• Trzeba we własnym zakresie
przeprowadzid identyfikację i
ranking ryzyk

24. Definiowanie zakresu testów
bezpieczeostwa
Wyjście od ryzyka Wyjście od budżetu
• Przedstawid kluczowe ryzyka, • Kto (z jakim doświadczeniem)?
które powinny byd zbadane • Przez ile czasu ma testowad?
• Trzeba we własnym zakresie • Testujący ma zaplanowad test
przeprowadzid identyfikację i – Scenariusze testowe wynikające z
ranking ryzyk ryzyka!
• Można sterowad czasem,
świadomie ograniczając zakres

25. Wykonanie
• Black box
• White box / grey box
– Dokumentacja,
– Scenariusze testów funkcjonalnych
– Możliwośd konsultacji,
– Wgląd do kodu,

26. Raportowanie
• Forma dopasowana do procesu usuwania
błędów
• Wspólny język
• Dobre zrozumienie kontekstu biznesowego
– Właściwe oszacowanie podatności
– Realne zalecenia
• Informacja o wykonanych testach

27. Podsumowanie
Właściwie dobrany zakres umożliwia znaczne
zoptymalizowanie testów bezpieczeostwa
• Zaplanuj (lub każ zaplanowad) testy
– Identyfikacja zagrożeo i celów  scenariusze testowe
• Wyznacz priorytety
• Udostępniaj informacje (white/grey-box)
• W raporcie wymagaj właściwego szacowania
podatności i realnych zaleceo

28. Nie należy jednak zapominad od ideałach ;)
Utrzymanie
Wdrażanie Testy w trakcie
Wytwarzanie
eksploatacji
Projektowanie Testy odbiorcze
Testy jednostkowe mechanizmów
Definiowanie zabezpieczających
Testowanie koncepcji
(modelowanie zagrożeń)

29. Materiały uzupełniające
• OWASP Application Security Verification
Standard (ASVS)
• OWASP Testing Guide
• OpenSAMM / BSIMM / Microsoft SDL
• Elevation of Privilege (EoP) Card Game

30. Kontakt
http://www.securing.pl Wojciech Dworakowski
e-mail: info@securing.pl wojciech.dworakowski@securing.pl
tel. (12) 4252575 tel. 506 184 550
fax. (12) 4252593