Threat intelligence and security analytics. This is the difference between waiting for a break-in and knowing a burglar is casing your house three streets away. For the 350-701 exam, you need to understand how organisations collect clues about attackers, interpret those clues automatically, and act fast enough to stop a breach—not just clean up after one. It is the shift from being reactive (calling the police after the window is smashed) to being proactive (spotting the suspicious van and locking the doors early).
Jump to a section
A simple way to picture Threat Intelligence and Security Analytics
32 cities in your county have 850 restaurants combined. Each restaurant serves 200 meals a day. Your job as the lone health inspector is to find the 3 restaurants that are serving spoiled food before anyone gets sick. You cannot visit every restaurant every day—there are too many. So you use intelligence: you read online reviews (open-source threat intelligence), you check suppliers’ delivery logs to see which kitchens are ordering unusual amounts of painkillers (internal telemetry), and you subscribe to a national alert system that warns you when a new food-poisoning strain appears (commercial threat feed). This tells you which restaurants to watch, which ingredients to test, and which cooking practices to check first.
Now imagine you install a smart thermometer in every fridge (sensors). That sensor data flows to a central dashboard (security analytics platform). When one fridge hits 10 degrees Celsius, the system instantly flags it—but it is not enough to act yet. You cross-reference that reading with the supplier delivery date and a recent Yelp complaint about warm chicken salad. That correlation is analytics.
You do not need to look at every fridge in every restaurant. You look at the ones the intelligence says are risky, and the analytics confirm. That is threat intelligence plus security analytics: knowing what to look for and where, so you do not drown in data or miss the one spoiled meal that makes 50 people ill.
Let us start with a brutal truth: the internet is full of attackers, and they do not take weekends off. A company like a bank or a hospital sees millions of events every day—someone logging in, a file being downloaded, a server responding to a request. Most of those events are normal and harmless. But buried in that mountain of noise are a handful of malicious actions: a hacker trying a stolen password, a piece of malware phoning home to its controller, an employee accidentally exposing customer data.
Threat intelligence is the organised knowledge about those attackers and their methods. Think of it as a criminal profile. It tells you what tools the attackers use (for example, a specific piece of ransomware called LockBit), what email subject lines they favour (like "Urgent invoice attached"), and which countries they operate from. This intelligence comes from several places:
Open-source intelligence (OSINT): public information like security blogs, social media posts from hackers, or government reports (for example, the US Cybersecurity and Infrastructure Security Agency, or CISA, publishes alerts about active attacks).
Commercial threat feeds: paid subscriptions to companies like Recorded Future or VirusTotal that analyse global attack data and send you customised warnings.
Internal intelligence: data your own organisation collects from past incidents—if an attacker used a certain IP address to break in last year, that IP stays on your watchlist forever.
Community sharing: industry groups where banks share attack patterns with other banks (called Information Sharing and Analysis Centres, or ISACs).
Security analytics is the engine that processes all that intelligence plus the organisation's live data. It uses algorithms, statistical models, and machine learning to find patterns that a human eye would miss. For example, if a user normally logs in from London at 9 AM Monday to Friday, and suddenly they log in from Nigeria at 3 AM on a Tuesday, the analytics engine calculates that this is 99% likely to be an anomaly. It flags it.
Why do organisations need both? Because intelligence without analytics is just a library of unread reports. And analytics without intelligence is a machine that raises alarms but does not tell you which alarms matter. Together, they form a feedback loop:
Intelligence tells analytics what to look for (for example, “watch for connections to this known malicious IP address”).
Analytics finds evidence of that behaviour in real time.
That evidence feeds back into the intelligence—if the analytics find a new IP that connects to the same malicious server, that IP gets added to the threat intelligence database.
The main categories of data that security analytics examines are:
Network data: traffic between devices—which IPs talk to which, what protocols they use (HTTP, DNS, SSH), and how much data moves.
Endpoint data: what happens on individual computers and servers—processes started, files created, registry keys changed.
User behaviour data: login times, failed attempts, password changes, privilege escalations.
Application data: how specific software behaves—a web server normally handles 1,000 requests per minute; if it spikes to 100,000, something is wrong.
This was not always possible. In the early days of IT security, organisations relied on manual log review. A security analyst would sit down each morning with a stack of log files from every server and read through them line by line. It was slow, boring, and ineffective—a needle in a haystack hunt.
Modern Security Information and Event Management (SIEM) systems changed that. A SIEM (for example, Splunk or Microsoft Sentinel) ingests all the logs from across the organisation, normalises them into a common format, and then runs correlation rules against them. A correlation rule might say: “If a user fails to log in five times in one minute from three different countries, then alert.” The intelligence tells the SIEM which patterns are dangerous; the analytics checks the data.
The output is a ticket or an alert that a human analyst investigates. That human decides whether this is a real threat (a true positive) or a false alarm (a false positive). Over time, the system learns—if the same pattern triggers weekly but is always a false positive, the analyst can adjust the rule to suppress it. That tuning process is part of security analytics too.
For the 350-701 exam, remember that threat intelligence has three levels of fidelity: strategic (long-term trends, like “nation-state actors are targeting healthcare”), operational (specific campaigns, like “a new phishing kit is using fake Microsoft login pages”), and tactical (specific indicators, like “IP address 185.220.101.45 is malicious”). The exam will ask you to identify which level a given piece of intelligence belongs to.
Collect Threat Intelligence
The organisation subscribes to one or more threat intelligence feeds—commercial (e.g., Recorded Future), open-source (e.g., AlienVault OTX), or community-based (e.g., an ISAC). These feeds provide lists of known malicious IPs, domains, file hashes, and descriptions of attacker tactics. This step ensures the organisation knows what to look for before an attack starts.
Ingest into Security Analytics Platform
The threat intelligence is fed into the SIEM (e.g., Splunk or Microsoft Sentinel) or a threat intelligence platform (TIP). The platform normalises the data into a consistent format so it can be compared against live network traffic, endpoint logs, and user behaviour data. Without this step, the intelligence sits unused.
Correlate with Internal Data
The SIEM runs correlation rules that compare the threat intelligence indicators against the organisation’s log data. For example, a rule might say: 'Alert if any device communicates with an IP on the malicious IP list.' The SIEM also applies behavioural analytics—looking for deviations from normal baselines, such as a user logging in from an unusual location.
Generate and Prioritise Alerts
When a match is found, the SIEM creates an alert with a priority score. High-priority alerts involve indicators that are less than 24 hours old or match known critical vulnerabilities. Low-priority alerts might involve older indicators or less sensitive systems. Prioritisation prevents analyst burnout by focusing attention on the most likely threats.
Analyst Investigation and Response
A human security analyst reviews the alert, enriches it by looking up additional context (e.g., who the user is, what the device normally does), and determines if it is a true positive. If yes, they contain the threat—for example, by isolating the device via endpoint detection and response (EDR) software or blocking the IP at the firewall. If false positive, they tune the rule to reduce future noise.
Feedback Loop and Intelligence Update
After the incident, the analyst updates the threat intelligence database with any new indicators discovered during the investigation—for example, a new domain the attacker used. This feeds back into the SIEM so that future correlating rules detect the updated threat. The organisation also shares anonymised intelligence with its ISAC or commercial feed provider, contributing to the global community’s defence.
Meet Maria. She is a security analyst at a mid-size retail company with 3,000 employees. Her company uses a SIEM called Splunk, subscribed to a commercial threat feed from Anomali, and participates in the Retail & Hospitality ISAC.
One Tuesday morning, a vendor calls Maria to say they accidentally sent a malicious PDF to one of her company’s accounting staff. That is external intelligence. Maria uploads the PDF to VirusTotal (a free service that scans files with 60+ antivirus engines). VirusTotal tells her the PDF contains a known trojan called Emotet. She extracts the command-and-control (C2) server IP address from the file—a tactical indicator.
Maria then builds a correlation rule in Splunk:
Trigger: Any device in the company sends traffic to IP address 91.234.56.78 (the C2 server).
Action: Generate a high-priority alert, isolate the device from the network (using the endpoint detection tool), and notify the incident response team.
This is threat intelligence feeding into analytics.
Twelve minutes later, Splunk alerts. An employee’s laptop in the warehouse has connected to that exact IP at 10:14 AM. Maria checks the user’s browser history—they clicked a link in an email that said “Shipping delay notice.” The laptop is now quarantined.
Maria also runs a retrospective analysis: she asks Splunk to search the last 30 days for any connections to that C2 IP from any device. Two other machines show up. Those machines are also quarantined. The threat intelligence she used (the C2 IP) became the input for analytics that found hidden infections—ones that were dormant and would have activated later.
Now, consider the opposite scenario: no intelligence, just analytics. Splunk would still raise an alert if a machine connected to an unusual IP, but without knowing that IP was malicious, Maria might dismiss it as a user visiting a legitimate but obscure website. The intelligence gave context, and context turns data into a decision.
The real-world workflow for an analyst like Maria is:
Triage: Every alert gets a priority. A single failed login is low. A failed login followed by a successful login from a new country is high.
Investigate: Open the alert, look at the raw logs, check user permissions, review network flows.
Enrich: Use threat intelligence to look up IP addresses, file hashes, or domain names. For instance, look up the IP on a service like AlienVault OTX to see if it is known for phishing.
Contain: If confirmed malicious, isolate the device, block the IP at the firewall, reset compromised passwords.
Learn: Update the threat intelligence database with any new indicators found during the investigation. Block the domain in the proxy server for all users.
Without threat intelligence, the analyst has to guess which alerts are serious. Without security analytics, the analyst would have to read every single log entry manually—impossible in a company with 3,000 employees. Together, they make security operations scalable.
The 350-701 exam tests threat intelligence and security analytics in two specific ways: definition matching and scenario analysis. You will not be asked to configure a SIEM. You will be asked to identify concepts, distinguish between similar terms, and choose the correct response to a given situation.
First, you must memorise the three levels of threat intelligence and what each level looks like on the exam:
Strategic intelligence: broad trends. Exam question pattern: “Which type of threat intelligence would a CISO use to justify a security budget increase?” Answer: Strategic.
Operational intelligence: specific tactics, techniques, and procedures (TTPs). Exam pattern: “Which intelligence reveals that a hacking group is using spear-phishing with COVID-19 themed emails?” Answer: Operational.
Tactical intelligence: atomic indicators—IPs, hashes, domain names. Exam pattern: “Which intelligence feeds directly into a SIEM correlation rule?” Answer: Tactical.
Second, know the difference between a SIEM and a SOAR (Security Orchestration, Automation and Response). The exam loves to confuse these. A SIEM collects, normalises, and correlates logs. A SOAR takes the alert from the SIEM and automates the response—for example, automatically blocking an IP at the firewall and creating a ticket. They work together: SIEM finds the problem, SOAR fixes it without a human clicking buttons.
Third, understand the indicator life cycle. A threat intelligence indicator (like a malicious IP) has a shelf life. Attackers change IPs often. The exam will present a scenario where an indicator is 6 months old and ask if it is still reliable. The answer: it is likely stale. Tactical indicators expire fast, sometimes within hours.
Fourth, watch for trap questions about false positives and false negatives. The exam will describe a situation where the SIEM alerts for a behaviour that is actually normal—for example, a CEO logging in from a hotel abroad. That is a false positive. The correct answer is to tune the SIEM rule to account for the CEO’s travel patterns, not to disable the rule entirely.
Fifth, the exam tests the difference between structured and unstructured threat intelligence. Structured intelligence is machine-readable—formats like STIX (Structured Threat Information Expression) and TAXII (Trusted Automated Exchange of Intelligence Information). Unstructured intelligence is a PDF report or a blog post. The question will ask: “Which format allows automated ingestion into a SIEM?” Answer: Structured (STIX/TAXII).
Key definitions to memorise:
Indicator of Compromise (IoC): a piece of evidence that suggests a system has been breached—e.g., a file hash, a malicious IP, a registry key change.
Indicator of Attack (IoA): a pattern that suggests an attack is happening right now, not that it already happened—e.g., multiple failed logins followed by a brute force script.
False positive: an alert that fires for benign activity.
False negative: a real attack that the system misses.
TTP: Tactics, Techniques, and Procedures—the behaviour of the attacker, not just the artifacts they leave behind.
Finally, exam questions will ask you to put the steps in order during an incident response process that uses threat intelligence. The correct order is: collect intelligence, correlate with internal data, identify the threat, contain, eradicate, recover. They will try to trick you by putting “contain” before “identify.” Do not fall for it—you must know what you are containing first.
Threat intelligence is organised knowledge about attackers—their motives, methods, and indicators—and comes in three levels: strategic, operational, and tactical.
Security analytics is the automated analysis of logs and events using correlation rules, statistical models, and machine learning to detect threats in real time.
A SIEM (Security Information and Event Management) system collects and normalises logs from across an organisation, then applies correlation rules to generate alerts.
Tactical indicators like IP addresses and file hashes expire quickly—sometimes in hours—and should not be trusted without recent validation.
A SOAR (Security Orchestration, Automation and Response) takes alerts from the SIEM and automates responses like blocking IPs or creating tickets, reducing manual work.
An Indicator of Compromise (IoC) suggests a past or current breach, while an Indicator of Attack (IoA) signals an ongoing attack by detecting behaviour patterns.
Structured threat intelligence formats like STIX and TAXII allow automated ingestion into security tools, whereas unstructured intelligence (like a PDF report) requires human reading.
These come up on the exam all the time. Here's how to tell them apart.
Strategic Threat Intelligence
Focuses on long-term trends and attacker motivations (e.g., 'Chinese state-sponsored groups target telecoms').
Used by executives for budgeting and policy decisions.
Example: a report on the rise of ransomware-as-a-service in the last quarter.
Tactical Threat Intelligence
Focuses on specific, atomic indicators (e.g., IP addresses, file hashes, domain names).
Used by security analysts to create SIEM rules and blocklists.
Example: a list of 50 IPs known to be part of the Emotet botnet.
SIEM (Security Information and Event Management)
Collects, normalises, and stores log data from across the organisation.
Uses correlation rules to generate alerts.
Primary output is an alert or a ticket for a human to investigate.
SOAR (Security Orchestration, Automation and Response)
Takes alerts from the SIEM and automates response actions (e.g., blocking an IP).
Orchestrates workflows across multiple tools (firewall, EDR, ticketing system).
Primary output is an automated action without human intervention.
Indicator of Compromise (IoC)
Evidence that a system has already been breached (e.g., a malicious file on disk).
Forensic in nature—used after or during an incident to find the extent of damage.
Example: a registry key change created by a known ransomware strain.
Indicator of Attack (IoA)
Patterns of behaviour that suggest an attack is happening right now (e.g., rapid login failures).
Proactive in nature—used to stop an attack in progress.
Example: a user performing a directory traversal on a web server.
Open-Source Threat Intelligence (OSINT)
Publicly available for free (e.g., security blogs, social media, government alerts).
May be less curated and less timely.
Example: reading a CISA advisory about a new vulnerability.
Commercial Threat Intelligence
Paid subscription service with dedicated research teams (e.g., Recorded Future).
Highly curated, validated, and often delivered via API for automatic ingestion.
Example: a feed that lists newly identified phishing domains within minutes of discovery.
Mistake
Threat intelligence is just a list of bad IP addresses.
Correct
Threat intelligence includes strategic insights about attacker motives and methods, not just technical indicators. IPs are tactical-level intelligence—the smallest and least durable part.
Beginners see the word 'intelligence' and assume it means data points. They do not realise that the most valuable intelligence is often the context—who is attacking and why.
Mistake
Security analytics detects 100% of attacks automatically.
Correct
Security analytics uses probability and pattern matching. It is good, but it produces false positives and misses novel attacks (false negatives). Human analysts are still essential.
Marketing hype from vendors makes analytics tools sound like magic. Beginners believe the machine does everything, so they underestimate the importance of analyst training.
Mistake
All threat intelligence feeds are equally valuable.
Correct
Feeds vary wildly in quality. A feed from a reputable vendor like Recorded Future is more reliable than a free community list. Also, a feed must be relevant to your industry to be useful.
Beginners think 'more data is better.' They do not understand that low-quality intelligence creates noise, which slows down analysts and increases false positives.
Mistake
A SIEM and a threat intelligence platform are the same thing.
Correct
A SIEM collects and analyses logs. A threat intelligence platform (TIP) aggregates, correlates, and shares threat data. The SIEM uses intelligence from the TIP, but they are separate systems.
Both tools deal with security data and produce alerts, so beginners conflate them. The exam deliberately tests this difference.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. A firewall blocks traffic based on rules you configure, but it does not know which IPs are currently malicious. Threat intelligence tells the firewall which IPs to block next, keeping your defences up to date with the latest attacks.
Threat intelligence provides the clues about what to look for. Threat hunting is the proactive search for hidden threats using those clues, often before any alert fires. Hunters use intelligence to narrow their search.
You can, but free feeds (like AlienVault OTX) usually have less curated data and may include stale or inaccurate indicators. Paid feeds offer higher reliability, faster updates, and more context about each indicator. For the exam, know that paid feeds are generally preferred for production environments.
As often as possible—ideally every few minutes for tactical indicators like IPs and domains. Attackers change their infrastructure constantly. If your feeds are updated only once a day, you are blind for hours. The exam emphasises that timeliness is critical for tactical intelligence.
A false positive is an alert that the system raises for a normal, harmless event, like a manager logging in from a hotel during a business trip. It wastes time and can cause analysts to ignore real threats if too common. Tuning the system reduces false positives.
No. A SIEM prioritises alerts by severity. A SOAR can automate responses for low-severity alerts. Only complex or high-severity alerts require human investigation. This layered approach keeps analysts from drowning in noise.
You've finished Threat Intelligence and Security Analytics. Continue through the 350-701 study guide to build a complete picture of the exam.
Done with this chapter?