Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads.
Jak tworzyć (lub zamawiać)
bezpieczne aplikacje?

Wojciech Dworakowski
# whoami
SecuRing (od 2003)

 Testowanie i doradztwo dotyczące
bezpieczeństwa aplikacji i systemów IT
 Badania dotyczące...
Historia pewnej aplikacji

3
4
XSS idea ;)

5
Hook

6
Listener

7
Uruchamia się exploit –
żadnych widocznych skutków

8
Połączenie od aplikacji
„wewnętrznej”

9
Sesja aplikacji wewnętrznej w
przeglądarce atakującego

10
… jest też SQLi

11
Struktura danych

12
Dane

13
Jak „usuwano” błędy

’

Dodatkowy znak żeby chronić przed
osadzaniem XSS / SQLi
 Obejście: ’’,

, …

Filtrowanie komend S...
15
Popełnione błędy
Zabezpieczenia tylko na styku z siecią
publiczną
Brak dbałości o bezpieczeństwo „od
wewnątrz”
Nieprawidło...
17
Popełnione błędy
Brak wiedzy programistów w zakresie
bezpieczeństwa
Niewłaściwie zdefiniowane wymagania

Podatności
 XSS
...
19
Projektowanie
Analiza i zdefiniowanie wymagań
dotyczących bezpieczeństwa
 Całość systemu
 Połączenia z innymi systemami
...
Projektowanie
Narzędzia
Analiza i zdefiniowanie wymagań
 Modelowanie
dotyczących bezpieczeństwa
zagrożeń
(Threat Modeling...
Wykonanie
Zasady bezpiecznego programowania

 Edukacja
 Kontrola
Weryfikacja przyjętych założeń
 Okresowe przeglądy wym...
Wykonanie
Narzędzia
Zasady bezpiecznego programowania
 OWASP
 Edukacja
Development Guide
 Kontrola
 OWASP Cheat
Sheet ...
Wdrażanie
Testy bezpieczeństwa

 Na podstawie przyjętych wymagań
 Objęcie całości systemu
 Zweryfikowanie realnych scen...
Wdrażanie
Narzędzia
Testy bezpieczeństwa
 OWASP Testing
 Na podstawie przyjętych wymagań
Guide
 Objęcie całości systemu...
Utrzymanie
Monitorowanie podatności

 Systemy
 Biblioteki
 Kod własny
Zarządzanie podatnościami
 Decyzje na podstawie ...
27
28
Standardy / modele dojrzałości
ISO/IEC 27034 - podejście procesowe
(na razie ukazała się tylko część 1)
BSIMM

http://bsim...
SAMM
Software Assurance Maturity Model

4 Business Functions x 3 Security Practices
3 poziomy dojrzałości + poziom 0 jako ...
SAMM: Wdrażanie
Assessment  Kwestionariusz (str.22)

Scorecard (przed)
Plan wdrożenia (roadmap) - etapami

 Gotowe szabl...
Security Practices
Dla każdego poziomu – opis:

 Objective
 Activities
 Assessment
 Results
 Success Metrics

 Costs...
SAMM: Roadmap (ex.)

33
SAMM: Security Practices (ex.)

34
SAMM: Security Practices (ex.)

35
36
Security Officer
Wdrożenie (elementów) SDLC

Analiza i definiowanie wymagań
 Również niefunkcjonalnych
 Przy uwzględnien...
Architekt
Modelowanie zagrożeń

Właściwe wyznaczenie granic zaufania
Bezpieczna architektura

 Zabezpieczenia przeciwdzia...
Project Manager
Podnoszenie świadomości zespołu w
zakresie bezpieczeństwa
 Scenariusze ataku
 Techniki bezpiecznego prog...
Testujący
Uwzględnij ryzyko

Uwzględnij logikę biznesową
Uwzględnij design

Uwzględnij połączenia z innymi
systemami
White...
41
Grafika:
http://flic.kr/p/LobZJ

Brian Hillegas

http://flic.kr/p/4NTqUr

UGArdener

http://flic.kr/p/9bF21n

akulawolf

h...
Upcoming SlideShare
Loading in …5
×

Jak tworzyć bezpieczne aplikacje?

12,667 views

Published on

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.

Published in: Technology
License:
  • Be the first to comment

Jak tworzyć bezpieczne aplikacje?

  1. 1. Jak tworzyć (lub zamawiać) bezpieczne aplikacje? Wojciech 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 2
  3. Historia pewnej aplikacji 3
  4. 4
  5. XSS idea ;) 5
  6. Hook 6
  7. Listener 7
  8. Uruchamia się exploit – żadnych widocznych skutków 8
  9. Połączenie od aplikacji „wewnętrznej” 9
  10. Sesja aplikacji wewnętrznej w przeglądarce atakującego 10
  11. … jest też SQLi 11
  12. Struktura danych 12
  13. Dane 13
  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 … 14
  15. 15
  16. Popełnione błędy Zabezpieczenia tylko na styku z siecią publiczną Brak dbałości o bezpieczeństwo „od wewnątrz” Nieprawidłowo zdefiniowane wymagania Nieprawidłowy zakres testów 16
  17. 17
  18. Popełnione błędy Brak wiedzy programistów w zakresie bezpieczeństwa Niewłaściwie zdefiniowane wymagania Podatności  XSS  SQL injection 18
  19. 19
  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 20
  21. Projektowanie Narzędzia Analiza i zdefiniowanie wymagań  Modelowanie dotyczących bezpieczeństwa zagrożeń (Threat Modeling)  Całość systemu  systemami  Połączenia z innymi OWASP ASVS  Scenariusze ataku  Dobranie zabezpieczeń (wymagań)  Uwzględnienie wymagań niefunkcjonalnych 21
  22. Wykonanie Zasady bezpiecznego programowania  Edukacja  Kontrola Weryfikacja przyjętych założeń  Okresowe przeglądy wymagań  Testy jednostkowe Narzędzia 22
  23. Wykonanie Narzędzia Zasady bezpiecznego programowania  OWASP  Edukacja Development Guide  Kontrola  OWASP Cheat Sheet Series Weryfikacja przyjętych założeń  Okresowe przeglądy wymagań  Testy jednostkowe Narzędzia 23
  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 24
  25. Wdrażanie Narzędzia Testy bezpieczeństwa  OWASP Testing  Na podstawie przyjętych wymagań Guide  Objęcie całości systemu  OWASP ASVS  Zweryfikowanie realnych scenariuszy ataku – źródła zagrożeń – cele atakującego 25
  26. Utrzymanie Monitorowanie podatności  Systemy  Biblioteki  Kod własny Zarządzanie podatnościami  Decyzje na podstawie ryzyka  Okresowe testy weryfikacyjne  Dokumentowanie poprawek 26
  27. 27
  28. 28
  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 29
  30. SAMM Software 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 30 Ź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 31
  32. Security Practices Dla każdego poziomu – opis:  Objective  Activities  Assessment  Results  Success Metrics  Costs  Personel 32
  33. SAMM: Roadmap (ex.) 33
  34. SAMM: Security Practices (ex.) 34
  35. SAMM: Security Practices (ex.) 35
  36. 36
  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 37
  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) 38
  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) 39
  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 40
  41. 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 AttributionNonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ 42

×