犯罪者の手口から逆算する企業防御――AI時代のサイバー攻撃を、どこで止めるのか

Posted at 2026-11-11

はじめに

セキュリティ対策を検討すると、EDR、DLP、ゼロトラスト、多要素認証、SIEMといった技術や製品の話になりがちです。どれも重要なものですが、そもそも何を防ぐために導入するのかが曖昧なままでは、対策が十分に機能しない可能性があります。

例えば、多要素認証を導入していても、ITヘルプデスクが騙されて認証設定を変更してしまえば、不正ログインを許すかもしれません。メールセキュリティを強化していても、正規の取引先アカウントから届いた偽の振込依頼を信じてしまえば、送金被害が発生する可能性があります。

技術的には正常な操作であっても、それを実行させた人物が犯罪者であれば、結果は不正なものになります。

ここに、企業のセキュリティ対策における難しさがあると考えます。

IPAが2026年1月に公表した「情報セキュリティ10大脅威2026」では、組織向けの1位がランサム攻撃、2位がサプライチェーンや委託先を狙った攻撃となり、AIの利用をめぐるサイバーリスクも初めて選出され3位にランクインしました。¹

正規の認証手続きやSaaS連携を悪用する攻撃、さらには企業のAI基盤を乗っ取って計算資源を不正利用する犯罪も報告されています。

そこで本稿では、実際に確認された犯罪手法を例に、攻撃の成立条件を分析し、その条件をどこでガードすれば企業を守れるのかを考えます。

目的は、セキュリティ製品の一覧を作ることではありません。企業の業務やシステムの中に存在する攻撃の成立条件を見つけ、具体的な対策と検証方法まで落とし込むことです。

1. セキュリティ対策は、攻撃の成立条件から考える

1-1. 攻撃者が狙うのは、必ずしもシステムの脆弱性ではない

サイバー攻撃というと、ソフトウェアの脆弱性を悪用して侵入するイメージが強いかもしれません。

もちろん、脆弱性を利用する攻撃は現在も重要な脅威です。しかし、攻撃者にとっては、必ずしも難しい技術を使う必要はありません。

正規の利用者を騙して操作させることができれば、システムの脆弱性を悪用しなくても目的を達成できる場合があります。

例えば、企業の経理担当者に偽の振込依頼を送る場合、攻撃者が必要とするのは銀行システムへの侵入ではありません。経理担当者を信用させ、正規の振込操作を実行させることです。

この場合、振込処理を実行したシステムは正常に動作しています。

システムが正常であっても、業務上の判断が攻撃に利用されれば、被害は成立するわけです。

1-2. 攻撃を成立させる条件を分解する

企業への攻撃を防ぐには、攻撃者が最終的に何を達成しようとしているのか、そのためにどのような条件が必要なのかを分解して考える方法が有効です。

例えば、認証情報を盗み出してSaaSから情報を持ち出す攻撃であれば、次のような流れが考えられます。

攻撃者が対象企業を選定
          ↓
従業員や取引先の情報を収集
          ↓
認証情報やアクセス権を取得
          ↓
企業のSaaS環境へアクセス
          ↓
権限を利用してデータを取得
          ↓
外部への持ち出し・恐喝など

※一般的な攻撃経路を簡略化した概念図です。すべての攻撃がこの順序や工程を経るわけではありません。

この攻撃を防ぐために、侵入経路の保護だけを強化するのでは不十分です。

仮に認証情報を盗まれてもログインできなければ、攻撃を止められます。ログインを許したとしても、権限が限定されていれば取得できる情報を減らせます。さらに、不審な大量取得を検知できれば、持ち出しの途中で対処できる可能性があります。

つまり、攻撃が成立するために必要な条件を複数の場所でガードすることが、防御の基本になります。

この考え方は多層防御とも整合します。ただし、防御層を増やすこと自体が目的ではありません。それぞれの防御が、どの攻撃条件に対して機能するのかを明確にすることが重要です。

2. 人間を騙す犯罪――メールと電話をどう防ぐのか

2-1. ビジネスメール詐欺：正規の振込操作を悪用する

ビジネスメール詐欺（BEC：Business Email Compromise）は、取引先や経営者などを装い、企業の担当者を騙して不正な送金を実行させる犯罪です。

IPAは、実際に確認された事例として、取引先担当者になりすました攻撃者が偽の振込先口座への変更を依頼する手口や、銀行口座証明書類を偽造する手口などを紹介しています。²

さらに、2026年3月には、社長などを装ったメールによって従業員をLINEグループへ誘導し、送金させようとする犯罪への注意喚起も公表しています。³

ここで、仮想的な企業の経理処理を考えてみます。

取引先から請求書が届き、振込先が変更されたと記載されています。送信者名は普段の担当者と同じで、請求金額や取引内容にも不自然な点はありません。経理担当者は社内の承認を得て、記載された口座へ送金します。

しかし、その振込先が攻撃者の口座だったらどうでしょうか。

この犯罪では、マルウェアやシステムの脆弱性が利用されていない可能性があります。

攻撃の成立条件は、偽の振込先が正規の取引先情報として承認されることです。

防御策：振込先変更を、メールだけで完結させない

重要なのは、メールの内容が自然かどうかを担当者が判断することではありません。振込先を変更する際に、独立した確認経路を用意することです。

例えば、次のような運用が考えられます。

取引先の振込先口座の変更は、通常の支払承認とは別の手続きにする
変更依頼を受けた場合、事前に登録された連絡先へ確認する
依頼メールに記載された電話番号や連絡先を、そのまま確認先として使わない
振込先マスターの変更履歴と承認者を記録する
重要な振込先変更は、複数の担当者による確認を必要とする

ここで注意したいのは、二重承認だけでは必ずしも安全にならないことです。

二人の承認者が同じ偽の請求書を見て承認しただけであれば、確認の独立性がありません。

必要なのは承認する人数を増やすことではなく、攻撃者が用意した情報とは独立した経路で、変更の正当性を確認することです。

技術的には、メールの認証や監視を強化することも有効です。ただし、正規の取引先アカウント自体が乗っ取られている場合には、送信元を検証できても内容が正当であるとは限りません。

そのため、メールセキュリティと業務手続きを組み合わせる必要があります。

2-2. ヘルプデスク詐欺：多要素認証を正規の手続きで突破する

次は、認証システムを狙う犯罪です。

2026年1月、Google Threat Intelligence Group（GTIG）は、攻撃者が企業のIT担当者を装い、従業員へ電話をかけて認証情報を取得し、不正な端末を多要素認証へ登録する手口を報告しました。⁴

これはビッシング（Vishing：ボイスフィッシング）と呼ばれる、電話を利用したフィッシングの一種です。

この事例の重要な点は、認証システムそのものの脆弱性を悪用したわけではないことです。

例えば、企業が多要素認証を導入していても、ヘルプデスクが電話で認証要素の再登録を受け付けている場合、その手続きが攻撃対象になります。

従業員本人を装う攻撃者がヘルプデスクに連絡し、スマートフォンの紛失を理由に認証方式の再登録を依頼するといった状況が考えられます。

ここで、氏名、社員番号、部署名、上司の氏名などを回答できたとしても、本人であることの証明にはなりません。これらの情報は過去の漏洩情報や公開情報から取得されている可能性があるためです。

防御策：認証手段の強度だけでなく、再設定手続きも保護する

企業がフィッシング耐性の高い認証方式を導入していても、その登録や再設定の手続きが弱ければ、全体としての防御は弱くなります。

この場合は、次の対策が考えられます。

多要素認証の再登録や認証要素の追加を高リスク操作として扱う
社員番号や個人情報の照合だけで再設定を許可しない
事前に登録された連絡先や承認経路で本人確認を行う
特権アカウントの認証再設定には、通常より厳格な手続きを適用する
新しい認証要素の登録、端末追加、不審なログインを監視する

加えて、FIDO2セキュリティキーやパスキーなど、フィッシング耐性を持つ認証方式の利用も重要です。

ただし、パスキーを導入すれば、ヘルプデスクへのなりすましを含むすべての攻撃が防げるわけではありません。

Googleの調査では、ヘルプデスクの本人確認や認証設定変更の手続きを強化することも推奨されています。⁵

そして、不正な認証要素の登録が疑われる場合には、パスワードの変更だけでなく、既存セッションの失効、不審な認証要素の削除、連携アプリへの認可の確認などが必要になります。

認証の強度は、ログイン時だけでなく、登録・変更・復旧を含む運用全体で評価する必要があるということです。

