雑記ブログとしてリニューアルしました(2021/05/03)

エンドユーザーに信頼される!セキュリティインシデント検知時の適切な対応とは?【若手インフラSE向け】

エンドユーザーに信頼される!セキュリティインシデント検知時の適切な対応とは?【若手インフラSE向け】

セキュリティエンジニアのめるりです。

あなたがセキュリティ基盤を運用しているSEの場合、年々高度化・多様化するサイバー攻撃を100%防御することは難しい時代になっていることを痛感しているのではないでしょうか。

私もその中の一人で、セキュリティインシデントとして検知した内容を的確に、スピード感をもってエンドユーザーに通知する必要がより大切になってきていると思います。

本記事では、セキュリティインシデントを検知した際の適切な対応について執筆します。

目次

セキュリティセンサーを確認する

セキュリティセンサーを確認する

セキュリティインシデントを検知することのできる機器をセキュリティセンサーと言います。

セキュリティインシデントを検知した時、まず初めにセキュリティインシデントのIPアドレス情報から、何のセキュリティセンサーで検知したかを確認します。

例えば検知したセキュリティセンサーがプロキシサーバの場合はWeb閲覧に関する通信であること、メールサーバの場合はメール関連の通信であることがわかります。

セキュリティインシデントの対応はWeb閲覧、メール関連といった機能ごとに確認する内容が全く異なるので、機能ごとに確認手順を整備されていることが望ましいです。

攻撃シグネチャの内容を確認する

攻撃シグネチャの内容を確認する

攻撃シグネチャとは、世の中で脆弱性が発表された時に製品ベンダーがその脆弱性を検知できるようにした識別子です。

簡単に言えば新作メニューの命名のようなものです。

例えば一時期流行したチーズが伸び伸びのハットクという食べ物がありますが、新しい食べ物には必ず新しい名前がつきますよね。

シグネチャも同じように、過去の脆弱性と区別できるよう、新しい識別子を割り振り、その中でどんな攻撃がなのかの情報を管理できるようにしています。

このため、シグネチャ名をもとに製品ベンダーから提供されるサイバー攻撃に関する情報を確認するようにします。

通信の成立可否を確認する

通信の成立可否を確認する

Web系のセキュリティインシデントの場合、通信が成立していない場合はエンドユーザ側の環境には影響がなかったと判断することがあります。

通信が成立していない状態とは、HTTPステータスで言えば500系・400系で、通信が成立している場合は300系・200系のステータスになります。

セキュリティインシデントの送信元・宛先IPアドレス情報をアクセスログと突き合わせることで、HTTPステータスの確認を行い、通信の成立可否を確認するようにしましょう。

通信先の正当性を確認する

通信先の正当性を確認する

通信が成立していたとしても、通信先が不審でない可能性が高い場合は、誤検知であると判断することがあります。

通信先の正当性の確認ツールとしては、VirusTotalやBlacklistMasterが有名です。
VirusTotalやBlacklistMasterの使い方は過去記事で紹介していますので、ご確認ください。

あわせて読みたい
ダイソンの偽サイトではマフラーが送られてくる?公式サイトの見分け方と登録・買ってしまった場合の対処
ダイソンの偽サイトではマフラーが送られてくる?公式サイトの見分け方と登録・買ってしまった場合の対処2020年10月21日、消費者庁は『実在の通信販売サイトをかたった偽サイトなどに関する注意喚起 』を公表しました。通信販売サイト(ECサイト)の被害の中で話題になっている...
あわせて読みたい
WordPressのWebサイト運営で海外からのアクセスが!IPアドレス情報から身元を確認する方法
WordPressのWebサイト運営で海外からのアクセスが!IPアドレス情報から身元を確認する方法あなたは日頃のブログ運営でアクセス解析をしていますでしょうか?WordPressの統計情報を見ていると、アメリカ合衆国からのアクセスが。本当でしょうか。Webサイトの管...

対象端末を特定する

対象端末を特定する

通信の成立可否、通信先の正当性の確認など一通りの確認を行い、エンドユーザに通知する必要があると判断した場合、エンドユーザーの対象端末を特定します。

アクセスログの送信元IPアドレス情報に対象端末のIPアドレスが直接記録されていれば話は早いです。

しかしエンドユーザーの環境でプロキシサーバを経由している場合、アクセスログに記録されているIPアドレスはプロキシサーバのIPアドレスとなってしまいます。

結果、アクセスログの送信元IPアドレス情報では対象端末のIPアドレスがわからない場合があります。

このような状況の場合、アクセスログに記録されたXFFヘッダ情報を確認するようにします。

XFFヘッダには、エンドユーザ環境の末端にある端末のIPアドレス情報が記録されており、プロキシサーバのような中継装置があった場合にも通常消えることはありません。

条件として、エンドユーザ環境のプロキシサーバ側でXFFヘッダを削除しないよう設定すること、そしてアクセスログでXFFヘッダ情報を取得するよう設定する必要があります。

時間厳守でエンドユーザーに通知する

時間厳守でエンドユーザーに通知する

これまでに説明したセキュリティインシデントに関する情報をもとに、エンドユーザに通知を行います。

ここで注意しなければいけないことは、検知から通知までの時間の取り決めている場合、時間を厳守することです。

良かれと思って通知内容事細かに整理している間に、エンドユーザーとの取り決め時間を破ってしまっては意味がありません。

予めメールフォーマットを作成したり、電話連絡帳の常に最新な状態に更新するなど、対応時間の短縮を図るために日ごろから準備することが大切です。

どうしても時間が間に合わない場合は、第一報として調査中の状況を一旦通知し、整理でき次第続報として通知するようにしましょう。

まとめ

まとめ

セキュリティインシデント検知時に必要な対処のポイントは以下の通りです。

  • まずは影響有無を確認する。
  • 影響ありと判断した場合、対象端末の特定を行う。
  • 時間厳守でエンドユーザへの通知を行う。
よかったらシェアしてね!
目次
閉じる