自動テストシステムにおけるセキュリティの影響

製造業界のユーザにとって、次のシナリオは他人事ではありません。誰もが眠っている午前2時15分に電話が鳴り、無理やり起こされます。電話に出ると、緊急に対応しなければならない事態が起きたと言われます。

生産ラインCの製造テストシステムで製品の品質を保証するために使用している2つのプログラマブル ロジック コントローラ (PLC) が故障したため、製造ラインCが停止したと言うのです。30分前にPLCとの通信が途絶えたため、製造管理センターでは製造ラインが稼働できる状態にあるかどうかを判断できません。今月、すでにこのような問題が3件発生しており、これで4件目です。しかし、今回は製造チームが再発に備えて準備していたので、予備能力のある隣接する施設に生産をシフトできました。これで、生産量の減少を少しでも少なくできたのではないか期待しています。

数日後に、これらの障害はサイバーセキュリティによるインシデントだったことが判明しました。しかし、外部からの攻撃ではなく、原因は社内にありました。IT部門が最近、すべてのネットワークデバイスを夜間にスキャンしてセキュリティを評価することを始めました。これまでテスト機器はほとんどのITプロトコルから除外されていたのですが、監視対象外のネットワークデバイスが狙われるセキュリティリスクが大きすぎるということで、経営陣は方針を変更したのです。セキュリティソフトウェアが誕生する数十年前に開発されたPLCのソフトウェアアルゴリズムは原始的で、夜間のセキュリティスキャンを実行すると、2つのPLCが大量のネットワークパケットを処理できず、障害対応としてシャットダウンしたのです。

重要な問題点

テストシステムにITセキュリティを適用するという傾向が進んでいるのには、いくつかの理由がありますが、監視されていないネットワークデバイスを攻撃するサイバーセキュリティインシデントの増加が最も深刻な理由です。だれも、暖房/換気システムコントローラを狙ったサイバー攻撃によって、POSシステムが侵害されたTarget社のCEOと同じ目に遭いたくはありません。テスト装置が自社のITシステムから攻撃を受け、大きな生産損失が発生して経済的な損失が出る事態も、同様に耐え難いものです。

傾向が進んでいるもう1つの理由は、汎用ITシステムのセキュリティ対策とテクノロジの成熟しているためです。システムを保護して侵害を検出するために、ITセキュリティスタッフは、ネットワーク検出スキャナ、侵入検出テクノロジ、デスクトップのウイルス対策/監視エージェントなど、さまざまなツールを駆使できます。特定目的のテストシステムおよびデバイスにこれらのセキュリティベストプラクティスとテクノロジの適用を拡張することは当然の展開です。これらのプラクティスを使用してNIST SP 800-171などの規制基準に準拠する場合には特にそうです。

しかし、この傾向が理にかなわない理由も少なくとも2つあります。まず、IT対応のテストシステムは、構成に関する小さな変化に対しても耐性が低いのが一般的です。通常のITシステムを使用しているユーザであれば、ダウンタイムが発生しても許容することができ、アプリケーションのパフォーマンスの低下に気付かない場合もあります。それが特定目的のテストシステム (特に製造で使用されるシステム) では、許容できません。セキュリティパッチや新しいセキュリティ機能を適用することで発生するパフォーマンス特性の変化は、小さなものでもテスト結果や収集するテストデータの品質に悪影響を及ぼす可能性があります。同様に、製造テストシステムでは短時間のダウンタイムでも企業の収益に重大な影響を及ぼす可能性があります。

2番目に、テストシステムには固有のセキュリティニーズがあることがよくあります。テストシステムでは、通常、組織内の他のコンピュータで使用されていない特殊なテストソフトウェアが実行されているので、標準のITセキュリティ技術では対象としていない特別な周辺機器が装備されています。たとえば、正確な計測を行うために校正が必要なテスト周辺機器では、校正データが故意に、または意図せずに変更された場合、テストの品質が低下したり、無効になる可能性があります。これらのテストシステム特有のサイバーセキュリティリスクを考慮せずに、ITセキュリティ対策を包括的に適用すれば、安全が保護できるという間違った感覚に陥ることが懸念されます。

