ISSEP — Information Systems Security Engineering Professional

1. Domain 1 — Systems Security Engineering / Kỹ thuật bảo mật hệ thống

1.1. SSE-CMM — Systems Security Engineering Capability Maturity Model

SSE-CMM (ISO/IEC 21827) định nghĩa 11 Security Process Areas (PA) tổ chức thành 3 nhóm: Engineering PAs (PA01-PA11) và 5 Capability Levels (0-5). Năm capability levels: 0 — Not Performed (không có evidence); 1 — Performed Informally (có thực hiện nhưng không có kế hoạch); 2 — Planned and Tracked (có kế hoạch, tài liệu, tracking); 3 — Well Defined (process được chuẩn hóa và tái sử dụng toàn tổ chức); 4 — Quantitatively Controlled (đo lường bằng metrics, kiểm soát bằng thống kê); 5 — Continuously Improving (cải tiến liên tục dựa trên measurement).

11 Security Process Areas của SSE-CMM: PA01 — Administer Security Controls; PA02 — Assess Impact; PA03 — Assess Security Risk; PA04 — Assess Threat; PA05 — Assess Vulnerability; PA06 — Build Assurance Argument; PA07 — Coordinate Security; PA08 — Monitor Security Posture; PA09 — Provide Security Input; PA10 — Specify Security Needs; PA11 — Verify and Validate Security. Mỗi PA có Base Practices (BP) — các hoạt động cụ thể phải được evidence để claim capability level.

1.2. NIST SP 800-160 Vol.1 & Vol.2 — Systems Security Engineering

NIST SP 800-160 Vol.1 (Systems Security Engineering — Considerations for a Multidisciplinary Approach) định nghĩa security engineering như một multidisciplinary activity tích hợp vào systems engineering lifecycle. Framework gồm 3 phần: Systems Engineering Processes (hơn 30 processes từ ISO/IEC/IEEE 15288), Systems Security Engineering Processes (security-specific processes), và Systems Security Engineering Considerations (principles và concepts). Key principle: security không phải là tính năng thêm vào — phải là emergent property của toàn bộ system.

NIST SP 800-160 Vol.2 (Developing Cyber Resilient Systems) mở rộng Vol.1 với tập trung vào cyber resiliency — khả năng anticipate, withstand, recover từ và adapt sau các adverse conditions. Định nghĩa 4 goals: Anticipate (dự đoán adversary actions), Withstand (chịu đựng attacks), Recover (khôi phục sau incident), Adapt (thay đổi để giảm exposure). 14 Cyber Resiliency Techniques được map vào NIST CSF functions và MITRE ATT&CK framework.

1.3. Engineering Trustworthiness — Trade-off Analysis

Trustworthy systems phải thỏa mãn 5 properties đồng thời, và security engineer phải quản lý trade-offs giữa chúng: Reliability (hệ thống hoạt động đúng theo spec dưới normal conditions) ↔ Safety (hệ thống không gây harm dù có failures) ↔ Security (hệ thống bảo vệ tính bí mật, toàn vẹn, sẵn sàng trước adversarial threats) ↔ Survivability (hệ thống duy trì critical functions khi bị tấn công) ↔ Privacy (hệ thống bảo vệ cá nhân thông tin nhạy cảm).

Trade-off ví dụ điển hình: Security vs. Availability — tăng authentication strength (MFA, certificate) tăng security nhưng có thể giảm availability (lockout risk, certificate expiry). Security vs. Safety — hệ thống safety-critical (ví dụ nhà máy điện) có thể require override authentication khi có emergency — security control không được block safety response. Engineer phải document trade-off decisions trong Architecture Trade-off Analysis Method (ATAM) records.

2. Domain 2 — Application of Risk Management / Ứng dụng quản lý rủi ro

2.1. FAIR — Factor Analysis of Information Risk

FAIR (Factor Analysis of Information Risk) là tiêu chuẩn quốc tế duy nhất (Open Group Standard) cho quantitative information risk analysis. FAIR model phân tích risk thành: Risk = Probable Frequency × Probable Magnitude. Hai component chính: Loss Event Frequency (LEF) — tần suất xảy ra sự kiện tổn thất, và Probable Loss Magnitude (PLM) — giá trị tổn thất kỳ vọng.

LEF được phân tích thành: Threat Event Frequency (TEF) × Vulnerability. Trong đó TEF = Contact Frequency × Probability of Action, và Vulnerability = Probability of Action Success = Threat Capability / Control Strength. PLM phân tích thành 6 loss forms: Productivity, Response, Replacement, Fines & Judgments, Competitive Advantage, Reputation.

