Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

セキュリティ対策を発注元に断わられたことを記録する方法は?

背景

要求仕様にセキュリティ対策の記載がない場合でも、十分に認知されているリスクはベンダが対策を行う必要があるとした東京地裁平成26年1月23日判決(平23(ワ)32060号)*1が出て以降、この点についてソフトウェア請負開発を行うベンダの立場は弱く、また求められる責務は多くなっていると言えるでしょう。

2019 MPOWER Cybersecurity Summitで徳丸先生が登壇されていた際*2は、ベンダ側としては「セキュリティ対策が必要であることを発注元に明示し、発注元から断わられたことを記録しておくことで、裁判になった場合のリスクを低減する(過失相殺が認定されるようにする)」が自衛策になるという話でした。上記の判例を所与のものとした場合、この方針しかないだろうというのは納得です。

問題

では、「セキュリティ対策が必要であることを発注元に明示」するのは、いつ・どこで・だれがどのように提示するのがよいのでしょうか? また、裁判になった場合のリスクを低減するには、記録をどのような形で作成し、どのような形で保存しておくのがよいのでしょうか?

論点

  • 情報システムの請負開発時に、ベンダ側でセキュリティリスクを識別する枠組み(ISMSのような枠組み)が整備されていない。実際には、開発するソフトウェアそのものに関するリスク以外にも、レピュテーションリスク(事故ったときに「開発ベンダは◯◯社です」と公表される場合のレピュテーションリスク)などが考えられるが、ほかにどのような観点が存在するか?
    • またそのような観点は、発注元・ベンダ・システム利用者などのステークホルダーの軸、およびISO/IEC 12207におけるプロセスの軸などをもとに、どのようにまとめられるか?
  • 情報システムの開発ベンダを総合評価方式の入札で決定する場合、どのような仕組みがあれば発注元はセキュリティ対策を実施してくれるベンダを選べるのか? 実施すべきセキュリティ対策が要求仕様に記載されており、その内容を満たすことで技術点が加点されるのが理想ではある。一方で、平23(ワ)32060号判決は「発注元はセキュリティの素人なんだから、プロであるベンダがちゃんと対策しなさい」という内容なので、それは難しいという前提に立つ必要がある。
  • 提案書を作成して入札する調達の場合、セキュリティ対策を提案書に盛り込んでしまうと、その後で取り下げることができない。「ベンダ側はセキュリティ対策が必要だと認識しているが、対策費用を入札額に盛り込んでしまうと価格で負けてしまう」という場合、ベンダ側もセキュリティ対策を提案書に盛り込むことができない。提案書には記載していないセキュリティ対策の内容検討を、ベンダから発注元に依頼するにはどうしたらよいか?
  • 「セキュリティ対策が必要であることを発注元に明示」し、納得してもらえれば変更契約となるわけだが、一方で「変更契約が成立しなかったことの記録を目的にセキュリティ対策の必要性を発注元に説明する」ことははたして可能なのか?
  • SLCP-JCF2013や、ISO/IEC 12207において、システムの開発プロセス上「ベンダ側は必要だと認識しているが、発注元は要否を認識していなかった機能について、発注元に要否を判断してもらう」という作業を実施するタイミングが、要求仕様の設計後に定義されていない。システムの開発プロセス上、どのタイミングで実施するのがよいか?
  • ISMSでは、存在する情報システムおよび情報資産について脅威や脆弱性を識別しリスクを評価するプロセスが定義されている。情報システムおよび情報資産について変更があった場合に脅威や脆弱性を再識別することは可能である一方、「近いうちに情報システムに○○という変更がなされる予定です」というタイミングでリスクの再評価をするプロセスが定義されていない(と思われるが、見つけられていないだけ?)。現存しないシステムに対するISMS的な評価は、どのタイミングで、どのような内容をもとに行われるべきか?
    • そもそもISMSのプロセス内に、「これから開発するシステムの開発ベンダ」による評価が行われるタイミングがない。現存せず、これから開発する予定のシステムの脅威や脆弱性を識別する場合、誰が参加するべきか?
  • 「発注元から断わられたことを記録しておく」として、それをどのような形で記録しておくのが適切か?
    • 発注元とベンダとの間の合意内容に関する文書なので、もっとも確実なのは契約書と同じ形式と思われる。ただし、裁判の際に発注元側が不利になる内容を含む文書なので、発注元がハンコを突いてくれたとしても、発注元の心象の悪化は避けられないのでは?
  • セキュリティインシデントの場合、裁判に使う証拠物件としてデータを保全する手続き(Chain of custody)が定められているが、情報システム開発において証拠物件の保全に相当する手続きは存在するのか?
  • 「発注元から断わられたことを記録しておく」場合、実質的に「情報システムで発生した問題をベンダ側の重過失としない」内容になってしまうと契約として無効になってしまう(と思われる)。記録方法としては、どのような記載が適切なのか、どのような記載だと問題があるのか?

余談

上記のような話がぜんぜん議論になっていないのは、いったいどうしてなんでしょうね?

  • 判決を受けて、どの発注元もセキュリティについてちゃんと仕様書に書くようになったし、どのベンダもちゃんとセキュリティ対策をするようになった。
  • 要求仕様に書いてないんだから、手弁当でやったらやっただけベンダが損を被ることになるのでやらない。重過失認定されたら仕方ないとあきらめている。
  • そもそも判例を認知していない。
  • セキュリティってなに? IPAっておいしいビール? というベンダばかりで問題視もされていない。
  • セキュリティってなに? IPAっておいしいビール? という発注元ばかりで、セキュリティの問題が発生したらベンダを頼ることはあっても、訴えるなんて思いもつかない(やさしい世界?)。
  • 契約書に何か書いてリスク対策をしていると思っている(重過失だと契約書中の上限額が無効と気付いていない)。