testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu
DESCRIPTION
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 2013TRANSCRIPT
![Page 1: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/1.jpg)
TESTOWANIE BEZPIECZEŃSTWAJAK DOSTOSOWAĆ ZAKRES DO REALNYCH ZAGROŻEŃ I BUDŻETU?
Wojciech Dworakowski
![Page 2: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/2.jpg)
login: Wojciech Dworakowski • Testowanie i doradztwo dotyczące
bezpieczeństwa aplikacji i systemów IT• Działamy od 2003 roku• Zbadaliśmy bezpieczeństwo ponad 200 systemów
i aplikacji Od 2011 – OWASP Poland Chapter Leader
![Page 3: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/3.jpg)
Agenda• Dlaczego testy bezpieczeństwa bywają
nieefektywne?• Jak zoptymalizować test bezpieczeństwa?– Przygotowanie– Wykonanie– Raportowanie
![Page 4: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/4.jpg)
Czy testy bezpieczeństwa są efektywne?
![Page 5: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/5.jpg)
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)?
![Page 6: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/6.jpg)
Czy znaleziono wszystkie istotne podatności?
• Np.: Podatności w bibliotekach i frameworkach• Zazwyczaj nie są uaktualniane• Bardzo często są pomijane w analizie bezpieczeństwa• Przykład: – Podatności frameworków Struts i Spring z 2010– możliwość wykonania własnego kodu na serwerze
aplikacji
![Page 7: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/7.jpg)
Czy szukano tam gdzie trzeba?• Aplikacja finansowa• Raport: XSS, CSRF, …• ale pominięto – Błędy kontroli dostępu do danych– Możliwość obejścia logiki biznesowej
![Page 8: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/8.jpg)
Testy automatem• Są powtarzalne• ale mogą wykryć tylko czubek góry lodowej• Niektórych (nowych) aplikacji nie da się
testować automatami• Przykład: Aplikacja GWT. Specjaliści musieli
„udawać” automat
![Page 9: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/9.jpg)
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
![Page 10: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/10.jpg)
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
![Page 11: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/11.jpg)
Brak planowania
• wrzesień 2012• Urząd miasta Tulsa, Oklahoma, USA• Testy bezpieczeństwa– Zlecone, okresowe, black-box, bez powiadomienia
zleceniodawcy• Personel urzędu zidentyfikował te działania jako
„cyber-atak”
![Page 12: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/12.jpg)
Brak planowania
• wrzesień 2012• Urząd miasta Tulsa, Oklahoma, USA• Testy bezpieczeństwa– Zlecone, okresowe, black-box, bez powiadomienia
zleceniodawcy• Personel urzędu zidentyfikował te działania jako
„cyber-atak”
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 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 to closely monitor their credit reports for suspicious activity.
Based on the information available at the time, the city proceeded with the mailings to comply with state notification laws, officials said.
City spokeswoman Michelle Allen said she didn't know why SecurityMetrics wasn't contacted immediately by city information technology workers after the suspected network breach. "We are still trying to figure that out," she said, adding that the IT Department will be having a personnel and organization review.
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)
![Page 13: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/13.jpg)
Jak zoptymalizować test bezpieczeństwa?
Właściwie dobrać zakres testów
![Page 14: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/14.jpg)
Rosnące koszty usuwania podatności
Definiowanie
Projektowanie
Wytwarzanie
Wdrażanie
Utrzymanie
Testowanie koncepcji(modelowanie zagrożeń)
Testy jednostkowe mechanizmów zabezpieczających
Testy odbiorcze
Testy w trakcie eksploatacji
![Page 15: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/15.jpg)
W idealnym świecie
Definiowanie
• Identyfikacja ryzyka
• Do kluczowych ryzyk są dobierane zabezpieczenia
• Zdefiniowanie założeń
Projektowanie
• Założenia są weryfikowane w projekcie
Wykonanie
• Testy jednostkowe zabezpieczeń i poprawności kodu (według przyjętych założeń)
Wdrażanie
• Testy odbiorcze – w zakresie odpowiadającym przyjętym założeniom
![Page 16: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/16.jpg)
Szara rzeczywistość
Definiowanie
• Identyfikacja ryzyka
• Do kluczowych ryzyk są dobierane zabezpieczenia
• Zdefiniowanie założeń
Projektowanie
• Założenia są weryfikowane w projekcie
Wykonanie
• Testy jednostkowe zabezpieczeń i poprawności kodu (według przyjętych założeń)
Wdrażanie
• Testy odbiorcze – w zakresie odpowiadającym przyjętym założeniom
• Brak założeń• Brak kwestii niefunkcjonalnych
(SQLi, XSS, CSRF, kontrola dostępu, logika, …)• Brak uwzględnienia realnych scenariuszy ataku
![Page 17: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/17.jpg)
Testy bezpieczeństwa
ZakresCzas, Budżet
![Page 18: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/18.jpg)
Intruz vs Tester
Nieograniczony czasWiele grup
Duża motywacja
Ograniczony czasJeden zespół?
![Page 19: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/19.jpg)
Jak zoptymalizować test bezpieczeństwa?
Zaplanowanie
• Identyfikacja ryzyka
• Ranking ryzyk • Scenariusze ataku
Wykonanie
• Wykonanie w kolejności od najistotniejszych
• Greybox
Raportowanie
• Jakie scenariusze były wykonane?
• Kompatybilny z procesem usuwania błędów
![Page 20: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/20.jpg)
Co zyskujemy?• Możliwość (prawie) dowolnego ograniczania
czasu / budżetu• Jednocześnie – zarządzanie jakością testu• Zawsze zostaną sprawdzone najistotniejsze
scenariusze• Koncentracja testujących na konkretnych
celach
![Page 21: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/21.jpg)
• Identyfikacja ryzyka Kto? chciałby atakować nasz system (Zagrożenia)
Po co? ktoś chciałby atakować nasz system (Skutki)
• Ranking ryzyk (ekspozycja, motywacja, skutki, …)• Scenariusze ataku
Jak? zagrożenia mogą osiągnąć cele== scenariusze testowe == zakres testów bezpieczeństwa
Zaplanowanie
![Page 22: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/22.jpg)
O czym trzeba pamiętać?• Niektóre scenariusze ataku mogą wymagać
sprawdzenia całej funkcjonalności aplikacji– podatności mogą istnieć 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
![Page 23: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/23.jpg)
Definiowanie zakresu testów bezpieczeństwa
Wyjście od ryzyka• Przedstawić kluczowe ryzyka,
które powinny być zbadane • Trzeba we własnym zakresie
przeprowadzić identyfikację i ranking ryzyk
![Page 24: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/24.jpg)
Definiowanie zakresu testów bezpieczeństwa
Wyjście od ryzyka• Przedstawić kluczowe ryzyka,
które powinny być zbadane • Trzeba we własnym zakresie
przeprowadzić identyfikację i ranking ryzyk
Wyjście od budżetu• Kto (z jakim doświadczeniem)?• Przez ile czasu ma testować?• Testujący ma zaplanować test
– Scenariusze testowe wynikające z ryzyka!
• Można sterować czasem, świadomie ograniczając zakres
![Page 25: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/25.jpg)
• Black box• White box / grey box–Dokumentacja, – Scenariusze testów funkcjonalnych–Możliwość konsultacji, –Wgląd do kodu,
Wykonanie
![Page 26: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/26.jpg)
• 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
Raportowanie
![Page 27: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/27.jpg)
PodsumowanieWłaściwie dobrany zakres umożliwia znaczne zoptymalizowanie testów bezpieczeństwa
• Zaplanuj (lub każ zaplanować) testy– Identyfikacja zagrożeń i celów scenariusze testowe
• Wyznacz priorytety• Udostępniaj informacje (white/grey-box)• W raporcie wymagaj właściwego szacowania
podatności i realnych zaleceń
![Page 28: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/28.jpg)
Nie należy jednak zapominać od ideałach ;)
Definiowanie
Projektowanie
Wytwarzanie
Wdrażanie
Utrzymanie
Testowanie koncepcji(modelowanie zagrożeń)
Testy jednostkowe mechanizmów zabezpieczających
Testy odbiorcze
Testy w trakcie eksploatacji
![Page 29: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/29.jpg)
Materiały uzupełniające• OWASP Application Security Verification
Standard (ASVS)• OWASP Testing Guide• OpenSAMM / BSIMM / Microsoft SDL• Elevation of Privilege (EoP) Card Game
![Page 30: Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetu](https://reader033.vdocuments.net/reader033/viewer/2022061223/54c3e7d24a795993108b4593/html5/thumbnails/30.jpg)
Kontakt
http://www.securing.pl e-mail: [email protected]. (12) 4252575fax. (12) 4252593
Wojciech [email protected]. 506 184 550