FAIR sử dụng Monte Carlo Simulation để tính distribution của risk thay vì single-point estimate. Mỗi input được định nghĩa bằng probability distribution (ví dụ minimum/most-likely/maximum) → simulation chạy 10.000-100.000 iterations → output là loss exceedance curve cho thấy "có X% khả năng tổn thất vượt quá Y triệu USD." Đây là ngôn ngữ mà Board và CFO hiểu — thay vì "Red/Yellow/Green" qualitative ratings.

2.2. Security Requirements Engineering

KAOS (Keep All Objectives Satisfied) là goal-oriented requirements engineering methodology áp dụng cho security requirements. KAOS phân tích từ high-level goals (ví dụ "Bảo vệ dữ liệu khách hàng") xuống operationalizable requirements thông qua refinement. Mỗi goal có thể bị obstructed bởi threats (anti-goals) — kết quả là security counter-requirements để mitigate threats.

SysML Security Extensions: SysML (Systems Modeling Language) được dùng để model security requirements trong systems engineering context. Block Definition Diagrams (BDD) model security components và their relationships; Use Case Diagrams thêm «threat» và «mitigation» stereotypes; Sequence Diagrams model attack scenarios và detection responses. Traceability từ security requirements lên threat model và xuống implementation là bắt buộc trong high-assurance systems.

2.3. Verification & Validation — Security Test and Evaluation (ST&E)

ST&E (Security Test and Evaluation) là quá trình kiểm tra và đánh giá security controls trước khi hệ thống được authorize. Gồm 3 activities: (1) Security Control Assessment — kiểm tra từng control theo NIST SP 800-53A (interview, examine, test). (2) Penetration Testing — simulated attacks để identify vulnerabilities không được phát hiện bởi control assessment. (3) Security Review — code review, configuration review, documentation review.

IV&V (Independent Verification and Validation) yêu cầu third-party thực hiện V&V — không phải developer hoặc system owner. Trong high-assurance systems (ví dụ hệ thống defense, hạt nhân), IV&V là bắt buộc. IV&V organization phải organizationally independent — không báo cáo cho project manager mà báo cáo cho program manager hoặc higher authority.

3. Domain 3 — Technical Management / Quản lý kỹ thuật

3.1. Configuration Management for Security

Configuration Management (CM) trong security context là kiểm soát thay đổi đối với system components để ngăn security degradation. CM Plan phải định nghĩa: CM scope (hardware, software, firmware, documentation), Baseline Management (security baseline được document và protected), Change Control Board (CCB) process — mọi change phải có security impact assessment trước khi approved.

Security Baseline Management: Mỗi system type có security baseline document (ví dụ "Windows Server 2022 Security Baseline v2.0") định nghĩa exact configuration của tất cả security-relevant settings. Baseline được lưu trong Configuration Management Database (CMDB). Khi baseline bị drift (ví dụ admin thay đổi setting), phải được detected (bằng SCAP/OpenSCAP scan, AWS Config, Azure Policy) và either justified hoặc remediated. Configuration drift là một trong những leading causes của security incidents.

3.2. Security Engineering Measurement — GQM

GQM (Goal-Question-Metric) methodology áp dụng cho security metrics: (1) Define Goal — ví dụ "Giảm mean time to detect (MTTD) xuống dưới 4 giờ". (2) Derive Questions — "Hiện tại MTTD là bao nhiêu?", "Tỷ lệ alert noise là bao nhiêu?", "SIEM rule coverage rate là bao nhiêu?". (3) Identify Metrics để trả lời từng question — MTTD, false positive rate, percentage of ATT&CK techniques covered by detection rules.

Security metrics dashboard cho C-suite phải thể hiện: Risk Posture (trend của risk score theo thời gian), Vulnerability Management (Mean Time to Remediate critical vulns), Incident Metrics (MTTD, MTTR, incidents per month by severity), Compliance (percentage controls passing assessment), Asset Coverage (% assets với EDR agent, % với current patches).

3.3. Supply Chain Risk Management (SCRM) & CMMC

SCRM (Supply Chain Risk Management) theo NIST SP 800-161r1: identify, assess, và mitigate risks arising từ global and distributed supply chains. Key risks: counterfeit components, malicious code insertion, unauthorized production, theft, tampering. Countermeasures: approved vendor list, hardware Bill of Materials (BoM) verification, firmware integrity checking, trusted foundry program.

CMMC (Cybersecurity Maturity Model Certification) v2.0 gồm 3 levels: Level 1 — Foundational (17 practices, FAR 52.204-21, annual self-assessment); Level 2 — Advanced (110 practices = NIST SP 800-171, triennial third-party assessment C3PAO); Level 3 — Expert (110+ practices, NIST SP 800-172, government-led assessment). Defense contractors xử lý CUI (Controlled Unclassified Information) phải đạt ít nhất Level 2. Hardware BoM analysis là yêu cầu của CMMC Level 2 Practice SR.1.001 (Supply Chain Risk Management).

4. Domain 4 — U.S. Government Information Assurance Regulations / Quy định IA chính phủ Mỹ

4.1. NIST RMF — Risk Management Framework 7-Step Process

NIST SP 800-37 Rev.2 định nghĩa RMF gồm 7 steps (thêm "Prepare" so với phiên bản cũ 6-step):

• Step 1 — Prepare: Thiết lập context và priorities: assign roles (AO, ISSO, ISSM), identify common controls (inheritable từ organization), establish risk tolerance. Outputs: Organization-level risk strategy, Mission/Business Process definitions.
• Step 2 — Categorize: Phân loại thông tin và hệ thống theo FIPS 199 (Low/Moderate/High cho CIA). Ví dụ: hệ thống xử lý PII có thể là Moderate-Moderate-Low (Confidentiality=M, Integrity=M, Availability=L). Overall classification = highest water mark.
• Step 3 — Select: Chọn security controls từ NIST SP 800-53 Rev.5 baseline tương ứng với FIPS 199 category. Moderate baseline có ~325 controls. Tailoring: bổ sung controls dựa trên threat environment, loại bỏ controls không applicable, thêm compensating controls.
• Step 4 — Implement: Triển khai security controls và document implementation. Outputs: System Security Plan (SSP) — document mô tả system, boundaries, và implementation của mọi selected control. SSP là body of evidence chính cho authorization.
• Step 5 — Assess: Security Control Assessors (SCAs) — independent khỏi system owner — đánh giá controls theo SP 800-53A assessment procedures. Ba phương pháp: Interview, Examine, Test. Kết quả: Security Assessment Report (SAR) liệt kê findings.
• Step 6 — Authorize: Authorizing Official (AO) — senior manager chịu trách nhiệm — review SSP, SAR, và Plan of Action & Milestones (POA&M), sau đó ra quyết định: Authorization to Operate (ATO), Denial of Authorization to Operate (DATO), hoặc Interim ATO với conditions.
• Step 7 — Monitor: Continuous monitoring: ongoing assessment of controls, configuration management, incident response, status reporting. Mỗi tháng report lên AO và CISO. Trigger re-authorization nếu có significant change.

4.2. FedRAMP — Federal Risk and Authorization Management Program

FedRAMP chuẩn hóa security authorization cho cloud services bán cho U.S. federal government. Ba authorization paths: (1) Joint Authorization Board (JAB) — P-ATO từ DoD/DHS/GSA, cho CSPs muốn serve nhiều agencies; (2) Agency Authorization — specific agency authorize CSP cho their use; (3) CSP-Supplied (discontinued). FedRAMP baselines: Low (125 controls), Moderate (325+ controls — phổ biến nhất), High (421 controls — cho high-impact data như law enforcement, emergency services).

FedRAMP Continuous Monitoring (ConMon): Sau khi có ATO/P-ATO, CSP phải: monthly vulnerability scanning (OS và web app), monthly reporting lên authorizing agency/JAB, annual security assessment của subset of controls, incident reporting trong 1 giờ với follow-up trong 72 giờ. Significant changes (ví dụ new service, new data center region) phải trigger Significant Change Request (SCR) review.

4.3. FISMA & STIG Compliance

FISMA (Federal Information Security Modernization Act) yêu cầu tất cả federal agencies implement information security program. CISO phải báo cáo hàng năm lên OMB qua CyberScope. POA&M (Plan of Action & Milestones) phải maintain cho tất cả open findings — track remediation progress, responsible party, estimated completion date. FISMA metrics bao gồm: % systems với current ATO, % high/critical vulnerabilities remediated trong 30 ngày, % users hoàn thành security awareness training.

