OWASP Application Security Verification Standard 4.0

Opublikowane przez Andrzej Dyjak w dniu 06.03.2019

Na początku marca pojawiła się nowa wersja OWASP Application Security Verification Standard (ASVS), który jest de facto podstawowym narzędziem w ocenie bezpieczeństwa aplikacji zarówno na naszym podwórku jak i za granicą. Zmian względem poprzedniej wersji 3.0.1 wydanej w 2016 roku jest sporo, zarówno od strony samych wytycznych jak i ogólnego “ducha” dokumentu. W związku z tym postanowiłem wypisać co ciekawsze punkty, lecimy! 🥳

  • Wyrównanie wytycznych “V2: Authentication” oraz “V3: Session Management” ze standardem NIST 800-63-3 Digital Identity Guidelines — świetny ruch, standardy branżowe powinny mieć punkty wspólne wszędzie gdzie tylko można;
  • Zmiana układu sekcji, która pomaga w dodawaniu/usuwaniu odpowiednich wytycznych z zakres audytu (np. jeżeli aplikacja nie korzysta z JSON Web Tokens to cała sekcja związana z JWT może zostać w prosty sposób pominięta);
  • Zmapowanie podatności do odpowiednich rodzajów wyznaczonych przez Common Weakness Enumeration (CWE), oczywiście w miarę możliwości bo nie wszystko da się przełożyć 1:1;
  • Wyrównanie całości poziomu 1 (L1) z wymogami OWASP Top 10 2017 (jedynym wyjątkiem jest tutaj A10 czyli logowanie) co ułatwia adoptowanie Top 10 bo pieczemy dwie pieczenie na jednym ogniu;
  • Poziom 1 (L1) w nowej wersji ASVS zapewnia zgodność z Sekcjami 6.5+ standardu PCI DSS 3.2.1 innymi słowy — implementując ASVS na poziomie 1 spełnimy wymagania związane z Sekcjami 6.5+ standardu PCI DSS w projektach, które tego wymagają;
  • Zmiana podejścia do architektury aplikacji z monolitów server-side na to co dzisiaj jest już chlebem powszednim czyli: server-less API, functional programming na produkcji, producenci (API) i cały wachlarz konsumentów (desktop, web, mobile), chmury, kontenery, CI/CD i związana z tym wszystkim kultura DevSecOps;
  • Porzucenie kontrolek związanych z aplikacjami mobilnymi na rzecz standardu OWASP Mobile Application Security Verification Standard;
  • Zapewnienie możliwości przetestowania całego poziomu 1 (L1) podejściem black-box bez dostępu do dokumentacji, kodu źródłowego, deweloperów et cetera. Jedynym wyjątkiem jest A10 (Top 10), które wymaga zrzutów ekranu, wywiadów i ogólnego dowodu na logowanie.

Ponadto da się wyczuć mocny nacisk na:

  1. Testowanie podejściem hybrydowym wszystkich trzech poziomów (w dokumencie brzmi to jak zwykły white-box);
  2. Automatyzację wszystkiego co można z poziomu CI/CD pipeline (np. narzędzia SAST i DAST powinny być używane w trybie ciągłym już na etapie wytwarzania aplikacji, a nie dopiero w momencie oceny podatności czy testu penetracyjnego).

Osobiście bardzo podoba mi się uwypuklenie podnoszenia poprzeczki w procesie wytwórczym oprogramowania, oraz zabranie głosu w sprawie ograniczeń związanych z podejściem black-box połączonej z rekomendacją hybrydowej oceny bezpieczeństwa aplikacji wychodzącej poza sam dostęp do instancji aplikacji i włączającej również przegląd kodu źródłowego czy wywiady z deweloperami.

Podsumowując nowa wersja ASVS bardzo dobrze wpasowuje się w dzisiejszy sposób wytwarzania, działania, i utrzymywania aplikacji. Jest to krok w dobrym kierunku, który był potrzebny już od dłuższego czasu (3 lata w IT to długo). Kudos w stronę autorów! 👍





Chcesz być na bieżąco w temacie cyberbezpieczeństwa? Zapraszam do subskrypcji biuletynu Cybergram 🤝