砂糖の甘い付箋

国際規格ISO/IEC 27701プライバシー情報マネジメントシステムのJIS化

プライバシー対策に関わる国際規格であるISO/IEC 27701が、JIS化されて発行されますので紹介します。

日本語対訳書が2020年3月に出版されていましたが、このたび、JIS規格として国内規格になることになりました。

草稿はできあがり最終的な出版の準備が進められています。（2023年3月現在）

ISO/IEC 27701とは

ISO/IEC 27701は、ISMS（情報セキュリティマネジメントシステム）の要求事項を規定したISO/IEC 27001及びISMSを実施するための規範をまとめたISO/IEC 27002に、プライバシー対策に関する要求事項及び規範を拡張することにより、組織によるPIMS（プライバシー情報マネジメントシステム）の構築を支援することを目的とした国際規格です。

27701の開発経緯は、ブログ「ISO/IEC 27701「プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張」の解説」で紹介しています。

27701と国内規格や個人情報保護法との違いなどは、ブログ「国際規格ISO/IEC 27701プライバシー情報マネジメントシステムと国内規格や個人情報保護法との違い」で紹介しています。

国際規格の27701は、ISO/IEC 27002規格が構成変更になったことを反映するための改訂を終えて、出版の最終準備段階にあります。（2023年3月現在）

そのため、JIS 27701が出版されるときには、国際規格の27701が改訂されていることになりますが、国際規格の改訂は現状の考え方や内容が大きく変わるものではなく、27002の構成変更に対応するための改訂なので実質的な問題はないと言えます。

ISO/IEC 27701の対訳書の課題

話しをJIS 27701に戻すと、もともと対訳書がある国際規格がJIS化される場合には、基本的には対訳書を大きく変えることはありません。

しかし、国際規格の27701は、通常の単語の使われ方とは異なる定義語がいくつかあります。定義した単語なので、定義語だと割り切って、その単語の元の意味にこだわらずに読めばよいのですが、誤解しやすい規格文になっています。

それらを概ね直訳した対訳書をそのままJIS規格にすると、日本語でも同様に、誤解しやすい規格文になってしまいます。

ISO/IEC 27701のJIS化での用語の見直し

そこで、今回のJIS 27701では、定義されている内容に見合うように定義語を書き換えました。

たとえば、国際規格の「customer」を対訳書では「顧客」と訳してありますが、JIS規格では「取引先」と訳すことに変えました。
この単語の訳だけを見ると、「customer」の訳が「取引先」って日本語訳がおかしいと思うかもしれませんが、国際規格での「customer」の定義内容を読むと、それが必ずしも「顧客」だけの意味ではないことがわかります。

たとえば、「customer」の定義の中に委託先が含まれています。
規格として委託先を含むと定義しているので、委託先を「顧客」と呼ぶことは規格として間違えではありません。
しかし、規格文を読むときに頭の中で、「顧客には委託先も含まれている」 と言い聞かせながら読まなければならなくなります。

そこで、JIS規格では「取引先」と訳しました。顧客のことを「取引先」と呼ぶことに違和感があるかもしれませんが、委託先を「顧客」と呼ぶことの違和感よりは、比べればましなのではないかということで、そのようにしました。

他にもあります。対訳書では「partner」を「取引相手」と訳していますが、JIS規格では「相手方」としました。
規格では、取引のある相手のことだけではなく、遵守事項を守らせる契約をしただけの相手のことも「partner」としています。
取引があれば「取引相手」で違和感はないのですが、単に守秘義務の誓約書を交わすだけの対象を「取引相手」と呼ぶよりは、単に「相手方」と呼ぶ方が、取引の有無とは関係ないということについて読みやすくなるために書き換えました。

これらは、私が27701規格の対訳書を理解するためのコンサルティングで、「規格文に書いてある顧客を取引先のこと、取引相手を単に相手方と読み替えるとわかりやすくなりますよ。」と説明していたものが採用されました。後から思ったのは、コンサルティングのネタの１つがなくなってしまうので、ちょっと惜しいことをしたかなと後悔していたりもします。（笑)

コンサルティングで説明していることには、他にもあります。 

この規格では、いわゆる個人情報のことをPII（Personally identifiable information）と呼びますが、これに付随した用語で難解とされているものに、PII管理者とPII処理者があります。

用語だけからすると、PIIを管理する人がPII管理者で、PIIを処理する人がPII処理者と思ってしまいそうですが、そうではありません。

定義では、PII管理者はPIIの利用目的を決定する人で、PII処理者はPII管理者の指示に従ってPIIを処理する人となっています。そのため、PII管理者とPII処理者は、両者ともそれぞれの役割にそってPIIを管理し処理もします。

これらの用語を単語の意味合いからの誤解を避けて直感的に読めるようにするには、たとえば、PII利用目的決定者と、PII委託処理者などとすれば、管理と処理という単語にまどわされずに、わかりやすくなるかもしれません。

しかし、PII管理者とPII処理者という用語は、既に出版されているJIS X 9250(ISO/IEC 29100)で定義されているものなので、JIS 277071でも変えずに直訳したままにしました。（決して、コンサルティングのネタが惜しくなって、わかりにくいまま残したのではありません。笑）

 

以上のような背景で、JIS 27701規格の用語のいくつかを、あえて英単語とは異なる日本語にしましたので、規格を読むときの参考にしてください。

国際規格ISO/IEC 27701プライバシー情報マネジメントシステムと国内規格や個人情報保護法との違い

 

　プライバシー対策に関わる国際規格としてISO/IEC 27701が、2019年8月に国際標準として発行されました。この規格について紹介します。

ISO/IEC 27701とは

　これは、ISMS（情報セキュリティマネジメントシステム）の要求事項を規定したISO/IEC 27001及びISMSを実施するための規範をまとめたISO/IEC 27002に、プライバシー対策に関する要求事項及び規範を拡張することにより、組織によるPIMS（プライバシー情報マネジメントシステム）の構築を支援することを目的とした国際規格です。27701は、日本工業規格化はされていませんが、日本語対訳書が2020年3月に出版されています。

　27701は、PIMSを構築するためのものですが、独立したマネジメントシステムではなく、ISMSによるマネジメントシステムの拡張として規定されています。

　また、27701を基にしてISMSの審査及び認証を行う機関に対する要求事項の開発が2019年12月に開始され、2021年2月にISO/IEC 27006（情報セキュリティマネジメントシステムの審査及び認証を行う機関に対する要求事項）のPart 2（PIMS）が技術標準として発行され、現在対訳書が準備中です。27006-2については、さらに内容を充実させるための国際標準化の審議が継続されています。

　国内では、27701を基にしたISMS-PIMS認証が2020年12月から開始されており、既に認証を取得した組織もあります。

27701と15001の位置付け

　日本では、個人情報保護マネジメントシステムとしての日本工業規格として、JIS Q 15001が1999年に発行されています。こちらは、27701とは異なり、独立したマネジメントシステムとして規定されています。15001を基にした個人情報保護マネジメントシステムの認証としては、JIPDEC（一般財団法人日本情報経済社会推進協会）によるプライバシーマーク制度や、JAPiCO（一般社団法人日本個人情報管理協会）によるJAPiCOマーク制度などが普及しています。

　27701と15001は、将来どちらか１つに統合されるものではなく、異なる２つのマネジメントシステムを構築するためにそれぞれ利用することができるものです。

　15001の最新の改正は2017年に改正されましたが、この改正により、マネジメントシステムの要求事項は、ISMSの27001とほとんど同じになりました。異なるのは、管理目的と管理策の包括的なリストである附属書の内容と、それらを実施するための規範の内容になります。

　27701の管理目的、管理策及び規範は、国際標準であるISO/IEC 29100（プライバシーフレームワーク）に基づいています。29100は、対応する日本工業規格が2017年にJIS X 9250として発行されています。

　15001の管理目的、管理策及び規範は、日本の個人情報保護法に基づいており、それに利用目的の事前同意取得（オプトイン）を求めるなどの要求事項を追加した内容になっています。

 国際標準と国内法の違い

　国際標準が国内法と異なる点はいくつかありますが、その一つは、保護の考え方です。国内法では、その名のとおり個人情報を保護しようとします。たとえば、電話番号については、どういう状況なら電話番号が個人情報になるのかを考え、それに該当するなら保護します。他方、欧米では、電話番号は疑いなく個人情報とした上で、個人情報の利用を保護しようとします。たとえば、夜間に電話できる時間帯を制限したり、職場に個人の投資信託のセールス電話をかけたりすることは、プライバシーを侵害することとして保護します。しかし、職場の電話番号に職場で必要な事務用品のセールス電話をかけることはプライバシーの侵害としません。つまり、電話番号が何かではなく、電話番号を使って何をするかに制限をかけようとします。 これについて詳しくは、以下のコラムで紹介しています。

• デジタル・フォレンジック研究会 第596号コラム「個人情報保護法改正に向けて」

　プライバシー対策を個人情報保護対策と訳して考えてしまうと、それらに違いがあることにとまどうかもしれませんが、上記の前者を個人情報保護対策、後者をプライバシー対策と区別して考えれば、わかりやすくなると思います。実際にも、個人情報保護を英訳すれば、protection of personal informationあるいはpersonal information protectionであり、privacy protectionではありません。そのため、プライバシーを保護するという表現はあまりされず、プライバシーの尊重(respect for privacy)という表現をします。プライバシーを尊重するために、個人情報を保護するという建付けを欧米ではしており、国際標準はその考え方に基づいています。

　国際標準と国内法の異なる点としては、PII管理者とPII処理者を区別することもあります。（PII:Personally Identifiable Information）これについては、以下のコラムで紹介しています。

• デジタル・フォレンジック研究会 第559号コラム「クラウド時代の情報管理：情報の管理者と処理者を区別することの重要性」

　その他にも、異なる点がありますが、27701の規格文書の構成については、解説動画としてまとめてあります。

• YouTube 「[15分でわかる] ISO/IEC 27701 PIMS概要」

　規格の開発経緯は、以下の記事で紹介しています。

• ブログ「ISO/IEC 27701「プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張」の解説」

 27701と15001の使い分け

　以上のように、組織が構築するマネジメントシステムで国際標準に合わせたいなら27701を、国内法に合わせたいなら15001を利用するという使い分けをすることができます。

iPhoneは他のスマフォに比べてなぜ比較的安全なのか～技術者以外にもわかるsandbox機能

iPhoneやiOSのOSであるiOSがバージョン10になるとのこと。

 

いろいろと便利な機能が増えて楽しそう。
Gigazineの記事：
iPhone・iPad向け最新OS「iOS 10」が発表、10の新機能が追加されシリーズ史上最大のアップデートへ

 

このiOS10については、これらの機能改善に加えて、セキュリティ機能の変更が検討されていました。
具体的には、ここで紹介するsandbox保護機能についての一部緩和です。セキュリティに関係する機能を緩和するということは、実は危険性が増すということになります。

 

まずは、sandbox機能の説明をした上で、それがどう役立つのかと、なぜ、その役立つ機能を一部はずそうとしたのかを、技術者ではなくても、わかるように紹介したいと思います。
・・・図のない長文ですが、お許しください。

sandboxとは、各アプリがアプリ間でデータなどを直接やり取りできないようにする機能のことです。
アプリには、アプリが使うデータを保存するために、アプリ個別の領域が用意されて、アプリはその領域にしかデータ保存ができません。
アプリをスマフォにインストールするときには、まず、スマフォの中に専用個室が作られ、アプリはその個室内でデータを処理することになります。
これが、子供が砂場の中で遊ぶような状態であることから、砂場を意味するsandbox機能と呼ばれています。

 

仮にマルウェアのアプリを誤ってインストールしたり、ウイルスに感染してしまっても、マルウェアは砂場の外に出れないので、他のアプリのデータを盗み見たり、書き換えたりすることができません。

 

iPhoneやiPadなどのOSであるiOSには、このsandbox機能があります。
AndroidやWindowsにsandbox機能がないというのは正確ではないですが、iOSのそれと同レベルではありません。
iPhoneが他のスマフォに比べて、セキュリティ上比較的安全とされる理由のうちの１つは、このsandbox機能です。

 

sandbox機能がなくても、各アプリが自分のデータを他のアプリからアクセスできないようにできます。
それを正しく設計すれば、データにアクセスされたくないアプリが、自分のデータを守ることができるということになります。
それに対して、sandboxは個々のアプリは、そのアプリ以外のデータにそもそもアクセスできないという点で異なります。
このことを、たとえ話しを交えながら説明します。

 

スマフォなどの端末の内部全体を街にたとえ、各アプリが使うデータ領域を家にたとえ、アプリをその家の住人にたとえることにします。
防犯のために、sandbox機能のない街では、各家の戸締りをしっかりしてください。というのに対して、sandbox機能があると、家の住人が外出できないように玄関がない家を建てているようなものになります。
前者は、戸締りしてない家は泥棒に入られてしまうし、仮に戸締りを万全にしていても鍵をこじ開けられてしまうかもしれないということです（特権奪取とかゼロデー攻撃と呼ばれています）。
一方で、後者は、そもそも泥棒が家の外に出ることができないことになります。

 

ただ、家の住人は玄関も窓もない真っ暗な家の中に隔離されているのかというと、そうではありません。

 

住むために必要な食材などの物資は与えてもらえるようになっています。
玄関はないけど、そのやりとりだけできる、小さな穴くらいは開いているということになります。
また、アプリが動作するのに最低限必要なデータについては屋外の様子を知ることができます。
家の中から外が見えるが、外から中は見えないマジックミラーの窓がついているようなものです。

 

「あれ？でもアプリから連絡先とか写真に共通でアクセスできるアプリがあるよ。」と思われるでしょう。
これは、iOS標準のアプリのいくつかは、街にもとからある特殊な家屋、いわば役場のようなものになっているからです。
そのような役場については、役場が許可した家からだけは、直接データを読み書きできるようになっています。
役場とだけは郵便のやりとりができるようなものです。

 

ちょっと、街と住人にたとえているので、これを読むと、自分が住人のように思ってしまうかもしれませんが、冒頭にたとえたとおり、住人に相当するのはアプリです。
iPhone利用者は、そんな街の市長さんということになります。
したがって、住人に役場の何をやりとりさせるのかを、市長さんとして役場に適切に指示する立場になります。

 

sandbox機能の街は、とても安全そうですが、その反面、住みにくそうな街でもありますよね。
隣に住んでいるのは親しい友人で、相手もこちらを信頼してくれていたとしても、互いに行き来することはできず顔も見れないということですから。
互いの家に玄関はないし、窓から近所の家は見れるけれど、相手の家の窓はこちらから見るとマジックミラーで鏡になっているから、その家の中にいる友人の顔を見ることはできないということになります。
郵便はあるが、それは役場とだけしか使えず、役場以外の家とはやりとりできないわけです。

 

逆に、sandbox機能のない街の家々は、みな、普通のガラスの窓がついていて、中を見られたくなかったら、カーテンを閉めてください。泥棒に入られたくなかったら、玄関の鍵を施錠してください。ということになります。

 

スマフォに話しを戻すと、sandbox機能があるiOSでは、アプリ間でのデータ通信や共有を直接することはできません。
このため、複数のアプリを連携させたいと思うアプリ開発者からは、データ連携の仕組みが欲しいという要望が当初からありました。
これに対して、アップル社はセキュリティ等を重視して拒否してきました。

 

ただし、直接やりとりできないと何も連携できないのかというと、そうではなく間接的な方法ならできるので、必要なら間接的に連携する仕組みを開発すべきというのが、アップル社の考えになります。
この街は、街の住人同士の直接のやりとりをできないようにしていますが、住人が街の外とやりとりすることは制限していません。
住人は、街の外の家には郵便を送ることができ、その家を介すことで、間接的にならば隣人とやりとりできることになります。
この街の外の家に相当するのが、インターネット上のアプリのサーバです。
そのため、アプリ間でのデータ連携をするには、アプリのサーバを開発しなければならず、それを省けたら助かるというのが開発者の言い分ということになります。
そこだけで考えると、すぐ隣の家の人に連絡するのに、わざわざ街の外の人を介して連絡するのは回りくどいと思うかもしれません。
しかし、隣の家の人に、電話するようなもので、仕組みとしては電話局を経由して隣家につながるため回りくどいし電話代もかかることになりますが、必ずしも不便ではないですよね。何より、それのおかげで安全な街なのだということを忘れてはなりません。

 

しかし、互いに信頼している家の人同士なら少しは、直接やりとりできるようにしてあげようかな？とiOS10の計画のときに心が揺らいで、１年ほど前にその予告がされました。
そのため、どうやって信頼関係を確認するのかとか、玄関は大きすぎるけど、既にある郵便用の穴を使えばできないかなどを試行錯誤していたようです。

 

これがどうなるのかに興味がありましたが、アップル社のリリース概要：
What's New in iOS 10.0
を読む限りでは、sandbox機能は緩和されなかったように見受けられます。（詳細な資料をまだ読んでいないので、実際のところはまだわかりませんが、ひとまず）

 

アプリ開発者の要望が問題だったと思うかもしれませんが、その先には、利用者の要望や期待があるわけです。
アプリ間で直接データのやりとりができるようになるということが、セキュリティ面ではどういう影響があるのかを理解したうえで、利用者は要望を出さないと、いつか、sandbox機能が緩和されるかもしれないので注意が必要です。

 

