CISSP 勉強ノート

目次の表示
  1. 1. 情報セキュリティ環境
    1. 1-1. 職業倫理の理解、遵守、推進
      1. 職業倫理
      2. (ISC)2 倫理規約
      3. 組織の倫理規約
      4. エンロン事件とSOX法の策定
      5. SOC (System and Organization Controls) レポート
    2. 1-2. セキュリティ概念の理解と適用
      1. 機密性、完全性、可用性
      2. 真正性、否認防止、プライバシー、安全性
      3. デューケアとデューデリジェンス
    3. 1-3. セキュリティガバナンス原則の評価と適用
      1. セキュリティ機能のビジネス戦略、目標、使命、目的との連携
      2. 組織のガバナンスプロセス
      3. 組織の役割と責任
    4. 1-4. 法的環境
      1. 法的環境
      2. 契約上の要件、法的要素、業界標準および規制要件
      3. プライバシー保護
      4. プライバシーシールド
      5. 忘れられる権利
      6. データポータビリティ
      7. データのローカリゼーション
      8. 国と地域の例
      9. 米国の法律 [追加]
      10. サイバー犯罪とデータ侵害
      11. 知的財産保護
      12. 輸入と輸出統制
      13. 越境データフロー
    5. 1-5. セキュアな設計の基本原則
      1. 最小権限 (最小特権)
      2. 多層防御
      3. セキュアなデフォルト (Secure by Default)
      4. フェイルセーフ (フェイルセキュア)
      5. 職務の分離 (SoD; Separation of Duties)
      6. シンプルであること
      7. Trust, but Verify
      8. ゼロトラスト
      9. プライバシー・バイ・デザイン (Privacy by Design)
      10. 責任の分担 (Shared Responsibility)
  2. 2. 情報資産のセキュリティ
    1. 2-1. 情報資産
      1. IT資産管理のライフサイクル
      2. 情報資産のインベントリ
      3. 分類とカテゴリ化
      4. データの分類とカテゴリ化のポリシー
      5. 分類とカテゴリ化:レベルとラベル
      6. 分類とカテゴリ化のメリット
      7. 分類とカテゴリ化に関する問題
    2. 2-2. データセキュリティライフサイクルの管理
      1. データセキュリティライフサイクル
      2. データの役割
      3. データの状態
      4. データライフサイクルに関する考慮事項
    3. 2-3. データセキュリティコントロールとコンプライアンス要件の決定
      1. 適用可能なコントロールの種類
      2. セキュリティコントロールのカテゴリ
      3. スタンダードの選択
      4. データセキュリティベースラインの確立
      5. ベースライン保護の目的
      6. ベースラインカタログ
      7. 一般に認められた原則
      8. 範囲の決定とテーラリング
  3. 3. IDとアクセスの管理 (IAM)
    1. 3-1. IDおよびアクセスのプロビジョニングライフサイクル
      1. アクセス制御
      2. IDライフサイクル
      3. プロビジョニング
      4. 認証
      5. 認可
      6. アカウンティング
      7. ユーザの振る舞いのレビュー
      8. 業務や義務のレビュー
      9. 無効化とデプロビジョニング
      10. アカウントアクセスのレビュー
      11. 権限昇格
      12. 権限昇格の種類
      13. IAAAはCIANA+PSを導入
    2. 3-2. アクセス制御モデルとメカニズムの実装と管理
      1. セキュリティモデルの基本的な概念の理解
      2. BLP (Bell-LaPadula)
      3. Biba
      4. Brewer-Nash
      5. Clark-Wilson
      6. Graham-Denning
      7. HRU (Harrison, Ruzzo, Ullman)
      8. Take-Grant保護モデル [追加]
      9. 最新の実装
      10. アクセス制御 (AC) モデル
      11. 強制アクセス制御 (MAC)
      12. 任意アクセス制御 (DAC)
      13. 非任意アクセス制御 (NDAC)
      14. ロールベースアクセス制御 (RBAC)
      15. ルールベースアクセス制御 (RuBAC)
      16. 属性ベースアクセス制御 (ABAC)
      17. リスクベースアクセス制御
    3. 3-3. 人とオペレーションの管理
      1. 最小権限
      2. 知る必要性 (Need to know)
      3. 職務と責任の分離
      4. 特権アカウント管理
      5. ジョブローテーションなどの人事戦略
      6. 強制休暇
      7. デュアルカストディ (2人制御)
    4. 3-4. 資産の物理的、論理的なアクセス制御
      1. IAM管理の選択
      2. システムとしてのアクセス制御
      3. 物理的アクセス制御システム (PACS)
      4. アプリケーション
    5. 3-5. 人、デバイス、サービスの識別と認証の管理
      1. IDストア (identity store)
      2. 資格情報管理システム
      3. IDアクセス管理 (IAM) の実施
      4. ISO Identity Model
      5. フェデレーションID管理 (FIM)
      6. 単一要素認証 (SFA) vs 多要素認証 (MFA)
      7. アクセス制御トークン
      8. 生体認証
      9. IDの登録、証明、確立
      10. シングルサインオン (SSO; Single Sign-On)
      11. アクセス制御のエラー
      12. ジャストインタイムID (JIT ID)
    6. 3-6. 認証・認可システムの導入
      1. セッション管理
      2. 初期の概念
      3. RADIUS
      4. TACACS
      5. LDAP
      6. OpenID
      7. Kerberos
      8. SAML (Security Assertion Markup Language)
      9. OAuth 2.0 (Open Authorization)
      10. サードパーティのサービスを利用したフェデレーションID
      11. 監査およびコンプライアンス報告
  4. 4. セキュリティアーキテクチャとエンジニアリング
    1. 4-1. セキュリティアーキテクチャ、設計およびソリューション要素の脆弱性の評価と緩和
      1. セキュリティエンジニアリング
      2. セキュリティエンジニアリングのプロセス
      3. 技術的プロセス
      4. 技術的管理プロセス
      5. イネーブリングプロセス
      6. 合意プロセス
      7. セキュリティポリシー、モデル、アーキテクチャ
      8. 様々なシステムアーキテクチャへのセキュリティモデルの適用
    2. 4-2. 暗号システム
    3. 4-3. ハイブリッドシステムと公開鍵基盤 (PKI)
    4. 4-4. 暗号システムハイジーン:運用およびメンテナンス
      1. 管理暗号
      2. 鍵管理と鍵管理のプラクティス
      3. 鍵復旧 (Key Recovery)
      4. 鍵の生成
      5. 鍵配布、鍵ラッピング、鍵暗号化鍵 (KEK; Key Encrypting Keys)
      6. 鍵の保存と破棄
      7. アルゴリズム管理とプロトコル管理
      8. セッション鍵:生成、使用、保護、破棄
      9. 国際輸出管理
    5. 4-5. 暗号解読
  5. 5. 通信とネットワークセキュリティ
    1. 5-1. OSIモデルとTCP/IPモデル
      1. ネットワーク用語
    2. 5-2. OSI第1層:物理層
      1. ネットワークトポロジーの種類
      2. ネットワークの種類
      3. 共通デバイス
      4. インターネットアクセスのための通信
    3. 5-3. OSI第2層:データリンク層
      1. プロトコル
      2. 脅威と対策
    4. 5-4. OSI第3層:ネットワーク層
      1. 送信の形態(伝送モード)
      2. プロトコル
      3. マルチプロトコルラベルスイッチング (MPLS)
      4. 脅威と対策
    5. 5-5. OSI第4層:トランスポート層
      1. プロトコル
      2. 脅威と対策
    6. 5-6. OSI第5層:セッション層
      1. 認証プロトコル
    7. 5-7. OSI第6層:プレゼンテーション層
    8. 5-8. OSI第7層:アプリケーション層
      1. プロトコル
    9. 5-9. ネットワークアーキテクチャにおけるセキュアな設計原則
      1. セキュアプロトコル
      2. マルチレイヤプロトコル (MLP)
      3. コンバージドプロトコル
      4. ソフトウェア定義ネットワーク (SDN)
      5. ソフトウェア定義広域通信網 (SD-WAN)
      6. SDNとセキュリティ
      7. コンテンツ配信ネットワーク (CDN)
      8. 「ゼロトラスト」vs.「Trust, but Verify」
    10. 5-10. セキュアなネットワークコンポーネント
      1. ハードウェアの操作
      2. ネットワークアクセス制御 (NAC) デバイス
      3. 802.1X NAC
      4. エンドポイントのセキュリティ
      5. NACフレームワーク
      6. NACのベストプラクティス
      7. ベースライン
      8. 監査
      9. ポートアドレス変換 (PAT)
      10. プロキシ型ファイアウォール
      11. プロキシの種類
    11. 5-11. 設計に基づくセキュアな通信チャネルの導入
      1. ワイヤレスアクセスポイント (WAP) のセキュリティ
      2. キャプティブ・ポータルの利用
      3. ワイヤレス攻撃
      4. リモートアクセス
      5. 仮想プライベートネットワーク (VPN)
      6. PPTP (ポイントツーポイントトンネリングプロトコル)
      7. L2TP (レイヤ2トンネリングプロトコル)
      8. SSLとTLSを用いた仮想プライベートネットワーク (VPN)
      9. 遠隔勤務
      10. スクリーンスクレーパー
      11. マルチメディアコラボレーション
      12. 回線の仮想化
      13. ネットワーク機能仮想化 (NFV)
      14. サードパーティとの接続性
  6. 6.ソフトウェア開発セキュリティ
    1. 6-1. 多くのソフトウェアシステムがセキュアでない利用
      1. リングとOSI7層モデル
      2. アーキテクチャと脅威モデリングプロセスレビュー
      3. 実行可能なコンテンツとモバイルコード
      4. ソフトウェアの構築と使用のサイクル全体に存在する脆弱性
      5. ソフトウェア環境のセキュリティ
      6. 開発期間 vs. エラーの影響
      7. ウォーターフォール型ソフトウェアライフサイクル開発 (SDLC) モデル
      8. ステージごとのビジネスインパクト vs. 変更するためのコスト
      9. どの程度の性能・安全性であれば十分か
      10. 古典的だが根強いソフトウェア設計とコーディングのエラー
      11. 良いプラクティスの存在
      12. データを中心とした脆弱性の制御
      13. 内臓のセキュリティは管理可能で到達可能
    2. 6-2. ソースコードレベルでのセキュリティの脆弱性
      1. ソフトウェアの設計と作成概要
      2. ソースと実行可能コードの比較
      3. プログラミング言語
      4. ソースコードから実行可能なプログラムまで
      5. プログラミング言語の世代
      6. オブジェクト指向テクノロジーとプログラミング
      7. ポリインスタンス化
      8. オブジェクト指向セキュリティ
      9. 分散オブジェクト指向システム
      10. CORBA (Common Object Request Broker Architecture)
      11. スタンダードライブラリ、その他のライブラリ、およびソフトウェアの再利用
      12. 悪用可能なソフトウェアソースコードのよくあるエラー
      13. 隠れチャネル
      14. その他の一般的なソフトウェアの攻撃ベクトル
    3. 6-3. データベースがセキュアでない理由
      1. データベースとデータウェアハウスアーキテクチャに対する脅威
      2. データベースとデータウェアハウス環境
      3. データベース管理システム (DMBS) アーキテクチャ
      4. データベースモデル
      5. モデルの種類
      6. リレーショナルデータベースモデル
      7. オブジェクト指向データベースモデル
      8. 異なるデータベースモデルにおけるデータ完全性の実現
      9. データベースインターフェイス言語
      10. 構造化クエリ言語 (SQL)
      11. マークアップ言語とデータベース
      12. アプリとデータベース接続
      13. 拡張マークアップ言語 (XML)
      14. オープンデータベースコネクティビティ (ODBC)
      15. Java Database Connectivity (JDBC)
      16. オブジェクト連携とデータベース埋め込み (OLE DB)
      17. アプリケーションプログラミングインターフェイス (API)
      18. 階層的アプリケーション手法
      19. ActiveXデータオブジェクト (ADO)
      20. メタデータ
      21. オンライン分析処理 (OLAP)
      22. ナレッジマネジメント
      23. データベースからの知識発見 (KDD)
      24. KDDのセキュリティコントロール
    4. 6-4. Webサイトがセキュアでない理由
      1. Webアプリケーションの脅威と保護
      2. 内臓のWebサイトセキュリティ
    5. 6-5. マルウェア、ランサムウェア、ランサム攻撃:ソフトウェアの観点
      1. 悪意のあるソフトウェア (マルウェア)
      2. ソーシャルエンジニアリング
      3. ウイルス
      4. その他のマルウェア
      5. アンチマルウェアまたはアンチウイルスシステム
      6. 侵入検知・防止システム
      7. ソフトウェアのブロックリストと許可リスト
      8. マネージドセキュリティサービス
      9. ランサムウェアとランサム攻撃からの保護
    6. 6-6. 内蔵のセキュリティ:開発管理の選択肢
      1. ソフトウェア開発ライフサイクル (SDLC)
      2. 分野横断的な手法
      3. 統合製品チーム (IPT)
      4. 統合生産プロセス開発 (IPPD)
      5. その他の手法とモデル
      6. 安全なソフトウェア開発のための成熟度モデル
      7. ソフトウェア能力成熟度モデル (SW-CMM)
      8. OWASPの成熟度モデル
      9. セキュアコーディングのガイドラインとスタンダード
      10. プログラミング言語による強力なデータの型付けと構造の強制
      11. 信頼できるライブラリの再利用の制限
      12. セキュアプログラミングのスタンダードとガイドラインの使用を強制する
      13. アプリケーションプログラミングインターフェイス(API)のセキュリティ
      14. Representational State Transfer (REST)
      15. REST APIのセキュリティに関する推奨事項
      16. 認証オプション
      17. OWASP REST セキュリティチートシート
      18. ツールセット、ライブラリ、リポジトリ、統合開発環境
      19. ソースコード解析ツール
      20. 開発・テスト用サンドボックス
    7. 6-7. ソフトウェア開発エコシステムにおけるセキュリティコントロール
      1. 環境の制御と分離
      2. IDE、プログラム実行、実行環境
      3. コードレポジトリのセキュリティ
      4. TCB (Trusted Computing Base)
      5. リファレンスモニター
      6. セキュリティカーネル
      7. ソフトウェアをより安全にするための暗号技術のアプローチ
      8. DMBS制御
      9. ロック制御メカニズム
      10. DBMSのその他のアクセス制御
      11. オンライントランザクション処理 (OLTP) のセキュリティ考慮事項
      12. ソフトウェアセキュリティの一側面としての構成管理 (CM)
      13. 構成管理計画
      14. 情報保護管理
      15. 継続的インテグレーションと継続的デリバリー (CI/CD)
      16. 不適切な粒度の制御
    8. 6-8. ソフトウェアアプリケーションとシステムのリスク分析と低減
      1. 安全なソフトウェアとシステムのための構成管理の必要性
      2. 変更の監査とログ記録
      3. ソフトウェアアシュアランスとセキュリティ評価
      4. 正式なアプローチ
      5. ソフトウェア品質保証
      6. 非機能的な要求の正式な評価
      7. ソフトウェア保証ポリシー
      8. 認証と認定
      9. テスト、検証、およびセキュリティ評価
      10. 受け入れテスト
      11. 回帰テスト
      12. セキュリティ評価テスト
      13. コントロールのテストおよび評価
      14. 調達時のソフトウェアアシュアランス
      15. オープンソースソフトウェアとセキュリティ評価
      16. 独立したソフトウェアとシステムのセキュリティ評価
      17. M&A
      18. コモディティシステム
  7. 7. セキュリティの評価とテスト
    1. 7-1. 評価、テスト、監査戦略の設計および検証
      1. セキュリティ監査・評価の目的
      2. 監査
      3. 評価
      4. スタンダードとフレームワーク
      5. NISTリスクマネジメントフレームワーク (Risk Management Framework)
      6. NISTサイバーセキュリティフレームワーク (NIST Cybersecurity Framework)
      7. ISO 27000「情報セキュリティマネジメントシステム」
      8. SOCレポート
      9. トラストサービス基準 (Trust Services Criteria)
      10. コモンクライテリア (CC) [追加]
      11. 業界、地域固有のスタンダード
      12. 内部監査と評価
      13. 外部監査と評価
      14. 第三者による監査と評価
      15. マネージドサービスとセキュリティ評価
      16. サプライチェーンセキュリティの原則
    2. 7-2. セキュリティコントロール評価の実施
      1. コントロール評価の方法とツール
      2. 評価のテーラリング
      3. 検査
      4. ログレビュー
      5. インタビュー
      6. テスト
      7. コンプライアンスと実証手続
      8. テストの観点
      9. コードレビューとテスト
      10. 企画・設計時のコードレビュー
      11. 申請・開発時のコードレビュー
      12. ミスユースケーステスト
      13. ネガティブテスト
      14. テストカバレッジ解析
      15. インターフェーステスト
      16. 倫理ペネトレーションテスト
      17. 倫理的ハッキング
      18. 基本的な方法論
      19. 継続的なフルサイクルテスト
    3. 7-3. セキュリティプロセスデータの収集
      1. アカウント管理
      2. 合成トランザクション
      3. リアルユーザー管理 (RUM)
      4. 合成性能監視
      5. マネジメントレビューと承認
      6. セキュリティ教育、トレーニング、アウェアネス (SETA)
      7. 可用性サービス
      8. バックアップ
      9. 災害復旧(DR)および事業継続性(BC)
    4. 7-4. 組織のパフォーマンスの分析および報告
      1. 重要業績評価指数 (KPI) と重要リスク指標 (KRI)
      2. 継続的なプロセス改善サイクル
      3. 例外処理
      4. 倫理的開示
      5. 非開示
      6. 全面開示
      7. 責任ある開示
      8. 報告義務
      9. 内部告発
  8. 8. セキュリティの運用
    1. 8-1. ログ取得とモニタリング
      1. ログ管理
      2. 侵入検知・防御システム (IDS/IPS)
      3. インサイダー、アウトサイダー、ゼロトラスト
      4. スレットハンティングとIDS/IPS
      5. セキュリティ情報とイベント管理 (SIEM)
      6. 継続モニタリング (ISCM)
      7. 入口監視と出口監視
      8. 脅威インテリジェンス
      9. ユーザとエンティティのふるまい分析 (UEBA)
      10. モニタリングの限界
    2. 8-2. 変更管理の実施
      1. 変更管理のスタンダードとプラクティス
      2. 主要な変更管理アクティビティ
      3. リリースとデプロイメントの計画とコントロール
      4. パッチ管理
      5. 脆弱性管理
      6. 構成管理とコントロール
      7. セキュリティベースライン
      8. 構成の自動化
      9. 変更管理委員会 (CMB)
      10. 執行
    3. 8-3. インシデントレスポンスの基本概念
      1. インシデントレスポンススタンダード
      2. 組織環境
      3. サイバーフォレンジック
    4. 8-4. インシデント管理の実施
      1. インシデントレスポンスのアクティビティ
      2. 準備
      3. インシデントマネジメントとSOCの概念
      4. 検知
      5. 分析
      6. レスポンス (対応)
      7. 緩和
      8. 復旧 (修復) と是正
      9. レポーティング (報告)
      10. レビューと改善 (教訓)
      11. セキュリティのオーケストレーションと自動化によるレスポンス (SOAR)
    5. 8-5. 検知策と防止策の運用と維持
      1. ツールと技術
    6. 8-6. バックアップとリカバリー戦略の導入
      1. バックアップストレージ戦略
      2. 最低限の保護
      3. バックアップロケーション
      4. バックアップの種類
      5. その他のバックアップに関する検討事項
      6. 復旧サイト戦略
      7. 代替ロケーションの種類
      8. システムのレジリエンス、高可用性、サービス品質(QoS)、フォールトトレランス
      9. ストレージ
    7. 8-7. サイトと施設の設計へのセキュリティ原則の適用
      1. 防犯環境設計 (CPTED)
      2. サイト計画
      3. 可用性
      4. 建築基準法
      5. データセンタースタンダード
    8. 8-8. サイトと施設のセキュリティコントロール
      1. ワイヤリングクローゼット/中間配線施設
      2. サーバルーム/データセンター
      3. ストレージメディアの保護と管理
      4. 証拠の保管と管理の連鎖
      5. 制限された作業エリアのセキュリティ
      6. ユーティリティ、暖房、換気、空調 (HVAC)
      7. 火災の予防、検知、および抑制
      8. 電力
      9. 境界セキュリティコントロール
      10. 内部セキュリティコントロール
    9. 8-9. 従業員の安全とセキュリティの概念
  9. 9. 全チャプターのまとめ
    1. 9-1. セキュリティガバナンス:究極の管理的コントロールのセット
      1. ガバナンスから業務遂行へ
      2. ポリシー
      3. プロシージャ
      4. ガイドライン
      5. スタンダード
      6. ガバナンスフレームワーク
    2. 9-2. 運用されているセキュリティフレームワーク
      1. プライバシーフレームワーク
      2. サイバーセキュリティフレームワーク
      3. リスクフレームワーク
      4. セキュリティコントロールフレームワーク
    3. 9-3. フォレンジック調査
      1. 調査の完全性の維持
      2. 証拠の収集と取り扱い
      3. 報告と文書化
      4. 調査手法
      5. デジタルフォレンジックのツール、戦術、プロシージャ
      6. 調査の種類
      7. 証拠に関する原則 [追加]
    4. 9-4. 事業継続と災害復旧 (BC/DR) 要件に対応する組織的能力の構築
      1. 適切なBCスタンダードの選択
      2. ビジネス影響度分析 (BIA)
      3. BC要件の特定と優先順位付け
      4. 事業継続計画および災害復旧計画の要素
      5. 災害復旧プロセス
      6. トレーニングとアウェアネス
    5. 9-5. 人的セキュリティポリシーおよびプロシージャへの貢献と執行
      1. 候補者の選考と解雇
      2. 審査・採用における特殊事情
      3. 採用契約と雇用ポリシー
      4. 新人受け入れ、異動、退職のプロセス
      5. コンプライアンスポリシー要件
      6. プライバシーポリシー要件
      7. 秘密保持契約 (NDA; Non-Disclosure Agreements)
      8. ベンダー、コンサルタント、契約者との合意と管理
    6. 9-6. リスクマネジメントの運用
      1. フレームワークからワークフローへ : リスクマネジメント
      2. リスクマネジメントにおける4つの視点
      3. リスクに関する定義
      4. リスク対応 : 4つの選択肢
      5. リスクアセスメントと分析
      6. シミュレーションとリスク評価
      7. リスク評価と対策の決定
      8. 脅威モデリング
      9. 対策の選択と実施
      10. 管理策の選択 (セキュリティとプライバシー)
    7. 9-7. ITサプライチェーンリスクマネジメント (SCRM) の概念の適用
      1. ハードウェア、ソフトウェア、サービスに関連するリスク
      2. 第三者による評価とモニタリング
      3. 最低限のセキュリティ要件
      4. サービスレベル要件
    8. 9-8. セキュリティアウェアネス、教育、トレーニングプログラムの確立と維持
      1. アウェアネスおよびトレーニングの方法と技法
      2. 定期的なコンテンツレビュー
      3. プログラムの有効性評価
    9. CISSPとしての考え方

CISSPを勉強した時の自分用のまとめです。 あくまで備忘録程度で、内容の正確性は保証しませんのでご了承ください。

1. 情報セキュリティ環境

1-1. 職業倫理の理解、遵守、推進

  • 多くの組織では、価値観やステークホルダーに対する義務を明記した倫理規約を作成する

職業倫理

  • 社会に貢献するために、職業上のガイドラインやベストプラクティスに沿って、全体の利益を考えて行動すること

(ISC)2 倫理規約

  • (ISC)2 メンバーが信頼を得るために、正しいマナーに従い、専門家としてふさわしい振る舞いをし、利益をもたらす存在とみなされること
  • (ISC)2 倫理規定の規律:
    • 社会、一般大衆の福利、およびインフラを保護する
    • 公正かつ誠実に責任をもって合法的に行動する
    • 当事者に対して、十分かつ適切なサービスを提供する
    • 専門知識を高め、維持する (維持にはCISSPの試験内容を公にしないことが含まれる)
  • 違反した場合は、委員会による認証が取り消される可能性がある

組織の倫理規約

  • 許容される行動様式を規定するもの

エンロン事件とSOX法の策定

  • SOXは、企業に対して財務報告の透明性と会計処理の文書化を求める米国の法律
  • 1990年代末から2000年代初めにかけて、エンロンなどの一流上場企業が関わる会計疑惑が連続したため、その対策としてSOX法が策定された

SOC (System and Organization Controls) レポート

  • SOCは、SOX法のコンプライアンス要件に対応するための認証された報告書
  • SOC監査では、他の監査(一般監査、データ保護監査、財務監査など)が適切に実施されているかを検証する

1-2. セキュリティ概念の理解と適用

  • 情報は、意思決定に利用されるものほど価値を持つ
  • 情報セキュリティは、情報が正しく、完全であり、意思決定をサポートするために利用可能であることを確認すること

機密性、完全性、可用性

  • 情報セキュリティの基本的な目標は、機密性、完全性、可用性 (CIAの三要素) を維持すること
    • 機密性 : アクセス権が保たれていること
    • 完全性 : 改竄されていないこと
    • 可用性 : 必要な時に利用できること

真正性、否認防止、プライバシー、安全性

  • CIA以外のモデルは、セキュリティに関心を持ち続けるためのものとして使われる
    • 真正性 : データが信用できるかを確認できること
    • 否認防止 : 過去の行為を取り消すことができないこと
    • プライバシー : 個人の活動に対する利益が他人に強制的に奪われないこと
      • OECDはプライバシーガイドラインを1980年に発表し (2013年に改定)、多くの国ではこのプライバシー基本8原則に基づいた法律を策定している
      • PII (Personally Identifiable Information) は、個人を特定できる情報
      • PHI (Protected Health Information) は、個人のプライバシーに関する保健情報
        • 米国の法律であるHIPPAプライバシールールでPHIの扱いが書かれている
    • 安全性 : 人や財産への危害を防止・制御すること

デューケアとデューデリジェンス

  • 権限や責任を持つ人が遵守し、実行しなければならない義務
    • デューケア : 組織や顧客に対して負う義務。役割。妥当な注意。常識人として一般的に期待される行動
    • デューデリジェンス : 実施した作業の裏付け。説明責任。適切な注意。責任を果たすためにすべき努力

1-3. セキュリティガバナンス原則の評価と適用

  • リスク低減のためにポリシーの作成やトレーニングを実施し、必要な行動がとられるように管理すること
  • プロセスの信頼性と再現性を高めることで、効率性・安全性・セキュリティを得ることができる

セキュリティ機能のビジネス戦略、目標、使命、目的との連携

  • ビジネスなしにセキュリティ部門は存在できない
  • アライメントは、目標や目的を達成するために計画やリソースを調整すること
  • ビジネス影響度分析 (BIA) は目標、リソース、リスクの整合性を把握するための手段

組織のガバナンスプロセス

  • ガバナンスは、組織を運営するためのプロセスであり、現場を観察して目標に向かっていないものを修正すること
  • ガバナンス委員会は、一部の企業で使われて、組織内の意思決定方法を決定する
  • セキュリティの目標は、ビジネス目標をサポートすること
  • 買収、合併、子会社化は、セキュリティに影響を与える可能性がある

組織の役割と責任

  • セキュリティ機能は、組織の階層構造に依存する
  • セキュリティ関連の役割:
    • 経営陣 : 組織の上層部でポリシーを指示したり、組織に義務を課す権限を持つ役員や幹部
    • セキュリティマネージャー/オフィサー/ディレクター : 組織内の上級セキュリティ担当者
    • セキュリティ担当者 : 組織内のセキュリティ専門家。管理者、アナリスト、インシデントレスポンダー など
    • ユーザー : 従業員。システムの安全な操作やセキュリティガイダンスの同意書への署名、潜在的なインシデントを報告できるようにトレーニングなどが必要

