セキュリティ担当者のためのセキュリティエンジニアとして活躍するために身につけておきたいSC思考

セキュリティ担当者のためのセキュリティエンジニアとして活躍するために身につけておきたいSC思考

2025, Jul 12    

様々なセキュリティサービス、セキュリティツール、セキュリティに対する知識をこれまでインプットし、このブログでアウトプットしてきました。しかしこの本はセキュリティインシデントの多くは技術的欠陥ではなく、人間の判断ミスで起こると言います。 それはセキュリティインシデントの上位がずっとフィッシング詐欺であることからも明らかです。しかし見落としてはいけないのは、一般的な従業員だけでなくセキュリティエンジニアも人間であること。人間の弱さを持っています。 仮に機器の操作ログを記録し、警告メッセージが出たとします。最初はしっかり調べていても、「いつもの従業員の月末月初の操作だろう」と慣れからスルーするようになってしまう。あるいは「監視ツールを導入すること」という手段自体が目的化してしまい、導入、初期設定して後は放置(本当は放置したいわけではないのですが、他の仕事が忙しくて手が回らない)。結果としてセキュリティインシデントを招いてしまう、というのは想像できる話です。

タイトルの「SC思考」は「セキュリティ思考」の略で、筆者の造語です。筆者の造語です。セキュリティ思考とは、技術について知っていることを前提の上で「どのように考えるべきか?」「どの対策が本当に必要なのか?」を考える思考になります。そのポイントは

1.攻撃者視点を持つ セキュリティエンジニアは組織のセキュリティの弱点を知っています。ええ、よーく知っていますとも。世間でセキュリティ事故のニュースが報道される時、「あの会社はダメだなぁ」などとは決して思いません、明日は我が身、まだターゲットになっていないだけだ、と思います。 セキュリティにおける攻撃者、防御者は同じ知識を持っています。そのため自分が攻撃者ならばここを攻めるという想像力は持っているべきですし、それに対し防御する必要があります。 技術的観点からいえば、「既知の脆弱性が放置されていないか」、「外部からアクセス可能な管理画面、apiが存在しないか」、「古い暗号化方式や不適切な管理権限が残っていないか」などの外部からの技術的な攻撃を想定しますが、「内部不正についての防御は十分か」、「ITに精通していない従業員のオペレーションミスを起こしやすい状況となっていないか」、「システムの運用ルールが厳しすぎて例外処理が生まれ、抜け道が生まれてないか」などの人間起因、それも悪意があるモノではなくミスによるセキュリティリスクも考慮する必要があります。

2.リスクアセスメントをする 各情報資産に対するリスクのアセスメント(量・価値の計算的評価)を行います。 すべての情報資産に100%の対策を行うことは現実的でなく、逆にリスクを増大化させます。そもそも人の稼働工数も、会社が支払える費用も限度があります。

  • 最新のセキュリティ機器を全拠点に導入
  • 従業員すべての操作を監視
  • あらゆるデータのバックアップ、同期

上記は不可能です。基準を作り、優先度を決めて長い期間をかけて対策を実施する必要があります。自分も社内でリスクアセスメントを行っていますが、優先度を決めるための基準はCIAを使っています。つまり

  • 「機密性(Confidentiality)」 この情報資産が外部に漏れる危険性
  • 「完全性(Integrity)」 この情報が改ざんされたりする危険性
  • 「可用性(Availability)」 この情報が利用できなくなる(ビジネスが行えなくなる)危険性

の掛け算で値を出し、値が大きいほど優先度高く対応する、という感じです。

また、AIのようなテクノロジーの進化や攻撃のトレンドにより、優先度は変わっていくものです。リスクアセスメントは毎年行い、評価値や対策を見直す必要があります。リスク評価に固定の答えはなく、組織が違えば対策は異なります。一つのヒントとして、自分の会社の業態やビジネススタイルにより生じた過去のセキュリティインシデントは、今後類似の被害が起こる可能性が考えられるため、そこを観点にするよう書かれていました。

3.経営や現場の視点を持つ 経営層が求めているのは攻撃がどのような技術を用いて行われるか、などではありません。以下です。

  • 問題の本質
  • リスクの深刻度
  • 次に何をすべきか

平常時、異常時ともに、これらを的確に伝えるとセキュリティエンジニアの評価も向上し、経営層の信頼を得ることができます。 「技術が分かるは普通」「現場が分かるは上級」「経営者視点で考えられるが最上級」と本書は説きます、今はどのレベルだろう?と自分に問いかけました。セキュリティエンジニアは「技術を知っている」だけでなく、「技術を生かして、実践的な解決策を考えられる人」になるべきで、そのためには

  • 現場の業務フローを理解し、実際に運用できる形でセキュリティを設計すること
    • 現場に受け入れられるセキュリティ施策でないと抜け道が作られる
    • つまり「僕は技術者だから、営業がどんな仕事をしているかはよく分からないよ」は論外
  • セキュリティを強化する一方、業務効率が低下してはならない
    • 技術的に正しい政策を現場が受け入れれやすいよう調整する
    • 従業員に「なぜこの対策が必要なのか」を理解できる説明を丁寧に行う