そのような意味では、iOSの音声認識機能であるSiriをアプリでも使えるようにしたSiriKitなどは、ここで説明したsandboxの観点で安全性と利便性に着目しながら各種設定をすることが必要です。
従来はOSだけがアクセスしていたところに、アプリがアクセスできるようになることには、ここで紹介したような危険性が生じる場合があるわけです。

 

なお、sandbox機能では、各アプリのスマフォ内のデータは強固に保護されますが、サーバに送るデータは、サーバの機能の強度によることになります。すなわち、家の中のデータは安全に保護されていますが、サーバに何を書き込むか、誰に読ませるかは、注意しないといけません。
また、アプリ固有のデータではなく、連絡先、カレンダーや写真などiOS標準の一部のアプリのデータについては、それらを適切なアプリにだけアクセスさせるように注意しないといけません。
これらの設定は、iOSであれば、「設定アプリ」→「プライバシー」→各アプリの「＞」で設定できます。
ここで許可することは、せっかく備わっているsandbox機能を一部解除することになるのだということを踏まえて判断する必要があります。
これまで確認したことがなかったようであれば、上記の設定を確認して、本来アクセスの必要がないアプリへの許可を禁止に戻しておきましょう。

 

ということで、sandbox機能が何かということと、それのセキュリティ面での有用性とアプリの利便性との関係、利用者として注意しないといけないことについて紹介しました。

 

ここまでで本題は終了です。
でも、ここまでのことが、なんとなくわかって、もうちょっと詳しく知りたいというときだけ、以下を読み進めてください。

 

ここまで、sandbox機能を街と家にたとえ、泥棒から家を守る話しを例に説明しました。
sandbox機能は、泥棒を家の中に閉じ込めることで、他の家を守るわけですが、「泥棒って、そもそも家の外にいるんじゃないの？」と思ったかもしれません。
これは、実生活ではそうなのですが、この街にたとえると、家のない来訪者はいません。ただし、この街に引っ越してくることはできます。引っ越し者が来ると、新築の家を建てて、その中に入居させることになります。道路に相当するようなところは、郵便屋さんの通路になるだけで、住人もそこに留まることはできません。
この引っ越してきて入居することが、アプリのインストールに相当します。

 

そして、泥棒に相当するのが、マルウェア（ウイルス）です。
したがって、sandbox機能そのものは、マルウェアに感染すること（マルウェアをインストールしてしまうこと）を防げるものではりません。
仮に、マルウェアをインストールしてしまっても、それがスマフォ内のデータを盗んだり書き換えることを防ぐためのものです。
街に泥棒は引っ越してくるかもしれないけれど、泥棒は、家から外に出られないということになります。

 

それなら、sandbox機能があればマルウェアに感染してしまっても安全かというと、そうではありません。
既に紹介したとおり、sandbox機能は、スマフォ内の各家々のデータを守りますが、仮にマルウェアに役場のデータ、すなわち連絡先や写真へのアクセスを許可してしまえば、街の外、すなわち、スマフォの外のインターネット上のサーバにデータを送信することはできます。
したがって、まずは、マルウェアに感染しないようにすることが大切です。

 

これについては、アプリをインストールするときに、それがマルウェアでないかをよく注意することが、いかに重要なことかということになります。
したがって、インストールの際に、どのデータにアクセスするかを聞いてきたり、表示していたりするので、その内容をよく確認することが重要です。
それを許可してしまったら、すなわち、街の市長として、役場にデータを出すように指示してしまったら、それによるデータの被害を防ぐことはできません。

 

なお、マルウェアがこっそりインストールされることは、いまのところ、PCと異なりスマフォの場合にはありません。
必ず、「App Storeアプリ」の画面を経由してインストールされます。
そのときに注意すればよいので、逆に、そのときの表示内容は、ちゃんと読んで怪しいアプリではないかを丁寧に確認しましょう。

 

ただし、これの落とし穴としてあるのが、スマフォをPCとケーブル接続したときです。このときに、PCがマルウェアに感染していると、そこを介して、結果的にスマフォが、知らない間にこっそり感染するということはあり得ます。
これを防ぐのは難しいですが、その可能性があることは知っておきましょう。

 

後半の話しが、難しかったなら、忘れてください（笑
さっきのところまで、わかっていれば、とりあえず大丈夫（のはず）です。

 

注：技術者のみなさまへ
技術者ではない人に、わかってもらえるように配慮しすぎたので、若干、技術的に微妙なところ（sandbox機能ではなく、その上のcontainment機能であるかのような表現）もありますが、わかりやすさ優先ということで、ご容赦ください。

政府から学ぶ情報セキュリティ対策のクラウド対応

情報セキュリティ対策についてのクラウド対応は、具体的にはどのようにすればよいのだろうか？
課題の列記や精神論的なものは目にすることも多いが、情報セキュリティ対策のマネジメントシステムを実施している組織が、規程の改訂などで具体的に何をしたのかを見る機会がほとんどないようだ。

そういうときに政府はどうしているかを見るのは参考になる。

ちなみに、外部委託とクラウドの関係は、昨年、以下のような発表をしたことがある。
「外部委託及びクラウドにおける情報セキュリティマネジメントシステム適合性評価の利用」

そんなことを踏まえながら、政府の対応を見てみるとよいだろう。

結論からすると、以下のとおり、補足説明の追加程度で済んでおり、特段の遵守事項の追加はないことがわかる。

管理的な観点では、以下の対応がされた。
　外部委託に、外部の設備を利用したサービスが含まれることが追加解説された
　外部設備を利用する場合に、データの所在に留意することが追加解説された
　ＩＴ部門を通さずにＩＴに相当する外部委託の発注を想定することが追加解説された
　細則である外部委託のマニュアルの中で以下の追加がされた
　　「約款による情報処理サービス」という定義をして留意事項例がまとめられた
　　ＩＴ部門以外にも周知することが重要である点が追記された
技術的な観点では、以下の対応がされた。
　通信回線の用語定義に仮想ネットワークを想定するよう追加解説された
　サーバを共用することを想定するよう追加解説された
　クラウド対応ということではないが関連することとしては、以下の遵守事項が追加された。
　　電子メールの送信元でのなりすまし防止対策

まとめてみると、上記のことくらいをすれば「クラウド対応」ができると言える。
上記のうち、主要なことは１つだけで、細則の「外部委託における情報セキュリティ対策実施規程 雛形付録」に、「約款による情報処理サービス」を追加したことと言ってもよいだろう。

クラウドが、何か新しい技術パラダイムであったり、新しい契約形態であるという紹介がされることもあるが、実務に照らしてみれば、従来の補足程度のことであることを示している。

ただし、クラウド対応を政府と同じくらい少なくできるかは、もととなる基準の品質に依存する。
つまり、
「クラウドを想定して検証することで、現状の情報セキュリティ対策の枠組みの出来具合がわかる。」
ことになるのは重要なことだ。
もしも、クラウドを想定して、現状の情報セキュリティ対策の見直しが多かったとしたら、それはクラウド対応なのではなく、現状の対策の枠組みがよく出来ていない可能性を疑ってみる必要もありそうだ。それはつまり、クラウド対応が局所的にならないような、全体枠組みを再構成するということの必要性を意味する。

その点で、政府の基準は枠組みとしては、ISO/IEC 27002などよりは、もともとよく整理してある。
今回のクラウド対応の検証では、統一基準は「外部委託（1.2.5.1）」以外に、以下のような観点の遵守事項をもとより定めている。
「情報の抹消（用語定義）」
「省庁外での情報処理（1.4.2.1）」
「省庁支給以外の情報システムによる情報処理（1.4.2.2）」
「主体認証・アクセス制御・権限管理・証跡管理・保証等の標準手順（1.5.2.4）」
「ドメイン名の利用（1.5.2.7）」
「リモート保守（2.3.2.3(1)(a)）」
これらの枠組みの中で、クラウドを整理することができている点が重要だ。
これらについての基準がない組織では、政府の例を参考に、それらを加えてもよいだろう。

政府機関の基準関連文書を確認した結果は、以上のとおりだが、経緯を以下に紹介する。

政府は、「政府機関の情報セキュリティ対策のための統一基準」を公表している。

そこに掲載されている、
旧版である
　「政府機関の情報セキュリティ対策のための統一基準（第４版）」
は、最新版で以下の２文書構成に分かれた
　「政府機関の情報セキュリティ対策のための統一管理基準」
　「政府機関の情報セキュリティ対策のための統一技術基準」

そこでまず、「政府機関統一基準改定の概要」を見てみると、最新版の改定はスライド２で示しているとおり、以下の５点で改定している。
　Ａ１．クラウド技術への対応
　Ａ２．外部からの不正アクセスに係る対応
　Ａ３．情報システムのセキュリティ強化に係る対応
　Ｂ１．統一基準の全体構成の見直し
　Ｂ２．教育・人材育成の充実
したがって、政府機関統一基準関連文書での改定差分のうち、上記の「Ａ１．クラウド技術への対応」の観点での改定箇所を見れば、それが情報セキュリティ対策基準における「クラウド対応」ということになる。
大げさに言えば、改定差分からＡ１以外の改定を取り除くようなリバースエンジニアリングをするということだ。（笑）

それをするために、具体的な差分を、管理基準、技術基準、マニュアルの順に紹介してみる。

まず、目次レベルでの差分を確認してみる。
そのためには、「旧版からの項番対応表」を参照するとよい。
今回の改定では、「Ｂ１．統一基準の全体構成の見直し」があるため、構成が変更になっているが、クラウドに関するような項目の変更がないことがわかる。
したがって、目次レベルでは、クラウドという項目を追加などする必要がないと判断されたことになる。

次に、本文の差分を確認してみる。
そのためには、以下の２つの文書を参照するとよい。
・「政府機関の情報セキュリティ対策のための統一管理基準」と旧版の新旧対照表
・「政府機関の情報セキュリティ対策のための統一技術基準」と旧版の新旧対照表

管理基準については、以下の変更箇所がクラウドに関係するものになるだろう。

No.71で、 クラウドに直接関係するものではないが、 「情報の抹消」を「廃棄した情報が漏えいすることを防止するために、全ての情報を復元が困難な状態にすることをいう。削除の取消しや復元ツールで復元できる状態は、復元が困難な状態ではない。」 と明記することで、「情報の抹消」作業の要件を示している。 No.74で 「通信回線」の用語定義を 「「通信回線」とは、これを利用して複数の電子計算機を接続し、所定の通信様式に従って情報を送受信するための仕組みをいう。回線及び通信回線装置の接続により構成された通信回線のことを物理的な通信回線といい、物理的な通信回線上に構成され、電子計算機間で所定の通信様式に従って情報を送受信可能な通信回線のことを論理的な通信回線という。」 を 「「通信回線」とは、これを利用して複数の電子計算機を接続し、所定の通信様式に従って情報を送受信するための仕組みであり、物理的なものと論理的なものがある。」 と改定している。 これは、仮想化技術におけるネットワークを想定したものである。 No.99に、 1.2.1.1(5)(a)解説として、 「なお、アプリケーションのみ別組織が管理するといったように、情報システムを共同で管理する場合は、あらかじめ責任分担を明確にすること。」 を追加している。 No.164に、 1.2.5.1趣旨として、 「府省庁外の者に情報処理業務を委託する場合」に、 「外部の設備を利用した役務提供も含む」とした点と、 「外部委託に関する対策基準を定める」ことについて、 「具体的には、 ・情報セキュリティ確保のための府省庁内共通の仕組みの整備 ・委託先に実施させる情報セキュリティ対策の明確化 ・委託先の選定 ・外部委託に係る契約 ・外部委託の実施における手続 ・外部委託終了時の手続 についての遵守事項を定めるものである。」 と明記している。 No.165に、 1.2.5.1(1)(a)解説として、 「また、データの所在については、海外のデータセンター等に情報を保存する場合には、保存している情報に対し、現地の法令等が適用されるため、国内であれば不適切となるアクセスをされる可能性があることに注意が必要である。例えば、「行政機関の保有する個人情報の保護に関する法律」で定義する個人情報については、国内法が適用される場所に制限する必要があると判断すること等が考えられる。」 と追記した。 No.172とNo.173に、 再委託に関する改定があるが、これはクラウドと関係するわけではなく、また旧版からの遵守内容の改定であるわけでもなく、文章を簡潔でわかりやすいものに改めたものだろう。 No.175は、 クラウドに直接関係するものではないが、No.71で定義した「情報の抹消」に併せて 1.2.5.1(5)(a)(イ)に、 「全ての情報を復元が困難な状態にすることをいう。」 と追記している。 No.215に、 1.3.1.3(1)(a)解説として、 「また、行政事務従事者が許可を得て、個人で利用するASP・SaaS サービスなどの外部の情報システムを用いて、要保護情報に関する情報処理を行う場合は、省庁対策基準と同等の情報セキュリティ対策が実施される場所に保存する必要がある。なお、海外のデータセンター等に情報を保存する場合には、保存している情報に対し、現地の法令等が適用されるため、国内であれば不適切となるアクセスをされる可能性があることに注意が必要である。」 を追記している。 No.302で、 1.4.2.2(3)(c)解説として、 「解説：情報システムセキュリティ責任者に対して、許可又は届出を受理した要保護情報を取り扱う府省庁支給以外の情報システムについて、府省庁支給の情報システムと同程度のセキュリティ対策が施されていることの確認を求める事項である。確認する頻度は、（以下、長文のため転載略）」 を追加 No.305で、 1.5.1.1(1)(b)解説として、 「また、ASP・SaaS サービス等の外部の情報システムを利用する場合は、管理責任範囲の分担を明確化し、セキュリティ対策の実施に漏れが発生しないようにすること。なお、物理的に分割されたシステムに限らず、論理的に分割されたシステムも同様に考慮すること。「論理的に分割されたシステム」とは、一つの情報システムのきょう体上に複数のシステムを共存させることを目的として、仮想的・論理的に分割させた状態の情報システムをいう。例えば、仮想化技術を利用することが考えられる。」 を追記している。 No.329～336 No.329で、 1.5.2.1(2)(a)に、 「また、情報処理業務を外部に委託する場合は、以下の事項を記載した台帳を整備すること。」 を追記しており、 No.335で、1.5.2.1(2)(a)(シ)に、台帳整備の項目として、 「ドメイン名（インターネット上で提供されるサービス等を利用する場合）」 を明記している。 No.423で、 用語解説として、「ASP・SaaS サービス」の解説を追加している。

技術基準については、以下の変更箇所がクラウドに関係するものになるだろう。

No.193で、 2.3.1.1(3)(a)解説にクラウドということでもないが、共用のサーバ室等の注意点として、 「なお、重要システムを設置している場合やサーバ室に設置している複数のサーバラックの運用主体が異なる場合、サーバラックの鍵を適切に管理すること等が考えられる。」 を追記している。 No.233で、 遵守事項として2.3.3.1(1)(c)を 「情報システムセキュリティ責任者は、電子メールの送信元について、なりすましの防止策を講ずること。」 を追加している。 そして、No.234で、その解説を追加している。 クラウドと直接関係することではないが、自組織のサーバ以外からメールを送信することについて、どのように真正性を受信者に示すかの参考にしてもよい項目だろう。 No.241からNo.246で、 遵守事項として2.3.3.2(1)(a)を追加している。 クラウドに直接関係することではないが、ウェブコンテンツに関する事項を改めてまとめてあるので、参考にしてもよい項目だろう。 No.258で、 遵守事項として2.3.3.2(2)(a)を追加している。 クラウドに直接関係することではないが、ウェブアプリケーションの開発に関する事項を改めてまとめてあるので、参考にしてもよい項目だろう。 No.291で、 2.3.4.1(1)(a)解説に 「なお、物理的に分割されたシステムに限らず、論理的に分割されたシステム間の通信も同様に考慮すること。（「論理的に分割されたシステム」とは、一つの情報システムのきょう体上に複数のシステムを共存させることを目的として、論理的に分割させた状態の情報システムをいう。例えば、仮想化ソフトウェアを利用することが考えられる。なお、仮想化ソフトウェアとは、１つのハードウェアで複数のオペレーティングシステムを同時に実行する 機能を有するソフトウェアをいう。以下同様。）」 を追加している。 仮想化技術による仮想ネットワークを、基準で定めている通信回線とみなすことを明記して、これまでの物理回線に対する事項のうち、適用できることは仮想ネットワークにも適用するように求めている。 No.297で、 2.3.4.1(1)(f)解説に、 「また、通信路の秘匿化は、機密性だけでなく完全性を保護する上でも有用である。なお、通信路の秘匿化のために、例えば、IPsec、SSL 及びTLS 等を使用することも考えられる。」 を追加している。 クラウドという観点では、機密性だけではなく、完全性についての観点もあることを示唆しているので、参考にできる項目だろう。

以上が規則である遵守事項を定めた基準２文書の確認であるが、次に、細則に相当するマニュアル作成手引書の差分を見てみる。

政府は、「政府機関統一基準適用個別マニュアル群」を公表している。

