公開2025.12.08更新2026.10.12 12 人が閲覧（直近 30 日）セキュリティ

CSIRT（シーサート）とは？情報セキュリティ体制での役割18種とSOC・PSIRTとの違い・構築手順

CSIRT（シーサート）は、組織内で起きたセキュリティインシデント（不正アクセスや情報漏えいなどのセキュリティ事故）に対応する専門チームです。情報セキュリティの体制のうち、ポリシーを作る委員会やISMSの運用とは別に、「事故が起きた瞬間に動く役」を受け持ちます。この記事では、JPCERT/CCと日本シーサート協議会（NCA）の定義を出発点に、「CERT」と名乗らない理由、ISMSの管理策との対応、NCAが定める18の役割と少人数での兼任の組み方、SOC・PSIRTとの分担、経営ガイドラインに沿った立ち上げ手順、そして窓口の公開と報告期限の計算をすぐ試せる設定例までを、一次資料で確認しながら整理します。

まとめ：CSIRTの定義・違い・立ち上げの結論

CSIRTは「組織内の情報セキュリティ問題を専門に扱う、インシデント対応チーム」（JPCERT/CC）。読み方は「シーサート」または「シーエスアイアールティー」です。
「CERT」は米カーネギーメロン大学の登録商標のため、一般名詞としては「CSIRT」を使います。
情報セキュリティ体制の中では、委員会やISMS事務局が「平時のルール」を、CSIRTが「事故時の判断と連絡」を持ちます。ISMSでは附属書Aの5.24〜5.28（インシデント管理）がCSIRTの守備範囲に重なります。
守備範囲の違いは、SOCが監視と検知、CSIRTが組織のインシデント対応全体、PSIRTが自社製品の脆弱性対応です。
NCAの「CSIRT人材の定義と確保 Ver.2.1」は18の役割を定め、兼任の組み方を5グループで例示しています。少人数の組織は、この5グループから人を割り当てると設計が早く進みます。
経営層の関与は、経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」の指示7で求められています。個人情報取扱事業者に法定報告義務が生じる漏えい等では、事態を知ってから速報は概ね3〜5日以内、確報は30日以内（不正目的のおそれがある事態は60日以内）が原則です。この期限に間に合う連絡体制を先に作ります。
立ち上げ初日にできる作業は2つあります。外部からの連絡窓口をsecurity.txt（RFC 9116）で公開することと、報告期限を自動で数える仕組みを用意することです。どちらも本文に設定例を載せました。

以下、定義から順に根拠を示します。

CSIRTの定義と読み方：JPCERT/CCとNCAによる表現の違い

JPCERT/CCの「CSIRTマテリアル」は、CSIRTを「組織内の情報セキュリティ問題を専門に扱う、インシデント対応チーム」と定義しています。日本シーサート協議会（NCA）はより広く、「コンピュータセキュリティにかかるインシデントに対処するための組織の総称」と書いています。正式名称はComputer Security Incident Response Teamです。

読み方について、JPCERT/CCは「シーエスアイアールティー」と「シーサート」の両方を示しています。国内の実務では、協議会の名称にも使われている「シーサート」が一般的です。

CSIRTは部署名ではありません。機能を指す呼び名です。専任の部署を置く企業もあれば、情報システム部門・法務・広報の兼務者を集めた仮想組織として運用する企業もあります。NCAの加盟規模は2026年8月時点で655組織・約6,100名です。国際団体のFIRSTは、2026年8月20日の発表で加盟チーム数を868超としています。

情報セキュリティ体制の中のCSIRT：ISMSの管理策と委員会との分担

