Zapewnienie bezpieczeństwa w całym cyklu życia aplikacji (czyli dlaczego lepiej zapobiegać chorobom, niż leczyć je w zaawansowanym stadium) dr inż. Jakub Botwicz CISSP, ECSA 9.10.2012 jakub.botwicz@pl.ey.com Copyright The Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the License. The Foundation http://www.owasp.org
Zapewnienie bezpieczeństwa w całym cyklu życia aplikacji czyli dlaczego lepiej zapobiegać chorobom, niż leczyć je w zaawansowanym stadium Koszty naprawy błędów na różnych etapach życia aplikacji Projekty: SAMM (Software Assurance Maturity Model) BSIMM (Building Security In Maturity Model) Wybrane aktywności: Szkolenia Specyfikacja wymagań bezpieczeństwa Testy automatyczne Użycie komponentów zewnętrznych 2
Motywacje Przypuśćmy, że w naszej aplikacji został znaleziony błąd po wdrożeniu produkcyjnym Jakie są konsekwencje? Straty reputacyjne Utracone zyski (przerwy w działaniu aplikacji lub błędne działanie aplikacji) Koszty poprawek projektu, kodu, ponownego testowania i wdrożenia Czy można było tego uniknąć?
Koszty naprawy błędów w aplikacjach 100 Koszt naprawy błędu 90 80 70 60 50 40 30 20 10 0 Zbieranie wymagań Implementacja Po wdrożeniu Tworzenie architektury Implementacja Zbieranie wymagań Faza popełnienia błędu Faza naprawy błędu Źródło: McConnell, Steve (2004). Code Complete. Microsoft Press.
Motywacje Im wcześniej wykryjemy i usuniemy błędy tym mniejsze poniesiemy koszty z nimi związane Profilaktyka choć wymagająca dodatkowych nakładów, w efekcie okazuje się być opłacalna W jaki sposób można tworzyć aplikacje z mniejszą liczbą błędów oraz szybciej wykrywać błędy?
BUILDING SECURITY IN MATURITY MODEL 6
Building Security In Maturity Model v.4 Badanie praktyk w dziedzinie bezpieczeństwa przeprowadzone w 51 firmach: Google, Intel, Microsoft, VMware, Adobe, SAP, Bank of America, EMC, Nokia, Symantec, Visa Firmy różnej wielkości: w przedziale od 11 do 30000 programistów, średnio 4455 Pierwsze wyniki opublikowano w 2009 roku i od tego czasu były 3-krotnie aktualizowane Powstał zbiór 12 praktyk ze 111 aktywnościami 7
BSIMM praktyki Szkolenie Strategia i metryki Analiza architektury Polityka bezpieczeństwa i zgodność z regulacjami Standardy i wymagania Modelowanie ataków Projektowanie i funkcjonalności bezpieczeństwa Przeglądy kodu źródłowego Testy bezpieczeństwa Testy penetracyjne Zabezpieczenie środowiska uruchomieniowego Zarządzanie konfiguracją i podatnościami 8
BSIMM poziomy aktywności Poziom 0: brak aktywności w tym obszarze Poziom 1: podstawowy, najłatwiejszy do wdrożenia, niezbędne niezależnie od wielkości firmy i branży Testowanie aplikacji przez niezależnych pentesterów Poziom 2: bardziej zaawansowane, dopasowane do specyfiki firmy Testowanie penetracyjne aplikacji okresowo z analizą pokrycia wszystkich funkcji Poziom 3: najbardziej kosztowne i wyrafinowane metody, na które mogą sobie pozwolić największe firmy Przygotowywanie własnych narzędzi do testów penetracyjnych dopasowanych do specyfiki aplikacji 9
BSIMM wykorzystanie Pozwala na ocenę i wizualizację aktualnego stanu praktyk bezpieczeństwa (wykres radarowy: odległość od środka = poziom zaawansowania w określonej praktyce) Dostawcy oprogramowania Instytucje finansowe Źródło: Building Security In Maturity Model 4, Gary McGraw, Sammy Migues & Jacob West (2012)
BSIMM Software Security Group Grupa pracowników firmy ekspertów w dziedzinie bezpieczeństwa (w różnych obszarach i stanowiskach) Liderzy zmian i projektów Przekazują wiedzę pozostałym pracownikom Liczba osób w SSG w badanych firmach: od 1 do 100 osób średnio 19,48 11
SOFTWARE ASSURANCE MATURITY MODEL 12
Software Assurance Maturity Model Podtytuł: A guide to building security into software development Bazuje na doświadczeniu i wiedzy autorów, a nie na wynikach przeglądu firm Opisuje zbiór 12 praktyk z 72 aktywnościami
SAMM elementy opisu aktywności Szczegółowy opis aktywności: Rezultaty: Źródło: Software Assurance Maturity Model, OpenSAMM Project, Pravir Chandra (2009)
SAMM elementy opisu aktywności Koszty wdrożenia: Wskaźniki powodzenia: Źródło: Software Assurance Maturity Model, OpenSAMM Project, Pravir Chandra (2009)
SAMM Building Assurance Programs Przykładowe plany wdrożenia praktyk: w jakiej kolejności wdrażać które można pominąć Profile: Dostawcy oprogramowania Dostawcy usług Instytucje finansowe Instytucje rządowe Dodatkowe wskazówki: Oprogramowania tworzone zewnętrznie Transakcje przetwarzanie w sieci Źródło: Software Assurance Maturity Model, OpenSAMM Project, Pravir Chandra (2009)
SAMM vs. BSIMM porównanie Źródło danych BSIMM Wyniki ankiety przeprowadzonej w 51 firmach SAMM Wiedza autorów Liczba aktualizacji 3 0 Liczba opisanych aktywności 111 72 Liczba stron 60 90 Poziom opisu aktywności Sposób wdrażania aktywności Pobieżny Brak opisu Szczegółowy Opisany 17
Jak korzystać z SAMM lub BSIMM 1. Uzyskanie wsparcia od kadry zarządzającej sponsorzy prac i projektów decydenci w sprawach strategicznych 2. Zbadanie stanu początkowego jednego, kilku wybranych lub wszystkich obszarów 3. Zebranie grupy Software Security Group 4. Określenie celów i etapów ich osiągnięcia
Jak wdrażać SAMM lub BSIMM 5. Wdrożenie pilotażowe (w mniejszym obszarze lub części funkcjonalności) a) planowanie b) wdrożenie c) sprawdzenie kosztów i korzyści d) wyciągnięcie wniosków i doświadczeń 6. Wdrożenie pełne (dla całej firmy lub wszystkich aplikacji)
NAJLEPSZE PRAKTYKI 20
Szkolenia najlepsze praktyki Dla nowych pracowników Powtarzane i uaktualniane okresowo (raz na rok) Wykorzystujące historyczne dane firmy (np. przypadki popełnionych wcześniej błędów) Dopasowane do stanowiska (programista, tester, architekt) Obejmujące również kadrę zarządzającą Z udostępnionymi materiałami do dalszej nauki
Wymagania dotyczące bezpieczeństwa Wymagania bezpieczeństwa powinny być dokładnie opisane razem z wymaganiami funkcjonalnymi Wymagania powinny być opisane pozytywnie Aplikacja ma być odporna na ataki SQL Injection Aplikacja ma walidować dane wejściowe pod względem występowania w nich znaków ze składni języka SQL i prawidłowo je kodować lub usuwać Defensywne aplikacje są łatwiejsze do obrony Pole login może zawierać dowolne znaki testowe Pole login może zawierać litery, cyfry i podkreślenia 22
Testy automatyczne Zalety testów automatycznych krótszy czas wykonania niż w testów manualnych możliwość sprawdzenia dużej liczby przypadków testowych powtarzalność testów i wyników Wady testów automatycznych konieczność przygotowania testów (konfiguracji narzędzi) jakość wyników uzależniona od jakości testów
Testy bezpieczeństwa najlepsze praktyki Aby połączyć zalety testów automatycznych i manualnych Testy automatyczne: wykonywać jak najczęściej np. przy każdym wprowadzeniu poprawek do systemu kontroli wersji używać jako testy regresyjne Testy manualne: wykonywać przy istotnych zmianach w aplikacji na podstawie ich wyników uaktualniać testy automatyczne
Użycie komponentów zewnętrznych Użycie sprawdzonego kodu zewnętrznego daje duże korzyści dostajemy gotowy do użycia kod oszczędzamy czas korzystamy z pracy innych programistów i testerów oszczędzamy koszty pracy naszych pracowników Ale w zamian za to błędy w użytym kodzie stają się błędami naszych aplikacji powinniśmy śledzić informacje o wykrytych błędach w kodzie, który używamy
PODSUMOWANIE 26
Podsumowanie Im wcześniej wykryjemy i usuniemy błędy tym mniejsze poniesiemy koszty z nimi związane Najlepiej uczyć się na cudzych błędach i nie popełniać własnych Dokumenty SAMM i BSIMM mogą służyć do sprawdzenia aktualnego stanu praktyk naszej firmy i przygotowania planu poprawy tego stanu Mocne strony: SAMM: szczegółowy opis praktyk, podane sposoby wdrożenia BSIMM: wyniki oparte na rzeczywistym badaniu praktyk, zawiera więcej aktywności
Dziękuję za uwagę! Czy mają Państwo jakieś pytania? 28