なぜセキュアなシステムが作れないのか?

(Last Updated On: 2017/10/02) 実はあまり知られていないセキュリティの常識。現状を知らないと隠れた大きなリスクを見逃します。

なぜセキュアなシステムが作れないのか?この問いは

なぜバグフリーのシステムが作れないのか?1

と同類の問いです。一定規模を超えると完全にバグ/問題がないシステムを作るのは非常に困難です。どのような状況でも正常に動作する完全にバグ/問題がないシステムは簡単には作れません。しかし、バグ/問題がないシステムが容易に作れないからといって「体系的な対策を行わない」のは賢明なアプローチではありません。

このエントリではよりセキュリティ問題が少くなるアプローチを紹介します。これはセキュリティ標準やガイドラインに記載されている考え方をまとめたモノです。

ポイントは

  • 構造化が大事
  • 基礎が大事
  • 目的が大事

です。

セキュリティ対策の構造化(≒ セキュリティ設計)、がない

セキュリティ対策を行うには設計が必要です。設計がないと「場当たり的な対策」に終始してしまいます。2017年6月のWiredの記事に参考になる記事があります。

Researchers Found They Could Hack Entire Wind Farms

この記事によると、風力発電システムのセキュリティ対策が脆弱であったため、簡単に制御を完全に乗っ取り可能で、設備の破壊を含む攻撃が可能だったとしています。なぜこのようになったのか?それはセキュリティ対策が構造化されておらず、セキュリティ設計が無かったからです。

セキュリティ設計を行う場合、少なくとも

  • 物理
  • ネットワーク
  • ソフトウェア
  • システム

レベルのセキュリティ設計が必要です。この例の風力発電システムにはこれらが不十分か全くありませんでした。2 3

物理レベルのセキュリティ設計がない(不十分)

  • 簡易な鍵で風力発電風車が施錠されていた
  • 風力発電風車に対する不正な侵入に対する検知/防御する仕組みがない
  • 風車の中のデバイスが物理的なデバイス接続に脆弱だった(USB接続された攻撃デバイスを検知/遮断できなかった)

ネットワークレベルのセキュリティ設計がない

  • ネットワークで接続された風力発電風車にネットワーク経由の攻撃対策がなかった

ソフトウェアレベルのセキュリティ設計がない

  • 操作コマンドなどの真正性を検証する仕組みがなかった
  • 機器の破壊につながる不正なコマンドに対する防御策がなかった

システムレベルのセキュリティ設計がない(不十分)

  • このシステムを設計したエンジニアは「風車に物理的には侵入できない」とする「物理レベルセキュリティの前提」に依存し、脅威に対して十分なセキュリティ設計を行こなっていなかった
  • システムレベルのセキュリティ設計には、脅威に対して複数レベルの対策が欠かせない、という基本が考慮されていなかった

 

セキュリティ対策の基礎、がない

既に記述した通り、セキュリティ対策を行うには物理、ネットワーク、ソフトウェア、システムのセキュリティ設計が欠かせません。これはセキュリティ対策の基礎中の基礎ですが、完全に見落されているケースはこの例の風力発電システムに限りません。自動車のコンピューターシステムが攻撃に対して脆弱であるケースも、この例と同じくセキュリティ設計がないことが原因で脆弱になっています。

この風力発電も自動車のセキュリティ対策にも、セキュリティ設計がない、原因は同じだと考えています。

  • セキュリティ対策(リスク対応策)はリスクの低減/廃除だけでなく、残存リスク/増加リスクも考慮する

これはセキュリティ対策の基礎で、ISO 27000、その前のISO 13335(1995年)から標準化されている概念です。標準化されてから20年以上経った今でも、残念ながら十分に浸透しているとは言い難い状況です。

風力発電システムの開発者は以下のように考えたはずです。

  • 風力発電機には「鍵を付けたから物理リスク対策OK!」

もしくは

  • 「物理リスク対策はITシステム開発者の範疇ではなく、建造物を設計するチームの責任。物理的なセキュリティは対策済み(物理リスク排除済み)として考慮しなくてもOK!」

ISO 27000では明確に物理的なセキュリティもITシステムのセキュリティ対策の範囲内であると定義し対策を求めています。ITシステムの開発者は、たとえ「ソフトウェアエンジニア」であっても「ITセキュリティを総合的に考慮する必要」があります。「物理リスクは知りません」では安全性が高いシステムは作れません。少なくとも

  • 十分な物理リスク対策が取られているか?
  • 物理リスク対策の残存リスク/増加リスクはあるか?
  • 残存リスク/増加リスクがある場合、ソフトウェア的に対策可能なモノがあるか?
  • ソフトウェア的に対策可能なモノがない場合、追加の物理リスク対策を要望できるか?

などを考慮しなければなりません。これらは物理セキュリティに限りません。ネットワークや他のソフトウェアコンポーネントに同じように考えて対策する必要があります。

  • 残存リスク/増加リスクも考慮する

が出来ていないケースがソフトウェアエンジニアの身近にあります。一時期、

  • プリペアードクエリ/プレイスホルダだけ使っていればSQLインジェクション対策はOK!

とするSQLインジェクション対策が提唱されていました。エスケープを考慮しないSQLインジェクション対策は不十分であることが明らかであるにも関わらず、にです。

  • セキュリティ対策(リスク対応策)はリスクの低減/廃除だけでなく、残存リスク/増加リスクも考慮する

