1. Bezpieczeństwo aplikacji Dlaczego się nim przejmować?

2. Trendy rosnące Kradzież danych Głośne „advanced persistent threat” Masowe ataki „oportunistyczne” Przy okazji Ataki na systemy VoIP Bardzo kosztowne

3. Infekcje masowe Bez względu na lokalizację strony Skanowanie, Google Rekordowe – po 500 tys. 2008 (MS SQL) 2011 (LizaMoon)

4. Polska Źródło: CERT.GOV.PL

5. Jak to wygląda z bliska?

6. Adresy URL charakterystyczne dla LizaMoon (2011)

8. Tak wygląda zainfekowana strona. Czy jest tu coś podejrzanego? Nie!

9. Kod źródłowy zainfekowanej strony zawiera odwołanie do kodu infekującego dziurawe przeglądarki osób odwiedzających tę stronę

10. Celem ataków oportunistycznychjest użytkownik

11. Serwis jest i ofiarąi nośnikiem ataku

12. Szkody dla operatora strony Trafia na czarne listy Google Safe Browsing, Microsoft Phishing Filter, OpenDNS etc.

13. Galeria ataków

14. Recepta na wyciek danych 23 marca 2011

15. Atak na MPiPS Źródło: MPiPS

16. Wyższa Szkoła Policji w Szczytnie Source: prawo.vagla.pl

17. Sąd Okręgowy w Częstochowie Source: prawo.vagla.pl

18. Centralna Komisja Egzaminacyjna Źródło: niebezpiecznik.pl

19. KSEON Optivum System rekrutacji do szkół ponadgimnazjalnych. Atak SQL injection. Źródło: niebezpiecznik.pl

20. ROEFS Krajowy Ośrodek EFS (2010) Źródło: niebezpiecznik.pl

21. UM Tarnowskie Góry Podmiana strony w 2009 roku. Źródło: Dziennik Internautów

22. UM Szczecinek Domniemany wyciek danych z UM Szczecinek (2009). Źródło: Dziennik Internautów

23. Wcześniej w gov.pl 2006 – Instytu Energii Atomowej Otwock 2007 – NIK, PARP, Min. Sprawiedliwości 2008 – MPiPS, liczne podstrony KPRM

24. Systemy samorządowe UM Płock – czerwiec 2011 Także Komunikacja Miejska, Miejski Zespół Obiektów Sportowych UW Łódź – luty 2011 UM Wadowice – lipiec 2011

25. Dywersja Ataki z wewnątrz UM Wrocław Wrzesień 2010 Zablokowanie centrum telefonicznego Były pracownik UM

26. „Głębokie ukrycie” Pseudozabezpieczenie i powód do żartów Raczej na pewno niezgodne z wytycznymi GIODO PKO BP (2010) – dane dłużników Sąd potwierdził brak faktycznych zabezpieczeń Pekao S.A. (2008) – 1500 CV Łotewskie ministerstwo finansów (2010) Kod „ataku” ma trzy linijki

27. 7’000 CV Wyciek danych z Terazpraca.pl (czerwiec 2011). Źródło: Niebezpiecznik.pl

28. Ataki na systemy telefoniczne UM Biała Podlaska 2010 Prawdopodobne włamanie do centrali VoIP 800 połączeń na płatne numery w Zimbabwe Ok. 50 tys. zł strat

29. Konsekwencje prawne GIODO – kary do 50 tys. zł Odpowiedzialność karna i zakaz przetwarzania danych

30. Jak to się dzieje?

31. Jak paść ofiarą? Metody gwarantowane Proste hasła FTP, SSH... Stare wersje Wordpress, Joomla, PHPbb System CMS, BIP lub inna aplikacja webowa wykonana dawno temu...

32. Bezpieczny serwis jestprocesema niejednorazowym zamówieniem

33. Metody prawdopodobne Pisanie własnych aplikacji Popularna technika programistyczna „polski agile” „Dokumentacja? Jaka dokumentacja?”

34. Jak to robić poprawnie?

35. Jak bezpiecznie pisać? Metodyki rozwoju dojrzałości systemów bezpieczeństwa SAMM (Software Assurance Maturity Model) BSIMM (Building Security in Maturity Model) W nich jest cała reszta SDL (Secure Development Lifecycle) Testy penetracyjne, przeglądy kodu

36. Systemy zamawiane Oddzielenie specyfikacji systemu od implementacji systemu Zamówienie specyfikacji Precyzyjny opis – UML, BPMN Ocena bezpieczeństwa specyfikacji Przegląd, ocena architektury Zamówienie implementacji Ocena bezpieczeństwa implementacji Testy penetracyjne, analiza kodu źródłowego, skany podatności

37. Bezpieczeństwo specyfikacji Dokumentacja założeń i mechanizmów bezpieczeństwa Architektura aplikacji Weryfikacja poprawności danych Jakie testy mają być wykonane na gotowym kodzie?

38. Bezpieczeństwo implementacji Testy automatyczne (skany) Kodu źródłowego (Static Code Analysis – SCA) Wysoka wykrywalność dziur, wyższy koszt, pomija bezpieczeństwo infrastruktury Aplikacji (skan podatności) Testuje całe środowisko w rzeczywistym kontekście Testy ręczne Analiza logiki biznesowej, testy penetracyjne

39. Testy systemów zamawianych Test produkcyjny W trakcie pisania aplikacji – wewnętrzna sprawa wykonawcy Test akceptacyjny Część odbioru aplikacji – wykonuje trzecia strona lub zamawiający Standard opisu poziomu wymagań testowych OWASP ASVS (Application Security Verification Standard)

40. Co z eksploatacją? Czy dostawca naprawi nowo odkryte dziury? Jak szybko? Kto za to zapłaci? Czy mogę sam naprawić dziury? Czy mam kod źródłowy? Czy mam do niego prawa? Co z bezpieczeństwem infrastruktury? Serwery, biblioteki programistyczne, serwery aplikacyjne Kto załata i jak szybko? Umowa modelowa: OWASP Secure Software Contract Annex

41. Hosting Źródło: niebezpiecznik.pl

42. Bezpieczeństwo hostingu SLA (Service Level Agreement) Klauzule w umowach na dostawę usług – telekomunikacyjnych, hostingowych itd Typowe SLA dla bezpieczeństwa Kto wykonuje kopie zapasowe? Jak często? Kto łata serwery? Jak szybko? Kto konfiguruje zapory, IPS? Kto analizuje alerty systemowe i sieciowe? Patrz: SANS, „Internal SLA (Service Level Agreements) forInformation Security”

43. Koszty łatania dziur

44. Koszty łatania... Na etapie rozwoju Applied Software Measurement, Capers Jones, 1996 Building Security Into The Software Life Cycle, Marco M. Morana, 2006

45. Na etapie testów... Test penetracyjny Analiza kodu Applied Software Measurement, Capers Jones, 1996 Building Security Into The Software Life Cycle, Marco M. Morana, 2006

46. I najgorsze... Włamanie! Applied Software Measurement, Capers Jones, 1996 Building Security Into The Software Life Cycle, Marco M. Morana, 2006

47. Literatura i źródła OWASP Open Web Application Security Project www.owasp.org Douglas W. Hubbard „The Failure of Risk Management”, Wiley, 2009

48. Pytania? pawel.krawczyk@hush.com