OCI Threat Intelligence

解決する課題

• 通信相手のIPやドメインが既知の悪性かどうかを、自前で情報を集めずに判定したい
• 脅威情報を複数ソースから集めると重複や信頼度のばらつきが出る → 整理・正規化された形で使いたい
• セキュリティ調査で見つけたIoC（侵害指標）の素性を、信頼できる文脈とともに確認したい
• 検知ルールやログ分析に脅威インテリジェンスを組み込みたいが、フィード契約や運用の手間を抑えたい

主要概念と用語

• 脅威インテリジェンス（Threat Intelligence）: 攻撃者の手口や悪性なリソースに関する情報を集約・分析したもの。OCI ではこれを API とコンソールで参照できる
• IoC（侵害指標 / Indicator of Compromise）: 悪性と判断された具体的な指標。IPアドレス・ドメイン・URL・ファイルハッシュなどが該当する
• インジケーター（Indicator）: OCI Threat Intelligence が扱う1件1件の脅威指標。値・種類・信頼度・関連する脅威タイプなどの属性を持つ
• インジケータータイプ（Indicator Type）: 指標の種別。IP_ADDRESS、DOMAIN_NAME、FILE_NAME、MD5_HASH などのカテゴリで分類される
• 信頼度（Confidence）: その指標が本当に悪性である確からしさを表すスコア。複数ソースの裏付けや鮮度などから算出される
• 脅威タイプ（Threat Type）: その指標が関連づく脅威の分類。マルウェア配布、フィッシング、ボットネットなどの文脈を示す
• 情報源（Source）: 指標の出どころ。Oracle 独自の解析、第三者ベンダー、オープンソースなど複数を集約する
• TTP: 攻撃者の戦術・技術・手順（Tactics, Techniques, Procedures）。脅威の振る舞いを体系的に表す文脈情報

仕様・制限・クォータ

• リージョン単位で提供され、各リージョンのエンドポイントから指標を参照する
• 指標はコンソール・REST API・CLI・SDKから照会でき、list-indicators などで条件検索する
• 検索条件にはインジケータータイプ・脅威タイプ・信頼度・最終更新日時などを指定でき、必要な指標だけを絞り込める
• 指標は複数ソースの集約結果で、重複は正規化され、信頼度や鮮度が属性として付与される
• 参照には IAM ポリシーによる読み取り権限が必要。テナンシ内のグループに threat-intel-family などの権限を付与する
• 集約される情報源の構成、指標の保持・更新頻度、API のレート上限などの詳細値は変動しうるため公式ドキュメントで確認する

内部の仕組み

OCI Threat Intelligence は、複数の情報源から脅威指標を取り込み → 正規化・重複排除 → 信頼度の算出 → 集約データとして配信という流れで動きます。

1. Oracle 独自の解析、第三者ベンダー、オープンソースなど複数ソースの脅威データを継続的に収集する
2. 同じ値を指す指標を正規化して重複を排除し、関連づく脅威タイプや TTP の文脈を付与する
3. 裏付けとなるソース数や鮮度などから信頼度スコアを算出し、各指標に属性として持たせる
4. 集約済みのデータをAPI・コンソール経由で照会できる形で提供する

照会側は、調査対象の IP やドメインを問い合わせて「既知の悪性か」「どの脅威タイプか」「信頼度はどの程度か」を確認できます。OCI 内部では、こうした脅威インテリジェンスが Cloud Guard の脅威検出や WAF の保護ルールなど他サービスの判断材料としても活用されます。

設計パターン / ベストプラクティス

• 信頼度でしきい値を設ける：低信頼度の指標まで一律にブロックすると誤遮断が増えるため、高信頼度はブロック・中信頼度は監視のように段階を分ける
• 調査ワークフローに組み込む：インシデント調査で観測した IP・ドメインを照会し、既知の悪性かどうかと脅威タイプを判断材料にする
• ログ分析と突き合わせる：VCN フローログや Audit、アプリログに現れた通信先を指標と照合し、悪性通信の兆候を洗い出す
• 鮮度を考慮する：脅威指標は時間とともに陳腐化するため、最終更新日時で絞り込み、古い指標に依存しすぎない
• Cloud Guard / WAF と役割分担：自動検知・防御は Cloud Guard や WAF に任せ、Threat Intelligence は素性確認と文脈付けの情報源として使う

