OT資産管理の導入実務｜タイ工場の台帳・RFP・90日受入

OT資産管理をタイ工場へ導入するとき、ゴールは「ネットワーク上の機器を数えること」ではありません。PLC、HMI、SCADA、VFD、産業用スイッチ、エンジニアリング端末、保守PC、リモート接続経路を、設備の役割・構成・通信・変更・復旧証拠まで結び付け、現場が継続して差分を処理できる状態をつくることです。本稿では、受動検出と手動発見の組み合わせ、OT資産台帳の項目、RFP、90日PoCの受入試験を実務レベルで解説します。

OT資産管理を「検出ツール導入」で終わらせない

工場で資産管理プロジェクトを始めると、「まずネットワークをスキャンすれば全台見える」「高機能な製品を入れれば台帳は自動で完成する」という期待が生まれがちです。しかしOTでは、通信していない予備品、保守時だけ接続するPC、シリアル接続の機器、PLCの背後にあるリモートI/O、制御盤内のアンマネージドスイッチ、外部業者の一時接続などが存在します。逆に、観測したIPアドレス一つをそのまま一資産と数えると、冗長構成、複数インターフェース、NAT、交換後に再利用されたアドレスを誤認することがあります。

NIST NCCoEが2026年6月に公表したプロジェクト説明は、OT資産管理の実践的な方法として、自動発見と手動発見、インベントリ管理、構成管理、変更管理を組み合わせる構想を示しています。ただし、これは高レベルの参照アーキテクチャと実証候補を示すプロジェクト説明であり、完成した規格や認証制度ではありません。この位置付けを正しく理解すると、製品の検出率だけでなく、現場確認や変更承認までを調達範囲に含める必要が見えてきます。

また、NIST SP 800-82 Rev.3はOT固有の性能、信頼性、安全性を考慮してセキュリティを扱うよう示しています。したがって、ITで一般的な探索手順を生産ネットワークへそのまま持ち込むべきではありません。本稿では、設備・プロトコルごとの安全評価を終えていない能動スキャンを禁止し、既存通信を観測する受動検出と、承認済みの現場確認を基本にします。

この記事は、OTセキュリティ全体の統制や事故対応訓練を扱うものではありません。全体像はタイ工場のOTセキュリティ実務、通信基盤は工場無線LANと産業ネットワークの設計、対応訓練はOTサイバーインシデント対応訓練を参照してください。ここでは「何があり、どう構成され、何と通信し、いつ変わったか」を調達・受入・日常運用へ落とすことに限定します。

最初にOT資産管理の目的と境界を一枚にする

最初の成果物は製品比較表ではなく、対象と目的を一枚にしたスコープシートです。最低限、対象拠点、対象工程、稼働時間帯、停止可能時間、対象ネットワーク、対象外設備、台帳の利用者、意思決定に使う業務を明記します。

目的の例は「保有台数を把握する」では弱すぎます。調達仕様へつながる表現に変えます。

• 保守終了が迫る制御機器を工程重要度と組み合わせ、更新計画の優先順位を決める
• 無承認の接続や構成変更を、現場確認できる差分キューへ送る
• PLCやHMIを交換するとき、必要なロジック、設定、ライセンス、ツール、手順の所在を確認する
• リモート保守経路の所有者、承認期間、接続先、使用記録を追跡する
• 障害や演習後に、期待した資産が観測できているか、どの変更が未処理かを説明する

ここで重要なのは、セキュリティ部門だけのプロジェクトにしないことです。生産、保全、制御設計、IT、情報セキュリティ、品質、安全、購買、外部保守会社がそれぞれ異なる情報を持っています。資産の名称や型式は保全が詳しくても、通信関係は制御設計、アカウントやリモート接続はIT、停止影響は生産が詳しいことがあります。一部署だけで作った台帳は、入力項目が多くても現実を表さない場合があります。

資産の単位を先に定義する

「一資産」の定義が曖昧だと、製品Aと製品Bの検出数を比較できません。例えばPLC本体、通信モジュール、リモートI/O、電源を別資産にするか、制御システムの構成要素として束ねるかで件数は変わります。HMI端末上のランタイム、OS、プロジェクトファイルを物理端末と別の構成項目として扱うこともあります。

実務では、少なくとも次の識別子を分けます。

