Jak tworzyć bezpieczne aplikacje?
42
Jak tworzyć (lub zamawiać) bezpieczne aplikacje? Wojciech Dworakowski
-
Upload
securing -
Category
Technology
-
view
1.776 -
download
1
description
Prezentacja z konferencji ISSA InfoTRAMS Holistic Application Security Od kilku lat na świecie jest promowane podejście polegające na wpisaniu bezpieczeństwa w cały cykl rozwojowy oprogramowania. W polskiej praktyce, nadal kwestie związane z bezpieczeństwem najczęściej poruszane są na dopiero na końcu projektu, tuż przed wdrożeniem gdy wykonywane są testy bezpieczeństwa. Bardzo często takie podejście skutkuje znacznymi kosztami usuwania błędów i sporym "zamieszaniem" w projekcie, ale o tym firma przekonuje się dopiero "za 5 dwunasta", po wykonaniu testów bezpieczeństwa. Z reguły, usuwanie podatności na tym etapie projektu polega na "gaszeniu pożarów" i przyklejaniu kolejnych łatek zamiast wprowadzenia systemowych zmian. W rezultacie, w dalszym cyklu życia, po wprowadzeniu zmian funkcjonalnych wypływają nowe przypadki wystąpienia starych błędów. Jak to zmienić? Czy zastosowanie podstawowych zasad tworzenia bezpiecznego oprogramowania jest faktycznie takie skomplikowane jak by mogło się wydawać? W trakcie prezentacji zostaną przedstawione metodyki wprowadzania bezpieczeństwa do całego cyklu rozwojowego oprogramowania (na przykładzie OWASP SAMM), również z uwzględnieniem sytuacji, gdy stworzenie aplikacji zlecane jest dla firmy zewnętrznej. Krótko omówiona zostanie skuteczność i potencjalne problemy tych metodyk w naszych, polskich realiach. Przedstawione zostanie także kilka prostych sposobów, które zdaniem autora pozwolą na skuteczniejsze osiągnięcie zamierzonego efektu - czyli aplikacji nieobarczonej podatnościami.
Transcript of Jak tworzyć bezpieczne aplikacje?
Jak tworzyć (lub zamawiać) bezpieczne aplikacje?Jak tworzyć (lub zamawiać) bezpieczne aplikacje?
Wojciech DworakowskiWojciech Dworakowski
2
# whoami
SecuRing (od 2003)
Testowanie i doradztwo dotyczące bezpieczeństwa aplikacji i systemów IT
Badania dotyczące nowych metod ataku i obrony
OWASP Poland Chapter Leader
Propagowanie wiedzy związanej z bezpieczeństwem aplikacji
3
Historia pewnej aplikacji
4
5
XSS idea ;)
6
Hook
7
Listener
8
Uruchamia się exploit – żadnych widocznych skutków
9
Połączenie od aplikacji „wewnętrznej”
10
Sesja aplikacji wewnętrznej w przeglądarce atakującego
11
… jest też SQLi
12
Struktura danych
13
Dane
14
Jak „usuwano” błędy
Dodatkowy znak ’ żeby chronić przed
osadzaniem XSS / SQLi
Obejście: ’’, \, …
Filtrowanie komend SQL
Obejście: kodowanie znaków, inna notacja, SQL hacks …
15
CO POSZŁO NIE TAK?
16
Popełnione błędy
Zabezpieczenia tylko na styku z siecią publiczną
Brak dbałości o bezpieczeństwo „od wewnątrz”
Nieprawidłowy zakres testów
Nieprawidłowo zdefiniowane wymagania
17
18
Popełnione błędy
Brak wiedzy programistów w zakresie bezpieczeństwa
Niewłaściwie zdefiniowane wymagania
Podatności
XSS SQL injection
19
CO MOŻNA BYŁO ZROBIĆ LEPIEJ?
20
Projektowanie
Analiza i zdefiniowanie wymagań dotyczących bezpieczeństwa
Całość systemu Połączenia z innymi systemami Scenariusze ataku Dobranie zabezpieczeń (wymagań) Uwzględnienie wymagań
niefunkcjonalnych
21
Projektowanie
Analiza i zdefiniowanie wymagań dotyczących bezpieczeństwa
Całość systemu Połączenia z innymi systemami Scenariusze ataku Dobranie zabezpieczeń (wymagań) Uwzględnienie wymagań
niefunkcjonalnych
Narzędzia
Modelowanie zagrożeń (Threat Modeling)
OWASP ASVS
22
Wykonanie
Zasady bezpiecznego programowania
Edukacja Kontrola
Weryfikacja przyjętych założeń
Okresowe przeglądy wymagań Testy jednostkowe
Narzędzia
23
Wykonanie
Zasady bezpiecznego programowania
Edukacja Kontrola
Weryfikacja przyjętych założeń
Okresowe przeglądy wymagań Testy jednostkowe
Narzędzia
Narzędzia
OWASP Development Guide
OWASP Cheat Sheet Series
24
Wdrażanie
Testy bezpieczeństwa
Na podstawie przyjętych wymagań Objęcie całości systemu Zweryfikowanie realnych scenariuszy
ataku– źródła zagrożeń– cele atakującego
25
Wdrażanie
Testy bezpieczeństwa
Na podstawie przyjętych wymagań Objęcie całości systemu Zweryfikowanie realnych scenariuszy
ataku– źródła zagrożeń– cele atakującego
Narzędzia
OWASP Testing Guide
OWASP ASVS
26
Utrzymanie
Monitorowanie podatności
Systemy Biblioteki Kod własny
Zarządzanie podatnościami
Decyzje na podstawie ryzyka Okresowe testy weryfikacyjne Dokumentowanie poprawek
27
NAJWAŻNIEJSZE NARZĘDZIE
28
Jak to uporządkować?
Secure Software Development Life Cycle (SDLC)
Model dojrzałości
29
Standardy / modele dojrzałości
ISO/IEC 27034 - podejście procesowe (na razie ukazała się tylko część 1)
BSIMM http://bsimm.com
MS SDL http://microsoft.com/sdl
SAMM http://opensamm.org
Security Assurance Maturity Model Model dojrzałości dotyczący bezpieczeństwa
w procesie wytwarzania oprogramowania
30
SAMMSoftware Assurance Maturity Model
4 Business Functions x 3 Security Practices
3 poziomy dojrzałości + poziom 0 jako punkt wyjściowy
Stosowane w: Dell, ING Insurance International, KBC, ISG, …
https://www.owasp.org/index.php/OpenSAMM_Adopters
Źródło: www.owasp.org
31
SAMM: Wdrażanie
Assessment Kwestionariusz (str.22)
Scorecard (przed)
Plan wdrożenia (roadmap) - etapami
Gotowe szablony dla typowych instytucji
Opis konkretnych działań wynikających z planu wdrożenia
32
Security Practices
Dla każdego poziomu – opis:
Objective Activities Assessment Results Success Metrics Costs Personel
33
SAMM: Roadmap (ex.)
34
SAMM: Security Practices (ex.)
35
SAMM: Security Practices (ex.)
36
Podsumowanie
37
Security Officer
Wdrożenie (elementów) SDLC
Analiza i definiowanie wymagań
Również niefunkcjonalnych Przy uwzględnieniu połączeń Brainstorming / Modelowanie zagrożeń
Testy bezpieczeństwa
Właściwie dobrany zakres
38
Architekt
Modelowanie zagrożeń
Właściwe wyznaczenie granic zaufania
Bezpieczna architektura
Zabezpieczenia przeciwdziałające scenariuszom ataku
Wiele poziomów zabezpieczeń (zgodnie z analizą ryzyka)
39
Project Manager
Podnoszenie świadomości zespołu w zakresie bezpieczeństwa
Scenariusze ataku Techniki bezpiecznego programowania
Wymagania
Kontrolowanie podczas wykonania … i przed wdrożeniem (testy)
40
Testujący
Uwzględnij ryzyko
Uwzględnij logikę biznesową
Uwzględnij design
Uwzględnij połączenia z innymi systemami
Whitebox ! Konsultacje z zespołem projektowym
41
42
Grafika:http://flic.kr/p/LobZJ Brian Hillegas
http://flic.kr/p/4NTqUr UGArdener
http://flic.kr/p/9bF21n akulawolf
http://flic.kr/p/M4C2b Paco CT
http://flic.kr/p/hoMcw Marcus Ramberg
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/
