皆さんこんにちは。 開発課の丸野です。
最近、アンドリー・スチュワート氏の「情報セキュリティの敗北史 脆弱性はどこから来たのか」を読み、色々と考えることがあったので、読書感想文を書きます。
最初期の情報セキュリティについて
最初に本書を通して学んだ、最初期の情報セキュリティについて、その挑戦と失敗について簡潔にまとめます。
情報セキュリティはいつ、どのようにして必要になったのか
- 1946年、ENIACの登場
諸説ありますが、歴史上もっとも古いコンピューターは、アメリカ陸軍の支援のもと、エッカートとモークリーによって開発されたENIACであるとされています。 これは、射表という、大砲を発射する際に弾道を予測し、照準の計算を行うための表を作ることを目的に作成されました。
- 1952年、UNIVACの開発
ENIACは戦闘を有利に進めることを目的に開発されましたが、第二次世界大戦終結後の米軍は、もっと複雑で抽象的な問題を解句ためにコンピュータを使いたいと考えました。 そうして、1952年、エッカートとモークリーは、UNIVACを開発しました。
これは、Universal Automatic Computerの略称であり、より汎用的な計算を可能にすることを意識して設計されました。 このUNIVACにはいろいろなバージョンが存在しますが、記憶装置として磁気テープを採用したり、プログラム内蔵方式を採用したりなど、様々な革新的技術が採用され、ビジネス用途にも利用されるようになりました。
- 1960年代、タイムシェアリングシステムの登場
コンピュータが普及していくにつれて、そのコストパフォーマンスが問われるようになってきました。 当時まだコンピュータは非常に高価なものでありながら、たった一人のオペレーターしか利用できず、オペレーターがどのように計算を行おうかなどと考えている間は、コンピュータはただ指示を待つのみで、ダウンタイムが生じていました。
こういった問題を解決するために、「タイムシェアリング型コンピュータ」が登場しました。 これは、複数人で同時にアクセスすることができ、他のユーザーが作業を中断している間、コンピュータリソースを有効活用できるようになりました。 しかし、それと同時に、他のユーザーに見られてはいけない情報が公開されてしまったり、他のユーザーのプログラムを妨害したりなどが可能になるというような、いわゆる「情報セキュリティ」の問題が発生するようになりました。
最初期のセキュリティに対する研究
- 1970年、「ウェア・レポート」の発行(1975年機密解除)
1967年に、米国防総省内に委員会が発足され、「マルチユーザーのタイムシェアリング式コンピュータシステムにおけるセキュリティ」の研究が行われることになりました。
この委員会には、様々なシンクタンクや政府組織、軍事企業の代表者が集められ、1970年に「ウェア・レポート」の発表が行われました。
このウェア・レポートの内容について、本書から一部を抜粋します。
コンピューターが複雑になるにつれて、それを使用するユーザーのスキルも向上するが、その一方で、ユーザーを管理するためのセキュリティ対策を実施することが困難になる
...
OSは大規模かつ複雑であるとして、そしてその規模と複雑さゆえに、「保護のための障壁、設計者も予想しなかった抜け穴がある可能性があり、その結果、「大規模なソフトウェアシステムにおいては、エラーや異常がないことを検証するのは事実上不可能」であり、「攻撃者がそのような抜け穴を計画的に探し、利用することも考えられる」
ウェア・レポートでは、このセキュリティの抜け穴という脅威に対抗するために、コンピュータを設計した後でセキュリティ機能を追加するのではなく、コンピュータベンダーが「セキュリティ」を組み込むことを推奨しました。
このレポートはあくまでも、軍が紙媒体の機密情報を扱う時のルールをベースに作成され、「機密性」を最重要視しており、機密情報の流出を検知したら即時シャットダウンするなど、商用のコンピュータではとても採用できないほど厳しい要件が提唱されていました。
CIAの三要素の提唱
- 1974年、「CIAの三要素」の提唱
計算機科学者のサルツァーとシュローダーは「コンピューターシステムにおける情報の保護」という論文を発表しました。
この論文で述べられた、
- 機密性
- 許可されたユーザー以外がデータを読み取れないようにすること
- 完全性
- 許可されたユーザー以外がデータを変更できないようにすること
- 可用性
- データにアクセスできるはずのユーザーが、アクセスできなくなるのを防ぐこと
という情報セキュリティにおける3つの基本的な目標は、のちにCIAの三要素と呼ばれるようになりました。
これは現代でも、情報セキュリティの目指す先として重要視されている概念で、情報セキュリティの進むべき道を示す重要な概念になりました。
三つの試み、三つの失敗
タイガーチームと、終わらないペネトレイト・アンド・パッチ
ウェア・レポートやCIAの三要素に基づいて、最初からセキュリティ機能を組みこんだ「MULTICS」というOSの開発が始まりました。
そして米空軍はこのMULTICSのセキュリティ評価と改善のため、「タイガーチーム」を結成しました。
彼らはMULTICSに対してペネトレイト(侵入)を行い、そして彼らの報告をもとにパッチ(修正)する、「ペネトレイト・アンド・パッチ」というサイクルを回そうとしました。
MULTICSは最初からセキュリティ機能が組み込まれたOSでありましたが、MULTICS自体の実装が巨大で複雑であったため、正式にセキュリティ要件を実装できているかを調査する術はありませんでした。
それでも、このOSが当時では最も洗練した形で安全性確保のための設計・構築がなされていたため、大きな期待が寄せられていました。
しかし、タイガーチームは重大な脆弱性を「比較的少ない労力」で以下のような脆弱性を発見できてしまいました。
- システムに保存されている全てのパスワードを読み取ることができる
- メモリ破壊により、任意のコードを実行できる
- 上位の権限を取得できる
- セキュリティ機能を迂回してデータにアクセスできる
- ログを改ざんできる
この結果は、コンピューターのセキュリティに携わる人々に2つの大きな示唆を与えました。
- タイガーチームが発見できなかった脆弱性が「存在しない」確証など得られない
- システムの脆弱性を修正しても、それは複雑性を上昇させ、新たな脆弱性を生むだろう
形式的検証と、複雑な現実
タイガーチームの失敗を受けて、セキュリティ関係者は、「安全なシステムを作るためには、そのシステムが安全であると証明する正式な方法が必要」と考えるようになり、ベルとラパデュラという二人の研究者が、「安全な状態」の明確に定義することを試み、それに基づいた数理モデルを「基礎セキュリティ定理」として発表しました。
基礎セキュリティ定理は、「システムが安全であるためには、システムが安全な状態で始まり、状態が変化するときも別の安全な状態に限られる」という考えを前提としている。状態遷移を取り締まることで、システムは安全ではない状態に移行することができず、安全な状態が延々と続くのだ。
...
コンピューターシステムの安全性が数学的に証明されていれば、隠れたセキュリティ上の脆弱性を心配する必要はない。また、システムの出所も重要ではなくなる。安全性さえ証明されていれば、ソ連の諜報機関であるKGBが設計・構築したコンピュータでも、米政府は利用することができたのだ。
こういった「基礎セキュリティ定理」などから始まり、コンピューターシステムのセキュリティ特性を数学で証明できると考える人々によって「形式的検証」という、計算機科学の新たな分野が生まれました。
しかし、この形式的手法もすぐに問題点が明らかになってしまいました。
1973年、SRIインターナショナルという企業が米国政府の資金援助のもと、「PROS」プロジェクトを開始しました。このプロジェクトでは、形式的手法でもってOSの安全性を可能な限り証明しようと試みましたが、プロジェクトの終了までに検証できたのは35～40％程度でした。
結局のところ、全てを形式的検証でもって検証しようとすると、OSのような大規模なシステムではコストがかさみ、さらに機能は制限されることになりメリットが減少してしまう、という状況になってしまいました。
また、ハードウェアに起因するような「カバートチャネル問題」は解決できませんでした。 カバートチャネル問題とは、設計者や管理者が意図しない形で、セキュリティ機能を迂回して情報を伝達する手段が確立されてしまう問題です。
例えば以下のような方法です。
- 一人は「CPUに負担をかける処理」を実行し、もう一人は「CPUの負担が急上昇したことを検知するプログラム」を書く
- 一定間隔でCPUに負荷をかけることで、まるでモールス信号のように情報のやりとりをすることができるようになる
形式的検証でもってソフトウェアの安全性を確保することの難しさ、そしてソフトウェアの問題が解決したとしても、依然カバートチャネル問題は残ってしまう、ということが明らかになりました。
オレンジブックの制定と、ムーアの呪縛
ペネトレイト・アンド・パッチや形式的検証を利用しても、情報セキュリティの確立には至らないと判明しつつある頃、1983年に米国防総省は「オレンジブック」と呼ばれる、コンピューターに一定のセキュリティレベルが実装されていることを証明するための評価基準を作成しました。
このオレンジブックを制定することによって、民間のベンダーが一番下のDランクから開発を開始して、そこにセキュリティ機能を追加していくことでAランクに近づいていくことを期待しました。
しかし、1991年までにAランク認証を取得できたのはわずか2システムのみでした。軍が時間をかけてシステム検証をしている間に、ムーアの法則に従ってコンピューターは急速に小型化・高度化し、コンピューターは政府機関や企業が利用するものだけでなくなり、「パーソナル・コンピュータ」の時代に突入していきました。
やがて、民間にとって政府機関向けにシステム開発をすることは旨味の少ないビジネスになってしまい、たとえAランクの判定を取れたとしても、それを納入する頃にはすでに時代遅れのシステムになっている、というような状況が発生するようになってしまいました。
オレンジブックはあくまでもシステムの要件に専念していますが、パーソナル・コンピュータの時代に入っていくにつれて、情報セキュリティガイドラインが作られるようになりました。
しかし、そういったガイドラインも、できるだけ様々な組織で共通的に適用できるように抽象化していくと、ごく基本的なことしか書くことが出来なくなってしまいました。そして、ガイドラインとして成立している以上、柔軟な変更は難しく、新技術の登場に対応できない、というような状況が発生するようになってしまいました。
つまるところ、何らかの基準を明確にしたとしても、技術の発展スピードに追い付くことはできず、常に対応しきれない状態が続くようになってしまったのです。
最初期のセキュリティから学べること
ここまでの情報から分かることとして、実は情報セキュリティの問題はその最初期から現在に至るまで、本質的な部分は変わっていないのです。
Webの発展によって、脆弱性の情報は広く共有され、ペネトレイト・アンド・パッチの規模もスピードも改善しました。しかし、何かしらの脆弱性対策によって新たな脆弱性が生じることは常に発生しており、そして脆弱性が「まだ見つかっていないだけ」という可能性を排除できない以上、誰一人として何らかのソフトウェア・ハードウェアが「安全である」と言い切ることは出来ません。
CPUやマザーボード自体にセキュリティ機能が組み込まれ、プログラミング言語にはガベージコレクションや静的解析など、最初から安全であることを確保するための仕組みは充実してきました。それでも、セキュリティについてのニュースを見ない日はありません。
情報セキュリティを確保するための様々なガイドラインや、認定機関が作られましたが、いつもどこかで情報流出事件は発生しています。
このように、情報セキュリティはずっと「敗北」し続けているのです。
これから考えていくべきこと
本書で得られた知見をもとに、これから自分自身がどのようなスタンスで生活していくべきかを考えました。 本書の中で述べられているものと同じような内容にはなりますが、一応自分の意見として述べます。
複雑さのコントロール
プログラミング言語Clojureの作者である、Rich Hickey氏の「Out of the tar pit」という論文では、ソフトウェア開発には「本質的複雑性」と「偶有的複雑性」があると述べています。
本質的複雑性とは、解決しようとしている問題自体が持つ複雑さで、偶有的複雑性とはそれ以外の全てです。Rich Hickeyはこの論文の中で、偶有的複雑性はツールや開発手法の選択によって大幅に削減できるとしています。
私自身、基本的にソフトウェア開発の業務に従事しているので、この偶有的複雑性のコントロールという観点で物事を考えていくべきだと思っています。
幸いにも、型システムの研究が進んでいますし、よりシンプルで高機能な言語が登場しつつありますし、利用できる言語は限られるものの、高性能な構文解析機能を持ったIDEを利用して、問題のあるコードを書いてしまうことをある程度防ぐことができるようになったりと、コーディングにまつわる環境はどんどん快適になってきています。これに加えてCI/CDを利用するなどして、できるだけ本質的複雑性にフォーカスできる環境を作りやすくなってきました。
こういった最新の「道具」の使い方だけでなく、目的や考え方を理解する努力を続けていくこと、もし技術があるなら新たな道具を作り出すことが非常に重要だと思います。
自分自身のFUDと向き合う
私自身は情報セキュリティの専門家ではなく、守る側も攻める側も経験が少ないので、はっきりと今現在の情報セキュリティの課題に対応するために何かしないといけないことを示すことをできませんが、少なくとも言えることとして、FUD(恐怖・不安・不信)に振り回されないようにすることが重要だと考えます。
FUDというと、主に特定の企業のマーケティング戦略を否定する際に使われることが多いですが、本当に大切なのは自分自身の「恐怖・不安・不信」に向き合うことだと思います。
個人的に、このFUDと向き合うために以下のような標語を考えました。
- セキュリティについての恐怖を煽るような言説に、簡単に流されない
- 自分と今の状況にとっての「安全」とは何なのかを、冷静に判断できるようにする
- セキュリティに絶対はないことを覚悟する
- 脆弱性は必ず存在し、脆弱性に対応すると複雑性が上昇し、複雑性はリスクを高める
- どんな問題も解決できる銀の弾丸はない
- 無力感に支配されてはいけない
- 専門家は尊重すべきである
- 「どうせセキュリティ対策なんて無駄」とか、「バレなきゃ良い」とは考えない
当たり前のことしか書いていませんが、セキュリティに関する情報に触れたときに見返そうと思っています。
