• 1.基本的な考え方
• 2.サイバーセキュリティ管理態勢
  • 2.1 サイバーセキュリティ管理態勢の構築
    • 2.1.1 基本方針、規程類の策定等
    • 2.1.2. 規程等及び業務プロセスの整備
    • 2.1.3. 経営資源の確保、人材の育成
    • 2.1.4. リスク管理部門による牽制
    • 2.1.5. 内部監査
  • 2.2. サイバーセキュリティリスクの特定
    • 2.2.1. 情報資産管理
      • 2.2.1.1. 情報システム及び外部システムサービス
      • 2.2.1.2. ハードウェア・ソフトウェア等
      • 2.2.1.3. 情報（データ）
      • 2.2.1.4. データフロー図・ネットワーク図
    • 2.2.2. リスク管理プロセス
      • 2.2.2.1. 脅威情報及び脆弱性情報の収集・分析
      • 2.2.2.2. リスクの特定・評価
      • 2.2.2.3. リスク対応
      • 2.2.2.4. 継続的な改善活動
    • 2.2.3. ハードウェア・ソフトウェア等の脆弱性管理
    • 2.2.4. 脆弱性診断及びペネトレーションテスト
    • 2.2.5. 演習・訓練
  • 2.3. サイバー攻撃の防御
    • 2.3.1. 認証・アクセス管理
    • 2.3.2. 教育・研修
    • 2.3.3. データ保護
    • 2.3.4. システムのセキュリティ対策
      • 2.3.4.1. ハードウェア・ソフトウェア管理
      • 2.3.4.2. ログ管理
      • 2.3.4.3. セキュリティ・バイ・デザイン
      • 2.3.4.4. インフラストラクチャ（ネットワーク等）の技術的対策
      • 2.3.4.5. クラウドサービス利用時の対策
  • 2.4. サイバー攻撃の検知
    • 2.4.1. 監視
  • 2.5. サイバーインシデント対応及び復旧
    • 2.5. サイバーインシデント対応及び復旧
    • 2.5.2. インシデントへの対応及び復旧
      • 2.5.2.1. 初動対応（検知・受付、トリアージ）
      • 2.5.2.2. 分析
      • 2.5.2.3. 顧客対応、組織内外の連携、広報
      • 2.5.2.4. 封じ込め
      • 2.5.2.5. 根絶
      • 2.5.2.6. 復旧
  • 2.6. サードパーティリスク管理
• 3. 金融庁と関係機関の連携強化
  • 3.1. 情報共有・情報分析の強化
  • 3.2. 捜査当局等との連携
  • 3.3. 国際連携の深化
  • 3.4. 官民連携
• 参考リンク

1.基本的な考え方

金融庁は2024年10月4日に「金融分野のサイバーセキュリティに関するガイドライン」（以下、ガイドライン）を公開した。ここではそれを理解するための要点をまとめる。

なお、要点をまとめる際は、章節を網羅しないで自分の仕事上関連性が強く、重要と思うものだけを書いてあるので、見てくれた方この点をご理解ください。

• 目的
  金融機能の安定の確保や預金者の保護。
• 適用対象(以下、金融機関等)
  主要行等、中小・地域金融機関、保険会社、少額短期保険業者、金融商品取引業者等、信用格付業者、貸金業者、前払式支払手段発行者、電子債権記録機関、指定信用情報機関、資金移動業者、清算・振替機関等、金融サービス仲介業者、為替取引分析業者、暗号資産交換業者、銀行代理業、電子決済手段等取引業者、電子決済等取扱業者、電子決済等代行業者、農漁協系統金融機関のほか、金融商品取引所。
• リスクベース・アプローチで検査・モニタリングを実施。

2.サイバーセキュリティ管理態勢

6項目について、「基本的な対応事項（125項目）」、「対応が望ましい事項（50項目）」に分けて推奨事項を記載。

2.1 サイバーセキュリティ管理態勢の構築

2.1.1 基本方針、規程類の策定等

• 基本的な対応事項
  • ⑤ 経営陣は、金融商品・サービスを導入する場合や、デジタルトランスフォーメーションを推進する場合には、セキュリティ・バイ・デザインを含むサイバーセキュリティ確保に向けた取組みも同時に推進すること。
    • セキュリティ・バイ・デザイン

      金融商品・サービスの企画・設計段階から、セキュリティ要件を組み込む考え方。

