Webセキュリティの“モヤモヤ”の正体はなに？　セキュアの共通認識を形成する「OWASP ASVS」

Webセキュリティのモヤモヤを解消する

佐々木 氏（以下、佐々木）：それでは始めます。本日は「セキュアなWebアプリケーションとは何か？」について、私佐々木から発表いたします。

前半は、なぜこのテーマを取り上げたのかという背景と目的を説明します。その上で、セキュアにすることがなぜ難しいのかということについて考察した結果を共有します。後半はセキュアにすることを容易にするツールであるOWASP ASVSについて解説し、実際に始めてみるということに関して、yamoryでのトライを簡単に共有します。

それではさっそく本題に入ります。まず、なぜこのテーマを取り上げたのかについてお話いたします。業務上、私はいろいろな方々とお会いしているのですが、セキュリティに取り組む際の課題としてよく聞くものが次の2つです。

1つ目は、対策がたくさんある中で何をすべきなのか悩ましいということ。SAST、DAST、例えばIPS、IDS、WAFなどいろいろセキュリティの対策手法というのは数多くありますが、どれを入れたらいいのか判断が付きにくいということです。

2つ目は、完璧なセキュリティというのはなかなかないと思っています。その中で自分たちはどこまで何をやればよいのか悩んでいる、ということをよくお聞きします。こういった課題に関して、yamoryが一発で解決できれば非常に望ましいのですが、残念ながらそういうわけではありません。

この場を介してこういった課題をお持ちの方々の助けに少しでもなればと思い、取り上げました。言い換えると今回のこのプレゼンテーションの目的は、Webセキュリティのモヤモヤを解消するということです。

セキュアなWebアプリケーションを作るのはバラバラな意見をまとめるようなもの

セキュアにしようとしたときになぜそれが難しいのか、なぜモヤモヤが存在するのかということをお話したいと思います。結論から申し上げますと、人によりセキュアということに関してイメージが違うからだと思っています。どういうことなのかと言うと、私が以前聞いたことのあるセキュアなWebアプリケーションの見解をいくつか紹介します。

人によってはセキュアな開発を行うこと、また人によってはテストを厳重に行うこと。また別の人はアプリケーションが設計通りに動くこと、というようないろんな見解が出てきます。人それぞれ得た知識とか経験によって、セキュアなWebアプリケーションというもののゴールが違うのではないかと思います。

この結果、セキュアなWebアプリケーションを作るのはバラバラな意見をまとめるようなもので、大変難しいことになります。そのため、セキュアなWebアプリケーションを作るということに関して、同じゴールを認識することが大事だと思います。

今回お話しする認識をもつためのツールがOWASP ASVSです。それでは後半のASVSの解説をしたいと思います。あくまでこちらは非公式、あくまでファンとしての解説になりますので、ご容赦ください。

OWASP ASVS とは

ASVSとは何かについてですが、一言で言うと開発者、セキュリティエンジニア、テスター、いろんな方々が使えるセキュアなWebアプリケーションの定義です。私がピックアップしたASVSの特徴を軸にもう少し深堀りします。こちらの3つで、1つずつ説明していきます。

1つ目の網羅的なセキュリティの基準ということに関してですが、ASVSは14個のチャプターという章と286項目で構成されています。この数を見ればわかるかと思いますが、非常に詳細に定義されています。「網羅的」と言われてもイメージが付かないと思うので、少し簡単に説明します。

（スライドを示し）これが簡単なWebアプリケーションの全体像のイメージだと思ってください。Webアプリケーションというのは大きく利用者とか外部サービスとかそういったところから、データベースとかログの管理とか開発者のコードの管理である等のアーキテクチャみたいなものと、アプリケーションの本体、本当にコードを書いて作りあげていく3つの層に分かれていると、ザックリ思ってください。

この図にASVSの各チャプターをマッピングしてみるとどうなるのかと言いますと、その結果がこちらです。パッと見てわかる通りASVSというのは非常に網羅的に考えられた基準であるということが、わかってもらえたかなと思います。次は、詳細に定義しているということに関して少し説明したいと思います。