STIG (Security Technical Implementation Guide) — DISA publish STIGs cho hàng trăm technology products (OS, network devices, applications). Mỗi STIG chứa security requirements được organize theo severity: Category I (CAT I / High) — nếu không fix sẽ directly enable privileged access hoặc complete compromise; CAT II (Medium) — directly enable unauthorized access; CAT III (Low) — reduce defense-in-depth. SRG (Security Requirements Guide) là parent document cho STIGs — SRG áp dụng cho một category (ví dụ "OS SRG"), STIG áp dụng cho specific product (ví dụ "Red Hat Enterprise Linux 9 STIG").

SCAP (Security Content Automation Protocol) là collection of specifications cho automated security checking: XCCDF (Extensible Configuration Checklist Description Format) — machine-readable checklist format; OVAL (Open Vulnerability and Assessment Language) — test conditions; CVE, CCE, CPE — naming identifiers. OpenSCAP (open-source) sử dụng SCAP content để scan systems và generate compliance reports.

5. Domain 5 — System Certification & Accreditation / Chứng nhận và công nhận hệ thống

5.1. Common Criteria — ISO 15408 & EAL Levels

Common Criteria (CC / ISO 15408) là tiêu chuẩn quốc tế để đánh giá tính bảo mật của IT products. Hai key documents: Protection Profile (PP) — document mô tả security requirements cho một category of product (ví dụ "Firewall PP") mà không refer đến specific implementation; Security Target (ST) — document của vendor mô tả security claims của specific product, referencing một hoặc nhiều PPs.

Evaluation Assurance Levels (EAL) 1-7 thể hiện độ sâu của evaluation, không phải security strength: EAL1 (Functionally Tested) — minimal testing; EAL2 (Structurally Tested) — vulnerability analysis; EAL3 (Methodically Tested and Checked) — thorough searching for vulnerabilities; EAL4 (Methodically Designed, Tested and Reviewed) — most common commercial level — đủ để justify existing products; EAL5 (Semiformally Designed and Tested) — semiformal design representation; EAL6 (Semiformally Verified Design) — rigorous development; EAL7 (Formally Verified Design) — full formal verification — chỉ achievable cho simple, well-defined products.

5.2. Security Assessment & Authorization (SA&A) — Body of Evidence

Body of Evidence (BoE) cho SA&A gồm: System Security Plan (SSP) (mô tả system và controls, template từ NIST SP 800-18), Security Assessment Report (SAR) (findings từ assessors), Plan of Action & Milestones (POA&M) (remediation plan cho open findings), Hardware/Software Inventory, Network Topology Diagrams, Data Flow Diagrams, Interconnection Security Agreements (ISAs) (cho connected external systems), Privacy Impact Assessment (PIA) (nếu system xử lý PII).

Continuous Authorization to Operate (cATO): Thay vì authorization point-in-time mỗi 3 năm, cATO duy trì authorization liên tục thông qua automated continuous monitoring, real-time dashboards, và defined thresholds. DoD đã adopt cATO trong DevSecOps pipelines — mỗi deployment phải pass automated security checks trước khi promote to production.

5.3. Penetration Testing for Certification

Rules of Engagement (ROE) cho penetration testing trong certification context phải định nghĩa rõ: (1) Scope — IP ranges, applications, excluded targets (ví dụ production DB không được test destructive attacks); (2) Test window — date/time ranges; (3) Authorized techniques — phân biệt reconnaissance, scanning, exploitation, post-exploitation; (4) Emergency contacts — khi nào phải stop và notify; (5) Evidence handling — cách lưu trữ và xử lý artifacts.

Findings Classification trong certification pentest: phân biệt Confirmed Vulnerabilities (đã successfully exploit) vs. Potential Vulnerabilities (discovered nhưng not exploited) vs. Informational Findings (weak practices không có immediate exploit path). Mỗi finding phải map về CVE/CWE, CVSS score, affected controls trong SSP, và recommended remediation with evidence of fix.

6. Bài thực hành / Hands-on labs

Lab 1 — STIG Compliance Scan với OpenSCAP trên Ubuntu 22.04

OS: Ubuntu 22.04 LTS · Tool: openscap-scanner, scap-security-guide. Mục tiêu: Scan hệ thống theo Ubuntu 22.04 STIG và phân tích findings.

1. Cài đặt OpenSCAP và SCAP Security Guide:

   sudo apt update
   sudo apt install -y openscap-scanner ssg-base ssg-debderived
   
   # Kiểm tra SCAP content có sẵn
   ls /usr/share/xml/scap/ssg/content/ | grep ubuntu
   # Expected: ssg-ubuntu2204-ds.xml (DataStream file)

