セキュリティの立ち上げで何をやる？
最近、セキュリティの立ち上げで何をやったらいいかわからない、という質問を何度か受けるケースがあったので、最初に何をやるか、というのを情シスやセキュリティ担当者としての考えをまとめてみる。
著者のキャリアについて
セキュリティの立ち上げについて書く以上、信頼に足る情報源なのか？という疑問がわくと思うので、簡単に著者のキャリアを書いておきます。
2002年にSIerでIT業界に入り、研究所のNetwork Admin、Web penetration test、ISMSコンサルの補佐などやり、その後外資プリセール分野で7年仕事して、最初のSIに戻ってセキュリティソリューションの立ち上げを担当、その後ユーザーサイドにキャリアを変えて、外資石油系企業のセキュリティアナリスト、中国系スタートアップのInfoSec Director&一人情シスをやってきたキャリアです。CISSPは2019年に取得しており、現在はUbie Discoveryで情報セキュリティを担当しています。
そのようなキャリアであるので、SaaSのプロダクトセキュリティで何をやるか、という観点ではなく、コーポレートや情シスサイドでの考え方を中心に、立ち上げでやることと各種情報のポインターを記載します。
プロダクトセキュリティについては、同僚の水谷さんが色々書いているので、そちらもぜひ参照いただきたい。水谷さんは、OPA/Regoについて一人アドベントカレンダー(!!!)をやっているので、ぜひ読んでみてください(自分も勉強中です)。
何もないところからスタートするとしたら？
CISSPや情報セキュリティスペシャリストなど、セキュリティの専門資格を有している担当者がいない場合、さて何をやろう？と考えると、おそらくほとんどの企業が途方にくれるのでは、と思います。
Anti-Virusは役に立たないと聞くし、EDR流行っているから入れようか、とか、ゼロトラスト流行っているから、なんかやってみるか、とか、世の中の動向を見てテクノロジーから入ってしまっていないでしょうか。あるいは、ISMSを取らないと入札要件満たせないから、とりあえずコンサルにお金積んでISMS取るか、と、ポリシー文書一式丸投げで体裁整えて終わり！、という企業もあるかもしれません。
何かやるというのはやらないよりマシなのですが、セキュリティはやはり自分ごととして、自分の組織のに合わせて決まりを作り、リスク分析した上で必要な対策かつ効果あるものに、限られた人と資源、資金を投資すべきものだと考えています。
では何から始めるか？については、おおまかに事業や組織の規模によって変わると思います。PMFって何？という方は、こちらのNote記事 (PMFのはかり方)などを参照してください。
- 人数規模50人未満 / PMF達成しそうか？(5->10)の段階
- 事業の対象とする分野や組織の成熟度により一概には言えないものの、通常この段階の組織でフルスペックのセキュリティ対策はtoo muchになると思います。
- 自分が担当するとしたら、IPAの中小企業の情報セキュリティ対策ガイドラインを参考に次の取り組みをすると思います。
- 情報セキュリティ基本方針の策定
- ITシステムを利用する上での最低限のルールを固め、Acceptable Use Policyを作り、従業員教育に力を入れる。
- 簡易的なリスク分析を行って、リスクの高い部分を中心にROIの高い方法で低減をはかる
- 就業規則など会社の規程、個人情報を取り扱う場合のプライバシーポリシー、外部委託契約などの契約書の見直し等、どちらかというとセキュリティ以外の部分の規程をしっかり作る。
- 人数規模が50人を超える / PMF達成した事業の核ができてスケールしはじめる (10-100に突入)
- この規模の組織では、セキュリティリスクによる事業影響が大きくなる上、顧客からの信頼を勝ち取るために、ISMSの取得など、対外的にセキュリティ管理をしっかりやっている姿を見せられるようにならないといけなくなります。
- この段階で自分がやるとしたら、次の流れでISMS取得にも耐えられるガバナンス体制を考えます。
- セキュリティポリシー文書の見直し、およびドラフト版/改定案の作成
- ガバナンス組織の立て付け
- リスク分析
- セキュリティベースラインの決定
- ポリシーのエンフォースメント
- 100人を超えてから慌ててやろうとすると、高リスクの負債があちこちに蓄積した状態から建て直さなければいけなくなりとても大変だと思うので、自分の場合は50人を超えて組織が拡大しそうな段階で始められるのがベストと考えています。
本ブログでは、人数規模が50人を超えてきてISMS取得を検討したり、あるいは、とりあえずISMSはコンサル入れて取得したけど、80人を超えてきて、さすがに実質を伴ったセキュリティ対策を考えなければ、という段階の組織を対象に、考え方や情報のポインターを記載します。
1. セキュリティポリシー文書の見直し
自分達はどんなセキュリティを実現したいのか、組織としての考え方を定めるのがセキュリティポリシーです。
ポリシーなんか誰も読まないでしょ、とISMSコンサルタントに丸投げして書いてもらったポリシー文書で運用しているところは、一回じっくり内容読んでみてください。執務室でカメラ付き携帯を使うな、とか、PC持ち出し原則禁止/承認取ったら暗号化してセキュアブートやれ、とか入ったりしていませんか？ それが守ることのできるルールであれば良いですが、守ることが難しいルールを定めても仕方ないので、自分達はどんなルールを定めて自分の会社の重要資産を守るのか、自分たちの組織や事業にあわせて方針を考えることが重要となります。
よって、自分の場合は、まずどんなポリシーを定めているのか、それははたして現段階の組織の成熟度を考えた場合に実現可能なレベルになっているのか、というところを分析します。これは、たとえISMSを取得済みの場合でも、まずポリシー文書の読み込みをやります。
もし、ポリシー文書一式をゼロから書かなければならない、という段階の場合は、以下のポリシーサンプルがおすすめです。
- JNSAポリシーサンプル: https://www.jnsa.org/result/2016/policy/
2016年に書かれたものなので、若干古い内容にはなるものの、ゼロからポリシー文書を書かなければならないケースでは、ベースラインとしてはとても良い材料になると思います。とはいえ、一部内容の薄い部分があり、5年以上前に書かれていることもあって、以下の項目は自分で考えて記載しないといけません。
- 情報資産についての規程
- 極秘、部外秘、社外秘など、情報資産の守秘区分を定義して、それぞれの区分に対してどんなルールを定めるか、というポリシーについては、記載内容が薄いこともあって、自分達で定める必要があります。
- SaaSなどクラウドサービスに関する規程
- 昨今は、自分達でインフラを持って運用するケースは、ことスタートアップについてはほとんどないと思います。
- SaaS利用に関する規程は全くサンプルがないので、SaaS利用を想定したルールを自ら記載する必要があります。
- ITシステム利用規程やAcceptable Use Policy
- オンプレ前提の規程になっているので、ここも昨今のクラウド利用やリモートワーク前提のポリシーを自ら考えて作成する必要があります。
一つ注意事項として、ポリシーを書く際は、あまりHowについて細かく書かず、あくまで方針を書くように注意するようにしてください。管理目的を達成するためのHowは、いろいろなものがあり、時代とともに変遷します。あまりHowを細かく規定してしまうと、実装を変えるたびにポリシー文書を改定する形になってしまうので、好ましくありません。詳細はポリシーの下位文書の手順書(Procedure)に記載するように、全体を構成するよう意識してください。
- 情報セキュリティ基本方針は、外部に公開するもので、よくホームページに記載されているやつです。
- 情報セキュリティ方針が、情報セキュリティ組織の構成と役割などを記載している大本のポリシーになります。
- 対策規程が、人的、物理的、情報資産管理、リスクマネージメント等々、個々の規程文書群で、ここまでが情報セキュリティポリシー文書群になります。
- ポリシーの方針を受けて、その運用に関する詳細を定めるのが対策手順書(Procedures)のレイヤーです。ここは具体的Howに基づいて詳細な手順を記載するため、頻繁に更新が行われます。
ISMSの管理策
JNSAのサンプルポリシー文書を見ていると、各章の番号の下に、(A.9.1.1)のような番号がついているのに気づくと思います。これは、ISMSの管理目的および管理策の項番に対応しています。
ISMSって何？という方は、以下を参照してください。
- ISMSとは？: https://isms.jp/isms/
ISMSは、組織のセキュリティマネージメントについての規格で、情報の機密性、完全性、可用性をバランス良く維持・改善するために、組織はどのようなことをルールとして定め、実装し、リスク分析を行っていくか、その要求事項が定められています。
ISMSでは、自社で採用する管理策を適合宣言書の中で宣言するのですが、その際に、管理策に対応するポリシーがどれなのか明記する必要があるため、JNSAのサンプルでも各章にISMSの付録Aの対応する管理策の番号が入る形式になっています。
自社のポリシーは網羅性が担保されているのだろうか？、定められたルールは安全を担保する上で十分な内容になっているのだろうか？という観点で分析するには、ISMSの管理策が一つの有効な指針になると思います。
ISMSの管理策については、規格文書を購入しても良いと思いますが、結構お高いので、政府が出している管理基準を参照にすると良いです。ISMSベースで作成されているので、章の番号がISMSの管理策と同じ構成になっています。
- 情報セキュリティ管理基準 (平成28年改正版)
各項目を見ながら、自分達がどこまで厳しいルールを課すかを考えてゆくと、ISMSに沿った一定の網羅性が担保されたポリシー文書を作ることができると思います。
2. ガバナンス組織の立て付け
ポリシー文書の最上位になる基本方針の中を読むと、一番最初の方に情報セキュリティを維持・管理するための組織構造や役割について記載された内容が書かれていると思います。ポリシー文書は、就業規則など、会社のトップによってAuthorizeされる必要のある文書として定めることが通常です。よって、誰がどんな責任で情報セキュリティの運用を行ってゆくか、組織体制をしっかり定めた上で、正式な組織がポリシー文書を承認する形にしなければなりません。セキュリティ担当がポリシー文書のドラフトを作ったら、はい完了即施行、ではなく、情報セキュリティ委員会のような組織体制をつくり、社長などトップマネージメントを入れた会社の正式な承認プロセスをはさんでから施行するようにしましょう。
なお、ユビーでは、ホラクラシーという形態で組織運営を行っていますが、この情報セキュリティ管理についても、情報セキュリティ委員会というサークルを作り、ポリシー文書に定めた役割をロールとして定義して、担当者をアサインして運用しています。社長もロールの一つとしてこの会議体に参加しています。
- フラットな組織の負債と向き合ったUbie Discovery が、ホラクラシー組織を採用した理由: https://note.com/ubie/n/nd86e2a5655c0
3. リスク分析
ルールを定めたら、次はリスク分析を行います。会社の重要資産をリスト化しつつ、自分達が定めたルール通り運用されているか？世の中の脅威状況をみた場合に、現在のルールや管理策は十分に機能するか、それぞれの資産に対する機密性、完全性、可用性のリスクを分析します。リスク分析については、世の中にいろいろな方法がありますので、自社にあったものを見つけていただければと思います。
自分の場合は、シンプルに会社の重要資産の重要度を定義して、それぞれに対する脅威を想定し、その発生頻度と既存の管理策の脆弱性を評価するスコアリングの方法を採用するアプローチを採用しています。このアプローチを採る場合は、以下の資料は非常に良い参考書になると思います。
- 重要インフラにおける機能保証の考え方に基づくリスクアセスメント手引書
重要度は、会社の事業への影響度、という観点で評価します。
自分の場合は、業務に対する影響度、予測復旧時間、レピュテーションへの影響、対応に要するコスト、人名への影響範囲・程度の5つの枠組みで、影響の大きさを5段階評価します。
続いて、リストした会社の資産に対して、具体的な脅威を想定しながら、その発生頻度と自分達が実施している対策の脆弱性を評価します。脅威は、たとえば次のようなものを想定しながら、機密性、完全性、可用性への影響を考えてゆきます。
| 脅威 | 主な脅威の例 |
|---|---|
| 犯罪 (外部) | 不正アクセス(盗聴、改ざん、なりすまし)、悪質なソフトウェア(マルウェア、バックドア等の攻撃)、建物への侵⼊/窃盗/破壊、レピュテーションの毀損 |
| 犯罪 (内部) | 就業者による不正アクセス、情報漏洩、システムへの不正⾏為、窃盗/破壊 |
| 災害 | 地震、⽕災、⾵⽔害、落雷、パンデミック |
| 故障 | 回線障害、機器故障、クラウドサービスのサービス停⽌、ソフトウェア障害、レピュテーション毀損 |
| 過失 | オペレーションミスによる情報の毀損/サービス障害、法令違反、レピュテーションの毀損 |
これらの脅威に対して、その発生頻度をある程度数値化してみます。自分の場合は、脅威によって、「意図的(計画的)脅威」、「偶発的脅威」、「環境的脅威」の３つの軸にわけて、５段階で評価するアプローチを採用しています。たとえば、内部犯行のような意図的(計画的)脅威については、
- 5: 発生が具体的に予想される
- 4: 実施による利益がある
- 3: 実施による利益は多少ある
- 2: 実施による利益はあまりない
- 1: 実施による利益はない
といった形で発生頻度を想定します。
最後に、脆弱性を評価します。脆弱性は、想定した脅威に対して、現在実施している対策がどの程度有効か？という点で評価します。たとえば、上の意図的(計画的)脅威に対しては、
- 5: 一般者が普通に実施可能 => 実施が簡単
- 4: 一般者が調査をすれば実施可能 => 調べれば実施は比較的簡単
- 3: 専⾨能⼒を持つ者によって可能 => 成功させるのは専門知識が必要
- 2: ⾼度な専⾨知識と設備を持つ者によって可能 => 高度な知識とツールがないと成功しない
- 1: 最高程度の対策を実施済み => 攻撃を成功させることはできない
影響度、脅威の発生頻度、そして脆弱性の３つの分析結果から、リスクスコアを算出します。算出方法は色々ありますが、自分の場合は、それぞれの掛け算でスコアを出し、会社でリスク低減のための対策を実施しなければならないレベルを定めています。
たとえば、リスクスコア20以上を対象とする場合の表は次のようになります。
リスクスコア表の例
会社の重要資産と脅威、影響度、脆弱性の分析結果は、リスク管理表に記載して、スコアを出していきます。このうち、しきい値を超えるリスクについて、リスク対応計画に載せるかどうか、載せる場合どのような対策でリスク低減や回避をはかるか検討します。
リスク管理表の例
たとえば、この表の場合、Google Driveに保存されている部外秘情報が、脆弱なアカウント管理のためにリスクが高い、という分析結果が出ている状況を示しています。これについては、リスク対策計画を立てて、不正アクセスを防止するための対策を検討する、といった流れで、リスク低減を行うためのタスクに落とし込み、情報セキュリティ委員会などで優先度とスケジュールの決定を行う、という流れで対策を考えます。
情シスやセキュリティ担当だけでは、当然全ての資産をリストすることはできないので、総務、人事、経理、各事業部、それぞれの担当者の協力を仰ぎながら、情報をリストアップして分析することが大事です。
国や業界団体などのガイドラインも合わせて分析する
このリスク分析と平行して、自社の事業に適用される法令やガイドラインについても合わせて分析して、セキュリティ対策の現状を確認します。
たとえば、ユビーの場合は、総務省や経済産業省が出している医療情報の安全管理ガイドラインなどを参照しながら、医療情報を取り扱う際に守るべき要件をピックアップし、自社の遵守状況をチェックします。金融系であれば、FISCのガイドラインなどを分析することになるでしょう。
これらのガイドラインでは、ISMSの管理策以上により詳細な要件が定められているケースが多いと思います。ガイドラインに準拠するためにポリシーで新たな社内ルールを追記しなければならないケースも出るでしょう。これらは、分析の結果、自社の取り組みが足りないと判明した場合は、リスク管理表に上げ、社内規程の更新や、社内プロセスの見直し、要件を満たすために必要な技術対策の導入などを計画してゆきます。
NISTのCybersecurity Frameworkを使った成熟度の分析
ISMSを取得してある程度ベースができてきたら、次の段階では、NISTのCybersecurity Frameworkを使って、自組織の成熟度(Maturity)をチェックすると良いと思います。ISMSは、ポリシーやルールが定められているかを見るだけで、その運用の実行水準がどうなっているか？という点は評価しません。NISTのフレームワークでは、Identity、Protect、Detect、Response、Recoverという5つのカテゴリーについて、運用を含む組織の成熟度を評価する形式になっているので、ISMSの次により高い水準を目指す組織にとって、非常に有用なフレームワークになっていると思います。
- NIST Cyber Security Framework: https://www.nist.gov/cyberframework
4. セキュリティベースラインの策定
続いて取り掛かるのは、セキュリティベースラインです。ベースラインとは、たとえば情シスが配布するWindows PCやMac OSの設定をより安全にするために、配布前に管理者が設定すべき項目を定めた文書を指します。社内にネットワーク機器がある場合は、それらを安全に構成するための最低基準を定めるのもベースラインです。
このベースラインを作る際に参考になるのは、CIS ControlsとBenchmarks、DISA STIGsです。
- CIS Controls: https://www.cisecurity.org/controls/v8/
- CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks/
- DISA STIGs: https://public.cyber.mil/stigs/
- Viewerがある。https://www.stigviewer.com/stigs
CIS Controlsでは、管理者権限を制限せよ、とか、アラートを一元管理せよ、など、実装すべき項目がリストとして整理されています。これにアラインする形で、実際にどんな設定をしなければならないか、が記載されているのが、CIS Benchmarksです。
DISA STIGsは、米軍の調達に際してのセキュリティ基準を記載した文書ですが、それぞれの機器にどんな設定を入れないといけないのか、というポイントが詳細に書かれており、参考になります。両方をあわせて読みつつ、設定の意味を理解し、どんなベースラインを自社の機器に設定するかを検討すると良いです。
社内のルールを決めて、リスクを分析して、リスクを低減するためのテクノロジーを展開したとしても、それが正しく設定されていなければ、新たな脆弱性を生むことになります。セキュリティリスクを生じさせないため、システムをどのように設定するか、会社として基準を定めましょう。
5. ポリシーのエンフォースメント
ポリシーでルールを定めたとしても、それが強制されていなければ意味がありません。
たとえば、スクリーンロックを10分でかけること、という社内規程を立てたとしても、ユーザが設定を自由にいじれてしまっては、それを強制していることになりません。ポリシーとして定めたルールを適用する場合、人間へアプローチする、プロセスを改善する、テクノロジーを使う、という3つの要素を組み合わせて、ビジネスや利用可能なリソースの状況にあわせて、バランスの良い対策を考えることが重要とされますが、自分はエンジニアということもあって、システムの力を最大限に使って統制を実装して、普通に使っていれば、ポリシーに自動的に準拠した状態になっている、という姿が理想と考えています。
たとえば、ポリシーで「会社の情報資産へのアクセスは、会社のPC/携帯のみを利用すること」といったルールを定めている企業も多いかと思います。ユビーでは、Google Workspaceを利用しているので、こういったポリシーのエンフォースメントには、Context-Aware Accessを使うことができます。
- IPが日本国内で、会社資産のPCかつMacOSについてアクセスを許可する例
個人情報を含むファイルは社外と共有してはならない、といったポリシーを定めた場合は、Google WorkspaceのDLPの機能を使って、警告表示させるような実装も可能です。
DLPルールにマッチしない場合のシートの共有ボタンの表示
DLPルールにマッチした場合のシートの共有ボタン (盾マークが現れる)
Ubie Discoveryでは、アラートセンターに上がるDLP関連のアラートについて、OPA/Regoと組み合わせることで、「Anyone with Linkで共有された場合のみ、Github issuesにアラートを上げる」といった実装を行って、セキュリティチームがすぐに是正に動けるような監視を実装していたりします。水谷さんの取り組みについては、ぜひ彼のAdvent Calendarをご参照ください。
このように、ポリシーで定めたルールを、どうシステム側で強制して手動のオペレーションを排するか？を考えてゆくのは、エンジニアとしてはとても楽しい作業ですが、ポリシーのエンフォースのHowについて書くと、とてつもなく長くなってしまうので、今回はここまでとして、また次回いろいろなテーマで書いていきたいと思います。
まとめ
会社の基本方針となるポリシーを揃え、情報資産の棚卸しとリスク分析を実施し、しきい値を超えるリスクについて、リスクレジスターに登録して対策を検討する。自社に展開されているツールやシステムについて、セキュリティベースラインを決めて、これらをエンフォースする仕組みを考えて、計画を立てて実装する。この一連の作業が、「セキュリティの立ち上げで何をやったらいいかわからない」という質問に対する自分の回答になるかな、と思います。
次の段階では、セキュリティのコントロールの実装と運用が適切に行われているのか、ポリシーに準拠しているかをチェックする監査が重要になってきます。実装や運用を行っている人間が監査もやっていたのでは意味をなさないので、組織体制が整わない最初のうちは、外部のコンサルタントを活用するケースも多いでしょう。
ユビーも、ISMSを2020年に取得していますが、最初の更新審査は、外部のコンサルタントの力を借りて監査を実施しました。しかし、組織と事業が拡大する中、監査の体制も自社内に整備していかなければならないステージに来ています。
ということで、ユビーでは、会社のリスクを管理し、セキュリティ管理が適切に実施されているかを監査する役割を担うポジションとして、リスクマネージメント・スペシャリストの募集を行っています。
内部監査、という肩書での募集になっていないのは、よくある大企業の内部監査のように、膨大な資料を提出させてエビデンスを逐一チェックして是正を指摘してくるような監査ではなく、コードとして記述されたポリシーをチェックしつつ、監査したい項目があれば自らポリシーをコードとして記述するような方を採用したい、という思いが背景にあります。
Ubie Discoveryでは、ポリシーもコード管理すべく水谷さん中心にOPA/Regoの取り組みを開始しており、監査する側の人間もRegoを読み書きできるようになろう！という取り組みを進めています。このような取り組みに面白みを見出し、Policy as a codeなど先進的な取り組みを一緒に進めて行きたい方のご応募をお待ちしています。
応募まで行かなくても、話を聞いてみたい、という方は、Meetyを公開しているので、そちらでもお気軽にコンタクトしてください。
Discussion