• 対応が望ましい事項
  • a.３線防衛態勢（業務部門、リスク管理部門及び内部監査部門）のガバナンスを確保。
  • b.サイバーセキュリティリスクをERMの一部として位置づけ、リスク選好度、リスク耐性度の設定。

    リスク選好度(リスクアペタイト)とは、自社の戦略目標や事業計画を実現するために、リスクキャパシティ（組織が許容できる最大のリスク量）の範囲内において、進んで受け入れるリスクの種類と総量をいう。
    リスク耐性度(リスクトレランス)とは、リスク選好度を設定した上で、重要な業務と特定した金融サービスについて、未然防止策を尽くしてもなお、業務中断が必ず生じることを前提に最低限維持すべき水準をいう。

  • d.経営陣は、少なくとも１年に２回、サイバーセキュリティにかかる指標の報告を担当部署等に求めること
    • パフォーマンス指標（KPI）の例
      • 標的型メール訓練の報告率、脆弱性対応率、情報資産棚卸進捗率、トレーニング受講率等
    • リスク指標（KRI）の例
      • サイバー攻撃試行件数、監査指摘件数、インシデント件数、未対応の脆弱性件数等

2.1.2. 規程等及び業務プロセスの整備

• 基本的な対応事項
  • ①経営陣は、サイバーセキュリティに係る規程及び業務プロセスを整備し、少なくとも１年に１回見直しを行うこと。

2.1.3. 経営資源の確保、人材の育成

2.1.4. リスク管理部門による牽制

• 基本的な対応事項
  • ① リスク管理部門は、サイバーセキュリティ管理態勢が有効に機能しているかについて、業務部門等から独立した立場から監視・牽制を行うこと。

2.1.5. 内部監査

• 基本的な対応事項
  • ① 内部監査部門は、独立した立場から、リスクベース・アプローチに基づき、サイバーセキュリティに係る内部監査計画を策定し、サイバーセキュリティをテーマとする内部監査を実施すること。

2.2. サイバーセキュリティリスクの特定

2.2.1. 情報資産管理

• 基本的な対応事項
  • ② 情報資産は、その重要度（機密性、完全性、可用性）に応じて保護の優先度を分類し、管理すること。
    • 情報資産とは

      ①情報システム及び外部システムサービス（外部委託先、クラウドサービス）、②その構成要素であるハードウェア・ソフトウェア等及び保管される情報（データ）並びに③ネットワークを指す。

2.2.1.1. 情報システム及び外部システムサービス

• 基本的な対応事項
  • ① 情報システム及び外部システムサービスを適切に管理するための台帳整備、メンテナンス手順を定めるなど、最新の状態を網羅的に把握。各部門の所管情報システム含む。当該台帳等は、2.2.1.2 節及び 2.2.1.3 節に規定する台帳等と相互参照可能に。

2.2.1.2. ハードウェア・ソフトウェア等

• 基本的な対応事項
  • ① HW及びSW等を適切に管理するための手続・台帳等を整備し、メンテナンス手順を定めるなど、最新の状態を網羅的に把握。台帳等には、以下の項目を含める。
    • サポート期間（サポート終了予定日、サポート期間延長の可否）
    • ソフトウェアの場合、バージョン情報
• 対応が望ましい事項
  • d. 管理対象外の個人所有端末等の情報資産や未承認のクラウドサービスの利用（シャドーIT 等）を特定、管理対象とするか使用を中止するなど、適切に対応。
  • e. 以下に掲げるものに関するソフトウェア部品表（SBOM、Software Bill of Materials）を整備。
    ・ 自社開発のソフトウェア
    ・ 利用しているサービス（当該サービス事業者が SBOM を提供している場合）

2.2.1.3. 情報（データ）

• 基本的な対応事項
  • ① 顧客情報や機密情報等を適切に管理するための台帳等を整備、メンテナンス手順を定めるなど、最新の状態を網羅的に把握。

2.2.1.4. データフロー図・ネットワーク図

• 基本的な対応事項
  • ① 全体を俯瞰してデータフロー及びNWを適切に管理するため、DF図・NW図を作成し、メンテナンス手順を定めるなどにより、最新の状態を把握（モバイル接続、外部接続、NWに接続するサードパーティ及び内部システムを含む）。

2.2.2. リスク管理プロセス

2.2.2.1. 脅威情報及び脆弱性情報の収集・分析

