IntelのSpectre-Meltdownのパッチでユーザーシステムがリブートしてしまう事故も

Intelにとってそれは、楽しい時間ではなかった。先週同社は、チップの脆弱性を二つ公表し、その後それらにはSpectreとMeltdownという名前まで付けられ、そしてさらにIntelだけでなくチップ業界全体の騒動になった。今週同社はパッチを発表したが、今日(米国時間1/12)は、それらをインストールした企業の一部がシステムの唐突なリブートを経験している、という情報がリークされてきた。泣きっ面に蜂、傷口に塩の不運な週だ。

Intelもそれを認め、同社Data Center GroupのVPでゼネラルマネージャーのNavin Shenoyが、この件に関するブログ記事を書いた。

そこにはこう書かれている: “複数の顧客から、ファームウェアのアップデートを適用したあとに高レベルのシステムがリブートする、という報告を受けている。具体的には、これらのシステムは、クライアントとデータセンターの両方でBroadwellとHaswellのCPUが動いている”。

“そのためにファームウェアアップデートの改訂が必要なら、その新たなアップデートは通常のチャネルから配布する”。

この問題はIntelがコントロールできないほど劇症化することはないだろう、とみんなが思っていたまさにそのときに、一層の劇症化が起きてしまった。Wall Street Journalが入手したIntelの極秘メモは、大企業やクラウドプロバイダーたちに、パッチをインストールしないよう指示している。一方Intelは消費者にはすべてのパッチをインストールするようアドバイスし、これはセキュリティの問題ではない、と指摘している。

ソフトウェアの不具合の問題にすぎないし、それは確実に直った、と言いたいところだったが、騒動の肥大化がプレッシャーとなり、ミスが生じたのかもしれない。

SpectreとMeltdownの問題は昨年、GoogleのProject Zeroのセキュリティチームが見つけていた。彼らは、セキュリティよりスピードを優先した設計により、現代的なチップのアーキテクチャに欠陥が生じ、チップのカーネルが露出した、と認識している。その場所にはパスワードや暗号鍵などの秘密情報が保存され、たぶん保護もされている。しかしその欠陥のために、保護がない状態になってしまった。

MeltdownはIntelのチップだけの問題だが、Spectreは今のチップのほとんどすべてにある…AMD, ARM, IBM Power, Nvidiaなどなど。この問題を抱えなかったのは、Raspberry Piだけかもしれない

今のところ、この脆弱性の悪用に関する情報や記録はない。Googleの昨日(米国時間1/11)のブログ記事によると、それは20年も前からチップに存在した脆弱性だが、しかしセキュリティの専門家たちによると、これまでのセキュリティ事故の、どれとどれがこの脆弱性の悪用であるかを特定するのは難しい。20年前からその存在を十分に知っていたとしても、事故原因としての特定は難しいだろう、という。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

データセキュリティーにとって最大の脅威は無関心

security-globe

データセキュリティーと言えば、サイバー攻撃の手口が高度になったとか、クラウド技術がリスク満載である等の話を聞く。こうした説明はある意味で真実だが、いずれももっと厳しい現実を隠す口実であるかもしれない。今日、企業データにとって最大の脅威の一つは無関心だ。

HP Security Researchの2015 Cyber Risk Reportによると、実地調査で見つかった最も危険な企業脆弱性9件は、その全部が3年以上経過していた。US-CERT(コンピューター緊急事態対策チーム)も、最も利用されたネットワーク侵入30件の研究で、同様の経年問題を指摘している。つまるところ、US-CERTの推定によるとネットワーク攻撃の85%は予防可能である。

殆どのケースが単純なセキュリティーパッチで十分だ ― そしてこの種のバグの場合何年も前からパッチが提供されている。セキュリティー専門家たちは、無関心故にアップデートの適用を怠っていたのか、それてももっとひどいことなのか?多分違う。おそらく、対処すべき根の深い問題が業界全体にはびこっている。

