Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Jak tworzyć bezpieczne aplikacje?

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.

  • Inicia sesión para ver los comentarios

Jak tworzyć bezpieczne aplikacje?

  1. 1. Jak tworzyć (lub zamawiać) bezpieczne aplikacje? Wojciech Dworakowski
  2. 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. 3. Historia pewnej aplikacji 3
  4. 4. 4
  5. 5. XSS idea ;) 5
  6. 6. Hook 6
  7. 7. Listener 7
  8. 8. Uruchamia się exploit – żadnych widocznych skutków 8
  9. 9. Połączenie od aplikacji „wewnętrznej” 9
  10. 10. Sesja aplikacji wewnętrznej w przeglądarce atakującego 10
  11. 11. … jest też SQLi 11
  12. 12. Struktura danych 12
  13. 13. Dane 13
  14. 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. 15
  16. 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. 17
  18. 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. 19
  20. 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. 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. 22. Wykonanie Zasady bezpiecznego programowania  Edukacja  Kontrola Weryfikacja przyjętych założeń  Okresowe przeglądy wymagań  Testy jednostkowe Narzędzia 22
  23. 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. 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. 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. 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. 27
  28. 28. 28
  29. 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. 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. 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. 32. Security Practices Dla każdego poziomu – opis:  Objective  Activities  Assessment  Results  Success Metrics  Costs  Personel 32
  33. 33. SAMM: Roadmap (ex.) 33
  34. 34. SAMM: Security Practices (ex.) 34
  35. 35. SAMM: Security Practices (ex.) 35
  36. 36. 36
  37. 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. 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. 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. 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. 41
  42. 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

×