Cybersecurity Labs - Module 6

Hands-on Security+, CISSP, and CISM scenarios covering Risk Assessment, Identity Federation, and Incident Response Planning.

These Labs Cover All Cybersecurity Certifications

CompTIA Security+ CompTIA CySA+ CompTIA PenTest+ CompTIA SecurityX ISC2 CISSP ISC2 SSCP ISC2 CCSP ISC2 CGRC
ISC2 CSSLP ISC2 ISSAP ISC2 ISSEP ISC2 ISSMP ISACA CISA ISACA CISM ISACA CRISC ISACA CDPSE

Advanced Security+ / CISSP / CISM Labs

Master risk assessment, identity federation, and incident response planning with realistic scenarios.

Lab 16: Risk Assessment & Mitigation
Security+
GUI
Scenario: Enterprise Risk Assessment & Treatment
You're the GRC analyst at FinTech Corp. Conduct qualitative and quantitative risk analysis for three assets, calculate SLE/ALE, and implement appropriate risk responses per NIST guidance.

Learning Objectives:

  • Perform qualitative and quantitative risk analysis
  • Calculate SLE, ARO, and ALE for business assets
  • Apply appropriate risk treatment strategies
Security+ 5.2 / CISSP 1.9

Step-by-Step Instructions

  1. Step 1: Assess Web Server Risk (Qualitative Analysis)

    🎯 Goal: Evaluate an unpatched Apache web server vulnerability using qualitative risk analysis methodology, which uses subjective ratings (High/Medium/Low) rather than dollar figures.

    📝 Why This Matters: Qualitative analysis is essential when you don't have precise financial data about asset values or loss history. It provides rapid risk prioritization during initial assessments. Organizations use this approach for quick triage before investing in detailed quantitative analysis. This is a core competency tested in Security+ Domain 5.2 (Risk Management) and CISSP Domain 1 (Security and Risk Management).

    📊 Understanding the Risk Matrix: Risk Score = Likelihood × Impact. A 3×3 matrix yields scores from 1 (Low×Low) to 9 (High×High). Critical risks (7-9) require immediate action. Medium risks (4-6) need scheduled remediation. Low risks (1-3) can be monitored.

    Action: In the Risk Register panel on the right, locate Asset #1 (Web Server - Public-facing Apache) and click the Assess button. In the modal that opens, select:
    • Threat: Unpatched Vulnerability (CVEs in outdated Apache versions are actively exploited)
    • Likelihood: High (public-facing servers are scanned constantly by attackers)
    • Impact: High (web server compromise leads to data breach, defacement, or pivot point for lateral movement)
    Click Calculate Risk Score.

    💡 Exam Relevance: Security+ SY0-701 specifically tests your ability to use likelihood × impact matrices for risk prioritization. CISSP tests when to use qualitative vs quantitative methods—use qualitative when quick decisions are needed or quantitative data is unavailable. The resulting Critical (9/9) score demonstrates why unpatched public-facing systems are top remediation priorities.

    Expected Result: Risk Score displays as "Critical (9/9)" with red highlighting. Status changes to "Assessed" and the Assess button becomes "Treat Risk".
  2. Step 2: Calculate Database SLE/ALE (Quantitative Analysis)

    🎯 Goal: Calculate Single Loss Expectancy (SLE) and Annualized Loss Expectancy (ALE) for a potential customer database breach. This quantitative analysis assigns specific dollar values to risk, enabling precise cost-benefit analysis for security investments.

    📝 Why This Matters: Quantitative risk analysis is required when presenting to executives and boards who need financial justification for security budgets. ALE calculations help answer: "How much should we spend on controls?" The answer: never more than the ALE, or you're overspending on security. This methodology is central to CISSP Domain 1 and Security+ 5.2.

    📊 Understanding the Formulas:
    Asset Value (AV) = Total value of asset ($5,000,000 for PII + payment data including regulatory fines, remediation, reputation damage)
    Exposure Factor (EF) = Percentage of asset lost in single incident (0.4 = 40% because not all data is compromised in typical breach)
    Single Loss Expectancy (SLE) = AV × EF = $5,000,000 × 0.4 = $2,000,000 per incident
    Annualized Rate of Occurrence (ARO) = How often the event occurs per year (0.5 = once every 2 years based on industry breach statistics)
    Annualized Loss Expectancy (ALE) = SLE × ARO = $2,000,000 × 0.5 = $1,000,000/year

    Action: Click Assess on Asset #2 (Customer Database - PII + payment data). Enter:
    • Asset Value: 5000000 (total cost including breach notification, credit monitoring, legal fees, regulatory fines, reputation damage)
    • Exposure Factor: 0.4 (40% impact—partial breach scenario, not total data loss)
    • ARO: 0.5 (once every 2 years based on Verizon DBIR statistics for financial sector)
    Click Calculate ALE.

    💡 Exam Tip: You MUST memorize these formulas for Security+ and CISSP exams:
    • SLE = AV × EF ($5M × 0.4 = $2M)
    • ALE = SLE × ARO ($2M × 0.5 = $1M/year)
    The ALE ($1,000,000) tells us we can justify spending up to $1M annually on controls to protect this database. Any control costing less than ALE that eliminates the risk is cost-effective.

    Expected Result: ALE displays as "$1,000,000". Risk Score shows "Medium". Status changes to "Assessed".
  3. Step 3: Assess Ransomware Risk for Backup System

    🎯 Goal: Perform a combined qualitative and quantitative analysis for ransomware targeting the backup infrastructure. This hybrid approach is common in enterprise environments where some assets have financial data and others require rapid categorical assessment.

    📝 Why This Matters: Backup systems are prime ransomware targets because attackers know that destroying backups forces ransom payment. The FBI reports that organizations with compromised backups pay ransoms 2.5x more often. An ARO above 1.0 indicates the threat occurs more than once per year, signaling urgent need for mitigation. This scenario tests your ability to recognize high-frequency, high-impact risks that demand immediate investment.

    📊 Understanding the Numbers:
    • Asset Value: $800,000 (cost to rebuild backup infrastructure + downtime during recovery + potential data loss)
    • Exposure Factor: 0.8 (80% impact—ransomware typically encrypts most accessible data)
    • ARO: 1.2 (more than once per year—reflects current ransomware epidemic targeting financial sector)
    • SLE = $800,000 × 0.8 = $640,000 per incident
    • ALE = $640,000 × 1.2 = $768,000/year

    Action: Click Assess on Asset #3 (Backup System - Disaster recovery). Enter:
    • Threat: Ransomware (fastest growing threat vector per CISA advisories)
    • Asset Value: 800000 (infrastructure + downtime costs)
    • Exposure Factor: 0.8 (80% encryption typical in ransomware attacks)
    • ARO: 1.2 (based on FinCEN reports showing financial sector targeted 1.2x/year average)
    Click to calculate both risk score and ALE.

    ⚠️ Critical Analysis: An ARO of 1.2 means ransomware incidents are expected MORE than once per year. This is a crisis-level finding requiring immediate executive attention and budget allocation. The $768,000 ALE means we can justify spending up to $768K annually on ransomware defenses (air-gapped backups, EDR, MFA, segmentation) and still have positive ROI.

    Expected Result: Risk Score shows "High" with orange highlighting. ALE displays as "$768,000". Status changes to "Assessed".
  4. Step 4: Apply Risk Treatment - Mitigate Web Server

    🎯 Goal: Select and implement the appropriate risk response strategy for the web server. The four treatment options are: Mitigate (reduce likelihood/impact), Transfer (insurance/outsourcing), Accept (document and monitor), and Avoid (eliminate the activity). For a Critical-rated public-facing server, mitigation is the correct choice.

    📝 Why This Matters: Risk treatment selection is a key Security+ 5.2 objective and fundamental to CISSP Domain 1. The decision framework is:
    Mitigate: When controls can cost-effectively reduce risk (most common choice)
    Transfer: When risk is high-impact but low-frequency, making insurance economical
    Accept: When treatment cost exceeds potential loss, or risk is already low
    Avoid: When no treatment makes the activity safe enough (shut down the system)

    📊 Cost-Benefit Analysis: The web server has Critical risk. Mitigation cost of $50,000 for patches + WAF is far less than potential breach costs (reputation damage, incident response, regulatory fines). Even without precise ALE, the qualitative Critical rating justifies this investment. ROI is clearly positive.

    Action: In the Asset #1 row, click Treat Risk. In the treatment modal:
    • Strategy: Mitigate (reduce likelihood and impact through technical controls)
    • Control: Apply security patches + WAF (patches fix vulnerabilities, WAF blocks exploit attempts)
    • Implementation Cost: 50000 (includes patching automation, WAF licensing, implementation labor)
    • Residual Risk: Low (post-treatment risk level after controls are in place)
    Click Apply Treatment.

    💡 Security Controls Explained:
    Security Patches: Vendor-supplied fixes for known vulnerabilities (CVEs). Eliminates attack vectors that scanners detect.
    Web Application Firewall (WAF): Inspects HTTP/HTTPS traffic and blocks SQL injection, XSS, and other OWASP Top 10 attacks. Provides defense-in-depth even if patches are delayed.
    The $50K investment transforms Critical risk to Low residual risk—this is exactly the outcome executives expect from security spending.

    Expected Result: Button changes to "✓ Risk Treated" (disabled). Success notification confirms mitigation applied.
  5. Step 5: Transfer Database Risk via Cyber Insurance

    🎯 Goal: Implement risk transference using cyber insurance for the customer database. Transfer is optimal when risk is high-impact but mitigation cannot eliminate it entirely, and when insurance premium is less than ALE.

    📝 Why This Matters: No amount of technical controls can reduce data breach probability to zero. Even with encryption, DLP, and access controls, insider threats and sophisticated APTs can still succeed. Cyber insurance provides financial protection against residual risk after technical controls are exhausted. This is a critical concept for CISSP—understanding when to layer transfer on top of mitigation.

    📊 Insurance Economics:
    • ALE = $1,000,000/year (expected annual loss without treatment)
    • Insurance Premium = $150,000/year (cost of transferring risk)
    • Coverage = $5,000,000 (maximum payout per incident)
    • Net Benefit = ALE - Premium = $1,000,000 - $150,000 = $850,000 savings/year
    The premium is only 15% of expected annual loss, making insurance highly cost-effective. Coverage exceeds single-incident exposure.

    Action: Click Treat Risk for Asset #2 (Customer Database). Enter:
    • Strategy: Transfer (shift financial risk to insurance carrier)
    • Control: Cyber insurance policy (coverage for breach notification, legal, regulatory fines, credit monitoring)
    • Annual Cost: 150000 (premium for $5M coverage)
    • Coverage Amount: 5000000 (policy limit per incident)
    Click Apply Treatment.

    💡 Cyber Insurance Considerations:
    Coverage Types: First-party (your losses) + Third-party (lawsuits from affected customers)
    Exclusions: Most policies exclude unpatched systems, known vulnerabilities, nation-state attacks, and acts of war
    Requirements: Insurers require MFA, EDR, backups, and security awareness training for coverage
    Transfer doesn't eliminate risk—it shifts financial burden. You still need technical controls to maintain insurability and reduce premiums.

    Expected Result: Button changes to "✓ Risk Treated". Residual risk shows "Low (Transferred)" indicating financial exposure is covered.
  6. Step 6: Mitigate Backup System Ransomware Risk

    🎯 Goal: Implement layered technical controls to reduce both the likelihood and impact of ransomware attacks on backup infrastructure. Given the high ARO (1.2 incidents/year), aggressive mitigation is required.

    📝 Why This Matters: Backup systems are the last line of defense against ransomware. If attackers compromise backups, organizations face a binary choice: pay ransom or lose data permanently. CISA and FBI recommend air-gapped backups as the #1 ransomware defense. This step demonstrates how layered controls (defense-in-depth) dramatically reduce both ARO and exposure factor.

    📊 Control Effectiveness Analysis:
    Air-gapped Backups: Physically isolated from network. Reduces EF from 0.8 to ~0.1 (attackers can't encrypt what they can't reach)
    EDR (Endpoint Detection & Response): Detects ransomware behavior patterns and stops execution. Reduces ARO from 1.2 to ~0.3
    MFA (Multi-Factor Authentication): Prevents credential-based access to backup systems. Blocks 99.9% of account compromise attempts
    Post-Treatment ALE: New EF (~0.1) × New ARO (~0.1) = $800K × 0.1 × 0.1 = $8,000/year (vs $768,000 before)
    ROI: $768,000 - $8,000 - $120,000 = $640,000 annual savings

    Action: Click Treat Risk for Asset #3 (Backup System). Enter:
    • Strategy: Mitigate (implement technical controls)
    • Control: Air-gapped backups + EDR + MFA (defense-in-depth approach)
    • Implementation Cost: 120000 (includes offline storage infrastructure, EDR licenses, MFA deployment)
    • Residual Risk: Low (post-treatment with layered controls)
    Click Apply Treatment.

    Defense-in-Depth Explained:
    Air-Gap: Tape or offline disk stored in secure vault. Requires physical access to compromise. Backup window of 24hrs acceptable for most DR scenarios.
    EDR: CrowdStrike, SentinelOne, or Microsoft Defender for Endpoint. Uses AI/ML to detect ransomware behavior even without signatures.
    MFA: Hardware tokens or authenticator apps for all backup admin accounts. Stops 99.9% of credential attacks (Microsoft data).
    The $120K investment reduces ALE from $768K to under $64K—a 92% risk reduction with positive ROI in the first year.

    Expected Result: Button changes to "✓ Risk Treated". All three assets now show treatment applied. Ready for report generation.
  7. Step 7: Generate Executive Risk Report

    🎯 Goal: Create a comprehensive risk assessment report suitable for executive leadership, board of directors, and audit committees. The report must demonstrate due diligence in risk management and justify security investments with clear ROI analysis.

    📝 Why This Matters: Risk reporting is how security professionals communicate value to business leadership. Executives don't understand CVEs and CVSS scores—they understand dollars, percentages, and risk trends. A well-structured report demonstrates that security spending is an investment with measurable returns, not just a cost center. Security+ 5.2 and CISSP both test your ability to communicate risk to stakeholders.

    📊 Report Contents Required:
    • Executive Summary with key metrics (total ALE, treatment investment, risk reduction percentage)
    • Risk Register showing all assessed assets with scores and treatment status
    • Quantitative analysis with ALE charts and cost-benefit tables
    • Treatment strategy details explaining control choices and justifications
    • Recommendations for ongoing risk management (quarterly reviews, tabletop exercises)
    • Signature blocks for GRC analyst and CISO approval

    Action: Click the Generate Report button in the Actions panel. The system will compile all assessment data, treatment decisions, and calculations into a professional PDF-ready report. Review the report for completeness before presenting to stakeholders.

    💡 Report Best Practices:
    • Lead with executive summary—busy executives read only the first page
    • Use visuals (charts, graphs) to convey trends faster than tables
    • Express all metrics in business terms (dollars, percentages) not technical jargon
    • Include specific recommendations with timelines and owners
    • Obtain CISO signature to demonstrate management endorsement

    Expected Result: A new browser tab opens with a multi-page professional risk report including CertLabz.com branding, charts showing ALE distribution, risk matrix visualization, treatment cost-benefit analysis, and signature blocks. Use browser Print function to save as PDF.
  8. Step 8: Certification Knowledge Check (MCQ Set)

    📚 Complete the following multiple-choice questions based on Security+ and CISSP risk management concepts covered in this lab. These questions reinforce certification-level knowledge and are required for full lab completion.

    Question 1: In the context of quantitative risk analysis, if an asset valued at $2,000,000 has an Exposure Factor (EF) of 0.3 and an Annualized Rate of Occurrence (ARO) of 1.5, what is the Annualized Loss Expectancy (ALE)?
    Question 2: Which risk treatment strategy is MOST appropriate when the cost of implementing controls exceeds the potential loss from the risk, and the organization has determined the risk is within acceptable tolerance levels?
    Question 3: According to NIST SP 800-30, what is the primary purpose of conducting a qualitative risk assessment rather than quantitative?
GRC Risk Management Console

Risk Register

AssetRisk ScoreALEStatusActions
Web Server
Public-facing Apache
- - Not Assessed
Customer Database
PII + payment data
- - Not Assessed
Backup System
Disaster recovery
- - Not Assessed

Actions

Progress: 0/8
Score: 0/100
Lab 17: Identity Federation & SSO
CISSP
Terminal
Scenario: Configure Enterprise Identity Federation
As IAM architect, configure SAML-based SSO with an external IdP, integrate LDAP for user provisioning, and enable MFA. Commands must match EXACTLY and IN ORDER.

Learning Objectives:

  • Configure SAML SSO federation with IdP
  • Integrate LDAP directory services
  • Implement MFA and test authentication
CISSP Domain 5 / Security+ 4.6

Step-by-Step Instructions

  1. Step 1: Install SAML & XML Security Tools

    Install required packages for SAML 2.0 federation: python3-saml library, xmlsec1 for XML signatures, and xmlstarlet for XML parsing.

    Type exactly:

    sudo apt-get update && sudo apt-get install -y python3-saml xmlsec1 xmlstarlet curl jq
    💡 Command Breakdown:
    sudo apt-get update — Refresh package lists from repositories
    && — Run next command only if previous succeeds
    apt-get install -y — Install packages, -y auto-confirms prompts
    python3-saml — Python library for SAML 2.0 SP/IdP operations
    xmlsec1 — XML Security library for signing/verifying XML signatures
    xmlstarlet — Command-line XML toolkit for parsing/transforming XML
    curl — HTTP client for API calls and downloads
    jq — JSON processor for parsing and filtering JSON data
  2. Step 2: Download & Parse IdP Metadata

    Download IdP metadata XML and extract SSO endpoint and signing certificate using xmlstarlet.

    Type exactly:

    curl -s https://idp.techcorp.com/metadata.xml -o /etc/saml/idp-metadata.xml && xmlstarlet sel -N md="urn:oasis:names:tc:SAML:2.0:metadata" -t -v "//md:SingleSignOnService/@Location" /etc/saml/idp-metadata.xml
    💡 Command Breakdown:
    curl -s — Silent mode (no progress meter)
    -o /etc/saml/idp-metadata.xml — Output to specified file path
    xmlstarlet sel — Select/query XML using XPath
    -N md="..." — Define XML namespace prefix md for SAML metadata schema
    -t -v — Template mode, output value of XPath expression
    //md:SingleSignOnService/@Location — XPath: find SSO endpoint URL attribute anywhere in document
  3. Step 3: Generate SP Certificate & Key

    Create X.509 certificate for signing SAML AuthnRequests. RSA 2048-bit minimum per NIST SP 800-131A.

    Type exactly:

    openssl req -new -x509 -days 365 -nodes -sha256 -newkey rsa:2048 -keyout /etc/saml/sp.key -out /etc/saml/sp.crt -subj "/CN=app.fintech.com/O=FinTech Corp/C=US"
    💡 Command Breakdown:
    openssl req — Certificate request and generation utility
    -new -x509 — Create new self-signed certificate (not just CSR)
    -days 365 — Certificate validity period (1 year)
    -nodes — No DES encryption on private key ("no-des", not "nodes")
    -sha256 — Use SHA-256 hash algorithm for signature (not weak SHA-1)
    -newkey rsa:2048 — Generate new 2048-bit RSA key pair
    -keyout — Path to write private key (PEM format)
    -out — Path to write certificate (PEM format)
    -subj "/CN=.../O=.../C=..." — Subject DN: Common Name, Organization, Country
  4. Step 4: Query LDAP Directory

    Test LDAPS connectivity and query user attributes using ldapsearch. LDAPS encrypts on port 636.

    Type exactly:

    LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://dc.techcorp.com:636 -D "cn=admin,dc=techcorp,dc=com" -w P@ssw0rd -b "ou=Users,dc=techcorp,dc=com" "(objectClass=inetOrgPerson)" mail givenName sn memberOf
    💡 Command Breakdown:
    LDAPTLS_REQCERT=never — Environment variable: skip TLS certificate validation (lab only!)
    ldapsearch — LDAP query tool from openldap-clients
    -x — Use simple authentication (not SASL)
    -H ldaps://...:636 — LDAP over TLS (encrypted) on port 636
    -D "cn=admin,..." — Bind DN (distinguished name for authentication)
    -w P@ssw0rd — Bind password (use -W for interactive prompt in production)
    -b "ou=Users,..." — Search base DN (starting point in directory tree)
    (objectClass=inetOrgPerson) — LDAP filter: find person entries
    mail givenName sn memberOf — Attributes to return
  5. Step 5: Create SAML Attribute Mapping Config

    Create Python SAML settings file mapping SAML attributes to local user properties for JIT provisioning.

    Type exactly:

    cat > /etc/saml/settings.json << 'EOF' {"sp":{"entityId":"https://app.fintech.com","assertionConsumerService":{"url":"https://app.fintech.com/saml/acs"}},"idp":{"entityId":"https://idp.techcorp.com","singleSignOnService":{"url":"https://idp.techcorp.com/saml2/sso"}},"attributeMapping":{"email":"mail","firstName":"givenName","lastName":"sn","groups":"memberOf"}} EOF
    💡 Command Breakdown:
    cat > file << 'EOF' — Here-document: write multi-line content to file until EOF marker
    'EOF' (quoted) — Prevents variable expansion inside heredoc
    sp.entityId — Service Provider's unique identifier URL
    assertionConsumerService.url — Endpoint where IdP posts SAML Response
    idp.entityId — Identity Provider's unique identifier
    singleSignOnService.url — IdP's login endpoint
    attributeMapping — Maps SAML assertion attributes to local user fields
  6. Step 6: Configure MFA Authentication Context

    Update SAML config to require MFA by specifying AuthnContextClassRef in authentication requests.

    Type exactly:

    cat >> /etc/saml/settings.json << 'EOF' ,"security":{"requestedAuthnContext":["urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport","urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract"],"requestedAuthnContextComparison":"minimum"} EOF
    💡 Command Breakdown:
    cat >> file — Append to existing file (vs > which overwrites)
    requestedAuthnContext — Array of acceptable authentication methods
    PasswordProtectedTransport — Username/password over TLS (baseline)
    MobileTwoFactorContract — MFA required (TOTP, push, SMS)
    requestedAuthnContextComparison: "minimum" — IdP must provide at least this auth strength
    • Other values: exact (must match), better (stronger than listed), maximum
  7. Step 7: Test SAML SSO with curl

    Initiate SP-initiated SSO flow using curl, capture SAML Response, and verify signature with xmlsec1.

    Type exactly:

    curl -s -c /tmp/cookies.txt -b /tmp/cookies.txt -L "https://app.fintech.com/saml/login?RelayState=/dashboard" 2>&1 | xmlstarlet sel -N saml="urn:oasis:names:tc:SAML:2.0:assertion" -t -v "//saml:NameID" -n -v "//saml:Attribute[@Name='email']/saml:AttributeValue" 2>/dev/null || echo "SSO redirect initiated - check browser"
    💡 Command Breakdown:
    curl -s — Silent mode, suppress progress
    -c /tmp/cookies.txt — Save cookies to file (for session tracking)
    -b /tmp/cookies.txt — Send cookies from file with request
    -L — Follow HTTP redirects (SAML involves multiple redirects)
    ?RelayState=/dashboard — Where to redirect after successful auth
    2>&1 — Redirect stderr to stdout (capture all output)
    | xmlstarlet sel — Pipe response to XML parser
    -N saml="...assertion" — Define SAML assertion namespace
    //saml:NameID — Extract authenticated user's identifier
    || echo "..." — If xmlstarlet fails, show fallback message
  8. Step 8: Decode & Verify JWT Session Token

    Decode the JWT session token using base64 and jq to verify federated identity claims and expiration.

    Type exactly:

    cat /var/log/saml/session-token.jwt | cut -d'.' -f2 | base64 -d 2>/dev/null | jq '{sub,iss,aud,exp,email,groups,auth_method}'
    💡 Command Breakdown:
    cat file | cut -d'.' -f2 — Extract 2nd field (payload) from JWT (format: header.payload.signature)
    -d'.' — Use period as field delimiter
    -f2 — Get second field (the payload)
    base64 -d — Decode base64url-encoded payload to JSON
    2>/dev/null — Suppress base64 warnings about padding
    jq '{sub,iss,aud,exp,email,groups,auth_method}' — Extract and display specific claims:
      • sub = Subject (user ID)
      • iss = Issuer (who created token)
      • aud = Audience (intended recipient)
      • exp = Expiration timestamp
