Bezpieczeństwo aplikacji Czy musi być aż tak źle? OWASP The OWASP Foundation

Transkrypt

1 Bezpieczeństwo aplikacji Czy musi być aż tak źle? 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

2 whoami Wojciech Dworakowski Od SecuRing Zarządzanie zespołem testującym bezpieczeństwo aplikacji i systemów IT Od 2011 Poland Chapter Leader

3 Open Web Application Security Project Misja: Poprawa stanu bezpieczeństwa aplikacji 100+ Local Chapters Members uczestników spotkań Projekty: dokumentacja, narzędzia w Polsce Od 2007 Regularne spotkania w Krakowie i Warszawie 3

4 Agenda Bezpieczeństwo aplikacji obecny stan Przykłady Jak można to zrobić lepiej? Jak może pomóc? Podsumowanie 4

5 Czy podatności w aplikacjach są faktycznym problemem? Verizon Data Breach Report Investigations 2010

6 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

7 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

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

9 Nowe technologie nowe źródła zagrożeń AJAX HTML5 Aplikacje mobilne NFC

10 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

11 Od czego zacząć? [rysunek: Zagrożenie / Ryzyko / Podatność / Zabezpieczenie] Żeby planować zabezpieczenia trzeba znać zagrożenia i wpływ na ryzyko

12 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

13 Co dalej? Kontrola podczas implementacji Testy przed wdrożeniem Szkolenie programistów Również PM-ów, architektów, testerów

14 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

15 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

16 Źródło: OpenSAMM 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

17 OpenSAMM 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

18 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

19 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

20 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

21 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

22 Zapraszamy na spotkania Poland Wstęp wolny Streaming Kraków Wstępny termin: (środa), 18:00 Krakowski Park Technologiczny Al. Jana Pawła II 41 L, III piętro Warszawa TBD Lista mailingowa Facebook: Poland Local Chapter