「情報セキュリティ」と「CSIRT」を並べて調べる人の多くは、すでにある情報セキュリティの体制（情報セキュリティ委員会、ISMS事務局、情報システム部門）と、新しく作るCSIRTがどう違うのかで迷っています。結論から言えば、両者を分けるのは活動の時間軸です。委員会やISMS事務局はポリシーと規程を作り、年単位で見直す「平時の仕組み」を担います。CSIRTは事故が起きたときに、規程に書かれていない判断まで含めて時間単位で動く「有事の機能」です。情報セキュリティの3要素や脅威の全体像は情報セキュリティの3要素・脅威・ISMSの基本の解説で整理しているので、そちらを前提に読むと位置づけがつかみやすくなります。

ISO/IEC 27001:2022附属書Aでインシデント管理を定める管理策

ISMSを運用している組織なら、CSIRTの仕事はすでに管理策として要求されています。ISO/IEC 27001:2022（国内ではJIS Q 27001:2023）の附属書Aでは、インシデント管理に関わる管理策が次のように並んでいます。

管理策	名称（要旨）	CSIRTの担当
5.24	インシデント管理の計画策定と準備	体制・役割・手順書
5.25	事象の評価と決定	トリアージ
5.26	インシデントへの対応	封じ込めと復旧の指示
5.27	インシデントからの学習	事後レビューと再発防止
5.28	証拠の収集	ログと端末の保全
6.8	情報セキュリティ事象の報告	従業員からの報告窓口

ISMSの審査では、これらの管理策について「手順書がある」だけでなく、訓練や実際の対応の記録も必要です。CSIRTの対応記録をそのままISMSの証跡にできるよう、記録の様式を最初から合わせておくと二重管理を避けられます。93項目の管理策全体と選び方はISMSの管理策（附属書Aの93項目）の解説にまとめています。

情報セキュリティ委員会とCSIRTの線引き：事故時の判断権限の分担

委員会とCSIRTを同じメンバーで構成する中小企業は少なくありません。それ自体は問題ありませんが、会議体としての委員会は招集に日数がかかり、夜間や休日には開けません。そのため、インシデント時に「誰の判断でシステムを止めてよいか」を委員会の決議事項にしてしまうと、初動が止まります。委員会では、CSIRTに委ねる判断の範囲（停止・遮断・公表の可否の権限）を事前に決め、事故の最中はCSIRTがその範囲内で動く、という分担にしてください。

CERTとCSIRTの違い：「CERT」が登録商標である事情

CERTとCSIRTの違いは、活動内容の違いではありません。名称の権利の違いです。

起源は1988年です。米カーネギーメロン大学ソフトウェア工学研究所（SEI）の沿革によると、Morrisワームの攻撃を受けてDARPAがSEIに対応チームの設立を求めました。これがCERT/CC（CERT Coordination Center）です。

SEIは現在、「CERT」をカーネギーメロン大学が1997年から保有する登録商標だと明記しています。そのうえで「CERT」を組織の種類を指す一般名詞として使わないよう求め、同種の組織に対して案内している呼称は「computer security incident response teams（CSIRTs）」です。さらに、米国外への「CERT」マークのライセンス供与をやめ、米国外のCSIRTには自国の商標の専門家に相談するよう勧めています。

日本のJPCERT/CCのように名称にCERTを含む組織もありますが、社内チームを新しく作るなら「CSIRT」や「〇〇-SIRT」と名付けるのが無難です。

CSIRTの業務：インシデント対応の流れと法令に基づく報告期限

NIST SP 800-61 Rev.3のDetect・Respond・Recover

インシデント対応の国際的な参照先は、米国立標準技術研究所（NIST）のSP 800-61です。2025年4月3日に最終版が出たRev.3は、2012年のRev.2を全面的に書き直し、文書全体をサイバーセキュリティフレームワーク（CSF）2.0のCommunity Profileとして組み直しました。

Rev.3では、Detect（検知）・Respond（対応）・Recover（復旧）の3つをインシデント対応そのものとして扱います。Govern（統治）・Identify（識別）・Protect（防御）は、対応を支える広いリスク管理活動という位置づけです。CSIRTの業務に置き換えると、次の2つに分かれます。

