GENZ, Inc.

SIEMテスト外注 SIEMのログ収集から検知・通知までを第三者の目で検証

導入したSIEMが自社のログと規程で意図どおり検知するかは、設定した側だけでは確かめにくいものです。GENZは第三者の視点でテストを設計し検証します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

SIEMツールでよくある不具合

SIEMの不具合は、導入や更改の完了時点では表面化しにくい性質を持ちます。収集と通知の各段階で起きやすい不具合の形を、確認すべき論点とあわせて整理します。

ログは届いているのに正規化後の項目がずれて検知ルールに当たらない

ログの収集は成功しているのに、項目名や型の対応が想定と異なり、相関分析の条件に合致せず検知されません。設定完了の時点では表面化しません。

ログ正規化

タイムゾーンの取り違えで相関分析の時間窓から対象イベントが外れる

ログソースのタイムゾーンの取り違えがあると、イベントの時刻に差異が生じ、相関分析の時間窓の外に出ます。同時に検知すべき事象が別々に扱われます。

相関分析

検知ルールの閾値の境界値で判定が想定と逆になる

検知ルールの閾値の境界値を確認しないと、「ちょうどその値」で判定が想定と逆になります。検知されるべき事象が通過し、合否の判断材料が作れません。

境界値

ルールの改定後に既存ルールの検知が止まりデグレードが残る

検知ルールの追加・改定で回帰テストを省くと、既存ルールの検知が止まるデグレードを見逃します。運用中のインシデントで初めて判明します。

回帰テスト

検知はしているのにアラートが通知先へ到達しない

検知ルールは動いているのに、アラートの通知設定の不備で担当者や連携先へ届かないことがあります。初動対応が始まらず、インシデントの把握が遅れます。

アラート通知
02 RISK

残存した不具合により生じる問題

リリース前の検証で見落とされた不具合が残ったまま稼働すると、検知の遅れ・説明責任の欠落・監査工数の増加という形で表面化します。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

SIEMの検証は、実行前の設計書レビューで大半の不整合を摘発できます。ログ収集からアラート通知まで、定義書と現実の仕様を照合する観点で、検知漏れの芽を稼働前に表面化させます。

規程の監視対象が未検知のまま定着する

検知ルール定義書とセキュリティ規程・脅威シナリオを照合する

検知ルール定義書の判定条件が、組織のセキュリティ規程と想定する脅威シナリオに対応しているかを照合します。規程で求められる監視対象がルール未整備のまま残ると、検知されない状態が定着します。

確認する資料
  • 検知ルール定義書
  • セキュリティ規程
  • 脅威シナリオ
正規化の不整合で検知が働かない

正規化定義とログソースの出力仕様を項目単位で照合する

正規化の定義と各ログソースの出力仕様を、タイムゾーン・文字コード・項目名の単位で照合します。定義と出力の不整合は相関条件に合致しない原因となり、収集成功のまま検知が働かない状態を生みます。

確認する資料
  • 正規化定義書
  • ログ出力仕様書
  • 項目対応表
閾値の不整合で検知漏れが起きる

相関条件の時間窓・閾値とログの発生間隔の実測値を照合する

相関条件の時間窓と閾値が、対象ログの実際の発生間隔・頻度に対して妥当かを実測値で照合します。実態と離れた閾値は、本来検知すべき事象の通過と誤検知の増加のどちらかを招くおそれがあります。

確認する資料
  • 相関条件定義書
  • ログ発生実測値
  • 閾値設定根拠
アラート到着後に対応が起動できない

アラート通知の項目定義と委託先のトリアージ手順書を照合する

アラート通知に含まれる項目の定義と、委託先のトリアージ手順書が前提とする情報を照合します。通知項目が手順の判断材料を満たさない場合、アラートは届いても一次対応が起動できません。

確認する資料
  • 通知項目定義書
  • トリアージ手順書
  • 通知先一覧
監査ごとに証跡整備の工数が発生する

ログ保存期間・アクセス権限の設定書と監査要求事項を照合する

ログの保存期間とアクセス権限の設定書を、監査で要求される証跡の観点と照合します。設定が監査要求を満たさないまま稼働すると、監査時期ごとに記録を遡って整える工数が発生します。

確認する資料
  • 保存期間設定書
  • 権限設定書
  • 監査要求事項
  • 証跡管理台帳
04 TEST DESIGN

動的テストの設計・実行のポイント

動的テストは、収集・正規化、ルール判定、通知到達、負荷と回帰の段に分けて設計します。段ごとに確認内容を切り分けます。

STEP 01 収集・正規化の確認収集の成功だけでは検知を保証しない
どう確かめるか

ログソース単位の収集・正規化をログの実データでユニットテストする

