セキュアなソフトウェアの設計と開発 (Loren Kohnfelder)

書籍情報

• 著者:Loren Kohnfelder(著), 秋勇紀(訳), 高田新山(訳), 小出洋(監訳)
• 発行日:2023-08-18
• ISBN:9784798069753
• URL:https://www.shuwasystem.co.jp/book/9784798069753.html

書籍目次

• 序文
• 著者前書き
• 謝辞
• 日本語版のための前書き
• 監訳者前書き
• 訳者前書き
• イントロダクション
• Part 1 コンセプト
  • Chapter 1 基礎
    • 1.1 セキュリティを理解する
    • 1.2 信頼
      • 1.2.1 信頼を感じる
      • 1.2.2 ビットを見ることはできない
      • 1.2.3 能力と不完全さ
      • 1.2.4 信頼とはスペクトラムである
      • 1.2.5 信頼の決断
      • 1.2.6 暗黙のうちに信頼されている部品（コンポーネント）
      • 1.2.7 信頼されること
    • 1.3 古典的原則
      • 1.3.1 情報セキュリティのC-I-A
      • 1.3.2 ゴールドスタンダード
      • 1.3.3 プライバシー
  • Chapter 2 脅威
    • 2.1 敵対的な視点
    • 2.2 4つの質問
    • 2.3 脅威モデリング
      • 2.3.1 モデルから取り組む
      • 2.3.2 資産の把握
      • 2.3.3 アタックサーフェスを特定する
      • 2.3.4 信頼の境界を特定する
      • 2.3.5 脅威を特定する
      • 2.3.6 脅威を軽減する
    • 2.4 プライバシーへの配慮
    • 2.5 どこでも脅威をモデリングする
  • Chapter 3 軽減策
    • 3.1 脅威への対応
    • 3.2 構造的な軽減策について
      • 3.2.1 アタックサーフェスの最小化
      • 3.2.2 脆弱性が入り込む時間幅を狭める
      • 3.2.3 データの露出を最小限に抑える
      • 3.3 アクセスポリシーとアクセス制御
    • 3.4 インターフェイス
    • 3.5 通信
    • 3.6 ストレージ
  • Chapter 4 パターン
    • 4.1 設計の特徴
      • 4.1.1 無駄のない設計
      • 4.1.2 透明な設計
    • 4.2 露出の最小化
      • 4.2.1 最小権限
      • 4.2.2 最小情報
      • 4.2.3 セキュア・バイ・デフォルト
      • 4.2.4 ブロックリストより許可リスト
      • 4.2.5 予測可能性を避ける
      • 4.2.6 セキュアに失敗する
    • 4.3 強い強制力
      • 4.3.1 完全な仲介
      • 4.3.2 共通メカニズムの最小化
    • 4.4 冗長性
      • 4.4.1 多層防御
      • 4.4.2 権限の分離
    • 4.5 信頼と責任
      • 4.5.1 信頼へのためらい
      • 4.5.2 セキュリティに責任を負う
    • 4.6 アンチパターン
      • 4.6.1 混乱した代理人
      • 4.6.2 信頼の逆流
      • 4.6.3 サードパーティのフック
      • 4.6.4 パッチ不可能なコンポーネント
  • Chapter 5 暗号技術
    • 5.1 暗号化ツール
    • 5.2 乱数
      • 5.2.1 疑似乱数
      • 5.2.2 暗号化されたセキュアな疑似乱数
    • 5.3 メッセージ認証コード
      • 5.3.1 MACを使用して改竄を防ぐ
      • 5.3.2 リプレイ攻撃
      • 5.3.3 セキュアなMAC通信
    • 5.4 対称暗号
      • 5.4.1 ワンタイムパッド
      • 5.4.2 AES（Advanced Encryption Standard）
      • 5.4.3 対称暗号を使用する
    • 5.5 非対称暗号化
      • 5.5.1 RSA暗号システム
    • 5.6 デジタル署名
    • 5.7 デジタル証明書
    • 5.8 鍵共有
    • 5.9 暗号化の使用
