AI時代に変わるPC調達の常識　価格・性能だけでなく「侵害後」をどう設計するか

AIの台頭　「検知」だけでは守れない時代に

　AIの普及により、脆弱性の調査やコード解析、標的にあわせたフィッシングメールの作成などを短時間で行えるようになった。サイバー攻撃は、人間には対応できない“マシンスピード”に変化していき、攻撃に必要な調査やコード作成のハードルが下がり、防御側の対応が追いつかない状況だ。

　特に課題となるのが未知の脆弱性を狙う「ゼロデイ攻撃」、修正パッチの適用が広がるまでの隙を突いた「ワンデイ攻撃」だ。攻撃者は、市販のソフトウェアやオープンソースソフトウェアのコードを分析し、脆弱性を探る。あるいは、修正前後のプログラムを比較し、どの欠陥が修正されたのかを推定して、攻撃コードの開発に結びつける場合もあるだろう。

　一方、企業では脆弱性の影響を受けるIT資産を特定し、業務への影響を確認した上で、パッチ適用の承認・配布を進める必要がある。その間に攻撃者は公開パッチの差分を解析し、修正内容を手掛かりに攻撃を試みる。つまり、パッチを全社展開するまでのタイムラグが攻撃者に悪用の機会を与えてしまう。

　近年のインシデントに共通する傾向として、木下和紀エドワルド氏は、正規の認証情報の悪用、管理ツールなど正規ソフトウェアの悪用、デジタル署名済みの要素を利用した防御回避を挙げた。これらは通常の業務操作と見分けにくく、挙動の検知を中心とする対策だけでは見落とすおそれがある。

　もし、侵入を見逃したまま攻撃が進行し、システムの暗号化・破壊に至ってしまえば、端末やサーバーを復旧させるだけでは事業を再開できない。安全性の確認や取引先との接続再開、監査、顧客・関係者への説明など、業務を通常の状態に戻すためには時間が必要だ。

　「本当に問うべきは、検知できなかった場合に何が起きるか、ということです」と木下氏。システムを復旧できるかだけではなく、検知をすり抜けた攻撃をどこまで封じ込め、事業への影響をどこまで抑えられるかを確認すべきだという。

　そこで、端末防御を「Detect（検知）」「Contain（封じ込め）」「Trust（信頼性の検証）」という、3つの観点でとらえることが大切だとする。建物の火災対策にたとえるならば、Detectは火災の発生を知らせる火災報知器、Containは火や煙の拡大を抑える防火扉、Trustは建物の基礎構造の健全性をたしかめる構造検査に相当するという。いずれも1つだけで十分なものではなく、うまく組み合わせることが重要だ。つまり、検知精度を高めるだけでなく、侵入後の被害を封じ込め、端末が信頼できる状態にあるかをOSよりも低いレイヤーで検証しなければならない。

OSよりも下層から「端末の信頼性」を担保する

　攻撃者が検知から逃れる手法を高度化させる中、標的はOSやアプリケーションだけでなく、BIOSやファームウェアにも及んでいる。そのリスクは端末の利用中に限らない。ハードウェアやファームウェアの開発・製造から物流まで、サプライチェーンの各段階でハードウェアやファームウェアが改ざんされる可能性がある。

　もし、利用者の手に渡る前にBIOSやファームウェアが改ざんされていれば、OS上で動くセキュリティ製品は、その改ざんされた状態を前提として動作することになる。OSよりも下層で起きた不正は、OS上の対策だけで十分に検証することが難しい。

　「OSやセキュリティ製品は、BIOSやファームウェア、ハードウェアが正しく動作していることを前提にしている。そこが改ざんされていれば、OS上で取得する情報や検知結果も信頼できなくなる。OSより下層の安全性を検証するためには、その仕組みが検証対象から独立している必要がある」（木下氏）

　そこで重要になるのが、OS上のソフトウェアとは独立したハードウェアに信頼の起点を置く「Root of Trust」の考え方だ。日本HPの実装例では、「HP Endpoint Security Controller（ESC）」が起動時にBIOSや重要なファームウェアの完全性を確認し、正当性を確認できないコードが実行されることを防ぐ。また、「HP Sure Start」という機能は、この仕組みを用いてBIOSや重要なファームウェアの改ざんを検知・復元するものだ。

　OS起動後に動作する対策だけでは、起動前のBIOSやファームウェアの改ざんを検証しにくい場合がある。HP Sure Startは、ESCを信頼の起点としてBIOSの完全性を検証し、改ざんや破損を検知した場合には、隔離された正常なコピーを使って自動的に復旧する。こうした仕組みが、端末を起点としたサイバーレジリエンスを支えるという。

　端末を調達する企業にとっても価格や性能だけでなく、製品の真正性や導入前後の完全性をどう確認するかが重要な検討項目になっている。

調達要件にも変化　「耐量子暗号」への移行は現実に

　長期運用する端末では、現在の脅威だけでなく、将来の暗号技術の変化も考慮する必要がある。量子コンピューターが暗号を解く能力を備えれば、RSAや楕円曲線暗号など、現在広く使われる公開鍵暗号の安全性が損なわれるおそれがある。この将来の転換点は「Q-Day」と呼ばれるが、その時期を正確に見通すことは難しい。