収集が成功していても、正規化の結果が想定と異なれば相関分析の条件に合致せず、検知されないまま設定完了へ進みます。ログソースごとに実データで正規化結果を突合し、差異の有無を確認します。

  • 01ログソースごとの収集粒度と接続設定を確認
  • 02実データで正規化結果を想定形式と突合
  • 03相関分析の条件との適合をログソース単位で検証
OUTPUT収集・正規化の確認結果
STEP 02 検知ルール単体の判定確認「検知されない」の合否基準を事前に定義
どう確かめるか

検知ルールごとの判定を境界値と同値分割で確認する

検知系では「検知されないこと」が正しい場合と誤りの場合が混在します。ルールごとに境界値と同値分割でテストデータを設計し、発火する条件としない条件の両方を合否基準として事前に定義します。

  • 01ルールごとに発火条件と非発火条件を定義
  • 02境界値と同値分割でテストデータを設計
  • 03判定結果を合否基準に照らして記録
OUTPUTルール単位の判定確認結果
STEP 03 検知から通知到達までの通し確認通知の形まで委託先SOCと共有する
どう確かめるか

攻撃・違反の兆候を意図的に発生させて検証し通知の到達まで統合テストする

想定する攻撃・違反の兆候を意図的に発生させて検証し、検知からアラート通知、委託先SOCでの受領までを通しで確認します。通知の形を事前に共有することで、リリース直前の追加作業を防ぎます。

  • 01想定する攻撃・違反の兆候を意図的に発生させて検知を検証
  • 02アラートの通知先と到達時刻を確認
  • 03委託先SOCの受領と一次対応の起動まで通しで検証
OUTPUT通知到達までの通し記録
STEP 04 負荷と回帰テストの確認改定のたびに既存ルールの回帰テストを実施
どう確かめるか

ログ量を増やしたパフォーマンステストと既存ルールの回帰テストを行なう

ログ量の増加で相関処理の応答時間が伸び、アラートの到達が遅れる変化は機能の確認だけでは判明しません。ルール改定時の回帰テストとあわせて、負荷下の動作とデグレードの有無を確認します。

  • 01ログ量を増やして応答時間と通知の遅延を測定
  • 02ルール追加・改定の影響範囲を既存ルールへ確認
  • 03デグレードの有無を回帰テストで検証し記録
OUTPUT負荷・回帰テストの結果
05 RATIONALE

GENZが代行するSIEMのテスト

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 検知の妥当性を確認する工程が手順としてそろいます
  • 検知系の合否基準を定義し項目書が作れます
  • 検証範囲外と理由を示す説明材料が残ります
  • 監査と運用委託先へ同じ記録で説明できます
06 SERVICE

検知ルールから設計するSIEMテスト支援

SIEMのテストは、製品の動作確認ではなく、自社のログと規程に照らして検知が意図どおり働くかを確かめる工程です。GENZは検知ルールを起点にテストを設計し、第三者の視点で検証範囲と結果を整理します。

SVC 01

規程と脅威シナリオからテスト設計を起こす

社内規程と脅威シナリオからテスト観点を洗い出し、静的レビューと動的テストの手順を組み立てます。合否基準と期待値の書き方まで定義します。

リスク要因と優先順位を示す無文字の図解。
SVC 02

検証した範囲と対象外を分けて示す

検証で実施した範囲の一覧に加え、対象外とした範囲と理由を分けて示します。網羅できていない部分を社内で説明できる材料として残します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

既存のQA体制に合わせて不足分を埋める

ベンダー側の試験範囲や既存のQA配置は組み替えず、重複と不足を整理して不足する範囲だけに入ります。体制に合わせた支援形態で進めます。

計画から報告までの流れを示す無文字の図解。
SVC 04

判断・監査・共有に使える報告書で納品

検証結果は、リリース判断の材料、監査の証跡、運用委託先への事前共有に使える報告書として納品します。同じ記録を作り直す手間が減ります。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から納品までの流れ

ご相談から報告書の納品まで、段階を追って進めます。各段階で検証範囲と成果物を確認しながら伴走します。

ヒアリング:ログと検知ルールの棚卸し

ログソースと検知ルールをご共有いただき、検証対象と優先順位を整理します。

テスト設計と見積もりのご提示

合否基準とテスト項目案を作成し、範囲・工数・日程と見積もりをご提示します。

テストの実施と結果の随時共有

検知ルールの動作と通知の到達を検証し、結果は随時ご担当者様へ共有します。

報告書の納品と残存課題の再確認

リリース判断や監査で使える報告書を納品し、残った課題と対応を再確認します。

無料相談で検証の輪郭が固まります

SIEMの検証範囲と優先順位をGENZにご相談ください

検証すべき範囲と優先順位、必要工数の考え方を整理しておくと、社内説明とリリース判断の材料が同時に作れます。ご相談では対象外の切り分けと監査証跡の要否まで確認いただけます。