件数を一つに集約するより、「どの単位を何の意思決定に使うか」を定義する方が重要です。PoCのカバレッジも、IP数ではなく、対象資産母集団と識別規則に対して測ります。

受動検出と手動発見を組み合わせる

受動検出は、ミラーポート、ネットワークTAP、承認済みのセンサー配置などから既存通信を観測し、資産候補と通信関係を抽出する方法です。制御機器へ探索パケットを送らないため、OTの第一選択にしやすい一方、通信が発生しない機器や観測点の外側は見えません。受動だから自動的に安全という意味でもありません。ミラー設定の誤り、帯域、センサー障害、時刻ずれ、取得データの機密性、管理ポートへのアクセスを設計し、変更承認を通す必要があります。

手動発見は、単なる「現場を歩いてExcelに記入する作業」ではありません。図面、制御盤、銘板、保全台帳、予備品棚、エンジニアリングツールのプロジェクト一覧、スイッチ設定、バックアップ保管庫、VPN設定、外部業者との契約、現場担当者への聞き取りを、同じ識別子へ結び付ける統制された作業です。写真撮影の可否、盤を開ける資格、設備への接近、安全装備、生産への影響も事前に決めます。

観測点設計は工場ネットワーク可視化の成否を決める

一台のセンサーをコアスイッチへ置いても、すべてのセル通信が見えるとは限りません。同一VLAN内でスイッチングされる通信、ローカルHMIとPLCの通信、リング内の通信、シリアルゲートウェイの背後、セル内のアンマネージドスイッチ、無線経路などは観測点を通らない可能性があります。

RFP前に、論理・物理ネットワーク図へ次を重ねます。

1. 対象工程と安全上重要な設備
2. VLAN、サブネット、ルーティング境界、冗長経路
3. 管理可能スイッチとミラー可能ポート
4. TAP設置候補、電源、ラック空間、配線経路
5. リモートアクセス、保守用無線、携帯回線
6. 観測できない区間と手動確認の担当

この図は完成後も台帳の一部として更新します。センサーの「検出台数」が増えても、観測範囲が説明できなければ、カバレッジの分母を定義できません。

能動スキャンを実施できる条件

能動スキャンを一律に永遠禁止するのではなく、安全評価を通過するまで禁止します。実施を検討する場合は、対象機器・ファームウェア・プロトコルごとにベンダー情報と既知の制約を確認し、制御担当と安全担当が承認し、試験環境または限定区画で検証します。生産時間帯、要求レート、使用するコマンド、タイムアウト、停止条件、監視者、ロールバック、障害時連絡を変更票に残します。

「read-only」「safe scan」という製品表示だけを受入根拠にはしません。実際にどのパケットをどの頻度で送るのか、対象が応答しない場合に再試行するのかを確認します。PoCで許可していない能動通信が発生しないことをパケット証跡でも検証します。

OT資産台帳に必要なフィールド

良いOT資産台帳は、項目数が多い台帳ではなく、意思決定と差分処理に必要な値が、所有者と更新根拠付きで保たれる台帳です。すべてを自動取得できる必要はありません。むしろ自動観測値、手動確認値、承認値を区別する方が重要です。

資産識別と所有責任

構成・通信・アクセス

重要度・安全・ライフサイクル・復旧

NIST SP 1339は、OTバックアップを変更管理へ統合し、定期的に作成・試験し、復旧演習でレビューする考え方を示しています。PLC、スイッチ、ファイアウォール、トランスミッター、アクチュエーター、DCS、SCADA、VFD、HMIなどが対象例として挙げられ、復旧にはロジック、設定、I/O、ファームウェア、HMI資産、ライセンス、ツール、文書が必要になり得ます。台帳は「バックアップ有無」のチェック欄ではなく、何をどの版で、何を使って戻せるかへリンクすべきです。

出所、確認日、信頼度を必須にする

同じフィールドでも、受動観測による推定、銘板確認、メーカー資料、担当者申告では確かさが違います。値ごと、またはレコードの重要な属性ごとに、情報源、最終確認日時、確認者、信頼度、承認状態を持たせます。自動検出が既存値と異なったとき、すぐ上書きせず差分キューへ送ります。

「空欄を許さない」ために推測値で埋めると、見栄えは良くても意思決定を誤ります。unknownは品質上の失敗ではなく、調査対象を明示する正当な状態です。ただし、担当者と期限がないunknownは永久に残るため、ワークフローが必要です。

