サイバーセキュリティ監査の種類を解説
セキュリティ監査の3つの種類と、それぞれの活用場面
著者
0 分で読めます
セキュリティ監査とは？
セキュリティ監査とは、ソースコードを分析したり、プログラムの実行時の動作を調べたりして、セキュリティ上の脆弱性やコンプライアンス違反、その他の潜在的な問題を見つけるプロセスです。セキュリティ監査では、開発者やセキュリティチームが静的解析ツールやソースコード解析ツールなどを活用し、攻撃者が企業のIT資産や機密データを侵害する前に問題を特定します。
この記事では、コードセキュリティ監査の3つの種類、内部監査と外部監査の違い、ソフトウェア開発ライフサイクル（SDLC）全体でセキュリティを監査する方法について解説します。
サイバーセキュリティ監査にはどのような種類がある？
サイバーセキュリティ監査には、次の3つの種類があります。
それぞれのセキュリティ監査について、詳しく見ていきましょう。
1. 脅威モデリング
現代のソフトウェア開発では、「魔法の3要素」とも言える成果、つまりリリースの迅速化、サイクルの短縮、コード品質の向上が求められます。高品質なコードにはセキュリティが欠かせません。そのため、開発者の迅速なリリースを妨げずに、開発サイクルにサイバーセキュリティを組み込む必要があります。
DevOpsのワークフローを妨げずにアプリケーションセキュリティを導入する鍵は、最初の段階から脅威モデリングを使ってセキュリティリスクを評価することです。このプロセスでは、ビジネス要件とロジックを検証し、セキュリティリスクにつながる可能性のある領域を特定します。
脅威モデリングでは、特に次の4つの領域を検証します。
システムの運用とデータフローの設計
リスクと悪用可能な領域
それぞれの攻撃への防御方法
脅威モデリングと防御策の有効性
脅威モデリングは継続的なプロセスであり、完全に終わることはありません。しかし、開発プロセスにセキュリティを組み込み、サイバーセキュリティの衛生管理に関するベストプラクティスに従うための第一歩です。
2. 脆弱性評価／侵入テスト
脆弱性評価では、脆弱性が実行環境に到達する前に発見できれば、修正が容易になるという考え方に基づいています。コードセキュリティ監査で静的解析やソースコード解析ツールを使うと、組織はインジェクション攻撃やサードパーティ製コンポーネントの脆弱性など、一般的かつリスクの高い脆弱性を発見して修正できます。また、リリース前にコードがコンプライアンス要件やライセンス要件を満たしているか確認できます。
侵入テストは倫理的ハッキングの一種で、内部または外部のテスターが環境へのサイバー攻撃をシミュレーションし、脆弱性の発見を試みます。
侵入テストは、テスターがコードをどの程度把握しているかに応じて、ホワイトボックス、ブラックボックス、グレーボックスの3種類に分けられます。
ホワイトボックステスト
ホワイトボックステストとは、テスターまたはツールがソフトウェアの内部構造を把握し、どのように動作するべきかを理解したうえで行う侵入テストです。この知識を活用し、コードを最小の機能単位に分解して各コンポーネントをテストできます（「単体テスト」）。また、コードの特定箇所を調べ、ビジネスロジックの抜け穴などのエラーがないか確認することもできます。ホワイトボックステストは自動化でき、Snyk Codeなどのツールを使ってCIパイプラインで実行できます。
ブラックボックステスト
ブラックボックステストとは、テスターまたはツールがソフトウェアの内部構造を把握せずに行う侵入テストです。攻撃者がシステムの欠陥を悪用して侵入しようとする方法をシミュレーションします。ブラックボックステストの手法には、次のようなものがあります。
ファジング：APIサービスやWebインターフェースに、ランダムまたはカスタマイズした入力を与えてテストする
構文テスト：不正な構文や機密データの露出など、無効な入力や出力がないか確認する
探索的テスト：分析担当者が隠れたセキュリティ問題を発見して報告し、修正方法を提案する
データ分析：システムログや応答を分析し、不審な挙動や潜在的なセキュリティ問題を発見する
広く使われているブラックボックステストの手法の1つに、動的アプリケーションセキュリティテスト（DAST）があります。DASTは手動でも自動でも実施できます。ソースコード自体を解析する静的アプリケーションセキュリティテスト（SAST）ツールとは異なり、DASTはソフトウェアの内部構造を把握する必要がないため、外部から実施できます。DASTは悪用可能な脆弱性のみを検出するため、SASTツールより誤検知が少ない一方、コードベース全体が評価されたことを確認するのは困難です。また、DASTテストの実施には、アプリケーションをデプロイするコストがかかります。
グレーボックステスト
ホワイトボックステストとブラックボックステストにはそれぞれ長所と短所があるため、テスターは両方の手法の利点を活かせるグレーボックステストをよく利用します。たとえば、グレーボックステストでは、攻撃者から見たアプリケーションの姿をシミュレーションしながら、アプリケーションに関する知識を使って脆弱性を発見します。アプリケーションの開発言語がわかれば、その知識を活かして、その言語でよく見られる脆弱性を特定できます。
3. セキュリティコンプライアンス監査
HIPAA、PCIなどの規格によって保護される機密データを扱うアプリケーションでは、コンプライアンスを確保するために特別な配慮が必要となる場合があります。特に、新たな脆弱性やこれまで検出されていなかった脆弱性がないか、定期的にテストする必要があります。Snykは、コンプライアンス・アズ・コードなどの手法を活用してコンプライアンスを確保し、監査人向けの証跡も提供するPCIコンプライアンスサービスを提供しています。
内部サイバーセキュリティ監査と外部サイバーセキュリティ監査の比較
サイバーセキュリティ監査には、内部監査と外部監査があります。開発者やセキュリティチームが実施する内部監査では、ソースコードが内部チームにのみ公開されるため、ホワイトボックステストが適しています。その後、外部監査人が攻撃者の視点からブラックボックステストを実施できます。
内部監査人、外部監査人の双方が利用できる新しいツールが数多く登場しています。内部監査人は、Snyk Codeのような高度なSASTツールを活用して、コード内の脆弱性を自動的に発見できます。外部監査人は、最新の侵入テストツールに加え、ログやリクエストを監視して脆弱性の兆候となり得る異常なパターンを発見するセキュリティ分析など、AIを活用した高度なツールを利用できます。
SASTでアプリのセキュリティを強化
開発者のために再構築された、効率的で実践的な静的アプリケーションセキュリティテスト。
SDLC全体を通じたセキュリティ監査
従来、セキュリティ対策はSDLCの終盤に実施されていましたが、DevSecOpsのアプローチでは最初の段階からセキュリティを組み込みます。SDLC全体を通じて継続的にセキュリティを監査することで、脆弱性を発見し、本番環境に影響が及ぶ前に修正できます。現代のソフトウェアアプリケーションの各要素に対して、監査がどのように行われるか見ていきましょう。
オープンソース監査
現代のアプリケーションのコードの大部分は、メインアプリケーションで利用されるオープンソースライブラリで構成されていることがあります。開発者が把握していない脆弱性が含まれている可能性があるため、これらのライブラリも監査する必要があります。Snykは、脆弱性の発見とオープンソースソフトウェアの管理を支援するオープンソース監査を提供しています。さらに、Snyk Open Sourceは、オープンソースの利用が関連するライセンス要件に準拠していることを確認するのに役立ちます。
コードセキュリティレビュー
コードレビューは、セキュリティ上の問題を含むコード品質低下の主な原因を発見するのに役立つため、SDLCの重要なプロセスです。通常、開発者自身が実施し、コード品質全般を対象とする点で監査とは少し異なります。一方、監査はセキュリティリスクに特化し、セキュリティチームや外部監査人が実施する場合があります。
コンテナイメージ監査
現代の開発者は通常、アプリケーションとともにコンテナ構成を指定するため、コンテナ管理プロセスも監査する必要があります。Snyk Containerは、安全なベースイメージの選定、ベースイメージの自動アップグレード、新たな脆弱性の継続的な監視など、コンテナのセキュリティ対策を支援します。これにより、開発者は高度なオペレーティングシステムの専門知識がなくても、安心してコンテナを利用できます。
IaCテンプレート監査
DevOpsのアプローチでは、コンテナのデプロイ先となるインフラストラクチャの構成を開発者が担うケースが増えています。セキュリティの観点からは、「最小権限」の原則に基づく運用、ネットワークトラフィックのセグメント化、転送中および保存中のデータの暗号化など、IaCのベストプラクティスを取り入れる必要があります。
CTFを始めよう
オンデマンドのバーチャル入門ワークショップで、CTFチャレンジの解き方を学びましょう。
よくある質問
セキュリティ監査が重要なのはなぜですか？
セキュリティ監査は、アプリケーションの問題や脆弱性の解消に役立つため、開発プロセスにおいて重要な役割を果たします。また、決済処理、金融、医療など、厳しい規制が適用される業界では、データに関する基準や規制への準拠を強化するうえでも監査が役立ちます。セキュリティ監査は、単なるチェックリストにとどまるべきではありません。
セキュリティ監査には何を含めるべきですか？
セキュリティ監査は、ソフトウェア開発の初期段階から始まり、脅威モデリングやリスク評価を行います。コードやオープンソースライブラリに脆弱性がないかを評価する必要があります。その後、ペネトレーションテストを実施して、コード内でまだ検出されていないエラーを見つけます。悪意のある攻撃者に悪用される前に問題を発見し、修正するのに役立ちます。
セキュリティ監査はどのくらいの頻度で実施する必要がありますか？
監査は終わりのないプロセスです。SDLCの初期段階で脅威モデリングやリスク評価から始め、その後も脆弱性評価や侵入テストを継続的に行う必要があります。セキュリティ監査は追加の作業としてではなく、プロセスの一部として組み込むべきです。