Cloud Security Framework — CivicNexus

Why it matters

Replaces public exposure and ad-hoc controls with an auditable security model for a platform holding citizen, personnel and IoT data. Two Critical risks (score 9) were treated down to Low, and a three-node database design raised planned availability from Medium to High.

The problem in detail

The academic brief described a smart-city platform handling continuous IoT telemetry and personnel data without the controls that data warrants. The web tier sat directly on the public internet, the MongoDB database accepted inbound traffic from 0.0.0.0/0 on its administrative and database ports, storage volumes were unencrypted, access rested on static SSH key pairs with no multi-factor authentication, and there was no logging or monitoring to detect misuse. Two risks scored Critical at the network layer alone — unreviewed infrastructure-as-code misconfiguration and publicly reachable DNS and IPv4 resources — while excessively open inbound rules made lateral movement trivial. The scenario also had no ISO 27001 alignment, so there was no defensible evidence of governance. The task was to quantify that exposure objectively, treat it in priority order, and leave behind an auditable framework rather than a set of ad-hoc fixes.

What I built

1. 01

   Split ownership of the infrastructure across the team so each critical asset had a named owner — the web server and network perimeter (Arif Rahman) and the database tier (Sukhvir Singh) — and scoped every control to four distinct layers: network, instance, server and data.

2. 02

   Ran the risk process against the ISO/IEC 27005 lifecycle: context establishment, risk identification, risk analysis, risk evaluation and risk treatment, with monitoring and review built in rather than bolted on.

3. 03

   Built a quantified Asset-Threat-Vulnerability register scoring each entry as Impact x Likelihood on a 1–3 scale, producing risk ratings from Low (P4) to Critical (P1) — for example, security groups using 0.0.0.0/0 on administrative and database ports scored 9 (Critical, P1), while rule shadowing scored 2 (Low, P4).

4. 04

   Prioritised treatment by risk score rather than by ease, so Critical P1 items — unreviewed IaC misconfiguration, public DNS/IPv4 exposure and open inbound administrative access — were remediated first.

5. 05

   Redesigned the network: a dedicated CivicNexus VPC on 10.0.0.0/16 replacing reliance on the default VPC, three private database subnets (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24) spread across us-east-1a/b/c, and a separate public subnet (10.0.4.0/24) for the web tier only.

6. 06

   Moved the database off the public internet entirely — private IP addressing, no public IP, and MongoDB port 27017 reachable only from trusted resources — with administrative access brokered through a bastion host instead of direct SSH exposure.

7. 07

   Replaced open security groups with tier-to-tier rules acting as virtual firewalls, so each tier accepts traffic only from the tier directly above it rather than from 0.0.0.0/0 on ports 22 and 80.

8. 08

   Hardened identity and access: IAM roles built on least privilege, role-based access control on MongoDB, MFA enforced on administrative accounts via Cognito/IAM in place of static key pairs, and scheduled permission reviews to prevent privilege creep.

9. 09

   Protected data at rest and in transit with KMS-backed encrypted EBS volumes, database-level encryption, secure transfer channels, keyfile authentication between replica-set nodes and automated backups.

10. 10

    Added detection capability where there had previously been none: CloudTrail for user and API activity auditing, CloudWatch alarms for monitoring, and a documented log-review process feeding incident response.

11. 11

    Designed a 3-node MongoDB replica set to raise data availability from Medium to High, addressing continuity as a security property rather than only an operations concern.

12. 12

    Wrote an integrated policy and governance framework — access control, monitoring and audit, and employee security awareness policies — with defined timelines, owners and resources for each treatment.

13. 13

    Mapped every control to ISO/IEC 27001 Annex A and recorded implementation status: A.5 policies, A.6 organisation, A.9 access management, A.10 cryptography, A.12 operations security, A.13 communications security and A.17 business continuity implemented, with A.7 human resource security planned.

14. 14

    Closed the loop with a post-treatment effectiveness review, comparing initial and final security levels per asset to evidence that residual risk had been reduced to an acceptable level.