応用情報技術者 2022年 春期 午後 問01
通信販売サイトのセキュリティインシデント対応に関する次の記述を読んで、設問1~4に答えよ。
R社は、文房具やオフィス家具を製造し、店舗及び通信販売サイトで販売している。
通信販売サイトでの購入には会員登録が必要である。通信販売サイトはECサイト用CMS (Content Management System) を利用して構築している。通信販売サイトの管理及び運用は、R社システム部門の運用担当者が実施していて、通信販売サイトに関する会員からの問合せは、システム部門のサポート担当者が対応している。
〔通信販売サイトの不正アクセス対策〕
通信販売サイトはR社のデータセンタに設置されたルータ、レイヤ2スイッチ、ファイアウォール(以下、FWという)、IPS (Intrusion Prevention System) などのネットワーク機器とCMSサーバ、データベースサーバ、NTPサーバ、ログサーバなどのサーバ機器と各種ソフトウェアで構成されている。通信販売サイトは、会員情報などの個人情報を扱うので、様々なセキュリティ対策を実施している。R社が通信販売サイトで実施している不正アクセス対策(抜粋)を表1に示す。

IPSは不正パターンをシグネチャとして登録するシグネチャ型であり、シグネチャは毎日自動的に更新される。
項番4の対策をCMSサーバ及びデータベースサーバ上で行うことで不正アクセスを受けにくくしている。R社では、①項番5の対策を実施するために、OS、ミドルウェア及び CMS で利用している製品について必要な管理を実施して、脆弱性情報及び修正プログラムの有無を確認している。また、項番 6 の対策で利用している b は、ソフトウェア型を導入していて、シグネチャは R 社の運用担当者が、システムへの影響がないことを確認した上で更新している。
〔セキュリティインシデントの発生〕
ある日、通信販売サイトが改ざんされ、会員が不適切なサイトに誘導されるというセキュリティインシデントが発生した。通信販売サイトを閉鎖し、ログサーバが収集したログを解析して原因を調査したところ、特定のリクエストを送信すると、コンテンツの改ざんが可能となる CMS の脆弱性を利用した不正アクセスであることが判明した。
R 社の公式ホームページでセキュリティインシデントを公表し、通信販売サイトの復旧と CMS の脆弱性に対する暫定対策を実施した上で、通信販売サイトを再開した。
今回の事態を重く見たシステム部門の S 部長は、セキュリティ担当の T主任に今回のセキュリティインシデント対応で確認した事象と課題の整理を指示した。
〔セキュリティインシデント対応で確認した事象と課題〕
T主任は関係者から、今回のセキュリティインシデント対応について聞き取り調査を行い、確認した事象と課題を表2にまとめて、S 部長に報告した。

