ファジングでIoT機器のセキュリティ対策を万全に！ ～第2回 SAST vs DAST vs ファジング

進化の速いデジタルの世界では「新しいアプリ、機能、更新をできるだけ早く、かつ頻繁にリリースしなければならない」というプレッシャーが常にかかっています。しかし、セキュリティ上の脆弱性を引き起こすことなく、継続的なコード変更を管理するには一体どうすればよいのでしょうか。また、クラウドアプリの使用量の増加と、それに伴い開かれる新たな攻撃への危険な扉という課題にどう対処すればよいでしょうか。

ここで自動セキュリティテストの出番です。最も一般的なのは、静的アプリケーションセキュリティテスト (SAST) と動的アプリケーションセキュリティテスト(DAST)です。SASTとDASTは、それぞれが異なる問題に対処し、独自の長所と短所がありますが、どちらもソフトウェア開発ライフサイクル (SDLC) の一部として、アプリケーションをテストするための速度、効率、およびカバレッジパスを向上させることを目的としています。

今回は、SASTとDASTを使用する利点と欠点、どちらを使用すべきか（または両方を使用すべきか）について、詳しく見ていきましょう。

SASTとはどんなセキュリティテストか?

静的アプリケーションセキュリティテスト (SAST：Static Application Security Testing) は、ソフトウェア開発の初期段階で使用されるホワイトボックステストの一種で、安全なコーディングを確保し、開発者がコードを実行する前に脆弱性を検出するために使用されます。 SASTソリューションは、アプリケーションを徹底的に分析し、静的入力とソースコードに対してテストを実行して、コードがコンパイルされる前にソフトウェアの欠陥をチェックします。

これにより、ハッカーによる脆弱なコードの悪用が防止され、DevOpsチームがアプリケーションのデプロイ後に問題を修正する必要がなくなります。SASTの使用は、ソースコードの弱点を見つけるための重要な手法として「OWASP」(Open Worldwide Application Security Project)によって認識され、次のような明確な利点があります。

• コーディングの問題のある場所を正確に特定し、開発の初期段階で欠陥を発見します
• 自動化でき、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインに簡単に統合して、コード変更を頻繁かつ確実に配信できます

つまり、コストと時間を最も節約するテスト方法としてまとめることができ、すべてのアプリケーション開発プロセスの一部となる必要があるソリューションです。

DASTとはどんなセキュリティテストか？

動的アプリケーションセキュリティテスト (DAST：Dynamic Application Security Testing) は、SASTの逆のテスト方法です。プロセスの後半で使用される DASTツールは、ソースコードにアクセスせず、ハッカーが侵入しようとするのと同じように、アプリケーションを外部からテストします。 このためDASTは、多くの場合に「動作テスト」「ブラックボックス テスト」、または「ファジング」と呼ばれます。 DASTは、SASTツールを超えて、エンドユーザーによるアプリケーションの使用方法など、実行中のアプリケーションの環境全体を監視します。

OWASPでは、Webアプリケーションの脆弱性テスト（特にアプリケーションが未知の脆弱性を抱えやすいオープンソースコードを使用している場合）において、DASTツールを使用することを推奨しています。DASTは、アプリケーションの脆弱性をスキャンするハッカーのように動作します。しかし、DASTは脆弱性を悪用するのではなく、アプリケーションを運用環境に適用させる前に脆弱性を修正する機会を提供します。

発見された脆弱性は、基礎となるコードのアーキテクチャ、または設計の問題を特定するために使用され、レポート結果からプログラムに変更を加えることで、セキュリティは向上します 。これは、API エンドポイントや Web サービス、物理インフラストラクチャ、ホストシステムの要素など、攻撃対象領域全体にわたる脆弱性を見つけるのに有効です。

SAST と DAST の概要と比較

SASTの長所と短所とは？

