第2回では、IIoTセキュリティプラクティス（本コラムにおける「Good practices for Security of Internet of Things in the context of Smart Manufacturing」）における具体的なIIoTのセキュリティ要件を見ていきたいと思います。
IIoTのセキュリティ要件は、ポリシー、組織的対策、技術的対策の3つに大別されています。ここでは、ポリシーと組織的対策について説明していきます。

ポリシー（PS-01～24）

ポリシー(Policies)は、IIoTセキュリティのレベル確保のために必要な方針や手順に関する要求事項を定めています。

図2　ポリシーの要件カテゴリ

ポリシーでは、大まかに以下の要件を定めていると言えます。

• - IIoTを構築するときは最初からセキュリティを考慮しましょう（セキュリティ・バイ・デザイン）
• - IIoTを構築するときは最初から個人データ保護を考慮しましょう（プライバシー・バイ・デザイン）
• - IIoTについてはツールなどを使って資産台帳を最新化しておきましょう（資産管理）
• - IIoTについては定期的にリスクマネジメントを行いましょう（リスクと脅威の管理）

1.1. セキュリティ・バイ・デザイン（Security by design）

セキュリティ・バイ・デザインは、製品開発の当初から適用されるべきセキュリティ対策です。ここでは、ライフサイクルの各段階におけるセキュリティ考慮や、デバイスの設計プロセスの初期段階からのセキュリティ考慮を求めています。（PS-01～05）

1.2. プライバシー・バイ・デザイン（Privacy by design）

プライバシー・バイ・デザインは、製品開発の当初から適用されるべきプライバシーおよび個人データの保護に関連するセキュリティ対策です。ここでは、GDPRなどの規制要件に沿ってプライバシー影響分析（PIA）を実行することや、個人データを他のデータと分離してセキュリティを確保することを求めています。（PS-06～10）

図3　ポリシーのセキュリティ要件1/2（PS-01〜10）
※ 図内のセキュリティ要件の略称は当社意訳

PS-01：	IoTのサイバーセキュリティをエンドツーエンドのプロセスではなく、マニュファクチャリングの開発ライフサイクル（SDLC）のすべての段階でデバイスおよびインフラストラクチャの観点からセキュリティ・バイ・デサインのアプローチを採用したサイクルとして取り扱うこと。
PS-02：	ネットワークレベルではなく、エンドポイントの組み込み機能を通じてサイバーセキュリティに対処すること。
PS-03：	セキュリティおよび安全性の評価後、適切であると判断された場合、識別機能と認証機能を備えた非常に限られた処理能力（アクチュエータ、コンバータなど）しか持たない最も基本的な接続デバイスでさえもIAM（ID及びアクセス管理）に関連するソリューションとの互換性を確保すること。
PS-04：	デバイスの設計プロセスのごく初期の段階から、サイバーセキュリティの専門家を含めてリスクと脅威の分析を行い、必要なセキュリティ機能が必要かを判断すること。
PS-05：	各設計ドキュメントには、工場の環境のすべての情報および制御システムのセキュリティを扱う章を含めること。
PS-06：	EU一般データ保護規則（GDPR）のような、該当する地域内および国際的な規制に基づいてプライバシーに関連する問題に対処すること。
PS-07：	機密データを収集または不必要に提供することを避け、設計フェーズ中にデバイスで処理されるデータの範囲と、この処理の目的を定義すること。
PS-08：	データストレージの物理的な場所を確立し、収集した個人データへのアクセスを許可された個人に限定し、どの組織間でデータを転送するかを定義すること。
PS-09：	デバイスによって処理されるデータのプライバシー影響分析（PIA）を実施すること。
PS-10：	例えば、IIoT環境内で転送された個人データの暗号化のように、個人の識別に使用できるデータを他の情報から分離し、セキュリティを確保すること。

1.3. 資産管理（Asset Management）

資産管理は、資産の検出、管理、監視とメンテナンスに関連するセキュリティ対策です。ここでは、資産管理ツールによる資産の検出や、一元化された資産台帳の整備を求めています。（PS-11～17）

1.4. リスクと脅威の管理（Risk and Threat Management）

リスクと脅威の管理は、Industry 4.0の環境に合ったリスクと脅威の管理手順の推奨アプローチに関するセキュリティ対策です。ここでは、インパクトドリブンのリスク管理アプローチを構築すること、トップダウンとボトムアップの2つのリスク管理アプローチを採用することを求めています。トップダウンとは、組織のビジネスニースを起点とする方法で、ボトムアップは、資産と人を起点にする方法です。（PS-18～24）

図4　ポリシーのセキュリティ要件2/2（PS-11〜24）
※ 図内のセキュリティ要件の略称は当社意訳

PS-11：	組織や工場の環境に特有の資産を動的に検出、識別、列挙できる資産管理をサポートするツールを活用すること。
PS-12：	会社に一貫した最新の資産台帳があることを確実にすること。
PS-13：	レガシーシステムを備えた複雑な工場の環境では、実現可能な場合は受動的な監視デバイスを使用するか、アクティブな監視ツールを検討する場合は導入前にテストフェーズを実行すること。
PS-14：	製造プラント内のコンピュータ化された環境全体に、集中管理された資産台帳を使用すること。
PS-15：	専用の管理ネットワークを介して、インフラストラクチャとセキュリティデバイスの管理によって資産のセキュアな管理を検討すること。
PS-16：	確立され、受け入れられ、伝達された変更管理プロセスに従う時のみ、新しいデバイスをシステムに導入すること。
PS-17：	ビジネス要件が満たされていない場合は、外部記憶媒体の使用を避け、USBポートを無効にすること。
PS-18：	新しいパラメータ、脅威、攻撃シナリオを考慮して、Industry 4.0とSmart Manufacturing専用のリスク管理アプローチを採用すること。
PS-19：	工場環境における重要インフラストラクチャに対し、企業、安全、環境などの側面に完全に対応した多数のリスク管理領域を確立すること。それらのリスク管理領域に対する脅威、脆弱性、および保護策を評価し、特徴付けること。
PS-20：	企業の個々のニーズとセキュリティ要件に従って、リスク管理プロセス及び脅威管理プロセスを確立すること。
PS-21：	少なくとも年1回、サイバーセキュリティの側面を含むリスク分析を実施すること。また、変更管理、インシデントハンドリング、脆弱性管理などの他のプロセスと統合すること。リスクアセスメントには、セキュリティポリシーとプロセスの有効性に関する技術的および手続き的テストが含まれている必要がある。
PS-22：	さまざまな情報源に依存し、信頼できる業界パートナー、ISAC、およびCERTと情報を共有することで、脅威インテリジェンスプロセスを企業の脅威管理アプローチに組み込むことを検討すること。
PS-23：	組織の観点から、選択した脅威を監視し、リスク分析を実行してシステムへの影響を判断すること。
PS-24：	リスク管理プロセスに関して、2つの異なるアプローチを同時に採用すること。トップダウンは、組織全体の視点からサイバーセキュリティへ対応すること。ボトムアップは、会社の状況について非常に細かく詳細な観点を提供すること。

組織的対策（OP-1～27）

組織的対策（Organizational Practices）では、IIoTの維持運用のための従業員や委託先などが守るべき組織のルールや責任等についての要件を定めています。

図5　組織的対策の要件カテゴリ

組織的対策では、大まかに以下の要件を定めていると言えます。

• - IIoTのエンドポイント機器のライフサイクルのすべての段階でセキュリティを考慮しましょう（エンドポイントのライフサイクル）
• - IIoTを作るとき、設計原則やネットワークのゾーニング等のセキュリティのアーキテクチャーを定めましょう（セキュリティアーキテクチャー）
• - IIoTについてはインシデントハンドリングのプロセスを確立しましょう。（インシデントハンドリング）/li>
• - IIoTについては脆弱性スキャンなどで脆弱性を検出し、対処しましょう。（脆弱性管理）
• - IIoTについては新規雇用時も、その後も継続してトレーニングを行いましょう。（トレーニングと意識向上）
• - IIoTについては第三者組織によるアクセスを適切に制限しましょう。（第三者組織の管理）

2.1. エンドポイントのライフサイクル（Endpoints lifecycle）

エンドポイントのライフサイクルは、調達プロセス、サプライチェーン、引き渡しフェーズ、攻撃およびend-of-life（製品の提供終了）を含む、製品のさまざまな段階（エンドデバイスおよびインフラストラクチャを含む）のライフサイクルにおけるセキュリティに関連するセキュリティ対策です。エンドポイント機器の発注、活用、廃棄等の各段階におけるハードとソフトのセキュリティの考慮を求めています。（OP-01～05）

2.2. セキュリティアーキテクチャー（Security Architecture）

セキュリティアーキテクチャーは、アーキテクチャーベースのアプローチとセキュリティアーキテクチャーの確立に関するセキュリティ対策です。アーキテクチャーベースのセキュリティを開発することを求めています。（OP-06～09）

図6　組織的対策のセキュリティ要件1/2（OP-01〜09）
※ 図内のセキュリティ要件の略称は当社意訳

OP-01：	エンドポイントライフサイクルのすべての段階でソフトウェアとハードウェアのセキュリティに着目すること。
OP-02：	サプライチェーン全体のセキュリティに関する考慮事項について考慮すること。
OP-03：	特定のデバイス/ソリューションに合わせたセキュリティ対策および要件を定義する調達プロセス全体のセキュリティ面を考慮すること。
OP-04：	さまざまな検証活動や製品ライフサイクルの段階で、技術仕様に対するサイバーセキュリティの受入れテストを実施すること。
OP-05：	プロジェクト実施プロセスの引継ぎ段階で、すべてのサイバーセキュリティ文書、プロセス、手順を適切に作成して渡すこと。
OP-06：	コンピュータ化されたエコシステムのセキュリティを確保するため、全体的なアーキテクチャーベースのアプローチを採用し、ビジネス要件に基づいてリスクに対応したセキュリティアーキテクチャーを開発すること。
OP-07：	セキュリティアーキテクチャーを定義する際に、組織の実装から物理的な実装に至るまで、すべての関連するセキュリティの側面が含まれていることを確認すること。
OP-08：	セキュリティアーキテクチャー内で、セキュリティに明確な役割と責任を割り当てること。 OTシステムとセキュリティプロセスの両方の役割を明確に定義し、伝達すること。
OP-09：	コンプライアンス施行コントロールを既存のセキュリティアーキテクチャーに統合し、すべての製品がその中で定義された要件を満たしていることを確認すること。

2.3. インシデントハンドリング（Incidents handling）

インシデントハンドリングは、Industry 4.0の環境で発生する可能性のあるインシデントの検出と対応に関するセキュリティ対策です。サイバーセキュリティのスペシャリストで構成されるOTサイバーセキュリティオペレーションセンター（SOC）の設立を検討すること等を求めています。（OP-10～13）

2.4. 脆弱性管理（Vulnerabilities management）

脆弱性管理は、脆弱性管理プロセス、関連する活動および脆弱性の開示に関するセキュリティ対策です。OT部門とIT部門の緊密な連携を確立することが求められています。（OP-14～18）

図7　組織的対策のセキュリティ要件2/2（OP-10〜18）
※ 図内のセキュリティ要件の略称は当社意訳