• 対応が望ましい事項
  • a. 自組織の業務に即して、金融 ISAC 等の専門性の高い情報共有活動や、業界横断的な団体、国際的な団体等に積極的に参画し、脅威情報や脆弱性情報等を収集し共有。
    • 金融ISAC（Financials ISAC Japan）

      金融機関がサイバーセキュリティに関する情報を共有し、高度化するサイバー攻撃への対応を強化するための枠組みとして2014年に設立。日本国内の金融機関を中心に、多くの会員が参加、不正送金、フィッシング攻撃、ゼロデイ脆弱性への対応など、最新のサイバー脅威情報を共有(ISAC:Information Sharing and Analysis Center)

  • c. 新技術（AI、量子コンピュータ等）、地政学的動向、偽情報、業界動向などの組織を取り巻く状況に留意し情報収集を行う。

2.2.2.2. リスクの特定・評価

• 基本的な対応事項
  • ② 脅威情報及び脆弱性情報を踏まえたサイバー攻撃の発生可能性、並びにサイバー攻撃が発生した場合の自組織の事業や情報資産に与える影響に基づき、サイバーセキュリティリスクを少なくとも１年に１回評価。また、重大な脅威や脆弱性が判明した時や、新規商品又はサービスの提供時にも評価。

2.2.2.3. リスク対応

2.2.2.4. 継続的な改善活動

• 対応が望ましい事項
  • b. パフォーマンス指標（KPI）及びリスク指標（KRI）を測定・評価し、経営陣に報告する仕組みを整備。また、具体的な目標及び達成指標を設定し、改善の状況及び課題を特定。

2.2.3. ハードウェア・ソフトウェア等の脆弱性管理

• 基本的な対応事項
  • ① HW・SW等の脆弱性管理に係る手続等を策定し、必要に応じて見直すこと。手続等には以下を含める。
    • 脆弱性情報の入手先及び情報を入手するためのプロセスに関すること（当該情報の入手先として、公的機関、情報共有機関及びサードパーティ等を含めること）
    • 入手した脆弱性の深刻度、影響の大きさ及び影響範囲の評価に関すること
    • 脆弱性への対応方法と対応期限の決定、及び対応状況の管理に関すること
    • 例外的な取扱いをする際の意思決定プロセスに関すること
  • ② 入手した脆弱性情報は、HW・SWの脆弱性管理に係る手続等に基づき、対応の要否を判断すること。
  • ③ システムの重要度、リスク又は脆弱性の深刻度に基づいたパッチ適用等の対応期限の設定とともに対応実績を管理。例外的にパッチ適用等の対応を実施しない場合には、実施しないことと実施しないことのリスクについて経営陣等から承認を得る。
  • ④ 深刻度の高い脆弱性が判明した場合、情報システム及びHW・SW等に関する台帳等に基づき、影響を受ける情報システム等を特定し、速やかに対応。
  • ⑤ 深刻度の高い脆弱性については、グループ会社、海外拠点が保有するシステムについても、脆弱性対応の範囲に含める。
  • ⑥ 深刻度の高い脆弱性については、重要なサードパーティが保有するシステムの脆弱性対応の管理を行う。
• 対応が望ましい事項
  • a. 深刻度の高い脆弱性については、クラウド事業者を含むサードパーティ（上記⑥のサードパーティを除く）が保有するシステムの脆弱性対応の管理を行う。

2.2.4. 脆弱性診断及びペネトレーションテスト

• 基本的な対応事項
  • ① 脆弱性対策やセキュリティの問題点を特定し、改善するために、リスクの大きさやシステムの重要度等も考慮した上で脆弱性診断及びペンテストを定期的に実施。また、関連する手続等を策定し、必要に応じて見直す。手続等においては、以下の点に留意。
    • 脆弱性診断の対象範囲（外部に直接接続している機器（VPN 機器など）を含む）、実施頻度、実施時期（システムのリリース前を含む）及び実施工程を含める。
  • 外部公開ウェブサイトについては、脆弱性診断として、PF診断に加え、ウェブアプリ診断も実施。
    プラットフォーム診断

    推測可能なPWの存在やOS・ミドルウェアの設定不備等、Webアプリの土台となるサーバ上に生じうる欠陥の有無を調査するもの。

    • モバイルアプリを対象とする脆弱性診断を実施。
    • リスクの高い構成である場合（NWセグメントを分離していない場合等）には、外部公開サーバや内部環境のセキュリティ上の根幹となる機器（Active Directory サーバ、ファイルサーバ等）に対する脆弱性診断を実施。
    • 特定された問題を優先順位付けし、対応方法と対応期限を決定し、対応状況を管理。
    • 脆弱性診断及びペンテストの結果のうち、重要性のあるものについては迅速に経営陣等に報告。
