情報セキュリティマネジメントシステム(ISMS)認証取得までの取り組み

ISMS認証とは

ISMSとは、組織が保有する情報資産を安全に利用し、リスクを管理するためのしくみを指します。 ISMSはISOが制定した国際的な規格である「ISO/IEC 27001」の要求事項に基づき運用されます。ISMSの認証を維持するためには、ISMS取得後、1年後と2年後はサーベイランス審査（維持審査）、3年後には更新審査、という周期で3年毎に審査が繰り返されます（規格が更新された場合は、加えて更新審査も受ける必要があります）。

「ISO/IEC 27001」では、責任者の明確化、情報の分離、アカウント管理...など、最新の規格で93項目の要求事項が定められています。 これらの要求事項に沿いPDCAサイクルに基づき運用し、第三機関の審査を受け、基準を満たす組織にISMS認証が与えられます。

※PDCAとは、Plan（計画）、Do（実行）、Check（評価）、Act（改善）の頭文字を取った略称です。

• Plan（計画）...ルールを明文化し、リスクに応じた対策を計画する
• Do（実行）...ルールや計画に従い運用し、記録をする
• Check（評価）...実施状況を監査し評価する
• Act（改善）...評価結果を改善する

認証取得に向けた文書作成

弊社ではすでに個人情報保護の認証であるプライバシーマークを取得していたため、プライバシーマークの基準に沿った、情報を適切に保護し管理するしくみは運用されていました。

ただし、プライバシーマークとISMSはどちらも情報セキュリティに関する認証ですが、規格で定めた保護する情報の対象が異なります。 プライバシーマークは個人情報を保護対象としているのに対し、ISMSは個人情報を含む機密情報全般を対象としています。 そのため、個人情報に当たらない財務情報や技術情報などの機密情報全般を対象とした運用プロセスを作り、文書を追加で作成する必要がありました。

ISMSの外部コンサルタントに文書のベースを作成してもらい、弊社の運用に合わせて細かに修正を重ね次の文書を作成しました。

• 情報セキュリティポリシー
• 情報を適切に取り扱い管理するための方針、体制、およびルールをまとめた文書
• 災害、障害、もしくは情報漏洩などのインシデントが起きた時に事業を継続する手順
• 社内システム部門や事務所を管理する部門など各部門の役割や定義を定めた文書
• 従業員むけにISMSのルールを定めたマニュアル
• 情報資産と情報資産別にリスク分析をした台帳
• 内部監査、マネジメントレビュー、もしくは年度計画などの運用記録

情報資産の再度棚卸し

ISMS、プライバシーマークのいずれにおいても、社内で扱う情報資産を洗い出した管理台帳を作成します。管理台帳はプライバシーマーク運用のために既に作成していましたが、ISMS審査に向け、下記の手順で再度洗い直しました。

1.資産ごとのCIAと資産レベルの算出

まずは、顧客情報や会社概要などの粒度で特徴や目的が同じ資産別に分類し、情報セキュリティの三要素であるCIAを数値化し、その合計値から資産レベルを算出します。

※CIAとは、情報セキュリティの三要素と呼ばれる機密性(Confidentiality)、完全性(Integrity)、可用性(Availability)の略称です。

• 機密性(Confidentiality)...アクセスを許可されたものだけが、必要な情報資産を利用できる
• 完全性(Integrity)...情報が正確で完全な状態で利用できる
• 可用性(Availability)...アクセスを許可されたものだけが、必要なときに利用できる

例えば社外秘である顧客情報は、従業員の中でも顧客対応に関連する担当者のみに利用は限定され、データは改ざんされない正確な状態である必要があり、必要な時に利用できないと事業に影響を及ぼす可能性があります。この場合は資産レベルも高くなります。

一方、会社概要などの対外向けの情報は公開されている情報のため機密性は下がり、顧客情報に比べると必要なときにすぐアクセスできずとも影響は軽微です。この場合は資産レベルの値も低くなります。

2.脆弱性の評価

洗い出した情報資産が災害やサイバー攻撃などのインシデントに対して、どれほどの弱点があるかを脆弱性の値として数値化します。 想定されるインシデントに対して正しく対応できていれば脆弱性の数値は下がり、一方で対応策を取っていないものは脆弱性の数値は上がります。

3.リスク値の算出

ここまで算出した資産レベルと脆弱性の評価値をもとに、リスク値を算出します。 資産レベルが高くても対策が取られていれば脆弱性の数値は下がり、リスク値も抑えられます。 一方資産レベルが高いにも関わらず、対応策を講じていなければ脆弱性の値は上がり、リスク値も上がります。

4.リスクの値の評価

受容できるリスクのレベルを定め、基準を上回った資産に対してリスクを認識し、組織の状況を加味してリスクを受け入れるかを判断します。

社内で利用している外部クラウドサービス（SaaSサービスとパブリッククラウド）の管理上の課題

資産を洗い出す中で、大きな課題となったのがクラウドサービスの管理です。 弊社は業務の特性上、クラウドサービスの利用が欠かせません。全社的に利用頻度が高いものや重要な機密情報を扱うクラウドサービスは厳格な管理をしていましたが、それ以外のクラウドサービスは情報が各所に散らばっていました。

そのため、誰がどのような目的で、どのようなクラウドサービスを利用しているかを一覧にした、クラウドサービスの台帳を作成することにしました。

1.利用許可基準や利用方法をまとめた社内ルールの作成

まずは台帳を作成するにあたり、クラウドサービスの利用許可基準や利用方法を社内ルールとしてまとめるところから始めました。 利用許可基準には、情報セキュリティに関する認証を取得しているか、解約後にデータ削除がされるか...など安全なクラウドサービスだと判定できる項目を定めました。

2.申請フローの整備

整備前はチャットツールで確認を取り利用を開始していたため、申請フォームを整え、情報セキュリティ担当の承認を得てから利用する運用に変更しました。 申請フォームを整えることで、「いつ」「だれが」許可したか証跡を残すことができ、内部統制の強化にもつながりました。

3.台帳への洗い出し

社内ルールとフローを整備した後は、部署ごとに利用しているクラウドサービスを洗い出してもらいました。 洗い出し後にサービス名やサービスの管理責任者、担当者などの情報を台帳化し、全従業員が閲覧できる場所に保管し情報を集約しました。

一覧で洗い出した結果、弊社では100社近いクラウドサービスを利用していることが判明しました。 こういった情報が整備されていないと、どこを見ればよいかわからないだとか、誰に聞けばよいの分からないといった状況が発生します。ISMS取得に向けた取り組みが、情報を整備する良いきっかけになりました。

最後に

こうして社内ルールの整備や文書作成に始まり、PDCAに基づいた運用を行い、ISMS認証を取得することができました。 しかし、ISMS認証は取得したら終了ではなく毎年定期的な審査を繰り返し、継続して確認し改善する必要があります。 ISMSの要求事項に沿って正しく情報を取り扱うためには、情報セキュリティ担当だけでなく、全従業員が情報セキュリティに関するルールを理解し運用してもらうことが重要です。

今回整備した社内ルールや手順は、一度作成後に周知をしただけでは中々社内に根付きません。 定期的な教育に加え、啓蒙資料の作成や手順のこまめな整備を繰り返し、より従業員に伝わりやすく発信することを意識し運用してまいります。