APHS was one of the first customers for Cisco Secure Workload, and has built a global professional services practice around it in the decade since — taking organisations from the first traffic-visibility exercise through to enforced, least-privilege policy on the applications they cannot afford to break.
Our practice
A dedicated Secure Workload practice
We were among the first organisations to adopt the platform, when Cisco launched it as Tetration in 2016, and we fed our experience from those early deployments back to Cisco as the product matured. Very little of what Secure Workload does today is new to us.
A decade on it is not a side line. It is the platform our security consultants work on daily, across estates that span on-premises data centres, Azure, AWS, GCP, Kubernetes and mainframe.
Cisco recommends APHS for Secure Workload professional services.
We work internationally, wherever the estate is, and we bring the same team through the whole programme rather than handing a design to someone else to implement. That continuity is usually what separates a segmentation project that reaches enforcement from one that stops at a dashboard.
We are platform-literate rather than platform-blinkered. Alongside Secure Workload we work with Cisco ACI and Nexus, Algosec BusinessFlow and FireFlow, and VMware NSX and vRNI — so when Secure Workload is not the right enforcement point for a particular segment, we will say so.
The platform
What Secure Workload does
If you are still evaluating, this is the short version. Secure Workload builds a live picture of how your applications actually talk to each other, proposes least-privilege policy from that evidence, lets you test the policy against real traffic, and then enforces it.
Visibility
Telemetry from software agents on the workload, and agentless sources such as NetFlow, ERSPAN, IPFIX and cloud flow logs. Alongside the traffic it collects installed packages, open ports and process hierarchy, so a workload is described by what it runs as well as what it talks to.
Dependency mapping and policy discovery
Machine-assisted grouping of workloads into logical clusters, and recommended policy derived from observed traffic rather than from an out-of-date spreadsheet.
Policy analysis before enforcement
Proposed policy is run against live traffic and shows you what it would have permitted and dropped. This is the step that makes enforcement survivable, and the step most often skipped.
Enforcement
Policy is applied at the workload by the agent, and through infrastructure enforcement points including firewalls, cloud security groups and load balancers, so segments without an agent are not left open.
Vulnerability and behaviour
CVE inventory per workload, filtered by package and severity, plus behavioural anomaly detection mapped to the MITRE ATT&CK framework.
How it is run
Either as a Cisco-hosted SaaS service, reached through Cisco Security Cloud Control, or on-premises as a physical or virtual appliance where data residency or air-gap requirements demand it. We deliver both, and we will give you an honest view on which suits your estate.
Professional services
What we do with it
Engagements are usually assembled from these. Most organisations start with an assessment and take it from there.
01
Assessment and readiness
A grounded view of what you have, what it will take, and what will get in the way — agent coverage, unsupported operating systems, appliances that cannot take an agent, and the segments someone else manages.
02
Design and build
Scoping, sizing and architecture for SaaS or on-premises deployment, including the scope hierarchy and naming that everything downstream depends on. Get this wrong and you rebuild in year two.
03
Agent deployment at scale
Packaging, phased rollout and remediation across thousands of workloads, working with the server, cloud and application teams who own them rather than around them.
04
Policy discovery and authoring
Running discovery, cleaning up the clusters it produces, and turning them into policy that application owners recognise and are prepared to sign off.
05
Enforcement rollout
Moving applications from analysis to enforcement one at a time, with a defined rollback, so nothing goes into enforcement that has not been proven against live traffic first.
06
Upgrades, health checks and migration
Version upgrades, cluster health checks, remediation of drifting policy, and migration between form factors or from an ageing Tetration deployment.
07
Integration
Connecting Secure Workload to the rest of the estate — firewalls and ACI, identity, CMDB and ticketing — so policy change follows your existing change process rather than sitting outside it.
08
Support, training and handover
Training your team on the platform and on the policy model you now own, with support that continues until they are genuinely ready to run it themselves.
09
Managed operation
Where a team is not yet in place, we operate the platform and the policy lifecycle on your behalf, and build the internal capability in parallel.
Coverage
Sectors and estates we have taken it into
Our Secure Workload work has been concentrated in financial services, government, critical national infrastructure, energy and education — sectors where an application broken by bad policy is a regulatory event, not simply an outage. That shapes how we work: nothing reaches enforcement until it has been proven against live traffic.
Segmentation programmes are judged on the awkward parts of the estate, not the easy ones.
Physical and virtual servers in on-premises data centres. Workloads in Azure, AWS and GCP. Containerised applications on Kubernetes and OpenShift. Mainframe. And the parts nobody wants to talk about: operating systems past end of support, appliances that will never take an agent, and segments run by a third party under someone else’s contract.
Those are the places where a policy model either holds together or quietly develops holes. They are the first thing we ask about.
Hard-won
Where Secure Workload programmes stall
We are usually called in either at the start, or after a first attempt has run aground. The pattern is consistent enough to be worth writing down.
Enforcement before dependency mapping
The fastest way to break a production application and lose the organisation’s confidence in segmentation for two years.
Agent coverage gaps
Partial coverage does not give you a partial picture, it gives you a misleading one. Traffic from uninstrumented hosts looks like traffic from nowhere.
Policy written without application owners
Policy authored purely by the network team gets challenged the first time something breaks, and enforcement stops. The owners have to be in the room.
A pilot that never becomes a rollout
Ten applications enforced and then nothing for a year, usually because the work was scoped as a proof of concept rather than as the first slice of a programme.
No one trained to own it
The platform is handed over at go-live to a team who have never authored a policy in it. Within months the model drifts and the exceptions pile up.
Further reading
Cisco’s own documentation
Where to read further on the platform itself. We are independent of Cisco’s marketing — these are the primary sources we point clients at.
- Cisco Secure Workload — the product overview
- Platform data sheet — form factors, scale limits and supported environments
- User guide, Release 4.0 — the current release documentation for the SaaS platform
- Release notes — what has changed in each release, including security fixes worth tracking