DEV Community: Sesank Munukutla (Naga)

From Compliance to Drift: Building and Breaking ISO 27001 Controls on AWS (Hands-on Evidence)

Sesank Munukutla (Naga) — Mon, 06 Apr 2026 17:13:07 +0000

Introduction

Most ISO 27001 implementations fail at one critical point: they treat compliance as a static checklist, not a continuous process.

In reality:

Systems drift
Configurations change
Controls break silently

This project demonstrates a real-world compliance lifecycle:

Build → Break → Detect → Investigate → Fix → Verify

Using:

Terraform (baseline provisioning)
AWS Config (continuous compliance)
Security Hub (aggregation)
CloudTrail (audit evidence)
S3 (evidence storage)

Architecture Overview

The system was designed as a lightweight continuous compliance engine:

Terraform → AWS Config → Security Hub → CloudTrail → S3 Evidence

Terraform establishes a compliant baseline
AWS Config continuously evaluates resources
Security Hub aggregates findings
CloudTrail records audit evidence

Baseline Deployment (Terraform)

Infrastructure was deployed using Terraform, creating:

AWS Config (recorder + rules)
CloudTrail (logging enabled)
S3 bucket (encrypted evidence storage)
Security Hub (enabled)

This ensures a controlled, compliant starting point.

Initial Compliance State

After deployment:

AWS Config begins evaluation
Initial state may show INSUFFICIENT_DATA
Eventually stabilizes into COMPLIANT / NON_COMPLIANT

This represents:

A baseline security posture before any drift

Simulating Real-World Misconfiguration

(ISO Control A.8.12 – Encryption of Data at Rest)

To simulate drift, an intentional violation was introduced:

Created an S3 bucket
Disabled default encryption

This represents a common real-world failure:

Data stored without encryption due to misconfiguration

Detection via AWS Config

AWS Config automatically evaluated the resource and flagged:

Rule: s3-bucket-server-side-encryption-enabled
Status: NON_COMPLIANT

Drilling into the resource:

Specific bucket identified
Evaluation result recorded
Timeline shows compliance change

This demonstrates:

Continuous monitoring instead of periodic audits

Aggregation via Security Hub

The same issue is surfaced in Security Hub as a finding.

Key observations:

Findings categorized by severity
Centralized visibility across services
Enables prioritization

This layer answers:

“Which issues matter most right now?”

Audit Evidence via CloudTrail

Detection alone is not sufficient — audit requires traceability.

CloudTrail provides that.

Relevant events:

CreateBucket
No encryption configuration applied

This proves:

The violation originated at resource creation, not later drift

Remediation Phase

The issue was fixed by:

Enabling S3 default encryption (SSE-S3)

After remediation:

AWS Config → COMPLIANT
Timeline updated with state transition

This completes the full lifecycle:

NON_COMPLIANT → FIX APPLIED → COMPLIANT

What This Demonstrates

1. Compliance is Dynamic

Traditional audits capture a snapshot.
Real systems require continuous validation.

2. Terraform ≠ Compliance

Terraform establishes a baseline, but:

Drift happens outside Infrastructure as Code

3. Detection vs Evidence

AWS Config → detects issues
Security Hub → aggregates
CloudTrail → proves what happened

Without CloudTrail:

You cannot defend your audit findings

4. Real Gap in Organizations

Most organizations:

Don’t monitor continuously
Don’t store evidence properly
Don’t validate remediation

Key Takeaway

This project moves ISO 27001 from:

Documentation-driven compliance

To:

Operational, continuously validated security posture

Final Thought

Compliance is not about passing an audit.

It’s about being able to answer:

What broke?
When did it break?
Who changed it?
Was it fixed?

This lab proves that with the right tooling,
ISO 27001 controls can be measured, enforced, and verified in real-time.

What’s Next

This was just one control (S3 encryption).

You can extend this to:

IAM MFA enforcement (A.5.23)
Logging validation (A.8.16)
Resource tagging (A.8.9)
Least privilege enforcement

If you’re building in cloud:

Start thinking in terms of control → detection → evidence → remediation

That’s where real security engineering begins.

Event-Driven EC2 Isolation in AWS: Building a Minimal Cloud SOAR Without Buying One

