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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェア開発環境のセキュリティ対策

ソフトウェアの開発環境は通常の環境と違う対策が必要です。その理由は開発環境には

  • 他人が書いた未検証のモノ
  • 自分が書いた実験用のモノ
  • 他人または自分が書いた作りかけのモノ
  • 制御された環境での利用を前提としたモノ
  • 意図的に利用している新しいモノ(リリース前のソフトウェアなど)
  • 意図的に利用している古いモノ(古いシステムサポートためなど)

※モノにはコード/ライブラリ/ツール/アプリ/システム などがあります。

などがある為です。開発環境はその他の環境に比べ「とにかく危険なモノがいっぱい」です。

更に最近ではソーシャルコーディングが当たり前になり、他人が書いた未検証のコードがどんどん実行される状態も当たり前です。それも1つ2つのライブラリではなく、依存性から何百、場合によっては何千というライブラリなどが自動的にダウンロードされ実行されています。

これがどういう状況かというと「PCがやっと使えるくらいのユーザーが、インターネットからプログラムをダウンロードしまくって実行している状況」とあまり変わりません。

参考: SOHO・家庭の安全なネットワーク環境2018

“ソフトウェア開発環境のセキュリティ対策” の続きを読む

なぜセキュリティ対策はリスクの増減として考えるのか?

ITセキュリティ標準ではセキュリティ対策(リスク対応)はリスクの増減に着目して対策を行います。(最初のリスクアセスメントが正しく実行されていれば、リスクの増減を見るだけで管理/対策できる)概念的な部分は理解しづらいようなので、なぜセキュリティ対策をリスクの増減として考えるのか解説します。

ここで紹介していることはリスク管理の基本的な概念です。リスク対策はITセキュリティ対策に対して上位互換、つまりより広い範囲のリスク/セキュリティ対策です。

“なぜセキュリティ対策はリスクの増減として考えるのか?” の続きを読む

セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!

セキュアコーディング/セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。(※ 対策の目的が何か?などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません)

どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング/セキュアプログラミングのガイドラインなどがどうなっているのか?紹介します。

このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング/セキュアプログラミングとは何か?は過去のブログをご覧ください。

“セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!” の続きを読む

実は標準の方が簡単で明解 – セキュリティ対策の評価方法

なぜセキュリティ対策の区別が異なるのか?長年疑問だったのですが、その理由の一つが判りました。

以下は、本質的には似たような入力確認である「WAFはセキュリティ対策」で「入力バリデーションはセキュリティ対策ではない」のか?と質問した時のツイートです。

どうも「目的」がセキュリティ対策であるか否か、の基準のようです。「セキュリティ対策の定義」が曖昧という問題もありますが、ここでは省略します。

“実は標準の方が簡単で明解 – セキュリティ対策の評価方法” の続きを読む