3. 正規のクラウド機能を悪用する犯罪――SaaSとデータをどう守るのか

3-1. OAuthトークンの悪用：正規の連携が侵入口になる

クラウドサービスの利用が進むにつれて、企業は複数のSaaSを連携させるようになりました。

例えば、顧客管理システムと営業支援ツール、メールシステムと外部アプリケーションなどを接続する構成です。

この際、OAuthという仕組みを利用して、アプリケーション間のアクセス権を付与することがあります。

OAuthは、パスワードを外部アプリケーションへ直接渡さず、許可された範囲のアクセス権を委任するための仕組みです。

しかし、そのアクセス権を表すトークンが盗まれた場合、攻撃者が正規の連携アプリケーションと同じ権限でデータへアクセスできる可能性があります。

2025年8月、GTIGはSalesloft DriftのOAuthトークンを悪用し、複数企業のSalesforce環境から大量のデータを取得した攻撃を報告しています。⁶

この事例では、Salesforce本体の脆弱性ではなく、外部アプリケーションとの連携に使われていたトークンが悪用されました。

つまり、企業自身の認証基盤を守っていても、連携先の認証情報が侵害されることで、自社のデータが持ち出される可能性があります。

防御策：連携アプリケーションの権限と有効性を管理する

この攻撃を防ぐには、ユーザーアカウントだけでなく、アプリケーションに付与した権限を管理する必要があります。

具体的には、次のような対策が考えられます。

SaaS連携アプリケーションの一覧と管理責任者を把握する
OAuthの許可範囲（スコープ）を必要最小限にする
不要になったアプリケーションの認可を取り消す
トークンの漏洩が判明した際に、速やかに失効させられるようにする
連携アプリケーションによる大量データ取得や異常なAPI利用を監視する

例えば、顧客情報の一部を参照するだけのアプリケーションに、すべての顧客情報を読み書きできる権限を付与する必要はありません。

また、SaaS間の通信は正規のAPIを利用して行われるため、ネットワーク上の通信だけを見ても不正だと判断できない場合があります。

そのため、どのアプリケーションが、どのデータに、どのような権限でアクセスしたのかを把握することが重要です。

これは、サプライチェーンのセキュリティ対策とも関係します。

外部サービスを利用するということは、単に業務を委託することではありません。場合によっては、自社データへのアクセス権の一部を外部サービスへ委ねることにもなるからです。

3-2. ランサムウェア：バックアップだけでは防げない

ランサムウェアへの対策として、バックアップを取得することは重要です。

しかし、近年のランサムウェア攻撃では、データを暗号化するだけでなく、あらかじめ情報を持ち出し、その情報を公開すると脅迫する手口も見られます。

IPAが2026年9月に公開した「ランサムウェア被害から学ぶ教訓集」でも、データの暗号化と情報の持ち出しを組み合わせた二重の脅迫が取り上げられています。⁷

ここで、企業が完全なバックアップを保有している場合を考えてみます。

攻撃者によってファイルが暗号化されても、バックアップから復旧できれば、業務停止による被害を抑えられる可能性があります。

しかし、攻撃者が顧客情報や機密情報を既に持ち出していた場合、バックアップから復旧しても、漏洩した情報を取り戻すことはできません。

つまり、バックアップは業務復旧のために重要ですが、情報漏洩そのものを防ぐ対策ではないということです。

防御策：業務復旧と情報流出防止を分けて考える

ランサムウェア対策は、侵入防止、内部での権限拡大防止、情報流出の検知、復旧という複数の観点で設計する必要があります。

防御段階	主な対策	防ぎたいこと
侵入	脆弱性管理、MFA、端末保護	攻撃者の初期侵入
権限拡大	特権ID管理、ネットワーク分離	侵害範囲の拡大
データ取得	最小権限、アクセス監査	不要な情報へのアクセス
情報持ち出し	DLP、転送量・アクセス異常の監視	大量データの外部流出
業務復旧	隔離されたバックアップ、復旧訓練	データや業務の復旧不能

さらに、バックアップ自体が攻撃対象となる可能性もあります。

そのため、本番環境とは独立した認証や管理権限、変更・削除に対する保護、定期的な復旧テストなどが必要です。

ここでは、すべての対策を一つのセキュリティ製品で実現しようとする必要はありません。それぞれの防御が異なる攻撃段階を担当し、一つが突破された場合でも次の防御が機能するように設計することが重要です。

