メソッド／関数呼び出しによるコード実行問題とその対策
言語の機能としてシリアライズされた”データ”からオブジェクトを生成（PHPの場合、unserialize関数）したり、呼び出すメソッド／関数を指定できる機能（PHPの場合、call_user_func関数／call_method関数など）を使ったりすると意図しないメソッド／関数が呼ばれるケースを想定しなければなりません。
インジェクション脆弱性の発生原理と対策 ＋ ISO標準
インジェクション脆弱性の発生原理は簡単です。エンジニアではないマネージャー向けに作った資料を基に原理を紹介します。
インジェクション脆弱性は、その種類に関わらず原理は同じです。原理が同じということは、対策も同じです。一つ一つのインジェクション脆弱性がどのように作られ、攻撃されるのか？は少しずつ異なりますが、基本的な部分は同じです。別々に考えるより、一まとめに考えて理解した方が応用もでき、新しい仕組みなどが生まれた場合にも対応できます。
経営者・マネージャーが知るべき情報セキュリティ
追記：平成29年度の講座の情報は
をご覧ください。
岡山大学大学院のビジネスマインド養成講座の講義資料を公開します。
http://www.slideshare.net/yohgaki/ss-50426869
PDFダウンロードはこちら
誤字脱字、誤りなどがあったらご指摘頂けると助かります。
ISO 27000とセキュアプログラミング
セキュアプログラミングの啓蒙にも少々食傷気味ですが、今回もセキュアプログラミングの話題です。IPAのセキュアプログラミング講座Web編は削除予定であるとFacebookではお伝えしましたが、ブログではまだだったので合わせて紹介します。
ISO 27000がセキュアプログラミングついてどのように書いているのか紹介します。ISO 27000シリーズはISMS（Information Secuirty Management System – 情報セキュリティマネジメントシステム）認証の根幹となっている国際セキュリティ標準です。ISMS導入で自動的にセキュリティ問題に対応できる！といったモノではありませんが、体系的なセキュリティ導入にとても役立つ規格で2015年6月29日時点で４６４６組織の認証登録があります。
徳丸さんのブログに対するコメント
最初、書いた時はユーザーが一人だけと頭にあったので思いっきり誤解していました。確かに複数ユーザーの場合は真正性に問題があります。修正版の差分をアーカイブを更新しておきました。
SMSを利用した2要素認証の脆弱性
SMSを利用した2要所認証を利用しよう、と検索される方も多いのでブログを書きます。SMSを利用した2要素認証の場合、Google認証システムを利用した場合に比べ、アプリの導入が不必要で容易に導入できます。しかし、リスクが高い部分があるので注意が必要です。
個々の脆弱性に対応する効果的な方法
全体的なセキュリティ対策やセキュリティ対策の基本的概念の話が続いたので、個々の脆弱性に対応するための効果的な方法を紹介します。前提知識なく、個々の脆弱性に対応するには、個々の脆弱性全て知る必要があります。
必要条件と十分条件 〜不十分なセキュリティ対策で大丈夫？〜
昨日、セキュリティの話をしていて当たり前のことですが見過ごしていた点を教えてもらいました。セキュリティ対策の必要条件と十分条件です。
IT以外のセキュリティ対策から学ぶITセキュリティ 〜害虫駆除より防虫〜
セキュリティ対策の基本はどの分野でもあまり変わりません。全体対策と個別対策、これらを総合的に駆使して安全性を維持します。全体対策、個別対策は両方とも”必要条件”です。全体対策だけ、個別対策だけ、では思ったような安全性を得ることは困難です。
ITセキュリティ以外の対策からITセキュリティについて考えてみます。
セキュアなソフトウェアアーキテクチャー
セキュアなソフトウェアアーキテクチャーに関するプレゼンを公開しました。
http://www.slideshare.net/yohgaki/ss-49863218
これだけだと契約プログラミングがどういうモノなのかよく分からないと思います。
を参考にしてください。
WordPressのGoogle Authenticatorを無効にする一番簡単な方法
このブログでは二段階認証にGoogle認証システム（スマホアプリ）とGoogle Authenticator（WordPressプラグイン）を使っています。携帯の修理でGoogle認証アプリを入れ忘れていたので、またブログにアクセスできなくなりました。前回はデータベースを直接操作してGoogle Authenticatorプラグインを無効にしたのですが、もっと簡単な方法があったので紹介します。
セキュリティ対策の目的と手段 〜 根本的誤りの元 〜
目的と手段、これを取り違えて大きな誤りを犯してしまうことはよくあります。これはセキュリティ対策に限ったことではありません。
対策をセキュリティ対策の目的と手段を取り違えると、根本的な誤りを犯してしまいます。
備考：目的と手段の取り違えが根本的な原因と言えますが、「セキュリティ対策」定義を取り違えているとこのブログの内容は理解しずらいかも知れません。セキュリティ対策に「緩和策」や「リスク増加」が含まれることを認識されていない方はまずセキュリティ対策の定義を確認ください。
容易に導入できるセキュア開発メソドロジー – SAMM
OpenSAMMのSAMMとはSoftware Assurance Maturity Model（ソフトウェア保証成熟度モデル）の略で名前の通り、成熟度モデルの一種です。成熟度モデルで有名な米カーネギーメロン大学のCMMI（Capability Maturity Model Integration – 能力成熟度モデル統合）同類の成熟度モデルに基づくセキュアなソフトウェア開発の方法論です。OpenSAMMはCMMIに比べるとかなり簡易化されており、小さな組織でも導入しやすいモデルになっています。
SAMMはプライバシーマーク認証やISMS認証を取得している組織でも有効です。これらの認証制度と重複している部分もありますが、ソフトウェア品質保証に特化したSAMMはより効果的かつ広範囲にセキュア開発をサポートできます。SAMMより広範囲な領域をサポートするCMMIを導入している組織には必要ありません。
私の会社では比較的導入しやすいセキュア開発メソドロジーであるSAMMを推奨し、導入サポートも行っています。SAMMは新しい物ではなく7年ほど前に最初のバージョンがリリースされており、当時から推奨しています。
「個々の脆弱性対策だけやれば良い」とする議論に組みしない理由
このブログを継続的に読んでいる方なら私が「個々のセキュリティ脆弱性対策も重要だが、基本的考え方や概念はより重要である」と考えていることがわかると思います。「個々の脆弱性対策だけやれば良い」とする議論がありますが、これには色々な欠陥があります。このため、「個々の脆弱性対策だけやる」では効果的なセキュリティマネジメントができません。つまり、より危険なセキュリティになってしまいます。
追記：このエントリだけではなぜマネジメントが大切なのかは伝わらないと思うので、容易に導入できるセキュア開発メソドロジー – OpenSAMM を書きました。こちらも参照ください。
入力バリデーションがセキュリティ対策かどうかは、”どうでもいい”！？
徳丸さんとの議論は終わっている いるので議論することはありません。しかし、 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ というおかしなスライドが目に入ったのでコメントしておきます。今現在で2万近くのビュー回数もあると放っておけません。
”セキュリティ専門家”という肩書を持つ方が非論理的／非科学的な独自のセキュリティ理論を展開されるようでは、誤解してしまった開発者がセキュアでないコードを書いてしまいます。どのように非論理的／非科学的なのか簡単にコメントします。