How do you build security into a network?

Being able to connect is not the same as being allowed to connect↑

Network design creates paths to destinations; security design decides who may communicate and how to detect suspicious activity. The existence of a routing path does not mean every user and program should be allowed to use it.

In our teaching example, an employee at PC-A needs to open a report on the business server App-S. A guest endpoint should have Internet access but no access to that report server. Even if both endpoints use the same building and switch, they do not have the same business role or data permissions. Start by separating the traffic you need to allow from the traffic you need to deny.

Separate VLANs divide Layer 2 access domains, but enabling inter-VLAN routing allows communication between them again. Conversely, traffic that stays within one VLAN may never pass through the gateway's firewall policy. Apply the lesson from the Layer 2/Layer 3 boundary article: restrict communication between the diagram's segments by placing policy on actual packet paths.

Each security function evaluates something different. Access authentication identifies the user and device. A firewall decides which traffic to allow; an IPS inspects flows for attacks and decides what to block. NDR analyzes observations for unusual behavior, while data protection covers file use and sharing after access has been granted. Even when one product provides several functions, distinguish what each function checks.

One product may provide several functions, or they may be distributed across endpoints, networks, and services. The diagram's boxes separate these roles; they do not mean you need to buy a device for every box. We draw business requests, authentication and policy exchanges, and observation collection as separate paths to identify missing controls and dependencies.

First, the overview shows where employees and guests should be allowed to go. Solid lines show example business traffic; dotted lines show identity, device, and permission information supplied to enforcement points. We will build on this layout with firewalls, IPS, VPNs, observation, and data protection.

Where do you check who is connecting and which device they use?↑

Trusting users solely because of their location can give a compromised endpoint broad access once it is inside the office. Check the user's identity, device posture, and requested resource together, and grant only the permissions needed.

When PC-A connects to a wired port or wireless network, access controls such as 802.1X and NAC can apply. The access device exchanges information with the authentication system and determines permissions from the result. Define user authentication, device authentication, and exceptions for devices that cannot authenticate. Permission to join the network does not replace the separate authorization required for each business application.

When the user opens a report on App-S, the application must check that user's data permissions again. Joining the network and viewing or editing a report are separate decisions. Also decide where permissions can be reduced or revoked when a person's role changes or a device becomes risky.

Zero trust is not the name of a particular authentication product or simply another term for multifactor authentication. It is a design approach that checks the conditions for resource access instead of granting implicit trust to the internal network. Authentication is one part; it must connect to least privilege, device posture, observations, and access revocation. Even after a successful login, continue checking permissions and device condition so access can be restricted when risk is found.

This does not mean every business packet passes through an authentication server. Authentication and policy exchanges can use different paths from the actual data. To design for both secure access and recovery, test how an authentication outage affects existing connections versus new access, and define the limits of approved emergency access.

How do you protect remote access and traffic inside the network?↑

Protecting remote access and restricting access to internal services may both be necessary. Entering the network securely does not grant access to every address and service inside it.

Suppose employee PC-R connects from outside through an encrypted remote-access VPN to the company's VPN endpoint. In this example, the tunnel protects transport between its two endpoints. The broader term VPN does not always imply the same encryption, so we limit this discussion to that remote-access method. Communication outside the tunnel and the endpoint itself require separate protection.

The VPN endpoint should provide routes and policies appropriate to the user's role. If PC-R only needs App-S's business functions, allow that scope and restrict unnecessary access to management networks and other servers. A firewall permits or denies traffic by checking these conditions and any required connection state. It can sit at an internal service boundary as well as the Internet edge.

Attacks can arrive through permitted ports, so define what to inspect. An IPS detects attack indicators in traffic it can analyze and blocks according to configured policy. Inline processing and passive observation of copied traffic differ in their ability to block and in the impact of a failure. Distinguish the deployment modes.

Even when a firewall and IPS share a product, check separately which policies and inspections apply on each path. Consider operational, privacy, and application requirements when deciding what can be seen in encrypted flows and which inspections may use decryption. The diagram shows where functions apply; verify the internal processing order for the actual model and configuration.

If PC-A's internal traffic never crosses the Internet edge, inspection at that edge cannot see all lateral activity. Apply appropriate policy in front of services too, and prepare ways to examine endpoint permissions and internal traffic. The next section covers detecting suspicious internal activity. Check the response path as well as the request against the requirements of state-tracking functions, so legitimate replies pass while prohibited traffic remains blocked.

Different line styles distinguish employees' actual data paths, authentication and policy exchanges, and observations sent to NDR. Follow each path to see what each security function can inspect.

How do you detect suspicious activity in permitted traffic?↑

An endpoint that was allowed onto the network can later behave suspiciously. NDR analyzes network observations for unusual behavior and signs of threats, and helps guide a response.