S部長はT主任からの報告を受け、セキュリティインシデントを専門に扱い、インシデント発生時の情報収集と各担当へのインシデント対応の指示を行うインシデント対応チームを設置するとともに、今回確認した課題に対する再発防止策の立案をT主任に指示した。
〔再発防止策〕
T主任は、再発防止のために、表2の各項目への対策を実施することにした。
項番1については、CMSサーバを構成するOS、ミドルウェア及びCMSの脆弱性情報の収集や修正プログラムの適用は実施していたが、②今回の不正アクセスのきっかけとなった脆弱性に対応する修正プログラムはまだリリースされていなかった。このような場合、OS、ミドルウェア及びCMSに対する③暫定対策が実施可能であるときは、暫定対策を実施することにした。
項番2については、bの運用において、新しいシグネチャで更新した際に、デフォルト設定のセキュリティレベルが厳し過ぎて正常な通信まで遮断してしまうcを起こすことがあり、運用担当者はしばらくシグネチャを更新していなかったことが判明した。運用担当者のスキルを考慮して、運用担当者によるシグネチャ更新が不要なクラウド型bサービスを利用することにした。
項番3については、dがセキュリティインシデントの影響度を判断し、サイト閉鎖を指示するルールを作成して、サイト閉鎖までの時間を短縮するようにした。
項番4については、サイトの改ざんが行われたことを検知する対策として、様々な検知方式の中から未改の改ざんパターンによるサイト改ざんも検知可能であること、誤って検知することが少ないことから、ハッシュリスト比較型を利用することにした。
項番5については、④各ネットワーク機器、サーバ機器及び各種ソフトウェアからログを収集し時系列などで相関分析を行い、セキュリティインシデントの予兆や痕跡を検出して管理者へ通知するシステムの導入を検討することにした。
T主任は対策を取りまとめてS部長に報告し、了承された。
設問1:
表1中のaに入れる適切な字句を5字以内で答えよ。
模範解答
a:サービス
解説
解答の論理構成
- 問題文には、サーバのハードニング施策として「“不要なアカウントの削除、不要な a の停止”」と記載されています。
- OS やミドルウェアのセキュリティ設定では、 未使用の常駐プログラムや通信機能を停止 することが基本事項です。
- これらは一般に “サービス” と総称されます。具体例としては、telnet や ftp など、利用していないネットワークサービスを無効化する対策が該当します。
- よって、空欄 a には「サービス」を入れるのが最も自然です。
誤りやすいポイント
- 「プロセス」「ポート」なども停止対象としてよく挙がるため混同しやすいですが、問題文は “停止” という動作と “アカウント削除” と並列に列挙しており、管理単位として適切なのは “サービス” です。
- “デーモン” という専門語もありますが、OS に依存した呼称で汎用性が低く、情報処理試験では “サービス” が標準表現です。
- “機能” と答えると抽象度が高く、具体的なシステム管理用語として不足します。
FAQ
Q: サービスを停止するときにまず確認すべきことは何ですか?
A: そのサービスを利用するアプリケーションやユーザが存在しないこと、停止後に業務影響が出ないことを事前に検証します。
A: そのサービスを利用するアプリケーションやユーザが存在しないこと、停止後に業務影響が出ないことを事前に検証します。
Q: サービス停止とファイアウォールでのポート遮断はどう使い分けますか?
A: 原則として、使わないサービスはソフトウェアごと停止し、どうしても停止できない場合にネットワーク側でポートを閉じて多層防御を行います。
A: 原則として、使わないサービスはソフトウェアごと停止し、どうしても停止できない場合にネットワーク側でポートを閉じて多層防御を行います。
Q: Windows と Linux でサービス停止のコマンドが異なりますか?
A: はい。Windows では services.msc や sc stop、Linux では systemctl stop など、OS によって操作方法が異なります。
A: はい。Windows では services.msc や sc stop、Linux では systemctl stop など、OS によって操作方法が異なります。
関連キーワード: 最小権限, ハードニング, ポート管理, サービス停止
設問2:
本文及び表1、2中のbに入れる適切な字句をアルファベット3字で答えよ。
模範解答
b:WAF
解説
解答の論理構成
- 手掛かりとなる記述
- 表1 項番6 に「CMSサーバ上のWebアプリケーションへの攻撃を、b を利用して検知し防御」とあります。Webアプリケーションへの攻撃を検知・防御する専用機能を持つ代表的な機器は Web Application Firewall です。
- シグネチャ更新との関係
- 表2 項番2 に「b のシグネチャが更新されていなかった。」とあるように、b はシグネチャ更新型の対策製品であることが示唆されています。WAF も IPS と同様にシグネチャを用いて攻撃パターンを識別するため、条件に合致します。
- 運用上の課題とクラウド型サービス
- 再発防止策で「運用担当者によるシグネチャ更新が不要なクラウド型bサービスを利用」と述べられており、昨今多くのベンダが提供するクラウド型 WAF と符合します。
- 誤検知(過検知)問題
- 「デフォルト設定のセキュリティレベルが厳し過ぎて正常な通信まで遮断してしまうc」は、WAF 運用で典型的な“誤検知”の説明です。
- 以上を総合すると、b に入るのは “WAF” であると論理的に導けます。
誤りやすいポイント
- IPS と混同する
いずれもシグネチャを用いますが、表1 項番1 ですでに「IPS」が明示されており、b とは別物であると分かります。 - FW(ファイアウォール)と誤解する
FW はポート/アドレス単位のフィルタリングが主で、Web アプリケーション層の特定攻撃を防ぐ機能は基本的に備えていません。 - WAF =アプライアンス限定と考える
問題文には「ソフトウェア型」や「クラウド型」といった実装形態の記述があるため、形態の違いで惑わされないことが重要です。
FAQ
Q: IPS があるのに WAF を別途導入する理由は何ですか?
A: IPS はネットワーク層~トランスポート層の攻撃検知が主で、SQLインジェクションや XSS などアプリケーション層特有の攻撃を十分にカバーできません。WAF は HTTP/HTTPS の内容を解析して Web アプリケーションを保護します。
A: IPS はネットワーク層~トランスポート層の攻撃検知が主で、SQLインジェクションや XSS などアプリケーション層特有の攻撃を十分にカバーできません。WAF は HTTP/HTTPS の内容を解析して Web アプリケーションを保護します。
Q: WAF のシグネチャを更新しないとどんなリスクがありますか?
A: 新しい攻撃手法や脆弱性を突くリクエストを検知できず、ゼロデイに近い攻撃を許してしまうリスクが高まります。
A: 新しい攻撃手法や脆弱性を突くリクエストを検知できず、ゼロデイに近い攻撃を許してしまうリスクが高まります。
Q: クラウド型 WAF を利用する利点は?
A: ベンダ側でシグネチャ更新や性能拡張が行われるため、運用負荷と誤設定によるセキュリティホールを低減できます。
A: ベンダ側でシグネチャ更新や性能拡張が行われるため、運用負荷と誤設定によるセキュリティホールを低減できます。
関連キーワード: WAF, シグネチャ, クラウドサービス, Webアプリケーション, 誤検知
設問3:
本文中の下線①で管理すべき内容を解答群の中から全て選び、記号で答えよ。
解答群
ア:販売価格
イ:バージョン
ウ:名称
エ:ライセンス
模範解答
イ、ウ
解説
解答の論理構成
-
引用:
「①項番5の対策を実施するために、OS、ミドルウェア及び CMS で利用している製品について必要な管理を実施して、脆弱性情報及び修正プログラムの有無を確認している。」
──脆弱性情報と修正プログラムを確認するには、対象ソフトウェアが“何であるか”と“どの版であるか”を把握している必要があります。 -
必要な管理情報の洗い出し
• どの製品なのか → 「名称」
• どのリリースなのか → 「バージョン」
これらを把握しておくことで、公開される脆弱性情報の「対象ソフトウェア名」や「影響を受けるバージョン」と自社環境を照合できます。 -
不要な情報の判断
• 「販売価格」:脆弱性有無の確認に無関係です。
• 「ライセンス」:ライセンス形態は法的・運用的管理項目であり、脆弱性の発見・適用判断には直接結び付きません。 -
よって、解答群から選ぶべきは「イ:バージョン」「ウ:名称」となります。
誤りやすいポイント
- ライセンス情報をセキュリティ管理に含めたくなる
→ ライセンスはコンプライアンス管理の範疇であり、脆弱性対応フローとは別物です。 - 価格情報も管理ドキュメントに載せている場合がある
→ コスト管理に用いるだけで、脆弱性の影響有無判定には寄与しません。 - “必要な管理”を「全ての管理項目」と誤読し、選択肢を広げてしまう
→ ①は脆弱性情報・修正プログラム確認のための管理に限定されています。
FAQ
Q: なぜバージョン管理がそれほど重要なのですか?
A: 脆弱性情報は「製品名」と「影響を受けるバージョン」をセットで公開されます。自社で稼働しているバージョンを正確に把握できなければ、影響の有無を迅速に判定できません。
A: 脆弱性情報は「製品名」と「影響を受けるバージョン」をセットで公開されます。自社で稼働しているバージョンを正確に把握できなければ、影響の有無を迅速に判定できません。
Q: オープンソース CMS ならライセンスも関係あるのでは?
A: ライセンス遵守は重要ですが、脆弱性対応フローには直接影響しません。ここで問われているのは“脆弱性確認”のための最低限の管理項目です。
A: ライセンス遵守は重要ですが、脆弱性対応フローには直接影響しません。ここで問われているのは“脆弱性確認”のための最低限の管理項目です。
Q: 価格情報は資産管理台帳に載せる場合がありますが?
A: 資産管理と脆弱性対応は目的が異なります。脆弱性有無の判断に価格は不要なので、本設問の答えとしては除外されます。
A: 資産管理と脆弱性対応は目的が異なります。脆弱性有無の判断に価格は不要なので、本設問の答えとしては除外されます。
関連キーワード: パッチ管理, 脆弱性情報, バージョン管理, 改ざん検知, シグネチャ
設問4:〔再発防止策〕について、(1)〜(5)に答えよ。
(1)本文中の下線②の状況を利用した攻撃の名称を8字以内で答えよ。
模範解答
ゼロデイ攻撃
解説
解答の論理構成
- 【問題文】の下線部②
「②今回の不正アクセスのきっかけとなった脆弱性に対応する修正プログラムはまだリリースされていなかった」
とあります。 - 修正プログラム(パッチ)が「まだリリースされていなかった」=公開されていない、または配布前の脆弱性を突く攻撃を表す用語は、一般に「ゼロデイ攻撃」です。
- したがって、攻撃名称を 8 文字以内で答える設問に対し、「ゼロデイ攻撃」が成立します。
誤りやすいポイント
- 「パッチが適用されていない」だけで判断し、既知脆弱性の「既知攻撃」や「1-day攻撃」と混同する。問題文は「まだリリースされていなかった」と明示しており、“未知”である点が決定的です。
- 「標的型攻撃」「APT」など広義の攻撃を連想してしまう。これらは攻撃手法全体を指し、パッチ未公開かどうかは要件ではありません。
- 「ゼロデイ“脆弱性”」と書いてしまう。設問は「攻撃の名称」を問うため、「ゼロデイ攻撃」が正解です。
FAQ
Q: “ゼロデイ脆弱性”と“ゼロデイ攻撃”はどう違いますか?
A: 脆弱性自体を指すのが「ゼロデイ脆弱性」、その脆弱性を突いて実際に行われる行為が「ゼロデイ攻撃」です。設問は「攻撃名」を問うため後者が該当します。
A: 脆弱性自体を指すのが「ゼロデイ脆弱性」、その脆弱性を突いて実際に行われる行為が「ゼロデイ攻撃」です。設問は「攻撃名」を問うため後者が該当します。
Q: ゼロデイ攻撃に対する一般的な防御策はありますか?
A: 仮想パッチ、挙動監視型セキュリティ、WAF の導入、脆弱性情報の早期収集と暫定対策などが挙げられます。
A: 仮想パッチ、挙動監視型セキュリティ、WAF の導入、脆弱性情報の早期収集と暫定対策などが挙げられます。
Q: 「1-day攻撃」とは何が違いますか?
A: 「1-day攻撃」はパッチが公開された“翌日以降”、適用が終わっていない環境を狙う攻撃です。パッチ未公開の段階を狙う「ゼロデイ攻撃」と区別されます。
A: 「1-day攻撃」はパッチが公開された“翌日以降”、適用が終わっていない環境を狙う攻撃です。パッチ未公開の段階を狙う「ゼロデイ攻撃」と区別されます。
関連キーワード: 脆弱性, パッチ, シグネチャ, 暫定対策, ハッシュ比較
設問4:〔再発防止策〕について、(1)〜(5)に答えよ。
(2)本文中の下線③について、暫定対策を実施可能と判断するために必要な対応を解答群の中から選び、記号で答えよ。
解答群
ア:過去の修正プログラムの内容を確認
イ:修正プログラムの提供予定日を確認
ウ:脆弱性の回避策を調査
エ:同様の脆弱性が存在するソフトウェアを確認
模範解答
ウ
解説
解答の論理構成
-
手順の前提確認
【問題文】では、②「今回の不正アクセスのきっかけとなった脆弱性に対応する修正プログラムはまだリリースされていなかった」とあります。よって恒久対策(パッチ適用)は現時点で不可能です。 -
代替手段の必要性
③「暫定対策が実施可能であるときは、暫定対策を実施することにした」と明記されています。暫定対策が“可能かどうか”を判断するには、その脆弱性に対してどのような回避策(ワークアラウンド)が存在するかを把握する必要があります。 -
解答群の突合
- ア「過去の修正プログラムの内容を確認」
過去のパッチが今回の未公開脆弱性を覆う保証はなく、暫定対策可否の判定材料になりにくい。 - イ「修正プログラムの提供予定日を確認」
提供時期を把握しても“暫定対策を実施できるか”の判断には直結しない。 - ウ「脆弱性の回避策を調査」
まさに暫定対策が存在するかどうかを確認する行為であり、③の判断条件に合致する。 - エ「同様の脆弱性が存在するソフトウェアを確認」
影響範囲の把握には役立つが、“暫定対策が可能か”の判断とは別問題。
- ア「過去の修正プログラムの内容を確認」
-
結論
暫定対策の可否判断に直結する対応は「ウ:脆弱性の回避策を調査」であり、模範解答と一致します。
誤りやすいポイント
- 「提供予定日が分かれば暫定策は不要」と早合点し、イを選択してしまう。パッチ公開までの期間にも攻撃は続くため暫定策は不可欠です。
- “過去のパッチ=全部入り”と誤解し、アを選ぶケース。パッチは個別脆弱性対応であり、未公開分は含まれません。
- “同様の脆弱性”という言葉に釣られ、エを選択。これは影響調査であり暫定策の有無判断とは別フェーズです。
FAQ
Q: 暫定対策と恒久対策の違いは何ですか?
A: 暫定対策は修正プログラムが入手できない・適用できない間の一時的な回避策です。恒久対策は正式な修正プログラムの適用や設定変更による完全対応を指します。
A: 暫定対策は修正プログラムが入手できない・適用できない間の一時的な回避策です。恒久対策は正式な修正プログラムの適用や設定変更による完全対応を指します。
Q: 回避策はどこから入手すれば良いのですか?
A: ベンダのセキュリティアドバイザリ、CERT/CC、JPCERT/CC などの脆弱性情報サイトが一次情報源になります。運用ルールとして定期モニタリングを行うことが重要です。
A: ベンダのセキュリティアドバイザリ、CERT/CC、JPCERT/CC などの脆弱性情報サイトが一次情報源になります。運用ルールとして定期モニタリングを行うことが重要です。
Q: 暫定対策実施後も他にすべきことはありますか?
A: 監視の強化、ログの重点的レビュー、同種システムへの横展開などです。暫定対策は恒久的な安全を保証しないため、パッチ公開後には必ず適用してください。
A: 監視の強化、ログの重点的レビュー、同種システムへの横展開などです。暫定対策は恒久的な安全を保証しないため、パッチ公開後には必ず適用してください。
関連キーワード: 脆弱性管理, ワークアラウンド, パッチマネジメント, セキュリティアドバイザリ, リスク低減
設問4:〔再発防止策〕について、(1)〜(5)に答えよ。
(3)本文中のcに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:過検知
イ:機器故障
ウ:未検知
エ:予兆検知
模範解答
c:ア
解説
解答の論理構成
- 【問題文】には、
“新しいシグネチャで更新した際に、デフォルト設定のセキュリティレベルが厳し過ぎて正常な通信まで遮断してしまうcを起こすことがあり”
とあります。 - 「正常な通信まで遮断してしまう」状態は、攻撃ではない通信を攻撃と誤判定する “false positive” を示しています。日本語では「過検知」と呼びます。
- 解答群を見ると、
ア:過検知
イ:機器故障
ウ:未検知
エ:予兆検知
のうち、正常通信を誤って検知する意味を持つのは「過検知」のみです。 - したがって c に入る適切な語は「過検知」であり、記号は「ア」です。
誤りやすいポイント
- 「未検知」と取り違える
未検知は true attack を見逃す false negative であり、文中の「正常な通信まで遮断」とは逆の意味です。 - 「予兆検知」と混同する
予兆検知は潜在的な異常の早期発見を指し、誤判定の多少には直接関係しません。 - ハードウェア障害だと考えて「機器故障」を選ぶ
文脈はシグネチャ更新による誤動作であり、物理故障ではありません。
FAQ
Q: 過検知を減らすにはどのような運用が有効ですか?
A: テスト環境で新シグネチャを検証し、許可すべきトラフィックをホワイトリスト登録してから本番反映する方法が効果的です。
A: テスト環境で新シグネチャを検証し、許可すべきトラフィックをホワイトリスト登録してから本番反映する方法が効果的です。
Q: 未検知との違いを簡潔に教えてください。
A: 過検知は “正常な通信を攻撃と誤判定” 、未検知は “攻撃を正常と誤判定して見逃す” ことです。
A: 過検知は “正常な通信を攻撃と誤判定” 、未検知は “攻撃を正常と誤判定して見逃す” ことです。
Q: クラウド型に切替えると過検知は解消されますか?
A: 自動チューニング機能やベンダによるシグネチャ最適化で低減は期待できますが、ゼロにはなりません。運用側のポリシ確認は依然として必要です。
A: 自動チューニング機能やベンダによるシグネチャ最適化で低減は期待できますが、ゼロにはなりません。運用側のポリシ確認は依然として必要です。
関連キーワード: シグネチャ更新, 過検知, クラウド型WAF, フォールスポジティブ, トラフィック遮断
設問4:〔再発防止策〕について、(1)〜(5)に答えよ。
(4)本文中のdに入れる適切な組織名称を本文中の字句を用いて15字以内で答えよ。
模範解答
d:インシデント対応チーム
解説
解答の論理構成
- 【問題文】「S部長は、セキュリティインシデントを専門に扱い、インシデント発生時の情報収集と各担当へのインシデント対応の指示を行う インシデント対応チーム を設置」と記載されています。
- 【問題文】再発防止策「項番3については、d がセキュリティインシデントの影響度を判断し、サイト閉鎖を指示するルールを作成」とあります。
- 影響度を判断し指示を出す役割は、前段で設置された インシデント対応チーム に合致します。
- したがって d には「インシデント対応チーム」をそのまま充てるのが妥当です。
誤りやすいポイント
- 「システム部門」や「S部長」と誤答する例が多いですが、【問題文】には“判断・指示”役として新たに設置された組織が明示されています。
- 「情報システム部」など既存組織を当てはめると、設問条件「本文中の字句を用いて」に抵触します。
- 「CSIRT」と一般名詞で書くと、本文に同語が登場しないため不適合です。
FAQ
Q: 既にある部署名ではだめですか?
A: だめです。本文で“S部長は…設置”とある新組織が対象だからです。
A: だめです。本文で“S部長は…設置”とある新組織が対象だからです。
Q: 「インシデント対応班」のような表現は?
A: 本文にその表現はなく、字句が一致しません。
A: 本文にその表現はなく、字句が一致しません。
Q: 設問は何文字以内ですが、語尾に「チーム」は要りますか?
A: 要ります。「インシデント対応チーム」が本文に登場する完全な名称だからです。
A: 要ります。「インシデント対応チーム」が本文に登場する完全な名称だからです。
関連キーワード: インシデント対応, 影響度評価, サイト閉鎖, 組織体制, ルール策定
設問4:〔再発防止策〕について、(1)〜(5)に答えよ。
(5)本文中の下線④のシステム名称をアルファベット4字で答えよ。
模範解答
SIEM
解説
解答の論理構成
-
キーワードの抽出
- 本文の下線④には、次の記述があります。
「④各ネットワーク機器、サーバ機器及び各種ソフトウェアからログを収集し時系列などで相関分析を行い、セキュリティインシデントの予兆や痕跡を検出して管理者へ通知するシステム」 - 重要語句は「ログを収集」「時系列などで相関分析」「インシデントの予兆や痕跡を検出」「管理者へ通知」です。
- 本文の下線④には、次の記述があります。
-
該当するセキュリティ製品・技術の照合
- これらの機能を備えた代表的なシステムは、Security Information and Event Management ― 略して「SIEM」と呼ばれます。
- SIEM は多様なログを一元的に集約し、相関分析エンジンによって異常を検出、アラートを発報することで知られています。
-
他候補との比較
- 「IDS」「IPS」は主にパケットレベルの不正検知・防御であり、ログを横断的に相関分析する説明と一致しません。
- 「WAF」は Web アプリケーション層の防御装置であり、ログ分析システムではありません。
- 「SOC」は組織体(運用センター)の名称であってシステム名称ではありません。
-
結論
- 以上より、下線④のシステム名称は「SIEM」と判断できます。
誤りやすいポイント
- 「IPS もログを扱うのでは?」と混同するケース
IPS はリアルタイム防御装置であり、広範なログ相関分析という④の説明とは役割が異なります。 - 「SOC=運用センター」をシステム名と誤解するケース
SOC は組織や部門の名称であってツール名ではありません。 - 「WAF のログ分析機能」を拡大解釈するケース
WAF は Web へ特化しており、ネットワーク機器全体のログ相関分析という要件を充たしません。
FAQ
Q: SIEM はインシデントの「予兆」も検出できるのですか?
A: はい。異常値検知や振る舞い分析ルールを設定することで、攻撃準備段階の不審な挙動をアラートできます。
A: はい。異常値検知や振る舞い分析ルールを設定することで、攻撃準備段階の不審な挙動をアラートできます。
Q: SIEM 導入だけで課題⑤の「原因調査に時間が掛かる」を完全に解決できますか?
A: 効果は大きいですが、ルールチューニングや運用体制(SOC など)を整備しなければ、分析スピードは向上しません。
A: 効果は大きいですが、ルールチューニングや運用体制(SOC など)を整備しなければ、分析スピードは向上しません。
Q: ログの保存期間はどの程度が望ましいですか?
A: 一般には 1 年以上が推奨されます。長期保存により、遅延して発覚したインシデントの追跡が可能になります。
A: 一般には 1 年以上が推奨されます。長期保存により、遅延して発覚したインシデントの追跡が可能になります。
関連キーワード: SIEM, 相関分析, ログ管理, インシデント検知, アラート通知


