Cybersecurity Analyst

Cybersecurity Analyst Skill

Purpose

Analyze events through the disciplinary lens of cybersecurity, applying rigorous security frameworks (CIA triad, defense-in-depth, zero-trust), threat modeling methodologies (STRIDE, PASTA, VAST), attack surface analysis, and industry standards (NIST, ISO 27001, MITRE ATT&CK) to understand security risks, identify vulnerabilities, assess threat actors and attack vectors, evaluate defensive controls, and recommend risk mitigation strategies.

When to Use This Skill

• Security Incident Analysis: Investigate breaches, data leaks, ransomware attacks, insider threats
• Vulnerability Assessment: Identify weaknesses in systems, applications, networks, processes
• Threat Modeling: Analyze potential attack vectors and threat actors for new systems or changes
• Security Architecture Review: Evaluate design decisions for security implications and gaps
• Risk Assessment: Quantify and prioritize security risks using frameworks like CVSS, FAIR
• Compliance Analysis: Assess adherence to security standards (SOC 2, PCI-DSS, HIPAA, GDPR)
• Incident Response Planning: Design detection, containment, eradication, and recovery strategies
• Security Posture Evaluation: Assess overall defensive capabilities and maturity
• Code Security Review: Identify security vulnerabilities in software implementations

Core Philosophy: Security Thinking

Cybersecurity analysis rests on fundamental principles:

Defense in Depth: No single security control is perfect. Layer multiple independent controls so compromise of one doesn't compromise the whole system.

Assume Breach: Modern security assumes attackers will penetrate perimeter defenses. Design systems to minimize damage and enable detection when (not if) breach occurs.

Least Privilege: Grant minimum access necessary for legitimate function. Every excess permission is an opportunity for exploitation.

Zero Trust: Never trust, always verify. Verify explicitly, use least privilege access, and assume breach regardless of network location.

Security by Design: Security cannot be bolted on afterward. It must be fundamental to architecture and implementation from the beginning.

CIA Triad: Security protects three properties—Confidentiality (only authorized access), Integrity (only authorized modification), Availability (accessible when needed).

Threat-Informed Defense: Base defensive priorities on understanding of actual threat actors, their capabilities, motivations, and tactics (threat intelligence).

Risk-Based Approach: Perfect security is impossible. Prioritize security investments based on risk (likelihood × impact) to maximize security per dollar spent.

---

Theoretical Foundations (Expandable)

Foundation 1: CIA Triad (Classic Security Model)

Components:

Confidentiality: Information accessible only to authorized entities

• Protection mechanisms: Encryption, access controls, authentication
• Threats: Eavesdropping, data theft, unauthorized disclosure
• Example violations: Data breach, password theft, insider leak

Integrity: Information modifiable only by authorized entities in authorized ways

• Protection mechanisms: Hashing, digital signatures, access controls, version control
• Threats: Tampering, unauthorized modification, malware
• Example violations: Database manipulation, man-in-the-middle attacks, ransomware encryption

Availability: Information and systems accessible when needed by authorized entities

• Protection mechanisms: Redundancy, backups, DDoS mitigation, incident response
• Threats: Denial of service, ransomware, system destruction
• Example violations: DDoS attacks, ransomware, infrastructure failures

Extensions:

• Authenticity: Verified identity of entities and origin of information
• Non-repudiation: Cannot deny taking action
• Accountability: Actions traceable to entities

Application: Every security analysis should identify which aspects of CIA triad are at risk and how controls protect each.

Sources:

• CIA Triad - Wikipedia
• NIST Cybersecurity Framework

Foundation 2: Defense in Depth (Layered Security)

Principle: Deploy multiple layers of security controls so compromise of one layer doesn't compromise entire system.

Historical Origin: Military defensive strategy—multiple concentric perimeter defenses

Security Layers:

1. Physical: Facility access controls, locked server rooms 2. Network: Firewalls, network segmentation, IDS/IPS 3. Host: Endpoint protection, host firewalls, patch management 4. Application: Input validation, secure coding, authentication 5. Data: Encryption at rest and in transit, DLP, tokenization 6. Human: Security awareness training, phishing simulation

Key Insight: Redundancy is not waste—it's resilience. Even if attacker bypasses firewall, they still face authentication, authorization, monitoring, encryption, and detection controls.

Application: Security architecture should have multiple independent defensive layers protecting critical assets.

Limitation: Can create complexity and false sense of security if layers are not maintained or are interdependent.

Sources:

• Defense in Depth - NSA
• Layered Security - CISA

Foundation 3: Zero Trust Architecture

Core Principle: "Never trust, always verify" regardless of network location

Contrast with Perimeter Model: Traditional security assumed internal network is trusted ("castle and moat"). Zero trust assumes no network location is trusted.

Key Tenets (NIST SP 800-207):

1. Verify explicitly: Always authenticate and authorize based on all available data points 2. Least privilege access: Limit user access with Just-In-Time and Just-Enough-Access 3. Assume breach: Minimize blast radius and segment access; verify end-to-end encryption

Components:

• Identity-centric security: Identity becomes new perimeter
• Micro-segmentation: Network divided into small zones with separate controls
• Continuous verification: Authentication and authorization are continuous, not one-time
• Data-centric: Protect data itself, not just perimeter around it

Drivers:

• Cloud adoption (no clear perimeter)
• Remote work (users outside traditional perimeter)
• Sophisticated attacks (perimeter breaches common)

Application: Modern security architectures should be designed with zero trust principles, especially for cloud and hybrid environments.

Sources:

• NIST SP 800-207: Zero Trust Architecture
• Zero Trust - Microsoft Security

Foundation 4: Threat Modeling

Definition: Structured approach to identify and prioritize potential threats to a system

Purpose: Proactively identify security issues during design phase when fixes are cheapest

Benefits:

• Find vulnerabilities before implementation
• Prioritize security work
• Communicate risks to stakeholders
• Guide security testing

Common Methodologies:

STRIDE (Microsoft):

• Spoofing identity
• Tampering with data
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

PASTA (Process for Attack Simulation and Threat Analysis):

• Seven-stage risk-centric methodology
• Aligns business objectives with technical requirements

VAST (Visual, Agile, and Simple Threat modeling):

• Scalable for agile development
• Two types: application threat models and operational threat models

Application: Use threat modeling for new features, architecture changes, or security reviews.

Sources:

• Threat Modeling - OWASP
• STRIDE Threat Model - Microsoft

Foundation 5: MITRE ATT&CK Framework

Description: Knowledge base of adversary tactics and techniques based on real-world observations

Purpose: Understand how attackers operate to inform defense, detection, and threat hunting

Structure:

• Tactics: High-level goals (e.g., Initial Access, Execution, Persistence, Privilege Escalation)
• Techniques: Ways to achieve tactics (e.g., Phishing, Exploiting Public Applications)
• Sub-techniques: Specific implementations
• Procedures: Specific attacker behaviors

14 Tactics (Enterprise Matrix):

1. Reconnaissance 2. Resource Development 3. Initial Access 4. Execution 5. Persistence 6. Privilege Escalation 7. Defense Evasion 8. Credential Access 9. Discovery 10. Lateral Movement 11. Collection 12. Command and Control 13. Exfiltration 14. Impact

Application:

• Map defensive controls to ATT&CK techniques
• Identify detection gaps
• Threat intelligence sharing
• Red team/purple team exercises

Value: Common language for describing attacker behavior; basis for threat-informed defense

Sources:

• MITRE ATT&CK
• ATT&CK Navigator

---

Core Analytical Frameworks (Expandable)

Framework 1: Attack Surface Analysis

Definition: Identification and assessment of all points where unauthorized user could enter or extract data from system

Components:

Attack Surface Elements:

• Network attack surface: Exposed ports, services, protocols
• Software attack surface: Applications, APIs, web interfaces
• Human attack surface: Users, administrators, social engineering targets
• Physical attack surface: Facility access, hardware access

Attack Vectors: Methods attackers use to exploit attack surface

• Network-based: Port scanning, protocol exploits, man-in-the-middle
• Web-based: SQL injection, XSS, CSRF, authentication bypass
• Email-based: Phishing, malicious attachments, credential harvesting
• Physical: Theft, unauthorized access, evil maid attacks
• Social engineering: Pretexting, baiting, tailgating

Analysis Process:

1. Enumerate: List all entry points and assets 2. Classify: Categorize by type and criticality 3. Assess: Evaluate exploitability and impact 4. Prioritize: Rank by risk 5. Reduce: Minimize unnecessary exposure

Metrics:

• Number of exposed services
• Number of internet-facing applications
• Number of privileged accounts
• Lines of code exposed to untrusted input

Application: Reducing attack surface is fundamental defensive strategy. Eliminate unnecessary exposure.

Sources:

• Attack Surface Analysis - OWASP
• Reducing Attack Surface - Microsoft

Framework 2: Risk Assessment Frameworks

Purpose: Quantify and prioritize security risks to guide resource allocation

Common Frameworks:

CVSS (Common Vulnerability Scoring System):

• Standard for assessing vulnerability severity
• Score 0-10 based on exploitability, impact, scope
• Base score (intrinsic characteristics) + temporal + environmental scores
• Widely used but criticized for not capturing actual risk in specific contexts

FAIR (Factor Analysis of Information Risk):

• Quantitative risk framework
• Risk = Loss Event Frequency × Loss Magnitude
• Enables cost-benefit analysis of security investments
• More complex but provides dollar-denominated risk figures

NIST Risk Management Framework (RMF):

• Seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor
• Links security controls to risk management
• Used by U.S. federal agencies

Qualitative vs. Quantitative:

• Qualitative: High/Medium/Low risk ratings (simpler, faster, subjective)
• Quantitative: Numerical risk values (complex, objective, requires data)

Application: Risk assessment informs prioritization. Not all vulnerabilities are equally important—focus on highest risks.

Sources:

• CVSS
• FAIR Institute
• NIST RMF

Framework 3: Security Control Frameworks

Purpose: Structured set of security controls to achieve security objectives

Major Frameworks:

NIST Cybersecurity Framework:

• Five core functions: Identify, Protect, Detect, Respond, Recover
• Not prescriptive—flexible for different organizations
• Widely adopted across industries and internationally

NIST SP 800-53 (Security and Privacy Controls):