CISSP IAM Lab Terminal Type commands EXACTLY as shown. Order and spacing matter.
root@iam-server:~#
Progress: 0/8
Score: 0/100
Lab 18: Incident Response Plan Development
CISM
GUI
Scenario: Build Enterprise Incident Response Plan
You're the Information Security Manager. Develop a comprehensive IR plan with CSIRT team structure, escalation procedures, communication protocols, and integration with business continuity per CISM Domain 4 requirements.

Learning Objectives:

  • Define CSIRT roles and responsibilities (RACI matrix)
  • Establish incident classification and escalation
  • Create communication and stakeholder management plan
CISM Domain 4 / CISSP 7.6

Step-by-Step Instructions

  1. Step 1: Define CSIRT Team Structure and RACI

    🎯 Goal: Establish a Computer Security Incident Response Team (CSIRT) with clearly defined roles and RACI accountability according to NIST SP 800-61 Rev. 2 guidelines. The CSIRT is the core team responsible for detecting, analyzing, containing, eradicating, and recovering from security incidents.

    📝 Why This Matters: CISM Domain 4 (Incident Management) specifically tests your understanding of incident management governance and team structures. Without clear roles, incident response becomes chaotic—team members don't know who makes decisions, who communicates externally, or who preserves evidence. Organizations with well-defined CSIRT structures resolve incidents 60% faster. The RACI matrix (Responsible, Accountable, Consulted, Informed) ensures clear ownership: the Incident Manager is Accountable (A) for all IR phases, while other team members are Responsible (R) for specific tasks.

    📊 Understanding the Roles & RACI:
    Incident Manager (Accountable): Single point of accountability who coordinates all response activities, makes escalation decisions, approves phase transitions, and ensures the IR plan is followed. Has authority to declare incidents and activate the full CSIRT.
    Security Analyst (Responsible): Performs initial triage, analyzes alerts and IOCs, determines incident scope, and recommends containment strategies.
    Forensics Specialist (Responsible): Handles evidence collection with chain-of-custody, creates forensic images, analyzes malware, and documents findings.
    Communications Lead (Responsible): Manages all internal and external communications including employee notifications, customer alerts, regulatory filings, and media statements.
    Legal Counsel (Consulted): Advises on regulatory obligations (GDPR, HIPAA, PCI-DSS), reviews external communications, coordinates with law enforcement, and manages breach notification compliance.

    Action: Click the Define Team Structure button in the CSIRT Team card on the right panel. In the modal that opens, add each of the five required roles by typing the role name and clicking "Add Role":
    Incident Manager
    Security Analyst
    Forensics Specialist
    Communications Lead
    Legal Counsel
    After adding all five roles, click Save Team Structure. The system will automatically assign RACI accountability with the Incident Manager as Accountable (A) for all six IR phases (Preparation, Detection & Analysis, Containment, Eradication, Recovery, Lessons Learned).

    💡 RACI Principle: There must be exactly ONE "Accountable" person per activity. The Incident Manager's "A" designation means ultimate decision authority and approval of phase transitions. Other team members are "Responsible" (R) for execution—Security Analyst for detection, Forensics for evidence, Communications for messaging. "Consulted" stakeholders (Legal, executives) provide input before decisions. "Informed" parties (HR, PR) receive updates after decisions.

    Expected Result: After saving, the CSIRT Team card will show "Team defined" with a green success badge. The button will be disabled. You can proceed to Step 2 (Classification Matrix).
  2. Step 2: Create Incident Classification Matrix

    🎯 Goal: Define a four-tier incident severity classification system (P1-P4) that determines response urgency, resource allocation, escalation requirements, and notification obligations. Classification enables consistent prioritization across all incidents.

    📝 Why This Matters: CISM Domain 4 emphasizes that incident classification drives everything—SLAs, staffing, executive notification, and regulatory reporting. Without classification, all incidents receive equal treatment, which means critical ransomware gets the same response time as a minor policy violation. Classification also determines who gets notified: P1 requires immediate CISO notification, while P4 may only require team lead awareness. Auditors specifically check that classification criteria are documented and consistently applied.

    📊 Understanding Severity Levels:
    P1-Critical: Incidents with immediate, severe business impact requiring emergency response. Examples include active ransomware, confirmed data breach affecting >10K records, critical infrastructure compromise, or nation-state attack indicators. Response SLA: 15 minutes. Notification: CISO, CEO, Legal, potentially Board. May trigger business continuity activation.
    P2-High: Significant incidents requiring urgent response but not emergency-level. Examples include malware outbreak affecting multiple systems, successful phishing leading to credential compromise, or unauthorized access to sensitive systems. Response SLA: 1 hour. Notification: IT Director, Security Manager, potentially CISO.
    P3-Medium: Moderate incidents requiring timely response. Examples include isolated phishing attempts, single-system malware, suspicious but unconfirmed activity, or policy violations without data exposure. Response SLA: 4 hours. Notification: Security Manager, Team Lead.
    P4-Low: Minor incidents for tracking and trending. Examples include blocked malware, policy violations without security impact, failed attack attempts, or user complaints. Response SLA: 24 hours or next business day. Notification: Team Lead, documented for metrics.

    Action: Click the Create Classification Matrix button in the Incident Classification card (after completing Step 1). Select the following exact values from dropdowns for each severity level: • P1-Critical Example: Data breach (>10K records)
    • P1 Response Time: 15 minutes
    • P1 Notification: CISO + CEO
    • P2-High Example: Malware outbreak
    • P2 Response Time: 1 hour
    • P2 Notification: CISO
    • P3-Medium Example: Phishing attempt (blocked)
    • P3 Response Time: 4 hours
    • P3 Notification: Security Manager
    • P4-Low Example: Policy violation (minor)
    • P4 Response Time: 24 hours
    • P4 Notification: Team Lead
    Click Save Matrix when complete.

    ⚠️ Exam & Compliance Considerations: P1/P2 incidents typically require executive notification within defined timeframes. SLA compliance is tracked and reported to demonstrate program effectiveness. Classification may change during investigation—an initial P3 phishing incident may escalate to P1 if data exfiltration is discovered. Document reclassification decisions and rationale. Regulatory frameworks like PCI-DSS require documented classification criteria and evidence of consistent application.

    Expected Result: Classification card shows "P1-P4 defined" with success badge. Escalation procedures can now be configured.
  3. Step 3: Define Escalation Procedures

    🎯 Goal: Create documented escalation triggers and decision trees that define when and how incidents are escalated to senior management, C-suite executives, and the Board of Directors. Escalation procedures ensure appropriate leadership involvement based on business impact, not just technical severity.

    📝 Why This Matters: CISM Domain 4 tests your understanding that escalation must be based on business impact, not technical metrics alone. A CISO may not care about a specific CVE, but they must know about any incident affecting customer data, regulatory compliance, or financial systems. Escalation procedures also protect the organization legally—documented escalation shows due diligence. Without clear escalation triggers, incidents may be under-escalated (executives surprised by media coverage) or over-escalated (CISO receiving every minor alert).

    📊 Understanding Escalation Triggers:
    Data Breach (>10K records): Any confirmed unauthorized access to personal data affecting more than 10,000 individuals requires immediate C-suite notification because it triggers regulatory reporting obligations (GDPR 72-hour rule, state breach notification laws) and potential class-action liability.
    Ransomware (>$1M impact): Ransomware affecting critical systems requires Board notification when potential financial impact exceeds $1M because this represents material risk that Board members have fiduciary duty to understand. May also require SEC 8-K filing for public companies.
    Regulatory Violation: Any incident that may result in regulatory penalty requires Legal and Compliance Officer involvement to manage notification requirements, preserve privileged communications, and coordinate with external counsel if needed.

    Action: Click the Define Escalation Procedures button in the Escalation card. Select the following exact values from the dropdown menus:
    • Data Breach (>10K records): Select CISO + Legal + CEO
    • Ransomware (>$1M impact): Select CISO + CTO + Board
    • Regulatory Violation: Select CISO + Compliance Officer + External Counsel
    • P1 Escalation Time: Select Immediate (0 min)
    • P2 Escalation Time: Select 1 hour
    Click Save Escalation.

    💡 CISM Principle & Legal Considerations: Escalation criteria must align with business impact, not just technical severity. A single compromised workstation might be P3 technically, but if it contains M&A documents, it's a P1 business impact requiring CEO notification. Board notification is typically required for "material" events that could affect stock price, reputation, or legal exposure. Document all escalation decisions with timestamps—this creates an audit trail showing appropriate management involvement and supports legal privilege claims.

    Expected Result: Escalation card shows "Escalation defined" with success badge. Communication protocols can now be established.
  4. Step 4: Establish Communication Protocols

    🎯 Goal: Define internal and external communication plans for different stakeholder groups including employees, customers, regulators, media, law enforcement, and cyber insurance carriers. Communication protocols ensure consistent, approved messaging that protects the organization legally while maintaining trust.

    📝 Why This Matters: CISM Domain 4 heavily emphasizes stakeholder communication as a critical incident management competency. Poor communication during incidents destroys customer trust, exposes the organization to legal liability, and can result in regulatory penalties. GDPR Article 34 requires notifying affected individuals "without undue delay" for high-risk breaches. HIPAA requires specific notification content and timelines. Getting communication wrong can be more damaging than the incident itself—Equifax's delayed and confusing notifications cost them billions in settlements.

    📊 Understanding Stakeholder Communications:
    Internal Alert: Notifies employees about incidents affecting their work, required actions (password changes, avoiding certain systems), and where to report suspicious activity. Must be clear, actionable, and avoid creating panic. Approved by Incident Manager.
    Customer Notification: Required by GDPR within 72 hours of breach discovery if personal data is compromised. Must include: nature of breach, categories of data affected, likely consequences, measures taken, contact point for questions. Legal must review before sending.
    Regulatory Report: Formal notification to supervisory authorities (ICO, HHS, state AGs). Must include detailed incident timeline, scope assessment, root cause, and remediation steps. Legal and Compliance lead preparation.
    Media Statement: Public-facing communication that acknowledges the incident, expresses concern for affected parties, and describes response actions. Must be approved by Legal and PR to avoid admissions of liability or inaccurate statements.

    Action: Click the Establish Communication Protocols button in the Communications card. Select the following exact options using radio buttons and dropdowns:
    • Internal Alert Template: Select Detailed (All above + Timeline + Next steps) radio button
    • Customer Notification (GDPR 72hr): Select Standard (Impact + Data affected + Remediation steps) radio button
    • Internal Approval Authority: Select CISO from dropdown
    • External Approval Authority: Select CISO + Legal + PR from dropdown
    Click Save Communications.

    ⚠️ Compliance Requirements & Timelines: GDPR mandates supervisory authority notification within 72 hours of becoming "aware" of a breach involving personal data. HIPAA requires breach notification to HHS within 60 days, and individuals must be notified "without unreasonable delay" (typically 60 days). PCI-DSS requires notification to payment brands immediately upon suspecting card data compromise. State breach notification laws vary—some require notification within 30 days. Always have Legal review external communications before sending—statements can create liability or waive privilege.

    Expected Result: Communications card shows "Protocols defined" with success badge. BCP integration is the next step.
  5. Step 5: Integrate with Business Continuity Plan

    🎯 Goal: Link the Incident Response plan with the Business Continuity Plan (BCP) to ensure coordinated response when incidents escalate to business disruption scenarios such as ransomware affecting critical systems, data center breaches, or prolonged outages. This integration prevents response gaps and ensures business operations can continue.

    📝 Why This Matters: CISM Domain 4 explicitly requires understanding the relationship between IR and BC/DR (Business Continuity/Disaster Recovery). Many organizations treat these as separate programs, but in practice they overlap significantly. A ransomware attack is both a security incident (requiring IR) and a business disruption (requiring BCP activation). Without integration, the IR team may be investigating while the business is unable to operate, or the BCP team may restore from backups without realizing they're restoring compromised systems.

    📊 Understanding IR/BCP Integration:
    RTO (Recovery Time Objective): The maximum acceptable time that a system or process can be unavailable. For critical financial systems, RTO might be 4 hours. This drives decisions about when to failover to DR site vs. continue incident investigation on primary systems.
    RPO (Recovery Point Objective): The maximum acceptable data loss measured in time. An RPO of 1 hour means you can lose at most 1 hour of data, requiring backups or replication at least hourly. This affects recovery decisions—restoring from a 24-hour-old backup when RPO is 1 hour is unacceptable.
    BCP Activation Triggers: Specific conditions that warrant BCP activation during an incident, such as ransomware encrypting critical systems, data center physical security breach, or any incident causing outage beyond RTO threshold.

    Action: Click the Integrate with Business Continuity button in the BCP Integration card. Select the following exact values from the dropdown menus:
    • Ransomware (critical systems) Trigger Action: Select Activate BCP, failover to DR site
    • Data Center Breach Trigger Action: Select IR + BCP joint activation
    • RTO (Recovery Time Objective): Select 4 hours
    • RPO (Recovery Point Objective): Select 1 hour
    Click Link BCP.

    💡 CISM Domain 4 Integration Points: IR and BCP teams must communicate constantly during major incidents. The IR team determines whether systems are safe to restore; the BCP team manages business operations during outage. Joint tabletop exercises should test this coordination annually. Key decision: Do you failover to DR immediately (meeting RTO but potentially replicating compromised data) or wait for IR investigation (risking RTO breach)? This decision should be pre-defined based on incident type and documented in both plans.

    Expected Result: BCP Integration card shows "BCP linked" with success badge. Post-incident review process is the next step.
  6. Step 6: Define Post-Incident Review Process

    🎯 Goal: Establish a formal lessons learned and continuous improvement process that occurs after every significant incident. Post-incident review identifies what worked well, what needs improvement, and generates actionable recommendations that improve future incident response capabilities.

    📝 Why This Matters: CISM Domain 4 requires demonstrating continuous improvement in incident management programs. Without formal post-incident review, organizations make the same mistakes repeatedly and miss opportunities to improve detection, response, and recovery capabilities. Regulatory frameworks (PCI-DSS, HIPAA) require documented post-incident review. Insurance carriers increasingly require evidence of lessons learned implementation. The post-incident review also provides legal documentation that the organization exercised due care.

    📊 Understanding Post-Incident Review Components:
    Lessons Learned Meeting: Formal meeting within 7 days of incident closure involving all CSIRT members and relevant stakeholders. Uses blameless approach focusing on process improvement, not individual fault. Documents timeline, decisions made, outcomes achieved, and areas for improvement.
    Root Cause Analysis (RCA): Technical deep-dive identifying the underlying cause of the incident—not just the attack vector, but why defenses failed. Includes both technical factors (missing patch, misconfigured firewall) and organizational factors (understaffing, lack of training, unclear ownership).
    Improvement Actions: Specific, measurable, assigned, and time-bound (SMART) actions resulting from RCA. Examples: update detection rules within 14 days, implement MFA by Q2, add phishing training module by month-end. Track completion.
    Metrics Review: Quantitative analysis of response effectiveness including MTTD (Mean Time To Detect), MTTR (Mean Time To Respond), containment effectiveness, and SLA compliance. Trend over time to demonstrate program improvement.

    Action: Click the Define Review Process button in the Post-Incident card. Select the following exact values using dropdowns and radio buttons:
    • Lessons Learned Meeting Timeframe: Select Within 7 days from dropdown
    • Lessons Learned Attendees: Select All CSIRT + stakeholders from dropdown
    • Root Cause Analysis Scope: Select Full analysis (Technical + Organizational + Human factors) radio button
    • Improvement Actions Priority: Select Update playbooks + controls + training (equal priority) radio button
    • Metrics to Review: Select Comprehensive (All above + Cost + Business impact) radio button
    • Review Lead: Select Incident Manager from dropdown
    • Final Approver: Select CISO from dropdown
    Click Save Review Process.

    Continuous Improvement & Metrics: CISM requires metrics-driven program enhancement. Key metrics to track: MTTD (how quickly incidents are detected—goal is to reduce this below industry average of 277 days for breaches), MTTR (how quickly incidents are resolved), containment effectiveness (percentage of incidents contained before spreading), SLA compliance (percentage of incidents meeting response time targets). Present metrics to leadership quarterly and demonstrate year-over-year improvement. Use metrics to justify budget requests for security improvements.

    Expected Result: Post-Incident card shows "Review process defined" with success badge. You can now generate the complete IR Plan document.
  7. Step 7: Generate IR Plan Document

    🎯 Goal: Compile all configured components into a comprehensive Incident Response Plan document suitable for CISO approval, board review, and regulatory audit. The generated document serves as the authoritative reference for incident response procedures and demonstrates organizational preparedness.

    📝 Why This Matters: CISM Domain 4 requires that IR plans be documented, approved by management, and regularly tested. Auditors and regulators will request the IR plan as evidence of security program maturity. The plan must be comprehensive enough to guide response during a crisis (when there's no time to figure things out) while being concise enough that team members actually read and follow it. CISO signature demonstrates management endorsement and commitment of resources.

    📊 IR Plan Document Components:
    Team Structure & RACI: Documented roles, responsibilities, contact information, and accountability matrix for all IR phases.
    Classification Matrix: P1-P4 severity definitions with examples, SLAs, and notification requirements.
    Escalation Procedures: Documented triggers, decision trees, and contact chains for management escalation.
    Communication Protocols: Templates, approval workflows, and regulatory notification requirements for all stakeholder groups.
    BCP Integration: Triggers for business continuity activation, RTO/RPO requirements, and coordination procedures.
    Post-Incident Review: Lessons learned process, RCA requirements, metrics tracking, and continuous improvement procedures.

    Action: Click the Generate IR Plan Document button in the Generate Plan card. The system will compile all your configurations into a comprehensive plan document. Review the generated plan for completeness, then submit for CISO approval.

    💡 Final Steps & Ongoing Requirements: The IR plan is a living document requiring annual review and updates after major incidents or organizational changes. Test the plan through tabletop exercises at least annually—walk through realistic scenarios with the CSIRT to identify gaps. The Board should formally approve the IR program annually as part of their risk oversight responsibilities. Distribute the plan to all CSIRT members and ensure they understand their roles. Store copies in multiple locations (not just on systems that might be compromised during an incident).

    Expected Result: Success notification confirms the IR Plan has been generated and is ready for CISO review. Lab 18 is complete when the plan is submitted.
  8. Step 8: Certification Knowledge Check (MCQ Set)

    📚 Complete the following multiple-choice questions based on CISM Domain 4 and CISSP Domain 7 incident response concepts. These questions test certification-level understanding and are required for full lab completion.

    Question 1: According to NIST SP 800-61 Rev. 2, which incident response phase involves developing processes and procedures to prevent incidents from occurring, and establishing the capability to respond effectively when incidents do occur?
    Question 2: In a RACI matrix for incident response, which role designation indicates the person who has ultimate accountability and authority to approve decisions, even though they may not perform the work themselves?
    Question 3: According to GDPR Article 33, within what timeframe must a data controller notify the relevant supervisory authority after becoming aware of a personal data breach?
IR Plan Builder - CISM Lab

CSIRT Team

Team not configured

Incident Classification

Classification not defined

Escalation

Escalation not configured

Communications

Communications not planned

BCP Integration

BCP not linked

Post-Incident

Review process not defined

Generate Plan

Progress: 0/8
Score: 0/100
`; reportWindow.document.write(reportHTML); reportWindow.document.close(); // Save HTML to disk in cybersecurity folder const blob = new Blob([reportHTML], {type: 'text/html'}); const link = document.createElement('a'); link.href = URL.createObjectURL(blob); link.download = `Risk_Assessment_Report_${new Date().toISOString().split('T')[0]}.html`; link.style.display = 'none'; document.body.appendChild(link); link.click(); setTimeout(() => { document.body.removeChild(link); URL.revokeObjectURL(link.href); }, 100); showNotify('success','Report Generated','Comprehensive 3-page risk report opened in new tab AND downloaded to your Downloads folder. Use Print (Ctrl+P) to save as PDF.'); } function validateSEC(){ const st=state.sec; const scoring=document.getElementById('sec-scoring'); const tasks=['Assess web server (qualitative)','Calculate database ALE','Assess backup system','Mitigate web server risk','Transfer database risk','Mitigate backup risk','Generate risk report','Answer all 3 MCQs correctly']; const completedIdx=st.completed.map(i=>i-1); const rem = tasks.filter((_,i)=>!completedIdx.includes(i)); let html = '
'; if(completedIdx.length>0){ html += '

Completed Tasks ('+completedIdx.length+'/'+tasks.length+')

'; } if(rem.length>0){ html += '

Remaining Tasks ('+rem.length+')

'; } if(rem.length===0){ html += '

Lab Complete!

Risk assessment and mitigation strategies applied per Security+ Domain 5.2 and CISSP Domain 1.9.

'; } html += '
'; scoring.innerHTML=html; } // ======= CISSP Terminal ======= const cisspCommands = [ { cmd:'sudo apt-get update && sudo apt-get install -y python3-saml xmlsec1 xmlstarlet curl jq', out:`Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease Hit:2 http://archive.ubuntu.com/ubuntu jammy-updates InRelease Hit:3 http://archive.ubuntu.com/ubuntu jammy-backports InRelease Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: libltdl7 libxmlsec1 libxmlsec1-openssl python3-defusedxml python3-isodate python3-lxml python3-xmlsec Suggested packages: xmlsec1-doc The following NEW packages will be installed: curl jq libltdl7 libxmlsec1 libxmlsec1-openssl python3-defusedxml python3-isodate python3-lxml python3-saml python3-xmlsec xmlsec1 xmlstarlet 0 upgraded, 12 newly installed, 0 to remove and 0 not upgraded. Need to get 3,847 kB of archives. After this operation, 15.2 MB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu jammy/main amd64 libltdl7 amd64 2.4.6-15build2 [39.6 kB] Get:2 http://archive.ubuntu.com/ubuntu jammy/main amd64 libxmlsec1 amd64 1.2.33-1build2 [184 kB] Get:3 http://archive.ubuntu.com/ubuntu jammy/main amd64 libxmlsec1-openssl amd64 1.2.33-1build2 [64.3 kB] Get:4 http://archive.ubuntu.com/ubuntu jammy/main amd64 xmlsec1 amd64 1.2.33-1build2 [152 kB] Get:5 http://archive.ubuntu.com/ubuntu jammy/universe amd64 xmlstarlet amd64 1.6.1-2.1 [52.4 kB] Get:6 http://archive.ubuntu.com/ubuntu jammy/main amd64 curl amd64 7.81.0-1ubuntu1.15 [194 kB] Get:7 http://archive.ubuntu.com/ubuntu jammy/main amd64 jq amd64 1.6-2.1ubuntu3 [52.5 kB] Get:8 http://archive.ubuntu.com/ubuntu jammy/universe amd64 python3-saml all 1.14.0-1 [1,068 kB] Fetched 3,847 kB in 2s (1,924 kB/s) Selecting previously unselected package libltdl7:amd64. (Reading database ... 156789 files and directories currently installed.) Preparing to unpack .../00-libltdl7_2.4.6-15build2_amd64.deb ... Unpacking libltdl7:amd64 (2.4.6-15build2) ... Selecting previously unselected package libxmlsec1:amd64. Preparing to unpack .../01-libxmlsec1_1.2.33-1build2_amd64.deb ... Unpacking libxmlsec1:amd64 (1.2.33-1build2) ... Selecting previously unselected package xmlsec1. Preparing to unpack .../02-xmlsec1_1.2.33-1build2_amd64.deb ... Unpacking xmlsec1 (1.2.33-1build2) ... Selecting previously unselected package xmlstarlet. Preparing to unpack .../03-xmlstarlet_1.6.1-2.1_amd64.deb ... Unpacking xmlstarlet (1.6.1-2.1) ... Setting up libltdl7:amd64 (2.4.6-15build2) ... Setting up libxmlsec1:amd64 (1.2.33-1build2) ... Setting up libxmlsec1-openssl:amd64 (1.2.33-1build2) ... Setting up xmlsec1 (1.2.33-1build2) ... Setting up xmlstarlet (1.6.1-2.1) ... Setting up curl (7.81.0-1ubuntu1.15) ... Setting up jq (1.6-2.1ubuntu3) ... Setting up python3-saml (1.14.0-1) ... Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.4) ...` }, { cmd:'curl -s https://idp.techcorp.com/metadata.xml -o /etc/saml/idp-metadata.xml && xmlstarlet sel -N md="urn:oasis:names:tc:SAML:2.0:metadata" -t -v "//md:SingleSignOnService/@Location" /etc/saml/idp-metadata.xml', out:` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 34 4283 34 1456 0 0 4368 0 0:01:47 0:00:32 0:01:15 4368 78 4283 78 3342 0 0 8355 0 0:01:47 0:01:05 0:00:42 8355 100 4283 100 4283 0 0 10707 0 0:01:47 0:01:47 --:--:-- 10707 === IdP Metadata Downloaded === File: /etc/saml/idp-metadata.xml (4283 bytes) === Extracted SSO Endpoints === https://idp.techcorp.com/saml2/sso/redirect https://idp.techcorp.com/saml2/sso/post` }, { cmd:'openssl req -new -x509 -days 365 -nodes -sha256 -newkey rsa:2048 -keyout /etc/saml/sp.key -out /etc/saml/sp.crt -subj "/CN=app.fintech.com/O=FinTech Corp/C=US"', out:`Generating a RSA private key ....................+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ writing new private key to '/etc/saml/sp.key' ----- === Private Key Generated === $ cat /etc/saml/sp.key -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC7JHoD3BSAIHH8 q4MfT7VdZrP3X5gYmCU2kFZ9YtVe8KJVcNQ2m3C9aHWxRz6V1vBtKQFN7L4HsP2u XJk2xLv9qRHbC4Z8nMcF3dGfWnP7VtF6K9RqVJ5X2D8qYHJgNM4w1XHT6d4BLQKP 1rH3Z9pK5cV7dRxYQ8nJ6WmP2sB4wLvM5tC3RqN8qH7F4K9xZD2jB6vQ3T9pL5nH 8w6Y7CmN3dK4sZLJ1VhB5x9RqFHpN2W7tC8vX4zPQmJK6L5Y9wR3D8mT2nHQ5sVt C7F8bKN1qWZp3X6R9vHL4jDqB5pN2C8wT3sK7L6Y9xRvZ4nQ2mP8wJqT5H3C7K9v X4zL1R8nAgMBAAECggEABxD2Q3Z8p5Y9wR7L4K9vN2mH3T5sC8wJ6qR1nXZ4tVQP K7F8L9xH2D3mN5vC4wT8sJ6qR1nZp3X5Y9wR7L4K9vN2mH3T5sC8wJ6qR1nXZ4tV QPK7F8L9xH2D3mN5vC4wT8sJ6qR1nZp3X5Y9wR7L4K9vN2mH3T5sC8wJ6qR1nXZ4 tVQPK7F8L9xH2D3mN5vC4wT8sJ6qR1nZp3X5Y9wR7L4K9vN2mH3T5sC8wJ6qR1nX Z4tVQPK7F8L9xH2D3mN5vC4wT8sJ6qR1nZp3X5Y9wR7L4K9vN2mH3T5sC8wJ6qR1 nXZ4tVQPK7F8L9xH2D3mN5vC4wT8sJ6qR1nZp3X5Y9wR7L4K9vN2mH3T5sAoGBAO xH2D3mN5vC4wT8sJ6qR1nZp3X5Y9wR7L4K9vN2mH3T5sC8wJ6qR1nXZ4tVQPK7F8 -----END PRIVATE KEY----- === Certificate Generated === $ cat /etc/saml/sp.crt -----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAK7F8L9xH2D3MA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV BAYTAlVTMRQwEgYDVQQKDAtGaW5UZWNoIENvcnAxIDAeBgNVBAMMF2FwcC5maW50 ZWNoLmNvbTAeFw0yNDAxMjUxNDMyMTdaFw0yNTAxMjQxNDMyMTdaMEUxCzAJBgNV BAYTAlVTMRQwEgYDVQQKDAtGaW5UZWNoIENvcnAxIDAeBgNVBAMMF2FwcC5maW50 ZWNoLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALskegPcFIAg cfyrgx9PtV1ms/dfmBiYJTaQVn1i1V7wolVw1DabcL1odbFHPpXW8G0pAU3svgew /a5cmTbEu/2pEdsLhnycxwXd0Z9ac/tW0Xor1GpUnlfYPypgcmA0zjDVcdPp3gEt Ao/WsfdnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA YHJgNM4w1XHT6d4BLQKPZGfWnP7VtF6K9RqVJ5X2DqV7dRxYQ8nJ6WmP2sB4wLvM 5tC3RqN8qH7F4K9xZD2jB6vQ3T9pL5nH8w6Y7CmN3dK4sZLJ1VhB5x9RqFHpN2W7 tC8vX4zPQmJK6L5Y9wRvZ4nQ2mP8wJqT5H3C7K9vX4zL1R8nAwIDAQABo1AwTjAd BgNVHQ4EFgQU7L4K9vN2mH3T5sC8wJ6qR1nXZ4swHwYDVR0jBBgwFoAU7L4K9vN2 mH3T5sC8wJ6qR1nXZ4swDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEA q4MfT7VdZrP3X5gYmCU2kFZ9YtVe8KJVcNQ2m3C9aHWxRz6V1vBtKQFN7L4Hs== -----END CERTIFICATE----- === Certificate Details === $ openssl x509 -in /etc/saml/sp.crt -noout -text | head -20 Certificate: Data: Version: 3 (0x2) Serial Number: ae:c5:f0:bf:71:1f:60:f7 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = FinTech Corp, CN = app.fintech.com Validity Not Before: Jan 25 14:32:17 2024 GMT Not After : Jan 24 14:32:17 2025 GMT Subject: C = US, O = FinTech Corp, CN = app.fintech.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) === Fingerprints === SHA1: 4A:B7:C8:D9:E0:F1:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD SHA256: 7F:8E:9D:0A:1B:2C:3D:4E:5F:60:71:82:93:A4:B5:C6:D7:E8:F9:0A:1B:2C:3D:4E:5F:60:71:82:93:A4:B5:C6 ✓ SP Certificate and Private Key created successfully` }, { cmd:'LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://dc.techcorp.com:636 -D "cn=admin,dc=techcorp,dc=com" -w P@ssw0rd -b "ou=Users,dc=techcorp,dc=com" "(objectClass=inetOrgPerson)" mail givenName sn memberOf', out:`# extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectClass=inetOrgPerson) # requesting: mail givenName sn memberOf # # admin, Users, techcorp.com dn: uid=admin,ou=Users,dc=techcorp,dc=com mail: admin@techcorp.com givenName: John sn: Admin memberOf: cn=Domain Admins,ou=Groups,dc=techcorp,dc=com memberOf: cn=SSO-Users,ou=Groups,dc=techcorp,dc=com # alice.johnson, Users, techcorp.com dn: uid=alice.johnson,ou=Users,dc=techcorp,dc=com mail: alice.johnson@techcorp.com givenName: Alice sn: Johnson memberOf: cn=Security-Team,ou=Groups,dc=techcorp,dc=com memberOf: cn=SSO-Users,ou=Groups,dc=techcorp,dc=com # bob.smith, Users, techcorp.com dn: uid=bob.smith,ou=Users,dc=techcorp,dc=com mail: bob.smith@techcorp.com givenName: Bob sn: Smith memberOf: cn=Developers,ou=Groups,dc=techcorp,dc=com memberOf: cn=SSO-Users,ou=Groups,dc=techcorp,dc=com # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3` }, { cmd:`cat > /etc/saml/settings.json << 'EOF' {"sp":{"entityId":"https://app.fintech.com","assertionConsumerService":{"url":"https://app.fintech.com/saml/acs"}},"idp":{"entityId":"https://idp.techcorp.com","singleSignOnService":{"url":"https://idp.techcorp.com/saml2/sso"}},"attributeMapping":{"email":"mail","firstName":"givenName","lastName":"sn","groups":"memberOf"}} EOF`, out:`$ cat /etc/saml/settings.json | jq . { "sp": { "entityId": "https://app.fintech.com", "assertionConsumerService": { "url": "https://app.fintech.com/saml/acs" } }, "idp": { "entityId": "https://idp.techcorp.com", "singleSignOnService": { "url": "https://idp.techcorp.com/saml2/sso" } }, "attributeMapping": { "email": "mail", "firstName": "givenName", "lastName": "sn", "groups": "memberOf" } } SAML SP configuration saved to /etc/saml/settings.json JIT (Just-In-Time) provisioning enabled via attributeMapping` }, { cmd:`cat >> /etc/saml/settings.json << 'EOF' ,"security":{"requestedAuthnContext":["urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport","urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract"],"requestedAuthnContextComparison":"minimum"} EOF`, out:`$ cat /etc/saml/settings.json | jq '.security' { "requestedAuthnContext": [ "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract" ], "requestedAuthnContextComparison": "minimum" } MFA Authentication Context configured: - PasswordProtectedTransport: Username/Password over TLS (baseline) - MobileTwoFactorContract: MFA required (TOTP/Push/SMS) - Comparison: "minimum" = IdP must provide AT LEAST MFA level Compliance: ✓ NIST SP 800-63B: AAL2/AAL3 (MFA required for sensitive resources) ✓ NIST CSF: PR.AC-7 (Users authenticated commensurate with risk) ✓ PCI-DSS 4.0: Requirement 8.4.2 (MFA for all non-console admin access)` }, { cmd:'curl -s -c /tmp/cookies.txt -b /tmp/cookies.txt -L "https://app.fintech.com/saml/login?RelayState=/dashboard" 2>&1 | xmlstarlet sel -N saml="urn:oasis:names:tc:SAML:2.0:assertion" -t -v "//saml:NameID" -n -v "//saml:Attribute[@Name=\'email\']/saml:AttributeValue" 2>/dev/null || echo "SSO redirect initiated - check browser"', out:` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2847 100 2847 0 0 9489 0 --:--:-- --:--:-- --:--:-- 9523 === SAML Response Received === Status: urn:oasis:names:tc:SAML:2.0:status:Success Issuer: https://idp.techcorp.com IssueInstant: 2024-01-25T14:45:23Z === Assertion Details === NameID: admin@techcorp.com NameIDFormat: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SessionIndex: _session_8f63a820-4c9d-0138-1234-0050568b9ab8 SessionNotOnOrAfter: 2024-01-25T22:45:23Z === Attributes === email: admin@techcorp.com givenName: John sn: Admin memberOf: cn=Domain Admins,ou=Groups,dc=techcorp,dc=com memberOf: cn=SSO-Users,ou=Groups,dc=techcorp,dc=com === AuthnContext === AuthnContextClassRef: urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract AuthnInstant: 2024-01-25T14:45:18Z AuthenticatingAuthority: https://idp.techcorp.com === Signature Validation === $ xmlsec1 --verify --pubkey-cert-pem /etc/saml/idp-cert.pem saml_response.xml OK SignatureMethod: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 DigestMethod: http://www.w3.org/2001/04/xmlenc#sha256 ✓ SSO Login Successful ✓ MFA verified (MobileTwoFactorContract) ✓ Assertion signature valid (RSA-SHA256) ✓ Session token issued: /var/log/saml/session-token.jwt` }, { cmd:`cat /var/log/saml/session-token.jwt | cut -d'.' -f2 | base64 -d 2>/dev/null | jq '{sub,iss,aud,exp,email,groups,auth_method}'`, out:`{ "sub": "admin@techcorp.com", "iss": "https://app.fintech.com", "aud": "https://app.fintech.com", "exp": 1706209523, "email": "admin@techcorp.com", "groups": [ "Domain Admins", "SSO-Users" ], "auth_method": "mfa" } === JWT Token Analysis === Algorithm: RS256 (RSA Signature with SHA-256) Issued At: 2024-01-25 14:45:23 UTC Expires: 2024-01-25 22:45:23 UTC (8 hours) Token Lifetime: 28800 seconds Identity Claims: Subject (sub): admin@techcorp.com Issuer (iss): https://app.fintech.com (SP) Audience (aud): https://app.fintech.com Federated Identity Attributes: Email: admin@techcorp.com Groups: Domain Admins, SSO-Users Auth Method: mfa (Multi-Factor Authentication) IdP: https://idp.techcorp.com/saml2 ✓ Token signature verified ✓ Token not expired ✓ Federated identity session established` } ]; function executeCISSP(){ const input=document.getElementById('cissp-terminal-input'); const output=document.getElementById('cissp-terminal-output'); const cmd=input.value; if(!cmd) return; output.innerHTML += `
root@iam-server:~# ${escapeHtml(cmd)}
`; const st=state.cissp; const expected = cisspCommands[st.index]?.cmd; if(cmd === expected){ output.innerHTML += `
${escapeHtml(cisspCommands[st.index].out)}
`; st.index++; markDone('cissp', st.index); } else { output.innerHTML += `
command not found or incorrect order. Commands must match EXACTLY (case-sensitive) and IN ORDER.
`; } input.value=''; output.scrollTop=output.scrollHeight; } function validateCISSP(){ const st=state.cissp; const scoring=document.getElementById('cissp-scoring'); const tasks=['Install SAML toolkit','Download IdP metadata','Generate SP certificate','Configure LDAP','Set attribute mapping','Enable MFA context','Test SSO login','Verify JWT token']; const completedIdx=st.completed.map(i=>i-1); const rem = tasks.filter((_,i)=>!completedIdx.includes(i)); let html = '
'; if(completedIdx.length>0){ html += ''; } if(rem.length>0){ html += ''; } if(rem.length===0){ html += ''; } html += '
'; scoring.innerHTML=html; } // ======= CISM IR Plan ======= function cismDefineTeam(){ if(!state.cism.teamRoles) state.cism.teamRoles = []; const rolesHtml = state.cism.teamRoles.length > 0 ? state.cism.teamRoles.map(r=>`
${escapeHtml(r)}
`).join('') : '

Roles will appear here...

'; const modal=``; document.querySelectorAll('#team-modal').forEach(m=>m.remove()); document.body.insertAdjacentHTML('beforeend', modal); document.getElementById('modal-overlay').classList.add('active'); } function cismAddRole(){ const input = document.getElementById('new-role-input'); const role = input?.value.trim(); if(!role) return; if(!state.cism.teamRoles) state.cism.teamRoles = []; state.cism.teamRoles.push(role); input.value = ''; const div = document.getElementById('team-roles'); div.innerHTML = state.cism.teamRoles.map(r=>`
${escapeHtml(r)}
`).join(''); } function cismRemoveRole(role){ state.cism.teamRoles = state.cism.teamRoles.filter(r => r !== role); const div = document.getElementById('team-roles'); div.innerHTML = state.cism.teamRoles.length > 0 ? state.cism.teamRoles.map(r=>`
${escapeHtml(r)}
`).join('') : '

Roles will appear here...

'; } function cismSaveTeam(){ const required = ['Incident Manager','Security Analyst','Forensics Specialist','Communications Lead','Legal Counsel']; const hasAll = required.every(r => state.cism.teamRoles?.some(tr => tr.toLowerCase().includes(r.toLowerCase().split(' ')[0]))); if(!hasAll){ showNotify('error','Incomplete Configuration','Review the instructions and add all required roles.'); return; } state.cism.team = true; state.cism.raci = true; markDone('cism', 1); markDone('cism', 2); document.getElementById('cism-team-status').innerHTML = 'Team defined'; document.querySelectorAll('.modal').forEach(m=>m.remove()); document.getElementById('modal-overlay').classList.remove('active'); // Disable button - step complete document.querySelector('#cism-team-status').parentElement.querySelector('button').outerHTML = ''; showNotify('success','Team Defined','CSIRT team structure created. Next: Create Classification Matrix.'); } function cismRACI(){ if(!state.cism.team){ showNotify('error','Team Required','Define team structure first.'); return; } const modal=``; document.body.insertAdjacentHTML('beforeend', modal); document.getElementById('modal-overlay').classList.add('active'); } function cismSaveRACI(){ const phases = ['prep','det','cont','erad','recov','lessons']; const allA = phases.every(p => document.getElementById(`raci-${p}`).value === 'A'); if(!allA){ showNotify('error','Incorrect Configuration','Review the instructions and try again.'); return; } state.cism.raci = true; markDone('cism', 2); document.querySelectorAll('.modal').forEach(m=>m.remove()); document.getElementById('modal-overlay').classList.remove('active'); // Update team card button to show completion const teamCard = document.querySelector('#cism-team-status').parentElement; teamCard.querySelector('button').outerHTML = ''; showNotify('success','RACI Assigned','Incident Manager accountable for all IR phases. Click "Create Classification Matrix" to continue.'); } function cismClassification(){ if(!state.cism.team){ showNotify('error','Complete Previous Steps','Complete Step 1 (Team Structure) first.'); return; } const modal=``; document.body.insertAdjacentHTML('beforeend', modal); document.getElementById('modal-overlay').classList.add('active'); } function cismSaveClassification(){ const p1 = document.getElementById('class-p1').value; const p1time = document.getElementById('class-p1-time').value; const p1notify = document.getElementById('class-p1-notify').value; const p2 = document.getElementById('class-p2').value; const p2time = document.getElementById('class-p2-time').value; const p2notify = document.getElementById('class-p2-notify').value; const p3 = document.getElementById('class-p3').value; const p3time = document.getElementById('class-p3-time').value; const p3notify = document.getElementById('class-p3-notify').value; const p4 = document.getElementById('class-p4').value; const p4time = document.getElementById('class-p4-time').value; const p4notify = document.getElementById('class-p4-notify').value; if(!p1 || !p1time || !p1notify || !p2 || !p2time || !p2notify || !p3 || !p3time || !p3notify || !p4 || !p4time || !p4notify){ showNotify('error','Incomplete Configuration','Please select all required fields.'); return; } if(p1 !== 'Data breach' || p1time !== '15min' || p1notify !== 'CISO+CEO' || p2 !== 'Malware outbreak' || p2time !== '1hr' || p2notify !== 'CISO' || p3 !== 'Phishing' || p3time !== '4hr' || p3notify !== 'Security Manager' || p4 !== 'Policy violation' || p4time !== '24hr' || p4notify !== 'Team Lead'){ showNotify('error','Incorrect Configuration','One or more severity levels have incorrect configuration. Review the Step 3 instructions carefully and ensure all dropdowns match the required values.'); return; } state.cism.classification = true; markDone('cism', 2); document.getElementById('cism-class-status').innerHTML = 'P1-P4 defined'; document.querySelectorAll('.modal').forEach(m=>m.remove()); document.getElementById('modal-overlay').classList.remove('active'); showNotify('success','Classification Saved','Incident severity matrix defined. Next: Escalation procedures.'); } function cismEscalation(){ if(!state.cism.classification){ showNotify('error','Complete Previous Steps','Complete Step 3 (Classification Matrix) first.'); return; } const modal=``; document.body.insertAdjacentHTML('beforeend', modal); document.getElementById('modal-overlay').classList.add('active'); } function cismSaveEscalation(){ const breach = document.getElementById('esc-breach').value; const ransom = document.getElementById('esc-ransom').value; const reg = document.getElementById('esc-reg').value; const p1time = document.getElementById('esc-p1-time').value; const p2time = document.getElementById('esc-p2-time').value; if(!breach || !ransom || !reg || !p1time || !p2time){ showNotify('error','Incomplete Configuration','Please select all required fields.'); return; } if(breach !== 'CISO + Legal + CEO' || ransom !== 'CISO + CTO + Board' || reg !== 'CISO + Compliance Officer + External Counsel' || p1time !== 'Immediate' || p2time !== '1hr'){ showNotify('error','Incorrect Configuration','One or more escalation procedures are incorrect. Review the Step 4 instructions and verify all escalation teams and timeframes.'); return; } state.cism.escalation = true; markDone('cism', 3); document.getElementById('cism-esc-status').innerHTML = 'Escalation defined'; document.querySelectorAll('.modal').forEach(m=>m.remove()); document.getElementById('modal-overlay').classList.remove('active'); showNotify('success','Escalation Saved','Executive escalation procedures established. Next: Communication protocols.'); } function cismCommunications(){ if(!state.cism.escalation){ showNotify('error','Complete Previous Steps','Complete Step 4 (Escalation Procedures) first.'); return; } const modal=``; document.body.insertAdjacentHTML('beforeend', modal); document.getElementById('modal-overlay').classList.add('active'); } function cismSaveCommunications(){ const internalRadio = document.querySelector('input[name="comm-internal"]:checked'); const customerRadio = document.querySelector('input[name="comm-customer"]:checked'); const internalApprover = document.getElementById('comm-internal-approver').value; const externalApprover = document.getElementById('comm-external-approver').value; if(!internalRadio || !customerRadio || !internalApprover || !externalApprover){ showNotify('error','Incomplete Configuration','Please select all radio button options and approval dropdowns.'); return; } if(internalRadio.value !== 'detailed' || customerRadio.value !== 'standard' || internalApprover !== 'CISO' || externalApprover !== 'CISO + Legal + PR'){ showNotify('error','Incorrect Configuration','Communication protocol settings do not match requirements. Review the Step 5 instructions and verify all radio button selections and approval authorities.'); return; } state.cism.comms = true; markDone('cism', 4); document.getElementById('cism-comm-status').innerHTML = 'Protocols defined'; document.querySelectorAll('.modal').forEach(m=>m.remove()); document.getElementById('modal-overlay').classList.remove('active'); showNotify('success','Communications Saved','Stakeholder communication plan established. Next: BCP integration.'); } function cismBCP(){ if(!state.cism.comms){ showNotify('error','Complete Previous Steps','Complete Step 5 (Communication Protocols) first.'); return; } const modal=``; document.body.insertAdjacentHTML('beforeend', modal); document.getElementById('modal-overlay').classList.add('active'); } function cismSaveBCP(){ const ransom = document.getElementById('bcp-ransom').value; const breach = document.getElementById('bcp-breach').value; const rto = document.getElementById('bcp-rto').value; const rpo = document.getElementById('bcp-rpo').value; if(!ransom || !breach || !rto || !rpo){ showNotify('error','Incomplete Configuration','Please select all required fields.'); return; } if(ransom !== 'Activate BCP, failover to DR site' || breach !== 'IR + BCP joint activation' || rto !== '4 hours' || rpo !== '1 hour'){ showNotify('error','Incorrect Configuration','BCP integration settings are incorrect. Review the Step 6 instructions and verify trigger actions and recovery objectives.'); return; } state.cism.bcp = true; markDone('cism', 5); document.getElementById('cism-bcp-status').innerHTML = 'BCP linked'; document.querySelectorAll('.modal').forEach(m=>m.remove()); document.getElementById('modal-overlay').classList.remove('active'); showNotify('success','BCP Integrated','IR and BCP coordination defined. Next: Post-incident review process.'); } function cismPostIncident(){ if(!state.cism.bcp){ showNotify('error','Complete Previous Steps','Complete Step 6 (BCP Integration) first.'); return; } const modal=``; document.body.insertAdjacentHTML('beforeend', modal); document.getElementById('modal-overlay').classList.add('active'); } function cismSavePostIncident(){ const meetingTime = document.getElementById('post-meeting-time').value; const meetingAttendees = document.getElementById('post-meeting-attendees').value; const rcaScope = document.querySelector('input[name="rca-scope"]:checked'); const improvePriority = document.querySelector('input[name="improve-priority"]:checked'); const metricsReview = document.querySelector('input[name="metrics-review"]:checked'); const lead = document.getElementById('post-lead').value; const approver = document.getElementById('post-approver').value; if(!meetingTime || !meetingAttendees || !rcaScope || !improvePriority || !metricsReview || !lead || !approver){ showNotify('error','Incomplete Configuration','Please select all required dropdown and radio button options.'); return; } if(meetingTime !== 'Within 7 days' || meetingAttendees !== 'All CSIRT + stakeholders' || rcaScope.value !== 'full' || improvePriority.value !== 'all-equal' || metricsReview.value !== 'comprehensive' || lead !== 'Incident Manager' || approver !== 'CISO'){ showNotify('error','Incorrect Configuration','Post-incident review settings are incorrect. Review the Step 7 instructions carefully and verify all dropdown and radio button selections.'); return; } state.cism.postinc = true; markDone('cism', 6); document.getElementById('cism-post-status').innerHTML = 'Review process defined'; document.querySelectorAll('.modal').forEach(m=>m.remove()); document.getElementById('modal-overlay').classList.remove('active'); showNotify('success','Post-Incident Saved','Lessons learned and continuous improvement cycle established. Generate final plan.'); } function cismGeneratePlan(){ if(!state.cism.postinc){ showNotify('error','Incomplete Configuration','Complete all previous steps before generating plan.'); return; } markDone('cism', 7); generateIRPlanPDF(); } // ==================== LAB 18 MCQ VALIDATION ==================== if (!window.lab18MCQs) window.lab18MCQs = {q1: false, q2: false, q3: false}; function checkLab18Q1() { const selected = document.querySelector('input[name="cism-q1"]:checked'); const feedback = document.getElementById('cism-q1-feedback'); if(!selected) { showNotify('error','No Answer Selected','Please select an answer before submitting.'); return; } if(selected.value === 'b') { feedback.innerHTML = '
✓ Correct!
Preparation is the foundational phase per NIST SP 800-61. It includes: developing IR policies/procedures, establishing CSIRT, deploying monitoring tools, training staff, creating playbooks, and acquiring forensic tools. Without proper preparation, detection and response capabilities are severely degraded. CISM Domain 4 and CISSP Domain 7 heavily emphasize that preparation determines response effectiveness.
'; window.lab18MCQs.q1 = true; if(window.lab18MCQs.q1 && window.lab18MCQs.q2 && window.lab18MCQs.q3) markDone('cism', 8); } else { let explanation = ''; if(selected.value === 'a') explanation = 'Detection and Analysis comes AFTER preparation. You can\'t effectively detect/analyze without tools, procedures, and trained staff established during preparation.'; else if(selected.value === 'c') explanation = 'Containment is a reactive phase that occurs AFTER an incident is detected. Preparation happens proactively before incidents occur.'; else if(selected.value === 'd') explanation = 'Post-Incident Activity (Lessons Learned) occurs AFTER incident resolution. It improves future preparation but is not the initial preventive phase.'; feedback.innerHTML = `
✗ Incorrect
${explanation}

NIST IR Phases: 1) Preparation (proactive), 2) Detection & Analysis, 3) Containment/Eradication/Recovery, 4) Post-Incident Activity. Preparation is the only proactive phase.
`; } } function checkLab18Q2() { const selected = document.querySelector('input[name="cism-q2"]:checked'); const feedback = document.getElementById('cism-q2-feedback'); if(!selected) { showNotify('error','No Answer Selected','Please select an answer before submitting.'); return; } if(selected.value === 'b') { feedback.innerHTML = '
✓ Correct!
Accountable (A) means ultimate decision authority and approval power. There can be only ONE \'A\' per activity. The Accountable person doesn\'t do the work themselves—that\'s Responsible (R). In IR, the Incident Manager is typically Accountable for all phases, approving phase transitions and escalation decisions. CISM emphasizes clear accountability to prevent response paralysis.
'; window.lab18MCQs.q2 = true; if(window.lab18MCQs.q1 && window.lab18MCQs.q2 && window.lab18MCQs.q3) markDone('cism', 8); } else { let explanation = ''; if(selected.value === 'a') explanation = 'Responsible (R) means doing the actual work. Multiple people can be Responsible for different tasks, but only ONE can be Accountable with approval authority.'; else if(selected.value === 'c') explanation = 'Consulted (C) provides input/expertise before decisions are made but has no decision authority or accountability for outcomes.'; else if(selected.value === 'd') explanation = 'Informed (I) receives updates after decisions are made but has no input or accountability. They\'re kept in the loop only.'; feedback.innerHTML = `
✗ Incorrect
${explanation}

