本物の情報を利用した嘘

IT Proの記事によると、「2017年9月19日」にDNSが使えなくなるかもしれないらしい。

決して確実ではないが、DNSSECに用いる鍵の更新の影響で、そういうことが起こり得るんだそうだ。

 

 

こういうニュースが実在することで、攻撃の手口として利用されてしまうのではないか?と懸念している。

例えば以下のような攻撃シナリオだ。

 

続きを読む

続・ランサムウェア再び

前回の記事で、Petya亜種に関するサイトをいくつか紹介しましたが、その最後の「CNET Japan」にはセキュリティパッチ適用以外の予防方法が載っています。

(本来は、セキュリティパッチ適用がベストな予防方法です。)

 

続きを読む

人はなぜ騙されるのか。

ここ数日のIT系ニュースは、ランサムウェアの話題で持ち切りです。

多くのニュースは、最後に「対策」を書いて締めくっているのですが、その内容はどれも似たり寄ったりで、「OSに最新のセキュリティパッチを当てましょう。」や「怪しいメールの添付ファイルは開かないようにしましょう。」といった、常識的なものばかりです。

 

続きを読む

サイバー犯罪の現場

タイトルの「現場」は「げんじょう」と読んでください。

警察や消防では、「げんば」とは読まずに「げんじょう」と読むそうです。

 

警察は基本的に都道府県単位の組織であり、各組織の中に「サイバー犯罪担当部署」が置かれています。

 

続きを読む

CCCの対応がちょっと残念だった件<前編>

CCCというのは、カレー屋さんでもなければ缶コーヒーでもありません。
ちょっと聞きなれないかと思いますが、レンタルビデオで有名な「TSUTAYA」を運営している会社です。
正式には「カルチュア・コンビニエンス・クラブ株式会社」といいます。

TSUTAYAの会員になると発行される “Tカード” は、コンビニなど多くの提携企業でも使えます。
意外なところで会計時に「Tカードをお持ちでしょうか?」と聞かれ、
「こんなところでも使えるんだなぁ」と驚いたことのある方も多いと思います。
本日は、あのTカードの個人情報の管理についてのお話です。

5月4日、佐賀県武雄市樋渡啓祐市長が、市立図書館の利用者管理に
Tカードを全面導入する計画を発表して話題になりました。
まだ”提携基本合意”という段階なので、具体的にどういう形で運営されるのかは未知数なのですが、
市長の記者会見を報じるネット上のニュースにおいて、少々気になるところがありました。

利用者の個人情報の扱いについて、市長が
「何を借りたかっていうのは、なんでこれが個人情報だ!って思ってる」
と発言したそうです。

市長の構想としては、貸し出し履歴のデータを元に、
amazonのような「リコメンド」をしたいそうです。
「もちろん市民の同意の上」とも言っていますが。

この発言に対し、「貸出履歴が個人情報じゃないわけないだろ!」というツッコミが
ネット上で散見されました。これはまあ、フツーの反応だと思います。

これに対し市長は、5月6日の自身のブログに反論を掲載しました。
曰く、
「具体的に言うと、「樋渡啓祐が「深夜特急」「下町ロケット」「善の研究」を5月6日に借りた。」
この情報が外部に出るとこれは個人情報の関係法令の適用に当たる、これは当然。
僕が言っているのは、「5月6日20時40分、42歳の市内在住の男性が、
「深夜特急」「下町ロケット」「善の研究」」を借りた。」ということそのものについては、
個人が特定できないし、仮にこれが外部に出ても法令に照らし、全く問題がない、これが僕の見解」
とのことです。

たしかに、個人情報保護法における個人情報の定義は「特定の個人を識別することができるもの」です。
なので、個人が容易に特定できないよう加工されたデータは、個人情報ではありません。

どうやら市長が言いたかったのは、人間視点からの「誰が何を借りたか」という情報ではなく、
本の視点からの「この本はどれぐらい借りられているか、どんな本と一緒に借りられているか」
という情報だったようです。
あの言い方(上述)では誤解されても仕方が無いと思いますが。

ですがTカードを利用する以上は、個人を特定できる情報、つまり
「樋渡啓祐が「深夜特急」「下町ロケット」「善の研究」を5月6日に借りた。」という情報は
図書館だけでなくCCCにも共有されます。
少なくとも、「樋渡啓祐が本を3冊借りた」という情報はCCCにも共有されるはずです。
でないとポイントの管理が出来ませんからね。
(厳密に言いますと、ポイントの管理をしているのはCCCの100%子会社である株式会社Tポイントです。)
あるいはもしかしたら、その手のデータは全てCCC側で集中管理していて、
図書館など提携企業側で自前のデータベースを持つことは無いのかもしれません。