実際にこのロギングの章、7.1.1のところを見てみます。意訳ですが、アプリケーションは、ログにクレデンシャル情報や支払い情報を含めないこと。そしてセッショントークンは、不可逆なハッシュ形式で保存することというようなかたちで、開発者の方でも何をしなければいけないのかというのが非常にわかりやすく書かれています。

要はアクショナブルなドキュメントだということがわかってもらえたらなと思います。

アプリケーションの重要度別に定義

続いて2つ目の特徴です。アプリケーションの重要度別に定義ということに関してですが、例えば普通のビジネスアプリケーションから電気とかガスとか水道などのインフラを扱うアプリケーションは、同じアプリケーションではないと思っています。それぞれで求められるセキュリティのレベルはまったく違います。

《スライド：ロギングの章》

ASVSではそれを考慮しており、3つのレベルが用意されています。どのように定義されているのかを見ていきます。先ほど少しお見せしたチャプターなんですが、右側にL1、L2、L3というかたちで定義しています。7.1.1はすべてのアプリケーションがやるべき、そして7.1.3ではL2以上のそれなりのアプリケーション以上がやるべきという定義の仕方です。

このレベルについて少し説明いたします。1、2、3段階で分かれておりまして、下がすべてのアプリケーションがやること。そして一番マックスはインフラとか金融情報、ヘルスケアといった重要なアプリケーションがやるべきということで定義されています。ここの図から自分がだいたい何をしなければいけないのかということをわかってもらえたかなと。掴みやすいドキュメントだということです。

そして最後の特徴のコミュニティドリブンについて説明します。これは私がASVSのもっとも好きなスキルでもあります。今回のバージョンは昨年出されたもので、バージョン4からGitHubで作成されています。世界中の誰もが作成とかレビューに参加できるというものです。

実際にどのようなやり取りが行われていたのかをちょっとご紹介します。これはSSRFの保護方法に関してライブラリを使うようにASVSに書くことを求めている人がいて、「そうではないよ」というようなやりとりが行われる。いろんな人の意見がこのドキュメントに集約されているというのが、ここからわかると思います。

ちなみにこの右側のJim Manicoさんという方は非常に有名な方で、きちんとこのSSRFの防ぎ方について事細かに書かれています。また別の話になりますが、本当にこのドキュメントの半分は優しさでできていると私は思います。

以上で3つの特徴を述べました。これらを総括してこのASVSというのはアクション可能な最良なWebアプリケーション、セキュアなWebアプリケーションの定義だということがわかったかと思います。

ASVSをどういうシチュエーションで使うのか

実際にこのASVSをどういうシチュエーションで使うのか、ケースを3つ考えてみました。1つ目は、例えばソリューションの検討ですね。自分のそのWebアプリケーションのセキュリティについて不足しているところがあって、それをほしいとした場合にこのドキュメントを用いればそのほしい機能を簡単に言語化できると思います。

2つ目のケースはセキュリティ対策状況か何かを報告しなければいけないときに「自分はレベル2を達成していますよ」「レベル1を達成していますよ」と一言で状況を伝えることができる。たくさんのレポートはいらないよということですね。

そして3つ目、これは非常に重要だと思うんですけれども、セキュリティの設計について関心ごとが明瞭になるという点です。何を気にしなければいけないのか、このドキュメントに詰まっていますので、そこについてあれこれ悩む必要がないというのがあることだと思います。

続いてASVSを実際に始めてみることについて。あくまでもyamoryでのトライなのですが、その結果を踏まえてこうしていけば始めるのにいいんじゃないかという内容を共有いたします。流れは大きく4つのステップで構成されています。1つずつ簡単に説明します。

1つ目の準備するということに関してですが、まず手元にASVSを用意しましょうということです。「やるやら」を選択できるチェックリストをおすすめします。あとで詳細を説明します。

