Search the published glossary
Published entries found: 36
DMARC
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It connects the domain in an email's visible From address to a passing, aligned SPF or DKIM result and lets the domain owner publish a handling policy. DMARC is not encryption, a guarantee of inbox delivery or proof that a genuine account has not been compromised.
Multi-Factor Authentication (MFA)
MFA, or multi-factor authentication, requires proof from more than one distinct authentication factor: something you know, possess or are. It helps protect accounts when a password is exposed, but the method, enforcement and recovery paths determine the practical protection. Two passwords are not two factors, and an enabled setting does not prove that every business account or sign-in route is covered.
Web Application Firewall (WAF)
A web application firewall, or WAF, inspects web traffic and applies rules to requests reaching an application through the protected path. It can help filter malicious HTTP requests and reduce exposure to some application attacks. Its value depends on traffic coverage, rule configuration and monitoring; it does not repair vulnerable code, remove a compromise or protect every network service.
Sender Policy Framework (SPF)
SPF, or Sender Policy Framework, lets a domain publish which hosts may use that domain in the SMTP sending identity. The receiver checks the connecting source against the relevant policy. SPF does not authenticate a person, encrypt the message or by itself validate the visible From address. To interpret a result, identify the domain and sending route that were actually evaluated.
DomainKeys Identified Mail (DKIM)
DKIM, or DomainKeys Identified Mail, adds a cryptographic signature associated with a signing domain to an email. A receiver can retrieve the public key using the signature's domain and selector and verify the covered content under the signing rules. DKIM is not message encryption, proof of a named person's identity or a guarantee that an authenticated message is honest or reaches the inbox.
Backup
A backup is a retained copy of data intended to support recovery after loss, damage or an unwanted change. Its usefulness depends on what it contains, which earlier states remain available, who can access it and whether the business can restore the needed function. A file in storage or a successful backup job is evidence of one stage, not proof of complete recovery.
Immutable backup
An immutable backup uses a configured control that restricts changes to protected recovery data, such as deletion or overwriting during a retention period. The protection depends on the provider, protected objects or versions, policy state and privileged permissions. Immutability does not by itself prove that the copy is clean, offline, complete or recoverable with the access and keys the business still has.
Recovery Time Objective (RTO)
RTO, or Recovery Time Objective, is the target limit for restoring a defined system resource or service before its unavailability causes an unacceptable impact. It is a planning objective, not a measured restore result or an automatic contractual guarantee. To use RTO meaningfully, specify the system, clock boundary, dependencies and acceptance condition that determine when the required recovery is complete.
Recovery Point Objective (RPO)
RPO, or Recovery Point Objective, defines the point in time to which data needs to be recovered after a disruption. It is often expressed as the tolerable data gap measured in time. It does not simply equal a backup schedule, and it does not describe how long restoration takes. The usable, consistent data point and the business records it includes must be verified.
Least privilege
Least privilege means giving a person, application or process only the access needed for an approved task, within the appropriate scope and time. It is an authorization principle: it concerns what an identity can do after access is granted. A strong sign-in method helps protect the identity but does not make excessive permissions appropriate.
Passkey
A passkey is a sign-in credential that uses a cryptographic key pair instead of sending a reusable password to the service. The service keeps a public key and the authenticator controls the matching private key. Passkeys can resist credential phishing when implemented correctly, but device ownership, user verification, recovery and account permissions still matter.
Password manager
A password manager stores credentials in a protected vault and helps people create and use different passwords for different accounts. Business features may also support shared access, administration and recovery. The vault controls access to stored secrets; the underlying service still controls its own accounts, permissions, sessions and credential validity.
DNS (Domain Name System)
DNS (Domain Name System) connects domain names with information that Internet services need, such as website addresses and mail-routing records. Different records support different functions. For a business, understanding DNS means identifying the authoritative provider, the account owner and the services that depend on each setting before changing it.
DNSSEC
DNSSEC adds cryptographic signatures that let validating resolvers check the origin and integrity of DNS data through a chain of trust. It does not encrypt DNS queries or certify that a website is safe. Its effectiveness depends on correct signing, delegation and validation, including the relationship between the DNS provider and the parent-zone settings.
HTTPS
HTTPS is HTTP carried over a TLS-protected connection. It helps protect data in transit and lets the client check the server certificate for the requested hostname. It does not prove that the website operator is trustworthy, the application is free of vulnerabilities or the information remains protected after the connection ends.
HSTS (HTTP Strict Transport Security)
HSTS (HTTP Strict Transport Security) is a browser policy delivered through the Strict-Transport-Security response header over HTTPS. It tells a supporting browser to use HTTPS for the covered host for a defined period. Scope, remembered state and preload matter: a policy should be extended only after the required hostnames and certificates can reliably support it.
WordPress plugin vulnerability
A WordPress plugin vulnerability is a weakness in a plugin that can allow an unintended action under particular conditions. A published advisory does not by itself prove that your installation is affected or compromised. Identify the exact component, edition, version, exposure and prerequisites before choosing a supported response and checking the result.
XSS (cross-site scripting)
XSS (cross-site scripting) is an application weakness in which untrusted content is handled in a way that can become executable browser behavior in the site’s context. Prevention depends on how and where the data is rendered. Safe framework behavior, context-appropriate output handling and carefully controlled rich content need review alongside supporting browser policies.
CSRF (cross-site request forgery)
CSRF (cross-site request forgery) involves causing a browser to send an unwanted request to an application that may recognize the browser’s existing credentials. The application needs an appropriate way to verify the request’s legitimacy as well as the user’s permission for the action. A logged-in session or a hidden button does not establish both.
SQL injection
SQL injection occurs when untrusted data becomes part of a database query’s instruction structure instead of remaining a data value. The primary prevention is to keep query structure separate and bind values through a supported database interface, while controlling dynamic query choices and database privileges. A WAF or a normal-looking search result does not establish that separation.
CVE (Common Vulnerabilities and Exposures)
CVE (Common Vulnerabilities and Exposures) provides identifiers and records that help people refer to the same publicly described vulnerability. A CVE identifier is not a severity score, proof that your installation is affected or evidence that an attacker used it. Read the current record, affected products, versions and references together with your own system inventory.
CVSS (Common Vulnerability Scoring System)
CVSS (Common Vulnerability Scoring System) describes vulnerability characteristics and technical severity using a versioned method and vector. A base score is not a complete measure of business risk or proof of exploitation. Read the score with its version, metrics, source and assumptions, then combine it with local exposure, threat evidence and the business function affected.
Zero-day vulnerability
A zero-day vulnerability is a weakness that was not yet known to the relevant vendor or defenders at the time described by the source. A zero-day attack is exploitation of a previously unknown weakness. Distinguish the vulnerability, exploit, disclosure, available fix and your installation’s current state before deciding what the label means for your business.
Vulnerability scanning
Vulnerability scanning uses automated checks to identify possible weaknesses or configuration issues within a defined target and access scope. Results need validation and interpretation. A scan is not automatically a penetration test, proof of compromise or evidence that every page, account and business process is secure.
Phishing
Phishing is deception in a digital message or website that tries to make someone disclose information, grant access, install software or perform a harmful action. It can arrive through email, text, a shared document or a QR code. For a business, the important question is what the request would authorize and how that request can be verified independently.
BEC (business email compromise)
BEC (business email compromise) is a fraud pattern in which a criminal uses a seemingly trusted business communication to redirect money or obtain sensitive information. The instruction may come from an impersonated sender or an abused genuine account. A fraudulent request does not, by itself, prove that your mailbox was compromised; payment verification and account investigation are separate tasks.
Malware
Malware is code or software intended to carry out harmful or unauthorized activity. On a business website it may alter content, redirect visitors, send unwanted messages or maintain unauthorized access. A vulnerability, an unusual file and a scanner alert are not interchangeable with a confirmed infection. Establish what was observed, which system is affected and what evidence supports the next action.
Backdoor
A backdoor is an undocumented access route that can bypass the way a system is intended to be accessed or controlled. In a website incident it may provide continuing unauthorized access even after visible damage is removed. A suspicious file alone does not prove a backdoor, and deleting one confirmed file does not establish that every access path has been closed.
Ransomware
Ransomware is malicious software used to lock or encrypt data or systems and demand payment. An incident may also involve stolen information and threats to disclose it. Restoring files addresses availability, but does not by itself remove unauthorized access or establish whether information was copied. A business needs separate decisions about containment, trusted recovery and possible data exposure.
Data breach
A data breach involves loss of control over information, unauthorized exposure or access, or other handling outside its permitted purpose. For a website incident, distinguish information being reachable, evidence of someone accessing it and evidence of extraction. This page uses an operational explanation: the legal classification, affected population and reporting duties depend on the actual data, circumstances and applicable jurisdiction.
SSRF (server-side request forgery)
SSRF (server-side request forgery) is a weakness that lets someone influence a server-side application to make an unintended request. The server may be able to reach destinations the visitor cannot access directly. Prevention needs controls on the actual destination and connection, together with appropriate network restrictions; a browser policy or a simple URL-looking check does not settle the server-side risk.
CSP (Content Security Policy)
CSP (Content Security Policy) is a browser-enforced policy that can restrict resources and behaviors allowed for a web document. A report-only policy observes violations without enforcing those restrictions. CSP can add a defensive layer, but it does not replace fixing unsafe code, authentication or server-side controls. Build and verify the policy around the website’s actual resources and business functions.
Security hardening
Security hardening is the process of reducing unnecessary exposure and strengthening a system’s configuration for its intended use. It can involve supported updates, fewer services, tighter permissions and controlled administrative access. A useful hardening result is an owned baseline with tested business functions and documented exceptions, not a claim that a system is invulnerable or that an existing compromise has been removed.
Firewall
A firewall controls network traffic according to a defined policy. Network and host firewalls govern traffic paths, while a WAF focuses on web-application traffic and has a different scope. A firewall label or an enabled setting does not prove the intended restriction is effective: verify the relevant source, destination, direction and actual path while preserving required business and recovery access.
Zero Trust
Zero Trust is an approach to access decisions that does not grant implicit trust merely because a user or device is inside a network or owned by the business. The resource, identity, device context and permitted action need an explicit policy and enforcement. A VPN, MFA setting or product label can support parts of that work without establishing a complete Zero Trust architecture.
3-2-1 backup rule
The 3-2-1 backup rule means keeping at least three copies of important data, including the original and two backups, using two different media types and keeping one copy offsite. It is a separation principle, not proof of recoverability. Check shared failure risks, protected access, retained history and actual restore results in addition to counting copies.
Start with the question your business needs to answer
A term is useful when it clarifies an action. If messages appear to use your domain, DMARC helps explain one part of authentication. If a supplier proposes MFA, ask which people and systems it covers and how recovery works. If a website uses a WAF, identify the requests that pass through it and who investigates a legitimate action being blocked.
The glossary is intentionally selective. The search below covers the English entries actually published here. It does not claim that every cybersecurity concept has an independent page or that a definition is sufficient to configure a production system. Use the related guides for a workflow and the service pages when you need to agree work, access and acceptance.
Choose the control by the business question
The published entries cover email-domain authentication, account authentication, web-request filtering and backup/recovery decisions. SPF, DKIM and DMARC explain different parts of the email path. MFA concerns account access; WAF concerns protected web requests. Backup, immutability, RTO and RPO explain different requirements and boundaries of recovery. Each has its own evidence and limits. Least privilege concerns permitted actions; passkeys concern a sign-in credential; a password manager concerns stored credentials and their ownership. Understanding those boundaries helps connect authentication, authorization and recovery without treating them as the same control. DNS locates service information; DNSSEC validates signed DNS data; HTTPS protects a connection; HSTS describes remembered browser policy. These entries distinguish registration, resolution, transport and application protection so a setting is connected to the question it actually answers.
Read the definition together with its limitations and example. Each entry identifies what observation would support a conclusion and what still needs a separate check. This avoids treating a familiar product or acronym as a guarantee, while making it easier for an owner and supplier to discuss the same scope.
Application weaknesses need their own questions. A plugin advisory concerns a particular component and conditions; XSS concerns browser rendering; CSRF concerns unwanted requests; SQL injection concerns database query construction. The definitions separate those boundaries from supporting headers and traffic filters, then connect them to an authorized review or a practical guide.
Vulnerability decisions also need a shared reference and an evidence boundary. CVE identifies the record; CVSS communicates technical severity; zero-day terminology depends on the knowledge and fix timeline; vulnerability scanning describes scoped automated checks. None alone proves local compromise or complete safety. Use the connected guides to assign priorities, review evidence and prepare incident decisions.
Phishing and business email compromise connect technical controls to the actions people are asked to authorize. Phishing explains digital deception across channels; BEC focuses on abused business trust and sensitive instructions. The related guides cover message checks, supplier changes, QR requests, voice verification, post-click response and a safe team rehearsal. A suspicious request alone does not establish a mailbox takeover or identify how an impersonation was produced.
Website incidents also need a shared vocabulary for harmful code, hidden access and information impact. Malware describes harmful or unauthorized code; a backdoor concerns an undocumented access route; ransomware raises separate encryption, control and confidentiality questions; a data breach needs evidence about exposure, access and extraction. These definitions support the incident guides without turning a symptom or a clean scan into a complete conclusion.
Security boundaries also depend on where a control operates. SSRF concerns requests made by the server; CSP governs selected browser behavior; hardening connects the system configuration to an owned baseline; a firewall enforces traffic policy along an actual path. The infrastructure guides connect these ideas to Linux, SSH, Docker and provider responsibilities without treating one setting or product label as complete protection.
Resource access and recovery also need explicit ownership. Zero Trust explains why network location alone is not permission for a business action. The 3-2-1 backup rule describes copy, media and location separation without proving usable recovery. The connected guides map assets, supplier access, remote workflows, application consistency, retained history and mailbox coverage so these principles lead to owned checks rather than product labels.
| Entry | Useful question | Separate question to keep visible |
|---|---|---|
| SPF | Which SMTP identity and sending route were evaluated? | Does that identity align with the visible From domain? |
| DKIM | Which signing domain and signature did the receiver verify? | Is signing active for the intended business source? |
| DMARC | How is use of the visible email domain evaluated? | Was the mailbox or payment request legitimate? |
| MFA | Which factors and access paths are actually enforced? | Can the business recover access safely? |
| WAF | Which web requests are evaluated by the control? | Has the application or account weakness been repaired? |
| Backup | What data and function can the copy help recover? | Was the required restoration actually tested? |
| Immutable backup | Which changes does the policy restrict? | Is the protected copy suitable and accessible? |
| RTO | What recovery time target applies to the defined service? | Which stages and dependencies were actually measured? |
| RPO | To which consistent data point must recovery return? | Does the copy contain that point and the required records? |
| Least privilege | Which action, scope and duration does the job require? | Is the identity also protected at sign-in? |
| Passkey | Which credential and verification model is used? | Who controls its provider, replacement and recovery? |
| Password manager | Who can access and recover the credential vault? | Which copied secrets and underlying accounts still need action? |
| DNS | Where are the active records and who owns them? | Do the website, email and dependent services work? |
| DNSSEC | Does the signed data validate through the intended chain? | Are account ownership and application controls appropriate? |
| HTTPS | Which connection and certificate checks passed? | Is the operator trustworthy and the application secure? |
| HSTS | Which HTTPS-only browser policy covers the host? | Are covered subdomains, certificates and recovery ready? |
| WordPress plugin vulnerability | Does the exact component and reported condition apply? | Is there evidence of exposure or actual compromise? |
| XSS | Where can untrusted content become browser behavior? | Is the relevant rendering path corrected? |
| CSRF | How is the authenticated request’s legitimacy checked? | Is the identity separately authorized for the action? |
| SQL injection | Are query structure and data kept separate? | Are dynamic choices and database privileges appropriate? |
| CVE | Which current record and component does the identifier describe? | Does the installed version and condition actually match? |
| CVSS | Which version, vector and source support the severity assessment? | What exposure and business context determine action? |
| Zero-day vulnerability | What was known and which fix existed at the relevant time? | What is the installation’s current state and evidence? |
| Vulnerability scanning | Which targets, checks and access were actually covered? | Were findings validated and corrections accepted? |
| Phishing | What action does the digital message ask someone to take? | Can that action be verified through a known independent route? |
| BEC | Which business instruction or payment detail is being changed? | Who independently verifies the change and authorizes release? |
| Malware | Which harmful or unauthorized code or behavior was established? | What finding, scope and evidence support the conclusion? |
| Backdoor | Which undocumented access route or persistence was found? | Was the route closed and the relevant entry condition addressed? |
| Ransomware | Which assets are encrypted or affected by extortion? | Are availability, access and information impact reviewed separately? |
| Data breach | What is known about exposure, access and extraction? | Which facts and jurisdiction assessment support organizational decisions? |
| SSRF | Which server-side request and destination are actually permitted? | Do application and network checks govern the real connection? |
| CSP | Which browser policy is delivered and is it enforced? | Were required resources and business functions accepted? |
| Hardening | What configuration reduces unnecessary exposure? | Who owns the baseline, exceptions and future changes? |
| Firewall | Which traffic policy is enforced at which point? | Does actual reachability match the intended path? |
| Zero Trust | Which identity, device context and resource action are authorized? | Where is the decision actually enforced and maintained? |
| 3-2-1 backup rule | Which original and backup copies have media/location separation? | What shared access, history and restoration limits remain? |
How to use an entry with your current supplier
Write down the system and action first, then ask the supplier to explain how the term applies there. A useful answer names the control, its location, the accounts or traffic it covers and the evidence that it is active. Ask what is excluded and who owns follow-up when the business introduces a new connection.
You do not need to memorize the terminology. Keep a short record of the agreed result: which sender should authenticate, which role should be challenged or which request should remain allowed. If the answer requires a change, agree authority, testing and a recovery route before carrying it out. A definition is preparation for that conversation, not permission to experiment.
Definitions, guides and services have different purposes
A glossary entry explains a concept and its boundaries. A guide walks through a particular diagnostic or planning task. A service page explains work that can be scoped with CyberFixCrew. These pages link to one another where the relationship helps the reader, but do not make a definition compete with every implementation question.
For example, understanding DMARC alignment is different from mapping all billing and website senders before enforcement. Understanding MFA is different from migrating staff without locking them out. Understanding WAF filtering is different from investigating a checkout false positive. When the implementation depends on a provider, use that provider's current documentation as well.
Sources, examples and updates
The entries cite relevant standards bodies or product documentation and distinguish the standard from a provider's implementation. Examples are labeled and do not become claims about a customer. A revision date identifies the entry's recorded content update; it is not a promise that the underlying product has stayed unchanged since then.
Our methodology page explains the difference between a source-based explanation, an original decision framework and a local experiment. A documented limitation is part of a useful definition. If evidence is unavailable, the page should leave the uncertainty visible instead of filling it with a score, invented measurement or unsupported guarantee.
Using the glossary across countries and systems
CyberFixCrew's Israeli company identity and website/digital-infrastructure specialization inform the topics we choose for worldwide business readers. The technical concepts can be relevant across countries, but a definition is not a universal compliance ruling. Legal duties, contractual requirements, service editions and available features need their own checks.
For help with an unfamiliar term, describe the business task and the system involved without sending credentials or customer data. We can clarify whether the question is definitional, a configuration task or a current incident, and what scope would be useful. Remote work and availability are agreed separately.