Sesank Munukutla (Naga) — Fri, 13 Feb 2026 16:56:02 +0000

Detection without response is operational noise.

GuardDuty alerts are valuable — but if a human has to read, decide, and manually isolate an instance, your blast radius window is still open.

I wanted high-confidence findings to trigger automatic containment.

So I built a minimal AWS-native SOAR pipeline.

No third-party tooling.

No overengineering.

Just deterministic, event-driven response.

🎯 Objective

Build an automated containment workflow that:

Responds only to high-severity GuardDuty findings
Automatically isolates compromised EC2 instances
Preserves forensic access
Avoids recursive execution
Is observable and debuggable

All event-driven. No polling. No manual trigger.

🏗 Architecture Overview

GuardDuty Finding
↓
EventBridge Rule (severity >= 7)
↓
Lambda Function (Isolation Logic)
↓
Modify EC2 Security Group → Quarantine SG
↓
SNS Notification (Visibility Layer)

Minimal. Deterministic. Cheap.

Filtering at the Event Layer (Not Inside Lambda)

Instead of checking severity inside the Lambda function, I filtered directly in EventBridge.

Why this matters:

Reduces unnecessary Lambda invocations
Makes response criteria explicit
Improves audit clarity
Lowers operational cost

Example event pattern:

{
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [ { "numeric": [">=", 7] } ]
  }
}

Only high-confidence findings trigger automation.

Everything else remains visible — but not auto-remediated.

Quarantine Security Group Design

Containment is not termination.

Terminating an instance destroys forensic evidence.

My quarantine security group:

❌ No outbound internet
❌ No inbound from public IP ranges
✅ Allow only SOC bastion IP
✅ Allow forensic collection host
✅ Optional: allow VPC Flow Logs / monitoring endpoint

The goal is isolation with controlled investigation access.

Isolation Logic (Lambda Example)

Core logic:

import boto3

ec2 = boto3.client('ec2')

def isolate_instance(instance_id, quarantine_sg_id):
    ec2.modify_instance_attribute(
        InstanceId=instance_id,
        Groups=[quarantine_sg_id]
    )

Additional safeguards added:

Check instance state before modification
Tag instance Quarantined=true
Exit if already isolated
Log original security groups for rollback

Containment must be idempotent.

Idempotency: Preventing Recursive Triggers

When Lambda modifies security groups, CloudTrail events may fire.

Without safeguards, you risk infinite loops.

Mitigation:

Tag check before modification
Structured event filtering
Explicit function logging
DLQ configured for failure cases

Automation that can repeat blindly is dangerous.

Failure Modes I Modeled

Automation amplifies mistakes.

I explicitly accounted for:

IAM permission drift
Partial security group modification
Concurrent findings on same instance
Cross-region GuardDuty setup
High-volume alert bursts

Mitigations:

Dead Letter Queue
Lambda concurrency limits
CloudWatch error metrics + alarms
Explicit structured logs (JSON format)
Permission boundary controls

Automation without observability becomes silent failure.

Impact

This reduced:

MTTR from minutes to seconds
Human triage fatigue
Decision bottlenecks
Inconsistent containment actions

But the real improvement was consistency.

Humans improvise during incidents.
Code executes predictably.

Trade-Offs & Risks

Auto-isolating compute is not trivial.

You must consider:

False positives at high severity
Production-critical workloads
Stateful applications
Already-compromised lateral movement
Multi-account architecture

Severity threshold tuning took longer than writing the Lambda function.

That surprised me.

Lessons Learned

Detection maturity does not equal response maturity.
Event-driven architecture scales better than polling remediation.
Idempotency is mandatory.
Multi-account containment becomes architecture work.
Automation exposes operational blind spots you didn’t know existed.

Next Iterations

If I evolve this into a more mature Cloud SOAR pattern:

Step Functions for multi-stage workflows
Automated EBS snapshot before isolation
Memory capture integration
Slack/Jira enrichment with context
Cross-account orchestration via AWS Organizations
GuardDuty central delegated admin integration

At that point, it becomes a response framework — not a script.

Final Thought

You don’t need a commercial SOAR platform to start automating response.

Start with:

Deterministic triggers
Guardrails
Observability
Explicit blast radius control

If detection isn’t wired to action, it’s just telemetry.

How to Implement Just-In-Time SSH Access for AWS EC2 (Stop Leaving Port 22 Open!)

Sesank Munukutla (Naga) — Wed, 11 Feb 2026 16:53:55 +0000

The problem: Most EC2 instances have permanent SSH access. Port 22 is open to the world. Long-lived keys floating around. Security groups that nobody remembers creating.

The reality: You get brute-force attempts within hours. Keys get leaked. Forgotten access stays forever.

I spent last week implementing Just-In-Time (JIT) access for EC2, and it completely changed how I think about server access. Here's what I built and what I learned.

What You'll Learn

✅ How to eliminate permanent SSH access to EC2
✅ Build auto-expiring access with native AWS services (no third-party tools)
✅ Set up full audit trails with CloudTrail
✅ Use Lambda to automate security group changes
✅ Apply least-privilege IAM design

Why JIT Access Matters

Permanent SSH access to EC2 is one of the most common and dangerous cloud misconfigurations.

Here's what happens when you leave SSH open:

🚨 Open port 22 = instant target for attackers
🚨 Long-lived SSH keys = credential sprawl
🚨 Forgotten security group rules = standing access nobody uses
🚨 No audit trail = "who logged in last month?"

JIT access solves this:

SSH access granted only when needed
Access is time-bound (expires automatically)
Revocation is automatic (no manual cleanup)
Every action is fully auditable

Architecture Overview

The solution uses only native AWS services:

Amazon EC2 – The target instance
AWS Lambda – JIT automation engine
IAM – Least-privilege roles
CloudTrail – Audit evidence
CloudWatch – Execution logs

Design principle:

No standing access. Access exists only while the automation is running.

Step 1: Lock Down the EC2 Instance (Baseline)

Start with zero access by default.

The EC2 instance is launched with:

❌ No inbound SSH rules
❌ No 0.0.0.0/0 on port 22
✅ Only necessary outbound access

Why this matters:

Eliminates permanent exposure
Forces all access through controlled mechanisms
Creates a secure baseline

Security group showing zero SSH access by default - no port 22 open

Step 2: EC2 IAM Role – SSM Only

The EC2 instance gets an IAM role with only the SSM managed policy.

Key point: The instance cannot modify its own security group.

This prevents:

Self-escalation attacks
Instance-level privilege creep
Unauthorised security group changes

Separation of duties is critical here.

EC2 instance role with only SSM permissions - cannot modify security groups

Step 3: CloudTrail for Auditability

CloudTrail is configured to log management events only.

This captures:

✅ Security group changes
✅ Who made the change
✅ When it happened
✅ What was modified

Why not data events?

JIT access modifies infrastructure, not data
Precision logging beats noisy logging
Lower costs, better signal-to-noise ratio

CloudTrail logging configuration - management events capture security group changes

Step 4: JIT Lambda Function

The core automation: a Lambda function that controls the access lifecycle.

What it does:

Grant – Add SSH rule for a single IP
Wait – Hold access for configured duration
Revoke – Remove the rule automatically

Lambda pseudo-code:

def lambda_handler(event, context):
    # Read configuration from environment variables
    security_group_id = os.environ['SECURITY_GROUP_ID']
    allowed_ip = os.environ['ALLOWED_IP']
    duration = int(os.environ['DURATION'])  # seconds

    # Grant SSH access
    ec2.authorize_security_group_ingress(
        GroupId=security_group_id,
        IpPermissions=[{
            'IpProtocol': 'tcp',
            'FromPort': 22,
            'ToPort': 22,
            'IpRanges': [{'CidrIp': f'{allowed_ip}/32'}]
        }]
    )

    # Wait for configured duration
    time.sleep(duration)

    # Revoke SSH access automatically
    ec2.revoke_security_group_ingress(
        GroupId=security_group_id,
        IpPermissions=[{
            'IpProtocol': 'tcp',
            'FromPort': 22,
            'ToPort': 22,
            'IpRanges': [{'CidrIp': f'{allowed_ip}/32'}]
        }]
    )

Step 5: Lambda Configuration via Environment Variables