資産・構成・通信・変更履歴の正本を分けて結ぶ

OT資産管理で「どのシステムが正本か」という議論は、一つのデータベースへ全項目を押し込もうとすると行き詰まります。正本は情報の種類ごとに定義できます。

一つの製品が四つを保持しても、CMDB、保全システム、ネットワーク可視化、変更管理を連携しても構いません。重要なのは、同じ永続IDまたは管理された対応表で結び、優先順位と更新規則を決めることです。

例えば、受動検出でファームウェア版が変わったように見えても、その値を承認済み構成へ自動反映しません。観測レコードを残し、予定変更票、保全作業、現物確認と照合し、承認後にbaselineを更新します。逆に、承認済み変更が実施されたのに観測値が変わらなければ、作業未完了、観測不足、表示ロジックの問題を確認します。

IEC 62443-2-1:2024の公式概要は、稼働中IACSの資産所有者・運用者が持つセキュリティプログラムの方針・手順を扱い、20年を超える可能性のあるライフサイクルや、サポート終了したレガシー機器も認識しています。公開previewの目次には、CM1 inventory management、baseline、infrastructure documentation、configuration、change controlに関する項目があります。ただし本稿は規格全文を確認した適合評価ではなく、台帳製品の導入だけでIEC 62443-2-1適合を保証するものでもありません。

unknown・new・missingを継続照合する

台帳を初回に完成させても、翌日から現場は変わります。交換品が入り、保守PCが接続され、設備が停止し、IPが変わり、バックアップ版が更新されます。日常運用の中心は、現在の観測と承認状態の差分を、次の三状態へ振り分けることです。

• unknown: 観測されたが、承認済み資産または構成へ結び付かない
• new: 導入予定・交換・増設として認識され、承認フロー中または新規登録待ち
• missing: 承認台帳では存在・稼働予定だが、定義した期間に観測されない

unknownが即侵入、missingが即故障とは限りません。unknownは請負業者の承認済み保守PCかもしれず、missingは計画停止中の予備PLCかもしれません。だから検知状態とインシデント判定を分け、現場文脈で確認します。

差分処理の標準フロー

1. 生成: センサー、手動walkdown、変更システム、保全システムから差分候補を作る。
2. 重複統合: MAC、シリアル、スイッチポート、場所、機器fingerprintなど複数情報で同一候補を束ねる。
3. 優先付け: 安全影響、業務重要度、リモート接続、変更時刻、信頼度で並べる。
4. 割当: ライン・設備・技術領域ごとの担当へ送る。
5. 確認: 変更票、作業記録、現物、図面、担当者に照会する。
6. 処理: 承認して台帳へ反映、観測誤りとして閉じる、一時例外へ期限を付ける、または調査をエスカレーションする。
7. 学習: 誤検知原因、観測不足、識別規則を改善し、処理結果を監査可能に残す。

優先順位は単純な件数順にしません。安全影響が高いラインのunknownリモート経路、業務重要度が高いPLCのbaseline差分、サポート終了機器のmissingなどは先に扱います。一方、定期的に電源を切る予備品は観測期間を長く設定できます。

KPIは「登録台数」より差分処理能力を見る

有効な運用指標には、対象母集団に対する確認済みカバレッジ、必須項目の根拠付き充足率、未処理差分の年齢、重要差分の確認時間、承認変更と観測変更の一致率、バックアップ復元証拠の有効期限などがあります。

「検出資産数が増えた」は、重複が増えただけかもしれません。「unknownがゼロ」は、観測できていないだけかもしれません。KPIには分母、測定期間、対象外条件、データ品質を付けます。

RFPでベンダーへ要求すること

RFPは機能チェックリストではなく、対象環境、禁止事項、データ所有、統合、運用、受入証拠を伝える文書です。製品名を先に選ぶより、同じシナリオで提案とPoCを比較できる形にします。

1. 対象と制約

• 対象拠点、ライン、セル、VLAN、主要プロトコル、資産種別
• 24時間稼働、停止可能窓、冗長構成、安全上重要な区画
• 能動スキャン禁止。例外は個別安全評価と変更承認がある場合のみ
• データ持出し、クラウド利用、越境、ログ保管の社内条件
• 英語、タイ語、日本語での運用・支援要件

2. 発見と識別