1-4. 法的環境

  • 法律、規制、スタンダード、契約は、すべて組織の行動に影響を与える

法的環境

  • 法的要件を知ることは、コンプライアンス違反のリスクを低減し、組織が守るべきビジネス要件と法的要件を理解するのに役立つ

契約上の要件、法的要素、業界標準および規制要件

  • 組織は、所属する業界や法律などの規制を遵守すること
  • スタンダードは、伝統的・文化的な義務の一部をまとめたもの
  • コンプライアンスは、規則を遵守すること

プライバシー保護

  • プライバシーは、自分に関する情報が出回る方法と範囲を制限できる権利のこと
  • 1980年に、OECDが初めて「OECDプライバシーガイドライン」を発表した (2013年に改定)
  • OECDのプライバシー原則は国際的に合意された最初のプライバシー原則であり、世界中のプライバシー関連の法律や規制の基となっている
  • 2018年には欧州連合で一般データ保護規則 (GDPR) が発表された

プライバシーシールド

  • セーフハーバーやプライバシーシールドは、GDPRの発表と同時に米国ではEUの個人や組織との取引に関する概念として開発された
  • プライバシーシールドは、米国とEUの合意により実施され、米国商務省がこれを監視している
  • 2020年7月に、欧州連合司法裁判所はプライバシーシールド協定を破棄した
    • プライバシーシールドは米国の監視活動の影響を受けるためにEU市民を保護するものではないと主張する原告を支持したため
  • プライバシーシールドの7原則:
    • 通知 (Notice)
    • 選択 (Choice)
    • 第三者移転に対する説明責任 (Accountability for Onward Transfer)
    • セキュリティ (Security)
    • データ完全性および目的外利用の禁止 (Data integrity and Purpose Limitation)
    • アクセス (Access)
    • 救済・執行・責任 (Recourse, Enforcement, and Liability)

忘れられる権利

  • 忘れられる権利は、市民がデータオーナーなどに対して自分に関わる情報を削除するように要求する権利
  • EUの法律や規制 (GDPR) で確立されている原則。EU以外の国でも導入されている

データポータビリティ

  • データポータビリティ権は、データサブジェクトが、あるデータコントローラーが保有する自分に関するデータを、別のデータコントローラーに転送して利用できるように要求する権利
  • システムの移行時にデータを移す際に行使される権利
  • システムのデータは、他のシステムで容易に受け入れできるように構造化されていることが必要

データのローカリゼーション

  • 国境を超える情報や国内のデータサブジェクトに適用される法律は、国ごとに異なる
  • GDPRでは、プライバシーにかかわる情報をEU/EEA域外に持ち出し、GDPRの要求事項に準拠していない国のシステムに転送する際の条件を定めている

国と地域の例

  • 米国:
    • 業界固有のプライバシーデータ保護法があるが、全米での統一的なプライバシーデータ保護法はない
    • 米国憲法修正第4条では、国民は政府による不当な捜索や押収から保護される。この解釈を拡張してプライバシーの侵害に対する保護も含めている
    • 米国パトリオット法は、9月11日の同時多発テロの直後、2001年10月26日に署名され、裁判所の捜査令状などがなくてもデータオーナーなどに対する捜索・押収の権限を拡大した
  • 欧州連合 (EU):
    • GDPRプライバシー原則 : GDPR第5条では、個人データの利用に関する6つの原則を規定している
      • 適法性、公正性、透明性 : データサブジェクトと監査人にとって合法的かつ公正で透明性のある方法で、収集・処理・使用・共有・保存・破棄をすること
      • 目的の制限 : 明示的かつ合法的な目的でのみ収集・処理すること
      • データの最小化 : 必要最小限のデータのみ収集・生成・使用すること
      • 正確性 : データサブジェクトからの修正を受け入れられること
      • 保存の制限 : 必要な期間を超えて保持をしないこと
      • 完全性と機密性 : 不正な閲覧・使用・コピー・修正から保護されること
  • アジア太平洋経済協力会議 (APEC):
    • APECのプライバシーフレームワークでは、情報フローに対する障壁をなくし、持続的な貿易と経済成長を確保するためのプライバシー保護を定めている

