Bezpieczeństwo aplikacji Czy musi być aż tak źle? 2012-10-24 Wojciech Dworakowski Poland Chapter Leader SecuRing Copyright The Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the License. The Foundation http://www.owasp.org
whoami Wojciech Dworakowski Od 2003 - SecuRing Zarządzanie zespołem testującym bezpieczeństwo aplikacji i systemów IT Od 2011 Poland Chapter Leader
Open Web Application Security Project Misja: Poprawa stanu bezpieczeństwa aplikacji 100+ Local Chapters 1500+ Members 20000+ uczestników spotkań Projekty: dokumentacja, narzędzia w Polsce Od 2007 Regularne spotkania w Krakowie i Warszawie http://www.owasp.org/index.php/poland 3
Agenda Bezpieczeństwo aplikacji obecny stan Przykłady Jak można to zrobić lepiej? Jak może pomóc? Podsumowanie 4
Czy podatności w aplikacjach są faktycznym problemem? Verizon Data Breach Report Investigations 2010
Przykład 1: SQL injection Aplikacja o znaczeniu strategicznym Kilkadziesiąt tysięcy użytkowników Blisko 1 mln linii kodu Testy penetracyjne blackbox SQL injection Przegląd kodu sklejanie SQL Usunięcie źródła problemu w praktyce niemożliwe Łatanie Testy Kolejne podatności Łatanie Koszt: Łatanie, wizerunek, spór z klientem
Przykład 2: Kontrola dostępu Aplikacja webowa Testy penetracyjne Całkowity brak kontroli dostępu do danych Developer twierdził że kontrola dostępu jest ale nie włączona Włączenie zajęło kilka tygodni ;) Po włączeniu znalezione kolejne przypadki Koszt: Opóźnienie, Kary umowne, wizerunek
Grafika: technabob.com Przykład 3: Aplikacja mobilna Uwierzytelnienie za pomocą PIN Dodatkowo na urządzeniu dane w postaci zaszyfrowanej Klucz szyfrowania generowany na podstawie PIN Efekt Klucz można crackować off-line 4 cyfry = 10 tys. Prób = kilka minut Koszt usunięcia: Zmiana algorytmu (po wdrożeniu)
Nowe technologie nowe źródła zagrożeń AJAX HTML5 Aplikacje mobilne NFC
Jak można to zrobić lepiej? Rosnące koszty usuwania podatności Wdrażanie Utrzymanie Projektowanie Wytwarzanie Definiowanie Wpisanie bezpieczeństwa w cały cykl rozwojowy aplikacji SDLC (Secuity in Development Lifecycle) Rosnące koszty usuwania podatności
Od czego zacząć? [rysunek: Zagrożenie / Ryzyko / Podatność / Zabezpieczenie] Żeby planować zabezpieczenia trzeba znać zagrożenia i wpływ na ryzyko
Modelowanie zagrożeń Modelowanie zagrożeń Zidentyfikowanie zagrożeń Scenariusze ataków Dobranie zabezpieczeń Założenia dotyczące bezpieczeństwa Scenariusze testowe Niezbędne: Doświadczenie Umiejętność wczucia się w rolę atakującego
Co dalej? Kontrola podczas implementacji Testy przed wdrożeniem Szkolenie programistów Również PM-ów, architektów, testerów
Testowanie bezpieczeństwa Ważne - bo może zawieść implementacja założeń Na podstawie zidentyfikowanych zagrożeń Wg priorytetów NIE black-box! Pamiętaj o uwzględnieniu całego środowiska Atakowany jest cały system a nie jeden komputer / serwer / aplikacja / urządzenie / Niezbędne doświadczenie
Jak może pomóc? Documentation Top10 Tools DETECT PROTECT LIFE-CYCLE ASVS Testing Guide Code Review Guide WebScarab Zed Attack Proxy JBroFuzz Development Guide Secure Coding Practices Quick Reference ESAPI AppSensor ModSecurity Core Ruleset OpenSAMM WebGoat Education Project ~140+ Projektów https://www.owasp.org/index.php/category:_project
Źródło: www.owasp.org OpenSAMM http://www.opensamm.org Software Assurance Maturity Model Model dojrzałości dotyczący bezpieczeństwa w procesie wytwarzania oprogramowania 4 Business Functions x 3 Security Practices Każda z 12 security practices ma zdefiniowane 3 poziomy dojrzałości + poziom 0 jako punkt wyjściowy
OpenSAMM http://www.opensamm.org Dla każdej praktyki / poziomu dojrzałości (4x3x3) opisane są: Cel Czynności Pytania do audytu Rezultat wdrożenia Miara sukcesu Wpływ na koszty, niezbędny personel
Application Security Verification Standard (ASVS) Testowanie zabezpieczeń, które chronią przed typowymi zagrożeniami Celem oceny wg ASVS nie jest poszukiwanie podatności ale sprawdzenie czy istnieją odpowiednie zabezpieczenia zasady dobrej praktyki
ASVS c.d. Zastosowanie: Jako wzorzec przy weryfikacji (da się zastosować jako wzorzec audytowy) Jako wytyczne dla developerów Jako specyfikacja w kontraktach na wykonanie aplikacji Jest dostępny po polsku! Owasp.org -> ASVS -> Downloads -> ASVS in Polish http://owasp-asvs.googlecode.com/files/asvs-webapprelease-2009-pl.pdf
ASVS Poziomy weryfikacji Poziom 1 Weryfikacja automatyczna 1A Dynamic Scan 1B Source Code Scan Poziom 2 Weryfikacja ręczna 2A Penetration Test 2B Code Review Poziom 3 Weryfikacja projektu L2 + wszystkie biblioteki i serwisy + modelowanie zagrożeń i weryfikacja projektu Poziom 4 Weryfikacja wewnętrzna L3 + framework, narzędzia, etc + weryfikacja możliwości wprowadzenia złośliwego kodu Źródło: ASVS http://code.google.com/p/owasp-asvs/wiki/approach
Podsumowanie Myśl o bezpieczeństwie! od planowania po wdrożenie i eksploatację systemu Zaplanuj bezpieczeństwo Identyfikacja zagrożeń Planowanie zabezpieczeń Testuj przed Modelowanie zagrożeń i po Testy penetracyjne, przeglądy konfiguracji,... Niezbędne - doświadczenie i mentalność atakującego
Zapraszamy na spotkania Poland Wstęp wolny Streaming Kraków Wstępny termin: 2012-11-21 (środa), 18:00 Krakowski Park Technologiczny Al. Jana Pawła II 41 L, III piętro Warszawa TBD https://www.owasp.org/index.php/poland Lista mailingowa Facebook: Poland Local Chapter Twitter: @owasppoland