Webセキュリティの小部屋

Twitter のフォローはこちらから Facebook ページはこちら Google+ページはこちら RSSフィードのご登録はこちらから
公開日:2013年5月2日

JINS セキュリティ事故報告に見る責任のあり方

JINS オンラインショップのセキュリティ事故に関する最終報告が、JINS のサイトに掲載されました。

今回の、JINS オンラインショップにおけるセキュリティ事故において、JINS が行った対応は、今後、企業がとるべき対応の手本になりうるものです。

具体的には、JINS は以下の対応を行いました。

  • 不正なアクセスが発見された時点で、サイトを早急に閉鎖
  • 推測される影響範囲とともに情報を早急に公開、随時更新
  • 影響があると思われるユーザーに状況をメールで通知
  • 不正アクセス専用の問合せ窓口の設置
  • 第三者のセキュリティ専門企業による影響調査と原因究明
  • クレジットカード会社、警察との連携
  • 影響するユーザーへの補償(カード再発行手数料負担、QUOカード送付)
  • 情報漏えい事故調査委員会の設置と最終報告

セキュリティ事故が起きたときに行うべき対応を着実に行っています。おそらく、セキュリティ事故が起きたときの対応計画をまとめた「インシデント計画書」が事前に作られていたのでしょう。

さて、肝心の最終報告の方ですが、こちらも妥当なものだと評価できます。

セキュリティ事故の原因は、Apache Struts2 の脆弱性を悪用されたことにあったようです。Struts をミドルウェアと呼んでいるのは、技術者視点からはフレームワークだろうとも思いますが、最終報告は一般向けに公開されているものなので許容範囲でしょう。

今回のセキュリティ事故において、JINS 社の責任には以下のものがあると委員会により指摘されています。自社の管理責任に触れていますね。

ベンダ選定時の調査・分析、システムの保守サポート業務品質の管理義務が充分になされていなかったという不備が認められる

一方、ベンダー側の責任については以下のように指摘されています。

ベンダは、すでに脆弱性が指摘されていたStrutsの古いバージョンを使用したまま、当社オンラインショップシステムの改修作業を完了しており、本来、システム開発会社として善良なる管理者の義務に基づき瑕疵のないシステム構成を設計すべき義務があるところ、それを看過してシステム構成の設計を行っていた点で責任がある

一見すると、ベンダーに責任を押し付けているようにも読めますが、よく読めば以下の段階を経ていると思われるため、ベンダーにも責任はあると言えるでしょう。

  • JINS オンラインショップ公開
  • Struts の脆弱性が発見される → この情報をベンダーがキャッチできなかった
  • JINS オンラインショップを改修
  • Struts の脆弱性を含んだまま改修後のシステムをリリース
  • そのまま運用を続けセキュリティ事故が起きた

ベンダーは改修作業を行っていることから、保守開発の契約を結んでいると考えられます。契約書に脆弱性の扱いについて記載がなかったとしても、ベンダーは採用しているシステム構成要素である Struts の脆弱性の情報は収集すべきであり、それをJINS 社に伝えるべきでした。そうしないと瑕疵のあるシステムをリリースすることになってしまうからです。

Struts のバージョンアップを行うと、システム全体の再テストが必要になり無視できないコストがかかります。ここで JINS 社が、コストをかけてバージョンアップを行うか、リスクを許容するかの判断を行う必要がありました。リスクを許容したなら、問題が起きたら JINS 社の責任になります。

このようにすることで、責任の所在を明確にし、問題を未然に防ぐ可能性もありました。問題が起きたとしても、ユーザーとベンダーのどちらに責任があるか明確になったでしょう。

しかし、実際はこのように簡単にはいきません。脆弱性の扱いについて契約について触れられることはあまりないでしょうし、システムも再テストを簡単にできることを前提に作成されていないからです。

一方で、Web サイトの脆弱性への攻撃は日増しに増加しています。最近、不正ログインのニュースが多いですが、使用される ID とパスワードの組み合わせは、脆弱性をついて入手したものでしょう。

時代はすでに変わっているので、契約のあり方、開発のあり方も変わっていくべきです。

契約のあり方は、脆弱性が発見されたときに誰の費用と責任でバージョンアップするか見直しが必要です。開発のあり方は、OS・ミドルウェアの脆弱性が公開されたときはセキュリティパッチを適用、もしくはバージョンアップし、システムの再テストが簡単にできるよう自動テストをできるだけ組み込むようにした方がよいでしょう。

脆弱性の対策は利益を生み出さないため軽視されがちですが、今回の JINS の事例を教訓に脆弱性への対策を行えるよう、少しずつでも状況を変えていくことを推奨します。


スポンサーリンク




カテゴリー:ブログ

Twitter でも、いろんな情報を発信しています。



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA