2008年10月31日金曜日

明治安田生命 更に被害拡大

更に規模が拡大したようです。
今度は、ルール見直しと書いていますが、教育の徹底&ルールの見直しは当然として、全社員のPCも含め、社内情報システムのセキュリティ診断するべきではない?

""

明治安田生命事件から情報リテラシーを考える

明治安田生命のお問合せページ」には、メール、Webでの問合せができるようになっていません。
今時、こんな話と思って、ウィキペディア「生命保険」に名前のある25社について、調べたところ、メール、Webでの問合せができるところとそうでないところは下記のようでした。
[メール、Webでの問合せができるところ]12社
アメリカンファミリー生命保険
アリコジャパン
損保ジャパンDIY生命保険
第一生命保険
アクサ生命保険
大同生命保険
富国生命保険
東京海上日動あんしん生命保険
T&Dフィナンシャル生命保険
日本興亜生命保険
あいおい生命保険
富士生命保険
[メール、Webでの問合せができないところ]13社
明治安田生命保険
日本生命保険
朝日生命保険
オリックス生命保険
マニュライフ生命保険
損保ジャパンひまわり生命保険
プルデンシャル生命保険
三井生命保険
住友生命保険
ソニー生命保険
AIGエジソン生命保険
AIGスター生命保険
三井住友海上きらめき生命保険

失礼ながら、もしかすると、情報セキュリティ以前に、情報リテラシーが低いのではないだろうか?
という気がしてしまった。
もしそうであるならば、問題を起こした担当者がWinny自体の知識すら正確ではなかった!というような落ちだったりするので、ITを使うための教育自体から新ためてすべきではないのだろうか?という気がする。

2008年10月30日木曜日

明治安田生命事件から情報セキュリティのマネジメント体制を考える

明治安田生命のWebサイトの「個人情報保護方針」の中に、「当社ではお客さまに関する情報の保護・管理強化に向け、情報管理を専門に担当する部署および「情報保護推進委員会」を設置し、全社横断的な取り組みを推進しております。」とある、「情報セキュリティポリシー」が公開はされていないので、この体制が個人情報に特化している可能性はあるとしても、マネジメント体制は構築してある!ということにはなる。
しかし、チェックする組織があるのか?また、チェックするタイミングがあるのか?は書かれていない。
十字架を背負うことにはなるが、明治安田生命くらいの大企業では、それくらい書くべきだし、それを実践していて然るべきと思う。
マネジメント体制は作ることに意味があるのではなく、その体制の元、マネジメントを実行し、トップダウンで情報セキュリティポリシーが守られなければ、なんの意味もなさないはず。
第一、明治安田生命のサイト、個人情報内部統制はあるが、こららのベースであるはずの、情報セキュリティポリシー(方針)については、どこにもないが、情報セキュリティポリシー(方針)がないのだろうか?

2008年10月29日水曜日

明治安田生命事件から情報セキュリティ教育を考える

明治安田生命企業サイトにある今回の個人情報漏洩・流出に関する「お詫び」を見て、教育はどうすべきかについて、書いてみます。
セキュリティは定められた方法で定められた手順が実践されて初めて守られるものなので、理屈ではなく、体で覚えるものです。なので、「習うより慣れろ!」です。
しかしながら、熟練ではなく、状況の変化に応じて柔軟に!という性格も併せ持つので、変更に対し、タイムリーに、これを自習できることも必要です。
そういった意味では、SNS/Blogのようなものを活用した教育システムは有効な気はするし、かつ、「足跡」をチェックして、利用促進していくための仕組み作りは当然必須となるでしょう。
「教育は繰り返すこと也」の実践がキーなんです。
さて、明治安田生命は、生命保険会社だからということで、本業ではない!と言って、実施していなかった、あるいは、これができる人が実質いなかった、のではないだろうか?
「お詫び」状を見る限りは、今後も期待していいものかどうか?と、ふと思う。

2008年10月28日火曜日

明治安田生命情報漏洩・流出事件を考える

