セキュリティエンジニアという仕事

• SIEM(さまざまな機器のログを1か所に集めて、怪しい動きを自動で警告してくれるツール)が出す警告(アラート)を確認し、本物の攻撃なのか誤検知なのかを見分ける(例: 深夜に海外から管理者アカウントへ何度もログインが試みられていないかを調べる)
• 不正アクセスやウイルス感染の疑いが見つかったとき、被害を広げないための初動対応(例: 該当のパソコンをネットワークから切り離す、パスワードを変更してもらう)
• 事故が起きたときの経緯の記録と、開発・情報システム・広報・法務など関係部署への報告の取りまとめ
• 誤検知が多い警告の条件を見直し、本当に危ないものだけが鳴るように監視ルールを調整する

午前は、前日の夜から朝までに届いたアラートを確認し、「すぐ調べるもの」「様子を見るもの」「問題なしとして閉じるもの」に振り分けます。午後は、気になったアラートの詳しい調査(関連するログをたどって、誰が・いつ・どこから何をしたのかを組み立てる)や、監視ルールの調整、開発チームや情報システム部門との打ち合わせに時間を使います。自社で24時間体制を組める会社は多くなく、夜間は外部の監視サービスに任せたり、呼び出し待機(オンコール)にしたりする体制が見られます。

届くアラートの件数は、会社の規模や監視ツールの設定によって大きく異なります。そのため、誤検知を減らして調べるべきものに集中できるようにする調整そのものが、重要な仕事の一部です。

成果物とツールの対応では、ログの検索・集計にはSIEMの検索機能とExcel(調査結果の件数集計)、事故の経緯をまとめる報告書にはWordや社内の記録ツールでの時系列の整理力が求められます。

• 突発的な呼び出しや、夜間・休日の対応に強いストレスを感じる人
• 地道なログの確認や、同じ種類のアラートの繰り返しの対応が苦手な人
• 最新の攻撃手法を学び続けることに負担を感じる人

• CSIRTのリーダー・セキュリティ責任者(CISO=最高情報セキュリティ責任者 候補)へ
• 脆弱性診断(システムの弱点を調べる検査)や、プロダクトセキュリティ(自社サービスそのものの安全性を開発段階から高める仕事)など、より攻撃・設計寄りの領域へ

• SIEM(さまざまな機器のログを集めて、怪しい動きを自動で警告するツール)やEDR(パソコンやサーバー上の不審な動きを検知して知らせるソフト)が出す警告の分析(例: 本物の攻撃か、社員の通常操作による誤検知かを見分ける)
• 攻撃と判断した場合に、クライアント企業へ状況と推奨する対応(例: 感染したパソコンをネットワークから切り離してください)を連絡する
• クライアントごとの環境に合わせた監視ルールの追加・調整(例: 誤検知の多い警告を減らす)
• 月次などの定期レポートの作成と、クライアントへの報告会

日勤・夜勤の交代制で、24時間365日の監視体制を回すのが一般的です。1回の勤務では、担当するクライアント複数社の警告画面を順番に確認し、重要度の高いものから調べていきます。調べた内容は、決まった手順書(プレイブック)に沿って記録し、必要なら上位のアナリストに引き継ぎます。

担当するクライアント数は、会社やチーム体制によって数社〜数十社と幅があります(具体的な件数は求人票には載らないことが多く、面接で確認するのが確実です)。

成果物とツールの対応では、調査結果の記録にはチケット管理ツールへの正確な入力、月次レポートにはExcelでの件数集計とPowerPointでの報告資料の構成力が求められます。

• 夜勤を含む不規則な勤務が体調的に合わない人
• 一つのシステムをじっくり深く理解したい人
• 決まった手順やルールの中で動くことに窮屈さを感じる人

• 上位のアナリスト・インシデント対応の専門職へ
• ペネトレーションテスター(攻撃者になりきって、実際に侵入できるかを試す担当)やセキュリティコンサルタントへ
• 事業会社(自社サービスを運営する会社)の社内SOC・CSIRT(社内で起きたセキュリティ事故に対応する専門チーム)への転身も

• 新機能やサービスのリリース前に、自社のWebサイトやアプリの脆弱性診断を行う(例: 入力欄に不正な文字列を送って、情報が盗めてしまわないかを確かめる)
• 見つけた弱点の危険度を評価し、開発チームへ報告して、修正後に直っているかを再確認する
• 外部の診断会社に診断を依頼する際の発注管理と、納品された結果のレビュー
• 診断の手順書づくりや、診断ツールの導入によって診断作業の内製化(自社で行えるようにすること)を進める

午前は、診断を依頼された機能の仕様を確認し、どこが狙われそうかを整理します。午後は、診断ツールを実行して結果を確認したうえで、ツールでは見つけにくい部分(ログインの仕組み、購入の流れなど)を手動で試します。診断の合間には、開発チームに結果を説明して修正方針を相談します。

診断の件数や期間は、システムの規模や会社の体制によって大きく変わります(1回の診断が数日で終わる場合もあれば、数週間かかる場合もあります)。自社に専任チームがある会社は多くないため、診断以外にも、開発者へのセキュリティ相談の窓口を兼ねることがあります。

成果物とツールの対応では、診断報告書の作成にWord、診断結果の一覧管理にExcel、通信の中身を確認して試すためにBurp Suite(通信を中継して内容を見たり書き換えたりする診断用ツール)などの扱いが求められます。

• 指摘して終わりにしたい、開発チームとの調整が負担な人
• さまざまな会社のシステムを幅広く経験したい人
• 地道な再現確認や報告書づくりが苦手な人

