プロフィール
ミアミン
ホワイトハッカーを夢みて、セキュリティアカデミーでお勉強中のミーアキャット。心配性でやさしい性格で、「みんな無事ミア？」「危険はないミア？」が口癖。ちょっとしたことですぐに「キャッ！」と動揺しがち。
中村
Webアプリケーション診断を担当するコンサルタント。最近の趣味は登山です。
セキュリティリスクを評価し、その影響や重要度を明らかに
中村さんこんにちは！今日のテーマは「Webアプリケーションの脆弱性診断の種類」と聞きました。ちょっと難しくなってきた気がするミア……。
中村さん
「脆弱性診断」の回で、「システム設計を把握したうえで脆弱性診断の対象や手法を決める必要がある」と教わりましたよね。今回は、その対象が「Webアプリケーション」の場合にどんな手法があるか、主要な3種類を紹介します。
- DAST（Dynamic Application Security Testing）
- SAST（Static Application Security Testing）
- IAST（Interactive Application Security Testing）
Webアプリケーションの脆弱性診断をする手法だけで3つもあるミア？
中村さん
そうなんです。それぞれの手法はシステムの現在のリスクを可視化するという共通の目的を持ちつつも、異なるアプローチや対象範囲を持っています。そこで、セキュリティの要件や目標、診断対象によって適切な診断手法を選択しなければなりません。
「Webアプリケーションの脆弱性診断ならこれ」と決まっているわけではなく、さらに細かく選択していく必要があるんですね。大変そうだけど、しっかり選んでおけば安心ミア！
DAST（Dynamic Application Security Testing）
中村さん
DASTはWebアプリケーションの脆弱性診断において、最も一般的な手法です。WebアプリケーションやAPIなど、実行中のアプリケーションの動的機能を対象としていて、開発工程の中でも連結テストから運用・保守といった工程に適しています。
DASTではシステムやプログラムの内部構造を考慮せず、入力値と出力結果に着目する「ブラックボックステスト」を使います。例えるなら、プレゼントの箱を開けずに中身を想像しながら振ってみて、重さを感じたり、音を聞いたりして、中身が壊れていないかを調べるようなイメージですね。
これに対して、「ホワイトボックステスト」は、箱を開けて中を見ながら「ちゃんと動くかな？」とチェックするイメージです。仕組みを知ったうえで、問題がないか調べます。
なるほど～。それで、DASTでの脆弱性診断はどのように行われるミア？
中村さん
DASTでは、このブラックボックステストで実行中のWebアプリケーションに対する外部からの攻撃を模倣してセキュリティ脆弱性を検出します。
具体的には、無害化した攻撃コード（外部攻撃を模倣する命令のこと。先ほどの例えでいう“箱を振ってみる”）を送信し、挙動（先ほどの例えでいう“感じられる重さや聞こえる音”）の変化によりセキュリティ脆弱性を検出します。つまり、Webアプリケーションやデータ（先ほどの例えでいう“箱の中のプレゼント”）には干渉しないので、破壊することなく診断できます。
「挙動の変化によりセキュリティ脆弱性を検出する」というのは、どんなふうに検出するミア？
中村さん
挙動の変化の中で「攻撃の足がかりとなる事象」をベースに、システムの現在のセキュリティリスクを分析し、報告するようになっています。
SAST（Static Application Security Testing）
中村さん
SASTは全アプリケーションのソースコード、バイナリコードやサードパーティーのライブラリを対象としていて、開発工程の中でも実装時からの脆弱性診断に適しています。
SASTでは先ほどのブラックボックステストと対になる「ホワイトボックステスト」を使います。例えるなら「箱を振ってみるだけでなく、箱を開けて中身が壊れていないかを確認する」ようなものです。SASTは、このホワイトボックステストでアプリケーションのソースコードを解析して、実装時に埋め込まれる潜在的な脆弱性を検出します。
なるほど。SASTでの脆弱性診断にはどのような特徴があるミア？
中村さん
他の手法はより下流の工程が適しているのに対し、SASTは実装時から診断できますから、開発が進んでしまってからの大幅なやり直しを避けられ、手戻りが少ないという優位性があります。そのため、外注して脆弱性診断をするケースはほとんどなく、開発会社が使用する場合に最も適しているといえます。
IAST（Interactive Application Security Testing）
中村さん
IASTはWebアプリケーションやAPIなど実行中のアプリケーションを対象としていて、開発工程の中でも機能テスト、運用・保守といった工程に適しています。
IASTではWebアプリケーションサーバーに検査用のエージェントを組み込み、動的な挙動とデータフローを分析し、脆弱性を検出します。
さっきのプレゼントに例えると「中身を作っている工場へ検査員が入ってきて、製造工程をリアルタイムでチェックしている」ようなイメージかな？IASTでの脆弱性診断にはどのような特徴があるミア？
中村さん
開発者や自社運用している組織が「脆弱性診断」ということを意識しなくてよいところでしょうか。テスト時に実行したコード部分のみが検査対象となるため、誤検知も少なく診断結果が開発者へ即時フィードバックされます。比較的早い段階でのテスト工程からセキュリティを担保しやすいので、開発上流工程（シフトレフト）に適した診断手法といえます。
DAST、SAST、IAST、それぞれ特徴が違うんですね。適した工程以外にも使い分けのポイントはあるミア？
中村さん
使い分けというよりも「組み合わせ」がおすすめです。DASTは実際の攻撃を模倣し、SASTはコードの解析によって潜在的な脆弱性を検出し、IASTは実際のデータの扱われ方を考慮して動的なセキュリティ評価を行う……それぞれ違う特徴を持っているということは、お互いに補い合う関係でもあるのです。
キャッ！3種類で補い合ってより強力な脆弱性診断へ、まるで毛利元就の「三本の矢」のようミア！
中村さん
よく知っていますね！これらの手法を組み合わせて開発工程や組織に取り込むことで、Webアプリケーションの脆弱性被害を縮小することにつながり、企業としてのセキュリティ対策や開発システムに対する信頼を高めていくことにもつながります。自社が開発や運用におけるセキュリティ対応策として今どんな手法で取り込んでいるのか、それがセキュリティ対応策として十分か、この記事をきっかけに見直してみてほしいですね。
「もう対策しているから」ではなく、「より脆弱性を減らす」という視点が重要ミア！今日はいろいろ教えてくれてありがとミア！
