情報処理安全確保支援士 オンライン講習（2021年度）単元２：セキュア開発
日時：2022年4月27日～5月1日概要
システムやソフトウェアのライフサイクルにおいて、開発を中心としてどのようにセキュリティを確保した設計、実装、試験を行うべきか学習する。
1章：システムライフサイクルとセキュリティ
- 政府機関等のサイバーセキュリティ対策のための統一基準群
- システムライフサイクルの企画・設計（早い段階）でセキュリティを意識して高める「セキュリティ・バイ・デザイン」「ビルトイン・セキュリティ」
- 企画・要件上の問題として、発注側もセキュリティ要件を定義すること
- システムライフサイクルを考えて、企画。要件定義、設計、製造などの開発プロセスを進めることが重要。
- 運用終了時には確実な廃棄を実施し、その証明を求める。
２章：セキュアな企画と要件定義
- セキュリティ・バイ・デザイン
- 企画段階からのセキュリティ確保
- 手戻りが少なく納期が守れる
- 最終的にコストを少なくできる
- 保守性の良いソフトウェアができる
- IPA セキュリティ・バイ・デザイン入門
- 発注側からセキュリティを意識
- 業務要件の検討
- 守るべき情報資産を洗い出す
- 環境やインシデント時の影響など業務要件を詳細化
- セキュリティ要件の策定
- 業務要件からリスク評価し、対策方針を検討
- 費用対効果や優先度を考慮し対策要件を決定
- 発注仕様に具体的な対策要件を記載
- セキュリティ要件に基づいて予算化・発注
- 企画段階から各段階においてセキュリティ対策を組み込み不可欠なものであると受注側に示す
- 予算や期間、人材などのリソースを確保
- 機能要件と非機能要件
- 機能要件
- ステークホルダーがシステムの目的に対して意図した機能を実現する要件
- 発注側も意識してこの要件を受注側に提示
- 非機能要件
- ステークホルダーが意図しない機能以外の当然対応されるべきものと考えられる要件
- 快適に利用できる、安全に利用できるなどの期待、セキュリティ要件も含まれる
- 非機能要件の課題
- 発注側が当然と考える非機能要件を機能要件として的確に定義することは難しい
- 発注側が意図したセキュリティ対策になっていない
- 運用監視ができるログが出力されない
- 非機能要求グレードの活用
- IPAから提供されているツール群
- システム構築の上流工程強化（非機能要求グレード）
- 残存リスク
- 組織の資源や目的に対する悪影響を最小限に抑えつつ、リスクを許容レベルまで回避、移転、低減しつつ受容するリスク
- 残存リスクの管理
- 許容理由を関係者全員で確認把握する
- 許容できるレベルまで低減されているか判断
- 責任者から許容の承認を得る
- 定期的に、および変更時に見直しを実施
３章：セキュアな設計と実装
- 脅威モデリング
- 開発対象のソフトウェアがさらされている脅威や攻略される可能性を洗い出す活動のひとつ
- ソフトウェアが動作可能な状態になる前でも実施可能
- セキュリティリスクを上流工程で見つけ出せる
- 脅威モデリングを行うタイミング
- ソフトウェアの設計段階の初期
- ソフトウェア全体の構成要素
- 外部とのインターフェース
- データの蓄積方法
- ソフトウェア内のデータの流れ
- IPA セキュア・プログラミング講座
- NIST リスクアセスメントの実施の手引き
- 脅威の分類（STRIDE）
- Spoofing identity なりすまし
- Tampering with data データの改ざん
- Repudiation 拒否
- Information disclosure 情報の漏えい
- Denial of service サービス拒否
- Elevation of privilege 特権の昇格
- Microsoft Threat Modeling Tool の脅威
- 設計原則と実装原則の例
- Saltzer & Schroederによる８つの原則
- 効率的なメカニズム
- フェイルセーフなデフォルト
- 完全な仲介
- オープンな設計
- 権限の分離
- 最小限の権限
- 共通メカニズムの最小化
- 心理学的受容性
- IPA セキュア・プログラミング講座
- 10の実装原則
- 信頼されていないデータソースからの入力を検証する
- コンパイラの警告に注意を払う
- セキュリティポリシー実現のための実装と設計を行う
- シンプルを維持する
- 拒否をデフォルトにする
- 最小権限の原則に従う
- 外部に渡すデータは渡した先で問題を起こさないよう加工する
- 多層防御を行う
- 効果的な品質保証技術を使う
- セキュアコーディング標準を採用する
- 認証・認可 許可した利用者に許可した操作のみを許容する仕組みを提供すること
- 認証（Authentication）アクセスしてきている対象が本物かどうか確認する
- 認可（Authorization）リソースの使用を許可された対象のみに制限すること
- 入力の検証（バリデーション）
- 想定したものだけを認め、検証時には事前に標準化や正規化を行うこと
- アプリケーションが他の処理を実行する前に入力をフィルタ、変換、拒否する
- 無害化（エスケープ処理）
- 入力されたデータを入力先にあわせて適切に無害化すること
- IPA 安全なウェブサイトの作り方
４章：開発プロセスにおけるセキュリティ
- 開発プロセス中のセキュリティ品質を確保するための活動
- [設計]セキュリティレビュー
- 設計ドキュメントをレビューし、考慮すべきセキュリティ対策に漏れがないか検証
- [開発]ソースコードレビュー
- 記述したソースコードを直接検証
- [テスト]セキュリティテスト
- プログラムを動作させてテストし、セキュリティ脆弱性を見つけ出す
- セキュリティレビューの目的
- セキュリティ対策漏れを早期に発見し、設計者へフィードバックすること
- 設計はセキュリティポリシーを満たしているか
- 設計にセキュリティ要件に対する対策漏れはないか
- 設計は既知の脆弱性対策を行えているか
- セキュリティレビューの対象
- 設計工程までに作成されるドキュメント
- セキュリティ要件の定義書
- ソフトウェア工オズ
- 業務仕様
- モジュール分割の設計書
- テストの計画書 等
- ソースコードレビューの目的
- ソースコードが読み易く、わかりやすく書かれているか、脆弱性、その兆しがないかを確認する
- 脆弱性検出のためのレビュー観点
- セキュアコーディング標準に従っているか
- 既知の脆弱性対象を行えているか
- セキュリティ上注意を要するライブラリ関数を呼び出していないか
- デバッグ機能や保守機能などがプログラマの判断で組み込まれていないか
- 情報漏えいやアクセス制御うの迂回がおこらないか
- 領域からデータがあふれる個所はないか
- ソースコードのチェックに静的アプリケーションセキュリティテスト（SAST）などの活用も検討する
- セキュリティテストの目的
- 作り上げたプログラムに十分なセキュリティ対策が実装されていることを確認する
- セキュリティテストの観点
- 既知の脆弱性パターンに陥っていないか
- セキュリティ設計どおりの実装ができているか
- 設計工程までに検討しきれなかった脆弱性がないか
- セキュリティテストｎ実施
- セキュリティテストは、単体、結合、システムテストのすべてのテスト工程で各テストの特性に合わせて実施する。セキュリティ要件を確認可能な自動テストを、各テスト工程に組み込めることが望ましい。
- 代表的なテスト方法
- ホワイトボックス
- ブラックボックス
- ファズテスト
- 脆弱性を発見するためのテスト手法
- ファズ（fuzz/予測不可能な入力データ）を与え、意図的に例外を発生させ挙動を確認する
- ファジングとも呼ばれる
５章：脆弱性診断とは
- 脆弱性診断の実施
- セキュリティ上の弱点である「脆弱性」があるかチェックすること
- ツールを使う自動型、手作業で行う手動型、通信を分析する通信監視型
- 脆弱性体験学習ツール AppGoat
- 自動動的診断ツールを利用した脆弱性の発見方法
- 診断範囲の設定
- 外部サイトへの通信を行わないよう設定
- リンク情報の収集
- 診断対象内のリンクを調査収集
- リクエストの改ざん
- パラメータを変更し、レスポンスを確認
- ディレクトリの探査
- 存在しやすい名前、狙われやすい名前を調査
- レポートの確認
- 自動検出した毛かkの確認、対応方法の検討
コメント
コメントを投稿