• Comprehensive catalog of security controls for federal systems
• 20 control families (Access Control, Incident Response, etc.)
• Detailed implementation guidance

CIS Controls (Center for Internet Security):

• 18 prioritized security controls
• Implementation groups (IG1, IG2, IG3) based on organizational maturity
• Actionable and measurable

ISO/IEC 27001:

• International standard for information security management systems
• 14 control domains, 114 controls
• Certification available

Application: Use frameworks to:

• Ensure comprehensive coverage
• Benchmark security posture
• Communicate with stakeholders
• Meet compliance requirements

Sources:

• NIST Cybersecurity Framework
• CIS Controls
• ISO 27001

Framework 4: Incident Response Lifecycle

Definition: Structured approach to handling security incidents

Standard Model (NIST SP 800-61):

Phase 1: Preparation

• Establish IR capability, tools, playbooks
• Training and exercises
• Communication plans

Phase 2: Detection and Analysis

• Monitoring and alerting
• Incident classification and prioritization
• Initial investigation
• Scope determination

Phase 3: Containment, Eradication, and Recovery

• Containment: Stop spread (short-term and long-term)
• Eradication: Remove threat from environment
• Recovery: Restore systems to normal operation

Phase 4: Post-Incident Activity

• Lessons learned
• Evidence preservation
• Incident report
• Process improvement

Key Concepts:

• Playbooks: Predefined procedures for common incident types
• Indicators of Compromise (IoCs): Artifacts indicating malicious activity
• Chain of custody: Evidence handling procedures
• Communication: Internal and external stakeholders, legal, PR

Metrics:

• Mean Time to Detect (MTTD)
• Mean Time to Respond (MTTR)
• Mean Time to Contain (MTTC)

Application: Effective incident response minimizes damage, reduces recovery time, and captures learning.

Sources:

• NIST SP 800-61: Computer Security Incident Handling Guide
• SANS Incident Response

Framework 5: Secure Development Lifecycle (SDL)

Purpose: Integrate security into software development process

Microsoft SDL Phases:

1. Training: Security training for developers 2. Requirements: Define security requirements and privacy requirements 3. Design: Threat modeling, attack surface reduction, defense in depth 4. Implementation: Secure coding standards, code analysis tools 5. Verification: Security testing (SAST, DAST, penetration testing) 6. Release: Final security review, incident response plan 7. Response: Execute incident response plan if vulnerability discovered

Key Practices:

• Static Analysis (SAST): Analyze source code for vulnerabilities
• Dynamic Analysis (DAST): Test running application
• Dependency Scanning: Check third-party libraries for known vulnerabilities
• Penetration Testing: Simulate real attacks
• Security Champions: Embed security expertise in development teams

OWASP SAMM (Software Assurance Maturity Model):

• Maturity model for secure software development
• Five business functions: Governance, Design, Implementation, Verification, Operations
• Three maturity levels for each function

Application: Security must be integrated throughout development lifecycle, not just at the end.

Sources:

• Microsoft SDL
• OWASP SAMM

---

Methodological Approaches (Expandable)

Method 1: Threat Intelligence Analysis

Purpose: Understand adversaries, their capabilities, tactics, and targets to inform defense

Types of Threat Intelligence:

Strategic: High-level trends for executives

• APT group activity and motivations
• Geopolitical cyber threats
• Industry-specific threat landscape

Operational: Campaign-level information for security operations

• Current attack campaigns
• Threat actor TTPs
• Malware families

Tactical: Technical indicators for immediate defense

• IP addresses, domains, file hashes
• YARA rules, Snort signatures
• CVEs being exploited

Analytical Process:

1. Collection: Gather data from internal sources, threat feeds, OSINT, dark web 2. Processing: Normalize, correlate, deduplicate 3. Analysis: Contextualize, attribute, assess intent and capability 4. Dissemination: Share with relevant teams in actionable format 5. Feedback: Assess effectiveness and refine

Frameworks:

• Diamond Model: Adversary, Capability, Infrastructure, Victim
• Kill Chain: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → C2 → Actions on Objectives
• MITRE ATT&CK: Map observed techniques to ATT&CK matrix

Application: Threat intelligence enables proactive, threat-informed defense rather than generic security measures.

Sources:

• CISA Threat Intelligence
• Threat Intelligence - SANS

Method 2: Penetration Testing

Definition: Authorized simulated attack to evaluate security of systems

Types:

Black Box: No prior knowledge (simulates external attacker)

Gray Box: Partial knowledge (simulates insider or compromised user)

White Box: Full knowledge (comprehensive security assessment)

Phases (Penetration Testing Execution Standard):

1. Pre-engagement: Scope, rules of engagement, legal agreements 2. Intelligence gathering: OSINT, network scanning, service enumeration 3. Threat modeling: Identify potential attack vectors 4. Vulnerability analysis: Identify exploitable weaknesses 5. Exploitation: Attempt to exploit vulnerabilities 6. Post-exploitation: Assess impact, lateral movement, privilege escalation 7. Reporting: Document findings, demonstrate impact, provide remediation guidance

Specialized Types:

• Web application penetration testing: Focus on OWASP Top 10
• Network penetration testing: Internal and external network
• Social engineering: Phishing, vishing, physical intrusion
• Wireless penetration testing: WiFi security assessment

Red Team vs. Penetration Testing:

• Penetration testing: Find as many vulnerabilities as possible
• Red teaming: Goal-oriented (e.g., access specific data), simulates APT, tests detection and response

Application: Regular penetration testing validates effectiveness of controls and identifies gaps before attackers do.

Sources:

• Penetration Testing Execution Standard
• OWASP Testing Guide

Method 3: Security Architecture Review

Purpose: Evaluate system design for security properties and identify architectural vulnerabilities

Review Dimensions:

Structural Analysis:

• Trust boundaries and data flows
• Authentication and authorization architecture
• Network segmentation and isolation
• Data classification and protection

Threat Modeling:

• Apply STRIDE or other methodology
• Identify attack trees
• Assess mitigations for identified threats

Control Assessment:

• Map controls to CIA triad
• Evaluate defense-in-depth layers
• Identify single points of failure

Compliance Review:

• Check against security frameworks (NIST, CIS, ISO)
• Regulatory requirements (PCI-DSS, HIPAA, SOC 2)

Technology Assessment:

• Cryptographic implementation
• Secure protocols
• Patch management approach
• Secret management

Analysis Questions:

• What are trust boundaries?
• Where does sensitive data flow?
• How is authentication/authorization enforced?
• What happens if component X is compromised?
• Are security assumptions documented and validated?

Outputs:

• Architecture diagrams with security annotations
• Threat model
• Risk assessment
• Remediation recommendations

Application: Architecture review during design phase prevents expensive security issues in production.

Method 4: Vulnerability Assessment and Management

Purpose: Systematically identify, classify, prioritize, and remediate security weaknesses

Process:

Phase 1: Discovery

• Asset inventory (what do we have?)
• Vulnerability scanning (automated tools)
• Manual security testing
• Code review (static analysis)

Phase 2: Assessment

• Classify vulnerabilities by type and severity
• Assess exploitability (is there exploit code? Is it being exploited?)
• Determine impact (what data/systems at risk?)
• Calculate risk score (CVSS, contextual factors)

Phase 3: Prioritization

• Rank by risk (likelihood × impact)
• Consider threat intelligence (is it being exploited in wild?)
• Business criticality of affected assets
• Remediation complexity

Phase 4: Remediation

• Patching (ideal)
• Configuration changes
• Compensating controls (if patching impossible)
• Accept risk (document and approve)

Phase 5: Verification

• Rescan to confirm remediation
• Update vulnerability database
• Track metrics (time to remediate, vulnerability density)

Challenges:

• Alert fatigue (too many findings)
• False positives
• Patching disruption
• Legacy systems

Best Practices:

• Risk-based prioritization (not just CVSS)
• SLA-based remediation (Critical: 7 days, High: 30 days, etc.)
• Automate where possible
• Track trends and metrics

Application: Continuous vulnerability management is essential hygiene. Can't fix what you don't know about.

Sources:

• NIST SP 800-40: Patch and Vulnerability Management

Method 5: Security Monitoring and Detection Engineering

Purpose: Design and operate capabilities to detect malicious activity

Components:

Data Sources:

• Network traffic (NetFlow, full packet capture)
• Endpoint logs (process creation, file access, registry changes)
• Authentication logs (logins, privilege escalation)
• Application logs (errors, transactions)
• Cloud APIs and audit logs

Detection Mechanisms:

Signature-based: Known malicious patterns (antivirus, IDS signatures)

• Pros: Low false positives, fast
• Cons: Only detects known threats

Anomaly-based: Deviations from baseline behavior

• Pros: Can detect novel attacks
• Cons: High false positives, requires tuning

Heuristic-based: Rules based on attacker behavior patterns

• Pros: Detects variations of known attacks
• Cons: Requires security expertise to create rules

Threat intelligence-based: Match against known IoCs

• Pros: Leverages collective knowledge
• Cons: Reactive (indicators discovered post-compromise)

Detection Development:

1. Understand attacker technique (MITRE ATT&CK) 2. Identify data sources that capture technique 3. Develop detection logic 4. Test against true positives and false positives 5. Tune threshold and logic 6. Document detection and response procedures 7. Monitor effectiveness and iterate

SIEM and SOC:

• SIEM: Aggregate, correlate, and analyze security logs
• SOC: Security Operations Center—team that monitors alerts and responds to incidents

Metrics:

• Detection coverage (% of ATT&CK techniques covered)
• Alert volume and quality
• False positive rate
• Mean Time to Detect (MTTD)

Application: You can't respond to what you don't detect. Invest in detection capabilities aligned to threats you face.

Sources:

• Detection Engineering - Splunk
• Sigma Rules

---

Analysis Rubric

What to Examine

Assets and Data:

• What sensitive data exists? (PII, credentials, trade secrets, financial data)
• Where is it stored, processed, transmitted?
• Who has access?
• What is business impact if compromised? (confidentiality, integrity, availability)

Attack Surface:

• What systems are exposed to internet?
• What are entry points for attackers?
• What authentication is required?
• What third-party dependencies exist?

Threat Actors:

• Who might target this? (Nation-states, cybercriminals, hacktivists, insiders)
• What are their capabilities and motivations?
• What TTPs do they typically use?
• What threat intelligence exists?

Vulnerabilities:

• Known software vulnerabilities (CVEs)?
• Configuration weaknesses?
• Architectural security flaws?
• Code-level vulnerabilities?
• Human vulnerabilities (phishing susceptibility)?

Existing Controls:

• What security controls are in place?
• Do they follow defense-in-depth principles?
• Are they properly configured and maintained?
• What detection and response capabilities exist?

Questions to Ask

Threat Questions:

• What could go wrong?
• What are most likely attack vectors?
• What threat actors might target this?
• What are their goals and capabilities?
• What historical incidents are relevant?

Vulnerability Questions:

• What weaknesses exist?
• How exploitable are they?
• What is impact if exploited?
• Are there known exploits or active exploitation?
• How quickly can vulnerabilities be remediated?

Control Questions:

• What protections are in place?
• How effective are they?
• What gaps exist in defensive coverage?
• Can controls be bypassed?
• How will malicious activity be detected?

Risk Questions:

• What is likelihood of compromise?
• What is potential impact?
• What is overall risk level?
• How does risk compare to organization's risk appetite?
• What risk treatment options exist? (mitigate, accept, transfer, avoid)

Compliance Questions:

• What regulations or standards apply?
• Are security requirements met?
• What evidence demonstrates compliance?
• What gaps exist?

Factors to Consider

Technical Factors:

• System architecture and design
• Technology stack and versions
• Configuration and hardening
• Cryptographic implementation
• Network topology and segmentation

Organizational Factors:

• Security maturity and culture
• Available resources and budget
• Risk tolerance
• Regulatory environment
• Business criticality

Threat Landscape:

• Current threat actor activity
• Emerging attack techniques
• Industry-specific threats
• Geopolitical factors

Operational Factors:

• Patch management processes
• Incident response capabilities
• Security monitoring and detection
• Security awareness and training
• Third-party risk management

Historical Parallels to Consider

• Similar security incidents
• Comparable vulnerability exploits
• Industry-specific attack patterns
• Lessons from major breaches
• Evolution of threat actor TTPs

Implications to Explore

Immediate Security Implications:

• Confidentiality: Data breach risk
• Integrity: Data tampering or corruption risk
• Availability: Service disruption risk
• Financial: Ransom, recovery costs, fines

Broader Implications:

• Reputation damage
• Legal and regulatory consequences
• Customer trust erosion
• Competitive disadvantage
• Systemic risk (if in critical infrastructure)

Strategic Implications:

• Security architecture changes needed
• Security program maturity gaps
• Resource allocation and prioritization
• Risk management approach

---

Step-by-Step Analysis Process

Step 1: Define Scope and Context

Actions:

• Clearly identify system, application, or event being analyzed
• Determine boundaries and interfaces
• Identify stakeholders and their security requirements
• Understand business context and criticality
• Gather relevant documentation (architecture diagrams, data flows, policies)

Outputs:

• Scope statement
• Asset inventory
• Stakeholder list
• Business context understanding

Step 2: Identify Assets and Data

Actions:

• List critical assets (systems, data, services)
• Classify data by sensitivity (public, internal, confidential, restricted)
• Map data flows (where data is created, stored, processed, transmitted, destroyed)
• Identify crown jewels (most valuable assets)

Outputs:

• Asset inventory with criticality ratings
• Data classification matrix
• Data flow diagrams
• Crown jewels list

Step 3: Analyze Attack Surface

Actions:

• Enumerate all entry points (APIs, web interfaces, network services, physical access)
• Identify trust boundaries (where untrusted input crosses into trusted zones)
• Map authentication and authorization points
• Identify dependencies (third-party services, libraries, suppliers)

Outputs:

• Attack surface map
• Trust boundary diagram
• Entry point inventory
• Dependency list

Step 4: Conduct Threat Modeling

Actions:

• Select threat modeling methodology (STRIDE, PASTA, etc.)
• Identify potential threat actors and their goals
• Enumerate potential attack vectors for each asset
• Create attack trees showing attack paths
• Map to MITRE ATT&CK techniques

Outputs:

• Threat model document
• Threat actor profiles
• Attack tree diagrams
• ATT&CK technique mapping

Step 5: Identify Vulnerabilities

Actions:

• Review known CVEs for technologies in use
• Analyze configuration against security benchmarks (CIS, STIGs)
• Review architecture for security design flaws
• Consider code-level vulnerabilities (if applicable)
• Assess human vulnerabilities (phishing susceptibility, privilege misuse)

Outputs:

• Vulnerability inventory
• CVSS scores or risk ratings
• Configuration gap analysis
• Architectural security issues

Step 6: Assess Existing Controls

Actions:

• Inventory security controls across all layers (network, host, application, data)
• Map controls to threats (which threats do controls mitigate?)
• Evaluate control effectiveness (properly configured? maintained? monitored?)
• Identify control gaps (threats without adequate mitigation)
• Assess detection and response capabilities

Outputs:

• Control inventory
• Threat-control mapping matrix
• Control effectiveness assessment
• Detection coverage gaps

Step 7: Analyze Risk

Actions:

• For each threat-vulnerability pair, estimate likelihood and impact
• Calculate risk scores (qualitative or quantitative)
• Prioritize risks
• Compare to organizational risk tolerance
• Consider risk interdependencies and cascading effects

Outputs:

• Risk register
• Risk heat map
• Prioritized risk list
• Risk acceptance recommendations

Step 8: Evaluate Detection and Response

Actions:

• Assess what malicious activities would be detected
• Evaluate MTTD (Mean Time to Detect) for various attack scenarios
• Review incident response plans and playbooks
• Assess incident response team capabilities
• Identify gaps in detection or response

Outputs:

• Detection coverage assessment
• MTTD estimates
• IR capability assessment
• Detection and response gaps

Step 9: Develop Remediation Recommendations

Actions:

• Propose mitigations for identified risks (preventive, detective, corrective)
• Prioritize by risk reduction and implementation effort
• Consider compensating controls where direct mitigation is impractical
• Estimate costs and implementation timelines
• Document risk acceptance for risks not mitigated

Outputs:

• Remediation roadmap
• Prioritized recommendation list
• Cost-benefit analysis
• Risk acceptance documentation

Step 10: Consider Compliance Requirements

Actions:

• Identify applicable regulations and standards
• Map controls to compliance requirements
• Document evidence of compliance
• Identify compliance gaps
• Recommend actions to achieve or maintain compliance

Outputs:

• Compliance matrix
• Gap analysis
• Evidence documentation
• Compliance remediation plan

Step 11: Synthesize and Report

Actions:

• Summarize key findings for different audiences (executives, technical teams, compliance)
• Provide clear risk assessment and recommendations
• Include metrics and KPIs
• Document assumptions and limitations
• Create action plan with owners and timelines

Outputs:

• Executive summary
• Technical findings report
• Remediation roadmap
• Compliance summary

---

Usage Examples

Example 1: Security Incident - Ransomware Attack

Event: Organization experiences ransomware attack; files encrypted, ransom note demands payment

Analysis:

Step 1 - Scope and Context:

• Affected systems: File servers, workstations, backups
• Business impact: Operations halted, data unavailable
• Critical: Understand ransomware variant, encryption scope, attacker access

Step 2 - Assets:

• Crown jewels: Customer database, financial records, intellectual property
• Status: Files encrypted, availability compromised

Step 3 - Attack Surface Analysis:

• Initial access vector: Likely phishing email or vulnerable RDP endpoint
• Lateral movement: SMB, credential theft

Step 4 - Threat Modeling (Post-Incident):

• Threat actor: Likely cybercriminal group (financial motivation)
• ATT&CK mapping:
• Initial Access: Phishing or Exploit Public-Facing Application
• Execution: User Execution or Exploitation for Client Execution
• Persistence: Registry Run Keys, Scheduled Tasks
• Privilege Escalation: Exploitation for Privilege Escalation
• Credential Access: Credential Dumping
• Lateral Movement: SMB/Windows Admin Shares
• Impact: Data Encrypted for Impact

Step 5 - Vulnerabilities:

• Phishing susceptibility (no email filtering, insufficient user training)
• Unpatched RDP vulnerabilities
• Weak passwords or credential reuse
• Inadequate network segmentation (ransomware spread easily)
• Backup vulnerabilities (backups also encrypted)

Step 6 - Control Assessment:

• Missing: Email security gateway, EDR, MFA
• Inadequate: Network segmentation, backup isolation, patch management
• Failed: Antivirus didn't detect ransomware

Step 7 - Risk Analysis:

• Impact: HIGH (business disruption, data loss, ransom demand, reputation damage)
• Likelihood: HIGH (demonstrated—incident occurred)
• Residual risk: CRITICAL (without improvements, repeat likely)

Step 8 - Detection and Response:

• Detection: Failed until encryption began (no EDR, limited logging)
• MTTD: Hours to days (too slow)
• Response: No playbook, uncoordinated response
• Gaps: No IR team, no communication plan, no legal/PR coordination

Step 9 - Recommendations (Prioritized):

_Immediate (Hours to Days)_:

1. Isolate affected systems (contain spread) 2. Identify ransomware variant and check for decryption tools 3. Engage incident response firm if no internal capability 4. Do NOT pay ransom immediately (assess alternatives first) 5. Notify legal, insurance, possibly law enforcement

_Short-term (Days to Weeks)_:

1. Restore from backups if available and uncompromised 2. Deploy EDR on all endpoints 3. Implement MFA for all remote access 4. Conduct forensic investigation to determine root cause and scope 5. Develop and test IR playbook

_Medium-term (Weeks to Months)_:

1. Network segmentation (prevent lateral movement) 2. Email security gateway (block phishing) 3. Privileged access management (limit credential theft) 4. Security awareness training (reduce phishing success) 5. Backup hardening (air-gapped or immutable backups)

_Long-term (Months to Year)_:

1. Security maturity assessment and roadmap 2. 24/7 SOC or MDR service 3. Penetration testing and red team exercises 4. Comprehensive vulnerability management program

Step 10 - Compliance:

• Regulatory notification requirements (GDPR, state breach laws, etc.)
• Cyber insurance claim
• Document incident for auditors

Step 11 - Synthesis:

• Root cause: Combination of phishing/RDP exploit + inadequate detection + weak segmentation + backup vulnerabilities
• Key lesson: Defense-in-depth failures—multiple control failures allowed attack to succeed
• Priority: Immediate containment and recovery, then build detective and preventive controls
• Cost: Ransom demand + downtime + recovery + remediation + reputation damage (potentially millions)

Example 2: Vulnerability Assessment - New Web Application Launch

Event: Organization planning to launch customer-facing web application; pre-launch security review requested

Analysis:

Step 1 - Scope:

• Application: E-commerce web application
• Users: External customers
• Data: PII, payment information, order history
• Criticality: HIGH (revenue-generating, customer trust)

Step 2 - Assets:

• Customer PII and payment data (confidentiality, integrity critical)
• Inventory and pricing data (integrity, availability critical)
• Application availability (revenue impact)

Step 3 - Attack Surface:

• Web interface (public-facing)
• APIs (mobile app, third-party integrations)
• Admin portal (internal users)
• Payment processor integration
• Third-party libraries and dependencies

Step 4 - Threat Modeling (STRIDE):

Spoofing:

• Threat: Attacker impersonates user or admin
• Mitigations: Strong authentication, MFA, session management

Tampering:

• Threat: Attacker modifies prices, orders, or user data
• Mitigations: Input validation, authorization checks, integrity controls

Repudiation:

• Threat: User denies placing order
• Mitigations: Audit logging, transaction signing

Information Disclosure:

• Threat: Attacker accesses other users' PII or payment info
• Mitigations: Authorization checks, encryption, secure session management

Denial of Service:

• Threat: Attacker overwhelms application
• Mitigations: Rate limiting, DDoS protection, scalable infrastructure

Elevation of Privilege:

• Threat: User gains admin access
• Mitigations: Least privilege, secure authorization, privilege separation

Step 5 - Vulnerabilities (OWASP Top 10 Analysis):

1. Broken Access Control: Check for IDOR vulnerabilities, horizontal/vertical privilege escalation 2. Cryptographic Failures: Verify encryption at rest and in transit, key management 3. Injection: Test for SQL injection, XSS, command injection 4. Insecure Design: Review for security design flaws, threat model gaps 5. Security Misconfiguration: Check for default credentials, unnecessary features, verbose errors 6. Vulnerable Components: Scan dependencies for known CVEs 7. Authentication Failures: Test password policy, session management, MFA 8. Software/Data Integrity: Verify supply chain security, unsigned updates 9. Logging Failures: Ensure security events logged, log tampering prevention 10. SSRF: Test for server-side request forgery vulnerabilities

Step 6 - Control Assessment:

_Positive Findings_:

• TLS 1.3 for all connections
• Passwords hashed with bcrypt
• Input validation framework in use
• Dependency scanning in CI/CD

_Gaps Identified_:

• No MFA for customer accounts
• Admin portal not on separate domain/network
• Verbose error messages expose stack traces
• No rate limiting on API endpoints
• Some third-party dependencies have known CVEs
• Insufficient authorization checks (IDOR vulnerabilities)
• No Web Application Firewall (WAF)

Step 7 - Risk Analysis:

_Critical Risks_:

• IDOR vulnerabilities: HIGH likelihood, HIGH impact (data breach)
• Vulnerable dependencies: MEDIUM likelihood, HIGH impact (RCE potential)

_High Risks_:

• No rate limiting: HIGH likelihood, MEDIUM impact (scraping, brute force)
• Admin portal on same domain: LOW likelihood, HIGH impact (credential theft)

_Medium Risks_:

• Verbose errors: MEDIUM likelihood, MEDIUM impact (information disclosure)
• No MFA: LOW likelihood (for now), HIGH impact (account takeover)

Step 8 - Detection and Response:

• Logging: Adequate for authentication and transactions
• SIEM integration: Not yet configured
• IR playbook: Generic, needs application-specific scenarios
• Recommendation: Configure SIEM, create app-specific IR playbook, implement alerting for suspicious patterns

Step 9 - Recommendations (Prioritized by Risk):

_Must-Fix Before Launch (Critical)_:

1. Fix IDOR vulnerabilities (implement authorization checks) 2. Update vulnerable dependencies 3. Remove verbose error messages in production 4. Implement rate limiting on all endpoints

_Should-Fix Before Launch (High)_:

1. Deploy WAF with OWASP Core Rule Set 2. Separate admin portal (different domain, VPN/IP restriction) 3. Configure SIEM integration and alerting

_Post-Launch (Medium)_:

1. Implement MFA for customer accounts 2. Enhance logging (capture more security events) 3. Conduct penetration testing 4. Establish bug bounty program

Step 10 - Compliance:

• PCI-DSS: Required for payment card data (use tokenization, minimize cardholder data environment)
• GDPR/CCPA: Customer data privacy requirements (consent, data minimization, breach notification)
• SOC 2: If B2B customers require assurance

Step 11 - Synthesis:

• Application has solid foundation (modern crypto, input validation, dependency scanning)
• Critical issues must be fixed before launch (IDOR, vulnerable dependencies)
• WAF provides defense-in-depth for web threats
• Post-launch: Continue testing, bug bounty, security monitoring
• Go/No-Go: NO GO until critical issues resolved

Example 3: Security Architecture Review - Cloud Migration

Event: Organization planning to migrate on-premises applications to AWS; security architecture review requested

Analysis:

Step 1 - Scope:

• Migration: 50+ applications, mix of web apps, APIs, databases
• Target: AWS (IaaS and PaaS services)
• Timeline: 12-month migration
• Criticality: Mixed (some business-critical applications)

Step 2 - Assets:

• Applications and data currently in controlled on-premises environment
• Concerns: Data sovereignty, compliance, shared responsibility model

Step 3 - Attack Surface Changes:

• Increases: Internet-facing cloud services, cloud management interfaces, broader attack surface
• Decreases: Physical access threats
• New: Cloud misconfigurations, IAM vulnerabilities, API security

Step 4 - Threat Modeling (Cloud-Specific):

_Cloud-Specific Threats_:

• Account compromise (stolen credentials, phishing)
• Misconfigured storage buckets (public S3 buckets)
• Overly permissive IAM policies
• Insufficient network segmentation (VPC design)
• Data exfiltration via cloud APIs
• Insider threats (cloud admin abuse)
• Supply chain (compromised cloud services or dependencies)

_MITRE ATT&CK for Cloud_:

• Initial Access: Valid accounts, exploit public-facing application
• Persistence: Account manipulation, create IAM user
• Privilege Escalation: IAM policy manipulation
• Defense Evasion: Disable cloud logs
• Credential Access: Unsecured credentials in code/config
• Discovery: Cloud service discovery
• Lateral Movement: Use alternate authentication material
• Exfiltration: Transfer data to cloud account

Step 5 - Vulnerabilities (Cloud Context):

• Lack of cloud security expertise
• On-premises mindset (perimeter-focused, not zero-trust)
• Unclear cloud IAM strategy
• No cloud configuration management (IaC not used)
• No cloud security posture management (CSPM)

Step 6 - Control Assessment (Shared Responsibility Model):

_AWS Responsibilities_ (Security OF the Cloud):

• Physical security
• Hypervisor security
• Network infrastructure

_Customer Responsibilities_ (Security IN the Cloud):

• IAM and access control
• Data encryption
• Network configuration (VPCs, security groups)
• Application security
• Compliance

_Proposed Controls_:

Identity and Access Management:

• Implement AWS Organizations with SCPs (Service Control Policies)
• Enforce MFA for all users
• Use IAM roles, not long-term credentials
• Principle of least privilege
• Regular access reviews

Network Security:

• VPC design with public/private subnets
• Security groups (stateful firewalls)
• NACLs (stateless firewalls)
• AWS WAF for web applications
• VPC Flow Logs for monitoring

Data Protection:

• Encryption at rest (S3, EBS, RDS with KMS)
• Encryption in transit (TLS)
• S3 bucket policies (block public access)
• Data classification and handling

Monitoring and Detection:

• AWS CloudTrail (API logging)
• AWS GuardDuty (threat detection)
• AWS Security Hub (aggregate findings)
• AWS Config (configuration compliance)
• SIEM integration

Incident Response:

• Cloud-specific IR playbooks
• Automate response with Lambda
• Snapshot and forensics procedures
• AWS support engagement plan

Compliance:

• AWS Artifact (compliance reports)
• AWS Config rules (continuous compliance)
• Encryption for HIPAA/PCI-DSS
• Data residency (region selection)

Step 7 - Risk Analysis:

_High Risks_:

• Misconfigured S3 buckets (likelihood: high, impact: high - data breach)
• Compromised IAM credentials (likelihood: medium, impact: high)
• Insufficient monitoring (likelihood: high, impact: medium - delayed detection)

_Medium Risks_:

• Inadequate network segmentation (likelihood: medium, impact: medium)
• Lack of cloud expertise (likelihood: high, impact: medium - misconfigurations)

Step 8 - Detection and Response:

• Deploy GuardDuty in all regions and accounts
• Centralize CloudTrail logs
• Configure Security Hub and Config
• Create cloud-specific alerts (unusual API calls, IAM changes, public S3 buckets)
• Develop cloud incident response playbooks

Step 9 - Recommendations (Cloud Migration Security Roadmap):

_Pre-Migration (Month 1-2)_:

1. Cloud security training for teams 2. Design AWS Organizations structure and account strategy 3. Define IAM strategy and policies 4. Design VPC architecture and network segmentation 5. Select and implement CSPM tool 6. Establish cloud security baseline (CIS AWS Foundations Benchmark)

_During Migration (Month 3-12)_:

1. Use Infrastructure as Code (Terraform/CloudFormation) for all resources 2. Automate security checks in CI/CD (SAST, DAST, IaC scanning) 3. Enforce encryption at rest and in transit 4. Implement least privilege IAM 5. Enable all cloud-native security services (GuardDuty, Security Hub, Config, CloudTrail) 6. Security testing before production deployment

_Post-Migration (Ongoing)_:

1. Continuous compliance monitoring 2. Regular IAM access reviews 3. Cloud security posture assessments 4. Penetration testing in cloud environment 5. Tabletop exercises for cloud IR scenarios

Step 10 - Compliance:

• Leverage AWS compliance certifications (SOC 2, ISO 27001, PCI-DSS)
• Use AWS Artifact for audit evidence
• Implement AWS Config rules for continuous compliance
• Document shared responsibility matrix

Step 11 - Synthesis:

• Cloud security requires different mindset (zero-trust, identity-centric, API-driven)
• Shared responsibility model is critical—must secure what AWS doesn't
• Major risks: Misconfigurations, IAM vulnerabilities, insufficient monitoring
• Opportunities: Cloud-native security services, automation, scalability
• Success factors: Training, least privilege, defense-in-depth, monitoring, IaC
• Recommendation: Proceed with migration, but implement security roadmap in parallel

---

Reference Materials (Expandable)

Essential Organizations and Resources

NIST (National Institute of Standards and Technology)

• Cybersecurity Framework: https://www.nist.gov/cyberframework
• SP 800 Series: Security and privacy controls, risk management
• National Vulnerability Database (NVD): https://nvd.nist.gov/

CISA (Cybersecurity and Infrastructure Security Agency)

• Alerts and Advisories: https://www.cisa.gov/topics/cyber-threats-and-advisories
• Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Resources: Free tools, training, best practices

MITRE

• ATT&CK Framework: https://attack.mitre.org/
• CVE Program: https://www.cve.org/
• CAPEC: Common Attack Pattern Enumeration and Classification

OWASP (Open Web Application Security Project)

• Top 10: https://owasp.org/www-project-top-ten/
• Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
• Cheat Sheets: https://cheatsheetseries.owasp.org/

SANS Institute

• Internet Storm Center: https://isc.sans.edu/
• Reading Room: Thousands of security papers
• Critical Security Controls: https://www.cisecurity.org/controls

Key Standards and Frameworks

ISO/IEC 27001: Information Security Management System ISO/IEC 27002: Information Security Controls PCI-DSS: Payment Card Industry Data Security Standard HIPAA: Health Insurance Portability and Accountability Act (Security Rule) SOC 2: Service Organization Control 2 (Trust Services Criteria) GDPR: General Data Protection Regulation NIST SP 800-53: Security and Privacy Controls CIS Controls: Center for Internet Security Critical Security Controls FedRAMP: Federal Risk and Authorization Management Program

Vulnerability Databases

• National Vulnerability Database (NVD): https://nvd.nist.gov/
• CVE: https://www.cve.org/
• Exploit-DB: https://www.exploit-db.com/
• VulnDB: https://vulndb.cyberriskanalytics.com/

Threat Intelligence Sources

• CISA Alerts: https://www.cisa.gov/news-events/cybersecurity-advisories
• US-CERT: https://www.cisa.gov/uscert
• Threat Intelligence Platforms: Recorded Future, Mandiant, CrowdStrike
• Open Source: AlienVault OTX, MISP, threat feeds

Security Tools and Platforms

Vulnerability Scanning: Nessus, Qualys, Rapid7 InsightVM SAST: SonarQube, Checkmarx, Veracode DAST: Burp Suite, OWASP ZAP, Acunetix SIEM: Splunk, Elastic, Sentinel, Chronicle EDR: CrowdStrike, SentinelOne, Microsoft Defender for Endpoint CSPM: Prisma Cloud, Wiz, Orca Security

Certifications

• CISSP: Certified Information Systems Security Professional
• CISM: Certified Information Security Manager
• CEH: Certified Ethical Hacker
• OSCP: Offensive Security Certified Professional
• GCIH: GIAC Certified Incident Handler
• Security+: CompTIA Security+

Communities and Resources

• r/netsec: https://www.reddit.com/r/netsec/
• Krebs on Security: https://krebsonsecurity.com/
• Schneier on Security: https://www.schneier.com/
• Dark Reading: https://www.darkreading.com/
• The Hacker News: https://thehackernews.com/

---

Verification Checklist

After completing cybersecurity analysis:

• [ ] Identified all critical assets and data
• [ ] Analyzed attack surface and entry points
• [ ] Conducted threat modeling appropriate to scope
• [ ] Identified vulnerabilities and assessed severity
• [ ] Evaluated existing security controls for effectiveness
• [ ] Analyzed risk using quantitative or qualitative methods
• [ ] Assessed detection and response capabilities
• [ ] Developed prioritized remediation recommendations
• [ ] Considered compliance requirements
• [ ] Mapped threats to MITRE ATT&CK framework (if applicable)
• [ ] Applied defense-in-depth and zero-trust principles
• [ ] Provided clear, actionable security guidance
• [ ] Used security terminology and frameworks precisely

---

Common Pitfalls to Avoid

Pitfall 1: Checklist Compliance Without Risk Context

• Problem: Following compliance requirements without understanding actual risks
• Solution: Risk-based approach—understand threats and business context, not just checkboxes

Pitfall 2: Perimeter-Only Security

• Problem: Assuming network perimeter protects everything inside
• Solution: Defense-in-depth and zero-trust—assume breach, protect assets themselves

Pitfall 3: Alert Fatigue and False Positives

• Problem: Too many low-quality alerts overwhelm responders
• Solution: Tune detections, prioritize high-fidelity alerts, automate response where possible

Pitfall 4: Ignoring Human Element

• Problem: Focus only on technical controls, ignore social engineering and insider threats
• Solution: Include security awareness, privileged user monitoring, insider threat programs

Pitfall 5: Point-in-Time Assessment

• Problem: One-time security review without continuous monitoring
• Solution: Continuous security—ongoing monitoring, vulnerability management, threat intelligence

Pitfall 6: Vulnerability Scoring Without Context

• Problem: Prioritizing by CVSS alone without considering exploitability or business context
• Solution: Risk-based prioritization—consider threat intelligence, exploitability, asset criticality

Pitfall 7: Security as Blocker

• Problem: Security seen as obstacle to business objectives
• Solution: Enable business securely—balance risk and business value, provide secure alternatives

Pitfall 8: Ignoring Supply Chain and Third Parties

• Problem: Focus only on first-party systems, ignore dependencies
• Solution: Supply chain risk management—assess third-party security, dependency vulnerabilities

---

Success Criteria

A quality cybersecurity analysis:

• [ ] Applies appropriate security frameworks and methodologies
• [ ] Identifies and prioritizes risks using threat modeling
• [ ] Evaluates security controls across multiple layers (defense-in-depth)
• [ ] Provides actionable, prioritized remediation recommendations
• [ ] Grounds analysis in threat intelligence and industry best practices
• [ ] Considers both technical and human factors
• [ ] Addresses detection and response, not just prevention
• [ ] Maps to recognized standards (MITRE ATT&CK, NIST CSF, etc.)
• [ ] Balances security with business objectives
• [ ] Demonstrates deep security expertise and critical thinking
• [ ] Communicates clearly to both technical and non-technical audiences
• [ ] Uses security concepts and terminology precisely

---

Integration with Other Analysts

Cybersecurity analysis complements other perspectives:

• Computer Scientist: Deep technical understanding of systems and code
• Lawyer: Legal implications of breaches, regulatory compliance requirements
• Economist: Cost-benefit analysis of security investments, cyber insurance
• Psychologist: Human behavior, social engineering, security culture
• Political Scientist: Nation-state threats, geopolitical cyber conflict, policy

Cybersecurity is particularly strong on:

• Threat modeling and risk assessment
• Vulnerability analysis
• Defense-in-depth design
• Incident detection and response
• Compliance and standards

---

Continuous Improvement

This skill evolves through:

• New threat actor TTPs and attack techniques
• Emerging vulnerabilities and exploits
• Evolution of security technologies and practices
• Lessons learned from security incidents
• Updates to frameworks and standards
• Cross-disciplinary security research

---

Skill Status: Complete - Comprehensive Cybersecurity Analysis Capability Quality Level: High - Enterprise-grade security analysis with modern frameworks Token Count: ~8,500 words (target 6-10K tokens)

Cybersecurity Analyst - Quick Reference

TL;DR

Analyze systems through security lenses: threat modeling (STRIDE), vulnerability assessment, cryptography validation, access control, incident response, and application security. Apply defense-in-depth and assume breach mentality to protect confidentiality, integrity, and availability.

When to Use

Perfect For:

• System and application security design
• Threat modeling and risk assessment
• Code review for security vulnerabilities
• Incident response and forensics
• Compliance assessment (SOC 2, GDPR, HIPAA)
• Security architecture review
• Penetration testing scoping
• Cryptography implementation review
• Access control design

Skip If:

• System has no security requirements
• Working with purely public, non-sensitive data
• Focused on pure functionality without threat context

Core Frameworks

CIA Triad

The foundation of security:

• Confidentiality - Prevent unauthorized information disclosure
• Integrity - Prevent unauthorized modification
• Availability - Ensure authorized users can access system

STRIDE Threat Model

Six threat categories:

1. Spoofing - Impersonating user/system (authentication) 2. Tampering - Modifying data/code (integrity) 3. Repudiation - Denying actions (logging/audit) 4. Information Disclosure - Exposing data (confidentiality) 5. Denial of Service - Making unavailable (availability) 6. Elevation of Privilege - Gaining unauthorized access (authorization)

OWASP Top 10 (2021)

Most critical web vulnerabilities:

1. Broken Access Control 2. Cryptographic Failures 3. Injection 4. Insecure Design 5. Security Misconfiguration 6. Vulnerable and Outdated Components 7. Identification and Authentication Failures 8. Software and Data Integrity Failures 9. Security Logging and Monitoring Failures 10. Server-Side Request Forgery (SSRF)

Defense in Depth

Multiple security layers:

• Perimeter - Firewall, VPN
• Network - Segmentation, IDS/IPS
• Host - Endpoint protection, hardening
• Application - Input validation, secure coding
• Data - Encryption, access control
• User - MFA, least privilege, training

Quick Analysis Steps

Step 1: Asset and Trust Boundary Identification (5 min)

• What assets need protection? (data, systems, users)
• What are the trust boundaries? (internet/DMZ, DMZ/internal, user/admin)
• Who are potential attackers? (external, insider, nation-state)
• What's the impact if compromised? (financial, reputation, legal)

Step 2: STRIDE Threat Modeling (10 min)

For each component/interface:

• S: Can attacker impersonate? (weak auth, no MFA)
• T: Can data be tampered? (no integrity checks, MITM)
• R: Can actions be denied? (no audit logging)
• I: Can data be leaked? (no encryption, excessive permissions)
• D: Can service be disrupted? (no rate limiting, resource exhaustion)
• E: Can privileges be escalated? (injection flaws, broken access control)