対応策 

テスト装置を保護するために推奨されるアプローチには、2つの重要なコンポーネントあります。まず、テストシステムにどんなITセキュリティ対策を適用するか、どの程度適用すべきかをIT部門にデータを使用して伝えます。データは、ITセキュリティスタッフとのリスクの評価や管理に関して話し合うための土台になります。2番目に、それらのITセキュリティ手段にテストシステム固有のセキュリティ機能を追加することで、固有のリスクに対処できます。こうすることで、標準的なITセキュリティ対策では対処できないギャップを埋めることができます。

データソースとして、年報のVerizon Data Breach Investigations Report (DBIR) が参考になります。Verizonは、前年に公表されたサイバーセキュリティ侵害に関するデータを解析して、このレポートで発表しています。2016 Verizon DBIRには、主要なソフトウェアベンダがパッチを発表した脆弱性を狙ったサイバー攻撃の解析が含まれています。ハッカーは、ベンダがパッチをリリースした時点からコンピュータへそのパッチがインストールされるまでの遅れを狙いました。ベンダのパッチを逆コンパイルして、パッチが適用されていないソフトウェアのどこに脆弱性が存在するかを見つけて、その脆弱性を攻撃するのです。ハッカーは大手ソフトウェアベンダをフォローして、パッチのリリースから2～7日以内に攻撃を実行します。

このデータを参考にすることで、お客様のテストシステムにパッチを適用する際のリスクをより正確に判断できます。リスクを減らすには、まずセキュリティパッチは、リリースから7日以内にインストールします。つまり、ソフトウェアベンダからの通知を監視し、パッチが適用可能かを評価し、影響を受けるシステムをすばやく再認定する必要があります。次に、テストシステムにインストールするソフトウェアの数を最小限に抑えます。これを事前に実行することに費やされた時間は、パッチ数の削減と再認証に要するコストの削減に即座に反映されます。これらの対策は、製造や生産などで使用されるリスクの高いテストシステムにとって特に重要です。

2番目の重要なコンポーネントは、ベンダ固有のセキュリティ機能を利用することです。たとえば、重要なキャリブレーションデータ、テストパラメータ、テストシーケンスがテスト品質を維持することがどれほど重要かを考えると、テストシステムとそのコンポーネント用に特別に構成されたファイル整合性監視やキャリブレーション整合性機能などの技術を使用することが重要です。同様に、テストシステムベンダが提供するセキュリティ関連のドキュメントを参照することで、どの会社がより優れたセキュリティを提供しているかを確かめることができます。

テストシステムの製造元に尋ねるべき質問

貴社のソフトウェアとWindows OSのセキュリティ機能との互換性を教えてください。

NIでは、Windowsセキュリティ機能との互換性を常にテストしているので、お客様はご使用の環境に応じて、必要なソフトウェアを有効にすることができます。すべてのNIアプリケーションソフトウェアは、標準ユーザ権限で実行できます。

セキュリティリスクを軽減するために、ソフトウェアコンポーネント「X」を安全に削除できますか。

NIソフトウェアインストーラでは、必要な製品だけをインストールし、必要な依存項目をすべて維持するようにインストールをカスタマイズできます。さらに、NIアプリケーションでは独自のカスタムインストーラを作成できるため、最小限のランタイム環境と依存項目でアプリケーションをデプロイすることができます。

テストソフトウェアとテストアプリケーションを保護するために、他にどのような安全対策を使用できますか。

追加措置として、ファイル整合性監視ツールを入手できます。NIでは現在、これらのタイプのツールを評価して、NIソフトウェアと動作するように構成する方法を調査しています。詳しくはNIまでお問い合わせください。

NIソフトウェアとハードウェアのセキュリティ情報はどこで入手できますか。

NIでは、ネットワークポートとプロトコル、Windowsサービス、メモリのサニタイズ、および重要なセキュリティアップデートに関するドキュメントを提供しています。