• 対応が望ましい事項
  • a. 脆弱性診断及びペンテストは、インターネットに直接接続していない VPN 網、内部環境も対象とする。
  • b. 定期的に脅威ベースのペンテスト（TLPT）を実施。実施する際には、以下の点に留意
    • 必要な経験及びスキルを持つ業者を選定。
    • 脅威インテリジェンスを踏まえ、実際の攻撃者が行う水準のテクニックを用いたテストを行う。
    • 関係主体等に対するサービスの提供に影響を及ぼしうる、深刻だが現実に起こりうる脅威シナリオをテスト計画に考慮。
    • テストでは、防御側の担当者（ブルーチーム）によるインシデント対応能力の評価（防御・検知・報告・封じ込め等）を行う。
    • テストは、本番環境を利用し、防御側の担当者（ブルーチーム）に予告することなく実施。
    • 判明した課題を経営陣に報告し、改善活動を行う。
  • c. 自組織のシステム環境を熟知する内部人材によるペンテスト（レッドチームによるテストを含む）を実施。
  • d. ペンテストの方法及び結果を定期的にレビューし、新たな独立した視点を得るためにテストベンダーの交代要否を検討。

2.2.5. 演習・訓練

• 基本的な対応事項
  • ① 組織におけるサイバーインシデント対応計画及びコンティンジェンシープランの実効性を確認し、課題を把握した上で継続的に改善するために、定期的な演習・訓練を実施すること（他組織主催の演習・訓練への参加を含む）。また、必要に応じて、演習・訓練への外部委託先の参加を検討するほか、業界横断的な演習に参加。
  • ② 経営陣、サイバーセキュリティを統括管理する責任者（CISO 等）及び業務部門の責任者が自らサイバー演習・訓練等に関与し、その結果を把握。
  • 演習・訓練のシナリオには、顧客に深刻な影響を与え、かつ現実に起こりうるシナリオを含めて検討。
  • 演習・訓練を通じて、業務継続等の観点でサイバーインシデント対応計画及びコンティンジェンシープランの有効性を定期的に検証し、演習・訓練で得られた課題や教訓等を踏まえ見直す。
  • 演習・訓練の手法・シナリオ等について、最新の脅威動向等に応じて見直す。
• 対応が望ましい事項
  • a. 実機等を用いた復旧訓練は、システムやデータの復旧手順の適切性や、復旧目標（目標復旧時点（RPO）、目標復旧時間（RTO））の妥当性の確認を含める。
  • b. 自組織への影響が大規模かつ長期間継続するインシデントや、取引所、清算・振替機関等への接続障害等が生じるインシデントなど、金融システム全体に深刻な影響が波及するシナリオを用いた演習・訓練を実施。

2.3. サイバー攻撃の防御

• 基本的な対応事項 ① サイバー攻撃に備え、不正侵入を防止するための境界NW対策、内部NWでのシステム不正利用を防止するための対策、外部への情報漏洩対策といった多層防御を講じる。

2.3.1. 認証・アクセス管理

• 基本的な対応事項
  • ① 認証及びアクセス権の付与に係る方針及び規程等を策定し、定期的に見直す。その際、以下の観点を踏まえる
    • ユーザ（システムを含む）のアクセス権限を必要最小限に制限し、職務の分離を考慮。
    • アカウントのライフサイクル（作成、使用、終了）管理、及びアカウントの定期棚卸しや操作履歴のレビュー実施、並びに無権限者によるアカウントの不正使用を防止。
    • 特権アカウントの利用を厳格に制限し管理（多要素認証、操作のダブルチェック、アカウントの時間制限の設定等）。
    • 外部委託先によるアクセス権の利用を適切に管理。
  • ② システムへのアクセス権限は、正当な業務上の要請があり、承認され、適切に教育・研修を受け、管理されている個人に対してのみ付与。また、ユーザによる機器及びシステムへのアクセス権限は、システムや情報の重要度を考慮して付与。
  • ③ 機器及びユーザのID及び認証情報を適切に管理（初期設定されたPWの変更、PW強度の要件、IDの自動失効、システム責任者による定期アクセスレビュー等）。
  • ⑤ システムや情報の重要度に応じて、認証要件（多要素認証、リスクベース認証等、認証時におけるリスク低減策等）を決定。特に、重要なシステムへのリモートアクセスには、多要素認証を使用。
  • ⑦ SSOや外部認証連携等、システム間又はセキュリティ境界にまたがる認証及び認可における機密性、完全性及び真正性等を確保。

