CISSP勉強メモ - Domain6

📒概要

セキュリティ評価とテスト。

• セキュリティ対策の有効性の評価
• ソフトウェアのテスト
• セキュリティライフサイクルにおける「評価」フェーズ
• 監査

🔍スキャン

アクティブスキャンとパッシブスキャンがあり、その手法の違いやメリットデメリットを理解する。

• アクティブスキャン
  • 積極的にデータを送信しその返答を解析する手法
  • オープンポートや動作中のソフトウェア、OS等の情報を収集する
  • システムに負荷を与える場合がある
  • ポートスキャン
    • nmap, Nikto, Nessus
    • UDPスキャン
      • UDPポートのスキャン。UDPなので応答がない場合もある。ICMP到達不能エラーの場合は閉じているとわかる。
    • TCP Connect
      • 3wayハンドシェイクを完了する。検知されやすい
    • SYNスキャン
      • コネクションを開くよう要求する。SYN/ACKが返ってきたらそのポートが開いていることがわかる。RSTを送信して中断する。
    • ACKスキャン
      • 既存接続を装い、対象ポートがどのように反応するか観察する。FWの規則などの構成を予想できる。
    • ICMPスキャン
      • ping。デバイス検出。サービスまではわからない
    • Xmasスキャン
      • FIN,URG,PSHの三種類のフラグが立ったパケットを送信。このフラグが同時に立っている状態は矛盾している状態のため、このパケットが処理されることはないが、対象ポート上でサービスが動いていた場合はパケットは破棄されサービスが動いていない場合はRSTパケットが返される。
    • サービスフィンガープリンティング
      • ネットワーク上のサービスやプロトコルを特定し、それらが動作しているシステムの種類やバージョンを識別するプロセス
• パッシブスキャン　
  • データは送信せず、普段の通信を監視して情報を収集する手法
    • トラフィックの分析
    • Wireshark
    • 通信のキャプチャ
  • 不正なデバイスの特定などに役立つ。MACアドレス等をキャプチャし組織所有のものか比較する
  • 実際のユーザの行動を監視するため、カバレッジするのが難しく、スキャン時間を長めにとる必要がある
• 認証スキャン
  • 外部からではなく、システム内に入ってから脆弱性スキャンを実施すること

Nice to know

• 脆弱性スキャンを実施して脆弱性が見つかった場合、（誤検知の場合もあるので）まず 「妥当性確認」 を行い、それから報告 → パッチ適用とすすむ
• nmapのデフォルト設定
  • 1000個のTCP/UDPポートをスキャン
  • Wekk-knownポート（0-1024）以外のポートも含まれる
  • UDPも含まれる
  • 64535個のポートをスキャンするにはオプションが必要
• nmapの結果
  • open --- ポートが空いている
  • closed --- ポートが空いているが動いているサービスがない（
  • filtered --- ポートが閉じている

🪲脆弱性

• ローカル脆弱性
  • 侵入後の脆弱性（Linpeas等でスキャンする）
• 認証を必要とする脆弱性
  • 認証情報があれば検出可能
  • Burpsuiteにスキャンする機能があるらしい？
• 脆弱性スキャナー
  • 既知の脆弱性を検出できる
  • テストやプラグイン、シグネチャーのない脆弱性を検出できない
  • ゼロデイ脆弱性も検出できない
  • シグネチャーには、バージョン番号、構成データ、サービスフィンガープリントが含まれる

🔍システムモニタリング

システムの性能等をモニタリングする。アクティブモニタリングとパッシブモニタリングの手法の違いやメリットデメリットを理解する。

• アクティブモニタリング
  • システムに積極的に介入しデータを送信することでモニタリングする
  • システムに負荷を与える場合がある
  • 事前に問題を特定できる
    • シンセティックモニタリング（合成モニタリング）
      • <--> Actual（リアルユーザ）モニタリング
      • 想定されるユーザの行動をエミュレートしたトランザクションを使用することで、システムの応答時間や機能等を検証する
      • トランザクションには、実際に記録された過去のユーザトランザクションが利用される場合もある
• パッシブモニタリング
  • システムに介入せず、運用中のトラフィックやデータの流れを解析する
  • システムの性能に影響を与えないメリットがある
  • 事後にしか問題を特定できない
    • リアルユーザモニタリング（RUM）
      • 運用中のユーザの行動をもとに、パフォーマンスやアプリケーション動作を監視する。

🔍ロギング

• SIEMでログを集める際、システムのログ設定を統一するには？
  • グループポリシー
• syslog
  • ログを転送するプロトコル
  • Linuxやエンタープライズサービスには標準搭載されているが、Windowsは標準ではWindowsのロギングフォーマットでログを生成するので、別途ツールが必要となることに注意

🔍テスト

ソフトウェアのテスト。機能要件は満たされているか？
想定外のデータによってエラーやバグを引き起こさないか？テスト項目は十分か？

• Fuzzing
  • Generative fuzzing
    • アプリケーションの入力形式をもとに0から入力データを生成する
  • Mutation fuzzing
    • 既存の入力データに小さな変更を加えることで大量のテストデータを生成する
  • Fuzzer
    • Fuzzingを自動化するツール
