脱初心者！ ASVS（Application Security Verification Standard）とは

社内定例で読むようにと共有された「OWASP アプリケーションセキュリティ検証標準 4.0」
入社1年ほどの自分ですが、1度読むだけではあまりにもとっつきにくく、理解ができませんでした。
序章部分だけでも理解できれば...と調べて自分なりに簡単な言葉でまとめてみました。

## この記事を読むとどうなるか

#### ASVSについて無知な状態から知ったかぶりができるようにはなります...

## 目次
* OWASPとは
* ASVS（Application Security Verification Standard）
    * アプリケーションセキュリティ検証標準 (ASVS)とは
    * バージョン4.0の更新内容

* ASVS の使い方 
    * ASVS の主な2つの目標
    * レベルについて
    * 活用方法

* 参考記事

 ## OWASPとは
　webアプリケーションに関わる意思決定を行う人たちや、開発者に向けて、Webアプリケーションを取り巻く課題の解決を目指すオープンなコミュニティのことです。
組織が信頼できるアプリケーションやAPIを開発、購入、維持できるように支援しており、全てのOWASPのツール、ドキュメント、ビデオ、プレゼンテーション、そしてチャプター(支部)は自由でオープンなものであり、アプリケーションセキュリティを改善する人なら誰でも活用することができます。

　有名な取り組みの一つとして「OWASP Top 10」があります。
開発者とWebアプリケーションセキュリティのための標準的な啓発文書であり、Webアプリケーションにおけるリスクの種類をランキング形式で公表しています。
[OWASP Top10](https://owasp.org/Top10/ja/)

## ASVS（Application Security Verification Standard） とは

### ASVS（Application Security Verification Standard） ＝ アプリケーションセキュリティ検証標準 (ASVS)

OWASPコミュニティーが公開している、Webアプリケーションセキュリティの評価ガイドラインのことで、トレンドに沿った基準や要件の更新も活発に行われています。14ものカテゴリに分類されおり、開発体制、ログ、認証、ログインフォームの設計等、実装についての各種検証要件が記述されており、多くの企業、開発者が開発する際のセキュリティ評価ガイドラインとして採用しています。

以下14のカテゴリ
* V1 アーキテクチャ、設計、脅威モデリングの要件
* V2 認証検証の要件
* V3 セッション管理検証要件
* V4 アクセス制御検証の要件
* V5 検証、サニタイズ、エンコーディング検証の要件
* V6 保存された暗号検証の要件
* V7 エラー処理とロギング検証の要件
* V8 データ保護検証の要件
* V9 通信検証の要件
* V10 悪意のあるコードの検証要件
* V11 ビジネスロジック検証の要件
* V12 ファイルとリソースの検証要件
* V13 APIおよびWebサービス検証の要件
* V14 構成検証の要件

### バージョン4.0の更新内容

1. 更新項目
`バージョン3.0` の時点では、開発者が同じ項目を何度もテストをしないですむように、重複の排除を行っています。
更に`バージョン4.0`では、最初から最後まで全面的に番号が付けられており、尚且つ検証要件がカテゴライズされたことで、不要なテストは行わず最小限に抑えられるようにしています。

2. 新規項目
共通脆弱性タイプ一覧CWE　(Common Weakness Enumeration)の内容が含まれるようになりました。
共通脆弱性タイプ一覧CWEとは、ソフトウェアの脆弱性の種類を識別するための基準のことです。
ASVSにて網羅されたことで、共通脆弱性タイプ一覧CWEの結果をバージョン4.0に対応させることができます。

ツール開発業者と脆弱性管理ソフトウェアを使用しているユーザーは他のツールや、以前のASVSのバージョンの結果を一致させて使用することができます。

## ASVS の使い方 
### ASVS の主な2つの目標

ASVSはの目標として以下の2つをあげています。
**1. 組織がセキュアなアプリケーションを開発および保守するのに役立つこと**
**2. セキュリティサービスベンダ、セキュリティツールベンダ、および利用者が、各々の要件とプロダクトを調整できるようにすること**

つまり、社内外、別案件セキュリティに対しての関係者とも共通の診断基準として定めることで、診断漏れを防いだり、診断の品質を保つことが可能になります。


### レベルについて
レベルは3段階に分けられています。
| レベル |概要|
|--|--|
| ASVS レベル 1 |最低保障レベル : 機密データを取り扱わないようなアプリケーション | 
| ASVS レベル  2 | 推奨保障レベル : 機密データの扱いがあり、保護が求められる、多くのアプリケーションに該当|
| ASVS レベル 3|最高保障レベル : もっとも重要なアプリケーションで、高機密トランザクションが含まれる|


### 活用方法
ASVSを使用したセキュリティチェックの一例です。ASVSを基にセキュリティチェックリストを作成しセキュリティテストを実施します。

活用方法例

**1. セキュリティチェックリストを作成する**
ASVSを参照し利用しやすい形式のセキュリティチェックリストを作成します。すでに多くの方がセキュリティチェックで作成したチェックリストを公開しているので、1から作成せずに、それらを流用して使用することも可能です。　
先述したようにASVSにはレベルが存在しているので、目指すレベルによってセキュリティチェックする内容が決まりますが、実際にはアプリケーションの特性やアーキテクチャ、事業のフェーズなどを踏まえてチェック事項を取捨選択する必要があります。

**2. セキュリティチェックを行い、現状を把握する**
実際にセキュリティチェックを行い、既存のコーディングルールなどをもとに既存の機能で何を満たしているのかを現状評価し、未達事項を明らかにします。

**3. 計画/実装**
現状を把握したら、未達成事項をどう解決していくのかの具体案の検討を行い、実装します。
ASVSではセキュアなアプリケーションが満たすべき項目について定義されていますが、それらを満たしていない場合どう解決するのか、の部分は明記されていません。そのため項目によっては解決するにはどうすればいいか検討が難しい場合もあります。
その際は、ASVS の参考情報として紐づいている `ProactiveControll、OWASP Cheat Sheet 、DevGuide` を確認することが可能です。

**4. 再度セキュリティチェックを行い、未達成事項が達成できているか検証を行う**
実装が完了したら、現状把握時点で未達成だった項目が満たされていることを検証（担保）を行い、全て達成できていることが確認できたら、セキュリティチェックが完了したこととなります。

## まとめ

ASVSという国際的に認知されている評価基準を使用することで、診断基準の統一化、最適なセキュリティチェックが可能になる、Webアプリケーションセキュリティの評価ガイドラインです。
さらに、ベストプラクティスの確認としても使用するこができるので、まだ、概要部分、使用方法今後チェックリスト部分の内容も読み、理解を深めたいと思いました。

#### 参考リンク
[ASVS バージョン4.0](
https://www.saj.or.jp/documents/NEWS/pr/20200903_OWASP_ASVS4.0-ja.pdf)
[ASVS バージョン3.0](
https://jpcertcc.github.io/OWASPdocuments/ASVS/OWASPApplicationSecurityVerificationStandard3.0.pdf)
https://www.shiftsecurity.jp/cloud-blog/20211020-1
https://qiita.com/AeyeScan/items/0a5ba6605daa92a6ddee