Wojciech Dworakowski,
SecuRing

Wojciech Dworakowski,
SecuRing

Bezpieczeństwo a
zarządzanie projektami

Bezpieczeństwo a
zarządzanie projektami

OWASP Poland, 2013-05-08

OWASP Poland, 2013-05-08

2

B

e

zp

ie

c

ze

ń

s

tw

o

Fun

kcjo

naln

ość

Do

stę

pn

oś

ć

3

Z mojego doświadczenia

Z mojego doświadczenia

Ponad 200 zbadanych systemów w
branży finansowej i nie tylko

Średnio ok.

10

podatności na

badany system

W ponad

70%

przypadków

znajdujemy podatności o
znaczeniu kluczowym

4

Koszty

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)

5

Przyczyny

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ń)

6

Wymagania - przykłady

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)

fu

n

k

cj

o

n

a

ln

e

n

ie

fu

n

k

c

jo

n

a

l

n

e

7

Jak to zmienić?

Jak to zmienić?

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)

8

Analiza ryzyka
(model uproszczony)

Analiza ryzyka
(model uproszczony)

Identyfikacja ryzyka

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

Ranking ryzyk (ekspozycja,
motywacja, skutki, …)

Definiowa

nie

Projektow

anie

Wykonani

e

Wdrażani

e

9

Zdefiniowanie wymagań

Zdefiniowanie wymagań

Scenariusze ataku

 Jak zagrożenia mogą osiągnąć

cele?

 Uwaga: Wymaga doświadczenia i

wiedzy eksperckiej

Definiowa

nie

Projektow

anie

Wykonani

e

Wdrażani

e

Zagrożeni

a

Skutki

Scenarius

ze ataku

Kto?

Jak?

Co?

10

Zdefiniowanie wymagań
(c.d.)

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

Definiowa

nie

Projektow

anie

Wykonani

e

Wdrażani

e

11

Projektowanie i
wytwarzanie

Projektowanie i
wytwarzanie

Projektowanie

 Weryfikacja wymagań w projekcie

Wytwarzanie

 Weryfikacja poprawności kodu
 Testy jednostkowe zabezpieczeń

Definiowa

nie

Projektow

anie

Wykonani

e

Wdrażani

e

12

Testy przed wdrożeniem

Testy przed wdrożeniem

Zakres testów

 Weryfikacja wymagań

Scenariusze testowe

 Scenariusze ataków

(z etapu definiowania)

Definiowa

nie

Projektow

anie

Wykonani

e

Wdrażani

e

13

Zalety

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

14

Zalety c.d.

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

15

Równowaga

Równowaga

B

e

zp

ie

c

ze

ń

s

tw

o

Fun

kcjo

naln

ość

Do

stę

pn

oś

ć

16

Pytania?

Pytania?

Wojciech Dworakowski
wojciech.dworakowski@securing
.pl
tel. [phone]