All JIT behavior is externalized:

SECURITY_GROUP_ID – Which security group to modify
ALLOWED_IP – Which IP gets access
DURATION – How long access lasts (seconds)

Why environment variables?

✅ No hardcoding
✅ Easy to audit
✅ Safe to change duration without code changes
✅ Works across environments (dev/staging/prod)

Lambda configuration externalized - no secrets hardcoded in the function

Step 6: Least-Privilege Lambda Execution Role

The Lambda execution role gets only the permissions needed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:RevokeSecurityGroupIngress"
      ],
      "Resource": "arn:aws:ec2:*:*:security-group/sg-xxxxxxxxx"
    }
  ]
}

This enforces:

Separation of duties
Minimal blast radius
Defense in depth

IAM policy allowing only security group ingress modifications - nothing else

Step 7: JIT Execution (Grant → Revoke)

When you execute the Lambda:

Timeline:

00:00 – Lambda starts
00:01 – SSH access GRANTED for 203.0.113.45/32
05:00 – Access active (you can SSH in)
10:00 – SSH access REVOKED automatically
10:01 – Lambda completes

Key log evidence:

✅ SSH access granted (CloudWatch)
✅ SSH access revoked (CloudWatch)
✅ Execution duration ≈ configured timeout
✅ No manual intervention

This confirms true JIT behavior, not manual cleanup.

The smoking gun: Logs prove access was granted at 00:01 and auto-revoked at 10:00

Step 8: CloudTrail Proof (Audit Evidence)

CloudTrail records both sides of the access lifecycle:

Grant event:

{
  "eventName": "AuthorizeSecurityGroupIngress",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAXXXXXXXXX:jit-lambda-function"
  },
  "requestParameters": {
    "groupId": "sg-xxxxxxxxx",
    "ipPermissions": {
      "items": [{
        "ipProtocol": "tcp",
        "fromPort": 22,
        "toPort": 22,
        "ipRanges": ["203.0.113.45/32"]
      }]
    }
  }
}

Revoke event:

{
  "eventName": "RevokeSecurityGroupIngress",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAXXXXXXXXX:jit-lambda-function"
  }
}

What this proves:

📊 Who made the change (Lambda role)
📊 What was changed (security group rule)
📊 When it happened (timestamp)
📊 That it was revoked (not forgotten)

This is audit-grade evidence, not just console screenshots.

CloudTrail proof #1: Lambda granted SSH access for specific IP at exact timestamp

What This Project Demonstrates

✅ No standing SSH access – Zero permanent exposure

✅ Time-bound, IP-restricted – Access expires automatically

✅ Automatic revocation – Enforced by code, not humans

✅ Full auditability – CloudTrail logging for compliance

✅ Least-privilege IAM – Minimal permissions everywhere

The 5 Mistakes I Made (So You Don't Have To)

Forgot to add CloudWatch Logs permissions – Lambda couldn't log execution
Used 0.0.0.0/0 in testing – Defeated the entire point
Didn't externalize duration – Had to redeploy Lambda to change timing
Set timeout too short – Lambda terminated before revoking access
Didn't test CloudTrail delay – Events take 5-15 minutes to appear

Final Takeaway

Security isn't about blocking access — it's about granting the right access, for the right time, with proof.

This project shows how JIT access can be implemented using native AWS services without introducing operational complexity or permanent risk.

No third-party tools. No manual cleanup. Just automatic, auditable, time-bound access.

What's Next?

In the next post, I'll cover:

Integrating this with AWS Systems Manager Session Manager (no SSH at all!)
Adding Slack notifications when access is granted
Building a self-service portal for developers

Have you implemented JIT access in your environment? What challenges did you face?

Drop a comment below or connect with me on LinkedIn.

Series: AWS Security Projects

This is part of my Friday Security Projects series, where I build hands-on cloud security projects focused on real-world failures and defence-in-depth design.

Previous projects:

Project 5: Zero-Trust EC2 Access with IAM, SSM, and GuardDuty
Project 4: Eliminating SSH with AWS Systems Manager
Project 3: Implementing Security Controls in Production
Project 2: Security Design Trade-offs
Project 1: Building a Secure Cloud Baseline