Baldanders.info

踊るセキュリティ

HeartBleed で踊れない

いや,まぁ,続報ってほどではないんだけど。

最初は OpenOpenSSL って聞いたけど,ダサいので止めたのか,他からクレームでも来たのか。 そもそも OpenBSD は「うちとこは影響を受けない」(独自の防御機能があるので,慌てて対処しなくても大丈夫)ってたかをくくっていたらしい。 でも,実際は OpenBSD にも影響を受けることが分かって「こりゃいかん」ということになったんだそうだ。 んで,実際にコードを査読してみたら他にもバグやら脆弱性やら山ほどあって,怒り心頭に発しているというオチまで付いている。 (だから「じゃあウチで作るわ」という話に繋がる。 まぁこの辺がエンジニアらしい発想ではある)

ソフトウェア開発にとってセキュリティ管理をどうするかってのは難しい問題のひとつだ。 特に長い期間続いているプロジェクトの場合は最初の頃と最近ではセキュリティ要件が変わってしまっている場合もある。 そこを柔軟に対処できるかがポイントである。

もうひとつは私が以前から言っている「専門家不全症」の問題だ。 私達にとって専門家は「お気に入りの言動を支持してくれる「権威」という名の消費財」にすぎない。 つまり,あるトピックに対して複数の意見が対立している時は,自分の意見を支持してくれる「専門家」を「選択」すればいい。 「あの先生はこう言ってるから正しい」と言うわけだ。 そして更に「あの先生の発言を非難するあなたは人間的に劣ってる(あるいは文化水準が低い)」と続ければそれで終わり。 こうした外側のくだらないやりとりに当の専門家は,関与しないのはまだマシなほうで,積極的に利用する連中まで登場し始めているので困ったもんである。

セキュリティはリスクであり(リスクであるがゆえに)科学であると思っているが,その科学が今や上述のような有り様なのが「現代」の特徴なのかもしれない。

踊る IE ユーザ

例の zero-day 脆弱性,週末に修正が出た模様。 うちの職場でも朝からみんなアップデートしてました。

Microsoft 社のセキュリティに関する歴史は是非勉強しておいた方がいい,特に企業は。 MS は1990年代はセキュリティに関してあまり積極的ではなかった。 セキュリティに対する要求は当時(特に企業においては)あまり高くなかったし,同社はバグを塞ぐより機能を上げる方を優先させていた。

(いまでもそういう方針の世界的大企業があるよね。 そう, Apple 社だ)

でも MS に対する批判が日増しに大きくなっていき,ついに同社は方針を変えるに至る。 積極的にセキュリティ・インシデントを開示し,ユーザに見える形で対応していくようになった。 でもそれはすぐに破綻する。 なぜならインシデントが多すぎて管理しきれなくなったからだ。 そこで MS は修正モジュールの公開を毎月第2火曜日(米国時間)に固定するようにした(少なくとも前週には予告がある)。 これで MS 側も余裕を持ってインシデントに対応できるし,ユーザ側も計画的に OS やアプリケーションを運用できるようになった。 この方法は好評だったのか,今では他の企業も真似している。

ただ問題は zero-day 脆弱性には対処しきれないことだ。 zero-day 脆弱性はすぐに具体的な被害が出るおそれがある(またはもう出ている)が,月に1度のアップデートしかできない状態では間に合わない。 そこで最近は EMET (Enhanced Mitigation Experience Toolkit) などを使って緊急避難的に対処しておき,あとで Windows Update で正式に対応する,といったやり方をとるようになった。 なので今回の措置は異例といえば異例だが,よい判断だと思う。 こうしたことにきっちりと対処できるのは優れた企業である証拠だ。

というわけで,何が言いたいのかというと,全然慌てる必要はないのだよ。

ひとつ文句を言いたいのは, IE を更新するのに OS 自体を再起動しなければならないようなく◯ったれ(←下品でゴメン)な設計は早く捨てろ,ということだ。 じつはこれが IE の最大のセキュリティリスク。 Firefox だって Chrome だって自身を更新する際に OS を再起動しろとは言ってこない。 そういう風に作ることは可能なのだ。 IE は Windows カーネルの深いところまで食い込んでいる。 Linux と違い Windows は,カーネル関連のモジュールの更新を稼働中に行うことができない(これはファイルシステムの違いが大きいんだけど)。 だから再起動を要求せざるをえないのだ。 これは IE そして Windows の Defect (欠陥)と言っていい。 そして攻撃者もそこにつけ込むわけだ。

見た目を気にする前に,こういう設計上の Defect を早く何とかしろよ > Microsoft

踊る国税庁

いやぁ,笑った笑った。

Apache Struts に関しては,個人的に過去にも現在にも関わった仕事がなく(もちろん勉強はしてたよ)スルーしてたのだが,国税庁がサービス停止になるとは思わなかった。

いや,これ,毎度毎度のことなんだけど,「再発防止」じゃダメなのよ。 わかる? ソフトウェアの Defect については「未然防止」でいかなきゃ。 工業製品と同じ。 障害を引き起こしたトリガーだけを見てもダメ。 障害が起きるときは必ず障害に至るプロセスがある。 そのプロセスを調べて対処するのが「未然防止」。 そこまでやらなきゃダメなのよ。

