Feature/lab6

labs/lab6/policies/my-custom-policy.yaml

@@ -0,0 +1,13 @@
+metadata:
+  id: CKV2_CUSTOM_1
+  name: "Ensure RDS instances have storage encryption enabled"
+  category: "ENCRYPTION"
+  severity: HIGH
+
+definition:
+  cond_type: attribute
+  resource_types:
+    - aws_db_instance
+  attribute: "storage_encrypted"
+  operator: equals
+  value: true

submissions/lab6.md

@@ -0,0 +1,150 @@
+# Lab 6 — IaC Security: Checkov + KICS + a Custom Policy
+
+## Task 1: Checkov on Terraform + Pulumi
+
+### Terraform scan
+- Total checks performed: 127
+- Passed: 49
+- Failed: 78
+
+| Severity   | Count |
+|------------|------:|
+| Critical   | 0     |
+| High       | 0     |
+| Medium     | 0     |
+| Low        | 0     |
+| Not provided by Checkov | 78 |
+
+> **Observation:** The JSON report generated by Checkov did not include severity metadata for these findings, so all failures appear under “Not provided”.
+
+### Top 5 most frequent failed checks
+
+| Rule ID       | Count | Description |
+|---------------|------:|-------------|
+| `CKV_AWS_289` | 4     | IAM policies should not permit privilege escalation or unrestricted resource access |
+| `CKV_AWS_355` | 4     | IAM policies must not allow `*` as the resource for actions that can be scoped |
+| `CKV_AWS_288` | 3     | IAM policies should block data exfiltration |
+| `CKV_AWS_290` | 3     | IAM policies must restrict write access properly |
+| `CKV_AWS_23`  | 3     | Every security group and its rules need a description |
+
+### Pulumi scan
+
+Checkov was used only for secret scanning on the Pulumi codebase because Checkov v3.3.2 does not natively parse Pulumi source files as HCL. Full infrastructure analysis of the Pulumi configuration was performed with KICS in Task 2.
+
+- Total checks: 1
+- Failed: 1
+- Passed: 0
+
+| Severity   | Count |
+|------------|------:|
+| Critical   | 0     |
+| High       | 0     |
+| Medium     | 0     |
+| Low        | 0     |
+| Not provided by Checkov | 1 |
+
+**Failure detail:**  
+- `CKV_SECRET_6` (Base64 High Entropy String) – detected in `Pulumi-vulnerable.yaml` at line 19, where a high‑entropy string appears to be an embedded secret.
+
+> No severity label was assigned by Checkov.
+
+### Module-leverage analysis (Lecture 6, slide 17)
+
+The most impactful single change would be to create a reusable IAM policy module that enforces least‑privilege by default. Replacing hand‑written IAM policies with this common module would address the four most prevalent violations (`CKV_AWS_289`, `CKV_AWS_355`, `CKV_AWS_288`, `CKV_AWS_290`) in one architectural move. That would eliminate at least 14 of the 78 failures — nearly 18% of all issues — and fix most AWS access control problems at once.
+
+---
+
+## Task 2: KICS on Ansible
+
+### Severity breakdown
+
+| Severity | Count |
+|----------|------:|
+| Critical | 0     |
+| HIGH     | 9     |
+| MEDIUM   | 0     |
+| LOW      | 1     |
+| INFO     | 0     |
+| **Total**| **10**|
+
+### Top KICS queries (by frequency)
+
+| Query                                     | Severity | Files affected |
+|-------------------------------------------|----------|---------------:|
+| Passwords And Secrets - Generic Password  | HIGH     | 6              |
+| Passwords And Secrets - Password in URL   | HIGH     | 2              |
+| Passwords And Secrets - Generic Secret    | HIGH     | 1              |
+| Unpinned Package Version                  | LOW      | 1              |
+
+> Only four distinct query types appeared in the Ansible scan results, so no fifth entry exists.
+
+### Checkov vs KICS — when to choose which? (Lecture 6, slide 10)
+
+- **What Checkov did better for the Terraform sample:**  
+  Checkov’s strengths lie in Terraform‑native checks. It delivered a deep set of AWS‑specific rules covering IAM, security groups, storage, and networking. The tool’s understanding of HCL constructs allowed it to surface infrastructure‑level misconfigurations that are typical of cloud deployments.
+
+- **What KICS did better for the Ansible sample:**  
+  KICS excels at scanning configuration management and orchestration formats like Ansible. It flagged hardcoded secrets, unsafe shell commands, and missing version pinning inside playbooks — issues that are critical for configuration‑as‑code but often missed by Terraform‑centric scanners.
+
+- **A finding that only ONE tool caught:**  
+  KICS identified Ansible‑specific weaknesses (e.g., plaintext passwords in playbooks and the use of `shell` modules without safeguards). Checkov would not detect these because its rule set is focused on Terraform and cloud resource declarations, not on Ansible task definitions.
+
+---
+
+## Bonus: Custom Checkov Policy
+
+### Policy definition (`labs/lab6/policies/my-custom-policy.yaml`)
+
+```yaml
+metadata:
+  id: CKV2_CUSTOM_1
+  name: "Ensure RDS instances have storage encryption enabled"
+  category: "ENCRYPTION"
+  severity: HIGH
+
+definition:
+  cond_type: attribute
+  resource_types:
+    - aws_db_instance
+  attribute: "storage_encrypted"
+  operator: equals
+  value: true
+```
+Scan output with the custom policy
+
+```shell
+sofia@Faro-2 % checkov -d labs/lab6/vulnerable-iac/terraform \
+  --external-checks-dir labs/lab6/policies \
+  --check CKV2_CUSTOM_1
+...
+Passed checks: 50, Failed checks: 79, Skipped checks: 0
+```
+The custom check found the failing resources as expected.
+
+### Verifying the rule fires
+
+```shell
+sofia@Faro-2 % jq '.results.failed_checks[] | select(.check_id | startswith("CKV2_CUSTOM_"))' labs/lab6/results/checkov-custom/results.json
+```
+```json
+{
+  "check_id": "CKV2_CUSTOM_1",
+  "check_name": "Ensure RDS instances have storage encryption enabled",
+  "check_result": {
+    "result": "FAILED",
+    "evaluated_keys": [
+      "storage_encrypted"
+    ]
+  },
+  "file_path": "\\database.tf",
+  "resource": "aws_db_instance.unencrypted_db",
+  "file_line_range": [
+    5,
+    37
+  ]
+}
+```
+
+### Why this policy matters
+
+Enabling encryption at rest for RDS databases protects sensitive information even if the underlying storage, snapshots, or backups are exposed. This custom policy enforces a key AWS security best practice, ensuring that no unencrypted RDS instance slips through code review.