Jednym z projektów OWASP jest projekt Application Security Verification Standards. Warto przyglądnąć się udostępnionym dokumentom (choć znajdują się wciąż w fazie beta)
Czwartek, kwiecień 30. 2009
Do zapisania w umowie: Application Security Verification Standards
Pisałem kilka razy o tym, że częstym problemem lub raczej błędem popełnianym przez klientów zamawiających aplikacje internetowe jest brak wyspecyfikowania w umowie warunków akceptacji aplikacji. Temat ten pojawił się również na spotkaniu SPIN podczas dyskusji (bo do slajdów dotyczących tego tematu nie doszedłem, patrz: materiały ze spotkania SPIN). Sam kilka razy stosowałem wymagania związane z OWASP Top10, co było rozwiązaniem niedoskonałym, ale lepszym niż nic. Obecnie pewnym wsparciem dla klientów może być ASVS. Definiuje on cztery poziomy weryfikacji:
- Level 1 – Automated Verification
- Level 1A – Dynamic Scan (Partial Automated Verification)
- Level 1B – Source Code Scan (Partial Automated Verification)
- Level 2 – Manual Verification
- Level 2A – Penetration Test (Partial Manual Verification)
- Level 2B – Code Review (Partial Manual Verification)
- Level 3 – Design Verification
- Level 4 – Internal Verification
W rozdziale Detailed Verification Requirements dostępne są szczegółowe punkty kontrolne, które aplikacja musi spełniać, by zaliczyć określony poziom. Jak widać lista jest dość rozbudowana, ale ogólna, tak więc może istnieć konieczność dopisania dodatkowych punków w przypadku specyficznych aplikacji. Listy te, nawet w postaci "domyślnej", są według mnie doskonałym kandydatem do wpisania w umowie jako warunków odbioru aplikacji (pod względem bezpieczeństwa). Tylko jedna uwaga - by wymagania miały sens, muszą być możliwe do zweryfikowania. Zwracam uwagę na fakt, że poziomy 2B, 3 i 4 są naprawdę wymagające, jeśli chodzi o sam proces weryfikacji. Moim zdaniem tworzenie zapisów w umowie, których później nie można egzekwować/wykonać, mija się z celem. W większości przypadków w zupełności wystarcza 2A ewentualnie uzupełnione przez elementy przeglądu kodu z 2B (i 2009 CWE/SANS Top 25 Most Dangerous Programming Errors).
UWAGA: na upartego weryfikację aplikacji pod kątem zgodności z takimi wymaganiami można określić mianem audytu. Osobiście jednak chyba optowałbym za użyciem pojęcia weryfikacja zgodności.
Ślady
Użyj tego linku jeśli chcesz stworzyć Ślad (Trackback) do tego wpisu
Brak Śladów
Komentarze
Mówiąc szczerze nie jestem do końca przekonany do ASVS w takim zastosowaniu. Ten dokument definiuje poziomy weryfikacji, a nie wymagane poziomy bezpieczeństwa - a wydaje mi się że to raczej w tym kierunku powinny iść zapisy w umowie. Zawsze jednak lepsze coś niż nic 
#1
lpt
o
2009-05-01 08:46
(Odpowiedz)
A czym jest "poziom bezpieczeństwa"? Jak jest zdefiniowany? Jak się go weryfikuje? Czy ta aplikacja JESZCZE spełnia, czy JUŻ nie? Jeśli ktoś ma czas/możliwość przygotowania odpowiednich wymagań oraz listy kontrolnej, może je zawrzeć w umowie. Ponieważ jednak zwykle takiej możliwości nie ma (możliwość jest, ale się tego z różnych powodów nie robi, na przykład z braku czasu/wiedzy), dobrze jest skorzystać z czegoś gotowego. To, co jest w ASVS (np. dla 2A) jest dość dobre, choć oczywiście dla specyficznej aplikacji ze specyficznymi wymaganiami niewystarczające. Nie dotyczy również konkretnych funkcji związanych z bezpieczeństwem - jak na przykłada pod te punkty podciągnąć autoryzację transakcji w bankowości elektronicznej?
#1.1
wampir
o
2009-05-01 15:50
(Odpowiedz)
Po namyśle - faktycznie trudno to zdefiniować. Mam na myśli to, że niektóre punkty poziomu 2A (V3.10, V3.12, V4.1, V4.8, V7, itp.) są moim zdaniem zbędne np. w stronach reklamowych, a jednocześnie wymaganie w umowie wszystkich punktów typu V2.13 jest oczywiste, mimo że w ASVS znajdują się dopiero na poziomie czwartym (ponieważ są to poziomy weryfikacji).
#1.1.1
lpt
o
2009-05-03 14:35
(Odpowiedz)
Na temat tego, co jest, a co nie jest zbędne ciężko dyskutować bez konkretnego przykładu. Natomiast co do "poziomów weryfikacji" na sprawę trzeb popatrzeć nieco z innej strony. Aplikacja ma używać "security controls", które są w jakiś sposób określone (zdrowy rozsądek, najlepsza praktyka, wymogi prawa). Weryfikacja stosowania tych mechanizmów może być realizowana w różny sposób. To, że coś jest "wymagane" dopiero na poziomie 3 czy 4 może wynikać z faktu, że dopiero przy pomocy "narzędzi" wykorzystywanych na tym poziomie, jest to możliwe do zweryfikowania. Na przykład "V2.13: Verify that all authentication credentials are encrypted and stored in a centralized location (not in source code)." jest praktycznie nieweryfikowalne przy pomocy testu penetracyjnego. Punkt ten jest natomiast wymieniony dla 2B (tu chyba jakaś rozbieżność jest), ponieważ w trakcie przeglądu kodu można to już stwierdzić.
#1.1.1.1
wampir
o
2009-05-03 20:29
(Odpowiedz)
Btw, ta CAPTCHA jest IE-only?
#2
lpt
o
2009-05-01 08:49
(Odpowiedz)