あと,実際に障害が起きた時のレスポンスが遅すぎる。 多分「事後」の対処に慣れていないからじゃないかと思うんだけど。 セキュリティ対策はね,「事後」に備えて初めてワンセットなのよ。 だからリスク管理が必要なわけ。

なんか「お役所」ってこういうところ全っ然なおらないよね。 なんでだろう。 自分でリスク(責任)を引き受けないからかな。 なにか起こった時に当事者の馘首を切って,それで「再発防止を行いました」とか言ってるんじゃないだろうか。 ネット上のサービス停止程度なら(今回のように)笑い話で済むけれど, 3.11 の原発事故を大惨事にまで拡大させたのは明らかに「お役所仕事」だからだよね。

みんな同根でみんな繋がってるんだよ。 20世紀型の「お役所」はもう機能しないってことを「お役所」は知るべき。

ああっと,ちなみに Struts 2 に関しては(時間はかかったけど)対策が施された 2.3.16.2 が公開されているので適用するように。 あと,Struts 1 なんか使ってんじゃねー!

踊る小市民

DNS 汚染の話については NVD や JVN の以下の alert が発端だと思うけど

これって2008年のインシデントなんだよね(当時は本当に大騒ぎだった。これを忘れたもしくは知らないということはセキュリティに無頓着であることを暴露しているのと同じ)。 つまり「なにいつまで放置してんだよ。バカなの?死ぬの?」 って言ってるわけ,NVD/CERT も JVN/JPCERT も。

しかも,更にこれをまるで「インターネットが死ぬ日」みたいに煽るバカがいて,本当に「ここは酷いインターネッツですね」って感じである。

踊るのに疲れたら

セキュリティ「業界」ってのは山師が跋扈しやすい環境でもある。 私も昔,セキュリティ管理者をやってた頃はセキュリティ企業の酷いマッチポンプ広告にウンザリしていた。 しかも今はもっと酷い。 こういった山師をうまくフィルタリングするには「科学的事実(fact)」を見ていくしかない。

まずセキュリティに関心のある方もない方も JPCERT/CC の alert を見逃さないこと。 そして alert に従って必ず対処を行うこと。 これは最低限の自衛行為だと思った方がいい。 JPCERT/CC では RSSメーリングリストで alert を流している。

企業などはセキュリティ対策企業と契約している場合も多いだろう。 そういったところからの情報ももちろんだが(ちゃんとした企業なら日頃から情報を流してくれるはず),併せて IPA の情報にも注目して見ておくべきだろう。 IPA の alert はうまく情報が集約されていて分かりやすいのでお薦め。

とりあえずセキュリティ管理とかを任されているような人でなければ上の2箇所をチェックしておけば十分。 alert には必ず対策(回避も含めて)方法が書いてあるので,慌てず騒がず冷静に対処するのが肝要。

最後に手前味噌だが, Twitter でセキュリティ情報配信@security_inci)を行っている。 セキュリティ関連サイトの RSS を集約して Twitter で流すだけの簡単なお仕事だが, Twitter メインで行動してる人には役に立つかもしれない。

(そういえば Twitter を Web で開くと「災害時に緊急情報をツイートするアカウントをフォローしましょう」って出るけど,何でそこに IPA とか JPCERT とか NISC とか出ないの? 最近ようやく日本でもソーシャルニュースとか流行り始めてるみたいだけど(私は関わらないよ, Flipboard で充分),そういうセキュリティ関連の alert とかちゃんとフォローしてるの? ネットなんだから,そこが最優先だろう?)

まぁ HertBleed クラスの大規模な障害は数年に1度くらいしか出ないし, IE の zero-day 脆弱性にしたって年1回程度の恒例行事みたいなものなので,過剰に反応しないことだ。 「踊るアホウ」は見てるだけで充分。

老婆心で言っておくけど,「事後」にうまく対処したいなら,日本国産のサービスは避けるのが無難だと思う。 HeartBleed の件とか見ても分かる通り,日本のサービスプロバイダは動きが遅い。 またそれを指摘するメディアや「専門家」もいない。 NISC とか何のために存在するのか分からない(IPA の alert を転送するだけなら私でもできるっちうねん)。 纏めて言うなら「全くやる気が無い」。 こんなところに私物を置いておくなんて,「泥棒に追い銭」だよ。

(個人の感想です)

photo
トヨタ式未然防止手法GD3―いかに問題を未然に防ぐか
吉村 達彦
日科技連出版社 2002-09
評価

日産自動車における未然防止手法Quick DR 想定外を想定する未然防止手法GD3 ついてきなぁ!設計トラブル潰しに「匠の道具」を使え!―FMEAとFTAとデザインレビューの賢い使い方 「設計力」こそが品質を決める―デンソー品質を支えるもう一つの力 FMEA辞書―気づき能力の強化による設計不具合未然防止 (JSQC選書)

by G-Tools , 2014/05/04

photo
インターネットが死ぬ日 (ハヤカワ新書juice)
ジョナサン・ジットレイン 井口耕二
早川書房 2009-06-25
評価

facebook 閉じこもるインターネット――グーグル・パーソナライズ・民主主義 グーグル秘録 クラウド化する世界 ウェブ進化論 本当の大変化はこれから始まる (ちくま新書)

by G-Tools , 2014/05/04

あっ,念の為に言っておくけど,ジョナサン・ジットレインの『インターネットが死ぬ日』は真面目で秀逸な本なのでお勧めです。 Jonathan Zittrain は日本でももっと知られるべき。