bezpieczeństwo aplikacji - czy musi być aż tak źle?
TRANSCRIPT
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
The OWASP Foundation
OWASP
http://www.owasp.org
Bezpieczeństwo aplikacji Czy musi być aż tak źle?
Wojciech Dworakowski
OWASP Poland Chapter Leader
SecuRing 2012-10-24
OWASP
whoami
Wojciech Dworakowski
Od 2003 - SecuRing
• Zarządzanie zespołem testującym bezpieczeństwo aplikacji i systemów IT
Od 2011 – OWASP Poland Chapter Leader
OWASP 3
Open Web Application Security Project
Misja: Poprawa stanu bezpieczeństwa aplikacji
100+ Local Chapters
1500+ OWASP Members
20000+ uczestników spotkań
Projekty: dokumentacja, narzędzia
OWASP w Polsce
Od 2007
Regularne spotkania w Krakowie i Warszawie
http://www.owasp.org/index.php/Poland
OWASP 4
Agenda
Bezpieczeństwo aplikacji – obecny stan
Przykłady
Jak można to zrobić lepiej?
Jak może pomóc OWASP?
Podsumowanie
OWASP
Czy podatności w aplikacjach są faktycznym problemem?
Verizon Data Breach Report Investigations 2010
OWASP
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
OWASP
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
OWASP
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)
Gra
fika
: te
chn
ab
ob
.co
m
OWASP
Nowe technologie – nowe źródła zagrożeń
AJAX
HTML5
Aplikacje mobilne
NFC
…
OWASP
Jak można to zrobić lepiej?
Definiowanie
Projektowanie
Wytwarzanie
Wdrażanie Utrzymanie
Rosnące koszty usuwania podatności
Rosnące koszty usuwania
podatności
Wpisanie bezpieczeństwa w cały
cykl rozwojowy aplikacji SDLC (Secuity in Development Lifecycle)
OWASP
Od czego zacząć?
[rysunek: Zagrożenie / Ryzyko / Podatność / Zabezpieczenie]
Żeby planować zabezpieczenia trzeba znać zagrożenia
• …i wpływ na ryzyko
OWASP
Modelowanie zagrożeń
• Zidentyfikowanie zagrożeń
• Scenariusze ataków
• Dobranie zabezpieczeń
• Założenia dotyczące bezpieczeństwa
• Scenariusze testowe
Mo
delo
wa
nie
zag
rożeń
Niezbędne:
• Doświadczenie
• Umiejętność wczucia się w rolę atakującego
OWASP
Co dalej?
Kontrola podczas implementacji
Testy przed wdrożeniem
Szkolenie programistów
Również PM-ów, architektów, testerów
OWASP
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
OWASP
Jak może pomóc OWASP?
DETECT PROTECT LIFE-CYCLE
Documentation Top10
ASVS
Testing Guide
Code Review Guide
Development Guide
Secure Coding Practices – Quick Reference
OpenSAMM
Tools WebScarab
Zed Attack Proxy
JBroFuzz
ESAPI
AppSensor
ModSecurity Core Ruleset
WebGoat
Education Project
~140+ Projektów https://www.owasp.org/index.php/Category:OWASP_Project
OWASP
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
Źródło: www.owasp.org
OWASP
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
OWASP
OWASP 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
OWASP
OWASP 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-webapp-release-2009-pl.pdf
OWASP
OWASP ASVS – Poziomy weryfikacji
Źródło: OWASP ASVS http://code.google.com/p/owasp-asvs/wiki/Approach
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
OWASP
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
OWASP
Zapraszamy na spotkania OWASP 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: OWASP Poland Local Chapter
Twitter: @owasppoland