Wojciech DworakowskiWojciech Dworakowski

Bezpieczeństwo w rozwoju systemów ITBezpieczeństwo w rozwoju systemów IT

Jak spełnić wymagania nowej Rekomendacji D?Jak spełnić wymagania nowej Rekomendacji D?

2

Wsparcie procesów związanych z utrzymaniem bezpieczeństwa IT

Od identyfikacji zagrożeń i tworzenia założeń…

…po testy odbiorcze i okresowe testy podczas eksploatacji

+ specjalizowane szkolenia

Niezależność od dostawców rozwiązańNie sprzedajemy produktów zabezpieczających

Wyłącznie usługi dotyczącyce bezpieczeństwa IT.

DoświadczenieDziałamy od 2003 roku

Zbadaliśmy bezpieczeństwo ponad 200 systemów i aplikacji

3

Agenda

Wymagania Rekomendacji D

Rozwój środowiska IT + Bezpieczeństwo

Stan obecny

Propozycje zmian

Wymagania nowej Rekomendacji DWymagania nowej Rekomendacji D

5

Definiowanie wymagań (7.2)

Określanie szczegółowych, jednoznacznych wymagań

M.in.: Wymagania dotyczące bezpieczeństwa systemu i przetwarzanych w nim danych

Również podczas wprowadzania zmian

6

Analiza ryzyka (7.4)

Przy wprowadzaniu nowego systemu informatycznego

„ze szczególnym uwzględnieniem aspektów bezpieczeństwa”

7

Metodologia testowania (7.7)

Bank powinien posiadać metodologię testowania

Niezależnóść weryfikacji spełnienia założeń

Zakres powinien obejmować weryfikację spełnienia wymagań

w tym - zgodność z wymogami bezpieczeństwa

8

Rozwój oprogramowania we własnym zakresie (7.5)

Określenie metodyki rozwoju

Stosowanie standardów, m.in. w zakresie testów i przeglądów kodu zapewniających odpowiedni stopień niezależności tych przeglądów

9

Rozwój oprogramowania z udziałem dostawców (7.6)

Reputacja, odpowiedni poziom jakości

W umowach – standardy i metodyki przyjęte w banku

Testowane wewnętrznie przez dostawcę

ale nie powinno to ograniczać testów po stronie banku

10

Akceptacja zmian (7.12)

Analiza zgodności z poprzednio ustalonymi wymaganiami

W szczególności związanych z jego bezpieczeństwem

11

Wsparcie specjalistów (6.3)

… uwzględnienie w zasadach prowadzenia projektów udziału przedstawicieli obszaru bezpieczeństwa środowiska teleinformatycznego w całym cyklu życia projektu

12

Rozwój oparty o wymaganiaW tym dotyczące bezpieczeństwa

Definiowanie• Analiza ryzyka (7.4)• Zdefiniowanie

wymagań (7.2)

Projektowanie• Wsparcie specjalistów (6.3)• Zasady prowadzenia

projektów (6.1)

Wykonanie• Wsparcie specjalistów (6.3)• Zasady prowadzenia

projektów (6.1)

Wdrażanie• Testy przed

wdrożeniem (7.5-6)• Weryfikacja

spełnienia wymagań (7.7)

Wymagania

Stan obecnyStan obecny

14

Z naszego doświadczenia

Ponad 100 zbadanych systemów bankowych

Średnio ok. 10 podatności na badany system

W ponad 70% przypadków znajdujemy podatności o znaczeniu kluczowym

15

Koszty

Szczegółowe testy bezpieczeństwa

Usuwanie podatności

Analiza zmian Negocjacje Korespondencja, spotkania Weryfikacja skuteczności poprawek

Czasowe istnienie podatności na produkcji (akceptacja ryzyka)

16

Przyczyny

Wymagania w zakresie bezpieczeństwa nie są definiowane w ogóle

lub nie uwzględniają cech niefunkcjonalnych

Osoby definiujące wymagania nie mają wiedzy pozwalającej na