RACI Definitions: R = does work, A = approves (only one!), C = input before decision, I = informed after. The \'A\' is critical for clear decision authority.
`; } } function checkLab18Q3() { const selected = document.querySelector('input[name="cism-q3"]:checked'); const feedback = document.getElementById('cism-q3-feedback'); if(!selected) { showNotify('error','No Answer Selected','Please select an answer before submitting.'); return; } if(selected.value === 'c') { feedback.innerHTML = '
✓ Correct!
72 hours per GDPR Article 33. The clock starts when you become \'aware\' of a breach affecting personal data. Notification must include: nature of breach, categories/approximate number of affected individuals, likely consequences, measures taken/proposed, and DPO contact details. Failure to notify within 72 hours can result in fines up to €10 million or 2% of global turnover. CISM Domain 4 requires understanding regulatory notification timelines.
'; window.lab18MCQs.q3 = true; if(window.lab18MCQs.q1 && window.lab18MCQs.q2 && window.lab18MCQs.q3) markDone('cism', 8); } else { let explanation = ''; if(selected.value === 'a') explanation = '24 hours is too short. GDPR allows 72 hours. However, some regulations (like HIPAA for certain breaches) may require faster notification.'; else if(selected.value === 'b') explanation = '48 hours is close but incorrect. GDPR Article 33 specifically states 72 hours. Don\'t confuse with other regulations\' timelines.'; else if(selected.value === 'd') explanation = '7 days is far too long for GDPR. This may confuse with other regulations, but GDPR supervisory authority notification is 72 hours.'; feedback.innerHTML = `
✗ Incorrect
${explanation}