2. Liệt kê các profile có sẵn trong Ubuntu 22.04 content:

   oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml \
     | grep -A 1 "Profiles:"
   
   # Hoặc list profiles chi tiết
   oscap info --profile "" /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml 2>&1 | \
     grep "Profile:" | head -20

3. Chạy scan với profile CIS Benchmark Level 1:

   # Chạy XCCDF evaluation với CIS Level 1 profile
   sudo oscap xccdf eval \
     --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
     --results /tmp/scan-results.xml \
     --report /tmp/scan-report.html \
     /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
   
   echo "Scan complete. Report saved to /tmp/scan-report.html"

4. Phân tích kết quả scan:

   # Đếm pass/fail/error
   oscap xccdf generate report /tmp/scan-results.xml | grep -E "pass|fail" | wc -l
   
   # Lấy danh sách FAILED rules (top 20)
   oscap xccdf export-oval-variables \
     /tmp/scan-results.xml 2>/dev/null || true
   
   # Parse kết quả bằng xmllint
   sudo apt install -y libxml2-utils
   xmllint --xpath "//result[text()='fail']/../@idref" \
     /tmp/scan-results.xml 2>/dev/null | \
     tr ' ' '\n' | head -20
   
   # Xem HTML report trong browser
   python3 -m http.server 8080 --directory /tmp &
   echo "Open http://localhost:8080/scan-report.html"

Lab 2 — Tạo System Security Plan (SSP) theo NIST SP 800-18

OS: Ubuntu 22.04 · Tool: Bash + Python 3. Mục tiêu: Generate SSP template với thông tin hệ thống thực tế được tự động collect.

1. Tạo script collect system info cho SSP:

   cat > /tmp/generate-ssp.py <<'PYTHON'
   #!/usr/bin/env python3
   """Generate System Security Plan template per NIST SP 800-18"""
   import subprocess, socket, datetime, platform
   
   def run(cmd):
       try:
           return subprocess.check_output(cmd, shell=True, stderr=subprocess.DEVNULL).decode().strip()
       except:
           return "N/A"
   
   hostname = socket.gethostname()
   ip = socket.gethostbyname(hostname)
   os_info = platform.platform()
   kernel = run("uname -r")
   cpu_count = run("nproc")
   ram_gb = run("free -g | awk '/^Mem/{print $2}'")
   disk = run("df -h / | awk 'NR==2{print $2}'")
   open_ports = run("ss -tlnp | awk 'NR>1{print $4}' | cut -d: -f2 | sort -u | tr '\n' ','")
   running_services = run("systemctl list-units --type=service --state=running --no-pager --no-legend | awk '{print $1}' | head -10 | tr '\n' ', '")
   date = datetime.date.today().isoformat()
   
   ssp = f"""# SYSTEM SECURITY PLAN (SSP)
   # Per NIST SP 800-18 Rev.1 — Guide for Developing Security Plans
   
   ## Section 1: System Identification
   | Field | Value |
   |-------|-------|
   | System Name | {hostname} Lab System |
   | System Abbreviation | HTLAB-SYS-01 |
   | System Owner | Trần Văn Hòa (MCT) |
   | System Owner Email | [email protected] |
   | ISSO Name | [Assign ISSO] |
   | Authorizing Official | [Assign AO] |
   | Assignment Date | {date} |
   
   ## Section 2: System Categorization (per FIPS 199)
   | Security Objective | Impact Level | Justification |
   |-------------------|--------------|---------------|
   | Confidentiality | Moderate | System processes internal training data |
   | Integrity | Moderate | Training content integrity required for accuracy |
   | Availability | Low | Downtime of <8 hours acceptable |
   | **Overall Categorization** | **MODERATE** | Highest water mark |
   
   ## Section 3: System Description
   | Component | Detail |
   |-----------|--------|
   | Operating System | {os_info} |
   | Kernel Version | {kernel} |
   | Hostname / IP | {hostname} / {ip} |
   | vCPUs | {cpu_count} |
   | RAM | {ram_gb} GB |
   | Storage (/) | {disk} |
   | Open Listening Ports | {open_ports} |
   | Running Services (sample) | {running_services} |
   
   ## Section 4: System Environment & Authorization Boundary
   The system boundary includes: this Ubuntu 22.04 server, its local storage, and all processes
   running on the OS. External connections: Internet access via ISP NAT. Cloud services used: None.
   
   ## Section 5: Security Control Implementation (NIST SP 800-53 Rev.5 — Moderate Baseline)
   | Control ID | Control Name | Implementation Status | Implementation Description |
   |------------|--------------|----------------------|---------------------------|
   | AC-2 | Account Management | Implemented | Local user accounts managed via adduser/usermod |
   | AU-2 | Event Logging | Partially Implemented | auditd installed; rules need review |
   | CM-6 | Configuration Settings | Planned | OpenSCAP CIS scan scheduled |
   | IA-5 | Authenticator Management | Implemented | Password policy via PAM |
   | SC-28 | Protection of Info at Rest | Not Implemented | Full disk encryption not configured |
   | SI-2 | Flaw Remediation | Implemented | unattended-upgrades enabled for security updates |
   
   ## Section 6: Plan of Action & Milestones (POA&M)
   | Finding ID | Finding Description | Risk Level | Responsible Party | Target Date |
   |-----------|---------------------|-----------|------------------|------------|
   | POA-001 | Full disk encryption not implemented (SC-28) | High | System Owner | 2026-07-01 |
   | POA-002 | Audit rules incomplete (AU-2) | Medium | ISSO | 2026-06-15 |
   
   ---
   *Generated: {date} | Template per NIST SP 800-18 Rev.1*
   """
   
   with open("/tmp/system-security-plan.md", "w") as f:
       f.write(ssp)
   print("SSP generated: /tmp/system-security-plan.md")
   print(f"Lines: {len(ssp.splitlines())}")
   PYTHON
   
   python3 /tmp/generate-ssp.py

