Cybersecurity Basics

Cybersecurity is the practice of protecting computer systems, networks, applications, and data from unauthorized access, disruption, or damage. That single sentence is where cybersecurity basics start, and almost every other idea in the field hangs off it. It covers the technology used to protect those things, the processes that govern how they are used, and the people who operate both.

The scope is broader than most introductions suggest. Cybersecurity includes designing systems so they are hard to attack, verifying that the design held, watching for signs that somebody is attacking anyway, responding when they do, and proving to auditors and customers that all of the above is happening. Those are different disciplines that require different skills, and no one person does all of them.

The word most people mean when they say cybersecurity is usually one of those pieces. An engineer typically means secure design and configuration. A compliance officer typically means demonstrable control coverage. Somebody working an alert queue means detection and response. Being explicit about which part is under discussion prevents a lot of circular conversations.

Because nearly everything an organization does now runs on systems that can be reached remotely, and the same reachability that makes them useful makes them attackable, and the importance is not really about computers, it's about what the computers now hold, which is the money, the operations, the customer relationships, and the records.

Three specific consequences drive most of the investment:

• Operational disruption: ransomware and destructive attacks stop organizations from operating, sometimes for weeks. For hospitals, manufacturers, and logistics companies, downtime is the primary harm rather than data loss.
• Data loss and misuse: customer data, intellectual property, and credentials have resale value, and the loss of them creates regulatory, contractual, and reputational exposure that lasts far longer than the incident.
• Trust and obligation: enterprise customers, insurers, and regulators increasingly require demonstrable security as a condition of doing business, which means cybersecurity has become a commercial requirement and not only a risk-reduction one.

There is a fourth reason that is less often stated and matters just as much. Attacks are increasingly opportunistic and automated, which means an organization does not have to be a target to be attacked. Most incidents are not personal.

Cybersecurity works by layering four kinds of activity, and each one exists because the previous one is imperfect.

• Reduce the attack surface: remove what is not needed, patch what is, restrict who can reach what. Everything that follows is cheaper when there's less exposed.
• Prevent: put controls in the path of an attack so most attempts fail, such as multi-factor authentication, email filtering, endpoint protection, and network controls.
• Detect: assume some attempts will succeed, and collect enough telemetry to notice when one has. This is the point at which a security operations function becomes necessary.
• Respond and recover: have the ability to contain, remove, and restore, and practice it before you need it.

All four are needed because each layer has a known failure rate. Attack surface reduction cannot eliminate what the business genuinely needs to expose. Prevention fails against novel techniques and against credential theft, where the attacker arrives with valid access. Detection fails when the telemetry was not collected. Response fails when nobody has done it before.

Prevention is where you spend to reduce volume, and detection and response is where you spend to reduce impact, so a program that funds prevention alone has no way of knowing how often prevention failed, and a program that funds detection alone spends its whole budget watching problems it could have stopped. Programs that fund only one of the two are common.

The CIA triad is the model that describes the three properties security controls exist to protect: confidentiality, integrity, and availability.

• Confidentiality: only those authorized can see the information. Encryption, access control, and data classification serve this property.
• Integrity: the information is accurate and has not been altered without authorization. Hashing, digital signatures, change control, and audit logging serve this one.
• Availability: the information and the systems are usable when needed. Redundancy, backups, capacity planning, and denial-of-service protection serve this one.

The triad is useful because it forces a question that is otherwise easy to skip, which is what exactly a given control protects. It also makes the trade-offs visible, since strengthening one property often weakens another. Aggressive access controls protect confidentiality and can harm availability. Immutable backups protect integrity and availability and can complicate a deletion request.

Some frameworks, including ISO/IEC 27000 and NIST SP 800-53, extend the triad with additional properties such as authenticity and non-repudiation, those extensions are useful in specific contexts and the three original properties remain the frame that almost every control maps back to.

Availability threats announce themselves and confidentiality threats do not, which makes the triad one of the more useful severity heuristics an analyst has.

When an analyst triages an alert, the underlying question is which property is threatened and how badly. That maps to priority in a fairly consistent way:

• Availability threats usually surface fastest and get priority by default: because somebody notices. Ransomware, destructive activity, and denial of service are self-announcing, and the business escalates them without help from the SOC.
• Confidentiality threats are the ones that need the SOC most: because nothing breaks. Data staged for exfiltration, an unauthorized read of a sensitive share, or an account accessing records outside its normal pattern produce no user-visible symptom at all. If detection does not catch these, nothing else will.
• Integrity threats are the hardest to weigh and the most often underrated: A modified record, an altered configuration, or a tampered log has consequences that appear much later and are hard to unwind. Integrity attacks on logging deserve particular attention, since they degrade the ability to investigate everything else.

When two alerts have the same nominal severity, the one threatening a property that would otherwise go unnoticed generally deserves attention first, because the severity field was set by whoever wrote the detection and it knows nothing about which of the three properties is actually at risk in your environment on this asset today. Availability incidents will find you. Confidentiality incidents will not.

Information security is the protection of information in all forms. Cybersecurity is the protection of systems, networks, and data in digital form. Information security is the broader term, and cybersecurity sits inside it.

What differs is scope. A locked filing cabinet, a policy about discussing customer data in public, and a clean-desk rule are information security and are generally not cybersecurity. A misconfigured cloud storage bucket is both.

In everyday use, particularly in job titles and vendor marketing, the two are treated as synonyms and very little turns on the distinction. It becomes relevant in two places, in standards work, where ISO 27001 is deliberately an information security management standard covering paper and people as well as systems, and in regulated industries such as financial services, where obligations attach to information regardless of its form.

Cyber risk is the combination of how likely a harmful event is and how much harm it would cause. A threat is one of the inputs to that calculation, not the calculation itself.

The three terms that get conflated:

• A threat is something or someone that could cause harm. A ransomware group, an insider, a piece of malware, a natural disaster.
• A vulnerability is a weakness that a threat could use. An unpatched service, a weak password policy, an over-permissioned account, an employee who has never seen a phishing simulation.
• A risk is what you get when a threat can reach a vulnerability and the result would matter. Risk requires all three parts: a threat, a vulnerability, and an impact.

This is why a critical vulnerability on a system that holds nothing and is reachable by nobody may be a low risk, and why a moderate vulnerability on a system holding regulated data may be a high one, and vulnerability severity scores describe the weakness. Risk describes the consequence in your specific environment, which is something only you can assess.

Being pedantic about this matters because security programs are funded against risk and measured against vulnerabilities, and the gap between those two things is where a lot of misdirected spending happens.

Cyber resilience is the ability of an organization to keep operating, and to recover, while under attack or after a successful one, it accepts as a premise that some attacks will succeed, and shifts the question from whether you can be compromised to how much the compromise costs you.

In practice, resilience covers things that a purely preventive program tends to underinvest in:

• Recovery capability that has actually been tested: backups that nobody has restored from are a plan, not a capability — and the difference is usually discovered on the worst possible day.
• Backup isolation: backups reachable with the same credentials as production are commonly encrypted alongside it, so isolation and immutability matter more than backup frequency.
• Degraded-mode operation: knowing which business processes can run without which systems, and having a manual fallback for the critical ones.
• Decision-making under disruption: who decides to take systems offline, who talks to customers, and what happens when the usual communication channels are the compromised ones.

Resilience and security overlap heavily and they are funded by different arguments, which is why they often sit with different owners. Security investment is argued on likelihood reduction. Resilience investment is argued on impact reduction, and it is generally easier to justify after an incident than before one.

A small number of attack types account for the large majority of incidents that organizations actually experience. The exotic techniques get the coverage, and these are what shows up in the incident data published each year by sources such as the Verizon Data Breach Investigations Report and Mandiant's M-Trends:

• Phishing and social engineering: tricking a person into giving up credentials, approving access, or running something. One of the two most common initial access routes, alongside stolen credentials.
• Credential attacks: using stolen, guessed, reused, or purchased credentials to log in as a legitimate user. Includes password spraying, credential stuffing, and use of credentials bought from access brokers.
• Ransomware: encrypting or stealing data and demanding payment. Almost always the end of an intrusion rather than the beginning of one.
• Malware: software installed to steal, spy, persist, or destroy, delivered by email, web, removable media, or a compromised software supply chain.
• Exploitation of internet-facing systems: attacking an unpatched or misconfigured service that is directly reachable, such as a VPN appliance, a file transfer product, or a web application. The MOVEit Transfer campaign is the best-known recent example of the file transfer case.
• Business email compromise: manipulating a legitimate email account or conversation to redirect a payment. Frequently involves no malware at all.
• Insider activity: misuse by someone who already has access, whether deliberate or accidental.
• Denial of service: overwhelming a system so it can't serve legitimate users.

The pattern worth noticing is how many of these involve valid credentials rather than technical exploitation, and the consequence is that a large share of the controls a security program buys are watching for a break-in that never happens, while the actual entry event looks identical to an employee signing in from a hotel. An attacker who logs in doesn't trigger the controls built to catch an attacker who breaks in. That is the central reason identity telemetry has become as important as endpoint telemetry.

Malware is software written to do something harmful to a system or its user, such as stealing data, granting remote access, encrypting files, or using resources without permission, and the categories overlap heavily, since a single piece of modern malware commonly does several of these things.

• Ransomware: encrypts data, steals it, or both, and demands payment.
• Infostealers: harvest credentials, session cookies, and browser data. Extremely common, and the front end of a large share of later intrusions.
• Remote access trojans: give an attacker interactive control of a host.
• Loaders and droppers: exist only to install the next thing, and are often the first stage of an infection chain.
• Rootkits and bootkits: hide the presence of other malware by subverting the operating system or the boot process.
• Worms: spread by themselves across a network without needing a person to do anything.
• Spyware and keyloggers: monitor and record activity.
• Cryptominers: consume computing resources to mine cryptocurrency. Often treated as low severity, and worth investigating because the access used to install it could have been used for anything.

A note on the categories. They describe function, not delivery, and function changes at runtime. Treating a malware classification from an antivirus verdict as the full story about an incident is a common triage mistake, since what the sample was called matters far less than how it got there and what it did afterwards.

Ransomware is an attack that makes an organization's data unusable or exposes it, and demands payment to reverse or prevent that, and most current operations use 'double extortion', meaning data is stolen first and then encrypted, so paying to decrypt does not resolve the exposure.

The encryption is the last step, and by the time it happens the attacker has usually been present for a while. A typical sequence:

• Initial access: stolen credentials, a phishing email, or an exploited internet-facing service.
• Establish persistence and escalate: ensure continued access, then obtain higher privileges, most often by harvesting credentials from memory or from a poorly protected service account.
• Move laterally and find what matters: locate file shares, databases, backup infrastructure, and the domain controller.
• Disable defenses and backups: turn off or evade endpoint protection, delete shadow copies, and reach the backup system. This step is why backup isolation is so consequential.
• Exfiltrate: copy the valuable data out, which is what makes the extortion work even against organizations that can restore cleanly.
• Encrypt: deploy the payload broadly, usually outside business hours.

The operationally important point is that everything before the final step is detectable, and often for days. Ransomware feels sudden to the victim because the visible event is the last one in a long sequence. The stages that precede it are where a security operations function actually has a chance.

Phishing is an attack that uses a message, most often email, to trick a recipient into revealing credentials, approving access, or running something harmful, it works on people rather than on software; that is why it survives every generation of technical control.

The main variants need different defenses:

• Bulk phishing: untargeted, high-volume, low effort — mostly stopped by email filtering.
• Spear phishing: targeted at a specific person using details about them or their role. Much harder to filter because the volume is low and the content is plausible.
• Whaling: spear phishing aimed at executives and other high-authority targets.
• Smishing and vishing: the same techniques delivered by text message and by voice call. Voice-based social engineering against help desks has become a notable route to account takeover.
• Multi-factor fatigue and consent phishing: rather than stealing a password, the attacker pushes repeated approval prompts until one is accepted, or persuades the user to authorize a malicious application.

"We have multi-factor authentication" is a weaker statement than it used to be. Phishing has adapted to target the second factor and the approval flow rather than the password, so the relevant question is which form of multi-factor authentication is in use, not whether it exists. Bulk volume is what an email security gateway such as Proofpoint removes; what survives that filter is the part a security team has to work by hand.

Social engineering is the manipulation of people into taking an action that helps an attacker. Phishing is one technique within social engineering, specifically the one delivered by message. All phishing is social engineering, and a good deal of social engineering is not phishing.

Techniques that are social engineering but not phishing:

• Pretexting: inventing a scenario that justifies the request, such as calling a help desk as an employee locked out before a meeting.
• Baiting: leaving something the target will want to use, physically or digitally.
• Tailgating: following an authorized person through a controlled door.
• Quid pro quo: offering something useful, such as fake technical support, in exchange for access or credentials.
• Impersonation in real time: on a phone call or a video call, increasingly aided by synthetic audio and video.

The distinction matters operationally because the defenses differ. Phishing is partly a technical problem with a technical control layer, meaning filtering, link rewriting, and authentication checks, and non-message social engineering has almost no technical control layer at all, and the defenses are procedural: identity verification steps at the help desk, callback rules for payment changes, and clear authority for staff to refuse an urgent-sounding request.

An insider threat is the risk that someone with legitimate access uses it in a way that causes harm. The category covers three quite different situations that get lumped together — and should not be.

• The malicious insider: deliberately steals, sabotages, or leaks. Rare, and the hardest to detect because the activity looks authorized by definition.
• The negligent insider: causes harm without intending to, such as by misconfiguring a storage bucket, emailing a file to the wrong recipient, or bypassing a control to get work done. By volume, the large majority of insider incidents.
• The compromised insider: an outside attacker operating with a legitimate user's credentials. Technically an external attack, and indistinguishable from a genuine insider in the telemetry until you investigate.

That third category is the one that connects insider threat to everyday security operations, and most detection logic aimed at insider behavior, such as unusual data access, access at unusual hours, or access to systems outside a role's normal pattern, fires equally on a compromised account.

Insider threat programs are as much a governance and human resources problem as a technical one, and monitoring employees carries legal and cultural constraints that vary considerably by jurisdiction.

A supply chain attack compromises an organization indirectly, by attacking something it depends on and trusts. The dependency can be software, hardware, or a service provider, and the shared characteristic is that the compromise arrives through a channel the victim has deliberately allowed.

The main forms:

• Software supply chain: a legitimate product or update is modified to include attacker code, so the compromise arrives signed and through the normal update path. The SolarWinds Orion compromise is the reference case.
• Open source dependency: a package a build pipeline depends on is compromised, typosquatted, or taken over by a new maintainer. Log4Shell showed how far a single widely-embedded component reaches.
• Service provider compromise: a managed service provider, cloud vendor, or contractor with access to your environment is breached, and their access becomes the attacker's access.
• Hardware and firmware: components are modified before delivery. Rare and consequential.

These attacks are difficult to defend against with conventional controls because the trust is intentional — you allowed the channel on purpose. The controls that do help are mostly about limiting the blast radius rather than preventing entry, such as restricting what third-party access can reach, segmenting the environment, monitoring vendor accounts as closely as privileged internal ones, and knowing what software you actually run.

They are three distinct things and the sequence matters. A threat is who or what might cause harm. A vulnerability is the weakness they could use. A risk is the combination of the two together with the consequence if it happens.

