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/