2.3.2. 教育・研修

• 基本的な対応事項
  • ② サードパーティ在籍の担当者が、業務を適切に行う上で必要となるサイバーセキュリティの教育・研修を受講していることを確保。サードパーティによる社内教育・研修が実施されていることを金融機関等が確認することをもって受講を確保することも含まれる。
  • ④ IT 又はセキュリティを所管する部門の役職員に対して、脅威及び対策の変化等、最新の知識とスキルを維持するための教育・研修を定期的に実施。
  • ⑤ 役職員に対して、自身がインシデントの当事者となった場合に適切な対応を行うために、必要な教育・研修等の機会を確保。また、インシデント対応及び復旧計画における役割及び運用手順に係る教育・研修を、関係する役職員に対して、定期的に実施。

2.3.3. データ保護

• 基本的な対応事項
  • ⑤ システム及び情報の重要度に応じたBKUP要件、BKUPの隔離と保護、整合性の検証、復旧テストの実施等を含む、BKUPに関する規程等を整備し実装。また、清算・振替機関等においては、BKUPデータの完全性の確保のために、必要に応じて、関係者との間において、データ共有に係る取決めを行っておく。特に、ランサムウェア攻撃のリスクを考慮して、BKUPの期間や頻度を検討。また、同一NW内のBKUPファイルを探索して削除するランサムウェアのタイプがあることを踏まえて、改ざん耐性BKUPシステムの利用、組織内NWから切り離した複数の環境での保管や媒体等へのBKUPを実施。
• 対応が望ましい事項
  • a. DLP又はそれに相当するものを導入し、役職員や外部関係者によるデータ漏えいを監視し保護。

2.3.4. システムのセキュリティ対策

2.3.4.1. ハードウェア・ソフトウェア管理

• 基本的な対応事項
  • ③ EOLに伴うHW・SWの廃止・更改を計画的かつ安全に実施。SWについてサポート対象Verへの更新が困難な場合には、補完的な措置を講じるとともに、迅速にサポートが得られるSWを利用したシステム・ビジネスプロセスへの移行計画を立て、着実に実行。
  • ④ システムをマルウェアの感染から保護する。例えば、以下の方法が考えられる
    • マルウェア対策ソフトの導入、マルウェアシグニチャ（パターンファイル）及び動作プロファイル（ふるまい定義）の自動更新。
    • 不正なコード（JavaScript、ActiveX、VBScript、PowerShell など）に対する保護機能の導入。
    • メールのマルウェア又は不正サイトへのリンクの検出、隔離、ブロック。
    • 悪意あるウェブサイト、未承認の SNS サービス、ファイル交換サービス等への接続制御。
• 対応が望ましい事項
  • a. システムで利用するサードパーティのLIBやミドルウェア、HWについては、不正侵入の経路となるバックドア等が含まれることのないように、セキュリティ・バイ・デザインやセキュリティ・バイ・デフォルト等の安全な開発手法を製品開発に取り入れている事業者から提供される安全なプロダクトを選定。 セキュリティ・バイ・デフォルト

    ユーザー（顧客）が、追加コストや手間をかけることなく、購入後すぐに IT 製品を安全に利用できること。

  • d. HWの調達基準等にセキュアな調達のための基準を設ける。調達基準や取引基準の中で、調達先又は取引先の法令順守、自組織のセキュリティ基準又は倫理基準などの社内基準の遵守を求める。法令、社内基準、国連制裁等を踏まえたサプライヤーリスト又は制裁対象リストを作成、維持し、これらを踏まえた調達を実施。

2.3.4.2. ログ管理

• 基本的な対応事項
  • ① ログの取得・監視・保存のための手続を策定し、定期的にレビューすること。手続には、例えば、以下の事項を含むこと。
    • ログに記録する内容
    • 対象範囲（監視対象のハードウェア、ソフトウェア、サービス等）
    • ログへのアクセス制御
    • 監視方法
    • ログの改ざん防止
    • 保存期間
    • 保存方法

2.3.4.3. セキュリティ・バイ・デザイン

• 基本的な対応事項
  • ① 金融商品・サービスの企画・設計段階から、セキュリティ要件を組み込む「セキュリティ・バイ・デザイン」を実践すること。サービス全体の流れの中で、重要なサードパーティも含めてリスクを検証し対策を講ずること。
  • ② 自組織にシステムを提供する重要なサードパーティにおいて、セキュリティ・バイ・デザインを実施できる体制となっているかを確認すること。