• 受動検出で取得できる属性、対応プロトコル、推定方法、信頼度
• 通信しない資産を手動登録・一括取込・現場確認する手順
• 複数NIC、冗長機器、NAT、交換、IP再利用、仮想資産の同一性処理
• PLC、HMI、SCADA、VFD、産業スイッチ、エンジニアリング端末、保守PC、リモート経路の扱い
• 未知機器や未対応プロトコルを空白にせず、unknownとして保持する方法

3. 正本・変更・証拠

• 資産、構成baseline、通信関係、変更履歴のデータモデル
• 自動観測値が承認値を上書きしない承認フロー
• API、CSV/JSON export、時刻、監査ログ、履歴保持
• 保全システム、CMDB、ID、変更管理、バックアップ台帳との連携方式
• 製品を解約・移行するときに取得できるデータと形式

4. 運用とライフサイクル

• センサー停止、packet loss、時刻ずれ、保存容量超過の監視
• コンテンツ・解析ロジック・機器fingerprint更新時の影響とrollback
• 権限分離、MFA、管理操作ログ、サポートアクセス
• EOL/EOS情報の出所・更新頻度・顧客による訂正方法
• 誤検知、未識別機器、タイ現地支援、エスカレーションのSLA候補

5. 受入証拠

「可視化できること」では受け入れられません。母集団に対するカバレッジ表、パケット証跡、差分イベント、監査ログ、API export、構成バックアップとのリンク、障害・復旧記録、利用者手順書を提出物として指定します。

90日PoCを4つの受入ゲートで設計する

以下は説明用の仮定例です。日数、割合、件数、応答時間は市場標準ではなく、実際の工場の母集団・リスク・人員に合わせて承認してください。ここでは90日を、準備、観測、照合、運用試験、受入の五段階に分けます。

Gate 1: カバレッジ

PoC開始前に、既存の保全台帳、図面、制御プロジェクト、スイッチ情報、現場walkdownから「比較用母集団」を作ります。完全な正解ではなくても、何を分母にしたかを固定します。仮定例として、対象セルに100件の物理・論理資産候補があり、うち常時通信70、断続通信15、非通信・予備15とします。

受入では、「受動検出が95%」の一数字ではなく、種別ごとに自動検出、手動確認、未確認、重複を示します。非通信資産を手動で正しく登録でき、受動観測と同じIDへ結べることも試験します。対象外は理由と承認者を記録します。

Gate 2: 安全な発見

PoCの監視区間で、許可していない探索・書込・設定変更の通信がセンサーから送信されていないことを、構成、ログ、パケットキャプチャで確認します。ミラーポート設定によるループや帯域影響がないか、センサー停止が制御通信へ影響しないかも確認します。

仮定試験では、センサー電源断、管理ネットワーク断、保存容量の警告、時刻同期喪失を起こし、制御への影響がなく、監視側に状態が通知され、復旧後にデータ欠落期間を説明できることを確認します。能動機能は無効化した設定画面だけでなく、通信証跡で検証します。

Gate 3: 変更検知と継続照合

承認済みの試験変更を用意します。例えば、テスト用HMIのIP変更、許可済み保守PCの一時接続、PLC構成情報の版更新、スイッチポート移動、予定停止によるmissingを実施します。各変更が観測され、期待するnewまたは差分状態になり、変更IDと照合され、担当者が承認・却下・例外化できることを確認します。

次に、変更票がない状態を模擬し、unknownとして別経路へ上がることを確認します。重要度や安全影響で優先順位が変わるか、通知を閉じても証跡が残るか、baselineが勝手に更新されないかを見ます。

Gate 4: 復旧証拠と引継ぎ

選んだPLC、HMI、スイッチ、VFDについて、台帳から必要なバックアップ、設定、ロジック、firmware情報、engineering tool、license、I/O文書、復旧手順へ到達できるかを確認します。ファイルが存在するだけでなく、承認された試験環境で復元または読出し確認した証拠へリンクします。本番設備への無計画な復元は行いません。

最後に、ベンダー担当者が操作するのではなく、工場の運用担当がunknownを受け取り、根拠を調べ、台帳へ反映し、週次レビューを実施します。担当者が運用できない仕組みは、デモが成功しても受入完了ではありません。

90日PoCの受入テスト表（仮定例）

次表はRFP添付用のたたき台です。すべて仮定であり、数値は工場が承認した値へ置き換えます。

