テーマ： incident-response

• シークレットをコミットしたら：ファイル削除だけでは足りない理由と対応の順序

  Git リポジトリへ push した認証情報は、履歴、フォーク、クローン、キャッシュ、CI ログに残ります。履歴の書き換えは今後の露出を減らせてもコピーは回収できないため、まず認証情報を失効・ローテーションし、次に履歴を整理し、使用状況を確認します。

  methodology · ja · reviewed · 知識の基準日 2026-09-23

• Cisco Secure Email GatewayとSD-WAN Manager：修正の確認と侵害の証拠保全

  メールスキャナーとSD-WAN Managerの対処記録は個別に管理する。実際にインストールされた修正を確認し、状態を変える復旧作業の前に証拠を保全したうえで、製品ごとの調査手順に従う。

  article · ja · reviewed · 知識の基準日 2026-10-25

• 事後検証の対応項目を完了まで追跡する：追跡チケット、単独の担当者、経過時間による見直し

  Site Reliability Workbook は、正式な追跡手順がないと事後検証の対応項目が忘れられがちだと警告しています。各項目に追跡チケット、担当者一人、種類、優先度を与え、未完了項目を経過時間順に定期確認し、期限を過ぎた項目を飛ばす行ではなく判断すべき事項として扱います。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• After a vulnerability report arrives: acknowledge, assess, fix in private, disclose

  Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.

  methodology · en · reviewed · 知識の基準日 2026-09-17

• 脆弱性が悪用されたエッジ機器へのパッチ適用後：証拠保全、復旧、運用再開の確認

  悪用が確認されている脆弱性にさらされたエッジ機器を調査するための運用手順案である。証拠を保全し、ベンダーの指示に従う再構築が必要かを記録して、漏えいした可能性のある信頼の基盤となる情報を交換し、パッチ適用とは別に復旧を検証する。

  methodology · ja · reviewed · 知識の基準日 2026-10-25

• APIキーを預けたプロバイダーで侵害が起きた場合：封じ込め、交換、請求の確認

  漏えいしたキーを発行元で失効させ、信頼できるシステムを通じて正当な利用側のアクセスを復旧し、利用状況と請求を調査する。予算アラートと交換用キーの配布は、検証が必要な別々の制御として扱う。

  methodology · ja · reviewed · 知識の基準日 2026-10-25

• Security incident response for a small team: a minimum procedure

  A two-person team cannot run a security operations centre, but it can prepare a contact list, a containment checklist and an evidence rule in advance; NIST SP 800-61 Rev. 3 frames incident response as part of ongoing risk management, and this procedure is the minimum that makes the first hour predictable.

  methodology · en · reviewed · 知識の基準日 2026-09-15

• Ivanti Connect Secure：CVE-2026-104935の修正と過去の侵害の調査

  認証回避の修正と侵害からの復旧を分けて扱う。互換性のある修正リリースを選び、フォレンジックの証拠を保全し、ネットワークとメモリの解析に加えて完全性チェックを行う。

  article · ja · reviewed · 知識の基準日 2026-10-25

• LiteLLMの2026年10月のインシデント：確認されたトークン漏えいとゲートウェイログの保護

  LiteLLMの後日の事後分析は、当初のログ窃取という仮説を訂正し、Agent Platform APIを通じたトークン漏えいの証拠を示した。このインシデントは引き続き、エージェントの認証情報、応答本文、高い権限を持つ自動処理に、それぞれ別のアクセス境界が必要な理由を示している。

  article · ja · reviewed · 知識の基準日 2026-10-25

• Postmortems ohne Schuldzuweisung: Ablauf, Ursachen und Massnahmen festhalten

  Ein Postmortem beschreibt, was während eines Vorfalls geschah, wen es wie lange traf, welche Umstände es ermöglichten und welche Massnahmen eine Wiederholung unwahrscheinlicher machen. Schuldfreiheit ist kein Höflichkeitsgebot, sondern die Bedingung dafür, dass Beteiligte Fakten berichten statt sich zu verteidigen.

  methodology · de · reviewed · 知識の基準日 2026-09-16

