Mateusz Olejarka

Utrzymanie bezpieczeństwa aplikacji produkcyjnych

na przykładach

O mnie

• Starszy specjalista ds. bezpieczeństwa IT, SecuRing

• Ocena bezpieczeństwa aplikacji webowych i mobilnych

• Trener• (Były) programista• OWASP Polska

Sonda

• Kto z Państwa pracuje z aplikacjami tworzonymi wewnętrznie?

• Kto z Państwa pracuje z aplikacjami zamawianymi?

Agenda

• Wprowadzenie• Typy aplikacji• Problemy• Rozwiązania • Q&A

WPROWADZENIE

Wprowadzenie

• Życie po Go Live• Perspektywy– Aplikacja tworzona wewnętrznie– Aplikacja tworzona na zamówienie

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

SDLC

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ń• Określenie co w przypadku, gdy dostawca nie

spełnił wymagań

Narzędzia

• Rodzaje– Skanery kodu źródłowego– Własne – 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