projektowanie scenariuszy ataków dobranie zabezpieczeń (wymagań)

17

Wymagania - przykłady

Po przekroczeniu maksymalnej liczby prób uwierzytelnienia konto zostaje zablokowane na okres czasu pozwalający na powstrzymanie ataków typu brute force.

Wszystkie mechanizmy uwierzytelniania są egzekwowane po stronie serwera.

Istnieje scentralizowany mechanizm zabezpieczający dostęp do każdego typu chronionych zasobów

Dla wszystkich wejść są zdefiniowane i zastosowane wzorce pozytywnej walidacji

Wszystkie niezaufane dane trafiające do interpreterów SQL używają parametryzowanych interfejsów Źródło: OWASP ASVS

(Application Security Verification Standard)

fun

kcjo

naln

en

iefu

nk

cjo

nal

ne

18

Jak to zmienić (i spełnić wytyczne Rekomendacji D)?

Definiowanie• Analiza ryzyka (7.4)• Zdefiniowanie

wymagań (7.2)

Projektowanie• Wymagania są

weryfikowane w projekcie

Wykonanie• Testy jednostkowe

(według przyjętych wymagań)

Wdrażanie• Testy przed

wdrożeniem (7.5-6)• Weryfikacja spełnienia

wymagań (7.7)

19

Analiza ryzyka(model uproszczony)

Identyfikacja ryzyka

Zagrożenia (Kto?) Potencjalne skutki (Po co?)

Ranking ryzyk (ekspozycja, motywacja, skutki, …)

Definiowanie Projektowanie

WykonanieWdrażanie

20

Zdefiniowanie wymagań

Scenariusze ataku

Jak zagrożenia mogą osiągnąć cele? Uwaga: Wymaga doświadczenia i

wiedzy eksperckiej Definiowanie Projektowanie

WykonanieWdrażanie

Zagrożenia SkutkiScenariusze

ataku

Kto? Jak? Co?

21

Zdefiniowanie wymagań (c.d.)

Dobranie zabezpieczeń

Jak bronić się przed atakami? WYMAGANIA

–funkcjonalne i niefunkcjonalne

Częściowo można wykorzystać istniejące standardy–Np. OWASP ASVS

Definiowanie Projektowanie

WykonanieWdrażanie

22

Projektowanie i wytwarzanie

Projektowanie

Weryfikacja wymagań w projekcie

Wytwarzanie

Weryfikacja poprawności kodu Testy jednostkowe zabezpieczeń

Definiowanie Projektowanie

WykonanieWdrażanie

23

Testy przed wdrożeniem

Zakres testów

Weryfikacja wymagań

Scenariusze testowe

Scenariusze ataków (z etapu definiowania)

Definiowanie Projektowanie

WykonanieWdrażanie

24

Zalety

Zmiany łatwe do wdrożenia

Wystarczy dodać definiowanie wymagań w zakresie bezpieczeństwa

Jasno zdefiniowane wymagania dla wykonawcy

Jasno zdefiniowany zakres testów bezpieczeństwa

25

Zalety c.d.

Optymalizacja kosztów

Zabezpieczenia adekwatne do ryzyka Możliwość wczesnej eliminacji

podatności

Znacznie łatwiejsza analiza wpływu zmian na bezpieczeństwo

26

Równowaga

Bez

pie

czeń

stw

oFunkcjonalnośćDostępno

ść

27

Jak możemy pomóc?

Wsparcie eksperckie

Definiowanie wymagań Weryfikacja projektu Metodyka testowania

Testy bezpieczeństwa

Edukacja

Szkolenia podnoszące świadomośćanalitycy, PM, programiści, testerzy

28

Kontakt

http://www.securing.pl e-mail: info@securing.plJontkowa Górka 14a 30-224 Krakówtel. (12) 4252575fax. (12) 4252593

Wojciech Dworakowskiwojciech.dworakowski@securing.pltel. 506 184 550