Etwa zweieinhalb Jahre nach dem letzten Release war es am 1. März soweit und die neuste Version des Application Security Verification Standards (ASVS), Version 4.0, wurde offiziell veröffentlicht.

Das ASVS-Projekt versucht immer Lektionen aus dem Feedback seiner Community und der Industrie zu ziehen und dies in den Standard einzubauen. Insbesondere ist den Leitern des ASVS-Projekts dabei wichtig, dass der Standard für verschiedene Use Cases in der Entwicklung sicherer Software einsetzbar ist.

Um nicht nur für das Testing nützlich zu sein, sondern bereits in der Entwicklung und beim Design von Software möglichst effektiv zu sein, wurde daher darauf geachtet, die Erkenntnisse und Ideen der OWASP Proactive Controls in den ASVS einzubauen. Die Proactive Controls sind grundlegende Strategien, welche auf einem hohen Level helfen, sichere Software zu schreiben. Den ASVS auch in diese Richtung weiterzuentwickeln ist sicherlich sinnvoll, da die Idee des Shift Left, also die Sicherheit früher im Entwicklungszyklus zu beachten, immer stärker verbreitet ist.

Dafür weitere, unterstützende Ressourcen bereitzustellen, ist sicherlich wertvoll. Je leichter es ist, sichere Software zu produzieren, je mehr SoftwareentwicklerInnen dabei unterstützt werden, desto sicherer wird die Software und desto höher wird die Qualität. Dazu gehört aber auch, dass die unterstützenden Ressourcen nicht nur korrekt, sondern auch verständlich sind.

Darum war es auch ein Ziel des ASVS v4, Überlappungen oder Widersprüche zu anderen Standards zu minimieren, indem der ASVS sich eng an sie angleicht (NIST SP 800-63) oder eine Übermenge bildet. Der ASVS deckt beispielsweise alles ab, was in den OWASP Top 10 2017 enthalten ist und mehr, so dass der ASVS nicht einfach mit den Top 10 konkurrenziert. Dadurch sollen Kosten und Aufwand in Bezug auf Compliance reduziert werden und keine Zeit dadurch verloren gehen, dass unnötige Differenzen als Risiken akzeptiert werden müssen.

Strukturelle Überarbeitung und Vereinfachungen

Der ASVS ist seit der ursprünglichen Veröffentlichung 2008 gewachsen und war darum nicht immer so klar und zielstrebig, wie er sein konnte. Mit Version 4.0 wurde daher die Gelegenheit genutzt, um den ASVS etwas zu straffen.

Dazu wurden die Levels des ASVS auch etwas umstrukturiert. Es gibt kein Level 0 mehr, L1 deckt nun das absolute Minimum ab und konzentriert sich dabei noch mehr auf die OWASP Top 10 als zuvor. Zudem ist L1 fast komplett durch einen Blackbox Penetration Test abdeckbar, ohne Zugang zu Quellcode oder Dokumentation. Davon wird im ASVS allerdings dringend abgeraten, da dies nur die Qualität der Resultate senkt. Dieser Empfehlung schliessen wir uns auch klar an, zumal es sogar auf L1 eigentlich Anforderungen gibt, welche nur mit Zugang zu Dokumentation oder Interviews mit Entwicklern wirklich überprüft werden können.

L1 ist auch nur ausreichend, um gegen opportunistische Angreifer geschützt zu sein. Sobald das Bedrohungsmodell gezielte Angriffe gegen die Applikation vorsieht, sollte man L2 in Betracht ziehen.

Neuordnung und Renummerierung

In der vorherigen Version des ASVS waren die Kapitel nicht durchgängig nummeriert, da einzelne Kapitel aus dem ASVS entfernt worden waren. Da die Nummerierung in Kapitel 2 sowieso überarbeitet werden musste, um den ASVS näher an NIST SP 800-63 heranzubringen, wurde das gleich zum Anlass genommen, den kompletten ASVS neu durchzunummerieren.

Dabei wurden Lücken in der Nummerierung geschlossen und die Kapitel in kleinere Unterkapitel unterteilt. Ebenso wurden Einträge aufgesplittet und sauberer getrennt. Einträge, welche sich nur auf eine einzelne Programmiersprache bezogen, wurden abgeschafft, genauso wie überlappende Einträge oder Einträge, welche wenig Gefahr darstellten.

Aus 19 Kapiteln mit rund 180 Einträgen wurden so 14 Kapitel, 69 Unterkapitel und 286 einzelne Items. Die Unterkapitel dienen dazu, dass Nutzer des ASVS leichter die Elemente aussuchen können, welche für sie relevant sind. Beispielsweise behandelt Kapitel 13 APIs und Web Services: 13.1 behandelt generische Anforderungen, 13.2 fokussiert auf RESTful Webservices, 13.3 SOAP-basierte und 13.4 auf GraphQL und andere Datenschichten. Wer also GraphQL nicht einsetzt, kann 13.4 ignorieren, statt sich über verschiedene Kapitel die Anforderungen an GraphQL suchen zu müssen, um sie als Nicht Anwendbar zu markieren.

Geplante nächste Schritte

Das ASVS-Projekt ist aber noch nicht am Ende angelangt, wo der ASVS nur noch gelegentlich an neue Technologien angepasst werden muss. Nächste Schritte sind bereits geplant und teilweise sogar angegangen worden.

Dabei werden weitere Mappings erstellt, um den ASVS effektiver mit anderen Dokumenten kombinieren zu können. Insbesondere soll der Bezug zum OWASP Testing Guide v4 hergestellt werden, damit der ASVS noch besser geeignet ist, als Grundlage für Tests und Reviews zu dienen. Zudem wird geprüft, ob für jeden Eintrag im ASVS eine Common Weakness Scoring System (CWSS) Bewertung erstellt werden soll. Das würde helfen, die einzelnen Einträge noch granularer zu priorisieren und einzuordnen.

Über den Autor

Mark Zeman hat seinen Master of Science in Engineering mit Vertiefung Information and Communication Technologies an der Fachhochschule Nordwestschweiz absolviert. Seit 2017 hat er seine Passion im Bereich Information Security zu seinem Fokus gemacht. Unter anderem hat er schon während seinem Bachelorstudium bei einer Email-Sicherheitsfirma gearbeitet. (ORCID 0000-0003-0085-2097)

Links

• https://cwe.mitre.org/cwss/
• https://pages.nist.gov/800-63-3/
• https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_2017_Project
• https://www.owasp.org/index.php/OWASP_Proactive_Controls