カテゴリー
Computer Development Programming Secure Coding Security

おかしなCWE-20の読み解き方(CWE-20入門)

徳丸さんが独自のCWE-20(≒入力バリデーション)解説を行っているので、CERT(1989年に米カーネギーメロン大学に設置された世界最古のコンピューターセキュリティ専門機関)が30年くらい前から提唱し、ISO 27000/NIST SP-800-171/PCI DSS等で要求されているCWE-20の解説を改めて書きます。

CWE-20(入力バリデーション)がなぜ重要なのか?それはCERT/MITRE/ISOが入力バリデーションをどのように解説しているかを見れば解ります。いずれも最も重要/一番最初の対策としています。(※ MITREはCWEを管理する組織で、CWEの本家と言える組織です)

徳丸さんのブログより前に、このブログでもCWE-20について以下のブログで既に書いています。CERT(≒米カーネギーメロン大学のコンピューターサイエンス学科)が提唱するセキュアコーディング/コンピューターサイエンスの基盤となる基礎概念の紹介では十分ではなかったかも知れません。

カテゴリー
Development Programming Secure Coding Security

セキュリティ機能の利用はソフトウェアセキュリティではない

7PK(7つの悪質な領域 – CWE-700として定義されている業界標準のソフトウェアセキュリティ分類)では「セキュリティ機能はソフトウェアセキュリティではない」としています。明白なのは「他のソフトウェアやデバイスのセキュリティ機能によるセキュリティ」です。7PKでは例としてHTTPSを挙げています。

HTTPSは必要なセキュリティ機能ですが、HTTPSの利用=ソフトウェアセキュリティ、ではありません。HTTPSを使って保護できる分野はありますが、HTTPSを使っても開発者が作っているソフトウェアのセキュリティを作る物ではないからです。

結局の所、他の”モノ”に頼らず開発者が作っているソフトウェアの中でセキュリティを作らないとソフトウェアは安全になりません。7PKの「セキュリティ機能はソフトウェアセキュリティではない」とは、「ソフトウェアセキュリティはそのソフトウェアを開発している開発者が実現する」ということです。

7PKソフトウェアセキュリティの基礎概念の一つと考えられています。 (CWE-700) セキュリティ機能を使うこと自体はセキュリティ対策になります。しかし、セキュリティ機能を使う=ソフトウェアセキュリティ対策、にはなりません。「セキュリティ機能を使う」は「必要なセキュリティ対策」のサブセット(一部、それも極一部)でしかないからです。「セキュリティ機能を使う」=「必要なセキュリティ対策」、こういった誤解が度々あるので7PKでは「セキュリティ機能」の解説として態々明示していると思われます。一言でいうなら「ソフトウェアセキュリティは”その”ソフトウェアを作っている開発者の責任に於て作るモノ」です。「◯◯、△△、を使えばOKではない」です。

カテゴリー
Security

欧州の個人データ移転規制が日本は対象外となる件について

2019/1/22の日経の記事で「欧州の個人データ移転規制、日本は対象外 枠組み23日発効」と報道されました。

一部に誤解を招きかねない解説が見られます。「欧州の個人データ移転規制」が「日本は対象外」となるのですが、これは利便性が上るだけで日本企業に高額なGDPR制裁金が課されなくなる訳ではありません。移転規制がなくなり便利になりますが、制裁金が課されるリスクは高くなります。

カテゴリー
Computer Development PHP Security Programming Secure Coding Security

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

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

カテゴリー
Computer PHP Security Secure Coding Security

セキュリティ対策の目的

何度か同じテーマで書いているのですが改めて簡単にまとめます。

適切な「目的」でなかったり、間違った「目的」を設定してしまうと目的を達成が困難になります。目的の設定/定義は重要です。

カテゴリー
Computer Database Development PHP Security Programming Secure Coding Security

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

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

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

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

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

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

カテゴリー
Computer Development PHP Security Secure Coding Security

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

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

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

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

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

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