導入
情報システム (IS) のセキュリティ監査は、IS のすべてまたは一部を特定の時点で表示し、IS の状態をベンチマークと比較できるようにします。
監査では、システムの全体または一部の長所、特に弱点 (脆弱性) がリストされます。監査人は、発見された脆弱性を削除するための一連の推奨事項も作成します。監査は通常、リスク分析と連携し、フレームワークに関連して実行されます。リポジトリは通常、次のもので構成されます。
- 情報システムセキュリティポリシー（PSSI）
- ISドキュメンタリー基地
- 企業固有の規定
- 法律文書
- ITセキュリティ分野の参考資料
なぜセキュリティ監査を行うのでしょうか?
監査はさまざまな目的で実行できます。
- 攻撃に反応する
- ISのセキュリティレベルをよく理解する
- PSSI の効果的な実装をテストする
- 新しい機器をテストする
- セキュリティの進化を評価する（定期的な監査を含む）
いずれの場合も、その目的はセキュリティを確認することです。セキュリティ サイクルでは、アクションが実行された後に検証が行われます。たとえば、IS に新しいコンポーネントを実装する場合、コンポーネントをテスト環境に統合した後、実際の実装前にそのセキュリティをテストすることをお勧めします。デミングホイールはこの原理を示しています。
その結果が監査報告書となります。これには、分析されたシステム上で監査人によって特定された脆弱性の完全なリストが含まれています。見つかった脆弱性を削除するための推奨事項のリストも含まれています。
監査をリスク分析と混同しないでください。脆弱性を見つけることはできますが、それが許容できるかどうかを判断することはできません。逆に、リスク分析により、どのリスクが IS に対して考慮されるか、または受け入れられるかを言うことができます。したがって、監査人 (サービスプロバイダー) は、被監査者 (クライアント) が従うか従わないかの推奨事項を作成します。推奨事項に従うかどうかは、セキュリティ ポリシーを参照してお客様が判断します。
監査ツール
リポジトリ
- COBIT (情報と技術の管理目標 ISACA): 情報システムのフレームワークを提供します。
- CELAR: 国防省の組織の監査を担当する電子兵器センター。
- 国家情報システム セキュリティ庁 (ANSSI) は、ISSに関するフランスの参照機関であり、特に一般的なセキュリティ フレームワーク (標準と推奨事項) を作成しています。
監査の実践
システムの脆弱性を可能な限り網羅的にリストするために、さまざまな手法が存在し、伝統的に実装されています。
インタビュー
一般に、面接は監査において不可欠です。 ISの組織を分析する場合には欠かせないものですらある。 IS セキュリティーで役割を果たすすべての人々は面接を受ける必要があります。
- 情報システムディレクター (DSI)
- 情報システムセキュリティ管理者 (CISO)
- 管理者
- 情報システムのユーザー (企業の生産、管理、IT リソースの単純な使用など)
- セキュリティに関連するその他の役割
質問を巧みに表現することが重要です。実際、人々に自分の仕事について尋ねることは、批判されていると感じさせ、結果が歪められる可能性があります。したがって、監査を実践するには外交力が不可欠なスキルです。
侵入テスト
侵入テストは技術的な監査手法です。ペネトレーション テストは、ホワイト ボックステスト、グレー ボックステスト、およびいわゆるブラック ボックステストの 3 つの主なカテゴリに分類できます。
ブラック ボックステストとは、テストを実行する人が実際の侵入状況にあることを意味します。テストは外部から実行され、監査人は情報システムに関する最小限の情報を持っています。したがって、このタイプのテストはターゲットの特定から始まります。
グレー ボックステストを実行する場合、監査人は監査対象のシステムに関する情報を持っています。通常、ユーザー アカウントが提供されます。これにより、彼は「通常のユーザー」の立場に立つことができます。
ホワイト ボックステストは、利用可能なすべての情報 (およびその他の情報) から始まります。次に、オープン ポートやアプリケーションのバージョンの検索など、さまざまな技術テストを使用して脆弱性の検索を開始します。これらのテストを実行するさまざまな製品が存在し、一連のテスト全体を自動化することを計画している製品もあります (Nessus) 、LANガード…）。
最後のフェーズは脆弱性の悪用です。望ましくない影響 (サービス拒否など) が発生する可能性があるため、このフェーズの実際的な側面は体系的ではありません。これは、発見された脆弱性を使用してシステムを侵害するために実装される手段を決定することから構成されます。実装する手段に応じて、クライアントは、検出された脆弱性に関連するリスクが無視できる (悪用の可能性が低い) と判断するか、逆に考慮すべきであると判断する場合があります。悪用の実現可能性を証明するために、監査人はエクスプロイトと呼ばれる、脆弱性を悪用するプログラムを作成します。
構成レポート
これには、情報システムのコンポーネントを徹底的に分析することが含まれます。構成は細部に至るまで検査されます。この観察に続いて、読み取り値を安全とみなされる構成および一連の既知の欠陥と比較することによって、脆弱性のリストが特定されます。
ISアーキテクチャからホスト(クライアントとサーバー) を含むアプリケーションに至るまで、あらゆるものを検査できます。たとえば、サーバー上で次のものを分析します。
コードの監査
広範囲にわたるアプリケーション向けに、非常に信頼性の高い脆弱性データベースがあります。ただし、あまり使用されないアプリケーションや、企業自身がコーディングしたアプリケーションの場合は、セキュリティの分析が必要になる場合があります。アプリケーションのソースが利用可能な場合は、ソース コードを読んで理解し、存在する可能性のある問題を検出する必要があります。特に、バッファ オーバーフロー、フォーマットのバグ、 Web アプリケーションの場合は SQL インジェクションにつながる脆弱性などです。
コード監査は非常に面倒で時間のかかる作業です。さらに、複雑さのため、コードの脆弱性の完全なリストを作成することは一般に不可能です。自動手法が存在し、RATS などのツールを使用して作業を大まかに行うことができます。しかし、このような方法だけに頼っていると、人間にとって明らかな問題を見逃してしまう可能性があります。
ファジング
コードが利用できないブラック ボックスアプリケーションの場合、コード分析に相当するものとしてファジングがあります。この手法は、制限値を使用して多かれ少なかれランダムなデータを入力として注入することにより、アプリケーションの動作を分析することで構成されます。構造分析であるコード監査とは異なり、ファジングはアプリケーションの動作分析です。