• ユースケーステスト、ミスユーステスト
  • ミスユースケース図には、攻撃者や脅威を書き込む
• 作ったテストは問題ないか？
  • ミューテーションテスト
    • テストのためのテスト
    • 人工的な誤り（ミュータント）を含むコードをコードテスターに入れて、ちゃんと機能するか確認する
  • コードカバレッジ
    • Function, Statement, Branch, Conditionの４つ！

Nice to know

• テスト環境と本番環境に差異があると、レースコンディションなどのタイミングに関する問題が見えなくなるおそれがある
• ソフトウェアの更新を行うと、新しい障害や「古い障害の再発生」が一般的である。リグレッションテストを行う場合は、「欠陥再発率」を指標にする。

🔍ペネトレーションテスト

• 計画
  • 許可を取る（getting authorization）
  • 脆弱性情報がリークするとさらなるリスクに繋がるため、脆弱性情報の保管方法や提供方法を先に決定しておく
  • 進入禁止ターゲットを明確にする
• 発見
  • nmap
• 脆弱性スキャン
  • Nessuss, Nikto
• 侵害
  • john　(パスワードクラック)
• 報告
  • ペネトレーションテストレポートに含まれるもの
    • 特定した脆弱性のリスト
    • リスクのランキング
    • リスク低減のためのガイダンス（そうなんだ）
    • （×）集めた機密情報のリスト　

🔍コードレビュー

色んな人が読んでチェックし、ツールを利用してソースコードの静的チェックを行う。

• フェイガンテスト
  • 計画からフォローアップまで通して詳細に実施するコードレビュー方法
  • 問題があった場合、計画に問題があったとして、計画に戻ってやり直す
  • 計画 -> 概要説明 -> 準備 -> インスペクション -> コード修正（コード修正後は、計画に戻る） -> フォローアップ
• ウォークスルー
  • コードや設計の段階で、開発チームが集まり、問題を議論し、フィードバックを与える非公式な会議
• プログラム理解、プログラム解釈
  • 人がプログラムを読んで、理解・解釈をするプロセス
• ソフトウェアインスペクション
  • 開発者以外の人々（しばしばピアグループ）がコードの品質を評価するために実施される正式な評価プロセス。チェックリストを使用してエラーを探す
• 静的プログラム分析
  • プログラムを実行せずにソースコードの分析を行う技術
  • 構文エラー、未使用変数、メモリリーク、コーディング規約違反などを検出する
  • ツールを用いてソフトウェアのバグ、脆弱性、スタイルの違反などを自動的に検出する
• マニュアルコードレビュー
  • 人がコードを読んでレビューする
  • 静的コードレビューはプラグラムでバグなどを見つける手法なので、ビジネスロジックを考慮してレビューして欲しい場合は、マニュアル（人による）コードレビューが望ましい

🔍セキュリティ設定共通化手順（SCAP）

2002-2015年くらいの話。共通言語や仕様が整備されていった。

セキュリティコンプライアンスへの技術的対応に膨大な時間と労力などのリソースを費やし、複雑化したコンプライアンスへの管理に対する負荷は増大しました。また、設定作業を手作業で行うと、設定ミスや設定者のセキュリティ知識の程度、判断の相違などからセキュリティが損なわれる可能性がある事などから、作業を自動化する事が効率牲・有効性の観点から求められるようになりました。これらの要因からNISTにおいて、情報セキュリティ対策の自動化と標準化を目指したSCAP（Security Content Automation Protocol：セキュリティ設定共通化手順）の開発が行われました。

• CVE（Common Vulnerabilities and Exposures）：脆弱性を識別
• CCE（Common Configuration Enumeration）：セキュリティ設定を識別
  • パスワードの有効期限
  • パスワードの長さ（何文字以上など）
  • パスワードの複雑さ（英数字以外の使用など）
  • パスワードの履歴管理（同じパスワードを使えない回数）など
• CPE（Common Platform Enumeration）：製品を識別
  • ハードウェア、オペレーティングシステム、アプリケーションなどのプラットフォームを識別するための、構造化された名称体系を規定している。ベンダーや専門家間での共通言語。
• CVSS（Common Vulnerability Scoring System）：脆弱性の深刻度
• XCCDF（eXtensible Configuration Checklist Description Format）：セキュリティチェックリストを記述する言語
  • CCEと共に具体的な項目をリストアップしまとめたチェックリストを記述する言語
  • 評価の自動化をサポートするようにデザインされている
  • チェックリストやベンチマーク等に共通の基盤を提供することを目的としている
• OVAL（Open Vulnerability and Assessment Language）：セキュリティ設定状況を検査するための仕様
  • それまで文書と手作業によるチェックだった
  • OVALは、文書による脆弱性対策情報を機械処理可能なXMLベースのOVAL言語で記述するための仕様
  • OVAL定義データは、OVALリポジトリとしてデータベース化
  • 脆弱性対策のための確認作業の自動化により管理工数の低減ができるようになる