CISP-TRE common mistakes
CISP-TRE · Understand the traps and how to avoid them.
When triaging an alert, the candidate immediately begins containment actions (isolating hosts, blocking IPs) before establishing a timeline of events or confirming the alert's validity, leading to incomplete evidence and missed scope.
Pressure to 'stop the breach' and a mental model that faster response equals better response. Candidates often conflate speed with effectiveness and skip the crucial scoping phase.
What to do instead
Always follow a structured triage process: validate the alert, determine scope and impact, preserve evidence, then contain. Practice with tabletop exercises that force you to justify each action with evidence. Remember that containment without understanding can destroy logs and allow the attacker to persist elsewhere.
Relying solely on IOC matching (IPs, domains, hashes) for threat detection and hunting, ignoring behavioral analytics and anomaly detection, which leads to missing fileless malware and living-off-the-land attacks.
IOCs are easy to understand and automate, and many training resources emphasize them. Candidates underestimate how quickly attackers rotate infrastructure and how common fileless techniques are.
What to do instead
Study the Pyramid of Pain and incorporate TTP-based detection. Practice writing detection rules for behaviors such as suspicious PowerShell usage, lateral movement via PsExec, and credential dumping. Use frameworks like MITRE ATT&CK to map detections to techniques.
In network traffic analysis, the candidate focuses only on payload content and ignores protocol metadata (headers, timing, flow data), missing command-and-control channels hidden in DNS, HTTP headers, or TLS certificates.
Many tools highlight payload signatures, and candidates may not be comfortable with protocol analysis at the packet level. They also may not realize how much intelligence can be derived from metadata.
What to do instead
Practice analyzing PCAPs with tools like Wireshark and Zeek, focusing on protocol anomalies, beaconing patterns, and unusual DNS queries. Learn to extract and interpret TLS certificate fields, HTTP user-agents, and flow statistics. Study common C2 frameworks and their network signatures.
In digital forensics, the candidate collects volatile evidence after non-volatile evidence, or fails to maintain chain of custody, compromising the integrity and admissibility of evidence.
Lack of hands-on experience with evidence collection order and legal requirements. Candidates may prioritize ease of collection over forensic soundness.
What to do instead
Memorize the order of volatility (RFC 3227) and always collect volatile data first (memory, network connections, running processes). Document every action with timestamps, hashes, and signatures. Use write blockers and maintain a chain-of-custody form. Practice with forensic toolkits in lab environments.
During malware analysis, the candidate performs dynamic analysis without isolating the environment properly, risking infection of the host or corporate network, or fails to take a snapshot before execution.
Overconfidence in sandboxing or lack of familiarity with safe lab setup. Candidates may rush to execute samples to see behavior without proper precautions.
What to do instead
Always use an isolated lab with no network bridging, use snapshots, and simulate internet services with INetSim or FakeNet. Follow a checklist: snapshot, baseline, execute, observe, revert. Study safe malware handling procedures and practice in a controlled environment.
In EDR, the candidate only looks at alerts generated by the console and ignores raw telemetry (process creation, network connections, registry changes), missing subtle malicious activity that doesn't trigger alerts.
Over-reliance on automated alerts and lack of familiarity with EDR query languages and data models. Candidates may not realize that EDR platforms store rich telemetry that can be queried.
What to do instead
Learn to write queries in EDR platforms (e.g., CrowdStrike Falcon LogScale, Microsoft Defender Advanced Hunting) to hunt for specific behaviors. Understand the data schema and practice correlating events across process trees. Use EDR telemetry to reconstruct attack chains.
In SOC automation, the candidate creates overly complex playbooks that attempt to automate decision-making without human oversight, leading to false positives and alert fatigue, or fails to include error handling.
Enthusiasm for automation and misunderstanding of its limitations. Candidates may try to automate too much too soon without considering edge cases.
What to do instead
Start with simple, repetitive tasks and include human approval steps for critical actions. Build in error handling and logging. Test playbooks with historical data and red-team exercises. Remember that automation should augment, not replace, analyst judgment.
When handling incidents, the candidate fails to properly document actions and findings in real-time, resulting in an incomplete incident report and lessons learned that cannot be used to improve processes.
Underestimating the importance of documentation during high-pressure incidents. Candidates may focus on technical resolution and treat documentation as an afterthought.
What to do instead
Use an incident response tracking system or template to log every action, timestamp, and decision. Assign a dedicated scribe if possible. After the incident, conduct a thorough post-mortem and update playbooks. Practice documenting during tabletop exercises.
In threat intelligence, the candidate consumes feeds without evaluating their relevance, reliability, and context, leading to intelligence that is not actionable or is misleading.
Treating threat intelligence as a data ingestion problem rather than an analysis problem. Candidates may not apply structured analytical techniques or source evaluation.
What to do instead
Apply the intelligence cycle: planning, collection, processing, analysis, dissemination. Evaluate sources using the Admiralty Code. Use frameworks like the Diamond Model and MITRE ATT&CK to contextualize. Always ask 'so what?' and tailor intelligence to stakeholder needs.
When building detection tooling, the candidate writes rules that are too specific (e.g., matching a single hash) or too broad (e.g., alerting on all PowerShell usage), resulting in high false negatives or false positives.
Lack of understanding of detection engineering principles and failure to test rules against a varied dataset. Candidates may not consider attacker evasion techniques.
What to do instead
Follow detection engineering best practices: use behavioral indicators, test rules with atomic red team or similar, and tune thresholds. Employ the MITRE ATT&CK framework to ensure coverage. Continuously validate and update rules based on feedback.