各メディアが続々報じましたが、IT Mediaの記事「明治安田生命、顔写真付き女子大生1800人情報流出 30代男性向け“オトシ技”も」と「明治安田生命のお詫び状」から、情報種別という点で、事件の問題点について考えてみました。
お詫びで「教育」と「管理」と書かれていましたが、事件の詳細を見る限り、事件を起こした個人にも問題はあるとしても、それを許してしまった「教育」については、当然、その内容&実施方法も含めて見直しをした上で、実施するは当り前だと思う。
ここからが本題だが、「管理」といっているが、「管理」の前に、機密性に着目した情報種別の設定とその種別毎の運用に問題がないかの見直しを行い、情報取扱のルールとこれの運用を再定義するのが先という気がします。(情報セキュリティにおける文書種別
どこまでやるかは難しいかもしれないが、今回のケースのような情報は漏洩・流出しても読み出せないように暗号化するなり、最悪でもファイル読出権限のパスワード設定くらいは絶対必要だと思う。(もし、パスワード設定されていて、それをパスされているのであれば、パスワード付与基準がザルなのか、それが守られていないし、そのチェックさえしていないということになるはずなので・・・)
Winnyを含め、脆弱性を突く攻撃が進化し続けている現時点においては、シンクライアント化して、インフラを守っているから安心ということはあり得ないのだから・・・

2008年10月27日月曜日

MySQLとPostgreSQLについて

オープンソースのデータベースと言えば、MySQLとPostgreSQLですが、どちらか一つと言われたら、どちらを選びますか?
システム構築していない人には、どうでもいいことでしょうが、システム構築を担当している人は、今今使っている方に拘った回答が寄せられることになると思う。でも、その選び方で本当にいいのでしょうか?
性能・機能は、ソフトウェア自体の成長とは別に、データベースを載せるプラットフォームにも依るところもあって、現時点で優れているからと言って、未来永劫変わらないかといえば、変わるもののはずです。
そういった視野で見た場合、今のお奨めは個人的には、MySQLだと思う。
ほんの一例に過ぎないかもしれないが、Blogツールと呼ばれるものを調べれば、調べる程、MySQLはサポートしているが、PostgreSQLをサポートしていないツールの多さにビックリしてしまった。(気付くの遅いかもしれませんが・・・)
数年前くらいから、日本でのレンタルサーバの主流は、MySQLには既になってきているのは知っていたが、ツールまでも・・・という感じ否めないです。
既にあるPostgreSQLのシステムを作り変える必要性はないにしても、MySQLでも対応できる柔軟性を身に付けるは必要かなとつくづく思う。

情報セキュリティ運営委員会の役割と責務(0)

最低限として、下記7項目となります。
(1)情報セキュリティマネジメントの企画及び計画
(2)「情報セキュリティポリシー」の流布責任
(3)社内教育の実施
(4)「情報セキュリティポリシー」の遵守状況の評価及び改訂
(5)監査結果の評価及び改訂
(6)代表取締役への報告
(7)「情報セキュリティポリシー」違反者への処罰
詳細は、次から書いていきます。

2008年10月24日金曜日

情報セキュリティのマネジメント体制

マネジメントをする上、最低限必要になるのは、維持運営を行うための組織(仮に「情報セキュリティ運営委員会」と呼びます。)とこれが機能しているかどうかをチェックする組織(仮の「情報セキュリティ監査委員会」と呼びます。)ですよネ?(組織じゃなくて、個人という企業もあるとは思いますが・・・)
常識的な話ですいませんが、この各委員会のトップは、経営メンバとするべきで、かつ、監査委員会のトップは、運営委員会のトップに「物申す」という人にすべきです。
実際のところ、情報セキュリティの見識がないので、無理だよと諦めず、寝る間も惜しまず、勉強していただきたいものです。
何故ならば、会社を本当に愛しているのは、経営に関わっている人なのですから・・・

2008年10月23日木曜日

情報セキュリティの用語定義

ISO/IEC 17799、JIS Q 15001等、ポリシーの関係規格を中心に、下記3つくらいは用語統一したいものです。最近になって、SAPがSaaSサービスを始めるのにあたり、SAP語で悩んでいるような状態を作らないといったことは以外と重要です。
(1)情報セキュリティ(ISO/IEC 17799から抜粋)
情報の機密性、完全性及び利用の可能性の維持。
機密性は、情報にアクセスすることが認可された者だけがアクセスできることを確実にすること、と定義する。
完全性は、情報及び処理方法の正確さ及び完全である状態を安全防護すること、と定義する。
利用の可能性は、認可されたユーザが、必要時に、情報及び関連財産にアクセスできることを確実にすること、と定義する。
(2)リスクアセスメント(ISO/IEC17799から抜粋)
情報及び情報処理施設/設備に対する脅威、それらへの影響及びバルネラビリティ並びにそれらがおこる可能性の評価。
(3)リスクマネジメント(ISO/IEC17799から抜粋)
許容コストにより、情報システムに影響を及ぼす可能性があるセキュリティリスクを明確にし、制御し、最小限に抑制するか、又は除去するプロセス。
その他としては、「脅威」、「脆弱性」等については、用語レベルだけではなく、「脅威」、「脆弱性」等の内容やレベルについても定義しておいた方が懸命でしょう。

2008年10月22日水曜日

スパイウェア独自評価結果

Webrootが、バックアップ機能を統合したセキュリティ対策製品を発表という記事を見て、ちょっとネタが古いですが、2007年11月時点で、無償版のアンチスパイウェアでどこまでできるかを実験し、それを独自評価したものを掲載しますので、参考にしてください。評価ツールは、Spyware Warriorサイトの情報をベースに、独自判断で抽出しました。
(1)Ad-aware (Lavasoft)
(2)Spy Sweeper (Webroot)
(3)Spyware Doctor (PC Tools)
(4)Windows Defender (Microsoft)
(5)Spybot Search & Destroy (SaferNetworking)
(6)AVG Anti-Spyware (ewido/Grisoft)
(7)SUPERAntiSpyware (SUPERAdBlocker)
なお、Ad-aware、Spybotは実験環境においては効力を発揮しなかったので、予め一覧から除いてあります。(無償版だからかもしれませんが・・・)

2008年10月21日火曜日

情報セキュリティポリシーの公開

情報セキュリティポリシーは社外秘文書とすべきという取り決めをしていることが多いと思います。
特に、規定類(ルール)、実施要領(スタンダード)はその必要性は高いと思われますが、方針(ポリシー)自体は、企業コンプライアンスの取組を対外的にアナウンスし、企業としての透明化を主張するための重要な施策になると思われるので、オフィシャルサイト等で積極的に開示していくことをお奨めしたいです。

2008年10月20日月曜日

情報セキュリティにおける文書種別

ところで、情報セキュリティ上で、文書化を行う時にどのようなランク付けがあるのかについて、今日は書いておきます。
情報の取扱レベルの観点と情報セキュリティの観点で整理できます。
情報の取扱レベルの観点では、最低限で分類すると、「重要」、「一般」に分けることができ、情報セキュリティの観点では、その機密性により、最低限、下記のように分けられます。
(1)厳秘or極秘
(2)秘密
(3)社外秘
(4)公開
(1)、(2)と(3)の差は、人を限定するかどうかによって分別され、(1)と(2)の差は、配布先をリストで管理する!とか配布後に情報の回収を行うかどうかによって、分別します。

2008年10月17日金曜日

情報セキュリティポリシーに関連する規格、法規

方針、規程類の文書化で参考とすべきものは、だいたい下記のものになります。
[国際規格]
・ISO/IEC 17799 情報セキュリティマネジメント実施基準(ISMS)
・ISO/IEC TR 13335 情報セキュリティマネジメントガイドライン
[国内規格]
・JIS Q 15001 個人情報保護
[国内法規]
・刑法
・不正アクセス行為の禁止等に関する法律
・建築基準法/同施行令
・消防法/同施行令/同施行規則
・不正競争防止法
・著作権法

ベストは全てを読み倒すではありますが、規格とか法規は標準的にすべきこと、すべきでないことについて、書かれているものばかりなので、機密を守るためにはどうするかで文書化したものの正当性に活用するが、使い方としては適正と思います。
でも、買い揃える必要性は有です。

2008年10月16日木曜日

情報セキュリティポリシーの構成

当然のようにピラミッド構成で、上位から方針(ポリシー)、規程類(ルール)、実施要領(スタンダード)の順に文書化されたものを文書体系としてまとめます。
実施要領=スタンダード?という疑問を持つ方は多いでしょうが、ここは多分会社の構造により、呼び方は確かに変えたほうがいいのかもしれません。
実際のところ、同じ会社でも事業が多角化している場合には、全社統一の実施要領ができないから、これに近いものを作業標準等ということが多いからです。
中小企業とか単一事業の会社では多分、実施要領の方がなじみ易い気はします。

【おまけ】Adobeがクリックジャッキング対策完了
AdobeがFlash PlayerをVersion10にメジャーバージョンアップして、対策完了したことがITMediaでアナウンスされました。
ITMediaのニュースサイト
Adobeダウンロードページ
皆さん、ダウンロードして危険を回避しましょう。

2008年10月15日水曜日

情報セキュリティ適用者

当然、役員、社員、同じ職場で働く協働者は当然のことながら、アウトソースしている第3者も含めるのはいうまでもないことと思うが、その第3者を契約で縛っているとしても実際のところ、問題となりえる状況がないかの調査は重要です。
確かに受託した側からすると、企業としての体力差から同じような措置なんか取れないヨ!という可能性はあり、請託側も仕組みや仕掛けだけに着目し、アウトソースできない!なんてことになりませんか?
しかし、本当に大事なのは、情報自体の機密性に着目し、日々これを保護する意識の方が重要なはずで、仕掛けや仕組みに頼ることなく、運用でも十分なセキュリティは保てるルール作りを一緒に作れるとは思う。

2008年10月14日火曜日

情報セキュリティポリシーの適用範囲

言うまでもないことですが、情報資産に関連する人的・物理的・環境的リソースとなります。
でも、業務毎、システム毎に当然、関係するものが異なるのは当り前ではあり、全業務の洗い出しがまず最初と思い込んでいると先に倒れないでしょう。
でも、SOX法対応しないといけない企業であれば、既にわかってはいることのはず?ではあり、問題となるのは、それ以外の中小企業かもしれません。
しかし、中小企業であれば、管理面を除けば、常日頃回している業務はわかっているはずなので、それを洗い出す時間さえあげれば、できることのような気はします。
ここでも、重要なのはやはり、企業Topの働きかけということにはなりますが・・・

2008年10月10日金曜日

[必読]クリックジャッキング対策

アドビがFlashPlayerの対策を10月中に出すと発表し、当面は、「カメラとマイクへのアクセス」を防ぐ策で対応することを推奨している。詳細はITproのページを参照されたし!
また、日本だとZDNet(大元は海外CNET、詳細はタイトルをクリックされたし!)で、やはり、当面の予防策としてのNoScriptのことが報じられています。
対象ブラウザがFirefoxのみの話ではありますが、タブブラウザとしての使い心地もいいし、プライバシー情報の消去をブラウザを閉じる時に指定できたりするので、この際、ieユーザは乗り換えてもいいのではと思うのですが・・・(MSさん、ごめんなさい)

2008年10月3日金曜日

情報セキュリティポリシー

今日からちょっと情報セキュリティについて、書いていくことにします。
まず、情報セキュリティポリシーについてですが、大事なのは作ることではなく、それが守られる仕組みを作り、そして、実践・改善できるようにすることです。
企業の規模毎に体力が異なるのだから、できること/できないことを明確にはすべきであり、できないことについては、将来的な改善計画があって然るべきというスタンスに立てば、改善のサイクルは守れるはずです。と言っても、それができないのが人間だったりします。
では、どうすればいいのでしょうか?
実は答えは簡単で、トップが常にこれをケアすれば言いわけで、企業のトップこそセキュリティ意識を高く持ち、これを浸透させるという以外に手はないでしょう。
でも、コストの問題で対策が打てない!ということが最近では散見されるようですが、それが事実だとしても、企業のセキュリティ担当者任せではなく、一緒に考えるくらいの気持ちがなくては、と思います。
ポリシーとはもともとそういうもののはずなので・・・