はじめに
(この記事はユニークビジョン株式会社 Advent Calendar 2018 10日目の記事です。また、この記事が書かれた2018年12月10日現在、ユニークビジョン株式会社はISO27001の審査の結果を待っている段階であり、認証を受けていませんのでご注意下さい)
普段、私はプログラマとして開発業務に携わっています。それと同時に、「セキュリティ委員会」という、週に1度、1時間程度、セキュリティに関する社内の問題点について考え、必要があれば対応するという、なんとなくふんわりとした組織、というか、サークルというか、不思議な組織に所属し、活動しています。
セキュリティ委員会発足時の議事録(2016年7月7日でした)を見ると、Pマークのような認証を、「取得すること自体」を目標として活動することについて、否定的に書かれています。結局、認証をとったとしても、きちんと運用しなければ意味はなく、逆にきちんと運用を行っているのであれば無理に取得をする必要はない、という意味でです。
その後の議事録をたどっていくと、Pマークと今回ここで話題に上げる、ISO27001の違いについてなど検討した旨が読み取れます。そのどれにおいても、認証が要求する意図、管理策について、有益なものがあれば、採用し、社内のセキュリティを向上させよう、とは考えるが、実際に認証を取得するつもりはない、というスタンスでした。
では、なぜ今回ISO27001を取得する方向へ舵を切ったのか。まあ、大した理由はなく、取引先と契約をする際に、規格を取得していると手続きを簡略化することができるため、というものでした。
しかし、数日前に審査を終え、審査結果を待つ今においても、規格自体の取得に重きを置かず、規格を利用して社内のセキュリティの向上を目指す、というスタンスは、全く変わりませんでした。ただ、実際に取得するための活動を行わなければ、規格が定める管理策の意図、意味を理解することはできなかった、とも思います。よって、実際に取得する活動を行ってよかったと考えています。
ISO27001と、取り組み方
ISOというと、堅苦しいというイメージを、少なくても私は持っていました。もちろん、よくよく考えてみると、C言語の仕様はISOによって規格化されていて、不明な点があれば規格を読む必要があるので、プログラマにとっては身近な存在といえるのかもしれません。しかし、私は普段コンパイラを作るようなことはしておらず、また、業務でC言語を利用することもなく、そのような国際規格を確認する機会はめったにありません。他にISOというものについて知っていることといえば、時折田舎道を走っていると、「ISO9001取得工場」という看板が目につくことがあるなぁ、という程度のものでした。
「ISO27001」というキーワードでWikipedia日本語版を検索すると、「情報セキュリティマネジメントシステム」の項へ転送され、その記事のはじめには以下のような記述があります（2018年12月9日23時閲覧）。
情報セキュリティマネジメントシステム（じょうほうセキュリティマネジメントシステム、ISMS: Information Security Management System）は、組織における情報資産のセキュリティを管理するための枠組み。情報セキュリティマネジメントとは、ISMSを策定し、実施すること。[1]
ISMSの目標は、リスクマネジメントプロセスを適用することによって、情報の機密性、完全性及び可用性を維持し、かつ、リスクを適切に管理しているという信頼を利害関係者に与える[2][3]ことにある。
ISMSの標準がISO 27001およびそれと同等なJIS Q 27001に規定されているので、本稿では2016年現在におけるこれらの標準の最新版であるISO/IEC 27001:2013（JIS Q 27001:2014と同等）を基に、ISMSを説明する。
その後、Wikipediaには説明が長々と書いてあります。が、正直、この活動を始めた頃の自分では、このWikipediaの記事の意味を、全て、具体的に何をやればよいのか、というイメージとともに理解することはできませんでした。ですが、後述するような作業を行ってきた今、改めて読むと何となくわかります。
ISO27001の規格を取得するにあたり、セキュリティ委員会は以下のような作業を行い(順番に行ったわけではありません。また、事業継続分析や、組織をとりまく環境の検討、守るべき法律の洗い出し等を実際には行いました)、ISMSを構築し、審査を受けました。
- 構築に際し、目標をたてて、経営陣の承諾を得た。
- 社内に存在する情報資産を洗い出した。
- ISO27001の規格が定める管理策に基づいてリスクアセスメントを行った。
- ISMSを運用するためのマニュアルを作成した。
- 監査を行った。
- 社内において、教育活動を行った。
- 構築したISMSのパフォーマンスを、この活動を行うことによって発見された社内の問題点の数などで、評価した。
- これまでの活動を経営陣に報告し、コメントをもらい、承認を得た。
- 審査を受けた。
ISMSを構築するにあたり、必要があれば、社内にルールを作る必要があります。ただ、今回の構築においては、なるべくルールを作らないことを目標にしました。弊社は一般的な会社に比べ、ルールが少ない会社だと思います。けれども、社内において、暗黙的に存在するルールがあります。そしてそれらのルールは、なんとなくメンバー全員で、必要だと思われているがゆえに、守られているルールだと思います。ので、ISMSの運用のためのマニュアルを作成するにあたっては、その暗黙的に存在するルールに基づいて、検討し、ルールとして文章にしていく、という作業を行いました。そのため、あらためて言われなくても、なんとなく社内の常識に従って業務を行っていれば、ISMSで定めたルールに基づいて業務を行っている状態に「大体」なる、という状態を作ることができたと考えています。
今の私の理解では、ISO27001が定めるISMSとは、社内の情報資産や組織をとりまく状況を評価し、その評価と規格が定める管理策に基づいてリスクを洗い出し、必要があれば改善する、改善し続ける活動、仕組みである、というものです。暗黙に存在する社内ルールをそのままルールとするケースが多かったとはいえ、リスクアセスメントの結果、あるいは監査の結果、たくさんの問題点が上がりました。今もその問題を改善し続けています。そしてその改善は確かに社内のセキュリティの向上、リスクの低減に寄与するものだと考えています。
この文章のはじめの方で、規格を取得すること自体には重きを置かない、と書きましたが、規格を実際に取得する作業を行うことによって、本来目的としていた、セキュリティの向上が図られる、という結果になりました。特に、認証を取得する作業に際し、コンサルタントの方や、審査を行ってくださった方による、外部の目による評価、というものは、非常に有益なものだったと思います。
実際に手を動かしてみると分かることがある、ということなのでしょう。
今後の課題
審査の結果はまだ出ていませんが、たとえ取得できなかったとしても、あるいは取得できたとしても、そこでこの活動が終わるわけではなく、改善を続けていく必要があります。特に、形骸化したルールが残らないように、常にルールの意味を問う作業を行っていきたいと考えています。