/
ランサムウェアの封じ込め

サイバーインシデントで何をすべきか、パート2:非技術的対応

で説明したように 第一部 このシリーズのうち、サイバーインシデント発生後の最初の技術的対応は、インシデントを封じ込め、さらなるデータ盗難を軽減するために重要です。サイバーインシデントの規模が明らかになるにつれ、非技術的な対応策の策定に役立つかもしれない細部まで書き留めておくことが重要です。サイバーインシデント対応計画はしっかりと策定されている必要があります。ガートナーはこれを次のように定義しています。

これは「コンピュータインシデント対応計画」とも呼ばれ、ウイルスやハッカーの攻撃など、壊滅的な被害をもたらす可能性のあるコンピュータ関連のインシデントに対応するために企業によって策定されます。CIRP には、インシデントが悪意のあるソースから発生したかどうかを判断し、発生源が悪意のある場合は、脅威を封じ込め、攻撃者から企業を隔離するための措置を含める必要があります。

この計画は、発生する可能性のあるインシデントを処理する関連チームの構成に反映されます。例としては、次のものが挙げられます。

  • ファーストレスポンダー
  • 戦術 (セキュリティ)
  • チームコーディネーター (Cレベル)
  • リーガル
  • パブリック・リレーションズ

通常、最初の対応者はITヘルプデスクで、組織内のIT関連の問題や故障/修正の問題に関与する傾向があります。報告された問題がセキュリティに関するものであれば、すぐに戦術(セキュリティ)チームにエスカレーションされ、インシデントの重大度によっては、より専門的な外部のインシデント対応チームが関与することもあります。その後、このチームが、より詳細なフォレンジック調査と根本原因分析を担当することになります。通常、CIO や CISO などの経営幹部は定期的に最新情報を受け取り、それをトップレベルの管理職に提供します。特に深刻なケースでは データ侵害。法的または広報上のコミュニケーションが必要になった場合は、それぞれのチームが関与する必要があります。これらすべてのステップは、全体計画の一部である標準運用手順 (SOP) の一部を構成する必要があります。

2.1

また、組織内のすべての従業員は、インシデントが発生した場合に報告ラインを明確に伝える必要があります。スタッフがそのような方針の重要性を認識していなければ、効果的なサイバー対応計画を立てることは非常に困難になります。

たとえば、不審なメールを受け取った従業員は、適切な技術スタッフが悪意のあるメールかどうかを確認できるように、そのようなインシデントをすぐに報告する必要があります。また、組織のサイバー監視システムのいずれかでアラートがトリガーされた可能性もあります。ほとんどの場合、脅威アクターは最も脆弱なリンクであるエンドユーザーを標的にします。一見些細なインシデントを報告しないことが、大規模な悪意のあるキャンペーンの始まりを検知するかどうかの分かれ目になることがあります。

したがって、非技術的対応部分では、以下を含むポリシー、手順、およびプロセスを扱います。

  • インシデントアセスメント
  • インシデントレポート
  • 規制報告
  • 公開情報開示

インシデントアセスメント

現在知られている情報に基づいてサイバーインシデントを初期分類することが重要です。すべての詳細が分からなくても、起こり得る影響レベルは最悪のシナリオであるべきです。で説明した参照例のように 初期技術対応、サイバーインシデントに内部ユーザーアカウントの侵害が含まれる場合、侵害されたアカウントがアクセスできる各リソースも影響を受ける可能性があります。

これは、特にインシデント発生時に多要素認証やマシン認証制御が使用されていなかった場合に、VPNやリモートアクセス、電子メールアクセス、イントラネットリソースアクセスなどのリソースである可能性があります。

2.2

潜在的な影響レベルは、テクニカル・レスポンス・フェーズの指針となるはずです。インシデントの全容をある程度確実に調査し判断できれば、既知の影響レベルの評価を確認することができます。その場合、インシデントの影響と影響が当初考えられていたほど深刻ではない可能性は十分にあります。

インシデントの初期影響を評価することは重要なステップです。これにより、規制当局への正式な報告の性質、パブリックコミュニケーションの開示が必要かどうか、バックグラウンドプロトコルを有効にすべきかどうかなど、他のステップについて情報に基づいた決定を下すことができます。いずれにしても、そうでないことが証明されるまで、最悪のシナリオを想定して進めるのが最善策です。

インシデントレポート

サイバーセキュリティインシデントが自動的に重大な侵害と見なされるわけではありませんが、インシデントレポートを作成することは依然として不可欠です。最初は、インシデントの重要な側面を詳述した正式な内部報告になります。レポートには、インシデント ID とインシデント所有者が明記されている必要があります。

2.3

