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:

• Physical: Facility access controls, locked server rooms

• Network: Firewalls, network segmentation, IDS/IPS

• Host: Endpoint protection, host firewalls, patch management

• Application: Input validation, secure coding, authentication

• Data: Encryption at rest and in transit, DLP, tokenization

• 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):

• Verify explicitly: Always authenticate and authorize based on all available data points

• Least privilege access: Limit user access with Just-In-Time and Just-Enough-Access

• 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):

• Reconnaissance

• Resource Development

• Initial Access

• Execution

• Persistence

• Privilege Escalation

• Defense Evasion

• Credential Access

• Discovery

• Lateral Movement

• Collection

• Command and Control

• Exfiltration

• 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:

• Enumerate: List all entry points and assets

• Classify: Categorize by type and criticality

• Assess: Evaluate exploitability and impact

• Prioritize: Rank by risk

• 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:

• Training: Security training for developers

• Requirements: Define security requirements and privacy requirements

• Design: Threat modeling, attack surface reduction, defense in depth

• Implementation: Secure coding standards, code analysis tools

• Verification: Security testing (SAST, DAST, penetration testing)

• Release: Final security review, incident response plan

• 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:

• Collection: Gather data from internal sources, threat feeds, OSINT, dark web

• Processing: Normalize, correlate, deduplicate

• Analysis: Contextualize, attribute, assess intent and capability

• Dissemination: Share with relevant teams in actionable format

• 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):

• Pre-engagement: Scope, rules of engagement, legal agreements

• Intelligence gathering: OSINT, network scanning, service enumeration

• Threat modeling: Identify potential attack vectors

• Vulnerability analysis: Identify exploitable weaknesses

• Exploitation: Attempt to exploit vulnerabilities

• Post-exploitation: Assess impact, lateral movement, privilege escalation

• 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:

• Understand attacker technique (MITRE ATT&CK)

• Identify data sources that capture technique

• Develop detection logic

• Test against true positives and false positives

• Tune threshold and logic

• Document detection and response procedures

• 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):

• Isolate affected systems (contain spread)

• Identify ransomware variant and check for decryption tools

• Engage incident response firm if no internal capability

• Do NOT pay ransom immediately (assess alternatives first)

• Notify legal, insurance, possibly law enforcement

Short-term (Days to Weeks):

• Restore from backups if available and uncompromised

• Deploy EDR on all endpoints

• Implement MFA for all remote access

• Conduct forensic investigation to determine root cause and scope

• Develop and test IR playbook

Medium-term (Weeks to Months):

• Network segmentation (prevent lateral movement)

• Email security gateway (block phishing)

• Privileged access management (limit credential theft)

• Security awareness training (reduce phishing success)

• Backup hardening (air-gapped or immutable backups)

Long-term (Months to Year):

• Security maturity assessment and roadmap

• 24/7 SOC or MDR service

• Penetration testing and red team exercises

• 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):

• Broken Access Control: Check for IDOR vulnerabilities, horizontal/vertical privilege escalation

• Cryptographic Failures: Verify encryption at rest and in transit, key management

• Injection: Test for SQL injection, XSS, command injection

• Insecure Design: Review for security design flaws, threat model gaps

• Security Misconfiguration: Check for default credentials, unnecessary features, verbose errors

• Vulnerable Components: Scan dependencies for known CVEs

• Authentication Failures: Test password policy, session management, MFA

• Software/Data Integrity: Verify supply chain security, unsigned updates

• Logging Failures: Ensure security events logged, log tampering prevention

• 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):

• Fix IDOR vulnerabilities (implement authorization checks)

• Update vulnerable dependencies

• Remove verbose error messages in production

• Implement rate limiting on all endpoints

Should-Fix Before Launch (High):

• Deploy WAF with OWASP Core Rule Set

• Separate admin portal (different domain, VPN/IP restriction)

• Configure SIEM integration and alerting

Post-Launch (Medium):

• Implement MFA for customer accounts

• Enhance logging (capture more security events)

• Conduct penetration testing

• 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):

• Cloud security training for teams

• Design AWS Organizations structure and account strategy

• Define IAM strategy and policies

• Design VPC architecture and network segmentation

• Select and implement CSPM tool

• Establish cloud security baseline (CIS AWS Foundations Benchmark)

During Migration (Month 3-12):

• Use Infrastructure as Code (Terraform/CloudFormation) for all resources

• Automate security checks in CI/CD (SAST, DAST, IaC scanning)

• Enforce encryption at rest and in transit

• Implement least privilege IAM

• Enable all cloud-native security services (GuardDuty, Security Hub, Config, CloudTrail)

• Security testing before production deployment

Post-Migration (Ongoing):

• Continuous compliance monitoring

• Regular IAM access reviews

• Cloud security posture assessments

• Penetration testing in cloud environment

• 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)