発生時：検知の受付、影響範囲の特定、封じ込め、復旧の指示、原因究明と記録
平時：脆弱性情報や脅威情報の収集、資産の把握、訓練、従業員教育、手順書の更新

旧版の「準備→検知・分析→封じ込め・根絶・復旧→事後対応」という4段階の図だけで社内規程を作っている場合は、Rev.3の区分に照らして、平時の活動が誰の担当になっているかを見直してください。

法定の報告期限：個人情報の速報3〜5日・確報30日と基幹インフラの報告義務

被害の拡大を防ぐ初動対応と、法令に基づく報告期限の管理は並行して進めます。個人情報保護法の報告対象の事態が起きた場合、施行規則第8条第1項は「速やかに」個人情報保護委員会へ速報するよう求めています。委員会のガイドライン（通則編）は、その目安を事態を知った時点から「概ね3～5日以内」とする記述です。確報は同条第2項により、知った日から30日以内です。不正の目的によるおそれがある事態（規則第7条第3号）は60日以内となります。報告対象の4類型と報告事項は個人情報保護委員会への報告義務の解説で条文に沿って整理しています。

電力・ガス・金融などの基幹インフラ事業者には、もう1つ期限が加わりました。サイバー対処能力強化法（重要電子計算機に対する不正な行為による被害の防止に関する法律、令和7年法律第42号）は、施行期日を定める政令（令和8年政令第46号）により2026年10月1日に施行され、特別社会基盤事業者にサイバー攻撃を認知したときの報告を義務づけています。対象かどうかと報告の期限はサイバー対処能力強化法の届出・報告義務の解説で確認してください。国全体のサイバーセキュリティ政策の枠組みはサイバーセキュリティ基本法の解説で扱っています。

ランサムウェアでは、データが持ち出されたかどうかの調査に時間がかかります。3〜5日の目安に間に合わせるには、法務担当への連絡経路と、判断を下す責任者を事前に決めておく必要があります。IPAの「情報セキュリティ10大脅威2026」組織編では、1位が「ランサム攻撃による被害」でした。警察庁が公表した令和7年のランサムウェア被害の報告件数は226件です。10大脅威の読み方は情報セキュリティ10大脅威2026の解説にまとめています。

CSIRTの役割分担：NCAが定める18の役割と5つの兼任グループ

CSIRTの役割分担を具体化するときに参考になるのが、NCAの「CSIRT人材の定義と確保 Ver.2.1」（2020年12月11日）です。18の役割を定義し、それぞれに任用の前提スキルと追加で教育するスキルを付けています。18人をそろえる前提ではありません。PoCは1つの役割ですが、下表では社外・社内の窓口を分けて表記しています。同文書の4.20節は、兼任できる役割を5つのグループにまとめた例を示しています（本人たちも「一例」としており、自社の事情に合わせて調整するよう注記しています）。

兼任グループ	含まれる役割
1 連絡・全体統括（連絡）	社外・社内PoC、法務助言、通知担当
1 連絡・全体統括（統括）	コマンダー、インベスティゲーター、トリアージ担当
2 SOC	リサーチャー、キュレーター、フォレンジック担当
3 セキュリティ戦略・製品評価	脆弱性診断士、ソリューションアナリスト
4 資産管理・教育	セルフアセスメント担当、教育担当
5 インシデント対応	インシデントマネージャー、インシデントハンドラー
グループ外	経営者、CSIRT運営管理担当、システム運用担当

表の「法務助言」はリーガルアドバイザー、「通知担当」はノーティフィケーション担当を指します。検索でよく調べられる「コマンダー」は、平常時とインシデント対応時の両方でCSIRT全体を統括する役割です。必要に応じてPoC（窓口担当）と一緒に経営者へ説明するのも、その役割の一つです。インシデントマネージャーは収集・分析担当から情報を集めてコマンダーに共有し、インシデントハンドラーに対応を指示して記録を残します。「経営者」も役割の一つで、CISOや社長がリソースの手配と最終判断に責任を持つと定義されています。