また、侵害が発覚した場合にシステムを停止するのか、どこまで業務を継続するのか、どの時点で経営判断を求めるのかといった対応も、事前に決めておく必要があります。

4. AI時代の新たな犯罪――企業のAI基盤そのものが狙われる

4-1. LLMJacking：AIを不正利用され、企業が費用を負担する

AIの悪用というと、フィッシングメールの生成や、攻撃プログラムの開発などを想像するかもしれません。

しかし、企業が利用するAIそのものが犯罪の対象になることもあります。

2026年11月5日、Google Threat Intelligence GroupとMandiantは、企業の大規模言語モデル（LLM）へのアクセス権を乗っ取る「LLMJacking」について、日本語の調査記事を公開しました。⁸

LLMJackingとは、攻撃者が企業のLLM APIやクラウド上のAIリソースを不正利用し、その計算資源を消費したり、第三者へ不正に転売したりする手口です。

同調査では、2026年に対応した個別のインシデントの中で、不正利用によるリソース消費額が1日で10万米ドルを超えた例や、アクセスを取り消すまでに累積請求額が100万米ドルに達した例が報告されています。

ここで注意したいのは、これは調査対象となった個別事例の数字であり、一般的な被害額を示しているわけではないということです。

攻撃者は、漏洩したAPIキー、クラウドの認証情報、不適切に公開されたエンドポイントなどを悪用して、企業のAI基盤へアクセスしていました。

例えば、業務アプリケーションに組み込まれた生成AIのAPIキーが漏洩し、攻撃者がそのキーを使って大量の推論処理を実行した場合、正規の契約者である企業に利用料金が発生する可能性があります。

この攻撃では、個人情報が盗まれなくても、企業に直接的な金銭被害が発生し得ます。

4-2. 防御策：APIキー、権限、利用量を管理する

企業がAI基盤を保護する際には、従来の認証情報管理に加えて、API利用量やサービスの有効化状況を監視する必要があります。

具体的には、次のような対策が考えられます。

APIキーやクラウド認証情報をソースコードに直接記載しない
シークレット管理サービスを利用し、認証情報を一元管理する
APIキーごとにアクセス可能なサービスやリソースを制限する
AIサービスの新規有効化や権限変更を監視する
通常の利用量から大きく外れたAPI呼び出しを検知する
利用量のクォータと予算アラートを設定する
不正利用を確認した際に、認証情報を失効し、アクセスを停止する手順を用意する

ただし、予算アラートが必ずしも利用を自動停止するわけではありません。また、サービスごとのクォータが実際の課金上限として機能するかも、契約や実装によって異なります。

アラートを設定しただけで安心せず、実際に利用を制限できるか、誰が停止判断を行うのかまで確認することが重要です。

さらに、AIアプリケーションが外部のプログラムやデータベース、業務システムを操作できる場合には、その実行権限も管理する必要があります。

AIが高性能になるほど、正規の権限を利用して処理できる範囲も広がります。その分、認証情報や実行権限が悪用された場合の影響も大きくなる可能性があります。

AIを導入する企業は、AIを利用して何ができるかだけでなく、そのAIや周辺システムが乗っ取られた場合に、何を実行できてしまうのかまで把握する必要があるでしょう。

5. 企業防御を実装する――何から始め、どう検証するのか

ここまで取り上げた犯罪は、手口も目的も異なります。

しかし、防御の観点から見ると、共通している部分があります。

攻撃者は、企業が正当なものとして許可している認証、権限、操作、業務手続きを悪用しようとしているという点です。

したがって、単に不正な通信やマルウェアを検知するだけでなく、正規の操作が不正な目的に使われる場合まで想定する必要があります。

5-1. まずは自社で成立し得る犯罪を洗い出す

すべての企業が同じ対策を、同じ優先順位で導入する必要はありません。

例えば、海外送金が多い企業であれば、ビジネスメール詐欺に対する振込先変更の確認が重要になるでしょう。SaaSを多数利用している企業であれば、OAuthトークンや外部アプリケーションの権限管理が重要になります。

自社で運用するAIサービスのAPIキーが多い場合には、その利用権限や利用量の監視も検討すべきです。

そこで、最初に作成するものとして、次のような一覧を提案します。

