V1: IoT エコシステム要件
Last updated
Last updated
開発前に実施されるシステムセキュリティ設計、およびシステム開発を継続的にサポートし、ライフサイクルのすべてのフェーズに統合されるセキュリティプロセスは、セキュアな製品アーキテクチャ実装を作るために必要な基本です。反復的なシステム脅威モデリングは製品設計ライフサイクルの一環として悪意に備えて緩和計画を策定するための手段となります。
セキュアな開発プロセスにより、IoT エコシステムに必要なすべての機密情報と機能の識別と文書化が保証され、決められたレベルですべてのセキュリティコントロールが実施され、エンドユーザーと顧客に脆弱性が通知され、セキュリティソリューションが時間通りに提供されます。以下の参考情報セクションに記載されている関連の OWASP 検証標準を開発プロセスの一部として組み入れるようにします。
サプライチェーンはすべての IoT 製品のセキュリティにとって極めて重要です。セキュアな開発プロセスではサプライヤとサードパーティコードに対してすべてのセキュリティ要件が適切なセキュリティレベルのコントロールを実装しているかどうか、また開発時の機能がデバイスに残されて脆弱性にさらされていないかどうかを検証します。
作成されたすべてのソフトウェアのセキュリティを確保するには、システムソフトウェアに対するビルドプロセスを、すべてのコンポーネントの完全性と真正性を検証するセキュアなビルド環境で実行する必要があります。コードは最善のセキュリティベストプラクティスを使用して記述し、利用可能な最善のセキュリティオプションを使用してコンパイルする必要があります。
システム構成の変更にはセキュリティイベントの監査証跡を提供するために適切なログ記録および監視機能を採用する必要があります。イベントの詳細を示す属性は調査に役立ちますが、機密情報を含む過度に冗長なログはセキュリティリスクをもたらします。
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
詳細については、以下も参照してください。
OWASP Threat Modeling: https://owasp.org/www-community/Application_Threat_Modeling
OWASP Software Assurance Maturity Model: https://owaspsamm.org/
OWASP Secure SDLC Cheat Sheet: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets_excluded/Secure_SDLC_Cheat_Sheet.md
Microsoft SDL: https://www.microsoft.com/en-us/sdl/
OWASP C-based Toolchain Hardening Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html
OWASP Embedded Application Security: https://owasp.org/www-project-embedded-application-security/
Banned C Functions (Safe Strings library): https://github.com/intel/safestringlib/wiki/SDL-List-of-Banned-Functions
NIST Draft NISTIR 8259D: https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259D-draft.pdf
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
1.1.1
IoT システムがデプロイされる環境によってもたらされる機能とリスクに応じたセキュリティレベル (L1, L2, または L3) で開発されていることを検証します。
✓
✓
✓
1.1.2
IoT エコシステム内のすべてのコンポーネントと通信チャネルが識別され、必要とされていることがわかっていることを検証します。必要ないものはすべて削除または無効にします。
✓
✓
✓
1.1.3
可能性のある脅威を特定し、セキュリティテストをガイドする適切なリスク対応を促進するために、各製品導入設計 (つまり新規および成熟) およびセキュリティ関連機能変更の一環としての脅威モデリングが使用されていることを検証します。
✓
✓
✓
1.1.4
セキュリティコントロールがサーバー側で実施されていること、およびデータと命令がサーバー側コンポーネントにより盲目的に信頼されてはいないことを検証します。
✓
✓
✓
1.1.5
責任ある開示ポリシーが確立されており、企業のウェブサイトで簡単に見つけられることを検証します。脆弱性を安全に伝達する方法とそれらをフォローアップする方法について、ポリシーが明確な概要を提供していることを確認します。
✓
✓
✓
1.1.6
脆弱性が製品に影響を与える場合、確立された通信チャネル (ウェブサイト、電子メール、セキュリティアドバイザリページ、変更ログなど) を通じてユーザーおよび関係する利害関係者に通知されることを検証します。
✓
✓
✓
1.2.1
エコシステム内の各アプリケーション (ファームウェアを含む) がサードパーティコンポーネント、バージョン管理および公開された脆弱性をカタログ化するソフトウェア部品表 (SBOM) を保守していることを検証します。
✓
✓
✓
1.2.2
サードパーティおよびオープンソースソフトウェアの使用に伴う潜在的なリスク領域が特定され、そのようなリスクを軽減するための措置が講じられていることを検証します。
✓
✓
✓
1.2.3
デバイスが (デバッグバージョンではなく) リリースビルドに適したセキュアなデフォルトで構成されたファームウェアでリリースされていることを検証します。
✓
✓
✓
1.2.4
デバイスを出荷する前に、デバッグインタフェース (JTAG, SWD など) へのアクセスが無効または保護されていることを検証します。プロセッサはこれをコード保護、リードバック保護、CodeGuard、またはアクセスポート保護と呼ぶことがあります。
✓
✓
1.2.5
FPGA のデバッグ機能が製品 PCB で無効化されていることを検証します。
✓
✓
1.2.6
ハードウェアベースで不変の暗号化された信頼ルートでデバイスがプロビジョニングされていることを検証します。
✓
✓
1.2.7
デバイスを顧客に出荷する前に、コード完全性保護メカニズムが有効であること、およびハードウェアがロックされていることを検証します。たとえば、セキュアブートが有効であること、およびブート構成がロックされていることを確認します。
✓
✓
1.2.8
バックドアが導入されていないことを確認するために、静的解析ツールを使用してサードパーティコードおよびコンポーネントが解析されていることを検証します。
✓
✓
1.2.9
半導体ドライバ、SDK、モジュール (例 5G, LTE, Bluetooth, Wi-Fi, ZigBee など) を含むすべてのコンポーネントを更新して、製品のサポートまたは保守終了ポリシーに沿ったセキュリティパッチを提供できることを検証します。
✓
✓
1.3.1
エコシステム内の各アプリケーションが安全で反復可能なビルド環境を使用して構築されていることを検証します。
✓
✓
✓
1.3.2
GPL ベースのファームウェアはそのソースコードが公開されており、機密情報やプロプライエタリ情報がプロセスに意図せず含まれていないことを検証します。
✓
✓
✓
1.3.3
禁止されている C/C++ 関数 (例 memcpy, strcpy, gets など) が安全な同等の関数 (例 Safe C, Safe Strings ライブラリ) に置き換えれていることを検証します。
✓
✓
1.3.4
パッケージが信頼できるソースからダウンロードおよびビルドされていることを検証します。
✓
✓
✓
1.3.5
ビルドパイプラインがバージョン管理システムで保守されているソースコードのビルドのみを実行することを検証します。
✓
✓
✓
1.3.6
コンパイラ、バージョン管理クライアント、開発ユーティリティ、およびソフトウェア開発キットが改竄、トロイの木馬、または悪意のあるコードについて分析および監視されていることを検証します。
✓
✓
✓
1.3.7
パッケージがオブジェクトサイズチェック (Object Size Checking, OSC) ありでコンパイルされていることを検証します。 (例 -D_FORTIFY_SOURCE=2)
✓
✓
1.3.8
パッケージが実行防止 (No eXecute, NX) またはデータ実行保護 (Data Execution Protection, DEP) ありでコンパイルされていることを検証します。 (例 -z,noexecstack)
✓
✓
1.3.9
パッケージが位置独立実行形式 (Position Independent Executable, PIE) ありでコンパイルされていることを検証します。 (例 -fPIE)
✓
✓
1.3.10
パッケージがスタックスマッシュ保護 (Stack Smashing Protector, SSP) ありでコンパイルされていることを検証します。 (例 -fstack-protector-all)
✓
✓
1.3.11
パッケージが読み取り専用再配置 (read-only relocation, RELRO) ありでコンパイルされていることを検証します。 (例 -Wl,-z,relro)
✓
✓
1.3.12
リリースビルドにデバッグコードや特権診断機能が含まれていないことを検証します。
✓
✓
✓
1.3.13
デバッグファームウェアイメージとリリースファームウェアイメージが異なる鍵を使用して署名されていることを検証します。
✓
✓
1.3.14
デバッグ情報に PII、資格情報、暗号化マテリアルなどの機密情報が含まれていないことを検証します。
✓
✓
✓
1.3.15
入力妥当性確認を実行し、ファームウェアコード、シェルコマンドラッパー、およびスクリプト内のパラメータをエスケープすることにより、組み込みアプリケーションが OS コマンドインジェクションの影響を受けないことを検証します。
✓
✓
✓
1.4.1
デバイスが認証試行の成功と失敗、デバッグ機能へのアクセスなど、セキュリティに影響するイベントに関するログを収集できることを検証します。
✓
✓
1.4.2
収集されたログには実行につながる洞察とアラートを有効にするのに十分な粒度があることを検証します。ログには少なくともイベントのタイプ、タイムスタンプ、ソース、結果、および関係者の ID を含める必要があります。
✓
✓
1.4.3
ログのタイムスタンプの妥当性を確認するために、デバイスには信頼できるタイムソースが含まれていること、または同期されていることを検証します。
✓
✓
1.4.4
収集されたログには PII、資格情報、暗号化鍵などの機密情報が含まれていないことを検証します。
✓
✓
1.4.5
収集されたログが、定期的またはオンデマンドで、オンライン収集を介してデバイスからセキュアに取得できることを検証します。
✓
✓
1.4.6
収集されたログが組織のポリシーで必要とされる期間保存され、保存期間が終了すると安全に削除されることを検証します。
✓
✓
1.4.7
収集されたログの機密性、完全性、真正性が、ログを作成したデバイスとログを保存または処理する他のシステムの両方で適切に保護されていることを検証します。
✓
✓