セキュリティインシデント せきゅりてぃいんしでんと
簡単に言うとこんな感じ!
会社のシステムや情報に「何かまずいことが起きた!」という出来事のことだよ。ウイルス感染・不正アクセス・情報漏洩など、セキュリティ上の脅威が現実になった瞬間から「インシデント」って呼ぶんだ!
セキュリティインシデントとは
セキュリティインシデントとは、組織の情報システムや情報資産に対して、機密性・完全性・可用性(いわゆるCIA三要素)のいずれかが損なわれた、または損なわれる恐れが生じた出来事のことです。具体的には、ウイルス・マルウェアへの感染、不正アクセス、情報漏洩、サービス妨害攻撃(DoS/DDoS)、内部不正などが代表例として挙げられます。
「インシデント(incident)」とは英語で「出来事・事件」を意味し、IT文脈では「通常の運用を逸脱した問題のある出来事」全般を指します。その中でもセキュリティ上の脅威に関するものをセキュリティインシデントと呼びます。発注・調達の立場でも「インシデント発生時の対応体制や報告ルートをベンダーと事前に取り決めておく」ことが非常に重要です。
インシデントが発生した場合、放置すれば被害が拡大し、法的責任や社会的信用の損失につながります。そのため「インシデントレスポンス(対応手順)」をあらかじめ整備しておくことが、現代の企業運営において欠かせない要件となっています。
インシデントの種類と深刻度
代表的なセキュリティインシデントを種類・影響度別に整理すると以下のとおりです。
| 種類 | 具体例 | 主な影響 |
|---|---|---|
| マルウェア感染 | ランサムウェア・ウイルス・スパイウェア | データ破壊・暗号化・情報窃取 |
| 不正アクセス | アカウント乗っ取り・SQLインジェクション | 情報漏洩・改ざん |
| 情報漏洩 | 個人情報・機密情報の外部流出 | 法的制裁・信用失墜 |
| DoS/DDoS攻撃 | サービス妨害・過負荷攻撃 | サービス停止・機会損失 |
| 内部不正 | 従業員による持ち出し・改ざん | 機密情報漏洩・業務妨害 |
| フィッシング | 偽メール・偽サイトへの誘導 | 認証情報・金銭の詐取 |
| 設定ミス | クラウドストレージの公開設定ミス | 情報漏洩 |
深刻度(重大度)レベルの考え方
インシデントはすべてが同じ重さではありません。対応の優先順位をつけるために深刻度レベルを設定するのが一般的です。
レベル1(Critical): 事業継続に直結する重大被害
レベル2(High) : 広範囲への影響・個人情報漏洩の疑い
レベル3(Medium) : 限定的な影響・業務の一部停止
レベル4(Low) : 軽微な影響・予防的対処で済む
「イベント」と「インシデント」の違い
| 用語 | 意味 | 例 |
|---|---|---|
| セキュリティイベント | 観察された何らかの事象(すべて) | ログイン試行、ファイルアクセスなど |
| セキュリティインシデント | イベントの中で実際に被害や影響が出たもの | 不正ログイン成功、データ持ち出しなど |
「イベント」はすべての事象を指し、その中で「問題あり」と判断されたものが「インシデント」になります。
歴史と背景
- 1988年 — 世界初の大規模マルウェア「モリスワーム」がインターネット上に拡散。セキュリティインシデントという概念の原点となる
- 1988年 — 米国でCERT/CC(コンピュータ緊急対応チーム)が設立。インシデント対応の組織的枠組みが生まれる
- 1990年代 — インターネット商用化とともにウイルス・不正アクセスが急増。企業がセキュリティ対策を意識し始める
- 2000年代 — SQL Slammer(2003年)やコンフィッカー(2008年)など大規模インシデントが世界規模で発生
- 2010年代 — ランサムウェアの台頭(WannaCry 2017年など)。標的型攻撃・APT(高度持続的脅威)が企業の主要リスクに
- 2015年〜 — 個人情報保護法・GDPRなど法規制が整備され、インシデント発生時の報告義務が法的要件となる
- 2020年代 — クラウド移行・テレワーク普及に伴い攻撃対象が拡大。サプライチェーン攻撃も増加
インシデント対応プロセスとCSIRT
セキュリティインシデントへの対応は、あらかじめ定めたインシデントレスポンスプロセスに沿って進めることが重要です。国際的には NIST SP 800-61 が広く参照されるフレームワークで、以下の4フェーズで構成されます。
CSIRTとは
CSIRT(シーサート/Computer Security Incident Response Team)とは、セキュリティインシデントへの対応を専門に担うチームのことです。社内に設置する「内部CSIRT」と、外部機関として機能する「外部CSIRT」があります。
| 役割 | 内容 |
|---|---|
| インシデント受付・トリアージ | 報告を受け、深刻度を判定 |
| 技術的対応 | 封じ込め・調査・証拠保全 |
| 関係部署への連絡調整 | 経営層・法務・広報・IT部門との連携 |
| 外部機関への報告 | 監督官庁・警察・JPCERTへの報告 |
| 再発防止 | 原因分析と対策立案 |
発注側が知っておくべきポイント
ベンダーやSIerにシステムを発注する際は、以下を契約・仕様書に盛り込むことが重要です。
✅ インシデント発生時の報告タイミング(何時間以内に連絡するか)
✅ 対応窓口・エスカレーションルートの明確化
✅ 証拠保全・ログ保管の期間と方法
✅ 再発防止報告書の提出義務
✅ 損害賠償・SLAとの連動
関連する規格・RFC
| 規格・番号 | 内容 |
|---|---|
| RFC 2350 | CSIRTの組織・運用に関する期待値と定義を規定 |
| RFC 7970 | インシデント情報の交換フォーマット IODEF(Incident Object Description Exchange Format)v2 |
| NIST SP 800-61 Rev.2 | コンピュータセキュリティインシデント対応ガイド(米国標準技術研究所) |
| ISO/IEC 27035 | セキュリティインシデント管理の国際規格 |
| 個人情報保護法(改正) | 重大インシデント発生時の個人情報保護委員会への報告義務(日本) |