この記事は、当社の NERC CIP-015ウェビナーシリーズのハイライトを振り返るブログシリーズの一部です。このシリーズでは、業界の専門家たちが、公益事業者が内部ネットワークセキュリティ監視（INSM）プログラムを構築する過程で得た知見や現場での教訓を共有しています。
第9回では、INSMの導入を、説得力のあるNERC CIP-015プログラムへと発展させるためのポリシー、プロセス、および関連文書の作成に焦点を当てました。私は資産所有者のバックグラウンドを持ち、これまでに何度かNERC CIPプログラムの策定、構築、開発に携わってきました。また、NERC CIPに関しては少々マニア的な面もあるため、このテーマは私にとって非常に楽しいものです。
ウェビナーに参加したり、ブログ記事を読んだりしてきた方にとっては、この情報はほぼ復習のようなものだと思います。今こそ、学んだことをすべてどのように実践に移すかを整理しておくべき時です。
NERC CIP-015 においては、文書化こそが要件である
NERC CIP-015、そして実際にはあらゆるNERC CIPプログラムにおいて、文書化こそがすべてです。
CIP-015-1およびCIP-015-2規格は、皆様にとっての法的指針となります。このウェビナーシリーズやその他のリソースがプログラムの構築に役立つとはいえ、監査の際に真に頼るべきものは、要件の文言とプログラムの文書のみです。
CIP-015では、組織に対し、1つ以上の文書化されたプロセスを実装することを繰り返し求めています。また、この要件では、文書化されたプロセスそのものと、それらが実装されたことを示す証拠の両方が求められています。文書化は、技術を導入した後に後付けで行うものではなく、要件の中核をなす部分です。その関係は、それほど単純なものです。
CIP-015をめぐる業界での議論は、センサー、タップ、プラットフォーム、データフィードといったツールに大きく焦点が当てられています。その理由は理解できます。この技術は、いわば「テントの長いポール」のような存在に感じられるからです。しかし、多くの組織ではセンサーを最優先し、文書化を後回しにしており、それがリスクを生み出しています。技術の導入自体は完璧に行えたとしても、プログラムを適切に構築しなければ、成功には至らないでしょう。
方針、プロセス、エビデンス：INSMプログラムを構成する3つの層
私は、CIP-15プログラムについて、「政策」「プロセス」「エビデンス」という3つの層から考えています。
方針：どのような約束をしましたか？
この方針は、貴組織の取り組みを明確にするものであるため、原則としてCIP担当の上級管理職または適切な経営陣による承認を受ける必要があります。この方針では、プログラムの趣旨、範囲、要件のマッピング、役割と責任、および重要な定義が定められています。
CIP-015は、さまざまな環境に対応できるよう意図的に策定されました。その柔軟性ゆえに、各責任主体が埋めるべき空白が残されています。貴社のポリシーでそれらの空白を埋める必要があり、そうしなければ監査人が解釈して埋めることになります。これには、リスクに基づく根拠、「異常」の定義、および評価結果などが含まれますが、これらについては以下で詳しく説明します。
この方針は比較的安定しているべきです。私は従来、毎年見直しを行い、再承認を得ることを好んでいますが、ワークフローや技術が変更されるたびに方針を変更する必要はないはずです。
プロセス：その方法は？
プロセスと手順は、ポリシーがどのように実行されるかを規定するものです。ここでは、ネットワークデータフィードの選択、リスクベースの根拠の適用、異常な活動の検出、異常の評価、および今後の対応の決定といった活動を文書化します。
これらの文書はより戦術的な性質を持つため、ポリシーよりも頻繁に変更されることになります。これらには、発動条件、責任の所在、業務フロー、および各ステップで作成される記録を明記する必要があります。
実用的な起草のルールとして、各プロセスのステップを完了する際には、「このステップにより、記録Xが生成され、時計Yに従って保存される」という考えで締めくくることが挙げられます。あるステップによって生成される記録を特定できない場合は、そのステップは不要であるか、あるいは証拠の欠落が見つかったことを意味します。
この文書の年次見直しと承認を行うことを推奨します。また、監査人がプロセスの変遷を追跡できるよう、バージョン管理を行う必要があります。
証拠：本当にやったのか？
そのプロセスを順守したことを示す証拠があります。これには、チケット、ログ、承認記録、会議議事録、タイムスタンプ付きのスクリーンショット、エクスポートデータ、更新されたネットワーク図やデータフロー図などが含まれる場合があります。
美しく記述されたプロセスであっても、その裏付けとなる運用記録がなければ、文書化されたプロセスがない場合と同様に、確実に失敗に終わります。理想としては、証拠は監査の前に事後的にまとめられるのではなく、日々の業務から自然に生み出されるべきものです。
CIP-15の各要件を順に確認し、ドキュメントがそれらを完全に網羅しているか確認しましょう。
R1 第1.1部：リスクに基づく根拠の文書化
INSMプログラムを作成する際は、規格で規定されている事項と、責任主体に委ねられている決定事項とを区別しておくと役立ちます。
R1のパート1.1において、必須要件には、接続、デバイス、およびネットワーク通信を監視するためのネットワークデータフィードの導入が含まれます。また、それらのフィードがどのように選定されたかを説明する、文書化されたリスクベースの根拠も必要です。
責任主体に委ねられている裁量権には、以下のものが含まれます：
- 監視対象のネットワークセグメント
- 導入が段階的に行われるかどうか
- どの回収方法を利用するか
- 可視性が仮想環境にまで及ぶかどうか
- 分析がネットワークレベルにとどまるのか、それともプロトコルやOT の変数といったより深いレベルまで及ぶのか
リスクベースの根拠の構成については、明確に定義されていません。しかし、だからといって、その根拠が任意のものとなるわけでも、最低限の補償範囲を正当化するための予算上の根拠として扱われるわけでもありません。貴組織の方針では、リスクベースの根拠をどのように策定するかを明確に定義しておく必要があります。
ネットワークセグメントごとに、その根拠として、影響度、攻撃経路との関連性、通信密度、可観測性のギャップ、および実現可能性上の制約などが考慮されるべきである。そして、その上で、「今すぐ監視を導入するか」、「後の段階で導入するか」、あるいは「導入しないか」という明確な判断を下すべきである。最も重要なのは、その判断の理由が、文書化された基準および本規格の目的に結びついていることである。
なお、リスクではなく予算に基づく根拠では通用しないことに留意してください。その根拠は監査可能な証拠であり、基準に明記された目的、すなわち「検知確率の向上」という観点から精査されます。「計測機器を設置しない」という結論は、その精査に耐えうるものでなければなりません。
R1 第1.2部：「異常」という言葉を文章で定義する
R1 第1.2部では、第1.1部に基づいて実装されたネットワークデータフィードを用いて、異常なネットワーク活動を検出するための1つ以上の手法が求められている。
その関連性は、文書の中で明確に示されるべきです。第1.1項に基づいて収集されたフィードは、文書化された検出方法と結びついている必要があります。検出方法で使用されていない孤立したフィード、あるいは文書化されたフィード計画外のデータに依存する検出方法は、その連鎖を断ち切ることになります。
本規格では、異常な活動をどのように検知するかについては規定していません。ベースライン分析、シグネチャ、プロトコルに応じた分析、統計的手法、あるいはそれらの組み合わせなどを利用することができます。対策では、証拠の一形態としてネットワーク通信のベースラインが言及されていますが、ベースライン分析は想定されているものであり、明示的に義務付けられているわけではありません。
プログラムのドキュメントにおいて最も重要なのは、「異常」という用語の定義です。この用語はあらかじめ定義されていないため、自分で定義する必要があります。
その定義には「負荷」という要素が2回含まれています。これは、R1のパート1.2においてメソッドが検出しなければならない範囲を定めると同時に、R2のトリガーともなります。というのも、R2は、責任主体によって異常であると判断されたネットワーク活動に適用されるからです。この定義により、検出の範囲と保持のトリガーの両方が確立されます。
R1 第1.3部：評価は成果を生み出さなければならない
検出と評価は同じ手順ではありません。
R1 第1.3項では、明確な評価プロセスと、その後の対応の決定が求められています。未審査の検知結果が数千件も溜まっているアラートキューは、単なる調整の問題にとどまりません。監査の観点からは、評価要件が実施されていないことを示唆している可能性があります。
手順書には、評価結果およびそれに関連する記録を定義する必要があります。例えば：
- 無害な、あるいは予想される活動は、ベースラインやルールの調整に反映される可能性があります。
- 許可されていないが、悪意のない活動であっても、追跡対象となる是正措置が発生する場合があります。
- 悪意のある活動と疑われる行為が確認された場合、直ちにデータを保存し、CIP-008 サイバーセキュリティインシデント対応計画に基づくエスカレーションが行われることがあります。
- 「未定」のタスクは、担当者と期限が設定された通過点として留めるべきであり、最終的な状態になってはならない。
トリアージの段階をどのように設定するか、自動化と人的作業の分担をどのように行うか、エスカレーションの経路をどのように設計するかは、各組織の裁量に委ねられています。ただし、取るべき措置は明確に定義され、その実行状況は確実に記録されなければなりません。
CIP-008への引き継ぎは、草案作成において重要な考慮事項です。2つのプログラムにおける定義、閾値、およびエスカレーション基準を整合させる必要があります。CIP-015において、CIP-008を発動させるべき活動として分類されているにもかかわらず、インシデント対応プロセスでそれが発動されない場合、コンプライアンス上の不備が生じている可能性があります。
R2 および R3：3つの保持クロックを記録する
R2およびR3は、データの保持と保護に関するものです。少なくとも、異常と判定されたアクティビティに関連するデータは、対応が完了するまで保持および保護されなければなりません。
3つの時計について考えてみると、役に立つと思います：
- 評価データ：異常を評価し、今後の対応を決定するために必要なデータを保持する。
- コンプライアンスの証拠：該当するNERC CIPの証拠保存期間および監査サイクルに従って、証拠を保存してください。
- 運用データ：調査、ベースライン設定、またはサイバーセキュリティ運用に有用である限り、追加データを保持する。
文書作成にあたっては、コンプライアンス要件と運用上の選択を明確に区別する必要があります。運用上の価値があるという理由でデータをより長期間保持することを選択する場合は、それが単なる「選択」であり、プログラムの要件ではないことを明確に明記してください。そうしないと、有益なサイバーセキュリティ対策が、意図せずして法的拘束力のあるコンプライアンス上の義務となってしまいかねません。
R3は、特に不正な削除や改ざんについて規定しています。この情報の保護については、CIP-015で定められた具体的な義務を文書化しつつ、可能な限り貴社のCIP-011「BESサイバーシステム情報（BCSI）」プログラムと整合させることをお勧めします。単にCIP-011のポリシーを参照するだけでは不十分です。
また、CIPの「例外的な状況」に関する記述はR2およびR3には存在しますが、R1には含まれていない点にも注意してください。その例外を規格全体に適用するようなINSMポリシーを作成しないでください。
INSMドキュメントにおける一般的なアンチパターン
私たちの多くは、一見完成しているように見えるものの、解決する問題よりも多くの問題を引き起こしてしまうプログラム文書を目にしたことがあるでしょう。CIP-015に関しては、特に以下のアンチパターンが重要です：
- 要件を方針として再定義する。「文書化されたプロセスを実施する」と述べるだけでは、貴組織が何を約束したのかが説明されていない。
- 曖昧な表現の使用。義務を定める際は、「～すべき」「通常」「一般的に」といった表現は避け、「～しなければならない」「～するものとする」といった明確な表現を使用してください。
- 機能ではなく製品名を指定する。ツールは変わるものです。組織がプラットフォームを変更するたびに、その方針について経営陣の承認を得る必要があってはなりません。
- 記録を残さない執筆プロセスの手順。証拠となる成果物がないプロセスは、その性質上、証拠がないものとなる。
- ベンダーによる導入に関する範囲の定義。範囲は、特定のプラットフォームの機能ではなく、CIP-002の分類、対象となるシステム、および電子セキュリティ境界に基づいて決定されます。
- ミキシング CIP-015-1 および CIP-015-2。現在プログラムに適用されているバージョンを定義し、プログラムの将来的な進化に備えて別途準備を行う。
1つのイベントをドキュメントチェーン全体にわたって追跡する
方針とプロセスの草案が完成したら、模擬監査の前にそれらをストレステストにかけましょう。
検出イベントを一握り抽出し、それぞれを最初から最後まで順を追って確認します：
- どのソースフィードが検知を引き起こしたのか、またそのフィードにはリスクに基づく根拠が文書化されているか。
- アラートとその発生源を示す、タイムスタンプ付きの検知記録はありますか？
- 誰が評価し、どのような結論を出したのですか？
- その活動が異常であると判断された場合、必要なデータは適切に保存・保護されていましたか？
- クローズを通じて、その後の対応は追跡されましたか？
リンクの断絶は一つひとつが、監査人のサンプリング対象となるのを待っている、起草上の不備や記録管理上の不備である。
INSMプログラムのドキュメントを実地テストする
私は、早い段階でドキュメントを作成し、それに従ってもらうことで、問題点を見つけ出してもらうという手法を大いに支持しています。文書化されたプロセスとその証拠の連鎖は、生き物のようなものです。継続的にメンテナンスを行えば、監査の際に役立てることができます。監査の直前まで待ってしまうと、証拠の収集はまるで考古学のような作業になってしまいます。
いつものことですが、この投稿ではウェビナーで取り上げられた内容のほんの一部にしか触れていません。まだ登録されていない方は、シリーズ全編に登録し、第9話のアーカイブ動画をご覧になって、議論の全容をご確認ください。これらの内容がご自身のプログラムにどのように応用できるかについて話し合いたい場合は、お気軽にお問い合わせください。私たちは皆様をサポートいたします。