2. Xem SSP được tạo:

   cat /tmp/system-security-plan.md

Lab 3 — FAIR Quantitative Risk Analysis bằng Python (pyfair)

OS: Ubuntu 22.04 · Tool: Python 3.11, pyfair library. Mục tiêu: Thực hiện FAIR analysis cho scenario ransomware tấn công hệ thống HR.

1. Cài đặt pyfair:

   pip3 install pyfair matplotlib --quiet
   python3 -c "import pyfair; print(f'pyfair version: {pyfair.__version__}')"

2. Tạo và chạy FAIR risk analysis:

   cat > /tmp/fair-analysis.py <<'PYTHON'
   #!/usr/bin/env python3
   """FAIR Quantitative Risk Analysis - Ransomware Scenario"""
   import pyfair
   from pyfair.model import FairModel
   from pyfair.report import FairSimpleReport
   import matplotlib
   matplotlib.use('Agg')  # Non-interactive backend
   import matplotlib.pyplot as plt
   import numpy as np
   
   # === SCENARIO: Ransomware attack on HR System ===
   # Organization: 500-employee company | System: HR database (2,000 employee records)
   
   model = FairModel(name="Ransomware - HR System", n_simulations=50_000)
   
   # Threat Event Frequency: how often attacker attempts attack
   # Min=1 per year, Mode=4 (quarterly), Max=12 (monthly)
   model.input_data('Threat Event Frequency', low=1, mode=4, high=12)
   
   # Vulnerability: probability attacker succeeds (0-1)
   # Without EDR and email filtering: low=0.2, mode=0.4, high=0.7
   model.input_data('Vulnerability', low=0.2, mode=0.4, high=0.7)
   
   # Primary Loss Magnitude: direct financial impact per event (USD)
   # Incident response + recovery: min $50k, most-likely $200k, max $800k
   model.input_data('Primary Loss Magnitude', low=50_000, mode=200_000, high=800_000)
   
   # Secondary Loss Event Frequency (regulatory fine, reputation)
   model.input_data('Secondary Loss Event Frequency', low=0.1, mode=0.3, high=0.6)
   
   # Secondary Loss Magnitude (GDPR fine + PR cost)
   model.input_data('Secondary Loss Magnitude', low=20_000, mode=100_000, high=500_000)
   
   # Calculate
   model.calculate_all()
   
   # Extract results
   results = model.export_results()
   risk_values = results['Risk']
   
   # Statistics
   percentile_10 = np.percentile(risk_values, 10)
   percentile_50 = np.percentile(risk_values, 50)  # Median
   percentile_90 = np.percentile(risk_values, 90)
   percentile_95 = np.percentile(risk_values, 95)
   
   print("=" * 60)
   print("FAIR RISK ANALYSIS RESULTS — Ransomware HR System")
   print("=" * 60)
   print(f"Simulations run:        50,000")
   print(f"10th percentile (best): ${percentile_10:>12,.0f} / year")
   print(f"50th percentile (median):${percentile_50:>11,.0f} / year")
   print(f"90th percentile:        ${percentile_90:>12,.0f} / year")
   print(f"95th percentile (worst):${percentile_95:>12,.0f} / year")
   print()
   print("RISK INTERPRETATION:")
   print(f"  There is a 90% probability that annual loss will be")
   print(f"  below ${percentile_90:,.0f}.")
   print(f"  Median expected annual loss: ${percentile_50:,.0f}")
   print()
   
   # Plot loss exceedance curve
   fig, ax = plt.subplots(figsize=(10, 6))
   sorted_risk = np.sort(risk_values)[::-1]
   exceedance_prob = np.arange(1, len(sorted_risk)+1) / len(sorted_risk)
   ax.plot(sorted_risk/1000, exceedance_prob * 100, color='#6366f1', linewidth=2)
   ax.axhline(y=10, color='red', linestyle='--', alpha=0.7, label=f'10% exceedance = ${percentile_90/1000:.0f}K')
   ax.set_xlabel('Annual Loss (USD Thousands)', fontsize=12)
   ax.set_ylabel('Probability of Exceedance (%)', fontsize=12)
   ax.set_title('FAIR Loss Exceedance Curve — Ransomware HR System', fontsize=13, fontweight='bold')
   ax.legend()
   ax.grid(True, alpha=0.3)
   plt.tight_layout()
   plt.savefig('/tmp/fair-loss-exceedance.png', dpi=150, bbox_inches='tight')
   print("Chart saved: /tmp/fair-loss-exceedance.png")
   PYTHON
   
   python3 /tmp/fair-analysis.py