Step 3: Vulnerability Identification (10 min)

Check for common vulnerabilities:

• Input validation - SQL injection, XSS, command injection
• Authentication - Weak passwords, no MFA, session fixation
• Authorization - Broken access control, insecure direct object references
• Cryptography - Weak algorithms, hardcoded keys, plain text passwords
• Configuration - Default credentials, unnecessary services, verbose errors
• Dependencies - Known CVEs, outdated libraries

Step 4: Attack Surface Assessment (7 min)

• List all entry points (APIs, forms, file uploads, network ports)
• Identify external vs. internal interfaces
• Map unauthenticated vs. authenticated access
• Count input sources requiring validation
• Prioritize highest-risk interfaces

Step 5: Security Controls Evaluation (10 min)

Assess existing controls:

• Prevention - Input validation, access control, encryption
• Detection - Logging, monitoring, anomaly detection
• Response - Incident response plan, backup/recovery
• Gaps - What's missing? What's weak?

Step 6: Risk Prioritization and Recommendations (8 min)

• Calculate risk: Likelihood × Impact
• Prioritize by CVSS score or qualitative risk (Critical, High, Medium, Low)
• Recommend mitigations (prevent, detect, respond)
• Quick wins vs. long-term hardening
• Ensure defense in depth

Key Security Principles

Least Privilege

Give minimum necessary permissions:

• Users: Only access they need for their job
• Services: Run with minimal OS privileges
• APIs: Scoped tokens, not full access
• Databases: Specific grants, not root

Fail Securely

On error, default to secure state:

• Authentication failure → Deny access (not grant)
• Authorization error → Deny (not allow)
• Crypto error → Reject (not continue insecurely)

Never Trust Input

All input is malicious until validated:

• Validate on server side (not just client)
• Whitelist, don't blacklist
• Encode output to prevent XSS
• Use parameterized queries to prevent SQLi

Defense in Depth

Never rely on single security control - layer multiple defenses.

Common Vulnerabilities

Injection Flaws

SQL Injection: Attacker injects SQL into queries

• Prevention: Parameterized queries, ORMs, input validation

Command Injection: Attacker executes OS commands

• Prevention: Avoid system calls, validate/sanitize input, use safe APIs

XSS (Cross-Site Scripting): Attacker injects malicious scripts

• Prevention: Output encoding, Content Security Policy, HTTPOnly cookies

Broken Authentication

• Weak passwords: No complexity requirements
• No MFA: Single factor is insufficient
• Session fixation/hijacking: Predictable session IDs

Prevention: Strong password policy, MFA, secure session management

Broken Access Control

• IDOR (Insecure Direct Object References): Access objects by guessing IDs
• Path traversal: Access unauthorized files (../../../etc/passwd)
• Missing authorization: Forgot to check permissions

Prevention: Validate authorization on every request, use indirect references

Sensitive Data Exposure

• Unencrypted data: Plain text passwords, credit cards
• Weak crypto: MD5, DES, ECB mode
• Insecure transmission: HTTP instead of HTTPS

Prevention: Encrypt at rest and in transit, use strong algorithms (AES-256, SHA-256, Argon2)

Resources

Quick Checklists

• OWASP Top 10 - Most critical web vulnerabilities
• OWASP ASVS - Application Security Verification Standard
• CIS Benchmarks - Hardening guides for systems

Essential Tools

• Burp Suite - Web security testing
• OWASP ZAP - Automated vulnerability scanning
• Snyk/Dependabot - Dependency vulnerability checking
• Nmap - Network reconnaissance
• Wireshark - Network traffic analysis

Learning Resources

• PortSwigger Web Security Academy - Free web security training
• OWASP Cheat Sheets - Quick security guidance
• HackerOne/BugCrowd - Bug bounty programs for practice

Red Flags

Major Security Issues:

• Passwords in plain text or weak hashes (MD5, SHA-1)
• No input validation on user-supplied data
• Hardcoded secrets (API keys, passwords) in code
• Default credentials not changed
• No HTTPS (HTTP only)
• Missing authentication/authorization checks
• Verbose error messages exposing system details
• SQL queries built with string concatenation
• Outdated dependencies with known CVEs
• No security logging or monitoring

Integration Tips

Combine with other skills:

• Computer Scientist - Cryptography theory, complexity
• Lawyer - Compliance and regulatory requirements
• Systems Thinker - Attack propagation and cascading failures
• Psychologist - Social engineering and human factors
• Engineer - Secure implementation and hardening

Success Metrics

You've done this well when:

• All components threat modeled with STRIDE
• Critical vulnerabilities identified and prioritized
• Defense in depth applied (multiple layers)
• Cryptography uses modern, secure algorithms
• All inputs validated, all outputs encoded
• Least privilege enforced throughout
• Security logging captures relevant events
• Incident response plan defined
• Dependencies scanned for known CVEs
• Compliance requirements mapped and met
• Risk assessment completed with prioritized remediation

Cybersecurity Analyst

Overview

The Cybersecurity Analyst brings security-first thinking, threat modeling, and defense-in-depth principles to protect systems, data, and users. This skill analyzes threats, vulnerabilities, and risks across technical, human, and organizational dimensions to design secure systems and respond to security incidents.

Cybersecurity is not just about technology - it encompasses cryptography, network security, application security, human factors, legal compliance, and risk management. Modern security requires understanding attacker motivations, techniques, and economics while building defense strategies that balance security with usability and business needs.

This skill combines offensive security thinking (how attackers exploit systems) with defensive security practices (how to prevent, detect, and respond to attacks) to provide comprehensive security analysis.

Core Capabilities

1. Threat Modeling

Systematically identifies potential threats, attack vectors, and security risks for systems, applications, and organizations. Threat modeling reveals vulnerabilities before attackers exploit them.

Methodologies:

• STRIDE - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
• PASTA - Process for Attack Simulation and Threat Analysis
• Attack Trees - Hierarchical diagrams of attack paths
• Kill Chain - Stages of cyber attacks (reconnaissance → delivery → exploitation → control)
• MITRE ATT&CK - Knowledge base of adversary tactics and techniques

2. Vulnerability Assessment

Identifies weaknesses in systems that could be exploited by attackers. Combines automated scanning with manual analysis to discover security flaws.

Vulnerability Categories:

• Injection flaws - SQL injection, command injection, XSS
• Broken authentication/authorization - Weak credentials, session management
• Sensitive data exposure - Unencrypted data, weak crypto
• Security misconfiguration - Default credentials, unnecessary services
• Known vulnerabilities - Unpatched CVEs, outdated dependencies
• Design flaws - Architectural security weaknesses

3. Cryptography Analysis

Evaluates cryptographic implementations, key management, and protocols. Ensures proper use of encryption, hashing, digital signatures, and random number generation.

Key Areas:

• Encryption - AES, RSA, elliptic curves (proper algorithms, key lengths, modes)
• Hashing - SHA-256, bcrypt, Argon2 (password storage, integrity)
• Key management - Generation, storage, rotation, destruction
• TLS/SSL - Certificate validation, protocol versions, cipher suites
• PKI - Public key infrastructure and certificate authorities

4. Access Control and Identity Management

Analyzes authentication, authorization, and identity systems to ensure proper access controls.

Principles:

• Least privilege - Minimum necessary permissions
• Separation of duties - No single person has complete control
• Defense in depth - Multiple layers of security
• Zero trust - Never trust, always verify
• MFA/2FA - Multi-factor authentication requirements

5. Security Monitoring and Incident Response

Designs detection mechanisms and response procedures for security incidents.

Components:

• Logging and monitoring - SIEM, IDS/IPS, anomaly detection
• Incident response - Preparation, detection, containment, eradication, recovery, lessons learned
• Forensics - Evidence collection and analysis
• Threat intelligence - Understanding attacker TTPs (Tactics, Techniques, Procedures)

6. Application Security (AppSec)

Applies security principles throughout software development lifecycle.

Practices:

• Secure coding - Input validation, output encoding, parameterized queries
• SAST/DAST - Static and dynamic application security testing
• Dependency scanning - Known vulnerabilities in libraries
• Security testing - Penetration testing, fuzzing, red team exercises
• Secure SDLC - Security requirements, design review, code review

Use Cases

System and Application Design

Apply security principles during design phase to build secure systems from the ground up. Threat model architectures before implementation to identify and mitigate risks early.

Code Review and Security Testing

Review code for security vulnerabilities, test applications for exploitable flaws, and scan dependencies for known CVEs. Conduct penetration testing to validate security controls.

Incident Response and Forensics

Respond to security incidents, contain breaches, analyze attacker behavior, collect forensic evidence, and implement remediation to prevent recurrence.

Compliance and Risk Management

Assess compliance with security standards (SOC 2, ISO 27001, GDPR, HIPAA, PCI-DSS), evaluate risk posture, and prioritize security investments based on threat and impact.

Security Architecture Review

Evaluate security architectures for defense-in-depth, identify single points of failure, assess attack surface, and recommend security improvements.

Key Methods

Method 1: STRIDE Threat Modeling

Apply STRIDE to identify threats:

1. Spoofing - Attacker impersonates user/system 2. Tampering - Unauthorized modification of data 3. Repudiation - Denying actions without proof 4. Information Disclosure - Exposing sensitive information 5. Denial of Service - Making system unavailable 6. Elevation of Privilege - Gaining unauthorized permissions

For each component, ask: What STRIDE threats apply?

Method 2: Attack Surface Analysis

Map all entry points and assess risk:

1. Enumerate interfaces (APIs, UI, network services) 2. Identify input sources (user input, file uploads, API calls) 3. Map trust boundaries (internal vs. external, privileged vs. unprivileged) 4. Assess attack complexity and likelihood 5. Prioritize reduction of attack surface

Method 3: Defense in Depth

Layer security controls:

1. Perimeter - Firewalls, VPN, network segmentation 2. Network - IDS/IPS, network monitoring 3. Host - Endpoint protection, hardening, patching 4. Application - Input validation, secure coding, WAF 5. Data - Encryption at rest and in transit 6. User - Strong authentication, least privilege, training

Method 4: Risk Assessment (CVSS)

Quantify vulnerability severity using Common Vulnerability Scoring System:

• Base score - Intrinsic qualities of vulnerability
• Temporal score - Current exploit availability
• Environmental score - Impact in specific environment
• Prioritize remediation by risk score

