X

セキュアコーディング論理

「脆弱性を局所的に潰す」はアンチプラクティス

本物の「セキュアコーディング」(セキュアプログラミング)を知ればもう議論など必要ない、と思っています。本物の「セキュアコーディング」を「知ろうとしない」と幾らでもアンチプラクティスを作ってしまいます。 議論は終り、と思っていたのですがそうも行かないようなので紹介します。セキュアコーディングの概念を全く知ろうとしないで、セキュリティを作るのは「ただの無駄」です…

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

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

セキュリティの原理、原則、ベストプラクティス

「セキュリティの」と付けていますが、どの分野でも共通することだと思います。 何事でも論理的に何かのガイドライン/ルールを作る場合、まず変えることのできない 原理 - 事物・事象が依拠する根本法則 を見つけ、その原理から導き出される 原則 - 多くの場合に共通に適用される基本的なきまり・法則 を作り、さらに特定の条件下の具体的な事例として ベストプラクティス …

出力対策の3原則 + 1原則

ソフトウェアの不具合/脆弱性を無くすためには、出力先に対して無害であることを保障する出力対策が重要です。どんな出力でも3つの方法で無害化できます。 このブログでは基本として、セキュアコーディングの概念に基き説明しています。先ずはよくある入力対策と出力対策の区別がついていない誤りから紹介します。 参考:IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき…

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

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

まだ誰も知らない脆弱性/攻撃に備える方法

セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ/形式は厳格にバリデーションすべきです。1 厳格なバリデーションは開発者が意識/把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。 適切なバリデーションは最強のセキュリティ対策の1つ2です。強い…

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

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

4種類の信頼境界とセキュリティ構造 – 構造設計なしのセキュリティ対策?

セキュリティ対策には設計図があります。少なくともアーキテクチャー図があります。しかし、何故かソフトウェアの場合は設計図もアーキテクチャー図も書けないセキュリティ対策が当たり前になっています。国際情報セキュリティ標準やセキュリティガイドラインを普通に理解すれば解ること、セキュリティ対策の基礎の基礎にも関わらず、です。 これは一般開発者の問題というより、セキュリ…

ゼロトラストをより細かく分解する

セキュリティを維持する為にはゼロトラスト、何も信頼しない所から始めて信頼できることを検証する、作業が必要です。ゼロトラストは信頼できるモノと信頼できないモノに分ける作業ですが、より細かく考える必要があります。 ※ より細かく考える、とはいっても「細かい事だけ」では合成の誤謬にハマります。全体と詳細、両方をバランスよく「ゼロトラスト」することが大切です。 (さ…

Python 2.7.14から学ぶセキュリティの基本

Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。 Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります…

セキュリティ対策が論理的に正しいか検証する方法

全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。 しかし、容易ではないからといって諦める訳にもいきません。不完…

当たり前?非常識?開発者必修のセキュリティ概念 Top 10

ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング/セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。 ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で…

入力値の種類は3種類しかない

入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる/できない、で大きな違いができてしまいます。 (さらに…)

アプリケーションのセキュリティと必要十分条件

セキュリティと必要十分条件については他のエントリでも書きました。以前書いたエントリではミクロの視点から単純な加算関数で考えました。今回はもう少し大きなマクロの視点、アプリケーションのセキュリティの必要十分条件を考えてみます。 論理的なセキュリティを考える為には必要なので書きました。ここに書いたことは読み物としては退屈かも知れませんが、重要な事だと考えています…

戸締りと金庫とセキュリティ

ずっと感じてきたことですが、ブログにしていませんでした。具体的には 戸締りする前に、金庫を買うセキュリティ対策 です。 IT技術者以外の方向けに書いています。最近問題だ、と話題のStruts2というソフトウェアを引き合いに書いていますが、技術的なことはほとんど書いてありません。 (さらに…)