Forem: Caesar Chan

ISO 27001 in 6 Months

Caesar Chan — Sun, 23 Nov 2025 14:00:48 +0000

Working in a B2B startup, an ISO 27001 certification is often requested by our enterprise clients and partners. However, with a lean team and tight deadlines, traditional manual processes seemed daunting.

By leveraging GRC automation platforms, we were able to streamline our compliance journey and achieved certification in just six months, proving that even resource-constrained startups can prioritize security without sacrificing speed.

What's ISO 27001?

ISO/IEC 27001:2022 is an international standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). It helps organizations manage risks to information assets through a structured framework of controls. For startups handling sensitive data like ours, certification signals maturity and builds trust with partners.

Startup Challenges in Compliance

Startups often juggle limited budgets, small teams, and rapid scaling, making full compliance feel overwhelming. Manual documentation and audits can consume months. In our case, as a cloud-native firm, we dealt with dynamic environments like AWS and Kubernetes, complicating control implementation. Without automation, the process might have stretched to multiple years.

Luckily, compliance automation tools are getting more and more mature. They helped small companies like us address these pain points by automating evidence collection and integrations.

It's actually easier to achieve compliance when the company is still small, as everything starts from scratch without entrenched legacy processes or sprawling systems to overhaul. This clean slate allowed us to embed security controls from the ground up.

Why Vanta?

The compliance automation market offers many alternatives like Drata, Scrut, Sprinto, and others, each with strengths in areas such as pricing or specific frameworks.

We evaluated these options but picked Vanta for its proven track record, unmatched reliability, extensive library of automated test cases, and over 400 integrations that covered our entire tech stack. This depth of automation reduced manual work by at least 80%, making it ideal for our lean team.

6-Month Roadmap to Certification

Months 1: Preparation

We kicked off by securing executive buy-in and forming a cross-functional team of three: our lead engineer, CISO, and myself.

Vanta provides policy templates for reference, which we used to draft our initial information security policies. By the end of the month, we had all the necessary policies, procedures and standards drafted and waiting to be approved.

The Vanta dashboard gave us a great overview of our compliance status, displaying a real-time percentage of completion that allowed us to keep track of the progress. The percentage can be further broken down into Documents and Automated tests.

Month 2-3: ISMS Development and Risk Assessment

Using Vanta's automated assessment, we conducted a gap analysis against the controls in ISO 27001. This showed us the percentage of controls having passing evidence.

With the gaps in mind, we gradually worked towards full compliance using Vanta's built-in resources. We performed a formal risk assessment, identifying assets like customer data, and evaluating threats per ISO 27005 guidelines.

Vanta automated risk scoring and treatment plans, recommending controls such as MFA and regular vulnerability scans. We implemented around 70% of controls here. We then leverage Vanta integrations to monitor compliance continuously.

Plicies and documentations were centralized in Vanta. Employees' policy acceptance was also tracked under it. Vanta also helps with vendor management by automating third-party risk assessments.

Month 4: Internal Audit

For the internal audit requirement, we decided to outsource it to a third-party at a reasonable cost. This was the best option for us in terms of speed. Having someone professional to vet our works before the actual external audit, definitely gave us a peace in mind.

The deliverable of the outsourced internal audit is a list of potential non-conformities and observations. Our team would then try to resolve any major or minor non-conformities ASAP.

Month 5: Stage 1 Audit

We selected a certification body from Vanta's network of partner audit firms, which made the process seamless.

The Stage 1 audit was basically the documentation review. It involved the auditor examining our ISMS design, scope, and policies remotely via calls. Vanta's centralized dashboard provided instant access to our SoA, risk assessments, and policies, impressing the auditor with our preparedness. They identified no major gaps, only suggesting refinements in our risk treatment process, which we addressed pre-Stage 2 audit.

This stage confirmed that our ISMS aligned with ISO 27001 requirements, validating our automated approach.

Month 6: Stage 2 Audit and Certification

Stage 2 focused on verifying implementation through interviews, evidence review, and on-site checks. Over a week, auditors reviewed our automated test cases on Vanta. Vanta's real-time evidence collection from our tech stacks like AWS, Entra ID, Snyk, etc. saved us weeks of manual work.

We resolved a few observations, such as formalizing HR onboarding, within the audit window. By month's end, we received certification, valid for three years, with annual surveillance audits planned. The partner auditor network ensured smooth coordination, avoiding common delays in finding qualified firms.

