第６３３号コラム：江原 悠介 理事（ＰｗＣあらた有限責任監査法人　システム・プロセス・アシュアランス部　シニアマネージャー）
題：「なつやすみのしゅくだい」

このようなタイトルを打ち出しているが、既に夏休みの時期はとうに終わり、季節柄としては秋に入り込んでいる当今、このコラムでは、当方も含めた様々な有志の下で作り上げられた、ある種の長いなつやすみの宿題への対応結果について紹介したいと思う。

それは、情報処理推進機構（IPA）より20年3月にパブリックコメント募集が行われ、今秋の公開を予定している「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」である。このガイドラインは、20年4月の民法改正に伴い、民法上の瑕疵担保責任が契約不適合責任へと変更される状況下においても、IT企業とユーザ双方がデジタルトランスフォーメーション（「DX」）の推進を継続できるように、情報システムにおけるモデル契約のひな型を検討していくなかで、DXという「攻めの姿勢」を継続的に維持するために、ベースラインとして求められるセキュリティのありかたを検討するという目的のもとで策定された。いうなれば、民法改正後における、DXに向けたセキュリティのベースラインを整理することを目的としたものである。

このように記すと、よくあるガイドラインの一種のように読み取られがちだが、このガイドラインは他のガイドライン群と比較した際に、特筆に値する特徴が3点ある。

1点目は、このガイドラインの策定には国内の主要なISAC団体が関与している点である。事務局を担ったSoftware-ISACをはじめ、交通ISAC、ICT-ISAC、J-AUTOISAC、医療ISAC等、国内のISAC団体のメンバーの参画のもと、業界・業種横断的に求められるセキュリティ上の要点が議論され、その結果が反映されている。さらに、これらの団体に加え、情報サービス産業協会（JISA）、OpenID ファウンデーション・ジャパン等も参画しており、ガイドラインの業界横断性が担保されていると言える。セキュリティガイドラインの多くは、業界・業種に特化する、あるいは標準性を志向する傾向が強く、前者は内向性が強くなり、後者は抽象性が高くなりがちである。

このガイドラインは両点をうまく押さえ、各業界固有の特性を踏まえつつも、共通項を中心に標準化を図ったセキュリティガイドラインとなっており、今後、特に国内ISAC団体が横連携する際のコミュニケーションフレームワーク（目線合わせの準拠枠）に位置付けられると言える。

2点目は、一般的に使われるOSにフォーカスした、実用的且つ詳細なコンフィグレーションスタンダードを策定するとともに、その陳腐化を防止する公開スキームを採用した点である。コンフィグレーションスタンダードの観点からは、特にサイバー攻撃の標的率の高いWindows Active Directoryを対象として、MITRE ATT@CK、米国国防総省のSecurity Technical Implementation Guides（DoD STIG）、Centerfor Internet Security Benchmarks（CISベンチマーク）等を援用し、具体的なパラメータやコンフィグレーション単位での推奨値の定義、セキュリティ上の考え方の紹介が行われている。（「セキュリティガイドライン Windows Active Directory編」）

テクニカルな観点で、OSを対象としたセキュリティ上の内部対策の具体的な内容を日本語で取りまとめた情報提供の取組は国内では限られており、その意味でも非常に有益なものと言える。

さらに、このWindows Active Directoryを対象としたテクニカルなセキュリティコンフィグレーションベースラインの検討・策定についてはマイクロソフト社の協力も得ている。その意味で、これらの推奨値はメーカが推奨する標準的なセキュリティ要件であり、サービス提供／利用者は必ず検討を行うことが望ましいものと言えるだろう。

また、情報の公開方式もドキュメント型ではなく、クリエィティブコモンズタイプのWiki型（https://www.softwareisac.jp/ipa/index.php）が採用されている。これにより、参照性・利用性の確保に加え、サイバー攻撃の動向等を踏まえた定期的なアップデートにより常に最新の情報にアクセスが可能な方式となっている。

最後に3点目となるが、セキュリティガイドラインによくある責任分界点の考え方に距離を置き、ユーザとIT企業双方のリスクコミュニケーションを通してセキュリティを相互補完的に確保することの重要性が考え方の中心に置かれている点である。

セキュリティガイドラインというと、自社として実施すべき対策・範囲の定義が先行し、その範囲における管理責任が十分に果たせているかという観点が前景化しがちである。その結果、セキュリティインシデント等が発生した際に「うちはガイドラインに基づいてここまでやっているから管理責任は果たしている」「うちは大丈夫です。問題は相手先にあります」云々という、自らの責任範囲を限定し、相手先に責任の所在を求める説明責任の取られ方が未だによく行われている状況である。このような説明責任のありかたは、昔ながらまだ通用したかもしれないが、様々なサービスが知らぬ間に多様に切り結び、ユーザ対IT企業の一対一の関係でセキュリティを論じることが既に出来なくなっている現在においては、ピントの外れたものと言わざるを得ないだろう。

一方、このガイドラインはDEOS IEC 62853 Open Systems Dependabilityを参照枠の一つとしている通り、サービス提供者／利用者それぞれが同じリスク認識（同じ物差し）のもとで、相手が何を行っているのか（リスク管理）／何を行っていないのか（残余リスク）を正しく共有（リスクに関するコミュニケーション）した上で、サービス全体のセキュリティを確保するために自らは何を為すべきかという「役割」をそれぞれが担っていく姿勢を重視している。つまり、リスク評価／対策の策定よりも、その結果に基づくリスクコミュニケーションを重視しているといえるだろう。前述の、テクニカルなコンフィグレーションスタンダードはそのための物差しの一つである。

民法改正後の契約不適合責任を回避するためには、ユーザとIT企業の関係は非対称的な関係でなく、共通の物差しに基づく対称的な関係のもとで、正しいリスクコミュニケーションを実施することを通した合意形成が重要となる。このコンセプトは単なる法令改正という観点のみでなく、DXの掛け声のもと、様々なものがネットワーク上で結びつこうとする現代において、セキュリティの確保を責任分界でなく、「役割」分担のもとで確保する姿勢の重要性を強調するものでもある。その意味で、このガイドラインは民法改正という法的コンテキストとDX時代におけるセキュリティのあるべき考え方を融合した観点より策定された、新たなセキュリティガイドラインといえる。

以上、「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」は今後のDX時代におけるセキュリティを検討する上で非常に刺激的な特徴を有していると考えている。

システム開発アプローチがウォーターフォールモデルを前提にしていること（アジャイル開発は今回対象外）、テクニカルなセキュリティコンフィグレーションの定義範囲がWindows OSに限定されていること等、今後の宿題はまだ残っているものの、未見の方は是非ご覧いただき、次のなつやすみに向けたご意見を頂ければ幸いである。

【著作権は、江原氏に属します】