OWASPとはどのような団体なのか？
OWASPとはアメリカを本拠地とした非営利慈善団体で、Open Worldwide Application Security Projectの頭文字を取っています。
主にソフトウェアのセキュリティに関する情報やツールを提供していくコミュニティで、会員は数万人以上、世界中に250以上の支部があります。日本にも10個ほどの支部があります。
集まっているのはソフトウェアのセキュリティ向上に関与する開発者やエンジニアなどのコミュニティです。ツールやコード、ドキュメント、ガイドラインに関してコミュニティが主導となって全てオープンソースで提供しています。
OWASPには数多くのプロジェクトが存在している
OWASPのプロジェクトはかなりの数がありまして、1つの支部だけで作られているものや、世界中からメンバーが参加して作っているものもあります。
その中で特に有用なのがFlagship Projectsで、OWASPとアプリケーションセキュリティ全体にとって、戦略的価値を実証したプロジェクトです。基本的に皆さんが活用する際はFlagship Projectsが多いと思います。
Production Projectsは本番稼働が可能で、皆さんのビジネスにも活用できるプロジェクトです。他にもLabやIncubatorという形のものもあります。
Flagship Projectsはこれだけの数がありまして、この中でいくつか使ったものもあるんじゃないかと思いますが、今回紹介するのは一部です。
1番メジャーなのはOWASP Top10というランキングだったり、最近だとSBOMとソフトウェアの部品管理表の規格でメジャーになっているCycloneDXですね。 Flagship Projectsをまず見れば、OWASPが何をしていてどういうものを提供しているのかが分かります。
ただ、 多くのプロジェクトは主に英語で提供されていて、一部は日本語の翻訳を行っているものもあります。現在は英語でも様々な翻訳ツールがあるので問題無く使えると思います。
次はFlagship以外の代表的なプロジェクトについて、全体→要件定義→設計→開発テスト→運用・保守という開発の典型的な流れに沿って挙げていきます。
世界中のWebアプリケーションのセキュリティの基準となるOWASP Top10
Webアプリケーションに関するセキュリティのリスクに対処すると当然コストがかかるので、リスクが高いほど対処する優先度も高くなります。
様々な機関がランキングを発表していますが、OWASPのTop10は世界中の色々なガイドラインの中で参照されています。
ガイドラインの中ではOWASP Top10に記載のリスクに対応しなければならないと書かれておりますので、OWASP Top10を参考にするのはプロダクトをセキュアにしていくのに理にかなっていると思います。
現在はOWASP Top10:2021が最新です。 通常のランキングは1年ごとが多いですが、OWASPは3年〜4年間隔で更新しています。
細かい内容の解説はしませんが、1位はアクセス制御、2位が暗号化の失敗、3位がインジェクション（SQLインジェクションやクロスサイトスクリプティングなど）です。4位以下はスライドの通りです。
こちらのTop10は以下のURLで日本語訳も出ています。
https://owasp.org/Top10/ja/
あと、Top10は単なるランキングだけではなく、脆弱性や防止方法、攻撃方法の解説も含まれています。
安全なWebアプリケーションの開発要件をまとめたWebシステム/Webアプリケーションセキュリティ要件書
Webアプリケーションを開発する際にはウォーターフォールであれアジャイルであれ、セキュリティの要件定義が必ず必要となってきます。
こちらはOWASP Japanで展開しているもので、海外と日本で要件が異なるわけではないですが、一部日本的な開発の文化なども加味したものが要件書に含まれています。 例えば、認証の部分をどのように作れば安全なのかという要件が書かれています。
セキュリティの多くの問題はどういう脅威があるかが一般的に知られていますが、そのような問題に対しての対処方法や予防方法のセオリーを知ることができるのがこちらの要件書です。
例えば、セッション管理のセッションの破棄について、一定時間以上アイドル状態の時にはセッションタイムアウトとするという対応で、必須または推奨の対応なのかが書かれたりしています。
業界のスタンダードとなっているOWASP ASVS
次に紹介するのはOWASP ASVSです。Application Security Verification Standardの略で、業界のスタンダードとして使われているアプリケーションです。
セキュリティ検証標準では、設計や開発、テストに必要なセキュリティ要件と管理策のフレームワークの標準化が提供されております。
ASVSでは要求されるセキュリティレベルを3段階に分けて、それぞれで必要なものが細かく書かれています。 レベル1はあらゆるWebアプリケーションで必要なもので、レベル2がある程度セキュリティを要求されて、レベル3がさらにセキュリティを要求されるものになります。
何を達成すればそのレベルに当たるのかは色々なガイドラインで相互参照されていることも多く、ASVSで言うとレベル2に適合するようにしましょうみたいな感じで書かれていたりします。
これらの項目は単に先ほどの認証だけではなく、ログの記録をどうしなければいけないかとか、ビジネスロジックをどうするかとか、構成の検証要件など結構幅広く書かれていて、開発の過程で必要なものが記載されているのでぜひ参考にしてください。 日本語では最新から一つ前のバージョンが提供されています。
セキュリティに関する設計や実装の事例をまとめたOWASP Cheat Sheet Series
Cheat Sheetとはいわゆるカンニングペーパーで、様々なセキュリティトピックに関する設計や実装の事例集です。 先ほど紹介したOWASP Top10やASVSとのCheat Sheetの対応表もあります。
Ajaxのセキュリティやアクセスコントロール、認証・認可など幅広いものがシートには載っています。細かいところでは、DOM basedのクロスサイトスクリプティングに対する防止策など全部で100個はあります。
それぞれ設計方法や実際のコードも書いてあるので、参考になると思います。
最低限求められるテスト項目と手順が書かれたWebアプリケーション脆弱性診断ガイドライン
こちらは日本で公開していますが、 元々は脆弱性診断を提供する事業者向けに書いたものなんです。 昔は脆弱性診断の事業者のレベル感がバラバラだったので、最低限どの事業者もここまで実施しておくべきという診断項目をピックアップしています。
書き方は割とプロ向けで、手動で行う診断の項目を主に記載しています。 詳しい方は見れば分かると思いますが、スライド内でピックしているのは、クロスサイトスクリプティングの診断でパラメーターの欄に書いている検出パターンを入れてリクエストを送るという形です。
そうすると、適切にエスケープされずにこのタグが動作をするというやり方が書かれていて、全部で100項目はあるので初心者の方が使うのは難易度が高いかもしれません。ただ、この項目をしっかりテストできれば、安全なWebアプリケーションになります。
あと、OWASPの本体の方のプロジェクトとして展開しているOWASP Testing Guideもあります。 こちらも世界的なガイドラインの中で、このTesting Guideに従ってテストしましょうと書かれています。
Webアプリケーションに関するテストの中でももう少し荒く広い感じで展開しているので、ぜひ参考にしてください。
脆弱性を自動診断できるZAP
ZAPに関しては元々OWASPのプロジェクトだったのですが、今は独立しています。
こちらはプロキシ型と呼ばれるWebアプリケーションの脆弱性診断です。ブラウザとサーバーの間にプロキシとしてZAPを挟むと、その間のリクエストレスポンスを記録したり、テストのパターンとしてリクエストを少し書き換えて送ったりできます。
ZAPは手動の診断もできますが、自動診断にも対応しています。URLを入れてボタンを押せば、Webアプリケーションの診断を行ってくれます。 ただ、完全な自動ではなくて、「ログインはどのようにしなければならないか」などを記録させたりする手順があります。
コマンドラインからの実行もできますので、今時のCI/CDのパイプラインの中に組み込んで開発することも可能です。
ZAPは利用者も非常に多く、ZAPの使い方の記事も日本語で公開されているので、ぜひ使ってみてください。
ソフトウェアの構成を分析できるOWASP Dependency-Check
次に紹介するのはOWASP Dependency-Checkで、ソフトウェアの構成分析ツールであるSCA(Software Composition Analysis)と呼ばれるツールの1つです。
log4jで以前事件がありましたが、アプリケーションには開発の過程で色々なライブラリが利用されます。 そのライブラリがさらに別のライブラリを読んでいることもあったり、そのライブラリのアップデートなどで脆弱性ができてしまうことがあります。
しかし、その脆弱性に気付くのは非常に難しいわけですね。 運用の過程で最初はアップデートして最新版になっていますが、1年も経つと脆弱性があるのに気付かないことも考えられます。
例えば、GitHub上では脆弱性を検知してアラートしてくれたりしますが、全てを管理できるわけではないので、これを手元でチェックできるツールがDependency-Checkです。コマンドライン版やプラグイン版などもあって、jQueryのバージョンが古いとか、こういう脆弱性があるというのをレポートで簡単に挙げられます。
そのため、Webアプリケーションを開発した本体だけではなく、そこで利用しているライブラリや脆弱性などを発見できるようになります。
このように様々なプロジェクトがあって何を活用したらいいかわからないときは、OWASPのプロジェクトのページにあるApplication Security Wayfinderが便利です。
例えば、設計(Design)の段階で活用できるプロジェクト、実装の段階で使えるドキュメントやツールが分かるようになっています。
こちらのページにアクセスして、目的に応じたプロジェクトを見つけて活用してみてください。
ボランティアと寄付で成り立っているOWASPの運営
最後はOWASPの運営に関して紹介します。
OWASPは基本的に全てボランティアで成り立っています。私もボランティアで完全にやっていますので、メンバーになっていただいたりプロジェクトをサポートしていただけると嬉しいです。
運営は寄付で成り立っていまして、個人会員は年間50ドルから受け付けております。お得なのはライフタイムの500ドルで、個人にとっては少し高いかもしれませんが、ぜひご検討いただければと思います。
そして、サポートするチャプター(支部)を選ぶことができます。私はOWASP Japanというチャプターですが、他の地元のチャプターなども選べます。
また、企業として参加することも可能です。基本的には非営利団体なので企業色を強く出せないですが、ロゴを掲載できます。その代わりに我々がイベントをするときに会場を貸していただいたりします。
あと、ワーキングループに参加する形もあります。我々がやっているプロジェクトの1つに脆弱性診断士スキルマッププロジェクトがあります。このプロジェクトでは先ほどの脆弱性診断のガイドラインや要件定義書を有志でずっと作り続けています。 こちらに参加したい・協力したいという方は参加していただけると嬉しいです。
さすがにそこまではやれないし時間も無いという方にも、先ほどのZAPは日本語に翻訳するのに1単語から参加できるという気楽なプロジェクトもあって名前なども載せられます。
ぜひそういった貢献をしていただけると助かります。
運営が用意したテーマによるディスカッションへ
――ここからは運営の方で用意したテーマに沿って進めていきます。最初は「OWASPのセキュリティ対策のフレームワーク・プロジェクトの活用方法」についてです。実際にプロジェクトや組織でOWASPの成果物を活用しようと思った場合に、 優先的に適用した方が良いものなどがあればお願いいたします。
上野：まずは社内にセキュリティの文化を作らないといけないと思います。 今日参加されてる方だけが「セキュリティやるぞ」と言っても、なかなかチームや会社は動かないと思います。
OWASP Japanの先ほど紹介した脆弱性診断スキルマッププロジェクトの1つに、アジャイル開発におけるセキュリティ|パターン・ランゲージというドキュメントがあります。
パターン・ランゲージは開発者の方には馴染みがある書き方だと思いますが、ここに「チームビルディング」という項目を作っていまして、セキュリティ・チャンピオンというセキュリティーを推進していく係があります。
別にセキュリティに詳しい必要はないですが、推進していく係の作り方やセキュリティの向上のためのルールの整備方法、アジャイル開発の中での要件の決め方、セキュリティのテストの実施・改善方法などが書かれています。
特にこれから始めようという方にはチームビルディングの部分が重要なので、セキュリティに対してどう責任を持って取り組んでいくのかを見ていただければと思います。
セキュリティチャンピオンの役割やその他参考資料も載せていたり、OWASPのドキュメント、ツールも紹介していたりしますので、こちらも参考にしてみてください。
――こちらの資料の中で、例えば実装やテストの時にASVSなどの設計の部分の指南書を役立てたいとなった場合におすすめのアプローチや手順も載っているのでしょうか。
上野：そうですね。例えば、開発者向けのおすすめのトレーニングがあって、同業他社のインシデントの事例をベースにして、そこで発生しやすい脆弱性について書いていたりします。参考資料としてOWASPが提供しているドキュメント以外にも、学ぶのにおすすめの外部のコンテンツも書いてあります。
――続いてのテーマです。「セキュリティ脆弱性診断の進め方とポイント」ということで、今度はセキュリティ対策として必須とも言える脆弱性診断にフォーカスを当てて、OWASPの成果物の活用方法を聞いていければと思います。まず、脆弱性診断を行うための使い方を改めて教えていただければと思いますが、いかがでしょうか。
上野：本当に初級の方がされるのであれば、ZAPが良いと思います。 ZAPには自動診断というツールが付いているので、それをまず使っていただくと良いです。ただ、ZAPを使うためにはZAPがどのように動くのか、クロールするのかを教えるフェーズがあって正しい使い方を学ぶ必要があります。
OWASP ZAPの方では、日本語のドキュメントやチュートリアルが充実しています。 あと、私が出している脆弱性診断ガイドという本でもZAPの使い方を書いていますので、その辺を見ていただければまず一通りの診断ができるようになると思います。
――ZAPに加えてWebアプリケーションに最低限必要な診断項目や手順書を一読することも必要でしょうか。
上野：そうですね。ZAPでできる診断は、基本的にはインジェクション周りなので、本当にカバーする必要がある全てのセキュリティリスクをチェックできていません。
全てをカバーするには手動で行う脆弱性診断が必要です。その辺りは先ほども紹介したガイドラインを使って診断する必要がありますね。この辺も我々のドキュメントや私の本に記載しているので、ぜひ参考にしてください。
――続いてのテーマです。「セキュリティチェックを開発段階で行う際にOWASPのツールでどのように自動化するのか」についてですが、アプローチ方法を含めていかがでしょうか。
上野：CI/CDのパイプラインに組み込むのが良いと思いますね。そして、OWASPのドキュメントではないですが、CISというアメリカの団体が出しているソフトウェアサプライチェーンのセキュリティガイドを参照すると良いです。英語版ですが、ソフトウェアの開発からリリースまでで何をすべきかが書いてあるので、 参考になると思います。
――そういったものを用いて検出された脆弱性への対応に関しては、今度は自動化などで対応を効率化していくのが良いのでしょうか。
上野：今答えることは難しいですね。我々のワーキンググループでトリアージガイドライン作成の手引きを作ろうとしていて、発見された脆弱性を何日以内に対応するとか、この脆弱性は対応する/しないを判断するガイドラインになりますので、完成まで少々お待ちください。
視聴者からの質問に答える質問タイムへ
――ここからは視聴者の質問に答えていきます。一つ目は「各プロジェクトは大体何人ぐらいで作っていらっしゃるのですか」とのことですが、いかがでしょうか。
上野：ピンキリですね。例えば、私がやっている脆弱性診断スキルマッププロジェクトでは、大体常時20人ぐらいで稼働していますね。 全体では100人近くいまして、皆さんは普段の業務がある方が多いので、時間を合わせられる方がどんどん参加していく形です。
海外のプロジェクトの場合は全部オンラインで完結できるので、英語が問題無く話せる方であれば、OWASP Top10の本家に参加していただいたりできます。
――続いて、「セキュリティ対策を組織に定着させて、継続的に改善していくコツやアドバイスがあれば教えてください」とのことですが、いかがでしょうか。
上野：チームビルディングにおいて誰かが責任を持って進めていかなければならないような文化の作り方とかも先ほどのドキュメントで紹介しているので、参考にしてください。
――続いて、「Cheat Sheet Seriesを開発者が効率的に活用するためのポイントは他にありますか」とのことですが、いかがでしょうか。
上野：なかなか効率的にやっていくのが難しいんですが、そのために先ほどのWayfinderができたんですね。Wayfinderの真ん中にOPENCRE.orgというのがあるんですが、これはOWASPの検索エンジンです。問題点を入れると参考になるものを出してくれるので、OPENCRE.orgを見ていただくのが1番良いと思います。
――続いて、「有償の脆弱性診断のツールとOWASP ZAPの違いを知りたいです」とのことですが、いかがでしょうか。
上野：脆弱性の発見に対するレベル感で言うと、有償もZAPも基本的には変わりません。 我々の提供している脆弱性診断ガイドラインやCheat Sheet Seriesには検証のパターンが載っています。世界中の脆弱性診断ツールの開発者はこういったものを見て参考にするので、品質の精度はあまり変わらないんです。
ただ、有償版とZAPの違いでまず挙げられるのは診断に関するサポートの手厚さですね。自動診断ではログインをどうやっていくかを教える必要があるという話をしましたが、効率の良い正しい診断のやり方は有償のツールの方が充実していますね。
有償の方は日本で買える日本語版があるので、 ツールの性能や使いやすさはどちらもそこまで変わりません。あとは好みですね。
――続いて、「OWASP ZAPを利用するにあたってどの程度のスキルが求められるのでしょうか」とのことですが、いかがでしょうか。
上野：基本的に開発者であれば使えると思います。普通の機能テストや性能テストができる方なら実施できます。 設定として難しいものは無いです。
ただ、レポートが自動で診断した場合には読み解くのに専門的なセキュリティの用語が入ってきますが、その言葉を検索して出てきたリファレンスを読めば理解が深まります。
ZAPはコミュニティも結構ありまして、日本でもOWASP ZAPを使った無償の勉強会も開催していますので、そういったコミュニティに参加するのもありだと思います。
――続いて、「「御社の脆弱性診断はASVSの3レベルのうち、どのレベルで診断していますか」と質問されることがあるのですが、 OWASP Testing GuideとASVSの3レベルの関係性はどのようになっているのでしょうか」とのことですが、いかがでしょうか。
上野：元々の関係性では別のプロジェクトなので、直接の関わりはありません。とはいえ、皆さんは両方を使う場合が多いですね。
OPENCRE.orgだと関連付けも出ていたりするので、レベル3であればこの辺のTestingを実施しなければいけないというのもあったりします。直接の関わりが無くて別のプロジェクトなんですが、なるべくすり合わせるようにはしています。
――続いて、「セキュリティ対策を進める上で陥りがちな問題点や誤解にはどのようなものがありますか」とのことですが、いかがでしょうか。
上野：誤解で言うと、セキュリティ対策をするとコストが増えると思っている方が結構多いですが、実はそうではないですね。
当然ゼロベースから学んでいくところにはコストがかかりますが、ある程度学んでしまえば、セキュリティ対策をして作ったアプリとそうではないアプリの作りのコストはあまり変わらないと思います。
結局は正しい作り方で作ればいいだけという話なので、Webアプリケーションの設計・要件定義・設計・開発・テストまで行くとそこまでコストが変わりません。
――続いて、「OWASPのツールによる脆弱性診断でカバーしきれないものだとベンダーを使う手段もあるかと思いますが、上手に組み合わせる方法はあるのでしょうか」とのことですが、いかがでしょうか。
上野：私が考えるのは、普段の日常的なアジャイル開発やスプリントごとのテストに関しては無償ツールや自動診断ツールを回して、リリースの段階ではベンダーによる診断をしっかりやった方が良いと思います。自分の組織の中に脆弱性診断ができる方がいればその方に頼るのもありです。
――続いて、「脆弱性診断を外部に委託する場合の選定ポイントはありますか」とのことですが、いかがでしょうか。
上野：経済産業省の方でベンダーに関する検索ができるので、そちらを確認するのが良いかと思います。
あとは実際に話してみないと多分わからないですね。自分たちの作っているアプリケーションをどの程度理解してもらえるかは重要です。まずベンダーさんに話を聞いてもらう段階からスタートしても良いんじゃないでしょうか。
――続いて、「ワーキンググループは会員のみが参加可能でしょうか」とのことですが、いかがでしょうか。
上野：会員でなくても参加可能です。別にお金を払わなくても色々なプロジェクトに貢献していただけるだけでも非常にありがたいです。
――続いて、「OWASPに貢献したい場合は個人よりも会社経由でアプローチした方が良さそうでしょうか」とのことですが、いかがでしょうか。
上野：そうですね。我々もお金がどうしても必要な場合がありますので、会社さんの大きいお金は助かりますね。ただ、何かプロジェクトを作っていくのは個人の力になってきますので、自分自身が活躍したい、活動したいというのであれば、個人で入っていただくのが良いかと思います。
――続いて、「OWASPで今最も注目されているプロジェクトやその動向はありますか」とのことですが、いかがでしょうか。
上野：バズワード的なところで言うと、SBOMの規格のCyclone DXですね。SBOMはソフトウェア部品表と呼ばれているもので、アプリケーションに依存してるライブラリやフレームワークを全部一覧にしています。
その一覧表の規格が世界中でいくつか乱立している状態なんですね。なので、何を中心に考えるかですね。 例えば、ライセンスの管理や脆弱性を中心に考えるのかと言った感じで、今後どの規格が先行していくのかは注目していますね。
