security-comms

Security Comms — セキュリティ業務をセキュリティに詳しくない相手に伝える

他のすべてのスキルが生み出すギャップを埋めるスキルです。監査系のスキルは指摘事項を生み出し、対応系のスキルはインシデントを生み出し、ガバナンス系のスキルはロードマップを生み出します。しかし、そうした成果物は、取締役会、顧客、セキュリティ質問票への回答を試みるセールスエンジニア、あるいは「これは費用がかかるのか」と尋ねる CFO を前にすると、役に立たなくなります。

このスキルは、技術的なセキュリティ業務を、対象者が実際に活用できる成果物へと変換します。セキュリティ担当者が週に 2〜3 回活用するスキルであり、専任のセキュリティチームを持たない創業者が、指摘事項をセキュリティの枠を越えて共有する必要があるときに活用するスキルです。

相互参照：他のすべてのスキル（監査の出力、インシデント報告書、脅威モデリングの要約、CSF 評価）から情報を受け取り、対象者に合わせた成果物を作成します。特に finding-triage（対応方針の報告）および incident-triage（対応の経緯）と密接に連携します。

承認

ユーザー自身の組織について、ユーザーから提供された事実に基づいてコミュニケーションの草案を作成します。草案は送信の承認を意味するものではありません。社外向け（顧客、規制当局、報道機関、研究者）の内容は、計画書に記載された責任者の承認が必要であり、侵害通知には法務レビューが必要です。承認を得ずに、顧客名、PII、未確認の詳細を草案に記載しないでください。

7 つの対象者（それぞれが実際に必要とするもの）

セキュリティコミュニケーションに、万能な書き方はありません。対象者ごとに必要な成果物は異なります。対象者に合わない書き方をすることが、最もよくある失敗です。

1. 取締役会／社外取締役

知る必要があること： 当社は重大なリスクにさらされていますか？チームは対処できていますか？追加の投資が必要ですか？

必要ないこと： CVE 番号、ファイルパス、スキャナー名、専門用語、手法。

形式： 1 枚のスライドまたは 1 ページ。3 つのセクションで構成します。現在の状況を 1 段落で説明し、上位 3 つのリスクをそれぞれ 1 文で述べ、必要な投資／意思決定を明記します。数字は重要性が伝わるもの（ドルでの金額や影響率）にし、生の件数にしないでください（「脆弱性が 47 件あります」では何も伝わりません。「決済チームの 2 つのサービスに、攻撃者が顧客のカード情報にアクセスするために利用できる未修正の問題があります」なら、何をすべきかが伝わります）。

よくある間違い： 取締役会に、評価点付きのヒートマップや 30 行の CVE 表を見せてしまうことです。求められているのは要点です。

2. 経営幹部（CEO／CFO／COO／GC）

知る必要があること： どのような意思決定を求められていますか？トレードオフは何ですか？何もしない場合のコストはどのくらいですか？

形式： 1〜3 ページのメモです。まず意思決定事項を示し、次に背景、トレードオフを含む選択肢、推奨案、そして拒否された場合に生じるコスト／所要時間／必要な人員／リスクを記載します。可能な限り数値化します（規制上のリスク額、解約率で示す顧客の信頼に関するリスク、エンジニアリングの工数など）。

よくある間違い： 予算が承認されなかった場合の代替案を示さずに、予算を要求することです。

3. エンジニアリング部門のリーダー／シニアエンジニア

知る必要があること： 何が壊れていて、どう直すのか、優先順位は何か、ロードマップ上でどのようなトレードオフがあるのか。

形式： チケットまたは設計文書の形式に沿った報告書です。具体的なファイル／エンドポイント／コミット、再現手順、修正案、検証手順、工数見積もりを含めます。エンジニアリング部門のリーダーが重視するのは具体性です。「どこかに XSS があります」という曖昧な説明は反感を招きます。

よくある間違い： 具体的な作業内容を示さずに、セキュリティ作業を緊急だと伝えることです。エンジニアは自分で指摘事項を検証したいと考えています。