Key Benefits and Lessons Learnt

Achieving ISO 27001 boosted our credibility, helping us secure a major client in the crypto industry.
Costs stayed manageable, including Vanta's subscription and audit fees, far below manual alternatives.
Automation not only sped up the process but embedded security into our DevSecOps pipeline.

For fellow cybersecurity professionals, the takeaway is clear:

Compliance automation tools transform ISO 27001 from a burden into a strategic advantage, especially when starting small.
Prioritize platforms with strong integrations and track records.

The 5 Steps of Threat Modeling in a Startup

Caesar Chan — Sat, 08 Nov 2025 14:46:02 +0000

From STRIDE-LM to ISACA’s 5 Steps: Leveling Up Threat Modeling in a Startup

For the past few years, we relied on STRIDE-LM to perform ad hoc threat modeling across our product stack. It served us well in identifying technical threats and structuring security reviews. But over time, we found a recurring gap: our process rarely addressed business context or risk appetite. Threat lists were comprehensive, but often disconnected from what really mattered to business, say, customer trust, operational resilience, and regulatory exposure. We knew it was time to raise the bar.

Why ISACA’s 5 Steps Work Surprisingly Well (Even for a 2-Person Team)

When we discovered ISACA's whitepaper Threat Modeling Revisited, our initial skepticism was quickly dispelled. At first glance, the approach looked “enterprisey”. However, as we dug deeper, we realized it’s actually lean and adaptable for small teams.

Here’s how we put it to work and what each step delivered:

1️⃣ Identify Business Objectives and Define Scope

Instead of modeling random components that come into our way, we prioritize business outcomes (regulatory compliance, up-time, customer privacy).

Outcome: A shared understanding of what’s most critical to protect, aligning engineering and security on what matters.
How security fit it in: Join the weekly agile business refinement. During the meeting, we assess if there are any new or changed business objectives, or features that might impact security.
- If no new security concerns arise, we consider it case closed. This keeps workload efficient and avoids unnecessary meetings.
- If yes, we proceed to step 2.

2️⃣ Map the Business Ecosystem

We sketched diagrams of data flow, trust boundaries, and external integrations, flagging out vendor dependencies and sensitive data handling.

Outcome: Visual clarity over where threats lie, plus a direct way to spot weak points and key integrations.
How security fit it in: Sketch simple diagrams in Draw.io just enough to support risk discussions.

3️⃣ Identify and Prioritize Threats

We still applied STRIDE-LM to technical assets, but for each we now asked: How does this impact business objectives? We focused on threats with real business consequences (regulatory fines, cash losses, brand damage).

Outcome: A ranked list of threats mapped directly to business objectives.
How security fit it in: Brainstorm and rank threats for what’s in active development, simply using an Excel sheet on SharePoint.

4️⃣ Develop Mitigation Strategies

Mitigations were scoped to what was actually actionable and tracked in Jira. If a threat couldn’t be resolved in the same sprint, we would document it as a risk and request follow-up.

Outcome: Action items with owners, and a clear backlog of residual risks.
How security fit it in: Document mitigation in the sprint documentation. Create new risk scenarios if not mitigated within the sprint.

5️⃣ Review, Validate, Iterate

Instead of a dedicated formal review, we blended in threat model reviews as part of our quarterly "security retros". We would adjust risk posture and update our mitigation backlog.

Outcome: Continuous improvement and stakeholder communication, keeping the risk register alive and always relevant.
How security fit it in: Use quarterly retros as check-ins, keeping sessions under an hour.

Consolidating Outcomes with Our Risk Register

A key benefit of ISACA’s approach is that every prioritized threat and mitigation fed directly into our Risk Register. Identified threats with business consequences became new entries, each assigned a risk owner, mitigation plan, and review date. This made our register a living document. It's no longer just a compliance checkbox, but an active tool for tracking security outcomes in line with the company’s risk appetite.

Lessons Learnt

STRIDE-LM gave us a solid technical footing, but ISACA’s 5 steps brought context and business alignment.
The framework is manageable even for a two-person security team, if you stay focused, build on what’s already working, and ruthlessly prioritize.
Threat modeling outputs are naturally actionable as risk register updates, making executive consensus and compliance reporting much easier.
You can move fast and still be strategic about security, if you align with business outcomes.
Lean teams benefit most from clarity and focus, not exhaustive lists.
Continuous improvement, not one-off exercises, delivers real value.

