セキュリティインシデント

Last Reviewed: YYYY-MM-DD Last Tested: YYYY-MM-DD

インシデントコマンダーは必須です

PagerDutyにおける全ての重大インシデントと同じように、セキュリティインシデントでは適切にタスクを委譲できる、インシデントコマンダーが必須です。 タスクはインシデントコマンダーから割り当てられ、並列に実行できます。 !ic page コマンドで 可能な限り早く呼び出してください。

セキュリティインシデントかどうかわからない

とにかく対応を開始してください。 それはあとから謝るよりも良いことです。 インシデントコマンダーが判断します。

チェックリスト#

これらのチェックリストの詳細は次に詳しく説明します。

  1. 現在の攻撃を停止する
  2. 攻撃ベクターの遮断する
  3. 対応チームを組む
  4. 攻撃を受けたインスタンスを隔離する
  5. 攻撃のタイムラインを特定する
  6. 漏洩したデータを特定する
  7. 他のシステムへのリスクを評価する
  8. 再攻撃のリスクを評価する
  9. 追加の措置や監視を適用する
  10. 攻撃されたシステムのフォレンジック解析をする
  11. 内部のコミュニケーションをする
  12. 法務部門、法的機関の利用
  13. 攻撃ベクターとして使われている可能性のある外部関係者に連絡
  14. 外部とのコミュニケーション

攻撃の防止#

なんとしてでも、可能な限り早く攻撃を止めてください。 サーバーをシャットダウンしたり、ネットワークから隔離したり、必要ならデータセンターを停止してください。 一般的には以下のことを試します。

  • プロバイダーコンソールからインスタンスをシャットダウンします(フォレンジック解析が必要になるので、削除はしないでください)。
  • たまたまログインしていたのなら、以下のことを実行してください。
    • トラフィックを制限するために、デフォルトのiptablesルールを再設定する。
    • 攻撃者と思われる全てのアクティブなセッションにkill -9を実行する。
    • rootパスワードを変更して、/etc/shadowを更新して他のユーザーをロックアプトする。
    • sudo shutdown now

攻撃ベクター遮断する~#

攻撃ベクターや経路と思われる物を特定し、攻撃を停止した後に使えないようにします。

  • 3rdパーティー製のプロバイダーに侵入されていると思われる場合は、自分(および物理的にそこにいる人)以外のアカウントを削除してください。そしてパスワードとMFAトークンを更新します。
  • もしサービスアプリケーションが攻撃ベクターだと思われる場合は、関連するコードパスを無効化するか、サービス全体を停止してください。

対応チームを組む#

セキュリティインシデントに対応する主要な人を判断して、彼らに逐一情報を提供します。 インシデントに関する情報をやり取りする、安全な手段を確立してください。 インシデントの詳細(またインシデントが起こったという事実さえも)、内部犯ではないとわかるまで秘密にしておく必要があります。

  • まだの場合はインシデントコマンダーを呼び出します。彼らは通常のインシデントコマンダーの役割も任命します。 インシデントコマンダーチームは実施されたアクションを記録して、適した社内のステークホルダーに通知する責務があります。
  • チャットやドキュメントで使用する、プロジェクトのコードネームをつけてください。 誰かがプロジェクト名を聞いたとき、それがセキュリティインシデントかわからないようにします(例: サファイアユニコーン)
  • まだ始めて無いのなら、音声通話を開始します。
  • インシデントのコードネームをつけたチャットルームを作成します。
  • 全ての応答者を、音声通話とチャットルームに招待します。
    1. セキュリティーチームは入れてください。
    2. 影響を受けるサービスの代表者を入れます。
    3. 経営陣のステークホルダーと法務部門は早い段階で招待すべきですが、運用上の対応者を優先します。
  • フォレンジック解析を実施するまでは、インシデントについて対応チーム以外の人とコミュニケーションを取らないください。内部攻撃の可能性もあります。
  • 全てのメールとチャットトピックの先頭に「弁護士作業計画」としてください。

攻撃を受けたインスタンスを隔離#

攻撃の影響を受けたインスタンスは、すぐに他のインスタンスから隔離する必要があります。 できるだけ早くシステムのイメージを取得して、後からフォレンジック解析で利用するために読み取り専用ストレージにコピーします。

  • 影響を受けたインスタンスのIPアドレスを、他の全てのインスタンスのブラックリストに追加します。
  • 攻撃を止められなかった場合は、インスタンスをシャットダウンします。
  • インスタンスが利用してるディスクのイメージを取得しストレージに保存します。このイメージは読み取り専用にして、改ざんできないようにします。

攻撃タイムラインの特定#

攻撃のタイムラインを特定して、攻撃者が何を実行したかを正確に特定します。

  • 攻撃が始まる前に、攻撃者がシステム上で行ったことの予備調査
  • 攻撃者はいつシステムにアクセスしたか
  • 攻撃者はシステム上で、いつ、何をしたか
  • 攻撃者を発見するまでの間や、攻撃者を追い出すまでに、どのくらいの間システムにアクセスしていたか
  • 攻撃者がデータベース上で走らせたクエリの特定
  • 攻撃者が他のバックドアからのアクセスを試みているかの確認。目立ったログの監視など。

情報漏洩#

ログファイル、時系列グラフ、他の情報やツールを使ってのフォレンジック解析をして、漏洩した情報があるかを特定する。

  • 攻撃中に漏洩しうる全てのデータを特定
    • データベースからデータが持ち出されたか?
    • 漏洩したと思われるシステムのキーはあるか?
    • 攻撃者は他のシステムのコンポーネントを特定できるか(ネットワーク構成の推測など)
  • どの顧客データが漏洩したか

リスク評価#

漏洩したデータを元に、他のシステムへのリスクを評価します。

  • 攻撃者は他のシステムを攻撃するための、十分なデータを持っていますか?
  • ホストにパスワードやキーが保存されていましたか?もしそうなら保存方法に関わらず、脅威に晒されている可能性があります。
  • 最初の攻撃に使われた可能性のあるアカウントの、キーやパスワードを全てのシステムで更新します。

追加措置#

システムの他の部分に、追加の処置を取ります。

  • 漏洩した可能性のあるデータを更新します。
  • 似たような犯行を検知するために、新しいアラートを設置します。
  • 攻撃に関連した全てのIPアドレスをブロックします。
  • 漏洩した可能性のあるキーやクレデンシャルを直ちに無効化します。

フォレンジック解析#

システムが保護されていると革新して、攻撃を検知できる十分な監視が整えば、フォレンジック解析のステップに進むことができます。

  • 作成した読み取り専用イメージやアクセスログから、攻撃に関する情報を精査します。
  • 何が発生して、それがどのように起こったのか、そして将来それをどう防止するかを特定ます。
  • 攻撃に関与した全てのIPアドレスを追跡します。
  • 攻撃者がシステムにもう一度アクセスしようとしてないかログを監視します。

内部コミュニケーション#

委任先: ヴァイスプレジデント(VP)または技術ディレクター

フォレンジック解析などから攻撃が内部犯行でないと確信してから、内部とのコミュニケーションを図ります。

  • あまり詳細を伝えないようにします。
  • タイムラインの概要を説明します。
  • 追加措置について議論します。
  • 新たな情報があればそれを追います。

法務部門や外部組織との連絡#

委任先: ヴァイスプレジデント(VP)または技術ディレクター

法務部門と協力して攻撃の発信元を特定し、オーナーにシステムに侵入された可能性があることを知らせます。

  • 社内の法務部門に連絡します。
  • FBIに連絡します。
  • 攻撃に使用されたシステムのオペレーターに、システムに侵入された可能性があることを連絡します。
  • セキュリティ会社に連絡して、次にやるべきリスク評価や報告の助言をもらいます。
  • サイバー保険会社に連絡します。

外部コミュニケーション#

委任先: マーケティングチーム

取得した全ての情報が確認できて、イベントのタイムラインや、どの情報が漏洩してどのように侵入されたかがわかれば、再発防止策を講じることができます。 その上で情報が漏洩したということと、取るべきアクションを顧客に向けて発表する必要があります。

  • 新たな侵入がされたと混同されないように、告知のタイトルに日付を付けます。
  • 「私たちはセキュリティ問題に真剣に取り組んでいます」とは言わないでください。それを読むとうんざりします。
  • 正直に、責任を受け入れ、事実を提供し、再発防止のために何を計画しているかを伝えてください。
  • 可能な限り、詳細なタイムラインにしてください。
  • 漏洩した情報と、それが顧客にどう影響があるかを可能な限り詳しく説明してください。保存してはいけないものを保存していた場合もそれを正直に伝えたください。後から判明すると最悪の事態になります。
    • 侵入の原因となった外部関係者の名前を上げたり恥をかかせないようにしましょう。それは良くないです(すでに彼らが告知してる場合を除く。その場合はその告知へのリンクを張ります)。
  • 可能な限り、できれば侵入が発覚して数日以内に外部に告知してください。期間が空くと事態は悪化します。
  • 可能であれば、一般公開する前に顧客の内部セキュリティチームと連絡をとってください。

インシデント発生中のコミュニケーション#

  • 音声通話やSlackを積極的に使います
  • どうしても必要な場合以外はメールは使わないでおきましょう
    • メールの件名は「弁護士作業計画」とします
    • @pagerduty.com以外のメールアドレスが宛先に含まれている場合、メールが暗号化されていることを確認してください。
  • インシデントに関する連絡にはSMSを使わないでください。
    • より安全なコミュニケーションチャネルに誘導する場合を除きます。たとえば「Slackにできるだけ早く参加してください」
  • 承諾が得られるまで、インシデントの情報を対応チーム外に漏らさないでください。

追加情報#