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

Bezpieczeństwo aplikacji

Dlaczego się nim przejmować?

Trendy rosnące

• Kradzież danych– Głośne „advanced persistent threat”

• Masowe ataki „oportunistyczne”– Przy okazji

• Ataki na systemy VoIP– Bardzo kosztowne

Infekcje masowe

• Bez względu na lokalizację strony–Skanowanie, Google

• Rekordowe – po 500 tys.–2008 (MS SQL)–2011 (LizaMoon)

Polska

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

Jak to wygląda z bliska?

Adresy URL charakterystyczne dla LizaMoon (2011)

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

Kod źródłowy zainfekowanej strony zawiera odwołaniedo kodu infekującego dziurawe przeglądarki osób odwiedzającychtę stronę

Celem ataków

oportunistycznychjest użytkownik

Serwis jest i ofiarą

i nośnikiem ataku

Szkody dla operatora strony

• Trafia na czarne listy– Google Safe Browsing, Microsoft Phishing Filter,

OpenDNS etc.

Galeria ataków

Recepta na wyciek danych

23 marca 2011

Atak na MPiPS

Źródło: MPiPS

Wyższa Szkoła Policji w Szczytnie

Sou

rce:

pra

wo.

vagl

a.pl

Sąd Okręgowy w Częstochowie

Sou

rce:

pra

wo.

vagl

a.pl

Centralna Komisja Egzaminacyjna

Źródło: niebezpiecznik.pl

KSEON Optivum

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

ROEFS

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

UM Tarnowskie Góry

Podmiana strony w 2009 roku. Źródło: Dziennik Internautów

UM Szczecinek

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

Wcześniej w gov.pl

• 2006 – Instytu Energii Atomowej Otwock• 2007 – NIK, PARP, Min. Sprawiedliwości• 2008 – MPiPS, liczne podstrony KPRM

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

Dywersja

• Ataki z wewnątrz• UM Wrocław

– Wrzesień 2010– Zablokowanie centrum telefonicznego– Były pracownik UM

„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

7’000 CV

Wyciek danych z Terazpraca.pl (czerwiec 2011). Źródło: Niebezpiecznik.pl

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

Konsekwencje prawne

• GIODO – kary do 50 tys. zł– Odpowiedzialność karna i zakaz

przetwarzania danych

Jak to się dzieje?

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...

Bezpieczny serwis jestprocesem

a niejednorazowym zamówieniem

Metody prawdopodobne

• Pisanie własnych aplikacji– Popularna technika programistyczna

„polski agile”• „Dokumentacja? Jaka dokumentacja?”

Jak to robić poprawnie?

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

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

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?

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

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)

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

Hosting

Źródło: niebezpiecznik.pl

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) for Information Security”

Koszty łatania dziur

Koszty łatania...

Applied Software Measurement, Capers Jones, 1996Building Security Into The Software Life Cycle, Marco M. Morana, 2006

Na etapie rozwoju

Na etapie testów...

Applied Software Measurement, Capers Jones, 1996Building Security Into The Software Life Cycle, Marco M. Morana, 2006

Test penetracyjnyAnaliza kodu

I najgorsze...

Applied Software Measurement, Capers Jones, 1996Building Security Into The Software Life Cycle, Marco M. Morana, 2006

Włamanie!

Literatura i źródła

• OWASP– Open Web Application Security Project– www.owasp.org

• Douglas W. Hubbard– „The Failure of Risk Management”,

Wiley, 2009

Pytania?

pawel.krawczyk@hush.com