From Permanent Access to Just-in-Time: A Startup's IAM Journey Part 3

Caesar Chan — Sun, 19 Oct 2025 03:19:01 +0000

This is the final post in our 3-part series on revamping our cloud IAM. Be sure to check out Part 1 and Part 2 if you haven't already.
In Part 2, we walked through the detailed, 4-phase implementation of our Just-in-Time access model.

The Flaw

During our implementation, we found an obvious security flaw. Our initial IAM roles in all member accounts had a trust policy that allowed any principal within the landing account to assume them.

The Original Trust Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root" 
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

This configuration meant that if any user or service within the landing account were compromised, the attacker could pivot and assume these privileged roles.

We fixed this by updating the policy to be highly specific, using a Condition to ensure that the role could only be assumed by a specific, AWS SSO-generated role.

The Improved Trust Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:role/aws-reserved/sso.amazonaws.com/ap-southeast-1/AWSReservedSSO_SecurityTeam_1a2b3c4d5e7f8a9b"
        }
      }
    }
  ]
}

This aws:PrincipalArn is the specific SSO IAM role that links back to our IAM Identity Center permission set, ensuring only the right employee coming from the right team can access the role.

Lessons Learnt

A technical solution is only half the battle. The real challenge is making security an enabler, not a barrier. We learned two major lessons along the way.

Lesson 1: JIT access requires a gentle introduction

The Problem: When we first rolled out the JIT model, our Dev and Infra teams were confused, leading to a surge in access-related support tickets.
The Fix: We realized technology alone wasn't enough. We implemented company-wide training sessions, created detailed architecture diagrams and documentation, and set up Slack notifications for faster access approvals. This transformed the process from a point of friction into a streamlined, understandable workflow.

Lesson 2: Least privilege should be a journey, not a decree

The Problem: We initially took a very strict least privilege approach, locking down roles to the bare minimum permissions. This backfired. Teams constantly hit permission walls, velocity dropped, and the security team was seen as a blocker.
The Fix: We pivoted to a "trust with monitoring" approach. We started with broader, role-based permissions and implemented continuous governance using IAM Access Analyzer. Now, we regularly monitor and remove unused permissions, delete dormant roles, and track utilization metrics, achieving least privilege without hindering productivity.

Moving Forward

Our journey from permanent access to Just-in-Time IAM wasn't just about implementing new technology. It was about changing how we think about security in a fast-moving startup environment. We eliminated standing privileges, closed critical security gaps, and most importantly, proved that security and velocity aren't opposing forces.

The key insight? Security transformations succeed when you treat them as change initiatives, not just technical projects. Start with the people, iterate on the permissions, and let monitoring guide you toward true least privilege over time.

If you're considering a similar shift in your organization, remember that perfection is the enemy of progress. Ship something functional, gather feedback, and refine continuously. Your security will strengthen, and you'll build something no compliance framework can measure: a culture where security and velocity aren't trade-offs.

From Permanent Access to Just-in-Time: A Startup's IAM Journey Part 2

Caesar Chan — Thu, 16 Oct 2025 02:53:50 +0000

This is the second post in our 3-part series on implementing Just-in-Time access. In case you missed it, you can find Part 1 here.

In Part 1, we outlined the significant security risks of our "always-on" access model and introduced the blueprint for our new JIT architecture using AWS and Entra ID.

The Implementation

Now, let's dive into the step-by-step plan we followed to bring this architecture to life.

Phase 1: Design and AWS Configuration

This phase was about laying the groundwork within our AWS Organization.

First, we held workshops to discuss and agree upon the new AWS IAM Groups and Roles needed for different teams (e.g., Infra, Dev, Product). This ensured the new structure met business needs.

We then built the core components in AWS.

In our AWS Management Account, we created new IAM Identity Center Permission Sets at the organization level, which define the granular permissions for each job function.

In our AWS Landing Account, we created new IAM Policies specifically designed to allow users to switch roles into the production and non-production accounts.

Sample Landing Account Switch Role Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::111111111111:role/InfraRole",
                "arn:aws:iam::222222222222:role/InfraRole",
                "arn:aws:iam::333333333333:role/InfraRole"
            ]
        },
        {
            "Effect": "Deny",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::111111111111:role/SecurityRole",
                "arn:aws:iam::222222222222:role/SecurityRole",
                "arn:aws:iam::333333333333:role/SecurityRole"
            ]
        }
    ]
}