まだ構想段階なので、どのような情報がどういう範囲で共有され、何に利用されるのかは
具体的にはほとんど決まっていませんが、慎重に取り組んでいただきたいと思います。

さて・・・

図書館の話はまだ先のことだとしても、Tカードはすでに多くの企業と提携しています。
私もTカードを持っているのですが、このニュースについて調べているうちに、
私の各種利用履歴がどのように扱われているのか、だんだん気になって来ました。

私がコンビニでシュークリームを買ったのが今日の何時何分なのか、
そんな情報がもし全提携企業間で共有されていたら、さすがにちょっと嫌ですから。
なにしろ4社や5社どころではないので。
そこで、CCCの問い合わせ窓口に直接聞いてみることにしました。
(問い合わせフォームはこちら

つづく

パーソナルファイアウォール

自宅のPCには、フリーのセキュリティソフト「COMODOインターネットセキュリティ」を入れています。
これはアンチウイルス機能よりも、もっぱらパーソナルファイアウォールの機能が良いことが評判です。
かなり細い設定でフィルタリングしたり、通信ログを取ることができます。
この自宅のPCは、アイオーデータのブロードバンドルーターにある
ダイナミックDNS」機能を使い、外からのリモートデスクトップを許可しています。
(必要無い時は繋がらないようにしていますが。)
先日、久しぶりにリモートデスクトップ接続の着信ログを見てみたところ、
身に覚えのない着信が結構ありました。
接続までは許可していないので侵入はされていないはずですが、
油断できないものです。
発信元のIPアドレスをいくつかブラウザに入力してみると・・・
中国語のサイトが現れました。
まあ、そういうことなんでしょうね。

セキュリティを上げないISMS導入は可能か。【検証①】

前々回、2009年11月14日投稿の 「セキュリティを上げないISMS導入は可能か。【着想】」 に
鋭いコメントをいただきましたので、その視点で検証をしてみたいと思います。
※この「セキュリティを上げないISMS~」シリーズは、
 「楽に認証を受けること」を主題としたものではありません。
 セキュリティのレベルを上げることだけを考えて
 現場の業務において無駄な苦労を産んでしまうことを避けることが主題です。
【教育】
QMSについても言えることですが、「必要な力量」を決定するって、結構難しいことですね。
おそらく、「どの程度まで具体的に定めればよいのか?」と頭を抱えている企業も多いことでしょう。
が、それはまた別の機会に論じたいと思います。
ただ、「組織全体での教育」という活動自体、
品質はともかくセキュリティについて、ISMS導入前にすでにやっている企業は少ないと思います。
たとえ現場の可用性を重視し、(導入前より)ルールを厳しくしないISMSであっても、
情報資産の棚卸同様、イチから始めなくてはいけない活動です。
マネジメントする側にとっては「新たな負担」です。
ですが、「必要な力量」を、現場の実情から乖離しないように設定すれば、
「必要な力量が持てるように施す訓練」も過剰にならないでしょうから、
現場への負担を最小限に抑えることが出来ます。
【内部監査・マネジメントレビュー】
どちらかというと現場ではなく「マネジメントする側」の問題なので、
前々回は特に取り上げませんでした。
ただ、内部監査は嫌が応にも現場が関わることになりますので、
それを最小限に抑える手法を考えてみます。
規格は、内部監査で現場を監査することを要求してはいません。
そこで、内部監査の主たる対象を、現場ではなく現場の管理職に絞ってみてはどうでしょう。
マネジメントシステムは文字通り、マネジメントのためのシステムなのですから、
現場をちゃんとマネジメントしているか、出来ているか、それで成果が上がっているかは、
現場をマネジメントしている管理職を対象に監査するのが筋のはずです。
現場を対象に内部監査を実施し、現場がルールを守っているかを監査する企業もあるようですが、
(それがいけないとは言いませんが、)
本来それは現場の管理職が日常的にやっていなければいけないことですので、
内部監査でやらなくてもいいはずです。
もっとも、全く現場を見ない内部監査と言うのもどうかと思うので、
現場の管理職への監査を補足する形で、少しだけ現場に協力していただく必要はあります。
早い話が、審査機関による認証審査、定期審査と同じスタイルを採用するということです。
<次回予告>
 【133の管理策】 【管理策の有効性の測定】 を扱います。

セキュリティを上げないISMS導入は可能か。【補足】

前回記事の補足です。まずはこちらからご覧ください。
もともと、セキュリティに「絶対」なんて無いんです。
どこまで厳重なセキュリティ体制を布くかは、相対的な問題でしかありません。
ISMSが求めているのは、「今より厳しく、もっと厳しく、さらに厳しく」ではありません。
そんなこと、要求事項のどこにも書いてありません。
それどころか、「可用性の喪失も考慮しなきゃ駄目よ。」と明記されています。
すでに厳しすぎるISMSを構築してしまった企業においても、
現場からの「やりにくくなった」という声を反映し、大幅にルールを緩和することは可能のはずです。
審査員から何か言われたら、
「これまでは可用性を軽視し過ぎていた。だからそこを改善した。これがISMSの継続的改善だ。」
と主張してみてはいかがでしょうか。
審査員によっては、
こんなにセキュリティの甘い受審企業は初めて見た。」みたいな文句を付けてくるかもしれません。
その場合は、規格を盾に抵抗しましょう。
審査員だって人間ですから、多少の思い込みはあります。
でも、審査は規格に基づいて行われなくてはいけません。
「審査員様がこうおっしゃっている!仰せの通りにしなくては!」
みたいに受け止める必要は、皆無です。
(事務局が自社の現場も規格の意図もよく理解していと、往々にしてそうなります。
特に、事務局が総務事務部門の片手間として運営されている場合は、陥りやすいと思います。)
管理責任者も事務局も、会社からお給料をもらっているんであって、
審査機関のために働いているのではありませんからね。
そもそも、「ISMS認証を取得するか否か」という判断だって、
企業にとっては経営上の選択肢でしかありません。
審査員の顔色をうかがうことはせず、自社のための仕事をしようじゃないですか!
(ちょっとストレス発散)

セキュリティを上げないISMS導入は可能か。【着想】

ISMSは、ある意味QMSより大変だと思います。 おなじISO規格なのに。
比較的早い段階で、「情報資産の棚卸」という大仕事があるからです。
大雑把にグルーピングすれば楽なのでしょうが、
あまり安易にそっちに走っちゃうと、無意味な活動になります。
情報資産の種類も絶対量も多い大企業では、本当に大変だと思います。
業態がシンプルであれば、量は多くても種類は少ないのかもしれませんが・・・
なんとか棚卸と評価を終え、そこに「これでセキュリティは万全だ!」というような
練りに練ったルールを適用しても、まだまだ苦労は絶えません。
「仕事がやりにくくなった!」という現場の声です。
これは精神的にきますね。
これがある意味最大の難所かも・・・  それに、ISMSを続ける限り終わることがありません。
そこでちょっと考えてみました。
現場の可用性を重視し、たいしてセキュリティが向上しなくても、
ISMSの認証を受けることは可能か?と。
つまり、ISMSを導入したからと言って、導入前の現場の実態を何も変えないのです。
「これは施錠管理しなさい」、「パスワードは×文字以上に変えなさい」みたいなことを、一切言わないのです。
ISO27001の4.2.1の、c)~g)において、リスクの評価も管理策の適用も、
基本的に「今やっていることを許容」するようにします。
そのように基準を設けても、やはり基準を超えるものはポロポロ出てくるでしょう。
それらは全部、残留リスクとして経営者が承認します。
そうすれば、現場はほとんどISMSの導入を意識することは無くなります。
最初の段階で情報資産の棚卸に協力しなくてはいけないぐらいで、
あとはほぼ関係ありません。
そんなISMSでは、セキュリティのレベルは全く向上しません。
その点は批判があるかもしれません。
しかし、確実に向上したと堂々と主張出来るものが、一つだけあります。
それは「マネジメントのレベル」です。
情報資産の棚卸や、何らかの基準による評価が行われていなかった頃は、
どこにどんなリスクがあるかも分からなかったはずです。
それが明らかになったということは、マネジメント上の大きな進歩のはずです。
(それらのリスクに「どう対処するか」は、別の問題です。)
今すぐに対処出来なくとも、「さすがにこれは、いずれはどげんかせんといかん。」
というモノも見えてくるはずです。
また、基準がが無かった頃は、部署ごとに(というか上司ごとに)
バラバラの指導が行われていたはずです。
ISMS導入により、それを統一することが出来ます。
そのため、厳密に言えば、現場の部署によっては
「今までより厳しくなった」とか、逆に「今までより甘くなった」という声が上がると思われます。
そのことへの不満は避けようがありませんが、
ダブルスタンダード状態が解消されたことを以って良しとしましょう。
現場の運用は何も変わらずとも、組織にとってはそのようなメリットがあるはずです。
それがISMSの本質であり、そこさえクリアしていれば認証は受けられるのではないか?
と、最近考えるようになりました。
はたして本当に可能かどうか、今後も検証していきます。