SecuRing Badanie praktyki wytwarzania bezpiecznego

oprogramowaniaRaport

Na wstępie pragniemy serdecznie podziękować ponad 50 specjalistom z firm zajmujących się wytwarzaniem oprogramowania, którzy zechcieli poświęcić swój czas i wziąć udział w naszym badaniu.

Secu

Rin

g Ba

dan

ie “

prak

tyki

wyt

war

zan

ia b

ezpi

eczn

ego

opro

gram

owan

ia”

2

Celem badania było sprawdzenie, jakie praktyki w zakresie wytwarzania

bezpiecznego oprogramowania są stosowane w polskich firmach. Badanie polegało

na przeprowadzeniu ankiety wśród specjalistów uczestniczących w konferencji

4Developers 2014.

Kluczowe wnioski wynikające z opracowania wyników ankiet.

Najczęściej stosowane praktyki:•

śledzenie na bieżąco i reagowanie na błędy wykrywane w stosowanych »

komponentach, frameworkach i bibliotekach,

testy bezpieczeństwa i implementacja poprawek wynikających z tych »

testów,

przeglądy kluczowych części kodu w zakresie bezpieczeństwa. »

Praktyki te stosowane są w ponad połowie badanych firm.

Szkolenia z zakresu bezpiecznego programowania (nawet na poziomie •

podstawowym) w dalszym ciągu nie są powszechnie stosowane, mimo iż

jest to skuteczny i łatwy do wprowadzenia środek prewencyjny.

W znacznej części projektów bezpieczeństwo jest na pewnym poziomie •

uwzględniane, ale wymagania w tym zakresie nie są spisywane, tak więc

również nie mogą być w sposób uporządkowany weryfikowane podczas

wytwarzania i wdrażania.

W większości projektów • (73%) są wprowadzane poprawki wynikające

z testów bezpieczeństwa i nie znalazł się ani jeden przypadek, w którym

po wykonaniu testów bezpieczeństwa nie trzeba byłoby takich poprawek

wprowadzać.

Testy bezpieczeństwa często są wykonywane • jedynie przez odbiorcę

oprogramowania.

Mniej niż połowa z osób, które miały do czynienia z testami bezpieczeństwa, •

uznało, że dostarczony przez wykonawcę testów bezpieczeństwa raport

był zrozumiały. Tak więc istnieje widoczna konieczność poprawy jakości

usług testowania bezpieczeństwa.

Stre

szcz

enie

Secu

Rin

g Ba

dan

ie “

prak

tyki

wyt

war

zan

ia b

ezpi

eczn

ego

opro

gram

owan

ia”

3

Badanie przeprowadziliśmy podczas konferencji 4Developers 6 kwietnia

2014. Dane zbierane były za pomocą formularzy ankietowych wypełnianych

przez uczestników konferencji. M

etod

yka

Pytania zostały skonstruowane na podstawie standardu OWASP OpenSAMM

“Security Assurance Maturity Model”1 w zakresie pierwszej fazy wdrożenia

zasad dobrej praktyki dla firm produkujących oprogramowanie.

Uczestnicy badania

W badaniu wzięło udział 52 pracowników z 42 firm. Większość

ankietowanych to programiści (56%) lub starsi programiści (17%). 17% osób

pracowało na stanowiskach managerskich.

Większość z odpowiadających na pytania stwierdziło, że z tematami

dotyczącymi bezpieczeństwa aplikacji ma do czynienia na co dzień (31%) lub

czasami (48%). Natomiast zdaniem 73% biorących udział w badaniu projekty,

w których uczestniczą, mogą być obiektem ataków.

56%

17%

17%

6%4%

programista

starszy programista

stanowisko

managerskie

tester

analityk/architekt

1 http://www.opensamm.org/

Secu

Rin

g Ba

dan

ie “

prak

tyki

wyt

war

zan

ia b

ezpi

eczn

ego

opro

gram

owan

ia”

4

Badane praktyki

W ankiecie pytaliśmy o następujące praktyki, mające na celu wytwarzanie bezpiecznego

oprogramowania:

Zarządzanie

Prewencja

Analiza i Projektowanie

Wytwarzanie i wdrażanie

Wdrożenie uporządkowanego planu zapewnienia bezpieczeństwa •

wytwarzanego lub zamawianego oprogramowania.

Wyznaczenie osoby odpowiedzialnej za bezpieczeństwo aplikacji.•

Szkolenia z zakresu bezpieczeństwa oprogramowania.•

Śledzenie i reagowanie na błędy wykrywane w stosowanych •

komponentach, frameworkach i bibliotekach.

Analiza najbardziej prawdopodobnych zagrożeń i dobranie •

odpowiednich dla nich zabezpieczeń (modelowanie zagrożeń).

Opisywanie w specyfikacji wymagań dotyczących •

bezpieczeństwa – w tym wymagań niefunkcjonalnych.

Formułowanie wymagań dotyczących bezpieczeństwa na •

podstawie analizy ryzyka lub zasad dobrej praktyki i zgodności

z obowiązującymi przepisami.

Przeglądy kluczowych części kodu w zakresie bezpieczeństwa.•

Testy bezpieczeństwa przed wdrożeniem, zgodnie z przyjętymi •

wymaganiami.

Implementacja poprawek wynikających z testów •

bezpieczeństwa.

Stosowanie narzędzi automatycznych, wyszukujących defekty •

bezpieczeństwa.

Obszar Praktyki

Secu

Rin

g Ba

dan

ie “

prak

tyki

wyt

war

zan

ia b

ezpi

eczn

ego

opro

gram

owan

ia”

5

Wyn

iki B

adan

ia

Najczęściej stosowane praktyki

Najczęściej stosowane dobre praktyki według wypełniających naszą ankietę

to:

śledzenie na bieżąco i reagowanie na błędy wykrywane w stosowanych •

komponentach, frameworkach i bibliotekach (77% odpowiedzi). Wynik

ten jest zgodny z rezultatami innych badań, np. monitoringu repozytoriów

komponentów (szczegóły poniżej w rozdziale „Prewencja” ),

testy bezpieczeństwa i implementacja poprawek wynikających z tych •

testów (73%). Należy jednak zauważyć, że znaczna część tych testów

to prawdopodobnie testy wykonywane przez odbiorcę oprogramowania

(szczegóły w rozdziale „Wytwarzanie i wdrażanie” ),

przeglądy kluczowych części kodu w zakresie bezpieczeństwa (65%).•

38% 38% 38%

77%

44%48%

31%

73%

65%

42%46%

Zarządzanie

Prewencja

Analiza i

projekto

wanie

Wytw

arzanie i w

drazanie

Secu

Rin

g Ba

dan

ie “

prak

tyki

wyt

war

zan

ia b

ezpi

eczn

ego

opro

gram

owan

ia”

6

Zarządzanie

W ankiecie pytaliśmy czy w firmach, w ramach kluczowych projektów, jest stosowany wystandaryzowany

program zapewnienia bezpieczeństwa wytwarzanego oprogramowania oraz czy jest wyznaczona

osoba odpowiedzialna za bezpieczeństwo aplikacji. W obydwu przypadkach ilość odpowiedzi

twierdzących była taka sama – około 38%. Zastanawiająca jest jednak korelacja między tymi

odpowiedziami. Tylko co czwarty ankietowany, który twierdził, że w firmie istnieje spójny program

zapewnienia bezpieczeństwa, odpowiedział twierdząco na pytanie dotyczące osoby odpowiedzialnej

za bezpieczeństwo aplikacji. Wyznaczenie takiej osoby jest kluczowym elementem każdego programu

zapewnienia jakości.

Prewencja

Pytaliśmy o dwie praktyki prewencyjne – o szkolenia oraz monitorowanie błędów ujawnianych

w stosowanych komponentach. Większość (77%) odpowiadających stwierdziła, że śledzą błędy

wykrywane we frameworkach i bibliotekach oraz reagują na te informacje. Uzyskane dane w pewnym

stopniu pokrywają się z niezależnymi badaniami Sonatype i Aspect Security2, z których wynikło,

że w 26% przypadków stosowane są „dziurawe” wersje bibliotek i frameworków.

Na pytanie czy architekci, programiści i testerzy przeszli podstawowe przeszkolenie z zakresu

bezpiecznego programowania 38% badanych odpowiedziało twierdząco. To niewiele, jeśli weźmiemy

pod uwagę, że jest to podstawowy, bardzo skuteczny i łatwy do wprowadzenia środek zmierzający

do podniesienia jakości oprogramowania w zakresie bezpieczeństwa.

38%

38%

38%

77%

Wdrożenie uporządkowanego planu zapewnienia bezpieczeństwa wytwarzanego lub zamawianego oprogramowania.

Wyznaczenie osoby odpowiedzialnej za bezpieczeństwo aplikacji.

Szkolenia z zakresu bezpieczeństwa oprogramowania.

Śledzenie i reagowanie na błędy wykrywane w stosowanych

komponentach, frameworkach i bibliotekach.

2 The Unfortunate Reality of Insecure Libraries: https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf

Secu

Rin

g Ba

dan

ie “

prak

tyki

wyt

war

zan

ia b

ezpi

eczn

ego

opro

gram

owan

ia”

7

Wytwarzanie i wdrażanie

Tylko 42% badanych potwierdziło, że przed wdrożeniem wykonują lub zamawiają testy bezpieczeństwa,

natomiast aż 73% pytanych potwierdziło, że implementowali poprawki wynikające z testów

bezpieczeństwa. Prawdopodobnie ta różnica wynika z tego, że często testy bezpieczeństwa wykonuje

jedynie odbiorca oprogramowania.

