Domain 4 accounts for 21.3% of the ISC2 Certified in Cybersecurity (CC) outline effective September 1, 2026. It connects ordinary networking knowledge to security decisions and then extends those decisions into cloud environments.
The three objectives move from foundation to architecture to operating model:
- understand the network technologies and environments being protected;
- organize them into security boundaries and layered controls;
- understand how cloud characteristics and service models change where security responsibilities sit.
1. Domain 4 map
| Objective | Official focus | Useful question |
|---|---|---|
| 4.1 | Network security: OSI and TCP/IP models, IPv4, IPv6, VPN, firewall ports and applications, Wi-Fi, Bluetooth, Industrial Control Systems (ICS), Internet of Things (IoT) | What technology is carrying or exposing the communication, and what security property or boundary matters? |
| 4.2 | Network security architecture: segmentation, firewall zones, VLAN, microsegmentation, defense in depth, Zero Trust | How should access paths be separated, controlled, and verified so one compromise does not automatically reach everything else? |
| 4.3 | Cloud security: cloud characteristics, service models, deployment models, shared security roles and responsibilities | Which capability is the provider operating, what remains under customer control, and where does the security responsibility fall? |
2. Network models: locate the function before choosing the control
The Open Systems Interconnection (OSI) model and the Transmission Control Protocol/Internet Protocol (TCP/IP) model organize network functions into layers. They are useful because security problems often occur at different parts of communication.
| TCP/IP area | Rough OSI relationship | Examples |
|---|---|---|
| Application | Application, presentation, session | Web, email, name resolution, application protocols |
| Transport | Transport | TCP and UDP, ports, connection behavior |
| Internet | Network | IPv4, IPv6, routing between networks |
| Network access | Data link and physical | Ethernet, Wi-Fi, frames, local delivery, media |
Do not treat the layers as seven unrelated vocabulary words. Use them to reason about where a security control operates.
- A port-based firewall rule is concerned with transport and application context.
- An IP route or address belongs to the network or Internet layer.
- Wi-Fi protection affects local network access.
- Application authentication operates above the transport path even though the traffic still depends on lower layers.
A single security control can also inspect more than one layer. Modern firewalls may use addresses, ports, connection state, application identification, user identity, and other context.
3. IPv4 and IPv6: addressing is not the security decision by itself
Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) provide logical addressing and routing between networks.
At the CC level, know the basic distinction:
- IPv4 uses 32-bit addresses.
- IPv6 uses 128-bit addresses and a different address representation.
- Both require security controls, correct routing, and appropriate filtering.
- IPv6 is not automatically secure merely because it is newer.
The important security question is usually not "Which version is safer?" It is "Does the organization understand, route, filter, monitor, and manage the version actually in use?"
An organization that secures IPv4 but ignores active IPv6 paths can create an unmonitored route around expected controls.
Use the IPv6 Addressing Reference when you need deeper practice with notation and address ranges.
4. Virtual Private Networks (VPN): protect the path, not every endpoint decision
A Virtual Private Network (VPN) creates a protected logical connection across another network, commonly by encrypting traffic between endpoints or gateways.
A VPN can support:
- confidentiality for data in transit;
- integrity protection for the protected traffic;
- authenticated tunnel establishment;
- remote access or site-to-site connectivity across untrusted networks.
A VPN does not automatically make the connecting device, user, or remote network trustworthy.
After a VPN is established, the organization still needs:
- identity and authentication controls;
- authorization;
- endpoint security;
- segmentation;
- monitoring;
- limits on which internal resources the connection may reach.
Think of a VPN as protecting a communication path. It does not replace the rest of the access-control architecture.
5. Firewalls, ports, and applications
A firewall controls traffic between systems, networks, or security zones according to policy.
A basic rule may consider:
- source and destination address;
- source and destination port;
- protocol;
- connection state;
- direction;
- network interface or zone.
More advanced controls may also identify applications, users, devices, content, or other context.
Ports provide context, not complete identity
A port number can suggest the service normally expected on a connection, but port numbers alone do not prove which application is actually running.
For study, understand the relationship:
application or service → transport protocol → port → firewall decision
Use the shared Ports and Protocols reference for common defaults and secure alternatives rather than memorizing another duplicate list here.
Default deny reduces unnecessary exposure
A restrictive rule set allows required traffic and blocks traffic that has not been justified. This supports least privilege at the network level.
The strongest rule is not always "block everything." The security objective is to allow required communication while reducing unnecessary paths.
6. Wi-Fi and Bluetooth: wireless convenience changes the boundary
Wireless communication extends beyond a cable and can expose access to anyone within radio range.
Wi-Fi
Important security considerations include:
- approved authentication and encryption;
- strong credential handling;
- separation of guest or untrusted devices from sensitive networks;
- detection or prevention of unauthorized access points;
- secure configuration of wireless infrastructure;
- updates and lifecycle support for access points and clients.
A user connecting to an untrusted wireless network may need additional protection for sensitive communication, but encryption at one layer does not make the entire environment trusted.
Bluetooth
Bluetooth is designed for short-range communication, but short range is not the same as no risk.
Useful practices include:
- disable Bluetooth when it is not needed;
- use secure pairing methods;
- avoid unnecessary discoverability;
- keep devices updated;
- remove old or unknown pairings;
- consider what data or device functions become available after pairing.
7. Industrial Control Systems (ICS) and Internet of Things (IoT)
Industrial Control Systems (ICS) monitor or control physical processes. They are part of the broader Operational Technology (OT) environment.
Security decisions in ICS and OT may have direct effects on:
- safety;
- physical processes;
- equipment;
- availability;
- production;
- environmental conditions.
That means ordinary IT practices may need additional care. A security change that causes unexpected downtime can create more than an inconvenience.
Useful principles include:
- maintain accurate asset inventory;
- understand dependencies and communication paths;
- segment control environments from unnecessary access;
- limit remote administration;
- manage changes deliberately;
- account for availability and safety requirements;
- monitor supported systems without disrupting critical processes.
IoT
Internet of Things (IoT) devices combine computing, networking, sensors, actuators, or other physical functions.
IoT security should consider whether the device supports capabilities such as:
- unique identification;
- secure configuration;
- protection of stored and transmitted data;
- controlled access to interfaces;
- software and firmware updates;
- security-state awareness.
A low-cost or physically small device can still create a meaningful network path or collect sensitive information.
8. Segmentation: limit how far access can travel
Segmentation divides systems or networks into smaller areas so communication between them can be controlled.
Segmentation can reduce:
- unnecessary reachability;
- lateral movement after compromise;
- exposure of sensitive systems;
- the number of systems affected by one failure;
- the amount of traffic a security control must evaluate.
A good segmentation decision starts with purpose.
Examples:
- guest devices should not freely reach internal administrative systems;
- user workstations may not need direct access to database servers;
- IoT devices may belong in a restricted segment;
- production systems may be separated from development;
- management interfaces may require a dedicated administrative path.
Segmentation is useful when boundaries are actually enforced. A diagram showing several zones does not provide security if traffic can move between them without meaningful control.
9. Firewall zones, VLANs, and microsegmentation
These concepts all separate communication, but they do so at different levels.
| Concept | What it separates | Security point |
|---|---|---|
| Firewall zone | Interfaces, networks, or systems grouped by trust or policy | Traffic crossing zones is subject to firewall policy. |
| Virtual Local Area Network (VLAN) | Logical Layer 2 broadcast domains | A VLAN creates logical separation, but traffic between VLANs still needs routing and appropriate security enforcement. |
| Microsegmentation | Workloads, applications, or smaller groups with fine-grained policy | Limits communication more precisely than broad network-zone boundaries. |
A VLAN by itself should not be treated as proof that access is securely controlled. The important question is what policy governs traffic that crosses the logical boundary.
10. Defense in depth and Zero Trust
Defense in depth
Defense in depth uses multiple safeguards so one control failure does not leave the asset completely exposed.
A layered design might combine:
- endpoint protection;
- authentication;
- authorization;
- network segmentation;
- firewalls;
- encryption;
- logging and monitoring;
- backups and recovery.
The layers should address different failure paths rather than duplicating the same weakness.
Zero Trust
Zero Trust removes the assumption that location alone creates trust. NIST describes Zero Trust Architecture as focusing on users, assets, and resources rather than granting implicit trust because something is inside a traditional network perimeter.
A useful CC-level summary is:
Verify access to the resource based on policy and context rather than trusting the network location.
Zero Trust can consider:
- user identity;
- device condition;
- requested resource;
- authentication strength;
- policy;
- risk signals;
- session context.
Defense in depth versus Zero Trust
They are not competing synonyms.
- Defense in depth emphasizes multiple layers of protection.
- Zero Trust emphasizes explicit, policy-based access decisions without implicit trust from location.
An organization can use both.
11. The five cloud characteristics
NIST defines cloud computing with five essential characteristics.
| Characteristic | Meaning |
|---|---|
| On-demand self-service | A customer can provision computing capabilities as needed without requiring manual interaction with the provider for each request. |
| Broad network access | Capabilities are available over networks through standard mechanisms used by different client platforms. |
| Resource pooling | Provider resources serve multiple consumers through a pooled model, with resources assigned and reassigned according to demand. |
| Rapid elasticity | Capabilities can expand or contract quickly as demand changes. |
| Measured service | Resource use is monitored, controlled, and reported in a way that supports transparency and metering. |
These characteristics help distinguish cloud computing from simply hosting a server somewhere else.
12. Cloud service models: IaaS, PaaS, SaaS
The service model changes which technology layers the provider operates and which remain more directly under customer control.
| Model | Customer primarily consumes | Security perspective |
|---|---|---|
| Infrastructure as a Service (IaaS) | Virtualized compute, storage, networking, and related infrastructure capabilities | The customer generally retains substantial responsibility for operating systems, applications, identities, configurations, and data above the provided infrastructure. |
| Platform as a Service (PaaS) | A provider-managed application platform or runtime | The provider manages more of the underlying platform while the customer still secures applications, identities, data, and configurations under customer control. |
| Software as a Service (SaaS) | A provider-operated application | The provider operates more of the stack, while the customer still has important responsibilities for users, access, data use, settings, and approved configuration. |
Do not memorize the models as "provider secure" versus "customer secure." Security responsibility shifts, but it does not disappear.
13. Cloud deployment models
NIST identifies four deployment models.
| Model | Basic idea |
|---|---|
| Private cloud | Cloud infrastructure is provisioned for exclusive use by one organization. |
| Community cloud | Cloud infrastructure is provisioned for a specific community of organizations with shared concerns. |
| Public cloud | Cloud infrastructure is provisioned for open use by the general public or a broad customer base. |
| Hybrid cloud | Two or more distinct cloud infrastructures remain separate but are connected to support portability or coordinated use. |
"Public" does not mean all customer data is public. The term describes the deployment model, not the confidentiality of every workload.
14. Shared security roles and responsibilities
Cloud security is shared because the customer uses technology operated partly or largely by another organization.
The exact boundary depends on:
- service model;
- provider;
- product;
- contract;
- configuration;
- feature being used.
A useful rule is:
The provider can operate a secure service while the customer still configures or uses it insecurely.
Customer responsibilities commonly include areas such as:
- deciding which data belongs in the service;
- managing users and access;
- configuring customer-controlled security settings;
- protecting credentials and secrets;
- monitoring customer activity and logs available to the customer;
- applying governance, privacy, and compliance requirements;
- understanding what the provider does and does not manage.
Provider responsibilities commonly include the technology layers and facilities the provider has agreed to operate.
Always check the provider's current documentation for the actual boundary. Do not infer responsibilities from the words "cloud" or "managed."
15. Common Domain 4 exam traps
IPv6 is not automatically secure
A newer addressing protocol does not remove the need for filtering, monitoring, configuration, and access control.
A VPN does not make the endpoint trusted
The tunnel protects communication. Endpoint health and authorization still matter.
A port number does not prove the application
Ports provide useful context, but applications can use unexpected ports and advanced controls may inspect more than the transport number.
A VLAN is not the whole security boundary
VLANs create logical Layer 2 separation. Inter-VLAN communication still requires routing and security policy.
Segmentation and microsegmentation differ in granularity
Segmentation creates boundaries between larger areas. Microsegmentation applies finer-grained policy to smaller workload groups or individual workloads.
Defense in depth is not Zero Trust
Defense in depth layers controls. Zero Trust avoids implicit trust and evaluates access to resources based on policy and context.
Public cloud does not mean public data
Public cloud describes who can obtain the service, not whether a customer's workload is intentionally exposed.
SaaS does not remove customer security responsibility
The provider operates more of the stack, but the customer still controls important decisions involving users, data, settings, and usage.
Shared responsibility is not identical for every cloud service
The actual division depends on the service model, provider, product, and agreement.
16. Rapid review checklist
Before leaving Domain 4, make sure you can explain:
- [ ] Why the OSI and TCP/IP models help locate network functions
- [ ] The basic difference between IPv4 and IPv6
- [ ] What a VPN protects and what it does not
- [ ] How firewalls use addresses, ports, applications, zones, and policy
- [ ] Why the Ports and Protocols reference matters to firewall scenarios
- [ ] Basic Wi-Fi and Bluetooth security concerns
- [ ] Why ICS and OT security must account for availability and safety
- [ ] Why IoT devices need inventory, secure configuration, updates, and controlled interfaces
- [ ] Segmentation and its effect on lateral movement
- [ ] Firewall zones versus VLANs versus microsegmentation
- [ ] Defense in depth versus Zero Trust
- [ ] The five cloud characteristics
- [ ] IaaS, PaaS, and SaaS
- [ ] Private, community, public, and hybrid cloud
- [ ] Why cloud security responsibilities are shared
- [ ] Why the exact responsibility boundary depends on the actual cloud service
If a scenario feels like a product-trivia question, return to the requirement: what communication, boundary, resource, or responsibility is the organization trying to protect?
17. Official and primary references
Use the ISC2 outline as the authoritative scope for this domain:
Primary references that add context:
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-145: The NIST Definition of Cloud Computing
- NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
- NIST IR 8259A: IoT Device Cybersecurity Capability Core Baseline
These sources add deeper architecture, cloud, OT, and IoT context. They do not replace the ISC2 exam outline as the coverage checklist.
CertHappens is an independent study resource and is not affiliated with or endorsed by ISC2.