4. 個々のエンジニア（実際に作業を行う人）

知る必要があること： 自分のコードのどこを、どのように変更すればよいのか、そして自分で実行して確認できる方法です。

形式： コードに即した詳細を含むチケットです。ファイルパス、行番号、現在のコード、修正後のコード、修正が維持されていることを証明するテストを記載します。これは最も具体的な書き方です。

よくある間違い： 背景説明なしにスキャナーの出力を貼り付けることです。エンジニアには、スキャナーが出力した 50 個のフィールドのうち、どれが重要なのかわかりません。

5. カスタマーサクセス／セールスエンジニアリング

知っておく必要があること： 質問を受けた際に顧客にどう説明するか。一般的なセキュリティ質問票の項目にはどう回答するか。伝えるべき変更点は何か。

形式： 社内FAQ — 顧客が尋ねるときの言い回しで質問を記載し、SEが読み上げたり返信に貼り付けたりできる回答を用意します。セキュリティ用語は避けます。法務から実際に指示がない限り、「コメントできません」といった表現は避けます。

よくある間違い： 顧客向けの文面を作成した後、公開前にカスタマーサクセスにトーンを確認してもらわないことです。セキュリティ担当者は、防御的または曖昧に聞こえる表現を使いがちです。

6. 顧客（公表対象の場合）

知っておく必要があること： 自分のデータにアクセスされましたか。どのような対応をしましたか。自分は何をすべきですか。

形式： 短い書簡。何が起きたかを、こちら側の表現ではなく顧客の視点で最初に伝えます。関係した可能性のあるデータを明記します。実施した対応を明記します。顧客が取るべき行動を明記します。実際に機能する問い合わせ先を示します。企業広報的な婉曲表現は避けます。曖昧にごまかしている印象を与えるためです。

よくある間違い： 「念のため」と書きながら、本当は「まだ分かっていませんが、伝える必要があります」という状況であることです。顧客には見抜かれます。

顧客への開示には法務および規制上の側面があります。このスキルで作成するのは草案であり、公開前に法務部門、場合によっては外部弁護士による確認が必要です。

7. 調達／法務／コンプライアンス担当者（社内またはベンダー側）

知っておく必要があること： コンプライアンスに準拠しているか、何が文書化されているか、契約上の立場はどうか、証拠はあるか。

形式： 構造化された成果物 — 質問票への回答、BAA／DPAの修正案への入力、監査証拠の抽出。相手方が使っているフレームワークの用語（CSFサブカテゴリID、ISO管理策、PCI要件番号、HIPAAセーフガード名）を使います。独自のフレームワークに置き換えないでください。相手方は自分たちの用語での回答を求めています。

よくある間違い： 証拠の参照先を示さずに「はい」または「いいえ」と回答することです。調達側のレビュー担当者は、求められてからではなく、回答に証拠が添えられていることを必要とします。

ワークフロー

このスキルには、技術的な入力から草案を作成するモードと、他の人が書いた草案をレビューするモードがあります。

モード 1：技術的な入力から草案を作成する

1. 対象読者を特定します。 上記の7つのうち、誰を対象とするかを確認します。複数の場合は、成果物を分けます。まとめないでください。
2. 求められている判断を特定します。 経営陣：「予算を承認する」。エンジニアリング：「期日までに修正する」。顧客：「適切に対応したと信頼する」。判断を一文で説明できない場合、対象読者に求める判断はなく、成果物は行動を促すものではなく情報提供を目的としています。
3. 対象読者に関係のない技術的な情報を取り除きます。 CVE番号はエンジニア向けです。金額は経営陣向けです。顧客への影響は顧客向けです。同じ調査結果でも、草案は3種類になります。
4. まず要点を書きます。 最初の段落だけを読んだ場合、何を持ち帰ってもらいたいですか。それを書いてから、裏付けとなる詳細を組み立てます。
5. 可能な限り数値で示します。概算でも構いません。 「有料顧客の約8％に影響します」は、「一部の顧客に影響します」よりも明確です。分からない場合は、明確にそう伝えます。曖昧な言い回しでぼかさないでください。
6. 対象読者と同じ視点を持つ別のレビュアーに確認してもらいます。 エンジニアリング向けの成果物は別のエンジニアに、顧客への開示文はカスタマーサクセスに、経営陣への報告は実際に経営会議へ出席する人に確認してもらいます。