Two consequences follow from keeping them separate. First, you cannot reduce a threat, you can only reduce your exposure to it, so a program aimed at eliminating threats is aimed at the wrong thing, and second, a vulnerability with no reachable threat and no meaningful impact is not a risk, which is what makes ranking by severity score alone such an unreliable way to prioritize remediation work.

The anatomy of a cyber attack is more consistent than it looks: most intrusions follow a recognizable sequence, even though the specific techniques vary enormously, and the sequence is not rigid, attackers loop back, skip steps, and sometimes achieve their objective in the first hour, and it's still the most useful mental model available for understanding where defense fits.

• Reconnaissance: the attacker learns about the target, such as which services are exposed, who works there, and what technology is in use. Much of this uses public information and produces no signal on your side at all. In MITRE ATT&CK terms the stages below map to the tactics from Reconnaissance (TA0043) through Impact (TA0040).
• Initial access: the attacker gets a first foothold, most often through a stolen credential, a phishing message, or an exposed and unpatched service.
• Execution and persistence: something runs, and the attacker arranges to keep access even if the machine reboots or the password changes.
• Privilege escalation: the attacker acquires more authority than the initial account had.
• Discovery: the attacker maps the environment from inside, finding shares, systems, accounts, and where the valuable data lives.
• Lateral movement: the attacker moves from the first host to others, usually using valid credentials rather than exploits.
• Collection and staging: the data of interest is gathered and prepared, often compressed and moved to a single location first.
• Exfiltration or impact: the data leaves, or the destructive or extortionate action fires.

The time spent in each phase is wildly uneven. Initial access can take seconds. Discovery and lateral movement commonly take days or weeks, and this is where a defender has the most opportunity, because it is the longest phase and the noisiest.

Most attacks start with a valid credential or with a person, not with a technical exploit, that is the single most useful thing to know about attack origins, and it reorders where defensive effort is worth spending.

The common starting points, roughly in order of how often they appear:

• Stolen or purchased credentials: harvested by infostealer malware, reused from an unrelated breach, or bought from a broker who specializes in selling access.
• Phishing and social engineering: including help desk manipulation to reset multi-factor authentication on a targeted account.
• Exploitation of an exposed service: typically an internet-facing remote access appliance, file transfer product, or web application that is unpatched or misconfigured.
• A trusted third party: such as a service provider or a compromised software update.

The defensive implication is uncomfortable for programs organized around malware. An attacker who logs in with a real credential produces no malicious file, triggers no antivirus verdict, and looks like an employee working late. Malware detection does not help here. The controls that address this are identity controls and identity telemetry, meaning phishing-resistant authentication, conditional access, and the ability to detect that a legitimate account is behaving unlike itself.

Initial access is the point at which an attacker first obtains a foothold in an environment. It's the boundary between reconnaissance, which happens outside your systems, and everything else, which happens inside them.

The common initial access techniques are a short list:

• Valid accounts: logging in with credentials the attacker already has.
• Phishing: a message that delivers a payload or harvests credentials.
• Exploiting a public-facing application: attacking something internet-reachable directly.
• External remote services: abusing VPN, remote desktop, or similar access, usually with valid credentials.
• Supply chain compromise: arriving through trusted software or a trusted partner.
• Removable media and physical access: less common in most environments and still relevant in some.

Initial access is different from everything that follows because it is the only phase where the attacker is outside and the only phase where perimeter and identity controls can prevent rather than detect, and once initial access succeeds, the game changes from prevention to detection.

Lateral movement is how an attacker travels from the first system they compromised to the systems they actually want. It is rarely dramatic. Most lateral movement uses legitimate administrative mechanisms with credentials the attacker has stolen — which is precisely why it's hard to detect.

Common methods:

• Remote services with valid credentials: such as remote desktop, SSH, or administrative shares.
• Pass-the-hash and pass-the-ticket: using stolen NTLM hashes or Kerberos tickets from Active Directory without ever knowing the password.
• Remote execution tooling: including built-in administration frameworks that a systems administrator would legitimately use.
• Abusing management platforms: such as configuration management or software deployment systems, which offer reach to many hosts at once.
• Identity provider abuse in cloud environments: such as Microsoft Entra ID or Okta, where movement happens between roles and tenants rather than between hosts.