この中で、今回のクラウド対応で改定したのは、DM6-02という文書番号の以下の３つである。
・「外部委託における情報セキュリティ対策実施規程 策定手引書」
・「外部委託における情報セキュリティ対策実施規程 雛形」
と「雛形付録」
（ウェブページ上では、ファイルが２つのように見えるが２つ目は上記のとおり、雛形と雛形付録の２つの異なるファイルへのリンクがあり、全部で３つのファイルがあるので注意）

基準と異なり、こちらには新旧対照表がないので、差分の比較のためには、PDFファイルをテキスト形式で保存したものを、ファイル差分比較のツールなどで横に並べて比較するとよい。
ページ番号がずれているために、その箇所がすべて差分として表示されるが、慣れてくると実際の本文の変更箇所を確認するのは、それほど大変ではない。

策定手引書の旧版からの差分については、以下のとおりだ。

まず、目次から見ていくと、以下の２点の変更だけである。

・以前の「８　外部委託の形態」の内容が「８．１外部委託する業務の分類」になり、新設の「８．２『約款による情報処理サービス』の利用による外部委託」が追加された

・「９．３．５再請負の原則禁止」が「９．３．５再委託に関する制限」に変更になった
こちらは、実際にはクラウド対応ということではなく、基準での表現変更を反映したもので、遵守内容に見合った見出しにしただけで内容の変更はない。

次に、本文を見ていくと、クラウドとは関係のない以下の変更がある。
・統一基準の変更の反映（基準文書の名称変更と、項番の変更など）
・参考資料の追加
そして、クラウドに関係する変更として
・9.3.1 外部委託に係る契約に「(14)『約款による情報処理サービス』利用時特有の留意事項」が追加された。

ここには、

約款が用意されており、情報セキュリティに関する事項について利用者による条件 選択の余地が限られている情報処理サービス（以下、「約款による情報処理サービス」 と言う。）を利用し、外部委託を行う場合である。（利用者に提供される機能など情報 セキュリティ以外の契約内容については要求に基づいて用意される又は条件選択や 修正ができるものであっても、情報セキュリティに関する事項に条件選択の制限があ れば、「約款による情報処理サービス」に含む。）例えばクラウドサービス等がこれに 該当する。

と記載されており、いわゆるパブリック・クラウドのうち、約款によって利用条件が決まっているものを「約款による情報処理サービス」として定義した。

そして、それに対して以下の留意点を示している。

一般に、外部事業者が提供する「約款による情報処理サービス」を利用する場合に は、サービス内容の保証は提供事業者が定める利用規約等の約款の範囲に限られる。 したがって、省庁対策基準及び規定で許容されているかどうかを確認のうえ利用を検 討することが必要である。具体的には、別紙１の雛形に加え、留意事項とチェックリ ストをまとめた別紙２の雛形付録を参照するとよい。 「約款による情報処理サービス」の利用に際しては、例えば以下の点に注意する必 要がある。 ・通常の情報処理サービスにより処理された結果生じる著作権等の権利については 利用者に帰属することが一般的であるが、「約款による情報処理サービス」では、 それらの権利の放棄や移管が利用条件となっている場合がある。 ・賃貸借・使用貸借部分の所有権はサービス提供者等の事業者側に帰属するため、 通常の情報処理サービスの利用終了時におけるデータ削除は、原状回復義務とし て利用者側の義務となることが想定されるが、「約款による情報処理サービス」 では、約款上、データ消去等をサービス利用者側で直接実施できないことがある。 ・「約款による情報処理サービス」では、利用したデータの削除についてサービス 提供者が個別には応じないことや、情報の置き場所が特定の場所に固定されず、 海外の法執行機関等による予期せぬアクセスが行われることがある。

さらに、以下のとおり、上記留意事項についてＩＴ部門に限らずに広く周知させることが重要であることを強調している。

なお、サービスの中には無償で利用できるものもあるが、無償で利用する場合でも 外部委託に該当するとの認識が必要である。つまり、府省庁外の情報処理サービスを 利用する場合には、それが有償で調達手続きを経る場合だけではなく、無償で利用を 開始できる場合であっても、本手引書で解説している「外部委託における情報セキュ リティ対策実施規程」を遵守することが求められる。無償で利用する例としては、無 償で提供されているメールサービスの利用やアンケート記入及び集計に係るウェブ サービスの利用等を挙げることができる。 こうした無償サービスの利用においては、その利用者が調達に従事する行政事務従 事者に限られたものではないため、当該留意事項について別紙２の雛形付録に基づき、 府省庁内に広く周知する必要がある。

雛形については、以下のとおりだ。

・手引書の８章の変更と同様に、以前の、「３　外部委託を行う業務の形態」が「３．１外部委託する業務の分類」となり、新設として「３．２『約款による情報処理サービス』の利用による外部委託」が追加され、３章は「外部委託の形態」になった。

・７章「７　契約における手続」に「７．６『約款による情報処理サービス』の利用による外部委託に関する注意」が追加された。

・「第Ⅱ部　調達仕様における情報セキュリティ関連事項の記述例」が３章と同様に、以前の内容を「１外部委託する業務の分類に基づく事項」として、「２『約款による情報処理サービス』の利用に関する事項」が追加された。
ここでのポイントは、業務の分類に基づいて、
1.1情報システムの構築等の場合
1.2情報システムの運用・保守・点検の場合
1.3情報の加工・処理等の場合
1.4情報の保存・運搬の場合
の場合ごとの事項を記述した上で、それらに加えて『約款による情報処理サービス』の場合には、「２『約款による情報処理サービス』の利用に関する事項」を記述するというアドオン形式の構造になっている。

そして、今回の唯一と言える、クラウド対応として、別紙２「「約款による情報処理サービス」利用チェックリスト」を新たに設けている。
その中で、留意事項を表１で、１～１８を示している。
チェックリストでは、「～～について約款上の記載があり、その記載内容は利用上問題ありませんか？」
という書き方をしているが、前段の「～～について約款上の記載があり、」という箇所では、「約款上に記載が明記されていない場合には、サービス提供者にサービス内容を確認せよ」ということになる。
それを確認したうえで、後段の「その記載内容は利用上問題ありませんか？」の問いは、
「サービスを利用する上でリスクを許容できるものであるかという意味を含むものである」としている。

したがって、政府の基準関連文書での、クラウド対応の中心的なものは、外部委託マニュアルにおいて、「約款による情報処理サービス」という定義をして、そのためのチェックリストを示したことである。

以上を参考にして、情報セキュリティ対策でのクラウド対応に役立てることができるだろう。
実際に使われている文書が、無償で再利用、再配布自由というのだから、使わない手はないだろう（笑）

政府機関統一基準のパブコメ

「政府機関の情報セキュリティ対策のための統一管理基準」（案）及び「政府機関の情報セキュリティ対策のための統一技術基準」（案）に関する意見の募集をしています。

http://www.nisc.go.jp/active/general/kijun5.html

技術者以外にもわかる「ＤＰＩ技術のマーケティング利用議論」入門

総務省が『「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」第二次提言』の中で、DPI に触れたため、DPI の議論がちょっとホットになってきた。

でも、「DPIって何？」「小文字の dpi なら、dots per inch でプリンタの印刷精度だよね」というのは、文系に限らず、IT系の人にとっても、あっても不思議ではない。
文脈を踏まえないと、唐突な３文字略語だからだ。（３文字程度では、他のものと同じ略語になってもしかたない。）

DPI (Deep Packet Inspector) 技術のマーケティング利用を議論するときに、そもそも、DPI ってどこから登場したのか？を知っておくと、議論に参加しやすいかもしれない。

クラウドコンピューティングというバズワード(Buz Word: Business word)のもとに、
一部の ASP(アプリケーション・サービス・プロバイダー) が自らを SaaS ベンダーと名乗ってみたり、
一部のサーバホスティング会社が、自らを HaaS ベンダーと名乗ってみたり、
と同様に、DPI という用語は技術的には範囲があいまいで、「自称」でしかないということを踏まえないと、最後に大切なことを取りこぼしてしまうかもしれない。

もともと、DPI は、IDS (Intrusion Detection System：侵入検出装置) メーカーがパケットのヘッダ部分（送信元ＩＰ＆ポート、送信先ＩＰ＆ポート）だけではなく、パケット本体の中味も検査するようになったときに、ヘッダ部分しか検査しない IDS との機能差別化を狙って作った、バズワードだ。

それを差別化しようとした背景には、その頃、登場した後発の IDS メーカーが、IPS (Intrusion Prevention System) という機能を設けて、「侵入（intrusion）を検出（detection）するだけでは意味がなく、阻止（prevention）しないと対策として役立たない」というもっともらしいことを主張したからだ。

これを「もっともらしい」と表現するのは、老舗IDSはヘッダ部分だけの頃からやっていて、その時代にはファイヤーウォールとIDSは一組で使うもので、ファイヤウォールが侵入を阻止して、その取りこぼしを IDS が監視するという役割分担があったため、検出に特化していればよかった。
なので、「意味がなく」というのは、誹謗であって、「意味もあり、役割も果たしていた」のが正しいはずだ。
ところが、パケット本体を IDS が検査するようになると、処理性能の問題から、それをリアルタイムでファイヤーウォールが通過制御するというのは困難なため、パケット本体の検査を備えた IDS が、ファイヤウォールと連動して、IPS を実現するということが期待されるようになった。
つまり、ファイヤーウォールは、従来どおりパケットヘッダ検査による通過制御を行い、それと同時に IDS がパケット本体検査をして、不適切なパケットを検出したら、それをファイヤウォールなどに通知して、そのパケットを中断させることで、不適切なパケットが通信を完遂できないようにして、結果として、IPS として「阻止」をするというわけだ。
近年は処理性能が向上したため、このような「ちょっと遅れた阻止」ではなく、リアルタイムに阻止できるようになっているが、当初はそのような、IDS の機能差別化によって始まった。

技術の経緯はまどろっこしいが、ビジネスの背景としては単純だ。
IDS の技術は成熟していたが、ファイヤウォールなどと連動するなどして IPS を実現するという部分は、後発メーカーとしては、先行メーカーと競合するときの売りになるということで、IPS に着目させるため、「侵入を検出するだけでは意味がなく、阻止しないと対策として役立たない」として IDS の土俵を仕切りなおすという、売り文句ができた。

この経緯において、パケットのヘッダだけ処理するファイヤーウォールや IDS と、パケット本体を検査するものを区別するために、後者について、DPI (Deep Packet Inspection) という用語を用いた。

そして、当初の DPI は単純な（静的な）パターンマッチングだったが、DPI を掻い潜ろうとする不正パケット側が動的に変化するパターンを用いたため、DPI 側もそれを検出するべく、動的パターンにもマッチングできるように進化していった。

したがって、DPI は侵入検出又は阻止を目的として進化を遂げた技術が出発点だ。

ところが、パケット本体内部の動的パターンのマッチングができるようになると、それは、利用者のアクセス嗜好解析など侵入阻止以外の目的にも使えることになるというパンドラの箱になったことを意味する。

DPI のマーケット利用の是非の議論は、このパンドラの箱のフタを開けることの是非の議論だ。

そして、いったんフタが開いてしまうと、リアルタイム検出していただけだったのが、ゲートウェイサーバ（中継サーバ）のように配置して、もとのパケットにない「印」をパケットに挿入してから中継することなどの機能も出始めた。その印としては、たとえば、cookie などを挿入することが考えられる。
そのように、他にない機能を盛り込みつつ、その機能があるのが、真の DPI だという製品差別化が行われた。

街中の別の物に置き換えて考えてみるとわかりやすい。

駅や商店街などに、防犯のために、監視カメラが設置されている。
この監視カメラを使って、利用客の行動分析や嗜好分析をできないか。
たとえば、食堂から出てきた人が、次にコンビニエンスストアに入ったなら、その人には、おにぎりを勧めるよりも、雑誌などを勧める方がよいということに使うということである。
このとき、そのようなサービスを有難いと思うか、監視カメラの先でそんなことを分析されるのは気持ち悪いと思うかは、その人次第なので、本人の希望次第でよいのではないかという考え方もある。
あるいは、監視カメラは、その名のとおり、監視が目的なのだから、それ以外のことに使うのは絶対禁止という考え方もある。

上記の例は、DPI のマーケット利用に否定的と取れる例を出してしまったかもしれないが、この記事では、その是非の結論を出すつもりはない。

ここで明確にしておきたかったことは、DPI のマーケティング利用の是非という議論が始まっているが、「DPI」という用語に限定するとおかしなことになる。
なぜなら、DPI という用語は、IDS や IPS という製品を売っていた人が、自らのビジネスや技術の差別化のために用意したバズワードであって、はっきりとした技術領域ではない。
つまり、「DPI の D はどういう意味で deep なの？」とか「DPI の I は検出や阻止、あるいは解析と inspection は何が異なるの？」というのは不毛で、「Deep Packed Inspection」という表現がビジネスインパクトのある語感だったというだけのことだろうからだ。
議論の過程を単純化するために、「DPI」という用語を使っておいてもよいが、それで結論が出たら、最後に、その用語の部分を「パケット本体の分析」に置き換えないと、本質的な問題を取りこぼしてしまうことになる。
すなわち、仮に「DPI のマーケット利用禁止」という結論が出たら、その表現のままでは、製品カテゴリーを DPI 以外に変更されたら逃れられてしまう。
それを正しく表現するには、「パケット本体分析のマーケット利用禁止」として、逃げ道を塞ぐ必要がある。
そうしないと、そもそも、自分達の都合で自ら名乗ったカテゴリーなのだから、それが不利な名称なら自分達で勝手に変えられてしまう。

また、議論が DPI を ISP に設置する文脈でなされているのか否かで、逆に技術制約の範囲を不必要に拡大してしまうことになる点にも併せて注意が必要だ。
たとえば、オンラインショッピングサイト自身が、自社の利用者の行動分析に、自社サイト内に DPI 技術を用いた装置を設置することは、ISP に設置してその分析結果を ISP 以外が利用することとは意味が異なることに注意が必要だ。
なぜなら、DPI を「パケット本体分析」とするなら、ショッピングサイトが自サイトの利用者行動分析をすることは、通常の cookie や web beacon などでも行っていることで、それを DPI 装置に高速に処理させるということは、ISP が第三者に利用させたり、第三者が ISP に設置することとは意味合いが異なる。

このように、DPI の議論は、その文脈で暗黙の範囲や条件が設定されていることを踏まえて、それを確認した上で議論に参加しなければ意見がかみ合わなくなる。
そして確認して議論したならば、議論の最後で、それら暗黙のことを明示的に示してから、議論に参加していなかった人達に示さないと、議論の意図が伝わらないことが考えられる。

DPI という用語だけを使って、逃げ道を作られないようにしつつ、
逃げ道をふさぐ用語（たとえば、「パケット本体分析」など）に適切な条件を付けずに否定して、無用の反発を受けないように議論する必要がある。

インシデントマネジメントの国際規格化動向

「インシデントマネジメントの考え方」でご紹介した講演内容をもとにして、デジタル・フォレンジック研究会のメール・マガジン用に記事をまとめました。

メール・マガジンの記事として文字数を減らすために、講演内容から事業継続に特化した詳細説明を省いた内容になります。

デジタル・フォレンジック研究会のメール・マガジンのウェブ・アーカイブ第５０号をご覧ください。

講演内容をすべて盛り込んだ内容は、講演主催者の報告書用として既に執筆してあるので、報告書が配布（オンラインでの公表はないそうです。）されたら、またご紹介するようにしたいと思っています。

まずは、短編版から・・・笑

インシデントマネジメントの考え方

情報セキュリティ総合的普及啓発シンポジウムにて、インシデントマネジメントの規格である ISO/IEC 18044 と 27035 の紹介をしました。

Y's Station にて、「事業継続マネジメントにおけるインシデントマネジメントの考え方」をお聴きください。

いまだにMD5 - 臨時ドメインサイトに要注意

MD5のSSL証明書を実際に破ったという報告がされました。
「MD5 considered harmful today - Creating a rogue CA certificate」

破ったことの簡単な邦訳はこちら。
「MD5コリジョンでインチキ認証局は作れる（ネットにとっては悪い報せ）」

この報告そのものは、PlayStation3を200台使って破れたというものなので、計算能力からすれば、MD5が破られるのは、以前からのMD5の脆弱性についての実証実験程度のことではあります。
特にゲーム機のCPUは配列やベクトル演算能力が特化しているため、この種の攻撃にはもってこい（？）ですね。
やれば SHA-1 でも破れると思いますので、破れたことは納得です。

ただ、気になるのは、、、

上記の報告の 5.1. Introduction
に書いてあるように、今だに MD5 証明書が沢山出回っていることですね。。。

報告によると、10万件くらいSSL証明書をかき集めたところ、3万件は、Firefoxが信頼できるCAで署名されてるものに該当したにもかかわらず、そのうちの9000の証明書は、MD5 だったということで、それは確かに驚きです。
ただ、それらの大半（報告書によると97%）が RapidSSL や FreeSSLの安価か無料の証明書と言われると、なんとなく想像はつきます。

企業や政府だと、自組織のドメイン名を背負ったサイトについては、ちゃんとした強度のものを買うようにすればよいですね。
ただ、以下のことを見逃さないようにしないといけませんね。

