OWASP Application Security Verification Standard(ASVS)4.0.2読んでみる - 冒頭編
はじめに
存在を知っているだけで中身読んだことなかったなと思い、まずは冒頭だけ読んでみました。解説ではなく未来の私向けのメモ書きなので、ご興味ある方だけ、どうか参考程度に。
ASVSの目次
※V2以降全ての項目に「…の検証に関する要求」（Verification Requirements）がつくので省略。
- V1: アーキテクチャ、デザイン、脅威モデリングに関する要求
- V2: 認証
- V3: セッション管理
- V4: アクセス制御
- V5: バリデーション、サニタイゼーション
- V6: 格納する暗号文
- V7: エラーハンドリングとロギング
- V8: データ保護
- V9: コミュニケーション
- V10: 悪意あるコード（Malicious Code）
- V11: ビジネスロジック
- V12: ファイルとリソース
- V13: APIとウェブサービス
- V14: 設定（Configuration）
Frontispiece
用途
※「About the Standard」より
- ASVSは、アプリケーションセキュリティの要求 / テスト項目のリストです。
- 想定ユーザー
- 誰でも
- 例：アーキテクト、デベロッパー、テスター、セキュリティ専門家、ツールベンダー、消費者
- 想定用途
- 要件定義
- 構築
- テスト
- アプリケーションセキュリティの検証（verify）
歴史
2008年に1.0を策定した。
※「Preface」より
4.0の主な変更点
NIST 800-63-3に準拠した認証制御
あんまりモダンすぎるものを取り入れるのも反発がありそうだけど、色んな標準が違うことを言っているのとコストが高くつくから、固有の要件を減らす目的でこうしているっぽい。
NIST SP 800-63 Digital Identity Guidelines
番号付けスキームの変更
チームが従わなければならないコントロールの最小化
CWEへのマッピング
- 何でもかんでもマッピングしているわけではない
- CWEそのものに重複があるので過信は禁物
OWASP Top 10 2017とOWASP Proactive Controls 2018への対応
OWASP Top 10は過失を回避するための最低限の要件（the bare minimum to avoid negligence）という位置付けであり、ASVSレベル1として対応している。
PCI DSS3.2.1への対応
ASVSレベル1が、PCI DSS 3.2.1のセクション6.5をカバーできるようにしたみたい。
https://ja.pcisecuritystandards.org/minisite/env2/
※PCI データセキュリティ基準 バージョン3.2.1 要件とセキュリティ評価基準（日本語版）より
6.5 ソフトウェア開発プロセスにおいて次のようにして一般的なコーディングの脆弱性に対応する。
開発者に対して一般的なコーディングの脆弱性を回避する方法を含む安全なコーディング技法について少なくとも年に一度トレーニングを実施する
安全なコーディングガイドラインに基づいてアプリケーションを開発する
注:要件 6.5.1～6.5.10 にあげられている脆弱性は、このバージョンの PCI DSS が発行された時点の最新の業界ベストプラクティスを踏襲しているが、しかし、脆弱性管理のための業界のベストプラクティスは更新されているため（OWASPガイド、SANS CWE Top 25、CERT Secure Coding など）、現在のベストプラクティスは、これらの要件を使用する必要がある。
モダンなアプリケーション、開発手法への対応
モバイルセクションの廃止
MASVSというのが別であるかららしい。確かに目次にない。
影響の少ないコントロールの廃止
重複する項目とマージするなどしたみたい。
ASVSの2つのゴール
※「Using the ASVS」より
- 組織のセキュアなアプリケーションの開発・運用の手助け
- セキュリティ業者、ツール開発者、およびそれらの消費者の要求と提案の標準化（alignment）
アプリケーションセキュリティ評価レベル
3つのレベルから構成される。茶色は任意、緑は必須ってこと？
レベル1
低保証。ペンテスト可能。……とは言え、ブラックボックステストができる、というだけでは意味がない。ソースコード主導の侵入テストに置き換えて行くべき。攻撃者は長い時間をかけて脆弱性を探せる（それな）。
レベル2
センシティブなデータを扱うアプリケーション向け。ほとんどのアプリはレベル2を目指すべき。
レベル3
特に信頼性が必要なアプリケーション向け。
診断ツールとの付き合い方
- DAST / SASTツールを、ビルドパイプラインで自動的に動くようにしておいた方がいいよ
- 自動ツールやオンラインスキャンだけでは、ASVSの半分も満たせない
- ビジネスロジックとアクセス制御の欠陥は手動テストでしか見つけられない
ASVSの使い方
組織のセキュアコーディングチェックリスト（のベース）として。
ASVS要求（Requirements）の参照方法
- <チャプター>.<セクション>.<要求>という構成になっている。
- ASVSのバージョンが変わるとナンバリングも変わるので、外部参照する場合は「v<ASVSバージョン>-<チャプター>.<セクション>.<要求>」としたほうがよい。
（ASVSによる）評価と検証
OWASPのスタンス
OWASP自体は（ベンダーニュートラルな非営利団体として）特定のベンダーや製品を認定したりはしていない。かといって、企業によるASVSをベースとした認定サービスの提供を妨げるべきでもない。
ASVS認定機関向けのガイダンス
- レポートには、検証のスコープ（特に、スコープ外になるコンポーネント）と、成功・失敗の両方を含む検証結果のサマリーを提供しなければならない（歴史的には、不合格項目のみがレポートで取り上げられていたが）。
- 検証ログはちゃんと残しましょう。
テスト方法
どんな方法を使うかは自由だけど、レポートに示すこと。
自動スキャンツールの位置付け
- ツールで済ませられることは済ませちゃっていい（L1の項目とか）けど、全部それで済ませられないことは前述の通り。
侵入テストの位置付け
ブラックボックスな侵入テストができるだけの環境をL1と位置付けているけど、早いところソースコードやドキュメントを整備して、ハイブリッドな侵入テストができるような環境にしましょう（それな）。