• 社内のセキュリティリーダー・プロダクトセキュリティ(自社サービスの安全性を開発段階から高める仕事)の責任者へ
• セキュリティ専門会社(セキュリティ対策を専門に提供する会社)のペネトレーションテスター(攻撃者になりきって、実際に侵入できるかを試す担当)や、より高度な攻撃検証の専門職へ

• 依頼元企業のWebサイトやスマートフォンアプリの脆弱性診断(例: ログイン画面や入力欄に細工したデータを送り、他人の情報が見えてしまわないかを調べる)
• ネットワークやサーバーに対するペネトレーションテスト(例: 外部から侵入できる穴がないか、侵入できた場合にどこまで内部へ入り込めるかを実際に試す)
• 診断結果を報告書にまとめ、弱点ごとの危険度と、直し方を依頼元に説明する
• 診断ツールの調整や、新しい攻撃手法の調査・検証(社内の技術共有)

診断期間中は、午前に診断ツールの実行や結果の確認を行い、午後はツールで拾いきれない部分を手作業で試します。診断が終わると、結果を整理して報告書を作成し、依頼元に報告会で説明する流れになります。複数の案件を並行して担当することも多く、診断期間と報告書作成の時期がずれるため、納期の管理が重要です。

1つの案件にかかる期間は、システムの規模によって数日〜数週間と幅があります。担当する案件数は会社や役職によって異なります。

成果物とツールの対応では、診断にBurp Suite(通信を中継して内容を見たり書き換えたりする診断用ツール)などの扱い、報告書の作成にWord、診断結果の整理にExcel、報告会の資料づくりにPowerPointでの構成力が求められます。

• 報告書の作成など、文章にまとめる作業が苦手な人
• 納期に合わせて複数案件を並行することに強いストレスを感じる人
• 一つの自社サービスにじっくり関わり続けたい人

• 高度な攻撃検証(レッドチーム=攻撃者役として組織の防御力を試す専門チーム)や研究職へ
• セキュリティコンサルタント・診断チームのリーダーへ
• 事業会社(自社サービスを運営する会社)の社内診断担当や、プロダクトセキュリティ(自社サービスの安全性を開発段階から高める仕事)への転身も

• 新機能の設計書を見て、攻撃されそうな箇所を洗い出す(脅威モデリング。例: 「決済画面なら、金額を書き換えられないか」を設計段階で考える)
• ソースコードを自動で検査して危険な書き方を見つけるツール(SAST)を、開発の流れ(CI=コードを更新するたびに自動でテストや検査を行う仕組み)に組み込む
• 外部から寄せられた脆弱性の報告を受け付け、影響を調べて修正の優先順位を決める(PSIRTとしての対応)
• 開発者向けのセキュリティ勉強会や、安全なコードの書き方のガイドラインづくり

午前は、開発チームの定例会議に参加し、これから作る機能のセキュリティ上の注意点を伝えます。午後は、設計レビューやツールの検査結果の確認、脆弱性の報告への対応など、自分の持ち場に合わせた作業を行います。コードを読んで修正案を示したり、必要ならセキュリティ関連のコードを自分で書いたりする場面もあります。

担当するチームの数やサービスの数は、会社の規模や体制によって差が大きく、少人数のセキュリティチームで複数のプロダクトを見る場合もあります。

成果物とツールの対応では、設計レビューの指摘にはドキュメントツール(Notionなど)やExcelでのチェックリスト管理、ツールの検査結果の分析にはGitHubなどのコード管理サービスの知識、開発者向けの勉強会資料にはPowerPointでの構成力が求められます。

• 開発者とのやり取りや交渉を避けたい人
• 「ルールを守らせる」役割に徹したい人
• コードや設計の話に興味が持てない人

• プロダクトセキュリティの責任者・CISO(最高情報セキュリティ責任者)候補へ
• セキュリティアーキテクト(安全な全体設計を担う専門職)へ
• セキュリティベンダー(セキュリティ対策を専門に提供する会社)でのコンサルタントへの転身も

• クライアントの新機能の設計書を確認し、攻撃されそうな箇所と対策を助言する(例: 「会員情報の画面では、他人のIDを入れて見られないようにしましょう」と具体的に指摘する)
• クライアントの開発の流れに、セキュリティの自動検査を組み込む支援(DevSecOps。例: コードを更新するたびに、危険な書き方を自動で調べる仕組みを整える)
• 安全なコードの書き方のガイドライン・規程類の整備支援
• クライアントの開発者向けのセキュリティ研修の実施

午前は、クライアントの開発チームとの打ち合わせや、設計書のレビューに時間を使います。午後は、レビューの指摘をまとめた資料の作成や、ツール導入の設定支援、研修の準備を行います。案件によっては、クライアントの現場に出向く形で、開発チームの一員のように入り込んで支援することもあります。

担当するクライアント数は、案件の規模や支援の深さによって異なり、複数社を並行して見る場合もあれば、1社に集中して支援する場合もあります。

成果物とツールの対応では、設計レビューの指摘資料にWordやExcel、経営層や開発責任者への提案にはPowerPointでの構成力、ツール導入の支援にはGitHubなどのコード管理サービスの知識が求められます。

• 自分でサービスを作り続けて、その成長を見届けたい人
• 提案資料の作成や、会議での調整が苦手な人
• クライアントごとに環境や進め方が変わることに負担を感じる人

• セキュリティコンサルタントのリーダー・マネージャーへ
• 事業会社(自社サービスを運営する会社)のプロダクトセキュリティ責任者・CISO(最高情報セキュリティ責任者)候補へ