Lateral movement matters more than almost any other phase for defenders, for two reasons, it is where the attacker spends the most time, and it's where a single detection reveals the whole intrusion rather than one host. Network segmentation, restricting administrative account use, and monitoring authentication patterns between systems are the controls that bite here.

Privilege escalation is the process of gaining more authority than the account you started with. It comes in two forms that are often confused.

Vertical escalation means getting higher privileges on the same system or in the same domain, such as moving from a standard user to a local administrator, or from a domain user to a domain administrator. Horizontal escalation means moving sideways to a different account at a similar level, which is useful when the other account can reach something yours cannot.

The methods that matter most in practice are not usually kernel exploits, despite the attention those receive. They are:

• Credential harvesting from memory or disk: collecting the credentials of anyone who has logged into a compromised host.
• Misconfigured permissions: such as a service account with far more rights than it needs, or a group whose membership has grown for years without review.
• Unpatched local vulnerabilities: which are still common on systems that are patched for internet-facing risk but not for local risk.
• Abuse of legitimate delegation: particularly in cloud environments, where a chain of role assumptions can lead somewhere nobody intended.

The organizational lesson from escalation is that account hygiene is a detection problem as much as a prevention one, and an environment where administrative accounts log into ordinary workstations gives attackers exactly what they need, and that pattern is visible in the logs long before it is exploited.

Data exfiltration is the unauthorized transfer of data out of an environment. It is the objective of a large share of intrusions, and it's generally one of the last things to happen.

Exfiltration is difficult to detect because it looks like normal outbound traffic; that is the whole point of it, and attackers routinely use channels that are already permitted, such as cloud storage services, collaboration platforms, and encrypted web traffic, and they commonly compress and encrypt the data first so that content inspection sees nothing useful.

The signals that do work tend to be about shape rather than content:

• Volume anomalies: an account or host sending far more data than its own history suggests.
• Staging behavior: large archives appearing in unusual locations shortly before the transfer.
• Destination anomalies: traffic to a cloud tenant or service that this organization does not use.
• Access anomalies preceding the transfer: an account reading far more records than its role requires, which is often visible earlier and more clearly than the transfer itself.

Exfiltration is usually easier to catch at the collection stage than at the transfer stage, because collection touches data stores where access patterns are well defined, and transfer hides inside traffic that is permitted by design.

Defender visibility peaks in the middle of an intrusion and collapses at both ends, and that shape explains most of what is otherwise confusing about detection. The stages below are the MITRE ATT&CK tactics read from the defender's side rather than the attacker's.

The pattern is that visibility rises through the middle of the intrusion and falls at both ends. The two blind spots are not equivalent, though. Missing reconnaissance costs almost nothing, since there's little you could have done. Missing collection and exfiltration is expensive, because it is the phase where the harm is actually realized and it is the phase most organizations have the least telemetry for.

If a program's detection strength is concentrated on the endpoint, it is strongest exactly where it already had the best chance, it is weakest on the identity and data layers, which is where modern intrusions increasingly live.

Each stage produces characteristic evidence, and knowing which source carries it turns a coverage conversation from opinion into a checklist.

Read down the "where it lives" column and mark which of those sources you actually collect and retain, and the result is a more honest coverage picture than most maturity assessments produce, and then check retention, because several of these sources are only useful if they go back far enough to cover the beginning of an intrusion you have not found yet.

The source that most often turns out to be missing is data-layer logging. Endpoint and identity telemetry are widely collected. File, object storage, and database access logging frequently aren't, and those are exactly the sources that cover collection and exfiltration.

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.

A security control is any safeguard put in place to reduce risk, and the types of security controls in common use fall along two independent axes rather than one list. That includes technology such as a firewall or an encryption setting, processes such as an access review or a change approval, and rules such as a policy that requires background checks.