• Correlation versus causation in incident and operations data

  A correlation coefficient measures how two series move together; it says nothing about which one drives the other, whether a third factor such as traffic drives both, or whether the data were selected by the outcome. Plot first, condition on the obvious common causes, check timing, and confirm with an intervention such as a flag or canary before acting.

  article · en · reviewed · 知識の基準日 2026-09-16

• プロバイダーの侵害通知を読む：送信元、影響範囲、指標を検証する

  プロバイダーの侵害通知を、検証済みの対応記録にする。通知の真正性を確かめ、影響を受ける資産と未解決の事実を特定し、結論を出す前に、保持しているログと指標を照合して評価する。

  article · ja · reviewed · 知識の基準日 2026-10-25

• A first game day: one chaos experiment with a hypothesis, a blast radius and an abort rule

  Run a first fault-injection exercise as a scheduled, announced experiment: define the steady state as a measurable output, hypothesise that it holds under one specific fault, limit the blast radius, set an abort condition, inject, and record what the system and the people did; the Principles of Chaos Engineering give the four steps and the Google SRE book describes disaster role-play as a weekly ritual.

  methodology · en · reviewed · 知識の基準日 2026-09-16

• PAN-OS CVE-2026-0322：メンテナンス系列ごとの修正確認と管理プレーンの復旧

  認証済みの攻撃者が悪用できる管理インターフェースの脆弱性が、PAN-OSファイアウォールとPanoramaに影響する。メンテナンスリリースの完全なバージョンを照合し、管理アクセスを制限するとともに、侵害が疑われる場合はベンダーが示すハードウェアまたは仮想アプライアンスの復旧手順を適用する。

  article · ja · reviewed · 知識の基準日 2026-10-25

• Runbooks für den Betrieb: Anleitungen, die eine Fremde nachts ausführen kann

  Ein Runbook pro Dienst beantwortet in dieser Reihenfolge: Was tut der Dienst, woran erkennt man in einer Minute, ob er gesund ist, welche bekannten Störungen gibt es mit Symptom, Diagnosebefehl und Gegenmassnahme, welche Handlungen sind sicher, welche gefährlich, und wer ist wann zu eskalieren; geprüft wird es von jemandem, der es nicht geschrieben hat.

  methodology · de · reviewed · 知識の基準日 2026-09-16

• Teams with fewer, alert-linked dashboards diagnose incidents faster than teams with many unowned dashboards

  Hypothesis: for services of comparable size, the time from a page to a named probable cause is shorter when the team maintains a small number of owned dashboards that alerts link to directly, than when it maintains many copied or auto-generated dashboards that responders have to browse; a proposed comparison using incident timelines and dashboard inventories.

  hypothesis · en · reviewed · 知識の基準日 2026-09-16

• Running a public status page honestly: components, automation and history

  A status page earns trust only when it turns red when users see red; host it off the infrastructure it reports on, list components users recognise, let everyone on call post without approval, update on a fixed cadence during incidents, and keep the history visible.

  article · en · reviewed · 知識の基準日 2026-09-16

• ログインプロバイダーの侵害後の対応：対象を絞ったリセット、セッションの復旧、漏えいパスワードの検査

  第三者での漏えいをすべて自分の環境の侵害の証拠とみなすことなく、影響を受けたユーザーアカウントを復旧する。証拠に基づくリセットとセッションの無効化に、クレデンシャルスタッフィングの監視とプライバシーに配慮したパスワード検査を組み合わせる。

  methodology · ja · reviewed · 知識の基準日 2026-10-25

• Bootstrapping NTP, DNS and DHCP after a full network outage: a dependency-ordered restart

  Proposed methodology: after an outage that took down NTP, DNS and DHCP together, bring time up first, then DNS, then DHCP, because certificate and Kerberos checks need correct time, most services locate each other by name, and DHCP may depend on both, with the caveat that an NTP server using upstream hostnames itself needs DNS.

  methodology · en · reviewed · 知識の基準日 2026-09-24

• NetScaler ADCとGateway：復旧前に9月と10月の修正を区別する

  CVE-2026-88771とCVE-2026-88772は、SAMLのサービス拒否の脆弱性CVE-2026-88779とは修正済みとなる最小ビルドが異なる。各情報に照らして確認し、侵害を調査したうえで、セッション終了を明確な判断の下で行う。

  article · ja · reviewed · 知識の基準日 2026-10-25

次のページ

機械可読： JSON