• Part 2 設計
  • Chapter 6 セキュアな設計
    • 6.1 設計におけるセキュリティの統合
      • 6.1.1 設計の前提条件を明示する
      • 6.1.2 スコープの定義
      • 6.1.3 セキュリティ要件の設定
      • 6.1.4 脅威モデリング
    • 6.2 軽減策の構築
      • 6.2.1 インターフェイスの設計
      • 6.2.2 データハンドリングを設計する
    • 6.3 プライバシーを設計に取り込む
    • 6.4 ソフトウェアのライフサイクル全体を見据えた計画
    • 6.5 トレードオフの判断
    • 6.6 設計の簡略化
  • Chapter 7 セキュリティ設計レビュー
    • 7.1 SDRのロジスティクス
      • 7.1.1 なぜSDRを実施するのか？
      • 7.1.2 SDRを実施するタイミング
      • 7.1.3 ドキュメンテーションは必須
    • 7.2 SDRのプロセス
      • 7.2.1 (1) 調査
      • 7.2.2 (2) 問い合わせ
      • 7.2.3 (3) 特定
      • 7.2.4 (4) 連携
      • 7.2.5 (5) 書く
      • 7.2.6 (6) フォローアップ
    • 7.3 設計のセキュリティを評価する
      • 7.3.1 4つの質問をガイダンスとして使用する
      • 7.3.2 どこを掘り下げるのか
      • 7.3.3 プライバシーレビュー
      • 7.3.4 更新のレビュー
    • 7.4 意見の相違を管理する
      • 7.4.1 機転を利かせたコミュニケーション
      • 7.4.2 ケーススタディ:難解なレビュー
      • 7.4.3 不一致をエスカレーションする
    • 7.5 練習、練習、練習
• Part 3 実装
  • Chapter 8 セキュアなプログラミング
    • 8.1 チャレンジ
      • 8.1.1 悪意のある影響力
      • 8.1.2 脆弱性はバグである
      • 8.1.3 脆弱性の連鎖
      • 8.1.4 バグとエントロピー
      • 8.1.5 警戒
    • 8.2 ケーススタディ:GotoFail
      • 8.2.1 1行の脆弱性
      • 8.2.2 フットガンに注意
      • 8.2.3 GotoFailからの教訓
    • 8.3 コーディングにおける脆弱性
      • 8.3.1 アトミック性
      • 8.3.2 タイミング攻撃
      • 8.3.3 シリアライゼーション
    • 8.4 いつもの容疑者
  • Chapter 9 低レベルコーディングの欠陥
    • 9.1 算術演算の脆弱性
      • 9.1.1 固定長整数の脆弱性
      • 9.1.2 浮動小数点精度の脆弱性
      • 9.1.3 例:浮動小数点数のアンダーフロー
      • 9.1.4 例:整数のオーバーフロー
      • 9.1.5 安全な算術
    • 9.2 メモリアクセスの脆弱性
      • 9.2.1 メモリ管理
      • 9.2.2 バッファオーバーフロー
      • 9.2.3 例:メモリ割り当ての脆弱性
      • 9.2.4 ケーススタディ:ハートブリード
  • Chapter 10 信頼できない入力
    • 10.1 入力検証
      • 10.1.1 有効性の判断
      • 10.1.2 検証基準
      • 10.1.3 無効な入力を拒否する
      • 10.1.4 無効な入力を修正する
    • 10.2 文字列の脆弱性
      • 10.2.1 長さの問題
      • 10.2.2 Unicodeの問題
    • 10.3 インジェクションの脆弱性
      • 10.3.1 SQLインジェクション
      • 10.3.2 パストラバーサル
      • 10.3.3 正規表現
      • 10.3.4 XMLのリスク
    • 10.4 インジェクション攻撃の軽減策
  • Chapter 11 Webのセキュリティ
    • 11.1 フレームワークの上に構築する
    • 11.2 Webのセキュリティモデル
      • 11.2.1 HTTPプロトコル
      • 11.2.2 電子証明書とHTTPS
      • 11.2.3 同一生成元ポリシー
      • 11.2.4 Cookieについて
    • 11.3 一般的なWebの脆弱性
      • 11.3.1 クロスサイトスクリプティング（XSS）
      • 11.3.2 クロスサイトリクエストフォージェリ（CSRF）
    • 11.4 その他の脆弱性と軽減策について
  • Chapter 12 セキュリティテスト
    • 12.1 セキュリティテストとは何か?
    • 12.2 GotoFail脆弱性のセキュリティテスト
      • 12.2.1 機能テスト
      • 12.2.2 脆弱性を利用した機能テスト
      • 12.2.3 セキュリティテストケース
      • 12.2.4 セキュリティテストの限界
    • 12.3 セキュリティテストケースの作成
      • 12.3.1 入力検証のテスト
      • 12.3.2 XSS脆弱性のテスト
    • 12.4 ファズテスト
    • 12.5 セキュリティ回帰テスト
    • 12.6 可用性テスト
      • 12.6.1 リソース消費量
      • 12.6.2 閾値テスト
      • 12.6.3 分散型Denial of Service（DoS）攻撃
    • 12.7 セキュリティテストのベストプラクティス
      • 12.7.1 テスト駆動開発
      • 12.7.2 統合テストの活用
      • 12.7.3 セキュリティテストのキャッチアップ
  • Chapter 13 セキュアな開発のためのベストプラクティス
    • 13.1 コードの品質
      • 13.1.1 コード衛生
      • 13.1.2 例外処理とエラー処理
      • 13.1.3 セキュリティのドキュメント化
      • 13.1.4 セキュリティコードレビュー
    • 13.2 依存関係
      • 13.2.1 セキュアなコンポーネントを選択する
      • 13.2.2 インターフェイスの安全性
      • 13.2.3 セキュリティ機能の車輪の再発明をしない
      • 13.2.4 レガシーなセキュリティ機能との闘い
    • 13.3 脆弱性トリアージ
      • 13.3.1 DREAD評価
      • 13.3.2 作業用エクスプロイトの作成
      • 13.3.3 トリアージの決定
    • 13.4 セキュアな開発環境の維持
      • 13.4.1 開発と本番を切り離す
      • 13.4.2 開発ツールをセキュアにする
      • 13.4.3 製品のリリース