正式なレポートには、インシデントの種類、インシデントの概要、タイムライン、影響、根本原因の分析、是正措置や復旧措置、最後に特定のインシデントから学んだ教訓など、いくつかの有用な情報も記載する必要があります。例としては、次のようなものがあります。

  • インシデント日付
  • インシデント ID
  • インシデントオーナー
  • インシデントサマリー
  • インシデントタイムライン
  • インシデントの詳細
  • 影響分析
  • 根本原因
  • 修復と回復
  • 学んだ教訓
  • 付録

レポートには、影響を受けたユーザーとそのアカウントに関する詳細と、インシデント前、インシデント中、インシデント後の発生のタイムラインを含める必要があります。コンピューターシステム、データ、ウェブサイトなど、影響を受ける組織の資産についても詳しく説明する必要があります。これは、最終的な影響分析と根本原因分析に役立つでしょう。すべての報告は適切に提出し、報告された各インシデントについて報告終了時にカタログ化する必要があります。

規制と情報開示

規制当局と取引する場合、組織の業種(医療、金融、運輸、小売)によっては、特定の枠組みや規制に従う必要があります。また、特に顧客や従業員の個人データが関係するインシデントでは、GDPRなど、さまざまな業種にわたる一般的なコンプライアンス規制も導入されるでしょう。この場合は、法執行機関への通知も必要になる場合があります。このような報告の受け取りを担当するのは、法執行機関の管轄かもしれません。防衛活動も行っている組織や、国の重要インフラと見なされる組織の一部である組織の場合、規制上の要件により、そのような機関への報告が明確になっている場合があります。

2.4

また、事件の法的側面についても十分に考慮する必要があります。繰り返しになりますが、事件が個人情報のデータ侵害を伴う場合は、潜在的な法的異議申し立てに備えて十分な準備も整えておく必要があります。組織は適切な法的助言を求めるべきです。また、法律顧問は、開示の内容と、組織内の誰が正式にそのような開示を行ったかを知らせる必要があります。このようなサブチームには以下が含まれる場合があります。

  • 経営幹部レベル (CIO/CISOまたは同等の職種)
  • インシデントレスポンスチームリーダー (技術)
  • リーガル
  • パブリック・リレーションズ

重大なデータ侵害が確認された場合(つまり、個人情報または顧客データに不適切なアクセスがあった場合)、公表する必要がある場合があります。これは、法的にも財務的にも組織に直接的または間接的に悪影響を及ぼす可能性があるため、非技術的対応において最もデリケートな部分の1つです。したがって、このような情報開示を行う最善の方法については、有能な広報チームと相談することが最も重要です。ほとんどの場合、いつ、どのように公開するかは、規制の枠組みによって決定されます。また、規制当局をいつ、どのように関与させるかについても決定します。

これで、すべての組織のサイバーセキュリティポリシー文書にサイバーインシデント対応計画を含める必要があることが明らかになったはずです。常駐の対応チームと、明確かつ実行可能な標準運用手順 (SOP) が必要です。すべてのスタッフ、請負業者、および関連職員は、サイバーポリシーと報告ラインを十分に認識している必要があります。NISTなどの地域および国際機関は、インシデント対応計画の指針となる公的枠組みを提供しています。サイバーインシデント対応に関しては、組織の規模や規模に関係なく、特にこの時代においては、計画と準備が成功への究極の鍵です。違反を想定. '

関連トピック

アイテムが見つかりません。

関連記事

名前:WRECK Takeaways — マイクロセグメンテーションが可視性と抑制にどのように役立つか
ランサムウェアの封じ込め

名前:WRECK Takeaways — マイクロセグメンテーションが可視性と抑制にどのように役立つか

マイクロセグメンテーションが、WRECKの脆弱性、リモートコード実行、サービス拒否を防ぐための可視性と封じ込めにどのように役立つのか。

Kubernetes はランサムウェアの影響を受けないわけではなく、イルミオがどのように支援できるか
ランサムウェアの封じ込め

Kubernetes はランサムウェアの影響を受けないわけではなく、イルミオがどのように支援できるか

ランサムウェアがKubernetesにおける非常に現実的なサイバーセキュリティリスクであり、DevSecOpsアーキテクトが無視するわけにはいかない理由をご覧ください。

Contain Ransomware at Its Source With Zero Trust Segmentation
ランサムウェアの封じ込め

Contain Ransomware at Its Source With Zero Trust Segmentation

Learn why the ransomware threat is so critical and how to achieve ransomware containment with Zero Trust Segmentation.

アイテムが見つかりません。

違反を想定.
影響を最小限に抑えます。
レジリエンスを高めます。

ゼロトラストセグメンテーションについて詳しく知る準備はできていますか?