OP-10：	会社の領域および業務範囲に基づいて、組織に関連するサイバーインシデントを定義し、該当する基準に従って分類すること。
OP-11：	OTとITのサイバーセキュリティ専門家からなるサイバーセキュリティオペレーションセンター（SOC）の創設を検討し、サイバーセキュリティインシデントを適切な役割と責任のもとで特定のサポートラインに切り分けること。
OP-12：	影響を受ける資産の特定、脆弱性の特定および分類、エスカレーションおよび通知からなるインシデントハンドリングのプロセスを確立すること。
OP-13：	セキュリティ関連の異常なイベントをすばやく検出して調査すること。
OP-14：	組織内の包括的な脆弱性管理プロセスを定義すること。このプロセスでは、リスク分析の結果から、自動ツールと手動ツールの使用を含めること。
OP-15：	脆弱性を排除しながら、資産とシステムの重要性を考慮して、最も重要な脆弱性から対処を開始すること。
OP-16：	脆弱性の開示のための包括的で明確なプロセスを確立すること。
OP-17：	管理された環境で、または検証フェーズの前/中に、また定期的に、そしてシステムの重要な更新後に、新しいIIoTソリューションのペネトレーションテストを実施すること。
OP-18：	OT部門とIT部門の緊密な連携を確立し、システムのビジネスオーナーや意思決定機関および他のステークホルダーとの協力が有効であることを確実にすること。

2.5. トレーニングと意識向上（Training and Awareness）

トレーニングと意識向上は、セキュリティトレーニングに関する推奨アプローチおよびIIoTデバイスおよびシステムで作業する従業員の意識向上に関するセキュリティ対策です。IIoTによる新たな脅威をカバーするとともに、自分のデバイスの安全な使用法についてIIoTのユーザーをトレーニングすることを求めています。（OP-19～23）

2.6. 第三者組織の管理（Third Party Management）

第三者組織の管理は、第三者組織の管理および第三者組織のアクセスの制御に関連するセキュリティ対策です。第三者組織への製造レイヤへのアクセス制限や、第三者組織向けセキュリティ要件の開発を求めています。（OP-24～22）

図8　組織的対策のセキュリティ要件2/2（OP-19〜22）
※ 図内のセキュリティ要件の略称は当社意訳

OP-19：	組織のあらゆるレベルの従業員を対象とし、Industry 4.0関連の新たな脅威に対処する、従業員のセキュリティトレーニングと意識向上に関する包括的なアプローチを採用すること。
OP-20：	新しく雇用されたすべての従業員に、業務開始前にサイバーセキュリティトレーニングを提供すること。
OP-21：	セキュリティトレーニングが継続的、定期的、頻繁に更新されていることを確実にすること。
OP-22：	IIoTのユーザーに、IIoTデバイスとエコシステムを保護するために導入された技術を説明し、デバイスのセキュアな使用方法をトレーニングすること。
OP-23：	サプライチェーンを含む各分野レベルでの他企業とのコミュニケーションを検討し、セキュリティ意識を高めるため、組織間のディスカッション、協力、情報共有を可能にするために形成された国際的なセキュリティインフラストラクチャに参加すること。
OP-24：	制御レイヤまたは製造レイヤへの第三者組織のアクセスを厳密に制御すること。オンデマンドで、特定の時間枠で、特定の目的で、最小限の特権のアクセスのみを許可すること。
OP-25：	ベンダーに制御レイヤまたは製造レイヤのシステムへの直接接続を提供しないこと。必要で選択された機能とネットワークの一部にのみアクセスを許可すること。
OP-26：	サプライヤにそのプロセスのセキュリティと自社製品に対するコミットメントに関する情報を提供するよう促し、ベンダーおよびサービスプロバイダに対する専用のセキュリティ要件を策定すること。
OP-27：	セキュリティを含む第三者組織とのパートナーシップのすべての関連する側面を、適切な合意および契約の中で明確に定義すること。

第2回では、IIoTのセキュリティ対策のポリシー（Policies）と組織的対策（Organizational Practices）について解説しました。
次回は、技術的対策（Technical Practices）について解説したいと思います。

※ 当コラムにおける和訳は当社にて英文を翻訳したものであり、その内容について保証するものではありません。正確な内容が必要な場合は適宜、英文の原文を参照していただけますようお願いします。

参考資料

• Good practices for Security of Internet of Things in the context of Smart Manufacturing（ENISA）
  https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot
• Good practices for Security of Internet of Things（ENISA）
  https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot

Writer Profile

セキュリティ事業部
セキュリティコンサルティング担当 チーフコンサルタント
戸田 勝之

• セキュリティサービス