Method 5: Security Testing Pyramid

Test security at multiple levels:

1. Unit tests - Security test cases for functions 2. Integration tests - Security of component interactions 3. SAST - Static analysis of source code 4. DAST - Dynamic testing of running application 5. Penetration testing - Manual security testing by experts

Resources

Essential Reading

• "The Web Application Hacker's Handbook" - Comprehensive web security
• "Threat Modeling: Designing for Security" - Adam Shostack
• "The Tangled Web" - Browser security by Michal Zalewski
• "Security Engineering" - Ross Anderson (comprehensive security principles)
• OWASP Top 10 - Most critical web application security risks

Key Frameworks

• OWASP - Open Web Application Security Project resources
• NIST Cybersecurity Framework - Risk management framework
• CIS Controls - Prioritized security best practices
• MITRE ATT&CK - Adversary tactics and techniques
• STRIDE/DREAD - Threat modeling methodologies

Standards and Compliance

• PCI-DSS - Payment card industry security
• GDPR - European data protection regulation
• HIPAA - Healthcare data security (US)
• SOC 2 - Service organization security controls
• ISO 27001 - Information security management

Tools

• Burp Suite - Web application security testing
• Metasploit - Penetration testing framework
• Wireshark - Network protocol analyzer
• Nmap - Network scanning and enumeration
• OWASP ZAP - Web app vulnerability scanner
• Snyk/Dependabot - Dependency vulnerability scanning

Links

• Agent Implementation
• Quick Reference
• All Skills

Best Practices

Do:

• Assume breach (defense in depth)
• Practice least privilege
• Validate all input, encode all output
• Use secure defaults
• Keep security simple (complexity is the enemy)
• Log security events
• Encrypt sensitive data (at rest and in transit)
• Keep dependencies updated
• Threat model during design
• Security test before deployment

Don't:

• Rely on security through obscurity
• Roll your own crypto
• Store passwords in plain text or weak hashes
• Trust client-side validation
• Ignore security in development
• Disable security features for convenience
• Use default credentials
• Forget about human factors (social engineering)
• Assume you'll never be attacked

Integration with Amplihack

Security aligns with amplihack's ruthless simplicity - complex systems have more attack surface and are harder to secure. Simple, well-understood security controls are more effective than elaborate schemes. Security-first thinking ensures long-term sustainability by protecting against threats that could destroy trust and viability.

Key Security Principles

1. Defense in Depth - Multiple layers of security 2. Least Privilege - Minimum necessary permissions 3. Fail Securely - Errors should default to secure state 4. Complete Mediation - Check every access 5. Separation of Privilege - Multiple conditions for access 6. Open Design - Security should not depend on secrecy of design 7. Economy of Mechanism - Keep security simple 8. Psychological Acceptability - Security should be usable

Cybersecurity Analyst - Domain Validation Quiz

Purpose

This quiz validates that the cybersecurity analyst applies security frameworks correctly, identifies vulnerabilities and threats, and provides well-grounded analysis. Each scenario requires demonstration of security reasoning, threat modeling, and evidence-based risk assessment.

---

Scenario 1: Zero-Day Vulnerability Disclosure

Event Description: A security researcher discovers a remote code execution vulnerability in a widely-used web server software (nginx) affecting versions from the past 3 years. The vulnerability allows attackers to execute arbitrary code by sending specially crafted HTTP headers. The researcher has not yet publicly disclosed the vulnerability but has contacted the vendor. The vendor acknowledges the issue and estimates 2 weeks for a patch. The researcher debates immediate public disclosure versus coordinated disclosure.

Analysis Task: Analyze the vulnerability disclosure decision and broader security implications.

Expected Analysis Elements

• [ ] Vulnerability Assessment:
• Remote Code Execution (RCE) - highest severity class
• CVSS scoring framework (likely 9.0+ critical)
• Attack vector: Network-based, no authentication required
• Impact: Complete system compromise

• [ ] Threat Modeling:
• Attack surface: All exposed nginx servers
• Threat actors: Nation-state APTs, ransomware groups, opportunistic attackers
• Time-to-exploit after disclosure (hours to days)
• Weaponization potential for botnets, ransomware

• [ ] Disclosure Trade-offs:
• Immediate disclosure: Public awareness, but attackers can exploit before patches
• Coordinated disclosure: Vendor time to patch, but vulnerability remains secret longer
• Responsible disclosure: 90-day window standard
• Risk of independent discovery or leak

• [ ] Risk Assessment:
• Scope: Millions of servers potentially affected
• Exploitability: High (network-accessible, no auth required)
• Impact: Data breach, ransomware, botnet recruitment
• Cascading effects: Supply chain, dependent services

• [ ] Mitigation Strategies:
• Immediate: WAF rules, network segmentation, IDS signatures
• Short-term: Vendor patch deployment
• Long-term: Vulnerability management programs, version lifecycle
• Compensating controls during patch window

• [ ] Stakeholder Analysis:
• Vendor: Reputation risk, legal liability
• Organizations: Patch management burden, potential breach
• Researcher: Ethical obligations, legal protections (CFAA concerns)
• Public: Right to know vs. protection from exploitation

• [ ] Historical Context:
• Heartbleed (OpenSSL 2014): Mass exploitation, industry response
• EternalBlue (SMB 2017): NSA exploit leaked, WannaCry ransomware
• Log4Shell (2021): Rapid weaponization, widespread impact
• Full disclosure vs. responsible disclosure debates

Evaluation Criteria

• Domain Accuracy (0-10): Correct application of vulnerability assessment, CVSS, threat modeling
• Analytical Depth (0-10): Thoroughness of risk analysis, disclosure trade-offs, mitigation strategies
• Insight Specificity (0-10): Clear recommendations, specific mitigation measures
• Historical Grounding (0-10): References to precedent vulnerabilities, disclosure outcomes
• Reasoning Clarity (0-10): Logical flow from threat assessment to recommendations

Minimum Passing Score: 35/50

---

Scenario 2: Ransomware Incident Response

Event Description: At 3:00 AM, a hospital's IT systems begin displaying ransomware encryption screens. Initial investigation reveals: 60% of workstations encrypted, file servers compromised, backup systems partially affected. The ransom note demands $5 million in cryptocurrency for decryption keys, with 48-hour deadline. Electronic health records are inaccessible, affecting patient care. Law enforcement has been notified. Backups from 48 hours ago are available but potentially infected.

Analysis Task: Analyze the incident and develop response strategy.

Expected Analysis Elements

• [ ] Incident Classification:
• Ransomware attack (encryption malware)
• Critical infrastructure target (healthcare)
• Active incident requiring immediate response
• Potential data exfiltration (double extortion)

• [ ] Immediate Response Actions:
• Containment: Isolate affected systems, segment networks
• Preserve evidence: Forensic imaging, log collection
• Activate incident response team
• Communication protocols (internal, external, regulatory)
• Patient safety prioritization

• [ ] Technical Analysis:
• Malware identification (strain, variant, encryption method)
• Initial access vector (phishing, vulnerability, credential compromise)
• Lateral movement analysis (how did it spread)
• Persistence mechanisms
• Data exfiltration assessment

• [ ] Decision Framework: Pay or Not Pay:
• Against payment: Funds criminals, no guarantee of decryption, legal concerns (OFAC sanctions)
• For payment: Immediate restoration, patient care continuity
• Alternative: Restore from backups (if clean and recent)
• Insurance coverage considerations
• Negotiation dynamics

• [ ] Recovery Strategy:
• Backup restoration plan (verify integrity first)
• System rebuild vs. decrypt decision
• Critical services prioritization (life-safety first)
• Validation and testing before production
• Timeline and resource requirements

• [ ] Regulatory and Legal:
• HIPAA breach notification (HHS, patients, media)
• FBI/CISA reporting requirements
• State attorney general notifications
• Civil liability concerns
• Insurance claims

• [ ] Post-Incident Improvements:
• Root cause analysis
• Security control gaps (MFA, network segmentation, backup isolation)
• User training (phishing awareness)
• Incident response plan refinement

• [ ] Historical Context:
• WannaCry (2017): NHS impact, global disruption
• NotPetya (2017): Masquerading as ransomware, destructive intent
• Colonial Pipeline (2021): Critical infrastructure, payment decision
• Healthcare sector targeting trends

Evaluation Criteria

• Domain Accuracy (0-10): Correct application of incident response framework, containment strategies
• Analytical Depth (0-10): Thoroughness of technical analysis, decision framework, recovery planning
• Insight Specificity (0-10): Clear action priorities, specific containment measures
• Historical Grounding (0-10): References to similar incidents, industry best practices
• Reasoning Clarity (0-10): Logical prioritization and decision-making process

Minimum Passing Score: 35/50

---

Scenario 3: Cloud Infrastructure Misconfiguration

Event Description: A security audit reveals that a company's AWS S3 bucket containing customer data (names, emails, purchase history) has been publicly accessible for 8 months. The bucket stored logs and analytics data from the company's e-commerce platform. Web scraping evidence suggests automated bots have been indexing public S3 buckets and may have discovered this data. No evidence of malicious use yet, but data exposure is confirmed. The company has 50,000 active customers.

Analysis Task: Analyze the data breach scenario and response requirements.

Expected Analysis Elements

• [ ] Incident Classification:
• Data breach (unauthorized exposure of PII)
• Misconfiguration vulnerability (human error)
• Exposure duration: 8 months
• Scope: 50,000 customers

• [ ] Technical Root Cause:
• S3 bucket policy misconfiguration (public read permissions)
• Lack of access controls and monitoring
• Infrastructure-as-Code (IaC) review gap
• Missing automated compliance checks

• [ ] Data Sensitivity Assessment:
• PII exposed: Names, emails, purchase history
• Regulatory classification: Personal data under GDPR, CCPA
• Potential harms: Phishing, identity theft, competitive intelligence
• Data minimization principle violation

• [ ] Breach Notification Requirements:
• GDPR: 72-hour notification to supervisory authority
• CCPA: Consumer notification without unreasonable delay
• State laws: Varies by state (e.g., California, New York)
• Affected individual notification
• Credit monitoring offerings (depending on data types)

• [ ] Risk Assessment:
• Likelihood of exploitation: High (bot indexing confirmed)
• Impact severity: Moderate (no financial data, but PII exposed)
• Reputational damage: Significant (customer trust erosion)
• Regulatory penalties: GDPR fines up to 4% revenue
• Civil litigation risk: Class action potential

