A security analyst is assisting a software engineer with the development of a custom log collection and alerting tool (SIEM) for a proprietary system. The analyst is concerned that the tool will not…

Question

Options

• ARandomly generate and store all possible file hash values.
• BCreate a default rule to alert on any change to the system.
• CIntegrate with an open-source threat intelligence feed.
• DManually add known threat signatures into the tool.

• A
  3% (1)
• B
  10% (3)
• C
  83% (25)
• D
  3% (1)

Explanation

Explanation

Integrating with an open-source threat intelligence feed (Option C) provides the custom SIEM with continuously updated, community-maintained data on known attack patterns, malicious indicators, and behavioral IoCs - directly solving the concern that the tool won't detect known threats without requiring manual curation of every signature.

Why the distractors are wrong:

• Option A is impractical and nonsensical - storing all possible hash values is computationally impossible and serves no security purpose, since threat intelligence focuses on known malicious hashes, not random ones.
• Option B would generate massive alert fatigue, flagging every legitimate system change and making the tool unusable in production environments.
• Option D is partially valid but is inferior because manually adding signatures is time-consuming, static, and will quickly become outdated as new threats emerge - it doesn't scale.

Memory Tip: Think of a threat intelligence feed as a live news subscription for cyber threats - instead of reading yesterday's newspaper (manual signatures), you get real-time updates. When a question asks about detecting known attacks at scale in a custom tool, look for the answer that involves automated, external threat data integration.

No community discussion yet for this question.