Embed Size (px)
Citation preview
Utrzymanie bezpieczeństwa aplikacji produkcyjnych
na przykładachMateusz Olejarka
O mnie
• Starszy specjalista ds. bezpieczeństwa IT, SecuRing
• Ocena bezpieczeństwa aplikacji webowych i mobilnych
• Trener
• (Były) programista
• OWASP Polska
Sonda
• Kto już miał do czynienia z testami bezpieczeństwa wytwarzanej aplikacji?
Agenda
• Wprowadzenie
• Typy aplikacji
• Problemy
• Rozwiązania
• Q&A
Wprowadzenie
Wprowadzenie
• Życie po Go Live
• Bezpieczeństwo z perspektywy dostawcy
Typy aplikacji
Typy aplikacji
• Podział ze względu na czas pomiędzy wydaniem/wdrożeniem kolejnej wersji:• Kwartał do roku (aplikacja A)
• Dwa do czterech tygodni (aplikacja B)
• Kilka godzin do kilku dni (aplikacja C)
Typy aplikacji
• Analiza:• Jak podejść do testowania bezpieczeństwa takiej
aplikacji?
• Jakie problemy się pojawiają?
• Zakładamy, że aplikacja przeszła już jakieś testy bezpieczeństwa przed pierwszym wdrożeniem
Aplikacja A
• Okres: kwartał do roku
Aplikacja A
• Okres: kwartał do roku
• Tworzona w modelu Waterfall
Aplikacja A
• Okres: kwartał do roku
• Tworzona w modelu Waterfall
• Testujemy zmiany wchodzące w wersji
Aplikacja A
• Okres: kwartał do roku
• Tworzona w modelu Waterfall
• Testujemy zmiany wchodzące w wersji
• Problemy?
Aplikacja B
• Okres: Dwa do czterech tygodni
Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:• Zmian?
Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:• Zmian?
• Jak często?
Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:• Zmian?
• Jak często?
• Czy wiemy dokładnie, co się zmieniło?
Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:• Zmian?
• Jak często?
• Czy wiemy dokładnie, co się zmieniło?
• Problemy?
Aplikacja C
• Okres: kilka godzin do kilku dni
Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia continuous delivery
Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia continuous delivery
• Testy:• Zmian?
Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia continuous delivery
• Testy:• Zmian?
• Których zmian?
Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia continuous delivery
• Testy:• Zmian?
• Których zmian?
• Kiedy i jak?
Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia continuous delivery
• Testy:• Zmian?
• Których zmian?
• Kiedy i jak?
• Problemy?
Problemy
Problemy
• Raport
• Podejście do bezpieczeństwa
• Wiedza, wymagania
• Brak koordynatora ds. bezpieczeństwa
• Ograniczenia budżetowe
Raport
• Forma raportu• Nieczytelna
• Brak copy&paste
• Nieprzekazywanie uwag twórcom raportu
• Omówienie raportu• Nie odbywa się spotkanie podsumowywujące testy
Podejście do bezpieczeństwa
• Negatywne podejście do tematu bezpieczeństwa w organizacji
• Negatywny „odbiór” raportu
• Nastawienie programistów do naprawy
Wiedza, wymagania
• Brak aktualizacji wiedzy:• Informacja o wykrytych błędach nie trafia do innych
projektów/osób
• Brak aktualizacji dobrych praktyk programistycznych/wdrożeniowych
• Brak aktualizacji wymagań
• Nieprzestrzeganie wymagań
• Brak aktualizacji zapisów w umowach
Brak koordynatora ds. bezpieczeństwa
• Nie ma osoby w organizacji:• Odpowiedzialnej za bezpieczeństwo
• Mającej czas, aby tym tematem się zająć
• Mającej odpowiednią „władzę” aby móc coś zmienić na lepsze
Ograniczenia budżetowe
• Budżet nie pozwala na takie testowanie, jakie chcielibyśmy mieć
• Pieniądze, jakie możemy na to wydać
• Czas, jaki możemy poświęcić
Rozwiązania
Rozwiązania na dziś
• Koordynator
• Wiedza
• Wymagania
• Narzędzia
• Szkolenia, konsultacje
• Zmiany procesu tworzenia oprogramowania
Koordynator
• Powołanie osoby odpowiedzialnej
• Odpowiednia moc sprawcza
• Zdefiniowanie zadań
• Pokazanie bezpieczeństwa jako priorytetu w organizacji
Wiedza
• Zdobywanie• Analiza raportu i wyciągnięcie wniosków
• Zaangażowanie różnych kompetencji• Testerzy
• Programiści
• Administratorzy
• Zbieranie, aktualizacja
• Wymiana
Wymagania
• Definiowanie i aktualizacja
• Egzekwowanie istniejących wymagań
Narzędzia
• Rodzaje:• Własne
• Skanery kodu źródłowego
• Skanery podatności aplikacji webowych
• Weryfikacja podatnych komponentów [!]
Szkolenia, konsultacje
• Najlepiej na własnych błędach
• Dopasowane do potrzeb:• Defensywne dla programistów
• Ofensywne dla testerów
• Z technologii, z jakich korzystamy
• Awareness
• Konsultacje• Tematyczne
• Optymalizacja kosztów
Zmiany procesu tworzenia oprogramowania• Ewolucja nad rewolucję
• We wszystkich obszarach
• Automatem to, co się da automatyzować
• Edukacja
