Hands-on CGRC, CISM, and ISSAP advanced scenarios with interactive GUIs, terminals, dashboards, and exact validation.
Advanced governance, risk management, security architecture scenarios with detailed instructions, tips, dynamic dashboards, exact validation, and safe reset.
Before selecting security controls, you must first categorize the system using FIPS 199 (Federal Information Processing Standard). This standard requires you to assess the potential impact if the system's confidentiality, integrity, or availability were compromised. For a Payment Processing System handling financial transactions and PII, a breach could result in significant financial loss, regulatory penalties, and reputational damage.
Why HIGH for all three:
Action: In the System Categorization panel, select Confidentiality: HIGH, Integrity: HIGH, Availability: HIGH, then click Submit Categorization.
NIST SP 800-53 defines three security control baselines (LOW, MODERATE, HIGH) that correspond to FIPS 199 categorization. Since our system is categorized as HIGH, we must select the HIGH baseline which includes 372 security controls across 20 control families. The HIGH baseline includes all controls from LOW and MODERATE plus additional controls for high-impact systems.
Control families included: Access Control (AC), Audit and Accountability (AU), Security Assessment (CA), Configuration Management (CM), Contingency Planning (CP), Identification and Authentication (IA), Incident Response (IR), Maintenance (MA), Media Protection (MP), Physical Protection (PE), Planning (PL), Personnel Security (PS), Risk Assessment (RA), System and Services Acquisition (SA), System and Communications Protection (SC), System and Information Integrity (SI), and more.
Action: Click Select Baseline, choose NIST 800-53 Rev 5 HIGH, then click Apply Baseline.
Gap analysis compares your current security posture against the required control baseline. For each of the 372 HIGH baseline controls, you must determine whether the control is: (1) Fully Implemented, (2) Partially Implemented, (3) Planned, or (4) Not Implemented. Controls that are not fully implemented represent compliance gaps that must be documented and remediated.
Common gaps in financial systems:
Action: Click Run Gap Analysis. The analysis will identify 12 non-compliant controls. You must review at least 3 gaps by checking the "Reviewed" checkbox to confirm you've analyzed the findings.
For each gap identified, you must assess the associated risk using NIST SP 800-30 (Guide for Conducting Risk Assessments). Risk is calculated as Likelihood × Impact. For the AC-2 MFA gap: the likelihood of credential theft is HIGH (phishing attacks are common), and the impact of compromised privileged accounts is HIGH (full system access). Therefore, the overall risk level is CRITICAL.
NIST 800-30 Risk Matrix:
Action: Click Assess Risks. For Control AC-2 (MFA gap), select Likelihood: HIGH, Impact: HIGH, Risk Level: CRITICAL.
The POA&M is a mandatory FISMA document that tracks identified weaknesses and planned corrective actions. For each gap, you must document: (1) the specific weakness, (2) resources required for remediation, (3) target completion date (milestone), and (4) responsible party. The milestone date should align with the risk level—CRITICAL risks require 30-day remediation.
POA&M for AC-2 (MFA Gap):
Action: Click Create POA&M. Select the appropriate options from each dropdown that match the AC-2 MFA weakness.
The System Security Plan (SSP) is the primary document describing your system's security posture. It consolidates all information from the RMF process: system description, categorization, control implementation status, risk assessment results, and POA&M. The SSP is required for ATO and must be updated whenever significant changes occur.
SSP Sections Generated:
Action: Click Generate SSP. The system will compile all documentation into a comprehensive SSP document.
The Authorization to Operate (ATO) is the formal decision by an Authorizing Official (AO) to accept the residual risk and permit the system to operate. The AO must be a senior official with authority to accept risk on behalf of the organization. For most organizations, this is the CISO. The ATO package includes the SSP, Security Assessment Report (SAR), and POA&M.
Why CISO as Authorizing Official:
ATO Decisions: Approve (full authorization), Deny (system cannot operate), or Conditional (operate with POA&M constraints). ATO validity is typically 1-3 years with continuous monitoring.
Action: Click Submit ATO Package. Select Authorizing Official: CISO, then click Submit.
After ATO submission, you must review the complete authorization package to understand what documentation is required for federal system authorization. The ATO package is a comprehensive collection of security documentation required by FISMA and NIST RMF that enables authorizing officials to make risk-based decisions.
ATO Package Components:
Action: Click View ATO Report in the Documentation panel to review the complete 6-page authorization package. Then click Download PDF to save a copy of the official ATO documentation.
📄 Download and carefully study the ATO report before answering these questions. These certification-level questions test your understanding of the ATO package documentation you just created.
Question 1 of 3: According to the ATO report's Executive Summary, what is the overall System Categorization for the Payment Processing System per FIPS 199?
Question 2 of 3: The Security Assessment Report (SAR) section identifies how many CRITICAL risk findings that require immediate remediation within 30 days?
Question 3 of 3: According to the POA&M section, what is the total estimated cost for remediating all identified security control deficiencies?
Complete system categorization first.
Select baseline to run gap analysis.
Complete gap analysis to assess risks.
Assess risks to create POA&M.
Complete POA&M to generate documentation.
🎯 Goal: Establish formal information security governance that defines decision-making authority, accountability, and reporting relationships across the organization.
💡 Why This Matters: Effective security governance ensures that security initiatives are aligned with business objectives and have executive support. Without proper governance, security becomes an afterthought rather than a strategic function. The governance structure determines who makes security decisions, who is accountable for security failures, and how security priorities are set and funded.
Action: Click Define Governance. Set Steering Committee: Board-level oversight, CISO Reports To: CIO, Security Council Frequency: Monthly. Click Establish Governance.
🎯 Goal: Create mandatory security policies that establish rules, expectations, and consequences for the entire organization.
💡 Why This Matters: Policies are the foundation of any security program—they translate security strategy into enforceable rules. Without written policies, there are no standards to enforce, no basis for disciplinary action, and no way to demonstrate due diligence to auditors or regulators. Policies also set employee expectations and provide legal protection for the organization.
Action: Click Create Policies. Select policy templates: Acceptable Use Policy, Data Classification Policy, Password Policy, Incident Response Policy. Set Review Cycle: Annual. Click Approve Policies.
🎯 Goal: Implement a structured methodology for identifying, assessing, and treating information security risks aligned with organizational risk appetite.
💡 Why This Matters: Risk management is the core of information security—you cannot protect everything equally, so you must prioritize based on risk. A formal risk framework ensures consistent assessment methodology, documented risk decisions, and alignment between security investments and actual threats. Without risk management, you either over-invest in low-risk areas or under-protect critical assets.
Action: Click Setup Risk Framework. Select Methodology: ISO 31000, Assessment Frequency: Quarterly, Risk Appetite: LOW (financial services). Click Initialize Framework.
🎯 Goal: Establish measurable leading indicators that provide early warning of increasing risk exposure before incidents occur.
💡 Why This Matters: KRIs are like early warning systems—they tell you when risk is increasing so you can act before an incident happens. Unlike KPIs which measure past performance, KRIs predict future problems. Effective KRIs enable proactive risk management rather than reactive firefighting, and they provide objective data for risk discussions with executives.
Action: Click Add KRIs. Enter: KRI 1: "Unpatched Critical Vulnerabilities > 30 days", Threshold: 5, KRI 2: "Failed Login Attempts > 10/hour", Threshold: 100, KRI 3: "Privileged Access Reviews Overdue", Threshold: 10%. Click Save KRIs.
🎯 Goal: Create a comprehensive incident response plan that defines roles, procedures, and timelines for detecting, containing, and recovering from security incidents.
💡 Why This Matters: Security incidents will happen—the question is how prepared you are to respond. A well-documented IRP reduces response time, minimizes damage, ensures consistent handling, and demonstrates due diligence to regulators. Without an IRP, incident response becomes chaotic, key steps are missed, and the organization suffers greater harm.
Action: Click Create IRP. Fill: CSIRT Lead: "Security Operations Manager", Escalation Path: "SOC ? Security Manager ? CISO ? CIO ? Board", SLA: Critical (1 hour), High (4 hours), Medium (24 hours). Click Approve IRP.
🎯 Goal: Develop business continuity and disaster recovery plans that ensure critical business functions can continue during and after disruptions.
💡 Why This Matters: Business continuity planning protects the organization from existential threats—ransomware, natural disasters, or infrastructure failures that could halt operations. The BCP ensures you can recover critical systems within acceptable timeframes and with acceptable data loss. Without BCP, an extended outage could result in revenue loss, regulatory penalties, and reputational damage.
Action: Click Create BCP. Set: RTO (Recovery Time Objective): 4 hours for critical systems, RPO (Recovery Point Objective): 1 hour data loss max, Backup Frequency: Hourly incremental, Daily full. Click Finalize BCP.
🎯 Goal: Establish metrics that measure security program effectiveness and present them to executive leadership through an actionable dashboard.
💡 Why This Matters: What gets measured gets managed—without metrics, you cannot demonstrate program value, justify budget requests, or identify areas needing improvement. Executive dashboards translate technical security data into business terms that leadership understands, enabling informed decision-making about security investments and priorities.
Action: Click Setup Dashboard. Select metrics: Risk Score Trend, Vulnerability Remediation Rate, Security Awareness Training Completion, Incident Response Time, Audit Findings Status. Set Report Frequency: Monthly. Click Generate Dashboard.
Define governance structure first.
Develop policies first.
Establish risk framework first.
Define KRIs first.
Create incident response plan first.
Finalize BCP to generate dashboard.
🎯 Goal: Confirm that nftables (the modern Linux packet filtering framework) is installed and ready for use.
💡 Why This Matters: Before configuring any firewall rules, you must verify that the required tools are present on the system. The nftables framework replaced the legacy iptables and provides a more consistent syntax for packet filtering. Checking the version confirms installation and ensures compatibility with the commands used in this lab.
Type exactly:
nft --versionnft — The nftables command-line utility for managing packet filtering rules--version — Flag that prints version information instead of executing any rule changes🎯 Goal: Create a dedicated nftables table to contain all Zero Trust firewall rules.
💡 Why This Matters: In nftables, all firewall rules are organized into tables. A table is a container that holds chains (which contain rules). By creating a separate table named "zt" for Zero Trust rules, you keep them isolated from any other firewall configurations on the system, making auditing, troubleshooting, and maintenance significantly easier.
Type exactly:
nft add table inet ztnft — The nftables command-line utility for managing packet filtering rulesadd table — Subcommand to create a new table in the nftables rulesetinet — Address family that handles both IPv4 and IPv6 traffic simultaneously (dual-stack)zt — The name we assign to this table (short for Zero Trust)🎯 Goal: Create an input chain that blocks all inbound traffic by default, implementing the Zero Trust "deny by default" principle.
💡 Why This Matters: Zero Trust Architecture fundamentally rejects the traditional "trust but verify" model. Instead, it implements "never trust, always verify." By setting the default policy to DROP, every inbound packet is blocked unless an explicit rule permits it. This is the opposite of legacy firewalls that often allow internal traffic freely.
Type exactly:
nft add chain inet zt input { type filter hook input priority 0; policy drop; }add chain — Creates a new chain within the specified tableinet zt input — Chain named "input" in the inet zt tabletype filter — This chain will filter packets (as opposed to NAT or route)hook input — Attaches to the kernel's input hook (incoming packets destined for local processes)priority 0 — Processing priority (0 is standard; lower numbers = higher priority)policy drop — Default action for packets not matching any rule: silently discard🎯 Goal: Create a forward chain that blocks all traffic passing through the system, preventing unauthorized lateral movement between network segments.
💡 Why This Matters: The forward chain controls traffic that passes through the system when it acts as a router or gateway between networks. In a Zero Trust architecture, blocking forwarded traffic by default is essential for micro-segmentation. If an attacker compromises one segment (e.g., DMZ web servers), they cannot automatically traverse to other segments (e.g., Database servers) without explicit authorization.
Type exactly:
nft add chain inet zt forward { type filter hook forward priority 0; policy drop; }add chain inet zt forward — Creates a chain named "forward" in our Zero Trust tablehook forward — Attaches to the kernel's forward hook (packets being routed through, not destined for local host)policy drop — Block all forwarded traffic by default, enforcing micro-segmentation🎯 Goal: Create an output chain that allows outbound traffic from local processes while enabling monitoring and logging.
💡 Why This Matters: The output chain controls traffic originating from processes running on this host. In this Zero Trust design, we allow outbound traffic by default (policy accept) because the host needs to initiate connections for updates, API calls, and legitimate business functions. However, all outbound traffic will be logged for monitoring and anomaly detection.
Type exactly:
nft add chain inet zt output { type filter hook output priority 0; policy accept; }add chain inet zt output — Creates a chain named "output" in our Zero Trust tablehook output — Attaches to the kernel's output hook (outgoing packets from local processes)policy accept — Allow outbound traffic by default (to be logged and monitored)🎯 Goal: Add a stateful rule that allows return traffic for connections initiated by this host, enabling legitimate responses while maintaining security.
💡 Why This Matters: Without this rule, the default-deny input policy would block ALL inbound traffic, including responses to connections you initiated (like DNS queries or HTTPS requests). Stateful packet inspection tracks connection states, allowing the firewall to distinguish between legitimate response traffic and unsolicited connection attempts.
Type exactly:
nft add rule inet zt input ct state established,related acceptadd rule — Adds a rule to an existing chaininet zt input — Target the input chain in our Zero Trust tablect state — Connection tracking state matcher (stateful inspection)established — Packets belonging to an already-established connectionrelated — Packets related to an existing connection (e.g., ICMP errors, FTP data channels)accept — Action: allow these packets through🎯 Goal: Create a named set to store IP address ranges representing our micro-segmented network zones.
💡 Why This Matters: Named sets in nftables allow you to group IP addresses or networks for efficient rule matching. Instead of writing separate rules for each network segment, you can reference the set in rules and manage segment membership centrally. This is essential for scalable micro-segmentation—when you add or remove network segments, you only update the set, not every rule.
Type exactly:
nft add set inet zt segments { type ipv4_addr; flags interval; }add set — Creates a named set within the tableinet zt segments — Set named "segments" in our Zero Trust tabletype ipv4_addr — Set contains IPv4 addressesflags interval — Allows CIDR notation ranges (e.g., 10.0.1.0/24) instead of individual IPs only🎯 Goal: Populate the segments set with three CIDR ranges representing our isolated network zones: DMZ, Application tier, and Database tier.
💡 Why This Matters: Each CIDR range represents a logically isolated network segment. The DMZ (10.0.1.0/24) hosts public-facing services like web servers, the Application tier (10.0.2.0/24) runs business logic and app servers, and the Database tier (10.0.3.0/24) stores sensitive data. By defining these segments explicitly, we can create precise rules that control exactly which segments can communicate with which.
Type exactly:
nft add element inet zt segments { ********/24, ********/24, ********/24 }add element — Adds entries to an existing setinet zt segments — Target the "segments" set in our Zero Trust table10.0.1.0/24 — DMZ segment (256 IPs for public-facing services)10.0.2.0/24 — Application segment (256 IPs for internal app servers)10.0.3.0/24 — Database segment (256 IPs for backend data stores)🎯 Goal: Display and verify the complete firewall ruleset to confirm all tables, chains, sets, and rules are configured correctly.
💡 Why This Matters: Before moving to policy configuration, you must verify that all nftables components are in place. This command displays the entire ruleset in a clean, readable format. If anything is missing or misconfigured, you'll see it here and can correct it before proceeding.
Type exactly:
nft -s list rulesetnft — The nftables command-line utility-s — Stateless output (omits runtime counters for cleaner display)list ruleset — Shows all tables, chains, sets, and rules in the systemZero Trust requires explicit authorization for every access request. Now we create a policy that allows only specific traffic: DMZ segment can communicate with App segment on TCP port 443 (HTTPS) only. All other traffic between segments remains blocked.
Why this configuration: The DMZ hosts public-facing web servers that need to communicate with backend application servers. By restricting to port 443 only, we ensure only HTTPS traffic is permitted—no SSH, no database ports, no other protocols.
Action: In the Policy Engine panel, configure:
DMZApp443/TCPThen click Apply Policy.
Zero Trust requires comprehensive logging of all access attempts for continuous verification and threat detection. Enable all telemetry options and set retention to 1 year to meet compliance requirements (SOC 2, HIPAA, PCI-DSS typically require 1 year minimum).
Why 1 year retention: Security investigations often require historical data. Ransomware attacks may not be detected for months. Compliance audits need evidence of controls over time. 1 year provides adequate forensic runway.
Action: In the Telemetry & Analytics panel:
Then click Activate Telemetry.
NIST Special Publication 800-207 defines the Zero Trust Architecture standard. Run an automated compliance check to verify your implementation meets all 7 ZTA tenets: verify explicitly, least privilege, assume breach, encrypt all traffic, continuous monitoring, dynamic policy, and comprehensive telemetry.
Why validation matters: Zero Trust is not a product but an architecture. Without validation, you may have gaps that create false confidence. Automated checks ensure all components are properly configured before production deployment.
Action: In the Architecture Validation panel, click Run ZT Compliance Check. Review results to confirm all 7 tenets pass. Then click Generate Architecture Report to document compliance.
Complete terminal configuration steps 1-9 first.
Configure policies first.
Enable telemetry first.