Book-Notes Section 14 Flashcards
🛡️ What is the MITRE ATT&CK Framework?
The MITRE ATT&CK Framework is like a playbook of how real-world hackers behave — step by step.
It helps cybersecurity teams understand:
What attackers do
How they do it
How to detect and stop them
🧠 What does “ATT&CK” stand for?
Adversarial Tactics, Techniques, & Common Knowledge
It’s a big collection of:
Tactics = The hacker’s goal (like gaining access or stealing data)
Techniques = How they try to do it (like phishing, password guessing, etc.)
📋 Example (Simple Breakdown):
Let’s say a hacker wants to break into a company’s system.
Here’s how the MITRE ATT&CK Framework would describe their steps:
Tactic (Goal) Technique (How)
Initial Access Phishing email with a fake link
Execution Tricking you into running a fake file
Persistence Installing a backdoor to stay inside
Privilege Escalation Getting admin rights
Data Exfiltration Stealing files and sending them out
🧠 The framework maps out all these steps so security teams know what to watch for and how to defend against them.
🧰 What is it used for?
🔍 Threat detection – spotting suspicious activity
🛡️ Defense planning – choosing what tools and policies to use
🧪 Red teaming / penetration testing – simulating real attacks
📚 Learning – understanding how attackers work
🔐 Where is it used?
SOC (Security Operations Center) teams
Penetration testers
Security+ and cybersecurity students
Incident response teams
✅ Summary (in plain words):
MITRE ATT&CK is like a cheat sheet that shows what hackers typically do — so you can spot them, stop them, and protect your systems better.
🤔 Why use sensors if devices can send data directly to the SIEM?
You’re right — some devices can send logs directly to the SIEM (like firewalls, servers, or applications).
But here’s why sensors are still needed or useful in many cases:
🧠 1. Not all devices can talk to the SIEM directly
Some systems are:
Too old
Too limited
Not configured to send logs properly
📦 A sensor can collect data from those systems and send it on behalf of them.
🧱 2. Sensors act as middlemen to normalize and filter data
Devices send logs in different formats (text, JSON, XML, etc.)
Sensors convert (normalize) the data into a format the SIEM understands
They also filter out noise, so the SIEM only gets useful information
🧠 Think of it like a translator who listens to different people and gives the SIEM one clear story.
🛡️ 3. Sensors can monitor things that logs can’t show
Some attacks don’t show up in logs — like:
Suspicious traffic on the network
Unusual user behavior
Real-time system changes
💡 Sensors can be placed to watch live activity, not just logs.
🧪 4. They add extra context
Sensors can add extra details the raw logs don’t include, like:
Geolocation
Process IDs
File hashes
Who was logged in at the time
This makes threat detection more accurate and intelligent.
🧰 5. Flexibility and performance
Instead of overloading your SIEM with every tiny log from every device:
Sensors can collect, filter, and batch the data
That makes things faster, more efficient, and less expensive
🦠 What is Malware Beaconing?
Malware beaconing is when an infected device quietly “calls home” to a hacker’s server — usually at regular intervals — to check in, get instructions, or send stolen data.
It’s like the malware is saying:
“Hey attacker, I’m still here. Got anything new for me to do?”
🔁 How does it work?
A computer or system gets infected with malware (e.g., via phishing or a bad download).
The malware sends out small, regular signals (called “beacons”) to a Command-and-Control (C2) server.
The hacker uses this connection to:
Give the malware new commands
Steal data
Move deeper into the network
These beacons are often:
Hidden
Encrypted
Made to look like normal traffic (to avoid detection)
🧠 Simple analogy:
Think of beaconing like a spy inside your house sending secret text messages every hour to their boss:
“I’m in. What’s the next move?”
🚨 Why is beaconing dangerous?
It’s a key part of advanced attacks
It lets hackers control infected machines remotely
It often means the malware is just waiting for instructions, even if nothing looks broken yet
🛡️ How is it detected?
Security tools (like SIEMs, EDR, and firewalls) look for:
Regular, repeated connections to suspicious IPs
Unusual patterns in outbound traffic
Long-standing connections that don’t match normal usage
🔔 What is alert fatigue?
Alert fatigue is when a security team gets so many alerts from their SIEM system that they start ignoring or missing real threats — because it’s just too much to keep up with.
🧠 Imagine this:
Your SIEM is like a security alarm system.
But if it goes off 1000 times a day — for big things, small things, and even false alarms — eventually, your brain says:
“Ugh… probably just another false alarm.”
And then you ignore a real threat when it finally happens. 😬
⚠️ Why does alert fatigue happen?
🚨 Too many alerts from too many sources
🤖 Lots of false positives (alerts that aren’t actual problems)
⏳ Not enough time or people to review everything
🔍 Some alerts lack context — hard to tell if they’re serious
🛡️ Why is it a problem?
Real attacks might go unnoticed
Analysts get overwhelmed and stressed
Wastes time chasing non-threats
Can lead to burnout or mistakes
🧰 How do teams reduce alert fatigue?
✨ Use smarter alert rules (fewer false positives)
🧠 Add correlation and context to alerts (show only important ones)
🤖 Use automation and SOAR tools to sort or respond to alerts
📊 Tune the SIEM regularly to improve its accuracy
difference between SIEM and SOAR
🛡️ What is a SIEM?
SIEM = Security Information and Event Management
🔍 Purpose:
It helps security teams collect, analyze, and monitor data from across the network.
🧠 Think of SIEM as:
📊 Your security data hub — it collects logs, detects threats, and creates alerts.
🚨 SIEM helps you:
Collect logs from firewalls, servers, and endpoints
Detect suspicious activity (like brute force or malware beaconing)
Send alerts to the security team
Provide dashboards and reports for compliance
🤖 What is a SOAR?
SOAR = Security Orchestration, Automation, and Response
🔍 Purpose:
It helps automate and respond to those alerts, instead of making analysts do it all manually.
🧠 Think of SOAR as:
🛠️ Your security assistant — it helps take action automatically and speed up responses.
⚙️ SOAR helps you:
Automatically block IPs, isolate devices, or reset accounts
Run playbooks (step-by-step responses to alerts)
Reduce alert fatigue by handling routine tasks
Let analysts focus on serious threats, not small stuff
🔄 SIEM vs SOAR – Simple Comparison:
Feature SIEM SOAR
Main job Detect and alert Automate and respond
Collects data? ✅ Yes ❌ No (uses data from SIEM or tools)
Sends alerts? ✅ Yes ✅ Yes (and handles them)
Automates actions? ❌ No ✅ Yes
Speeds up investigations? 🟡 Somewhat ✅ A lot
Uses playbooks? ❌ No ✅ Yes
🧠 Simple analogy:
SIEM = Your security camera system — it watches everything and tells you when something suspicious happens.
SOAR = Your security robot assistant — when it sees an alert, it locks the door, calls the police, and writes the report for you.
🛡️ What is an Active Response Component?
An Active Response Component is the part of a SIEM system that can take action automatically when a rule is triggered — instead of just sending alerts.
🧠 So instead of just saying:
“Hey! Something suspicious happened!”
The SIEM responds right away — like: “Block that IP!” or “Disable that user account!”
🔥 What does it do?
When a SIEM rule detects something bad (like too many failed logins, malware beaconing, or unusual behavior), the Active Response Component can do things like:
🚫 Block an IP address on a firewall
🔒 Lock a user account
🧯 Kill a suspicious process
📤 Quarantine a device from the network
🔄 Send data to a SOAR platform to trigger a full response playbook
⚙️ Example (simple flow):
SIEM rule: “More than 5 failed logins in 1 minute”
SIEM triggers alert
Active response kicks in
It runs a script that:
Disables the account
Sends a message to the security team
Blocks the IP that made the attempts
❗ What is a mistriggered rule?
A mistriggered rule happens when a SIEM rule detects something that looks suspicious, but it turns out to be harmless or normal behavior.
🧠 It’s basically a false positive — the rule was triggered, but it shouldn’t have been.
🧠 Simple analogy:
Imagine a motion sensor alarm goes off because a cat walked across the room, not a burglar.
That’s a mistriggered alert — the system thought it saw a threat, but it was wrong.
🛠️ Example of a mistriggered rule in SIEM:
🚨 Rule:
“If a user logs in from two countries within 5 minutes, trigger an alert (possible account compromise).”
👨💻 What actually happens:
The user connects to a VPN that routes traffic through Canada.
Then they switch networks, and it looks like they logged in from the U.S.
❗ SIEM alert:
“User login from two countries — possible account breach!”
🤔 Reality:
It’s a legitimate user switching networks or using a VPN — not a real threat.
💥 That’s a mistriggered rule.
✅ Why it matters:
Mistriggered rules lead to alert fatigue
Security analysts waste time investigating non-threats
Real threats might get overlooked
🔧 How to fix it:
Tune the rule (e.g., whitelist VPN IP ranges)
Add context (is this user known to use VPNs?)
Add additional conditions to reduce false positives
🕒 What is Data Lifespan?
Data lifespan is the amount of time data is stored and kept active — from the moment it is created until it is deleted or archived.
It’s also sometimes called:
Data retention period
Data lifecycle
Data expiration time
🛠️ Example:
Let’s say your SIEM logs have a data lifespan of 90 days:
Logs are kept and searchable for 90 days
After that, they are deleted or archived
That means their lifespan is 90 days.
🌐 What is Internet Information Services (IIS)?
IIS is a web server software created by Microsoft.
It lets you host websites, web apps, and services on Windows servers.
🧠 Think of IIS as the “middleman” that takes a request from your browser and delivers the website from the server.
🛠️ What can IIS do?
📄 Host websites (HTML, CSS, JavaScript)
🧑💻 Run web applications (like ASP.NET apps)
📨 Handle web services (APIs)
🔒 Manage SSL certificates for HTTPS
📊 Log traffic and monitor performance
🧠 Simple analogy:
IIS is like a waiter in a restaurant 🍽️
You (the browser) ask for a web page →
The IIS server goes to the kitchen (the files/app), grabs what you asked for, and brings it back to you.
💻 Who uses IIS?
Businesses hosting websites on Windows Server
Developers testing ASP.NET web apps
IT teams running internal web portals
Organizations hosting web services/APIs for apps
🧾 Example:
If you visit http://example.com and the server is running IIS, it:
Receives the request
Finds the matching page (like index.html or home.aspx)
Processes it (if it’s dynamic like .NET)
Sends the result back to your browser
Internet Information Services (IIS) is like Apache, but it’s designed to work best on Windows.
difference between syslog, rsyslog, syslog-ng, and NXLog in simple terms 👇
🧾 First, what is syslog?
Syslog is a standard protocol used to send and store log messages from devices, applications, and servers — mostly in Unix/Linux environments.
It defines:
📨 How logs are formatted
🔁 How they’re sent (usually over UDP/TCP)
📦 Where they’re stored
🧠 Think of syslog as the basic language for logging in IT systems.
🔧 So what are rsyslog, syslog-ng, and NXLog?
They are all log management tools that use (and extend) the syslog protocol, but with extra features.
🔹 Rsyslog
🧪 “Reliable Syslog”
Built on the original syslog but with added features like:
🔒 Better security (encryption)
📤 Support for sending logs over TCP, UDP, or RELP
🧹 Filtering, parsing, and formatting logs
💨 Very fast performance
✅ Default on many modern Linux systems
🔸 syslog-ng
“Next Generation Syslog”
Focused on:
🔀 Advanced filtering and routing
📊 Better structured logging (like JSON)
💼 More flexible than rsyslog in some cases
✅ Often used in complex or large environments
🔳 NXLog
Cross-platform log collector (works on Windows, Linux, and more)
Supports syslog, but also:
📁 Reads Windows Event Logs
📑 Supports file-based logs, JSON, XML, etc.
🔐 Encryption and log forwarding
⚙️ Built for integration with SIEMs (like Splunk or Graylog)
✅ Good for mixed environments (Linux + Windows)
difference between NetFlow, sFlow, and IPFIX
🚦 First, what are they?
NetFlow, sFlow, and IPFIX are all technologies used to monitor network traffic.
They don’t capture full packets like Wireshark — instead, they collect summary data about who’s talking to who, how much data is sent, and when.
🧠 Think of them like:
📊 Network traffic reporters — not watching every word (packet), but giving you a summary of the conversation (flow).
🔹 NetFlow (by Cisco)
Developed by Cisco
Monitors network flows — meaning it tracks:
Source IP
Destination IP
Ports, protocol, how much data, etc.
Flow-based monitoring (waits for the conversation to finish before exporting info)
Very common in routers and firewalls
✅ Best for detailed traffic analysis in Cisco-heavy environments
🔸 sFlow (by InMon)
Developed by InMon Corp
Samples the traffic (e.g., 1 out of every 1,000 packets)
Packet-based and real-time
Can monitor:
Network traffic
CPU, memory, and interface stats
✅ Best for real-time performance monitoring and multi-vendor environments
🔳 IPFIX (Internet Protocol Flow Information Export)
Based on NetFlow v9, but is an open standard
More flexible and customizable
Used by multiple vendors (not just Cisco)
Can export more types of data (like app-level info)
✅ Best for modern and vendor-neutral environments
🧠 What is systemd?
systemd is like the manager or organizer of your Linux system when it starts up.
It’s the first program that runs when you turn on your computer.
It starts everything your system needs to work: like the network, display, sound, and other services.
It also keeps an eye on those services to restart them if they crash.
Think of it like a conductor of an orchestra—making sure every musician (or service) starts at the right time and plays correctly.
🧠 What is journald?
journald is part of systemd. It’s like a notebook or logbook.
It records messages from programs and services about what they’re doing.
These messages are called logs—they help you see if something went wrong or just to track what’s happening.
journald stores these logs in a special format so they’re easy to search.
So if systemd is the manager, then journald is the journal it uses to write down everything that happens.
difference between Isolation and containment in the context of IR?
🔒 Containment = Stopping the spread
It’s about limiting the damage and keeping the threat from moving to other parts of the system.
The goal is to control the situation without shutting everything down.
🧠 Think of a virus outbreak in a hospital:
You quarantine the infected area so it doesn’t spread to the rest of the building.
🛠 Examples:
Blocking a malicious IP address at the firewall
Disconnecting a server from the network
Disabling a compromised user account
🧍♂️ Isolation = Separating the threat
It’s a type of containment, but more focused on cutting off the infected system or process completely.
It’s often used when you’re sure which device or system is affected.
🧠 Back to the hospital example:
You move the infected patient to a private room, completely away from others.
🛠 Examples:
Putting a compromised computer in a sandbox or isolated VLAN
Turning off the network connection for one laptop
Using virtualization to run malware in an isolated environment