Finally in our AWS member accounts, we created the new target IAM Roles that users would ultimately assume to do their work, e.g. arn:aws:iam::111111111111:role/InfraRole.

Phase 2: Entra ID Integration and Configuration

With AWS ready, we connected our identity provider (IdP).

We set up the federation by connecting Entra ID SSO with IAM Identity Center. This allows AWS to trust Entra ID for user authentication.
Next, we mapped our Entra ID Groups with the IAM Identity Center Groups to ensure that a user in a specific Entra ID group (e.g., "Infra Team Production") would be associated with the correct permissions in AWS.

A crucial step was to configure Entra ID PIM on the production access groups, enabling the JIT request and approval workflow.

We also had to revamp our Conditional Access rules in Entra ID to enforce stronger authentication requirements (e.g. phish-resistant MFA, MDM compliance) when users access AWS production.

Phase 3: User Migration and Go-Live

This was our phased roll-out to users.

We started by assigning a few pilot users to the new groups for testing, allowing us to iron out any kinks in the workflow.
Pilot users will test out the entire self-service access request flow.

Once the pilot was successful, we proceeded to reassign all other users to the new groups according to their job function.

Phase 4: Cleanup and Hardening

The final and most important phase was to remove the old, insecure configurations.

Cleanup

We enabled IAM Access Analyzer in our organization management account to begin monitoring for overly permissive or unused access.
We began a process of removing obsolete IAM Policies, Accounts, Groups, and Roles.
Critically, we removed all permanent, long-lived CLI access keys used by employees, forcing all CLI access through the new temporary credential model.

Hardening

Finally, we performed a security review to lock down all IAM role trust policies, ensuring they could only be assumed by the specific IAM Identity Center roles, as detailed in the final part of the series.

With the 4 phases of our implementation covered, the technical foundation is now in place. However, the journey doesn't end with deployment. In the final part of our series, we'll zoom in on a security policy fix we discovered and share the lessons we learned about balancing security with developer productivity.

From Permanent Access to Just-in-Time: A Startup's IAM Journey Part 1

Caesar Chan — Fri, 10 Oct 2025 09:37:47 +0000

This post is the first in a 3-part series detailing our journey to secure cloud access.

In a FinTech startup, speed and agility are paramount. But as many of us in the security field know, rapid growth can often lead to "chaos", especially when it comes to cloud infrastructure access. My journey at a startup began with untangling this challenge. We had a classic case of an "always-on" access model, and it was clear we were at risk.

This is the story of how we moved from a state of risky permanent access, to a secure and efficient Just-in-Time (JIT) model.

The Problem

When we first assessed our AWS environment, we found several security issues that are common in rapidly scaling companies:

Single-Factor Authentication: Multi-Factor Authentication (MFA) was not universally enforced for our AWS console logins, leaving a gaping hole in our first line of defense.
Permanent "Always-On" Access: Engineers had a static path directly into both non-production and production environments. Many had generated permanent AWS access keys, which, if leaked, could provide an attacker with a persistent backdoor.
Overly Permissive Roles: Developers were often granted broad IAM roles with administrative privileges across multiple services and environments.
No Separation of Duties: A single access path could be used by an engineer to reach every environment, from development all the way to production.
Lack of Just-in-Time (JIT): There was no system for engineers to request and receive temporary, time-bound access for specific tasks.

This setup was a breeding ground for potential disasters, from account hijacking to insider threats to ransomware and cloud cryptomining.

Leaked AWS credentials quite often leads to "silent compromises", where attackers use stolen keys to encrypt S3 buckets and demand a ransom, all without triggering alerts:

The Blueprint

We knew we had to act. Our mission was to revamp our IAM strategy completely. We set clear end goals:

Implement risk-based MFA.
Eliminate all permanent human access to production.
Enforce the principle of least privilege for every IAM role.
Establish a clear separation of duties.

To achieve these, we chose a modern tool-set designed for cloud-native environments: AWS IAM Identity Center, AWS IAM Access Analyzer, Entra ID Privileged Identity Management (PIM) and Entra ID Conditional Access.

We've now covered the security gaps that prompted this project and the high-level blueprint for our new Just-in-Time model.

In the next part of this series, we’ll roll up our sleeves and walk through the detailed, 4-phase implementation plan we followed, from initial AWS configuration to the final cleanup.