Do zapisania w umowie: Application Security Verification Standards
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)
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.
Oryginał tego wpisu dostępny jest pod adresem Do zapisania w umowie: Application Security Verification Standards
Autor: Paweł Goleń