運用・監視

• 調査時はインジケータータイプと脅威タイプで絞り込み、対象の IP・ドメインの素性を素早く確認する
• 検知・防御に組み込む場合は信頼度しきい値を運用方針として定め、誤検知と見逃しのバランスを取る
• 指標照会の API はバッチ的に呼び出す設計にし、ログ突合などで大量問い合わせをする際はレート上限を意識する
• Threat Intelligence へのアクセス自体は OCI Audit に記録されるため、誰がどの指標を参照したかを追跡できる
• 自動連携を組む場合は Events / Functions / Logging と組み合わせ、悪性通信の検知から通知までを仕組み化する

コスト

OCI Threat Intelligence の指標照会（コンソール・API・CLI）は追加料金なしで利用できます。脅威フィードを個別契約して取り込む方式に比べ、まず使い始めるハードルが低いのが特徴です。ただし、照会結果を活用して連携する他サービス（Functions による自動処理、Logging によるログ保管、Cloud Guard や WAF の利用など）には、それぞれの課金が発生します。

セキュリティ

• 参照は最小権限で：Threat Intelligence への読み取り権限は調査・運用に必要なグループに絞り、IAM ポリシーで限定する
• 素性確認の一次情報源：観測した通信先の悪性度を客観的な信頼度付きで確認でき、調査の判断を裏付ける
• 検知の入力として活用：Cloud Guard の脅威検出や WAF の保護ルールが、集約された脅威情報を判断材料に使う
• OCI Audit と相互補完：Audit が「誰が何をしたか」、Threat Intelligence が「その通信先は既知の悪性か」を示し、調査時に組み合わせる
• 過信しない：脅威指標は網羅的ではなく時間で陳腐化するため、唯一の判断基準にせず他の検知・防御と多層で組み合わせる

Well-Architected の観点

• セキュリティ（Security）: 既知の悪性リソースを信頼度付きで把握できる脅威インテリジェンスの基盤として、検知・調査・防御の各層に文脈情報を供給する。Cloud Guard（検知・修復）、WAF（Web 防御）、Audit（操作記録）と役割が重ならず補完関係にあり、これらの判断精度を高める位置づけ

試験で問われるポイント

関連サービス・比較

OCI Threat Intelligence は脅威情報の集約・提供に特化し、検知や自動修復は Cloud Guard が担います。両者は補完関係で、Threat Intelligence が供給する脅威の文脈を Cloud Guard が検知判断に活かす形になります。

他クラウドでは、AWS の脅威インテリジェンスフィード（GuardDuty が内部で用いる脅威情報や脅威リスト）が近い位置づけですが、OCI Threat Intelligence は集約済み指標を直接照会できる独立サービスとして提供される点が特徴です。

ハンズオン / CLI例

# 1. 脅威指標を一覧（インジケータータイプで絞り込み：IP アドレス）
oci threat-intelligence indicator-summary list \
  --compartment-id <compartment-ocid> \
  --type IP_ADDRESS

# 2. 信頼度の高い指標だけに絞って一覧（しきい値を指定）
oci threat-intelligence indicator-summary list \
  --compartment-id <compartment-ocid> \
  --type DOMAIN_NAME \
  --confidence-greater-than-or-equal-to 80

# 3. 特定の指標の詳細（信頼度・脅威タイプ・情報源など）を取得
oci threat-intelligence indicator get \
  --indicator-id <indicator-ocid>

# 4. 利用可能な脅威タイプの一覧を確認
oci threat-intelligence threat-type-summary list \
  --compartment-id <compartment-ocid>