モード 2：草案をレビューする

1. 対象読者の確認。 指定された対象読者にふさわしい文体ですか。
2. 判断の確認。 相手が下す必要のある判断は明確ですか。
3. 専門用語の確認。 対象読者が日常業務で使わない用語をすべて洗い出します。
4. 曖昧な表現の確認。 「念のため」「最大限の努力」「業界標準」などは、曖昧にごまかしているように受け取られます。可能な限り具体的な表現に置き換えます。
5. 具体性の確認。 草案には、何が見つかり、何を実施し、次に何をするのかが、担当者名とともに記されていますか。

テンプレート

テンプレート：セキュリティインシデントに関する経営陣向け報告

# Security Update — [Date]
## To: Board
## From: [CISO / equivalent]

### Bottom line
[One sentence — material exposure yes / no, contained yes / no, action needed yes / no]

### What happened
[Two to four sentences in the board's terms. No file paths or CVE numbers.]

### What's been done
- [Action 1, by date]
- [Action 2, by date]

### What we're asking of the board
[If anything — funding, vendor change, communications approval. If nothing, say so.]

### What we'll know by [next-meeting date]
[Open questions, planned investigations]

テンプレート：判断を求める経営陣向けメモ

# Memo: [Decision name]
## From: [author]
## To: [decision-maker]
## Date: [date]
## Decision needed by: [date]

### The decision
[One sentence — what you're asking them to approve.]

### Why now
[Two sentences — what changed, what the regulatory / customer / risk pressure is.]

### Options
1. [Option A — cost, time, residual risk]
2. [Option B — cost, time, residual risk]
3. [Do nothing — what happens]

### Recommendation
[Which option and why.]

### Cost of inaction
[Specific — regulatory fines, customer-trust impact, engineering hours saved elsewhere, etc.]

テンプレート：顧客向け侵害開示（ドラフト — 法務レビュー必須）

# Security Notice
## Date: [date]

Dear [customer],

On [date], we identified [what happened — in the customer's terms]. Information that may have been involved includes [specific data fields]. Information not involved includes [specific data fields].

We have taken the following steps:
- [Action 1]
- [Action 2]

We recommend you:
- [Action 1 they should take, e.g., reset password]
- [Action 2]

If you have questions, contact [working contact path — not a generic security@].

We are sorry this happened.

[Name and title — not a corporate signature]

テンプレート：事後検証の経緯（社内向け）

# Post-mortem: [Incident name]
## Severity: [SEV1 / SEV2 / SEV3]
## Date detected: [date]
## Date resolved: [date]
## Duration: [hh:mm]
## Authors: [names]

### Summary
[One paragraph that someone outside the response can read and understand the incident.]

### Timeline
[Bulleted, with timestamps in one timezone. Detection → triage → containment → eradication → recovery → all-clear.]

### Impact
- [Who was affected — customers, internal users, third parties]
- [What was affected — service availability, data confidentiality, data integrity]
- [Quantify where possible — affected user count, downtime minutes, data records involved]

### Root cause
[The actual root cause — not the proximate trigger. Why did the trigger lead to user impact?]

### What went well
[Two to four items. Be specific.]

### What did not go well
[Two to four items. Be specific. No blame language.]

### Action items
| Item | Owner | Deadline | Status |
|------|-------|----------|--------|

### Lessons for the rest of the org
[What other teams should change based on this incident.]

テンプレート：監査指摘事項の翻訳（エンジニアリング向け）

# Security Findings — [Project / sprint]
## Audit source: [owasp-audit / api-audit / etc.]
## Date: [date]

### Summary
[One sentence — N findings, severity breakdown, target resolution window.]

### Findings (prioritized)
| ID | Severity | File / endpoint | Effort estimate | Sprint candidate |
|----|----------|-----------------|-----------------|------------------|

### Per-finding detail
[Per-finding entries with file:line, reproduction, fix proposal, verification step, effort estimate.]

### Not findings (FYI)
[Items the scanner / audit flagged that we've determined are not real — with one line each on why. This builds engineering trust that we're not crying wolf.]

テンプレート：セールスエンジニアリング FAQ

# Customer Q&A — [Topic, e.g., recent vulnerability disclosure]
## Internal — for SE use; not customer-facing

**Q: Were we affected by [CVE / event]?**
A: [Straight answer. Yes / no / partially with which part.]

**Q: What did you do about it?**
A: [Specific actions with dates.]

**Q: Should I be doing anything on my end?**
A: [Customer-facing recommendation, or "no action required, here's why."]

**Q: When can I expect a written notice?**
A: [Date / not applicable / "you're reading the only one, you can quote it."]

**Q: [Other anticipated question]**
A: [...]

**If asked something not on this list:** [Escalation path — to whom, with what info, how fast.]

AI が生成したセキュリティ関連文書のレビュー

このスキル自体が AI エージェントによって使われるため、特に注意が必要です。

AI がセキュリティ関連文書を生成した場合、その対象読者に適した人間のレビュアーを通さずに公開してはいけません。具体的には：

• 顧客向けの開示は、送信前に法務レビューを受ける必要があります
• 取締役会向けの報告は、資料に盛り込む前に CEO / CISO の確認を受ける必要があります
• 経営幹部向けのメモは、その経営幹部の意思決定スタイルを理解している人の確認を受ける必要があります
• エンジニアリングチケットは、簡易なレビューで公開できますが、検証手順を省略してはいけません

AI が作成したセキュリティ関連文書は、最終稿ではなく初稿として最も役立ちます。このスキルにより初稿の作成時間は 90 分から 10 分に短縮されますが、レビュープロセスがなくなるわけではありません。

境界

• このスキルはコミュニケーション用の成果物を作成しますが、開示を許可するものではありません
• 顧客向けの侵害開示には、法的、規制上（GDPR 第 33 条、HIPAA 侵害通知規則、州の侵害通知法、上場企業の重要なインシデントに関する SEC 8-K 開示）、および契約上の側面があります。ドラフトは送信済みのメッセージではありません
• 重要な影響の過小評価、誤った責任の帰属、または受容済みリスクの指摘事項を解決済みと表現することなど、誤解を招くことを意図したコミュニケーションの作成は拒否してください
• 許可なく、個々の顧客の名前を挙げたり、その顧客の PII を含めたりする開示を作成してはいけません
• 法執行機関が関与するインシデント（ランサムウェアへの支払い、国家主体への帰属判断）では、コミュニケーション戦略は法務顧問と決定します。このスキルが作成するのは対象読者向けのドラフトであり、法執行機関向けのものではありません

参考資料

• 「Crafting the InfoSec Playbook」— Bollinger / Enright / Valites（コミュニケーションの章）
• SANS — 経営幹部とのコミュニケーションに関するレポート（年次）
• 「The Manager's Path」— Camille Fournier（技術者以外の読者に向けた文章作成について）
• サイバーセキュリティリスク管理、戦略、ガバナンス、およびインシデント開示に関する SEC 最終規則（2023 年）— 重大インシデントの開示時期
• GDPR 第 33 条（侵害通知の時期 — 監督機関への通知は 72 時間以内）
• HIPAA 侵害通知規則（影響を受けた個人への通知は 60 日以内）
• ENISA — 危機コミュニケーションガイダンス
• 「Cybersecurity Incident Response: How to Contain, Eradicate, and Recover from Incidents」— Eric C. Thompson