Mục tiêu bài học — Learning Objectives
- Xây dựng Vendor Risk Assessment lifecycle: tiering, questionnaire, scoring, approval, ongoing monitoring
- Soạn thảo security clauses trong contracts: data processing agreements, SLA security requirements, right-to-audit
- Đọc và đánh giá SOC 2 Type II report — phân biệt qualified vs. unqualified opinion
- Quản lý fourth-party risk và chuỗi cung ứng software dependencies
- Sử dụng security rating tools (BitSight, SecurityScorecard) để monitor vendor posture liên tục
Lý thuyết — Theory
1. Vendor Risk Assessment Lifecycle
Third-party breaches ngày càng phổ biến (SolarWinds, MOVEit, Change Healthcare). Bên thứ ba có thể là entry point vào tổ chức — phải đánh giá họ như đánh giá rủi ro nội bộ.
- • Truy cập vào sensitive data (PII, PHI, PCI)
- • Business-critical services (uptime dependency)
- • Kiểm soát vào production systems
- Review: Annual + event-driven
- Assurance: SOC 2 Type II hoặc on-site audit
- • Truy cập internal systems nhưng không sensitive
- • Tích hợp API với data exchange
- • Nhà cung cấp dịch vụ quan trọng nhưng có thể thay thế
- Review: Annual
- Assurance: Questionnaire + SOC 2 review
- • Không truy cập vào IT systems
- • Dịch vụ commodity (office supplies, catering)
- • Tác động tối thiểu nếu gián đoạn
- Review: Every 3 years
- Assurance: Standard onboarding checklist
2. Security Clauses trong Contracts & SLA
Contract là công cụ pháp lý để enforce security requirements với bên thứ ba. Không có security clauses trong contract = không có leverage khi sự cố xảy ra.
- • Minimum security standards (ISO 27001, SOC 2)
- • Data protection obligations (GDPR DPA nếu data processor)
- • Breach notification: 24-72h notify customer
- • Right-to-audit: audit vendor annually với notice 30 ngày
- • Subprocessor restrictions: phải approve trước
- • Data retention và deletion requirements
- • Pentest frequency: annual, share results
- • Background checks cho nhân viên có data access
- • Uptime: 99.9% (8.7h downtime/year) với penalties
- • Incident response time: Critical ≤ 1h, High ≤ 4h
- • Patch critical vulnerabilities: ≤ 48h
- • Vulnerability assessment: quarterly
- • Security report: monthly/quarterly delivery
- • Personnel security: background check for all staff with access
- • Termination clause: secure data return/destruction trong 30 ngày
3. SOC 2 Report Review — Đọc và đánh giá
SOC 2 Type II là "gold standard" để đánh giá security của SaaS/cloud vendors. Biết cách đọc SOC 2 report là kỹ năng quan trọng của GRC professional.
- Qualified opinion = auditor không đồng ý với controls
- Exceptions (deviations) trong test results — nhiều = bad
- Report >12 tháng tuổi — không còn relevant
- Type I thay vì Type II — chỉ point-in-time, không test effectiveness
- Phạm vi (scope) quá hẹp — không bao phủ systems bạn dùng
- Complementary User Entity Controls — bạn chịu trách nhiệm implement
4. Fourth-Party Risk & Ongoing Monitoring
Fourth-party risk = rủi ro từ vendors của vendors. Khi SolarWinds bị tấn công, mọi khách hàng của SolarWinds (bao gồm US government agencies) đều bị ảnh hưởng dù họ không làm gì sai.
- • Yêu cầu vendors liệt kê key subprocessors
- • Receive notification khi subprocessors thay đổi
- • Require vendors flow-down security requirements
- • SBOM (Software Bill of Materials) cho software vendors
- • Cloud provider shared responsibility model clarity
- • Concentration risk: nhiều vendors dùng cùng subprocessor
- BitSight: Security ratings từ external signals (exposed services, malware, etc.)
- SecurityScorecard: Letter grade A-F, 10 risk categories
- UpGuard: Data leak detection + attack surface monitoring
- RiskRecon (Mastercard): Third-party risk ratings
- Manual reviews: Annual questionnaire + SOC 2 refresh
- Threat intelligence: Monitor vendor breaches via news/darkweb
5. Cloud Provider Due Diligence
Cloud providers là vendors đặc biệt quan trọng. Shared Responsibility Model xác định ai chịu trách nhiệm gì — hiểu sai mô hình này là nguyên nhân của nhiều cloud security incidents.
| Responsibility | IaaS (EC2, Azure VM) | PaaS (App Service, RDS) | SaaS (M365, Salesforce) |
|---|---|---|---|
| Physical infra | Cloud Provider | Cloud Provider | Cloud Provider |
| Hypervisor/Network | Cloud Provider | Cloud Provider | Cloud Provider |
| OS & Runtime | Customer | Cloud Provider | Cloud Provider |
| Application | Customer | Customer | Cloud Provider |
| Data & Encryption | Customer | Customer | Customer |
| IAM & Access Control | Customer | Customer | Customer |
Lưu ý: Data luôn là trách nhiệm của Customer — dù ở SaaS. Cloud provider bảo vệ platform, bạn bảo vệ data trong platform đó.
Bài thực hành — Hands-on Labs
Vendor Risk Scorecard — PowerShell tạo vendor assessment & risk scoring
# Vendor Risk Scorecard — ISC2 CGRC Third-Party Management
# Scoring: 1 (best) to 5 (worst) per category; lower total = lower risk
$vendors = @(
@{
Name = "CloudPay Processor"; Tier = "Critical"
DataAccess = 5 # 5=high sensitive data (PCI)
SOC2 = 1 # 1=SOC2 Type II current
ISO27001 = 1 # 1=certified
PentestRecent = 2 # 2=pentest within 12mo
BreachHistory = 2 # 2=minor incident >3yr ago
SLACompliance = 1 # 1=100% SLA met last 12mo
ContractClause = 1 # 1=full security clauses
SubprocessorRisk = 2 # 2=known subprocessors
},
@{
Name = "MarketBot Analytics"; Tier = "High"
DataAccess = 3; SOC2 = 3; ISO27001 = 4; PentestRecent = 3
BreachHistory = 1; SLACompliance = 2; ContractClause = 3; SubprocessorRisk = 4
},
@{
Name = "OfficeSupply Co"; Tier = "Standard"
DataAccess = 1; SOC2 = 5; ISO27001 = 5; PentestRecent = 5
BreachHistory = 1; SLACompliance = 1; ContractClause = 2; SubprocessorRisk = 1
}
)
$weights = @{
DataAccess=0.25; SOC2=0.15; ISO27001=0.10; PentestRecent=0.15
BreachHistory=0.15; SLACompliance=0.10; ContractClause=0.05; SubprocessorRisk=0.05
}
$results = foreach ($v in $vendors) {
$score = 0
foreach ($k in $weights.Keys) { $score += $v[$k] * $weights[$k] }
$risk = switch ([math]::Round($score,1)) {
{ $_ -le 1.5 } { "LOW" }
{ $_ -le 2.5 } { "MEDIUM" }
{ $_ -le 3.5 } { "HIGH" }
default { "CRITICAL" }
}
[PSCustomObject]@{
Vendor = $v.Name
Tier = $v.Tier
WeightedScore = [math]::Round($score, 2)
RiskRating = $risk
Action = switch ($risk) {
"LOW" { "Approve — triennial review" }
"MEDIUM" { "Approve — annual review + monitoring" }
"HIGH" { "Conditional — remediation plan required" }
"CRITICAL" { "Reject or escalate to CISO" }
}
}
}
$results | Sort-Object WeightedScore -Descending | Format-Table -AutoSize
$results | Export-Csv "C:\GRC\vendor-risk-register.csv" -NoTypeInformation
Vendor WeightedScore RiskRating Action ------ ------------- ---------- ------ MarketBot Analytics 2.95 HIGH Conditional — remediation plan required CloudPay Processor 2.20 MEDIUM Approve — annual review + monitoring OfficeSupply Co 1.70 MEDIUM Approve — annual review + monitoring CSV: C:\GRC\vendor-risk-register.csv Action: Request SOC 2 Type II and ISO 27001 from MarketBot Analytics within 90 days
Vendor Security Monitoring — Bash kiểm tra TLS/certificate và exposed services
#!/bin/bash
# Vendor Security Posture Check — kiểm tra TLS, cert, security headers
VENDOR="${1:-example-vendor.com}"
REPORT="/tmp/vendor-check-${VENDOR}-$(date +%Y%m%d).txt"
PASS=0; WARN=0; FAIL=0
log() { echo "[$(date +%H:%M:%S)] $1" | tee -a $REPORT; }
chk() { printf " %-40s [%s] %s\n" "$1" "$2" "$3" | tee -a $REPORT
case $2 in PASS) (( PASS++ ));; WARN) (( WARN++ ));; FAIL) (( FAIL++ ));; esac; }
log "=== Vendor Security Check: $VENDOR ==="
# 1. TLS version check (reject TLS 1.0/1.1)
TLS_VER=$(openssl s_client -connect ${VENDOR}:443 -tls1_2 </dev/null 2>&1 | grep "Protocol" | awk '{print $NF}')
if [ -n "$TLS_VER" ]; then
chk "TLS version (min TLS 1.2)" "PASS" "Supports TLS 1.2"
else
chk "TLS version" "FAIL" "TLS 1.2 not available"
fi
# 2. Certificate expiry check
CERT_EXPIRY=$(echo | openssl s_client -connect ${VENDOR}:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
DAYS_LEFT=$(( ( $(date -d "$CERT_EXPIRY" +%s) - $(date +%s) ) / 86400 ))
if [ $DAYS_LEFT -gt 30 ]; then chk "Certificate expiry" "PASS" "${DAYS_LEFT} days remaining"
elif [ $DAYS_LEFT -gt 0 ]; then chk "Certificate expiry" "WARN" "Expiring soon: ${DAYS_LEFT} days"
else chk "Certificate expiry" "FAIL" "EXPIRED!"
fi
# 3. Security headers check
HEADERS=$(curl -sI https://${VENDOR} --max-time 10 2>/dev/null)
for header in "Strict-Transport-Security" "X-Content-Type-Options" "X-Frame-Options" "Content-Security-Policy"; do
if echo "$HEADERS" | grep -qi "$header"; then
chk "Header: $header" "PASS" "Present"
else
chk "Header: $header" "WARN" "Missing — security risk"
fi
done
# 4. HTTP → HTTPS redirect
HTTP_CODE=$(curl -so /dev/null -w "%{http_code}" http://${VENDOR} --max-time 5 2>/dev/null)
if [ "$HTTP_CODE" = "301" ] || [ "$HTTP_CODE" = "308" ]; then
chk "HTTPS redirect" "PASS" "HTTP redirects to HTTPS (${HTTP_CODE})"
else
chk "HTTPS redirect" "WARN" "HTTP response: ${HTTP_CODE} — verify redirect"
fi
log ""
log "=== RESULT: PASS=$PASS WARN=$WARN FAIL=$FAIL | Report: $REPORT ==="
[09:20:00] === Vendor Security Check: cloudpay-vendor.com === TLS version (min TLS 1.2) [PASS] Supports TLS 1.2 Certificate expiry [PASS] 187 days remaining Header: Strict-Transport-Security [PASS] Present Header: X-Content-Type-Options [PASS] Present Header: X-Frame-Options [PASS] Present Header: Content-Security-Policy [WARN] Missing — security risk HTTPS redirect [PASS] HTTP redirects to HTTPS (301) [09:20:05] === RESULT: PASS=6 WARN=1 FAIL=0 | Report: /tmp/vendor-check-...txt === Action: Request vendor add Content-Security-Policy header within 30 days
Tình huống doanh nghiệp — Business Scenario
Dragon Bank sử dụng một vendor HR software bị breach qua zero-day vulnerability trong file transfer tool (tương tự MOVEit 2023). 45,000 bản ghi nhân viên bị exfiltrate gồm: họ tên, CCCD, lương, số tài khoản ngân hàng.
Tự kiểm tra — Self-Assessment (5 câu)
1. SOC 2 Type II khác SOC 2 Type I ở điểm nào?
2. Trong SOC 2 review, "Complementary User Entity Controls" (CUECs) có nghĩa là gì?
CUECs rất quan trọng — nếu bạn không implement, SOC 2 của vendor không bảo vệ bạn. Ví dụ: "Customer phải enable MFA" — nếu bạn không bật, vendor không chịu trách nhiệm breach.
3. GDPR Article 28 yêu cầu gì khi sử dụng một vendor xử lý dữ liệu cá nhân EU?
4. "Fourth-party risk" đề cập đến rủi ro từ đâu?
5. Trong Cloud Shared Responsibility Model, thành phần nào luôn là trách nhiệm của KHÁCH HÀNG dù ở IaaS, PaaS hay SaaS?
Quy trình 7 bước — Third-Party Risk Management
7-Step Third-Party Risk Process
Lập danh sách (catalog) toàn bộ bên thứ ba có quyền truy cập dữ liệu hoặc tích hợp hệ thống. Bao gồm: nhà cung cấp SaaS, đối tác tích hợp API, nhà thầu phụ, nhà cung cấp cloud.
Phân tầng theo inherent risk dựa trên độ nhạy dữ liệu và mức độ truy cập:
Sử dụng bảng câu hỏi chuẩn: SIG Lite (Shared Assessments), VSA (Vendor Security Alliance), hoặc nội bộ. Kết hợp xem xét: SOC 2 Type II report, chứng chỉ ISO 27001, tóm tắt pen test gần nhất, chính sách bảo mật và privacy.
Chấm điểm kết quả bảng câu hỏi, tính residual risk, gắn cờ (flag) các điểm yếu. Kết quả phân loại: Critical / High / Medium / Low gaps. Báo cáo gửi vendor và lãnh đạo nội bộ.
Vendor phải khắc phục các điểm yếu Critical trước hoặc trong quá trình onboarding. Theo dõi bằng POA&M. Các gap không thể khắc phục ngay cần được phê duyệt rủi ro (risk acceptance) từ lãnh đạo.
Không chỉ đánh giá một lần. Giám sát liên tục bao gồm:
- • Tier 1: Tái đánh giá hàng năm (annual re-assessment)
- • Tier 2–3: Hai năm một lần (biennial)
- • Theo dõi breach news feeds, CVE liên quan đến vendor
- • Xem xét thay đổi SOC 2 report, chứng chỉ hết hạn
Khi hợp đồng kết thúc hoặc vendor bị thay thế:
POA&M — Tích hợp với Quy trình Vendor
POA&M (Plan of Action & Milestones) theo dõi các cam kết khắc phục của vendor. Mỗi phát hiện chưa giải quyết phải có entry POA&M riêng biệt — không tùy chọn trong đánh giá chính thức.
| Trường dữ liệu | Nội dung | Ví dụ |
|---|---|---|
| Weakness Description | Mô tả chi tiết điểm yếu được phát hiện | Thiếu MFA cho admin portal |
| Responsible Party | Bên chịu trách nhiệm khắc phục | Vendor CISO: John Smith |
| Scheduled Completion | Ngày hoàn thành cam kết | 2025-09-30 |
| Resources Needed | Ngân sách, nhân lực, công cụ cần thiết | $15K — MFA platform license |
| Milestones | Các mốc tiến độ cụ thể | M1: Pilot 20 users (Aug 1) → M2: Full rollout (Sep 30) |
POA&M không phải tùy chọn — bất kỳ phát hiện chưa giải quyết nào trong đánh giá chính thức đều phải có POA&M entry. Đây là yêu cầu của FISMA, FedRAMP và hầu hết các framework GRC cấp liên bang Mỹ.