米国の法律 [追加]

  • 合衆国法律集 (USC; United States Code) : 米国のすべての連邦刑法と民法の条文が記載されている
  • SOX : 上場企業会計改革および投資家保護法
  • HIPPA (Health Insurance Portability and Accountability Act) : 医療保険の相互運用性と説明責任に関する法律
    • HIPPAの対象団体に代わって個人の健康情報を扱う者は、ビジネスアソシエイツ契約 (BAA) の条項に従うこと
  • FERPA (Family Educational Rights and Privacy Act) : 学生の記録のプライバシーを保護する法律
  • COPPA (Children's Online Privacy Protection Act) : 児童オンライン保護法
    • 13歳未満の子供から個人情報を収集するには、事前にWebサイトで保護者の同意を得ることを要求する
  • GLBA (Gramm-Leach-Bliley Act) : グラム・リーチ・ブライリー法
    • 金融機関の顧客の機密データを保護する法律 (民法)
  • FISMA (Federal Information Security Modernization Act) : 連邦情報セキュリティマネジメント法
  • HSA (Homeland Security Act) : 国土安全保障法
  • CFAA (Computer Fraud and Abuse Act) : コンピュータ不正行為防止法
    • 悪意を持って任意の1年間に連邦政府コンピュータシステムに$5000を超える損害を与えると、連邦政府に対する犯罪となる
  • CALEA (Communications Assistance for Law Enforcement Act) : 法執行機関のための通信援助法
    • すべての通信事業者に対して、裁判所の命令を受けている法執行機関当局者は、盗聴できることを要求する
  • ECPA (Electronic Communications Privacy Act) : 電子通信プライバシー法
  • eDiscovery (eディスカバリー, 電子情報開示) : 当事者は、事件に関連する全情報の開示を求めることができる制度

サイバー犯罪とデータ侵害

  • サイバー犯罪は、情報・情報システム・情報技術を、当該システムや情報に関連する法律に違反する方法で使用する行為
  • データ侵害されたサーバが、ユーザとは別の国にある場合、複数の国の法律に違反する可能性がある

知的財産保護

  • 知的財産 (IP; Intellectual Property) は、人間の創造性による無形の創造物。著作権や商標などのこと
    • 有効期限 : 特許は20年。著作権は作者の死後70年。商標は無期限に更新可能
  • 経済スパイ法は、米国企業から営業秘密を盗んだ者に罰金と懲役刑を科す米国の法律
  • パブリックドメインは、目的を問わず誰でも無制限に使用できるライセンス
  • デジタルミレニアム著作権法 (DMCA) は、デジタル化された著作物に関する米国の法律
    • デジタルデータの複製を防止する技術を回避するソフトウェアなどの開発・頒布を禁止する
    • インターネットサービスプロバイダーは、DMCAの規定の下でセーフハーバー保護を受けることができ、顧客の一時的な違法行為に対する責任を負わない
  • 米国特許商標庁 (USPTO) が、特許の登録に関する責任を負う

輸入と輸出統制

  • 国家間で輸出入される技術が、国家間の戦力バランスを変えないようにするために条約が結ばれる
  • 特に暗号技術が規制対象になる場合がある

越境データフロー

  • 越境データフローは、国家や国などの政治的境界を越えたデータフローのこと

1-5. セキュアな設計の基本原則

  • 開発プロセスのできるだけ早い段階でセキュリティを考慮すること
  • 後からセキュリティを追加すると、既存の設計を変更しなければならず、性能に悪影響を及ぼす可能性があり、コストが増加する

最小権限 (最小特権)

  • 最小権限は、ユーザに職務を果たすために必要な最小限の機能を与えること

多層防御

  • 多層防御 (DiD; Defense in Depth) は、何重ものセキュリティを実施すること
  • 多層防御におけるそれぞれの層は「データ」「アプリケーション」「ホスト」「内部ネットワーク」「境界」「物理的コントロール」「ポリシー、プロシージャ、アウェアネス」の7層

セキュアなデフォルト (Secure by Default)

  • システムのデフォルト設定は可能な限り最も安全にすること

フェイルセーフ (フェイルセキュア)

  • フェイルセーフは、システムがクラッシュしても安全に故障すること
  • 潜在的な情報漏洩やその他のセキュリティリスクを軽減することができる
  • 制御された障害はシャットダウンで対応する(ブルースクリーンなど)

職務の分離 (SoD; Separation of Duties)

  • 職務の分離は、作業に2以上の人が必要になるようにし、1人に権限が集まらないようにすること
  • 職務の分離マトリックスは、競合する可能性のある2つの権限を1人が得られないようにするための役割とタスクに関する表

シンプルであること

  • シンプルなプロシージャは、正しく実行しやすく間違えにくい
  • シンプルな設計は、テスト、検証、正しさの証明が容易になる

Trust, but Verify

  • 信じよ、されど確認せよ
  • 1回でも認証されたユーザは、システム内を自由に歩き回ることができる

ゼロトラスト

  • ゼロトラストは、内部での振る舞いも検証できるようにするために、内部ネットワークを細かくセグメント化し、ユーザーIDの再認証を頻繁に行うようにすること

プライバシー・バイ・デザイン (Privacy by Design)

  • プライバシー・バイ・デザインは、システムの設計・開発段階でプライバシー維持が考慮されていることを保証するためのシステム設計手法

責任の分担 (Shared Responsibility)

  • 責任の分担は、クラウドサービス事業者がプライバシーとセキュリティを維持するための責任の一部を持つこと
  • ユーザは、クラウドサービス事業者と責任を共有する(共有責任モデル)


2. 情報資産のセキュリティ

2-1. 情報資産

  • すべてのデータは分類とカテゴリ化をして、取り扱いや使用を制御する

IT資産管理のライフサイクル

  • 資産管理のライフサイクルでは、まず資産とは何かを明確に定義することから始める必要がある
  • 資産の定義に基づいて、セキュアに維持する必要のある資産を区別する
  • 有形資産はサーバや建物などの物理的に存在するもの
  • 無形資産はアイデア、データ、情報、プロセスなどの物理的に存在しないもの
  • 組織が認識しているすべての資産は、情報資産とその場所をインベントリに記録すること

情報資産のインベントリ

  • 情報資産のインベントリは、何らかのセキュリティ保護が必要になる可能性がある様々な種類のデータオブジェクトの数と場所を把握するもの

分類とカテゴリ化

  • 組織が様々な情報資産を保護するために必要なセキュリティコントロールを決定すること
    • 分類 : アクセス権を分類する作業(極秘、秘、社外秘 など)
    • カテゴリ化 : 従事する業務に応じたアクセス権を分類する作業。検索しやすくもなる
      • 例:同じレベルの職員でも、プロジェクトAに参加している人だけがアクセスできる情報には、プロジェクトAというカテゴリを付与する

データの分類とカテゴリ化のポリシー

  • データの適切な利用のために、分類やカテゴリ化をするためのポリシーを決定する

分類とカテゴリ化:レベルとラベル

  • データの機微性のレベルは、データが侵害されたときの被害の大きさを表す
  • 機微性は分類 (開示) とカテゴリ化 (完全性、可用性、真正性) の両方を含む
  • 機微性のレベルの例:
    • 米国政府での分類
      • 最高機密 (Top Secret) : 非常に重大な損害
      • 機密 (Secret) : 深刻な損害
      • 部外秘 (Confidential) : 損害
      • 非機密 (Unclassified)
    • 民間での分類
      • 社外秘 (Confidential) / 専有 (Proprietary) : 非常に重大な損害
      • プライベート (Private) : 深刻な損害
      • 重要 (Sensitive) : 損害
      • 公開 (Public)
  • カテゴリ化は、そのデータの使用を決定するセキュリティ要件を反映する。検索しやすくもなる
  • カテゴリの例:
    • 個人識別情報 (PII) に関わるカテゴリ
    • 独自データのカテゴリ(組織内部のプロセスや意思決定など)
    • コンプライアンスデータのカテゴリ(契約など)
    • 個人健康情報、企業秘密、専有情報など
    • その他いろいろ

分類とカテゴリ化のメリット

  • 組織の情報保護の取り組みについて、従業員と顧客へ伝えることができる

分類とカテゴリ化に関する問題

  • 分類とカテゴリ化は、資産の価値と機微性を理解しているデータオーナーが実施する必要がある
  • 人的ミスや一貫性のない分類とカテゴリ化によって、データが侵害される可能性がある

2-2. データセキュリティライフサイクルの管理

  • データが作成されてから破棄されるまでの間に、人や組織が果たすべき役割を確認する

データセキュリティライフサイクル

  • すべてのデータ(無形資産)は、作成から破棄までに6つの状態がある
    • 作成(暗黙知)
    • 保存(形式知)
    • 利用(追加・修正・閲覧・削除など)
    • 共有(コピーなど)
    • アーカイブ(以降変更されないように保護する)
    • 破棄(利用不可にする)
  • 記録保持は、必要な期間、情報を保持・管理するプロセス

データの役割

  • プライバシー法は、個人が自身の個人情報をコントロールできるようにするための法律
  • コンプライアンスを遵守するために、組織はアカウンタビリティと責任を適切に割り当てる必要がある
  • それぞれの役割:
    • データサブジェクト : データによって識別される個人。データが参照する個人
    • データオーナー : 所有するデータの価値決定と保護を行う人。保護責任者&権限付与者。管理者とも呼ばれる
    • データコントローラー : 個人データの処理や保護の目的と方法を決める人。保護責任者代理
      • データオーナーの代わりになることができる
    • データスチュワード : データの内容、前後関係、関連業務ルールについて責任を負う人。データ使用の監視者
    • データプロセッサー : データコントローラに代わってデータを処理する人やプロセス。処理実行者
    • データカストディアン : データが保存されている間の完全性や機密性の責任を負う人。データ監視者。データ管理者とも呼ばれる
      • データオーナーから監視に関する権限を付与される
      • 保護ルールの作成とデータセキュリティの監視を行う
                        (DataOwner) ~= (DataController)
                             |
                             | Labeling
                             | 
               Provide       V          Monitoring
(DataSubject) -----------> [PII] <- - - - - - - - - (DataCustodian)
                             ^
                             |          Monitoring
                             | Use <- - - - - - - - (DataSteward)
                             |
                       (DataProcessor) 
  • その他の役割:
    • システムオーナー : システムのセキュリティに関する計画・特定・選択・実装などを実施する。システム管理責任者
      • システムに対して、処理するデータのレベルに対応するラベル付けを行う
    • システム管理者 : システムオーナーから権限を委譲され、ユーザにアクセス権を付与する役割を果たす
    • ビジネスオーナー : セキュリティ確保と事業継続のバランスをとる。ビジネス責任者

データの状態

  • データや情報の状態は、以下の3つのいずれかになる:
    • 保存データ : メディアに保存されており、プロセスなどが使用中でないデータ
    • 移動中(転送中)のデータ : ネットワークを通して移動しているデータ。リンク暗号化やエンドツーエンド暗号化によって保護される
    • 使用中のデータ : 追加・修正・削除などの処理やアクセスがされているデータ

データライフサイクルに関する考慮事項

  • データ収集 : 収集したらデータオーナーを任命してデータを分類する
  • データロケーションとデータローカライゼーション : データ保存場所、保護の仕組み、保持期間などの現地の法律を理解する
  • データメンテナンス : 各フェーズでデータ保護制御の実施を保証する
    • DLPやデジタル著作権管理 (DRM)、暗号化によるアクセス制御など
  • データ保持 : 必要な期間のみ保存されるようにする
  • データ残留 (Remnant Data) : 通常の使用期間が終了した後も情報を保持しているものに注意する
    • ストレージシステム、CPUのレジスタやRAM、ディスプレイ画面の回路など
    • SSDは「ウェアレベリング」機能によって別の領域にデータのコピーが常に作られるため、従来のサニタイズ手法では効果が得られない場合がある
  • データ破棄 : データ残留に対する対策方法
    • サニタイズ : データ破壊に関する広い概念。再利用する前にデータが残らないようにすること。PCから取り外す手順やディスク暗号化も含まれる
      • クリアリング : ランダムな値やゼロで上書きすることでデータ破壊を行うこと
      • パージング : 物理的な影響が残っている可能性を排除する作業のこと。HDDのデガウス (消磁) など
    • 物理破壊 : 媒体の再利用をしない場合の処理。裁断、切断、分解、酸でエッチング、焼却、埋め立て
  • エンドオブライフとエンドオブサポート : データの使用・保持・移動をサポートするハードウェア・ソフトウェア・サービスが突然サポート切れしたときのデータ損失を考慮する

2-3. データセキュリティコントロールとコンプライアンス要件の決定

  • 資産のセキュリティを維持するために、組織は資産に対して適切なコントロールを設定すること

適用可能なコントロールの種類

  • 組織はリスクを軽減するために、大きく分けて3種類のコントロールを使用する
    • 管理的コントロール : ポリシーやプロシージャを通じて実施する
    • 技術的・論理的コントロール : 電子的システムを使って実施する
    • 物理的コントロール : 物理的な仕組みを使って実施する(番犬、警備員、フェンス、マントラップ、ターンスタイルなど)

セキュリティコントロールのカテゴリ

  • コントロールは効果によってカテゴリ化される(コントロールタイプ):
    • 指示型(管理型)コントロール : ポリシーやプロシージャによって行動を制限する。貼り紙など
    • 抑止型コントロール : 攻撃のコストが高いと思わせて攻撃を諦めさせる。警告やカメラ、多要素認証など
    • 防止型コントロール : 不正な侵入を防止する。フェンス、DLPやIPSなど
    • 補完型コントロール : プライマリコントロールの喪失による影響を低減する。冗長構成など
    • 検出型コントロール : 敵対的な活動を検出する。人感センサーや警備員、IDSやSIEMなど
    • 修正型(補償型)コントロール : 修正・復元のためにインシデントに対応する。消化システムやCSIRTなど
    • 回復型(復旧型)コントロール : インシデント前の状態に回復する。バックアップやRAID、災害復旧計画など

スタンダードの選択

  • PCI DSS や ISO、GDPR などのフレームワークを利用する

データセキュリティベースラインの確立

  • セキュリティベースラインは、基準となる最低限のセキュリティ

ベースライン保護の目的

  • 組織の分類した資産を保護するために、最低限のセキュリティ対策を確立すること

ベースラインカタログ

  • ベースラインは、セキュリティ構成の集合
    • 組織のセキュリティ要件に合致するように調整できる
  • ベールラインカタログは、使用すべきセキュリティ対策や、取り組むべきセキュリティ要件を提案している

一般に認められた原則

  • 情報セキュリティを俯瞰できる一般的な原則がいくつかある:
    • 予防、検知、対応、復旧
    • 使用中、転送中、保存中の情報の保護
    • 外部システムをセキュアではないと見なすこと
    • 情報システムのレジリエンス(破壊的な出来事に耐え得ること)
    • 監査能力とアカウンタビリティ
    • その他いろいろ

範囲の決定とテーラリング

  • フレームワークやスタンダードを導入する際は、範囲を決定する(スコーピング)
  • スコーピングは、ベースラインのコントロールを保護対象のシステムに適用させるときに行う
  • テーラリングを通して、組織はフレームワークやスタンダードの一部分だけを導入することもできる
  • テーラリングは、手順などを組織に適したものに調整すること


3. IDとアクセスの管理 (IAM)

3-1. IDおよびアクセスのプロビジョニングライフサイクル

  • IDは、人間だけでなくシステムを構成するハードウェアやソフトウェアにも割り当てられる
  • 各エンティティは、オンボーディングからオフボーディングまでの間、IDで管理される
  • IDに紐づく権限は、業務やタスク内容に応じて変更する

アクセス制御

  • アクセス制御は、ビジネスとセキュリティ要件に基づいて資産へのアクセスが認可・制限されることを保証する手段
  • アクセス制御は、システム内のオブジェクトに対するサブジェクトへのアクセスを制御すること
    • オブジェクトは、情報資産やシステムリソース
    • サブジェクトは、オブジェクトにアクセスしたい人やプロセスなど
    • アクセスは、オブジェクトに対する操作のこと

IDライフサイクル

  • 識別子は、すべてのオブジェクトとサブジェクトが持つラベルのこと
  • IDライフサイクルは、プロビジョニング > 認証 > 認可 > アカウンティング > ユーザ挙動のレビュー > オフボーディング の順番で進む

プロビジョニング

  • プロビジョニングでは、ユーザがアクセス権限を要求すると、管理者は本人であることのID証明をして、作業範囲に応じたアカウント権限をユーザに割り当てる
  • ID証明は、あるIDに対するユーザの主張と第三者の証明によって妥当性を検証すること
  • 帯域外のID証明 (Out-of-bound identity proofing) は、最初に検証を要求した環境以外での検証を利用するID証明
  • 資格 (Entitlement) は、アカウントを最初に設定するときにユーザに与えられる権限
  • SPML (Service Provisioning Markup Language) は、ユーザ・リソース、サービスのプロビジョニング要求の統合・相互運用に使用されるプロトコル
    • ワークフローベースのアカウントプロビジョニングは、ワークフローで入力した情報でアカウントをプロビジョニングすること

認証

  • 認証は、リソースへアクセス時にユーザ・プロセス・デバイスの身元の主張の妥当性を確認すること
  • 認証では、ユーザの資格情報と知る必要性を検証する
  • マスカレード(仮装)攻撃は、盗み出した、または偽りの認証資格情報を利用して認証メカニズムをバイパスする攻撃
  • リプレイ攻撃は、キャプチャーしたネットワークトラフィックを利用して接続を再確立するマスカレード攻撃の一種

認可

  • 認可は、IDがオブジェクトへアクセスするための権限を付与すること
  • 認可は、サブジェクトのアクション時にオブジェクトへの権限やルールで許可されていることをリアルタイムで確認すること
  • アクセス制御リスト (ACL) は、ユーザの認可レベルを決定する
  • セルフサービスID管理は、ユーザが自身でIDや権限を変更できること
  • アクセス権を付与する(認可する)際は、ユーザのクリアランスと知る必要性を検証する

アカウンティング

  • アカウンティングは、全IDの全アクションを追跡するID管理機能
  • ログは、説明責任を果たすために必要

ユーザの振る舞いのレビュー

  • 可能であれば期待されるユーザのふるまいのパターンを定義する

業務や義務のレビュー

  • 権限のクリープは、不要になった権限を放棄しないこと。特権クリープとも呼ばれる
  • 権限のクリープを防止するために、業務や責任が変わるたびに権限のレビューを行うこと

無効化とデプロビジョニング

  • アカウントを削除するとログの調査に支障が出るので、削除ではなく無効化をすること
  • デプロビジョニングは、権限の無効化をシステム全体に適用すること

アカウントアクセスのレビュー

  • アカウントレビューは、イベント時に必ず行うこと
    • ユーザの役割が変わるとき
    • ユーザが退職するとき
  • アカウントレビューは、イベントに関係なく定期的に行うこと
    • 無効なアカウントの無効化
    • 権限集約(権限のクリープ)の防止
    • 権限不足によるアカウントの使いまわしの防止

権限昇格

  • 権限昇格は、OSやソフトウェアのバグを利用して保護されたリソースへのアクセス許可を昇格させること

権限昇格の種類

  • 垂直方向の権限昇格は、現在使用中のアカウントでより高い権限レベルのアプリやサービスを実行すること
  • 水平方向の権限昇格 (システム内の横移動) は、現在使用中のアカウントで別のサーバ上のデータやリソースにアクセスすること

IAAAはCIANA+PSを導入

  • CIANA+PSは、機密性(Confidentiality)、完全性(Integrity)、可用性(Availability)、否認防止(Non-repudiation)、真正性(Authenticity) + プライバシー(Privacy)、安全性(Safety) の略語
  • ID、認証、認可、アカウンティングの各機能を統合することで、CIANA+PSに対応することができる
--> Identification --> Authentication --> Authorization -->
              |              |                 |
              |              V                 |
              +--------> Accounting <----------+

3-2. アクセス制御モデルとメカニズムの実装と管理

セキュリティモデルの基本的な概念の理解

  • セキュリティモデルは、ポリシーを守らせるためのふるまいのルールを定義するもの
  • セキュリティモデルの中には、システムの機密性や完全性のポリシーも含まれる

BLP (Bell-LaPadula)

  • Bell-LaPadulaは、マルチレベルセキュリティ (MLS) で「機密性」を扱うモデル
    • 単純セキュリティ属性 : read upできない(機密性が高い層はアクセスできない)
    • スター属性 : write downできない(機密性が低い層に書き込めない)
    • 強化スター属性 : read up/down, write up/downできない(同じ層のみ読み書き可能)
  • ラティス(マトリックス)を利用してアクセス制御する強制アクセス制御 (MAC) モデルの一種

Biba

  • Bibaは、マルチレベルセキュリティ (MLS) で「完全性」を扱うモデル
    • 単純完全性属性 : read downできない(完全性が低い層の情報を使えない)
    • スター属性 : write upできない(完全性が高い層の情報を汚染できない)
    • 呼び出し属性 : 上位レベルにアクセスできない
  • ラティス(マトリックス)を利用してアクセス制御する強制アクセス制御 (MAC) モデルの一種

Brewer-Nash

  • Brewer-Nashは、倫理の壁(ファイヤーウォール、万里の壁)が中央にあり、一方にアクセスできる時はもう一方にはアクセスできないモデル

Clark-Wilson

  • Clark-Wilsonは、Bibaの改良版で、トランザクションレベルでの完全性に焦点を当てている
    • サブジェクトとオブジェクトの間にプログラム(リファレンスモニター)が存在し、アクセスが正しいものか検証する

Graham-Denning

  • サブジェクトとオブジェクトの作成方法や、サブジェクトに権限を割り当てる方法、オブジェクトのオーナーシップを管理する方法を扱うモデル

HRU (Harrison, Ruzzo, Ullman)

  • HRUは、Graham-Denningモデルに似ていて、一般的な権限のセットと有限のコマンドのセットを構成するモデル

Take-Grant保護モデル [追加]

  • 特定のルールに従う特定のコンピュータシステムの安全性を確立するためのモデル
  • 4つのルールから構成される:
    • 獲得ルール (take rule) : サブジェクトは別のオブジェクトの権利を取得できる
    • 付与ルール (grant rule) : サブジェクトは別のオブジェクトに権利を付与できる
    • 作成ルール (create rule) : サブジェクトは新規オブジェクトを作成できる
    • 削除ルール (remove rule) : サブジェクトは別のオブジェクトから権利を削除できる

最新の実装

  • セキュリティモデルの一部分をOSベンダー固有の方法で実装している
  • セキュリティモデルを実装しようとすると技術的な制限がある

アクセス制御 (AC) モデル

  • アクセス制御モデルは、ポリシーとメカニズムの間の抽象度のギャップを埋めるもの
  • MACモデル、DACモデル、NDACモデル などがある

強制アクセス制御 (MAC)

  • MACは、アクセス制御ポリシーの決定を中央機関が行うアクセス制御システム
  • すべてのサブジェクトとオブジェクトはラベル付けされる
    • サブジェクトに対して付与するラベルは「クリアランス」とも呼ばれる
    • SELinuxでは、サブジェクト(プロセス)に対して付与したラベルを「ドメイン」と呼ぶ
                  [Policy] <(NG!)
                     ^
                     |
                     V
               / Reference \          [DataOwner] <(OK!)
(Subject) -----\  Monitor  /----> (Object)
                     |
                     V
                    Log
  • ラティスベースのモデル(サブジェクトとオブジェクトのラベルから、アクセス許可を判断するモデル)に基づいている
  • ラティスベースのモデルは、アクセス制御マトリックスとも呼ばれる
  • SELinuxやゼロトラストアーキテクチャなど
  • 強制アクセス制御 (MAC) システムの形態は、以下の3つがある:
    • 階層 : ドメインが順序付けされて上下関係を持つ
    • 区間 : ドメイン間に関係がない
    • ハイブリッド : 階層と区間の両方が混在する

任意アクセス制御 (DAC)

  • DACは、自分が所有するオブジェクトへのアクセス権を誰に与えるかをオーナーが決定するアクセス制御システム
  • アクセス制御をオブジェクトオーナやオブジェクトへのアクセスが許可された人にまかせる
  • WindowsやLinuxなどの一般的なOSで使用されている
                                      [DataOwner] <(OK!)
(Subject) ----------------------> (Object)

非任意アクセス制御 (NDAC)

  • ロールベースアクセス制御 (RBAC) を適用し、中央機関でポリシーを決定する
  • ベンダーがポリシーを決める。インストール時に管理者パスワードを入力させるなど

ロールベースアクセス制御 (RBAC)

  • 職務や認可に応じて個別にロールを設定し、情報システムへのアクセスを許可されたユーザに限定する
  • RBACの利用方法:
    • 制限付きRBAC : 一部のアプリケーションとそのデータがRBACで保護されている
    • フルRBAC : すべてのアプリケーションとそのデータがRBACで保護されている
  • グループベースのモデルに基づいている
  • 各グループの役割に基づいて許可を与える

ルールベースアクセス制御 (RuBAC)

  • RuBACは、いつ、どこで、指定した条件で、システムが読み書き実行を許可するかなどの粒度で管理するアクセス制御
  • RuBACでは、IPアドレスや特定の時間帯などでアクセスを制限する
  • ファイアウォールは、通過するすべてのトラフィックの制御にRuBACを使用している
  • すべてのサブジェクトに適用されるルールを使用して許可を与える

属性ベースアクセス制御 (ABAC)

  • ABACは、属性の組み合わせをポリシーとし、属性を満たすユーザにアクセス権を付与するアクセス制御
  • ABACでは、ユーザの属性、リソースの属性、環境の属性などをポリシーとして設定できる
  • ABACは、RuBACをよりシンプルにしたもの
  • ABACは、文脈 (コンテキスト) に依存した制御とも呼ばれる

リスクベースアクセス制御

  • 属性などに基づいて算出したリスクレベルによって、RuBAC、RBAC、ABAC でアクセス権を付与する基準を変化させるアクセス制御
    • 例 : 接続先IPの地域が変わった際に追加の認証を求める

3-3. 人とオペレーションの管理

最小権限

  • 最小権限は、割り当てられた職務やタスクを実行するために必要な最低限のレベルの権限を割り当てること
  • プロビジョニングや権限管理のときに考慮する

知る必要性 (Need to know)

  • 知る必要のない情報にはアクセスできない

職務と責任の分離

  • 職務の分離 (SoD; Separation of Duties) は、個人が単独でプロセス全体を完了できないこと
  • 不正行為を防ぐために使用する
  • 重要な手順には、第2、第3の人の承認を必要にすること

特権アカウント管理

  • 高度な権限を持つアカウントは影響が大きいため、以下の緩和策が必要
    • ログの取得、監査強化
    • より厳格なアクセス制御
    • 特権は一時的に扱う (sudoなど)

ジョブローテーションなどの人事戦略

  • ローテーション後に引き継いだ後任者が前任者の不正を発見できる
  • 単一障害点となる従業員がいなくなることで、事業継続性と災害復旧がスムーズにできる
  • 技術や知識が共有される

強制休暇

  • 強制休暇は、偽装や隠蔽された不正行為を発見し、不正や横領の機会を減らす
  • 別の従業員が責任をカバーすることで、社内にいない人の不正を発見する
  • 休暇は、少なくとも1週間~2週間以上はとること

デュアルカストディ (2人制御)

  • デュアルカストディ(デュアルコントロール)は、重要なアクションを完了するために2人以上の個人が別々のアクションを同時に実行すること
  • 機密性の高い処理操作をする際に使用する

3-4. 資産の物理的、論理的なアクセス制御

IAM管理の選択

  • 集中管理 : アクセス制御を中央管理が行うこと
  • 分散管理 : ファイルのオーナーや作成者が、情報へのアクセスを制御すること
    • 分散型アクセス制御は、リソースに近い人員にアクセス制御の権限を与えること
    • デメリットは、一貫したアクセス制御を提供しない点。制御点を移動するだけなので、冗長性は提供しない
  • ハイブリッド : 全般的で基本的なアクセスは集中管理し、各ファイルは作成者やオーナーによって管理(分散管理)する

システムとしてのアクセス制御

  • 管理コントロールと物理的コントロールと論理コントロールの3つ全てを使って構築される
  • 論理的アクセス制御を選択・実装する前に、情報の分類とカテゴリ化をする必要がある

物理的アクセス制御システム (PACS)

  • PACS (Physical Access Control System) は、境界線にある特定の入り口を通る人や物の移動を管理する

アプリケーション

  • アプリケーションは組織の資産インベントリの一部であり、組織にとって重要なデータが含まれている
  • アプリケーションへのアクセスもアクセス制御の原則に従う必要がある
    • 制限されたインターフェース (Constrained Interface) は、ログインユーザのアクセス権限によってインターフェースを制限すること

3-5. 人、デバイス、サービスの識別と認証の管理

  • IDストアの使用と資格情報の作成や使用が、シングルサインオンやフェデレーションID管理などの技術を構成する

IDストア (identity store)

  • IDストアは、IDに関するすべての情報の集中的なリポジトリを提供する
  • 複数の資格情報を管理するユーザの負担を減らし、様々な環境におけるIDサービスを標準化する仕組み
  • レポジトリの例 : Kerberos, RADIUS, LDAP, OAuth2.0, SAML, OpenID, OpenID Connect, FIDO, WebAuthn

資格情報管理システム

  • 資格情報 (クレデンシャル) は、認証者と識別子の間の結びつきのこと
  • FICAM 2.0のアーキテクチャでは以下の5段階の登録プロセスがある
    • スポンサーシップ : 資格情報の認証要求者を保証 (スポンサー) する
    • 登録 : 身元確認を行い、資格情報を登録する
    • 資格情報作成 : スマートカード、公開鍵暗号、デジタル証明書の形で作成する
    • 発行 : 認証要求者に資格情報を発行する
    • 資格情報ライフサイクル管理 : 資格情報は、失効、再発行、再登録、有効期限切れ、一時停止、復活などの活動を通じて維持される

IDアクセス管理 (IAM) の実施

  • IAMを実施するには、まず自組織のニーズ、課題、要望を理解すること

ISO Identity Model

  • ISO/IEC 24760 は、ISOがID管理のために作成したフレームワーク
  • プライバシーを扱うISO 2910x シリーズや、身元証明に関するISO 29003などのスタンダードもある

フェデレーションID管理 (FIM)

  • FIM (Federation Id Management) は、ドメインを超えて組織のID管理を統合すること
  • FIMは、SAMLやOAuthなどを利用する
  • FIMは、異なるセキュリティドメイン間で信頼関係を構築する
  • 信頼ドメインは、以下の3つの構成要素からなる共通のデジタルIDを用いてアクセス (検証) を行う
    • クライアントやプリンシパル
    • サービスプロバイダ (SP) やリライングパーティ (RP)
    • IDプロバイダ (IdP)
  • IdPは、仲介サービスを行い、本人が誰であるか、名前は何かを主張する
  • SPは、認可サーバのメンテナンスや承認/拒否の決定を行う
  • FIMモデルでは、各組織がIdPとなり、異なるドメインに属する資格情報の有効性を主張する

単一要素認証 (SFA) vs 多要素認証 (MFA)

  • ログインが許可されている証拠の種類:
    • あなたが知っているもの : パスワード、PIN、質問への回答など (タイプ1認証要素)
    • あなたが持っているもの : トークン、スマートカードなど (タイプ2認証要素)
    • あなたが何であるか : 生体認証、指紋、虹彩など (タイプ3認証要素)
  • コグニティブパスワード (Cognitive password) は、知っている質問に対する回答に基づいてユーザを認証するタイプ1認証要素
  • 虹彩は、生涯を通じて変化しないタイプ3認証要素
  • 単一要素認証は、1種類の証拠だけで認証すること
  • 多要素認証は、複数種類の証拠で認証すること

アクセス制御トークン

  • 物理的なセキュリティトークン : 「あなたが持っているもの」の証拠として使用される。トークンデバイスやスマートフォンなど
    • ソフトウェアトークンは、スマホアプリやSMSなどで使えるため、ハードウェアトークンよりも柔軟性が高い
  • 論理アクセストークン : 認証されたユーザIDに対して生成される情報。セッションやCookieなど

生体認証

  • バイオメトリック技術は測定における誤差などがあるため、単一要素認証としては使われない
  • 多要素認証システムの一部として使用される
  • センサーによって得られた特徴量は、バイオメトリック参照データや、テンプレートと呼ばれる

IDの登録、証明、確立

  • IAL (Identity Assurance Level) は申請者が主張するIDの信頼度合いを表すカテゴリ
    • IAL1 : 自分で作成したIDを使うとき
    • IAL2 : 第3者が発行したIDを使うとき
    • IAL3 : 十分な本人確認をしてIDを発行するとき

シングルサインオン (SSO; Single Sign-On)

  • SSOは、複数のシステムにアクセスする際に、エンドユーザの視点から統一されたログイン方法を提供する
  • SSOは、ドメインをまたいだ様々な組織やアプリのID認証ができる
  • SSOは、フェデレーションID管理とも呼ばれる

アクセス制御のエラー

  • 本人拒否率 (FRR; False Rejection Rate), タイプ1 : 正しいIDを認識できないエラー
  • 他人受入率 (FAR; False Acceptance Rate), タイプ2 : 許可されていないIDを許可してしまうエラー
  • FRR, FAR はバイオメトリック技術でよく使われるが、それ以外のシステムでも使われる
  • FRRが高いほど、高いセキュリティ&低い可用性
  • FARが高いほど、低いセキュリティ&高い可用性
  • 等誤り率 (CER; Crossover Error Rate) : FRRとFARが交差する点

ジャストインタイムID (JIT ID)

  • ジャストインタイムIDは、オンデマンドでリアルタイムに、ユーザIDの作成とプロビジョニング、権限昇格、デプロビジョニング、一時停止、終了などのIDライフサイクルを提供する
  • 例 : PAM (Privileged Account Management) は sudo で一時的に権限昇格させる

3-6. 認証・認可システムの導入

セッション管理

  • セッション管理は、同じサブジェクトからのサービスへの複数の要求を追跡し、保護すること
  • Kerberosでは、認証チケット(Kerberos Authentication Ticket; TGT)を生成する
  • Webアプリでは、セッションIDを生成してクッキー (Cookie) に保存させる
  • クッキーにセキュア属性を設定してTLSを強制することで、セッションハイジャックを防止できる

初期の概念

  • Kerberos, LDAP, Active Directory などは X.500 Directory Access Protocol がベースになっている

RADIUS

  • RADIUSは、認証と認可を提供するAAAプロトコル
  • RADIUSは、モデム、無線ネットワーク、ネットワークデバイスに使用されることが多い
  • RADIUSは、ダイアルアップの利用者を認証する方法として開発され、リモートアクセスのサポートに利用されてきた
  • RADIUSは、デフォルトでUDPを利用する。TLSモードに変えることも可能
  • RADIUSは、デフォルトでパスワードのみを暗号化する。TLS over TCP に変えることも可能。UDP over TLS はサポートされていない
  • Diameterは、RADIUSの代替となるために改善された幅広い機能を持つAAAプロトコル

TACACS

  • TACACSは、リモートユーザの認証を自動化したい米国国防総省ネットワークのニーズから生まれたシステム
  • TACACSは、Cisco Systems社のネットワーク機器で一般的に使用されている
  • TACACSは、オープンスタンダードではない
  • TACACS+は、TACACSをベースにした全く新しいプロトコル
  • TACACS+は、TCPを使用してセッション全体を暗号化する。多要素認証もサポートしている

LDAP

  • LDAPは、X.500 Directory Access Protocolに基づくディレクトリサービス
  • LDAPサーバは、ユーザ情報とサービス情報をディレクトリツリーに格納する
  • LDAPディレクトリツリーの各エントリーは、識別名 (DN; Distinguished Name) によって示される
  • LDAPディレクトリは、様々なユーザ情報を保存している
  • LDAP識別名 (DN) は、相対識別名 (RDN; Reletive DN) という1個以上のコンマ区切り要素から構成される
    • 例 :「CN=suzuki,OU=Eigyou1,DC=example,DC=co,DC=jp」
  • LDAPは、389/tcp (平文)、TLSを使ったLDAPSは 636/tcp (暗号化) を使用する
  • グローバルディレクトリ(LDAP in Active Directory)のポートは、3268/tcp (平文)、3269/tcp (暗号化) を使用する
  • OpenLDAPは、デフォルトでuserPasword属性を平文で保存する
  • LDAPのSASL (Simple Authentication and Security Layer) は、セキュアな方式を含む幅広い認証タイプをサポートする
  • LDAPバインドは、ユーザ資格情報を使用して認証するためのコマンド

OpenID

  • OpenID Connect (OIDC) は、認可フレームワークである OAuth 2.0 の実装である
  • SAMLはWebサイトからの要求に特化しているのに対して、OIDCはWebサイトやモバイルアプリを要求元として認証することができる
  • OIDCは、OAuth 2.0プロトコル上の認証層として動作する
  • OAuth 2.0は、認可プロトコル
  • OIDC認証では、リライングパーティ (RP) は OAuth 2.0 アプリケーションで OpenID Connect Provider (OP) にIDトークンを要求する
  • IDトークンのフィールドには、以下のデータが含まれている
    • sub (Subject) : ユーザ
    • iat (Issued At), exp (Expired) : 認証イベントのタイミング (発行時刻と有効期限)
    • iss (Issuer Identifier) : OPの発行者識別子
    • aud (Audience): RPが発行者に登録したクライアント識別子

Kerberos

  • Kerberosは、認証・認可・監査の3つの要素でネットワークを保護するチケットベースの認証プロトコル
  • Kerberosは、SSO (Single Sign-On) を実現するプロトコル
  • Kerberosでは、以下の3つのシステム間でやりとりが行われる:
    • プリンシパル : Kerberosサーバとやりとりするあらゆるエンティティ(ユーザ、アプリ、サービスなど)
    • エンドポイントの宛先サーバ : アプリや情報リソースが存在する場所
    • KDC (Key Distribution Center)
  • KDCは、認証において、認証サーバ (AS; Authentication Server) とチケット発行承諾サーバ (TGS; Ticket-Granting Server) の2つの機能を果たす
  • ユーザは、Kerberosレルムに追加されると、ASから認証を受けられるようになる
  • レルム (Realm) 信頼は、レルムA内のユーザーが、レルムBに属するかのように、別のドメインのリソースにアクセスするために信頼されること
  • KDCは、TGSによって検証されたチケットをプリンシパルに提供する
  • アクセス手順:
    1. ユーザは、ASに認証資格情報を提供する
    2. ASは、クライアントTGS鍵を生成する
    3. ASは、認証をする
    4. ASは、ユーザにTGT (Ticket Granting Ticket) を発行する
    5. ユーザは、TGSにTGTとIDを提供する
    6. TGSは、クライアントサーバーチケットを生成する
    7. TGSは、TGTの有効期限を検証する
    8. TGSは、ユーザにST (サービスチケット) を発行する
    9. ユーザは、サービスにSTと認証コードを使ってアクセスする
      • STは、サブジェクトがオブジェクトにアクセスする権限が与えられている証拠を提供する
      • 認証コードは、クライアントIDと、タイムスタンプをセッション鍵で暗号化したものが含まれる
  • チケットが有効である場合、ユーザは再認証する必要がない
  • Kerberosプロセスでは時間を使うため、時間を確実に同期できるNTPデーモンを起動する必要がある
    • ローカルシステム時間が同期から5分以上ずれていると、TGTは無効になる
  • 暗号化について
    • KDCは、対象鍵暗号を使用して、すべてのプリンシパルの秘密鍵をデータベースに保持している
    • ユーザは、Kerberosログイン時に、ユーザ名とパスワードをAESで暗号化してからKDCに送信する
    • KDCは、ユーザのパスワードを利用してハッシュを生成し、そのハッシュで対象鍵を暗号化する
    • KDCは、暗号化された対象鍵と、暗号化されてタイムスタンプが押されたTGTの両方をユーザに送信する
    • ユーザは、TGTを受理して、ユーザのパスワードのハッシュを利用して対象鍵を復号する
  • Kerberosは、88/udp を使用する

SAML (Security Assertion Markup Language)

  • SAMLは、オンライン事業間でセキュリティ情報を記述交換するためのXMLベースのフレームワーク
  • SAMLの3つの役割:
    • IDプロバイダー (IdP)
    • サービスプロバイダー (SP) / リライングパーティ (RP)
    • ユーザーエージェント
  • SAMLのコンポーネント:
    • アサーション : SAMLの属性、認証、認可をやり取りする方法を決める
    • バインディング : SAMLのアサーションとプロトコルメッセージの交換をする方法を決める
    • プロトコル : SOAPやHTTPなど、使用するプロトコルを決める
    • プロファイル : 特定の機能的ニーズに対応するために必要なアサーション、バインディング、プロトコルのセットを決める
  • アクセス手順:
    1. ユーザは、アプリ(SAMLが組み込まれたサードパーティサービス)へのアクセスを試行する
    2. アプリは、HTTPレスポンスでSSO URLにリダイレクトさせる
    3. ユーザのWebブラウザは、SSO URLにアクセスする
    4. IdPは、ユーザを認証してSAMLレスポンスを作成する
    5. IdPは、SAMLレスポンスをブラウザに送信する
    6. ユーザのWebブラウザは、SAMLレスポンスをサードパーティに送信する
    7. アプリは、SAMLレスポンスが検証し、サードパーティアプリにログインする
  • アプリが偽のSSO URLにリダイレクトさせる場合は、ユーザの意識啓発が最も効果的な防御策となる

OAuth 2.0 (Open Authorization)

  • OAuthは、あるサイトからの資格情報をサードパーティのアプリで使用することを限定的に許可する認可フレームワーク
  • RFC 6749 参照
  • OAuthの4つの役割:
    • リソースオーナー : 保護されたリソースへのアクセスを許可するエンティティ
    • リソースサーバー : 保護されたリソースを持つサーバ。クライアントはアクセストークンによってアクセスできる
    • クライアントアプリケーション : リソースオーナーに代わって、保護されたリソースへのアクセス要求を行うアプリケーション
    • 認可サーバー : クライアントにアクセストークンを発行するサーバ
  • アクセス手順:
    1. クライアントアプリは、認可サーバへ認可依頼を出す
    2. 認可サーバは、リソースオーナーへ許可するか否かの確認をする
    3. リソースオーナーは、認可サーバへ許可を送信する
    4. 認可サーバは、クライアントアプリへ認可をする
    5. クライアントアプリは、リソースサーバへ認可結果に基づいてアクセスする

サードパーティのサービスを利用したフェデレーションID

  • FIDやIAMをアウトソーシングする場合でも、デューケアやデューデリジェンスの最終的な責任は組織にある

監査およびコンプライアンス報告

  • IDaaSは、ID管理、プロビジョニング、ガバナンス、管理サービスを組み合わせて顧客企業に提供するサービス
  • サービスのカテゴリ:
    • IGA (Identity Governance and Administration) : アカウントやアクセスのメンテナンスを提供する
    • アクセス : SSOなどによる認証認可、SAMLやOAuthなどのフェデレーションアクセススタンダードをサポートする
    • インテリジェンス : IDアクセスやアクティビティについてのログ、監視、レポートを提供する


4. セキュリティアーキテクチャとエンジニアリング

4-1. セキュリティアーキテクチャ、設計およびソリューション要素の脆弱性の評価と緩和

セキュリティエンジニアリング

  • 一般的なエンジニアリング手法を用いて、特定の状況、問題、必要性に対してシステムセキュリティの理論を実用的、効果的な方法で適用する

セキュリティエンジニアリングのプロセス

  • エンジニアリングには、変更管理と構成管理が含まれる

技術的プロセス

  • ビジネスおよびミッション分析プロセス : ビジネスまたはミッションの問題を理解する
  • ステークホルダーのニーズと要件の定義プロセス : 利害関係者のセキュリティ要件を定義する
  • システム要件の定義プロセス : 利害関係者のセキュリティ要件をシステム要件に変換する
  • アーキテクチャ定義プロセス : 代替案の選択に役立つシステムアーキテクチャの一覧を作成する
  • 設計定義プロセス : システムとそのデータや情報を提供する
  • システム分析プロセス : 意思決定に必要なデータや情報を提供する
  • 実装プロセス : セキュリティ要件をシステム要素とその振る舞いに変換する
  • 統合プロセス : セキュリティ要件通りにシステムを構成する
  • 検証プロセス : セキュリティ要件を満たしていることを検証する

技術的管理プロセス

  • プロジェクト立案プロセス : セキュリティタスクの達成に必要な成果物を特定する
  • プロジェクト評価・統制プロセス : 具体的な管理措置の必要性を伝える
  • 決定管理プロセス : 意思決定のための代替案を特定、分析、評価する
  • リスク管理プロセス : セキュリティリスクを特定、分析、処理、監視する
  • 構成管理プロセス : システムライフサイクルの管理と制御が、セキュリティを考慮すること保障する
  • 情報管理プロセス : すべてのセキュリティ上の懸念事項が、適切に対処されることを保証する
  • 測定プロセス : 効果的な管理を支援し、製品・サービス・プロセスの品質を保証する
  • 品質保証プロセス : セキュリティ品質保証分析をし、求められるセキュリティ品質を満たしていることを確認する

イネーブリングプロセス

  • イネーブリングは、何かを実現させること
  • ライフサイクルモデル管理プロセス : ライフサイクルのセキュリティの懸念事項を特定・評価する
  • インフラ管理プロセス : インフラやサービスが懸念事項に対応できるかを確認する基盤を提供する
  • ポートフォリオ管理プロセス : ポートフォリオの管理にセキュリティの考慮を徹底し、投資を正当化する
  • 人的資源管理プロセス : 要員の評価・選定、トレーニングのためのセキュリティ基準を定義する
  • 品質管理プロセス : セキュリティ品質を満たしているかを判断するための基準を定義する
  • ナレッジ管理プロセス : セキュリティに関する知識と技能を特定、取得、維持、管理する

合意プロセス

  • 調達プロセス : セキュリティの懸念事項が、調達者の要件によって対処されることを保証する
  • 供給プロセス : 調達者のセキュリティ要件に対処しつつ、サービスを提供できるようにする

セキュリティポリシー、モデル、アーキテクチャ

  • システム開発では、ビジネスやミッションのニーズや制約条件を「ポリシー」という
  • セキュリティポリシーは、システムとその振る舞いの制約を課す
  • セキュリティモデルは、サブジェクトとオブジェクトによって表される概念のモデル
    • 状態マシンモデル : システムの開始状態と終了状態を特定する
    • 情報フローモデル : 状態マシンモデルの拡張で、システム全体の情報の動きに焦点を当てている
    • 非干渉モデル : あるレベルのオブジェクトやサブジェクトが、他のレベルと不適切に相互作用しないようにする
    • リングモデル : ハードウェアとソフトウェアの層でのセキュリティ機能の相互作用に焦点を当てている
      • リング0 : OSとセキュリティカーネル
      • リング1 : デバイスドライバ
      • リング2 : ユーティリティ
      • リング3 : アプリケーション
      • リング0~2は、特権モードで動作する。リング3は、ユーザモードで動作する
  • セキュリティアーキテクチャは、セキュアなシステムの構築やシステムやソフトウェアコンポーネントに要求されるセキュリティのふるまいや特性を記述したもの

様々なシステムアーキテクチャへのセキュリティモデルの適用

  • クライアント型システム
  • サーバベースシステム
  • データベースシステム
  • 産業用制御システム (ICS; Industrial Control Systems)。以下の3要素から構成される
    • 監視制御とデータ取得 (SCADA; Supervisory Control And Data Acquisition)
    • 分散制御システム (DCS; Distributed Control System)
    • プログラマブル論理コントローラ (PLC; Programmable Logic Controllers)
  • 組込みシステム
  • IoT
    • 導入するデバイス数は増えているが、頻繁にアップデートされていないため、安全ではないことが多い
  • 分散システム
  • 仮想化システム
    • 脆弱性 : スプロール(イメージ管理が無秩序な状態)
    • 脆弱性 : VMエスケープ(仮想環境からホストコンピュータを操作すること)
    • 仮想マシン同士の通信は「仮想スパンポート」でポートミラーリングして通信をモニタリングする
    • 仮想マシンでコピーアンドペーストを有効化すると、隠れチャネルとなる可能性がある
  • クラウドベースシステム
  • クラウドコンピューティングの特徴
    • サービスモデル:
      • SaaS (Software as a Service) : クラウド基板上で動作するアプリケーションを提供する
      • PaaS (Platform as a Service) : クラウド基板上でユーザのプログラムやサービスを展開することを提供する
      • IaaS (Infrastructure as a Service) : クラウド基板上で動作するOS、ストレージ、ネットワークを提供する
    • デプロイメントモデル:
      • パブリッククラウド : 一般の人が自由に利用できる。顧客同士はお互いの身元を知ることができない
      • プライベートクラウド : 単一の組織が独占的に利用できる
      • コミュニティクラウド : 共通の目的を持つ複数の個人や組織からなる特定のコミュニティが独占的に利用できる
      • ハイブリッドクラウド : 複数のクラウドインフラ(パブリック、プライベート、コミュニティ)を組み合わせたもの
    • マイクロサービス
    • コンテナ化
    • サーバーレスアーキテクチャ
  • 高性能計算システム (HPC; High Performance Computing)
  • エッジコンピューティングおよびフォグコンピューティングのアーキテクチャ

4-2. 暗号システム

  • セキュリティ特性
    • 機密性(暗号化)
    • 完全性(改ざん検知)
    • 真正性(デジタル署名)
    • 可用性(認可されたユーザが必要なときに情報を利用できること)
    • 否認防止(デジタル署名)
  • ワークファクター : 攻撃者が費やす労力
  • 鍵の強度は鍵空間のサイズに依存する。総当たり攻撃に対しては鍵を長くすることで対応する
  • ケルクホフス(kerckhoffs)の原理 : 鍵以外のすべてが公開されてもセキュアである
  • 古典暗号
    • 換字暗号 (Substituation) は、文字の写像
    • 転置暗号 (Transposition) は、文字の入れ替え
  • 対象鍵暗号
    • 3DES : 3DESは2個または3個の暗号鍵を使用する。1個だけだとDESと同等になる。使用は非推奨
      • DESは、64bitの暗号化鍵の内、56bitをキーマテリアル、残りの8bitを改ざん検知に使用する
    • AES : 現在最も使用されている共通鍵暗号。鍵長は、128bit, 192bit, 256bit に対応している
  • 非対称鍵暗号
    • RSA : 素因数分解問題を元にした公開鍵暗号
    • ECC : 離散対数問題を元にした公開鍵暗号
  • ステガノグラフィー : データに情報を隠すための技術。隠れチャネルの一部としても使用できる
    • 電子透かし(ウォーターマーク、Watermarks)は、そのデータの所有権を示すためのもの。形式は可視と不可視の両方がある

4-3. ハイブリッドシステムと公開鍵基盤 (PKI)

  • 公開鍵基盤
    • 認証局 (CA; Certificate Authority) : エンティティのデジタル証明書に署名し、その内容が証明書のオーナーを正確に表していることを証明する
    • 登録局 (RA; Registration Authority) : ユーザから署名を要求された証明書を受け取る際に、ユーザの識別情報を検証する
  • X.509証明書
    • X.509の規格は、ITU-Tの国際標準
  • 証明書の執行
    • 認証失効リスト (CRL; Certification Revocation List) : リストはブラウザ内で管理されており、定期的に認証局からCRLを取得する
      • CRLに含まれている証明書のシリアル番号と比較して検証する
      • 多くの一般的なブラウザはデフォルトではCRLをサポートしていない
    • OCSP (Online Certificate Status Protocol) : 証明書のステータスを確認するためのネットワークプロトコル
      • OSCPを受け取った認証局は「Good」「Revoked」「Unknown」のステータスを返す
      • OSCPは、完全にセキュアなプロトコルではなく、中間者攻撃に弱い
      • 認証局が要求を検証するのに時間がかかるため、ブラウザ側の処理に大幅な遅れが生じる
  • ハッシュ関数
    • MD5
    • SHA
    • 可変長ハッシュ (HAVAL; HAsh of VAriable Length)
    • RIPEMD
  • メッセージ完全性コントロール (MIC; Message Integrity Control)
    • 偶然による変化を検知する:
      • パリティ
      • ハッシュ関数
      • チェックサム
    • 意図的な変化を検知する:
      • デジタル署名
      • 鍵付きハッシュ(HMAC)
      • CBC-MAC

4-4. 暗号システムハイジーン:運用およびメンテナンス

  • サイバーハイジーン : セキュリティの衛生を保つこと(リスクが許容できるところまで抑えることができている状態を保つこと)

管理暗号

  • 暗号プロセスでは、組織独自の手順や手法を作ってはいけない
  • 一般的なガイドラインを参考にすること

鍵管理と鍵管理のプラクティス

  • 鍵管理は、鍵の生成、記録、コピー、配布、インストール、保管、変更、使用、鍵関連データの廃棄 に関わる全ての作業を含む
  • ケルクホフスの原理により鍵以外の全てが公開されているので、鍵管理はシステムをセキュアに保つための最も重要な活動である

鍵復旧 (Key Recovery)

  • 鍵復旧は、鍵の紛失や破損のときにのバックアップの仕組み
    • 鍵の預託 (key escrow)
    • 鍵の登録
    • デジタルウォレット

鍵の生成

  • 擬似乱数発生器によって生成した乱数は、シードやソルトなどの暗号変数に使われる
  • N人のユーザに必要な鍵の数は、
    • 対称鍵暗号では、N(N-1)/2
    • 非対称鍵暗号では、2N
  • RSA暗号の強度
    • 1024bitのRSA鍵は、80bitの対象鍵に相当する
    • 2048bitのRSA鍵は、112bitの対象鍵に相当する
    • 3072bitのRSA鍵は、128bitの対象鍵に相当する

鍵配布、鍵ラッピング、鍵暗号化鍵 (KEK; Key Encrypting Keys)

  • 共通鍵を安全に相手に配送するために使用する

鍵の保存と破棄

  • 全ての鍵は、改ざんから保護する必要がある
  • 秘密鍵は、不正な開示から保護する必要がある

アルゴリズム管理とプロトコル管理

  • 暗号の使用に関するポリシーが必要
  • 少なくとも以下の事項に対応すること
    • 暗号アルゴリズムと鍵サイズ
    • 危殆化したアルゴリズムや鍵の移行計画
    • 運用とメンテナンスのプロシージャ
    • どのデータにどの形式の暗号化が必要かを判断するための選択基準とプロセス
    • 鍵の生成、鍵の預託、安全な破棄の方法
    • 鍵やアルゴリズムの危殆化に関するインシデントレポート

セッション鍵:生成、使用、保護、破棄

  • セッション鍵を共有するためのプロトコル
    • Diffie-Hellman (DH)
    • Kerberized Internet Negotiation of Keys (KINK)
  • セッション鍵は、使用後に復元できないように破棄すること

国際輸出管理

  • 強力な暗号の機能を内蔵した製品の輸出は、安全保障上規制される場合がある

4-5. 暗号解読

  • 暗号文ベースの攻撃
    • 暗号文単独攻撃 (Ciphertext-only Attack)
    • 既知平文攻撃 (Known-plaintext Attack)
    • 選択平文攻撃 (Chosen-plaintext Attack)
    • 選択暗号文攻撃 (Chosen-ciphertext Attack)
    • 線形解読法 : ブロック暗号の振る舞いを推測するために線形近似戦略を用いた既知平文攻撃
    • 差分解読法 : 選択平文攻撃にわずかな変更を加え、生成される暗号文にもそれに対応するわずかな変化が現れるか確認する攻撃
  • 実装とアルゴリズムの攻撃
    • 総当たり攻撃 (Brute Force Attack)
    • Pass the Hash攻撃 : Active Directoryに対する攻撃で、パスワードの代わりにパスワードのNTLMハッシュやLMハッシュを使用して、リモートのサーバやサービスを認証する攻撃
    • 中間者攻撃 (Man-in-the-Middle Attack)
    • サイドチャネル攻撃 : 電力消費や漏洩などの実装の物理的属性を利用する受動的攻撃
      • 対策1 : ホワイトノイズ (アクティブなコントロール)
      • 対策2 : Faradayケージ (パッシブなコントロール)
    • フォールト分析攻撃 : システムを強制的にエラーにした時の結果と正常時の結果を比較して、有用な情報を取得する攻撃
    • プロービング攻撃 : 暗号化モジュール周辺の回路を監視して有用な情報を取得する攻撃
    • リプレイ攻撃 : 通信を再送することで妨害や損害を与える攻撃
    • 代数的攻撃 : ブロック暗号の数学的構造を利用する攻撃
    • レインボーテーブル : ハッシュ出力のルックアップテーブル
    • 頻度解析
    • バースデー攻撃
    • 素因数分解攻撃
    • 辞書攻撃 : よく使われる単語を基にした様々なパスワードの一覧を使った攻撃
    • 乱数生成器への攻撃
    • フォールトインジェクション (Fault Injection) : 暗号システムに既知の欠陥データを挿入したり送信したりして、実装に関する詳細を明らかにする攻撃
    • 一時ファイル : 暗号システムが計算を一時的に保存するためのファイルに侵害する攻撃


5. 通信とネットワークセキュリティ

5-1. OSIモデルとTCP/IPモデル

  • データの名称
    • 物理層では、信号やビットという
    • データリンク層では、フレームという
    • ネットワーク層では、パケットという
    • トランスポート層では、TCPではセグメント、UDPではデータグラムという
  • カプセル化 : OSIモデルで上の層から受け取ったデータに対してヘッダーを追加すること
  • 非カプセル化 : OSIモデルで下の層から受け取ったデータに対してヘッダーを削除すること
  • プロトコル : 儀式・やりとりのこと
  • インターネットワーキング : やりとりのこと
  • サイバーセキュリティ・キルチェーンの7フェーズ:
    • 偵察 : OSINT、スキャニング、ソーシャルエンジニアリングなど
    • 兵器化 : アクセス方法の選択、スクリプト化など
    • デリバリ : メール、USB、URLなど(対策 : 入口対策)
    • エクスプロイト(対策 : アンチマルウェア)
    • インストール(対策 : 構成管理)
    • コマンド&コントロール(対策 : 出口対策)
    • 目標の実行 : 情報漏洩や妨害・損害を与える

ネットワーク用語

  • レイテンシー : 送信元から宛先へのパケット配信にかかる時間
  • ジッター : 異なるパケットのレイテンシーの変動
  • 干渉 : パケットの内容を破壊する電気ノイズまたはその他の障害。パケットが移動中に壊れること

5-2. OSI第1層:物理層

ネットワークトポロジーの種類

  • バス型 : 利点はノードの追加が容易。欠点はバスが単一障害点となる
  • ツリー型 : 利点はノードの追加が容易。欠点はブランチで障害が発生したときにすべての従属ノードが動作しなくなる
  • リング型 : 利点は最大待ち時間を予想できる。欠点はリングが単一障害点となる
    • 光ファイバ分散データインターフェイス (FDDI) は反対方向にトラフィックが流れる2個のリングを使用するネットワーク
  • メッシュ型 : 利点は高い冗長性。欠点はコスト
  • スター型 : 利点はノードの追加が容易。欠点は中心の接続デバイスが単一障害点となる

ネットワークの種類

  • 有線ネットワークはバウンド (bound) ネットワーク。機器同士の接続には物理的な信号導体が必要
  • 無線ネットワークはアンバウンド (unbound) ネットワーク。ノード間のパスの長さは変化する

共通デバイス

  • アンプ : 増幅 (ノイズも大きくなる)
  • リピーター : 修復&増幅 (ノイズは消える)
  • リピータハブ : リピーターとハブの機能の組み合わせ
  • マルチプレクサ : 一本の回線で複数のやりとり
  • コンセントレータ : 回線を束ねる機械

インターネットアクセスのための通信

  • モデム : デジタルアナログコンバーター (D/A Converter)
  • デジタル加入者線 (DSL)
  • Wi-Fi:
    • 802.11b : 2.4GHz : 11Mbps
    • 802.11g : 2.4GHz : 54Mbps
    • 802.11a : 5GHz : 54Mbps
    • 802.11n : 2.4GHz/5GHz : 600Mbps (Wi-Fi 4)
    • 802.11ac : 5GHz : 6.9Gbps (Wi-Fi 5)
    • 802.11ax : 2.4GHz/5GHz : 9.6Gbps (Wi-Fi 6)
  • 第N世代移動通信システム:
    • 2G : CDMA, GSM, IDEN
    • 3G : EDGE, DECT, UTMS
    • 4G : WiMAX, LTE, IEEE 802.20モバイルブロードバンド
  • ワイヤレス攻撃:
    • ブルージャッキング : 匿名メッセージをBluetooth経由で端末に送る攻撃
    • ブルースナーフィング : Bluetooth端末にある情報を本人に気づかれずにアドレス帳などにアクセスする攻撃

5-3. OSI第2層:データリンク層

  • すべてのデバイスは、メディアアクセスコントロール (MACアドレス) と呼ばれる固有のアドレスを持つ
  • デバイスは、NICの数だけMACアドレスが存在する
    • スマホの場合、Wi-Fi側のMACアドレスとBluetooth側のMACアドレスの2つがある
  • 00:00:00:00:00:00 : 前半の3つがメーカ番号、後半の3つがデバイス番号
  • 重複するときのために、MACアドレスは書き換えが可能(なりすましも可能)

プロトコル

  • ARP : IPアドレスからMACアドレスに変換する
  • DHCP
  • パケット衝突検知・回避(競合ベースプロトコル)
    • CSMA/CD (搬送波感知多重アクセス/衝突検出) : Ethernetなどの有線で使用する
    • CSMA/CA (搬送波感知多重アクセス/衝突回避) : Wi-Fiなどの無線で使用する

脅威と対策

  • 各層における攻撃は、基本的に以下の4種類:
    • スプーフィング(なりすまし)
    • クローニング(複製)
    • フラッディング(大量送信)
    • スニッフィング(盗聴)
  • 脅威:
    • MACアドレスのスプーフィング : MACアドレスのなりすまし
    • MACフラッディング : 偽のMACソースアドレスを持つイーサネットフレームを大量に送信する攻撃
    • VLANホッピング (802.1Q攻撃) : 通常はアクセスできない他のVLAN上のトラフィックにアクセスすること
    • ブロードキャストストーム : ネットワークセグメントを過負荷にする攻撃

5-4. OSI第3層:ネットワーク層

送信の形態(伝送モード)

  • ユニキャスト : 1対1 (one-to-one)
  • ブロードキャスト : 1対全体 (one-to-many)
  • マルチキャスト : 1対グループ (one-to-many-of-many)
  • エニーキャスト : 1対グループの1人 (one-to-one-of-many)

プロトコル

  • IPv4, IPv6
  • IPv4のプライベートアドレス (RFC 1918)
    • クラスA : 10.0.0.0~10.255.255.255 (ネットワークマスク : 255.0.0.0)
    • クラスB : 172.16.0.0~172.31.255.255 (ネットワークマスク : 255.255.0.0)
    • クラスC : 192.168.0.0~192.168.255.255 (ネットワークマスク : 255.255.255.0)
  • IPv4のループバックアドレス : 127.0.0.1
  • APIPAアドレス : 169.254.0.0~169.254.255.255 (IPアドレスの割り当てがない場合に、自分のIPアドレスを自動で割り当てるときに使用するIPアドレス)
  • ゲートウェイ (gateway) : コンピュータネットワークをプロトコルの異なるネットワークと接続するためのネットワークノード。IPv4とIPv6の変換に使用する
  • ディスタンスベクタープロトコル : ホップ数を基準にして最短経路を求める。RIPなど
  • パスベクタープロトコル : 動的に更新されるパス情報を保持する。BGPなど
  • リンクステートプロトコル : パスベクタープロトコルの強化版。接続速度、リンクの混雑状況、rinkの可用性、総ホップ数からもっとも最適なパスを決定する。OSPFなど
  • ICMP (インターネット制御メッセージプロトコル) : pingなど
  • IGMP (インターネットグループ管理プロトコル) : マルチキャストに使用する
  • NAT (ネットワークアドレス変換)
  • PAT (ポートアドレス変換)

マルチプロトコルラベルスイッチング (MPLS)

  • MPLS (Multi Protocol Label Switching) は、ネットワークアドレスの代わりにパスラベルを使用する技術
  • MPLSは、OSIモデルの第2層と第3層の両方で動作するリンクステートルーティングプロトコル
  • MPLSは、ATMやDSLなどのプロトコルを処理する
  • MPLSは、ルーティングテーブルの計算を減らし、WANの効率化を目的とした広域ネットワークプロトコルの作成に役立つ

脅威と対策

  • ファイアウォール : IPとPortまたはMACアドレスで通信制限をする
  • 脅威:
    • ルーティング攻撃 : ルーティングを変える攻撃
    • ICMP攻撃 : ICMPパケットを大量に送信する攻撃 (c.f. ICMPフラッド攻撃、Pingフラッド攻撃)
    • SYNフラッド攻撃
    • Smarf攻撃 : IPアドレスを送信元アドレスをなりすましたICMPパケット (Ping) を大量に送信する攻撃
    • Land攻撃 : 送信元と宛先に同じIPアドレスを設定して送信する攻撃
    • IPアドレススプーフィング
    • パケットスニッフィング

5-5. OSI第4層:トランスポート層

プロトコル

  • TCP
  • UDP
  • ポート
    • Well-knownポート : 0~1023
    • Registeredポート : 1024~49151
    • Dynamicポート または Privateポート : 49152~65535

脅威と対策

  • 多くのファイアウォールには、保護対象のシステムに代わってSYNに応答する対SYNフラッド防御機能が組み込まれている
  • 脅威
    • フラグル (Fraggle) 攻撃 : 送信元が偽のUDPを大量に送信する攻撃
    • Teardrop攻撃 : IPパケットを断片化して送信する (~= Slowloris攻撃)
  • 次世代ファイアウォール : IAMや属性ベースのアクセスコントロールも含まれている
    • IPとPortだけではフィルタリングできないから

5-6. OSI第5層:セッション層

認証プロトコル

  • PAP (Password Authentication Protocol) : 平文パスワードによる認証プロトコル
  • CHAP (Challenge-Handshake Authentication Protocol) : チャレンジレスポンスによる認証プロトコル
  • EAP (Extensible Authentication Protocol) : PKIを使用する拡張認証プロトコル。通常は暗号化されない
    • 事前共有鍵 (EAP-PSK) または TLS (EAP-TLS) を使用して暗号化を行う。Wi-Fiで使用される
  • PEAP (Protected Extensible Authentication Protocol) : EAP-TLSに類似している保護された拡張認証プロトコル
    • EAPメソッド暗号化機能と認証機能を提供する
  • LEAP (EAP Cisco Wireless Light Extensible Authentication Protocol) : Cisco版のEAP。WEPで使用される。保護機能に脆弱性があり危険

5-7. OSI第6層:プレゼンテーション層

  • 変換サービス (ASCII, Unicodeなど)
  • 圧縮サービス (MP3, WAVEなど)
  • 暗号化サービス (S/MIMEなど)

5-8. OSI第7層:アプリケーション層

プロトコル

  • FTP : 20,21/tcp
  • SSH, SCP : 22/tcp
  • Telnet : 23/tcp
  • DNS : 53/udp, 53/tcp
  • HTTP : 80/tcp
  • HTTPS : 443/tcp
  • Kerberos : 88/udp
  • SNMP : 161/udp, 162/udp
  • LDAP : 389/tcp
  • LDAPS : 636/tcp
  • Windows SMB : 445/tcp
  • syslog : 514/udp, 6514/tcp
  • MSSQL : 1433/tcp
  • RDP : 3389/tcp
  • LPR (Line Printer), LPD (Line Printer Daemon) : 515/tcp, 9100/tcp

5-9. ネットワークアーキテクチャにおけるセキュアな設計原則

  • セキュリティアーキテクチャを技術設計に適用すると、システム性能とセキュリティ機能のトレードオフが発生する
  • ネットフローデータは、すべてのネットワーク通信の送信元、宛先、サイズなどの情報を含むデータ

セキュアプロトコル

  • レガシーなプロトコル (Telnet, FTP, finger)
  • セキュアプロトコル
    • IPsec
      • 認証ヘッダ (AH) : 転送データが改ざんされていないことを保証する
      • カプセル化セキュリティペイロード (ESP) : IPパケットを暗号化する
      • セキュリティアソシエーション : エンドポイントが相手と通信する際に使用するメカニズムを決める。AHとESPのどちらのプロトコルを使用するか、どの暗号化と認証のアルゴリズムを使用するかを決める
      • エンドポイントは、以下のどちらかのモードで通信する:
        • トランスポートモード : IPペイロードを保護するが、IPヘッダは保護しない
        • トンネルモード : IPペイロードとIPヘッダが保護され、トンネルを経由するために新しいIPヘッダが追加される。VPNなどで使用される
      • インターネット鍵交換 : AHやESPで暗号化する際に、両者が対象鍵を交換するためのプロトコル (DHなど)

マルチレイヤプロトコル (MLP)

  • プロトコルの組み合わせによって、TCP/IPがアプリケーションに必要なサービス品質を提供できなくなる
  • 例 : TLSを採用しないとデータの機密性と真正性を保護できない
  • マルチレイヤープロトコルによるセキュリティ懸念事項:
    • 隠れチャネルが隠ぺいされること(上位層で暗号化することで下位層での検知を回避する)
    • 隠蔽されたトラフィックがフィルタをバイパスできること(HTTPSがIPSを回避するなど)
    • ネットワークセグメントに設定した論理的な境界を一定の条件下でバイパスできること

コンバージドプロトコル

  • コンバージドプロトコルは、TCP/IPなどの標準的なプロトコルと、独自のプロトコルやその他の非標準なプロトコルを組み合わせること
  • FCoE (Fiber Channel over Ethernet) は、イーサネット上でファイバーチャネル通信を実現するコンバージドプロトコル

ソフトウェア定義ネットワーク (SDN)

  • SDN (Software Defined Network) は、インフラをデバイスやハードウェアから仮想化する技術
  • SDNは、レジリエンス(耐障害性)に対するビジネス要件をより容易に満たすことができる
  • SDNの3つのプレーンや階層
    • アプリケーションプレーン : ビジネスアプリケーションへのAPIを提供する
    • コントロールプレーン : ネットワーク機能やプログラマビリティの制御をする
    • データプレーン : スイッチやルータなどのインフラを含む
  • コントロールプレーンから見てアプリケーションプレーン側へのデータフローを北向き (North bound) という
  • コントロールプレーンから見てデータプレーン側へのデータフローを南向き (South bound) という

ソフトウェア定義広域通信網 (SD-WAN)

  • WANアーキテクチャをサポートするSDN

SDNとセキュリティ

  • データ、コントロール、アプリケーションの各プレーンで一貫したポリシーとプロシージャを適用すること
  • クラウドホスト型のSD-WANは、バックアップとリストアの機能などがあり、レジリエンスが強化されている

コンテンツ配信ネットワーク (CDN)

  • CDNは、インターネット上の複数のデータセンターに実装される大規模な分散型サーバシステム
  • CDNは、エンドユーザに高可用性と高パフォーマンスでコンテンツを提供することを目的とする
  • CDNは、オリジンサーバとエッジサーバの2種類で構成される
    • オリジンサーバ : オリジナルのデータを持つ
    • エッジサーバ : キャッシュデータを持つ

「ゼロトラスト」vs.「Trust, but Verify」

  • Trust, but Verify では、ネットワークに接続されるユーザ・プロセス・デバイスを認証・認可するプロセスに依存する
  • 複数のセグメントに分け、境界装置を通過するときに認証を必須にする
    • 要塞サーバ (Bastion Server) : 高いセキュリティを持つサーバ。インフラ領域のサーバへのSSH接続を提供する踏み台サーバなどとして使う
    • エッジサーバ : CDNで使用され、高可用性を提供する
  • ゼロトラストでは、全てのプロセスやアクセスが認証・認可される

5-10. セキュアなネットワークコンポーネント

  • ハードウェアとソフトウェアは、そのライフタイムを通じて継続的にセキュリティを確保する必要がある

ハードウェアの操作

  • ルートオブトラスト (RoT) : トラストアンカーに依存することで、後続のアクションで作られたシステムはセキュアな状態であることを保証する
    • ハードウェアやOSのセットアップにおける考え方
    • トラストアンカーは、不変の信頼できるハードウェアコンポーネント
  • 権限の層は、トラストアンカー > カーネルモード > ユーザモード の順番で弱くなる
  • ハードウェアに搭載された TPM チップに焼き付けられた暗号鍵を用いて、BIOSなどの有効性を保証し、管理する

ネットワークアクセス制御 (NAC) デバイス

  • NAC (Network Access Control) は、ネットワークに参加を希望するデバイスが、ポリシーの要件を満たしているときのみ接続できる仕組み
  • NACは、アクセスセキュリティに必要なネットワークの可視化を提供するため、インシデントレスポンスの調査にも使用される

802.1X NAC

  • 802.1X は、ポートベースのネットワークアクセスコントロール (PNAC) プロトコルで、LANやWLANに接続を試みる機器の認証制御を行う
  • 3つのコンポーネントで構成される:
    • サプリカント(ユーザの端末)
    • オーセンティケータ(スイッチやアクセスポイント)
    • 認証サーバ

エンドポイントのセキュリティ

  • エンドポイントセキュリティのソリューションの主要な機能:
    • ベースラインの確立を含む、アイデンティティ管理と制御
    • アップデートやパッチの提供を含む、構成管理と制御
    • デバイスの健全性と状態の確認によるアクセス制御(または最初にアップデートをするように強制する)
    • 特権的アクセスを持つデバイスの振る舞いのモデリング
    • デバイスの紛失などに備えて、特定の状況下でデバイスからデータを強制的に消去できる財産管理と物理セキュリティ
    • デバイスへのリモート管理とポリシーの執行・更新・確保
    • デバイスのジオロケーション(位置情報)
  • エンドポイントセキュリティを導入して、エンドポイントで取得される膨大なデータ (ログ) を扱えるようにすること

NACフレームワーク

  • 有名なスタンダード:
    • Cisco の CNAC (Cisco Network Access Control)
    • Microsoft の NAP (Network Access Protection) イニシアティブ
    • TNC (Trusted Computing Group)

NACのベストプラクティス

  • 組織のリモートアクセスポリシーの作成と評価から始まる
    • ネットワークアクセスの範囲
    • ゲストユーザの要件
    • モバイルデバイス管理 (MDM) ポリシー

ベースライン

  • ネットワークのベースラインは、ネットワーク上で誰が何をしているかを把握する
  • 新しいデバイスが組織のネットワークに接続しようとすると、アラートによって管理者に通知する

監査

  • NACデバイスによって生成されるアラートは、組織の監査ポリシーやプロセスに含める必要がある
  • 監査機能には、リアルタイムのレポートと過去のデータが含まれる
  • レポートをもとに、組織の防御ポスチャ(健全性)を評価する

ポートアドレス変換 (PAT)

  • PAT (Port Address Translation) は、あらゆるアドレスを1個のIPアドレスに変換するNATの拡張版

プロキシ型ファイアウォール

  • プロキシ型ファイアウォールは、内部ホストと外部ホストの直接通信を防止する
  • 外部の信頼できないサーバから、内部クライアントを隠すことができる

プロキシの種類

  • サーキットレベル (回路レベル; 低いレイヤー) のプロキシは、通信のオーバーヘッドは少ないが、悪意のあるコンテンツは検出できない
  • アプリケーションレベルのプロキシは、通信に含まれる悪意のあるコンテンツを検出できるが、通信のオーバーヘッドは増加する

5-11. 設計に基づくセキュアな通信チャネルの導入

  • 通信には、セキュアな通信インフラが必要
  • VoIP:
    • 音声をすべてデータパケットに変換して送信するプロトコル
    • SIP (Session Initiation Protocol) : マルチメディア接続を管理するためのプロトコル。MD5によるダイジェスト認証と完全性保護を提供する
  • Wi-Fi:
    • IEEE 802.11 スタンダードに準拠した無線ネットワーク通信
    • LEAP方式では、認証が成立するとクライアント固有のWEPキーが発行される
    • WPA2 PSKでは、パスワードを共有しても悪意のある人によってデータ収集はできない
    • WPA2は、複数のSSIDを提供することができる
    • TKIP (Temporal Key Integrity Protocol) は、Wi-FiのWPAで採用された暗号化プロトコル
      • 暗号化アルゴリズムにRC4を用い、一定の送受信回数ごとに切り替わる一時鍵や、MACアドレスを暗号キーに加える
      • WEPの重大なセキュリティ問題を修正するために、TKIPが使用された
      • 現在ではTKIPの代わりに、CCMP (Counter mode with CBC-MAC Protocol) 暗号化プロトコルを使用している
    • 無線通信する際の規格 : WEP, WPA, WPA2
    • 無線通信の暗号化方式 : TKIP (RC4), CCMP (AES)
    • Evil Twin (エビルツイン, 悪魔の双子) 攻撃があるため、信頼できる公衆Wi-Fiスポットは存在しない
      • 公衆Wi-Fiスポットを使用する場合は、常にVPNを使用すること
    • 端末間の通信:
      • アドホックモード (Ad hoc mode) : 各端末の無線LANアダプタが、1対1で互いに直接通信する
      • インフラストラクチャーモード (Infrastructure mode) : アクセスポイントを介して端末間の通信を行う
  • Bluetooth:
    • P2Pのワイヤレス伝送を提供する技術
    • 利点は、省電力で多くのデバイスが対応していること
    • 欠点は、2.4GHzを使用するので、Wi-Fiの802.11bや802.11gと干渉すること
    • 強力な暗号化機能を持っていない

ワイヤレスアクセスポイント (WAP) のセキュリティ

  • DHCPは、アクセスポイントに接続する前の認証の役割を果たす

キャプティブ・ポータルの利用

  • キャプティブポータルは、公共の場で使用される無線ネットワークの認証セーフガード
  • キャプティブポータルは、新しく接続されたデバイスを強制的にWebページにアクセスさせ、認証されたアクセスを確立するためのもの
    • デバイスフィンガープリンティングは、OS、バージョン、ソフトウェア情報、システムを一意に識別できるデータを収集すること
  • キャプティブポータルは、プライバシーポリシーや利用規約を公開するためにも利用できる

ワイヤレス攻撃

  • ワイヤレス攻撃への対策は、物理的・管理的・技術的なものがある:
    • 定期的な無線周波数 (RF) のサイト調査を行い、不正なアクセスポイントを探す
    • キャプティブポータルを利用して、接続を許可する前にデバイスの健全性を検証する
    • パッシブスキャンは、不正なデバイスの特定に役立つ
    • アクティブスキャンは、IDSやIPSシステムのテストに役立つ

リモートアクセス

  • 社外からシステムに接続するための認証・認可方法を提供すること
  • セキュリティ上の課題:
    • 人の問題 : 不注意による開示や取り扱いのポリシーに違反することで、機密情報を公開してしまう
    • ネットワークと通信の脆弱性 : プロトコルスタックのすべての層に対する様々な攻撃
    • 脅威アクターからの関心 : 価値の高いシステムとして脅威アクターからの関心が集まる
    • 実装上の問題 : リモートアクセスを導入してセキュリティを確保することは、技術的に非常な困難な場合がある

仮想プライベートネットワーク (VPN)

  • VPNは、プライベートネットワークを公衆ネットワーク上で拡張するポイント間接続
  • VPNのトンネリングによって、エンドポイントはネットワークに直接接続しているように見える

PPTP (ポイントツーポイントトンネリングプロトコル)

  • PPTPは、GRE (ジェネリックルーティングカプセル化) によってエンドポイント間のトンネルを構築するレガシーなプロトコル
  • PPTPは、PPPパケットをカプセル化して送信する
    • PPPは、ダイヤルアップ接続を目的として、モデム、ISDN、フレームリレーなどで使用される
  • PPTPは、PPPを基盤として、PAP, CHAP, EAP などで認証する
    • ユーザ名とハッシュ化されたパスワードを送信する可能性がある

L2TP (レイヤ2トンネリングプロトコル)

  • L2TPは、レイヤ2フォワーディング(L2F)機能とPPTPを組みあわせたプロトコル
  • L2TPは、IPsecを使用してトラフィックを暗号化する(L2TP VPN)
  • PPTPは、PPPを基盤として、PAP, CHAP, EAP または IPsecで認証する
  • L2でトンネリングするため、非IPプロトコルの通信にも対応できる

SSLとTLSを用いた仮想プライベートネットワーク (VPN)

  • SSL-VPNは、Webブラウザを使用してリモートアクセスする

遠隔勤務

  • 以下の事項を考慮する必要がある:
    • ユーザは、VPNなどセキュアな接続を確立できるソフトウェアに関するトレーニングを受けているか
    • ユーザは、貴重な情報の種類を理解しているか
    • ユーザの物理的な所在地は、作業内容の種類に適した安全性が確保されているか
    • 他に誰がアクセスしているか

スクリーンスクレーパー

  • スクリーンスクレーパーは、人間用にデザインされたディスプレイ出力からデータを抽出するプログラム
  • スクリーンスクレーパーは、PCに表示されている内容をリモートコンピュータにコピーするツール
  • スクリーンスクレーパーによって、銀行取引サイトの暗証番号入力画面などが収集される可能性がある

マルチメディアコラボレーション

  • マルチメディアコラボレーション(音声通話やビデオ通話)では、様々な技術やプロトコルが使用されている
  • 以下基本的なメカニズム:
    • P2Pアプリケーション
      • 制御されていないチャネルを開けて、保護されているネットワークに侵入する手段になり得る
      • P2Pボットネットを制御する「ボットハーダ(bot herder)」は、マスターノードをシャットダウンしても、スレーブノードの1つがマスタノードになることで、ボットネット操作を継続する
    • インスタントメッセージ
      • チャット以外にも、画面共有、リモート制御、ファイル交換、音声ビデオ通話などの追加機能を提供する

回線の仮想化

  • 回線の仮想化によって、専門回線のような接続を、高帯域幅、マルチユーザケーブル、ファイバ上のエンドポイント間接続で実現する

ネットワーク機能仮想化 (NFV)

  • NFVは、ファイアウォールの管理、侵入検知、NAT、名前解決などの機能を、ソフトウェアとして提供する技術
  • NFVは、仮想ネットワークとも呼ばれる

サードパーティとの接続性

  • 業務の効率化を図るために、第三者の接続サービスを利用したり、第三者が自社のインフラに直接接続できるようにすることがある


6.ソフトウェア開発セキュリティ

6-1. 多くのソフトウェアシステムがセキュアでない利用

リングとOSI7層モデル

  • リングモデルやOSI7層モデルの各層は下の層に依存するため、下の層に脆弱性がある場合は、その脆弱性を継承してしまう

アーキテクチャと脅威モデリングプロセスレビュー

  • 脅威モデル : 攻撃者が使用する脆弱性の種類(カテゴリー)をまとめたもの
  • 設計およびコーディングの欠陥数とその他の欠陥の重大度を低減するためのもの
  • 一般的なモデルとしてSTRIDEがある
    • Spoofing (なりすまし)
    • Tampering (改ざん)
    • Repudiation (否認防止)
    • Information disclosure (情報漏洩)
    • Denial of Service (サービス妨害)
    • Elevation of Privilege (権限昇格)

実行可能なコンテンツとモバイルコード

  • 実行可能なコンテンツは、モバイルコードとも呼ばれる
    • 外部からダウンロードして実行する
    • Javaアプレット、ActiveX、フラッシュなどがある
    • HTML5にすることで対策できる

ソフトウェアの構築と使用のサイクル全体に存在する脆弱性

  • 以下のフェーズを通して、ソフトウェアの脆弱性が埋め込まれる
    • ソフトウェアの設計
    • コーディング
    • テスト
    • デプロイ
    • 使用する人間によるエラー

ソフトウェア環境のセキュリティ

  • ソフトウェア環境は、システムやアプリの作成、使用、変更、破棄に影響するすべての要素、活動、情報、人、システムを指す
  • 商用オフザシェルフ (COTS; Commercial Off-The-Shelf) は、市販されている既製品のこと
  • 商用オフザシェルフとして販売されているソフトウェアの場合は、市場全体がソフトウェア環境となる
  • システムライフサイクルモデルでは、時間的に異なる3つの視点が、ソフトウェア環境を複雑にしている:
    • システムの設計と開発 : 自分で悪用可能な脆弱性をシステムに追加してしまうため
    • 運用時の使用 : 脅威サーフェスが最大になるため
    • システムのリプレイスやリタイヤ : システム自体が拡張していくため

開発期間 vs. エラーの影響

  • 「素早いソフトウェア機能の変更」と「セキュリティ対策」はトレードオフ

ウォーターフォール型ソフトウェアライフサイクル開発 (SDLC) モデル

  • 従来のソフトウェア開発手法
  • 次の順番でフェーズが進む : ニーズの特定 > 要件定義 > システム設計 > コーディング > ユニットテスト > システムテスト > 統合テスト > 受入テスト > デプロイ

ステージごとのビジネスインパクト vs. 変更するためのコスト

  • エラーを発見して修正するのが遅いほど、全体的なコストや影響が大きくなる
  • アイデアからコードへ直接進むことが最も安価だが、リスクの少ないアプローチではない
    • アジャイルは、多くの実用的なソフトウェアを迅速に提供するが、必ずしも高い品質や安全性を提供するわけではない

どの程度の性能・安全性であれば十分か

  • ソフトウェアのセキュリティと安全性をどれだけ早い段階で組み込めるかが重要

古典的だが根強いソフトウェア設計とコーディングのエラー

  • 安全でないコーディングパターンを特定するチェックリストを用いた、様々なソースコード検査技術が開発された
  • 入力されたデータが許容範囲外や不完全、不正確であると、システムが異常な動作をする

良いプラクティスの存在

  • より効果的なプログラミング言語と統合開発環境によって、ソフトウェアエラーのリスクを大幅に減らすことができる

データを中心とした脆弱性の制御

  • データ中心の脅威モデリングは、データの移動・配置・実行・入力・出力に焦点を当てた方法論とフレームワークを確立する

内臓のセキュリティは管理可能で到達可能

  • 設計者が強力で効果的な制御ロジックを構築できていないと、安全ではなくなる
  • 失敗の原因は、ソフトウェアプロセス内の制御の流れや外界とのインターフェイスに十分な注意を払っていないため

6-2. ソースコードレベルでのセキュリティの脆弱性

ソフトウェアの設計と作成概要

  • 機能要件 : システムが実行しなければならないタスクやプロセスを記述したもの
  • 非機能要件 : システム全体の大まかな特徴を示すもの。安全性、セキュリティ、プライバシー、レジリエンスなど

ソースと実行可能コードの比較

  • ソースコード : ある設計を実現するための人間が読める形で書かれた一連の記述
  • 実行コード (オブジェクトコード) : ハードウェアを直接実行する機械語命令セットのバイナリ
  • 中間コード : ソースコードと実行コードの中間にあるコード。移植性を高めるために使う
  • 任意コード : 攻撃者がシステムの意図に反して実行するコード(任意コード実行)

プログラミング言語

  • 低時言語 : アセンブリ言語など
  • 高次言語 : C言語など
  • 概念
    • データタイプエンフォースメント : 異なるタイプのデータに対する操作を拒否すること
    • データ保護データ隠蔽 : データの読み取りや変更を制限・防止すること (カプセル化)
    • コードプロテクションロジック隠蔽 : あるソフトウェアが別のソフトウェアのソースコード・中間コード・実行コードを読み取ったり変更したりするのを防止すること (抽象化)

ソースコードから実行可能なプログラムまで

  • アセンブリ : 1つのステートメントを1つのインストラクションに変換する
  • コンパイラ : 1つのステートメントを複数の命令に分割する
  • インタープリター : 1つのステートメントを多くの中間オペコードに変換する

プログラミング言語の世代

  • ジェネレーション1 : 機械語、オペコード、オブジェクトコード
  • ジェネレーション2 : アセンブリ言語
  • ジェネレーション3 : 高次言語。C言語やJavaなど
  • ジェネレーション4 : 超高級言語。スクリプト言語やGUIで作成するもの(コードレス・プログラミング)など。レポートジェネレータやアプリケーションジェネレータなど
  • ジェネレーション5 : 自然言語インターフェース。制約ベースのプログラミング言語や論理プログラミング言語とも呼ばれる

オブジェクト指向テクノロジーとプログラミング

  • オブジェクト指向プログラミング (OOP) は、オブジェクトを中心としたプログラミング
  • 特徴:
    • カプセル化 : コードが誤って他のデータにアクセスできなくする。データ隠蔽とも呼ばれる
    • 継承 : スーパークラスの特徴を共有するサブクラスを定義する
    • ポリモーフィズム : 同じメソッド名と異なる処理をする
    • 異なるデータタイプ : データタイプに応じて異なる処理ができる

ポリインスタンス化

  • 同じ情報を異なるバージョン毎にインスタンス化すること
  • 分類レベル毎にオブジェクトを分けることで、推論攻撃を防ぐことができる

オブジェクト指向セキュリティ

  • カプセル化によって、機密性の高いデータと信頼できるメソッドを結びつけることができる

分散オブジェクト指向システム

  • 各コンポーネントは相互に通信でき、プログラムはコンポーネントを呼び出すことができる
  • 分散オブジェクト指向システムによって、アプリケーションはリモートマシンからローカルホストにコードをダウンロードできる
  • RMI (Java Remote Method Invocation) や DCOM (Distributed Component Object Model) など

CORBA (Common Object Request Broker Architecture)

  • CORBAは、ネットワーク上の異なるマシンに存在する製品間の相互運用性のニーズに対応する一連のスタンダード
  • CORBAを使用すると、アプリケーションはリモートのコンポーネントと相互に通信することができる

スタンダードライブラリ、その他のライブラリ、およびソフトウェアの再利用

  • OSとハードウェアのライブラリ : ベンダによって提供され、デジタル署名されたアップデートが提供される
  • プログラミング言語のライブラリ、社内の独自ライブラリ、信頼できるオープンソースのライブラリ
  • 開発フレームワーク : Microsoftの .NET など
  • サードパーティのオープンソースのライブラリ : バックドアやコーディングエラーなどの追加の検査が必要

悪用可能なソフトウェアソースコードのよくあるエラー

  • バッファオーバーフロー
  • 不正な形式の入力攻撃
  • 不完全なパラメータチェック
  • 実行可能なコンテンツとモバイルコード : リモートから入手した実行コードは安全か
  • メモリやオブジェクトの再利用 : メモリリークやデータ残留

隠れチャネル

  • 隠れチャネル(隠れ経路)は、セキュリティポリシーに違反する方法で情報を転送するもの
  • 隠れストレージチャネル (CSC; Covert Storage Channels) は、2つのサブジェクトがストレージを共有すること
    • プロセスがストレージを読み書きし、別のプロセスが同じストレージを使用すること
    • 情報漏洩の流れの一部として使用される
  • 隠れタイミングチャネル (CTC; Covert Timing Channel) は、動作タイミングを変化させることで観測しているプロセスに情報を伝達すること
    • レスポンスの時間差などで相手に情報を伝えるなど

その他の一般的なソフトウェアの攻撃ベクトル

  • ソーシャルエンジニアリング : 詐欺行為や脅迫、説得などで情報を得る攻撃
  • TOC/TOU (Time of Check vs. Time of Use) : 変数の内容をチェックしたときと、変数の内容を使用するまでの間に、変数の内容を改ざんすること
  • レースコンディション (競合状態) : DoS攻撃の一種。テスト環境と実稼働環境に差分があると問題が見えなくなるおそれがある
  • 未利用時間における攻撃 (Between-the-lines attack) : 通信回線への侵入によるデータの不正挿入
  • トラップドア、バックドア : 対策としては、デプロイ前にデバッグ機能を除去すること

6-3. データベースがセキュアでない理由

データベースとデータウェアハウスアーキテクチャに対する脅威

  • 集約 : 非機密情報を組み合わせて機密情報を作成すること。単一の情報源を利用する
  • 推論 : 集約で組み合わせた情報から機密情報を推測すること。多数の情報源を利用する
  • バイパス攻撃 : DBアプリケーションのフロントエンドのコントロールを迂回して情報にアクセスすること
  • アクセス制限に使用されるデータベースビューの不正使用 : ビューはユーザが閲覧できるデータを制限する
  • 同等ではない大体のアクセスルートの利用 : MVCモデルで意図しないViewからのアクセス
  • データ汚染 : 不正な形式を入力すること
  • デッドロック : 2つのプロセスがお互いがロックしているリソースを要求して処理が停止すること
  • サービス妨害 (DoS)
  • 情報の不適切な変更 : ユーザが故意または誤って情報を変更すること
  • データの傍受 : DBへのリモートアクセスが許可されていると、転送中データの傍受や改ざんが可能
  • クエリ攻撃 : 不正な形式のクエリで問い合わせること
  • サーバへの物理的または直接的な論理的アクセス
  • TOCTOU : 問い合わせクエリが承認されてからデータが表示されるまでの間にデータを変更すること
  • Webベースの攻撃
  • 不正アクセス
  • ロストアップデート : 別のトランザクションによって値が上書きされてしまうこと
  • ダーティリード : まだコミットされていない情報を読み込んでしまうこと

データベースとデータウェアハウス環境

  • データウェアハウス : 分析のためにデータを1つの大きなシステムに集めるもの
  • データレイク : データウェアハウスの一般的な形式や構造になっていないデータ
  • 代表データの抽出方法:
    • サンプリング : 統計的手法を用いてデータ集合全体を代表するサンプルを選択する。人間によるバイアスを回避するためにも使用する
    • クリッピング : 事前に定義した閾値を超えるレコードのみを選択する

データベース管理システム (DMBS) アーキテクチャ

  • データベース管理システム (DBMS) は、データの作成、保存、検索、更新、削除を行う

データベースモデル

  • データベースモデルは、以下の要件を満たす必要がある:
    • トランザクションの永続化
    • フォールトトレランスと復旧
    • 複数ユーザでの共有
    • セキュリティコントロール : 機密性、完全性、可用性、アクセス制御、完全性チェック、ビューの定義
  • ACID特性:
    • 原子性 (Atomicity) : トランザクションはすべてコミットされるか、すべてロールバックされる
    • 一貫性 (Consistency) : トランザクションは完全性制約を満たすときのみ許可される
    • 独立性 (Isolation) : トランザクションが終了するまで、その結果は他のユーザから見えないようにする
    • 永続性 (Durability) : トランザクションが終了したときの結果は、システムやメディアの障害に耐えられる(一度完了したら取り消すことができない)

モデルの種類

  • 階層型データベース管理モデル
  • ネットワークデータベース管理モデル
  • リレーショナルデータベース管理モデル (RDMS)

リレーショナルデータベースモデル

  • リレーショナルモデルの要素:
    • テーブルまたはリレーショナルと呼ばれるデータ構造
    • テーブルにおける許容される値と値の組み合わせに関する完全性ルール
    • リレーショナルのデータ操作エージェントと割り当てオペレータ

オブジェクト指向データベースモデル

  • データをオブジェクトとして保存するモデル。O/Rマッパー

異なるデータベースモデルにおけるデータ完全性の実現

  • データ完全性は、DBMSレベルとユーザレベル(トランザクション)の2つのレベルで必要

データベースインターフェイス言語

  • SQL (Structured Query Language) を使ってデータにアクセスする

構造化クエリ言語 (SQL)

  • スキーマ : テーブルのアクセス制御を含むデータベースの構造を説明する
  • テーブル : データの列と行を持つ
  • ビュー : 各テーブルを結合してユーザがアクセス可能なデータのみを表示する
  • データ定義言語 (DDL; Data Definition Languaage) : データベースや、テーブル、ビューなどを作成する
  • データ操作言語 (DML; Data Manipulation Language) : データの照会や挿入、削除、更新などをする
  • データ制御言語 (DCL; Data Control Language) : 管理者がデータへのアクセスを確立・制御する

マークアップ言語とデータベース

  • データベース接続技術の中では、マークアップ言語が使用される場合もある

アプリとデータベース接続

  • プログラムからデータベースに接続する
  • インターフェイス技術 (APIなど) を適切に利用することで、より強力なセキュリティと制御や、データ接続サービスの強化が可能になる

拡張マークアップ言語 (XML)

  • XML (Extensible Markup Language) : メタデータの定義に使用される

オープンデータベースコネクティビティ (ODBC)

  • ODBCは、標準化されたデータアクセスの手段 (ODBC APIなど)

Java Database Connectivity (JDBC)

  • Sun Microsystemsが開発したアプリケーションがデータベースに接続するための技術
  • JavaプログラムがDBへ接続するためのAPI (ドライバ) を提供する

オブジェクト連携とデータベース埋め込み (OLE DB)

  • OLE (Ojbect Linking and Embedding) は、ExcelのシートなどのオブジェクトをWord文書などの別オブジェクトに埋め込むまたはリンクすることができるMicrosoftの技術
  • OLE DB は、DBMSのデータをリンクするためのインターフェイス

アプリケーションプログラミングインターフェイス (API)

  • APIは、アプリケーションがネットワーク上でデータ、メソッド、機能を共有する方法を提供する仕組み

階層的アプリケーション手法

  • 最もよく使われるアーキテクチャは、3層で構成されている:
    • プレゼンテーション層 (View)
    • ビジネスロジック層 (Controller)
    • データ層 (Model)

ActiveXデータオブジェクト (ADO)

  • ADOは、あらゆる種類のデータに対応するMicrosoft社の高レベルインターフェース
  • ADOは、アプリ、ツール、ブラウザ経由で、フロントエンドデータベースクライアントや中間層ビジネスオブジェクトを作成することができる
  • ADOは、システムへのアクセスに対して設定可能な制限がない

メタデータ

  • メタデータは、他の情報を説明するための情報(データに関するデータ)
  • データマイニングデータベースからの知識発見 (KDD; Knowledge Discovery in Database) などの分析は、重要度の高いデータを明らかにする

オンライン分析処理 (OLAP)

  • OLAP (OnLine Analytical Processing) は、クエリを定式化し、そのクエリの結果に基づいて別のクエリを定義することができる技術

ナレッジマネジメント

  • ナレッジマネジメントは、企業内の情報と関連リソースを効率的かつ効果的に管理する方法
  • (参考):
    • エキスパートシステムは、専門家の英知を集めたナレッジベースと、そこから結論を導く推論エンジンの2つの要素で構成される

データベースからの知識発見 (KDD)

  • KDDは、意味のある情報を抽出するための、データから有用なパターンを識別する統計学的な可視化の方法

KDDのセキュリティコントロール

  • KDDは、有用なビジネスインテリジェンスと意思決定を促進するため、プロセスを保護することは重要

6-4. Webサイトがセキュアでない理由

Webアプリケーションの脅威と保護

  • Webサイトに対する攻撃:
    • サービス妨害 (DoS) 攻撃と分散型サービス妨害 (DDoS)
    • Man-in-the-middle (MitM) 攻撃
    • ドライブバイダウンロード攻撃 (DBD; Drive-By Download) : ブラウザを介してユーザに気付かれないようにソフトウェアをダウンロードさせる攻撃
    • パスワード攻撃 : 総当たり攻撃や辞書攻撃など
    • SQLインジェクション攻撃
    • XSS (Cross Site Scripting) : 信頼できないコードを実行させる攻撃
    • CSRF (Cross Site Request Forgery) : 認証されたリクエストを第三者のサイトに強制的に送信させる攻撃
    • 盗聴攻撃
    • バースデー攻撃(誕生日攻撃)
    • マルウェア攻撃

内臓のWebサイトセキュリティ

  • OWASP (Open Web Application Security Project) は、Webアプリの安全な展開の焦点を当てた、複数の有用なフレームワークを提供している

6-5. マルウェア、ランサムウェア、ランサム攻撃:ソフトウェアの観点

悪意のあるソフトウェア (マルウェア)

  • マルウェア(悪意のあるソフトウェア)は、価値のあるリソースや資産に害を及ぼすことを目的として作成されたアプリケーション

ソーシャルエンジニアリング

  • ソーシャルエンジニアリング : だますことや脅すことによって、人がすべきでないことをさせること
  • ダンプスターダイビング (dumpster driving) : 捨てられた潜在的から価値のある情報を見つけること
  • ショルダーサーフィング (shoulder surfing) : 人がパスワードを機器に入力する様子を盗み見て、情報を不正に入手すること

ウイルス

  • ウイルスは、自らをコピーして拡散する意図と能力があるソフトウェアプログラムのこと
  • ウイルスは、ユーザのアクションによって動作し、拡散する
  • ウイルスのタイプ:
    • ファイル感染ウイルス : プログラムやファイルを書き換える
    • ブートセクター感染型ウイルス : マスターブートレコードを書き換える
    • システム感染 : 起動時にウイルスが呼び出される
    • コンパニオンウイルス : 拡張子の優先順位を利用する。MS-DOSではコマンドが与えられると、内部コマンド、.com、.exe、.bat の順で実行を試みる
    • メールウイルス : メールを使って拡散する
    • 複合感染型 : ブートセクターとプログラムファイルの両方を書き換える
    • マクロウイルス : ExcelやWordのVBA (Visual Basic for Application) を利用する
    • スクリプトウイルス : インタプリタで実行できる。.vbs など
    • ポリモーフィック型ウイルス : 感染するたびにシグネチャ検知を回避するために内部コードを書き換える
    • マルチパータイト型ウイルス : マスタブートレコード、ブートセクタ、およびファイルに感染し、システムのセキュリティコントロールを無効化する

その他のマルウェア

  • その他のマルウェアのタイプ:
    • ワーム : ユーザのアクションなしに拡散する。OSの脆弱性などを利用してネットワーク内で次々と感染する。ウイルスより迅速かつ効果的に拡散する
    • Hoax (デマウイルス) : デマの警告を表示し、ユーザに指示を与える
    • トロイの木馬 : 正しい振る舞いをする一方で、別の望ましくない動作をする。ユーザのアクションで動作する
    • リモートアクセストロイの木馬 (RAT) : 攻撃者が容易にアクセスできるようにするためのトロイの木馬
    • DDoSゾンビ : 攻撃者の指示に従って他のホストを攻撃する
    • 論理爆弾 : 条件を満たしたときに動作するプログラム。開発者や管理者が解雇される際に、会社のリソースや資産に損害を与えるために使用される
    • スパイウェアとアドウェア : Webユーザによる閲覧パターンから関心のある情報を提供し、ユーザがインストールするように仕向けること
    • いたずら (prank)
    • ボットネット
    • ランサムウェア : ファイルを暗号化し復号鍵を販売する攻撃。身代金要求攻撃

アンチマルウェアまたはアンチウイルスシステム

  • アンチマルウェアは、マルウェアを検知するためのソフトウェアシステム
  • 検知するための3つのアプローチ:
    • シグネチャースキャン (シグネチャーベースのIDS) : ウイルスに含まれる特徴的な文字列を探す
    • アクティビティモニタ (ルールベースやアノマリーベースのIDS) : 疑わしいアクティビティを監視する
    • 変更検出 (統計学に基づいたIDS) : プログラムや設定のファイルを定期的に比較して変更点を探す

侵入検知・防止システム

  • 侵入検知・防止システムには、ホストベースの IDS や IPS などがある
  • 感染の疑いがあるファイルを検査可能な場所に移動させて、そのファイルが無害かを判断し、隔離や消去などの防御措置をとることができる

ソフトウェアのブロックリストと許可リスト

  • ソフトウェアのブロックリストと許可リストは、事前に承認されていないファイルを実行しようとする試みを検知・防止する。
  • 不正なソフトウェアを実行すると、ITセキュリティ担当者に警告が通知される
  • 人種差別問題を考慮して、以下の言い換えをすること:
    • ホワイトリスト => 許可リスト
    • ブラックリスト => ブロックリスト

マネージドセキュリティサービス

  • サードパーティに委託するほうが、ビジネス上では理にかなっている場合もある

ランサムウェアとランサム攻撃からの保護

  • ランサム攻撃に対する戦略は、拒否、検出、封じ込め、レスポンスとリカバリー

6-6. 内蔵のセキュリティ:開発管理の選択肢

  • セキュリティを組み込むには、ソフトウェアの計画、開発、運用の各段階で、最初からセキュリティを必須要件として扱う必要がある

ソフトウェア開発ライフサイクル (SDLC)

  • SDLC (Software Development Lifecycle) は、ソフトウェア開発プロジェクトの構想から機能要件の定義・実装までの各フェーズをガイドするフレームワーク
  • 古いSDLCは、ウォーターフォールモデルとも呼ばれる
  • SDLCの流れ:
    1. プロジェクトの開始と計画
    2. 機能要件の定義
    3. システム仕様の設計
    4. 開発と実装
    5. 受け入れテスト
      • 独立した検証と妥当性確認 (IV&V; Independent Verification and Validation)
      • 運用テスト・評価活動 (OT&E; Operational Testing and Evaluation)
    6. 本番への移行
    7. 修正とシステム交換
    8. 運用と保守
      • サービスレベル契約 (SLA) へのコンプライアンスを常に確認する必要がある

分野横断的な手法

  • 複雑なシステムの開発と提供でよく使われるアプローチ:
    • 統合製品チーム (IPT)
    • 統合生産プロセス開発 (IPPD)

統合製品チーム (IPT)

  • IPT (Integrated Product Team) は、定義されたプロセスや製品を達成するために協力する、様々なスキルを持ったステークホルダーや個人からなるチーム

統合生産プロセス開発 (IPPD)

  • IPPD (Integrated Product and Process Development) は、システムプロジェクトにおいて、開発管理手法、製造アプローチ、試験・検証戦略の選択などの、未検討段階ではできないことを認識しようとするもの
  • IPPDは、熟練したチームを使って、設計、製造、プロセスを最適化する管理手法として利用できる
  • IPPDのチームには、企業と請負業者またはコンサルタントの両方が参加する場合がある

その他の手法とモデル

  • 構造化プログラミング開発 : コードは再利用可能なモジュールとして作成され、各フェーズでレビューが行われる
  • 反復的開発 : 要件、設計、開発を継続的に改善・修正する。変更コントロールの仕組みも決めておく必要がある
  • RAD (Rapid Application Development) : 質の高いコードを迅速に作成する。意思決定が急すぎて設計の質が悪化する可能性もある
    • RADでは、要件計画 > ユーザ設計 > 製作 > カットオーバー の4つのフェーズを使用する
  • 共同分析開発 (JAD; Joint Analysis Development) : すべてのステークホルダがプロセス全体に関与できる
  • 探索的モデル : 現在入手可能な情報で策定された一連の要件を使って開発する。システムがどのように動作するかの仮説を立てる
  • スパイラル方式 : ウォーターフォール方式をネストしたもの。ウォーターフォールの各フェーズでPDCAサイクルを回す
  • プロトライピング : 簡易バージョンをレビュー用にリリースして、ステークホルダのフィードバックからより優れた次のバージョンを作成すること。そしてこれらを繰り返すこと
  • 修正プロトタイプモデル (MPM; Modified Prototype Model) : プロトタイピング手法をWebアプリ開発に適した形に改良したもの
  • クリーンルーム : 正確な設計を通じてソフトウェアの欠陥やバグを制御・防止すること
  • エクストリームプログラミング : コミュニケーションとフィードバックによって開発を進める。開発者は常にペアで作業を行う
  • アジャイル開発 : 少人数で協調的で反復可能な学習、構築、テスト、運用をする。「スクラム」「スプリント」「セーフ」などの活動パターンに沿って活動する
    • スクラム : 開発サイクルを何回も繰り返すこと。開発サイクルは優先度の高い順に行う
    • スプリント : 開発サイクルにおける反復の単位
  • DevOps : 開発と運用の組み合わせによって、改善が必要な製品をより短い期間でデプロイできる
    • DevOpsモデルは「ソフトウェア開発」「品質保証」「運用」の3つから構成される
  • DevSecOps : DevOpsにセキュリティを組み込んだもの

安全なソフトウェア開発のための成熟度モデル

  • 成熟度モデルは、特定のビジネスプロセスの信頼性、再現性、品質を測定・評価するための方法

ソフトウェア能力成熟度モデル (SW-CMM)

  • SW-CMM (Software Capability Maturity Model) は、独自のレビューと自己評価の両方を用いて、組織の現在と将来の状態を評価するモデル
  • ソフトウェア能力成熟度モデル (CMM または SW-CMM) には、5つの成熟度の段階がある:
    • 初期 (気づいた)
    • 反復可能 (ルールを作った)
    • 定義された (ルールを回した)
    • 管理された (テーラリングされた)
    • 最適化 (他と融合した)

OWASPの成熟度モデル

  • OWASPソフトウェア保証成熟度モデル (SAMM; Software Assurance Maturity Model) : 安全なソフトウェア開発を測定・改善するためのフレームワーク
  • OWASPのDevSecOps成熟度モデル (DSOMM; DevSecOps Maturity Model) : CMMの考え方をDevSecOpsに取り入れたモデル

セキュアコーディングのガイドラインとスタンダード

  • コーディングのガイドラインとスタンダードを使用することで、開発者の好みや慣れによるコーディングを防止する

プログラミング言語による強力なデータの型付けと構造の強制

  • 型安全または型強制 (strong typed) のプログラミング言語を使用することで、プログラムを安全に(エラーしないで)実行できる

信頼できるライブラリの再利用の制限

  • コードをコピーして調整するほうが簡単な場合があるが、同時に問題も発生する
    • プログラマは再利用するコードが何をするか正しく理解していない可能性がある
    • 再利用するコードは書かれている通りに正しく機能しない可能性がある

セキュアプログラミングのスタンダードとガイドラインの使用を強制する

  • 強制方法には管理面と技術面の2つの面がある

アプリケーションプログラミングインターフェイス(API)のセキュリティ

  • APIは、多くの異なるモジュール同士の通信を可能とするコネクタ
  • APIは、WebサイトやIoTで使用されている
  • APIの管理と保護が必要

Representational State Transfer (REST)

  • RESTは、ネットワークアーキテクチャを設計するためのアーキテクチャスタイル
  • REST APIを使うことで、複雑なリクエストではなく単純なURLを使用して、Webシステムと対話することができる

REST APIのセキュリティに関する推奨事項

  • APIには、組織が導入する他のWebアプリと同様のセキュリティメカニズムを使うこと (WAFなど)
  • 独自のセキュリティソリューションを実装しないこと
  • 無償かつ読み取り専用の公開APIでない場合は、単一の鍵ベース認証を使用しないこと
  • 暗号化すること (TLSなど)
  • ハッシュベースのメッセージ認証コード (HMAC) を使うのが最も安全

認証オプション

  • TLSによるベーシック認証 : ベーシック認証ではパスワードが平文で送られるので必ずTLS上で暗号化すること
  • OAuth 1.0a : HMAC-SHA1を使用して署名するプロトコル。3つのプロトコルの中で唯一TLSなしで安全に使用できる
  • OAuth 2 : TLSを必須にした代わりに、署名が削除されてプロトコルが簡潔になった

OWASP REST セキュリティチートシート

  • REST APIに関するセキュリティ要件を検討する際に使用できるOWASPのチートシート

ツールセット、ライブラリ、リポジトリ、統合開発環境

  • 開発者は、迅速な開発戦略を可能にするためのツールを効果的に使用・管理する方法を学ばなければならない
  • ライブラリのメリット : 信頼性の向上、プロセスリスクの低減、スペシャリストの有効活用、スタンダードへの準拠、加速する開発
  • ツールセット : プログラミングツールやソフトウェア開発ツールは、開発者がアプリの作成、デバッグ、メンテナンス、サポートを行うために使用するプログラムやアプリケーション
  • 統合開発環境 (IDE; Integrated Development Environment) : 多くのツールや機能を1つの環境にまとめて、開発者が使用できるようにしたもの

ソースコード解析ツール

  • ソースコード解析ツールは、ソースコードやマシン語を解析するためのツール
  • ソースコード解析ツールは、セキュリティ上の欠陥や弱点を探すために使う
  • 複数のアプローチ:
    • 静的テスト (SAST; Static Application Security Testing) : 自動ツールなどによるコード検査
    • 動的テスト (DAST; Dynamic Application Security Testing) : ファジングなど
      • ジェネレーショナルファジングは、検査対象の知識を利用して入力データを生成する。インテリジェントファジングとも呼ばれる
    • インタラクティブテスト (IAST; Interactive Application Security Testing) : Webブラウザやモバイルの操作から検査する
    • ランタイムテスト (RASP; Runtime Application Security Testing) : 潜在的なセキュリティ違反が発生した際に、そのコードを終了させるために使用するセキュリティ保護ツール
  • 弱点や限界:
    • 自動的に発見できない脆弱性 (認証、アクセス制御、暗号の安全でない使用など)
    • 誤検知の数が多くなる場合がある
    • 設定上の問題点を発見できない場合がある

開発・テスト用サンドボックス

  • サンドボックスは、特定のコードが悪意のあるかをテストするための遊び場
  • サンドボックスは、プログラムが使用できるメモリとプロセッサのリソースに制限がある

6-7. ソフトウェア開発エコシステムにおけるセキュリティコントロール

環境の制御と分離

  • ソフトウェア開発の現場には、開発環境、品質保証環境、本番環境の3つの環境がある
  • 各環境を分離することが大切

IDE、プログラム実行、実行環境

  • ランタイムシステムは、環境に関係なくアプリケーションをコンピュータシステム上で動作させるための仕組み

コードレポジトリのセキュリティ

  • コードリポジトリは、コードを保存する場所
  • コードレポジトリの保護は、貴重な資産と同じように扱う必要がある

TCB (Trusted Computing Base)

  • TCBは、アーキテクチャ内でセキュリティを受け持つハードウェア、ソフトウェア、コンポーネントの集まり
  • TCBは、セキュアカーネルやリファレンスモニターなどのコンポーネントの集合を表す
  • TCBは、カーネルに含まれている
+-------------------------------+
|          User Space           |
|   +---------+   +---------+   |
|   | Process |   | Process |   |
|   +---------+   +---------+   |
|                               |
+-------------------------------+
|                               |
|   +-----------------------+   |
|   |   Reference Monitor   |   |
|   +--------- TCB ---------+   |
|             Kernel            |
+-------------------------------+

リファレンスモニター

  • リファレンスモニター (参照モニター) は、サブジェクトとオブジェクトの間でセキュリティを強制する要素

セキュリティカーネル

  • セキュリティカーネルは、リファレンスモニターの概念を実装したもの
  • セキュリティカーネルは、以下の3つの基本要件を満たす:
    • 完全性 : 情報へのアクセスはすべてカーネルを経由して行うこと
    • 隔離性 : カーネル自体があらゆる種類の不正アクセスから保護されること
    • 検証可能性 : カーネルは設計仕様への適合を証明すること

ソフトウェアをより安全にするための暗号技術のアプローチ

  • コンテンツ保護は、デジタル署名などのPKIベースの暗号化プロセスに依存している

DMBS制御

  • データベース内のデータの読み取り、書き込み、更新、照会、削除を制限すること

ロック制御メカニズム

  • DMBSでロックできるユーザを制限すること

DBMSのその他のアクセス制御

  • ビューベースのアクセスコントロール : ビューを作成・管理してセキュリティ要件に対応する
  • アクセスコントロールの付与と取り消し
  • オブジェクト指向データベースのセキュリティ
  • メタデータのコントロール : メタデータは機密情報へのアクセス制限にも使用できる
  • データ汚染管理 : データの完全性を確保する
    • 入力コントロールの例 : ハッシュサム、エラー検出・修正・自己チェックディジットなど
    • 出力コントロールの例 : トランザクションの妥当性確認、認可制御、監査証跡など

オンライントランザクション処理 (OLTP) のセキュリティ考慮事項

  • OLTP (OnLine Transaction Processing) は、大量のトランザクションすべてをホストで処理すること
  • OLTPシステムは、モニタリングシステムとしても機能する

ソフトウェアセキュリティの一側面としての構成管理 (CM)

  • 構成管理 (CM; Configuration Management) は、プログラムやドキュメントに対する変更を監視し管理すること
  • CMプロセスの流れ:
    1. 識別 : 変更があったことを識別する
    2. コントロール : 変更するためにレビューと承認が必要なときに発生する
    3. アカウンティング : 構成の変更を記録し報告する
    4. 監査 : 完了した変更を検証できる

構成管理計画

  • 構成管理計画は、変更が段階的に厳密に合意された方法で実行されることを保証するもの

情報保護管理

  • ソフトウェアを共有する場合は、ポリシー、開発管理、ライフサイクル管理を確実に行うことで、不正な変更から保護する必要がある

継続的インテグレーションと継続的デリバリー (CI/CD)

  • 継続的インテグレーション (CI; Continuous Integration) と、継続的デリバリー (CD; Continuous Delivery) は、コーディングしてからデプロイするまでの様々なプロセスを自動化すること
  • CI/CDが適切に実装されることは、DevSecOpsアプローチにもつながる

不適切な粒度の制御

  • 粒度は、他のアクションを許可して特定のアクションだけを制限する能力を意味する
  • コントロールの粒度が不十分な場合は、最小権限や職務分離を適切に実施すること

6-8. ソフトウェアアプリケーションとシステムのリスク分析と低減

安全なソフトウェアとシステムのための構成管理の必要性

  • 構成管理 (CM; Configuration Management) と構成コントロール (CC; Configuration Control) は、組織のセキュリティ、安全性、回復力をサポートする
  • 開発パイプラインにおけるプログラムや設定などの改ざん防止のため

変更の監査とログ記録

  • 変更管理とコントロールでは、まずシステムの要素をどの程度の粒度で定義し、列挙、管理、コントロールするかを決める必要がある
  • 監査では、ログに記録されたすべての変更の結果が、ベースラインと一致しているかを確認する

ソフトウェアアシュアランスとセキュリティ評価

  • 選択したリスク管理がうまく機能しているかどうかを継続的に評価すること

正式なアプローチ

  • ソフトウェアシステムのセキュリティシステム評価には、以下の4つのタイプがある:
    • 認証 (Assurance) と認定 (Accreditation) : ニーズや要件を分析し、必要な機能が正しく実装されていることを確認すること
    • リスクマネジメントフレームワーク (RMF) : フレームワークを使うことでリスク管理と緩和の意思決定サイクルを網羅することができる
    • ソフトウェア能力成熟度モデル (CMM; Capabilities Maturity Model) : 品質基準を満たすことも目的としたモデル
    • ソフトウェア品質保証またはソフトウェアアシュアランス : ソフトウェアが要求事項をどれだけ満たしているかを確認する

ソフトウェア品質保証

  • ソフトウェア保証(ソフトウェア品質保証)は、システムが適切に機能しているかどうかを確認すること

非機能的な要求の正式な評価

  • ソフトウェア品質保証の手法では、容易に評価できないことがある

ソフトウェア保証ポリシー

  • ソフトウェア保証のポリシーやプロセスを適切に文書化すること

認証と認定

  • 認証 (Assurance) は、システムが提供されるすべてのセキュリティ要求事項を満たしていることを確認すること
  • 認定 (Accreditation) は、システムを本番環境に移すための承認
  • 認証は開発チームの最終テストが完了したとき、認定は運用チームの受け入れテストが完了したときに実施される

テスト、検証、およびセキュリティ評価

  • テストは、指定された一連の入力と初期条件が要求された結果をもたらすかどうかを確認するプロセス
  • (参考) :
    • ホワイトボックステスト : 開発者の視点からテストする。有効性の検証
    • ブラックボックステスト : ユーザの視点からテストする。現実性の検証
    • グレーボックステスト : ユーザの視点からテストするが、ソースコードにアクセスできる
    • クリスタルボックステストは、ホワイトボックステストとも呼ばれる

受け入れテスト

  • 受入テストは、システムが受け入れ基準を満たしているかを判断し、オーナーや顧客がシステムを受け入れるかどうかを決定するために実施するテスト

回帰テスト

  • 回帰テストは、変更や追加によって既存の機能が影響されていないことを確認するテスト
  • 回帰テストは、変更を加えたときやパッチを当てたあとに実施する
  • 回帰テストは、多数のテストケースを繰り返し実施して、その結果をベースラインと比較する
  • (参考) :
    • 単体テスト : モジュールやコードセクションに重点を置いたテスト
    • 統合テスト (結合テスト) : モジュールが一体となってどのように動作するかのテスト
    • システムテスト (総合テスト) : 完全に統合された製品のテスト

セキュリティ評価テスト

  • 情報システムの運用期間を通じて行うことで、評価するために必要なデータを収集できる

コントロールのテストおよび評価

  • セキュリティ評価テストでは、設計されたセキュリティ対策に焦点を当てて、それらが正しく動作しているか、環境全体がもたらす脅威に対応しているかを評価する必要がある

調達時のソフトウェアアシュアランス

  • 段階的なアプローチの段階 : 計画フェーズ > 契約フェーズ > モニタリング、受け入れ、デプロイメントフェーズ > 継続的な使用とサポートのフェーズ

オープンソースソフトウェアとセキュリティ評価

  • リーナスの法則 : コードを見る目があれば、そのソフトウェアのバグはすべて明らかになる
  • 誠意のないプログラマが、脆弱性を見つけてもコミュニティ全体に報告しない可能性がある

独立したソフトウェアとシステムのセキュリティ評価

  • ソフトウェアやファームウェアは、メーカーやベンダのサポートを受けられなくなる可能性がある
  • 最終的には、その技術を使用しているビジネスプロセス全体をリファクタリングすることになる

M&A

  • M&A(合併・買収)を行った組織で得られた複合的な資産やアーキテクチャのセキュリティ評価は困難

コモディティシステム

  • 数によって安全性を保証
  • 様々な機能が既製品として入手され、組織のITインフラ全体に組み込まれる


7. セキュリティの評価とテスト

7-1. 評価、テスト、監査戦略の設計および検証

セキュリティ監査・評価の目的

  • 公式 (Formal) : コンプライアンススタンダードに対する評価
  • 非公式 (Informal) : コンプライアンススタンダードの一部分に対する評価

監査

  • 監査は、コンプライアンスを測定または決定するために構造的にレビューすること
  • 監査の結果は、以下のような発見事項として組織に正式に報告される:
    • 状況 : 監査の結果を記載した所見
    • 基準 : 非監査人の活動またはパフォーマンスを測定するために使用されるスタンダード
    • 原因 : 問題が発生した理由の説明
    • 影響 : 状況と基準との違いと重要性
    • 改善提案 : 原因を修正するための取るべき行動
  • 監査の実施は、事前に予定され、コンプライアンスカレンダーを通じて追跡される

評価

  • 評価は、経営者の期待に応えるためのコントロールを評価すること
  • 評価には、テスト、検査、分析タスクなどが含まれる
  • テストは、任意のレベル (範囲) と任意の環境 (開発・本番) で行うことができる
  • 環境の弱点を特定して対処するために、監査に先立って評価が行われる場合が多い

スタンダードとフレームワーク

  • スタンダードやフレームワークには、法律や市場の期待が含まれる

NISTリスクマネジメントフレームワーク (Risk Management Framework)

  • NISTのリスクマネジメントフレームワーク (RMF) は、監査やコントロール評価を実施する際のスタンダードとして長く使われている

NISTサイバーセキュリティフレームワーク (NIST Cybersecurity Framework)

  • CSF (CyberSecurity Framework) は、組織がサイバーセキュリティの回復力を評価するためのツールセットを提供する
  • CSFは、検証されたリスク主導型の成熟度モデルを提供する
  • CSFは、組織がサイバーセキュリティのプラクティスを大規模な組織のリスク管理のプラクティスに統合することを可能にする

ISO 27000「情報セキュリティマネジメントシステム」

  • ISO 27000シリーズのスタンダードは、情報セキュリティ管理システム (ISMS) の有効性を評価するための評価や監査のフレームワーク

SOCレポート

  • SOC (System and Organization Control) は、財務報告にかかる内部コントロールが有効に機能していることを評価するフレームワーク
  • SOCレポートは、SOC 1, SOC 2, SOC 3 の種類がある
  • SOC 1 と SOC 2 には、タイプが Type 1 と Type 2 の2種類ある
    • タイプIは、コントロールの「適合性」や「設計」を評価するもの
    • タイプIIは、コントロールの「有効性」を評価するもの。監査レポートには外部監査人の報告が含まれている
  • SOCレポートの表:
    • SOC 1 Type I : 特定の時点における財務に関する内部コントロールの評価
    • SOC 1 Type II : 特定の期間における財務に関する内部コントロールの評価
    • SOC 2 Type I : 特定の時点におけるトラストサービス基準 (技術的なセキュリティ管理) を評価
    • SOC 2 Type II : 特定の期間におけるトラストサービス基準 (技術的なセキュリティ管理) を評価
    • SOC 3 : 概要レポートで、SOC 2 Type II レポートを要約したもの

トラストサービス基準 (Trust Services Criteria)

  • トラストサービスクライテリアは、SOC 2, 3 で使われており、セキュリティ、可用性、処理の完全性、機密性、プライバシーなどを評価するための判断基準

コモンクライテリア (CC) [追加]

  • CC (Common Criteria) は、IT 製品や情報システムに対して、情報セキュリティを評価し認証するための評価基準を定めている
  • コンピュータセキュリティのための国際規格であり、ISO/IEC 15408 である
  • セキュリティ保証要件における評価保証レベル (EAL; Evaluation Assurance Level):
    • EAL1 : 機能テスト
    • EAL2 : 構造化テスト
    • EAL3 : 方式的テスト、およびチェック
    • EAL4 : 方式的設計、テスト、およびレビュー
    • EAL5 : 準形式的設計、およびテスト
    • EAL6 : 準形式的検証済み設計、およびテスト
    • EAL7 : 形式的検証済み設計、およびテスト
  • 保護プロファイル (PP; Protection Profile) : 製品のセキュリティ要件を特定する文書
  • セキュリティターゲット (ST; Security Target) : 製品のセキュリティコントロールを特定する文書

業界、地域固有のスタンダード

  • PCI DSS : クレジットカード業界のスタンダード。クレジットカード情報の保存、処理、伝送をコントロールする
  • IEC 62443 : 産業用コントロール
  • Cyber Essentials : 英国の組織
  • CIP : 米国の重要なインフラ
  • UL 2900 : 電子機器
  • STAR : クラウドサービスプロバイダー
  • ISAE 3000 : EUの監査スタンダード
  • Customer Security Controls Framework : 国際的な金融取引

内部監査と評価

  • 内部評価の実施には、以下のステップが含まれる:
    1. 憲章 (chartering) : 経営陣は評価活動の範囲(スコーピング)、作業スケジュール、評価の実施方法、結果の報告形式、作業担当者の決定
    2. テスト : 人、プロセス、技術を含む物理的、技術的、管理的なコントロールを対象とする
    3. 報告 : ステークホルダのニーズに配慮して報告する
    4. 是正 : 是正活動は組織のプラクティスに従って進める
      • 米国連邦政府では POM&M (Plan of Action and Milestones) によって対応策を計画し、マイルストーンを設定する
  • 内部監査は、経営者に報告するときに有効

外部監査と評価

  • 監査は、組織のコントロールと実務がコンプライアンススタンダードを満たしていることを証明するために、第三者が行う評価のこと
  • 外部監査は、外部に報告するときに有効

第三者による監査と評価

  • クラウドサービスプロバイダー (CSP) や、インターネットサービスプロバイダー (ISP) などと協力して、問題点を解決する場合もある

マネージドサービスとセキュリティ評価

  • マネージドサービスは、一連の機能の実行を第三者が引き受けること (アウトソーシング)。AWSなど
  • クラウドやマネージドサービスのプロバイダーと結んだSLAにより、サマリーレベルのセキュリティ監査報告書の情報が得られる
  • リスクを評価するために、組織はベンダーのサプライチェンのセキュリティ管理を評価する必要がある

サプライチェーンセキュリティの原則

  • 保護すべきものとその理由を理解する
  • サプライヤーとの契約プロセスにセキュリティ考慮事項を要求する
  • サプライヤーへセキュリティインシデントに対するサポートを提供する
  • サプライチェーン管理アプローチに保証活動を組み込む
  • サプライチェーンにおけるセキュリティの継続的改善を促進する
  • サプライヤーとの信頼関係を構築する

7-2. セキュリティコントロール評価の実施

コントロール評価の方法とツール

  • コントロール評価は、テスト、検査、インタビューなどを組み合わせて行う

評価のテーラリング

  • 評価の範囲決定 (スコーピング) とテーラリングには、現状を考慮したベースラインの更新やアップデートを含める
    • スコーピング : 適用されるシステムに基づいてセキュリティコントロールを検討して選択するプロセス
    • テーラリング : セキュリティコントロールのリストを組織のミッションと照合させるプロセス
    • ベースライン : セキュリティコントロールの最低限の基本セット

検査

  • 多くの場合、評価者は特定のアーティファクトをレビューするだけでコントロールの評価ができる
  • アーティファクトには、仕様書、アーキテクチャ・設計書、技術マニュアルなども含まれることがある

ログレビュー

  • ユーザの活動、例外、障害、情報セキュリティイベントを記録したイベントログを作成し、保管し、定期的にレビューすること
  • 計画プロセスで、組織はログ記録の要求事項と目的を規定する必要がある
  • 計画プロセスに基づいて、組織はログ管理活動 (ログの生成、送信、保管、管理、廃棄) に関するポリシーを策定すること
  • ログ記録で重要なこと:
    • 組織全体でログ管理の優先順位付けを適切に行う : 時間とリソースのバランスに基づいて優先順位付けする
    • ログ管理のポリシーとプロシージャを確立 : 組織全体でログの一貫性を保つ
    • セキュアなログ管理インフラを構築・維持 : ログの完全性を守る
    • ログ管理の責任を負うスタッフに対する適切なサポートを提供
  • ログ施設とログ情報は、改ざんや不正アクセスから保護されること

インタビュー

  • インタビューは、文書化されたプロセスと実際の仕事ぶりの違いを特定するために用いる
  • インタビューは、意識啓発 (アウェアネス) の評価に役立つ

テスト

  • テストは、定義された条件下でのシステム、プロセス、アクティビティの実際の動作とその期待される動作を比較するプロセス

コンプライアンスと実証手続

  • テストは、コンプライアンスまたは実証手続に分類される
  • コンプライアンステストは、コントロールが適切に運用されているかどうかを判断する
  • 実証手続は、プロセスの適切な動作を評価する(オフボーディング操作の評価など)

テストの観点

  • テストは、内部または外部の視点から行う
  • 外部テストと内部テストの両方を実施する場合は、外部テストを先に行う
  • 内部テストでは、インサイダーの脅威を想定して行う

コードレビューとテスト

  • コードレビューの種類:
    • 手作業による検査技術
    • ソースコード解析技術
  • コードレビューでの確認事項:
    • 必要な機能が全て揃っている
    • 無関係なコードが存在しない
    • デッドエンドや到達できないコードがない
    • バックドアやトラップドアがない
    • コーディングスタンダードを満たしている
    • 全てのコードは信頼できるソースから取得している

企画・設計時のコードレビュー

  • アーキテクチャのセキュリティレビュー : 製品のアーキテクチャがセキュリティ要件を満たしているか
  • 脅威モデリング : ビジネスケースや使用シナリオの構造化された手動分析
    • ソフトウェアの脅威モデリングは、設計およびコーディングの欠陥数とその他の欠陥の重大度を低減するためのもの
  • ファーガン (Fagan) テストは、計画からフォローまで通して詳細なコードレビューを行う
    • 計画 > 概要 > 準備 > 視察 > やり直し > フォローアップ の順番で進む

申請・開発時のコードレビュー

  • 静的アプリケーションテスト (SAST; Static Analysis and Security Testing) : ソースコード解析技術によるテスト
  • 静的なバイナリコード解析と手動によるバイナリレビューの2種類ある

ミスユースケーステスト

  • ユースケースは、タスクを達成するために人々がシステムを使用する際の意図した使用方法を記述したもの
  • ミスユースケーステストは、システムやセキュリティの障害につながる一連の行為が人間によって行われると仮定した検証

ネガティブテスト

  • ポジティブテストは、システムが期待通りに動作することをテストする
  • ネガティブテストは、予期しないデータや無効なデータがある場合のアプリケーションの動作をテストする
    • 期待する動作は、予期しないデータを完全に拒否すること

テストカバレッジ解析

  • テストカバレッジは、ソフトウェア構造の何割がテストされたかを示すメトリクス (評価基準)
  • テストカバレッジ = テストされたユースケース数/ユースケースの総数
  • コードカバレッジは、関数や条件などを使った式で評価される
  • 構造カバレッジの種類:
    • ステートメントカバレッジ : すべてのステートメントが最低一回は実行されるようなテストケースを実行する
    • ディシジョン (ブランチ) カバレッジ : 条件の分岐をすべて通るようなテストケースを実行する
    • コンディションカバレッジ : 条件の組み合わせごとにテストケースを実行する
    • マルチコンディションカバレッジ : 可能なすべての条件の組み合わせごとにテストケースを実行する
    • ループカバレッジ : ループが最後まで実行されるテストケースを実行する
    • パスカバレッジ : パス (開始から終了までの処理) ごとにテストケースを実行する
    • データフローカバレッジ : データフローごとにテストケースを実行する
    • 必須項目の入力
    • データとフィールドの対応関係
    • 許可された文字列
    • 許可されたデータの境界と制限

インターフェーステスト

  • インターフェーステストは、アプリケーションの異なるコンポーネント間のテスト
  • Webアプリはインターフェースを介してWebブラウザと通信するので、UIテストはインターフェーステストに該当する

倫理ペネトレーションテスト

  • ペネトレーションテストは、脅威となる人物が入手可能な情報を用いて、攻撃をシミュレーションする
  • ペネトレーションテストをする前に、明確に定義された交戦規程 (RoE; Rules of Engagement) を定めてから契約する
  • 倫理ペネトレーションテストは、RoEなどの契約や法律に基づいてペネトレーションテストをすること

倫理的ハッキング

  • 倫理的ハッキングは、セキュリティ研究者がシステムや製品の脆弱性を調査、探索、リバースエンジニアリングで検出すること
  • バグバウンティプログラムや、GoogleのProject Zeroなど

基本的な方法論

  • 倫理ペネトレーションテストの方法は、厳密に従わなければならない
    1. 憲章 (Chartering) (計画策定)
      • 交戦規定 (RoE) が作成され、テストの範囲・方法・条件が定義される
      • 報告時に問題とならないように、脆弱性データの保存方法と送信方法も決めておく
    2. 探索 : 情報収集と発見を行う
      • Nmapでポートスキャンをする際、デフォルトでは Well-knownポート+有名なポート にのみスキャンをする点に注意
    3. スキャン : 脆弱性スキャンを行う
      • 認証スキャンは、読み取り専用アカウントを使用してシステム内に入ってからスキャンをすること
    4. エクスプロイト : 侵害攻撃を行う
    5. 報告

継続的なフルサイクルテスト

  • ペネトレーションテストはある時点での結果なので、脅威の進化に対応するためには継続的にテストする必要がある
  • カオスエンジニアリングアプローチは、本番システムを強制的に停止させて、組織のインシデント検知、対応、復旧能力を評価するもの

7-3. セキュリティプロセスデータの収集

  • セキュリティ専門家は、情報を提供するシステムを特定し、その情報を相関させ、その結果に基づいて瞬時に行動できる必要がある

アカウント管理

  • IDとアクセス管理は、情報を保護する際に行われる最も重要なセキュリティ活動の一つ
  • IAMに関する活動をレビューするには、様々な文書や情報にアクセスする必要がある

合成トランザクション

  • 合成トランザクションは、動作スクリプトを利用し、実際の顧客のWebサイト利用をシミュレートするWebサイト監視
  • 合成トランザクションは、シンセティックトランザクションや、シンセティックトラフィックとも呼ばれる

リアルユーザー管理 (RUM)

  • RUM (Real User Monitoring) は、Web上での各ユーザのやりとりを収集し分析するためのWeb監視手法
  • RUMによって、ユーザの活動からシステムに負担がかかる場所がわかる
  • RUMは、パッシブモニタリング手法の1つ
  • (参考):
    • パッシブモニタリングは、監視システムに実際のトラフィックをコピーして動かす
    • アクティブモニタリングは、合成トランザクションを利用する

合成性能監視

  • 合成性能監視(シンセティックモニタリング)は、外部エージェントがWebアプリに対してスクリプト化された処理を実行し、性能 (UX) を評価する
  • シンセティックモニタリングは、プロアクティブな監視とも呼ばれる

マネジメントレビューと承認

  • 定期的なマネジメントレビューは、セキュリティプロセスのデータが期待通りに使用され、必要なコントロールが期待通りに機能することを確認できる
  • プロセスの継続的な改善をサポートすることが目的

セキュリティ教育、トレーニング、アウェアネス (SETA)

  • SETA (Security Education, Traning and Awareness) は、環境の変化に対応するための努力活動
  • 教育 : 幅広い問題に適用できる知識体系を教える
  • トレーニング : 職務を実行するために必要な知識を習得する
  • アウェアネス : 個人の注意を問題に向けさせること (意識啓発、意識向上)。情報セキュリティに関する最低限の理解の基準を確立する

可用性サービス

  • 可用性サービスは、組織のコントロールの有効性を判断するためのもの
  • 可用性の高いサービスを提供できることは、コンプライアンス上の義務を果たせるかに直接影響する

バックアップ

  • 組織のバックアップとリストアのプロセスは、セキュリティ管理にとって必要
  • バックアップを取るだけで終わりではなく、取得したバックアップデータがコンプライアンス上の期待と組織の要件を満たし、所定の時間内にリストアできることを検証しなければならない

災害復旧(DR)および事業継続性(BC)

  • BC (Business Continuity) / DR (Disaster Recovery) 計画では、組織の義務と目標、レジリエンスの現状、実施する訓練の方法とスケジュールに対応する訓練プログラムを確立すること
  • 災害は、通常のIT運用を中断させる可能性のあるすべてのイベント
    • 自然災害 : 洪水や火災、地震など
    • 人為的災害 : ハッキングインシデント、テロ、機器の故障など
  • 訓練プログラムの例:
    • デスクチェック : 各自で運用文書を確認する(チェックリストレビューなど)
    • ウォークスルー : マニュアルに沿ってそれぞれの役割と活動を説明する
    • 机上演習 : 会議室で、災害シナリオに沿ってその対応を議論する
    • シミュレーション : 災害イベントをシミュレーションする
    • 並行(パラレル): 本番環境と並行して、災害をシミュレーションして災害復旧サイトを稼働させる
    • フルカットオーバー(完全停止テスト) : 本番環境に影響を与える

7-4. 組織のパフォーマンスの分析および報告

重要業績評価指数 (KPI) と重要リスク指標 (KRI)

  • KPI (Key Performance Indicators) は、過去を見るもの。過去の活動を精査するもの
    • KPIは、測定基準にメトリックスを使用する
  • KRI (Key Risk Indicators) は、未来を見るもの。リスクプロファイルを測定し、影響の変化を把握する
  • 重要リスク指標は、主要リスク指標とも呼ばれる

継続的なプロセス改善サイクル

  • PDCAモデルの4つのフェーズ:
    1. Plan : 何をすべきかを決め、目的を設定し、必要なプロセスを決定する
    2. Do : 計画を実行する
    3. Check : 結果を評価する
    4. Act (Adjust) : 失敗の根本原因を特定し、計画と実行を修正する
  • IDEALモデル : プロセス改善のライフサイクルモデル。開始 > 診断 > 確立 > 行動 > 学習 の順番で進む

例外処理

  • 合意されたレベルのリスク低減を達成していないコントロールを発見した場合は、そのコントロールを改善する
  • リスク許容度を変更して、コントロールの状態に合わせること

倫理的開示

  • 監査中に違法な行為を示唆するものが出てきた場合、当局に報告する法的義務がある

非開示

  • 監査中にシステムの脆弱性を発見しても、通常は秘密保持契約などで公開することはできない

全面開示

  • 全面開示は、監査中にシステムの脆弱性を発見したときに、影響の受ける可能性のあるすべての組織に対して、その脆弱性を公表すること
  • システムを持つベンダーが社会的に恥をかくことで、脆弱性を修正する動機付けを与える

責任ある開示

  • 責任ある開示は、脆弱性を発見した個人が、その弱点に対処する責任のある組織に報告し、公開する前にその組織に脆弱性を修正する時間を与えること

報告義務

  • 評価者や監査中に法律によって報告しなければならないもの(犯罪など)を発見した場合は、当局に報告する必要がある

内部告発

  • 内部告発者は、法的な保護を受けられる場合と受けられない場合がある


8. セキュリティの運用

8-1. ログ取得とモニタリング

ログ管理

  • ログ管理は、システムレポートに依存するすべての分析活動の基礎となる
  • ログ取得は、イベントによって生成されるシグナルをキャプチャすること
  • イベントは、システム環境内で発生するあらゆる種類のアクション(ログインやユーザインタラクションなど)
  • イベント単体では、それが悪意のあるものかどうかは判断できない
                 Policy <------------------------+
                   ^                             |Insident Response
                   V                             |
             / Reference \                       |
(Subject) ---\  Monitor  /---> (Object)          |
                   |                             |
                   V                             |
                  Log --> Event --> Signal --> Alert
                   |
                   V
                  Remote Journaling
  • イベントの種類:
    • 前兆 : 組織の内部状況の変化を示唆する事象からのシグナル
    • インジケーター : セキュリティの懸念がある活動が行われている・行われたことを示唆する事象からのシグナル
  • IoC (Indicators of Compromise) は、侵入、マルウェア、その他の敵対的や危険なイベントが発生している・発生したことを知らせるもの

侵入検知・防御システム (IDS/IPS)

  • 侵入は、組織外の攻撃者からの不正アクセスのこと

インサイダー、アウトサイダー、ゼロトラスト

  • 侵入検知システム (IDS; Intrusion Detection System) : 環境をモニタリングし、意図的な不正アクセスの試みを自動的に検知するソリューション
  • 侵入防止システム (IPS; Intrusion Prevension System) : 環境をモニタリングし、意図的な不正アクセスの試みを認識して自動的に対処するソリューション
  • IDS/IPSの検知手法:
    • 逸脱 : 標準的なアクティビティのベースラインから逸脱したものを疑わしいと判断する
    • シグネチャ : トラフィックに含まれる既知の攻撃パターンを認識する
    • パターンマッチング : 複数のシグネチャなどの組み合わせで攻撃を認識する
    • ヒューリスティック : 機械学習によるベースラインを設定し、逸脱したものを疑わしいと判断する

スレットハンティングとIDS/IPS

  • EDRやXDRは、HIDSやNIDSと比べると、より時間をさかのぼって攻撃を検知することができる
  • すべてのシステムにはセキュリティのトレードオフが存在する
    • IDS/IPSはネットワークトラフィックに遅延をもたらす
    • 侵入防御は可用性にも影響を与える

セキュリティ情報とイベント管理 (SIEM)

  • SIEM (Security Information and Event Management) は、システム内のセンサーからの情報とイベントを集約し、相関して分析することで、イベントをリアルタイムに監視するソリューション
  • (参考):
    • syslogは、ログフォーマットをするシステム
    • syslogは、重大度 (Severity) を設定して、送信するログを決める閾値を設定できる
    • 重大度には、デバッグ、情報、注意、警告、エラー、致命的、警報、緊急 などがある
    • syslogのファシリティコード (ログメッセージの種類) は、どのような状況でログが発生したかを表す番号が指定される
    • ログは、要塞ホスト (Bastion Host) と呼ばれる安全なログサーバに送信することで、ログを侵害から守ることができる

継続モニタリング (ISCM)

  • 情報セキュリティ継続モニタリング (ISCM; Information Security Continuous Monitoring) は、監視によって継続的なアウェアネスを維持し、組織のリスク管理の決定をサポートする
  • NIST SP 800-137 の ISCM のプロセスは次の6段階からなる:
    • 定義 > 確立 > 実装 > 分析と報告 > 対応 > レビューと更新

入口監視と出口監視

  • 入口監視は、着信トラフィックとアクセス試行の監視と評価を行うこと
    • ファイアウォール、ゲートウェイ、IDS/IPS、SIEM、アンチマルウェアソリューションなど
  • 出口監視は、組織のIT環境から出ていくデータを規制するために使う
    • データ損失防止 (DLP; Data Loss Prevension) : 以下の方法で検知してデータ送信を規制する
      • シグネチャ : 特定の文字列を含むとき
      • パターンマッチング : 複数の条件(文字列など)を満たすとき
      • ラベリング : 資産に対して「機密」などのラベルが存在するとき

脅威インテリジェンス

  • 脅威インテリジェンスは、組織の脅威となる攻撃者の能力、動機、目標を分析すること
  • 外部では、ベンダー、政府機関、情報共有分析センター (ISAC; Information Sharing and Analysis Centers) などの第三者機関から脅威情報が提供される
  • 内部では、組織が環境内のシステムや活動を監視した結果を使用する
    • 構成管理データベースとシステムインベントリは、特定の脅威の標的となり得る弱点を持つリソースを特定に役立つ

ユーザとエンティティのふるまい分析 (UEBA)

  • UEBA (User and Entity Behavior Analytics) は、機械学習を利用して組織内のユーザとエンティティのふるまいを分析すること
  • IAM環境だけでなく、システム(エンティティ)の振る舞いについても、長期間にわたる環境モニタリングを通して正常なふるまいのテンプレートを作成することができる

モニタリングの限界

  • 以下の活動に対しては検知できない:
    • ログファイル削除などのイベントの相関関係を崩すための単純な攻撃
    • 警告のしきい値を超えないようにゆっくりと時間をかけて行う攻撃

8-2. 変更管理の実施

変更管理のスタンダードとプラクティス

  • 変更管理 (CM; Change Management) は、現在の状態から未来の状態に移行するためのルール
  • 構成管理において、ベースライン化は、システム全体のインベントリを構成要素や部品ごとに作成すること
  • プロビジョニングは、特定の構成ベースラインを取得し、そのコピーを修正して、あるべき環境に適切に配置するための活動 (新しいインスタンスの構築など)
  • (参考):
    • リクエストコントロール : ユーザが変更をリクエストし、マネージャーが費用対効果を分析し、開発者がタスクの優先順位付けができる
    • 変更コントロール : 実稼働環境にロールアウトする前に、複数の開発者がソリューションを作成してテストできる
    • リリースコントロール : すべての変更が理解され、機能することを確認するための受入テストが含まれる
    • 構成コントロール : ソフトウェアのバージョン変更が、変更コントロールと構成管理プロセスに従って実行されることを保証する

主要な変更管理アクティビティ

  • 変更管理は、「変更要求」から始まり、開発やテストを経て、変更がユーザエンドにリリースされるまでの活動
  • 変更要求 (Request for Change: RFC) は、ユーザからの提案や問題報告をもとに作成される

リリースとデプロイメントの計画とコントロール

  • リリースは、システムや変更パッケージを本番環境に移動させ、エンドユーザがすぐに使用できるようにすること
    • リリースコントロールでは、受け入れテストが確実に行われるようにする
  • デプロイメントは、他の環境との間でコントロール、一覧化、管理された移動のこと

パッチ管理

  • ソフトウェアは、定期的にアップデートが必要
    • サービスパックは、様々なアップデートを集めたもの。Windows OSやアプリのメジャーアップデートなど
  • パッチは、一般的にセキュリティ上の脆弱性に関わる問題であり、ユニットとしてインストールする必要がある
  • パッチを本番環境に当てる際は、組織の変更管理のプロシージャに従うこと
    • 通知 > 評価 > 影響 > テスト > 承認 > バックアップ > パッチ適用 > 運用監視 > 検証 > フィードバック > 文書化
    • 回帰テストでは、変更による異常動作が発生していないことを確認する
    • 検証では、変更をモニタリングし、パフォーマンスが不十分と判断された場合はロールバックする

脆弱性管理

  • 脆弱性管理は、弱点の検知と評価を行うためのプロセス
  • 特定されたシステムの弱点は、構成変更、パッチの適用、運用環境の変更 (ファイアウォールのルール、DLPの設定など) によって対処される
  • (参考):
    • CVE (Common Vulnerabilities) : 共通脆弱性識別子。例 : CVE-2021-44228
    • CVSS (Common Vulnerability Scoring System) : 共通脆弱性評価システム。脆弱性のレベルをスコアで表示する
    • NVD (National Vulnerability Database) : 脆弱性に関する情報を提供する。NISTが提供するSCAPで使用されている
      • SCAP (Security Content Automation Protocol) は、脆弱性とセキュリティ構成情報を取り扱うために使用される一連の仕様

構成管理とコントロール

  • 構成管理は、組織の情報システムを保護するために必要な最低限の管理を定義し、文書化し、実施するための包括的なプロセス
  • 構成アイテム (CI) は、組織のセキュリティの範囲内にある資産
  • 構成管理データベースは、CIの状態を記録するもの

セキュリティベースライン

  • セキュリティベースラインは、最低限必要とされるセキュリティコントロールのセット
  • ベースラインコンフィギュレーションは、安全なシステムやアプリを設計するための出発点として機能する

構成の自動化

  • ツールによる自動化で、セキュリティベースラインの管理や適用を行う

変更管理委員会 (CMB)

  • CMB (Change Management Board) は、変更に関する活動を統括し、ステークホルダの関与と承認のための構造を提供するとともに、変更が適切にリソースを確保して実施されることを保障する
  • 変更管理委員会 (CMB) は、構成管理委員会 (CCB; Configuration Control Boards) とも呼ばれる
  • 変更管理は、以下の3つのプロセスを繰り返している:
    • 構成管理 : システムとその状態を管理する
    • 脆弱性管理 : システムの弱点を特定する
    • パッチ管理 : システムのアップデートをする
+---------- Change Management ----------+
|                                       |
|   Configuration       Vulnerability   |
|     Management  ---->  Management     |
|            ^             |            |
|            \             /            |
|             \           /             |
|              \         /              |
|               \       V               |
|                 Patch                 |
|               Management              |
|                                       |
+---------------------------------------+

執行

  • 組織が言っていることと実際にどのようにオペレーションを管理しているかは、しばしば大きく異なる
  • 優れた変更管理 (CM) を実施するには、経営陣の理解と行動が必要

8-3. インシデントレスポンスの基本概念

  • インシデントは、システムに危害を加える可能性があるイベント(システムの状態の変化)

インシデントレスポンススタンダード

  • NIST SP 800-61 はインシデントレスポンスの活動を4段階のライフサイクルで構成している
    • 準備 > 検知と分析 > 封じ込め、根絶、復旧 > インシデント後の活動
  • ISO/IEC 27035 はインシデントレスポンスの活動を5段階のフェーズで構成している
    • 計画および準備 > 検知および報告 > 評価および決定 > レスポンス > 教訓

組織環境

  • インシデントレスポンスは、インシデントによる情報の損失や盗難、サービスの中断を最小限に抑えること

サイバーフォレンジック

  • フォレンジック調査の段階:
    1. 収集 : 現場を確保し、データの識別、ラベル付け、記録、収集し、その完全性を保持する
    2. 検査 : 適切なフォレンジックツールと技術を用いて検査し、完全性を保護しながら関連する情報を特定して抽出する
    3. 分析 : 検査の結果から原因を分析する
    4. レポーティング : 調査員が行ったアクションの説明、他に必要なアクション、組織のフォレンジックプロセスの改善などが含まれる
  • テクノロジの変化により、サイバーフォレンジックは複雑になっている
  • フォレンジックディスクコントローラは、ディスクへの書き込みを防止し、読み取り専用にするための装置
    • ストレージデバイスに送信されたコマンドに介入して、そのコマンドを修正や破棄する
    • フォレンジックドライブコントローラや、ライトブロッカーとも呼ばれる

8-4. インシデント管理の実施

インシデントレスポンスのアクティビティ

  • インシデントレスポンスは、危害を及ぼす可能性のあるイベントの検知・評価・効率的な対処によって組織の業務への影響を最小限にする

準備

  • 準備 : インシデントが発生する前に行うプロセス
  • インシデント対処するための明確なポリシーは、事前に組織が定めておく必要がある
    • ポリシーは、エスカレーション、情報共有、パフォーマンスの測定、意思決定の権限などに影響する

インシデントマネジメントとSOCの概念

  • SOC (Security Operations Center) は、セキュリティコントロールの継続的な運用管理や監視を行う
  • SOCは、組織の情報システムを保護し、活動を再開させるための技術的な主導権を持つ
  • SOCは、対応と復旧のための法的な力を守るための役割も担う

検知

  • 検知 : 攻撃の最初の兆候を発見するための重要なプロセス

分析

  • 検知システムが適切かつタイムリーに事象を捉えていたとしても、情報の分析が遅れるとインシデントの認識が遅れることがある
  • イベントがインシデントであると判断されたら、対応のために適切な優先順位をつけること

レスポンス (対応)

  • レスポンス : 被害を隔離し、原因を排除し、影響を受けたシステムを復旧させるためのプロセス
  • インシデントレスポンスの進捗に合わせて、根本原因の分析も進める
  • 根本原因分析の種類:
    • パレート分析 : 20%の努力から80%の価値を得る
    • なぜなぜ分析 : 「なぜこれが起こったのか」と尋ねて原因を特定
    • フィッシュボーン (石川) ダイアグラム : 原因に着目した可視化ツール
    • 故障モード影響分析 : 体系的に構成要素の不具合を特定
    • フォールトツリー : ブール理論を用いて不具合を特定
  • (参考):
    • 自動復旧 : システムは、複数の障害に対して自己復旧できる
    • 過度のデータ損失が発生しない自動復旧 : 自動復旧に加えて、データを損失から保護することもできる
    • 機能復旧 : システムは、自動的に機能プロセスを復旧できる
    • 手動復旧 : 管理者により手動で動作を復元する

緩和

  • 緩和 : 封じ込めと根絶という2つの独立した作業からなるプロセス
  • 封じ込め : 隔離や無効化などをすること
    • セキュリティコントロールのベンチマーク、フレームワークなどを使ってシステムのハードニングを行う
  • 根絶 : 原因となるファイルを特定してシステムから削除すること

復旧 (修復) と是正

  • 復旧 : システムやデータが再構築されて運用可能であると宣言されるプロセス
  • 是正 : インシデントの再発の可能性を制限・低減するための構成変更のプロセス

レポーティング (報告)

  • インシデント対応が終了したら、関係者全員に復旧作業が完了したことを知らせる

レビューと改善 (教訓)

  • IRのプロセス自体を分析し、改善を行う
  • 教訓のプロセスは罰則ではなく適切な雰囲気を設定しなければならない
  • 学んだ教訓についての会議は審問会ではなく学びのイベントであり、経営陣はその期待に応えなくてはならない
  • 教訓が文書化されると、その報告書は経営陣がプロセス改善活動を推進するために利用できる

セキュリティのオーケストレーションと自動化によるレスポンス (SOAR)

  • SOAR (Security Orchestration, Automation, and Response) は、発生するインシデントの原因がわかっていて解決策も明確になっている場合に、これらの対応を自動化することで復旧を早めること

8-5. 検知策と防止策の運用と維持

ツールと技術

  • 許可リストとブロックリスト
  • ファイアウォール、IDS、IPS
  • サンドボックス
  • ハニーポットとハニーネット
    • ハックバック (自分の組織をハッキングした悪意のある攻撃者をハッキングすること) は違法行為。多くの司法では、ただのハッキングと同等の行為とみなされる
    • 疑似欠陥は、攻撃者を引き付けるためのシステム内の偽の脆弱性のこと
  • アンチマルウェア防御
  • ランサムウェアとランサム攻撃
  • 機械学習(ML)と人工知能(AI)ベースのツール
  • SDS (Software Defined Security) : 仮想化することでハードウェア依存を減らすことができる
  • スマートフォン(スマホ)を紛失した・盗難された場合:
    • 端末の完全暗号化とパスコードの必須化によって、機密性を保証できる
    • リモートワイプとGPSトラッキングは、端末がセルラーネットワークやWi-Fiに接続した場合のみ有効

8-6. バックアップとリカバリー戦略の導入

バックアップストレージ戦略

  • BC/DRの取り組みを推進するには、正確で包括的なバックアップが役立つ
  • バックアップは、CIAの可用性を保証する

最低限の保護

  • 3-2-1バックアップ戦略:
    • 3つのデータコピー : 元データと2つのバックアップ
    • 2種類のストレージメディアタイプ : 片方は、磁気テープ、リムーバブルディスク、クラウド などにコピーする
    • 1つのオフサイトコピー : コピーは十分離れた場所に置いておく

バックアップロケーション

  • オンサイト : 記憶媒体が本番の施設に置かれている
  • オフサイト : 十分離れた堅牢な場所に保管する
  • クラウド : BaaS (Backup-as-a-Service) などを使用する

バックアップの種類

  • 各方法はバックアップとリストアに必要な時間が異なる:
    • フルバックアップ : すべてのデータを取得する。アーカイブ完了後に対象データのアーカイブビットを0にする
    • 差分バックアップ : フルバックアップ以降の差分を取得する。アーカイブ完了後に対象データのアーカイブビットを1のままにする
    • 増分バックアップ : 前回のバックアップからの増分を取得する。アーカイブ完了後に対象データのアーカイブビットを0にする
                        +--+ ^      ^
                        |  | | Incr |
           +--+ - - - - +--+ v      | Diff
Full       |  |         |  |        |
+--+ - - - +--+ - - - - +--+        V
|//|       |//|         |//|
|//|       |//|         |//|
+--+       +--+         +--+
  • データを対象としたバックアップ戦略:
    • ジャーナリング : コミット毎にトランザクションをログに書き込み、指定のコミットまでロールバックできる
    • スナップショット : 仮想化されたストレージ環境を利用して、メディア上のデータブロックのミラーを取得する
    • 継続的データ保護 (CDP; Continuous Data Protection) : データブロックが変更されるたびに、そのブロックがスナップショットされる
  • バックアップ媒体のローテーション戦略:
    • GFS (Grandfather/Father/Son) 方式 : あらかじめ設定されているローテーションのサイクルに合わせて、日、週、月の単位でバックアップを実行する
    • ハノイの塔方式 : 古いデータは少しだけ、新しいデータはたくさん、バックアップを残す方式。バックアップは時間が経つにつれて価値が下がるため
    • Six Cartridge Weekly Backup方式 : 月曜日から木曜日に増分バックアップを取得し、金曜日にフルバックアップを取得する
  • データベース復旧手法の種類:
    • リモートジャーナリング : スケジューリングされた時間(1時間ごと)にトランザクションログをリモートサイトに自動転送する
    • リモートミラーリング : プライマリーDBのすべてのトランザクションをリモートサイトにミラーリングする
    • 電子ボールティング : スケジューリングされた時間(毎日)にプライマリーDBからリモートサイトにバックアップを自動転送する

その他のバックアップに関する検討事項

  • バージョン管理
  • 検証によって、完全性チェックによる改ざんや変更の有無を確認できる

復旧サイト戦略

  • 実運用環境が業務に適さなくなった場合、別の場所を使用する

代替ロケーションの種類

  • ミラー (複数処理サイト) : ミラーサイトは、プロダクションサイトと並行して運用されるサイト。高い可用性を提供する
  • ホット : 必要なハードウェア、ソフトウェア、データを完備した運用サイト。ホットスタンバイ状態
  • ウォーム : 最新バージョンがなく、すぐには運用できないサイト。共有ストレージと復旧用バックアップを運んでくることで運用できるようになる
  • コールド : 電源、空調、接続設備を備えた空き施設
  • モバイル : 車に搭載したり運ばれたりするポータブルなサイト。場所の制限がない
  • クラウド : クラウドコンピューティングのサービスプロバイダに運用サイトがある。任意の場所から業務を再開できる
  • 共同操業協定 (JOA; Joint Operating Agreement) / 覚書 (MOU; Memorandum Of Understanding) : 環境が破壊された場合にパートナーと活動拠点を共有する。政府機関など

システムのレジリエンス、高可用性、サービス品質(QoS)、フォールトトレランス

  • 十分な予備コンポーネントを準備する
  • クラスタリング : システムを組み合わせて1つのシステムが停止しても常に稼働できる
    • クラスタリングモードの種類:
      • アクティブ/アクティブ : クラスタ内の全システムが通常の運用で稼働している
      • アクティブ/パッシブ : 障害が発生した場合にのみオンラインになる
    • フェイルオーバー : エラー発生時に自動的に予備システムに切り換えること
    • フェイルオープン : エラー発生時にトラフィックフローの処理方法を選択すること (防御システムの再起動中は検査なしで通すことで可用性を維持する)
    • フェイククローズ : エラー発生時に全ての活動を停止させる保守的な障害管理方法
  • 電気は、可用性を支える重要な要素
    • 電力
    • 無停電電源装置 (UPS; Uninterruptible Power Supplies)
    • 発電機

ストレージ

  • RAID:
    • RAID 0 : ストライピングのみ
    • RAID 1 : ミラーリング
    • RAID 5 : データとパリティビットを複数のディスク間でストライピングする (故障は1台まで許容可能)
    • RAID 6 : データと2組のパリティビットを複数のディスク間でストライピングする (故障は2台まで許容可能)
  • 集中データストレージ:
    • SAN (Storage Area Network) : 複数のストレージをまとめて1つのボリュームストレージを提供する
    • NAS (Network-Attacked Storage) : 多数のユーザがアクセスするファイルサーバ

8-7. サイトと施設の設計へのセキュリティ原則の適用

防犯環境設計 (CPTED)

  • CPTED (Crime Prevention Through Environmental Design) は、犯罪の課題を組織的、機械的、自然的デザインの手法で解決するためのもの

サイト計画

  • 一般的に、組織の主要な拠点は、セキュリティではなくビジネス上の理由で選択される
  • 代替サイトは、主要な拠点とは地理的に異なる場所にし、災害に強い場所にする

可用性

  • 物理セキュリティを達成するために、必要な時に必要な方法で必要な場所にアクセスできなければならない

建築基準法

  • 建築物の安全性を確保するための建築主の責任

データセンタースタンダード

  • Uptime Institute's Tier Classification System : 施設の認証を行う業界団体
    • Tier I : 基本的なサイトのインフラである
    • Tier II : 冗長サイトの構成部品がある
    • Tier III : 同時進行でメンテナンス可能なサイトインフラである
    • Tier IV : フォールトトレラントなサイトインフラである

8-8. サイトと施設のセキュリティコントロール

ワイヤリングクローゼット/中間配線施設

  • 配線インフラストラクチャやケーブルプラントは、ネットワークの物理層へのアクセス保護の対象

サーバルーム/データセンター

  • データセンターは、高レベルの物理的セキュリティを維持する必要がある
  • データセンターは、サージ保護装置やUPSなどの電力面も考慮する必要がある
  • データセンターは、建物の中央の階に配置する。下層階では洪水や物理的侵入、最上階では風や屋上の損傷の影響を受けやすくなる

ストレージメディアの保護と管理

  • メディア保存施設では、耐火/防水容器を使用することを推奨する
  • 温度と湿度はメディアの保存要件に合わせる
    • ハードウェアの寿命を最適化するための温度の範囲は、18~27℃
    • 湿度は40〜60%が適切。40%を下回ると静電気が発生しやすくなり、機器への損傷リスクが上がる

証拠の保管と管理の連鎖

  • 施設または部屋ごとにアクセスを厳格に制限する
  • 積極的にモニタリングを行う場合もある
  • 管理の連鎖 (Chain of Custody) を常に維持する

制限された作業エリアのセキュリティ

  • 機密性の高い作業を行う場所や、センシティブ情報を保存する施設では、制限エリアのセキュリティが適用される
  • 機密隔離施設 (SCIF) は、セキュアな施設や極秘の作業場所などのこと

ユーティリティ、暖房、換気、空調 (HVAC)

  • HVAC (Heating, Ventilation, and Air Conditioning) は、スタンダードに基づいて制御すること
  • HVACは、冗長構成にすること

火災の予防、検知、および抑制

  • スポット型煙検知器は、イオン化や光電セルを使用して火災を検知する
    • イオン化は、2枚の帯電した板の間を空気が通過する際の電流を測定することで煙を検知するもの
    • 光電セルは、煙の粒子による光の変化を測定するもの
  • 超高感度煙検知 (VESDA; Very Early Somke Detection Apparatus) システムは、吸引式センサーを使用する
    • 吸引式センサーは、周囲の空気を少量ずつ吸い込み続けて煙を検知する
  • 火災の特徴の種類:
    • クラスA : 通常の可燃物(紙や木など)
    • クラスB : 可燃性液体(石油製品など)
    • クラスC : 電気 (消火時は水ベースではなくガスベースの消火器を使用する)
    • クラスD : 燃えやすい金属(マグネシウムなど)
    • クラスK : 業務用調理器具
  • 消化方法には、水系とガス系と乾燥粉末の3種類ある
  • 水系システムの種類:
    • ウェットパイプ : 管が水で満たされており、熱でスプリンクラヘッドが作動する
    • ドライパイプ : 管が水で満たされていない。ウェットパイプより作動に若干の遅れがある。凍結のリスクが減るため、屋外などで使用される
    • プレアクション : 火災センサーによって管を水で充填させ、熱でスプリンクラヘッドが作動する
    • 一斉放水 : プレアクションに似ているが、スプリンクラヘッドは常に開放されたままになっている
    • 水性発泡消火剤 (AFFF; Aqueous Firefighting Foam) : 水溶性の発泡剤を利用する
    • 予作動式消化システム : 火災の初期兆候が検知されると配管に水が供給されて、スプリンクラーヘッドの熱センサーが検知すると放水する
    • 水は、炎の温度を低下させる
  • ガス系システム:
    • 二酸化炭素やハイドロフルオロカーボンなど
    • ガスは、酸素供給を遮断する
  • 乾燥粉末による消化システム:
    • 濃硫酸や炭酸水素ナトリウムなど
    • 乾燥粉末は、燃料の供給を遮断する

電力

  • 冗長化された二重電源(複数の発電所)
  • バックアップ用の発電機
  • (参考):
    • スパイク : 瞬間的に高電圧が流れること
    • サージ : 長期にわたり高電圧が流れること
    • ブラウンアウト (サグ) : 低電圧になっている時間のこと

境界セキュリティコントロール

  • 境界の移動時には、セキュリティコントロールを使用する
  • CCTV(監視カメラ)や人感センサーなど

内部セキュリティコントロール

  • 施設の境界内でもセキュリティ対策を行う
  • カードリーダ、磁器作動式スイッチ、音響センサー、赤外線センサーなど
    • パッシブ赤外線センサーは、赤外線検知器を使って侵入者の熱を検知する
    • 赤外線リニアビームセンサーは、赤外線のビームを送り、物体に跳ね返ってくる信号の変化を監視する
    • 波形モーション検知器は、超音波またはマイクロ波の信号を送り、物体に跳ね返ってくる信号の変化を監視する

8-9. 従業員の安全とセキュリティの概念

  • 移動時や移動後のリスクを考慮すること
  • 最も重要なことは、健康と人々の安全
  • 危機管理 : 個人の安全を最優先事項として考慮に入れる
  • 強迫 (Duress) への対応と、サイン (連絡手段) の確立
  • モバイルデバイス管理 (MDM) は、紛失した・盗難されたデバイスのコンテンツ削除にも使える


9. 全チャプターのまとめ

9-1. セキュリティガバナンス:究極の管理的コントロールのセット

ガバナンスから業務遂行へ

  • ガバナンスの重要な側面の1つは、組織の全体的な目標と目的を、セキュリティと資産保護の目標と目的にリンクさせること

ポリシー

  • ポリシーは、上級管理職によって組織に提供される指示や意思表示

プロシージャ

  • プロシージャは、特定のタスクを達成するために必要な反復可能な活動を定義するもの

ガイドライン

  • ガイドラインは、期待される活動を明確にし、タスクや目標を達成するための代替手段を提供する助言的な情報
  • ガイドラインは、ベストプラクティスを提供するだけで、遵守すべき義務ではない

スタンダード

  • スタンダードは、広範で戦略的なものから、詳細な属性を規定するものまで存在する
  • スタンダードの具体的な内容を実行するために、運用プロシージャに落とし込む必要がある

ガバナンスフレームワーク

  • ISO 270XX シリーズ : 包括的なガバナンスフレームワーク
    • ISO 27002は、情報セキュリティに関する国際規格
  • COBIT (Control OBjective for IT) : 企業のITとセキュリティ機能を管理するためのガバナンスフレームワーク
    • COBITの5つの原則 : (1) ステークホルダーのニーズを満たす (2) 事業船体を包含する (3) 統一されたフレームワークを適用する (4) 包括的なアプローチを実現する (5) 管理からガバナンスを分離する
  • ITIL (IT Infrastructure Library) : ITサービス配信に関する一連のベストプラクティス
    • ISO 27002に基づいて作成されている

9-2. 運用されているセキュリティフレームワーク

プライバシーフレームワーク

  • EU一般データ保護規則 (GDPR; General Data Protection Regulation) : EU域内にある個人情報をEU域外に出す際のルール。個人情報の保護レベルが十分でない国を考慮した対策
  • プライバシーマネジメントフレームワーク (PMF; Privacy Management Framework) : 米国公認会計士協会が発表したもの。GDPRなどの基準が組み込まれている
  • OECDプライバシーガイドライン : 経済協力開発機構 (OECD; Organisation for Economic Co-operation and Development) が公開しているガイドライン

サイバーセキュリティフレームワーク

  • ISO 270XX
  • リスクマネジメントフレームワーク (RMF):
    • 準備 > 分類 > 管理策の選択 > 実装 > アセスメント > 運用認可 > 監視
  • HITRUST Common Security and Privacy Framework (CSF)
  • CSA STAR : (Cloud Security Alliance – Security, Trust, and Assurance Registry) クラウドセキュリティに関するスタンダードやツールを公開しているボランティア組織

リスクフレームワーク

  • ISO 31000, ISO 27005
  • COSO : 財務報告の規則違反や不正行為に対するガイドラインやプラクティス
  • ISACA RISK IT
  • NIST SP 800-37

セキュリティコントロールフレームワーク

  • SCF (Security Control Framework) は、活動範囲内でのセキュリティコントロールの実装と運用を行うために必要最小限の演習を提供する
  • ギャップ分析は、評価・査定ツールとしてSCFを使用するためのアプローチを構造化された形で提供する

9-3. フォレンジック調査

調査の完全性の維持

  • フォレンジック調査では、その調査の完全性の保護が最重要

証拠の収集と取り扱い

  • アーティファクトは、通信機器やシステム要素や物理的なオブジェクトなど。たとえインシデントとは無関係なものでも証拠となりうるもの
  • 証拠カストディアンの任命 : デジタルフォレンジック調査で初めにやることは、カストディアンを任命すること
    • カストディアンは、管理の連鎖を維持する責任を持ち、問題が解決するまで関連する全ての証拠の処理を取り締まる
  • 管理の連鎖の維持 : 証拠は収集されてから法廷に提出されるまでの間、セキュアに扱い、維持する必要がある
  • バックアップの使用 : HDDなどはビットレベルでコピーする
  • 証拠の連鎖は、インシデントの一部として人や証拠品が関わる場所、動き、活動を段階的に説明したもの、またはタイムライン

報告と文書化

  • 証拠に基づいた報告書は、客観的にインシデントや状況の全体像を説明するのに十分な情報やサンプルを含めること
  • 証拠を提示するとき、以下の信条に従うこと:
    • 認容性 (忍容性) : 裁判所が認めた証拠のみ提示できる
    • 正確性 : 根拠は真実で明確であること
    • 網羅性 : 不利な証拠を除外しないこと
    • 客観性 : 証拠は事実に基づいて説明すること。主観的な意見を紹介しないこと
  • インシデントレスポンスの「報告」フェーズでは、法執行官や規制当局にも報告するかを判断する

調査手法

  • 自動キャプチャ : データやログの収集
  • インタビュー : 意識啓発の調査
  • 手動キャプチャ : 音声インタビュー、インシデントの現場、対応プロセスの写真、ビデオ撮影
  • 外部の依頼 : 通信事業者などへ情報を要求する

デジタルフォレンジックのツール、戦術、プロシージャ

  • デジタルフォレンジックの原則:
    • 全てを文書化する
    • 記録されていない・意図しない修正を避ける
    • 証拠の維持

調査の種類

  • 調査の種類:
    • 行政調査 (管理調査, 内部調査) : インサイダー活動の調査。プロセスの全てが組織内に収まる
    • 民事調査 : 裁判所が関与する調査。「証拠の優越性 (preponderance-of-the-evidence)」基準を使用する
    • 規制調査 : 規制当局による調査。地域において適切な基準を使用する
    • 刑事調査 (犯罪調査) : 法執行機関による調査。「合理的な疑いの余地のない (beyond-the-reasonable-doubt)」基準を使用する

証拠に関する原則 [追加]

  • 口頭証拠ルール (口頭証拠排除原則, Parol Evidence Rule) : 書面の契約がすべて
  • 最良証拠ルール (最良証拠原則, Best Evidence Rule) : コピーの証拠よりもオリジナルを優先する
  • 伝聞証拠ルール (伝聞証拠禁止の原則) : 他人の話したことは原則として証拠にならない

9-4. 事業継続と災害復旧 (BC/DR) 要件に対応する組織的能力の構築

適切なBCスタンダードの選択

  • NIST SP 800-34
  • ISO 223XX セキュリティとレジリエンス

ビジネス影響度分析 (BIA)

  • BIA (Business Impact Analysis) は、組織が保有する資産の価値、資産を失う潜在的なリスク、組織に影響を及ぼす可能性の高い脅威、脅威が現実となる可能性を判断する取り組み

BC要件の特定と優先順位付け

  • 事業継続性 (BC) は、有事の際に組織が重要な業務を継続できるようにするための行動、プロセス、ツール
    • 意識啓発トレーニングは、初期段階の障害を検知するために、全社員に実施する
  • 災害復旧 (DR) は、組織を緊急時の運営から通常の運営に復帰させるための作業や活動
    • バックアップは、災害復旧計画の取り組みの一環として行う
  • 優先順位付けは、ビジネスの種類、内部・外部からの要請によって変化する

事業継続計画および災害復旧計画の要素

  • 事業継続計画は、プライマリサイトで何らかのインシデントが起きた時に、以下を実施する計画のこと:
    1. プライマリサイトで事業を続けるために緊急時対応計画 (コンティンジェンシープラン) を実施する
    2. 緊急時対応計画で対応できないときは災害宣言をして災害復旧計画を実施し、バックアップサイトに移動する
    3. 最終的にプライマリサイトに戻るために回復計画を実施する
+------------ Business Continuity Planning -----------------+
|                                                           |
|                             +------+                      |
|                             V      | 1. Contingency Plan  |
|                 (Primary Site) ----+                      |
|                            |                              |
|                  ^         |                              |
|                  |         | 2. Disaster Recovery Plan    |
| 3. Recovery plan |         |                              |
|                  |         V                              |
|                 (Backup Site)                             |
|                                                           |
+-----------------------------------------------------------+
  • 事業継続計画におけるプロジェクトの範囲と計画策定フェーズでは、以下の4つの活動を行う:
    • (1) 組織の構造化分析 (2) BCPチームの結成 (3) 利用可能なリソースの評価 (4) 法規制状況の分析
  • 最大許容停止時間 (MAD; Maximum Allowable Downtime) : 損害を与えることなく停止できる最長時間
    • MADは、MTD (Maximum Tolerable Downtime) とも呼ばれる
  • 復旧時間目標 (RTO; Recovery Time Objective) : 障害発生後から運用に戻すまでの時間。事業影響度評価によって決まる
  • 復旧時点目標 (RPO; Recovery Place Objective) : 復旧作業中に失われる可能性のあるデータの最大量を時間で表す
  • 作業復旧時間 (WRT; Work Recovery Time) : 障害期間中にできなかった通常業務や移行などの作業
                    MAD
           |<--------------------->|
           |       MTD        WRT  |
           |<------------->|<----->|
     RPO   |         RTO   |       |
|<-------->|    |<-------->|       |
|          |    |          |       |
o----------x----o----------o-------o
^          ^    ^          ^       ^
Normal     |    Detect     |       Recovery
           Incident        Restoration
  • 事業継続計画プロセスの目標は、復旧時間目標 (RTO) が最大許容停止時間 (MTD) よりも短くすること (RTO < MTD)

災害復旧プロセス

  • 組織のニーズに合わせて、BC/DR計画をカスタマイズする
  • 災害復旧では、事業を継続するためにバックアップサイトに移動する
  • 復旧作業によって、プライマリサイトが使用可能になったら、プライマリサイトに移動する

トレーニングとアウェアネス

  • BC/DRタスクに割り当てられたメンバーは、それぞれの役割に応じたトレーニングを受ける必要がある
  • 復旧から学んだ教訓:
    • システムが正常に戻ったら、全てのイベントログを見直して混乱の中での経験から教訓を得ること
  • コンプライアンス要件:
    • 全ての組織は、何らかの外部の規制の下(契約や法律など)で活動している
    • 特定の分野では、BC/DR がコンプライアンス要件になっている
  • BC/DR計画を評価するには、それをテストして計画が意図通りに動作するかを確認すること
  • 読み合わせとテーブルトップは、DRの担当者と司会者のみが参加するロールプレイング活動
    • シナリオは、口頭で説明する
    • 机上演習は、低コストで任務に慣れていない担当者のトレーニングに適している
  • ウォークスルーは、用意されたシナリオに沿って参加者は対応活動のために訪れる必要のある場所に移動する
  • シミュレーションは、特定のオフィスや場所にいる従業員全員が用意されたシナリオ上の緊急事態に対応する
    • 避難訓練など
  • 並行 (パラレル) 演習は、代替サイトから実際に運用するまでの作業を実施する
  • フルインタラプション (完全なシステム中断) は、実際にシステムを停止させて対応する
    • 最もリスクとコストがかかる選択肢のため、組織への影響も大きい

9-5. 人的セキュリティポリシーおよびプロシージャへの貢献と執行

候補者の選考と解雇

  • スクリーニングは、組織に悪影響を与える可能性のある候補者を特定して採用を控える
  • 採用時は、バックグランドチェックを行う

審査・採用における特殊事情

  • 会社の倒産によって前職の情報が入手できず、審査・採用が十分に行えない状況も考えられる

採用契約と雇用ポリシー

  • 従業員ハンドブック : 従業員が一連のポリシーとスタンダードを文書化したもの
  • 雇用契約書
  • 秘密保持契約 (NDA; Non-Disclosure Agreements)

新人受け入れ、異動、退職のプロセス

  • 新人受入れには、契約の条件や仕事内容の確認、組織のセキュリティポリシーやプロシージャを教えるトレーニングが含まれる
  • 退職には、直前にシステムやデータに変更を加えられないようにし、組織の財産を従業員から回収する

コンプライアンスポリシー要件

  • 組織は全ての担当者に対して、許容範囲内の使用ポリシー (AUP; Acceptable Use Policies) を適用する
  • AUPは、資産の適切かつ承認された使用方法をユーザの想定される観点から詳細に説明する

プライバシーポリシー要件

  • 職員が PII (健康産業では PHI) にアクセスできる場合、取り扱いに関する組織のポリシーとプロシージャを文書化し、法的な影響を認識させること

秘密保持契約 (NDA; Non-Disclosure Agreements)

  • NDAは、機密情報や営業秘密を保有する業界において、従業員が開示してはならないデータを指定して行う両当事者間の法的な合意
  • NDAの種類:
    • 一方向のNDA
    • 相互NDA
    • 多角的NDA
    • 競業避止義務契約 : 労働者が所属する企業と競合する企業への就職や会社の設立を禁止する

ベンダー、コンサルタント、契約者との合意と管理

  • 組織は、従業員以外のアクセスを区別し、適切に規制するプロシージャやプロセスを作成する
    • 契約上の保護
    • 秘密保持契約、競業避止義務契約
    • 区別された制限付きアカウント(ゲストアカウント)
    • エスコート要求(従業員の立ち合い)
    • 身元確認

9-6. リスクマネジメントの運用

フレームワークからワークフローへ : リスクマネジメント

  • リスクマネジメントは、組織が使用しなければならない全ての時間または意思決定を網羅する一連の計画・実行・評価・改善のサイクル
    • NIST Cybersecurity Framework (CSF) では、識別 > 防御 > 検知 > 対応 > 復旧 の順番で作業する

リスクマネジメントにおける4つの視点

  • (1) 資産ベース (2) 成果ベース (3) 脆弱性ベース (4) 脅威ベース

リスクに関する定義

  • リスク : 組織にマイナスの影響を与える可能性のある出来事
    • リスクは、脅威と脆弱性を組み合わせたもの
  • ハザード : リスク事象が偶発的に意図的でなくても発生する可能性があるもの
  • 脆弱性 : システムに内在する弱点や欠陥。これを使用されるとリスク事象が発生する可能性があるもの
  • 脅威 : 目的を達成するために脆弱性を悪用する人や集団

リスク対応 : 4つの選択肢

  • リスクへの準備や対応の前に2つの決定をする必要がある
    1. リスクの優先順位付け
    2. 緩和 (Mitigate)・回避 (Avoid)・移転 (Transfer)・受容 (Accept)
      • ISO 27005 : 2018 では「緩和」を「修正」、「移転」を「共有」に変更している
  • リスク低減 (緩和) : リスク事象の発生の可能性やその影響を防止・低減すること
    • 是正は、システムやプロセスの修理・変更のことで、リスク事象に関する脆弱性を低減・除去する
  • リスクには、どれだけ時間とお金を投入しても低減できないものが存在する
  • 残存リスクは、全てのセキュリティコントロールを実施した後に残るリスク
  • リスク回避 : 組織の活動の一部または全てを中止すること
  • リスク移転 : リスクによる損害金額の一部を他の当事者が支払うこと(保険)
    • ISO 27005 : 2018 では、クラウドなどとの契約による「リスクシェアリング」に名前が変わった
  • リスク受容 : リスクを相殺するのに十分な利益があるという理由で、リスクに対する活動をそれ以上取らないこと
    • 受容するまでの意思決定プロセスは、監査人に説明できるように文書化しておく
  • リスクの露出(リスクエクスポージャー)は、リスクマネジメントの概念で以下の意味を持つ言葉:
    • 露出ウィンドウ : リスクイベントの発生確率を時間的に測定するもの
    • 露出ファクター (EF; Exposure Factor) : リスクイベントが発生したときに、組織の資産や成果の価値が下がる割合。被害額/資産価値 で計算できる。危険係数とも呼ばれる

リスクアセスメントと分析

  • 定性的リスク評価(高・中・低などのラベル)と定量的リスク評価(確率などの数値)
  • 定性的リスクアセスメントでは、発生可能性 (確率) と影響を組み合わせて評価する
  • 定量的リスクアセスメントでは、予想損失額を求め、提案された対策の費用対効果を分析する

シミュレーションとリスク評価

  • シミュレーションを使うことで、複雑な意思決定に伴う不確実性を低減する

リスク評価と対策の決定

  • ALE = SLE × ARO
    • 単一損失予測 (SLE; Single Loss Expectancy) : 1回のリスクイベントで予想される損害金額
    • 年間発生率 (ARO; Annual Rate of Occurrence) ; 1年間でリスクイベントが発生する確率
    • 年間損失予測 (ALE; Annual Loss Expectancy) : 1年間で予想される損害金額
  • SLE = AV × EF
    • 資産価値 (AV; Asset Value) : 資産の評価額
    • 露出ファクター (EF; Exposure Factor) : 0〜100%。リスクイベント発生後の資産の評価額に対する損害の割合

脅威モデリング

  • 代表的なものに Microsoft 社の STRIDE がある
    • Spoofing (なりすまし)
    • Tampering (改ざん)
    • Repudiation (否認防止)
    • Information disclosure (情報漏洩)
    • Denial of Service (サービス妨害)
    • Elevation of Privilege (権限昇格)
  • その他の脅威モデル
    • OCTAVE
    • TRIKE
    • 低減分析 : システムを、信頼境界、データフローパス、入力ポイント、特権操作、セキュリティコントロール の5つの要素に分解して分析する
  • 脅威モデリングは、どのような脆弱性がどこに存在するかという問題を確認するために行う

対策の選択と実施

  • 各セキュリティコントロールは、運営に対して何らかのマイナスの影響を及ぼすことがある

管理策の選択 (セキュリティとプライバシー)

  • セキュリティコントロールアセスメント (SCA; Security Control Assessment) は、組織がリスク・脅威・統制プログラムに対して実施しなければならない定期的なレビューの一覧
    • 一般的には、セキュリティコントロールを評価するための米国政府のプロセスを指す
    • セキュリティテストと評価 (ST&E) のプロセスと組み合わされる

9-7. ITサプライチェーンリスクマネジメント (SCRM) の概念の適用

ハードウェア、ソフトウェア、サービスに関連するリスク

  • ハードウェア : 購入する全ての機器についてレガシーシステムが存在するリスクが懸念される
  • ソフトウェア : 使用する全てのソフトウェアについてバグや不適切な設計による機能が含まれている可能性がある
  • サービス : サプライヤーが攻撃されるリスク

第三者による評価とモニタリング

  • サプライチェーンにもリスク管理手法を適用する必要があるが、多くの場合は維持が困難
  • 外部組織のセキュリティ評価についてのスタンダードや監査方法:
    • ISO認定の監査 : 対象の組織向け
    • CSA STARの評価 : クラウド事業者向け
    • AICPA SSAE 16 : 米国基準のSOCレポート
      • SSAEは、受託業務を行う会社の内部統制の有効性を評価する保証基準
      • SSAEは、米国公認会計士協会が定めたもの
      • SSAEは、古い基準である SAS を置き換えたもの
  • 米国でのTrusted Foundry (信頼できる工場) プログラムは、サプライチェーンを保護するのに役立つ

最低限のセキュリティ要件

  • 適切なレベルのセキュリティを確保するには、期待される結果に対する基本的な理解が必要

サービスレベル要件

  • SLA : どのような条件でいつ何が提供されるかの最低限の要件を定める
  • 客観的な数値の評価基準を使って、SLAが満たされているかを確認する
  • 災害時の応答/復旧のように、ほとんど発生しないイベントは、SLAに含めないで契約書にのみ含めること
    • クラウドサービス : データの位置と可用性、BC/DRソリューション
    • データセンター : 物理的セキュリティ、内部監査統制

9-8. セキュリティアウェアネス、教育、トレーニングプログラムの確立と維持

アウェアネスおよびトレーニングの方法と技法

  • コンピュータベーストレーニング (CBT; Computer-Based Training) : 自分のペースで受けられる
  • ライブトレーニング : 特定の時間に会議を開く
  • オンライン同期トレーニング : バーチャルコラボレーションプラットフォームを利用する
  • 報酬制度 : 適切なパフォーマンスに対して報酬を与える
  • ゲーミフィケーション : セキュリティアウェアネスプログラムにゲーミフィケーションを組み合わせる

定期的なコンテンツレビュー

  • トレーニングやアウェアネスの教材の内容は、最新のものにすること
    • 法令、最近流行した攻撃、セキュリティツールと技術などを含める

プログラムの有効性評価

  • ユーザ参加型 : 研修終了後にテストや監査、抜き打ち検査、アンケートなどを利用して評価する
  • ソーシャルエンジニアリング対応 : ソーシャルエンジニアリングを使った模擬的な攻撃を試して、訓練を受けた従業員がそれに応じて反応するかを確認する。意識啓発にも役立つ
  • ログレビュー : ユーザのイベントログを調べて、その活動がトレーニングで伝えたポリシーに従っているかを確認することで、従業員の振る舞いを評価する


Appendix.

CISSPとしての考え方

  • Q. いつからセキュリティ対策を考えるのか?(When)
  • A. システムの用件定義などの早い段階から検討する。一番良いのはライフサイクルの中にセキュリティを組み込むこと
  • Q. どこをセキュリティ対策すべきか?(Where)
  • A. 定量的評価では価値の高い資産から順に、定性的評価では発生可能性と影響を考慮して、優先順位を付けて守る。全てを守る必要はない
  • Q. どの立場からセキュリティを考えるのか?(Who)
  • A. 経営者の視点からセキュリティ対策を考える。技術の安全な利活用の方法とビジネスへの貢献を考える
  • Q. 何を最優先に守るべきか?(What)
  • A. 健康と人命が最優先。人を守れない組織に、資産を守ることはできない
  • Q. なぜセキュリティ対策をするのか?(Why)
  • A. 最低限の安全確保をして最大限にITを利活用するため。対策費用が予想被害額よりも高くてはいけない
  • Q. どのようにセキュリティ対策をするのか?(How)
  • A. 範囲を決めてガイドラインや国際的なスタンダードなどのベストプラクティスを実施する。次に、少しずつ手順を組織に合うように調整していく
  • Q. どのくらいセキュリティ対策が必要なのか?(How much)
  • A. 攻撃を完全に防げる対策は存在しない。しかし、攻撃者を諦めさせる対策や侵入を遅らせる遅延策の組み合わせでも十分効果がある