4developers utrzymanie bezpieczenstwa

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

Dziękuję za uwagę

mateusz.olejarka@securing.pl@molejarka