NetSec Platform: Building Blocks
A well implemented NetSec platform will give centralised intent and control, distributed enforcement, and shared visibility - consistently applied wherever users and applications are active.
In this post I'll outline a simple reference model with example building blocks. The goal is to create a starting point that scales.
Building Blocks
A NetSec platform consists of core building blocks that can be grouped into 3 architectural layers:
- Connectivity, routing, enforcement
Connectivity and routing: connectivity isn't a network team detail, it is foundational to security outcomes. A NetSec platform should define traffic steering to enforcement, private routing to applications, failover behaviour, and blast radius. Without this intentional design user experience will be poor and troubleshooting difficult.
Design goal: predictability - in relation to path selection, failures, and user experience.
Distributed enforcement: this is about where the packet gets inspected, which will typically happen in 4 main places:
A) Remote users - the modern reality is that people are working from anywhere and often on unmanaged networks. Enforcement examples include Zero Trust Network Access (ZTNA) and agent-based Security Service Edge (SSE).
B) Branch and site edge - these locations need internet breakout controls, private connectivity, segmentation, and resilient access. They may also have considerations such as connected Operational Technology (OT) devices.
C) Cloud - workloads need ingress and egress, east/west segmentation, and controlled connectivity to shared services and SaaS. Applications delivered as SaaS still require security inspection for use cases like Data Loss Prevention (DLP).
D) Data centre / legacy core - even cloud-first organisations usually have some legacy applications and shared services or partner connectivity. These environments are more likely to be using the old perimeter and trusted network approach.
Design goal: consistent policy enforcement across each location, despite technology and operational differences.
- Detection, inspection, prevention
Shared security services: inspection logic across distributed enforcement points must remain consistent to allow for scale. Capabilities such as threat detection, malware analysis, DNS and URL controls, and behavioural analysis should share inspection intelligence, detection models, and threat updates across the platform.
Design goal: intelligence and updates are applied centrally and consumed globally.
Identity and device context: identity is now the most important network security component. This means a consistent source of truth for users and groups, devices and posture, authentication and conditional access, and service accounts and non-human identities (such as AI agents).
Design goal: security policy should follow the user/device/app and not the IP address.
- Management, policy, visibility
Visibility and operations: a good platform provides end-to-end visibility with central logging and consistent event meaning, context enrichment, dashboards and analytics (that engineers actually use), and automated alert correlation and troubleshooting.
Design goal: troubleshooting steps and owners should be easy to identify and form a standard process.
Policy engine: policies should only grant the least amount of privilege required. This is part of Zero Trust - more on that in the next post. The platform needs a policy model that supports a global baseline (minimum standards), application-specific policies, risk-based and dynamic policy decisions, and exceptions that are controlled, time-bound, and reviewable. That last one might sound counter intuitive, but it's important to plan for the worst.
Design goal: a policy framework should apply the principle of least privilege and keep its structure after 12 months of change.
Control Plane vs Data Plane
It is important to understand the difference between the control plane and the data plane, since this split will drive design decisions.
The control plane is where the platform is operated and security intent is defined.
The data plane is where traffic is inspected and policy is enforced.
The typical responsibilities of a NetSec platform control plane include:
- Policy management
- Visibility and logging
- Configuration and lifecycle
- Identity and context
- Automation and integration
The data plane is where the work happens:
- Routing and connectivity
- Traffic inspection
- Decryption where required
- Segmentation and access enforcement
- Threat prevention
- URL filtering and DNS controls
The data plane should be designed for performance, resilience, and predictable enforcement. The platform should not depend on a perfect network day to be secure.
Design Considerations
Not an exhaustive list, but some of the main things to consider:
Consideration 1: Where are users and applications located and what are their access patterns?
This is probably the most important consideration. It will drive coverage, segmentation boundaries, enforcement points, performance, and traffic steering design. What is the source of truth for identity? What is the authentication strategy and does it include session context? How are applications, including shadow IT, discovered and identified? How are user device, and application lifecycles managed?
Consideration 2: What must continue working during outages?
Consider first the minimum viable business or organisation equivalent. What is needed to keep the doors open? What are the critical assets and dependencies? This will feed into the platform design - what happens if a region or service edge fails? What does 'degraded mode' look like? What happens if the control plane is unreachable? Security shouldn't disappear during instability, but the minimum viable business cannot stop either.
Consideration 3: Define operational ownership.
Make sure roles and responsibilites are clearly defined for things like policy, routing, identity, and endpoints. Key stakeholders will help define the policy model, change and exception process, governance, and troubleshooting workflows. This shapes metrics that matter like user-impacting incidents and Mean Time To Resolve (MTTR).
Consideration 4: Prioritise visibility.
Visibility must be a platform feature from the start, not an add-on. If logs are scattered then incidents take longer to resolve, change becomes riskier, and teams lose confidence. Ensure visibility early including log collection and retention strategy, consistent data model and event meaning, and ecosystem integrations such as XDR and SIEM.
Consideration 5: Automation should be possible even if isn't implemented on day 1.
Avoid making decisions that make automation difficult later. Standardise processes, names, and configurations. Use consistent templates and API-friendly workflows, and minimise manual one-offs.
Operational Outcomes
A successfully implemented platform model delivers the following outcomes:
- New sites are onboarded using standard patterns
- Remote access behaves consistently for users
- Policy remains understandable and reviewable as the environment scales
- Troubleshooting is repeatable and fast
- Leadership can see risk and control coverage clearly
What's Next?
Now that we've established the platform building blocks, we can map real technologies.