なぜこれが起きているのか?セキュリティー専門家の怠慢、は便利な答だが不正確でもある。多くの場合、メーカーはパッチの存在およびどんな影響があるかの情報共有ができていない。さらには、あまりにも多くのパッチが、利益より害をもたらす余計なソフトウェアと共に配布されている。

パッチの適用がリスクになる時

例えばMicrosoftが昨年発行したパッチのうち6件は、直ちにユーザーに問題を引き起こしたAppleOracleにも同様の問題があった。Oracleの場合、2014年8月のJavaに対するアップデートがサードパーティーアプリケーションを破壊し、再度のパッチ発行を余儀なくされた。Appleは、9月に発行したiOSアップデートがいくつかのiPhone機能を阻害し、一部のユーザーは通話不能に陥った。

善意のパッチが不本意 ― そして厄介 ― な結果を招いた時に、CIO[最高情報責任者]やセキュリティー責任者の慎重な行動を責めることは難しい。

しかし手動のパッチ当ては答にならない。システムのパッチに要する時間に、影響を受けるシステムの数を掛け、さらにその作業のために雇ったコンサルタントに支払う時給を掛ければ、中堅規模の企業でさえ、わずか1回のパッチに何十万ドルも費していることがわかる。他の選択肢が運用を遮断するなら、IT無関心も良い選択に思える。

自動化は、急速に成長するIT基盤のパッチに関しては答の一つになるだろう。定期的な監視も、システム化されたアップデートに伴って導入されるブレークポイントの発見、修正に必要だ。パッチ不履行がもたらす損害を考えれば、それ以下は許されない。

リスク vs 恩恵

つい最近、ポーランドの航空会社LOTは乗客1400人が立ち往生する攻撃を受けた。さらに、人事局に対する最近のハッキングは、現在および過去の政府職員数百万人分 ― 私を含む ― の極めて個人的な経歴情報を暴露した。これに比べるとあのSony文書リーク事件が ― 評判へのダメージは大きくとも ― かわいく見える。

公平を期して言うと、これらの組織がどのセキュリティーホールを開けたままにしていたのかは不明だが、最新アップデートを定期的に適用している自己回復ITプラットフォームに対して、古い侵入手口は通用しない。多くのセキュリティー対策が実施されずこのように管理されていない状況は、当然の結果を招く深刻な問題である。

あなたの会社の規模を考えてほしい。次に各従業員が何台の端末を会社のネットワークにつなぐかを考える。社内の誰を取ってもその数は最低でも2(パソコンとスマートフォン)であり3(+タブレット)であることも多い。それぞれの端末がノードであり、あらゆるノードが攻撃者の入口になり得る。サイバーセキュリティーの幅広い時宜を得た対応は、基本ネットワークを真に保護するために不可欠だ。

しかし人々の行動は正反対だ。多くのCIOとセキュリティー責任者は、自動アップデートを避ける慎重な決断を下す。それは新たなソフトウェアをシステムに導入する際に直接制御できないために起きる結果を恐れるためだ。メーカーはこれを、自分たちがいかにパッチプロセスの信頼を裏切ってきたかの結果と見るべきだ。

約束、そして実行

ソフトウェアベンダーにとってユーザー ― 直接の消費者 ― の信頼を取り戻すことは容易ではないが、自動アップデートに対する信頼を勝ち取るためには必須だ。

ここで鍵となるのが、パッチとその影響に関するオープンで透明な情報共有だ。顧客はパッチがいつ入手可能で、何をするか、どんな影響があり得るかを知らされる必要がある。もし問題が起きれば、メーカーは何が起きていているかについても同様に明確にし、受けた影響の回避策を提供しなければならない。

要するに、メーカーはセキュリティーパッチに関する情報共有を、広報事項ではなく、顧客保護の問題として取り組むべきなのである。

[原文へ]

(翻訳:Nob Takahashi / facebook