セキュリティチェックシート刷新への道：OWASP ASVS活用による改善事例
本文の状態
日本語全文を表示中
詳細モードで約7分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Mirai Translate Tech Blog
社内セキュリティチェックシートをOWASP ASVS基準で刷新した背景と活用ポイントを紹介。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るSource Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
この記事は「みらい翻訳 - Qiita Advent Calendar 2024 - Qiita」10日目の記事です。QAチームのyaboがお送りします。
当社では、常にセキュリティ対策を強化・改善し、より安全なシステム運用を目指しています。
その一環として、これまで社内で利用していたセキュリティチェックシートの内容を大幅に見直し、「OWASP ASVS」をベースとしたものにリプレースしました。
本記事では、その背景や国際的なセキュリティ標準である「OWASP ASVS」を活用したポイントなどについてご紹介します。これからセキュリティ対策を強化しようと考えている方や、既存の社内基準に悩んでいる方の参考になれば幸いです。
背景：なぜチェックシートを見直す必要があったのか
OWASP ASVSベースのチェックシートへのリプレース
背景：なぜチェックシートを見直す必要があったのか
当社では、社内で独自に策定したセキュリティチェックシートを活用し、リリース時に確認するようにしています。しかし、社内での運用が確立されておらず、セキュリティチェックシートの項目更新がしばらくの間されていない状態になっていました。
昨年、新しいプロジェクトを進める中で、この古いチェックシートを再度見たところ、「今のセキュリティ脅威に合った対策になっているのだろうか？」「なぜこの項目が必要なのか？」といった疑問が出てきました。
また、自分たちでセキュリティチェックシートの項目をメンテナンスし続けるのは手間も大きく、もっと効率の良い方法はないかと検討を始めました。
そこで目を向けたのが、世界中のセキュリティ専門家が参加するオープンコミュニティ「OWASP（Open Worldwide Application Security Project）」が提供する「OWASP ASVS（Application Security Verification Standard）」です。
ASVSは、Webアプリケーションのセキュリティ要件を体系的・段階的にまとめたガイドラインで、現在はv5.0への改訂が進められています。
ASVSには次のような特長があります。
段階的なレベル分け： アプリケーションの重要度や機密度に応じて、L1（Minimum）、L2（Standard）、L3（Advanced）の3段階で要件が整理されています。これにより、自分たちのシステムに必要なレベルを柔軟に選択できます。
CWEとのひも付け： 脆弱性の国際的な分類「CWE」と要件が対応しているため、セキュリティ診断ツールなどとの相性が良く、「どこがツールでカバー可能か」を把握しやすくなります。
継続的なアップデート： ASVSはGitHubを通じて日々更新されており、最新の脅威やベストプラクティスを常に取り込んでいます。これにより、自社で要件をすべて追いかける必要がなくなり、実質的に業界標準への「アウトソース」が可能になります。
また、コミュニティ主導で日本語版も作成いただいていることが採用の後押しとなりました。
OWASP ASVSベースのチェックシートへのリプレース
私達はこのたびASVSのL1レベルの要件をベースに新しいセキュリティチェックシートを作成し、そちらにリプレースを行いました。作成にあたっては、純粋な項目を列挙するだけでなく、記入しやすいフォーマットになるよう以下の点を工夫しています。
対策状況・リスクアセスメントの明記： 単純に「対策済・未対策」をチェックするだけでなく、「未対策の場合はどのくらいのリスクになると想定されるか」を記入するフォーマットにしました。各要件にも重要度の濃淡があると思われますし、現実的にすぐ対策できない場合もあるので、それらをディスカッションするベースとしてのフォーマットとできるようにしてあります。
ツール利用との整合： 弊社で利用しているペネトレーションテストツールであるZAPでカバーできる要件の範囲を明確化しました。具体的には、ZAPの示すアラートに付記されているCWEと、ASVS要件のCWE要件のマッチングを取り、その内容を確認しています。
日英併記、記入にあたっての補助項目の設定： 開発チームからのフィードバックにより、日本語訳の要件だけでなく、英語原文や、記載にあたっての補助情報を記載する列などを設けました。専門用語など内容の解釈が難しい項目もあるため、その記入を楽にすることを目的としたものです。
チェックシートの一例（英語原文・補助項目列等は折りたたんでいます）
今回のリプレースにより、いくつかのメリットが得られたように思っています。
要件の妥当性確保： 国際的な専門家コミュニティでメンテナンスされる基準を活用することで、「これ本当に必要な対策かな？」といった疑念を減らし、より納得感のあるチェック項目を使えるようになりました。
メンテナンス性の向上： 自前で要件を随時アップデートするのは大変ですが、ASVSはコミュニティベースで更新されます。その成果を取り込むことで、自社リソースを過度に割かずに済み、長い目で見た運用コストを下げられると考えています。
ツールや外部ベンダによる脆弱性診断との組み合わせの容易化： CWEによる対照により、ツールのスキャン結果とチェックシートを紐付けやすくなりました。また、外部ベンダに脆弱性診断を依頼する場合にも、ASVSベースでの議論が可能になりました。これによって、要件の網羅性の確認がかんたんになりました。
もちろん、ASVSの採用によりすべてが一気に解決したわけではありません。
運用上の手間： チェック項目がわかりにくい、つけるのが面倒、といった実務上の課題はまだ残っています。この点は、補助項目の充実や事例共有などを通じて、少しずつ改善していく予定です。
要件の洗練： 現在はたたき台として、L1レベルの要件をすべて確認することを基準にしていますが、将来的には重要度の高いシステムにはL2要件を確認したり、また逆に、自分たちには重要度の低い・必要がない項目はシートから外すような議論をできればよいと考えています。これらのディスカッションができるよう、シートの運用を通じて着実にレベルアップしていく方針です。
総合的なセキュリティ強化： ASVSはアプリケーションセキュリティ分野に強みがありますが、インフラ・ネットワーク・運用面も含めた総合的なセキュリティ対策には、他の基準やフレームワークとの組み合わせが欠かせません。現在は別のチェックシートでそちらを補完していますが、そちらのチェックシートの改善も行えるとよいと思っています。
セキュリティ対策は、短期的な効果が分かりづらい分野ですが、一度大きなインシデントが起これば事業に深刻なダメージを与えてしまいます。
今回のチェックシート刷新は、そうした「いつか訪れるかもしれないリスク」に備えるための地道な取り組みの一環です。ASVSという国際標準を取り入れることで、より信頼性・妥当性・メンテナンス性が高い仕組みを手にすることができたように考えています。
この取り組みが皆さんのセキュリティ対策を考える際の一助となれば幸いです。
OWASP Application Security Verification Standard (ASVS) | OWASP Foundation
GitHub - OWASP/ASVS: Application Security Verification Standard
GitHub - owasp-ja/asvs-ja: draft for Japanese translation of OWASP Application Security Verification Standard
Blog｜セキュアな Web アプリケーションを作るには？ Vol.01 OWASP ASVS 4.0.1 編 | yamory | 脆弱性管理クラウド | SBOM対応
セキュリティ診断のグローバル・スタンダードの紹介（OWASPセキュリティ診断基準と診断サービスの選定ポイント） | NTTデータ先端技術株式会社
原文を表示
この記事は「みらい翻訳 - Qiita Advent Calendar 2024 - Qiita」10日目の記事です。QAチームのyaboがお送りします。
当社では、常にセキュリティ対策を強化・改善し、より安全なシステム運用を目指しています。
その一環として、これまで社内で利用していたセキュリティチェックシートの内容を大幅に見直し、「OWASP ASVS」をベースとしたものにリプレースしました。
本記事では、その背景や国際的なセキュリティ標準である「OWASP ASVS」を活用したポイントなどについてご紹介します。これからセキュリティ対策を強化しようと考えている方や、既存の社内基準に悩んでいる方の参考になれば幸いです。
背景：なぜチェックシートを見直す必要があったのか
OWASP ASVSベースのチェックシートへのリプレース
背景：なぜチェックシートを見直す必要があったのか
当社では、社内で独自に策定したセキュリティチェックシートを活用し、リリース時に確認するようにしています。しかし、社内での運用が確立されておらず、セキュリティチェックシートの項目更新がしばらくの間されていない状態になっていました。
昨年、新しいプロジェクトを進める中で、この古いチェックシートを再度見たところ、「今のセキュリティ脅威に合った対策になっているのだろうか？」「なぜこの項目が必要なのか？」といった疑問が出てきました。
また、自分たちでセキュリティチェックシートの項目をメンテナンスし続けるのは手間も大きく、もっと効率の良い方法はないかと検討を始めました。
そこで目を向けたのが、世界中のセキュリティ専門家が参加するオープンコミュニティ「OWASP（Open Worldwide Application Security Project）」が提供する「OWASP ASVS（Application Security Verification Standard）」です。
ASVSは、Webアプリケーションのセキュリティ要件を体系的・段階的にまとめたガイドラインで、現在はv5.0への改訂が進められています。
ASVSには次のような特長があります。
段階的なレベル分け： アプリケーションの重要度や機密度に応じて、L1（Minimum）、L2（Standard）、L3（Advanced）の3段階で要件が整理されています。これにより、自分たちのシステムに必要なレベルを柔軟に選択できます。
CWEとのひも付け： 脆弱性の国際的な分類「CWE」と要件が対応しているため、セキュリティ診断ツールなどとの相性が良く、「どこがツールでカバー可能か」を把握しやすくなります。
継続的なアップデート： ASVSはGitHubを通じて日々更新されており、最新の脅威やベストプラクティスを常に取り込んでいます。これにより、自社で要件をすべて追いかける必要がなくなり、実質的に業界標準への「アウトソース」が可能になります。
また、コミュニティ主導で日本語版も作成いただいていることが採用の後押しとなりました。
OWASP ASVSベースのチェックシートへのリプレース
私達はこのたびASVSのL1レベルの要件をベースに新しいセキュリティチェックシートを作成し、そちらにリプレースを行いました。作成にあたっては、純粋な項目を列挙するだけでなく、記入しやすいフォーマットになるよう以下の点を工夫しています。
対策状況・リスクアセスメントの明記： 単純に「対策済・未対策」をチェックするだけでなく、「未対策の場合はどのくらいのリスクになると想定されるか」を記入するフォーマットにしました。各要件にも重要度の濃淡があると思われますし、現実的にすぐ対策できない場合もあるので、それらをディスカッションするベースとしてのフォーマットとできるようにしてあります。
ツール利用との整合： 弊社で利用しているペネトレーションテストツールであるZAPでカバーできる要件の範囲を明確化しました。具体的には、ZAPの示すアラートに付記されているCWEと、ASVS要件のCWE要件のマッチングを取り、その内容を確認しています。
日英併記、記入にあたっての補助項目の設定： 開発チームからのフィードバックにより、日本語訳の要件だけでなく、英語原文や、記載にあたっての補助情報を記載する列などを設けました。専門用語など内容の解釈が難しい項目もあるため、その記入を楽にすることを目的としたものです。
チェックシートの一例（英語原文・補助項目列等は折りたたんでいます）
今回のリプレースにより、いくつかのメリットが得られたように思っています。
要件の妥当性確保： 国際的な専門家コミュニティでメンテナンスされる基準を活用することで、「これ本当に必要な対策かな？」といった疑念を減らし、より納得感のあるチェック項目を使えるようになりました。
メンテナンス性の向上： 自前で要件を随時アップデートするのは大変ですが、ASVSはコミュニティベースで更新されます。その成果を取り込むことで、自社リソースを過度に割かずに済み、長い目で見た運用コストを下げられると考えています。
ツールや外部ベンダによる脆弱性診断との組み合わせの容易化： CWEによる対照により、ツールのスキャン結果とチェックシートを紐付けやすくなりました。また、外部ベンダに脆弱性診断を依頼する場合にも、ASVSベースでの議論が可能になりました。これによって、要件の網羅性の確認がかんたんになりました。
もちろん、ASVSの採用によりすべてが一気に解決したわけではありません。
運用上の手間： チェック項目がわかりにくい、つけるのが面倒、といった実務上の課題はまだ残っています。この点は、補助項目の充実や事例共有などを通じて、少しずつ改善していく予定です。
要件の洗練： 現在はたたき台として、L1レベルの要件をすべて確認することを基準にしていますが、将来的には重要度の高いシステムにはL2要件を確認したり、また逆に、自分たちには重要度の低い・必要がない項目はシートから外すような議論をできればよいと考えています。これらのディスカッションができるよう、シートの運用を通じて着実にレベルアップしていく方針です。
総合的なセキュリティ強化： ASVSはアプリケーションセキュリティ分野に強みがありますが、インフラ・ネットワーク・運用面も含めた総合的なセキュリティ対策には、他の基準やフレームワークとの組み合わせが欠かせません。現在は別のチェックシートでそちらを補完していますが、そちらのチェックシートの改善も行えるとよいと思っています。
セキュリティ対策は、短期的な効果が分かりづらい分野ですが、一度大きなインシデントが起これば事業に深刻なダメージを与えてしまいます。
今回のチェックシート刷新は、そうした「いつか訪れるかもしれないリスク」に備えるための地道な取り組みの一環です。ASVSという国際標準を取り入れることで、より信頼性・妥当性・メンテナンス性が高い仕組みを手にすることができたように考えています。
この取り組みが皆さんのセキュリティ対策を考える際の一助となれば幸いです。
OWASP Application Security Verification Standard (ASVS) | OWASP Foundation
GitHub - OWASP/ASVS: Application Security Verification Standard
GitHub - owasp-ja/asvs-ja: draft for Japanese translation of OWASP Application Security Verification Standard
Blog｜セキュアな Web アプリケーションを作るには？ Vol.01 OWASP ASVS 4.0.1 編 | yamory | 脆弱性管理クラウド | SBOM対応
セキュリティ診断のグローバル・スタンダードの紹介（OWASPセキュリティ診断基準と診断サービスの選定ポイント） | NTTデータ先端技術株式会社
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み