• 対応が望ましい事項
  • a. セキュリティ・バイ・デザインにかかる管理プロセスを、以下の点も考慮のうえ、整備し運用。
    • セキュアコーディングに係る基準を策定し実施。
    • データの機密性、アクセス管理、イベントログ取得等のセキュリティ要求事項を明確化。
    • セキュリティ技術・アーキテクチャーに係る設計標準を策定。
    • アプリケーションソフトウェアのリリース前及びリリース後定期的に、アプリケーションの脆弱性診断を実施。
    • システムへの脆弱性の混入及び作込みを未然に防止し、早期に検知するツール（ソースコード解析ツール等）を活用。

2.3.4.4. インフラストラクチャ（ネットワーク等）の技術的対策

• 基本的な対応事項
  • ① 不正侵入を防止するため、外部NWと内部NWの接続部分に適切な不正侵入防止策を講ずる。また、外部NWと内部NWとの間のデータ授受に対する不正侵入防止策を講ずる。
  • ② NW機器の設定（FWルール、ポート、プロトコルなど）を定期的及びシステム環境の更新時に点検し、必要に応じて更新すること。FWは必要な通信のみを許可する設定。
  • ③ 情報の機密性や完全性等を保護する観点から、専用線や暗号技術の活用等を通じてNWのセキュリティを確保。
  • ④ 無線 LAN NWへのアクセスは、適切な認証機能及びアクセス制御機能を実装し、不正利用を防止。
  • ⑤ テレワークやベンダーによる保守等においてリモートアクセスの対象とするシステムを制限し、適切に管理すること（セッションタイムアウト、利用者認証や通信内容を含むログの取得・保存・監視など）。また、重要なシステムは多要素認証や暗号化接続を使用。
• 対応が望ましい事項
  • a. DDoS/DoS 攻撃対策、DNS に係るサイバーセキュリティ対策、代替通信経路の制御などによって、組織の通信及びNWサービスの耐性度を強化。
  • b. 開発環境及びテスト環境を本番環境から分離するとともに、不正アクセスや情報資産の不正な変更を防止。
  • c. NWセグメントを細分化し、マルウェアの水平移動を阻止することなどにより、サイバー攻撃の被害拡大防止を図る。

2.3.4.5. クラウドサービス利用時の対策

• 基本的な対応事項
  • ① 利用するクラウドサービスの仕様を確認し、理解を深める。
  • ② 責任共有モデルを理解し、クラウド事業者との責任範囲等を明確に。
  • ③ 情報公開等の設定にミスがないか確認。設定の妥当性の確認においては、必要に応じて、専門家によるシステム監査や誤設定の自動検知等の診断サービス等を利用。
  • ④ 責任分界に応じて、サービス仕様が変わる際には影響を確認。
  • ⑤ 多岐にわたる関係主体等を把握し、情報共有体制・インシデント対応体制を構築。

2.4. サイバー攻撃の検知

• 基本的な対応事項
  • ① アノマリ（異常値）、IoC（侵害の痕跡）などのサイバー攻撃の端緒の検知のための監視・分析・報告に係る手続等を策定し、必要に応じて見直すこと。
  • ② サイバー攻撃に対するリスク低減を図るために、脅威に応じて必要な監視・分析などの対策を講ずる。対策を外部委託している場合には、当該委託先で実施している対策の具体的な内容を把握するとともに、対策の講じられていない領域が判明した場合には、必要な措置をとる。

2.4.1. 監視

• 基本的な対応事項
  サイバー攻撃の端緒を検知するため以下を継続的な監視を実
  • ① HW・SWについて、例えば、以下の監視
    • 未承認のHWや組織内ポリシー違反のHWのNWへの接続。
    • 未承認のSWのインストール。
    • SW、ファームウェアの更新時に当該SW、ファームウェアの改ざん等が行われていないこと。
    • サーバや端末における不審な挙動。
    • SWのパッチ適用状況。
  • ② NWについて、例えば、以下の監視をすること。
    • 組織内NWへの不正侵入（IPSやIDSの利用等による監視）。
    • DDoS 攻撃等によるNWフローやトラフィックの異常値。
    • 不正又は通常と異なるNW接続やデータ転送。
    • 悪意のあるウェブサイト、未承認の SNS サービス、ファイル交換サービス等の接続。
  • ③ 役職員によるシステムへのアクセスについて、例えば、以下の監視をすること。
    • 通常利用とは異なるアクセスパターン等の不審な振る舞い
  • ④ 外部のISPによるシステムへのアクセス（保守作業等）について監視をすること。
  • ⑤ サイバー攻撃の端緒がインシデントに該当するかどうかを分析し、速やかにしかるべき責任者に報告。
  • ⑥ サイバー攻撃の端緒を検知するためのアラート基準や閾値等の妥当性を定期的に検証。
  • ⑦ データセンターやサーバ室への出入や不審な活動を監視。
