デジタルトランスフォーメーション（DX）の進展を受けて、企業はデジタル技術を活用して自社のコアビジネスをデジタル化することで、競争力を高めようとする動きが加速している。
一方で、DXにより生み出されるデジタルサービスにおいて、仕様のスキをつく攻撃によって、利用者や企業もしくはその両方の資産が毀損され、場合によってはビジネス自体が停止に追い込まれる事例もある。例えば以下のようなケースだ。
- 事例1：同一人物によって大量のアカウントを発行され初回登録のクーポンを大量に詐取された
- 事例2：付与したポイントが返品時に減算されない仕様を利用してポイントを詐取された
- 事例3：アプリでのパスワード再設定は多要素認証を求めていたが、コールセンター経由でのパスワード再設定は本人確認の甘さがあり他人によるなりすましが行われた
- 事例4：会員番号が数字で推測可能なものであり、会員番号がわかればチャージしたバリューが使える仕様になっていたため、会員番号が推測され他人によるなりすましでバリューが奪われた
上記の例は、従来セキュリティ対策として行われてきた脆弱性診断等でシステム基盤を安全な状態にしていても防げない。「デジタルサービスの仕様」に関わるリスク分析が必要となる。
このデジタルサービスのリスクを分析する際に必要になるのが「脅威情報」だ。
デジタルサービスにおいて脅威情報をどれだけ把握できているかというのは、デジタルサービスの生死にかかわると言っても過言ではない。しかし脅威情報は、ただ大量に集めてサービスの担当者に渡せばいいというものではない。
まず、当然ながらこれから作るデジタルサービスの名称で検索したとしても攻撃手法は出てこない。サービス仕様への攻撃は単一機能に対する攻撃ではなく、一見関係のない、遠くはなれた機能（往々にして別部署が担当している）をサービス提供側が予期しない利用を行うことで、サービスの「考慮外」の部分を突く。
自社のデジタルサービスに関連する脅威情報を適切な情報ソース、キーワードで検索して収集する作業が必要となる。これを「川上」とすると、サービスの担当者が理解できる形に加工して提供し、デジタルサービスでのリスク対応を検討するといった「川下」の対応まで含めて脅威情報の取扱い方法を考えなければならない。
ただ情報が提供されるだけでは現場はリスクを把握できず、リスクへの適切な対策もわからず、対策が行われないままデジタルサービスがリリースされてしまう。
本稿ではこの脅威情報、特に「サービス仕様への脅威情報」に焦点をあてて、その種類や目的に応じた活用方法について述べる。
ITシステムへの脅威情報とサービス仕様への脅威情報の違い
脅威情報について議論するとき、その情報が何を対象にした脅威情報（ITシステムへの脅威情報、サービス仕様への脅威情報）なのか、どのレイヤー（戦略・作戦・戦術）の話をしているのかなど、認識を合わせたうえで話をしなければ、話がかみ合わず議論が進まないことがある。
例えば以下のような情報のカテゴリを用意して、どの部分の情報について話をしているか認識を合わせながら議論を行うことが有効である。
図１．脅威情報の種類
「ITシステムへの脅威情報」は直接的な脅威であるため、もちろん重要ではあるが、本稿では、これまで疎かにされがちだった、上図右側の「サービス仕様への脅威情報」に焦点をあてて話をする。
脅威情報についての話をすると「ITシステムへの脅威情報」を前提としてイメージされることが多い。実際にベンダーに相談するとITシステムへの脅威情報を想定して、整理されたシステム・基盤の脆弱性情報が整理されたものを有償で提供（ディープウェブに相当）、一歩進んで、ダークウェブと呼ばれる通常のインターネット上に存在しない場所に存在する情報（自社に関連する不正プラグラム、漏洩したクレジットカード番号や会員情報等）の提供を提案されることがある。
一方で、「サービス仕様への脅威情報」については、ニュースサイト、ブログ、Twitter、掲示板等の公開情報であるサーフェスウェブに多く存在し、一部、会員登録して参照するようなコミュニティサイト（ディープウェブに該当）に存在する情報が有用となる。
このように、脅威情報にも様々な種類があるため、目的と利用方法に応じて使い分けを行う必要がある。「サービス仕様への脅威情報」の具体的な利用方法については、次節で説明する。
図２．利用目的に合わせた情報収集先
サーフェスウェブ：Google等のサーチエンジンで検索可能で、普通のブラウザでアクセス可能なサイト
ディープウェブ：インターネットに公開されているものの、検索できないようなサイト
ダークウェブ：普通のブラウザではアクセスできず、特殊なブラウザでのみアクセス可能なサイト
脅威情報を取得する目的と利用方法
デジタルサービスのリスクを把握し分析するために、「サービス仕様への脅威情報」を利用する場合、具体的に以下のような方法がある。
- ＜「サービス仕様への脅威情報」の利用方法＞
A.サービス企画時、過去に同様のサービスにおいて不正行為が行われていないかどうかの確認 - B.サービスリリース後、当該サービスに関わる不正行為の兆候がないかどうかの確認
＜利用方法A＞ サービス企画時、過去に同様のサービスにおいて不正行為が行われていないかどうかの確認
現状、多くの企業のDX案件では、サービス企画段階で事業部門の企画者や、システム化要件定義を行う担当者の経験や知識をもとにしたサービス企画が行われ、この担当者の知識・経験によってどれだけリスクが残存してしまうかが決まってしまう。
「賢者は歴史に学び、愚者は経験に学ぶ」という言葉がある。
担当者の知識・経験だけでなく、他社の事故事例（歴史）を参照することで、過去にあった手口で自社サービスに対して不正行為が行われることは絶対に避けなければならない。
この他社の事故事例を考慮したリスクへの対応が漏れてしまうと、不正が発生した時に、「なぜ以前他社で〇〇という事件があったのに貴社では対応をしていなかったか？」ということを問われたり、企業のレピュテーションの問題に波及して単なる不正行為の損害以上の被害が出てしまう可能性がある。
このため、デジタルサービスの企画・要件定義のタイミングで、当該サービスのビジネスモデルを分解して、どのような要素を含むのかを把握しなければならない。
例えば、ポイント、QRコード決済、サブスクリプション等である。情報収集の際はそういったビジネスモデル或いは機能名称だけではなく、他社類似サービス名称等を情報収集時のキーワードを考える必要もある。また収集した情報は、そのままでは関係者に理解できないことがあるため、例えば、収集した過去事例をもとに、不正の成立条件とこれを成立させないための対策を整理した脅威シナリオを作成してディスカッションするといったやり方が有用だ。
＜利用方法B＞ サービスリリース後、当該サービスに関わる不正行為の兆候がないかどうかの確認
前述のように「サービス企画時」にリスク分析を行っていても、リリース後、新たな不正の手口が見つけられることがあるため、リリース後もサービス仕様への脅威情報を継続して見続けなければならない。
ITシステムへの攻撃であれば、利用している製品の脆弱性情報を継続して確認し、パッチを当てることが主な対策となる。一方で、サービス仕様の穴をつく攻撃は正常に機能している製品を組み合わせで発生するため、サービス仕様の変更等、自社に適切な対策を考えなければならない。
いくつかの不正行為による事故事例をみると、実は不正が発生する前からその兆候はある。
図３．不正行為によるインシデントのライフサイクルと掲載メディアの関係
上の図は、不正行為によるインシデントの発覚前後のライフサイクルと掲載メディアの関係のイメージである。横軸で時間、縦軸で関連情報が掲載されるメディアを表現している。
前述の利用方法Aの「サービス企画時の確認」は他社のインシデント事例の参照が中心となるため、他社でインシデントが発生、発覚後、炎上、収束した後にニュースサイト（IT系ニュースサイト、各種オンラインメディア）や伝統的メディア（新聞・テレビ、雑誌）でまとめられた記事を参照することができる可能性がある。
一方で、自社サービスリリース後は、インシデント発生前の予兆をできるだけ早くつかむ必要がある。具体的には、上図の”不正行為の兆候”の範囲にある情報を能動的に取得しなければならない。
発覚前（不正行為の兆候の範囲）は、ソーシャルメディア（Twitter、5ちゃんねる）や個人のブログに断片的な情報として、関連する脆弱性や、不正行為・迷惑行為のアイデアや実際にその行為が成立した自慢等が書き込まれる。
特に発覚前に書き込みのあるソーシャルメディアやブログでは、社名やサービス名、技術名が「隠語」で書き込まれていて、一般の人が読んでも意味がわからない記載になっている場合もある。
不正行為発覚前の兆候の検知とその後の対応はとにかくスピードが大事になる。複数担当者による輪番で、自社サービスについて影響力のあるインフルエンサー（Twitterの投稿者、ブロガー等）をフォローして発言をチェックしたり、5ちゃんねるの関連するスレッドをウォッチしておき、何か兆候があれば関係者に即時連絡、内容によって利用方法Aの確認時のような脅威シナリオを作成してディスカッションを行うという対応を行っている企業もある。
上記の脅威情報の収集・利用方法は、一例である。攻撃者は常にサービス仕様の穴をねらい進化を続けるため、攻撃者が何に注目してどう攻撃してくるか、市場の動向、新技術の動向、攻撃者の動機の動向等に依存する。また攻撃を受けた時の風評ダメージはメディアの動向や有識者の考え方の動向等に依存する。このため、何の情報を収集すべきか、あるいは情報収集先の判断には高度なノウハウ、情報の蓄積、日頃からの慣れが必要である。
情報収集は誰が行うべきか
ではこれまで述べてきた「サービス仕様への脅威情報」の収集は誰が行うべきなのか？
サービス仕様を把握している企画担当者が企画中のサービス内容を踏まえて情報収集を行うことが望ましい。さらに言えば、この担当者がサービス企画、業務要件定義から次のステップであるシステム要件定義に適切に仕様を連携し、システムとしてリリースする前にはリスクへの対策がすべて対応された形でシステム実装されたかどうか確認までできる担当者であることが理想的だ。
しかし、実際に各サービス企画担当に対応を任せるとサービス企画担当によって情報収集量、把握できるリスク量に差が出てしまう。
以前、本ブログにおいてサービスに潜むデジタルリスク検討を行う態勢として、DSIRT/SSIRTという組織の必要性を説明させていただいた。まさに上記情報収集の支援を担うのがDSIRT/SSIRTである。
もちろん情報収集はDSIRT/SSIRT単独で行うものではなく、サービス企画担当者との共同作業が不可欠である。デジタルサービスの仕様を理解せずに、有用な情報を見つけるのは困難である。したがって、サービス企画担当に要件を確認しながら、DSIRT/SSIRTが目的にあった情報収集・提供を行う体制を作ることが肝要だ。
おわりに
本稿では、DXに関わる脅威情報の取扱いについて述べた。NRIセキュアでは、DXにおけるリスクを分析する活動（サービスリスク分析）や、このリスクへの対応組織であるDSIRT/SSIRT構築や実行支援を行っており、この活動の中で脅威情報の収集・分析・共有の支援を行っている。
DXに関わるリスクや、脅威情報、対応組織についてお悩みがあればぜひ一度気軽にご相談いただきたい。
