Skip to content

06/SECURE YOUR INFRASTRUCTURE

A customer started asking security questions.

A prospect has sent a security questionnaire, or an auditor has asked how access is controlled, or a customer contract now has requirements attached to it.

You suspect the answers are mostly fine and you cannot demonstrate any of them, which in practice is the same as not having them.

The AWS account grew as the company did. Permissions were granted to unblock people and rarely revoked, and there are credentials in places nobody wants to think about.

You need to know what the actual gaps are, in the order they matter, before someone else finds them.

01/Why it happens

It is nearly always one of these three.

  1. Permissions accumulate and never get removed

    Access is granted under deadline pressure and revoking it has no urgency behind it. Over a few years, most accounts hold broad permissions attached to people and services that no longer need them.

  2. Secrets end up wherever they were convenient

    Environment files, CI variables, a message thread, an old commit. Rotation is rare because nobody is confident they know every place a credential is used.

  3. Logging exists but nothing reads it

    CloudTrail is on and the logs are retained, which is not the same as detection. Without alerting on the events that matter, the audit trail only helps after you already know something happened.

02/What we do about it

The engagement, phase by phase.

  1. Review the environment

    one to two weeks

    IAM policies and roles, network boundaries and exposure, encryption at rest and in transit, secrets handling, logging coverage and backup integrity. Findings are ranked by exploitability and impact rather than by scanner severity.

    Produces

    A findings document, ordered by real-world risk

  2. Close the exposed gaps

    days, scheduled immediately

    Anything reachable from the internet that should not be, and any credential in the wrong place, is dealt with first and separately from the rest of the plan.

    Produces

    Public exposure and credential problems resolved

  3. Tighten access

    two to four weeks

    Permissions reduced against measured usage rather than guesswork, applied in stages with monitoring, so tightening access does not break a job nobody remembered.

    Produces

    Least-privilege roles, with the old permissions removed

  4. Make it evidenceable

    about a week

    Logging coverage completed, alerts on the events that matter, and a plain description of each control — which is what a questionnaire or an auditor actually asks for.

    Produces

    Audit logging, alerting and a written control description

03/What done looks like

How you will know it worked.

  • No unintended public exposure of storage, databases or admin interfaces
  • IAM permissions reduced to what is measurably used, with roles over long-lived keys
  • Secrets held in Secrets Manager or Parameter Store, with rotation possible
  • Encryption in transit and at rest across data stores and backups
  • CloudTrail complete, retained, and alerting on the events that matter
  • Backups tested by restoring one, not by checking a box
  • A written control description you can hand to a customer or an auditor

04/Honest caveats

Where this gets harder.

Every engagement has failure modes. Here are this one’s, before you commit to anything rather than after.

  • This is a security review, not a formal certification or a penetration test. It improves your position and produces evidence; it does not by itself make you compliant with a specific standard.
  • Tightening permissions on a live environment carries a real risk of breaking something undocumented. We stage it and monitor, and that is why it takes weeks rather than an afternoon.
  • Security findings have a shelf life. An environment that changes weekly needs periodic review, not one pass.
  • Some findings will need application changes rather than infrastructure changes, and those are scoped separately because they are engineering work.

05/Questions

Secure your infrastructure, asked about.

01

Is this a penetration test?

No. This is a configuration and access review of your AWS environment from the inside — how permissions, boundaries, encryption and logging are set up. A penetration test attacks from the outside, and the two answer different questions.

02

Can you help with a security questionnaire?

Yes. The written control description that comes out of the final phase is aimed at exactly that, and it is considerably easier to complete a questionnaire when the underlying controls have been reviewed first.

03

Will tightening permissions break things?

It can, which is why it is staged rather than applied at once. Permissions are reduced against measured usage, changes go out in batches, and monitoring stays on afterwards so anything that was quietly relying on old access surfaces quickly.

Sound familiar?

Describe your version of it. You will get a reply from an engineer within one business day, including if we think you do not need us.