Controls are usually described along two independent axes, and mixing them up is the source of most of the confusion in this area. The first axis is type, meaning what kind of thing the control is: technical, administrative, or physical. The second axis is function, meaning what the control does about a threat: prevent it, detect it, correct it, and so on.

Every control has a position on both axes. Multi-factor authentication is technical by type and preventive by function. A quarterly access review is administrative by type and detective by function. A door lock is physical and preventive, and once you hold the two axes separately, the various published lists of "the types of security control" stop contradicting each other, because most of them are quietly listing one axis, the other axis, or a mixture.

These are three functions on the same axis, describing what a control does relative to an adverse event in time.

• Preventive controls act before: they try to stop the event from occurring at all. Multi-factor authentication, network segmentation, input validation, and least privilege are preventive.
• Detective controls act during or after: they identify that something has occurred or is occurring. Logging, monitoring, alerting, intrusion detection, and access reviews are detective.
• Corrective controls act after: they limit the damage and restore the state. Backups and restoration, host isolation, patching in response to a finding, and incident response procedures are corrective.

The relationship between them is the point. Prevention will fail at some rate, which is why detection exists. Detection produces knowledge but changes nothing, which is why correction exists. A program heavy on prevention and light on detection has no idea how often prevention failed, which is a genuinely common position and an uncomfortable one. You cannot fix what you never saw.

