IT以外のセキュリティ対策から学ぶITセキュリティ 〜害虫駆除より防虫〜
セキュリティ対策の基本はどの分野でもあまり変わりません。全体対策と個別対策、これらを総合的に駆使して安全性を維持します。全体対策、個別対策は両方とも”必要条件”です。全体対策だけ、個別対策だけ、では思ったような安全性を得ることは困難です。
ITセキュリティ以外の対策からITセキュリティについて考えてみます。
セキュアなソフトウェアアーキテクチャー
セキュアなソフトウェアアーキテクチャーに関するプレゼンを公開しました。
これだけだと契約プログラミングがどういうモノなのかよく分からないと思います。
を参考にしてください。
セキュリティ対策の目的と手段 〜 根本的誤りの元 〜
目的と手段、これを取り違えて大きな誤りを犯してしまうことはよくあります。これはセキュリティ対策に限ったことではありません。
対策をセキュリティ対策の目的と手段を取り違えると、根本的な誤りを犯してしまいます。
備考：目的と手段の取り違えが根本的な原因と言えますが、「セキュリティ対策」定義を取り違えているとこのブログの内容は理解しずらいかも知れません。セキュリティ対策に「緩和策」や「リスク増加」が含まれることを認識されていない方はまずセキュリティ対策の定義を確認ください。
容易に導入できるセキュア開発メソドロジー – SAMM
OpenSAMMのSAMMとはSoftware Assurance Maturity Model（ソフトウェア保証成熟度モデル）の略で名前の通り、成熟度モデルの一種です。成熟度モデルで有名な米カーネギーメロン大学のCMMI（Capability Maturity Model Integration – 能力成熟度モデル統合）同類の成熟度モデルに基づくセキュアなソフトウェア開発の方法論です。OpenSAMMはCMMIに比べるとかなり簡易化されており、小さな組織でも導入しやすいモデルになっています。
SAMMはプライバシーマーク認証やISMS認証を取得している組織でも有効です。これらの認証制度と重複している部分もありますが、ソフトウェア品質保証に特化したSAMMはより効果的かつ広範囲にセキュア開発をサポートできます。SAMMより広範囲な領域をサポートするCMMIを導入している組織には必要ありません。
私の会社では比較的導入しやすいセキュア開発メソドロジーであるSAMMを推奨し、導入サポートも行っています。SAMMは新しい物ではなく7年ほど前に最初のバージョンがリリースされており、当時から推奨しています。
「個々の脆弱性対策だけやれば良い」とする議論に組みしない理由
このブログを継続的に読んでいる方なら私が「個々のセキュリティ脆弱性対策も重要だが、基本的考え方や概念はより重要である」と考えていることがわかると思います。「個々の脆弱性対策だけやれば良い」とする議論がありますが、これには色々な欠陥があります。このため、「個々の脆弱性対策だけやる」では効果的なセキュリティマネジメントができません。つまり、より危険なセキュリティになってしまいます。
追記：このエントリだけではなぜマネジメントが大切なのかは伝わらないと思うので、容易に導入できるセキュア開発メソドロジー – OpenSAMM を書きました。こちらも参照ください。
入力バリデーションがセキュリティ対策かどうかは、”どうでもいい”！？
徳丸さんとの議論は終わっている いるので議論することはありません。しかし、 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ というおかしなスライドが目に入ったのでコメントしておきます。今現在で2万近くのビュー回数もあると放っておけません。
”セキュリティ専門家”という肩書を持つ方が非論理的／非科学的な独自のセキュリティ理論を展開されるようでは、誤解してしまった開発者がセキュアでないコードを書いてしまいます。どのように非論理的／非科学的なのか簡単にコメントします。
攻撃者がどうやって脆弱性を見つけ攻撃するのか、仕組みを知れば対策も解る
「攻撃者がどうやって脆弱性を見つけ攻撃するのか」これは比較的よくセキュリティ対策で解説されていることだと思います。本質を理解し、対策を考えます。
今時のShellcodeとセキュア／防御的プログラミング
コンピュータセキュリティのことを考えるとShellcode（シェルコード）のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています
Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。
私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。
IoTでリクエストフォージェリが問題となる
今後WebシステムをインターフェースとするIoTデバイスが続々と出てくると思われます。その中で特に危惧しているセキュリティ問題があります。その１つがリクエストフォージェリです。
リクエストフォージェリ – SSRFとCSRF
リクエストフォージェリ（Request Forgery – リクエスト偽造）はかなり古くから知られている脆弱性です。恐らく1980年代から良く知られていたはずです。昔から知られているSSRFとCSRFの類似性を考えてみます。類似性を考えると、少し解りづらいCSRFも簡単に理解できるかも知れません。
ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイド
単純にこういった定義や標準があります、と紹介してもなかなか原文を参照することは敷居が高いです。このブログでも色々紹介できてきたので、ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドなどをまとめて紹介します。
PHPに無いセキュリティ機能 – PHPカンファレンス関西2015
PHPカンファレンス関西に参加してきました。私のセッションの資料をPDFまたはSlideshareで見れるようにしました。
- PHPにないセキュリティ機能（PDF）
CERT Top 10 Secure Coding Practices
CERTは米カーネギーメロン大学に設置されたコンピュータセキュリティ対策を行う老舗の組織です。CERTが設立される前もセキュリティが無視されていたのではありませんが、CERT設立後と前ではコンピュータセキュリティ、特にソフトウェアセキュリティに対する考え方が大きく変わりました。詳しくはセキュアプログラミング（防御的プログラミング）の歴史をざっと振り返るを参照してください。
CERTはSecure Coding Standardsとして
- SEI CERT C Coding Standard
- CERT C++ Coding Standard
- AndroidTM Secure Coding Standard
- SEI CERT Oracle Coding Standard for Java
- SEI CERT Perl Coding Standard
を公開しています。その中でもセキュアコーディング（セキュアプログラミング／防御的プログラミング）で最も重要なトップ10をTop 10 Secure Coding Practicesとしてまとめています。
日本語訳が無いようなので資料として利用できるよう私訳しておきます。
（追記：IPAのセキュアコーディングガイドは入力対策が出鱈目でした。 2017年からやっとIPAがCERT Secure Coding Practicesをセキュアコーディングの”原則”として紹介するようになりました。CERT版では出力対策を7番目に記載しています。IPAは順序を変えて2番目にしています。トップ10の原則とする際に順序を入れ替えるのは混乱の元です。オリジナルの順序のままにすべきだと思います。順序を変えると外国人とコミュニケーションが取れなくなります。）
よく勘違いされているので書いておきます。入力対策と出力対策は”独立したセキュリティ対策”です。間違えないようにしましょう。
入力バリデーションが第1位の対策であるのは科学的／論理的／原理的な理由が根拠となっています。最も重要な対策ですが、よく誤解されています。
参考：
OWASP Secure Coding Practices – Quick Reference Guide
OWASPのガイドラインはPCI DSSでも参照するように指定されているセキュリティガイドラインです。その中でも比較的簡潔かつ体系的にセキュアプログラミングを解説した資料がOWASP Secure Coding Practices – Quick Reference Guide (v2) です。
日本語訳がないようなので一部未訳ですが訳しました。CC-BY-SAライセンスです。クリエイティブコモンズライセンスに従って自由に配布できます。
チェックリスト形式になっているので、自分のコーディング／開発スタイルがどの程度適合しているのか、簡単にチェックできるようになっています。コーディングスタイルのみでなく、運用はシステム構成に関連する物も含まれています。私が解説／紹介しているセキュリティ対策を行っている開発チームであればこれらの殆どに適合しているはずです。どのくらい適合していたでしょうか？
イントロダクションでは、開発者に対して少々厳しいことが書いてあります。
この技術的不可知論文書は一般的なセキュアコーディングを実践に必要な要素をソフトウェア開発ライフサイクルに統合可能なチェックリストとして定義します。
「技術的不可知論文書」（不可知論：物事の本質は人には認識することが不可能である、とする立場のこと ※ ）としているのは、この文書が取り扱うセキュアコーディングの本質が理解されていない、理解されることがない、と嘆いていることを意味します。セキュアコーディングの本質の解説は諦めて作ったチェックリストであることを示唆しています。私も同じ感覚を共有しています。興味がある方はぜひ以下の参考資料を参照してください。原理と原則を知った方が応用範囲が広がります。
正確な直訳より分かり易さを優先しました。見直しをする時間まではありませんでした。誤り、誤解を招く訳などの指摘を歓迎します。
※ Agnostic（不可知論）について： このガイドは2010年に公開された文書です。最近、agnosticは「〜に依存しない」「〜に関わらず」「〜を問わず」「汎用的」「プラガブル」「詳しく知らなくても使える」といったコンテクストで割と一般的なIT用語として利用されています。2010年頃は哲学的意味が強かったと思いますが、現在は先に書いたような意味で使われているケースが多くあります。
参考資料：
- セキュアプログラミングの７つ習慣
- エンジニア必須の概念 – 契約による設計と信頼境界線
- CERT Top 10 Secure Coding Standard
- 開発者は必修、SANS TOP 25の怪物的なセキュリティ対策
- セキュアプログラミング（防御的プログラミング）の歴史をざっと振り返る
セキュアなアプリ開発 – もしあなたが開発を丸投げするなら？
もし「新規開発を丸投げしセキュアなWebアプリ開発を実現してください」と依頼されたらどうするでしょうか？開発者として開発に参加するのではなく、開発主体、つまりアプリの運営者としてして「新規開発を丸投げしセキュアなWebアプリ開発を実現すること」が目的です。開発プロジェクトのディレクションを担当し、開発は丸投げなので自分が開発に一切関わらないことが前提条件です。
セキュア開発を行うには？を考えたメモです。