犯罪手法	自社で成立する条件	担当部門	最初に確認すること
ビジネスメール詐欺	偽の振込先変更が承認される	経理・財務	変更時の別経路確認の有無
ヘルプデスク詐欺	本人以外が認証を再設定できる	IT・ID管理	MFA再登録時の本人確認手順
SaaS連携の悪用	過剰な権限を持つトークンが利用される	IT・SaaS管理	連携アプリと権限の一覧
ランサムウェア	侵入後に権限拡大や情報持ち出しが可能	インフラ・SOC	特権ID、ログ、バックアップの状態
LLMJacking	AI基盤やAPIキーを不正利用できる	クラウド・AI担当	APIキー管理と利用量制限

この一覧で重要なのは、脅威を列挙するだけで終わらせないことです。

自社の業務やシステムを確認し、攻撃の成立条件が実際に存在しているかを調べる必要があります。

5-2. 90日間の実行計画を立てる

既存の環境が大きく異なる企業に、同一の実施計画を適用することはできませんが、初期の取り組みとしては次のような段階的な進め方が考えられます。

期間の目安	主な活動	完了を判断する成果物
1〜30日	重要業務と高リスク操作の洗い出し、現行対策の確認	攻撃成立条件の一覧、未対策箇所の整理
31〜60日	認証再設定、振込先変更、SaaS連携などの統制強化	改訂された運用手順、設定変更の記録
61〜90日	想定シナリオに基づく対応訓練、検知と復旧の検証	訓練結果、未解決課題、改善計画

※90日という期間は実行計画の例です。組織の規模、システム構成、契約上の制約、既存の統制によって必要な期間は変わります。

この計画では、新たなセキュリティ製品を購入することを前提としていません。

既存の認証基盤やSaaSの管理機能、監査ログ、業務承認手続きなどを確認し、現在の仕組みで実現できる対策から着手する方法が考えられます。

また、システム担当者だけで判断できない対策も存在します。

振込先変更の手続きは経理部門、認証の再登録は人事情報やヘルプデスク、取引先への確認は営業部門など、関係する部門の協力が必要です。

経済産業省の「サイバーセキュリティ経営ガイドライン Ver.3.0」でも、経営者がリスクを認識し、体制の構築、予算や人材の確保、緊急対応や事業継続の整備などに関与することが求められています。⁹

つまり、企業防御はIT部門だけで完結する活動ではありません。

5-3. 対策を導入したら、実際に止められるか確認する

セキュリティ対策は、導入したという事実だけでは有効性を評価できません。

例えば、次のような検証が考えられます。

検証例1：偽の振込先変更依頼

取引先から振込先変更の依頼が届いたという模擬ケースを用意し、実際の社内手続きでどのように確認されるかを検証します。担当者が内容を信じたとしても、独立した連絡先への確認が行われ、未確認の口座変更が承認されないかを評価します。

検証例2：認証要素の再登録

従業員がスマートフォンを紛失したという模擬ケースで、ヘルプデスクの再登録手続きを検証します。本人情報を知っているだけの第三者では再登録を完了できないか、例外的な手続きを誰が承認するのかを確認します。

検証例3：SaaS連携の権限変更

検証環境で連携アプリケーションへ不要な権限が付与されていないかを確認し、トークンを失効させた場合にアクセスが確実に遮断されるかを試します。また、想定外のデータ取得を監査ログから発見できるかも評価します。

検証例4：ランサムウェアによる業務停止

重要システムが利用できなくなったという想定で、バックアップからの復旧だけでなく、代替業務、連絡体制、情報流出が疑われる場合の対応まで検証します。復旧手順が存在するだけでなく、実際に実行できることを確認します。

検証例5：AI APIの不正利用

実際の不正課金を発生させず、検証環境や模擬ログを使って、異常なAPI利用を検知できるかを試します。さらに、予算アラートが届いた際に、誰が調査・停止するのかを確認します。

これらの検証は、必ず事前に許可された範囲で実施し、本番環境や実際の取引に影響を与えない方法を選ぶ必要があります。

5-4. 評価すべきなのは、導入率だけではない

例えば、多要素認証の導入率が100%だったとしても、再登録の手続きが容易に悪用されるのであれば、認証基盤全体が安全だとは言えません。

