セキュリティというと、「後付けのセキュリティ対策で守るもの」と思われがちですが、機器自体が堅牢であることが大前提です。機器の堅牢性だけでは守れない点を後付けのセキュリティ対策で補うという考え方が重要です。堅牢化といっても、何か特別に難しいことをしなければいけない訳ではありません。今回は組み込み機器の堅牢化について、シンプルかつ基本的な考え方を紹介します。
1. 攻撃の入り口を減らす
堅牢化を考えるうえで最も重要なのが、攻撃の入り口を減らすという考え方です。攻撃者がアクセス可能な経路が少なければ、当然守るものが少なくなり、必要なセキュリティ対策が減ります。攻撃の入り口を減らす方法を4つ紹介します。
(1) 不要な通信ポートを開かない
組み込み機器を開発するうえで、チップのリファレンスOSなどのベースとなるOS・ディストリビューションをベースに開発することが多いと思います。サンプルとして多くのサービスを起動し、それに伴い多くの通信ポートが開いている場合があります。最低限必要なサービス以外は削除する、起動しないようにするなどの対策を行いましょう。
(2) 接続元を制限する
たとえば、管理者のみのアクセスを前提としたweb管理画面のように、特定の接続元や特定のユーザー以外からのアクセスが不要な場合は、インターネット側から接続できないようにしたり、特定のIP以外から接続できないようにしたりなど、パケットフィルタリングによる制限をしましょう。
(3) デバッグ用の通信を残さない
telnetやSSHのようなデバッグ用の通信を経由した攻撃も多くみられます。特にデバッグ用通信は直接OSコマンドを実行できるうえにパスワード等の認証が弱く、攻撃者から見て魅力的な攻撃経路です。出荷前にデバッグ用通信のポートを閉じる、もしくはインターネット側から接続できないようにするなどの対策を行いましょう。
デバッグ用通信で特に多いのが、開発者が開発時の利便性を求めて設計書に無いデバッグ用通信を勝手に用意するケースです。設計書に載っていなければ検査も行われないため、検査を素通りして出荷されてしまいます。これはデバッグ用通信を勝手に用意する開発者が悪いのではなく、開発者の利便性を考慮したデバッグ手法があらかじめ設計されていない点に問題があります。設計時に開発者の利便性を考慮したデバッグ用通信を検討し設計書に記載するとともに、検査時にデバッグ用通信が開いたままになっていないことを検証するという考え方が重要です。
(4) ユーザーにデフォルトパスワードを使わせない
管理画面にデフォルトID・パスワードでログインできてしまう場合も多くみられます。出荷時に機器ごとに異なる初期パスワードを割り当てる、最初にパスワード変更をしないと使用できないような仕組みが重要です。
2. 既知の脆弱性を極力減らす
サイバー攻撃で特に多いのは、既知の脆弱性に対する攻撃です。攻撃観測を行っていると、脆弱性情報や攻撃の実証コードが公開された後に攻撃が始まる場合が多いことが分かります。最近は組み込み機器開発においてもLinuxをはじめとするオープンソースソフトウェア(以下、OSS)を活用する場合が多いです。攻撃者にとって、OSSの脆弱性は同じ方法で多くの機器を攻撃できるため、とても魅力的です。出荷時に対策を行うのはもちろんのこと、出荷後も新しい脆弱性が出ていないか定常的に確認することも重要です。
よく勘違いされますが、「かならず最新バージョンを使わなければいけない」という訳ではありません。安定性や処理性能の観点から最新バージョンを使えない場合もありますし、最新バージョンを使用することにより検査が膨大になるなど、対策コストに見合わない場合もあります。
セキュリティリスクを受容可能なレベルまで下げるという考え方がセキュリティの基本です。古いバージョンのOSSにパッチをあてて脆弱性を修正することも対策として有効ですし、攻撃者が機器に直接触れないと攻撃できないような脆弱性であれば、機器の利用シーン次第では脆弱性が残留していても問題ありません。
脆弱性の重要度の指標として共通脆弱性評価システム（CVSS：Common Vulnerability Scoring System）が使われます。CVSSのスコアに目が行ってしまいがちですが、機器への影響を評価するうえでCVSSの各評価項目に着目するべきです。たとえば評価項目の攻撃元区分（AV：Attack Vector）には、攻撃者がネットワーク越しに攻撃できるのか、物理的に触れないと攻撃できないのかという情報があります。攻撃条件の複雑さ（AC：Attack Complexity）には、攻撃条件が複雑かどうかという情報があります。
3. 脆弱性を作りこまない
機器独自に作りこまれてしまった脆弱性は、攻撃者から見ると発見が難しいうえに特定の機器にしか通用しない攻撃となるため、上記で述べた2つの脆弱性より狙いにくいです。しかし、攻撃者がツールを使って発見できてしまえば、脆弱性は上記2つと同レベルの高いリスクとなるため、作りこまないように注意が必要です。
(1) デバッグ用通信を残さない
「1. 攻撃の入り口を減らす」でも紹介しましたが、デバッグ用通信は作りこんでしまう脆弱性の中でも深刻です。ポートスキャンツールを使って解放ポートを検出する検査を行うと、デバッグ用通信のような意図しない通信ポートを検出できます。
(2) web画面の脆弱性
組み込み機器でも管理画面等でwebのユーザーインターフェースを持つ機器が増えています。webユーザーインターフェースに対する攻撃は、web脆弱性検査ツールを使用した検査の実施や、web脆弱性診断サービスを受けるといった対策が重要です。
(3) メモリ関連の脆弱性
バッファーオーバーフローのようなメモリ関連の脆弱性は、任意プログラム実行などの重大な攻撃に繋がります。近年は、ハッカーコンテストでも、ファジングテスト（※）ツールを用いてメモリ関連の脆弱性を発見し侵入するハッカーが多いという傾向があります。メモリ関連の脆弱性は、実装フェーズではソースコードの静的解析で検出でき、ファジングテストを行うことにより検査フェーズでも検出できます。
※ ファジングテスト：予測不可能な入力データを大量に入力し挙動を監視することで脆弱性を検出する検査手法
ファームウェア更新機能を用意する
組み込み機器の堅牢化の考え方として脆弱性を予防する対策を3つ紹介しました。しかし、どんなに予防をしても、攻撃方法が後から発明されたり、脆弱性が後から発見されたりすることがあります。その際に、機器にファームウェア更新機能が無いと対策が行えません。また、ファームウェア更新機能があっても、組み込み機器のファームウェアを定期的にアップデートするユーザーは少ないというのが現状です。ファームウェアの自動更新機能を用意したうえで、自動更新機能をデフォルトでONにして出荷することが望ましいです。
最後に
システム開発者と話をすると、「3. 脆弱性を作りこまない」で紹介したような、自身が実装するコードの脆弱性を気にする人が多いように感じます。脆弱性を作りこまないことも確かに重要です。しかし、同程度もしくはそれ以上に重要な、「1. 攻撃の入り口を減らす」や「2. 既知の脆弱性を極力減らす」で紹介した対策が、見落とされたり軽視されたりしているように感じます。本記事でセキュリティについて気付きを得られる技術者がいらっしゃると幸いです。
富士ソフトのセキュリティソリューションについて、詳しくはこちら
セキュリティソリューション
富士ソフトのIoTセキュリティソリューションについて、詳しくはこちら
IoTセキュリティソリューション