人数が限られるなら、グループ1とグループ5を最初に社内で埋めてください。どちらも社内の業務やシステムの停止影響を知らないと務まりません。グループ2の監視・フォレンジックとグループ3の診断は、外部サービスに任せやすい領域です。

CSIRTとSOC・PSIRTの違い：守備範囲と連携時の役割分担

チーム	守る対象	中心の業務
SOC	ネットワーク・端末・ログ	監視、検知、分析
CSIRT	組織のインフラと情報資産	インシデント対応の統括、社内外の連絡
PSIRT	自社が提供する製品・サービス	製品脆弱性の受付、修正、公表

3つとも「セキュリティチーム」と呼ばれるので混同されがちです。違いは、何を守るかと、判断をどこまで持つかにあります。

CSIRTとSOCの違い：監視・検知から対応判断までの役割分担

SOCは監視・検知・分析を中心に担い、契約や権限によっては封じ込めなどの対応も行います。CSIRTは関係部門と連携し、組織全体の対応を調整します。NCAの兼任グループでも、リサーチャー・キュレーター・フォレンジック担当は「SOC」グループです。インシデントマネージャーの説明には「SOCから上がってくるアラートを該当システム部門と調整、調査する」とあります。SOCはCSIRTに情報を上げる機能で、CSIRTの一部として置くことも、外部に委託することもあります。SIEM・SOARを含む監視運用の仕組みはSOCとSIEM・SOARの違いの解説を参照してください。

CSIRTとPSIRTの違い：社内インフラと自社製品の対応範囲

FIRSTは、CSIRTは組織のインフラの保護に焦点を置き、PSIRTは組織の製品に存在する脅威や欠陥に対応すると区別しています。PSIRTの業務の枠組みは、FIRSTの「PSIRT Services Framework」（現行はVersion 1.1）にまとめられています。

ソフトウェアや機器、SaaSを外部に提供していない企業には、PSIRTは要りません。提供している企業では、外部の研究者から届く脆弱性の報告をCSIRTの窓口で受けると、社内インシデントと製品の修正が同じ列に並んでしまいます。JPCERT/CCも、製品の脆弱性への対処はCSIRTが担う組織もあれば、製品を所管する部門が担う組織もあると説明しています。製品の脆弱性対応を担う責任者と処理手順を定め、共通窓口を使う場合も社内インシデントと区別して担当者へ引き継いでください。開発工程にセキュリティを組み込む取り組みはDevSecOpsの解説で扱っています。

CSIRTの構築手順：経営層の指示から運用開始までの体制整備

経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」（2023年3月24日公開・2026年10月時点の最新版）は、経営者がCISO等に指示すべき重要10項目の7番目に「インシデント発生時の緊急対応体制の整備」を置いています。求めている内容は「制御系を含むサプライチェーン全体のインシデントに対応可能な体制（CSIRT 等）を整備させる」ことです。対象は自社だけでなく、委託先や子会社も含みます。10大脅威2026の2位が「サプライチェーンや委託先を狙った攻撃」だったことと同じ流れです。攻撃の類型はサプライチェーン攻撃の起点別3類型で整理しています。

経営層がCISO等を任命し、CSIRTの設置を指示する（予算と、システムを止める判断の権限をここで決める）
対象範囲を決める（本社のみか、子会社・委託先・制御系まで含めるか）
NCAの18役割を参考に自社に必要な役割を選び、社内担当者と必要な委託先を決める
インシデントの定義、報告経路、個人情報保護委員会・警察・取引先への連絡手順を文書にする
机上演習で、速報の目安である3〜5日以内に判断材料がそろうかを試す
NCAへの加盟や業界ISACへの参加で、社外の情報共有の窓口を持つ