2014年に発生した工業用制御システムをターゲットにした悪意のあるソフトウェア (マルウェア) のニュースは、世間を驚かせました。これは、ハッカーが特定の工場の防御システムにリモートで侵入したり、秘密工作員が石油精製所のシステムにマルウェアをインストールしたのではありません。トロイの木馬を組み込んだベンダーソフトウェアを介してマルウェアをインストールしたのです。

このハッキングは発電所を狙ったもので、ロシアが発信源だと考えられたことから、「Energetic Bear」と呼ばれました。作戦の一部の対象となったのがサプライチェーンでした。彼らは、産業用制御システムソフトウェアを顧客がダウンロードできるWebサイトを提供しているソフトウェアベンダ3社を狙いました。ハッカーはWebサイト上のファイルにアクセスし、正規のベンダソフトウェアインストーラにマルウェアを組み込んで、Webサイト上の元の場所にそれを保存したのです。マルウェアは、トロイの木馬に感染したソフトウェアをダウンロードしてインストールした顧客に、またたく間に広がりました。ソフトウェアベンダとその顧客の両方が受けた経済的影響は不明です。

Kaspersky Labsが2010年に発見した、より洗練されたケースでは、早ければ2005年から複数ベンダの商用ハードドライブが侵害されていたことを示すサプライチェーン侵害があります。ハードドライブが正常に動作しているように見えていたハードドライブコントローラに組み込まれたファームウェアが改ざんされていました。機密情報と見なされる内容のコピーが、ファームウェアを含む不揮発性メモリの未使用領域に密かに保存されていたのです。変更されたファームウェアには外部との通信機能がないため、ハードドライブの使用を中止した後に、工作員がハードドライブを回収して機密情報を収集したと推測されます。廃棄する前にハードドライブの内容をサニタイズしても、機密情報は回復可能なのです。

重要な問題点

Energetic Bear工作におけるWebサイトの侵害方法は、テストシステム (または任意のシステム) の整合性がライフサイクル全体を通じてコンポーネントの整合性に依存していることを示しています。コンポーネントを使用する人が変わるすべての場所と、コンポーネントが長期間放置されたままになっている場所は、侵害される可能性が大きくなります。そのため、明確な管理方式を確立することが不可欠であり、各段階で侵害されたコンポーネントを保護して検出するための安全措置も重要です。

Kasperskyのハードドライブ侵害の発見は、世界の洗練されたハッカーがベンダの開発プロセスに侵入して、ベンダの非公開のソースコードにアクセスする手口を示しています。犯人は、ベンダのソースコードを不法に使用して、完全にインストール可能で機能的なバリアントを作成し、それを顧客がハードドライブを購入して使い始めたずっと後に、ハードドライブにアクセスして、インストールしました。

サプライチェーンの侵害においては、影響を受けない製品部分はありません。たとえ小さなプラグインやアドオンであっても、すべてのインストーラがEnergetic Bear工作によって侵害された可能性があります。厳密なセキュリティチェックをせずにフィールド更新を許可したハードドライブコントローラの小さなファームウェアでも同じことが言えます。

サプライヤの多様性と標準化のトレードオフを理解して、サイバーセキュリティリスクに対処する必要があります。多様化には、1つのサプライヤコンポーネントが侵害されても、システム全体に侵害が広がるリスクが減るという利点がありますが、この利点は、多くの場合、多種多様の機器に対して作業員をトレーニングしたり、すべてのサプライヤとの関係を管理するための持続可能性コストを上回ります。標準化することで、持続可能性コストは削減されますが、システム全体に侵害が及ぶリスクは高くなります。

対応策 

標準化には多くのコストメリットがあるため、侵害されるリスクが高いという以外には、サプライヤの多様化を正当化することは困難です。最も現実的なアプローチとしては、サプライヤのサプライチェーンセキュリティの評価をする際に、サプライヤの標準化を意思決定の重要な基準とすることが挙げられます。