　木下氏は、「脅威はQ-Day当日に突然始まるのではない。前夜である現在、既に攻撃は始まっています」と述べる。その一例が「Harvest Now, Decrypt Later（今盗み、後で復号する）」だ。医療情報や政府文書、重要インフラ、産業システムの設計情報など、長期間の秘匿性が求められる暗号化データを収集し、量子コンピューターで復号できる時期まで保管することを指す。

　量子コンピューターの影響は、長期間秘匿すべきデータにとどまらない。端末を安全に更新しつづけるための、ファームウェア署名の仕組みにも関わる。PCや産業用IoT機器は、10年以上使われることも多い。もし、運用期間中に現在の署名方式の安全性が損なわれれば、攻撃者が正規の更新プログラムを装った不正なファームウェアを配布し、サプライチェーン経由で影響範囲が広がりかねない。

　こうした長期的なリスクを踏まえ、端末の調達時点から量子コンピューター時代を見据える必要があると木下氏は訴える。PQC（耐量子暗号）への移行計画を立てるだけでなく、ファームウェア更新が正規のものであること、ハードウェアを信頼の起点として検証する仕組みが必要になるという。

　そこで日本HPは、最新世代のEndpoint Security Controller（ESC Gen5）において、ファームウェアの完全性確認に、従来のRSA署名とLMS（Leighton-Micali Signature）を組み合わせて用いる。LMSは、量子コンピューターによる影響を受けにくいステートフル・ハッシュベース署名方式。ESC Gen5では、従来のRSA署名に加えてLMS署名も検証することで、将来の暗号移行を見据えたファームウェアの真正性確認を行う。これにより、将来の暗号移行も見据え、ファームウェアが改ざんされていないかをハードウェアレベルで検証する設計だ。

　耐量子暗号を遠い将来のテーマとして扱うのではなく、長期運用を前提とした端末調達の要件として検討すべきだと木下氏は訴える。既にNIST（米国立標準技術研究所）も最初のPQC標準の公開を受けて、組織に耐量子暗号への移行を促している状況だ。

侵害時の事業影響を抑える「端末起点」の隔離アプローチ　日本HPが提案する、隔離を軸とした端末保護

　AIを悪用したフィッシングや未知のマルウェア、正規の認証情報を悪用する攻撃に対し、検知を中心とする対策だけで対応することは難しい。木下氏は、こうした前提に立ち、日常業務で外部から持ち込まれるリスクと、侵害時の影響が大きい業務を分けて保護する考え方を示した。

　まず、外部から持ち込まれるリスクは、Web閲覧や電子メール、添付ファイルの開封などが起点となる。従来は、ファイルやURLをスキャンして安全性を判断した上で、ホストOS上で開く方法が一般的だった。しかし、未知の攻撃や検知を回避するマルウェアもあるため、入口での判定だけですべての脅威を防ぐことは難しい。

　そこで、日本HPが推奨するのは「HP Sure Click Enterprise」による隔離だ。これはWeb閲覧や添付ファイルの開封といった操作をホストOSから分離した、マイクロVM内で実行するもの。悪意あるファイルやWebコンテンツが含まれていた場合、その脅威はマイクロVM内に封じ込められる。Webブラウザ上のタブや添付ファイルを閉じさえすれば、破棄される仕組みだ。

　また、管理者権限での操作、基幹システムへの接続、クラウド管理コンソールへのアクセスなどを日常業務の環境と分けて保護することも重要だとする。たとえば、日常的にWebを閲覧しているような環境で特権操作を行えば、端末の侵害時に認証情報や管理者権限が窃取される可能性が高まるからだ。

　日本HPでは「HP Sure Access Enterprise」によって、特権アクセスのセッションをホストOSや他タスクから分離した仮想環境で実行。端末が侵害されている可能性も想定し、重要システムへの接続時には、日常業務で使用する環境と切り分ける仕組みだ。ハードウェア支援型の仮想化技術を利用し、特権アクセスのセッションをホストOSや日常業務の環境から分離して実行する。

　外部から持ち込まれるリスクをマイクロVMで隔離し、特権アクセスをともなう重要業務は別の仮想環境で保護。さらに、端末の起動時にはESCによってBIOSや重要なファームウェアの完全性を確認する。これらの組み合わせによって検知だけに依存せず、被害の封じ込めと端末の信頼性確認を組み合わせることで、侵害時の事業影響を抑え、継続・復旧を支える端末保護を目指す。

「守りのボーダーライン」をどこに置くか

　講演の最後、木下氏はセキュリティ対策と端末の調達基準を見直す必要性をあらためて示した。これからの調達では搭載機能の数や価格だけでなく、「検知できなかった場合でも、被害を抑えながら事業を復旧できる仕組みがあるか」を問うべきだという。

　AIを悪用した攻撃、サプライチェーンを介した改ざんリスク、将来の量子コンピューターによる暗号への影響など、企業を取り巻くリスクは変化している。検知や境界防御は引き続き重要だが、それだけで被害を防ぎ切ることは難しい。だからこそ、検知をすり抜けた場合でも影響を封じ込め、信頼できる状態へ復旧する仕組みを“端末の設計段階”から組み込むことが重要だ。

　防御の起点をネットワークやOSだけに置かず、ハードウェア、ファームウェア、隔離された実行環境にも広げる。木下氏は、このように防御を多層化することが、攻撃を受けた後も業務を継続・復旧するためのサイバーレジリエンスにつながると説明した。