For example, PC-A might stop simply reading reports and suddenly attempt repeated connections to many servers. Even if each request uses a permitted port, unusual destination counts, frequency, or timing can justify investigation. That alone does not prove a compromise: compare the user's work, other logs, and the endpoint's condition.

Observations can come from flow information such as NetFlow and IPFIX, device logs, or, depending on the configuration, copied packets. Actual packets do not necessarily pass inline through an NDR analyzer. Draw collection paths differently from the original data paths, marking where each observation comes from, so the analysis scope is clear.

Mark unobserved segments as outside your visibility. Encrypted content is not automatically readable, and results also depend on collection location, sampling, loss, and clock differences. If collection from a device stops, an attack may produce no alert. When no alerts appear, check that collection itself is healthy.

Detection and response are separate decisions. An operator can review the evidence before acting, or an approved integration can request restrictions through a firewall, NAC, or endpoint controls. Define automatic blocking authority, conditions, rollback, and false-positive impact. If an actual compromise is confirmed to be spreading, apply the incident-response article's emergency isolation principle instead of waiting for analysis to finish.

How do you protect data when an authorized user tries to share it externally?↑

Authentication and permitted traffic do not, by themselves, control how data is used. When an employee with permission to view a report shares the file externally, you must consider its content and sharing permissions as well as the network path.

DLP compares data content, classification, usage context, and policy to detect and control inappropriate disclosure or sharing. Implementations may apply it on endpoints, in email or collaboration services, or on supported network segments. An Internet-edge DLP appliance cannot see every way data leaves, so first identify where and how the data you need to protect actually moves.

Suppose PC-A tries to send a report downloaded from App-S to an external sharing location. Policy considers the data type, destination, transfer method, and any approved exception. It may notify, warn, block, or require approval, but not every product provides every action on every channel.

Here, DRM means protecting permissions to use enterprise documents, not controlling movie or music distribution. This includes approaches known as IRM. Supported applications and permission systems determine who may open, edit, or print a protected file. Those permissions can remain enforceable after the file is copied elsewhere, unlike DLP's decision about whether data may leave.

DLP and document DRM can complement each other, but they are not the same function. The former controls the context in which data is used or sent out; the latter focuses on maintaining permissions over a protected file. Check supported formats, clients, offline conditions, and the availability of permission services to understand the actual protection.

Technology alone cannot prevent every authorized reader from photographing a screen or retyping its contents. Combine least privilege with data classification, usage-log review, and user education. Decide which sharing is allowed, then connect controls on endpoints, services, and documents so needed collaboration remains possible while data is protected.

For the same report, document DRM and IRM enforce viewing, editing, and printing permissions, while DLP evaluates the content and context of external sharing. The diagram separates when each function applies.

What happens to connectivity and protection when security fails?↑

Plan for security devices and services to fail too. If you only check that traffic still flows, you may mistake lost inspection for recovery. Verify both connectivity and the continued operation of required security functions.

When inline inspection fails, bypassing it to keep traffic flowing and blocking traffic create different risks. These behaviors are often called fail-open and fail-closed, but their exact scope depends on the product, mode, and failure type. Define the conditions in advance using business criticality, the resources being protected, and approved compensating controls.

If you deploy two firewalls, revisit connection state and remaining capacity from the redundancy article. Verify the backup device's policies, connection state, and support for NAT and VPNs, then test business operations with inspection enabled. A successful connection is not enough if the alternate path bypasses a security boundary or the backup lacks required policy.

A collection failure in NDR may not interrupt forwarding, but it removes visibility. Authentication or document-permission service outages can affect new access and permission checks. Identify which function failed and how it affects existing connections versus new access. Do not report an unknown state caused by lost collection as normal.

An ongoing compromise requires a different response from an ordinary equipment failure. Prioritize preventing further harm. If the affected scope is uncertain or the compromise keeps spreading, widen containment, including isolating the entire affected network. Do not keep a compromised path open to continue business simply because normal policy prioritizes availability. Follow the incident-triage and recovery article's principles and the incident command process for specific containment and recovery decisions.

Next, explore how each security function works↑

We have separated the security functions involved as an employee connects and shares a report. A later security series can examine how authentication, traffic authorization and inspection, behavioral analysis, and data permissions actually work, rather than simply listing more product names.

Initial access for users and endpoints, connection state in firewalls and VPNs, inspection and observation with IPS and NDR, and DLP and document permissions each merit a closer look. As you read more, ask where each function operates and what it cannot see. In this series, we first turn to route-based control of attack traffic, then move on to design validation and incident recovery.

Once you have placed security functions along the paths, consider attacks that saturate the circuit itself. Upstream attack mitigation distinguishes where blocking, observation, and scrubbing occur and how they affect legitimate services. The following design-validation and incident-response articles test whether these policies hold in practice and explain how to resume business safely after a problem.