手遅れになる前に：IoTアプリに最初からセキュリティを組み込む方法
Jane Porter
IoTデプロイメントにサイバーセキュリティを組み込み続ける中で、次に検討したい分野は独自アプリケーション作成の課題です。私たちの多くがアプリケーションを作成する際のアプローチを考えてみましょう。顧客の問題を解決できる新しいアプリケーションの開発への興奮は、設計プロセスにおいて非常にモチベーションを高めます。通常、開発者が最初に注目するのは、ユーザーエクスペリエンスに関連する項目です：
- アプリケーションの目的は何か？ユーザーに何を達成させるのか？
- アプリケーションの主要機能は何か？
- アプリケーションはどこで実行されるのか—PCかモバイルデバイスか？これはアーキテクチャにとって何を意味するのか？
- UIはどのように設計すべきか？よりシンプルで直感的にするには何ができるか？
これらはすべて重要ですが、何が欠けているかお分かりでしょうか？セキュリティの懸念は開発プロセスの最初から考慮される必要があります。アプリケーション開発の設計、開発・テスト、保守フェーズにサイバーセキュリティを組み込むことで、製品ライフサイクル管理がはるかに容易になります。
設計
アプリケーションの設計を開始する際は、アプリケーションに関連する潜在的な脅威について考えてください。例えば：
アプリケーション内で共有される情報はどの程度機密性が高いか？
非常に一般的な情報と相互作用を提供している場合、この場合はセキュリティは懸念事項ではないと判断し、アプリとデータへの匿名アクセスを許可できるかもしれません。作業完了、これでUIと動作の設計という華やかな部分に移ることができます。しかし、より機密性が高い場合は、もう少し考える必要があります。
標準的な認証と認可
提供している情報の一部がプライベートに保たれるべき相互作用のレベルを必要とする場合、ある程度の認証が必要になります。この典型的な例は音楽ストリーミングプラットフォームです；プラットフォームに匿名でアクセスして使用できますが、広告を削除してオフライン再生用のコンテンツを構築したい場合はログインする必要があります。また、一般公開されることを絶対に望まない支払い詳細も提供します。
このアプローチでは、これらの主題に関する以前のブログで議論した標準的な認証と認可技術を使用したいでしょう。覚えておくべき重要なことは、アプリケーションの一部のみがセキュアである必要がある場合でも、そのセキュリティは真剣に受け止められる必要があるということです。この分野での典型的なエラーは、ユーザーがアプリの非認証エリアからデータに誤ってアクセスできる場合です—これは設計がセキュアエリアを正しくコンポーネント化していない場合です。
高度に規制された業界
モバイルバンキングアプリなどの高度に機密な情報へのアクセスと相互作用を提供する場合、現在利用可能な最高レベルのセキュリティを提供する必要があります。この場合、あなたの組織はアプリが満たす必要がある詳細なガイドラインを持っている可能性が高く、その良い例がSecurity Technical Implementation Guide（STIG）です。このタイプのガイドは非常に長く、初めて読む際は理解が非常に困難な場合があります。私たちの提案は、すでにガイドラインを使用してアプリを作成した組織内の誰かを見つけ、セキュリティ要件を満たすためにアプリケーションに設計する必要があるセキュリティ制御についてのアイデアを提供してもらうことです。例として、ユーザーを正しく識別するために適応認証を使用する標準的なバンキングアプリがあります。
開発・テスト
標準的なガイドラインから始めましょう—うめき声が聞こえますが、数回使用すれば、これの多くが第二の天性になります。使用している言語によって、異なるガイドラインがあります。良い初期ガイドはOWASP FoundationのSecure Coding Practices Guideから来ており、以下にリンクされています¹。少なくとも、コードを書く際に考える必要があることについて正しい方向を示すのに役立ちます。
次に、セキュリティテストにどの程度焦点を当てたいかを決める必要があります。他のすべての決定と同様に、これは特定のアプリケーションにとってどの程度セキュリティを意識する必要があるかによって決まります。例えば、セキュリティを心配しないという決定を下した場合、このセクションをほぼ無視できます。ただし、セキュリティがほとんどないアプリケーションが、偶然にアプリケーションインフラストラクチャのより安全な領域へのユーザーアクセスを許可しないことを再確認したいかもしれません。
最初からセキュリティを考えてコードを書き、可能な限り安全にするためのガイドラインを使用した後、次のステップは静的アプリケーションセキュリティテスト、または私たちの多くがソースコードスキャンと呼ぶものを実施することです。アプリケーションのサイズによって、これはコンポーネントまたはアプリケーション全体かもしれません。スキャンは、すべてのライブラリを含むソースツリー、つまりあなたのコードと第三者ライブラリの両方で実行されるべきです。オープンソースから商用提供まで、多くの有名なソースコードスキャナーがあります。どれを選択するかに関係なく、ソースコードについては、出力はセキュリティ脆弱性の重要度と場所を強調する「発見事項」のリストになります；これらはクリティカルから低まで評価されます。第三者ライブラリについては、脆弱性のあるライブラリの共通脆弱性・エクスポージャーリストを取得し、CVEリストは1から10までの数値スコアを持ち、10がクリティカルで、これはCVSSシステムと呼ばれます。
これらの強調された脆弱性のうちどれだけを軽減するかを選択するのはあなた次第ですが、最低限として、自分のソースコードのクリティカルと高重要度に対処し、CVSSが7から10のライブラリについては更新されたライブラリを取得することをお勧めします。
ソースコードでスキャンを実行した後、動的アプリケーションセキュリティテストを実行したいと思います。これはコンパイル、ビルド、デプロイされたアプリケーションで実行され、悪用可能な脆弱性の別のリストを提供します。これとソースコードスキャンの主な違いは、動的アプリケーションセキュリティテストがランタイム環境に含まれる構成と他のコンポーネントを含むことです。これは、上記で議論した個別のアプリケーションに対して行った決定に関係なく、すべてのアプリケーションに対して実行されるべきです。
最後に、何も見逃していないことを確認するために侵入テストを実行したいと思います。これは、同僚があなたのセキュリティ防御を突破しようとするような低調なものから、主要なIoTプラットフォームの場合はこのタイプの倫理的ハッキングを専門とする第三者組織を雇うことまで可能です。侵入テストの良い出発点は、このウェブサイト、OWASP Top Ten | OWASP Foundationを使用することです。彼らは最新の既知の脆弱性、攻撃パターン、その他の有用な情報でサイトを最新に保っています。
保守・サポート
私たち全員が知っているように、セキュリティは、アクセスすべきでないデータへのアクセスを得る新しい方法を継続的に見つけようとする悪意のある者に反応して常に進化しています。これは、私たちのアプリケーションが常に世話される必要があると常に仮定しなければならないことを意味します；デプロイして忘れることはできません。再び、所有組織のサイズによって（結局のところ、一人だけかもしれません）、定期的に以下をチェックすることを確実にする必要があります：
- 第三者ライブラリをチェックし、最新に保つ
- アプリケーションを実行する環境をパッチと最新バージョンで最新に保つ
大規模な組織では、これを世話するチームまたはそれ以上があり、ISO 27001やSOC2などの標準の監査コンプライアンスの一部としてプロセスも整備されています。