TESTOWANIE BEZPIECZEŃSTWAJAK DOSTOSOWAĆ ZAKRES DO REALNYCH ZAGROŻEŃ I BUDŻETU?

Wojciech Dworakowski

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

Agenda• Dlaczego testy bezpieczeństwa bywają

nieefektywne?• Jak zoptymalizować test bezpieczeństwa?– Przygotowanie– Wykonanie– Raportowanie

Czy testy bezpieczeństwa są efektywne?

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)?

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

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

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

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

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

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”

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)

Jak zoptymalizować test bezpieczeństwa?

Właściwie dobrać zakres testów

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

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

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

Testy bezpieczeństwa

ZakresCzas, Budżet

Intruz vs Tester

Nieograniczony czasWiele grup

Duża motywacja

Ograniczony czasJeden zespół?

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

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

• 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

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

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

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

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

Wykonanie

• 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

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ń

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

Materiały uzupełniające• OWASP Application Security Verification

Standard (ASVS)• OWASP Testing Guide• OpenSAMM / BSIMM / Microsoft SDL• Elevation of Privilege (EoP) Card Game

Kontakt

http://www.securing.pl e-mail: info@securing.pltel. (12) 4252575fax. (12) 4252593

Wojciech Dworakowskiwojciech.dworakowski@securing.pltel. 506 184 550