はじめまして:
株式会社ONE COMPATHの「やまかず」と申します。
普段は「ISMS運用」として、リスク分析、委託先・受託時のセキュリティチェック、個人情報保護検討、セキュリティ相談窓口などのセキュリティマネジメント業務(世の中で「文系セキュリティ」といわれているもの)を行っています。
ISMSの業務は幅が広く「担当になったはいいけど、何から取り組めばいいの?」と悩む人が多いといいます。私も、よくわからないまま業務に取り組んでいて、途方に暮れた記憶があります。
今回は、初めてISMSの担当になった方がつまづきやすい4つのポイントを、私の経験をもとにまとめてみました。同じキャリアを歩む人たちが悩むときに、少しでもヒントになれば幸いです。
ISMS担当になった時に、つまづきやすいポイント:
ISMS担当になった時、つまづきやすいと個人的に感じたポイントになります。いかがでしょうか?どのケースもよくある話題ではないかと思います。
| 番号 | つまづきポイント | こんなこと・あんなこと |
|---|---|---|
| 1 | (1)規格や用語が難しくて覚えられない | ISMSの附属書Aの管理策は93個(※)あり、とても全部覚えていられません。(※ISO/IEC 27001:2022時点) |
| 2 | (2)現場とのコミュニケーションが難しい | 特に監査対応の協力依頼をするとき。各部門が忙しそうで話しかけづらいです。また、監査対応時に現場が何を話せばいいか困っているのをよく目にします。 |
| 3 | (3)業務が属人化しやすい | セキュリティに関する知識に差がでてくると対応者が限定されてしまいます。 |
| 4 | (4)新しいセキュリティの課題がふられる | 例えば生成AIガイドラインの策定をしてほしいといった新しい課題の取り組みが突然やってきます。 |
つまづきやすいポイントと解決策(一部):
それぞれのつまづきポイントに対して、実践してみたことを記載してみます。
(1)規格や用語が難しくて覚えられない
ISMSの規格要求事項、全部覚えるのなんて無理!そう思いませんか?私はISMS担当になった時、正直無理じゃない?となりました。でも、安心してください。規格や用語を丸暗記するよりも、理解することの方が大事だと考えています。
私は、ISMSの規格要求事項の全体像をつかむところから始めました。全体像をつかむために、社内のISMSガイドラインや先輩が作った運用資料を読み込むなど『この業務やサービスは、この規格と関係がありそう』といった漠然としたイメージを結びつけるようにしています。
例えば『脅威インテリジェンス』
これを単体でとらえると難しく感じますが、私は次のように具体的な行動と紐付けて考えました。
脅威インテリジェンスのイメージは?
①脅威情報の情報収集
⇒セキュリティ関連の情報を「どこから収集するか」を把握します。
②脆弱性のパッチ適用
⇒どの部門が「どのタイミングでパッチを当てるか」を把握します。
③社内共有フロー構築
⇒社内で「どんな情報をいつ、誰に、どう伝えるか」を把握します。
このように、用語を『会社で実際に行われている業務』に置き換えて考えることで、丸暗記するよりも理解が深まります。
(2)現場とのコミュニケーションが難しい
『セキュリティ?また業務が増えるのか…
』『審査とか面倒くさい…
』ISMSを担当していると、現場からこんな声が聞こえてくることがありませんか?情報セキュリティを『業務を邪魔するもの』だと現場が思っているケースは、残念ながら少なくありません。
この状態の改善のために、私は、審査時は『絶対に現場の味方』というスタンスを貫いています。大事な点として、審査はあくまで「自社の良い点や悪い点を、第三者の視点で見つけてもらう場」として考えてもらうようアプローチし、攻撃される場ではない。ことを伝えることかと思っています。審査員と現場担当者の間に立ち、現場担当者が困っていたら助け舟を出すなど、不安を取り除くことを第一に考えています。
現場との信頼関係を築くために、私が実践してみたことを3つご紹介します。
信頼関係を築くための私のスタンス
①審査前のヒアリング
⇒現場が不安に思っている点は、事前にしっかり聞き取ります。
②審査前相談窓口の設置
⇒審査前に、よくある質問をまとめ、審査前に口頭のやり取りが可能な窓口を設置。対面で不安をお聞きします。
③セキュリティ=足かせではない姿勢
⇒セキュリティ対策が現場の負担にならないよう、守るべきことは実施するよう、コントロールできるルール作りを考えます。
時には現場との認識のズレがでてしまい結果を出せず失敗することもあります。こんな時は、PDCAプロセスに乗せ、チェック、アクションをします。当社は150名規模であることから、自律的に動きやすいところもあり、積極的なコミュニケーションや、ルール変更は柔軟に検討可能です。現場にはセキュリティは「現場の味方」でありたい。厳しくするだけではなく「バランスを取りたい」ということを伝えていく動きが重要だと考えてます。
(3)業務が属人化しやすい
『この仕事はあの人しか分からない…
』ISMSの業務は専門性が高く、特定の担当者にしかできない属人化が起きやすいと思いませんか?チームで担当者が何名かいても、それぞれの得意分野が異なると業務が偏りがちになります。
専任者が休暇してしまったら業務が止まってしまう。といったことが起きないように、今期から情報セキュリティをチームで回すことに注力し始めました。
チームとして業務を回すために、いま私が頭に入れてやってみたことを4つご紹介します。
専任体制からチーム体制への取り組み
①ノウハウの見える化
②業務を任せる勇気
③「人に任せるためのノウハウ」は上司から学ぶ
④ノウハウの発信
※説明が長くなってしまうので、別建てで記載します。
ノウハウの見える化
⇒自分の得意な分野(個人情報保護やデータ活用など)のノウハウを、タスク管理システム「Backlog」やスプレッドシートにまとめています。こうすることで、自分以外の人もいつでも知識にアクセスでき、業務がスムーズに進むようになると考えています。人に見てもらうと、自分が気が付かないことも多く出てきます。専任性の強い担当者がやりがちな「暗黙知」も洗い出せるので、一石二鳥です![]()
業務を任せる勇気
⇒お仕事を依頼する際には、相手のスキルや状況に合わせて、情報の伝え方を工夫するようにしています。細かすぎるとマイクロマネジメントになりますし、大雑把すぎると放任になってしまいます。個人的に人に業務を任せることが得意ではありませんが、あえて任せることでチームの成長を促すように心がけています。これが属人化をやめるための第一歩と自分に言い聞かせてます。
「人に任せるためのノウハウ」は上司から学ぶ
⇒今まで自律的にかつ専任的に対応をすることを得意としていたので 「人にお願いする」「納得して動いてもらう」「わかりやすく伝える」といったところが私の苦手なところです。苦手な部分は上司にアドバイスをいただくことにしています。
私の直接の相談相手は、CISOや、部長であり「時間をかけることができない」相手です。なのでコミュニケーションの基本を意識してヒューマンマネジメントに関するアドバイスをいただきます。
ひとから学ぶために基本として心がけていること
①「何が言いたいのか?」という指摘が出ないように、結論から話す。
②相談事項にノイズを入れないようにする
③時間の意識
④相談事と合わせて「提案」をセットにする
上司は「人に仕事を任せて結果をだしてもらうこと」のスペシャリストです。その視点は、専任職である私よりもずっと深いものであり、いろいろな気付きを与えてくれます。「上司と話すのは苦手」って人は多いと思いますが、上司の視点を知る経験のメリットは、何気に大きいと思います。
ノウハウや思いの発信
⇒調査結果、事象、世の中の動向、CSIRTからの情報等、自分の考え方等、会社のセキュリティ向上のために共有したほうがいいと思ったことは、チームの定例会でなんでも話題に出しています。逆に情報発信が「たんなる独りよがり」になっていないかも注意しています。
(4)新しいセキュリティの課題がふられたとき
生成AIの活用が経営戦略につながる時代です。世の中がこんな環境であれば、現場から 『生成AIガイドラインを作ってほしい!』 といった対応を求められることも自然なことです。
当社でもプロジェクトが立ち上がり 「技術戦略」「情シス」「法務」「セキュリティ」 で対応を進めました。当時は生成AIに関しての知識ゼロの状態。それを埋めるべく、試行錯誤してきたポイントを3つご紹介します。
新しい課題がでてきたとき
①技術部門と「共通言語」を持つ
②リスクを「原理原則」で考える
③長いものに巻かれる
※説明が長くなってしまうので、別建てで記載します。
技術部門と「共通言語」を持つ
⇒技術部門との定例やスキル共有会で話が通じるよう、自分の知識アップデートを常にを心がけていました。 アップデートをするたびに、何がAIでできるのか。どんな業務でAIを使いたいと、みんなが言い出すだろうか?どこにリスクポイントがでてくるのか。 といったことに対応できる知識はなんだ?を考えて動きます。
新しい技術を得るということで、書籍、書類、WEB情報の収集をしていました。
知識のアップデートに使っていたもの
■ガバナンス関係
・法律事務所が出している生成AIの本
・政府が出していた生成AIに関するガイドライン
・AIの7つの原則について書いてあるページの参照
■体験
・Udemyの生成AIの勉強をしてみる
・ChatGPTをプライベートでいじってみる
・YouTubeの動画をみる
■技術
・Qiitaの記事を読む
リスクを「原理原則」で考える
当初、生成AIの活用が本格的になった時は、今までの技術とは全く別次元のものとしてリスクをとらえなくてはならないという先入観がありました。
ところが、この考えがあるうちは検討がうまくいかず、ガイドライン策定に苦戦しました。
そこで、生成AIのように新しいものであっても、従来のシステムとリスクに対する考え方や対応が大きく変化するものではないとして割り切ることで、うまくいきました。
例えばですが、生成AI特有の課題といわれている、プロンプトインジェクション、ハルシネーション、モデルデータの著作権違反などを、従来のリスク分析に「どうやって組み込めばいいんだよ?」と悩みました。が、これらの内容は、今までの内容に「+」して評価すればいいとし 従来のリスク評価と切り分けて進めました。
長いものに巻かれる
有識者の調査結果などがwebにどんどんアップデートされています。これらの情報を活用してガイドラインをアップデートしていきました。当社のグループ会社方針で出てきた指標もどんどんアップデートしていきました。こうすることで 「独りよがりにならず、外部の情報を活用する」 ことができ、都度、自社のセキュリティにあったバージョンアップをすることができました。
これらの対応を実施してきた結果、当社の生成AIの取り組みは 「事業レベル」 で広がっていて、生成AIの活用が当たり前になってきています。最近だと MCP(Model Context Protocol)サーバーのリスク の話題も上がっています。これらの要望に対しても真摯に取り組まなければと考えている次第です。
最後に
いかがでしたでしょうか。初めてISMSを担当した人がつまづきそうな点について、私の実体験を含めて記載してみました。少しでもヒントになれば嬉しいです。