SASTソリューションを使用すると、SDLCは開発に対して「セキュリティ第一」のアプローチを採用します。 開発者は、コードベースにロジックと機能を生成すると直ちに通知を受け取ります。 SASTスキャンにより、悪用される可能性のある論理欠陥（例えばサニタイズされていない入力は、SQLインジェクションやクロスサイトクリプティング などの攻撃を受けやすい）が特定されます。SASTツールは、ユーザーが生成した入力に対し、サニタイズしていない関数を特定して開発者に欠陥を警告し、コードベースのメインブランチにコミットされる前に脆弱性を修復できる点がメリットになります。

SASTの欠点としては、限られた一連の脆弱性しか特定できないことが挙げられます。例えば、開発者はユーザー入力をサニタイズしたつもりでも、巧妙に作成された SQLインジェクションの文字列を見落とす可能性があります。 SASTはこの見落としを発見できず、コードが検査に合格してしまう可能性があります。

SASTツールのもう 1 つの欠点は、構成ミス エラーを検出できないことです。多くの場合、展開中に、ソフトウェアが実行できるようにサーバーが構成されます。 SAST は開発者の環境内で自身のコードのみをスキャンするため、攻撃対象領域全体の脆弱性は特定されません。

DASTの長所と短所とは？

セキュリティに対する事後対応型のアプローチであるDASTソリューションは、SAST ツールにはない利点があります。その一つは、複数のサーバー、環境 (クラウドやオンプレミスなど)、APIエンドポイント、その他インフラストラクチャにわたる攻撃対象領域全体をスキャンできることです。たとえば、データを受信および配信するAPIエンドポイントと連携するアプリケーションを作成できます。DASTソリューションは、メインアプリケーションに加えて、エンドポイントの脆弱性をスキャンするように構成できます。

より包括的なスキャンを提供するDASTソリューションですが、いくつかの欠点があります。DASTソリューションは環境に合わせて構成する必要があるため、侵入テストと悪用に関する知識が必要です。環境が十分に監査されていない場合、エントリポイントを見逃して、知らず知らずのうちに脆弱性の存在を許してしまうことを否定できません。

環境を完全にスキャンすることは、開発者にとって大変な作業になる可能性があります。脆弱なコードがどこに存在するか分からなかったり、レポートの内容を理解していなかったりする場合、開発者は問題の原因となっている機能を特定することが困難になるかも知れません。DAST ツールを使用するには、OWASP Top 10とコードの悪用で何が起こるかについて、より多くの知識が要求されます。

DASTツールに関するもう 1 つの懸念事項は、その制限です。DASTは Webベースのアプリケーションで動作するため、ネットワーク経由でスキャンできないソフトウェア (ローカル デスクトップ アプリケーションなど) には追加のセキュリティサポートが必要になります。

SASTとDASTどちらを選択？

SASTは開発者がコードを作成している間に実行され、DAST はテスト環境への展開後にソフトウェアをスキャンします。どちらも本番環境への脆弱性の侵入を防ぎ、データ侵害のリスクと可能性を軽減します。どちらかを選択することもできますが、ソフトウェアをテストする最も有益な方法は、SASTとDASTの両方を使用することです。SASTとDASTを併用すると、アプリケーションのセキュリティを360度にわたり見渡せるようになります。

どちらも本番環境に脆弱性が持ち込まれる可能性を減らしますが、それぞれに独自の検出方法があります。 最良の設定は両方のソリューションを使用することですが、一方が他方よりも有益である2つのシナリオを考えてみましょう。

シナリオ 1：

1つのモノリシック環境でコードを作成する開発者のチームがあるとします。開発者は、更新が完了するとメインのコードベースに変更をコミットします。ソフトウェアは毎月コンパイルされ、予定された日に実稼働環境にプロモートされます。この場合、脆弱性はずっと後になって発見されることになり、開発者は発見後に脆弱なコードに戻ってパッチを適用する必要があります。SASTツールはコミット前にコードをスキャンするため、このシナリオでは有益です。開発者はコーディング中に問題を認識するため、脆弱性がメインのコードベースに導入される前に修正できるからです。

シナリオ 2：

