X

リスク分析

危険なコードを書くメカニズム

世の中のソフトウェアには危険なコードが埋もれています。これがセキュリティ問題の原因になっています。なぜ危険なアプリケーションが書かれるのか?その仕組みを理解すると、対策が可能です。 (さらに…)

セキュリティ対策の目的

何度か同じテーマで書いているのですが改めて簡単にまとめます。 適切な「目的」でなかったり、間違った「目的」を設定してしまうと目的を達成が困難になります。目的の設定/定義は重要です。 (さらに…)

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

情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。 情報システムは「モノ」(物と人)、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。 当然、ソフト…

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

前のブログでリスク分析について書きました。リスク分析方法を書く前にセキュリティ要求について書きます。ISO 27000では6つのセキュリティ要素が情報セキュリティに必要であるとしています。 Confidentiality - 機密性Integrity - 完全性Availability - 可用性Reliability - 信頼性Authenticity -…

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

炎上プロジェクトの主な原因の1つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。 これと同じことが情報セキュリティ対策でも起きています。 致命的な脆弱性が残っているシステムの主たる原因の1つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリ…

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

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

攻撃可能面(アタックサーフェス)の管理 – セキュリティの基本

Attack Surface (攻撃可能面=攻撃可能な箇所)の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。 攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析(=リスク分析)します。その上でできる限り攻撃可能な箇所を削減(=リスク削減)します。攻撃可能面の分析と管理とはリスク分析と管理です。セキ…

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

入力バリデーションでほぼ全てのインジェクションリスクを回避/防止できるケースは以前書いたブログで紹介しています。 今回は趣向を変えて、入力バリデーションで許可してしまった文字で発生するリスクをざっと紹介します。 ※ ここで紹介する考え方は脆弱なブラックリスト型です。より安全な方法はホワイトリスト型の考え方です。参考: ほぼ全てのインジェクション攻撃を無効化/…

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

ソフトウェアのセキュリティを向上させよう!と日々奮闘している方も多いと思います。しかし現在、ソフトウェアセキュリティは十分、と言える情報からは程遠い状態です。 なにが足りないのか?なぜ不十分になるのか?基本的な部分の見落としに原因があります。 (さらに…)

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

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

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

入力バリデーションで文字列の妥当性を検証(保証)しないと、不正文字問題の解決はできません。 よく「文字エンコーディングバリデーションは入力バリデーションしなければならない」と紹介はするのですが、その理由を詳しく解説していませんでした。これは文字エンコーディング攻撃の仕組みを理解してれば分かる事なのでしていませんでした。 しかし、文字エンコーディング攻撃の仕組…

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

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

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

現在のWebアプリケーションのほとんどは「入り口対策」がない「入り口ノーガード設計」です。 ※ アプリケーションの入力処理、つまりMVCアーキテクチャーならコントローラーレベルで「入り口対策」がない設計が「入り口ノーガード設計」です。 このような設計になっているので、本来は自然数だけのハズのHTTPヘッダーのContent-Length(やContent-T…

「出力対策だけのセキュリティ設計」が誤りである理由

まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。 なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか? (さらに…)

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

「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。 アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策(=リスク管理)は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュ…