Part 008 — Cloud Risk Register and Control Mapping

Security yang matang tidak dimulai dari tool.

Ia dimulai dari kalimat seperti ini:

Apa risiko yang sedang kita kurangi?

Tanpa jawaban jelas, organisasi akan mengaktifkan banyak service tetapi tetap tidak tahu apakah posture membaik.

GuardDuty aktif. Security Hub aktif. Config aktif. Inspector aktif. Macie aktif. CloudTrail aktif. Tetapi saat auditor, incident commander, atau CTO bertanya “risiko terbesar kita apa?”, jawabannya tetap kabur.

Itu tanda sistem security masih tool-driven, bukan risk-driven.

Part ini membahas cara membangun cloud risk register dan control mapping untuk AWS environment.

Risk register bukan dokumen GRC statis. Untuk engineering, risk register adalah struktur kerja yang menghubungkan:

threat scenario -> affected asset -> impact -> control -> evidence -> owner -> remediation -> residual risk

AWS Cloud Adoption Framework menekankan pentingnya security governance, risk assessment, control framework, security assurance, dan continuous monitoring untuk mengevaluasi efektivitas kontrol. AWS Prescriptive Guidance juga membagi security controls menjadi preventive, proactive, detective, dan responsive controls. Itu memberi kita bahasa operasional untuk memetakan risiko menjadi sistem kontrol.

1. Problem: Banyak Finding, Sedikit Risk Clarity

Lingkungan AWS yang cukup besar biasanya menghasilkan banyak sinyal:

• Security Hub findings,
• GuardDuty findings,
• AWS Config noncompliance,
• Inspector vulnerabilities,
• IAM Access Analyzer external access findings,
• Macie sensitive data findings,
• CloudTrail suspicious events,
• CloudWatch alarms,
• budget anomalies,
• penetration test reports,
• audit observations,
• incident postmortems.

Tanpa risk model, semua sinyal ini menjadi noise.

Masalah klasik:

• Critical vulnerability di instance non-routable dev dianggap sama dengan critical vulnerability di public-facing prod.
• Public S3 bucket kosong mendapat perhatian lebih besar daripada IAM role prod dengan privilege escalation path.
• Security team membuat finding, tetapi tidak tahu owner teknis.
• Platform team menutup finding satu per satu tanpa memperbaiki control penyebabnya.
• Audit meminta evidence, tetapi evidence tersebar di screenshot, spreadsheet, dan percakapan Slack.
• Remediation SLA dibuat berdasarkan severity tool, bukan business impact.

Risk register yang baik mengubah ini menjadi sistem berpikir.

2. Risk Register untuk Engineer

Risk register bukan sekadar tabel compliance. Ia harus bisa dipakai engineer untuk mengambil keputusan.

Minimal field:

Format risk statement yang bagus:

Because <condition>, a <threat actor or failure mode> could <action>, causing <impact>.

Contoh:

Because production IAM roles can create new inline policies without permission boundaries,
a compromised deployment role could escalate privileges and modify security controls,
causing unauthorized access to sensitive data and loss of audit integrity.

Kalimat ini jauh lebih berguna daripada:

IAM risk high.

3. Control Taxonomy

AWS Prescriptive Guidance membagi security control menjadi empat tipe utama.

3.1 Preventive Controls

Preventive controls mencegah event terjadi.

Contoh AWS:

• SCP menolak penggunaan region tidak disetujui.
• IAM policy tidak memberi s3:PutBucketPublicAccessBlock sembarangan.
• KMS key policy tidak mengizinkan decrypt lintas account tanpa syarat.
• VPC endpoint policy membatasi akses bucket tertentu.
• Permission boundary membatasi role yang dibuat platform team.

Preventive control bagus untuk invariant yang jelas.

Tetapi terlalu banyak preventive control tanpa exception path akan menghambat engineering dan mendorong bypass.

3.2 Proactive Controls

Proactive controls mencegah resource noncompliant dibuat, biasanya pada provisioning path.

Contoh:

• IaC policy check menolak S3 bucket public sebelum merge.
• CloudFormation Guard rule mencegah resource tanpa encryption.
• Control Tower proactive control mengecek template sebelum provision.
• CI/CD policy gate mencegah security group 0.0.0.0/0 untuk port sensitif.

Proactive control berada sebelum resource hidup.

3.3 Detective Controls

Detective controls mendeteksi, mencatat, dan memberi alert setelah event terjadi.

Contoh:

• CloudTrail merekam API call.
• AWS Config mendeteksi resource drift.
• GuardDuty mendeteksi credential exfiltration pattern.
• Security Hub mengagregasi posture findings.
• IAM Access Analyzer mendeteksi external access.
• CloudWatch alarm mendeteksi error rate atau unusual activity.

Detective control penting karena tidak semua risiko bisa dicegah.

3.4 Responsive Controls

Responsive controls menggerakkan remediation.

Contoh:

• EventBridge memicu Lambda untuk memblokir public S3 bucket.
• Systems Manager Automation mengisolasi EC2 instance.
• Security Hub custom action membuat ticket incident.
• Step Functions menjalankan approval + remediation workflow.
• Incident Manager memanggil on-call dan membuat incident timeline.

Responsive control membuat detection menjadi action.

3.5 Recovery Controls

AWS Prescriptive Guidance menekankan empat tipe di atas. Dalam engineering, kita juga sering memisahkan recovery controls karena recovery adalah kemampuan berbeda dari remediation.

Contoh:

• AWS Backup restore test.
• Cross-region replication.
• Immutable backup vault.
• Disaster recovery runbook.
• Rebuild-from-IaC capability.

Recovery control menjawab:

Setelah failure atau compromise, bisakah sistem kembali ke state aman?

4. Risk-to-Control Mapping Flow

Mapping ini memaksa kita tidak berhenti di “aktifkan service”.

Untuk setiap risiko, tanyakan:

1. Bisakah dicegah?
2. Bisakah dicegah sebelum provision?
3. Kalau terjadi, bagaimana dideteksi?
4. Setelah terdeteksi, siapa bergerak?
5. Bagaimana dipulihkan?
6. Evidence apa yang membuktikan kontrol berjalan?
7. Risiko apa yang tetap tersisa?

5. Risk Register Example: Public S3 Exposure

Risk Statement

Because S3 buckets may be created or modified with public access,
an external actor could read or write sensitive objects,
causing data disclosure, integrity loss, regulatory exposure, and reputational damage.

Mapping

Notes

Public exposure is not always wrong. A static public website bucket may be intentional. The risk register must support exception, not pretend all public access is equal.

The correct question is:

Is this exposure intentional, approved, scoped, monitored, and free of sensitive data?

6. Risk Register Example: Long-Lived Human Access Keys

Risk Statement

Because human IAM users may possess long-lived access keys,
phishing, malware, or accidental disclosure could allow unauthorized API access,
causing privilege misuse, data access, resource manipulation, or persistence.

Mapping

Design Principle

Human access should go through federation and temporary credentials. IAM users are exceptional, not default.

7. Risk Register Example: CloudTrail Disabled or Tampered

Risk Statement

Because workload administrators may be able to stop, delete, or alter audit logging,
a malicious or compromised principal could hide unauthorized activity,
causing loss of forensic evidence and audit integrity.

Mapping

Important Insight

Audit integrity is a tier-0 control. If logging can be disabled by the same people being monitored, the system has weak evidence integrity.

8. Risk Register Example: Unpatched Compute

Risk Statement

Because compute resources may run vulnerable packages or runtime versions,
an attacker could exploit known vulnerabilities,
causing unauthorized access, lateral movement, data exposure, or service disruption.

Mapping

Severity Trap

Do not blindly use CVSS as business priority.

A critical CVE on an isolated dev instance may be lower operational priority than a medium CVE on an internet-facing production authentication service.

Risk priority needs context:

severity = technical severity × exposure × asset criticality × exploitability × compensating controls

9. Risk Register Example: Overprivileged Deployment Role

Risk Statement

Because deployment roles may have broad administrative permissions,
a compromised CI/CD pipeline or malicious commit could modify IAM, disable controls, or access sensitive resources,
causing privilege escalation and production compromise.

Mapping

Design Principle

A deployment role should have enough power to deploy the workload, not enough power to become the organization administrator.

10. Building a Control Library

Risk register becomes scalable only if controls are reusable.

Control library format:

A control library prevents every risk assessment from reinventing the same controls.

11. Evidence Mapping

A control without evidence is a belief.

Evidence mapping answers:

How do we prove this control exists and operated during the period in question?

Examples:

Good evidence has properties:

• generated automatically,
• timestamped,
• hard to tamper with by workload owner,
• linked to account/resource/owner,
• retained long enough,
• queryable during audit or incident.

Screenshots are weak evidence. They may be acceptable for manual exceptions, but not as primary control proof.

12. Risk Scoring That Engineers Can Use

Avoid pretending risk scoring is mathematically precise. It is a prioritization tool.

A useful scoring model:

risk_score = impact × likelihood × exposure_modifier × control_gap_modifier

Impact

Likelihood

Exposure Modifier

Control Gap Modifier

This model is intentionally simple. The goal is consistent prioritization, not false precision.

13. Risk Register as Workflow

Risk register harus bergerak bersama engineering cadence.

Setiap risk item perlu lifecycle.

Tanpa lifecycle, risk register menjadi graveyard.

14. Exception Model

Security exception bukan kegagalan. Exception tanpa expiry adalah kegagalan.

Exception harus punya:

• risk ID,
• control yang dilanggar,
• alasan bisnis/teknis,
• affected account/resource,
• compensating control,
• approver,
• expiry date,
• review cadence,
• rollback/remediation plan,
• evidence.

Contoh exception buruk:

Allow public S3 because app needs it.

Contoh exception lebih baik:

Exception AWS-RISK-DATA-001-EX-2026-004 allows public read for bucket app-static-prod-assets.
Bucket contains only hashed static assets generated by pipeline.
S3 Block Public Access remains enabled at account level except bucket policy managed by IaC.
Macie classification confirms no sensitive objects.
CloudTrail data events enabled for object writes.
Expires 2026-10-01 or when CloudFront OAC migration completes.
Approved by Product Security and App Owner.

Exception yang jelas menjaga velocity tanpa menghancurkan governance.

15. Mapping AWS Services to Control Types

A service can support more than one control type depending on design. CloudTrail is primarily detective, but it also supports responsive workflows because events can route to EventBridge. Config is detective by default, but remediation automation can make it part of responsive control.

16. Control Coverage Matrix

Untuk setiap high-risk area, pastikan kontrol tidak hanya detective.

If a risk has only detective controls, you are accepting that bad states can happen and remain until response. That may be acceptable for low-risk dev scenarios. It is usually not acceptable for tier-0 production controls.

17. Owner Model

Every risk needs two owners:

Risk Owner

The person or group accountable for accepting or reducing business/technical risk.

Examples:

• application owner,
• platform owner,
• data owner,
• product owner,
• CISO delegate,
• compliance owner.

Control Owner

The team responsible for implementing and operating the control.

Examples:

• identity platform team owns IAM Identity Center baseline,
• security platform team owns GuardDuty/Security Hub aggregation,
• workload team owns application-level encryption and dependency patching,
• cloud platform team owns account vending and SCP baseline,
• SRE team owns operational alarms and incident runbooks.

Do not confuse them.

Security team may own detection tooling, but workload owner often owns remediation.

18. SLA Model

SLA harus mempertimbangkan:

• severity,
• environment,
• exposure,
• data sensitivity,
• exploitability,
• business criticality,
• compensating controls.

Contoh SLA:

SLA yang sama untuk semua environment akan gagal. Terlalu ketat untuk sandbox, terlalu longgar untuk prod.

19. Risk Register Storage Model

Risk register bisa dimulai sebagai MDX/YAML, bukan harus langsung tool besar.

Contoh file:

risk_id: AWS-RISK-IAM-003
risk_statement: >
  Because deployment roles may have broad administrative permissions,
  a compromised CI/CD pipeline or malicious commit could modify IAM,
  disable controls, or access sensitive resources.
category: identity
inherent_risk: critical
affected_environments:
  - prod
controls:
  preventive:
    - AWS-CTRL-IAM-BOUNDARY-001
    - AWS-CTRL-SCP-IAM-001
  proactive:
    - AWS-CTRL-IAC-IAM-LINT-001
  detective:
    - AWS-CTRL-CLOUDTRAIL-IAM-001
    - AWS-CTRL-ACCESS-ANALYZER-001
  responsive:
    - AWS-CTRL-IR-REVOKE-ROLE-001
owner:
  risk_owner: platform-engineering
  control_owner: identity-platform
sla:
  prod: immediate
residual_risk: high
review_cadence: quarterly

File-based risk register punya keuntungan:

• bisa direview via pull request,
• versioned,
• dekat dengan engineering workflow,
• bisa digenerate menjadi dashboard,
• bisa dipetakan ke controls-as-code.

Nanti saat maturity naik, data ini bisa masuk ke GRC platform atau Audit Manager mapping.

20. Minimal Initial Risk Register for AWS

Mulai dengan risiko inti ini.

Jangan mulai dengan 200 risiko. Mulai dengan 15–25 risiko yang benar-benar bisa ditindaklanjuti.

21. How to Review Risk Register

Review risk register secara periodik dan event-driven.

Periodic Review

• monthly untuk high-risk open items,
• quarterly untuk full risk register,
• annually untuk risk model dan compliance mapping.

Event-Driven Review

Review saat:

• account baru dibuat,
• workload baru masuk prod,
• incident terjadi,
• audit finding muncul,
• major AWS service/control berubah,
• data classification berubah,
• new public endpoint ditambahkan,
• new third-party integration dibuat,
• acquisition/reorg mengubah ownership.

Risk register yang tidak berubah saat arsitektur berubah berarti tidak lagi merepresentasikan realita.

22. Anti-Patterns

Anti-Pattern 1 — Risk Register sebagai Spreadsheet Mati

Spreadsheet yang hanya diperbarui sebelum audit bukan risk management. Itu audit theater.

Anti-Pattern 2 — Semua Risiko Diberi Rating High

Kalau semua high, tidak ada prioritas.

Anti-Pattern 3 — Severity Tool Sama dengan Risk Priority

Tool severity penting, tetapi tidak cukup. Tambahkan context environment, exposure, data, dan business criticality.

Anti-Pattern 4 — Control Tanpa Owner

Control tanpa owner akan drift.

Anti-Pattern 5 — Evidence Manual sebagai Default

Screenshot dan manual attestation tidak scale. Automate evidence wherever possible.

Anti-Pattern 6 — Exception Tanpa Expiry

Exception tanpa expiry adalah policy baru yang tidak diakui.

Anti-Pattern 7 — Remediate Finding, Bukan Control Gap

Jika public bucket muncul sepuluh kali, masalahnya bukan sepuluh bucket. Masalahnya provisioning path tidak punya proactive/preventive control.

23. Practical Implementation Plan

Week 1 — Build Initial Register

• Ambil top 20 AWS risks.
• Tulis risk statement yang jelas.
• Mapping affected account/environment.
• Tentukan risk owner dan control owner.

Week 2 — Map Existing Controls

• SCP apa yang sudah ada?
• Config rule apa yang aktif?
• CloudTrail/GuardDuty/Security Hub sudah coverage account mana?
• Evidence apa yang tersedia otomatis?
• Remediation apa yang masih manual?

Week 3 — Identify Control Gaps

Untuk setiap risk:

• Apakah hanya detective?
• Apakah preventive terlalu longgar?
• Apakah response tidak punya owner?
• Apakah evidence tidak cukup?
• Apakah exception tidak punya expiry?

Week 4 — Prioritize Engineering Backlog

Buat backlog:

• baseline account vending,
• SCP hardening,
• CloudTrail/log archive protection,
• GuardDuty/Security Hub organization aggregation,
• Config conformance pack,
• IAM Access Analyzer rollout,
• remediation automation untuk top 5 risks,
• evidence dashboard.

24. Kesimpulan

Cloud risk register adalah jembatan antara security architecture dan daily engineering.

Tanpa risk register, Anda hanya punya banyak tools dan banyak finding.

Dengan risk register, Anda punya sistem:

risk -> control -> evidence -> owner -> remediation -> residual risk

Prinsip utama:

1. Risk harus ditulis sebagai scenario sebab-akibat.
2. Control harus dipetakan ke preventive, proactive, detective, responsive, dan recovery capability.
3. Evidence harus otomatis, timestamped, queryable, dan sulit dimanipulasi oleh workload owner.
4. Owner harus jelas: risk owner berbeda dari control owner.
5. SLA harus mempertimbangkan environment, exposure, data sensitivity, dan business criticality.
6. Exception harus punya expiry dan compensating control.
7. Finding berulang adalah sinyal control gap, bukan sekadar backlog remediation.

Dengan Part 008, fase fondasi selesai. Part berikutnya mulai masuk ke AWS Organizations Deep Dive, yaitu bagaimana struktur organisasi AWS menjadi control plane untuk semua account, OU, delegated administrator, SCP, dan governance inheritance.

References

• AWS Prescriptive Guidance — Types of security controls. https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/security-control-types.html
• AWS Cloud Adoption Framework — Security Perspective: compliance and assurance. https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html
• AWS Cloud Adoption Framework — Governance Perspective: control and oversight. https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/governance-perspective.html
• AWS Control Tower — About controls. https://docs.aws.amazon.com/controltower/latest/controlreference/controls.html
• AWS Control Tower — Control behavior and guidance. https://docs.aws.amazon.com/controltower/latest/controlreference/control-behavior.html
• AWS Well-Architected Framework — Security Pillar. https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html