• [ ] Remediation Actions:
• Immediate: Restrict bucket access, audit all other buckets
• Short-term: Implement S3 bucket policies, AWS Config rules
• Long-term: Infrastructure security review, IaC validation, least privilege
• Monitoring: CloudTrail logging, automated compliance scanning

• [ ] Defense in Depth Failures:
• Preventive controls: IAM policies, bucket policies
• Detective controls: AWS Config, CloudTrail monitoring
• Corrective controls: Automated remediation
• Administrative controls: Security training, change management

• [ ] Historical Context:
• Capital One breach (2019): S3 misconfiguration, SSRF vulnerability
• Uber data breach (2016): S3 credentials exposed on GitHub
• Verizon/NICE Systems (2017): 14M customer records exposed via S3
• Industry pattern: Misconfigurations are leading cloud breach cause

Evaluation Criteria

• Domain Accuracy (0-10): Correct application of breach notification requirements, cloud security principles
• Analytical Depth (0-10): Thoroughness of root cause, risk assessment, remediation strategy
• Insight Specificity (0-10): Clear notification timeline, specific remediation measures
• Historical Grounding (0-10): References to similar cloud breaches, regulatory outcomes
• Reasoning Clarity (0-10): Logical flow from incident to response to prevention

Minimum Passing Score: 35/50

---

Scenario 4: Supply Chain Attack via Dependency

Event Description: A popular npm package (10 million weekly downloads) used in thousands of applications releases version 2.3.5 containing malicious code. The code exfiltrates environment variables (potentially including API keys, credentials) to an attacker-controlled server. The malicious version was published after the maintainer's account was compromised through credential stuffing. The package remained compromised for 72 hours before detection. Your organization uses this package in 15 production applications.

Analysis Task: Analyze the supply chain attack and organizational response.

Expected Analysis Elements

• [ ] Attack Classification:
• Supply chain attack (software supply chain)
• Dependency confusion/poisoning variant
• Account takeover as initial access
• Widespread impact (thousands of downstream users)

• [ ] Attack Vector Analysis:
• Initial access: Credential stuffing (poor password hygiene, no MFA)
• Malicious payload: Environment variable exfiltration
• Distribution: NPM package manager, automatic updates
• Persistence: Semver auto-update rules (^2.3.0 pulls 2.3.5)

• [ ] Blast Radius Assessment:
• Direct impact: 10M weekly downloads
• Downstream: Thousands of applications
• Your organization: 15 production applications affected
• Data at risk: API keys, database credentials, secrets
• Lateral movement potential: Compromised credentials enable further attacks

• [ ] Immediate Response:
• Identify affected applications (dependency tree analysis)
• Rotate all potentially exposed credentials
• Downgrade to last known good version (2.3.4)
• Network forensics: Check for data exfiltration
• Incident response activation

• [ ] Credential Compromise Assessment:
• Inventory exposed environment variables per application
• Credential scope: Database, APIs, cloud providers, third-party services
• Privilege levels: Admin vs. read-only
• Blast radius from compromised credentials
• Evidence of exploitation (log analysis)

• [ ] Supply Chain Security Gaps:
• Dependency pinning vs. automatic updates
• Software Bill of Materials (SBOM) missing
• Package integrity verification (checksums, signatures)
• Dependency scanning and vulnerability management
• Least privilege for service accounts

• [ ] Prevention and Detection:
• Software Composition Analysis (SCA) tools
• Dependency lock files (package-lock.json)
• Runtime monitoring for anomalous behavior
• Secrets management (vault, no hardcoded credentials)
• Network egress monitoring

• [ ] Historical Context:
• SolarWinds (2020): Build system compromise, nation-state attack
• Codecov (2021): Bash uploader script compromised
• Event-stream npm incident (2018): Bitcoin wallet theft
• UA-Parser-JS npm attack (2021): Cryptocurrency mining
• Growing trend: 650% increase in supply chain attacks (2021)

Evaluation Criteria

• Domain Accuracy (0-10): Correct application of supply chain security, credential management
• Analytical Depth (0-10): Thoroughness of blast radius, credential assessment, prevention
• Insight Specificity (0-10): Clear response actions, specific detection measures
• Historical Grounding (0-10): References to supply chain attacks, industry trends
• Reasoning Clarity (0-10): Logical flow from detection to containment to prevention

Minimum Passing Score: 35/50

---

Scenario 5: Insider Threat Investigation

Event Description: Security alerts flag unusual activity: A software engineer with database access has been running queries to download large customer datasets after business hours. The engineer's access is legitimate for their role, but the volume and timing are unusual. The engineer submitted resignation 2 weeks ago (effective in 2 weeks) and will join a competitor. HR confirms no non-compete agreement exists. Legal is concerned about trade secret theft. No evidence of data exfiltration outside the network yet, but USB activity is detected on the engineer's workstation.

Analysis Task: Analyze the potential insider threat and response strategy.

Expected Analysis Elements

• [ ] Threat Classification:
• Insider threat (malicious or negligent)
• Elevated access (legitimate database permissions)
• Potential trade secret theft
• Pre-departure risk indicator (resignation, competitor)

• [ ] Behavioral Analysis:
• Indicators: Unusual hours, large data access, USB activity
• Baseline deviation: Compare to normal work patterns
• Intent assessment: Malicious (theft) vs. innocent (work completion)
• Motivations: Financial gain, competitive advantage, revenge
• Opportunity: Legitimate access, notice period window

• [ ] Data at Risk:
• Customer data: PII, contact information, purchase behavior
• Trade secrets: Proprietary algorithms, business intelligence
• Intellectual property: Code, architecture, processes
• Competitive intelligence: Pricing, strategy, customer relationships

• [ ] Investigation Approach:
• Non-disruptive monitoring (avoid alerting suspect)
• Log analysis: Database queries, file access, network traffic, USB devices
• Endpoint forensics: File activity, email, cloud storage uploads
• Correlation with business value data
• Legal considerations: Privacy, consent, jurisdiction

• [ ] Immediate Actions:
• Enhanced monitoring (not immediate revocation, to gather evidence)
• Coordinate with HR, Legal, Management
• Document everything (for potential litigation)
• Revoke access strategically (when sufficient evidence or risk threshold)
• Network egress controls (DLP, email monitoring)

• [ ] Legal and HR Coordination:
• Trade secret protections (state laws, federal DTSA)
• Civil litigation options (injunction, damages)
• Criminal referral (if warranted - 18 USC 1831)
• HR exit interview strategy
• Non-disparagement and IP agreements at departure

• [ ] Preventive Controls:
• User and Entity Behavior Analytics (UEBA)
• Data Loss Prevention (DLP) systems
• Least privilege access (why such broad database access?)
• Pre-departure access reviews
• Exit interview security components

• [ ] Historical Context:
• Waymo vs. Uber (2017): Stolen self-driving car trade secrets
• Tesla trade secret theft cases: Employees to Chinese competitors
• Insider threats: 34% of data breaches (Verizon DBIR)
• Average cost: $15.4M per insider threat incident (Ponemon)

Evaluation Criteria

• Domain Accuracy (0-10): Correct application of insider threat frameworks, investigation techniques
• Analytical Depth (0-10): Thoroughness of behavioral analysis, legal considerations, evidence gathering
• Insight Specificity (0-10): Clear investigation steps, specific monitoring measures
• Historical Grounding (0-10): References to insider threat cases, industry statistics
• Reasoning Clarity (0-10): Logical balance between monitoring and action, legal coordination

Minimum Passing Score: 35/50

---

Overall Quiz Assessment

Scoring Summary

Passing Criteria

To demonstrate cybersecurity analyst competence:

• Minimum per scenario: 35/50 (70%)
• Overall minimum: 175/250 (70%)
• Must pass at least 4 of 5 scenarios

Evaluation Dimensions

Each scenario is scored on:

1. Domain Accuracy (0-10): Correct application of security frameworks and methodologies 2. Analytical Depth (0-10): Thoroughness and sophistication of threat analysis 3. Insight Specificity (0-10): Clear, actionable security recommendations 4. Historical Grounding (0-10): Use of precedents, attack patterns, industry data 5. Reasoning Clarity (0-10): Logical flow, coherent risk assessment

What High-Quality Analysis Looks Like

Excellent (45-50 points):

• Applies multiple security frameworks accurately (NIST, MITRE ATT&CK, Kill Chain)
• Considers technical, operational, legal, and business dimensions
• Makes specific, prioritized recommendations with timelines
• Cites relevant precedents, CVEs, and industry statistics
• Clear logical flow from threat assessment to risk evaluation to response
• Acknowledges uncertainties and residual risks
• Identifies non-obvious attack vectors or defenses

Good (35-44 points):

• Applies key security frameworks correctly
• Considers main technical and business impacts
• Makes reasonable response recommendations
• References some precedents or industry practices
• Clear reasoning
• Provides useful security insights

Needs Improvement (<35 points):

• Misapplies security concepts or frameworks
• Ignores critical risks or response actions
• Vague or technically incorrect recommendations
• Lacks grounding in real-world attacks or defenses
• Unclear or illogical reasoning
• Superficial threat analysis

---

Using This Quiz

For Self-Assessment

1. Attempt each scenario analysis 2. Compare your analysis to expected elements 3. Score yourself honestly on each dimension 4. Identify areas for improvement

For Automated Testing (Claude Agent SDK)

from claude_agent_sdk import Agent, TestHarness

agent = Agent.load("cybersecurity-analyst")
quiz = load_quiz_scenarios("tests/quiz.md")

results = []
for scenario in quiz.scenarios:
    analysis = agent.analyze(scenario.event)
    score = evaluate_analysis(analysis, scenario.expected_elements)
    results.append({"scenario": scenario.name, "score": score})

assert sum(r["score"] for r in results) >= 175  # Overall passing
assert sum(1 for r in results if r["score"] >= 35) >= 4  # At least 4 scenarios pass

For Continuous Improvement

• Add new scenarios as security incidents evolve
• Update expected elements as threat landscape changes
• Refine scoring criteria based on analyst performance patterns
• Use failures to improve cybersecurity analyst skill

---

Quiz Version: 1.0.0 Last Updated: 2025-11-16 Status: Production Ready