セキュアな Web アプリケーションを作るには？ Vol.02 ASVS 活用編
この記事は、セキュアな Web アプリケーションを作るには Vo.1 の続編です。
前回の記事では、Web アプリケーションをセキュアにする上で有用なドキュメントである OWASP ASVS についてその概要を紹介しました。
今回は OWASP ASVS を開発現場で活用していくにあたりどのように進めていくのが良いのか、ポイントと行き当たる問題を含めて yamory の見解を解説します。
ASVS を始めてみる
ASVS の活用手順
アプリケーションをセキュアにするための大まかな ASVS の活用手順を解説します。
1.ASVS を用意する
まず自組織が利用しやすい形式の OWASP ASVS チェックリストを作成しましょう。
すでに多くの方がチェックリストを作成、公開しているので、既存のものを流用することをお勧めします。
独自にチェックリストを作成する場合は公式が出している CSV 変換ツールを利用することと、以下の項目を組み込むことをお勧めします。
- 番号：OWASP ASVS の番号
- 要求事項：OWASP ASVS の要求事項
- 評価結果：
- 対象外：実施しない
- 未実施：要求事項を実施する予定はあるが、満たしていない
- 実施済：要求事項を満たしている
2. 現状把握
ASVS は目指すレベルによって大枠の要求事項が判明しますが、実際にはアプリケーションの特性やアーキテクチャ、事業のフェーズなどを踏まえて要求事項を取捨選択する必要があります。
その上で必要とした要求事項について、リリース前のセキュリティテストや既存のコーディングルールなどをもとに既存の機能で何を満たしているのかを現状評価し、未達事項を明らかにします。
3. 計画/実装
ASVS では、解決方法は複数ありアプリケーションによって最適な方法は異なるという考え方のもと、要求事項に対応する解決策は具体化されていません。
そのため要求事項によっては具体策の立案を導き出すことが難しいと感じる場合があります。
その際は、ASVS の参考情報として紐づいている ProactiveControll、OWASP Cheat Sheet 、DevGuide を確認することをお勧めします。
4. 検証
実装が完了したら、実装した要求事項が満たされていることを検証（担保）する必要があります。
現状把握で用いた手段により検証していくことはできますが、シフトレフトや負荷の観点からも可能な限りテストコードを用意していくことをお勧めします。
なおアーキテクチャ周りなど、あまり変更が発生しない要求事項に対してはヒアリングなどを用いる方がコストの面から有用です。
ASVS をはじめる際のポイント
スモールスタート
ASVS を初めて読む、または使ってみる人にとっては、各要求事項の定義を理解していくだけでも重い作業に感じることと思います。
そのため、まずは ASVS に慣れ親しむことを目的に適用対象を特定の小さいサービスや機能に限定し、適用する章も影響が全体に及び難いアプリケーションに閉じる章（V2,V3,V13 など）に限定することをお勧めします。
完璧を目指さない
ASVS は Level1 だけでも要求事項が 136 もあり、レベルに応じた要求事項を全て満たすことは容易なことではないと思います。
そのため、プロダクトのフェーズや事業特性と実装に必要なコストを天秤に掛けて、実装しないことを選択することも必要だと考えます。
ただし、チェックリストを用いて何が未達なのか（リスクを許容していること）を把握できる状態にしておくことをお勧めします。
時間を決めておく
セキュリティは将来の損失リスクを低減させる役割を担いますが、必ずしもいますぐの収益に直結しないため、セキュリティに投資する時間（セキュアにする時間）の確保が最も難しいと思います。
そのため、ASVS の未達項目をバックログとしておき、一定期間（1 週間単位など）でバックログを消化するなどあらかじめ時間を決めておくと動きやすいでしょう。
なお新しい機能においては、セキュリティ要件を考慮する際のリファレンスとして ASVS を用意しておくことで、初期段階から大凡のレベルでセキュアにすることはできます。
ASVS 活用の際の課題と解決策
ASVS の活用を始める上で直面するであろう課題と解決策を紹介します。
分かり難い記載
ASVS を読み進めていくと、要求事項の中に一見すると具体性に乏しく、何に対して対策すべきか、どのようなリスクを想定しているのか分かり難い項目があります。
この場合、項目の多くが Cheat Sheat や Proactive Controlls が参考情報として紐づいているので、問題を解決することはできるでしょう。
また、参考情報がない場合でも、昔のバージョン（3.0 以前）に含まれていた要求事項であれば、Web を検索することである程度の情報を得ることができます。
参考情報が紐づいておらず、かつ、4.0 及びそれ以降に取り込まれた要求事項で情報が不足している場合は、その要求事項ができるに至った経緯を GitHub のプルリクエストを通じて確認することをお勧めします。
＊ ASVS 4.0 から GitHub を使用して作成されたため、ほとんどの経緯を確認できます。
具体的な例として、V1 Architecture に関する章の一部を取り上げます。
V1: Architecture, Design and Threat Modeling Requirements
1.2.3 All authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.（OWASP ASVS v4.0.1）
（意訳）全ての認証経路とアイデンティティ管理APIは、アプリケーションのリスクを通じて脆弱な代替手段がないよう、同じ強度のセキュリティ管理が行われていることを検証する。
上記の要求事項の場合、具体的にどのようなリスクを想定しているのか、どのような箇所を想定しているのかは明らかではありません。
この要求事項が取り込まれることになった経緯を GitHub のプルリクエストから確認します。
New item: consistent controls on authentication and identity management APIs #529
An issue that continues to bite dev teams is creation of APIs that allow identity management operations（password changes, authentication, etc.）
[...]
Some examples would be, ensure API responses do not leak information（e.g. user existence）that is not available in other channels（e.g. the UI or other versions of the same API）. Ensure APIs for authentication prevent brute-force password guessing attacks with the same protections as other channels.（意訳）開発チームを悩ませている課題はID管理に関する操作（パスワード変更、認証など）を許容するAPIを作ることです。
[...]（意訳）例として API レスポンスが、他の経路（例：UI、異なるバージョンの同じ API）においても情報（例：ユーザの存在）を漏洩しないこと、認証 API はブルートフォースでパスワードを推測する攻撃を他の経路と同じ保護で防ぐことが挙げられます。
プルリクエストを確認した結果、上述の要求事項は、ユーザ情報などのアイデンティティ（ユーザ ID、パスワードなど）に関して、画面や他の API、同一 API の別バージョンがそれぞれ異なる保護仕様であることによって、別ユーザの存在確認やブルートフォースが成立するリスクを懸念しており、ユーザに関する情報等を管理するAPI、認証経路に対して同じ保護施策を求めていることが分かります。
要求を満たしたかは各自が判断する
ASVS は認定制度を持たないため、本当にそのレベルに達しているか確認するための手段は公式には用意されていません。
そのため自身の判断でどの程度のレベルにあるかを判断する必要があります。
この判断は ASVS やセキュリティに関する知見だけではなく、構成の理解を必要とする場合が多く、最初の段階では難しく感じることがあると思います。
なおレベル 1 ではペネレーションテストにより検証できますし、セキュリティ診断を行う会社によっては ASVS を元に診断する会社もあるため、最初は外部の力を借りることを検討しても良いかもしれません。
最後に
今回は ASVS の活用に関する yamory の見解を記載しました。
ASVS は透明性があり、かつ当面のリスクに対応する網羅的なドキュメントであるため、セキュアな Web アプリケーションを実現する上ではとても有用です。
しかしながら、実際に導入しようとした場合、初期は ASVS に対する不慣れさや要求事項の多さから負担を感じると思います。
ASVS は毎日の開発で意識しければならないような、変更頻度の高い要求事項が多くないため、これらの負担意識は時間の経過とともに落ち着くと思います。
yamory では引き続き、ASVS の活用に関する情報発信を行っていきます。
今後ともどうぞよろしくお願いいたします。
また yamory は、ASVS の要求事項 14.2.1、14.2.5、OWASP Top10 A9 を一瞬で解決するツールです。
是非ともお試しください。