Several other functions appear in various frameworks alongside these three, most often deterrent (discourages the attempt, such as visible monitoring or warning banners), compensating (a substitute when the intended control isn't feasible), and directive (instructs behavior, such as a policy). They are legitimate categories and they are also where the published lists start to diverge.

There is no settled answer, and the disagreement is real rather than a matter of one source being wrong. Published lists give three, four, six, seven, or eight, and pages routinely answer "there are three types" while describing six of them in the body.

The reason is the two-axis structure described above:

• By type, there are three: technical, administrative, and physical. NIST SP 800-53 splits the middle one into managerial and operational, which produces four.
• By function, there are commonly six or seven: preventive, detective, corrective, deterrent, compensating, and directive, with some lists adding recovery as separate from corrective.

Three and six are therefore both correct answers to different questions, and a list of eight is usually a merged set containing items from both axes.

Stop asking how many there are and ask what the categorization is for. If you are mapping controls to a compliance framework, use whichever taxonomy the framework uses and stay inside it. If you are trying to find gaps in your own program, the function axis is more useful, because the useful question is "what do we have that detects this, and what do we have that corrects it." If you are assessing coverage across the organization, the type axis is more useful, because it surfaces the administrative and physical controls that a purely technical inventory misses.

Multi-factor authentication requires more than one kind of evidence to prove identity, drawn from different categories: something you know such as a password, something you have such as a device or a hardware key, and something you are such as a fingerprint.

What it reliably stops is the reuse of a stolen password on its own. Credential stuffing, password spraying, and the use of credentials from an unrelated breach are all substantially defeated by a second factor wherever that second factor is actually enforced, and that covers a large share of opportunistic attacks.

What it doesn't reliably stop is more important to understand, because this is where the assumption that multi-factor authentication solves identity risk breaks down:

• Real-time phishing proxies: the victim enters the code into a site that relays it to the real service immediately. One-time codes by text message or authenticator app do not survive this.
• Session and token theft: malware or a phishing kit steals the session cookie after authentication has already succeeded, so the second factor was completed and is irrelevant.
• Push fatigue: repeated approval prompts until somebody accepts one, often at an inconvenient hour.
• Help desk and recovery-flow abuse: convincing a support process to enrol a new device. This bypasses the factor rather than defeating it.
• Anything that does not use the authentication path: such as legacy protocols that were never enrolled, or a service account with a static key.

The distinction that matters is between phishing-resistant factors, meaning those bound cryptographically to the site such as FIDO2 and WebAuthn hardware keys and passkeys, and everything else. NIST SP 800-63B is the reference for what counts as which. Codes and push approvals are a large improvement over a password alone and they are defeated by techniques that are now commonplace. If a program is relying on multi-factor authentication as a primary control, which factor is in use is the question worth answering.

The principle of least privilege says that any user, account, or process should have only the access required to do its job, and no more. It is one of the oldest ideas in security and one of the least consistently implemented.

Its value is entirely about limiting consequences. Least privilege doesn't stop an account from being compromised, it determines what happens next. An attacker who takes over an account with narrow, well-scoped access has to work for every additional step. An attacker who takes over an over-permissioned account may already be finished.

It is hard to implement for reasons that are organizational rather than technical:

• Permissions accrete and rarely get removed: people change roles and keep the old access, so entitlements grow monotonically over a career.
• Nobody wants to be the reason something broke: removing access carries a visible risk of interrupting work and an invisible benefit, which is the wrong shape of incentive.
• Service and machine identities are worse than human ones: because they are frequently provisioned with broad rights during a rushed deployment and then never revisited.
• Determining what "required" means is genuine work: and it requires understanding what each role actually does.

The practices that make it achievable are joiner-mover-leaver processes that actually remove access on the move step, time-bounded elevation instead of standing administrative rights, and periodic review of the accounts that would cause the most damage rather than of everything at once.

Because patching is a continuous obligation with a discontinuous risk profile, and almost every organization has more things to patch than capacity to patch them, and falling behind is the default state, and the interesting question is which things you fall behind on.

The recurring causes:

• Volume: new vulnerabilities are published continuously across every product in the estate, and the arrival rate exceeds most teams' remediation rate.
• Change windows and availability requirements: patching requires downtime or restarts that business processes will not always allow, and in operational technology and healthcare environments may be genuinely unsafe.
• Dependency and compatibility risk: applications certified against a specific version block the underlying platform from being updated.
• Ownership gaps: security finds the vulnerability, an infrastructure or application team applies the fix, and the two report to different people with different priorities.
• Inventory gaps: you cannot patch what you do not know you have, and shadow systems and forgotten appliances are frequently the ones that get exploited.
• Prioritization by severity score alone: which produces a large undifferentiated pile of critical findings and no ordering within it.

That last cause is the one most within a team's control. A severity score describes the weakness in the abstract, not the risk in your environment. Prioritizing by whether the vulnerability is internet-reachable, whether it appears in CISA's Known Exploited Vulnerabilities catalog, and what the affected system holds produces a much shorter and much more defensible list than a CVSS severity threshold does. Scanners such as Rapid7 supply the inventory for that decision; the ordering is still yours to make.

You test them, because the alternative is inferring detection capability from an absence of alerts, and an absence of alerts is exactly what a broken detection stack produces.

The methods, roughly in order of cost:

• Log source health monitoring: alert on the absence of data. A collector that stopped reporting on Friday is the most common and least dramatic detection failure there is, and it is invisible unless something is watching for silence.
• Detection coverage mapping: map your detections to adversary techniques using MITRE ATT&CK, and look at what is not covered. This tells you what you never built, which is different from what is broken.
• Atomic testing: execute individual known techniques in a controlled way and confirm that the expected telemetry was produced, that the detection fired, and that the alert reached the queue. Each of those three is a separate failure point.
• Purple teaming: run an attack sequence with the offensive and defensive teams working together, and record what was seen, what was seen and dismissed, and what was missed entirely.
• Full adversary emulation or a red team exercise: which tests the whole chain including the people and the process, at correspondingly higher cost.

Two failure modes are worth naming because both look like success. The first is a detection that fires correctly into a queue nobody works, which is a coverage number that's technically true and operationally meaningless. The second is a detection that was tuned into uselessness after a noisy period and still appears in the coverage inventory, and testing the path end to end, from technique executed to human acted, is the only way either one surfaces. Proactive searching for activity that never alerted at all is a related discipline, covered in the threat hunting section.