自動化がSDLCの一部である効率的なDevOps環境があります。使用環境では、ローカル プラットフォームとクラウド プラットフォーム (AzureやAmazon Web Servicesなど) にまたがる展開でコンテナ化を活用します。開発者が変更をコーディングすると、DevOpsツールが自動的にコードをコンパイルし、数分以内にデプロイされるコンテナを生成します。この継続的インテグレーションおよびデリバリー (CI/CD) 手法によって展開は高速化されますが、攻撃対象領域が拡大します。DASTツールは、攻撃対象領域全体のスキャンを行い、運用環境やテスト環境で構成の問題や脆弱なコードを検出するため、このシナリオでは有益です。

ソフトウェアセキュリティテストの共生的アプローチ

最新のSASTおよびDASTツールは、運用者と開発者がソフトウェアの主要なセキュリティ問題を理解するのに役立ちます。たとえば、自動化できるSASTは、開発者がソースコード内の欠陥を迅速に特定して修正できるレポート作成用として使用できます。SASTツールでリアルタイムにレポートを生成し、コーディングプロセス中であってもその場でフィードバックを提供することで、SDLC中に一連の欠陥が促進されるのを防ぎます。SASTを使用すると、DevOpsとDevSecOpsを組み合わせて、アプリケーションの脆弱性の包括的なビューを提供し、開発者に安全なコーディングのガイダンスを提供できます。

最新のDASTツールでは脆弱性テストも自動化しており、ブラックボックスファジングが組み込まれている場合があります。この手法は、プロトコル、APIインターフェイス、その他の環境変数における悪用可能な脆弱性をテストします。DASTツールをモバイルデバイス管理 (MDM) と併用して、リモートユーザーや個人アクセス (BYOD) ポリシーを使用しているユーザーなど、拡張されたネットワーク全体のモバイルアプリの脆弱性を見つけることもできます。

SASTとDASTを併用すると、実用的で効果的なテストとレポートに基づいて構築された共生的なDevSecOps/DevOpsプロセスが提供されます。これら2つのテスト方法を統合することで、より安全なSDLCが生成され、昇格されたアプリケーションにシステム侵害を引き起こす可能性のある脆弱性が含まれる可能性が全体的に減少します。

SAST vs DAST vs ファジング～どれがよいのか？

DASTツールに組み込まれることもあるブラックボックスファジングですが、近年、出荷前の脆弱性検証としてIoT機器への利用要求が増えています。
「ファジング」（ファズテスト）では、他のテストツールが見逃してしまうアプリケーションエラーを検出することが可能です。ファジングとは、「ファズ」と呼ばれる予期しないデータを意図的に入力することにより、プログラムクラッシュやメモリリークを発生させて、一般的な機能テストやセキュリティテストでは発見が難しいバグや脆弱性などを検出する、セキュリティテスト方法です。ファジングが、IoT機器のセキュリティ検証を最も効果的に行う手法の一つと言われている理由として、下記の理由が挙げられます。

• 大量データ送信で運用時の製品耐性を確認
• サービス停止などに繋がる外部からの脅威に未然に対処
• 完成品への動的検証により、セキュリティ品質の向上と修正対応のコストを削減
• ツール利用により技術者不足による体制構築への影響を軽減

SAST、DAST、ファジングテストは、いずれもアプリケーションの設計や実装に潜むセキュリティの脆弱性を見つけるのに役立ちます。セキュリティテストは、コストもそれなりにかかります。しかし、運用後に脆弱性が見つかった場合の対応に必要とされる莫大なコストを避けるためにも、これらのテスト手法を適切に組み合わせ、ハッカーに攻撃される前にソフトウェアの脆弱性を見つけ出すことで、投資対効果の向上が期待されます。

次回は、ファジングについてさらに深掘りしていく予定です。お楽しみに！

参考：ファジングでIoT機器のセキュリティ対策を万全に！ ～第1回 サプライチェーン攻撃と脆弱性テスト

ファジングでIoT機器のセキュリティ対策を万全に！ ～第1回 サプライチェーン攻撃と脆弱性テスト

---

「ファジングでIoT機器のセキュリティ対策を万全に！」の最新話は、メールマガジンにてもご案内致しています。是非JAPANSecuritySummit Updateのメールマガジンにご登録ください。
メールマガジンの登録はこちらからお願いします。