イベントやセミナーなどの運営を業務委託して、イベント専用の臨時のドメインサイトを立ち上げさせたりすると、これらの無料証明書が使われる可能性があります。
ITに関係しない業務委託の際にも、SSL証明書を取得する状態となる場合には、強度の指定をしなければならないということを意味していますね。
ポイントは、以下の２点です。
・業務委託がITに限らない（たとえば、イベントの運営業務など）という点
・業務のために結果的にWebが使われる場合がある（業務の裏方で使わ
れるなど、委託した業務の表面上はわからない利用形態もあり得る）という点

とはいえ、これまでだと、これらの委託先に、MD5の脆弱性とかを理解してもらうのは現実的ではありません。また、中途半端に技術のわかるWebサイト開発者などがいると、「危険とかいっても、他でも使ってるから大丈夫はず」とか言われてしまい、それを打ち消すための説得をしないといけなかったわけです。
そういうときに、「実際に証明書を偽造できた」という説明に今回の報告を紹介すると効果がありそうです。
細かいことはよいので、「実際に証明書を偽造できた」ということが直感的で説得力がありそうです。
まさに、実証実験は大切ということですね。

しかし、そもそも・・・

イベントやセミナー用に、わかりやすい URL にする目的などで臨時のドメインサイトを設けた場合には、イベント終了後に、そのドメインの使用契約を終えてから悪用されるのを防ぐために、相当な期間の契約を継続しなければならないことも考えると、臨時ドメインという発想自体を、もうやめた方がいいということも言えそうです。

政府機関統一基準第４版案パブコメ

政府機関情報セキュリティ対策統一基準の第４版案についてパブコメ募集が出ました。

http://www.nisc.go.jp/active/general/kijun4.html

今回の改訂で基本的な考え方は変わっていませんが、これまでの各遵守事項について求めていることが技術的なことかどうかなどにより、基本編と情報システム編に分けることで、点検時の観点が区別しやすいようにしたり、下位規程の整備を集約するなどしたために、構成が大幅に変更されています。

技術的な変更箇所については、案文にて、各種製品の設定などで不都合のない表現になっているかなどもご意見があると参考にされるものと思います。

パスワードの定期的な変更は必要か？

パスワードを定期的に変える必要があるか？と、
政府機関統一基準を、政府機関以外に適用するときのことについて相談を受けることがときどきある。

先日は、ある同業約８０の組織が検討しているとのことで、そこからタイトルのような質問を受けた。
（この記事は、実は相当以前に書いていたが、下書き保存したまま公開していなかったので、いまさらながら公開しています。）
正確にいうと、質問というよりも、「パスワードを定期的に変えるのは本当にやらなければならないのか？それは本当に意味があるのか？」という苦言を呈されたのだった。

少し悲しかった。。。
というのも、政府機関統一基準は、パスワードの定期変更を一意には求めていないからである。
それがちゃんと読まれることもなく、「情報セキュリティの基準と言えば、パスワードの定期的な変更を求めるのが当たり前」と先入観で思っているらしく、読む前から上のような苦言をされたのである。

苦言を呈した人に、「読まずに聞かないで」とは言えなかった。
なぜなら、彼もまた、１７７９９改め２７０００シリーズの教条主義者による悪行の被害者であり、その人を責めるものでもないので、悲しかったのである。

「パスワードを定期的に変更しなければならない」ということを条件も付けずに安易にルール化しているというのは、どういうことだろうか。。。

まず、最初に言っておくと、パスワードの定期的な変更がまったく必要ないということではない。
たとえば、以下のような場合には、パスワードの定期的な変更をしなければならないこともある。

・ひとつのアカウントを複数人がひとつのパスワードを使って共用しており、
・それら複数の人が定期的に入れ替わる場合。

ただし、上記の場合でも、人が入れ替わったとき、すなわち、必要なときにパスワード変更をすればよいので、「定期的に」変更するかどうかは、人が入れ替わるのが定期的か次第でしかない。

さて、ＩＴセキュリティをしている人に以下のパスワードポリシーＡについてセキュリティ上の意見を聞くとおもしろい。

パスワードポリシーＡ
　Ａ１：パスワード長は数字のみ４桁
　Ａ２：パスワードは変更できない
　Ａ３：ただし、カードをカードリーダに通さなければならない

まったくレベルの低い人は、「Ａ１が８桁ないとダメだからダメ。」と答えるだろう。
１７７９９などにやられちゃった人は、「Ａ１はパスワード再入力までの時間間隔などで微妙だけど、Ａ２についてはダメ。」と答えるかも。
もうちょっとまともな人は、「Ａ１とＡ２は強度が高いとは言えないけど、Ａ３が本人確認要件の所有確認となっているので必ずしも不十分とは言えないかも・・・」と、もごもごするかもしれない。

上記はちょっとイジワルな例で、まともな答えは、「上記のパスワードポリシーの情報だけでは、意見のしようがない。」である。
それでは聞き返して得なければならない情報はなんだろうか・・・
重要なことから順番にしていくと以下のようなことだ。

最初の質問は、「このパスワードポリシーＡを適用しようしているシステムでは、間違ったパスワードが入力されたときにどういう処理をしますか？」だ。
それによって、以下の情報を得る必要がある。

・次のパスワード入力を許すまでの時間（１回間違ったら何秒間待たないと、次のパスワードの入力をできないかとかということ）

しかし、実はこれは、ポリシーＡ１の「数字だけで４桁」がどの程度脆弱かを念のため確認する意味しかない。

より重要な情報は、
・間違ったパスワードの入力を許す上限の回数

これには、実際には積算失敗回数か連続失敗回数の２種類ある。

積算失敗回数は、そのパスワードを使い始めてからの失敗回数の総数だ。
連続失敗回数は、連続して失敗した回数なので、正しいパスワードが入力されたらリセットして数える回数だ。

積算失敗回数が、仮に３回でカードが永久に使えなくなるならば、パスワードポリシーＡはセキュリティ上問題とは必ずしもいえない。
ただし、設定するパスワードを容易に推定されるものにしないなどの条件は必要だ。（これはどんなときにも言えるので、以降は繰り返さないことにする。）

積算ではなく、連続失敗回数が３回でカードが永久に使えなくなるのならば、万全とは言えないが、カードの管理がしっかりされているならば、これもセキュリティ上問題とは必ずしもいえない。
相対的にみれば、積算３回であれば、カードの管理が多少疎かでも実用に耐えれる場合があることを意味する。

もうおわかりのことと思うが、パスワードポリシーＡは、日常生活において、銀行のキャッシュカードやクレジットカードによる本人確認に用いられているもので「即ダメ。」とか「実用に耐えない。」というはずがないものである。
重要な条件は、
・カードと併用する
・パスワード（暗証番号）を３回入力ミスでカードは永久に利用不可になる（カードの再発行が必要）
であり、その条件であれば、
・パスワードは数字のみ４桁でも不十分ではない
ということだ。

このとき、連続失敗回数３回だと、「カードの管理がしっかり」が加わっているが、これは厳重な管理かというとそうではない。
どういう状態で危険になるかを考えるとわかりやすい。
危険な状態は、「カードを使って誰かが不正パスワード入力を２回試みる。その試みが本人に気付かれないうちに、本人が正しいパスワード入力したことを知ることができて、その後にまた２回試みる。を繰り返せる状態」となる。
率直に言って、「かなりずさんな状態」と言える。そのような状態にならない程度の管理をしっかりすればよいのであって、「厳重な管理」という表現とは違うものだろう。
考えれば、あたり前だ。
だから、キャッシュカードは財布に入れて、普段持ち歩けるわけだ。
キャッシュカードについて、「厳重な管理」を求められて、手提げ金庫のようなものに保管して持ち歩かなければならないとしたら・・・
その金庫にキャッシュカードではなく現金を保管すればよいだろう。

ならば、回数上限を１回にしてしまえばよいのか？
すなわち、１回でも失敗したら、カードを使えなくするということになる。
この回数を減らせば、本人が単に入力時に入力ミスをしただけで、カードが使えなくなってしまうので、本人にとっての利便性が失われる。
利便性が低下してよいなら、回数を少なくしておくことができる。
人は間違えるものだと思えば、回数をある程度のものにしておく必要がある。

とはいえ、連続失敗回数制限では、カードの管理状況に依存するのは確かだ。
それを強化したい場合には、積算失敗回数制限にするしかないのだろうか？
そうとは限らない。これを補間する方法はある。
それは、直前の失敗を成功時に本人に知らせることだ。
そうすれば、本人からすれば、いわば、積算失敗回数を確認していることになる。

つまり、パスワードを普段入力ミスしない人であれば、あるとき、正しいパスワードを入力した際に、「直前に２回パスワードミスがありましたよ！」と表示されれば、「誰かがカードを自分の気付かない間に使おうとした」ということに気付けるので、その人が必要な対応ができるということだ。

ということで、政府機関統一基準では、パスワード変更を無条件に求めていないし、直前の結果を知ることができる機能を強化遵守事項として求めているなど、主体認証についてはいろいろと仕込んであるので、参考に読んでみてくださいね。。。

「事故前提社会」は誤用である

「次期情報セキュリティ基本計画に向けた第１次提言」等に関する意見の募集に、先日意見を提出してみた。

それは、この基本計画で初期から用いられている「事故前提社会」という言葉についてだ。
言葉の意味としては、「事故を前提とする社会」ということになる。
事故の発生は想定しなければならないが、前提とするものではないはずだ。

想定と前提では意味が異なることは、「性善説を前提にして性悪説を想定する」でも紹介したとおりだ。

正しくは、「事故想定社会」又は「事故対応前提社会」だろう。

そこで、以下のとおり意見を提出してみた。

意見内容： 「事故前提社会」とういう表現について、「事故想定社会」に改めるべき。

理由： 「前提」とは、「物事を成す土台となるもの」などが一般的な意味である。 社会を成す土台が事故であるという語法は明らかな誤用である。 本文中では、たびたび、事故が発生するのは仕方がないと言うわけではないという趣旨の説明を繰り返しているが、その場合の正しい日本語は「想定」である。 「事故前提社会」の意味として誤解しないで欲しいとして、上記の趣旨の説明をしているが、そもそも、自らが間違った用語を使っておきながら、誤解しないで欲しいというのは、馬鹿げている。 正しい用語を使えば、誤解は誤った用語を使う程には生じない。 社会を成す土台が事故であると主張するのでなければ、言葉を改めて、「事故想定社会」などの正しい日本語表現とすべきである。 この誤用は、貴センターのすべての資料等に従前からあるものであるが、新規のものについて訂正をはかるべきである。 誤用しておきながら、いったん使ったものだからという理由で、誤用をそのまま訂正せずに、日本語の意味を不当に異なるものにすりかえた解釈を強いることは、健全な社会を標榜しようとする立場として許されることではない。 情報セキュリティにおいてＰＤＣＡなどのマネジメントシステムの構築を促しておきながら、自らが「見直し」もできないということのないように、十分な確認をお願いしたい。

意見書として提出した「事故想定社会」は、あくまで一例ではある。

６文字で正すならば、「事故想定社会」と言うべきだろう。
「前提」ではなく「想定」という言葉ではインパクトが弱くなるとして「前提」を残したいのならば、意味を正して、「事故対応前提社会」などのように、「事故」を前提とするのではなく、「事故に備えた何か」を前提とすればよいだろう。

「事故前提社会」という言葉がどのように使われてしまっているかを書いている側は知らないのかもしれないが、ＩＴ関連の事故を起こしてしまった当事者に、「政府でも事故は前提としているような世の中だから・・・」の言い訳にされているのが実情だ。
事故の発生を前提としているのではなく、それを想定した上で、事故への備えをすることを前提としなければならない。ということが言葉だけからわかるようにしなければ、かえって逆効果なのである。

いくら、訴えたいことの趣旨（事故の発生の前提ではなく備えの前提を期待）を、基本計画の文章で丁寧に繰り返して説明している。としても、言葉というのはそれだけで独り歩きする方が、人の目につきやすい。
言葉を耳にしたすべての人が、基本計画を読んでくれると思うのは、あまり現実的ではない。
キャッチコピーになるような言葉は、それが言葉だけで独り歩きすることを「想定」しないといけない。

そのことは以前、「性善説を前提にして性悪説を想定する」でも紹介したとおりだ。

日本人なのだから、日本語は丁寧に使うようにしなければいけない。

デジタル・フォレンジックの体系化の意義

デジタル・フォレンジック研究会のメール・マガジンに寄稿しました。

デジタル・フォレンジックは、基礎技術としての意味から、調査手法全般としての意味まで基礎から応用という多階層で用いられるとともに、応用分野としても多様な観点からデジタル・フォレンジックが位置づけられており、まさに縦横無尽に用いられる言葉です。

つづきは、こちらからどうぞ：

第１４回コラム 「デジタル・フォレンジックの体系化の意義」

経済産業省 「ＩＴサービス継続ガイドライン」

経済産業省が「ＩＴサービス継続ガイドライン」を公表しました。

これまであいまいにされてきたことについて、このガイドラインで、実はさらっとふれています。。。

情報セキュリティと事業継続は包含関係なのか、上下関係なのか、横並びなのかについて、いろいろな考え方があります。
このガイドラインでは、図 2.1-2 「IT サービス継続、事業継続、IT 戦略との関係」（４ページ）で、事業継続にＩＴサービス継続を含むとした上で、以下の図 2.1-3 「IT サービス継続と情報セキュリティとの関係」（５ページ）があります。

この図では、情報セキュリティの基本要件である機密性・完全性・可用性のうち、可用性だけをＩＴサービス継続に配置した上で、以下のような注釈を加えています。

４ページ　脚注５ 広義のIT サービス継続には、機密性・完全性の要素も含まれ得るが、本ガイドラインでは主に可用性の 面に着目し、情報の機密性と完全性の確保を主に情報セキュリティ上の責務と捉えた上で、IT サービス継 続は常に情報セキュリティ対策と並行して確保すべきとの考えに立つものとする。

つまり、「情報の機密性と完全性の確保は、情報セキュリティの責務であり、ＩＴサービス継続には含んでいない。ただし、それはやらないということではなく、常に情報セキュリティ対策と並行して確保しなければならないことを意味する。」という考え方もあるとしました。
言い換えると、
「仮に、ＩＴサービス継続にて、可用性を維持したものの、機密性と完全性だけが損なわれた場合があったとしたら、その場合には、ＩＴサービス継続は機能したことになり、その際に、情報セキュリティのうち可用性以外の要件が機能しなかった。」という考え方で整理して、マネージメントシステムを構築することができます。

ガイドラインでのひとつの捉え方として、これを一般論とするつもりではないことにしていますが、これまであまり仮例も示されていなかったので、いいきっかけになるものと思います。

おまけ・・・

一方で、ＩＴサービス継続で、情報セキュリティからはみ出している部分はどういうものになるのでしょうか？

結構つらいですが、
一応、無理無理ですが、以下のような解釈を議論の出発点にするしかなさそうです。

「情報セキュリティ対策は、リスク分析時の脅威の特定に基づくため、脅威として、たとえば故障を含めていなければ、それへのリスク対応としての情報セキュリティ対策が見逃されることになる。
それに対して、ＩＴサービス継続対策は、脅威の有無を問わず、継続するという目標に必要な対策をすべて講じることがあってもよい。
検討においては、必要な対策をすべて洗い出す際に、脅威を想定するのが一般的であるため、ほとんどの場合は、可用性の侵害への脅威として特定されることで足りると考えるが、分類の考え方としては、情報セキュリティは脅威の特定に基づくもの、ＩＴサービス継続は、必ずしも脅威に基づくことに限定しないものとして、わずかながら相違部分がある。」

これについてもいつかガイドラインに明記できるような仮例が示せるときがくるといいですな。。。

ＩＴゼネコンの構造的破綻？

ちょっとショッキングなタイトルですが、第１弾として、「無責任な委託の連鎖」ということで・・・

Y's Station にて、「委託先における情報セキュリティ対策のあり方と認証制度の関係」をお聴きください。

政府機関統一基準による情報セキュリティ対策の基本的考え方

高等教育機関向け情報セキュリティセミナーでの講演について、期間限定でストリーミング配信をしています。

ぼくの担当は、政府機関統一基準ですが、国立大学向け基準雛型の説明を他の講師の方々がしていますので、参考にしていただけると思います。

ストリーミング配信の期間とアクセス先は以下のとおりです。

配信期間：９月１８日（火）１２時～１１月１６日（金）１２時
配信ホームページ：「情報セキュリティセミナー」の配信

http://www.nii.ac.jp/sec200708/

※接続の際には下記のID及びパスワードを利用して下さい。

ID：sec-seminar
パスワード：secsem0708

高等教育機関の情報セキュリティ対策のためのサンプル規程集

「高等教育機関の情報セキュリティ対策のためのサンプル規程集」の意見募集が始まりましたので参考まで。

http://www.nii.ac.jp/syskan/sp/Pubcomm.htm

以下、上記のページより抜粋：

～～～～～　ここから　～～～～～
本文書は、平成17年12月に「政府機関の情報セキュリティ対策のための統一基準」が制定されたことを踏まえ、各国立大学法人等を対象とするセキュリティ水準の向上を目的として、国立情報学研究所学術情報ネットワーク運営・連携本部が設置した「国立大学法人等における情報セキュリティポリシー策定作業部会」において、社団法人電子情報通信学会が設置している「ネットワーク運用ガイドライン検討ワーキンググループ」と合同で情報セキュリティポリシーのサンプル規程集として検討した成果をとりまとめたものです。
～～～～～　ここまで　～～～～～

