Cloud and Application Hardening
An organisation running applications on cloud infrastructure configured during a rush to launch, with credentials shared informally, permissions granted broadly, and backups that have never been restored.
The problem
The infrastructure works, which is the problem. Nothing has forced a review, and the configuration reflects whoever set it up under time pressure.
In scope
- Identity and access
- Network exposure
- Secrets management
- Logging and monitoring
- Backup and tested restore
- Patching position
- A hardened baseline documented so future systems start correctly
Out of scope
- Application code rewriting.
- Migrating between providers.
- Building a security operations centre or providing 24-hour monitoring — worth stating, because buyers conflate hardening with monitoring.
What this would cover
Grouped by module — open the ones you want to read.
Identity
- Accounts, roles, least privilege, multi-factor enforcement, removal of shared logins and dormant accounts, and a process for departures
Network
- What is exposed to the internet and whether it needs to be; administrative interfaces reachable publicly are the most common finding
Secrets
- Keys, credentials and tokens out of code and configuration files, into a managed store, with rotation
Logging
- What is logged, where it goes, whether it is tamper-evident, and whether anything generates an alert a human sees
Backup and restore
- Schedule, encryption, offsite copy, retention, and a restore actually performed and timed, because an untested backup is a belief
Patching
- Current position, and a cadence the organisation can realistically sustain
Baseline
- The hardened configuration documented, so the next environment starts from it rather than repeating the original rush
Deliverables
- Current-state assessment, hardening changes implemented within agreed windows, documented baseline, tested restore evidence, runbook for the organisation's own team
Data model
- Not a build in the software sense — this delivers configuration changes and documents: a current-state assessment, a documented hardening baseline, tested restore evidence and a runbook.
Invariants
- Not applicable — this is a hardening engagement, not a deployed system. The one structural rule: every change is made inside an agreed window, with a rollback and a named owner, never applied silently.
Offline behavior
Not applicable.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Hardening breaks things, and the breakage lands on people who did not ask for the work.
Removing a shared login that three staff quietly depend on stops their day. Closing an exposed port disables an integration nobody documented. Every change needs a window, a rollback, and a named person who knows what changed — and the organisation has to accept some disruption. A hardening engagement done without change windows to avoid disruption will be reversed within a week by whoever it inconvenienced.
Multi-factor enforcement is where these engagements stall, particularly with senior staff and particularly where people share devices.
It is a policy decision that the organisation must make and enforce. Afivox can implement it; only the organisation can require it.
End state
What would be true about their day once this is running.
- Access is individual, least-privilege and multi-factor, and departures remove it.
- Nothing administrative is exposed to the internet that does not need to be.
- Secrets are in a store and rotated.
- Logs exist and something watches them.
- A restore has been performed, timed and documented.
- The next environment starts from a written baseline.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review