手順3で自社に必要な役割の担当者が決まらない場合は、兼任や外部委託を検討し、暫定の責任者と連絡経路を決めてください。担当者の決まっていない役割は、インシデント発生時にも誰も担いません。

CISOとCSIRTの関係：意思決定と対応統括の役割分担と兼任時の注意点

CISO（最高情報セキュリティ責任者）はCSIRTの体制整備や意思決定に責任を持ち、組織によってはCSIRTの統括も兼ねます。NCAの実装例でも、大学を想定したモデルDでは、CSIRTを取りまとめるのはCISOまたは情報センターの副CISOです。経営ガイドラインの重要10項目は、経営者が「CISO等」に指示する形で書かれています。NCAの18役割でも「経営者」の例はCISO・CSO・社長で、人とシステムのリソースを手配し、セキュリティ施策の最終判断と責任を持つ役割です。CSIRTの現場を統括するのはコマンダーで、経営者への説明はPoCと一緒に行います。

つまりCISOは「止めるか」「公表するか」を決め、コマンダーは決めるための材料をそろえます。CISOがコマンダーを兼ねると、判断と調査の両方が1人に集まり、夜間や休暇中に対応が止まります。兼ねるなら代理を必ず指名してください。

自治体のCSIRT：総務省ガイドライン令和8年3月版の体制整備の例文

地方公共団体では、総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」（令和8年3月27日改定）が基準になります。第2編第2章の情報セキュリティ対策基準の例文には「CISOは、CSIRTを整備し、その役割を明確化しなければならない」とあり、CSIRTに所属する職員の中からCSIRT責任者を置くことも定められています。インシデントの報告を受けたCSIRTが、インシデントかどうかを評価し、CISOへ速やかに報告し、応急措置と復旧を指示し、原因を究明して記録を残すところまでが、例文に示された一連の流れです。第3編の解説では、CSIRTがCISO、総務省、都道府県等に報告することにも触れています。民間企業と違い、報告先に国と都道府県が入る点が自治体CSIRTの特徴です。

業界CSIRTとISAC：金融ISACの例に見る社外の情報共有先

1社では集めきれない脅威情報は、業界で共有します。ISAC（Information Sharing and Analysis Center、アイザック）は業界単位の情報共有組織です。金融ISACは2014年8月1日に一般社団法人として設立され、会員企業ページでは、2026年10月2日の確認時点で正会員を447会員と掲載しています。金融機関のCSIRTにとって、ここは社外PoCの主要な連絡先の一つになります。

CSIRTの初動準備：security.txtで窓口を公開し報告期限を自動で数える

規程や体制図は会議で作れますが、それだけでは事故の当日に動けません。立ち上げ直後に手を動かして済ませられる作業を2つ挙げます。どちらも数十分で終わり、机上演習の題材にもなります。

RFC 9116のsecurity.txtで社外PoCの連絡先を公開する設定例

外部の研究者や取引先が「御社のサイトに脆弱性がある」と知らせたくても、問い合わせフォームしか見つからず、営業窓口で止まってしまう例は珍しくありません。この経路を整える標準がRFC 9116（A File Format to Aid in Security Vulnerability Disclosure）です。Webサイトの /.well-known/security.txt にテキストファイルを置き、セキュリティ報告の受付先を機械可読で示します。RFC 9116では Contact と Expires が必須で、Expires に推奨されるのは1年未満先の日時です。項目の作り方はsecuritytxt.orgの生成フォームでも確認できます。

Contact: https://www.example.com/security/contact
Expires: 2027-09-30T23:59:59+09:00
Preferred-Languages: ja, en
Canonical: https://www.example.com/.well-known/security.txt
Policy: https://www.example.com/security/policy

Contact にはCSIRTの社外PoCが毎日確認する受付フォームを指定します。HTTPSで配信されているかは、次のコマンドで確かめられます。

curl -sS https://www.example.com/.well-known/security.txt