ほとんど場合、サプライヤはすでに標準化に従っています。この場合、お客様とサプライヤは、どちらも関係を維持することにメリットがあります。サプライチェーンのセキュリティに対処するために最も重要なことは、サプライヤとよく話し合うことです。サプライヤに独自のサプライチェーンについて質問し、開発、製造、注文処理プロセス全体を通して製品の整合性を保護するために、どのような措置を実施しているのかを質問してください。プロセスの弱点を把握することで、サプライチェーンが侵害されるリスクを軽減し、サプライヤのセキュリティを強化できます。このような会話をしないと、両者ともに情報不足な状態で判断を下すことになります。

サプライヤとの話し合う際には、予防措置の他にも、、侵害を検知する方法を話し合う必要があります。ハッカーに十分な動機とリソースがあれば、どのようなセキュリティシステムも危険にさらされる可能性があります。システムに、いつ侵害が発生したかをどうかを検出するためのチェックポイントが十分あり、それらに対応できる明確な手順が準備されていることが重要です。Energetic BearのWebサイトの侵害のケースでは、検出メカニズムの最後の砦はインストーラのデジタル署名チェックですが、その検出メカニズムにより、インストールを中止し、ヘルプデスクにチケットが発行されるようにするには、適切な手順を定め、トレーニングを実施する必要があります。ハードドライブのファームウェアが侵害された場合、サプライヤのファームウェアアップデートの設計を調べると、インストールされているファームウェアの整合性を検証する方法がないことが明らかになります。

テストシステムの製造元に尋ねるべき質問

貴社から受け取ったソフトウェアが正当であることを確認するにはどうすればよいですか。

NIは、すべてのWindowsソフトウェアインストーラにデジタル署名を付け、お客様 (およびWindows) が、インストーラがNIからのインストーラであることを確認できるようにしています。さらに、NIではソフトウェアの提供を物理的に保証する安全なソフトウェア配布ソリューションを提供しています。NIソフトウェアは、開封されたことがわかるように梱包され、追跡可能な光ディスクに保存されています。また、他のパッケージのソフトウェアのファイル整合性を検証たるための検証ディスクを別途、配送します。

偽造部品やコンポーネントの改変からサプライチェーンをどのように保護していますか。

NIは、部品の調達先と最終製品の組み立て方法に関して、厳しい品質管理を実施しています。NIでは、製造およびテストに関わるスタッフに対してバックグラウンドチェックを行い、お客様に高品質の製品を提供するために、さまざまなチェックと管理を実施しています。詳細については、NIまでお問い合わせください。

ハードウェアキャリブレーションデータが改ざんされていないことをどのように確認できますか。

NIのハードウェアモジュールの長期のキャリブレーションデータを変更するには、パスワードが必要です。このパスワードは、Windowsパスワードの管理と同等の注意を払って管理してください。NIは現在、いくつかのハードウェアモジュールに対してキャリブレーション整合性機能を開発しています。この機能を使用すると、キャリブレーションが認定された後に、長期のキャリブレーションデータが変更されていないことを確認できます。

NI製品はベンダの多様化をどのようにサポートしていますか。

NIは、可能な限り業界標準に準拠することで、多くの他社製品との相互運用性を最大限、維持しています。たとえば、NI製品はPCI、PXI、IEEE、IETF、およびISO/IEC通信規格に準拠しており、IVIやOPC-UAなどの業界標準技術を使用しています。また、NIは多くの標準委員会に参加しています。

Edward Snowdenが国家安全保障局から機密情報を漏洩した事件は、インサイダーの脅威に対する注目を集める最大の原因となりました。彼の行動は、米国のテクノロジに対する不信を募らせる結果となり、テクノロジ業界に推定22～350億ドルの経済的損失を与えました。しかし、インサイダーによる脅威はこれが初めてではありません。

Omega EngineeringのTimothy Lloydは、1996年に引き起こしたインサイダー行為で悪名をはせました。それはまだMicrosoft Windows 95の時代で、サイバーセキュリティは主流メディアではほとんど取り上げられていませんでした。Timothy Lloydが特権を持つインサイダーとして達成した事件は、当時としては驚異的でした。彼は製造現場でシステム管理者をしていました。解雇されることを知った彼は、管理しているシステムからすべての製造ソフトウェアを指定した時間にシステム的に削除するソフトウェアをインストールしました。この時限的削除は、Lloydの解雇された翌日に最初に管理者が ネットワークにログインしたときに実行されました。この事故によりOmega Engineeringが受けた経済的影響は数百万ドルに上り、80人が解雇されました。会社も破産寸前まで追い込まれました。

重要な問題点

このような問題は多面的であり、今後も重要な研究トピックです。問題には、重要なテストシステムにアクセスできるすべての人 (雇用形態は問わない) に注意を払う必要があります。それには、ビジネスの最も重要な側面と、その側面で役割を担う人々、そして彼らの間でどのように権限が配分されているかを明確に特定することが必要です。このようなソリューションでは、一般的にかなりの程度の行動監視が必要となり、業務効率に必要な対人信頼に悪影響を及ぼす可能性があります。

インサイダー脅威の可能性は低いものですが、与える影響は大きく、2016 Verizon DBIRもそう主張しています。2015年に起きた64,000件を超えるサイバーセキュリティ事件のうち、インサイダーによる特権の悪用によるものは、わずか172件でした。インサイダー脅威の事件では、その75%以上は、外部からの支援や他のインサイダーとの共同工作なしの単独行為でした。

対応策

重要性の高いシステムを除いて、インサイダー脅威への対応は、これまでの傾向で説明した基本的なことに取り組んだ後に行うのが最適です。それらの傾向は、テストシステムが侵害される可能性が最も高い方法を示しています。

しかし、重要性の高いシステムでは、設計プロセスの早い段階でインサイダー脅威に対処する必要があります。システムの最も機密性の高い部分やミッションクリティカルな部分を特定した後、その職務を少なくとも2つの役割に分割し、1つの役割に両方の職務を割り当てられないようにする権限管理ソリューションを設計します。Verizon DBIRのデータによると、これにより、77パーセントの単独行為のケースから8パーセントの共同工作ケースに確率が移行します。

テストシステムサプライヤへの質問 

ソフトウェアのソースコードをどのように内部的に保護していますか。

NIでは、ソフトウェアソースコードに対して何重もの保護を施しています。変更を行うためには固有のユーザ名とパスワードを必要とし、アクセスは開発に関わるエンジニアリンググループのみに制限されています。またアクセス制御リストを定期的に確認しています。エンジニアリンググループは、コード変更はアクセス制御リストにあるメンバーからのみに制限するか、非メンバーからのコード変更を許可するかを選択できます。メンバー以外からのコード変更を許可するグループの場合、NIではこのようなソースコードの変更通知を必要とし、グループメンバーによるコードレビューを義務付けています。

テストシステムのサイバーセキュリティニーズに対応するのは容易ではありません。無限に存在する潜在的なセキュリティリスクに悩まされるか、あるいは圧倒されて何もできない状態に陥るかです。現実的には、十分なリソースと時間さえあれば、理論的にすべてのソリューションが侵害される可能性があるため、完璧なセキュリティは達成できません。そのような両極端ではなく、現実的なシナリオに基づいて問題に優先順位を付け、最初に重要な問題に対処し、その後は常識に従って対処していきます。

まず、関係者 (経営陣、ITセキュリティスタッフ、サプライヤなど) の間で、セキュリティ上の脅威に対処することは、関係者すべての重要事項であるという合意を得ることから始めます。この出発点は、サイバーセキュリティ脅威の性質と、セキュリティインシデントがもたらす潜在的な悪影響について、関係者全員の認識を高めるという利点もあります。次に、サイバーセキュリティのプロジェクト、トレーニング、テクノロジに時間と費用を割り当てます。テストシステムに対するサイバーセキュリティの脅威は現実であり、組織に経済的リスクをもたらすので、割り当てらてた組織のリソースはサイバーセキュリティのニーズを評価と対応に割り当てる必要があります。サイバーセキュリティの脅威が業務に与える影響を現実的に評価した後、それらのニーズに対応するために必要なリソースを割り当てます。

• NIセキュリティに関する詳細情報 
• テストシステム構築のベストプラクティスの詳細 
• テストシステムを構成する