日本IBM委託先から神奈川県の生徒情報流出について考える(3)

記事内の「今年6月にPCがウイルスに感染し、ファイル交換ソフトウエアの「Winny」から情報を流出させる状態」と「日本IBMは今年9月に問題を把握し、Winnyネットワークの24時間監視を開始」という記事がありますが、この3ヶ月のギャップは何なのでしょうか？
6月時点で知りえたのであれば、6月から開始してもいいような気はするので、もしかして、この3ヶ月の間、事実を掴んでいなかった、あるいは、確証が取れたのが9月だったのいずれかな？と想像してしまう。
Winnyで情報漏洩した場合には、その流れを食い止めること自体、現状では無茶な話のはずなので、漏洩、流出を前提とした善後策を取るべきなのに・・・と思う。
被害に遭われた人には、誠に申し訳ないことを言っていますが、起きたことは変えられないのだから、被害を極小に抑えるために、早急な対処という意識は欲しいものです。

日本IBM委託先から神奈川県の生徒情報流出について考える(2)

記事内の「（1）PCにWinnyをインストール、（2）開発完了後も約11万人分の個人情報データを保持、の主に2点で日本IBMとの取り決めに反していた。」の中の「(2)の開発完了後も」というフレーズ、妙に思えませんか？
どんなシステムかはわからないので、判断難しいですが、開発中は全てのデータを取得でき得る状態にあったということになる。
古典的なシステム開発であれば、実データで試験するのは、お客様も含めた、運用試験とか総合試験というものを行う時だけのはず！
システム開発の進め方にも問題あった！ということを暴露しているような気がしてならないが、そう思うのは、私だけなのだろうか？

日本IBM委託先から神奈川県の生徒情報流出について考える(1)

日経ITProに出ていた記事「日本IBM委託先から神奈川県の生徒情報流出、Winnyで最大11万件の可能性」について、いくつもの問題があるので、一つづつコメントして行こうと思います。
まず今日は、「ITベンダーの社員。今年6月にPCがウイルスに感染し、ファイル交換ソフトウエアの「Winny」から情報を流出させる状態」の部分についてですが、
そもそも、ITベンダーの社員が、Winny感染ウィルスのこと知らない？というのは如何なものだろうと思う。
アンティニー(ANTINNY)等のWinny感染ウィルスは、2003年に登場し、下記のようなサイトで情報公開もされているのに・・・とも思う。
「内閣官房情報セキュリティセンタ」
「総務省」
「トレンドマイクロ」
「マイクロソフト」
確かにITという業種も幅広い知識を要求されるので、全て飲み込めないヨ～と言い訳されそうではありますが、Winnyの問題が指摘されたのはいつの話なんでしょうかネ。
同じ業界人として、お恥ずかしい限りです。

Flash、スクリプト等の攻撃から身を守る！

@ITに出ていた記事です。
"

「WPA突破」よりも重要なセキュリティ問題とは？ − ＠IT via kwout

"
攻撃者のターゲットはサーバからクライアントPCに移っていることが象徴的に書かれています。
面倒くさがらずに、かつ、インフラをあてにせず、これからは自ら、スパイウェア対策や情報の暗号化、情報の秘匿等に留意すべきと思います。如何でしょうか？

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

「(3)社内教育の実施」についてですが、当然、継続的、かつ、計画的に実施できることはもとより、単純に技術を中心とした話だけではなく、意識付けに重みをおくべきです。
繰り返しになってしまいますが、セキュリティは誰かに守ってもらうのではなく、自ら守ることを意識しない限りは守れません。
そういった意味では、情報の差別化をどのようにしていくか？また、その差別化されたことにより、どんな手法で守るのかを徹底していない限りは、当然、何をどのようにが徹底しないので・・・

メールのセキュリティは確保可能なのか？

インターネットメールがどのように運ばれているかご存知でしょうか？
バケツリレーでほぼ裸のままで、メールサーバ間を渡り歩いて、送られています。
つまり、メールサーバまでSSLで暗号化しているから安心です！なんてことはいえないのです。
どうしてもということであれば、PGP等の暗号化メールという手段がありますが、これはメーラに組み込むというツールであることから、ちょっと前までは、メーラの動きが重くなるという理由で敬遠されていました。
今今のPCだとメーラの動きというのは解消できる可能性はあるとしても、メールの送信先に聞きまわらないと使えるかどうか不明なので、なかなか浸透はしないような気がします。
後ろ向きな考えかもしれないですが、やはり、メールはセキュリティが確保できないものと思い、送る情報自体を暗号化するなりの方が現実的とは思う。
でも、メーラを使わず、特定のWebメールのASPサービス（例えばGmail等）をSSLで利用する、ができるのであれば、PGP等の暗号化メールはいらないのですが・・・

迷惑メールについて考える

情報セキュリティの話からちょっと脱線しますが、Yahoo!BBが広大な計画で進めている「OP25B(Wikipediaの解説)」の対策を先頃、東京地区でも行いました。
回線はYahoo!BBなのですが、メールサービスのプロバイダがDreamnetだったので、サブミッションポートへの設定変更だけでなく、SMTPメールサーバの変更も必要であることになかなか気付かず、若干てこずりました。
Yahoo!BBの対応が最終的には１２月８日終わる予定ではあり、これでだいぶ迷惑メールは当分減ることが期待できるかな？とは思いたいのですが、迷惑メールの量は、各ISPさんの頑張りもあって、徐々に減ってきていたような気はするし、その内容も、宣伝ばかりになってきているので、フリーメールではあれ、送信元が実は正規アカウントであるという可能性もあり、今以上に減らないかもしれないとは思う。
逆に「OP25B」対策により、人様の正規アカウントを乗っ取り、迷惑メールを送る輩が出てくるのでは？という心配をしています。

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

「(2)「情報セキュリティポリシー」の流布責任」についてですが、
「情報セキュリティポリシー」の策定、改訂に伴い、全ての対象者(従業員)に配布する責任があるということですが、そこに書かれている内容を従業員のその属性で、役員・社員と協働者が同じでいいかや、迅速に末端まで届けるために如何なる方法、紙なのか電子的になのか、機密性を保つべきかどうかといったことを考えるということがすべきことなので、論理的には大した内容ではありません。
企業の大きさにもだいぶ左右されますが、あくまで、このイベントは始まりであって、ポリシーに基づく、規程類、実施要領に対する策定、改訂とかの方が、重い作業となるでしょう。
ところで、ポリシーがそんなに変わるか？という話ですが、どくまで、ポリシーに記述するかにもよりますが、時代に左右される要素は少ないはずであり、業務と密着し、時代の変化も考慮しない規程類(ルール)と比較すれば、確率的にも変動は少ないはずです。そもそも方向性について書くものなので、そう変更がないようにすべきとも言えます。一方、規程類(ルール)は、「ルールは破られるためにある！」とも言うように、革新していくのであれば、変更は大歓迎とすべき気はします。

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

リスクマネジメントのアウトソースについて、ちょっと調べてみましたが、私の調べた限りでは、見つけられませんでした。
一時的にコンサルするとか、情報を提供しているので見てくださいサイトは多数ありますが、世の中の動きをWatchし、リスク判断します！というようなものはありませんネ。
確かに業務内容により、リスクチェックの基準は異なるだろうが、使っている道具さえわかれば、脆弱性やその影響範囲はわからないことではないはずなので、そういったサービスあってもいいような気はするのだが、やはり、インフラで防御しているはずだから、インターネット上の脅威は無視しても大丈夫だと！という風潮なのだろうか？
SQLインジェクション、クリックジャッキング、スパイウェア、トロイの木馬等といったWebブラウザをターゲットとした攻撃をインフラで守りきれるかどうかという気が最近しているので、日本企業大丈夫？と思うのは私だけ？
それとも、企業内で頑張ってくれているということで解決していいのだろうか？

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

「(1)情報セキュリティマネジメントの企画及び計画」についてですが、この中には、情報セキュリティマネジメントの企画、計画とこれの実施が含まれます。その内容としては、
(1)リスクアセスメント
(2)リスクマネジメント
(3)「情報セキュリティポリシー」の見直し
(4)従業員への普及・啓発
があり、この中でこれからも、多分一番重い業務は間違いなく、リスクマネジメントだと思います。
特に攻撃の主流が、サーバではなく、クライアントPCであり、かつ、メーラやOSではなく、Webブラウザを利用した攻撃が多くなってきているからです。
リスクアセスメントしている間もなく、次から次へと公開される脆弱性に関する洗い出しが本来は必要ではありますが、なかなか手が届かないということにはなる可能性は高くなるので、誰がどのようにチェックするかを慎重に考えないといけないと思います。
でも、セキュリティの造詣のある人でないと、チェックにすらならない可能性を考えると外部ソースの活用が本当は有効な解決策かもしれません。