yamory Blog

セキュアな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を一瞬で解決するツールです。是非ともお試しください。

オープンソース脆弱性管理ツール yamory

  • 利用中のOSSを抽出し
    脆弱性を自動スキャン
  • 脆弱性への対応優先度を自動で分類
  • 組織規模に合わせたプランを選択可能

フリー

¥0

個人向け

1件ずつ Immediate な脆弱性を管理

1チームまでの開発チーム作成

yamory を使いはじめる

プロ

有料料金はお問い合わせください

中〜大規模組織向け

無制限で Immediate な脆弱性を管理

無制限の開発チーム作成

開発チームを俯瞰できるセキュリティチーム機能

危険な脆弱性の Slack 連携通知機能

特定のソフトウェアの脆弱性一覧を表示

特定の脆弱性を含むソフトウェア一覧を表示

Jira Cloud と連携

30日間の無料トライアルを開始