• 対応が望ましい事項
  • a. おとりアカウントやサーバを用いて、攻撃の初期段階に検知するための仕組みを導入。
  • c. SIEM等のツールを活用して、複数の監視情報（ソーシャルメディア、ダークウェブ等の外部情報を含む）を集約し、情報の相関関係を含めて、リアルタイムにサイバー攻撃の端緒がインシデントに該当するかどうかを分析。

2.5. サイバーインシデント対応及び復旧

2.5. サイバーインシデント対応及び復旧

• 基本的な対応事項
  • ① サイバー攻撃を想定したインシデント対応計画及びコンティンジェンシープランを、サイバー攻撃の種別ごとに策定。その中 で対応の優先順位や目標復旧時間、目標復旧水準を定めておく。左記を定期的あるいは必要に応じて見直しを実施。
• 対応が望ましい事項
  • a. コンティンジェンシープランにおいては、資金清算インフラや決済インフラ等におけるインシデントや、データセンターやクラウド等を含めたサードパーティが提供するサービス等が長期間利用できないようなインシデントなど、大規模な被害が生じるサイバーインシデントに対応するためのコンティンジェンシープランも整備。

2.5.2. インシデントへの対応及び復旧

2.5.2.1. 初動対応（検知・受付、トリアージ）

• 基本的な対応事項
  • ① 2.4 に掲げる事項を含め、各種システムの監視や、顧客等からの問合せ、セキュリティ対応機関など外部組織からの連絡により、インシデントを検知。
  • ③ インシデントは、業務影響等に応じた優先順位付けを行い、あらかじめ定められた基準に従い、インシデント対応組織の管理者や、サイバーセキュリティを統括管理する責任者（CISO 等）、経営陣に報告。

2.5.2.2. 分析

• 基本的な対応事項
  • ① 対応が必要と判断したインシデントについて、攻撃の手口や原因・経路、システムへの影響、現在発生している業務影響及び今後発生しうる業務影響等について分析。特に、分析を行う際は事前にログ等の証跡を保全し、分析は保全したログ等に対して行う。
  • ② インシデントの検知・受付から復旧までのフェーズに関し、記録（インシデントの内容、その対応において取られた行動内容や調査における収集ログの一覧等）を残しておく。

2.5.2.3. 顧客対応、組織内外の連携、広報

• 基本的な対応事項
  • ① インシデント対応計画やコンティンジェンシープラン（復旧計画含む）に基づき、CISO 等の責任者や担当者、各コンティンジェンシープランの関係者が、それぞれの役割、必要な連絡先、必要な対応手順について習熟。
  • ② 情報漏えい等により顧客に二次被害などの影響がある場合は、影響範囲や注意事項、対応方法等を当該顧客に伝達。
  • ③ インシデント発生時は、法令等に従い、規制当局等に速やかに報告。
  • ⑤ 攻撃者の TTP（Tactics（戦術）、Techniques（技術）、Procedures（手順））等、他機関にとっても有効となる攻撃技術情報について、機密情報を除いた上で、必要に応じ、金融ISACやJPCERT/CC等の情報共有機関に共有。

2.5.2.4. 封じ込め

• 基本的な対応事項
  • ① サイバー攻撃による被害拡大を防止するための対応を行うにあたり、事前に以下の点を考慮。
    • 被害の拡大防止のために通信の遮断やシステム停止等を行うに当たっては、事前に対応の実施を判断する権限者を明確にしておく。また、判断する際の検討要素として、停止する時間帯や期間、停止するサービスの範囲に応じた業務影響、業務の代替手段や通信経路等を整理しておく。
  • ② 封じ込めに当たって、情報漏えいによる再発及び二次的被害の可能性が危惧される場合、発生を防ぐための対策を実施。その際には、以下の点を考慮。
    • 通信の遮断やシステム停止等を行う場合、封じ込めと証拠保全のいずれを優先すべきか、状況や自組織の方針に従い判断。
    • 必要に応じて、外部専門家を活用して封じ込めを実施。

2.5.2.5. 根絶

• 基本的な対応事項
  • ① サイバー攻撃により被害が発生した原因を除去（マルウェアの駆除、パッチの適用等による脆弱性の修正等）。その際、以下の点を考慮。
    • セキュリティを高めるための対策（NWの監視レベルの引上げ、FWやセキュリティ装置の設置及びアクセス制御の適切な実施等）を検討。
    • 必要に応じて、外部専門家を活用して根絶を実施。

2.5.2.6. 復旧

• 基本的な対応事項
  • ① 復旧計画において、復旧完了し業務再開を判断する際には、判断権限者を明確にしておくとともに、判断要素を整理しておく。被害を受けた原因を特定しないまま復旧を行うことにより、再度同様の攻撃を受け、被害が発生することが想定されるため、業務再開の判断要素には、原因への対応がなされたことの確認を含める。
  • ② 復旧作業においては、被害を受けた機器の初期化、システム再構築等を行い、システムを通常の運用状態に戻して正常稼働を確認。
  • ③ BKUPからの復旧の際には、攻撃の手法に応じて、既にBKUデータ等が改ざんされている可能性や、マルウェア等に感染している可能性に留意。清算・振替機関等においては、BKUPからの復旧の際に、例えば、参加者等が指図したものの未達のものがある場合等には、当該指図の再送信を参加者等に求める。
  • ④ 被害を受けたシステムと他システムを再接続する前に、システムの正常な稼働や接続がなされていることを確認。
  • ⑥ 復旧後、インシデントの発生原因や被害の拡大に関する原因等を分析し、対応の評価を行う。また、当該評価を基に、インシデント対応計画やコンティンジェンシープランを含むサイバーセキュリティ管理態勢の見直しや改善を行う。

2.6. サードパーティリスク管理

• 基本的な対応事項
  • ① サイバーセキュリティに係る戦略、取組計画を策定する際にはサプライチェーン全体を考慮。また、サードパーティを含む業務プロセス全体を対象としたサイバーセキュリティ管理態勢を整備。
  • ② サードパーティのリスク管理のライフサイクル全体を通じ、サードパーティに起因するサイバーセキュリティリスクを管理するために必要な態勢を整備し、サードパーティリスク管理の方針を策定。
  • ⑤ サードパーティの管理台帳等を整備し維持（管理項目の例：名称、提供する商品・サービス及び機能、サードパーティが自組織のシステムに対し有するアクセスレベル、サードパーティが保持又は処理する自組織のデータの種類や機密性及び場所）。
  • ⑧ サードパーティが遵守すべきサイバーセキュリティ要件を明確化の上、重要度に応じ、サードパーティ等との契約や SLA（サービスレベルアグリーメント）等において、例えば、以下の項目を明記すること。
    • サードパーティとの役割分担・責任分界
    • 監査権限
    • 再委託手続
    • 実施すべきセキュリティ対策
    • サードパーティの役職員が遵守すべきルール
    • インシデント発生時の対応及び報告
    • 脆弱性診断等の実施及び報告
    • 深刻な脆弱性が判明した場合の対応及び報告
    • サイバーセキュリティに係る演習・訓練の実施（共同演習・訓練への参加を含む）
    • データの所在・保管・保持・移転・廃棄に関する取決め
    • 契約終了の条件及び契約終了時の取決め
    • 外部評価等の実施（第三者保証報告書の提出、第三者認証の取得を含む）
  • ⑩ サードパーティとの取引終了時の管理プロセス（データ廃棄、組織内システムへのアクセス遮断措置など）を整備。

3. 金融庁と関係機関の連携強化

3.1. 情報共有・情報分析の強化

金融庁は、サイバーセキュリティの司令塔である内閣サイバーセキュリティセンター（NISC）、日本銀行、金融ISAC、金融情報システムセンター（FISC）及び各 CEPTOAR等との連携を維持、強化する。

3.2. 捜査当局等との連携

3.3. 国際連携の深化

3.4. 官民連携

参考リンク

• (金融庁)金融分野におけるサイバーセキュリティに関するガイドライン
• (デジタル庁)政府情報システムにおけるセキュリティ・バイ・デザインガイドライン
• 金融分野でも求められる「セキュリティ・バイ・デザイン」｜脆弱性を減らす開発の進め方とは？
• 金融庁サイバーセキュリティガイドラインの要点は？～175項目はどのような項目か？