カメラシステムは、それを設置した企業よりも長く使われ続けることが少なくありません。今回のHelp Net Securityのインタビューでは、Hikvision EuropeのEMEAサイバーセキュリティディレクターを務めるRob Janssens氏が、施工業者がいなくなり、ドキュメントが失われ、誰も管理者権限を持っていない状況で何が起きるのかについて語ります。
同氏は、顧客が自力で制御権を取り戻せる製品設計がなぜ必要なのか、そしてセキュア・バイ・デフォルトの設定が、ありがちな設置ミスによる被害をどう軽減するのかを説明します。さらに、ソースコードエスクロー、原産国規制、そしてベンダーが重要インフラ事業者に提示できる証拠とできない証拠についても論じています。
多くのカメラ資産は、設置した施工業者よりも長く使われ続けます。6年目になって施工業者が廃業し、導入時のドキュメントが失われ、誰も管理者権限を持っていない場合、運用上何が起こるのでしょうか。
この業界が認めたがらないものの、実はこうした状況は珍しくありません。カメラの稼働寿命は10年に及ぶこともありますが、それを設置した企業が5年後に同じ形で存在しているとは限りません。人は転職し、契約業者は入れ替わり、ドキュメントは失われていきます。
メーカーの立場としては、この現実を受け入れなければなりません。システムを所有しているのは顧客です。顧客は、制御権を維持するために特定の施工業者に依存すべきではありません。
だからこそ、基本を押さえることが非常に重要なのです。デバイスには、安全なアクティベーションプロセス、適切なアカウント管理、アクセスを復旧・リセットする管理された手段、ファームウェアの保守、そして何が起きたのかを顧客が把握できるだけの十分な監査情報が必要です。当社では、アクティベーション時のパスワード作成を必須とし、ログイン失敗の監視、IPフィルタリング、SSHアクセスの制御を義務付けています。これらは有用な制御策ですが、デバイスが顧客の所有物として維持・管理され続けて初めて正しく機能するものです。
もう一つ、今後さらに進むと見ているのが資産管理の高度化です。セキュリティチームは、デバイスの発見や設定確認、通常の管理体制から外れてしまったシステムの特定を格段に得意になってきています。AIはそこで役立つでしょうが、私はAIを基本的なガバナンス問題の答えにするべきではないと考えています。第一に求められるのは、依然として所有権、ガバナンス、そして文書化された復旧プロセスです。
施工業者がいなくなり、顧客が自社のカメラを管理できなくなるのは、ライフサイクル上の問題です。メーカーは、顧客が元の施工業者に頼らずとも制御権を取り戻せるような製品設計をすべきです。
物理セキュリティ機器のかなりの部分は、価格重視で購入する調達チームが選定し、電気工事業者が設置し、その後二度と触られることがありません。あなたのハードニングガイドを読まないような販売チャネルに向けて、どのように設計しているのでしょうか。
こうしたシステムがどのように設置されているのか、現実的に捉える必要があります。すべての施工業者が長大なセキュリティマニュアルを読み、5年後もそれを覚えている、という前提でセキュリティ戦略を組み立てることはできません。
だからこそ、製品側がより多くの役割を担わなければなりません。
例えば、汎用の初期パスワードのまま機器を出荷するより、デバイスのアクティベーション時に新しいパスワードの設定を要求する方がはるかに優れています。不要なサービスは、たまたま利用可能だからといって単純に公開されるべきではありません。リモート管理は制御された形で行われるべきであり、デバイスは安全な選択が容易な選択となるように作られるべきです。
ここで、セキュア・バイ・デザインとセキュア・バイ・デフォルトの違いも重要になります。セキュア・バイ・デザインとは、開発、テスト、保守の全過程を通じてセキュリティが考慮されていることを意味します。セキュア・バイ・デフォルトとは、顧客がある程度安全な初期設定を得るために、わざわざセキュリティの専門家になる必要がないことを意味します。
当社のセキュア開発ライフサイクルは、要件定義と設計から、開発、検証、リリース、保守に至るまで製品全体をカバーしています。これは業界にとって正しい方向性です。セキュリティは、設置プロジェクトの最後に付け加えるようなものであってはなりません。
もちろん、いかなるメーカーも、あらゆる不適切なネットワーク設計を補うことはできません。誰かがカメラを直接インターネットに接続し、制御機能を無効化し、パッチも当てずに放置すれば、依然としてリスクは残ります。しかし、ありがちなミスに対する耐性を、製品側で格段に高めることは可能です。
顧客が5時間ではなく5分でリモートアクセスを使えるようにしたいがために、セキュリティ機能を意図的に無効化した状態でデバイスを導入している施工業者に対しては、どう対応しますか。
まず、何が、そしてなぜ無効化されているのかを正確に把握したいと思います。リモートアクセスには正当な運用上の要件がありますが、「動く」ことと「安全である」ことは同じではありません。
施工業者が意図的にセキュリティ制御をオフにするのであれば、顧客はそれが何を意味するのかを知っておくべきです。その判断は、インストールスクリプトの中に隠されたり、単に早いからという理由だけで下されたりするべきではありません。
ここには製品側の責任もあります。リスクの高い設定は、誤って変更できてしまうようなものであってはなりません。ユーザーはセキュリティ制御が弱められたことを確認できるべきであり、重要な変更には監査証跡が残されるべきです。
リモートアクセスの問題に対するより良い答えは、通常セキュリティを無効化することではなく、アーキテクチャにあります。アクセスを制限し、適切なセキュアプロトコルを使用し、映像ネットワークをセグメント化し、実際に必要なサービスのみを公開することです。例えば当社の製品セキュリティガイダンスでは、システムを直接インターネットに公開するのではなく、リモートアクセスを制限し、VPNなどのより安全な手法を用いることを推奨しています。
顧客がリスク判断を一切下さないふりをするつもりはありません。実際には判断しますし、そこには十分な運用上の理由がある場合もあります。私たちの責任は、そうした判断を可視化し、顧客が出発点とできる安全なベースラインを提供することです。
脅威環境自体も変化しています。自動スキャンによって、以前なら何カ月も気づかれなかったであろう設定が、非常に短時間で発見されるようになっています。そのため、「昔からこうしてきた」という理由は、もはやセキュリティ上の論拠として通用しません。
欧州の複数の購入者は現在、ソースコードエスクロー、第三者によるバイナリ解析、あるいは原産国制限を要求しています。これらの措置のうち、どれを「セキュリティ・シアター」だと考え、どれが実際に製品を改善させたと考えますか。
これらの措置を単独で「セキュリティ・シアター」と呼ぶことには慎重になりたいと思います。それぞれが異なるリスクに対処しているからです。
独立したテストや脆弱性調査は有用です。社内チームが見逃したものを、別のエンジニアが発見できる可能性があるからです。バイナリ解析も、特に顧客がドキュメントだけに頼らず、デバイス上で実際に何が動作しているのかを理解したい場合には価値があります。
ソースコードエスクローは事情が異なります。事業継続性やサプライヤーリスクの観点から顧客がそれを求める理由は理解できます。しかし、ソースコードへのアクセスがあること自体は、その製品が安全であることの証拠にはなりません。安全な開発プロセス、コードレビュー、テスト、脆弱性管理、依存関係の管理、そして信頼できるビルド・更新プロセスは依然として必要です。
原産国要件はさらに複雑です。重要インフラを運用する顧客には、正当な法的・地政学的・サプライチェーン上の懸念があります。こうした要件には誠実に向き合う必要があります。同時に、国籍だけを理由に、客観的で技術的なセキュリティ評価を代替すべきではありません。重要なのは、どのような証拠と技術的制御が存在し、それらがどのようなリスクに対処しているのか、という問いです。
当社の立場から言えば、技術的な価値を持つ措置とは、継続的なフィードバックによるセキュリティテスト、脆弱性の開示、テスト、安全な開発要件、そして継続的な改善を生み出すものです。
だからこそ、透明性が重要になります。顧客はセキュリティがどのように扱われているかを尋ねることができ、必要に応じてその答えを検証できるべきです。
Hikvisionは米国の制裁下にあり、複数の欧州諸国で継続的な監視の対象となっています。重要インフラ事業者から「なぜ御社のファームウェアを信頼すべきなのか」と問われたとき、どのような証拠を提示し、何を証明できないのでしょうか。
まず申し上げたいのは、顧客は単にベンダーが「自社のファームウェアは安全です」と言うだけで信用すべきではない、ということです。顧客は証拠を求めるべきですし、私たちはその製品と顧客に見合った証拠を提示できるよう備えておくべきです。
これにはいくつかの要素があります。一つは開発プロセスです。Hikvisionは、自社のセキュア開発ライフサイクルや、設計、開発、検証、保守の各段階で用いている管理策について情報を公開しています。また、製品セキュリティ情報を公開しているほか、ISO/IEC 29147およびISO/IEC 30011の認証を受けた、非常に成熟した脆弱性報告プロセスを運用しています。
さらに、当社のAIはエッジ型です。つまり、外部接続を必要とせず、AIがカメラ上で直接動作します。当社はまた、ISO/IEC 42001認証を取得した業界の先駆者の一社でもあります。これは、AIマネジメントシステム(AIMS)向けのAI標準に特化した、世界初の認証可能な国際規格であり、AIガバナンスのための体系的な枠組みを提供するものです。この規格により、当社のAIシステムが倫理的で透明性が高く、安全であり、ステークホルダーの期待に沿ったものであることを確保できます。
もう一つの要素は製品そのものです。顧客は、認証、パスワード管理、安全な管理プロトコル、ファームウェア保護、更新機構といった点を確認できます。例えば、Hikvisionの製品セキュリティ文書には、パスワード要件と、新しいパスワードの設定を要求するアクティベーションプロセスが記載されています。また、ダウングレード防止機能や、管理者が有効化しない限りデフォルトでSSHが無効化されていることについても記載されています。
そして、独立した検証があります。顧客は独自のテストを実施したり、第三者によるアセスメントを利用したり、バイナリ解析やネットワーク解析を行ったりすることができます。これは、重要インフラ向けにビジネスを行う上で当然のことだと考えています。真剣な顧客であれば、サプライヤーに対して疑問を投げかけるべきです。
私たちが証明できないのは、特定のソフトウェアに脆弱性が一切含まれていないということです。責任あるメーカーやソフトウェアベンダーであれば、そのような主張をすることはできません。
信頼についても同様です。認証や白書だけで信頼を作り出すことはできません。より良いアプローチは、顧客が技術を評価するのに十分な情報を提供し、製品を改善し続け、脆弱性が報告された際には対応し、独立した監視を受け入れることです。私にとって、それは単に「私たちの言葉を信じてください」と顧客に求めるよりも、はるかに説得力のある立場です。