Lab 4 — Tạo Security Requirements Traceability Matrix từ Threat Model

OS: Ubuntu 22.04 · Tool: Python 3. Mục tiêu: Tạo Requirements Traceability Matrix (RTM) ánh xạ từ STRIDE threats → security requirements → NIST SP 800-53 controls → test cases.

1. Tạo RTM generator:

   cat > /tmp/security-rtm.py <<'PYTHON'
   #!/usr/bin/env python3
   """Security Requirements Traceability Matrix Generator"""
   
   # RTM: STRIDE Threat → Security Requirement → NIST Control → Test Case
   rtm_data = [
       {
           "threat_id": "T-001",
           "stride": "Spoofing",
           "threat_desc": "Attacker impersonates legitimate user via stolen credentials",
           "req_id": "SR-001",
           "security_req": "System SHALL enforce multi-factor authentication for all user logins",
           "nist_control": "IA-2(1), IA-2(2)",
           "test_id": "TC-001",
           "test_case": "Verify login fails with correct password but no MFA token",
           "status": "Implemented"
       },
       {
           "threat_id": "T-002",
           "stride": "Tampering",
           "threat_desc": "Attacker modifies log records to cover tracks",
           "req_id": "SR-002",
           "security_req": "System SHALL ensure audit logs are write-once and tamper-evident",
           "nist_control": "AU-9, AU-9(2)",
           "test_id": "TC-002",
           "test_case": "Verify audit user cannot delete/modify log entries; logs have integrity hash",
           "status": "Partially Implemented"
       },
       {
           "threat_id": "T-003",
           "stride": "Repudiation",
           "threat_desc": "User denies performing privileged action",
           "req_id": "SR-003",
           "security_req": "System SHALL log all privileged actions with user identity, timestamp, and action detail",
           "nist_control": "AU-2, AU-3, AU-12",
           "test_id": "TC-003",
           "test_case": "Perform privileged action and verify audit log contains user, time, action, outcome",
           "status": "Implemented"
       },
       {
           "threat_id": "T-004",
           "stride": "Information Disclosure",
           "threat_desc": "Unauthorized access to PII in HR database",
           "req_id": "SR-004",
           "security_req": "System SHALL encrypt PII data at rest using AES-256-GCM and enforce column-level access control",
           "nist_control": "SC-28, AC-3(7)",
           "test_id": "TC-004",
           "test_case": "Verify database files are encrypted; low-privilege user cannot SELECT PII columns",
           "status": "Not Implemented"
       },
       {
           "threat_id": "T-005",
           "stride": "Denial of Service",
           "threat_desc": "Flood of authentication requests locks out legitimate users",
           "req_id": "SR-005",
           "security_req": "System SHALL implement rate limiting: max 5 failed login attempts per 15 minutes per account",
           "nist_control": "AC-7, SI-10",
           "test_id": "TC-005",
           "test_case": "Send 6 failed logins in 15 min → verify account locked and alert generated",
           "status": "Implemented"
       },
       {
           "threat_id": "T-006",
           "stride": "Elevation of Privilege",
           "threat_desc": "Low-privilege user exploits API to gain admin functions",
           "req_id": "SR-006",
           "security_req": "System SHALL enforce server-side authorization for every API endpoint; client-supplied roles SHALL NOT be trusted",
           "nist_control": "AC-3, AC-6",
           "test_id": "TC-006",
           "test_case": "Attempt to call admin API with regular user token → verify 403 Forbidden returned",
           "status": "Implemented"
       },
   ]
   
   print("=" * 110)
   print(f"{'SECURITY REQUIREMENTS TRACEABILITY MATRIX':^110}")
   print(f"{'System: HR Management System | Version: 1.0 | Date: 2026-05-24':^110}")
   print("=" * 110)
   print(f"{'T-ID':<8} {'STRIDE':<22} {'Req-ID':<8} {'NIST Control':<18} {'TC-ID':<8} {'Status':<22}")
   print("-" * 110)
   for row in rtm_data:
       print(f"{row['threat_id']:<8} {row['stride']:<22} {row['req_id']:<8} {row['nist_control']:<18} {row['test_id']:<8} {row['status']:<22}")
   
   # Summary stats
   total = len(rtm_data)
   impl = sum(1 for r in rtm_data if r['status'] == 'Implemented')
   partial = sum(1 for r in rtm_data if r['status'] == 'Partially Implemented')
   not_impl = sum(1 for r in rtm_data if r['status'] == 'Not Implemented')
   
   print("=" * 110)
   print(f"\nSUMMARY: {total} requirements | Implemented: {impl} ({impl/total*100:.0f}%) | Partial: {partial} | Not Implemented: {not_impl}")
   print(f"Coverage: STRIDE all 6 categories covered | NIST SP 800-53 controls: {len(set(c for r in rtm_data for c in r['nist_control'].split(',')))} unique controls")
   
   # Save as markdown
   with open("/tmp/security-rtm.md", "w") as f:
       f.write("# Security Requirements Traceability Matrix\n\n")
       f.write("| T-ID | STRIDE | Threat | Req-ID | Security Requirement | NIST Control | TC-ID | Status |\n")
       f.write("|------|--------|--------|--------|---------------------|--------------|-------|--------|\n")
       for row in rtm_data:
           f.write(f"| {row['threat_id']} | {row['stride']} | {row['threat_desc'][:40]}... | {row['req_id']} | {row['security_req'][:50]}... | {row['nist_control']} | {row['test_id']} | {row['status']} |\n")
   print("\nMarkdown RTM saved: /tmp/security-rtm.md")
   PYTHON
   
   python3 /tmp/security-rtm.py