はセキュリティ対策の基礎中の基礎です。考えた上でこれが出来ていないのは良い方です。残念ながら、考えもしていない、このような事例は枚挙にいとまがありません。

残存リスク/増加リスクも考慮する、は基礎の基礎です。基礎がない上に何かを作っても良い結果は生まれません。4

セキュリティ設計を行う場合、物理、ネットワーク、ソフトウェア、システムレベルで信頼境界線を引いてセキュリティ設計を行います。この「信頼境界設計」もセキュリティ対策の基礎の基礎ですが、理解出来ていないケースがあります。酷い場合は「信頼境界という考え方は使い物にならない」と誤解しているケースさえあります。(長くなるので信頼境界設計の話は省略)

物理的なセキュリティを確保する責任は仕様を実装するプログラマの責任ではありません。しかし、少なくともソフトウェア構築のプロジェクトマネージャーには「十分な物理的セキュリティ(ネットワークも)が確保できている」ことを検証/保証する責任があります。官僚主義で「物理やネットワークセキュリティは私(達)の責任ではない」とする取り組み方では十分にセキュアなシステムは作れません。

 

セキュリティ対策の目的、がない

セキュリティ対策の基礎がない、できていない、原因を突き詰めて考えると

  • セキュリティ対策の目的がない

に収斂されるでしょう。ITセキュリティ対策の目的は

  • ITシステムを許容可能な範囲のリスクに抑えて利用する

です。この目的をハッキリ意識していれば、

  • 物理、ネットワーク、ソフトウェア、システムのセキュリティ設計を行う
  • セキュリティ対策(リスク対応策)はリスクの低減/廃除だけでなく、残存リスク/増加リスクも考慮する

といった基礎の基礎の部分を「全く考えない」「ほとんど考えない」といった事態にはならないハズです。

 

セキュリティ問題が少くなるアプローチ

ここまでの説明で「セキュリティ問題が少くなるアプローチ」は理解できたと思います。簡単にまとめます。

  • 構造化が大事

まず体系的に問題に対応するには構造化が必要です。現在の一般に利用されているセキュリティ対策の考え方には「セキュリティ設計」が足りないか全く在りません。

  • 基礎が大事

適切な構造化を行うには「基礎が欠かせない」ことを既に紹介しました。セキュリティの基礎がない上にITシステムを作っても、十分なセキュリティの構築は困難/不可能です。

  • 目的が大事

十分なセキュリティとは何か?その定義を忘れていたり、知らないなら達成できなくても当たり前です。人はよく「目的」と「手段」を勘違いします。リスクを削減/廃除する対策は「手段」に過ぎません。セキュリティ対策の目的は「リスクを許容範囲内に抑えてITシステムを利用する」です。

リスクを許容範囲内に抑える、とは「リスクを許容範囲内に管理する」です。ITシステムを利用する以上、ITシステムを利用するリスクを完全にゼロにできません。つまりITセキュリティ対策の本質はリスクマネジメントです。

  • 明確な目的を持ち
  • 論理的に基礎を理解し
  • 構造化されたセキュリティを構築する

これが「セキュリティ問題が少くなるアプローチ」です。

ここで紹介した考え方であれば、細かなセキュリティ対策であるSQLインジェクション対策で「プリペアードクエリ/プレイスホルダだけ使っていれば十分」「入力検証はせキュティ対策とは言えない」とする基礎的な勘違いも防げるはずです。

参考:完全なSQLインジェクション対策セキュリティ対策を論理的に検証する方法根本的なセキュリティ対策とは何か?

問題や課題もありますが、ISO 27000は体系的に「リスクを許容範囲内に管理する標準」として有用です。ISO 27000だけを読んで体系的にITセキュリティを構築できるか?そこが問題であり、課題だと思います。

 

経営者/マネージャーが知るべきセキュリティ

平成29年度も「岡山大学 ビジネスマインド養成講座」の講師を担当しています。今年の担当講座「経営者/マネージャーが知るべきセキュリティ」は11月11日(土)です。実は知られていないセキュリティ対策の基礎の基礎、基礎を知らない為に発生するリスク、この問題にどのような対応すべきか?を解説します。

ITセキュリティ対策の本質とはリスクマネジメントです。このため”経営者/マネージャー”とタイトルに入っていますが、全てのITシステム利用者/開発者が対象です。ご都合の良い方は是非受講ください。無料公開講座です!5

 


  1. 一定規模を超えると完全にバグがないシステム構築がほぼ不可能であることと同じように、完全にセキュリティリスクがないシステム構築は不可能です。 
  2. これ以外にデータがあります。データのセキュリティの解説はより複雑なので、ここでは省略します。 
  3. ここでは風力発電システムを事例として取り上げていますが、全てのITシステムに共通する問題です。セキュリティ対策の構造化が不十分であることが原因で、不必要にリスクに対して脆弱になっているシステムばかりです。 
  4. 基礎は”残存リスク/増加リスクの考慮”だけではありません。 
  5. こういった「基礎も目的も理解されていない」現状を解消する努力は本来IPAなどのITセキュリティを啓蒙する機関はセキュリティ専門家が力を入れて啓蒙すべき、なのですが肝心のセキュリティ専門家と言われている人にも基礎を理解していない方も居るのが現状です。 

Comments

comments

実はあまり知られていないセキュリティの常識。現状を知らないと隠れた大きなリスクを見逃します。