CASE STUDY · CLOUD SECURITY (CSPM / CWPP)
Implementing CWPP across a multi-cloud environment in 6 weeks.
- 92%92% of critical assets covered by week 6
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Workload agents, permission policies and exception alerts, rolled out in phases over 6 weeks.
- 1The company ran workloads across two clouds.
- 2Each side had its own tools, its own logs and its own idea of normal.
- 3Nobody could say what was running inside the workloads, or whether anything unusual was happening.
- 4Alerts, where they existed, went to different inboxes and depended on who happened to be watching.
- 5The security lead wanted one view and a clear way to act on it, without slowing the delivery teams.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01The first wave raised a flood of alerts
A legitimate deployment tool started shells and opened outbound connections in ways the default policy treated as suspicious. The queue filled up and engineers began to ignore it, which is the exact outcome we were there to prevent.
- PROBLEM 02We paused enforcement, tuned the policy against a week of observed behaviour, and wrote explicit allow rules for known tooling
Then we changed the plan. Every later wave ran in monitor-only mode long enough to learn its normal pattern before anything was blocked. The delay to the schedule was small, and the later waves were quiet.
- PROBLEM 03The delay to the schedule was small, and the later waves were quiet
03 · THE PROCESS
How we ran it.
The rollout followed risk, not the org chart.
- 01Weeks 1 and 2
inventory of workloads on both clouds, classification by data sensitivity, and agent testing in a non-production environment.
- 02Weeks 3 to 5
phased rollout, starting with the workloads that handle the most sensitive data. Each wave ran in monitor-only mode first, then moved to enforcement.
- 03Week 6
alert routing, exception handling and handover.
We held a short check-in with the platform team after every wave, and a weekly review with the security lead. Each wave had a go or no-go point, agreed in advance.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
One alert queue, one owner per alert and one agreed response path across both clouds.
- NOW 02
New workloads are onboarded with the agent and policy already in place.
- NOW 03
Policy exceptions are recorded, reasoned and reviewed.
- NOW 04
The platform and security teams plan rollouts together and use monitor-only mode before enforcement.
- 92%
92% of critical assets covered by week 6
Alerts routed into a single queue
05 · WHAT WE BUILT
How it works.
- Agents were deployed to VMs and containers, with a lighter approach for serverless functions.
- Runtime policies covered process behaviour, unexpected outbound connections, file changes in sensitive paths and vulnerable images.
- Permission policies limited what each workload could do, so a compromised service could not reach everything around it.
- Alerts from both clouds were normalised and sent into a single queue.
- Each carried a severity, an owner and a suggested first action.
- We wrote exceptions down with a reason and a review date.
- Controls and monitoring
- Each wave had an agreed rollback: remove the agent, restore the previous policy. We watched agent health, CPU and memory impact on every workload, and compared them with the pre-rollout baseline. One legacy VM showed a visible slowdown, so we gave it a lighter policy and recorded the reason as an exception.
- Handover
- The platform team now owns agent deployment inside their pipeline. The security team owns policy and the alert queue. We wrote a one-page guide that says who changes what, and how a policy change moves from proposal to enforcement.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company ran workloads across two clouds. Each side had its own tools, its own logs and its own idea of normal. Nobody could say what was running inside the workloads, or whether anything unusual was happening. Alerts, where they existed, went to different inboxes and depended on who happened to be watching. The security lead wanted one view and a clear way to act on it, without slowing the delivery teams.
- What did Brandsmashers build?
- Workload agents, permission policies and exception alerts, rolled out in phases over 6 weeks.
- How was the work run?
- The rollout followed risk, not the org chart.
- What were the results?
- 92% of critical assets covered by week 6; alerts routed into a single queue.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