なお、その後、このサンプルについてのセミナが企画されています。
https://yoshihiro.cocolog-nifty.com/postit/2007/08/post_3d07.html

情報セキュリティセミナーについて
　日　時： 平成19年8月31日(金)　13:00～17:10
　対　象： 大学等において情報セキュリティ業務に携わる職員
　主　催： 文部科学省、メディア教育開発センター、国立情報学研究所
詳細はこちら

情報の使用目的制限という観点

警察の捜査資料などが、捜査の勉強のために複製され、結果的にそれが情報セキュリティの脆弱性により流出した事案についてを考えてみると、これまでの「情報の格付け」に追加すべき観点について考察することができる。

この事案では、もとより、捜査資料を完全に複製禁止として格付けすることができたかと考えれば、それは現実的ではない。
捜査業務のために、必要な複製は妨げられるべきではない。
それらが適切に管理されるかどうかは、もとの捜査資料の格付けによる。

しかし、この事案のように、それが、「捜査の勉強のため」という目的で複製されたことについて考えてみる。

それは、業務目的外の複製ではないと考えることができる。
なぜなら、「捜査の勉強」は、業務目的の範囲内と位置づけられるからである。
そのように考えると、この事案の原因となっている、捜査資料の複製は、これまでの情報の格付けに基づく対策では防げないことになる。

ただし、この事案では、業務目的の範囲内ではあったが、もとの捜査資料は、その捜査業務を遂行することが目的であり、捜査の勉強が目的のための資料ではないという点に着目することができる。
つまり、業務目的の範囲内であっても、「使用目的の変更」を不用意に行なって、情報を取り扱ったことに問題がある。「使用目的の変更」を「転用」というならば、「転用禁止」という格付け（取扱制限）を指定していれば、捜査資料を勉強のために複製することは、禁止事項であったとすることができる。

そこで、「転用禁止」という取扱制限をひとつの考え方として取り上げることができる。

しかし、情報個別に指定するための取扱制限を、ここで使うということを考えてみると、それが個別に判断するべきことであるかに疑問が生じる。
たとえば、「業務外目的の使用禁止」は、情報個別の取扱制限ではなく、すべての情報にかかっており、情報の取扱いとしての遵守事項として存在する。
それを考えると、同様にすべての情報について「転用禁止」を遵守事項に設けることが考えられる。
しかし、以下のことにより、「すべて転用禁止」という遵守事項を設けることでは、適切な運用と管理が実はできないことが予想される。

結論から言えば、転用は「禁止」されるかというと、実際は禁止されるべきものではない。

なぜなら、その転用により、新たな使用目的が、業務外目的になることは、「業務外目的の使用禁止」により、そもそも禁止されているので、それについては改めて遵守事項を設ける必要はないことになる。
したがって、「転用」が生じてしまうのは、「業務範囲内での転用」であって、それならば転用はすべて一律に禁止されるべきものではない。
一律に禁止されるのではなく、転用によって必要となる措置がないかを検討し、必要な措置を講ずるということが情報の取扱いとしては適切であると考えられる。

一定の措置を講じればよいことを「禁止」ではなく「制限」と呼ぶならば、「転用禁止」ではなく「転用制限」とするのがよい。

このとき、「転用制限」を運用するためには、その情報の本来の使用目的が明示されていなければ、使用目的に沿っているのか転用なのかを、情報の利用者が判断できず適切に運用できない。
そのため、「転用制限」という遵守事項を設けるに際しては、その「使用目的」を明示するという遵守事項を併せて設けることが、適切な運用に不可欠となる。

場合によっては、すべての情報に対して「転用制限」を適用するのではなく、情報個別に取扱制限を指定するということもあるかもしれない。ただし、その場合においても、「転用制限」を指定するにあたっては、「使用目的の明示」が必要となることは変わりない。

このとき、「使用目的の明示」における、「明示」は、「格付けの明示」と同様に運用するのでよいものと思われるが、「格付け」については、予め決めた「機密性２」などのような特定の用語による格付けでよいのに対し、「使用目的」については、自由書式となるため、「格付け」における暗黙の指定を認めるかについては注意が必要になると思われる。

いずれにせよ、業務手順の自由度が増した職場では、情報セキュリティ対策において、情報の格付けに加えて、情報の使用目的についても明示するということについて考察することは、おもしろそうである。

個人情報を取り扱う事業者において、その利用目的が制限されているが、そのような目的の制御はいまのところITのアクセス制御で直接管理することができないが、情報セキュリティ対策において、使用目的の管理をする解決策が見出されると、それは、個人情報保護対策にも貢献するかもしれない。

リスクは細部に宿りたもう

「リスクの集中管理」と言った場合に、リスクを集中的に管理するというのは、リスク管理作業を集中化するということを意味するのではないと思っている。
そのように集中化できることを否定はしないが、そのようにするには、リスク管理のスーパーマンを想定しなければならない。

すべての企業にそんなスーパーマンはいるのだろうか？
いたら頼めばよいが、いなかったら育成するのだろうか？
育成できないならあきらめるしかないのだろうか？

そんなことについての考えを、翔泳社の IT Compliance Web が取材でまとめてくださったので、よかったらどうぞ。
もとは雑誌の記事だったけれど、Ｗｅｂにも掲載されたのでお読みください。

IT Compliance Web

　「リスクは集中管理できるのか～企業における法対応とITのバランス」

経営者が知っておくべきデジタル・フォレンジック

NTT Communications の Information Security Guide に記事を投稿しました。

お題は決まっていたので、それに合わせてかなり強引に執筆しましたが、内容としてまちがってはいないでしょう・・・

連載：信頼される企業・組織運営のためのデジタル・フォレンジック
第５回　経営者が知っておくべきデジタル・フォレンジック

政府機関統一基準の解説音源

Y's Station（わいズすてぇしょん）に、政府機関統一基準の解説音源をアップしました。

以下の２バージョンあります。

・40分版
・90分版

お楽しみ（？笑）ください。

情報セキュリティインシデントの管理

情報セキュリティインシデントの管理については、ISO/IEC JTC1 から、以下の文書が出ています。

ISO/IEC TR 18044 Information Security Incident Management

同書の邦訳は出ていませんが、文書名は、「情報セキュリティインシデントの管理」ということになると思います。

この文書の作成をしていたので、これにどんなことが書いてあるかについての紹介文を用意してみました。

ISO/IEC TR 18044 Information Security Incident Management（情報セキュリティインシデントの管理）
に書かれている内容を簡単に紹介すると、以下のようなものです。

ISO/IEC JTC1/SC27では、情報セキュリティインシデントの管理に関してISO/IEC TR 18044という技術報告書（Technical Report）を発表しています。 この技術報告書は、以下のような点から助言及び指針を与えています。 組織では、インシデントへの対応手順や体制を整備しなければなりません。しかし、インシデントを迅速に対応できる体制が確立しても、日常的に発生している多くの事象を、現場の当事者がインシデントとして認識するのが遅れると、結果的に対応が遅れてしまいます。 そのようにならないためには、インシデントと認識された以後のことばかりではなく、それ以前の事象にも広く注意をする必要があります。つまり、インシデントの管理をする際に、インシデントから始めるのでは不十分な管理策となってしまいます。 そこで、インシデントとなる可能性や未知の状況を示している「事象」が、事業運営を危うくする確率及び情報セキュリティを脅かす確率が高くなることで「インシデント」に変遷するという考え方をすることが重要であり、インシデントの管理では、インシデントになる前の事象も対象とする管理策を講じなければなりません。 それらについて以下の流れで示しています。 ・情報セキュリティインシデントの検出及び報告、査定 ・影響の予防及び低減、並びに、影響からの回復のための適切な管理策の活性化を含んだ、情報セキュリティインシデントへの対応 ・情報セキュリティインシデントからの学習及び予防的管理策の探求、情報セキュリティインシデントマネージメントの総合的な取り組みに対する四六時中の改善 また、これらを確立するために PDCA モデルに似た以下のようなプロセスモデルを適用しています。 ・計画準備段階 ・利用段階 ・レビュー段階 ・改善段階 このようなプロセスモデルを適用して、計画準備段階として事前計画に基づく対応手順を充実させて、実際のインシデント発生時に、手順に従って対応することを基本にしています。しかし、その一方で、計画準備段階に用意した手順がインシデントの実情に沿わないときには、手順以外の方法による対応をするための手続きが必要であることも指摘しています。なぜなら、インシデントとは、予測不可能な状況となることもあり、その場合には、事後対応を事前計画で想定した範囲内だけで実施することは、むしろ想定外の状況に柔軟に対応をできなくなる場合がるからです。そのため、想定外の状況に遭遇した場合には、実際の担当者の判断で、事前に定められた処置とは異なる例外処置をできるようにすることも必要です。そのような例外処置についても管理するような管理策を講じることについて述べています。

インシデント・マネジメントについて検討している場合には、参考にしてみてください。

政府機関統一基準適用個別マニュアル群

内閣官房情報セキュリティセンターが以下の文書群を新たに公開しました。

• 政府機関統一基準適用個別マニュアル群
  

公表日が、9月11日という意味ありげだったり、URLが、kijun_man だったりと、つっこみどころ満載ですが、内容はいたってまじめなものです。

たとえば・・・

公開されたのは、１９文書４０ファイルですが、ここでは１つくらい紹介しておきましょう。

「情報の格付け」は、ISO/IEC 17799 のコントロールにもありますが、具体的なことが書いていないので漠然としたままということもあるかもしれません。
統一基準適用個別マニュアル群の中には、

• DM3-01 情報の格付け及び取扱制限に関する規程 策定手引書
  
• DM3-02 情報取扱手順書 策定手引書，情報取扱手順書 雛形
  

などを参照すると、具体的なイメージがつかめるようになると思います。

その他にも、「雛型」と称して、「たたき台」を示しており、さらにその「たたき方」を「策定手引書」と称して補足説明していますので、「政府機関統一基準適用個別マニュアル群」のページでご確認ください。

政府の公開文書というのは、改訂するのに色々と事務手続きをふんで、履歴管理をするのが一般的なのですが、この「統一基準適用個別マニュアル群」については、ページ冒頭の注意書きにもあるように、よりよい情報をタイムリーに提供することを優先して、随時改訂されることになります。
ダウンロードして蓄えてしまうよりも、必要なときに、随時アクセスして最新版を入手するように使うのがよいと思います。

「暗号化」と「暗号で保護する」を使い分ける

まるちゃんの情報セキュリティ気まぐれ日記に投稿されていた、
　・個人情報の暗号化と安全管理措置
　・個人情報の暗号化と安全管理措置のコメントへの回答
を読んで、「暗号化」と「暗号で保護する」という表現を使い分けるのがよいと思った。

経済産業省の個人情報保護ガイドラインにおいて、第２０条部分で特段に暗号についてふれなかったのは、次のような消化をしたからだ。

・個人情報を暗号化しても個人情報であることには変わらない。
・暗号化とは（実際には情報が変換されるがそうではなく）情報を包み込むようなものとして位置づけた。
・暗号化することとは、紙面に記載された個人情報のリストを鍵付きの箱に入れて送ることとして考えた。
・たとえば、郵送であれば箱ではなく封筒となるが、封筒の強度を定量的に議論することがないのと同じく、暗号の強度などについてもふれないのが妥当と考えた。

情報を記載した紙面を鍵つきの箱に入れると、紙面と箱が有形物として異なるため、紙面が保護対象であり、箱は保護手段であるという分担が直感的にわかりやすい。
それに比べ、暗号化では、データそのものが変換されるという処理に着目してしまうと、暗号化する前と後をともに１つの情報として考えてしまい「暗号化された個人情報」という個人情報が加工された表現のようになってしまう。
これは技術的にはまったく正しいが、そのまま直接的に安全管理措置の保護対象としての情報として取り扱うと混乱のもととなる。

「暗号化された個人情報」という表現は普通にするし間違っていないが、技術的な処理方法を直接取り扱うという呪縛の表現だと思えてきた。
そうではなく、「暗号によって保護された個人情報」という表現を使うと、少しはすっきりするのではないだろうか。
英語だともうちょっとわかりやすいかもしれない。
Encrypted personal information
と言うよりは、
Personal information protected by encryption
と言う方が整理が進むのではないかということだ。

個人情報が暗号化されたら、個人情報が暗号という箱に格納された状態をイメージするとよい。
このことは技術的にはまったく間違っているが、個人情報の暗号化と安全管理措置の関係を整理するときには、考察しやすくなるに違いない。
技術的な意味での正確さを維持したままの表現で、管理を議論すると、技術からの中立性が実は奪われてしまうのかもしれないと言える。

仮に「暗号による保護」を「鍵付きの箱による保護」と割り切ってしまうという大胆なことをすると、箱の強度を考えたときに、箱の素材の強度だけを論じるのでは不十分だということなどを直感的に取り上げやすくなり、技術屋ではない者を議論の中に取り込みやすくなる。
そのように議論したうえで、「箱のこの機能は暗号ではどうなるのか？」という問いに対して、技術屋はそれを機能要件と捉えて実装手段に関連付ければ、技術的な正確さを失っていることは、後でつじつまあわせをすることができる。
そのような手法を取れば、暗号化することによる安全性について考察するときに役立つ。

特に技術屋といっても、多くの技術屋は暗号技術についての知識が実は貧弱だ。
そういう技術屋を見抜くのにも、暗号を箱に置き換えて説明させるのは役立つ。
まるちゃんも引用している、高木浩光＠自宅の日記にある
流出した暗号化ファイルと傍受された暗号化通信データの違いの中で触れているように、安全性はパスワード頼みということが多いことについて、管理を議論する者が気づきやすくなる。

技術屋に、鍵付きの箱と暗号の関係において、パスワードと暗号強度がどのように関連付けるかを質問するとよい。
パスワードは挿入する鍵に対応し、暗号強度は錠前の強度に対応すると答える者がいるかもしれないが、そういう者に暗号による保護を相談しない方がよい。
ほぼすべての暗号製品では、パスワードが挿入する鍵に対応するのは間違いないが、暗号強度は箱の強度に対応してしまう。本来重要な錠前の強度がとばされているということだ。
箱がいくら頑丈であっても、錠前が脆弱では箱は無傷のままで箱の中身が盗まれてしまう。
暗号のアルゴリズムと鍵のビット長ばかりを議論するが、それは箱の強度でしかないということだ。
箱の強度は大切だが、錠前に相当する部分が、その暗号製品ではどのように保護されているかを確認する必要があるのに、ほとんど議論されることがない。
その点において、高木浩光氏の「パスワードのレベルに落ちている」については同感だ。
ただ、そのように説明されると同感だと理解できる程度の技術屋では、相談相手としては、なお不十分だ。
暗号強度が錠前の強度になるにはどうなっていればよいかを明確に答えられるなら、相談するのに十分だ。
それについての答えはここでは書かないことにする。
書いてしまうと、答えだけ暗記する者と十分な知識がある者を見抜きにくくなるだろうから・・・
見抜きたい相手に答えさせて、その内容に納得できれば、それが正解だと思えばよい。

個人情報の暗号化ということで書いたが、このことは、個人情報には限らない情報の安全管理措置における暗号化の位置づけと同じことになる。

「暗号化」という言葉は、技術論議のときだけ使うことにして、管理を論じるときには、「化」を付けずに「暗号による保護」という言葉を用いるのがよいのだろう。

そうすれば、暗号を情報の状態ではなく、管理策の手法として位置づけることができ、アクセス制御などとの関係を決めやすくなる。
「暗号化された情報をアクセス制御で保護する」
という言い方は避け、
「情報を暗号とアクセス制御で保護する」
と言うことを心がけるのがよい。

コストをかけないモバイルＰＣセキュリティ対策

ThinkIT の連載の第５回は、コストをかけないモバイルＰＣセキュリティ対策としてまとめました。

記事は以下に掲載しています。

第５回：コストをかけずにできるセキュリティ対策

ＰＣのセキュリティ対策は、お金をかけなくてもできることが結構あります。
セキュリティ屋からセキュリティ対策を教わると、そういうことが逆におろそかになり、金のかかることばかりを勧められたりするので注意しましょう。

上記の記事では、ＴＰＭについては、簡単にしか触れていませんが、ＴＰＭもコストをかけずにできる強力なセキュリティ機能です。
そちらについては、以下のブログで紹介しているので、ご興味ある方は参照してください。

• TPMガイドライン
  
  

連載記事のバックナンバーは以下のとおりです。

第１回：データが語る個人情報保護法の実態
第２回：企業における対応方針と成功の秘訣
第３回：個人情報の分別
第４回：社内ガイドラインの作成

TPMガイドライン

経済産業省の高信頼性端末の電子認証基盤の調査研究である

信頼できるコンピューティング環境の実現に向けて
～Trusted Platform Module(TPM)の可能性 ～

が日本画像情報マネジメント協会から公開されています。

報告書は、上記のページの右下にある「成果報告書」というリンクからダウンロードできます。

委託先におけるISMS認定の意味

JIPDEC から以下のガイドラインが公開されました。