• 後書き
  • A.1 行動喚起
    • A.1.1 セキュリティはみんなの仕事
    • A.1.2 セキュリティを強化する
  • A.2 将来のセキュリティ
    • A.2.1 ソフトウェアの品質の向上
    • A.2.2 複雑さの管理
    • A.2.3 透明性の最小化から最大化へ
    • A.2.4 ソフトウェアの認証、信頼、責任を向上させる
  • A.3 ラストワンマイルを届ける
  • A.4 結論
• 訳者後書き
• 付録
  • Appendix A サンプル設計書
  • Appendix B 用語集
  • Appendix C 課題
  • Appendix D チートシート
    • Chapter 1
    • Chapter 2
    • Chapter 4
    • Chapter 7
    • Chapter 13

Chapter 1 基礎

信頼はスペクトラムである

• 「信じよ、されど確認せよ」ポリシー

完全な信頼と完全な不信のギャップを埋める

• 自動監査
• 手動監査

ソフトウェアは「信頼するか、しないか」という二者択一を迫られる

• T/O

情報セキュリティのC-I-A

• 機密性、完全性、可用性
• 機密性:
  • 許可されたデータアクセスのみ認可する
  • 情報を漏らさないようにする
• 完全性:
  • データを正確に管理する
  • 不正な変更・削除を許さない
• 可用性:
  • データを利用可能な状態に保つ
  • 大幅な遅延やシャットダウンを許さない

ゴールドスタンダード

• 認証:
• 認可:
• 監査:

Chapter 4 パターン

セキュアなソフトウェアパターンのグループ化

• セキュリティパターン:
  • 設計の属性
  • 露出の最小化
  • 信頼と責任感
  • 冗長性
  • 強い強制力
  • アンチパターン

無駄のない設計

• 設計はできるだけシンプルであるべき
• シンプルな設計であれば、バグは少なく、発見されない脆弱性も少なくなる（一般論）
• シンプルさより複雑さを受け容れるのは、それが重要な価値をもたらす場合に限るべき
• ただし、「より単純な選択肢が無条件に優れている」「より複雑な選択肢が無条件に劣っている」と主張するものではない