W trakcie swojej prezentacji poruszę problematykę utrzymania bezpieczeństwa aplikacji po wdrożeniu produkcyjnym. Na przykładowych aplikacjach pokażę wyzwania z tym związane, w odniesieniu do konkretnej aplikacji oraz realiów, w jakich funkcjonuje. Wspólnie z uczestnikami przeanalizujemy możliwe mechanizmy mające na celu utrzymanie bezpieczeństwa aplikacji. Zastanowimy się nad optymalnym ich doborem oraz momentem, w którym warto z nich skorzystać, uwzględniając również koszt wykorzystania danego mechanizmu.

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

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 z Państwa pracuje z aplikacjami
tworzonymi wewnętrznie?
• Kto z Państwa pracuje z aplikacjami
zamawianymi?

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

5. WPROWADZENIE

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

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

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