アカウント名:
パスワード:
お客様からは、「サウンドハウスの個人情報管理が甘かったのではないか」という管理責任を問う声を頂きました。(略)それに対して弊社の率直な答えは、通常、企業が取るべき対策は取っており、完璧ではないが、落ち度があったと言われるレベルでもない、ということです。(略) 弊社のWEBサイトは全て自社開発をしており、セキュリティ面に関しましては、24時間体制のシステム管理者が、外部のアドバイス、指導を受けて構築してきております。そのシステムのセキュリティ対策として、早くからファイアーウォールを構築、2005年1月には「WEBサイトの安全性を証明」、「世界標準」という謳い文句で広告されているハッカーセーフを導入しました。 その後、2006年7月には、カード会社側からの提案で、「導入すると、万が一不正使用があっても明確な責任区分ができ、その場合もカード会社が責任を取るので弊社にとってメリットとなる」というお話から、3Dセキュアも取り入れました。この3Dセキュアの導入により、弊社の認識としては、セキュリティ対策は十分に行っているという安心感が社内に漂ってしまったようです。 (略)その内、世間ではハッキング事件が急増し、特に2005年以降は、SQLインジェクションによる被害も多々レポートされているにも関わらず、それらの情報を十分に得て、様々な他社の教訓から学ぶことがないまま、今回の事件に遭遇してしまいました。しかしこれは単に、一企業のみの責任ではなく、クレジットカードの被害状況を日々、把握、データ化しているにも関わらず、アラートを出して具体的な対策を示さないクレジットカード会社や、これらの被害情報をもっとタイムリーに収集して、世間に大々的に告知する為に能動的に動かない行政にも責任があるものと考えます。
お客様からは、「サウンドハウスの個人情報管理が甘かったのではないか」という管理責任を問う声を頂きました。(略)それに対して弊社の率直な答えは、通常、企業が取るべき対策は取っており、完璧ではないが、落ち度があったと言われるレベルでもない、ということです。(略)
弊社のWEBサイトは全て自社開発をしており、セキュリティ面に関しましては、24時間体制のシステム管理者が、外部のアドバイス、指導を受けて構築してきております。そのシステムのセキュリティ対策として、早くからファイアーウォールを構築、2005年1月には「WEBサイトの安全性を証明」、「世界標準」という謳い文句で広告されているハッカーセーフを導入しました。
その後、2006年7月には、カード会社側からの提案で、「導入すると、万が一不正使用があっても明確な責任区分ができ、その場合もカード会社が責任を取るので弊社にとってメリットとなる」というお話から、3Dセキュアも取り入れました。この3Dセキュアの導入により、弊社の認識としては、セキュリティ対策は十分に行っているという安心感が社内に漂ってしまったようです。
(略)その内、世間ではハッキング事件が急増し、特に2005年以降は、SQLインジェクションによる被害も多々レポートされているにも関わらず、それらの情報を十分に得て、様々な他社の教訓から学ぶことがないまま、今回の事件に遭遇してしまいました。しかしこれは単に、一企業のみの責任ではなく、クレジットカードの被害状況を日々、把握、データ化しているにも関わらず、アラートを出して具体的な対策を示さないクレジットカード会社や、これらの被害情報をもっとタイムリーに収集して、世間に大々的に告知する為に能動的に動かない行政にも責任があるものと考えます。
独自開発なのに2008年の時点でSQLインジェクションを知らなかったなんて……。しかも知らなかったのは行政のせいだなんて……。
これを読んで、この社長が経営する会社のサイトは今後も使わない方がいいと私は思いました。
例えばSQLインジェクションでは、会員の情報を抜いて見せて報告をすればいいのですが、 一度そういう報告をすると「これ…訴えられるかもしれないよ」とお叱りを頂きます。
君の言っていることは、窃盗の危険を示すために実際に窃盗して見せるという行為で、到底社会が許す行為ではない。これは日本だけじゃなくて、欧米諸国でも同じ。侵入してもおとがめなしなのは中国くらいなもんだ。
Office氏の事件以降、 善意の第三者が危険な状態になっている事をお知らせというのは激減している。 そこに、セキュリティ情報の提供が難しくなっている背景があると思う。
>文面を読む限りだと「SQLインジェクションを知らなかった」と言うわけではなくて、
ここの話 [itmedia.co.jp]によると、サウンドハウスはSQLイジェクション自体を知らなかったようですよ。
しかし、今時SQLインジェクションで攻撃されてしまうとは... サウンドハウスのサイトでも最初は「SQLインジェクションという特殊な方法で...」と書いてあったのが2ちゃんねるで「特殊でも何でもない古典的な手法ではないか」とツッコミされて、「SQLインジェクションという方法で」に急遽書き換えられていたのでちょっと笑いました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
要するに (スコア:3, 興味深い)
独自開発なのに2008年の時点でSQLインジェクションを知らなかったなんて……。しかも知らなかったのは行政のせいだなんて……。
これを読んで、この社長が経営する会社のサイトは今後も使わない方がいいと私は思いました。
Re:要するに (スコア:5, 参考になる)
全く知らないのでなく、セキュリティには金を払っているのだから、
これで防げるのではないかと思っていたという事でしょ。
技術の専門家で無かった自分は「ハッカーセーフ」とやらの謳い文句が、
十分投資に見合った体制だと思っていたと20ページ目に書いている。
技術の専門家だったら責めるのも解るけど、エンドユーザーの態度としては、
こんなもんじゃないかなあとも思うんだけど。
>知らなかったのは行政のせいだなんて
この会社、この社長の発言全てを弁護するわけじゃないがOffice氏の事件以降、
善意の第三者が危険な状態になっている事をお知らせというのは激減している。
そこに、セキュリティ情報の提供が難しくなっている背景があると思う。
「2006年6月19日に名指しされていた」事が、当時の社長に伝わらなかった。
そしてその間、効果があると思っていた「ハッカーセーフ」に頼り切っていた。
これは、セキュリティの生々しい情報(攻撃側の最新情報
、防御装置の防御範囲)が
表に出てこないからで、素人は学ぼうにも限界があったという事でしょう。
・生々しい情報を公開する
これを言いだしっぺの法則でやってから、注文してる態度は評価してもいい。
それでエンドユーザーの無知ばかりを責めたてるのは得策とは思えない。
例えば、それぞれのセキュリティソリューションの実効性をチェックして公開とか、
各社セキュリティプランの保護領域を比較してくれる第三者機関とか、
エンドユーザーが望む情報がエンドユーザーが危険を冒すことなく、
エンドユーザーの知識で理解できて、コストの不安が無い仕組みが提供できるとすれば、
行政という言葉になってしまうのじゃないかな。
IPAでも情報は公開しているけど、サウンドハウスのようにある程度、
ソリューションを導入していると「ウチに限って」と思い込むのはありうるし、
「ハッカーセーフ」を提供した会社だって「これじゃ不安です」とは言わない。
Re:要するに (スコア:4, 興味深い)
>十分投資に見合った体制だと思っていたと20ページ目に書いている。
ここ不思議ですよね。「ハッカーセーフ」というのはSQLインジェクションの脆弱性の診断もやってくれるのだそうですが。
http://www.hackersafe.jp/product/point.html [hackersafe.jp]
「中国のブログ」の記述では、SQLインジェクションの脆弱性をスキャンツールで発見しているようですから、このサービスも当然脆弱性を見つけていたのではないかと思うのですが。どうなんでしょう。
Re:要するに (スコア:2, 参考になる)
HackerSafeのやってるSQLインジェクションチェックは、
サードパーティ製品などに見付かっている既知の問題クエリとかで、決まったパターン。
で、今回問題だったのは、サイトカスタムなSQLインジェクションで、決まってないパターン。
まぁ、売る側からすれば「SQLインジェクション」診断してますと言うが、
実際には無駄なパターンを数多くたれ流しているだけに過ぎず、いざというときの役に立たない。
安かろう、悪かろうな典型だわな。
だがこれは、別にHackerSafeが悪いわけじゃない。
問題は、正しくリスク分析ができなかった連中が悪いんだ。
今回の件くらいの規模のリスクが発生することを見越していれば、
定期的に人力で診断するなりなんなり出来たはずだろう。
Re: (スコア:0)
>問題は、正しくリスク分析ができなかった連中が悪いんだ。
そうかなあ?じゃあ正しいリスク分析って誰がどうやってやるんだろう。
もちろん大手SIerにでも振れば、重厚長大な圧倒的ソリューションで、
守ってくれるかもしれないけど、実際サウンドハウスのような事業主さんだと
情報価値を分析して、実際の脅威(この情報を知るのが難しい)に即しているか
売ってる技術の中身を検討して買いに来いといわれたら困るんじゃないかな。
「WEBサイトの安全証明」
「365日休まずWEBサイトを診断することでハッキングのリスクからウェブサイトを守ります
Re: (スコア:0)
どこの技術者が誰に向かってどういうときにする説明の話?
Re: (スコア:0)
CISOがやるべきだろ。
居ないなら、外部コンサルを雇え。
その方が安い。
Re:要するに (スコア:2, 参考になる)
>Office氏の事件以降、善意の第三者が危険な状態になっている事をお知らせというのは激減している。
そのOffice事件を受けてIPAやJPCERTなどの取り組みが制度的に整備されました。
そののち、それまで問題点を発見しても誤解されることを恐れて通報を躊躇していた善意の第三者の皆さんは、多少の不安も感じながらそれらの取り組みに加わっています。
したがって、善意の第三者が直接「問題のある組織団体」や「ネット上」へ危険な状態になっている事をお知らせというのは激減していますが、それは当たり前のことで、むしろ通報する側される側とも余計なリスクを負うことが無くなったことは歓迎すべきだと思います。
IPAやJPCERTもJVN準拠で処理されており、その線で情報公開も行われています。
また自分がかかわった案件の経緯をブログ等で公開している開発者もいます。
脆弱性情報が閉ざされたり闇に葬られるようになったわけではありません。
サウンドハウスも企業としてIPAにきちんと報告しています。
その結果、経産省のヒアリングを受けますが、これは単なるご説明ではなく、多量流出案件に対するペナルティの意味を有しています。
つまり単なる情報流出事件ではなく、流通と金融に係るトラブルであると経産省が認識しているのであり、外郭団体と中央省庁の連携がきちんと機能していることを表しています。
Office事件は通報者自身の不手際もあり逮捕者も出しましたが、その教訓はきちんと生かされているのではないでしょうか。
Re:要するに (スコア:2, 興味深い)
(略)
>その教訓はきちんと生かされているのではないでしょうか。
レスありがとうございます。
この部分、自分でも最後まで触れずにいようかと思いましたが、やはり触れることにしました。
このようなツッコミが入る程度には、IPAの活動は周知されているのか、普通にOffice事件から
進展がないと受け止めている人が多いのか解らなかったからです。
あれ以降、確かに軽微なものはリスクを負う事無く報告されるようになりました。
そして問題が起きた後のインシデントレスポンスの体制は整ったかもしれません。
しかし、今回の経緯 [srad.jp]を見て、そして自分が通報したときの経験からすると充分といえません。
・「海外における善意の第三者」の通報には対応していないか、窓口が知られていない
逆に一見日本語が提供されていても、グローバル企業、日本以外に本拠点のあるサイトへの対応は弱い
・今回のような脆弱性を全個所(SQLインジェクション以外の部分)報告する事は歓迎されない
そこを糸口にした影響範囲を調査する事は逆に制限がついている
・報告しても放置が多いのに全く公開されず公開できず、その間ユーザーは危険に晒されつづける
具体的事例を蓄積しているはずなのに、統計的にしか知ることが出来ない
という問題を依然抱えているように思えるからです。
>Office事件は通報者自身の不手際
これがたまたま、比較的オープンな集会であったために発覚しましたが、今回のようにアンダーグラウンドで
取引されているような脆弱性情報 [impress.co.jp]のような、
即警察にも動いて欲しい事案を報告するにはIPAの窓口だけでは不足です。
(場所によっては、裏切り者となって殺されるリスクがあるかもしれません)
そして、ソフトウェア事例ですが一太郎の脆弱性が、シマンテックのブログで公開された事例について
高木浩光氏 [takagi-hiromitsu.jp]も「一太郎zero-day攻撃のニュースは、
次のように、いつも Symantecの blog が一次情報源になっている。」と書いています。
(まあ、氏のblogなので、やや煽り気味である表現があるのは無視して読むことが必要ですが)
要するに、海外の善意の第三者は依然Office流とも言える対応をしているし、悪意のある人間は尚更です。
日本国内の善意の第三者だけが守るような取り組みで、その善意の示し方も慎重なやり方に制限されています。
結果的に、通知された側は本当のリスクが見えなくなっています。
脆弱性を通知された組織の側から、間近に問題がどう受け止められたかを見た事もあります。
私は当該アプリケーションの実装もしていなければ、何か決定する権限が与えられている訳では
ありませんが、他に誰もその脆弱性報告がどういう攻撃をされるのに利用されて、
一番大事な所ですがビジネスリスクになるのが解らないという事で相談された事があります。
IPAからの報告は、技術者に届かなければ意味が通じず効果がないという事なのです。
統計的なデータ [security-next.com]だけでは、わが社に限って狙われることは無いと思ったりするのです。
特にクロスサイトスクリプトのようなものは、「これまでにこれでこういう事例があった」
みたいな一時報告者は知らなくてもIPAが蓄積しているであろう具体的なソースを提示しないと、
すぐにエスカレーションされる機会が殆ど無いのです。
例えばSQLインジェクションでは、会員の情報を抜いて見せて報告をすればいいのですが、
一度そういう報告をすると「これ…訴えられるかもしれないよ」とお叱りを頂きます。
だからシングルクォートを入れたらSQLエラーが画面に出た、程度の情報で報告します。
では、そこからIPAが相手と同意をとって検証して、会員情報リストが抜ける形を示して
くれるかというとそうでは無いので、よほど日頃からセキュリティ事情に関心をもっている、
CIOでも置いていない限りビジネスリスクとして認識してくれません。
オフショアに丸投げにして作られたものなどは、解っていても「契約外、仕様外」といって、
直すのに新規構築に負けないくらいの金と労力がとられるので躊躇する場面もあるようです。
まあ、SQLインジェクションは、もはや名前だけが一人歩きするようになっているので、
「とにかく対策しなければ」と思う人のほうが多いと思ってしまいます。
しかし、44件残っているうち1年以上放置されているのが20件 [nikkeibp.co.jp]というのが実情です。
しかも、今回のような事案の場合、「この欄に'を入れたらエラーが出たよ」どまりの報告では、
抜本的な対策を取る事無く別欄のインジェクションで攻撃されている不安が残ります。
ラックさんとの協力でツールを公開 [atmarkit.co.jp]してくださったようですが、
これは複数台サーバーにわたる膨大なログを定期的に自動処理出来ないので実行コストが嵩みます。
すると、結局元々意識の高い会社が「ああやっぱり攻撃されてなかったね、よかったね」という確認を
自主的に行って安心する程度になってしまう可能性が高いです。
これまでの、「統計的な取り組みは評価に値する」「あの頃に比べれば改善したと思う」という意味で、
その認識は貴方と同じですが、今回の事例からハッカーセーフを導入するようにはなったが、
しかしそのソリューションが一体何を守っているのか解っていないでやっているという実態が
明らかになり、ウェブをやってるのは技術者がいる会社だから技術者に解る内容で公開すればいい、
という性善説的な従来の限界、日本国内ルールの限界が見えてきたと思います。
IPAの実効性に論点が膨らみすぎましたので、Office事件後と事件前の話だけに絞りましょう。
Office氏のやった事は、発表の場とプロセスが悪かったにせよ具体的なプレゼンでありました。
あれ以降、IPAに報告をすることで、具体的なプレゼンを必要としなくなってはいるが、
それだけに充分相手に伝わらなくなっているという事です。
Re:要するに (スコア:1, すばらしい洞察)
君の言っていることは、窃盗の危険を示すために実際に窃盗して見せるという行為で、到底社会が許す行為ではない。これは日本だけじゃなくて、欧米諸国でも同じ。侵入してもおとがめなしなのは中国くらいなもんだ。
Re:要するに (スコア:1, 参考になる)
ただIPAに期待したいのは脆弱性がある可能性があるという報告をするだけでなく、
それがどの程度危険なのか、回避策も含めた業者紹介も含めた総合的なアナウンスというか説得作業等で相手を意識改革をさせる事でしょうか。
ぶっちゃけ現状のIPA、一度届けるとIPA越しになるのでレイテンシが長くなる上に、こちらのメールを直接送付じゃないのか話がねじれて非常に「邪魔」です。
無謀な人、社会的に失う物が少ないと思える人は訴訟リスクを取るかもですね。
だって実例の方が説得力は圧倒的に増しますからね。
# エラー画面から、攻略手順を1から10まで書いて仮想通貨の搾取が可能ですよとメールした事があるのでAC
# 結局向こうはSQLどころかデータベースすらちゃんと解ってなかった・・・コピペ・サンプル・解説本の罪なんですかね。
ファーストサーバーの社長が逮捕されたので (スコア:1, 興味深い)
久保田理事がこんなことを言ってたんですね。
レンタルサーバー会社の安全性を認証する第三者機関を~ACCS久保田理事
http://internet.watch.impress.co.jp/cda/event/2004/09/30/4793.html
「レンタルサーバーを借りるときに、きちんとそのサーバー会社がセキュリティに対して適切な体制を整えているかをチェックしないと、実際に情報が漏洩した際にそのサーバー会社を選んだことに対して委託元としての法的な管理責任を問われる可能性が高いが、個々の企業にはそのようなチェックを行なうノウハウがないために実質的にはチェックは困難」と指摘。「そのような問題を避けるためにも、サーバー会社が適切な管理を行なっているかどうかを認証する第三者のチェック機関が必要だ」と訴えた。
これがサウンドハウスの社長を含めて一般的な経営者の感覚そのものなのでしょう。
そして、その感覚は過去も現在も変わっていない、と。
ホスティング会社に限らずセキュリティサービスを提供する企業の格付けが必要であることは間違いないでしょうが、ではそれをどこの誰がやるのかが問題になります。
それについてなにかアイディアをお持ちでしょうか。
ご指摘のとうり、IPAやJPCERTの枠組みは完璧ではありませんが、改善させることは可能です。
また格付けそのものではなくガイドラインのような形式でもよいのかも知れません。
いずれにしても、実務経験から得られた問題点や改善点についてのご意見や提案をおもちなのでしたらそれらは公の場に問うてみてはいかがでしょうか。
ひとりでぐちぐち悩んでいるよりは問題意識を共有している方々と前向きに取り組んでみてはいかがでしょうか。
(#1332755)の内容には大筋で同意しますし(#1333162)の内容は大方は理解できます。
ただ、正式なセキュリティ監査案件で受注したのではなく当事者間の口約束みたいなことで相談に乗る、というは内部統制(セキュリティ管理統制)の面で問題ありすぎなので、用心にされた方がよろしいかと。
技術屋としての良心というかお気持ちはわかりますが、そのような場合には、やはりきちんとしたセキュリティベンダーへ相談することを勧めるにとどめるのがIT分野のプロとしてのたしなみではないでしょうか。
約10万件、カード会社二社からの通報で発覚と言うことは既に流出したカードが悪用されていたことになります。
決済時期が国内使用とずれる海外で悪用されていたことが発覚すればカード会社は金融庁の聴取を受けることになるでしょう。
クレジットカード (日本) - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AC%E3%82%B8%E3%83%83%E3%83%88%E3%82%AB%E3%83%BC%E3%83%89_%28%E6%97%A5%E6%9C%AC%29#.E6.97.A5.E6.9C.AC.E3.81.AB.E3.81.8A.E3.81.91.E3.82.8B.E3.82.AF.E3.83.AC.E3.82.B8.E3.83.83.E3.83.88.E3.82.AB.E3.83.BC.E3.83.89.E3.81.AE.E6.B3.95.E8.A6.8F.E5.88.B6
カード会社は加盟店契約を行う場合に審査を行いますが、セキュリティ面での対応が適切であるかどうか技術的なことまでは踏み込みません。
恐らくカード会社はサウンドハウスはハッカーセーフを導入していたことから優良加盟店として認識していたのではないかと思われます。
そのうちクレジット会社主導でセキュリティ格付け制度が立ち上がるかもしれません。
Re:ファーストサーバーの社長が逮捕されたので (スコア:1, 参考になる)
ハッカーセーフは、既にクレジットカード会社公認のようですよ。
ビザ・インターナショナル『日本初のインターネット脆弱性スキャニングとセキュリティ診断の無料サービス』を開始 [hackersafe.jp]
ハッカーセーフのサイトにありますが、ビザインターナショナルのリリースのようです。
Re:要するに (スコア:1, すばらしい洞察)
Re: (スコア:0)
丼勘定なテキトーな理解で批判するのは筋違いというものだ。
というか、話の筋を理解してないだろ?
Re: (スコア:0)
Re:要するに (スコア:5, すばらしい洞察)
構造計算書や産地や原料の偽装だってバレるまではひた隠しにした方がいいに決まってるんです。社会正義なんて嘯く連中にだまされてはいけません。
Re:要するに (スコア:2, おもしろおかしい)
#「くいだおれ」にもいなかった。
Re:要するに (スコア:3, すばらしい洞察)
今回の事件を受けて所感・提言の
2つに分ければいいのに、と思った。
ここに限らず、お詫び文と一言もの申すをひとつに束ねちゃうと
発言側の意図しない受け取られ方をするのになぁと常々思う。
Re:要するに (スコア:2, 参考になる)
文面を読む限りだと「SQLインジェクションを知らなかった」と言うわけではなくて、「SQLインジェクションの危険性を知らなかった」ということだと思いますよ。
行政云々~っていうのはそれを受けての発言だと考えれば、社長の言い分も分からなくはないです。
// まぁでも行政へ責任転嫁する姿勢は私もどうかと思いますけどね。
// 社長の言い分が正しいとなれば極端な例で「Windows使うのは危険」「Linux使うのは危険」と
// 行政は言わなくてはならなくなると思います。あくまで極端な例ね。
// 「はさみを使うと手を切る危険があります」なんて行政がアラート出すわけありませんものねぇ
// だからはさみメーカーは「こどもの届かないところに置いて!」って警告を書いているわけですし
Re:要するに (スコア:4, 興味深い)
>文面を読む限りだと「SQLインジェクションを知らなかった」と言うわけではなくて、
ここの話 [itmedia.co.jp]によると、サウンドハウスはSQLイジェクション自体を知らなかったようですよ。
Re:要するに (スコア:1)
Re: (スコア:0)
・「特殊な方法」って書いておけば、少しは批判も和らぐかな?
・まずい、特殊じゃないって叩かれたぞ、逆効果だから消しちゃえ
ってくらいのノリを想像しますが
つーか、開発してて本当に知らないという事態の方が想像出来ないな
寿司屋がアニサキス(鯖の寄生虫レベルでいい)を知らないような話だぜ?
この一件、良くも悪くも業界外の認識はこんなものだろうなと、興味深いですね
セキュリティ屋の胡散臭さを知ってる身としては、無条件には叩けない
Re: (スコア:0)
もしそうだとしたら、Windowsやはさみと違ってSQLインジェクションが外部からWebサイトへの攻撃以外の目的で使われることはまず無いので
「食中毒は知っていたけど食中毒の危険性は知らなかった飲食店」くらい間抜けな話だなあ。
「セキュリティについては一切の業務を外部に委託していたので何も分からない」と言った方が(おそらく)正直で良かったのに。
Re:要するに (スコア:2, 興味深い)
一部だけ取り出して読むとそういう意見もあるでしょうが、私は社長の心情も含め赤裸々によく書けていると思いましたよ。クレジットカードのデータ流出を起こすとどんな目に遭うのか良く分かるので、同様のシステムを抱えている人にとって参考になると思いますし。
#私は何年か前にここで購入した事があり、何度か今回の件でメールが届いていました。
#結果的に私のデータは流出事件の対象外でしたけど。
Re:要するに (スコア:1)
この一文を境に、前と後ろの落差が極端だなぁ。
っつーか24時間体制のシステム管理はどこに逝ったんだ?
そんな人員が居るなら、SQLインジェクション知りませんでしたなんていいわけは到底通らないだろうに。
3Dなんちゃら導入した結果、安心してシステム管理部門を解散してしまい、後はほったらかしでしたってんなら
それこそ経営責任だと思うけどなぁ。
# 0Dayに対応できませんでしたってんならともかくねぇ。
Re:要するに (スコア:2, おもしろおかしい)
んで気になったのは総論の中のこの一文
>サイバーテロによる破壊の被害にもあいましたがその結果、
>サウンドハウスは今、およそ最強のセキュリティ管理体制を整えつつあります。
なんかまた安心してしまっているような…、気のせい?
Re:要するに (スコア:2, すばらしい洞察)
国防省ぐらいコストをかけているなら最強といってもいいけど、
セキュリティ専門家すらいない低コストで運用している一中小企業が、最強のセキュリティを手にいれられるわけないでしょうが。
せいぜい、現時点で、対処できる施策の中で、コストとリスクを考えた上で、もっともよい施策を選んだ程度でしょ。
Re:要するに (スコア:2, おもしろおかしい)
それが「最強のセキュリティ」じゃないかなぁ、と思う。
#そうであることを祈る。
Re:要するに (スコア:1)
>なんかまた安心してしまっているような…、気のせい?
対応策には「4.プログラムの除去 外部から挿入された疑いが高い不正プログラムの除去を実施。」とあって、OSを入れ替えました、とか、再インストールしました、とは明確に書いてないんですよね。少なくとも任意のシェルコマンドを実行可能だった疑いのある期間があったわけですから、真っ先にそこをどう対策したのか書くべきじゃないのかな、と思います。最強のセキュリティ管理体制が早く整うと良いなぁ、と願うばかりです。
Re: (スコア:0)
「これまでの経緯」を読むと、3月23日にOSの再インストールとサーバの再構築を実施しているようです。
Re:要するに (スコア:1)
Re:要するに (スコア:1)
私はこの文言が気になりました。
テロなんて大仰なもんじゃなくて、単なる窃盗犯による窃盗被害じゃないの?
言外に「不可抗力による突発的な事故ですよ」と臭わせているようでモニョる。
Re: (スコア:0)
Re:要するに (スコア:1)
なんかこう、情報流出の前段階として何か悲しいことが起きていたんじゃないだろうか。
Re:要するに (スコア:2, おもしろおかしい)
・・・一人三交代とか・・・
・・・社内ひきこもりとか・・・
・・・サーバールームに巣くう巨大な蓑虫とか・・・
・・・昼間社員で夜警備員とか・・・
Re:要するに (スコア:1, すばらしい洞察)
早期対応が遅れた理由もひたすらカード会社からの指示ばかり繰り返しているし。
#JCBの対応の方が鈍いのが面白い。
後半の社長の作文なんて目が滑って流し読みでしたが、泣き言はいいから腹でも切って朽ちろとしか思えないですな<流出された身としては
なんというか、こういう釈明文はあんまりいい印象を受けないんですが。
みなさんはどうですか?
Re:要するに (スコア:2, 参考になる)
同様の事件でいつも感じる、「なんでこんなに発表遅れるの?」という理由が
しっかり書かれているように思いましたが。
ユーザは一刻も早く情報が欲しいと騒ぐけれど、当事者になってしまうと、
対象が絞れないまま第一報を出してしまったら混乱するという、
当たり前の視点が抜けてしまうんだなぁ、と思いましたよ。
後半を作文と言ってしまうのは簡単ですが、
一般的な企業のセキュリティ意識としてしっかり受け止めることは大切だと思います。
また、セキュリティ製品を売っている方達には、
セキュリティ製品に完全は無いのに、大げさに宣伝した結果、
ユーザが、製品によって解決できる問題と解決できない問題を把握出来ず、
結果、このようなことが起こりうるのだと言うことも、把握することも大事だと思います。
ありがとうスラド (スコア:0)
サウンドハウスの事件で第一報を知ったのはスラドのRSSでした。
即、サウンドハウスのHPに行き、登録内容と事件の詳細を確認。
とりあえず自分は対象外である事を確認し、安心して寝る事が出来ました。
ちなみにサウンドハウスからのメールが届いたのはその次の日。
最後に買い物をしたのは数年前なのに、ちゃんと連絡が来たのは少し感心しました。
Re: (スコア:0)
公開していないアドレス宛に,聞いたこともない通販食品販売会社より私の実名入りの
PRメールが届きました.そのアドレスと名前が結び付いて第三者から届いたのは,もう
10年ほど使ってて初めてで,ついに来たかぁ・・・と思ってたところに,この通知だった
ので,すわ漏洩の結果かと確信しました.
しかし,ほどなくして届いた補足メールでは,自分は被害対象外だったとありました.
いったい何がホントに起こったのやら・・・情報管理されてる側からだと確かめようが
ないのが不安ですねぇ.
Re: (スコア:0)
時系列の詳細報告まではよくやった、他も見習えコンチクショーですが、
それ以降の泣き言は経済誌などに載せてもらって同じように軽い気持ちでオンラインサービスを行っている企業人に読んで貰って下さい、と云った感想。
実際の所被害者と興味のある人間しかあんな報告読みません。ウチは大丈夫と思っている他社が読むはずもなく。
# 近くにLACの人が居るのでAC。
Re: (スコア:0)
Re: (スコア:0)
言いつづければ本当になる (スコア:1, すばらしい洞察)
社長は技術的にはあまり詳しく無く、技術があげてくる説明(言い訳と読む)をつなぎ合わせて、詫びとお知らせという文章を作ってしまったということはないでしょうか?
どこの会社でも失敗したときに自分を正当化するためにこういう言い訳をする技術者って、良くいませんか?
いくら苦しい言い訳でも言い続ければ、不思議なもので30%ぐらいは分があると思うようになってしまうものです。
Re: (スコア:0)
Re: (スコア:0, 荒らし)
Re: (スコア:0)
「長いので要点を抽出してみました。縦読みすると本音が読めます。このとおり」
って投稿と同じじゃないの?
新聞編集メソッドで記者の言いたい方向へ情報編集しただけじゃない。
せめて自分はこういう読み方をした、と抜き出した部分を貼りなよ。
「これが要点です」って貼るのは読者にそれが真実だと思いこませたい意図でもあるのかな?
特に今回は、せっかく1クリックで完全な元ソースにあたれると言うのに、
部分的に抜き出して短くしてしまっては、類を見ない詳細情報をあえて公開してある利点が台無しです。
#
ま、どういう投稿しても自由なんですけどね。なのでこちらもひねくれてみました。