7. Tình huống doanh nghiệp / Real-world scenario

8. Tự kiểm tra / Knowledge check

1. SSE-CMM có 11 Process Areas và 5 Capability Levels. Phân biệt Capability Level 2 (Planned and Tracked) và Level 3 (Well Defined). Tại sao Level 3 quan trọng hơn Level 2 từ góc nhìn organizational maturity?
2. NIST SP 800-160 Vol.2 định nghĩa 4 Cyber Resiliency Goals. Với một tổ chức tài chính bị APT tấn công persistent trong 6 tháng, goal nào cần prioritize và tại sao?
3. Trong FAIR model, phân biệt Threat Event Frequency (TEF) và Loss Event Frequency (LEF). Một system có TEF cao nhưng LEF thấp — điều này nói lên điều gì về security posture của system đó?
4. NIST RMF Step 6 (Authorize) — Authorizing Official (AO) review 3 documents để ra quyết định ATO. Nếu SAR có 2 High findings chưa remediated, AO có những lựa chọn nào ngoài "Deny ATO"? Explain điều kiện để chọn mỗi option.
5. Common Criteria EAL4 là phổ biến nhất cho commercial products. Tại sao EAL7 không phải là "tốt nhất" cho mọi use case? Cho ví dụ scenario mà EAL4 là appropriate và EAL7 là overkill.
6. FedRAMP Moderate baseline yêu cầu ~325 controls. Phân biệt "inherited controls" (common controls từ CSP infrastructure) và "customer-responsible controls" trong shared responsibility model. Cho ví dụ 3 controls thuộc mỗi loại.
7. STIG CAT I finding yêu cầu remediation ngay. Trong scenario thực tế, một CAT I finding (ví dụ "Default admin password unchanged") không thể remediate ngay vì application vendor chưa có patch. Security engineer nên xử lý thế nào theo NIST RMF quy trình?