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

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

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

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

去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。 ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。 (さらに…)

JWTが凄い使われ方をしているようなので、可能な限りマシなCookieベースのセッションセーブハンドラーを書きました。メリットは サーバー側のリソース（DBやファイルなど）を使わないので簡単にスケールする ことにあります。 しかし、Cookieの保存は大きく分けて3つの問題があります。 ネットワークが不安定だとデータが失われる場合がある（ネットワーク接続の問…

危険な脆弱性であっても名前を付けないとなかなか認知してもらえない、といったことがよくあります。「データ検証をしないアプリ仕様」は危険で脆弱な仕様ですが、基本的な対策を実装しない危険性はあまり認知されてないと思います。例えば、とんでもないGDPR制裁金を支払うといったリスクが高くなります。 名前が必要なのかも知れません。 実は新しく考えなくても既にOWASPが…

ITセキュリティ対策の概念で最も足りていないモノは「構造化」ではないでしょうか？ システム開発者は常に「システムの構造化」を考えています。構造化プログラミング、オブジェクト指向設計、DoA、DDDなど「システムの構造化」には様々な構造が考えられています。 何故か「セキュリティの構造化」を十分考えていないのが現状です。その結果、「”基本構造が無い”場当たり的セ…

基本的にWebアプリへの入力データは全てバリデーションする必要があります。具体的には以下のような構造でバリデーションが必要です。 https://blog.ohgaki.net/there-are-3-types-of-validations Webアプリへの入力データの種類は大抵の場合、数百程度です。Validate for PHPはこれらの入力仕様を定義…

ソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK！でしょうか？ ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。 (さらに…)