Warto przy tym zauważyć, że tylko 43% z osób, które miały do czynienia z testami bezpieczeństwa

uznało, że „dostarczony przez wykonawcę testów bezpieczeństwa raport był zrozumiały i nie

wzbudzał kontrowersji”.

Wśród ankietowanych nie znalazł się ani jeden przypadek, w którym testy bezpieczeństwa były

wykonywane, ale nie skutkowało to wprowadzeniem koniecznych poprawek.

Około połowa ankietowanych firm (46%) stosuje narzędzia automatycznie wyszukujące defekty

bezpieczeństwa. Natomiast aż 65% pytanych stwierdziło, że w ich firmach są stosowane przeglądy

kluczowych części kodu w zakresie bezpieczeństwa.

Analiza i projektowanie

44% odpowiadających na pytania potwierdziło, że w ich firmach stosuje się modelowanie zagrożeń,

tzn. są analizowane najbardziej prawdopodobne zagrożenia dotyczące ataków na aplikacje. Podobna

liczba osób (48%) stwierdziła również, że wymagania dotyczące bezpieczeństwa są formułowane

na podstawie analizy ryzyka lub zasad dobrej praktyki i zgodności z obowiązującymi przepisami.

Natomiast tylko 31% ankietowanych potwierdziło, że wymagania dotyczące bezpieczeństwa są opisane

w specyfikacji. Można z tego wyciągnąć wniosek, że w znacznej części projektów bezpieczeństwo

jest uwzględniane, ale wymagania w tym zakresie nie są spisywane, co powoduje, że nie mogą być

w sposób uporządkowany weryfikowane podczas wytwarzania i wdrażania.

44%

31%

48%

73%

65%

42%

46%

Analiza najbardziej prawdopodobnych zagrożeń i dobranie odpowiednich dla nich zabezpieczeń (modelowanie zagrożeń).

Przeglądy kluczowych części kodu w zakresie bezpieczeństwa.

Opisywanie w specyfikacji wymagań dotyczących bezpieczeństwa – w tym wymagań niefunkcjonalnych.

Formułowanie wymagań dotyczących bezpieczeństwa na podstawie analizy ryzyka lub zasad dobrej praktyki i zgodności z obowiązującymi przepisami.

Testy bezpieczeństwa przed wdrożeniem, zgodnie z przyjętymi

wymaganiami.

Implementacja poprawek wynikających z testów

bezpieczeństwa.

Stosowanie narzędzi automatycznych, wyszukujących defekty

bezpieczeństwa.

Secu

Rin

g Ba

dan

ie “

prak

tyki

wyt

war

zan

ia b

ezpi

eczn

ego

opro

gram

owan

ia”

8

SecuRing to zespół ekspertów zajmujących się bezpieczeństwem aplikacji

i systemów informatycznych. Naszą misją jest zapewnienie wsparcia dla

naszych partnerów na każdym etapie procesu, jakim jest zarządzanie

bezpieczeństwem aplikacji.O

Sec

uRin

g

Oferujemy między innymi:

testy bezpieczeństwa aplikacji webowych, mobilnych, WebService, •

grubego klienta, embeded systems, SaaS i innych,

analizę ryzyka, modelowanie zagrożeń – przed przystąpieniem •

do implementacji,

wsparcie w definiowaniu założeń dotyczących bezpieczeństwa,•

ocenę projektu systemu pod względem bezpieczeństwa,•

pomoc we wpisaniu bezpieczeństwa w cały cykl rozwoju i utrzymania •

systemów.

Nasza firma działa od 2003 roku i w tym okresie z naszych usług

skorzystały czołowe banki, instytucje ubezpieczeniowe, operatorzy

telekomunikacyjni, firmy tworzące oprogramowanie, a także instytucje

administracji centralnej zarówno w Polsce jak i za granicą. Staramy się

dostarczać usług o wysokiej jakości, opartych na wiedzy naszych pracowników

i doświadczeniu firmy.

Przejrzyj nasze prezentacje i raporty: http://www.slideshare.net/wojdwo.

Nasza strona www: http://www.securing.pl

Koszt usuwania defektów bezpieczeństwa wykrytych przez odbiorcę

aplikacji jest wielokrotnie wyższy, niż koszt wykrycia i usunięcia

potencjalnego defektu po stronie firmy wykonującej aplikację. Nasz

zespół zdobywał swoje doświadczenie pracując przez wiele lat przy

testach bezpieczeństwa dla klientów końcowych. Jeśli chcesz mieć

pewność, że aplikacje i systemy dostarczane przez Twoją firmę są właściwie

zabezpieczone i pragniesz, by klienci Twojej firmy postrzegali ją jako partnera,

do którego produktów można mieć zaufanie – skorzystaj z naszych usług.

Jeśli chcesz uzyskać więcej informacji, skontaktuj się z nami pod telefonem

+48 12 4252575 lub email-em info@securing.pl.

www.securing.plinfo@securing.pl+48 12 4252575