Prezentacja porusza problematykę utrzymania bezpieczeństwa aplikacji po wdrożeniu produkcyjnym z perspektywy dostawcy aplikacji. Na przykładowych aplikacjach (platforma SaaS, aplikacja tworzona zwinnie, aplikacja tworzona w waterfall) pokazane sa wyzwania z tym związane, w odniesieniu do konkretnej aplikacji oraz realiów, w jakich funkcjonuje.

1. Utrzymanie bezpieczeństwa
aplikacji produkcyjnych
na przykładach
Mateusz Olejarka

2. O mnie
• Starszy specjalista ds. bezpieczeństwa IT, SecuRing
• Ocena bezpieczeństwa aplikacji webowych i
mobilnych
• Trener
• (Były) programista
• OWASP Polska

3. Sonda
• Kto już miał do czynienia z testami bezpieczeństwa
wytwarzanej aplikacji?

4. Agenda
• Wprowadzenie
• Typy aplikacji
• Problemy
• Rozwiązania
• Q&A

5. Wprowadzenie

6. Wprowadzenie
• Życie po Go Live
• Bezpieczeństwo z perspektywy dostawcy

7. Typy aplikacji

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

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

10. Aplikacja A
• Okres: kwartał do roku

11. Aplikacja A
• Okres: kwartał do roku
• Tworzona w modelu Waterfall

12. Aplikacja A
• Okres: kwartał do roku
• Tworzona w modelu Waterfall
• Testujemy zmiany wchodzące w wersji

13. Aplikacja A
• Okres: kwartał do roku
• Tworzona w modelu Waterfall
• Testujemy zmiany wchodzące w wersji
• Problemy?

14. Aplikacja B
• Okres: Dwa do czterech tygodni

15. Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie

16. Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:
• Zmian?

17. Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:
• Zmian?
• Jak często?

18. Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:
• Zmian?
• Jak często?
• Czy wiemy dokładnie, co się zmieniło?

19. Aplikacja B
• Okres: Dwa do czterech tygodni
• Tworzona zwinnie
• Testy:
• Zmian?
• Jak często?
• Czy wiemy dokładnie, co się zmieniło?
• Problemy?

20. Aplikacja C
• Okres: kilka godzin do kilku dni

21. Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia
continuous delivery

22. Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia
continuous delivery
• Testy:
• Zmian?

23. Aplikacja C
• Okres: kilka godzin do kilku dni
• Tworzona zwinnie, korzystająca z podejścia
continuous delivery
• Testy:
• Zmian?
• Których zmian?

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

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

26. Problemy

27. Problemy
• Raport
• Podejście do bezpieczeństwa
• Wiedza, wymagania
• Brak koordynatora ds. bezpieczeństwa
• Ograniczenia budżetowe

28. Raport
• Forma raportu
• Nieczytelna
• Brak copy&paste
• Nieprzekazywanie uwag twórcom raportu
• Omówienie raportu
• Nie odbywa się spotkanie podsumowywujące testy

29. Podejście do bezpieczeństwa
• Negatywne podejście do tematu bezpieczeństwa w
organizacji
• Negatywny „odbiór” raportu
• Nastawienie programistów do naprawy

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

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

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

33. Rozwiązania

35. Rozwiązania na dziś
• Koordynator
• Wiedza
• Wymagania
• Narzędzia
• Szkolenia, konsultacje
• Zmiany procesu tworzenia oprogramowania

36. Koordynator
• Powołanie osoby odpowiedzialnej
• Odpowiednia moc sprawcza
• Zdefiniowanie zadań
• Pokazanie bezpieczeństwa jako priorytetu w
organizacji

37. Wiedza
• Zdobywanie
• Analiza raportu i wyciągnięcie wniosków
• Zaangażowanie różnych kompetencji
• Testerzy
• Programiści
• Administratorzy
• Zbieranie, aktualizacja
• Wymiana

38. Wymagania
• Definiowanie i aktualizacja
• Egzekwowanie istniejących wymagań

39. Narzędzia
• Rodzaje:
• Własne
• Skanery kodu źródłowego
• Skanery podatności aplikacji webowych
• Weryfikacja podatnych komponentów [!]

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

41. Zmiany procesu tworzenia
oprogramowania
• Ewolucja nad rewolucję
• We wszystkich obszarach
• Automatem to, co się da automatyzować
• Edukacja

43. Dziękuję za uwagę
mateusz.olejarka@securing.pl
@molejarka