この記事は、当社の ウェビナーシリーズのハイライトを振り返るブログシリーズの一部です。このウェビナーシリーズでは、業界の専門家たちが、公益事業会社における内部ネットワークセキュリティ監視（INSM）プログラムの構築から得た知見や現場での教訓を共有しています。
第6回では、NERC CIPプログラムの根幹をなすテーマ、すなわち「生成される証拠」と、そのライフサイクル全体にわたる管理方法について取り上げました。私は電力業界での経験をもとに、このテーマについて語ります。 私はNERC CIPプログラムの構築・運営に携わってきたほか、コンサルタントとして模擬監査を実施し、資産所有者に助言を行ってきました。今回のエピソードでは、シーメンスのビジネス開発マネージャー兼サイバーセキュリティ担当チーフ・テクノロジー・エバンジェリストであるジェフ・フォーリー氏をお招きしました。同氏は、世界中の重要インフラ事業者が標準に基づいたセキュリティプログラムを構築できるよう支援しています。
Auditでは、お客様のINSMエビデンスが成果物となります
NERC CIPが、私たちが日々行っている多くの業務とは一線を画す、気まずい現実があります。それは、たとえ世界最高のプログラムを持ち、すべてを正しく行っていたとしても、実際に何かを行ったことを証明できなければ、何の意味もないということです。監査人にその実施状況を提示できなければ、懸念事項や指摘事項として扱われることになるでしょう。
NERC CIP-015は目的志向の規格です。プログラムを策定するのと同様に、コンプライアンスを実証するためにどのような証拠を収集するかも、各組織が自ら決定することができます。これには、INSMプロセスに記述した内容を実践していることを示す証拠が含まれるべきです。規格および技術的根拠には一定の指針が示されていますが、それらは強制的なものではありません。
さらに事態を複雑にしているのは、NERC CIP-015の証拠資料が異例なほど多様であるという点だ。証拠資料の構成がかなり標準化されているCIP-004の研修要件と比較すると、INSMの場合、証拠資料はポリシーやプロセスからデータフィードの設定、検知イベント、保存レポートに至るまで多岐にわたり、これらはすべてプログラムおよびINSMソリューションによって駆動されている。
INSMは、他の多くのNERC CIP規格以上に、データ管理規格である。
NERC CIP-015-1の各要件に関する証拠の分析
証拠要件にはさまざまな種類があるため、各要件において何を考慮すべきか、よくある落とし穴や証拠例も含めて詳しく見ていきましょう。
R1 文書化された1つ以上のプロセス
文書化されたCIP-015プロセスの写しを提出することは、NERC CIP証拠提出における標準的な手順です。一方、プロセスの実施に関する証拠を提示することこそが、各組織にとってより大きな課題となる可能性があります。これについては、各要件ごとに実施するのが最適であり、プロセス全体のバージョン管理、承認、および導入プロセスを文書化する必要があります。これには、プロセスの実施時期について、専門家（SME）や経営陣による承認を得ることも含まれる場合があります。
一般的な証拠：
- 承認済みのNERC CIP-015プロセスおよび方針
R1 1.1 ネットワークデータフィードおよびリスクに基づく根拠
ネットワークデータフィードがどこで収集されているか、またその理由を文書化することが、R1 1.1 の要件を満たすための鍵となります。多くの場合、「百聞は一見に如かず」と言われますが、このケースでは、論理的なネットワーク構成、通信フロー、センサー配置図を含むネットワーク図が非常に役立ちます。リスクに基づく根拠を含む理由付けを文書化することは、より困難であり、組織をコンプライアンスリスクにさらす可能性があります。 プロセスを文書化する際には、意思決定フローチャートと明確な根拠を記載することが推奨されます。トラフィックのフィルタリングが行われている場合は、その決定内容と根拠も記載する必要があります。例えば、バックアップトラフィックはセキュリティ上の価値が低く、多くの場合暗号化されているため、フィルタリングされることがよくあります。
一般的な証拠：
- 論理ネットワーク図
- 通信フロー図
- 論理ネットワークセンサー図
- ネットワーク給電位置の根拠
- リスクに基づく根拠の正当化（文書化された意思決定の流れ）
- ネットワーク収集ポイントの設定（タップ、スイッチ、パケットブローカーの設定）
R1 1.2 異常なネットワーク活動を検出する方法
異常なネットワーク活動を検知するには、まずその定義を明確にする必要があります。次に、それをどのように検知するかを文書化する必要があります。ベースライン、シグネチャ、行動検知、あるいは複数の手法を組み合わせて使用する予定でしょうか？ これらの多くは、R1で定義されているCIP-015 INSMプログラム文書の一部となっているかもしれませんが、1.2では、ネットワーク異常検知を可能にする設定の証拠に加え、検知された異常イベントの証拠も求められることになります。
一般的な証拠
- 異常なネットワーク活動を定義する
- 異常なネットワークの検出方法に関する文書
- ネットワークのベースライン（該当する場合）
- 異常検知ルール
- 検出された異常
- アラート処理ロジック
- INSM システム設定
R1 1.3 検出された異常なネットワーク活動を評価する方法
異常なネットワーク活動の評価方法に関する証拠を提示してください。これには、実施された措置やエスカレーションの手順を含め、CIP-008サイバーセキュリティインシデント対応計画への言及も盛り込んでください。評価プロセスや意思決定フロー図は、特に検知されたネットワークの異常に関するログや結果によって裏付けられている場合、有力な証拠となります。
一般的な証拠
- 異常評価プロセスの文書化
- CIP-008に基づくインシデント対応を発動するための基準を含む、異常の分類およびエスカレーションプロセスの文書化
- アクションと結果を含む異常事象
R2 INSMデータを保持する
データの保存期間については、単純明快だと考えられがちです。保存期間、保存方法の設定、データの保存場所やレプリケーション先、そしてバックアップの方法などは、プロセスによって定義されます。しかし、保存期間の管理は単にプロセスを定義するだけにとどまりません。保存期間に関して、チームが最もつまずきやすい点は、運用データと証拠資料の要件の違いを理解することです。CIP-015には2つの保存区分があり、それぞれ異なる義務と異なる保存期間が定められています：
重要な点は、異常が評価された瞬間、特にそれがインシデントの始まりであることが判明した場合には、運用データがコンプライアンスデータに変わるということです。要件としては、分析を行うために必要な期間、データを保持することになっていますが、これは私たちが慣れ親しんでいる明確な基準に比べると、曖昧に聞こえるかもしれません。ベストプラクティスとして、「3ヶ月後に削除する」といった恣意的なルールを設定すべきではありません。データの保持期間は、分析結果に基づいて決定すべきです。
一般的な証拠
- 文書化されたデータ保持プロセス
- データ保存が適切に行われていることを示す証拠
R3：INSMデータの保護
R3については、データが監査中ではなく監査前の段階でBCSIに該当するかどうかを判断してください。通常、これはプロセスの開始時点となります。通常、INSMデータはBCSIに該当しますが、各々が独自のプログラムを作成しています。これをBCSIとして分類し、CIP-011情報保護プログラムの下で保護すれば、R3の要件を満たすはずです。もし該当しないと判断した場合でも、保護措置を適用し、その内容を文書化する必要があります。
いずれにせよ、ロールベースのアクセス制御、監査ログ、セグメンテーション、ストレージの整合性確保、およびシステムの強化は、攻撃者が、その存在を検知するために頼るべき記録そのものを、気づかれないうちに削除してしまうのを防ぐために設計された対策です。データを保護するためにどのような対策が導入されているかを文書化することが重要です。
一般的な証拠
- 文書化されたデータ保護プロセス
- データ保護が実施されていることを示す証拠
データ管理
INSMは、他の多くのNERC CIP規格以上に、データ管理規格としての性格が強いものです。オーバーヘッドのない100 MbpsのPCAPデータを、1年分、さらに3年分に換算して試算してみると、ストレージ要件が驚くほど急速に膨れ上がることがわかります。 エンタープライズクラスのストレージでは、1テラバイトあたり年間およそ1,500～3,000ドル（この金額は上昇傾向にある）かかるため、「すべてを保存する」という戦略は現実的ではなくなります。
すべてのデータが長期にわたって同じ価値を持つわけではないため、価値や必要性、そしてストレージコストに基づいてデータを階層化するのが賢明な方法です。その技術的な根拠については、以下のような表が挙げられます（ここでは内容を一部改変しています）：
評価や調査を支援するためにデータが確実に利用可能となるようデータ管理戦略を採用しつつ、証拠として必要のない価値の低いデータは保持しないことが、INSMのデータ管理プログラムを成功させるための鍵となる。
発見が隠されている場所
「検出と評価」（R1 第1.2項および第1.3項）は、監査人が問題を発見しやすい箇所です。監査のサンプル調査で1,000件もの異常が検出されたと想像してみてください。もし監査人が、たまたま評価ワークフローが完了していなかった1件を選んでしまったら、それは大変な事態です。そのような事態を避けるためには、プロセスを明確に定義し、すべての事象に対してそのプロセスに従う必要があります。なぜなら、どの異常が重要になるかは、事前に予測できることはめったにないからです。
常に監査に備えておく
これらすべてを結びつける習慣があるとすれば、それは私の初期のメンターたちが徹底して教えてくれた「常に監査に対応できる態勢を整えておく」というものです。証拠の生成を自動化しましょう。システムが定期的に.pdf、.csv、または監査ログをフォルダに保存するように設定し、誰かにそれを確認してもらいます。 「信頼はするが、検証もする」。模擬監査を実施しましょう。リハーサルで問題点を発見し、事前に自主報告しておけば、監査人に指摘されるよりも、地域との関係をはるかに良好に築くことができます。
証拠の生成と収集に関する最終的な考察
CIP-015-2が導入されます。証拠要件の大部分は実質的に変更されませんが、適用範囲がESPを超えて拡大され、「共有サイバーインフラストラクチャ」が対象に加わります。プログラムが適切に構築されていれば、情報の収集方法に変化はないはずですが、収集量については変更が必要になるでしょう。
この投稿では、ウェビナーで取り上げられた内容のほんの一部にしか触れていません。ウェビナーシリーズに登録し、第6回のアーカイブ動画をご覧いただければ、ストレージの計算方法や、厳選された模擬監査の事例など、議論の全容をご確認いただけます。また、これらの内容がご自身のプログラムにどのように適用できるかについて話し合いたい場合は、お気軽にお問い合わせください。私たちは皆様をサポートいたします。
.webp)
