DX推進により、様々な企業が、デジタル技術を組み合わせた新たなサービスを開発するようになった。これらのサービスは、利用者に新たな価値を提供することで顧客満足度を向上させ、企業の競争優位性を高めることに貢献をしている。その一方で、これらのサービスにはリスクが潜んでおり、これらのリスクに対して、適切にかつ、効率的に対処することが課題となっている。
本稿では、DX推進に伴うリスクについて、そしてそのリスクへの対処として有効な「セキュリティ・バイ・デザイン」の進め方、および実践するうえでのポイント・注意点について解説をする。
DX推進において対処が欠かせないリスク
デジタル技術を自社の強みと組み合わせ、製品・サービスの新規創出や高付加価値化、いわばDXにチャレンジする企業が増えている。
デジタル技術は実世界にある情報のデータ化と活用、自社や社外にある他のシステムとのシームレスな連携を通じ、企業が競争優位性を獲得する手段として注目されている。実際、当社にも、ITを事業の主軸としていない業界（自動車、流通、小売等）の企業様からDX推進に伴うセキュリティ課題の相談を受ける機会が増えてきた。
相談の背景には、DX推進において対処しなければいけないリスクの存在がある。では、そのリスクとはいったい何だろうか。ここではDX推進をする際に対処が必要なリスクを2つに分けて見ていきたい。
リスク① サービスリスク
1つめのリスクは実現しようとするビジネスモデルや、そこで取扱う情報・機能の性質に起因するサービスリスクだ。DXでは製品・サービスで取扱われる情報や機能がデジタル化される中で、その仕様（ビジネスモデルや利用者のユースケース）がリスクを内包する可能性がある。本稿ではこれをサービスリスクと称す。
サービスリスクの例としては金銭的価値のある情報を取り扱うサービスで、意図しない使用方法によりサービス提供企業や他の利用者の金銭が窃取されたケースがある。加えて、個人情報・プライバシー情報を取り扱うシステムにおける個人情報・プライバシー関連法令への違反といったコンプライアンス上の問題が発生したケース、IoT機器へのリモート操作のような現実世界に物理的影響をもたらすシステムに対する人命にかかわる危険や施設などへの影響が発生したケースが挙げられる。
リスク② システムリスク
２つめのリスクは基本的なシステム設計、コーディング、テスト、運用といった所謂システム開発・運用の不備がもたらす、システムへの侵害や改ざん・破壊、ヒューマンエラーや災害耐性の不十分さといったシステムリスクだ。
例えば、DXを支えるITインフラとしてWebアプリケーションを構築する場合、Webアプリケーションの安全性確保として、SQLインジェクションやクロスサイトスクリプティングといったWebアプリケーションならではの脅威への対応が必要となる。この対応が不十分な場合サイバー攻撃によるシステムの乗っ取りや利用者情報の不正窃取等が起こりうる。
また、当社がお客様のDX構想をヒアリングさせていただくと、IoT、スマートフォンアプリケーション、Webシステム、各種クラウドサービスといった複数のデジタル技術を組み合わせて実現されるケースが多い。その場合、採用する各デジタル技術の特徴に合わせた対策検討が必要だ。
DXを成功させるには、これらリスクを適切に管理する必要があるのは言うまでもない。さらに、リソースが有限なビジネスの現場では、リスクをコントロールするための対策や、その対策を決定していくアプローチは効率的であることも求められる。
そこで次章以降では上記に挙げたリスクのうち、2つ目に取り上げたシステムリスクに着目し、これを適切かつ効率的に管理する方法として、「セキュリティ・バイ・デザイン」を取り上げ、その実践のポイントを検討したい。
なお、当社では1点目のサービスリスクについても、リスク分析や対策実施といったご支援を提供している。[1]是非こちらも参考にされたい。
[1] https://www.nri-secure.co.jp/service/consulting/digital-service
安全な情報システムを効率的に実現する「セキュリティ・バイ・デザイン」
DXのインフラとなる情報システムが抱えるシステムリスクを効率的に対処するためにとり入れたい考え方がセキュリティ・バイ・デザインだ。まずはセキュリティ・バイ・デザインとは何か、改めて振り返りたい。
セキュリティ・バイ・デザインが実践される以前のシステム開発では、情報セキュリティ確保といえば、コーディング後の各種テストやセキュリティ診断の実施、そして運用面での対策検討を指していた。
しかし、この方法には問題がある。システムに致命的な欠陥が発見された場合、企画フェーズや設計フェーズに巻き戻してやりなおす必要が出てくるからである。
この状況に陥った場合、システムのオーナーは納期やコストを犠牲にして手戻りを実施するか、不十分な品質や残留するリスクを承知の上でシステムをリリースするかという苦渋の選択を迫られる。利用者への斬新かつ高度な体験価値のスピード感ある提供やその体験価値を支えるセキュリティ、そしてこれらを通じて期待されるビジネスへの貢献が求められるDXでは絶対に避けたい状況だ。
セキュリティ・バイ・デザインの潮流
そこでセキュリティ・バイ・デザインが役に立つ。セキュリティ・バイ・デザインは「情報セキュリティを企画・設計段階から確保するための方策」として日本では内閣サイバーセキュリティセンター（NISC）で2011年頃に提唱されたことなどをきっかけに認知が広がってきた。NISCの提唱から10年以上経過しているが、現在においてもその必要性・有効性は全く色あせていないどころか、より強調されていると認識している。
IoT、クラウドサービス、スマートフォンアプリケーション等のデジタル技術の利活用が急速に発展し、各デジタル技術に対応するセキュリティ確保が求められる一方、その活動には、システムの早期リリースや細かな改修へのニーズに応えるための効率性が求められるためである。
この潮流の現れとも読み取れるのが、2022年6月のデジタル庁による「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」の発行だ[2]。これは、政府情報システムの開発や運用業務に従事する関係者を主な読み手として、政府情報システムにおいてセキュリティ対策を確実かつ効率的に実装する手段として、政府機関のシステム開発の各工程で実施すべきセキュリティ・バイ・デザインとしての実施内容、要求事項が示された文書である。本書で取り上げられている考え方は政府情報システムに限らず、全ての情報システムで求められる観点や実践内容がまとめられている。
また、情報処理推進機構（IPA）はセキュリティ・バイ・デザインを実施する効果として、手戻りによる遅延の減少、コスト削減、保守性向上を挙げている。とくにコストの観点では、「設計時のセキュリティ対策コストを1とすると運用時のセキュリティ対策コストは100」であるという衝撃的な数値を公表している[3]。
セキュリティ・バイ・デザインはその文字が表す通り、セキュリティの確保を目的とした考え方だが、その過程を通じビジネス要件に直接現れない非機能要件を充実させる。その結果システムの信頼性やユーザビリティの向上といった体験価値の向上にもつながりうると考える。DXを成功させるためにセキュリティ・バイ・デザインの取組は必須といっても過言ではない。
セキュリティ・バイ・デザインはDX実現においてセキュリティを維持・向上に寄与するだけでなく総合的なコスト・納期(手戻り)リスクの低減につながる。
Webアプリケーションを対象とした、脆弱性に関するレポート・リサーチ
ここまで、DX推進にはデジタル技術の利活用に伴うリスクが存在し、その対処が必要なこと。また、そのうち、システムリスクへの対応を効率的に進めるには、セキュリティ・バイ・デザインを適用した取組が必要であることを述べてきた。それでは、セキュリティ・バイ・デザインはどのように進めていくのがよいだろうか。次章よりセキュリティ・バイ・デザインを実践するうえでのポイントや注意点を考えたい。
[2] 政府情報システムにおける セキュリティ・バイ・デザインガイドライン
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/2a169f83/20220630_resources_standard_guidelines_guidelines_01.pdf
[3] https://www.ipa.go.jp/files/000055823.pdf
実践のためのポイント① ガイドラインの活用
DXではIoT、スマートフォンアプリケーション等様々なデジタル技術を組み合わせ、未知で前例のないビジネスモデルに挑戦することもしばしばあるため、既存ガイドラインに頼るのではなく、リスクは何かをゼロベースで洗い出したのちに、これに漏れなく対処するリスクベースのアプローチが向いていると考える。
しかし、各リスクへの対策をゼロから考案するのには苦労が伴い、また、システム開発や特定技術への知見が無ければ品質の保証も難しくなる。また、DXを支えるデジタル技術それぞれに求められる技術的対策は、世間でノウハウが蓄積されているため、それらノウハウは是非活用したい。
これらを勘案すると、DX事業におけるセキュリティ・バイ・デザインの実践では、リスクベースのアプローチで対策を網羅することを目標としつつも、既にプラクティスが確立している領域については、ビジネスやシステムの特徴を捉えたガイドラインを上手く収集・選定し、補助輪的に活用できることが重要であると考える。
幸いなことにシステムを構成するデジタル技術毎の対策は参考になる文書類が多々存在する。発行者は政府機関、デジタル技術や業種を軸とした業界団体、ITベンダーと様々である。手前味噌で大変恐縮だが当社もWebアプリケーション、スマートフォンアプリケーション、IoTの3領域でセキュア設計・開発ガイドラインを提供している[4]。従って、これらの活用で既に確立したプラクティスを実践することで必要な対策を網羅できる可能性が高まる。
[4]セキュア設計・開発ガイドライン策定支援 / サービス・製品 / 情報セキュリティのNRIセキュア (nri-secure.co.jp)
ガイドライン活用における「落とし穴」
ここで、唐突ではあるが、アメリカのセキュリティ研究者のブルースシュナイアーの著書「セキュリティはなぜ破られたのか」の内容を一部紹介したい。本著では、セキュリティリスクへの対応要否を意思決定するためのフレームワークとして下記5つのステップを紹介している。
- 守るべき資産は何か
- その資産はどのようなリスクにさらされているのか
- セキュリティ対策によって、リスクはどれだけ低下するのか
- セキュリティ対策によって、どのようなリスクがもたらされるのか
- 対策にはどれほどのコストとどのようなトレードオフが付随するか
ここで上記フレームワークを紹介した理由は、ガイドラインの活用における注意点が読み取れると考えているからだ。多くのガイドラインでは③を中心とした、実施すべきセキュリティ対策の具体例や手順に言及しているが、その対策を実施する価値があるかどうかの判断は①、②、④、⑤の手順を経た、総合的な判断が必要となる。そして、その方法はガイドラインでは記載されてない自社のリスク感度や取り巻く状況を正確に把握する他ない。
これを掘り下げ、ガイドライン活用における注意点を2点述べたい。
1点目は、ガイドラインはシステムの状況を踏まえ、必要かつ適切なものを選定しなければいけないということだ。上記フレームワークでいえば、開発するシステムに関して①や②を正確に把握し、それに合致した適切なガイドラインが選定できることを指す。
世間に公開されているセキュリティに関するガイドラインは無数に存在しており、その内容は管理・技術、特定業界向け・全業界向け、プロセスの解説に主眼・個々の対策の列挙に主眼、特定の国や地域/法規に配慮・非配慮など、文書によってその性質は異なる。活用候補となるガイドラインを幅広く収集し、自社の業種や開発したいシステムの特徴等を鑑みて、何を採用すべきか判断しないとガイドラインを参照したのに考慮が足りなかったという事態になりかねない。
2点目は、対策を講じるべきかどうかの判断は、読み手が自身の状況を踏まえて判断する必要があることだ。これは上記フレームワークでいえば、開発するシステムに関して④や⑤を論理的・合理的に考え抜き、本当に必要な対策を取捨選択することを指す。
ガイドラインには一般的なセキュリティリスクに対する対策が記載され、併せて、その対策一つ一つに「必須」「推奨」等の形で分類が与えられていることが多いが、これは読み手が必ずそれに従わなければいけないということを意味していない※。
※但し、法令順守や規制対応として規定内容の厳格な準拠と認定を求められる業界基準や行政機関の基準、国際基準も存在する。
場合によってはガイドライン上では優先度が低いが、自社としてはニーズが高いと判断すべき対策や、逆に、高い優先度が設定されているが代替策が既に検討されている等の理由で自社としては対応不要と判断できる対策が紛れている可能性もある。
さらに複数のガイドラインを参照する場合は同種の対策に異なる優先度が設定されている可能性もある。従って、読み手は対策漏れや過剰投資を回避するために、自身が置かれている状況を鑑みたうえで、各対策が本当に必要なのかを判断する軸を持つことが欠かせない。
リスク対応要否意思決定フレームワークから見た、ガイドライン活用における注意点
以上、DXにおけるセキュリティ・バイ・デザイン実践のポイントとして、ガイドラインの活用を挙げさせていただいた一方で、これを実践する上で陥りがちな落とし穴を指摘した。では、この落とし穴をどう回避するか。これを更なるポイントとして論じたい。
実践のためのポイント② 専門家の伴走
DXを支えるシステム開発を進めるにあたり、リスク分析やガイドラインの収集・選定・活用等を自力で遂行することに不安がある場合は、専門家を伴走させることを考えたい。専門家の伴走は要員の一時的追加というコスト上のデメリットはあるが、以下、メリットによりセキュリティ・バイ・デザインの成功、ひいては、限られた納期で高い品質を持った、DXを支えるインフラとして不足ないシステムの実現を後押しできると考える。
メリット１．対策検討のスピードが上がること
ガイドラインの活用には選定段階で注意が必要であることは先述の通りではあるが、デジタル技術や業界に応じたセキュリティ対策に知見が深い専門家であれば、当該システムを取り巻く状況を踏まえて必要なガイドラインを迅速・適切に選定することができる。
さらに、専門家がそのガイドラインを適用するプロセスにも参画する場合は、他社への支援実績等で培った実行力を活かし、ガイドライン適用にかかる手間や時間を格段に減らすことができる。結果、徹底した対策検討がスピード感を持って進められる。
メリット２．世間動向・事例などの情報が得られること
ガイドラインを参照し要件や設計にセキュリティ対策を埋め込む現場では、例え対策の実施有無の判断基準を自社で確立していたとしても「世間ではこのリスクの大小をどう評価しており、それと比較し、自社の判断に見落とし等ないか」「現場が判断した内容を上層部にどう説明したらよいか」と判断や関係者との調整に苦労する場面が度々生じる。
その際に、世間動向、競合他社や業界での事例を得て、自社の状況を相対比較することで、意思決定が捗る場面も多い。多種多様かつ大小さまざまな企業を支援した実績のある専門家であれば、世間動向や他社・業界の動向に関する事例情報や見解を有しているため、これら情報の提供を通じ、腹落ち感のある意思決定をサポートすることができる。
終わりに
本稿では、DXの進展とそれにともなうリスクへの対処の必要性、そのうちシステムリスクに効率的に対処する方法としてセキュリティ・バイ・デザインの考え方を紹介し、さらにセキュリティ・バイ・デザインの実践におけるポイントや注意点を述べた。
DXを推進する現場では、顧客への新しい体験価値や期待される収益性、スピード感あるリリースが関心事となりがちだ。しかし、それは製品・サービスの安全性・信頼性という大前提があって成り立つものであると考える。ぜひ、一歩立ち止まっていただき安心・安全なDXを実現するためには何をどういうステップですべきか検討いただき、最初の一歩を踏み出していただきたい。
NRIセキュアではDXに挑戦するお客様をサポートするための各種コンサルティングやセキュリティサービス、ソリューションを取り揃えている。例えばIoT、Web、スマートフォン、クラウドといったDXで活用されるデジタル技術に軸足を置いたガイドラインのご提供や、お客様のDX事業にそれらガイドラインを適用したリスク分析や要件・設計策定の実行支援等が可能である。DX推進におけるセキュリティ課題をお持ちの方がいたら、ぜひ当社にご相談を頂ければ幸甚である。
＜関連サービス＞
デジタルサービス向けリスク分析支援
セキュア設計・開発ガイドライン
