セキュアプログラミング

推薦の言葉
本書に寄せられた言葉
まえがき

1章　平坦な道のりはない
        1.1　セキュリティホールのサイクル
        1.2　「攻撃」とは何か？
                1.2.1　どのようにして攻撃は行われるのか？
                1.2.2　攻撃と防御
        1.3　善良な人々が、なぜ望ましくないコードを作成するのか？
                1.3.1　技術的要因
                1.3.2　心理的要因
                1.3.3　現実世界の要因
        1.4　戦いのはじまり
        1.5　まとめ

2章　アーキテクチャ
        2.1　セキュリティアーキテクチャとは？
                2.1.1　アーキテクチャ設計書とは？
                2.1.2　最初が肝心
        2.2　セキュリティアーキテクチャの原則
                2.2.1　質問することから始める
                2.2.2　行動する前に目的を決める
                2.2.3　どの程度のセキュリティを「適切」とするか決める
                2.2.4　標準的な技術を使用する
                2.2.5　前提を知る
                2.2.6　最初からセキュリティを考える
                2.2.7　敵を想定して設計する
                2.2.8　信頼関係を理解し尊重する
                2.2.9　最小権限で動かす
                2.2.10　ポリシーに反する処理をテストする
                2.2.11　適切な耐障害性で構築する
                2.2.12　エラー処理を適切に行う
                2.2.13　緩やかな性能低下
                2.2.14　フェールセーフ
                2.2.15　デフォルトの処理は安全なほうを選択する
                2.2.16　シンプルに構築する
                2.2.17　十分にモジュール化する
                2.2.18　不明瞭なものを信頼しない
                2.2.19　最小限の状態情報を保持する
                2.2.20　ユーザが受け入れることができる現実的な手段を採用する
                2.2.21　責任者を明確にする
                2.2.22　リソースの消費を自己管理する
                2.2.23　イベントの再構築を可能にする
                2.2.24　「脆弱な連結部」を排除する
                2.2.25　複数の防御策を準備する
                2.2.26　アプリケーション全体を考える
                2.2.27　セキュアなコードを再利用する
                2.2.28　既製のソフトウエアを信用しない
                2.2.29　セキュリティのために民主主義の原則を犠牲にしない
                2.2.30　「忘れているものはないか」を常に問う
        2.3　ケーススタディ：Javaサンドボックス
        2.4　まとめ

3章　設計
        3.1　設計がなぜ重要か？
        3.2　セキュアな設計のステップ
                3.2.1　ステップ1：リスクと脅威の評価
                3.2.2　ステップ2：リスクを緩和させる戦略の採択
                3.2.3　ステップ3：メンタルモデルの構築
                3.2.4　ステップ4：技術的に高度な問題の解決
                3.2.5　ステップ5：適切な実現方法の選択
                3.2.6　選択手順の評価
        3.3　特殊な問題
                3.3.1　アプリケーションを補強すること
                3.3.2　コードの保守
                3.3.3　区分化
        3.4　失敗の要因
                3.4.1　誤った設計のアプローチ方法に注意する
                3.4.2　設計に関する特定の問題を遠ざける
        3.5　ケーススタディ
                3.5.1　ケース1：Access Control Executive
                3.5.2　ケース2：AusCERTのWrapper
                3.5.3　ケース3：Sendmail Restricted Shell
                3.5.4　ケース4：Postfix Mail Transfer Agent
                3.5.5　ケース5：TCP Wrappers
                3.5.6　ケース6：無線LANのセキュリティ設計の過ち
        3.6　まとめ

4章　実装
        4.1　成功の要因
                4.1.1　知識を高める
                4.1.2　データを注意深く操作する
                4.1.3　優れたコードを可能な限り再利用する
                4.1.4　レビュー方法にこだわる
                4.1.5　チェックリストを大いに活用する
                4.1.6　保守を大切にする
        4.2　失敗の要因
        4.3　ケーススタディ
                4.3.1　ケース1：ホワイトノイズの実装ミス
                4.3.2　ケース2：ファイルのパース処理のセキュリティホール
                4.3.3　ケース3：権限分離のミス
                4.3.4　ケース4：電話帳CGIプログラムの欠陥
        4.4　まとめ

5章　運用
        5.1　セキュリティはみんなの問題である
        5.2　成功の要因
                5.2.1　ネットワーク環境に装甲を施す
                5.2.2　OSの要塞化
                5.2.3　慎重にアプリケーションを配置する
                5.2.4　信頼できる運用方法の確立
                5.2.5　その他の成功要因
        5.3　失敗の要因
        5.4　ケーススタディ
                5.4.1　ケース1：電話交換システムの欠陥
                5.4.2　ケース2：惨状の記憶
                5.4.3　ケース3：CodeRedワーム
        5.5　まとめ

6章　自動化とテスト
        6.1　なぜテストするのか？
        6.2　成功の要因
        6.3　ライフサイクル全体を通した成功の要因
                6.3.1　設計時のテスト
                6.3.2　実装時のテスト
                6.3.3　運用時のテスト
        6.4　リスク評価の手法
                6.4.1　ACSM/SAR
                6.4.2　ASSET
        6.5　ケーススタディ
                6.5.1　ケース1：フルサービスネットワークのレビュー
                6.5.2　ケース2：レガシーなアプリケーション
                6.5.3　ケース3：顧客向けポータルサイトの設計
        6.6　まとめ

付録A　情報源

索引