外注したシステムの脆弱性は誰のせい？ 連日の「深刻な脆弱性」にどう向き合い、どう対応するか？（3/4 ページ）

[宮田健, 谷崎朋子，＠IT]

＠ITの人気連載著者が語る、「外注したシステムの脆弱性は誰のせい？」

ITコンサルタント 細川義洋氏

　東京地方裁判所で民事調停委員を10年間務め、システム開発にまつわる紛争の解決に寄与してきたITコンサルタントの細川義洋氏（＠ITの人気連載『「訴えてやる！」の前に読む IT訴訟 徹底解説』も執筆）は、特別講演「訴えてやる！の前に――外注したシステムの脆弱性は誰のせい？」において、有名なIT関連の裁判を取り上げ、「開発要件に入っていなかったから」「全てお任せだからインシデントが起きればベンダーのせい」は通用しないと訴えた。

　その判例とは、平成22年、あるユーザー企業AのWeb販売システムで顧客のクレジットカード情報6795件が不正アクセスされた事件に関するものだ。これらの情報はインターネットからアクセス可能な場所に置かれており、暗号化はされておらず、SQLインジェクション対策も施されていなかった。A社は開発外注先のベンダーBに対し、1億1千万円の損害賠償を求めて提訴した。

　だが、B社はそもそも開発要件にセキュリティ項目が含まれておらず、保守運用時に脆弱性に気付いて改修を提案したが聞き入れられなかったと明かし、A社にも責任があると反論した。

　これに対して裁判所は、まずベンダーは専門家責任があり、予見可能なSQLインジェクション脆弱性に対する攻撃に対策しなかったことから、重過失として損害賠償の対象に値すると断定。ユーザー企業も、脆弱性の指摘に対応せず、漏えいの一因になったばかりか、顧客に影響を与えた責任がある。よって、損害賠償額はユーザー企業の責任を差し引いた3割減という判決が下った。

　「今やセキュリティ事故は日常茶飯事。そんな時代、不作為は罪だ。ベンダーおよびユーザー企業はセキュリティについて学び、検討し、対応し続けることが求められる」

システムに脆弱性を組み込まないためには、何をすべきか

　では、システムに脆弱性を組み込まないためには、何をするべきなのか。

　1つは、経済産業省や総務省、IPAなどが公開する契約書のモデルやひな型を参考に、大方針をまとめた契約書と、該当システムが受ける可能性のある攻撃への予防策を別紙にまとめることだ。

契約書や別紙などの書き方

　もう1つは、運用保守担当者の人選だ。ユーザーあるいはプライムベンダーのプロジェクトに参加した期間、その間に起こした問題の数を選定条件に含める他、採用後はモチベーションを醸成する施策の実施（教育、表彰）、面談の実施、モチベーション低下の確認などを適宜実施することが挙げられる。細川氏は自身の経験を次のように振り返る。

　「セキュリティ事故を起こさなかったら表彰するのも有効だ。私自身、運用管理で一室にこもっていたとき、副社長が来て日頃の努力に感謝すると直々に言われたとき、単純だが私は良いことをやっているとうれしくなった。（褒められて）少なくとも悪いことをしてやろうという気持ちにはならなくなる」

「トリアージ」の実践

　だが、それでも漏えい事故が発生することもある。そこで細川氏は、上記に加えて「情報のトリアージ」「トリアージに基づく情報保護方針の作成」「組織を守るためのトリアージ」を実践してほしいと述べた。

　情報のトリアージでは、自組織の情報を棚卸しし、例えば「経営に重大な影響があっても守るべき情報（個人情報、国家機密）」「そこまでではないが対外的に影響が大きいもの（取引先の通常情報、未発表の決算情報）」「外部に及ぶ損害は限定的だが社の被害が大きい情報（経営戦略情報、固有の技術情報）」「限定的だが社内での損害がある情報（顧客台帳、社員の個人情報）」などに分類する。

　そしてトリアージに基づき、国家機密なら個人のPCに保管しない、原則としてインターネットには接続しないといったような情報保護方針を作成する。実際、経産省ではインターネットや外部メールと、経済産業省内部のやりとりを仮想マシン別に分離、警察庁では物理的に使用するPCを分けて使っているという。

情報のトリアージ

トリアージに基づく情報保護方針の作成

　この他、細川氏は「組織の場合、情報の値札付け（損害額の算出と支払準備金の積立）、謝罪者と決裁者の決定（漏えい時に誰が誤るか、誰が損金を決済するか）、謝罪者と決裁者への周知（保持する情報の通知、いざというときの対応の決定）を行うといい」とアドバイスした。