また、監視ツールを導入していても、検知した異常に対応する担当者が決まっていなければ、実際の被害を止められない可能性があります。

そのため、次のような観点で効果を評価することを提案します。

評価項目	確認したい状態
攻撃阻止	不正な依頼や操作を、定めた制御で拒否できる
検知	模擬的な不審操作を監査ログや通知から発見できる
対応	検知後に担当者が判断し、必要な停止措置を実行できる
復旧	想定した被害から必要な業務を再開できる
継続改善	訓練で見つかった課題が是正され、再検証される

これらは実務上の評価項目の提案であり、特定の規格における認証基準ではありません。

NISTが2025年4月に公開した「SP 800-61 Rev.3」でも、インシデント対応を独立した活動として扱うのではなく、組織全体のサイバーセキュリティリスク管理へ組み込む考え方が示されています。¹⁰

したがって、セキュリティ対策の有効性を評価するには、製品の設定だけでなく、業務手順、検知、判断、復旧まで一連の流れとして確認する必要があります。

おわりに

ここまで、企業を狙う実際の犯罪手法を例に、防御策を考えてきました。

ビジネスメール詐欺では、正規の振込操作が犯罪に利用されます。ヘルプデスク詐欺では、正規の認証再設定手続きが悪用されます。SaaS連携では、正規のアクセス権を持つトークンが攻撃に利用される可能性があります。

さらに、ランサムウェアでは情報の暗号化だけでなく持ち出しが問題となり、LLMJackingでは企業が契約するAIの計算資源そのものが犯罪の対象になります。

それぞれ手口は異なりますが、共通することがあります。

攻撃者は、企業が正規のものとして認めている機能や手続きを利用して、犯罪を成立させようとしているという点です。

これに対抗するためには、単に新しいセキュリティ製品を導入するだけでは十分とは限りません。

どの業務が悪用され得るのか、どの権限が奪われると何ができてしまうのか、どの操作が実行された時点で被害が成立するのかを把握する必要があります。

そして、その条件を崩すために、技術的な制御と業務上の確認手続きを組み合わせることが重要になります。

AIの進化によって、攻撃の速度や規模、個別対応力が高まる可能性があります。しかし、防御側がすべての新しい攻撃手法を予測し、個別に対応することには限界があります。

だからこそ、犯罪の表面的な手口だけでなく、その攻撃が成立するために必要な条件へ目を向けるべきではないでしょうか。

まずは自社の重要業務を一つ選び、犯罪者がその業務を悪用するとしたら、何を知り、どの権限を取得し、誰に何を実行させる必要があるのかを整理してみることをおすすめします。

その条件を一つずつ検証し、必要な対策を実装することが、現実的なセキュリティ強化の第一歩になると考えます。

参考

IPA：情報セキュリティ10大脅威2026 — 2025年の社会的影響の大きかった脅威をもとに選定された2026年の組織向け脅威 ↩
IPA：ビジネスメール詐欺の事例集を見る — 偽の振込先変更、口座証明書類の偽造などの国内事例 ↩
IPA：社長等をかたる詐欺メールに注意！（2026年3月12日） — 経営者へのなりすましによる送金詐欺の事例と対策 ↩
Google Threat Intelligence Group：Vishing for Access（2026年1月30日） — 電話による認証情報の窃取、MFA登録の悪用、SaaS侵入の調査 ↩
Mandiant：Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS（2026年1月） — ヘルプデスクの本人確認、認証情報やセッションの管理、検知に関する防御指針 ↩
Google Threat Intelligence Group：Widespread Data Theft Targets Salesforce Instances via Salesloft Drift（2025年8月） — OAuthトークンを悪用したSaaS経由のデータ窃取事例 ↩
IPA：ランサムウェア被害から学ぶ教訓集（2026年9月公開） — 国内の被害組織へのインタビューをもとにした対策と経営判断の教訓 ↩
Google Threat Intelligence Group：LLMJackingの台頭（2026年11月5日） — AI APIやクラウド認証情報を悪用した計算資源の不正利用と防御策 ↩
経済産業省：サイバーセキュリティ経営ガイドラインと支援ツール — 経営者によるリスク認識、体制構築、予算配分、インシデント対応の指針 ↩
NIST：SP 800-61 Rev.3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management（2025年4月） — インシデント対応を組織全体のリスク管理に組み込むためのガイドライン ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up