もう1つが軽く読むということで、一通り目を通してどんなことが書いてあるのか把握することをおすすめします。実際にQiitaとか、このGitHubのURLで親切な方が日本語訳をしてくださっていたので、それを参考に本家を読んでみるといいのではないでしょうか。

「チェックリストをおすすめします」と言ったところなんですけど、なぜかと言いますと、細かいところは割愛しますが、実際に項目によっては簡単な1回の確認程度で済むものもあります。

例えばDBのマスターキーとかどこに保存していますか？　TPM、堅牢なハードウェアに保存しましょうねという要件があったときに、大概そういうものは頻繁に変更するものではないので、1回きちんと確認してチェックすると、それだけで済みます。全部が全部スマートにやらなくてもいいのかなと思っています。

対象はどのチャプターがよいのか

2つ目の対象を決めることに関してお話しします。決めなければいけないことは大きく2つです。1つ目が対象の機能、プロジェクトというところ。2つ目がチャプターで、どれをやるかという話です。対象の機能、プロジェクトを選ぶということに関してyamoryのおすすめですけど、初めてASVSを使う場合ですね。できればASVSに自分の関心を集中させたほうがよいので、できあがっている機能から着手するとより楽じゃないかなと思います。

チャプターを決める。全部をやろうとすると14個もあるので、130いくつもあるのでとても大変です。なので、2つないし3つ、4つぐらいからやっていくといいのではないでしょうか。実際にどのチャプターがよいのかというと、これはあくまでyamoryの簡単な推奨をちょっと共有します。

今赤枠で囲っているアプリケーションのところですね。アクセス制御とか認証とかロギングとかが一番やりやすいです。APIとかアプリケーションのある程度変更だけで済むところのほうがいいんじゃないかと思います。暗号とかのデータ保護とか、そこらへんを変えるとなるとけっこう影響範囲が広範に該当するところでもあるので、大変だと思います。最後ぐらいにやればいいやと思ってくれればいいと思います。

実際にどのように解決していくか

そして3つ目のセキュアにする。ざっくりプランニング・実装・検証といったところで、そこまで普通の開発のサイクルだと思います。詳細は割愛しますが、プランニング、どう実装するかですね、セキュリティ抜きのそこについてちょっとTipsみたいなものを紹介します。実際にASVSの全部が全部事細かくわかりやすく書いてあるかというと必ずしもそうでもないんですね。

これはまたログの要件の意訳です。「各ログイベントには、イベント発生時におけるタイムラインの詳細調査で必要な情報を含んでいることを確認する」という内容です。実際にこれを読むと「各ログイベント」って何？　というのと、「必要な情報」ってなんなんだろう？　というのが、きちんと考え出すと思い浮かぶ疑問なのかなと思います。

こういうのも多々あるのでどう解決していくかということなんですけど、ステップは3つあります。まず1番目に見なければいけないのはリファレンスです。リファレンスと言っているのは何かというと、このC9でリンクが付いているところですね。ここに書かれているドキュメントです。たいていの場合はProactive Controlsというドキュメントだったりします。

そして2つ目はOWASP Cheat Sheet。また別のOWASPプロジェクトですね。すごいいろいろと細かく書いてあるやつです。そしてGitHub。この要求事項がなぜ生まれたんだろうというようなところ、背景とか意図というところを理解してここら辺の情報を把握するというような方法です。そこまでやらなくても2番で大概は解決できます。一番おすすめです。

実際にどのように解決していくかを見ていきたいと思います。Cheat Sheetは、基本的にはこちらのASVSの内容とCheat Sheet内のリンクが対応付いています。今回の場合は7.1シリーズなのでここのLogging Cheat Sheetというのを選択します。そこに何が書いてあるか、どのイベントかという話に関して言うと、実際ここにどんなタイプのイベントでログを出力しろと言っているのかもわかります。

