-
タグ
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR
こんにちは。
疑似的な攻撃を実行して攻撃者の目的が達成できるか実証する「ペネトレーションテスト」を行っているデジタルペンテスト部の藤原です。
デジタルペンテスト部オフェンシブペンテストグループでは、IoT機器やIoTシステムのセキュリティ対策の有効性や、セキュリティ上の問題の有無を検証する「IoTデバイスペネトレーションテスト」を提供しています。このサービスは、通信ネットワーク機器や車載ユニット、IoT Gateway、医療機器など、さまざまなIoT機器に対して実施しています。
今回はIoT機器を開発するにあたり、「セキュリティ対策は必要か?」というお話をしたいと思います。
IoT機器に対してペネトレーションテストを日々実施しているラックの視点では、ネットワークに接続するIoT機器は攻撃者に侵入されないように、セキュリティ対策はもちろん「必要である」と考えます。それでは、製品を開発するメーカー様ではどのような状況でしょうか?
製品開発の要求仕様にセキュリティ対策を盛り込むと......
展示会などでメーカーの方とお話をすると、製品開発時のセキュリティ対策について悩まれている方が多い印象です。まだまだ、製品開発の要求仕様にセキュリティ対策が明示的に盛り込まれていないのが実情ではないでしょうか。
私はセキュリティ業界に約15年在籍しており、前職のメーカーでは製品開発現場のプロジェクトリーダー、ハードウエア設計・開発を担当していました。そのため開発現場の方々のお気持ちがとてもよく分かります。
もし、製品企画会議で新製品開発の要求仕様に「セキュリティ対策」の追加が提案されたら......
私が開発チームのリーダーだったら以下の質問をします。
- 開発スケジュールを再検討させていただくことは可能ですか?
- 開発予算を上積みすることは可能ですか?
- そもそも、「セキュリティ対策」が必要な根拠を示してください!
ところが恐らく販売部門や事業管理部門側からは、「スケジュールの延長も予算の上積みも不可」、「必要根拠については強制力のあるものはないがセキュリティ対策は必要条件としてほしい」、といった回答が来るケースが多いのではないでしょうか。
IoT製品開発の際、セキュリティ対策を組み込む必要性は理解しているものの、従来の工数や予算では対応が困難です。
このような状況下において、セキュリティ対策を組み込むためのスケジュールや予算はどのように検討すればよいでしょうか。また、スケジュールや予算を確保するための根拠はどのように考えればよいでしょうか?
ここからは、「セキュリティ対策を組み込むための開発スケジュール」、「開発予算の検討」、「セキュリティ対策が必要な根拠」について、1つずつ考えていきたいと思います。
セキュリティ対策を組み込むための開発スケジュール
製品開発において、要求仕様に「セキュリティ対策」を組み込む場合、以下の作業が必要です。
項目 | 実施内容 |
---|---|
①侵入ポイントと脅威の分析 | 攻撃者がどこから侵入するか、侵入された場合にどのような脅威があるかを検討する。 |
②リスクの分析 | 脅威が発生した場合にどのようなリスクがあるかを検討する。 |
③各リスクに対する対応方針の検討 | 想定したリスクに対して対策するか、許容するか、さらに、対策する場合はどのような対策を実施するかを検討する。 |
④対応方針に基づく設計、実装 | 検討した対策を製品に実装する。 |
⑤第三者によるペネトレーションテスト | 設計に脆弱性がないか、または、実装に脆弱性がないかを確認するために第三者によるペネトレーションテストを実施して検証することも有効であると考えます。 |
⑥セキュリティ上の問題点の修正 | テストにてセキュリティ上の問題点が検出された場合は、実装または設計までさかのぼって修正する。 |
ここでは、スマートフォンのアプリからWi-Fi通信で操作できる家庭用ロボットを開発するケースを例に、セキュリティ対策を追加する作業の流れを具体的に解説します。
脅威とリスクの分析
「①侵入ポイントと脅威の分析」では、攻撃者がどこから侵入するか、侵入された場合にどのような脅威があるかを製品の仕様と機能に対して検討します。
例えば、スマートフォンのアプリと家庭用ロボットの間の通信は攻撃者の侵入ポイントの1つとして考えられます。スマートフォンのアプリと家庭用ロボットの間の通信に攻撃者が侵入した場合、攻撃者によって通信内容の盗聴や改ざんが行われる脅威が想定されます。
そして、その脅威によりどのようなリスクが発生するかを想定する作業が「②リスクの分析」です。
セキュリティ対策の実装
発生する可能性のあるリスクに対して、「③各リスクに対する対応方針の検討」を行います。想定したリスクに対して対策するか、許容するか、さらに、対策する場合はどのような対策を実施するかを検討します。
そしてその後の「④対応方針に基づく設計、実装」では検討した対策を製品に実装します。
攻撃者による通信内容の盗聴や改ざんに対する対策が「データを暗号化して守る」であれば、使用する暗号方式や暗号鍵の作成・保管方法などを設計し、プログラミングして実装します。
セキュリティ対策の有効性の評価
実装したセキュリティ対策について、設計に脆弱性がないか、または実装に脆弱性がないかを確認するために「⑤第三者によるペネトレーションテスト」を実施することも有効です。
ペネトレーションテストの結果、セキュリティ上の問題点が検出された場合、実装または設計までさかのぼって「⑥セキュリティ上の問題点の修正」を行います。
このように実際に起こりうるリスクの想定から対策を決定したうえで全体の作業期間を決定すると、手戻りなく現実的な開発スケジュールを策定できます。
開発予算の検討
「セキュリティ対策を組み込むための開発スケジュール」で検討した内容を予算に組み込む際のポイントを整理します。
項目 | 検討のポイント |
---|---|
①侵入ポイントと脅威の分析 |
|
②リスクの分析 | |
③各リスクに対する対応方針の検討 | |
④対応方針に基づく設計、実装 | 従来必要のなかったデータの暗号化などを実施する必要があります。そのため、その設計および実装のための工数を追加する必要があります。 |
⑤第三者によるペネトレーションテスト | 脆弱性のないことを確認するため第三者にペネトレーションテストを委託する場合、外部への委託費用が必要になります。 |
⑥セキュリティ上の問題点の修正 | ペネトレーションテストで問題を指摘された場合、その対策方針の検討と設計および実装が必要になり、その工数が必要になります。 |
上記のような工数や費用が必要になりますので、場合によっては開発工数の増加および外部委託費などの追加による開発費の見直しが必要になります。
IoT機器にセキュリティ対策が必要な根拠
さて、最後に「セキュリティ対策が必要な根拠」についてです。
今までネットワークに接続していなかった機器をネットワークに接続するということは、攻撃者が侵入できる入口がネットワーク上に新たに作られたということになります。
攻撃者に侵入されると最悪、攻撃者に機器が乗っ取られる、自由に操作される、機微情報を窃取されるなどのリスクがあります。IoT機器を開発する際には、攻撃者に侵入されたらどのような脅威が想定されるか、そして、その脅威によるリスクは何か、リスクにどのように対応するか、必ず検討してください。
2024年3月15日、経済産業省よりIoT製品を対象としたセキュリティ適合性評価制度構築に向けた検討会のとりまとめが公表されました。
調達者が自身を守るために、求めるセキュリティ水準のラベルが付与された製品を優先的に選択するようになることが必要不可欠であるとして、2025年3月頃にIoT製品共通の最低限の脅威に対応するための基準に対する自己適合宣言の受付およびラベル付与の開始を目指しています。
機器により4段階のレベル(レベル☆1~☆4)の要求事項があります。レベル☆1~☆2は自己適合宣言による方式、☆3~☆4は第三者認証が必要と考えられています。
今後は、IoT製品を対象とした「セキュリティ適合性評価制度」が、セキュリティ対策が必要な根拠、すなわち、セキュリティ対策が必要な大義名分になり得ると考えられます。
※ IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会の最終とりまとめを公表し、制度構築方針案に対する意見公募を開始しました (METI/経済産業省)
最後に
結論、IoT機器の開発時には、必要な工数と予算を確保いただき、セキュリティ対策をぜひ盛り込んでいただきたいと思います。
ラックは、IoT機器の開発の初期段階で、攻撃者視点での脅威分析とリスク分析、そして各リスクへの対策を提案する「IoTセキュア開発コンサルティング」、開発の終了段階で、設計・実装がセキュリティ上問題ないか検証する「IoTデバイスペネトレーションテスト」を提供しております。
なお、IoTデバイスペネトレーションテストは2023年末に、経済産業省が定めた「情報セキュリティサービス基準」の適合サービスとして情報セキュリティサービス台帳に登録されたサービスです。
IoT機器のセキュリティ対策の検討、検証の際にはお気軽にご相談ください。
過去の記事もご紹介させていただきます。
IoTの脆弱性を発見するセキュリティテストを疑似体験できるホワイトペーパー
IoTデバイス開発の現場で役立てていただけるように、ラックで行っている脆弱性を発見するセキュリティテスト「IoTデバイスペネトレーションテスト」を疑似体験できるホワイトペーパーです。IoTデバイスの開発やセキュリティ対策に関わる方におすすめの内容です。ぜひご覧ください。
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- もっと見る +
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR