V3: ソフトウェアプラットフォーム要件
Last updated
Last updated
ブートローダーはデバイスのブートプロセス時に実行される最初のコードです。ファームウェアの製造元はブートローダーを正しく構成する責任があります。そうしないと、その脆弱性がデバイス全体のセキュリティを損ない、侵害やデバイスハイジャックにつながる可能性があります。この章のコントロールは、ロードされたコードの暗号署名を検証し、外部の場所からのイメージのロードを許可せず、ブート時のメモリ、シェル、その他のデバッグアクセスを禁止することにより、ブートの信頼性を確保します。
オペレーティングシステムとそのカーネルは特に、特権モードで実行され、多くのセキュリティプリミティブを含む重要なデバイス機能を実装するため、デバイスセキュリティの中心となります。これにはオペレーティングシステム、カーネル構成、および堅牢化のための最善のセキュリティプラクティスが必要です。
Linux オペレーティングシステムは IoT で最も人気のあるものの一つです。名前空間と cgroup によりサポートされる分離メカニズムや、アクセス制御用の追加のカーネルセキュリティモジュールなど、一次セキュリティから多層防御まで多くの機能があります。コンテナ内で実行するサードパーティアプリケーションを構成および展開する場合は、これらの分離メカニズムを活用します。
デバイスソフトウェアの更新と保守は製品のセキュリティにとって非常に重要です。アップデートシステムは設計と実装の一環としてセキュリティのベストプラクティスを採用する必要があり、デバイスが既知の脆弱性のない暗号署名されたソフトウェアのみを実行するようにします。パッチと脆弱性の管理プロセスでは、エンドユーザーを侵害から守るため、アップストリームセキュリティパッチが適用された新しいビルドを利用可能な最新バージョンとしてデプロイします。
ハードウェアセキュリティチップをソフトウェアプラットフォーム内にセキュアに構成および統合することで、デバイスは製造時にチップ内に書き込まれた暗号でアサートされた ID を使用できます。セキュリティチップには保存時に暗号化された鍵やシークレットを格納するための特権ストレージを提供する機能もあります。
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
詳細については、以下も参照してください。
ENISA - Baseline Security Recommendations for IoT: https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot/at_download/fullReport
CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks/
TGC Guidance for Secure Update of Software and Firmware on Embedded Systems: https://trustedcomputinggroup.org/wp-content/uploads/TCG-Secure-Update-of-SW-and-FW-on-Devices-v1r72_pub.pdf
U-Boot FIT Signature Verification: https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt
GSMA - IoT Security Guidelines for Endpoint Systems: https://www.gsma.com/iot/wp-content/uploads/2017/10/CLP.13-v2.0.pdf
OWASP Docker Top 10: https://owasp.org/www-project-docker-top-10/
Linux Containers Security (LXC): https://linuxcontainers.org/lxc/security/
Linux Containers Security (LXD): https://linuxcontainers.org/lxd/docs/master/security
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
3.1.1
ブートローダーがストレージ (SD, USB, など) とネットワークロケーション (NFS, TFTP, など) の両方を含む任意の場所からのコードのロードを許可していないことを検証します。
✓
✓
✓
3.1.2
ブートローダー構成は製品リリースで不変であることを検証します。
✓
✓
3.1.3
デバイスのブートプロセスのすべてのステージにおいて USB, UART などの通信インタフェースが無効化または適切に保護されていることを検証します。
✓
✓
3.1.4
ファーストステージブートローダーの真正性が、読み取り専用メモリ (ROM) の構成を変更できない信頼できるコンポーネントにより検証されていることを検証します。 (ハードウェアトラストオブルートを備えた CPU ベースのセキュアブート、トラステッドブートなど)
✓
✓
3.1.5
ブートプロセスの後続のステップを実行する前に、ブートローダーステージまたはアプリケーションコードの真正性が暗号で検証されていることを検証します。
✓
✓
3.1.6
デバイス起動の一部としてブートローダーステージに機密情報 (コンソールに記録された秘密鍵やパスワードなど) が含まれていないことを検証します。
✓
✓
3.1.7
ファームウェアが保存時に暗号化されたボリュームに保存されていることを検証します。
✓
✓
3.1.8
ブート時にダイレクトメモリアクセス (Direct Memory Access, DMA) が不可能であることを検証します。たとえば、PCI 接続を介して DMA が不可能であることを確認します。
✓
✓
3.2.1
組み込みオペレーティングシステムが業界の最新のベストプラクティス、CIS または SCAP ベンチマーク (適用可能である場合) にしたがって構成され、安全なデフォルトを使用していることを検証します。
✓
✓
✓
3.2.2
デバイスにより公開されているすべてのネットワークインタフェース上のすべてのネットワークサービスが必要なサービスであること、および不要なサービスが削除または無効化されていることを検証します。
✓
✓
✓
3.2.3
デバイスが Telnet や FTP などのレガシーまたは安全でないプロトコルを使用していないことを検証します。
✓
✓
✓
3.2.4
OS カーネルとソフトウェアコンポーネントが最新であり、既知の脆弱性を含んでいないことを検証します。
✓
✓
✓
3.2.5
Verify that persistent filesystem storage volumes are encrypted.
✓
✓
3.2.6
デバイス上で実行されているアプリケーションが基盤となるオペレーティングシステムまたはカーネルのセキュリティ機能を使用していることを検証します。これには暗号化、鍵ストレージ、乱数生成、認証と認可、ログ記録、通信セキュリティを含みます。
✓
✓
3.2.7
アドレス空間配置のランダム化 (Address Space Layout Randomization, ASLR) や データ実行防止 (Data Execution Prevention, DEP) などのメモリ保護コントロールが組み込みオペレーティングシステムにより有効であることを検証します。
✓
✓
3.2.8
ハードウェアレベルのメモリ保護が使用され、特権レベルが適用されていることを検証します。
✓
3.2.9
組み込み OS が RAM への不正アクセス (RAM スクランブリングなど) に対する保護を提供していることを検証します。
✓
3.2.10
完全性測定アーキテクチャ (Integrity Measurement Architecture, IMA) または同様の完全性サブシステムが使用され、適切に構成されていることを検証します。
✓
3.2.11
サードパーティアプリケーションが、ホストオペレーティングシステムから適切に分離されるように堅牢化された、コンテナ化されたランタイム環境 (Linux コンテナ、Docker など) 内で実行するように構成されていることを検証します。
✓
3.3.1
Linux カーネル名前空間を使用してプロセスが分離されていることを検証します。
✓
✓
3.3.2
コントロールグループ (cgroups) を使用して、重要なプロセスがリソースを制限するように構成されていることを検証します。
✓
✓
3.3.4
Linux カーネル機能が昇格されたアクセスを必要とするプロセスについて最小限のセットで構成されていることを検証します。
✓
✓
3.3.5
フィルタ付きセキュアコンピューティング (SECure COMPuting, seccomp BPF) が使用され、必要なシステムコールのみ許可するように構成されていることを検証します。
✓
✓
3.3.6
SELinux, AppArmor, GRSEC などのカーネルセキュリティモジュールの使用を検証します。
✓
3.4.1
パッケージとユーザー空間アプリケーションがファームウェアアップデートから切り離された Over The Air アップデートを使用していることを検証します。
✓
✓
3.4.2
事前定義されたスケジュールでデバイスを自動的にアップデートできることを検証します。
✓
✓
✓
3.4.3
アップデートが信頼できるソースにより暗号で署名され、それらの真正性が実行前に検証されていることを検証します。
✓
✓
✓
3.4.4
アップデートプロセスが Time-of-Check Time-of-Use (TOCTOU) 攻撃に対して脆弱ではないことを検証します。これは一般的にアップデートの真正性を妥当性確認した直後にそのアップデートを適用することによって実現します。
✓
✓
✓
3.4.5
アップデートがユーザーに通知することなくユーザーが構成した設定、セキュリティ、プライバシー設定を変更しないことを検証します。
✓
✓
✓
3.4.6
デバイスを既知の脆弱なバージョンにダウングレードできないこと (アンチロールバック) を検証します。
✓
3.4.7
アップデートに失敗した場合、デバイスがバックアップイメージに戻るか IoT エコシステムに通知することを検証します。
✓
✓
✓
3.4.8
署名されていないデバッグ用出荷前ファームウェアビルドをデバイスにフラッシュできないことを検証します。
✓
✓
✓
3.4.9
暗号化されたファームウェアイメージがデバイス上で安全に復号化されていることを検証します。
✓
✓
3.4.10
アップデートをダウンロードする前にデバイスがアップデートサーバーコンポーネントについて認証していることを検証します。
✓
✓
✓
3.4.11
ファームウェアアップデートは暗号化されたサーバーサイドに保存されていることを検証します。
✓
✓
3.4.12
ソフトウェアとファームウェアのアップデートが暗号化された通信チャネルを使用して送信されることを検証します。
✓
✓
✓
3.5.1
セキュリティチップとその他のハードウェアコンポーネントとの間のバスで暗号化が使用されていることを検証します。
✓
✓
3.5.2
シリアルバスで暗号化を有効にするために使用される鍵 (共有鍵または秘密鍵) がホストで適切に保護されていることを検証します。
✓
✓
3.5.3
バス暗号化で使用されるデフォルトのベンダー鍵が製品ビルドで置き換えられていることを検証します。
✓
✓
3.5.4
ハードウェアセキュリティチップにより提供されている場合でも、非推奨で安全ではない暗号およびハッシュ関数 (例 3DES, MD5, SHA1 など) が新しいアプリケーションに使用されていないことを検証します。
✓
✓
3.6.1
ロードされたカーネルモジュールが暗号で署名および検証されていることを検証します。
✓
✓
3.6.2
実行時に必要なカーネルモジュールのみが有効であることを検証します。
✓
✓
✓