制度の概要、認証基準及びガイド一覧
　の中の
「外部委託におけるISMS適合性制度の活用方法」

ガイドラインには長々と書いてありますが、何が言いたいかを簡潔にいうと・・・

委託先（下請け）に「ISMS 認定を取得していること」というだけの契約条件を課しているのではダメですよ。
ということです。

意味のあるものにするには、「適用範囲定義書」に記載された内容を確認しなければなりません。

意外にも、「ISMS 認定を取得していること」という不毛な規程を設けている委託元が多いため、わざわざガイドラインとして用意されました。
無意味な規程にならないような、規程の書き方の例としては、政府機関統一基準を参考にすることができます。

なぜ、統一基準で言及した上に、ガイドラインまで用意して理解を促そうとしているかということについては、

委託業務における委託元と委託先の関係

で解説をしていますので、参考にしてください。

これだけ、しつこく資料を用意したわけですから、今日以後は、下請けに対して「ISMS 認定を取得していること」とだけ要求する委託元は、自ら「当社は情報セキュリティ対策に責任を持つつもりはありません」と宣言しているのと同じです。
そうではなく、ISMSを有効に活用するために、委託する業務が適用範囲定義書に明記されるように求めるのならば、それを求めるか否かによって、それなりの対価を支払う必要があるということについて自覚していなければなりません。

そうしなければ、無責任の連鎖は止まらないのですから。。。

白飯みたいな情報セキュリティ

「まるちゃんの情報セキュリティ気まぐれ日記」で紹介されたので、会場にいなかった方にも説明をしておきます・・・です。

まるちゃんが紹介してくれている資料は、こちらにアップしました。

そして、まるちゃん日記にある「面白かった話１」

内部統制とかSOX法対応を幕の内弁当とすると、情報セキュリティは白飯。

が意味するところは・・・

最近気になっていることがあります。

「SOX法対応には、情報セキュリティの強化が必要です。」
とおっしゃる、情報セキュリティ屋さんをよく見かけるわけですが、
それは、
「幕の内弁当には、白飯が必要です。」
と言うのと同じような売り口上だと思っています。

「幕の内弁当には、白飯が必要です。」は、嘘ではないのだけど、
その「幕の内弁当」と「白飯」の関係は、
「のり弁当には、白飯が必要です。」
とか
「から揚げ弁当には、白飯が必要です。」
「生姜焼き定食には、白飯が必要です。」
というのと同じくらいの関係しかありません。

「○○には、××が必要です。」と声高々に言う場合には、
××には、○○の特徴的なものを言うべきだと思います。

「白飯」は、あらゆる弁当や定食にも含まれる基本的なものであって、
それぞれの特徴的なものではありません。

つまり、
「から揚げ弁当には、から揚げが必要です。」
と言うなら、まだしも、それを
「から揚げ弁当には、白飯が必要です。だから、白飯を買ってください！」
って言うのは行き過ぎです。

どうも、「個人情報保護には、情報セキュリティの強化が必要です。」と言ったら、
「情報セキュリティ関連グッズ」がいろいろ売れたもんだから、
それに味をしめているようですが。

まぁ、百歩譲って、
「幕の内弁当には、白飯が必要です。」ということにしてあげたとしても、
「じゃぁ、幕の内弁当とから揚げ弁当は何が違うの？」と聞いてみると、
「いや。まずは白飯の話しをしているので、おかずのことは次に考えましょう。」
と言われてしまうと、嘘ではなくて許されることにも限度があると思ってしまう。

「内部統制のための情報セキュリティ」を売る人達はしばしば、
「財務処理やアプリケーションは範囲外で、インフラ部分が対象です」とか
言うのだけど、
それって、
幕の内弁当を欲しがっている人に、白飯だけを売ろうとしているのと変わりない。

「幕の内弁当には、白飯が必要です。だから、白飯を買ってください！」
は嘘ではないけど、
それで、白飯だけを売ろうとするのは、良いことではなさそうだ。

ただ、それで白飯を買う人がいるから、白飯売りが世にはびこるということだとも思う。
それならば・・・
日の丸弁当を、幕の内弁当だと思って食べているなら、
それはそれで幸せなことなのかもしれない。
売って喜ぶ人と、買って幸せになる人がいるなら、
その人達の間では丸くおさまっているわけだから、まぁ、いいんだけど。。。

というのが、まるちゃん日記にある「面白かった話１」の顛末です。

なんで、喩え話しの弁当の種類が、幕の内弁当かというと、
講演前の昼食に、幕の内弁当を食べたというだけです。。。

Winnyを介した情報流出の対策

内閣官房情報セキュリティセンターが、以下の注意喚起を掲載しました。

Winnyを介して感染するコンピュータウイルスによる情報流出対策について

もともとは、政府内での注意喚起のために準備した資料を基に、同様の情報は一般でも有益であろうとの判断で資料や対策内容をより改善して公開となったものです。

ただし、そもそも、「Winny でまたも機密情報流出！」という表現は正確ではありません。
「Winnyで流出していた機密情報がまたも発見」というのが正確な表現です。
なので今から流出防止対策だけをやるのでは片手落ちです。

他にも、いくつか気にしなければならないことがあります。

このような具体的な手順書が示されることは、企業などで対策を検討している人達にとって、有益なことだと思われます。
そのような情報提供を継続してもらうために、情報を利用する者が心得るべきことがあります。

このような手順書を出す側からすれば、その内容に不備があれば、その点が責任問題になってしまうかもしれないということを気にし始めると、情報提供活動そのものが萎縮してしまいます。
このとき、不備には２種類あって、内容が「誤り」という場合と、「不足」という場合があるでしょう。
もちろん、誤りであれば、情報提供者は責任を少なからず持つべきです。
しかし、誤りではないが不足があったということであれば、情報の受け手は、万が一不足があっても、情報提供者の責任云々についてあまり言わないように心がけるべきです。
不足があれば、気づいた者が、追加の情報を提供するということで、不足を補うことで情報をよりよいものにしていければ、この種の情報提供活動が萎縮することはないものと思います。

ということで、対策手順の情報提供を歓迎することが大切でしょう。

で、本題のWinnyによる情報流出については、以下のようなことを考えてみました。

「Winny でまたも機密情報流出！」という表現は正確ではありません。
「Winnyで流出していた機密情報がまたも発見」というのが正確な表現です。
想像ですが、Winnyネットワークには、既に少なくない量の機密情報が流出してしまっているけれど、そこにある膨大な他の情報に埋もれていて発見されていない状況で、それらの既に流出してしまっている情報が発見され始めたというのが実態ではないかと思います。

想定問答的に説明することにします。

---

Ｑ１
Winnyなどのデータ交換ツールやウィルス、スパイウェアなどのソフトウェアによる情報漏えいリスクは、今に始まったものではないと思われる。
しかし、"ここへきて急に"個人用パソコンからの情報漏えい事件が明らかになるケースが急増しているのには、何か潜在的な背景・要因があるのか。

Ａ１
報道などを見る限り、Winny での新たな流出があったというのではなく、正確には Winny ネットワーク上に既に流出しているものの中から、不適切なファイルが、「新たに発見された」というのが正しいと思います。
ケースが急増した理由ですが、特に根拠のあるものではなく、あくまで私見ですが、これまで Winny 上にはファイル交換を目的とするユーザが存在しており、その中で偶然に企業や組織の機密ファイルがみつかっていました。
なぜなら、ユーザが Winny 上でファイルを検索するために使うキーワードは、好きなアーティストや映画のタイトルだったためです。
ここにきて、「Winny 上に機密情報などが流出している」ということが話題になったために、これまでのユーザとは異なり、「機密情報を見つける」ことを目的とするユーザが参入したのではないかと、推察します。
つまり、検索キーワードとして、「機密」とか「○○会社」などを使って検索することで、これまで既に流出していたが、膨大なファイル群の中に埋もれていた機密ファイルの類が発見されるようになったとも考えられます。

---

Ｑ２
こういった問題の対策としては、もちろんセキュリティの高いシステムを入れるであるとか、システム的・技術的な問題をすぐ想像しがちだが、実はもっと、たとえば仕事場の環境の問題（１人１台パソコンがないとか）など、抜本的な問題があるのではないかと考えているのだが、その点についてはどう考えるか。

Ａ２
そのとおりだと考えています。ただ、１人１台のパソコン環境などという単純なことではなく、いくつかの類型を考えることができます。

（１）組織が調達していないＰＣを業務に使うことの問題

この場合、ＰＣに関する管理規則が及ばないのでいくらルールを設けても効果は低く、本来は業務に必要なＰＣのコストを充当していないことが本質的な問題となります。
さらに、建前として、「私物のＰＣを業務に使うな」というルールを設けていると、「私物のＰＣを業務で使う場合には・・・」というルールすら設けることができないために、まったく監督ができなくなります。
少なくとも、実態とルールを一致させた上で、さらに、私物にルールを適用させるにはどうするかという課題を克服しなければなりません。
実態とルールを一致させる解決策の１つは、「業務に必要なＰＣはすべて組織が支給する」ということだと思います。
１人１台でも、モバイルの用途があるのにデスクトップしか支給されていなければ、１人１台でも足りないということになります。また、１人１台なくても、共有ＰＣの適切なものがあれば事足りるのであれば、必ずしも１人１台支給する必要はありません。
したがって、「１人１台ないのは問題」という表現は適当ではなく、「業務に必要なＰＣが支給されているか」という表現の方が適当だと思います。
一例として、「１人１台のＰＣが必要な業務・職場において、１人１台のＰＣがないのは問題」というのがあると思います。

（２）組織が調達したＰＣにWinnyが入っていることの問題

これも、Winnyのことだけを取ってみるとWinnyを入れる人が悪いということになりますが、Winny以外のフリーソフトで業務に役立つものはＰＣに自由にインストールさせているというのが実態であれば、その中でWinnyだけを規制するのは現実的ではないと思われます。
本来業務に使うソフトについては、すべて会社が管理することにしていれば、「各人が勝手にソフトをインストールするな」は実態に即しますが、実害のない文房具的なソフト（たとえば、画面に付箋を貼るなどのフリーソフト）を使って、現場裁量で業務改善をしていることについては黙認しておいて、都合の悪いときだけ、「自分で勝手にソフトを入れるな」は説得力を失います。
先の（１）が、ＰＣというハードウェアについて、業務に本来必要なコストを充当していないとするなら、この（２）は本来購入すべき業務ソフトウェアを購入せずに済ませているという観点となります。
Winnyは業務で使う用途のソフトでない場合がほとんどだと思いますが、だからといって、業務に役立つものは勝手にインストールしてよくて、そうでないものはダメというのは、理屈の上では成り立っても、実態としては徹底できないと考えるべきです。

---

というようなことだと思います。
今回紹介された対策を実施することは必須です。
しかし、だからといって、その対策を完璧に実施したとしても、それ以後に情報流出が「発見」されることがなくなるということではありません。
企業は、過去に流出してしまっている情報が「発見」されたときに備えての対応も、引き続き準備しなければならないものと思います。

公益通報者保護制度

2006年4月1日から、公益通報者保護法が施行されますね。

内閣府がこれのポータルサイトを用意してくれており、とてもよくできています。

ただ、公益通報者保護を Whistleblower Protection と英訳するのは、いただけません・・・

内閣府の「公益通報者保護制度ウェブサイト」は、

　http://www5.cao.go.jp/seikatsu/koueki/index.html

として公開されています。

法条文そのものの他に、運用上のガイドラインや報告様式の雛形なども用意してくれています。
また、立法時の審議内容や諸外国の動向調査報告書などを、まとめてくれており、ポータルサイトとしてよくできています。
他の法律もこれくらいのことをやってくれていると大変ありがたいです。
他の事案についても、立法審議時、施行時、施行後の政府としての情報提供のお手本として見習って欲しいものです。

ところが・・・
ちょっと残念だったのは、このポータルサイトそのものではなく、内閣府のホームページのリニューアルです。2006年1月6日にリニューアルされたのですが、それまでは、ホームページから、上記のポータルサイトには、「公益通報者保護制度」という見出しからワンクリックでアクセスできたのに、リニューアルによって、２クリックになってしまいました。ワンクリックできるといいのに。。。
ということで、クリック１回分の違いだけなのですが、ここに URL を残しておくことにしたのでした。ｗ

本題に戻りますが・・・
関連情報のポータルサイトとしてお奨めしますが、現時点での、公益通報者保護法制度の内容そのものについては、まだ議論の余地が多くありそうです。

まず、このサイトでは、公益通報者保護を Whistleblower Protection と英訳していますが、これはやめた方がいいと思っています。
Whistleblower Protection の邦訳は、内部告発者保護でよいと思います。正確には、内部はなくて、単に告発者保護だとは思いますがまぁいいでしょう。
そこで、なぜ、公益通報者保護を Whistleblower Protection と訳さないほうがよいかというポイントはいくつかあります。
・Whistleblower Protection = 内部告発者保護と思われており、そうすると公益通報者保護＝内部告発者保護と誤解される。しかし、公益通報者保護制度は、外部告発者も対象にしている。・・・でも、これは些細なことです。
・内部告発者保護は、不正の告発を広く対象にするが、公益通報者保護制度は、公益通報を限定的に定めている。・・・こっちが大きな違い。

今後の運用の議論の中で、これらの違いがなくなって、公益通報者保護＝告発者保護となれば、それ以後は、公益通報者保護を Whistleblower Protection と英訳してよいと思いますが、それまでは言葉による誤解を生じることになるのでやめたほうがよいと思います。

たとえば、個人情報保護をプライバシー保護と混同してはいけないのと同じ問題です。
それぞれの英訳は、Personal Information Protection と Privacy Protection とで異なるわけです。
公益通報者保護を Whistleblower Protection と英訳することは、個人情報保護を Privacy Protection と訳してしまうことと同じようなものだと思います。

名は体を表すことになりますから、米国において、Whistleblower Protection Act として名と体が定着している「名」を安易に使い始めるのはよくないことです。
その「名」に体を合わせるという覚悟を示したいということであればよいのですが、まだそう決めているわけではないのでしょうから。。。

英訳語のことだけ書きましたが、本題の、公益通報者保護制度の中身については、気になるところがありますが、それはもう少し勉強してから書くことにします。

政府機関統一基準の全体版公開

政府機関の情報セキュリティ対策のための統一基準の全体版が公開されました。

2005/12/13 に、第3回情報セキュリティ政策会議が開催されました。

政策会議にて報告がありましたが、「政府機関の情報セキュリティ対策のための統一基準」に追加すべき項目に関する意見の募集の結果が公開されました。

約1ヶ月に渡って実施していた意見募集の結果として、「政府機関の情報セキュリティ対策のための統一基準」の2005年12月版［全体版初版］が掲載されています。

そのページでは、遵守事項本文だけですが、統一基準のページでは、解説書も公開されています。

政府機関の情報セキュリティ対策のための統一基準

• 「政府機関の情報セキュリティ対策のための統一基準（2005年12月版［全体版初版］）」
  
• 「政府機関の情報セキュリティ対策のための統一基準（2005年12月版［全体版初版］）」解説書
  

以前にも紹介しましたが、「解説書」は、統一基準について逐条での解説を加えたものになっており、自分の会社や組織などにおける情報セキュリティ対策基準策定にあたって今回の統一基準を参考にする際にも役立てられるものと思います。

ここで公開された統一基準は、民間でも著作権を気にすることなく活用することができます。
このような雛形に相当するものだけを使って、情報セキュリティのコンサルティングと称している事業者にとっては、より付加価値のあるサービスを提供しなければならないことになります。
その結果、本当にコンサルティング能力の高い人を見抜きやすくなるかもしれません。

これまで、セキュリティポリシーはなんとなく作れたけど、その次の具体的な基準は大変だ。と思っていた方は、解説書を読みながら役立ててみてください。

まったくの偶然ではありますが、同日付けで、会社の方ではこんなこともしてみました。

社内個人情報保護ガイドラインを無償公開

性善説を前提にして性悪説を想定する

組織における情報セキュリティ対策について、性善説では不十分だとか、性悪説を前提にするとかいうのは正確な日本語ではない。
言葉を正確に使わないと、意図は正しく伝わらない。
むしろ、話し手の期待と異なって、誤解を生じてしまうということに注意しなければならない。

●誤：性善説を前提にするのをやめて、性悪説を前提にする
●正：性善説を前提として、性悪説も想定する

「性善説を前提にするな」というようなことを、有識者と呼ばれる人達も言ったり書いたりしているが、彼らの全文をちゃんと読んでみると、その思いを正しい日本語で表現できていないように思う。
正しくは、佐藤が以前から使っている「性善説を前提に性悪説を想定せよ」と同じのようだ。つまり、「前提」と「想定」を使い分けていない。
「前提」と「想定」を使い分けない例は、有識者ばかりではなく政府にもある。
ｅＪａｐａｎ戦略では、「事故前提社会」と言っているが、それを言うなら、「事故想定社会」の方がより正確だ。
事故を前提に社会制度を作られたらたまらない。
この場合も、「想定」のことを強調する意味で、「前提」と使っているのだろう。

これら政府や有識者の思いは性悪説「想定」なのであって、単に「前提」という用語を誤用しているだけと思われる。
しかし、それらの発言に対する影響度の大きさには気をつけた方がよい。
自分たちの発言力は、自分が思うほど小さくないということだ。
彼らの思いとは異なり、その言葉を真に受けてしまうことで、「性悪説前提」論者が出てきてしまっている。

