リスク分析とリスク対応をしよう

情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。

情報システムは「モノ」(物と人)、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。

当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない!といった場合も多いので仕方ない側面もあります。

しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。

※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。

“リスク分析とリスク対応をしよう” の続きを読む

究極のセキュリティ要求事項とは?

前のブログでリスク分析について書きました。リスク分析方法を書く前にセキュリティ要求について書きます。ISO 27000では6つのセキュリティ要素が情報セキュリティに必要であるとしています。

  • Confidentiality – 機密性
  • Integrity – 完全性
  • Availability – 可用性
  • Reliability – 信頼性
  • Authenticity – 真正性
  • Non-repudiation – 否認防止 (Accountability – 責任追跡性)

これらが基礎的な情報セキュリティの要求事項になります。以上です。

※ 2014年の改訂でセキュリティのCIAに信頼性、真正性、否認防止を加えたモノが情報セキュリティに必要な要素と定義されています。ISO 13335(古い情報セキュリティ標準)で定義していた要素に戻った形になりました。

これで終わってしまうと何の事なのか?究極の要求事項とは何なのか?となると思います。もう少し説明します。究極の要求事項を知って適用するだけ、でも大きな違いが生まれると思います。

“究極のセキュリティ要求事項とは?” の続きを読む

無視されているリスク分析

炎上プロジェクトの主な原因の1つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。

これと同じことが情報セキュリティ対策でも起きています。

致命的な脆弱性が残っているシステムの主たる原因の1つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリティ要求定義なし、であることが少なくない数あります。IoTやスマートカーのセキュリティを見れば明らかです。セキュリティ要求定義が不明確か無い状態で作った、としか思えない事例が数えきれません。

漏れのないセキュリティ要求定義には漏れのないリスク分析が必要です。

  • ◯◯対策として△△を実施する

といったセキュリティ仕様をセキュリティ要求だと勘違いしているケースも数えきれません。

システム要求定義がないプロジェクトが簡単に炎上するように、セキュリティ要求定義がないシステムも簡単に無視することが不可能な脆弱性だらけのシステムになります。

特にソフトウェアの分野では「リスク分析」が不十分過ぎる、さらには全く無い、システムで溢れています。これでは十分な安全性を効率良く達成することは不可能です。

続きを読む

データフロー分析とセキュリティ

データフロー分析とはコールフローグラフ(CFG)を使ってプログラムを分析する手法です。ソフトウェアのセキュリティ対策にもデータフロー分析は広く利用されています。例えば、静的ソースコード検査ツールは静的(=プログラムを動作させず)にプログラム実行時のデータフローを分析し、問題を発見する手法です。

コールフローグラフ

データフロー分析の基礎知識はハーバード大学コンピューターサイエンス学科の講義資料(PDF)が参考になります。こちらを参考にしてください。英語の資料ですが容易な内容です。

“データフロー分析とセキュリティ” の続きを読む

攻撃可能面の管理 – セキュリティの基本

Attack Surface (攻撃可能面=攻撃可能な箇所)の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。

攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析(=リスク分析)します。その上でできる限り攻撃可能な箇所を削減(=リスク削減)します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基本的な管理です。

Attack Surface (攻撃可能面)

The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attacker”) can try to enter data to or extract data from an environment.[1][2] Keeping the attack surface as small as possible is a basic security measure.

出典:Wikipedia

日本語訳すると以下のようになります。

ソフトウェア環境における攻撃可能面は不正なユーザー(攻撃者)がデータを攻撃対象に入力または取り出し可能な様々箇所(アタックベクター)の集合である。攻撃可能面を可能な限り小さくするのは基本的なセキュリティ対策である

“攻撃可能面の管理 – セキュリティの基本” の続きを読む

入力バリデーションで許可した文字で発生するリスク

入力バリデーションでほぼ全てのインジェクションリスクを回避/防止できるケースは以前書いたブログで紹介しています。

今回は趣向を変えて、入力バリデーションで許可してしまった文字で発生するリスクをざっと紹介します。

“入力バリデーションで許可した文字で発生するリスク” の続きを読む

今のソフトウェアセキュリティが不十分である原因とは?

ソフトウェアのセキュリティを向上させよう!と日々奮闘している方も多いと思います。しかし現在、ソフトウェアセキュリティは十分、と言える情報からは程遠い状態です。

なにが足りないのか?なぜ不十分になるのか?基本的な部分の見落としに原因があります。

“今のソフトウェアセキュリティが不十分である原因とは?” の続きを読む

”形式的検証”と”組み合わせ爆発”から学ぶ入力バリデーション

形式的検証とは

形式的検証(けいしきてきけんしょう)とは、ハードウェアおよびソフトウェアのシステムにおいて形式手法数学を利用し、何らかの形式仕様記述やプロパティに照らしてシステムが正しいことを証明したり、逆に正しくないことを証明することである

英語ではFormal Verificationとされ

formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics.

と説明されています。形式手法として紹介されることも多いです。

参考: 形式検証入門 (PDF)

形式的検証は、記述として検証する方法から数学的にプログラムが正しく実行されることを検証する仕組みまで含みます。数学的な形式的検証では、可能な限り、全ての状態を検証できるようにしてプログラムが正しく実行できることの証明を試みます。

参考:ソフトウエアは硬い (日経XTECHの記事)

契約プログラミング(契約による設計 – Design by Contract, DbC)も形式的検証の1つの方法です。

形式検証の仕組みを知ると、厳格な入力バリデーションが無いと”組み合わせ爆発”により、誤作動(≒ セキュリティ問題)の確率も爆発的に増えることが解ります。

“”形式的検証”と”組み合わせ爆発”から学ぶ入力バリデーション” の続きを読む

エンジニアならわかる文字エンコーディングバリデーションの必要性

入力バリデーションで文字列の妥当性を検証(保証)しないと、不正文字問題の解決はできません。

よく「文字エンコーディングバリデーションは入力バリデーションしなければならない」と紹介はするのですが、その理由を詳しく解説していませんでした。これは文字エンコーディング攻撃の仕組みを理解してれば分かる事なのでしていませんでした。

しかし、文字エンコーディング攻撃の仕組みを理解していても必要なし、とする意見があるので理解り易く説明します。(理解りづらかったら教えてください)UTF-8のみですが、他の文字エンコーディングでも基本は同じです。

“エンジニアならわかる文字エンコーディングバリデーションの必要性” の続きを読む

セキュリティを論理的に構築する方法

セキュリティの原理、原則、ベストプラクティスに自分でコメントを追加しました。以前、論理的にセキュリティ対策を検証する方法論理的なセキュリティ対策の評価方法は書いたのですが、論理的にセキュリティを構築する方法は書いていないことを思い出しました。追加したコメント欠陥だらけのソフトウェアセキュリティ構造を紹介したブログをベースにセキュリティを論理的に構築する方法を紹介します。

このエントリの解説はCERT、つまり米カーネギーメロン大学、の資料をベースにしています。

“セキュリティを論理的に構築する方法” の続きを読む

ソフトウェアはセキュリティの原理・原則から間違っている「入り口ノーガード設計」のままで良いのか?

現在のWebアプリケーションのほとんどは「入り口対策」がない「入り口ノーガード設計」です。

※ アプリケーションの入力処理、つまりMVCアーキテクチャーならコントローラーレベルで「入り口対策」がない設計が「入り口ノーガード設計」です。

このような設計になっているので、本来は自然数だけのハズのHTTPヘッダーのContent-Length(やContent-Type/Content-Disposition)にプログラムが書けてしまったStruts2 Webアプリにより国内ではクレジットカード情報が何十万件も盗まれる、米国では1億4千万件以上の信用情報が漏洩する、といった事件が発生しています。

幸い、「入り口対策」がない「入り口ノーガード設計」でもこういった大規模インシデントになるような脆弱性の攻撃は多くありません。しかし、話題にならないだけで多数のインシデントが世界中で発生していると考えられます。

先の事例はStruts2/フレームワークのセキュリティ問題、と捉えられていることが多いと思います。しかし、これは本質的にセキュリティ原則を無視した「入り口ノーガード設計」の問題です。

コード検査していると「入り口対策」をしていて、本当に良かったですね!というケースに出会うことが少なくありません。

2018年5月からEUでGDPRが施行されます。GDPR違反となると2000万ユーロまたは全世界売上の4%のどちらか高い方が罰金(組織によっては1000万ユーロまたは全世界売上の2%)となります。GDPRには様々な要件が要求されていますが、国際情報セキュリティ標準であるISO 27000で”普及している”とされた”セキュアプログラミング技術”の原則さえ採用しないシステムで個人情報漏洩が起きた場合の被害は、簡単に会社を潰すレベルの損害になる可能性があります。

“ソフトウェアはセキュリティの原理・原則から間違っている「入り口ノーガード設計」のままで良いのか?” の続きを読む

出力対策”のみ”のセキュリティはアンチプラクティス

「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。

アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策(=リスク管理)は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュリティ対策は大抵アンチプラクティス2です。

※ 今まで出力対策”だけ”がセキュリティ対策だと勘違いしていた方には確証バイアスが働きやすいようです。論理的/構造的にどうすればリスクを効果的に削減できるのか?を考えると理解るはずです。

“出力対策”のみ”のセキュリティはアンチプラクティス” の続きを読む

実は知られていない?リスク対策の原則?

ISO 31000(リスクマネジメント標準規格)はa)からk)まで、11のリスク管理の原則を定めています。

ITエンジニアであればISO 27000(情報セキュリティマネジメント標準規格)を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎/基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。

情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。

リスク対策の原則が知られていない?ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。

“実は知られていない?リスク対策の原則?” の続きを読む

なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策

強いデータ型を持つ言語は弱いデータ型の言語(PHPやJavaScriptなど)に比べよりセキュアなのか?「なぜよりセキュアなのか?」簡単に解説します。

結論から書くと「強いデータ型」はそれだけでは「強いセキュリティ構造」を作るモノではなく、少しだけ安全なコードを書く手助けくらいの効果しか期待できません。安全かつ正しく動作するプログラムを最小のコストで作りたい場合、契約プログラミングを行うのが効果的です。

“なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策” の続きを読む

ほぼ全てのインジェクション攻撃を無効化/防止する入力バリデーション 〜 ただし出力対策も必須です 〜

入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか?を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化/防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか?

ソフトウェア開発者が知っておくべきセキュリティの定義/標準/ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。

厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。

重要:セキュア/防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。どちらかをすれば良い、ではなく入力と出力の両方で対策を行います。よく誤解されるので注意してください。

重要 その2:ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。ホワイトリストによる入力バリデーションは”無害化”ではありません。”妥当性の検証”です。

重要 その3あまり広く理解されていませんが、セキュアコーディングの第1原則は「全ての入力をバリデーションする」、第7原則が「全ての出力を(エスケープ/API/バリデーションで)無害化するです。セキュアコーディングはISMS/PCI DSSなどの認証規格の要求事項です。

なぜこのようなブログを書いたか?というと入力バリデーションしていても、”ほぼ全てのインジェクション攻撃を無効化/防止できる入力バリデーション”でない場合、入力時のセキュリティ処理だけでは”残存リスク”としてインジェクション攻撃が可能になる、という事を理解して欲しいからです。

参考:

“ほぼ全てのインジェクション攻撃を無効化/防止する入力バリデーション 〜 ただし出力対策も必須です 〜” の続きを読む

今時のShellcodeとセキュア/防御的プログラミング

コンピュータセキュリティのことを考えるとShellcode(シェルコード)のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています

Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。

私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。

“今時のShellcodeとセキュア/防御的プログラミング” の続きを読む

間違いだらけのHTTPセッション管理とその対策

HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。

まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成(リセット)も不完全な物が多いと思います。

参考:

“間違いだらけのHTTPセッション管理とその対策” の続きを読む