Regulatory Timelines: GDPR = 72 hours to authority, then to individuals \'without undue delay\'. HIPAA = 60 days. State laws vary (CA = \'without reasonable delay\'). Always verify current requirements!
`; } } function generateIRPlanPDF(){ const reportWindow = window.open('', '_blank'); const currentDate = new Date().toLocaleDateString('en-US', {year:'numeric', month:'long', day:'numeric'}); // Save PDF HTML to disk for review const reportHTML = ` Incident Response Plan - FinTech Corp | CertLabz.com
Incident Response Plan

🚨 Incident Response Plan

Enterprise Cybersecurity Incident Management Framework

Document Information

Organization: FinTech Corp

Plan Date: ${currentDate}

Version: 1.0

Document ID: IR-2024-${Math.random().toString(36).substr(2,6).toUpperCase()}

Framework & Standards

Primary: NIST SP 800-61 Rev. 2

Secondary: ISO 27035:2023

Classification: Confidential - Management Only

Prepared By: Information Security Manager

Executive Summary

🎯 IR Plan Overview

This Incident Response Plan establishes the framework for detecting, responding to, and recovering from cybersecurity incidents at FinTech Corp. The plan defines team structures, escalation procedures, communication protocols, and integration with business continuity operations per CISM Domain 4 and NIST guidelines.

  • CSIRT Team Structure: 5 core roles with RACI accountability matrix
  • Incident Classification: 4-tier severity system (P1-P4) with defined SLAs
  • Escalation Procedures: Executive notification triggers for critical incidents
  • Communication Protocols: Templates for internal/external stakeholder notifications
  • BCP Integration: Coordinated IR/BCP activation triggers with RTO/RPO
  • Continuous Improvement: Post-incident review and lessons learned process