たとえば、「当社は性悪説で考えます」と経営者が言うことは、「社長のぼくのことも信じないでね。チャンスさえあれば、会社の資産を悪用するよ」と宣言しているわけだ。暗黙には、「予めそう言ったのだから、ぼくが不正しても文句言わないでよね」という完全無責任宣言だということがわかっていないのだろう。

●誤：性善説対策ではなく、性悪説対策を実施する
●正：性善説対策を実施した上で、性悪説対策を追加実施する

世の中には、もうひとつ、不十分な日本語表現が、誤解を生じている。
「組織における情報セキュリティは、性善説から性悪説へ」というものだ。
この表現は暗黙に、「性善説から性悪説へ切り替えよ」という述語を含んでいるが、それはまちがえだ。

これも日本語を誤用して広まっているものだ。
このたぐいのデマを吹聴する人のほとんどが米国事情を引き合いに出すが大嘘だ。
性善説から性悪説に移行した企業なんて存在しない。
性善説対策をある程度達成したら、次に、性悪説対策も追加するのであって、切り替えるものではない。
性善説対策もできていない組織が、性悪説対策なんてできるはずがない。

ルールは性善説の者にしか守られないのだから、性善説を前提にしなければならないのは自明だ。
性善説を否定することは、ルール設置を否定することに他ならない。
性善説の人に、性悪な人と戦ってもらわなければ、体制は成り立たない。

日本で見かける「性善説対策＝信頼するから組織は何も定めないし、何もしない」はまちがえだ。
「性善説対策＝善悪の違いについてをその理由とともに明確に定め、それを周知・徹底すること」と考えなければならない。
本来はそれを定める役目が、情報セキュリティポリシーだったのに、教条主義に走ったため、「その理由」が欠落して、例外事象への適応ができなくなり、結局、例外ではない明確な遵守事項までもが守られなくなった可能性がある。

性善説対策が相当程度に完遂できているかを、確認することが今とても重要になっているのだと思う。
それができた組織が、性悪説対策を実施すれば、効果があがるはずだ。
そうでない組織は、いつまでも、性善・性悪とも共倒れして、同じ事故を繰り返すことになるだろう。

ちなみに、性善説対策の達成が、そもそも、情報セキュリティガバナンスだ。
したがって、情報セキュリティガバナンスを論じるときに、性善説対策をあまり取り扱わずに、性悪説対策のことばかりを偏重するのはよくないことだ。
概ねは、性善説：性悪説＝８：２くらいの比率で考えるべきだろう。
性悪説対策は、情報セキュリティガバナンスの下に実施される情報セキュリティ対策の中で、集中的に取り扱えばよい。

おまけ：

性弱説という人当たりのよい言葉選びをしている人がいる。
ただ、性弱説というのは、性善説と性悪説の中間をとらえたような考え方になり、現象を説明するためにはよいが、それに基づいた解決策を導き出すことには、不向きだと思う。
性弱説として現象を説明はできるけれど、最初から性悪の人がいないとも言えないし、常に性善の人を否定するのもよいこととは思えない。そのためだと思うが、性弱説を唱える人が示す解決策は、何か抽象的な精神論になるか、あるいは、明らかに飛躍したものになることが多いように感じている。
性善と性悪の間で、人は性弱に揺れながら、どちらかにたどり着くのだということにした上で、その後の、性善説対策と、性悪説対策のどちらを人に適用するかを決める。という図式の中にならば、性弱説を持ち込んでみるのは説明を容易にすることに役立つに違いなし。
しかし、性弱説対策という切り口には、あまり同意できていない。

参考：

　・まるちゃんの情報セキュリティ気まぐれ日記

　・日弁連コンピュータ委員会シンポジウム'04

佐藤の講演から：

　・I-4 Regional Meeting (2002/12/5)

　・ネットワークセキュリティワークショップin越後湯沢 (2003/10/2)

　・第21回 Korea Techセミナー (2005/7/7)

政府のセキュリティ対策

情報ネットワーク法学会の第５回研究大会に参加しました。

情報ネットワーク法学会

基調講演を、山口英先生に内閣官房情報セキュリティ補佐官としてお話ししていただきました。
まるちゃん日記でも紹介されていますが、わかりやすい講演でした。

INTERNET Watchの記事：
　政府のセキュリティ対策、今後は新たな法律制定にも踏み込む必要性

講演資料：
　http://yosihiro.com/go/inlaw5

内閣官房情報セキュリティセンターは、官民からの人材で運営されており、山口先生は学からとなりますが、官だけでは、気づかなかった、あるいは、なかなか言い出せなかった観点でセンターがよりよい対策をめざそうとしていることがわかる、すばらしい講演だったと思います。

その中でできあがった政府機関統一基準は、いろいろな役立て方があるので、広く紹介していこうと思いました。
いまはちょっと、いろいろたてこんでいますが、年明けくらいからがんばります。

ISMSからISO/IEC 27001への移行解説

株式会社インフォセックがホームページで、「ISMSからISO/IEC 27001への移行解説」と題した連載コラムを開始したようです。

ちょっと、気になるところはありますが・・・

株式会社インフォセックが、ホームページで連載コラムを始めたようです。

「ISMSからISO/IEC 27001への移行解説」

珠に傷というところでは、ISO/IEC 27001 を ISO27001と書いてしまっている部分があるところですね。
ISO と ISO/IEC は異なるので誤記になります。
よくある説明などでは、ISO/IEC を ISO と誤記しているのをよく見かけますが、規格そのものを解説するコラムの中で ISO/IEC を ISO と書いてしまっているのは残念ですね。
そもそも、上記のコラムのタイトルそのものが、ISO 27001 と書いてあります。

その程度の軽微の気になるところがありますが、全５回のうち、まだ２回目ですが、わかりやすく書かれていると思います。
この後、詳細部分が、どの程度正確に紹介されるかに期待するところです。

ちなみに、ISO/IEC 27001 や 17799 といった情報セキュリティ関連の規格は、ISO/IEC JTC1 SC27 という委員会で決められていますが、次回の国際会議は、１１月７日からマレーシアのクアラルンプールで開催されます。
クアラルンプールに行くのは初めてなので楽しみです。

情報ネットワーク法学会第５回研究大会

情報ネットワーク法学会の第５回研究大会が開催されます。

・情報ネットワーク法学会
・第５回研究大会開催案内

上記の開催案内で内容を確認できます。

この学会の大会参加費は良心的な設定になっています。
学会員は参加無料です。
それ以外の方の参加費は、学会年会費と同額になっており、研究会に参加してみて入会することにしたら、支払った参加費はそのまま年会費に充当してくれます。（別途、入会費がかかります）

大会は年次開催となっており、首都圏と首都圏以外で交互に開催されます。
昨年が横浜だったので、今年は、名古屋ということになります。

今年は、佐藤もデジタルフォレンジックのパネルディスカッションの司会をさせていただきます。

ご興味ある方は、名古屋でお会いしましょう！

政府機関統一基準に関する意見募集

内閣官房情報セキュリティセンターが
「政府機関の情報セキュリティ対策のための統一基準」に追加すべき項目（骨子）に関する意見の募集
を開始しました。

その骨子の中で、いくつか興味深い点にふれていますが、ＢＣＰと情報セキュリティの関係も示しています。

また、この意見募集に合わせて、いくつかの追加資料が公開されました。
統一基準の解説資料もあり、既に公開されている統一基準を理解するのに役立ちます。

　　
内閣官房情報セキュリティセンターが
「政府機関の情報セキュリティ対策のための統一基準」に追加すべき項目（骨子）に関する意見の募集で、以下の文書を公開しました。
　・追加すべき項目の骨子
　・同骨子の補足説明資料

骨子では、興味深い点についてもふれており、たとえば、最近話題のＢＣＰと情報セキュリティ対策をどう関連づけるかの案も示しており参考になります。

この他統一基準に関係して公開した情報は、以下のページにまとめられています。

政府機関の情報セキュリティ対策のための統一基準

このページでは、既に公開している
　・基本方針
　・指針
　・統一基準（項目限定版）
に加えて、新たに、
　・統一基準（項目限定版）解説資料
　・政府機関統一基準とISO/IEC17799：2005等との対応について
が公開されました。

「解説資料」は、統一基準について逐条での解説を加えたものになっており、自分の会社や組織などにおける情報セキュリティ対策基準策定にあたって今回の統一基準を参考にする際にも役立てられるものと思います。

また、「ISO/IEC17799：2005等との対応について」は、統一基準の構成において、ISO/IEC17799：2005 と NIST SP800-53 との対応を表にしたもので、統一基準のみならず、ISO/IEC17799：2005 と NIST SP800-53 との関係を俯瞰するのにも役立てられるものと思います。

政府が、政府自身の対策を検討するにあたって、このように政府以外の対策にとっても有用となるような資料が同時にできあがり公開されることは大変よいことだと思います。

以前であれば、情報セキュリティの対策についての高価なコンサルティングでしか得られなかったような対策基準の雛形や解説などは、今後、多くの情報が無償か、あるいは相当安価に入手できるようになるでしょう。そのことは、Technology Adoption Lifecycle に関する Geoffrey A.Moore 氏の名著 Crossing the Chasm からも必然です。
このような雛形に相当するものだけを使って、情報セキュリティのコンサルティングと称している事業者にとっては、より付加価値のあるサービスを提供しなければならないことになるのでしょう。

フィッシング詐欺に気をつけて

ライフカードがＣＭのつづきとしてＷｅｂで公開している「フィッシング詐欺に気をつけて」というビデオはおもしろい。

ぴぴーぴぴ

ライフカードのトップページから、
「フィッシング詐欺に気をつけて」というアイコンをクリックすると見ることができます。

こういう普及啓発がいいですね。

電車男での演技も最高だった、劇団ひとり氏の独壇場です。

「フィッシング詐欺に気をつけて」 を開いたら、「ＣＭ」を見てから、「その後の川島」を見ましょう。

まず、 「ＣＭ」をクリック
ストリーミングではないのでダウンロードが終わるのをじっと待つ。（再生ウインドウの中に、小さくダウンロードの％が表示されています）
ダウンロードが終わると、勝手に再生が始まります。

「その後の川島」をクリック
「問い合わせる」のカードをクリック
ダウンロードが終わるのをじっと待つ。（今度は本編なので、ちと待ち時間長いです）

このビデオのすばらしい点は、「フィッシング詐欺に気をつけて」という注意喚起にもかかわらず、フィッシングのことについての詳細説明を一切していない点です。
フィッシングというと、とかく、技術の詳細を得意げに説明したり、うんちくを語ったりして、説明者が自己満足（陶酔ともいえる）していることが多く、おそらく、一般の人にはまったく理解されません。
このビデオくらい、すっぱり切り取ることが普及啓発という目的にはかなっていると思われます。

とはいえ、劇団ひとり氏の演技がすばらしい。何度見てもおかしい。

情報セキュリティ対策における政府機関統一基準

内閣官房の情報セキュリティ政策会議の第２回会合が開催され、その資料が公開されました。

第２回会合（平成１７年９月１５日）

その中で、資料４－３として、
「政府機関の情報セキュリティ対策のための統一基準（２００５年項目限定版）」
があります。

各府省庁ごとでの情報セキュリティ対策が講じられていますが、今回は、政府機関としての共通の拠り所を得ることで、各府省庁が相互に協力して対策強化に役立てようとするものです。
政府機関用として策定してありますが、いくつかのポイントを踏まえて手直しすれば、民間企業でも使えることになります。
これまで、ISO/IEC 17799 などを導入しようとしたときに、次の一手、すなわち、具体的な対策基準の作成に苦労されていた方々にとっては、そのたたき台として使うという方法もあると思います。

今回は項目限定版ですが、あと少しで、統一基準の全体版ができることになると思いますので、乞うご期待です。
全体版ができてから読めばよいでしょうが、限定版とはいえ既に分量が多いですから、今のうちから読み始めておくとよいかもしれません。

第２回情報セキュリティ政策会議に関する報道内容は、以下のとおり。

●ITmedia
　脱「省庁縦割りセキュリティ対策」、政府が統一基準

●INTERNET Watch
　各省庁の情報セキュリティ水準を統一へ、NISCが基準策定

●MYCOM PCWEB
　「情報セキュリティ政策会議」第2回会合--政府は何を/どのように守るべきか

●IT Pro
　「各省庁のセキュリティには大きな差，対策が急務」---情報セキュリティ政策会議

Kensington ロックの安全性

日本ではあまり話題になっていませんが・・・
デスクトップＰＣやモバイルＰＣの盗難防止によく使われている Kensington ロックケーブルですが、これの安全性は以前から疑問視されています。

特に今年になってからは、キーを破れることは当たり前として、いかに日常的な物を使って破れるかということが競われるくらいにまで、その強度の問題が指摘されています。

たとえば、トイレットペーパーの芯や名刺などの厚紙を使ったケースでは、準備を含めて３０秒くらいで破る方法が公開されています。
以下の動画ファイルで、解説付きで見ることができます。
「kensington623.wmv」をダウンロード

実際には、Kensington ロックと同じ円筒形の鍵については同じ問題があります。
オートバイのＵ字ロックなどでも使われており、そちらはボールペンのキャップを使って破れることがわかっています。

Engadget: Kryptonite Evolution 2000 U- Lock hacked by a Bic Pen

このメーカーは、この問題に真摯に対応しており、ロックの交換などをしています。

Kryptonite社の交換サービス
（ページの下の方に、日本の国旗があり日本の顧客へのサービス内容も記載してあります）

それに比べると、Kensington 社の対応はよくないようですね。

まぁ、もともと、オートバイなどの路上に放置されるものと、室内の卓上での用心のためのロックという違いもありますが、こうも簡単にはずせるとなると、ロックをしている意味はありません。

別の種類のワイヤーロックを探すというよりも、机などからＰＣが盗まれた場合にどうするかを考えることが重要なのでしょう。

もちろんディスクデータの暗号化などの機密漏えい防止について考えることも必要ですが、ちょっと、奇をてらったことも考えられそうです。

S.T.O.P.(Security Tracking of Office Property)
は、おもしろい発想です。

ＰＣなどに、強力なシールで、S.T.O.P. というシールを貼ります。
表面は、資産管理シールになっています。普段は資産管理シールとして使えます。
これをはがそうとするとシールの表面がめくれて、「これは盗品です。こちらまで連絡ください。」と書かれた下地が残るというものです。下地を無理にはがそうとすると機器を傷つけてしまいます。
これ自体は盗難防止になっていませんが、盗む人の目的が売却だとすると、売りにくいということがあるので、予防効果が若干あります。また、盗まれて売却されても、買った人からの連絡を受けれるかもしれません。
「連絡してくれたら新品を提供します」くらいまで書けば、買った人からの連絡度合いは高まりそうですね。

それを思うと、ＰＣは小奇麗に使うのをやめて、いろんなワッペンを貼ったり、少しくらいぶつけて傷をつけていたりすると盗まれにくくなるのかもしれませんね。

ぼくはスプレーで何かペイントでもしようかな。。。

検疫ネットワーク

検疫ネットワークは、これから重要なイネーブラになるだろう。
いまは、主としてモバイルＰＣの社内接続時に限定された用途が多いが、ここで検討されるイネーブリング技術はもっと広い目的でも使えるはずだと思う。

なので、製品としての検疫ネットワークソリューションとしてより、現時点では、その技術方式を理解しておくことが重要と思われる。

ZDNet の連載にある「検疫ネットワークを探る」がわかりやすく書いてあったので基礎知識としてよい。

その上で、TPM の TNC などに着目するとよい勉強になるはずだ。

内閣官房セキュアＯＳ調査研究報告

内閣官房の情報セキュリティセンターの調査研究報告として、以下のものが公開されました。
いわゆる、セキュアＯＳのことです。

電子政府におけるセキュリティに配慮したOSを活用した情報システム等に関する調査研究

http://www.bits.go.jp/inquiry/index.html

クレジットカード情報流出(2)

クレジットカード情報の漏洩を「個人情報漏洩」として扱うのは、やめた方がいいと思っています。

個人情報保護法の基本理念では、個人情報の定義の対象を、分類しないことにしていますから、名刺の住所とクレジットカード情報を明確に区別して議論することは基本理念を変えない限り現実的ではありません。

今回の事件の報道や検討では、まず、「クレジットカード情報の漏洩」と限定的に議論しないと、不毛なことになります。
物事を考えるときには、言葉はとても重要なので、今回の件では、「個人情報」という言葉を使用禁止にして、限定した視点をまず持つことが出発点でしょう。

クレジットカードのＣＶＣ情報（＊脚注）が個人情報なんてバっカみたいですよね。

「個人情報漏洩」という言葉から離れれば、今回の件についてを、「個人情報保護法」とはまず最初は距離を置いて議論しようということが明確になります。
今回の情報のようなものを、企業内のすべての情報のうち、どのように類型化して対策を講じるのかというところから議論すべきと思います。

以上は、そもそも論です。
次に、今回の事件の本質論にも少しふれておきます。

