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 鈥渄ucha鈥 dokumentu. W zwi膮zku z tym postanowi艂em wypisa膰 co ciekawsze punkty, lecimy! 馃コ

  • Wyr贸wnanie wytycznych 鈥淰2: Authentication鈥 oraz 鈥淰3: 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! 馃憤





B膮d藕 na bie偶膮co!

Zapisz si臋 do newslettera ju偶 teraz i otrzymuj powiadomienia o nowych postach, ciekawe materia艂y o security, oraz newsy prosto do swojej skrzynki mailowej. 馃

Tym samym wyra偶asz zgod臋 na otrzymanie informacji marketingowych (doh...)