Bezpieczeństwo aplikacji<br />Dlaczego się nim przejmować?<br />
Trendy rosnące<br />Kradzież danych<br />Głośne „advanced persistent threat”<br />Masowe ataki „oportunistyczne”<br />Przy...
Infekcje masowe<br />Bez względu na lokalizację strony<br />Skanowanie, Google<br />Rekordowe – po 500 tys.<br />2008 (MS ...
Polska<br />Źródło: CERT.GOV.PL<br />
Jak to wygląda z bliska?<br />
Adresy URL charakterystyczne dla LizaMoon (2011)<br />
Tak wygląda zainfekowana strona. Czy jest tu coś podejrzanego? Nie!<br />
Kod źródłowy zainfekowanej strony zawiera odwołanie<br />do kodu infekującego dziurawe przeglądarki osób odwiedzających<br...
Celem ataków oportunistycznychjest użytkownik<br />
Serwis jest i ofiarąi nośnikiem ataku<br />
Szkody dla operatora strony<br />Trafia na czarne listy<br />Google Safe Browsing, Microsoft Phishing Filter, OpenDNS etc....
Galeria ataków<br />
Recepta na wyciek danych<br />23 marca 2011<br />
Atak na MPiPS<br />Źródło: MPiPS<br />
Wyższa Szkoła Policji w Szczytnie<br />Source: prawo.vagla.pl<br />
Sąd Okręgowy w Częstochowie<br />Source: prawo.vagla.pl<br />
Centralna Komisja Egzaminacyjna<br />Źródło: niebezpiecznik.pl<br />
KSEON Optivum<br />System rekrutacji do szkół ponadgimnazjalnych. Atak SQL injection.<br />Źródło: niebezpiecznik.pl<br />
ROEFS<br />Krajowy Ośrodek EFS (2010) Źródło: niebezpiecznik.pl<br />
UM Tarnowskie Góry<br />Podmiana strony w 2009 roku. Źródło: Dziennik Internautów<br />
UM Szczecinek<br />Domniemany wyciek danych z UM Szczecinek (2009). Źródło: Dziennik Internautów<br />
Wcześniej w gov.pl<br />2006 – Instytu Energii Atomowej Otwock<br />2007 – NIK, PARP, Min. Sprawiedliwości<br />2008 – MPi...
Systemy samorządowe<br />UM Płock – czerwiec 2011<br />Także Komunikacja Miejska, Miejski Zespół Obiektów Sportowych<br />...
Dywersja<br />Ataki z wewnątrz<br />UM Wrocław<br />Wrzesień 2010<br />Zablokowanie centrum telefonicznego<br />Były praco...
„Głębokie ukrycie”<br />Pseudozabezpieczenie i powód do żartów<br />Raczej na pewno niezgodne z wytycznymi GIODO<br />PKO ...
7’000 CV<br />Wyciek danych z Terazpraca.pl (czerwiec 2011). Źródło: Niebezpiecznik.pl<br />
Ataki na systemy telefoniczne<br />UM Biała Podlaska 2010<br />Prawdopodobne włamanie do centrali VoIP<br />800 połączeń n...
Konsekwencje prawne<br />GIODO – kary do 50 tys. zł<br />Odpowiedzialność karna i zakaz przetwarzania danych<br />
Jak to się dzieje?<br />
Jak paść ofiarą?<br />Metody gwarantowane<br />Proste hasła FTP, SSH...<br />Stare wersje Wordpress, Joomla, PHPbb<br />Sy...
Bezpieczny serwis jestprocesema niejednorazowym zamówieniem<br />
Metody prawdopodobne<br />Pisanie własnych aplikacji<br />Popularna technika programistyczna „polski agile”<br />„Dokument...
Jak to robić poprawnie?<br />
Jak bezpiecznie pisać?<br />Metodyki rozwoju dojrzałości systemów bezpieczeństwa<br />SAMM (Software Assurance Maturity Mo...
Systemy zamawiane<br />Oddzielenie specyfikacji systemu od implementacji systemu<br />Zamówienie specyfikacji<br />Precyzy...
Bezpieczeństwo specyfikacji<br />Dokumentacja założeń i mechanizmów bezpieczeństwa<br />Architektura aplikacji<br />Weryfi...
Bezpieczeństwo implementacji<br />Testy automatyczne (skany)<br />Kodu źródłowego (Static Code Analysis – SCA)<br />Wysoka...
Testy systemów zamawianych<br />Test produkcyjny<br />W trakcie pisania aplikacji – wewnętrzna sprawa wykonawcy<br />Test ...
Co z eksploatacją?<br />Czy dostawca naprawi nowo odkryte dziury?<br />Jak szybko? Kto za to zapłaci?<br />Czy mogę sam na...
Hosting<br />Źródło: niebezpiecznik.pl<br />
Bezpieczeństwo hostingu<br />SLA (Service Level Agreement)<br />Klauzule w umowach na dostawę usług – telekomunikacyjnych,...
Koszty łatania dziur<br />
Koszty łatania...<br />Na etapie rozwoju<br />Applied Software Measurement, Capers Jones, 1996<br />Building Security Into...
Na etapie testów...<br />Test penetracyjny<br />Analiza kodu<br />Applied Software Measurement, Capers Jones, 1996<br />Bu...
I najgorsze...<br />Włamanie!<br />Applied Software Measurement, Capers Jones, 1996<br />Building Security Into The Softwa...
Literatura i źródła<br />OWASP<br />Open Web Application Security Project<br />www.owasp.org<br />Douglas W. Hubbard<br />...
Pytania?<br />pawel.krawczyk@hush.com<br />
Upcoming SlideShare
Loading in …5
×

Dlaczego przejmować się bezpieczeństwem aplikacji (pol)

1,115 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,115
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dlaczego przejmować się bezpieczeństwem aplikacji (pol)

  1. 1. Bezpieczeństwo aplikacji<br />Dlaczego się nim przejmować?<br />
  2. 2. Trendy rosnące<br />Kradzież danych<br />Głośne „advanced persistent threat”<br />Masowe ataki „oportunistyczne”<br />Przy okazji<br />Ataki na systemy VoIP<br />Bardzo kosztowne<br />
  3. 3. Infekcje masowe<br />Bez względu na lokalizację strony<br />Skanowanie, Google<br />Rekordowe – po 500 tys.<br />2008 (MS SQL)<br />2011 (LizaMoon)<br />
  4. 4. Polska<br />Źródło: CERT.GOV.PL<br />
  5. 5. Jak to wygląda z bliska?<br />
  6. 6. Adresy URL charakterystyczne dla LizaMoon (2011)<br />
  7. 7.
  8. 8. Tak wygląda zainfekowana strona. Czy jest tu coś podejrzanego? Nie!<br />
  9. 9. Kod źródłowy zainfekowanej strony zawiera odwołanie<br />do kodu infekującego dziurawe przeglądarki osób odwiedzających<br />tę stronę<br />
  10. 10. Celem ataków oportunistycznychjest użytkownik<br />
  11. 11. Serwis jest i ofiarąi nośnikiem ataku<br />
  12. 12. Szkody dla operatora strony<br />Trafia na czarne listy<br />Google Safe Browsing, Microsoft Phishing Filter, OpenDNS etc.<br />
  13. 13. Galeria ataków<br />
  14. 14. Recepta na wyciek danych<br />23 marca 2011<br />
  15. 15. Atak na MPiPS<br />Źródło: MPiPS<br />
  16. 16. Wyższa Szkoła Policji w Szczytnie<br />Source: prawo.vagla.pl<br />
  17. 17. Sąd Okręgowy w Częstochowie<br />Source: prawo.vagla.pl<br />
  18. 18. Centralna Komisja Egzaminacyjna<br />Źródło: niebezpiecznik.pl<br />
  19. 19. KSEON Optivum<br />System rekrutacji do szkół ponadgimnazjalnych. Atak SQL injection.<br />Źródło: niebezpiecznik.pl<br />
  20. 20. ROEFS<br />Krajowy Ośrodek EFS (2010) Źródło: niebezpiecznik.pl<br />
  21. 21. UM Tarnowskie Góry<br />Podmiana strony w 2009 roku. Źródło: Dziennik Internautów<br />
  22. 22. UM Szczecinek<br />Domniemany wyciek danych z UM Szczecinek (2009). Źródło: Dziennik Internautów<br />
  23. 23. Wcześniej w gov.pl<br />2006 – Instytu Energii Atomowej Otwock<br />2007 – NIK, PARP, Min. Sprawiedliwości<br />2008 – MPiPS, liczne podstrony KPRM<br />
  24. 24. Systemy samorządowe<br />UM Płock – czerwiec 2011<br />Także Komunikacja Miejska, Miejski Zespół Obiektów Sportowych<br />UW Łódź – luty 2011<br />UM Wadowice – lipiec 2011<br />
  25. 25. Dywersja<br />Ataki z wewnątrz<br />UM Wrocław<br />Wrzesień 2010<br />Zablokowanie centrum telefonicznego<br />Były pracownik UM<br />
  26. 26. „Głębokie ukrycie”<br />Pseudozabezpieczenie i powód do żartów<br />Raczej na pewno niezgodne z wytycznymi GIODO<br />PKO BP (2010) – dane dłużników<br />Sąd potwierdził brak faktycznych zabezpieczeń<br />Pekao S.A. (2008) – 1500 CV<br />Łotewskie ministerstwo finansów (2010)<br />Kod „ataku” ma trzy linijki<br />
  27. 27. 7’000 CV<br />Wyciek danych z Terazpraca.pl (czerwiec 2011). Źródło: Niebezpiecznik.pl<br />
  28. 28. Ataki na systemy telefoniczne<br />UM Biała Podlaska 2010<br />Prawdopodobne włamanie do centrali VoIP<br />800 połączeń na płatne numery w Zimbabwe<br />Ok. 50 tys. zł strat<br />
  29. 29. Konsekwencje prawne<br />GIODO – kary do 50 tys. zł<br />Odpowiedzialność karna i zakaz przetwarzania danych<br />
  30. 30. Jak to się dzieje?<br />
  31. 31. Jak paść ofiarą?<br />Metody gwarantowane<br />Proste hasła FTP, SSH...<br />Stare wersje Wordpress, Joomla, PHPbb<br />System CMS, BIP lub inna aplikacja webowa wykonana dawno temu...<br />
  32. 32. Bezpieczny serwis jestprocesema niejednorazowym zamówieniem<br />
  33. 33. Metody prawdopodobne<br />Pisanie własnych aplikacji<br />Popularna technika programistyczna „polski agile”<br />„Dokumentacja? Jaka dokumentacja?”<br />
  34. 34. Jak to robić poprawnie?<br />
  35. 35. Jak bezpiecznie pisać?<br />Metodyki rozwoju dojrzałości systemów bezpieczeństwa<br />SAMM (Software Assurance Maturity Model)<br />BSIMM (Building Security in Maturity Model)<br />W nich jest cała reszta<br />SDL (Secure Development Lifecycle)<br />Testy penetracyjne, przeglądy kodu<br />
  36. 36. Systemy zamawiane<br />Oddzielenie specyfikacji systemu od implementacji systemu<br />Zamówienie specyfikacji<br />Precyzyjny opis – UML, BPMN<br />Ocena bezpieczeństwa specyfikacji<br />Przegląd, ocena architektury<br />Zamówienie implementacji<br />Ocena bezpieczeństwa implementacji<br />Testy penetracyjne, analiza kodu źródłowego, skany podatności<br />
  37. 37. Bezpieczeństwo specyfikacji<br />Dokumentacja założeń i mechanizmów bezpieczeństwa<br />Architektura aplikacji<br />Weryfikacja poprawności danych<br />Jakie testy mają być wykonane na gotowym kodzie?<br />
  38. 38. Bezpieczeństwo implementacji<br />Testy automatyczne (skany)<br />Kodu źródłowego (Static Code Analysis – SCA)<br />Wysoka wykrywalność dziur, wyższy koszt, pomija bezpieczeństwo infrastruktury<br />Aplikacji (skan podatności)<br />Testuje całe środowisko w rzeczywistym kontekście<br />Testy ręczne<br />Analiza logiki biznesowej, testy penetracyjne<br />
  39. 39. Testy systemów zamawianych<br />Test produkcyjny<br />W trakcie pisania aplikacji – wewnętrzna sprawa wykonawcy<br />Test akceptacyjny<br />Część odbioru aplikacji – wykonuje trzecia strona lub zamawiający<br />Standard opisu poziomu wymagań testowych<br />OWASP ASVS (Application Security Verification Standard)<br />
  40. 40. Co z eksploatacją?<br />Czy dostawca naprawi nowo odkryte dziury?<br />Jak szybko? Kto za to zapłaci?<br />Czy mogę sam naprawić dziury?<br />Czy mam kod źródłowy? Czy mam do niego prawa?<br />Co z bezpieczeństwem infrastruktury?<br />Serwery, biblioteki programistyczne, serwery aplikacyjne<br />Kto załata i jak szybko?<br />Umowa modelowa: OWASP Secure Software Contract Annex<br />
  41. 41. Hosting<br />Źródło: niebezpiecznik.pl<br />
  42. 42. Bezpieczeństwo hostingu<br />SLA (Service Level Agreement)<br />Klauzule w umowach na dostawę usług – telekomunikacyjnych, hostingowych itd<br />Typowe SLA dla bezpieczeństwa<br />Kto wykonuje kopie zapasowe? Jak często?<br />Kto łata serwery? Jak szybko?<br />Kto konfiguruje zapory, IPS?<br />Kto analizuje alerty systemowe i sieciowe?<br />Patrz: SANS, „Internal SLA (Service Level Agreements) forInformation Security”<br />
  43. 43. Koszty łatania dziur<br />
  44. 44. Koszty łatania...<br />Na etapie rozwoju<br />Applied Software Measurement, Capers Jones, 1996<br />Building Security Into The Software Life Cycle, Marco M. Morana, 2006<br />
  45. 45. Na etapie testów...<br />Test penetracyjny<br />Analiza kodu<br />Applied Software Measurement, Capers Jones, 1996<br />Building Security Into The Software Life Cycle, Marco M. Morana, 2006<br />
  46. 46. I najgorsze...<br />Włamanie!<br />Applied Software Measurement, Capers Jones, 1996<br />Building Security Into The Software Life Cycle, Marco M. Morana, 2006<br />
  47. 47. Literatura i źródła<br />OWASP<br />Open Web Application Security Project<br />www.owasp.org<br />Douglas W. Hubbard<br />„The Failure of Risk Management”, Wiley, 2009<br />
  48. 48. Pytania?<br />pawel.krawczyk@hush.com<br />

×