もう待てない、サイバーレジリエンス法対策
サイバーレジリエンス法(CRA:Cyber Resilience Act)は、2022年9月に欧州委員会にて草案が提出され、当初は2023年後半の発行、2025年後半の適用を目指していました。違反した企業に多額のペナルティを課すこの法律には大きな反響がありました。その後、施行時期が2024年前半に調整されたとの話がありましたが、2024年8月現在、施行に至っていない状態です。施行から実際の適用までには36か月の猶予期間(報告義務等の早いものでは18か月)も設けられているので余裕があるように思えますが、情報を集め、会社に認知させ、組織を作り、製品に反映するには、それなりに時間を要します。
ここでは、知識や情報、組織対応が十分とはいえない状況下、先に準備できる最低限のことは何か?について、設計や開発の観点から最新の情報とともに解説します。
目次
1. サイバーレジリエンス法の概要
2. よりどころとなるガイドライン
3. 本来は事前に実施すべきこと
4. 設計・開発に必要なこと
5. 検証にはツールやサービスを利用するのがベター
6. それでも対策がよくわからない場合
7. まとめ
より詳しい技術や関連製品について知りたい方へ
本コラムに関係する技術や関連する製品について知りたい方は、お気軽にご相談ください。
1. サイバーレジリエンス法の概要
サイバーレジリエンス法は、原則としてデジタル要素を含むすべての製品(ただし、同様の規制をもつ車載関連製品、医療機器関連製品などは非対象)が対象となり、ソフトウェア更新などのセキュリティ要件に対する適合を受けなければなりません。製品のクラスによって、自己申告または第三者認証による適合性証明が求められ、適合性評価証明書(CEマーク)が必要となっています。インシデント発生時には、24時間以内の欧州ネットワーク情報セキュリティ庁(ENISA)への報告が義務付けられ、法令に違反した場合には制裁金(1500万ユーロまたは全世界の年間売上高の2.5%の高い方)が課されます。また、欧州無線指令(RED)にもセキュリティ要件が追加され、サイバーレジリエンス法との統合の動きもあります。
2. よりどころとなるガイドライン
サイバーレジリエンス法には、大きな視点であるべき姿としてのセキュリティ特性要件が定められておりますが、その実現方法やレベル感などは明記されておりません。より具体的なガイドラインなどは、自社で規定することも可能ですが、他の規定などを参照しながら対策していくのが現実的になります。欧州における民生分野向けの「EN303 645」や国際規格である産業機器分野におけるセキュリティ規約「ISO/IEC62443」などが活用されますが、現状はより詳細で具体的な「ISO/IEC62443」をベースに対策を検討するケースが多く見受けられます。
全てのデジタル製品に求められるセキュリティ特性要件(附属書I)
附属書Iの1「セキュリティ特性要件」
- リスクに基づいて適切なサイバーセキュリティを確保するよう設計・開発・⽣産されていること。
- 悪⽤可能な脆弱性が含まれないこと。
- リスクベースアセスメントに基づいて、以下を満たすこと。
- (a) 製品を元の状態にリセット可能である等、安全な構成となっていること。
- (b) 適切な制御メカニズムにより不正アクセスからの保護が確保されていること。
- (c) 最先端の暗号化などにより個⼈データ・その他のデータの機密性を保護すること。
- (d) データやプログラムなどの完全性を許可されていない操作から保護し、破損についても報告すること。
- (e) 必要なデータに限定して処理を⾏うこと。(データの最⼩化)
- (f) DoS攻撃からの回復・緩和などの重要な可⽤性の機能を保護すること。
- (g) 他の機器やネットワークからのサービスの可⽤性について⾃⾝への悪影響を最⼩化すること。
- (h) 外部インターフェース等の攻撃対象領域を制限して設計・開発・製造されていること。
- (i) インシデントの影響を軽減するように設計・開発・製造されていること。
- (j) アクセス、データ修正、サービス、機能などの内部活動を記録・監視し、セキュリティ情報を提供すること。
- (k) ⾃動更新やユーザーへのアップデート通知などによりセキュリティアップデートによる脆弱性対応を確実に⾏えること。
附属書Iの2「脆弱性処理要件」・・・製造業者が満たすべき要件
- 製品に含まれる脆弱性とコンポーネントを特定し、⽂書化すること。そのために、機械読み取り可能な形式で⼀般的に使⽤されるSBOM作成(少なくとも最上位レベルの依存関係含む)を⾏うこと。
- セキュリティアップデートの提供など、遅滞なく脆弱性に対処・緩和すること。
- 効果的かつ定期的なテストとレビューを⾏うこと。
- 脆弱性情報の公開及び修正を⾏うこと。
- 脆弱性開⽰ポリシーを導⼊し、実施すること。
- 製品やサードパーティコンポーネントの潜在的な脆弱性に関する情報共有を⾏い、連絡先を提供すること。
- 悪⽤可能な脆弱性が適時に修正・緩和されるように安全にアップデートを配布するメカニズムを提供すること。
- セキュリティパッチや更新プログラムが遅滞なく無料で配布され、ユーザーへの助⾔メッセージも添付すること。
サイバーレジリエンス法におけるセキュリティ特性要件
出展:経済産業省 サイバーレジリエンス法(草案概要)https://www.jasa.or.jp/dl/gov/20220926.pdf
3. 本来は事前に実施すべきこと
サイバーレジリエンス法のセキュリティ特性要件は、大きく分けて「組織や運営」に関する部分と「設計や開発」に関する部分に分けられます。ISO/IEC62443でも、「プロセス」に関する部分と「個々の機器」に関する部分で文書が分かれています。
具体策に着手できない
サイバーレジリエンス法対策に取り組むに際して、本来であればプロセスを明確にしてから開発に進むべきですが、①サイバーレジリエンス法はまだ草案レベルであり実際の施行時には修正される可能性があること、②企業や組織としての決定や判断には時間がかかることなどが要因となり、具体策の着手に取りかかれないケースが少なくありません。
とても重要な「リスクに基づいて」とリスクの洗い出し
サイバーレジリエンス法のセキュリティ特性要件の最初には、『リスクに基づいて適切なサイバーセキュリティを確保できるよう設計・開発・生産されていること』と記述されていますが、ここの『リスクに基づいて』の部分がとても重要になります。無線通信などは、第三者による傍受や接続が可能でリスクが高く、おのずとリスクレベルは高くなります。一方で、機器内部のデバッグ用ポートなどは、物理的に開封が必要など接触としてのリスクレベルは低くなりますが、ログ情報での重要機密の流出の可能性やJTAGインターフェースからのソフトウェアの改ざん・流出など、一度アクセスされると、致命的な問題になるリスクを含んでいるとも言えます。
これらのリスクの洗い出しは、(一部を除き)組織の横断や会社全体におよぶ話ではないので、机上での議論が可能です。慣れやスキルの問題もありますが、ある意味想定内のケーススタディであり、所属する部門内で時間さえかければ実行可能な部分です。セキュリティに対する部員の意識を高めたり、将来的な教育目的となったりすることも視野に入れて、一度議論されることをお勧めします。
ステージにおける判断レベル
4. 設計・開発に必要なこと
セキュリティ・バイ・デザインという考え方があります。設計の段階からセキュリティを担保していく考え方で、さまざまな攻撃や意図しない操作・アクセスに対する耐性の仕組みをあらかじめ実装しておく手法です。以下は、その基本的なポイントです。
- 重要なデータやプログラムが盗まれない、改ざんされない。つまり安全な領域に配置する
- 盗まれてもわからない。つまり暗号化する
- 改ざんされてもチェックできる。つまり常に証明書やハッシュなどで正しいかチェックする
- 侵入させない。つまり不要な入り口をできるだけ閉じる
- 関係ない人・モノを接続させない。つまり接続時に認証プロセスを設ける
- 緊急時に更新する。つまりソフトウェアがアップデートできる
この中の対策のいくつかは、すでに設計を終えた製品に施すには非常に大変な作業で、あらかじめ設計段階で実装されていることが望ましいものです。セキュリティ対策の方針や会社・組織のスタンス、リスク分析などが明確にならないうちに対策を実施することは難しいかもしれません。しかし、上記の対策はいずれも普遍的なものばかりで、製品レベルにおける基本的なセキュリティ対策といえます。以下に、より具体的に抽出します。
- 安全な領域の確保のためセキュアエレメント(デバイス)やセキュアマイコンを採用する
- アプリケーションソフトウェアの安全なアップデートや自分自身の安全の証明のため、ハッシュや証明書を利用したセキュアブート、セキュアアップデートを実装する
- 暗号化のためのソフトウェアライブラリやハードウェアアクセラレータを使用する
これらは、結果的に信頼の起点(RoT:Root of Trust)となります。最新のセキュアマイコンの使用は理想的ですが、ソフトウェア資産の流用やアーキテクチャの変更など、さまざまなハードルがあります。その場合はTPMなどのセキュアエレメントを外部に接続すれば対応可能です。これらのことからも、後からの変更が難しいハードウェア面での対策は、できる限り設計の初期段階に考慮すべきことと言えます。
5. 検証にはツールやサービスを利用するのがベター
設計ルールの徹底、各種静的・動的試験や検証などは、ツールを使って合理化したいところです。以下は、現在実施されている代表的な検証と対応するツールです。
- 信頼性の高いコーディングのために規約に準拠しているか検証すること ⇒ 静的コード解析ツール
- 網羅的にテストがなされているか確認すること ⇒ カバレッジ計測ツール
- 意図しない大量または異常データの入力に耐えるような検証をすること ⇒ ファジングツール
- SBOM(Software BOM)を作成・管理すること ⇒ SBOM作成ツール
SBOM作成やファジング検証などはほとんどのガイドラインで明記されており、必ず実施する必要があります。
複数の開発部門を持つ会社の場合、全社レベルでのツール導入が望ましいのですが、社内での歩調合わせには時間を要します。また、一度に多くのツールを導入するにはコストの問題もありますし、開発者が使いこなすのにも時間がかかります。優先度なども考慮して、当面は外部の管理・検証サービスの利用を検討することもお勧めします。
SBOM作成サービスの実施フローイメージ
6. それでも対策がよくわからない場合
現状のサイバーレジリエンス法はまだ草案レベルであり、実際の施行時には変わる可能性もあります。先にも示した通り、施行からの猶予期間もあり、様子見の企業も見受けられます。しかし、施行時に想定される要件を満たすためには、脆弱性開示ポリシーの導入などの部門を超えた体制作りや、プロセス含めた会社全体での取り組みも必要となります。必要な対策についてイメージのつかめない場合は、知見のあるコンサルタントに相談することをおすすめします。
7. まとめ
サイバーレジリエンス法は、まもなく施行される見込みです。これには、会社・組織ぐるみの対応が求められ、ハードウェアの追加・変更などの後戻りできない部分には迅速な決断が迫られています。ある程度の方針や方向性が決定すれば、おのずと機器レベルでの対策が現実化します。そうなれば、セキュリティ対策の基本に基づいて、信頼の起点RoTの確保、各種ライブラリの活用、ツール導入、第三者検証サービス利用なども視野に入ってくると思います。
ユビキタスAIでは、組込み業界でのノウハウを生かしたさまざまなステージにおけるサービスや製品を用意しておりますので、まずはお気軽にご相談ください。
ユビキタスAIが展開するセキュリティ製品・サービスの一覧
ステージ | 種別 | 対応製品・サービス | 概要 |
---|---|---|---|
方針 | コンサルティング | パートナー紹介 | お問い合わせください。 |
設計・開発 | 暗号ライブラリ | HE-CRYPTO | 軽量コンパクトな暗号ライブラリ |
暗号通信ライブラリ | Ubiquitous TLS | TLS/SSL通信ライブラリ | |
HE-NETシリーズ暗号通信ライブラリ | TLS、SSL、IPSec、IEEE802.X認証など | ||
セキュリティライブラリ | Ubiquitous Securus | マイコン内蔵セキュアハードウェアを使用し、漏洩・改ざんを防止 | |
Ubiquitous TPM Security | TPMライブラリ(TSS) | ||
検証 | 静的解析ツール | CodeSonar | |
カバレッジ計測ツール | Testwell CTC++ | ||
SBOM作成ツール | CodeSentry | バイナリファイルからのSBOM作成。作成サービスあり。 | |
FossID | ソースコードからのSBOM作成 ※関連会社グレープシステム取り扱い製品 | ||
ファジング・ペネトレーション検証 | IoT機器セキュリティ検証サービス | 脆弱性検証サービス。ツール販売もあり。 | |
製造・保守 | デバイスライフサイクルマネージメント | Edge Trust | 機器の稼働、廃棄、証明書の更新など管理・運用サービス |
より詳しい技術や関連製品について知りたい方へ
本コラムに関係する技術や関連する製品について知りたい方は、お気軽にご相談ください。
各国のIoT製品セキュリティ確保のための取り組み:日本
2024.10.03
各国のIoT製品セキュリティ確保のための取り組み: 英国
2024.04.18
ソフトウェアテストの新常識:ファジング入門
2024.04.17
各国のIoT製品セキュリティ確保のための取り組み:欧州
2024.01.26
JIS T 81001-5-1に準拠した医療機器のセキュリティ対策
2023.12.19
各国のIoT製品セキュリティ確保のための取り組み:米国
2023.12.18
サプライチェーン攻撃と脆弱性テスト
2023.12.14
セキュリティ規格について
2023.09.01
ファジングとは?
2023.09.01
脆弱性検証―何をどこまで実施すれば良い?
2023.09.01
HEMS機器の脆弱性検証
2023.07.14
ファジングの限界
2023.07.14