運用で詰まるのは Expires です。期限が切れたファイルは「もう誰も見ていない窓口」と受け取られるため、年1回の机上演習の項目に更新を入れておくと失念を防げます。自社製品を提供している企業では、Policy に置く脆弱性の受付方針がPSIRTの窓口の役割も兼ねます。

個人情報の報告期限を数えるPythonコード：知った日を1日目として計算

確報の期限は、日数の数え方で1日ずれやすい項目です。個人情報保護委員会のガイドライン（通則編）は、確報の期限（30日以内または60日以内）を事態を知った時点を1日目として数え、土日・祝日も含めるとしています。そのうえで、30日目または60日目が土日・祝日・年末年始閉庁日（12月29日〜1月3日）に当たる場合は、その翌日を期限としています。この規則を、標準ライブラリだけで動くコードにすると次のとおりです。

from datetime import date, timedelta

# 土日・年末年始閉庁日（12月29日〜1月3日）は自動判定。祝日は自社のカレンダーから追記する
HOLIDAYS = {date(2026, 11, 3), date(2026, 11, 23)}

def is_closed(d):
    md = (d.month, d.day)
    return d.weekday() >= 5 or d in HOLIDAYS or md >= (12, 29) or md <= (1, 3)

def kakuhou_deadline(aware, days=30):
    d = aware + timedelta(days=days - 1)  # 事態を知った日を1日目として数える
    while is_closed(d):                   # 期限の末日が閉庁日なら翌日へずらす
        d += timedelta(days=1)
    return d

aware = date(2026, 10, 9)  # 事態を知った日
print("速報の目安:", aware + timedelta(days=3), "～", aware + timedelta(days=5))
print("確報の期限(30日):", kakuhou_deadline(aware))
print("確報の期限(60日):", kakuhou_deadline(aware, 60))

Python 3系で実行すると、次の結果になります。2026年10月9日（金）に知った場合、30日目は11月7日（土）に当たるため、期限は翌営業日の11月9日（月）にずれます。

速報の目安: 2026-10-12 ～ 2026-10-14
確報の期限(30日): 2026-11-09
確報の期限(60日): 2026-12-07

速報の「概ね3～5日以内」は法令上の期限ではなく目安なので、コードでも範囲として出しています。実際の事案では、知った日時をインシデントの記録票の先頭に書き、このコードに渡す値と一致させておくと、後から報告日を説明しやすくなります。

中小企業・ひとり情シスのCSIRT：委託する範囲と社内に残す判断

専任者を置けない組織でもCSIRTは作れます。ただし、すべてを外部に任せると機能しません。NCAの人材定義は、ユーザ企業で総務部門等が主体となるCSIRTを「モデルA」と呼び、システムの維持はベンダーに任せ、インシデント時には社として守るべき優先順位を判断する「最低限の自警団の機能」と位置づけています。自警団で対応できないときにだけ、セキュリティ専門ベンダーに支援を求める形です。

社内に残すのは、NCAの兼任グループ1（連絡・全体統括）の判断部分です。システムを止めるかどうか、取引先や個人情報保護委員会に何をいつ伝えるかは、業務の影響を知っている社内の人間にしか決められません。一方、グループ2（監視・フォレンジック）とグループ3（脆弱性診断）は、MSSP（セキュリティ運用の委託事業者）やフォレンジック事業者の守備範囲です。ログや端末をどう保全するかは、デジタルフォレンジックの調査の流れと平時の備えで解説しています。グループ3の診断を外部に任せる場合は、Webアプリケーションやサーバーの脆弱性診断・セキュリティ診断を年1回など定期的に受け、見つかった問題をCSIRTの対応台帳に載せて修正の完了まで追う運用にすると、診断結果が報告書のまま放置されずに済みます。

