セキュリティとコンプライアンスのためのイベントログ管理
会社の知的財産を含むサーバー上のディレクトリへのアクセス制御リスト (ACL) に未承認の変更は加えられていませんか？規制コンプライアンスの対象となるデータに不正にアクセスされていませんか？内部システムへのハッキングの試みはありませんか？コンプライアンス遵守を証明する監査レポートを依頼されたら対応できますか？
世界中のコンピュータネットワークで、毎日、発生したイベントの記録が生成されています。ルーチンとして何が起きたかが書き出されているものもあれば、ネットワーク状態の悪化やセキュリティ侵害の試みを示すものもあります。ログファイルには、組織が、侵入者、マルウェア、損害、損失、法的責任などからのリスクを削減するための豊富な情報が含まれています。Sarbanes Oxley、Basel II、HIPAA、GLB、FISMA、PCI DSS、NISPOM などの規制コンプライアンス基準を満たすためには、ログデータを収集、保存、分析、監視する必要があります。ログファイルは、様々なソースから、多様な形式で、大量に提供されるので、収集、分析、監視するのは困難な作業になります。
ここでは、一般的なイベントおよびログ管理 (Event and Log Management、ELM) の要件と、セキュリティ侵害のリスクを軽減し、規制コンプライアンスを満たすためのベストプラクティスについて説明します。
統合されたイベントおよびログ管理
ネットワーク内のすべてのシステムが、何らかの種類のログファイルを生成します。すべてのハードウェアで発生するイベントまたはトランザクションごとにログが記録されます。Microsoft ベースのシステムは Windows イベントログを生成し、UNIX ベースのサーバーやネットワークデバイスはシステムログ (Syslog) スタンダードを使用します。Apache や IIS などの Web アプリケーションサーバー、ロード バランサー、ファイアウォール、プロキシサーバー、コンテンツセキュリティアプライアンスなどは、W3C/IIS ログファイルを生成します。
イベントおよびログ管理を統合して、ファイルアクセス、ユーザーによる不正なアクティビティ、ポリシーの変更、および従業員、患者、財務記録などの重要な個人データを含むファイルまたはフォルダに対して実行されるその他の重要なアクティビティを、一元的に監視、監査、およびレポートできるようにすることは極めて重要です。セキュリティ侵害は、どこからでも発生し得るので、Windows イベントログ、Syslog、W3C ログのすべてを管理できるべきです。
Windows システムには、一貫して監視する必要がある複数の異なるイベントログがあります。イベントログの中で最も重要なのは、誰がネットワークにログオンしていて何を行っているのかの情報を提供するセキュリティログです。この情報から、セキュリティの実装に脆弱性が存在することがわかる場合もあります。
Syslog は、インターネット技術特別調査委員会 (Internet Engineering Task Force、IETF) によって標準として定義されたログメッセージ形式およびログ送信プロトコルです。2001年に RFC-3164 として公開され、その後、2009年に機能強化された RFC-5424 に移行しました。ネットワークデバイス、UNIX および Linux システム、そして多くのソフトウェアとハードウェアプラットフォームが、標準のログ形式として Syslog を実装し、ログファイルを一元化されたログ管理リポジトリに送信および収集する手段を提供します。Syslog 情報を使用すると、デバイスの状態に関する詳細な情報を取得できます。情報をソートおよび分析して、運用パターンやパフォーマンスパターンの変化による通常でない動作を確認できます。その変化は、単一または複数の問題を示している可能性があります。Syslog データを保存しておくことで、ネットワークの信頼性とデータの保護に影響を与える可能性のあるイベントを追跡するための監査ログを提供することができ、コンプライアンスの取り組みをサポートします。
同様に、W3C ログもユーザーとサーバーのアクティビティに関する情報を提供します。これらの監査ログは、Web サーバーなどへの、不正な侵害の試みを特定するために使用できる貴重な情報になり得るので、監視する必要があります。IIS ログ ファイルは固定 (カスタマイズできない) ASCII 形式であり、ユーザーの IP アドレス、ユーザー名、リクエストの日時、サービスステータスコード、受信したバイト数などの基本的な項目を含みながら、他のログファイル形式よりも多くの情報を記録します。IIS ログファイルには、経過時間、送信バイト数、アクション、ターゲットファイルなどの詳細な項目が含まれます。
統合されたログ管理ソリューションを導入することで、システムによって生成される膨大な量のログ情報の管理を合理化できます。ログデータにリアルタイムでアクセスし、セキュリティ侵害の原因となる可能性のあるイベントを「干し草の山の中から」フィルタリングして特定できます。
ログデータの量
サーバーその他のネットワーク デバイスによって、毎日10 万個のログエントリが生成されると言われています。平均的な企業は1日に最大4GBのログデータを蓄積します。ログファイルのデータの95％以上は、ユーザーのログイン、アプリケーションの開始と停止、ファイルアクセスなど、システムで発生したすべての成功したイベントまたはトランザクションを記録する詳細情報です。
収集され、格納される膨大な量のログデータの大部分がこのような単なる記録だけの情報であることがわかると、がっかりするかもしれません。ほとんどがルーチン的なデータであることから、絶えず生成されるログデータのキャプチャ、保存、分析をないがしろにしがちですが、その中にはセキュリティに関する重要なデータも含まれており、ログデータの重要性を過小評価すべきではありません。
ログデータを手作業で収集してチェックしなければならないと、ログデータを生成するサーバーが多くなるにしたがってチェックしなければならないデータの量が膨大化し、手に負えなくなります。セキュリティ関連の問題を検出したり、あるいはコンプライアンスを満たすためにログデータを収集・分析・保存したりしようとしても、発生するログデータの膨大な量に追いつかない可能性が高くなります。
境界内のセキュリティ
セキュリティは、どのような組織にとっても、IT 戦略の最前線に置かれます。最前線の戦略は、組織外部からの不正なアクセスや悪意ある攻撃を防ぐために、ネットワークの境界部を警戒するものです。
このような外部攻撃から防御するセキュリティは不可欠ですが、組織内部についてはどうでしょうか？会社の機密の財務データを見て、アクセス許可を変更しようと試みるような困った社員はいませんか？あるいは、キーサーバーにバックドアを作成してテラバイトの顧客データを削除しようとする不満分子はいませんか？これらは極端な例かもしれませんが、このような起こり得る内部からの脅威イベントに対抗する準備はできていますか？セキュリティ侵害は、外部からだけではなく、内部から発生する可能性もあります。内部というアドバンテージがあるので、ひょっとしたら内部からの可能性の方が高いかもしれません。許可されていない個人が保護されるべきデータにアクセスしたとわかると、その会社が責任を問われる可能性はかなり高くなります。
セキュリティ監視のために、内部アクティビティや通常の業務活動の、常軌を逸脱した動きに関するログデータを包括的に管理する ELM 戦略を確立すれば、小さなイベントのときに検出して破壊的な惨事を引き起こす前に防止することができます。
コンプライアンスへの取り組み
ほとんどの組織は、何らかの規制コンプライアンスを満たす必要があります。たとえそういった規制を受けない場合でも、コンプライアンス要件を確認することは十分意味があります。コンプライアンスで規定されていることは、セキュリティ確保のための要件であり、これを満たすことがセキュリティ強化策に直結します。
例えば、証券取引委員会 (SEC) に報告する企業は、サーベンス・オクスレー法 (Sarbanes-Oxley、SOX) に違反した場合、役員に重い罰金と法的責任が課される可能性があります。セキュリティとコンプライアンスに関する要件の多くはログ管理に関連しており、サーベンス・オクスレー法のものと重なっています。したがって、上場企業も私企業も、ログ管理戦略を策定するにあたって、サーベンス・オクスレー法を参考にすることは有意義です。
主要なコンプライアンス制約を以下にまとめます。
Sarbanes-Oxley
サーベンス・オクスレー法では、セクション 404 の「内部統制」という部分が規制コンプライアンスの中心です。[…] 内部統制レポートは次の点を満たす必要があります：
- 財務報告のための適切な内部統制構造と手続きを確立し、維持するための管理の責任を記述すること; そして
- 発行者の直近の会計年度の終了時点で、財務報告に対する発行者の内部統制構造と手続きの有効性に関する評価が含まれていること
これらの要件が誰にどのように適用されるかについては誤解されがちなようです。まず、サーベンス・オクスレー法は、7,500万ドルを超える上場企業、または私企業が上場企業に買収された場合にのみ適用されます。誤解されやすいことの２つ目として、サーベンス・オクスレー法で「統制構造」が問題になるのは財務データ自体や財務報告だけには限らないという点があります。そのデータの信頼性に影響を与える可能性のあるほぼすべてのものを含むと非常に広く解釈されています。
ネットワークの構成、ビジネスモデル、市場、そして監査人が何に重きを置くかなどについては差異があるので、後述のベストプラクティスを参照してください。
ほとんどの場合、これを含むより大きなコンプライアンス戦略が必要になるので、特定の業界のコンプライアンスに関連する詳細については、監査のスペシャリストに相談してください。
Basel II
サーベンス・オクスレー法に比べると、Basel II はあまりよく知られていません。Basel II の目標は、国際的に金融システムの安定性を高めることです。Basel II では、「運用リスク」に対する懸念が述べられていますが、いろいろな解釈のしかたがあります。サーベンス・オクスレー法に準拠することを出発点と考えた方がいいかもしれません。取り組もうとする場合は、管理チームと監査チームとの協働で、高度な測定アプローチ（Advanced Measurement Approach、AMA）を行う必要があります。GLBA
グラム・リーチ・ブライリー法（Gramm-Leach-Bliley Act、GLBA）は、金融機関による顧客データの保護に焦点を当てています。GLBA の多くは、サーベンス・オクスレー法の要件と重複しています。規則の別の形の寄せ集めまたは単なるガイドラインと見做されることもありますが、GLBA には厳しい罰則があります。遵守しない場合は、米国司法長官から民事訴訟を起こされる可能性があります。この法律には、連邦取引委員会のウェブサイトからアクセスすることができます: https://www.ftc.gov/privacy/privacyinitiatives/glbact.htmlHIPAA
HIPAA (Health Insurance Portability and Accountability Act、医療保険ポータビリティ及びアカウンタビリティ法) の要件は GLBA に似ていますが、医療患者の個人データを保護するための信頼性の高い監査証跡の存在を強調するのが特徴的です。HIPAA には、プライバシーとセキュリティの2つの主要なルールがあり、それぞれ実装とレポートに関する独自の要件を規定しています。メディケア・メディケイドサービスセンター ( Centers for Medicaid and Medicare) によると、「情報のセキュリティまたは整合性に対する脅威または危険」から保護するための IT インフラストラクチャと戦略を構築することに加えて、潜在的なセキュリティ侵害を調査するための準備を整える必要があります。「どのイベントが発生したか、いつ発生したか、誰が（または何が）それらを引き起こしたかを確認するための十分な情報」を提供できる監査証跡を求められます。FISMA
連邦情報セキュリティ管理法 (Federal Information Security Management Act、FISMA) は、米国政府の重要な情報インフラストラクチャを保護することを目的としています。情報および情報システムの最低限のセキュリティ基準を設定し、情報を保護するための適切なコントロールを評価および選択するためのガイダンスを提供します。各連邦政府機関とその請負業者は、FISMA 基準を満たすポリシーを策定、文書化、実施する必要があります。国立標準技術研究所 (National Institute of Standards and Technology、NIST)は、連邦政府の執行機関を支援する情報システムのセキュリティ制御を選択し、指定するためのガイドラインを提供するために、特別出版物 800-53 を発行しました。NISPOM
国家産業セキュリティプログラム運用マニュアル (National Industrial Security Program Operating Manual、NISPOM) の第8章に含まれる要件は、機密データにアクセスできるスタッフを持つ政府機関や民間請負業者向けのものです。マニュアルには、セキュリティ監査には、セキュリティ関連のアクティビティに関連する情報の認識、記録、保存、および分析が含まれると記載されています。監査レコードを使用して、発生したアクティビティと、それを担当したユーザーまたはプロセスを識別できます。PCI-DSS
クレジットカード業界データセキュリティ基準 (Payment Card Industry Data Security Standard、PCI-DSS) は、国際カードブランド5社（American Express、Discover、JCB、MasterCard、VISA）のクレジットカード情報を処理、保存、伝送、アクセスする組織に課される国際的なコンプライアンス規定です。PCI-DSS を実装する機関は、毎年の PCI-DSS 監査レポートで、標準に準拠していることを証明する必要があります。証明できない場合は、クレジットカード関連の情報を処理または保存する機能がないと見做される可能性があります。任意のエンティティ PCI-DSS は、PCI-DSS が標準に準拠していることを年次 PCI-DSS 監査報告書で証明するか、クレジット カード関連情報を処理または保存する機能を拒否される必要があります。セクション10 は、監査情報とログファイルの要件を定義しています。イベントおよびログ管理のベストプラクティス
ベストプラクティス #1: すべてのログレコードを統合して一元管理する
デフォルトでは、Windows イベントログと Syslog ファイルは統合されておらず、各ネットワークデバイスまたはシステムが独自のログアクティビティを記録します。セキュリティとコンプライアンス確保のためにネットワーク全体で何か起きているのかをすべて把握するには、すべてのログデータを収集、保管、監視、分析、レポート作成し、それらのレコードを中央データベースに統合する必要があります。ログデータの保存期間を7年以上とするようなコンプライアンス基準もあり、ログデータの収集と保存は非常に重要です。自動化は、時間を節約し、ログデータの信頼性を確保するのに大変有用です。
- アーカイブされたログファイルのデータは、高い信頼性が求められます。自動化によって人間が介入する可能性がなくなれば、データの信頼性のレベルは高くなります。
- 企業内のマシン、ユーザー、管理者の数、そして帯域幅や競合するリソースなど、様々な要素が絡み合ってログ収集・分析プロセスは複雑化します。すべてのイベントを確実に収集する唯一の方法は自動化されたソリューションになります。
よくある手法は、ネットワーク全体のサーバーやワークステーションから毎晩 (または定期的に) イベントログレコードを収集する ELM ツールを設定することです。このプロセスには、各システムからのアクティブなイベントログファイルの保存とクリア、ログエントリの中央データベース（Microsoft SQL など）への書き込み、保存されたログファイルの圧縮と安全なサーバーへの保存が含まれます。
ログデータをデータベースレコードと圧縮フラットファイルの2つの形式で保持すると、ストレージと監査に明確な利点があります。フラットファイルのイベントログデータは非常に効率的に圧縮でき、多くの場合、元のサイズの5％まで圧縮されます。したがって、ストレージコストの観点からは、監査のために必要になった場合に備えてアーカイブログデータを何年も保持するのにかかるコストが抑えられます。ただし、フラットファイルは分析やレポート作成には適していないので、アクティブなワーキングデータセットをデータベースに保持（多くの場合60〜90日）すると、最近のイベントに関して定期的なレポートだけでなくそのときに必要なアドホックレポートを作成してチェックできます。古い保存ログファイルが必要になった場合に迅速にデータベースに再インポートできる ELM ツールを探してください。フラットファイルを追跡して、膨大な量の中から特定のタイプのデータを抽出しようとすると、監査のために非常に長い時間を要してしまいます。中央データベースに必要なデータが用意できるようにしておくと、監査が入った時、無駄に長時間をかける必要がなくなります。
ベストプラクティス #2: イベント監視 - リアルタイムアラートと通知ポリシー
ほとんどの組織の IT 環境は、異種のオペレーティングシステム、デバイス、システムが混在する異種混在環境になっています。Windows のデスクトップとサーバーと OS をもっぱら使用しているとしても、Windows イベントログ以外のログ監視は必要になります。Syslog のサポートは、ルーター、スイッチ、IDS、ファイアウォールだけでなく、UNIX や LINUX システムにも重要です。
監視する必要があるイベントの種類に関しては、組織によって適応するルールが異なりますが、セキュリティイベントには常に注意する必要があります。セキュリティイベントログの監視は不可欠ですが、他のイベントログも、アプリケーション、ハードウェアの問題、または悪意あるソフトウェアに関する問題を示す可能性があります。監視対象のイベントはすべて、少なくとも、発生元のポイントに戻ってトレース可能である必要があります。
リアルタイムでチェックしたいイベントのログをどのような頻度で行うかを含め、継続的な監視の方法論を定義する必要があります。定義されたイベントは、それぞれ設定した間隔でポーリングされ、問題になりそうなエントリが検出されたときにアラートまたは通知を生成します。
設定されたイベントの数、ターゲットシステムの数、およびポーリング頻度によって、ポーリングサイクル中に消費される帯域幅の量が決まります。特定のシステムでどのイベントを監視したいのかがすでにわかっている場合は、それに合わせて設定を変更すればいいのですが、初めてイベント監視を設定する場合は、すべてのイベントを有効にして、高いポーリング頻度を設定するのがいいかもしれません。次第に慣れてきて感覚がつかめたら、監視するイベントの数を減らし、ポーリング頻度を低くするよう調整できます。
ベストプラクティス #3: セキュリティとコンプライアンスのために必要なレポートを作成
ログ監視それ自体に加えて、レポート機能も重要です。レポートは、セキュリティ関連の重要なデータを提供し、コンプライアンスを証明するためにも必要です。セキュリティの侵害につながる可能性のある、または侵害を発生させてしまったイベントに基づいてセキュリティポリシーを変更する必要性を実証するのにも役立ちます。
ELM ソリューションを選択する場合は、以下の点をチェックするようにしてください。
- どのようなレポート形式を使用できるか？
- パッケージ化されたイベントログレポートの完成度はどの程度か？
- カスタムレポートは作成できるか？
- カスタマイズされたフィルタは、簡単に繰り返し使用できるか？
- どのデータソースからレポートを生成できるか？EVT、テキスト、Microsoft Access、ODBC は含まれているか？
- イベントのアーカイブソリューションとは互換性があるか？