コンピュータセキュリティにおける6つの愚かな考え方（2005）
(ranum.com)- コンピュータセキュリティは製品・会議・書籍・法案が増え続ける分野だが、繰り返される失敗の根には Default Permit や Enumerating Badness のような誤った基本前提がある
- 核心的な問題は、「許可するもの」を狭く定義せず、「防ぐべきもの」を際限なく追いかける構造にあり、ファイアウォール・コード実行・ワーム対策で Default Deny を選ばなければ、攻撃者との軍拡競争に陥る
- 悪いものの列挙は、75,000種以上のウイルスと毎月200〜700件の新たな脅威を追跡する方式であり、実際に必要な30個前後の正常なアプリケーションを管理する Enumerating Goodness より非効率である
- 脆弱性を見つけてパッチを当てるやり方、ハッキングを格好よく消費する文化、ユーザー教育に依存する戦略は、いずれも設計上の欠陥を減らすより 事後対応 を繰り返すことになる
- 新技術はすぐに導入するより、待って検証したほうが安全な場合があり、セキュリティ実務者は流行より 常識的な設計 と疑う姿勢を優先すべきである
セキュリティの失敗を生む「反・良いアイデア」
- コンピュータセキュリティでは新製品、新しい会議、新しい本、新しい法案が次々に登場するが、問題は繰り返される
- 「愚かなアイデア」とは、良いアイデアの反対側にあるアプローチであり、不可能なことをやろうとしたり、現実を無視したりすると生まれる
- こうしたアプローチは善意の誤解から出てくることもあれば、手早く金を稼ごうとする、よく包装された製品から出てくることもある
- 6つのアイデアはよく見かける順に整理されており、とくに最初の3つを避けられるなら、少数の優れたセキュリティ実務者に入ると考えられる
1. Default Permit: デフォルト許可
- Default Permit は、明示的に禁止していないものをすべて許可する方式であり、ファイアウォールのルールで最も見分けやすい
- 初期のネットワーク管理者は、入ってくる telnet、rlogin、FTP だけを遮断し、それ以外は許可していた
- 新しい脆弱性が見つかるたびに、管理者は遮断するかどうかを決めなければならず、侵害される前に追いつく必要があった
- 1990年代のワーム登場で消えているべきだったが、多くのネットワークはいまも細かな分離のない開放的なコア構造を持っている
- コード実行でも同じ問題が繰り返される
- ユーザーがクリックすれば、基本的には何でも実行され、アンチウイルスやスパイウェア対策ソフトが止めた場合にだけ実行が拒否される
- 実際によく使うアプリケーションは15個程度、ときどき使うものを含めても20〜30個程度なのに、OS はウイルスやスパイウェアの実行をデフォルトで許可している
- E-banking セキュリティプロジェクトでは逆のアプローチを使っている
- ロードバランサーが既知の攻撃だけをブラックホールへ送る代わりに、正しい URL の一覧と一致しないすべてのトラフィックを、画像と 404 ページを返すロックされたサーバーへ送る
- 既知の攻撃だけを止める Default Permit ではなく、正常な構造から外れたリクエストを拒否する方式である
- 攻撃者との軍拡競争 をしているなら、Default Permit に陥っているサインである
- 反対概念である Default Deny は、実装への献身、思考、理解を必要とするが、より良いアプローチである
2. Enumerating Badness: 悪いものの列挙
- Enumerating Badness は、既知の悪いものをすべて一覧化したうえで検知または遮断する方式である
- 初期には既知のセキュリティホールが少なく、可能に見えたが、1992年ごろからインターネット上の「悪いもの」は「良いもの」よりはるかに多くなった
- 典型的なアンチウイルス製品は 75,000 種以上のウイルスを把握している
- 1台の個人用コンピュータにインストールされた正常なアプリケーションは約30個とみなせる
- 正常なアプリケーション30個を追跡し、それ以外を実行させなければ、スパイウェア、ウイルス、リモート制御トロイの木馬、あまり使われないプリインストールコード実行型エクスプロイトの問題をまとめて減らせる
- 一部の業界分析によれば、毎月200〜700件の新しい「悪いもの」がインターネットに現れる
- 企業ネットワークは複雑なので正常なアプリケーションを把握するのは難しい、という反論に対しては、CTO が技術が何をしているか大まかにすら分からないなら、容量計画・災害計画・セキュリティ計画は立てられないと反論している
- 1994年のファイアウォール製品のログ分析は、最初は悪い条件を探す方式だったが、第2版では Artificial Ignorance を使った
- 興味がないと分かっているログを捨てる
- 残ったログを興味深いものとみなす
- このアプローチは、思いつけなかったはずの運用条件やエラーを検知した
- アンチウイルス、侵入検知、侵入防止、アプリケーションセキュリティ、ディープパケットインスペクション型ファイアウォールは、この方式に頼ることが多い
- 定期的な シグネチャ更新 が必要だったり、初見のワームを通してしまったりするシステムは、Enumerating Badness の兆候である
- 治療法は Enumerating Goodness だが、OS にはこうしたソフトウェアレベルの制御を支える仕組みがほとんどないと見ている
3. Penetrate and Patch: 侵入してパッチを当てる
- Penetrate and Patch は、外部からファイアウォール・ソフトウェア・Web サイトなどを攻撃して欠陥を見つけ、その欠陥を直したうえでまた探すという循環型の方式である
- この方式が作るのは、設計上より優れたシステムではなく、試行錯誤で固くなったシステムにすぎない
- Richard Feynman の Personal Observations on the Reliability of the Space Shuttle は、複雑なシステムの信頼性をどう達成すべきかを示す読み物である
- 核心的なメッセージは、「ハックできるように設計したシステムでない限り、ハックできてはならない」という考えに近い
- 脆弱性公開とパッチ更新の流行も、このアプローチに基づいている
- 脆弱性研究者は、ハッカーより先に穴を見つけて修正させることで共同体を助けていると考える
- ベンダーは、ハッカーやワーム作成者に悪用される前にパッチを出すので、正しいことをしていると考える
- しかし、最初から安全で信頼性高く設計されたコードなら、脆弱性発見は退屈で報われにくい作業になる
- Internet Explorer で10年間、毎月2〜3件のセキュリティバグが出ていたのなら、Penetrate and Patch が有効だったとは言いがたい
- PostFix、Qmail のような一部アプリケーションは、権限と処理をモジュール化・区画化するよう設計されており、セキュリティバグの履歴が非常に少ないとされる
- 侵入テストにも同じ限界がある
- 根本設計やセキュリティ慣行が間違っているネットワークは、何度侵入テストを受けても侵害され続ける
- 最初から特定方向・特定トラフィック・慎重に構成されたサーバーだけを通すよう設計されたネットワークでは、一般的な侵入テストは無意味になりうる
- 毎回「今週のバグ」に脆弱なら、Penetrate and Patch に陥っている状態である
- ソフトウェアとシステムは secure by design であるべきであり、欠陥への対処を念頭に置いて設計されるべきである
4. Hacking is Cool: ハッキングは格好いいという考え
- Hacking is Cool は、ハッカーにストックオプション、本、講座、高額な侵入テスト報酬を与えたり、美化したりする文化への批判である
- Donn Parker は、リモートコンピューティングが犯罪における物理的接近の必要性をなくし、匿名性と被害者と対面しないことが犯罪への心理的障壁を下げたと見ている
- ハッキングは技術的問題というより 社会的問題 に近い
- インターネットは、社会性に乏しい人々に新しい活動空間を与える
- セキュリティ実務者がハッカーを英雄化すれば、ハッキングを暗黙に奨励することになる
- メディアはハッカーを「whiz kids」や「brilliant technologists」として描くことがある
- セキュリティ実務者がハッキング技術を学ぶことも、このアイデアの一部とみなされる
- エクスプロイトとその使い方は、その穴がパッチされればすぐ古くなる
- 専門能力が Penetrate and Patch の軍拡競争に依存することになる
- ハック可能なシステムを見つける方法より、ハックに強いセキュリティシステムを設計する方法を学ぶほうが合理的である
- 「Hacking is Cool」は10年以内に消えると予測する一方で、その反対の「Good Engineering is Cool」が置き換わる兆しはないと見ている
5. Educating Users: ユーザー教育
- Educating Users は、人間に適用される Penetrate and Patch に近い
- 教育そのものは良さそうに見えるが、効果があるならすでに結果が出ているはずだ
- いくつもの研究で、相当な割合のユーザーがキャンディ1個でパスワードを渡してしまうという結果があったという
- Anna Kournikova ワームは、人類のほぼ半分が、やや有名な女性のヌード写真が入っていそうに見えるものなら何でもクリックすることを示す事例として使われる
- ユーザー教育を戦略にするなら、毎週ユーザーを「パッチ」しなければならないかもしれない
- 本当の問いは、「ユーザーをもっと安全に教育できるか」ではなく、「そもそもなぜユーザーを教育しなければならないのか」である
- なぜユーザーは実行ファイル添付を受け取るのか
- なぜユーザーは、口座すら持っていない銀行からのメールを期待するのか
- 添付ファイルとフィッシング対策も Default Permit の問題である
- すべてのユーザーがメール添付を受け取れるようにすると、送られてくるすべてをデフォルトで許可することになる
- より良い方法として、すべての添付ファイルを隔離し、実行ファイルは削除し、許可したファイル形式だけをステージングサーバーに保存することができる
- ユーザーは SSL 対応ブラウザでログインしてファイルを取得するようにでき、パスワード要求は多くのワーム拡散メカニズムを即座に弱体化させる
- MIMEDefang のような無料ツールは、受信メールから添付ファイルを切り離してユーザーごとのディレクトリに保存し、メール中の添付ファイルをその URL に置き換える用途に使える
- 小規模なセキュリティスタートアップを運営していた当時、Windows を使いたい社員は自分でインストールと管理ができなければならず、そうでなければ採用されなかった
- 10年以内に、教育が必要なユーザーはハイテク労働市場から脱落するか、競争力を維持するために自宅で自ら訓練するようになると予測している
6. Action is Better Than Inaction: 行動は無行動よりましだという信念
- IT 幹部は「early adopters」と「pause and thinkers」に分かれ、成功し安全なミッションクリティカルシステムを作ったのは後者に近いと見ている
- 新技術が出たらすぐ導入するより、待って、ほかの初期導入者の結果を見て、経験者が出てきてから展開するほうが安全な場合がある
- ある上級 IT 幹部は、企業向け無線ネットワーク導入計画を「2年待った後、自社より大きな会社で無線展開を成功させた人を採用する」と定めた
- その間に技術はより整理され、価格も大幅に下がる
- 核心となる補助命題は、「賢いことをするより、愚かなことをしないほうが簡単な場合が多い」というものだ
- セキュリティのアウトソーシングも1〜2年先送りし、生き残った組織の推薦や意見を聞けという助言が続く
- 検証なしに大金を使おうとしていた顧客の事例では、関連カンファレンス LISA に社員を送り、実運用経験者を探すよう提案している
- その社員は、製品経験者を夕食に招いて非公式な評価を聞くことができた
- 200ドルの夕食代が40万ドル以上の技術的苦痛を減らしたと IT 管理者は語った
- プロフェッショナルな「カンフー」とは、何もしないことで愚かなことを避け、その回避の功績を上司に認めさせることである
そのほかの小さな愚かさ
- 「うちは標的ではない」
- ワームは、Web サイトやホームネットワークが面白いかどうかを判断できるほど賢くない
- 「みんなが特定の流行のセキュア OS を使えば安全になる」
- OS は複雑なのでセキュリティ問題があり、システム管理はまだ解決済みの問題ではない
- 流行に乗って切り替えると、管理者が時間をかけて蓄積する専門性を得にくくなる場合がある
- 「ホストのセキュリティが十分ならファイアウォールは不要だ」
- ネットワーク基盤を信頼できないなら、ネットワークを流れるすべてのアプリケーションが潜在的な標的である
- 例として Domain Naming System が挙げられる
- 「良いファイアウォールがあるからホストセキュリティは不要だ」
- ファイアウォールが背後のホストへトラフィックを通すなら、それらシステムのホストセキュリティも考えなければならない
- 「今すぐ本番に載せて、セキュリティは後でやろう」
- 今きちんとやる時間がないなら、壊れた後にやり直す時間があるのかと問うべきだ
- 最初の数日を惜しんだせいで、その後何年も修正し続ける状況になりうる
- 「たまに起きる問題は防げない」
- 航空業界が命を預かるのにそんなアプローチを取っていたら、民間旅客機に乗れるだろうかという問い返しにつながる
セキュリティ実務者に求められる姿勢
- コンピュータセキュリティは、「今週の新技術」に過度に夢中になり、常識を捨ててしまったと見ている
- セキュリティ実務者の仕事は、通念と現状に疑問を投げかけ、必要なら真正面から挑戦することである
- 通念が有効なら、システム侵害率は下がっているはずだという問題意識で締めくくられる
1件のコメント
Hacker News のコメント
またこの話をするのか、という感じ: https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
この記事には突っ込みどころが多いが、いつも指摘したいのは、Ranum が反対していた脆弱性研究に対する本音だ。90年代末〜2000年代初頭、Marcus Ranum と Bruce Schneier は、脆弱性の公開は利益より害が大きく、外部研究者ではなくベンダーがそれを担うべきだという立場の代表的な論者だった。その見方は結局正しくなかった。2002年には、外部による完全公開型の脆弱性研究を「ハッキング」の下にまとめることもできたが、今ではまったくそうではない。セキュリティ分野の4大カンファレンスはもちろん、暗号学の文献まで攻撃研究を扱っている
見落としているのかもしれないが、パスワードの話がないのには驚いた。最小長を除く強制的な文字種ルール、定期変更、「パスワード代替」への試みは、本質的に愚かだと思う。文字種ルールは、紙に書く、同じパスワードを使い回す、末尾に 1 を付けるといった結果を生み、代替手段は UX がひどいか分かりにくく、結局パスワードに戻ってくる。ただ自分で選んだ文字で X 文字以上のパスワードを作らせてくれれば、スマートフォンやコンピュータがなくても、海外にいても、実際に覚えていられる
suckmyDICK123!!のようなものを入力する。それでもたいていはブルートフォースの処理量が足りないか、5回失敗するとアカウントがロックされるので、そう簡単には破られない。最近では「ボットが超人的な速度でパスワードを試す」くらいのことは多くの人が知っており、どんなパスワードポリシーも悪いパスワード選択を防げない。「責任感のある」人たちが現実を解決しようとして膨大な時間を浪費している例だ。銀行のような機密性の高い1〜2件を除けば、1分だけ遊んだゲーム80本のように無理やりアカウントを要求するサービスには、同じパスワードを使いたくなる。独自 GUI で貼り付けもできないことが多く、パスワードマネージャーを使うこともできるが、わざわざそうする理由がないハッキングはかっこいいこともある。他人のデータやシステムにアクセスすることではないが、自分が所有するシステムを深く理解し、自分に有利な形で誤動作させる方法を見つけるのはかっこいい。隣家の鍵をピッキングするのは良くないが、自分の鍵をピッキングするのはかっこいいし、リモートのコンピュータを操作して不当なアクセス権を得るのは良くないが、自分のコンピュータに本来できないことをさせるのはかっこいい。可能性の縁を探る姿勢が世界を前に進めるのであって、枠の中にとどまることを称賛した成功した人間社会はほとんどなかったはずだ
この記事には非常に悪い判断が多い。「自分のシステムは慎重に設計・実装・設定したのだから、テストする必要はない」という趣旨の文は、実際に聞いた中で最悪のセキュリティ観かもしれない。「ハッキングは社会的問題であって技術的問題ではない」という言葉も、隠蔽によるセキュリティに近く、常に社会的問題であるわけでもない。企業スパイ活動や国家主体を見ればそうではない
核心的な問題はたいてい、ユーザビリティ vs セキュリティという不幸なトレードオフであり、ここで愚かなアイデアとして挙げられているものの多くは、平均的なユーザーの不便を減らそうとしてセキュリティを犠牲にした結果である。たとえばデフォルト許可はセキュリティ上最悪で、Windows の多くの問題の原因でもあるが、ユーザーは新しいプログラムごとに明示的に許可しなければならないのを嫌う。Microsoft が確認ダイアログを追加したときも、多くの人はソフトウェアをずっと面倒にした悪い設計だと考えた。だから「デフォルト許可」「悪いものの列挙」「侵入後のパッチ」がデフォルトになったのだ。個人的には、パスワードそのものがセキュリティにおける最も愚かなアイデアの1つだと思う。良いパスワードの定義が、すなわち覚えにくく、まともなキーボードのないデバイスでは入力しにくく、ユーザーにとってほぼあらゆる面で不便なものだからだ。しかし現実的な代替案もない。メールリンクはメールへのアクセス権が奪われれば全部奪われるし、パスワードリセットもたいてい同じだ。物理認証デバイスは、ユーザーが外出先でログインできなかったり、アクセサリを常に持ち歩かなければならなかったりする。ほぼすべての方式が良いセキュリティ習慣を要求するが、人口の99.9%はほとんど関心がない
「複数のエクスプロイトと使い方を学ぶのは、すぐにパッチが当たれば古くなってしまうツールや技術を学ぶことに時間を費やすだけだ」という言い方は間違っている。実際には理論とともに実務的側面を学んでいるのであり、非常に有用だ
このリストから「ハッキングはかっこいい」を外して、クライアント信頼を入れたい。最近、クライアントを信頼しようとする試みが増えている。モバイルアプリが OS が改変されていないことの証明を要求したり、Google が Web に似たような DRM を入れようとした事例がそうだ。ネットワークセキュリティモデルがクライアントソフトウェアを信頼することに依存しているなら、すでに壊れている
「デフォルト拒否」について「デフォルト許可よりはるかに難しいわけではなく、夜もよく眠れる」とあるが、IT セキュリティ担当者はよく眠れるだろうが、会社のほかの人たちは、何をするにも IT 部門と3往復しなければならず、非常にいら立つ。そして人がいら立つほど、セキュリティの概念を崩す迂回策を使う可能性も高まる。毎月パスワード変更を強制すると、
password1、password2、password3のようなものを使う、といった具合だ。良い IT セキュリティは単にネットワークケーブルを抜くことではなく、ユーザーにとって魔法のように見えず、邪魔にならないものであるべきだセキュリティ中心の記事はたいてい、セキュリティを極端に重視する人が書いており、純粋なセキュリティ中心のアプローチが安全なソフトウェアの利用者にもたらす不便さを無視しがちです。セキュリティは常に、安全性と利便性のスライダーとして見るべきです。完全に安全な設計は不便すぎて利用者がほとんどおらず、完全に便利な設計も十分に安全ではないため、結局同じ結末に至りかねません。それでもこの記事はおおむね読む価値がありますが、セキュリティ専門家がエクスプロイトを書いてみたり、特定のシステムを悪用する方法を学んだりするのは愚かだという考えには強く反対します。「安全な設計」を学んだことよりも、脆弱性とエクスプロイトを研究し、自分でホワイトハット的に実装してみることで、セキュリティについてはるかに多くを学びました。「敵を知るには敵になってみる必要がある」という言葉に近いです
これはほとんど、19年前のひどいリストです。「ソフトウェアとシステムは設計段階から安全であるべきで、欠陥への対処まで考慮して設計されているべきだった」というのは、「完璧な世界なら、すべてが最初から安全だったはずだ」という意味です。そんなことは絶対に起きないので、発見後にパッチを当てる手法を使う必要があり、発見された脆弱性を実際に修正し、その失敗から今後のコーディング慣行を学ぶ企業では、うまく機能してきました。また、ほとんどのシステムは静的ではありません。安全なシステムを一度リリースして二度と更新しないわけではなく、ほとんどのアプリケーションやシステムは頻繁に更新され、その際に新しい脆弱性が入り込みます
scriptやonclickのようなキーワードを含むリクエストをブロックすることで「修正」するような場合です