イベントレポート
Internet Week 2017
Wi-Fiストレージ「ポケドラ」の脆弱性・出荷停止から学んだ、IoTハードウェアメーカーとしての取り組み
アイ・オー・データ機器での実例を当事者が語る
2017年12月6日 06:00
インターネットの技術研究・開発や構築・運用などに携わる人々がリアルで集い、最新情報を共有・議論するイベント「Internet Week 2017」が11月28日から12月1日まで開催された。その中から、いくつかのセッションの模様をお伝えする。
- がんばりすぎないルーティングとは？ 日本人はギリギリ運用しすぎ？（12月1日付記事）
- IoT機器のマルウェア感染、国内で1日8000台を観測、一番の狙われどころはtelnet（12月5日付記事）
- Wi-Fiストレージ「ポケドラ」の脆弱性・出荷停止から学んだ、IoTハードウェアメーカーとしての取り組み（この記事）
- 変化するDNSとサーバー証明書の関係～「ランチのおともにDNS」より（12月8日付記事）
- 「KSKロールオーバーはまだ終わっていない」～今年の「DNS DAY」の話題から（12月13日付記事）
- シンガポールとAPNICから見た、アジアと日本のインターネット（12月15日付記事）
- 1995年ごろのAPNICやISOCや「インターネットマガジン」を振り返る（12月15日付記事）
11月29日に開催されたセッション「転ばぬ先のIoTセキュリティ～コウカイする前に知るべきこと～」では、PCやスマートフォン以外でインターネットに接続する“IoT機器”のセキュリティ問題について発表がなされた。
株式会社アイ・オー・データ機器の島田康晴氏（事業戦略本部企画開発部）は、「PSIRTと事後対応の取り組み」と題して、機器メーカーの実際の取り組みを紹介した。特に、Wi-Fiストレージ「ポケドラ」に脆弱性が発見されたのを機会に、全社的な取り組みを強化した事例を当事者が語る、興味深いものだった。
島田氏はまず、「PSIRT（Product Security Incident Response Team）という言葉を念頭にして活動していたわけではなく、活動していたことがPSIRTに合致していた」と自社の取り組みを位置付けた。
PSIRTとCSIRT（Computer Security Incident Response Team）の役割について、島田氏は「業務インフラに関するインシデント」「サービスに関するインシデント」「商品に関するインシデント」の3種類のインスデントに分けて説明。業務インフラに関するインシデントはCSIRTが担当、サービスに関するインシデントはCSIRTを中心に一部をPSIRTが担当、商品に関するインシデントはPSIRTが担当すると整理した。
アイ・オー・データでは、PSIRTに相当するチームとして「情報セキュリティ対策チーム」がある。ポケドラの脆弱性を契機に、片手間では対策が困難ということで、全社的な取り組みとして結成されたという。役割は、PSIRTの機能を中心に、CSIRTの機能も一部持つ。
続いて、インシデントハンドリングの流れが紹介された。1番めはインシデント情報が来るところ。同社ではJPCERT/CCから来ることがほとんどで、それ以外はサポート窓口や広報窓口で対応しているという。
2番めは、重大性の判断。自社のインシデント判断基準をもとに開発部門で1次判断し、対策チームが最終判断する。判断基準としては、インターネット側かLAN側か、攻撃の成立度、ユーザーデータの影響度、周りへの影響度などが紹介された。
3番めは、対策検討および対策。これは開発部門の作業となる。また、対策より先にワークアラウンドがある場合は先に公開する。ポケドラのように重大インシデントの場合は、出荷を停止することもある。
4番めは、対策の公開。JPCERT/CCと調整したあとに、自社サイトと脆弱性情報サイト「JVN（Japan Vulnerability Notes）」で脆弱性を公開する。公開においては、対象商品、バージョン、対策方法、対策済みのバージョン、ソフトウェアダウンロード先が必要項目となっている。
島田氏はここから、ポケドラの脆弱性が発見されてからの実例を語った。
この件では、まず外部から脆弱性の指摘があり、重大インシデントと判断してまず出荷停止。自社サイトとJVNでワークアラウンドも公開した。約2週間で対策ファームウェアを公開し、販売店へも案内した。
それを受けて、ポケドラの件から気付かされたことが語られた。まず1つめは「ユーザーの利用実態が想定と違っている部分があった」こと。アイ・オー・データでは、ポケドラのルーター機能をLAN内で使う想定でいたため、インターネット接続製品より緩い基準だったが、インターネットにつなげて使われることがあったという。これについては、ユーザーの使い方を決めつけないことが必要だという教訓が語られた。
2つめは、ワークアラウンドがあれば先に公開することが重要であること。ポケドラの件では、ファームウェアによる対策に時間がかかりそうだったため、ワークアラウンドを先に公開したという。
3つめは、サイバーセキュリティに対する世の中の関心が非常に高くなっていること。数々の取材を受けたことから実感したという。4つめは、それがきっかけとなって、対策チームや開発体制など取り組みを再点検したという。
取り組みの再点検としては、不要なポートが開いていないか確認するポートスキャナーの導入や、担当者によってセキュリティ意識に差があるのを解決するセキュリティ教育、セキュアな製品開発のためのセキュリティポリシーやガイドラインの作成などを島田氏は語った。
最後に島田氏は、ポケドラ以外の事例とそこから得られた知見を語った。
1つめは、複数製品が該当するWPA2の脆弱性（KRACKs）の問題だ。この事例については、脆弱性の存在が公表されたら、まず、「自社製品に該当するものがあるため、調査中であること」を発表するのが重要だと島田氏は語った。
2つめは、古い製品の対応事例だ。2004年発売の有線LANルーター「NP-BBRRS」にDoS攻撃の踏み台にされる可能性がある脆弱性が発見されたが、古い製品なのでファームウェアによる対策はすでにできない状態となっていたという。そこで、やむなく製品そのものの利用停止をお願いする案内をした。
この事例については、ハードウェア製品にEOS（End of Service）の考え方を導入し、古い商品を買い換えてもらうアイデアを語った。ただし、さまざまな課題があるため、導入はしていないという。
こうした事後対策については、メーカーからの情報やセキュリティ修正パッチがユーザーにリーチしているか分かりづらいという課題も語られた。そのため、更新機能を高度化にすることで、自動更新だけでなく、更新状態の把握やヘルスチェックもできればと島田氏は語った。