T05の15分やサンプル20件は例であり、保証値ではありません。検出の速さだけを上げると、短時間の一時通信を大量に拾い運用負荷が増えることがあります。重大度ごとに通知時間を分け、確認の正確性と両立させます。

導入後の運用設計

本番移行後は、日次、週次、月次、変更時のルーチンを決めます。

日次

• 高重要度のunknown/new/missingとセンサー障害を確認する
• 新しいリモート接続、エンジニアリング端末、保守PCを優先する
• 期限切れ例外と担当未設定をエスカレーションする

週次

• 生産・保全・制御・IT/セキュリティで差分キューをレビューする
• 誤検知、重複、観測不足、古い図面を改善課題へ戻す
• 承認変更と観測変更の未一致を確認する

月次・四半期

• EOL/EOS、サポート契約、予備品、更新計画を見直す
• バックアップの鮮度、restore test、engineering tool/licenseを点検する
• 権限、外部ベンダーアクセス、センサー健全性、データ保持をレビューする
• 対象工程や観測点の追加・撤去をスコープへ反映する

責任分担では、ツール管理者と資産承認者を分けます。ベンダーが検出ロジックを更新しても、工場の承認baselineを自動変更できないようにします。現場の設備責任者は存在と用途を、制御担当は構成と通信を、ITは基盤とIDを、購買は契約とEOL情報を、管理者はワークフローと証跡を持つ、といったRACIを作ります。

タイ工場での実装上の注意

複数言語の資産名が混在する場合、表示名と永続IDを分けます。英語の標準種別と、タイ語・日本語の現場別名を持たせ、検索できるようにします。人名ではなく役割やチームを所有者に設定し、異動後も責任が切れないようにします。

外部SI、機械メーカー、制御ベンダーが保守する設備では、契約終了時に図面、プロジェクトファイル、パスワード引継ぎ、ライセンス、接続機器を回収できるか確認します。リモートアクセスはURLやVPN名だけでなく、入口、jump host、到達先、認証主体、承認期間、サポート連絡先、利用ログの所在を記録します。

Yokogawaは2026年9月15日、シンガポールにIndustrial Cyber Resilience Centerを開設すると発表し、東南アジアのOT cyber readiness支援を掲げました。これは地域の取り組みを示す最近の一例ですが、ベンダー発表であり、市場全体の需要や普及率を示す統計ではありません。導入判断は自工場の資産・停止・安全・保守の課題と受入結果に基づけるべきです。

よくある失敗と回避策

検出台数を競わせる

台数が多い製品が優れているとは限りません。重複、短命な通信相手、IT資産、対象外機器を含めて件数が増えることがあります。母集団、資産単位、重複規則、手動発見を含むカバレッジで比較します。

初回台帳の完成をプロジェクト終了にする

設備は変わり続けます。差分queue、担当、期限、承認、週次レビューまで受入範囲にします。90日PoCでは、実際に工場担当者が一巡処理します。

自動観測値で承認baselineを上書きする

観測は事実候補であり、承認とは別です。source、timestamp、confidenceを保ち、変更票と照合してからbaselineを更新します。

EOL一覧を作って終わる

サポート終了情報だけでは更新順位を決められません。業務重要度、安全影響、予備品、代替可能性、backup適合、復旧依存を合わせます。

バックアップの存在を復旧可能と見なす

ファイルがあっても、対応するツール、ライセンス、firmware、パスワード、I/O文書がなく、読めないことがあります。管理された環境で復元証拠を作り、台帳から辿れるようにします。

FAQ：OT資産台帳・工場ネットワーク可視化・IEC 62443-2-1

OT資産管理と一般的なIT資産管理の違いは何ですか？

OTでは、機器が物理プロセスを監視・制御し、安全、可用性、信頼性への影響があります。長寿命・レガシー機器、独自プロトコル、停止困難な設備、エンジニアリングツール、ロジックやI/Oなどの復旧要素を扱います。そのため、ITのエージェント配布や能動スキャンをそのまま適用せず、受動観測、手動確認、安全評価、変更承認を組み合わせます。

OT資産台帳には最低限何を入れるべきですか？

永続ID、種別、型式・シリアル、場所、業務・技術所有者、稼働状態、構成版、interface、通信相手、リモート経路、業務重要度、安全影響、EOL/EOS、backupと復旧依存、情報源、確認日、承認状態が基本です。すべてを一度に埋めるより、重要資産から根拠付きで充足し、unknownを処理する仕組みを優先します。

工場ネットワーク可視化は受動監視だけで十分ですか？

十分とは限りません。受動監視は観測点を通る通信に強い一方、停止中・予備・非通信の資産、シリアル区間、観測点外のセル、保守時だけ接続する端末を見落とします。図面、walkdown、保全台帳、制御プロジェクト、スイッチ設定、契約情報を組み合わせ、見えない範囲を明記します。

能動スキャンは完全に禁止すべきですか？

安全評価なしには実施しないのが原則です。対象機器、firmware、protocol、送信内容、rate、時間帯を確認し、ベンダー・制御・安全のレビュー、変更承認、限定試験、監視、停止基準、rollbackを整えた場合だけ検討します。「safe」という製品名称だけでは判断しません。

IEC 62443-2-1対応のために台帳製品を入れれば十分ですか？

十分ではありません。IEC 62443-2-1:2024は資産所有者・運用者のセキュリティプログラムに関する方針・手順を扱います。公式previewにはinventory、baseline、infrastructure documentation、configuration、change controlに関する項目がありますが、製品導入だけで適合を保証できません。正式な適合判断では、購入した規格全文と組織の適用範囲に基づく評価が必要です。

90日PoCで費用対効果を証明できますか？

PoCでは、検出と手動確認のカバレッジ、差分処理時間、変更との一致、EOL・backup情報の利用性、運用工数を測れます。ただし長期の停止削減額や事故回避額を、短期PoCだけで断定すべきではありません。既存の棚卸し工数、調査時間、監査準備、保守更新計画など、自社が測定可能な基準と比較します。

まとめ：OT資産管理は継続照合まで受け入れる

OT資産管理の成果は、きれいな台帳画面ではなく、受動検出と手動発見で対象を説明でき、PLC・HMI・SCADA・VFD・産業スイッチ・エンジニアリング端末・保守PC・リモート経路を根拠付きで結び、資産・構成・通信・変更の正本を保ち、unknown/new/missingを継続処理できることです。RFPには安全制約、データ所有、統合、運用、出口証拠を記載し、90日PoCではカバレッジ、安全な発見、変更検知、復旧証拠の四ゲートを、工場が承認した条件で判定します。

タイ工場でOT資産台帳の対象範囲整理、観測点設計、RFP、90日PoCの受入条件を検討している段階でも、TOMAS TECHへのお問い合わせからご相談いただけます。特定製品の導入を前提にせず、既存図面・保全台帳・変更手順を起点に、現場が運用できる評価項目へ整理します。

参考情報

• NIST NCCoE, “Asset Management as a Foundation for OT Cybersecurity” project announcement, 2026-06-25: https://csrc.nist.gov/news/2026/comment-on-nccoe-s-draft-ot-cybersecurity-project
• CISA and partners, “Foundations for OT Cybersecurity: Asset Inventory Guidance,” 2025-08-13: https://www.cisa.gov/sites/default/files/2025-08/joint-guide-foundations-for-OT-cybersecurity-asset-inventory-guidance_508c.pdf
• NIST SP 800-82 Rev.3, Final, 2023-09-28: https://csrc.nist.gov/pubs/sp/800/82/r3/final
• IEC 62443-2-1:2024 official overview: https://webstore.iec.ch/en/publication/62883
• IEC 62443-2-1:2024 preview: https://webstore.iec.ch/en/iec_catalog/product/preview/?id=L3B1Yi9wZGYvcHJldmlldy9pbmZvX2llYzYyNDQzLTItMXtlZDIuMH1iLnBkZg%3D%3D
• NIST SP 1339, “OT Backup Quick Start Guide,” Final, 2026-06-17: https://csrc.nist.gov/pubs/sp/1339/final
• Yokogawa, “Industrial Cyber Resilience Center,” 2026-09-15: https://www.yokogawa.com/au/news/press-releases/2026/2026-09-15/
• CISA, “Cross-Sector Cybersecurity Performance Goals”: https://www.cisa.gov/cybersecurity-performance-goals

*本稿は技術・調達検討の参考情報であり、法令・安全・規格適合の保証ではありません。設備への操作は、資産所有者の安全手順、メーカー情報、変更管理、現地法令に従ってください。*