Upload
securing
View
118
Download
0
Embed Size (px)
Citation preview
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 [email protected].
[email protected]+48 12 4252575