避けたい失敗は、CSIRTという名前の規程だけを作り、連絡先の一覧も訓練記録も更新されない状態です。年1回の机上演習で「誰に電話するか」「委託先との契約で夜間の対応が含まれているか」を確認できないなら、その体制は発生時に動きません。社内の兼務者が1人しかいない場合は、その人が不在のときの代理を必ず決めてください。

CSIRT人材に役立つ資格：情報処理安全確保支援士とGCIH

CSIRT担当者の資格は、監視・分析、インシデント対応、法務など、担当する役割に合わせて選びます。NCAの文書も、役割ごとに必要なスキルを分けて定義しています。

情報処理安全確保支援士（登録セキスペ）：IPAが実施する国家資格です。登録者数は2026年4月1日時点で26,453名。コマンダーやインシデントマネージャーなど、技術と管理の両方に関わる役割の基礎になります。
GIAC Certified Incident Handler（GCIH）：インシデントハンドリングを対象にした米GIACの認定資格です。インシデントハンドラーやフォレンジック担当の技能の証明に使われます。

PoCやリーガルアドバイザーについて、NCAが任用の前提に挙げているのは「情報を正しく伝えるコミュニケーション能力」や関連法の知識です。技術資格より、社内調整や法務の経験を優先して人を選んでください。立ち上げ前の研修としては、NCAが加盟組織以外も参加できる勉強会を開いており、2026年11月27日には名古屋で「CSIRTのはじめ方ｰそして続けられるように」を予定しています。

CSIRTに関するよくある質問：読み方・委員会との関係・役割の違い

CSIRTの読み方は？

一般的には「シーサート」と読みます。JPCERT/CCは「シーエスアイアールティー」と「シーサート」の両方を示しています。国内の業界団体の名称も「日本シーサート協議会」です。正式名称はComputer Security Incident Response Teamで、組織のセキュリティインシデントに対応するチームを指します。

情報セキュリティ委員会があればCSIRTは不要ですか？

役割が違うため、委員会だけでは足りません。委員会はポリシーや規程を決めて定期的に見直す会議体で、夜間や休日にすぐ集まることを前提にしていません。CSIRTは事故の最中に封じ込めや報告の判断を担う機能です。ISMSでも附属書Aの5.24〜5.28でインシデント管理が求められています。小規模な組織では委員会のメンバーがCSIRTを兼ねてかまいませんが、事故時にCSIRTが単独で判断できる範囲を事前に決めておいてください。

CSIRTとSOCの違いは何ですか？

SOCはネットワークや端末の監視・検知・分析を中心に担い、契約や権限によっては封じ込めなどの対応も行います。検知された事象をインシデントとして扱うかを判断し、封じ込め・復旧・社内外への連絡を統括するのがCSIRTです。NCAの役割定義でも、SOCのグループからCSIRTのインシデントマネージャーにアラートが上がる関係として整理されています。

PSIRTとCSIRTの違いは何ですか？

FIRSTは、CSIRTを組織のインフラを守るチーム、PSIRTを自社製品の脅威や欠陥に対応するチームとして区別しています。PSIRTの業務をまとめた文書はFIRSTのPSIRT Services Framework（Version 1.1）です。製品やサービスを外部に提供していない企業にはPSIRTは不要で、提供している企業は製品の脆弱性対応を担う責任者と処理手順を定め、共通窓口を使う場合も適切に振り分けます。CERTとCSIRTの違いは活動内容ではなく名称の権利で、「CERT」は米カーネギーメロン大学の登録商標です。

CSIRTの役割にはどんなものがありますか？

日本シーサート協議会の「CSIRT人材の定義と確保 Ver.2.1」は、PoC、コマンダー、インシデントマネージャー、インシデントハンドラー、トリアージ担当、フォレンジック担当、経営者など18の役割を定義しています。同文書は、少人数でも回せるよう、連絡・全体統括、SOC、セキュリティ戦略・製品評価、資産管理・教育、インシデント対応の5グループにまとめる兼任の例も示しています。