Cybersecurity Domains

Cybersecurity domains are the usual way the field is divided up, sorted by what is being protected. The published lists vary, and the following covers the ground most of them agree on:

• Network security: protecting data in transit and controlling what can reach what.
• Endpoint security: protecting laptops, servers, and other devices, and seeing what happens on them.
• Cloud security: protecting infrastructure, platforms, and configuration in cloud environments.
• Application security: finding and fixing weaknesses in software before and after it ships.
• Identity and access management: controlling who is who and what they can reach.
• Data security: classifying, protecting, and monitoring the data itself.
• Governance, risk, and compliance: policy, risk decisions, and demonstrating control to auditors and customers.
• Security operations: the continuous detect-and-respond function that runs across all of the above.

Two notes on how to read this list. The domains are not equally sized and are not mutually exclusive — a cloud identity misconfiguration is simultaneously cloud security and identity, and and security operations is a different kind of entry from the others, because it is defined by activity rather than by asset type, which is why it cuts across every other domain.

Network security is the practice of protecting data as it moves and controlling which systems can communicate with which. It covers the controls that sit between systems rather than on them.

The main components:

• Segmentation: dividing the network so that reaching one part does not grant reach to everything. The network control that does the most to limit lateral movement.
• Firewalls and access control: deciding what traffic is permitted, at the perimeter and increasingly between internal zones.
• Secure remote access: VPN and its modern replacements, which is where a great deal of initial access happens.
• Traffic inspection and monitoring: detecting malicious activity in flows and in content, though the value of content inspection has declined as traffic encryption has become near-universal.
• DNS controls: blocking known-bad domains and monitoring lookups, which remains one of the cheaper and more useful signals available.

Network security's role has shifted rather than shrunk. When most systems sat inside a perimeter, the network boundary was the primary control, and with cloud services and remote work, the perimeter is thinner and the network's most valuable contribution is now internal, meaning segmentation to limit movement and flow telemetry to see it.

The tooling splits along that same line. Fortinet FortiGate and Cisco hold the firewall and segmentation side, while Zscaler and Cato Networks represent the newer model where the control follows the user instead of the perimeter.

Endpoint security is the protection and monitoring of the individual devices in an environment, including laptops, desktops, servers, and in many programs mobile devices as well. It matters disproportionately because nearly every intrusion touches an endpoint at some point.

It generally spans four things: preventing malicious code from executing, hardening the device through configuration and patching, recording detailed activity for detection and investigation, and providing the ability to act remotely on a compromised device.

Endpoint telemetry is the backbone of most detection programs because it's the richest single source available, and process creation with full command lines, parent-child relationships, file and registry activity, and network connections from the host together allow reconstruction of what actually happened, which no other single source supports as well.

The limitation is coverage rather than quality. Endpoint tooling sees only managed devices, which excludes contractor machines, personal devices, network appliances, many operational technology systems, and most cloud control-plane activity. Programs that assume endpoint coverage equals environment coverage tend to have a blind spot exactly where modern attacks are moving.

In practice this layer means CrowdStrike, SentinelOne, or Microsoft Defender for Endpoint, with Microsoft Intune handling the configuration and patching half of the same job.

Cloud security is the protection of workloads, data, identity, and configuration in cloud environments, and the disciplines carry over from on-premises security and the failure modes are different, mostly because the primary risk in cloud is misconfiguration rather than malware.

The distinctive parts:

• Shared responsibility: the provider secures the underlying infrastructure and the customer secures what they build on it. AWS, Microsoft Azure, and Google Cloud all publish a version of this model, and most incidents fall squarely on the customer side of the line.
• Configuration and posture: publicly exposed storage, over-permissive roles, disabled logging, and unmanaged keys account for a large share of cloud incidents.
• Identity as the control plane: in cloud, permissions are the perimeter. A role that can assume another role that can read a bucket is a path, and those paths are hard to see without tooling built for it.
• Control plane telemetry: cloud audit logs record API activity, and they are the equivalent of endpoint telemetry for cloud infrastructure. They are also frequently under-collected or under-retained.
• Workload protection: containers and serverless functions are short-lived, which breaks assumptions built into tooling that expects durable host.

The operational difference that matters most for a security team is speed. In cloud, a misconfiguration can expose data in seconds and a permission change can grant broad access instantly, so detection latency has a much more direct relationship to impact than it does on-premises. Posture and permission-path problems are what a tool like Wiz is built to surface; AWS GuardDuty covers the control-plane detection side.

Application security is the practice of finding and fixing weaknesses in software, both in the code an organization writes and in the components it depends on. It spans design, development, testing, and the running application.

The main activities:

• Secure design and threat modeling: deciding what can go wrong before it is built, which is the cheapest place to fix anything.
• Static and dependency analysis: examining source code and third-party components for known weaknesses, usually against a reference set such as the OWASP Top 10.
• Dynamic testing and penetration testing: attacking the running application to find what analysis missed. Covered in more depth in the penetration testing section.
• Runtime protection and monitoring: web application firewalls and application-layer logging, which is often the only telemetry available for an exploited web application.

Application security connects to security operations at exactly one seam and it is usually a weak one, and when a runtime alert traces back to a code-level weakness, the SOC has found something it cannot fix and the development team owns a fix for something it did not see. Organizations that haven't agreed in advance who owns that handoff generally rediscover the question during an incident.

Identity and access management, usually abbreviated IAM, is the discipline of establishing who or what a requester is and controlling what they are permitted to do. It covers accounts, authentication, authorization, and the lifecycle of both.

The components:

• Authentication: proving identity, including passwords, multi-factor methods, and passwordless approaches.
• Authorization: deciding what an authenticated identity may do, usually through roles, groups, or policies.
• Lifecycle management: provisioning access when someone joins, changing it when they move, and removing it when they leave. The last of those is the one that fails most often.
• Privileged access management: additional controls for accounts that can cause the most harm, such as approval, session recording, and time-bounded elevation.
• Non-human identity: service accounts, API keys, and workload identities, which typically outnumber human accounts and are far less governed.

IAM has become the center of gravity for security operations because so many attacks are now identity attacks. If an intruder arrives with a valid credential, the identity provider's logs are the primary detection surface, and access review data is what determines how much damage the credential permits, that last point is why over-permissioned accounts are an operations problem and not only a compliance finding. For most organizations that identity provider is Okta or Microsoft Entra, which makes those logs the highest-value source in the estate.

Somebody has to own the whole story, and in most organizations nobody is formally assigned to. This is one of the more common structural gaps in security programs, and it produces a specific failure: two teams each investigate their half, each concludes their half is explainable, and the intrusion that spans both is closed twice.

The situation is routine rather than exotic. An identity alert for an unusual sign-in and an endpoint alert on the same user's laptop are one event. A cloud storage access anomaly and a network alert on the same host are one event. Domains are an organizational convenience, and attackers do not respect them.

Three arrangements work, and the choice matters less than making one of them explicit:

• Security operations owns the correlation by default: the SOC is the only function defined by activity rather than by asset type, which makes it the natural owner. This requires the SOC to have visibility into all the domain tools, not only its own. How that function is staffed, measured, and tooled is covered in cybersecurity operations.
• A named incident commander per case: one person owns the whole investigation for its duration, pulling in domain specialists as consultants rather than as parallel investigators.
• A standing rule that any cross-domain alert escalates immediately: cheap to implement and it accepts over-escalation as the cost of not splitting a case in half.

What does not work is the default arrangement, where each team owns its own console and the correlation exists only if somebody happens to notice, and the practical test for any organization is to ask who would have investigated the last cross-domain case, and whether that person had access to both sets of data.