はじめに
本記事は、CySec(中央大学が提供する社会人向けセキュリティ教育プログラム)第1回の後編、シリーズ通しで #2 にあたる復習ログです。前編では、「なぜ情報セキュリティは標準化されるのか」を、ISO/IEC とマネジメントシステムの歴史からたどりました。記事の軸にしたのは、次の大きな物語です。
標準化は「ネジ(部品)→ 品質管理 → マネジメントシステム → ガバナンス(経営者の責任)」へと進化してきた。
前編では、このうち「ネジ → 品質 → マネジメント」までを立ち上げました。後編であるこの記事では、いよいよ最後の「→ ガバナンス」まで物語を進めます。具体的には、ISMS がどういう歴史で生まれたのか、なぜ 2022年に大改定されたのか、そしてその中核にあるリスクマネジメント(ISO 31000)とは何かを整理します。
想定読者は、少し前の私と同じく、「情報処理安全確保支援士や ISMS 審査員、CISSP などの学習・実務で ISO 27001 / ISMS に触れ始めたが、その歴史的背景やリスクマネジメントの型を知らない学習者」です。前編を読んでいなくても追えるように書きますが、物語の流れは前編から続いています。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。
情報セキュリティの規格を作る人たち ── SC27 の5つの WG
前編で、IT 分野の国際規格は ISO/IEC JTC1(第一合同技術委員会)が担当し、その下に SC(専門委員会)が番号で並んでいると書きました。私たちが学ぶ ISO/IEC 27001 は、このうち SC27 が手がけている規格です。
SC27 の正式名称は「情報セキュリティ・サイバーセキュリティ・プライバシー保護」です。その内部は、さらに5つの WG(作業部会、Working Group)に分かれています。
| WG | 担当分野 | 代表的な規格 |
|---|---|---|
| WG1 | 情報セキュリティマネジメントシステム | ISO/IEC 27000 シリーズ |
| WG2 | 暗号とセキュリティメカニズム | ISO/IEC 18033 など |
| WG3 | セキュリティ評価基準 | ISO/IEC 15408(コモンクライテリア) |
| WG4 | セキュリティコントロールとサービス | — |
| WG5 | アイデンティティ管理とプライバシー技術 | — |
ここで覚えておきたいのは、私たちが普段「ISMS」と呼んでいる ISO/IEC 27001 や 27002 は、WG1 の管轄だという点です。暗号(WG2)や製品の評価基準(WG3)は別の WG が担当しています。同じ「27000 番台」でも、規格によって作っているチームが違います。番号だけ見ていると一枚岩に見えますが、内部はこのように分業されています。
ISMS はどう生まれたか ── 標準化前夜から BS7799 まで
ここから ISMS の歴史です。いきなり ISO 27001 が生まれたわけではなく、そこに至るまでには助走期間がありました。年代ごとに追ってみます。
1980年代 は、共通の規格がない時代でした。情報セキュリティに取り組んでいたのは一部の大企業くらいで、各社が独自のやり方で対応していました。「自社ではこう守る」という個別の工夫はあっても、横でそろえる物差しが存在しなかったわけです。
1990年代 に入ると、いくつかのガイドラインや評価基準が登場します。
- GMITS(ISO/IEC TR 13335): IT セキュリティ管理の技術ガイドラインです。
- Common Criteria: 米国の TCSEC と欧州の ITSEC を統合する、セキュリティ評価基準の流れです(後の ISO/IEC 15408)。
- 情報システム安全対策基準: 日本のいわゆる「安対制度」です。ただしセキュリティに関する記述は数ページほどで、大型コンピュータが中心の時代の内容でした。
そして、この時期に英国で登場したのが BS 7799 です。英国規格協会(BSI)が作ったこの規格は、現場で使いやすく、しだいにデファクトスタンダード(事実上の標準)として広がっていきました。ただし、当時はまだ社会全体のセキュリティへの関心は低いままでした。
2000年代 になって、状況が一変します。2000年問題、Windows の普及、そしてインターネットの一般への普及が重なり、情報セキュリティへの関心が一気に高まりました。守るべき情報がどの組織にもある時代になったのです。共通の物差しを求める声が、ここで初めて大きくなりました。
BS7799 の物語 ── 一度否決され、それでも国際規格になった
ここで少し寄り道して、BS 7799 にまつわるエピソードを紹介します。私が「規格にも物語があるんだな」と思った話です。
英国で評価されていた BS 7799 を、「これは世界で使える」と考えた人たちが ISO に持ち込みました。ところが、私が学習に使った教材では、1996年の投票で一度否決されたと説明されていました(理由は「先進的すぎた」「標準化を主導する組織が反対した」とのことです)。一次資料での裏取りは私はまだできていないので、詳しい方はぜひ教えてください。いずれにせよ、良い規格であってもすんなり国際規格になれるわけではない、という話として受け取っています。
しかしその後、「良いものは良い」という声が再評価につながり、BS 7799 は形を変えて国際規格化されていきました。一度ダメだったものが評価され直して世界標準になる、というのは、技術の世界でもよくある展開です。この経緯を知っておくと、ISO 27001 が「最初から完成形として降ってきたルール」ではないと実感できます。
ISMS の系譜 ── BS7799 から ISO/IEC 27001 へ
BS 7799 が、どのように現在の ISO/IEC 27001 / 27002 になったのかを整理します。BS 7799 はもともと2部構成でした。
- BS 7799-1(実践規範): やるべきこと(管理策)を集めた手引きです。これが ISO/IEC 17799 として国際規格化され(2000年発行、2002年に正式版)、2006年に ISO/IEC 27002 へ改称されました。
- BS 7799-2(要求事項): 認証の土台となる「満たすべき要件」です。これが ISO/IEC 27001(2005年制定・発行)になりました。
つまり、現在の ISO 27001(要求事項=認証される側)と ISO 27002(管理策の手引き)は、もとをたどれば BS 7799 の2つのパートに行き着くわけです。
ここで一つ、規格番号にまつわる面白い痕跡があります。JIS 化したときの頭文字です。X は技術の規格、Q はマネジメントの規格を表します。情報セキュリティの規格は、当初は技術規格だと思われていたため JIS X 5080 という番号でした。ところがその後、「これはマネジメントの規格だ」と位置づけが見直され、JIS Q 27001 / JIS Q 27002 という Q 番号に切り替わりました。番号の頭文字に、「技術規格だと思われていたものが、マネジメント規格だと捉え直された」歴史が刻まれているということです。
日本の ISMS 略史 ── 旧認証制度から国際規格ベースへ
日本での歩みも見ておきます。日本には、ISMS 認証制度が始まる前に独自の認定制度がありました。
| 時期 | できごと |
|---|---|
| 1981年7月20日 | 「情報システム安全対策実施事業所認定制度」開始(通商産業省告示342号) |
| 2000年7月31日 | 旧制度を打ち切り |
| 2001年4月 | ISMS 認証制度(第三者認証)を本格運用(JIPDEC 主導) |
旧制度が終わり、国際規格をベースにした第三者認証へと舵を切ったのが 2001年です。JIS のほうも、これに合わせて整備されていきました。
-
JIS X 5080:2002(ISO/IEC 17799:2000 に対応。情報セキュリティ管理基準) - 2005年以降は国際規格をベースにする方針へ
-
JIS Q 27001:2006/JIS Q 27002:2006(ISO/IEC 27001:2005 / 27002:2005 に対応)
前の章で触れた X から Q への切り替わりが、ここで実際の番号として現れています。現在は、国際規格を翻訳して JIS 化する運用が定着しています。日本独自の規格を一から作るのではなく、世界標準を日本語に持ち込む形です。
なお、日本の ISMS 認証数は右肩上がりで伸びてきました。2024年9月時点では、約7,914認証に達しています。前編で見たとおり、情報を守ることへの関心が、それだけ多くの組織に広がっているわけです。
2022年の大改定 ── ISO/IEC 27002 はなぜ 114→93 になったのか
ここが後編の山場の一つです。ISO/IEC 27002 は、2013年版から 2022年版への改定で、管理策の構成が大きく変わりました。具体的には、14カテゴリ・114項目から、4カテゴリ・93項目 へと再編されました。
| 項目 | 2013年版 | 2022年版 |
|---|---|---|
| カテゴリ数 | 14 | 4 |
| 管理策の数 | 114 | 93 |
新しい4カテゴリは、次のとおりです。
| カテゴリ | 管理策の数 |
|---|---|
| 組織的管理策 | 37 |
| 人的管理策 | 8 |
| 物理的管理策 | 14 |
| 技術的管理策 | 34 |
93項目への再編の内訳は、追加が11、統合が24、更新が58 です。単純に数が減ったのではなく、重複していた管理策を統合し、足りなかったものを追加し、多くを現代向けに更新した結果が「93」という数字です。
新規追加された11の管理策
時代の変化が一番よく見えるのが、新しく追加された11の管理策です。
| 番号 | 管理策 |
|---|---|
| 5.7 | 脅威インテリジェンス |
| 5.23 | クラウドサービス利用のための情報セキュリティ |
| 5.30 | 事業継続のための ICT 準備 |
| 7.4 | 物理的セキュリティ監視 |
| 8.9 | 構成管理 |
| 8.10 | 情報削除 |
| 8.11 | データマスキング |
| 8.12 | データ漏えい防止 |
| 8.16 | 監視活動 |
| 8.23 | Web フィルタリング |
| 8.28 | セキュアコーディング |
クラウド、脅威インテリジェンス、データ漏えい防止、セキュアコーディングと並べてみると、この10年で現場の関心がどこへ移ったかが一目で分かります。改定の理由は、認証取得組織の増加、クラウドなどの技術進歩、そしてサイバーセキュリティの深化です。要求事項である ISO/IEC 27001 のほうも、2013年(マネジメントシステムの共通構造に準拠)を経て 2022年に改定されています。
認証を取得している組織には、新版へ移行する期限が設けられます。この移行期限は、認定機関(IAF や日本の ISMS-AC)の決議によって決まります。ISO/IEC 27001:2022 では、発行から3年にあたる 2025年10月末 が移行期限とされ、この記事を書いている2026年時点ではすでに期限を過ぎています(以後、2013年版の認証は失効扱いです)。すでに認証を持っていた組織にとって、改定は「いつかやること」ではなく、すでに対応必須の「自分ごと」でした。
ISMS の広がり ── クラウド(27017)とプライバシー(27701)
ISMS は、ISO 27001 / 27002 だけで完結しているわけではありません。土台となる 27001 を拡張する形で、特定領域に踏み込んだ規格が用意されています。
| 規格 | 領域 | 位置づけ |
|---|---|---|
| ISO/IEC 27017 | クラウドセキュリティ | ISO 27001 を拡張 |
| ISO/IEC 27701 | プライバシー情報マネジメント | ISO 27001 / 27002 を拡張 |
現在のところ、これらはいずれも ISMS の「追加認証」という扱いです。27001 の認証を土台にして、その上にクラウドやプライバシーの認証を積み増すイメージです。ただし将来的には、個別の認証として分かれていく見込みだと学びました。領域が成熟すると、土台から独立して一本立ちしていく、というのは規格の自然な成長過程なのかもしれません。
リスクマネジメントの型 ── ISO 31000
ここで、ISMS の中核にあるリスクマネジメントに踏み込みます。ISMS は「リスクに基づいて管理策を選ぶ」仕組みなので、リスクの扱い方を知らないと話が前に進みません。その共通の型を定めているのが ISO 31000 です。
ISO 31000 は、初版が 2009年、改訂版が 2018年です。対象は規模や業種を問わず、あらゆる組織です。日本での系譜も興味深く、1995年の阪神・淡路大震災を契機にした危機管理規格 JIS Q 2001 が出発点でした。その後、自然災害に限らずリスク全般を扱うように拡張され、JIS Q 31000 へと置き換わっています。
リスクの定義が直感に反して面白い
ISO 31000 で一番おさえておきたいのが、リスクの定義です。
リスクとは、目的に対する不確かさの影響である。
ここで注目したいのは、「影響」は良い方向にも悪い方向にも逸脱しうる、という点です。つまりリスクには、悪い結果だけでなく、好ましい方向の「機会(チャンス)」も含まれます。「リスク=危険・損失」という日常の感覚からすると、これは直感に反します。私は最初これを聞いたとき、「リスクに良い意味があるのか」と少し驚きました。リスクをきちんと管理するとは、危険を避けるだけでなく、機会をつかみにいくことでもあるのです。
主要な用語も整理しておきます。
| 用語 | 意味 |
|---|---|
| リスクレベル | 結果 × 起こりやすさ |
| リスク基準 | リスクの重要性を評価するための「ものさし」 |
| リスクアセスメント | リスク特定・リスク分析・リスク評価の総体 |
| 残留リスク | 対応したあとに残るリスク |
| 管理策(Control) | リスクを修正するための手段 |
2009年版から2018年版への変化
ISO 31000 は、2009年版から 2018年版への改訂で、いくつか重要な変化がありました。
| 観点 | 2009年版 | 2018年版 |
|---|---|---|
| 原則の数 | 11原則 | 8原則に整理 |
| 用語 | 指令及びコミットメント | リーダーシップ及びコミットメント |
| 責任主体 | トップマネジメント | 監督機関(取締役会など)及びトップマネジメント |
私がここで注目したいのは、責任主体の変化です。2009年版では「トップマネジメント」だったところが、2018年版では「監督機関(取締役会など)及びトップマネジメント」へと明確化されました。実務の経営層だけでなく、それを監督する取締役会まで責任の射程に入ったわけです。これはまさに、本記事の物語のゴールである「ガバナンス」への伏線になっています。また、「指令及びコミットメント」が「リーダーシップ及びコミットメント」へと言い換えられたのは、ほかのマネジメントシステム規格と表現をそろえる動きです。前編で見た HLS の発想が、ここにも効いています。
リスクマネジメントのプロセス
ISO 31000:2018 の本体である、リスクマネジメントのプロセス(第6章)を見ておきます。箇条番号とともに整理すると、次のような流れです。
なお、6.2 コミュニケーション及び協議と 6.6 モニタリング及びレビューは、本来どれか1工程に挟まるものではなく、全プロセスに並走します(図ではこの2つに「全プロセスに並走」と注記し、6.2 からの点線も代表的な工程にだけ引いています)。リスクアセスメント(6.4)は、リスク特定 → リスク分析 → リスク評価という3ステップの総体です。そのあとのリスク対応(6.5)では、見つけたリスクにどう向き合うかを選びます。選択肢は次のとおりです。
| リスク対応 | 中身 |
|---|---|
| 回避 | リスクの原因となる活動をやめる |
| 低減 | 管理策で発生可能性や影響を下げる |
| 保有 | リスクを受け入れて持ち続ける |
| 共有 | 保険や委託で他者と分け合う |
| 機会の追求 | 好ましいリスク(機会)を積極的に取りにいく |
「機会の追求」が選択肢に入っているのが、先ほどのリスク定義(良い方向の影響も含む)と一貫しています。リスク対応は、避ける・減らす・受け入れる・分け合う、だけではありません。
なお、2009年版にあったプロセス図の細かい矢印は、2018年版では「誤解を生む」として削除されました。代わりに「記録作成及び報告」(6.7)が独立した項目として追加されています。プロセスを図で縛りすぎず、記録と報告を明示する方向へ整理されたわけです。
そしてガバナンスへ ── 誰が責任を取るのか
ここまで来て、ようやく物語のゴールである「ガバナンス」にたどり着きます。前編から続く軸の、いまどこにいるかを示すと、こうです。
ネジ(部品)→ 品質管理 → マネジメントシステム → 【現在地】ガバナンス(経営者の責任)
標準化は、部品(ネジ)から始まり、品質、組織を動かす仕組み(マネジメントシステム)へと、対象を一段ずつ抽象化しながら登ってきました。情報セキュリティも、社内利用に閉じている間は、何か起きても「社内の問題」で済みます。ところが、顧客の情報を預かり、サービスとして外に提供するようになると、事故の影響は顧客にまで及びます。そうなると問われるのは、「いったい誰が責任を取るのか」です。
この問いに答える仕組みが、IT・情報セキュリティの ガバナンス です。前の章で見た ISO 31000:2018 が、責任主体を「監督機関(取締役会など)及びトップマネジメント」へと明確化したのは、まさにこの流れの表れです。現場の担当者でも、システム部門だけでもなく、経営を監督する立場までが責任の輪に入る。ここで標準化の物語は、ついに経営の話へと到達します。
最後に、私が一番面白いと思った対比を紹介します。これまで見てきた規格は、いずれも「部品 → 品質 → マネジメント → ガバナンス」という順に、下から登ってきました。ところが AI の分野だけは、逆向き だと学びました。AI では、多くの組織がまず「ガバナンス」から着手しているのです。技術が積み上がってから経営の話になるのではなく、影響が大きすぎるために、最初に経営の責任を問うところから始まっている。標準化のたどってきた道とは逆順で、ここに時代の変化を感じます。
まとめ
この後編では、ISMS の歴史とリスクマネジメントを通して、前編から続く物語を、軸のゴールである「ガバナンス(経営者の責任)」まで進めました。後編で立ち上げたのは、次のところです。
- ISMS(ISO 27001 / 27002)は SC27 の WG1 が担当し、英国の BS 7799 を源流とする。BS 7799 は(教材によれば)1996年に一度否決されたが、再評価されて国際規格になった。
- 規格番号の頭文字 X / Q には、「技術規格だと思われていたものがマネジメント規格と捉え直された」歴史が刻まれている。
- 日本は 2001年に旧認定制度から ISMS 認証制度へ移り、いまは国際規格を翻訳して JIS 化している。認証数は右肩上がりで、2024年9月で約7,914認証。
- ISO/IEC 27002 は 2022年改定で 114項目・14カテゴリから 93項目・4カテゴリへ再編され、クラウドや脅威インテリジェンスなど11の管理策が新設された。
- ISO 31000 はリスクを「目的に対する不確かさの影響」と定義し、悪い方向だけでなく良い方向の「機会」も含む。2018年版は責任主体に監督機関を加え、ガバナンスの視点を強めた。
- 標準化の物語は最後に「ガバナンス(経営者の責任)」へ到達する。AI 分野だけは逆向きに、ガバナンスから始まっている。
前編と後編をあわせて読むと、ISO 27001 が「いきなり生まれた特別なルール」ではなく、100年以上続く標準化の歴史の延長線上にあり、その先にガバナンスという経営の話が待っている、という見取り図が完成します。この地図を持っておくと、これからセキュリティの規格やリスクマネジメントを学ぶときに、用語が物語の中に位置づいて理解しやすくなるはずです。ここまで読んでいただき、ありがとうございました。
参考
本記事で挙げた年号・規格番号・数値は、次の一次情報で確認できます。記事中の数値は学習時点のもので、最新値は各サイトで確認してください。
- ISO 公式: https://www.iso.org/
- ISO/IEC 27001(情報セキュリティマネジメントシステム): https://www.iso.org/standard/27001
- ISO/IEC JTC 1/SC 27(情報セキュリティの専門委員会): https://www.iso.org/committee/45306.html
- ISO 31000(リスクマネジメント): https://www.iso.org/iso-31000-risk-management.html
- The ISO Survey 2022(認証数): https://www.iso.org/the-iso-survey.html
- ISMS-AC(情報マネジメントシステム認定センター。ISO/IEC 27001:2022 への移行期限などの根拠): https://isms.jp/
- IPA(情報処理推進機構): https://www.ipa.go.jp/
※ ISO/IEC 27001:2022 への移行期限(発行から3年=2025年10月末)は、認定機関(IAF / ISMS-AC)の決議に基づきます。
※ BS 7799 が 1996年に否決された経緯は、私が学習に使った教材(CySec 講義)に基づく記述で、一次資料は未確認です。