現場の声を聞いて、現場を理解し、現場の負荷にならない友好なセキュリティ施策を実施します(もちろん、まったく役に立たないセキュリティ施策ではダメです)単なる技術者から、組織に貢献できるエンジニアになるためにはコミュ力も必要なのです。

4.シンプルに考える 「理論的に正しいセキュリティ対策は必ずしも実践的ではない」現場を知れば、自分の組織のセキュリティ対策と意識があるべき姿に遠く及ばない状態であることに愕然とするセキュリティエンジニアはいると思います。しかし、そこで一気に厳しい規制を行うと、現場のバックドアというもっと大きなセキュリティリスクを生みます。そのためシンプルで守りたくなる、自分たちの業務を守ってくれている、と従業員に感じてもらえるルールにすることが重要です。

5.冷静な判断力を持つ

どれだけ防御を講じていたとしてもセキュリティインシデントを完全に防ぐことは不可能、セキュリティエンジニアの力を真に発揮する場所は(考えたくはないですが)システムインシデント対応です。

  • DDoSだと思って急ぎ全従業員のPCをネットワーク遮断を行ったら、実際には影響範囲は軽微だった。余計な損害が出てしまった
  • データ漏洩したと思って経営層に報告して、対外的に報告したら実際には漏洩したデータはテストデータだった
  • 単なる一時的なネットワークの輻輳ですぐに解消したが、システムの再構築を行ってしまった

上記のエピソードを”自分が実際にやらかすのでは”と顔を青くしながら読んでいました。 スピード感を持つことは大事ですが、間違った情報を拡散しない、正確な情報を持って対応するのはそれ以上に重要です。セキュリティエンジニアは判断を下すのではなく、判断材料を提供します。システムの停止は顧客への影響が発生することから、絶対に経営層や業務部門と連携する必要があります。その際に伝えるべきことは

  • 影響範囲は
  • 発生している現象は
  • 考えられる対応策は

の3点です。加えてBRAフレームワークという、これも筆者の独自のフレームワークが紹介されます。個のフレームワークは技術的な報告ではなく、ビジネスに影響を与える情報を経営層に伝える点にフォーカスしています。

  • Business Impact=会社への影響
    • 顧客情報X件
    • 復旧までにX時間 -影響金額はX万円
  • Risk=具体的なリスクの深刻度:「現状で分かっていること」「まだ確定していないこと」を明確に
    • 社員のアカウントが乗っ取られた可能性
    • ネットワークへに侵入された
  • Action=次に何をするべきか、具体的な対応策、意思決定の選択肢

まずは事実確認、次に影響範囲の見極め。その後にリスクの評価を行い経営層に報告します(初報だけは入れたほうがよいと自分は考えます) 影響があったのは数台のPCであれば全社的な業務停止は不要で、特定PCをネットワークから隔離すれば問題はいったんは解決します。経営層に即座に報告したら、経営層が社外に即座に報告し、のちに誤報と判明してさらに信用を失う愚もあります。エンジニアが「可能性」として報告しても、経営層は「確定事項」として受け取ることがあります。

最後に

この記事を書いているのはゴールデンウィーク前ですが、ゴールデンウィーク明けにはセキュリティに関する施策を経営陣に提案するミッションが待ち構えています。この本の内容は事前に知らずに読んだのですが、ピンポイントで刺さる内容でした。自費出版の本で、ページ数はそれほどでもありませんでしたが、これだけ長く感想を書いたことからも得るものが多かったのだ、と振り返って感じました。

様々な種類のエンジニアが企業に所属していますが、特にセキュリティエンジニアこそ経営視点だと思いました。経営層に対してセキュリティ活動と、ツール導入によって生じるコストを承諾してもらうためには

  • 事業の成長や競争の優位性を語る、リスクを語るは当たり前
  • このセキュリティ導入による投資効果を語る
  • セキュリティ強化により新規契約が実現できる
  • サプライチェーンリスクの重要性が理解されるようになり、これまであまり重視されていなかった委託先に対するセキュリティレベルを上げる要望が強まってきている
  • 脆弱性によるセキュリティインシデントの実例を挙げ、自社にも同じ脆弱性があることを伝える
  • 技術用語、専門用語を使わず、「リスク」と「ビジネス」の目線から説明する

など、セキュリティ強化が受注と企業の継続した成長に密接に関わっていることを丁寧に説明することが重要と感じました。そして経営層からOKをもらえたら、現場と連携して実効性があり、守ってもらえるツール・規程を浸透させることが大切だと思いました。100点は目指さない(目指せない)。70点のセキュリティを目指そう。やるぞ。