今回、カード会社は、当該業務委託先に対して、カード情報を保持するなという契約をしていたとのことですが、「守れないルールを設けるな」にみごとに抵触したといえます。
アフターサポートのことを考えれば、カード情報を一切保持しないということはありえません。
そのため、業務委託先は、ルールを違反して保持しました。
その結果、アフターサポートに必要のないＣＶＣ情報などまで流出したわけです。
ひとたび、ルールの違反が常態化すると、ルール違反の中にルールを設けることはできないため、このようなことが発生します。
カード会社は、委託先がアフターサポートをしなければならないことを考えて、「アフターサポートに必要な最小限のデータだけを保持せよ。アスターサービスに必要なデータについては、～～～という対策を講じること。」という契約をすべきだったと思います。
それを「データを一切保管するな」としたために、対策についてを言及できなくなったと言えます。
カード会社は、現在、委託先への「データを保管するな」という契約を元に、責任回避をしようとしています。百歩譲って、「その契約についての委託監督義務が不十分であった」としようとしています。
しかしながら、ぼくからすると、その契約書の内容事態が「委託監督の放棄」の証拠そのものだと思えます。
そうでないのであれば、「アフターサポートは（カード会社自らが直接実施するので）委託先側では一切必要ない。だからデータを一切保管するな。」という業務委託内容でなければなりません。

２つのことを書きましたが、、、

限定的に情報を整理して対策を議論した後に、個人情報との関係を考察するということをせずに、今回の事件を個人情報保護の射程で考えると、百害あって一利なしの議論になるのではないでしょうか・・・

今回の事件を「個人情報漏洩」と称して変なものを売りつける、自称コンサルタントが急増しているようです。
「よいコンサルタントの見極め方」で、よいコンサルタントを見抜くための質問を書いてみしたが、新たな質問が増えました。

「今回のクレジットカード情報漏洩の対策と、個人情報保護対策とはどういう関係ですか？」

この記事を参考に、質問に対する回答と比べてみてください。

＊脚注：

ＣＶＣ情報というのは、クレジットカードが番号や名義人情報など目で見てわかる情報だけから偽造されないようにするために、磁気ストライプの中に書き込むチェックのためのコードのことです。
今回は、ＣＶＣ情報まで流出したため、これらの情報を使うと、実際のクレジットカードを偽造することもできるようになり、被害が拡大しつつあるわけです。

よいコンサルタントの見極め方

よいコンサルタントを選別するのは、なかなかと難しいものです。

ただ、見極めるのに役立つ質問がありますので紹介しましょう。

情報漏洩対策の製品導入場面についてを例にとってみることにします。

その質問とは、その製品の効用だけではなく限界を聞くというものです。
すなわち、効用として、「どういうことを守れるか？」を聞いた後に、「では、どういうことについては守れない部分がありますか？」という限界を質問してみます。
「この製品ならすべてを守れます」は論外ですが、言葉に詰まるようなベンダーはあてにしない方がいいです。
限界の質問に答えられたら、次に、「では、それらの守れない部分についてはどういうことをすればいいですか？」という解決策についての質問をします。それにも、ちゃんと親身になって答えてくれるベンダーであれば信頼できると思います。 ここで重要なのは、きれいに答えられなくても、「親身になって答えようとしているか」の姿勢を見ることです。
導入実績のある製品で、それらの導入後のアフターケアもしているベンダーであれば、役立つかは別として別の事例くらいは、解決策についても答えられなければ、うさんくさいです。
販売実績はあっても、実際使われていないか、導入後のアフターケアを怠っている証拠です。
以下のような人からは、ものを買わないほうがよいでしょう。
　－製品に不十分な点があることを隠して売ろうとする
　－製品に不十分な点があること自体がわかっていない

とりあえず、情報漏洩対策の製品についてで書きましたが、同じことは、サービスについても言えますし、情報漏洩などのセキュリティ対策以外のこと、広く言えばＩＴ以外のことについても言えます。
たとえば、文書管理システムであれば、
効用についての質問は、「この製品でどんな文書管理ができますか？」ですし、限界についての質問は、「この製品ではどんなことはできそうにないですか？」となります。

さて、さっそく出入りの自称コンサルタントに、「効用と限界」の質問をしてみてください。
よいコンサルタントが見つかるとよいですね。
ただ、よいコンサルタントではなかったとしても、その人だけが悪いのではありません。
よいコンサルタントを見抜けない人、見抜けても相応の費用を払わない人には、よいコンサルタントは寄ってきません。
もしも、出入りの人が、よいコンサルタントだとしたら、それは採用している人の人徳の為せることでもあるのです。
もしも、出入りの人が、よいコンサルタントでなかったとしら・・・

クレジットカード情報流出(1)

この事件で思うこと。

クレジットカードの不正利用は、全額補償なので事後処理はされそうですね。
ただ、不正利用されたカード番号は即日無効になるため、定期的な支払い（ＩＳＰの月額とか）に登録して使用していると番号変更が大変そうです。
考えようによっては、不正利用されてから番号変更するくらいなら、いまのうちに、番号変更してしまう方が楽かもしれません。

今回の件は、最初 MasterCard の事件として報道されましたが、実際には、CardSystems Solutions Inc. という会社の問題なので、ここが処理したすべてのトランザクションに影響があるのかもしれませんが、 彼らのプレスリリースを読む限り、Visa+Master 関係を対象として発表していますね。限定して書いていることからすると、Visa+Master のシステムだけが被害にあったのかもしれません。
ただ、この内容で、そもそも、最初に Master だけが報道されたのは不思議（気の毒？）ですねｗ

で、彼らのやっていた業務を見るとクレジットカードに関係するほとんど全部ですね・・・

アメリカでオンライン・オフラインを問わずクレジットカードを使った場合は、もう漏れているかもしれませんね。
消費者としては、もはや、請求書のチェックしかありませんが、自動引き落としの日本が狙われる可能性は高いかもしれません。

いずれにせよ、カードの所有者としては、全額補償されるのでカード会社からの請求書をちゃんとチェックして届け出れば済むように思います。（ただし、先述のとおり、カード番号は即日無効となることに注意が必要ですが）

一方で、システム構築事業者として次のような題材があるかもしれません。

ぼくも総額１００万円の不正利用をされたことがありそのときに、手口を調べたのですが、不正利用者はカードの利用上限額まで引き出すために、小さな金額で少しずつ積み上げて、最後に与信エラーになったところでやめるようです。
それを機械的に効率的に実行するためには、比較的簡単にカード利用できるネットサイトを使うようです。
ネットサイトで物品を購入し、それを売却して現金に換金するということですね。
ぼくの被害の例では、実際には、オンラインの薬品販売サイトでしたが、商品コードと送付先、カード番号など注文に必要な処理を入力画面１ページから１送信で完了できるようになっていました。
お気づきのとおり、このショッピングサイトですと、１つのカード番号を使って繰り返し注文を出すプログラムを簡単に作成できます。

逆に言うと、注文までのページ遷移が簡単だと、カード情報を入手した不正利用者に狙われやすいサイトになることが懸念されます。
もちろん、ページ遷移が複雑すぎると、ユーザの利便性が低下するためそれとの兼ね合いが必要ですが、ぼくが不正利用されたサイトのように、簡単すぎると悪用されやすいと言えます。

クレジットカードの不正利用について、カード所有者は全額補償されます。カード会社は通常これらを保険で支払います。
ただし、不正利用されたショッピングサイトは、カード手数料を徴収されます。場合によっては、不正利用による支払いキャンセル手数料も徴収されることもあります。

悪用された原因が、注文画面のページ遷移が簡単であったことが原因となれば、サイト運営者は、そのシステム構築者に損害賠償を請求するかもしれません。

日本の報道は、例によって、クレジットカードが流出したこと自体とカード所有者保護だけを主として報道しているので、そこに注目しがちですが、実際にはその中間に、カードの不正利用を処理してしまう部分がある点にも注意すべきです。
次のようなサイトが狙われやすいということになります。
　注文入力画面の送信処理の繰り返しを自動化しやすい構造になっている
　１万円～１０万くらいで換金しやすい商品を扱っている

日本では、世界では非常識とされている銀行引き落とし制度により、クレジットカード請求も自動引き落としですから、日本人が、この後、不正利用に狙われる可能性は高いかもしれません。
自動引き落としが例外の欧米では換金できるような商品を詐取できる可能性が低いように思うからです。

サイト運営者としては、以下のような対策が考えられます。
　自動化されにくい注文ページ遷移を工夫する
　単位時間あたりの多量注文数を監視する

技術に詳しくないサイト運営者が上記のことを考えるのは大変なので、サイトの構築事業者が提案するのがよいかもしれませんが、火事場泥棒と思われない程度にしないとですな。

とりあえずは、自分のカードの再発行を依頼するかどうか決心しないといけません。。。

ISO/IEC 17799:2005 を 100 倍楽しむ方法

いよいよ、ISO/IEC 17799 の改訂版である 2005 年版が発売開始されましたね。
改訂作業には佐藤も参加していますが、今回の改訂ポイントを知っておくと楽しいかもしれません。

ISO/IEC 17799 の改訂版である 2005 年版は以下のＷｅｂからオンラインで購入できます。

ISO/IEC 17799:2005

情報セキュリティのお仕事している人は、必読書だと思います。

改訂作業には佐藤も参加していますが、今回の改訂ポイントのひとつは、「わかりやすい文章にしよう！」でした。
同じ文章なのに、読んだ人の解釈しだいで意味が変わってしまうのはおかしいですからね。（もちろん、内容そのものについての再検討が主たるポイントです）
以前の版を読んで、「よく理解できず、自分の英語の語学力が低いのかなぁ」と語学力の自信を喪失していた方は、改訂版を読んでください。きっと、自信を回復できるかもしれません。
逆に、以前の版で英文が抽象的なことを書いていたにもかかわらず、それをあたかも具体的なことであるかのごとくに解説していた方々は、面目がなくなることでしょう。

日本人はとかく英語コンプレックスになりがちですが、読んでもよくわからないような英文は、「そもそも英文の内容がおかしいんじゃないの？」と思うことも大切です。
英語で書いてあることは正しいはずに違いない。だから、自分の理解が異なっているのは、自分の理解に誤りがあるのだと萎縮する必要はありません。
自分の正しいと思うことについては、検証をして、それでもなお正しいと思うならば、英文がおかしいということは当然あるわけです。
以前の版がどのように改訂したかを、そんな観点で見比べてみるのも、ISO/IEC 17799:2005 の楽しみ方としておもしろいかと・・・

ということで、ISO/IEC 17799:2005 を 100 倍楽しんでいただければと思います。

公認不正検査士

公認不正検査士協会( ACFE:Association of Certified Fraud Examiner ) というのがあるんですね。

日本支部：
http://www.acfe.jp/

本部：
http://www.cfenet.com/

東京情報コンサルティング株式会社の松浦さんに教えてもらいました。

機密保持の誓約書強要

これは奥の深いテーマなので、後で考察しようということで、とりあえずメモ。

東京新聞５月１９日夕刊
機密保持の誓約書強要

というか、この件で、日弁連の個人情報保護法研修会のパネリストをすることになっているので、後でちゃんと整理しないといけませんよ＞自分。

米政府の機密保持にかかる費用は年間65億ドル

他山の石としよう！ということでメモ。

米政府の機密保持にかかる費用は年間65億ドル

IPA のセキュアＯＳ関連報告書

いわゆるセキュアＯＳ関係について IPA が公開した報告書です。

強制的アクセス制御に基づく Web サーバーに関する調査・設計（IPA）
http://www.ipa.go.jp/security/fy16/reports/mandatory_access_contol/web_server.html

電子政府システムにおけるアクセス制御要件に関する調査（IPA）
http://www.ipa.go.jp/security/fy16/reports/eGov_access_control/index.html

情報セキュリティと情報活用のバランスをふまえた企業情報管理戦略

ヒューレット・パッカードの自社事例として、「情報セキュリティと情報活用のバランスをふまえた企業情報管理戦略」と題して当社のプライベートイベントである HP World 2005 にて講演をすることになっています。

http://www.hpworld.jp/2005/

情報管理戦略の中でも、個人情報のＩＬＭについてを中心に紹介します。
今週号の AERA にて少しふれられていますが、ある条件下では、社内の誰も顧客の個人情報にアクセスしなくてもビジネスを遂行することができます。アクセスしなければ漏えいすることはありません。

AERA 2005年5月16日号

ただ、ここで紹介する内容は、ＨＰにとっては、１９９６年に計画し２００１年に完成する予定だったＩＴ戦略です。
その後、Agilent Technologies との分社や Compaq との合併などにより、当初計画から２年遅れて２００３年に一部運用を開始したものです。
１９９６年当時は、この計画のセキュリティアーキテクトとして参加し、その後分社や合併で進捗がなかったため半ば忘れていたものでしたが、いまとなっては、その運用の責任者になるとは思っていませんでした。
今回の講演のために、９６年当時に自分で作成した資料などを復習したりしています。
これらのことは国内社外でも講演しているものですので、不思議なかんじです。
約９年前に設計したアーキテクチャを、最新の対策として紹介するわけですから・・・

実際に９０年代後半には、国内日本企業にコンサルティングも実施しており、当社の当初線表どおりに２００１年に実現した日本企業もあります。
しかし、ＩＴ戦略というものは、外見からは実は見えにくいものです。
この講演内容を聞いて、どれだけの人が、このＩＴ戦略に基づいたＩＴを実装している日本企業を言い当てることができるのかが実は楽しみです。
そして、そのことがＩＴアーキテクトの重要性に気づき、関心を持ってもらえるようになればいいなと思っています。

日本のＩＴ構築の多くは、欧米企業の「外見」だけをまねているように思えて、嘆かわしいからです。
ＩＴはビジネスを向上するための方策であって、目的ではないということが当たり前のことですが、とても重要なことなのです。

内閣官房情報セキュリティーセンター

内閣官房情報セキュリティーセンターが設置されました。

http://www.kantei.go.jp/jp/tyoukanpress/press.html

関連報道

http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20050421/159860/
http://www.itmedia.co.jp/enterprise/articles/0504/21/news077.html
http://japan.cnet.com/news/sec/story/0,2000050480,20083045,00.htm
http://www.mainichi-msn.co.jp/it/solution/news/20050421org00m300109000c.html

歴史的瞬間

それは、2005/4/15 にあった。

何があったのかは、この場ではお伝えできません。。。守秘義務があるので。

この写真から推察できたあなたは、情報セキュリティに関して、かなりマニアックな人です。

公益通報者保護法

公益通報者保護法の施行が決まりましたね。

・・・トラックバックという機能を使ってみたかったので、あえて、まるちゃん日記を引用してみました。法条文などはそちらからアクセスしてください。
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2005/04/post_4.html

公益通報者保護法とは、いわゆる内部告発者を保護する法律です。

公益通報者保護が議論された頃に、とても気になったものですが、国会が別の議題であふれたりして、ずっと先送りになってしまい、個人的には残念でした。
なんで興味を示したかを書いておきます。

個人情報保護であれば、個人情報保護法に照らせば、軽微な事故は多くの企業で発生していることが推定されます。
たとえば、「名刺がみあたらない」＝「個人情報の紛失」ということなわけです。
これらのことについて、会社としては、「軽微なので相手に知らせないし公表もしない」と決めても、関係者の誰かが、「会社はそう決めたけれど、公表すべきではないか」と思えば、そのアクションを起こしやすくなります。
これは正社員に限らず、委託先や派遣、アルバイトなど広範に、その事実を知っているすべての関係者に言えることです。

企業としては、公益通報者保護法が施行された場合には、企業内の事故を隠蔽することは非常に高いリスクを負うことになるのでしょう。
いくら社員に退社後の機密保持契約を締結しても、条件を満たせば、公益通報者保護法が優先することになるわけですから、いままでのように、「会社の決定」を強いることはできなくなります。

事故発生の事後対応についての企業での整備は、この法律の施行日までに完了しなければならなくなると予想しています。

ＩＴ道徳教育

読売新聞2005/4/5朝刊によると、世田谷区にて、区立小学校１校を「情報モラル教育」の研究校に指定する。とのこと。

きっかけは、世田谷区立中学の生徒が、旧千円札を偽造したこと。

3/25 に提出された検討委員会提言には、

家庭でのパソコンや携帯電話を使うルールとマナーの徹底や、有害情報を見分ける健全な価値観を子どもたちに育てるため、親も一定程度、情報を判断し、使いこなす能力を身につける必要がある。 また、学校には、パソコンの使い方に偏った従来の情報教育を改め、コミュニケーション能力や判断力を育てるカリキュラム編成などを求めた。

とあるらしい。

「コミュニケーション能力や判断力を育てるカリキュラム」。
大人にも展開してほしい。

企業における情報セキュリティガバナンス

年度末だったから、色々出てるわけですね。
３月３１日だけですごい量だ。
http://www.meti.go.jp/press/index.html

前にちょっと気になった、これ↓も最終報告書が出ていた。

企業における情報セキュリティガバナンス

http://www.meti.go.jp/press/20050331004/20050331004.html

この報告書は、ちょっと期待と違っていた。
情報セキュリティガバナンスをどうやって確立するのかが、企業の課題だと思うのだが、こちらの報告書は、情報セキュリティガバナンスがあるとして、それをどう活用するかという観点というように思う。

うーん。