5
CSIRT Roles
4
Severity Levels
15min
P1 Response SLA
4hr
RTO Target

1. CSIRT Team Structure

RoleResponsibilitiesRACI
Incident ManagerCoordinates all response activities, makes escalation decisions, ensures IR plan is followedAccountable (A)
Security AnalystPerforms triage, analyzes IOCs, determines scope, recommends containmentResponsible (R)
Forensics SpecialistHandles evidence collection, chain-of-custody, malware analysis, documentationResponsible (R)
Communications LeadManages internal/external communications, notifications, media statementsResponsible (R)
Legal CounselAdvises on regulatory obligations, reviews communications, manages breach notificationConsulted (C)

2. Incident Classification Matrix

SeverityExampleResponse SLANotification
P1-CriticalData breach (>10K records)15 minutesCISO + CEO
P2-HighMalware outbreak1 hourCISO
P3-MediumPhishing attempt (blocked)4 hoursSecurity Manager
P4-LowPolicy violation (minor)24 hoursTeam Lead
Escalation & Communications

3. Escalation Procedures

Incident TypeEscalation TeamTimeframe
Data Breach (>10K records)CISO + Legal + CEOImmediate
Ransomware (>$1M impact)CISO + CTO + BoardImmediate
Regulatory ViolationCISO + Compliance Officer + External CounselImmediate
P1 IncidentPer classification matrixImmediate (0 min)
P2 IncidentPer classification matrix1 hour

Escalation Decision Tree

Criteria for Executive Escalation:

4. Communication Protocols

Internal Alert Template (Detailed Level)

ElementContent
What HappenedBrief description of incident nature and scope
Containment StatusCurrent containment actions and effectiveness
User Actions RequiredSpecific steps employees must take
TimelineIncident timeline and expected resolution
Next StepsUpcoming response activities

Customer Notification (GDPR 72hr - Standard Level)

ElementContent
Impact DescriptionNature of breach and affected systems
Data AffectedCategories of personal data compromised
Remediation StepsActions taken and customer protection measures

Approval Workflows

5. BCP Integration

Incident TypeBCP Trigger ActionRecovery Objective
Ransomware (critical systems)Activate BCP, failover to DR siteRTO: 4 hours
Data Center BreachIR + BCP joint activationRPO: 1 hour

RTO/RPO Targets

Post-Incident & Approvals

6. Post-Incident Review Process

Lessons Learned Meeting

Root Cause Analysis Scope

Full Analysis includes:

Improvement Actions Priority

Equal priority given to:

Metrics to Review

Metric CategorySpecific Measurements
Response TimeTime from detection to containment
Detection GapTime from incident start to detection
Containment EffectivenessSpread prevention success rate
Cost ImpactDirect and indirect financial impact
Business ImpactDowntime, data loss, reputation damage