そして「何の情報を含めなければいけないんでしょうか？」というお話に関しては、これもCheat Sheet内の情報で細かく書かれています。このOWASPのASVSだけではわからなくても、周りのプロジェクトを活用していくことによってアクション可能で、とくに行き当たる問題もないのかなと思います。情報がきちんとたくさんあるということですね。

Top10から始めましょう

そして最後の「広げていく」ということについてお話しします。広げ方は2つあると思っていまして、対象のチャプターを広げる。そしてプロジェクトを広げるという点です。プロジェクトを広げるということに関してちょっと注意点を伝えたいと思います。

言い換えるとこれは巻き込む人を増やしていくことだと思っております。巻き込む人を増やすと言ったときに、いきなり「136個の要件があるからやってみようよ」。そういったところで、言われた相手は誰でも非常にヘビーだと感じると思います。抵抗もあるかもしれません。そうならないためにどうしようかというお話で、これは以前私のブログで紹介したんですけど、Top10から始めましょうという話です。

10個のやらなければいけないことについてまずは潰して、そのあと少しでもセキュリティの抵抗感のないところにProactive Controlsを持っていってASVSへ移行という流れがスムーズなんじゃないかなと思います。一応こちらポイントというところで注意点みたいなところなんですけど、とにかくスモールスタートが大事だと思っています。

すべてをいきなりやろうとしたら本当に本末転倒になってしまうので、ここだけは注意していただければと思います。あとは完璧を目指さない。例えばNVDだからこの要件は実装しない、そういった選択もありなのではないかなと思います。

あとASVSは基本的にそのテストで確認というかエビデンスみたいなものを求めているんですけど、パスポートの要件に例えば絵文字を使わなければいけません、使えるようにしなければいけませんとなったときに、それを検証しなくてもいいかという反応をしてもいいのかなと思います。時間は限られているといったところです。

3つ目なんですけど、時間を決めましょうということです。セキュリティ投資というものは直接お金を生むようなものではなく将来の損失を防ぐためのものなので、そこの理解が得られないというのもあると思っています。ですから、事前にプロダクトオーナーとかマネージャとかに、「週何時間、何ポイントというかたちでセキュリティ向上にあてさせてください」という進め方はいいのではないでしょうか。

ASVSの実践例は非常に情報が少ない

まとめです。今回はセキュリティのモヤモヤを解決するということを目的としました。まず大事なのは、第1ステップとして「セキュアなWebアプリケーションとは何か」について、ASVSを通じて共通認識を形成しましょう。ASVSとは何かと言うと、セキュアなWebアプリケーションの定義で、アクショナブルというところが重要です。

そしてポイントはスモールスタートで始めていくことです。ちょっとざっくりですが、本編はここで以上となります。

残りはAPPENDIXで少し簡単にお話しします。DevSecOpsやDevOpsSecなどいろいろ言い方はあってバズワード感が少しありますが、DevSecOps勉強会なので、これに対する私の見解をお話したいと思います。先ほどちょっとお見せした図ですが、セキュアなWebアプリケーションがこの右端のこのカラフルな図だと思っていただければと思います。

DevSecOpsというのはセキュアであることを自動的に担保していくことだと私は考えています。実際にASVSをもしやろうとするならば開発でセキュリティを組み込まなければならないという要素はかなり多くて、DevSecOpsを始めたいという方はASVSを取り組んでみるのはいかがでしょうか。

そして最後なので2つだけお願いいたします。ASVSの実践例とかは非常に情報が少ない印象です。とくに開発現場における実践例ですね。今後はできる限り情報発信していきたいと思いますので、yamory Blogをぜひ読んでください。そしてみなさまもできれば情報発信してもらって相互扶助できる関係が築けたらなと思っています。

そしてもう1点、セミナー後にこちらのASVS 14.2.1と14.2.5は必ず読んでください。合わせてOWASPのTop10のA9も読んでください。こちらはすごく大事な項目になります。これはyamoryが対策できるので、ぜひともyamoryをお試しください。

以上です。ありがとうございました。