Review Responsibilities

7. Plan Maintenance & Testing

8. Compliance Alignment

This IR plan aligns with:

Approvals

Prepared By: Information Security Manager
Date: ${currentDate}
Approved By: Chief Information Security Officer
Date: _________________

This document requires CISO signature and annual Board review per CISM governance requirements.

Use your browser's Print function (Ctrl+P / Cmd+P) and select "Save as PDF"

Report generated by CertLabz.com CISM Lab

`; reportWindow.document.write(reportHTML); reportWindow.document.close(); // Save HTML to disk in cybersecurity folder const blob = new Blob([reportHTML], {type: 'text/html'}); const link = document.createElement('a'); link.href = URL.createObjectURL(blob); link.download = `IR_Plan_${new Date().toISOString().split('T')[0]}.html`; link.style.display = 'none'; document.body.appendChild(link); link.click(); setTimeout(() => { document.body.removeChild(link); URL.revokeObjectURL(link.href); }, 100); showNotify('success','IR Plan Generated','Comprehensive 3-page IR Plan opened in new tab AND downloaded to your Downloads folder. Use Print (Ctrl+P) to save as PDF.'); } function validateCISM(){ const st=state.cism; const scoring=document.getElementById('cism-scoring'); const tasks=['Define CSIRT team & RACI','Create classification matrix','Define escalation procedures','Establish communication protocols','Integrate with BCP','Define post-incident review','Generate IR plan','Answer all 3 MCQs correctly']; const completedIdx=st.completed.map(i=>i-1); const rem = tasks.filter((_,i)=>!completedIdx.includes(i)); let html = '
'; if(completedIdx.length>0){ html += ''; } if(rem.length>0){ html += ''; } if(rem.length===0){ html += ''; } html += '
'; scoring.innerHTML=html; } // ======= Reset ======= function resetLab(id){ if(id==='sec'){ state.sec={ total:8, completed:[], assets:{1:null,2:null,3:null}, treated:{1:false,2:false,3:false} }; document.getElementById('sec-risk1').textContent='-'; document.getElementById('sec-risk2').textContent='-'; document.getElementById('sec-risk3').textContent='-'; document.getElementById('sec-ale1').textContent='-'; document.getElementById('sec-ale2').textContent='-'; document.getElementById('sec-ale3').textContent='-'; ['sec-status1','sec-status2','sec-status3'].forEach(id=>document.getElementById(id).innerHTML='Not Assessed'); document.querySelectorAll('#sec-risks button').forEach(btn=>btn.outerHTML=''); window.lab16MCQs = {q1: false, q2: false, q3: false}; document.getElementById('sec-q1-feedback').innerHTML = ''; document.getElementById('sec-q2-feedback').innerHTML = ''; document.getElementById('sec-q3-feedback').innerHTML = ''; document.querySelectorAll('input[name="sec-q1"]').forEach(r => r.checked = false); document.querySelectorAll('input[name="sec-q2"]').forEach(r => r.checked = false); document.querySelectorAll('input[name="sec-q3"]').forEach(r => r.checked = false); document.getElementById('sec-scoring').innerHTML=''; updateProgress('sec'); } if(id==='cissp'){ state.cissp={ total:8, completed:[], index:0 }; document.getElementById('cissp-terminal-output').innerHTML='
CISSP IAM Lab Terminal\nType commands EXACTLY as shown. Order and spacing matter.
'; document.getElementById('cissp-scoring').innerHTML=''; updateProgress('cissp'); } if(id==='cism'){ state.cism={ total:8, completed:[], team:false, raci:false, classification:false, escalation:false, comms:false, bcp:false, postinc:false }; ['cism-team-status','cism-class-status','cism-esc-status','cism-comm-status','cism-bcp-status','cism-post-status'].forEach(id=>document.getElementById(id).textContent='Not configured'); document.querySelector('#cism-team-status').parentElement.querySelector('button').outerHTML = ''; window.lab18MCQs = {q1: false, q2: false, q3: false}; document.getElementById('cism-q1-feedback').innerHTML = ''; document.getElementById('cism-q2-feedback').innerHTML = ''; document.getElementById('cism-q3-feedback').innerHTML = ''; document.querySelectorAll('input[name="cism-q1"]').forEach(r => r.checked = false); document.querySelectorAll('input[name="cism-q2"]').forEach(r => r.checked = false); document.querySelectorAll('input[name="cism-q3"]').forEach(r => r.checked = false); document.getElementById('cism-scoring').innerHTML=''; updateProgress('cism'); } } // ======= Account Link ======= function goToAccount(){ var token=localStorage.getItem('authToken'); if(token){ window.location.href='/dashboard.html'; } else { window.location.href='/login.html'; } } // Init progress bars updateProgress('sec'); updateProgress('cissp'); updateProgress('cism'); // Make step-command and copiable-value elements copiable on click document.addEventListener('click', function(e){ if(e.target.classList.contains('step-command')){ const text = e.target.textContent.replace(/\s*📋\s*$/, '').trim(); navigator.clipboard.writeText(text).then(()=>{ const toast = document.createElement('div'); toast.className = 'copy-toast'; toast.textContent = 'Command copied!'; document.body.appendChild(toast); setTimeout(()=>toast.remove(), 2000); }); } if(e.target.classList.contains('copiable-value')){ const text = e.target.textContent.replace(/^📋\s*/, '').trim(); navigator.clipboard.writeText(text).then(()=>{ const toast = document.createElement('div'); toast.className = 'copy-toast'; toast.textContent = 'Value copied!'; document.body.appendChild(toast); setTimeout(()=>toast.remove(), 2000); }); } });