Repository navigation
content: Foundation leaf pages (EN + French) - #2292
Conversation
…er Culture, Human Element, Principles), subject-specific structure, EN + French
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5eeaeb0123
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Consider an employee whose laptop is taken from a car. No single control decides the outcome; the layers do. | ||
|
|
||
| - **Full-disk encryption** (preventive, technical) keeps the files unreadable to the thief. | ||
| - **A password manager and multi-factor authentication** (preventive, technical) mean that saved sessions alone do not open company accounts. |
There was a problem hiding this comment.
On a stolen laptop with a still-valid browser session, the session secret is already a post-authentication credential, so neither the password manager nor MFA is consulted and the thief can access company services until the session expires or is revoked. NIST describes session continuity as possession of the session secret. The mirrored French page repeats this error; describe these controls as preventing fresh logins, while session revocation, short lifetimes, or device-bound sessions address saved-session access.
Useful? React with 👍 / 👎.
| | Identity and access | Multi-factor authentication blocks the stolen password on its own; [least privilege](least-privilege.md) means the account can reach only what the job requires | The attacker is inside, but limited to one user's scope | | ||
| | Network | Segmentation and firewalls keep that user's zone apart from servers and sensitive systems | Lateral movement becomes possible | | ||
| | Host and application | Patched, hardened systems and input validation deny the easy exploits needed to escalate | The attacker can run code on more machines | | ||
| | Data | Encryption at rest and in transit, plus offline backups, keep information unreadable or recoverable | Data may be exposed, but can be restored | |
There was a problem hiding this comment.
In the phishing scenario established above this table, encryption at rest and in transit is normally transparent to the legitimate application and user account, so an attacker using the victim's session or running code on a compromised host can still receive plaintext. Offline backups restore availability but do not make exposed data unreadable. This row therefore is not another barrier the same attacker must cross; qualify the threats encryption covers or use controls such as record-level authorization, isolated keys, or tokenization for this scenario.
Useful? React with 👍 / 👎.
|
|
||
| Consider a signed-in user, Alice, whose browser asks an accounting app for invoice 1042. Following the request step by step shows where each check belongs and what goes wrong when one is missing. | ||
|
|
||
| 1. **Alice's session token arrives.** The server validates it and concludes "this is Alice." That is authentication, and it is only as strong as the login behind it: a single reused password makes it easy to forge. |
There was a problem hiding this comment.
A reused password lets an attacker complete the normal login flow and receive a legitimate session token; it does not make an existing random or signed token easy to forge. Token forgeability instead depends on generation, signing keys, and validation, while NIST defines the session secret as being issued after authentication. Saying the password enables token forgery teaches the wrong failure mechanism; describe it as making authentication and acquisition of a valid session easy.
Useful? React with 👍 / 👎.
…laims (Codex review)
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 81b7f7853b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| # Vulnerabilities and exploits | ||
|
|
||
| A **vulnerability** is a flaw or weakness in a system that could let an attacker undermine its security, while an **exploit** is the concrete code or technique that actually takes advantage of that flaw. A vulnerability is a condition that exists whether or not anyone ever abuses it; an exploit is the act of abuse. A house with an unlocked door has a vulnerability, and a burglar walking through that door is the exploit. |
There was a problem hiding this comment.
On this foundational terminology page, the sentence first defines an exploit as code or a technique, but then contradicts that definition by calling the act of abuse itself an exploit. The act is exploitation, while an exploit is the method, payload, or code used to perform it; MITRE similarly distinguishes an exploit capability from the act of exploitation. Correct the burglar analogy and the mirrored French sentence so learners are not taught two meanings for the term the page is intended to clarify.
Useful? React with 👍 / 👎.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cf86a67bd4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| Consider an employee whose laptop is taken from a car. No single control decides the outcome; the layers do. | ||
|
|
||
| - **Full-disk encryption** (preventive, technical) keeps the files unreadable to the thief. |
There was a problem hiding this comment.
If the stolen laptop is powered on and unlocked, as would be necessary for the thief to use the open browser sessions discussed in the next bullet, full-disk encryption has already released the volume key and does not keep local files unreadable. NIST describes full-disk encryption as open to a user unless the device is locked, with protection tied to power state (NIST presentation); qualify this control as protecting a powered-off or securely locked device, and make the same correction on the mirrored French page.
Useful? React with 👍 / 👎.
| | Cybercriminals | Money | Moderate to high, often bought or rented | Ransomware, fraud, theft of data they can sell | | ||
| | Nation-state actors | Espionage, sabotage, strategic advantage for a government | High: funding, time, custom tooling | Long, quiet intrusions into government, defense, and critical infrastructure | | ||
| | Hacktivists | A political or social cause | Low to moderate | Website defacement, leaks, disruption timed to events | | ||
| | Insiders | Grievance, money, or simply carelessness | Legitimate access, which often outweighs skill | Misuse of access by current or former employees and contractors | |
There was a problem hiding this comment.
Including carelessness as a threat-actor motivation contradicts this page's earlier statement that honest mistakes are non-adversarial threats and that the remainder focuses on deliberate actors. NIST likewise classifies human error as a non-adversarial threat, so a careless employee belongs under accidental threat sources; reserve this actor row for insiders who intentionally misuse access, and update the French mirror as well.
Useful? React with 👍 / 👎.
…less insiders out of actor table (Codex review)
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8758c573ba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | | Tester with authorization | Person without it | | ||
| |---|---|---| | ||
| | Legal standing | Lawful work under a signed agreement | A likely offense under computer-misuse laws | | ||
| | Liability | Shielded by the contract, within its terms | Personally exposed for every action taken | |
There was a problem hiding this comment.
When an authorized assessment causes an outage, captures third-party data, or implicates another applicable law, staying within the technical scope does not automatically shield the tester from liability. NIST SP 800-115 §6.6 says legal concerns must be evaluated separately and that contracts may include negotiated indemnity or limitation-of-liability clauses, so this row should say that liability is governed by the agreement and applicable law rather than promise protection; the French mirror makes the same promise.
Useful? React with 👍 / 👎.
|
|
||
| # Misconfiguration | ||
|
|
||
| **Misconfiguration** is the gap between a system that could be secure and one that actually is, created when software is deployed with weak defaults, unnecessary features, or settings that were never tightened. The code may be sound and the design may be strong, yet the running system still exposes data or access because someone left a setting at its factory value, skipped a step, or did not understand what an option controlled. It is consistently one of the most common root causes of breaches, and it sits squarely on the human side of security because it stems from decisions and oversights, not from a flaw in the software itself. |
There was a problem hiding this comment.
When a vendor ships an open permission or known password as the default, the deployment can be hardened by changing configuration, but the unsafe default is still a product design flaw affecting every installation. This claim that weak defaults are categorically human oversights and not software flaws directly contradicts design-and-development-errors.md:26,36, which correctly classifies shipped insecure defaults as construction errors; distinguish vendor-owned defaults from an operator accepting or later drifting from a secure baseline, and make the same correction in the French mirror.
Useful? React with 👍 / 👎.
| | Project | Where and when | The question behind it | What it became | | ||
| | --- | --- | --- | --- | | ||
| | Spacewar! | MIT, PDP-1, 1961 to 1962 | Could this small computer run a real-time, two-player game with physics? | One of the first influential video games, used by DEC to demonstrate the machine | | ||
| | Unix and C | Bell Labs, 1969 to 1973 | What would a simpler, more pleasant operating system look like? | The ancestor of most server, desktop, and mobile operating systems in use today | |
There was a problem hiding this comment.
The desktop part of this claim is false: Windows is the dominant desktop family, while Microsoft describes Windows NT as a separately created operating system that merely supported a POSIX subsystem, not as a Unix descendant (Microsoft history); current desktop usage is also predominantly Windows (StatCounter). Limit the claim to Unix descendants such as Linux, Android, BSD, macOS, and iOS, and update the identical French row.
Useful? React with 👍 / 👎.
…ration, Unix lineage (Codex review)
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3cce6a457b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | | Protective intent | Harmful or self-serving intent | | ||
| | --- | --- | --- | | ||
| | **Authorized** | White hat: penetration testers, security researchers, and in-house defenders working under a contract, a scope, or a disclosure policy | Rare in theory, but real: an insider or contractor who abuses legitimate access | |
There was a problem hiding this comment.
When an employee uses legitimate credentials to steal data, the owner authorized the employee's normal job access, not that harmful activity, so the answer to the authorization question above is still “no.” Placing this example in the authorized quadrant conflates possession of access with permission to perform the action and undermines the page's stated classification; move malicious misuse to the unauthorized/harmful category or rename the axis to describe access capability.
Useful? React with 👍 / 👎.
|
|
||
| # Authorization and consent | ||
|
|
||
| **Authorization is the explicit permission that turns an otherwise hostile act into a legitimate one.** The same technique, such as scanning a network, cracking a password, or exploiting a flaw, is either professional security work or a crime, and the difference is rarely in the technique itself. It is in whether the owner of the system agreed, in advance and in writing, to let someone act against it. Consent is the ethical and legal ground every practitioner stands on. |
There was a problem hiding this comment.
For a person merely scanning publicly exposed ports without crossing an access control or obtaining protected data, lack of written permission does not by itself make the scan a crime in every jurisdiction. Even the U.S. DOJ's CFAA policy requires additional access, knowledge, and enforcement elements, so this categorical work-or-crime framing can misteach the legal boundary; retain the ethical requirement to obtain permission but describe criminal liability as dependent on the conduct and applicable law. DOJ CFAA charging policy
Useful? React with 👍 / 👎.
| - **Prosecution policy.** In May 2022 the U.S. Department of Justice announced that good-faith security research should not be charged under the Computer Fraud and Abuse Act, defining it as access solely for testing, investigating, or correcting a security flaw in a way designed to avoid harm. | ||
| - **Professional titles.** "Ethical hacker" and "security researcher" are now mainstream job titles built directly on the white hat idea, and NIST describes penetration testing as testing that mimics real-world attacks under defined conditions. | ||
|
|
||
| Many legal disputes still turn on whether access was authorized, which is exactly the gap the grey hat label names. Each of these mechanisms narrows that gap by making permission explicit before anyone starts probing. |
There was a problem hiding this comment.
For U.S. researchers acting without an owner's permission, neither a professional title nor the DOJ's decision not to charge qualifying good-faith research makes authorization explicit before probing. The DOJ states that this policy only guides prosecutors and creates no enforceable right or benefit, and it does not resolve civil liability, state law, or other federal offenses; keep disclosure and bounty terms as the authorizing mechanisms and describe the policy and job titles separately. DOJ CFAA charging policy
Useful? React with 👍 / 👎.
…diction-dependent criminality (Codex review)
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b21e86e01f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| Consider a clinic hit by modern "double extortion" ransomware. The attackers first copy patient files to their own servers, then encrypt everything on the clinic's network. | ||
|
|
||
| 1. **Availability fails first and most visibly.** Staff cannot open schedules or patient charts, and appointments are canceled. |
There was a problem hiding this comment.
In this scenario, line 41 explicitly says the attackers copy the patient files before encrypting the network, so confidentiality fails before availability. Calling availability the first failure reverses the stated chronology and conflicts with the next point saying confidentiality has already failed; remove “first” or reorder the sequence, and make the same correction in the French mirror.
Useful? React with 👍 / 👎.
|
|
||
| 1. **The design flaw.** The spec says "user enters their email, then chooses a new password on the next screen." Nothing ties the second screen to proof of email ownership, so anyone who knows an address can take over the account. No amount of careful coding fixes this; the step is missing from the plan. | ||
| 2. **The edge case.** After the design is corrected to email a reset link, the token never expires and is not invalidated after use. An old link found in a mailbox months later still works. | ||
| 3. **The weak default.** The token is generated with a predictable value, because the convenient random function in the language was not designed for security. An attacker can guess valid tokens. |
There was a problem hiding this comment.
Choosing a non-cryptographic random function for a reset token is an implementation error, not a weak default: the page’s own table defines an insecure default as a shipped configuration that users are expected to harden. This label blurs the distinction the page is teaching between design, implementation, and configuration errors; relabel the example or replace it with an actual unsafe default, including in the French mirror.
Useful? React with 👍 / 👎.
|
|
||
| Practitioners manage dual-use knowledge through norms and judgment rather than a single rule. The main levers, roughly from individual choice to state policy: | ||
|
|
||
| 1. **Coordinated disclosure.** A researcher reports a flaw to the vendor and allows time for a fix before publishing details. Some teams set fixed deadlines; Google Project Zero, for example, gives vendors 90 days to ship a patch and then publishes. |
There was a problem hiding this comment.
Project Zero does not simply publish vulnerability details after giving the vendor 90 days to ship a patch. Under its current 90+30 policy, a patch released within 90 days is followed by a 30-day adoption window, while an unpatched issue is disclosed at the 90-day deadline; actively exploited issues follow a separate seven-day deadline. The current wording therefore misstates the example used to explain disclosure tradeoffs; update it and the French mirror to match Project Zero's policy.
Useful? React with 👍 / 👎.
…s, Project Zero 90+30 policy (Codex review)
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d59ed97511
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - Because both systems synchronize their clocks against the same time source, the two events line up in the right order. | ||
| - The logs were shipped in real time to a central store the database administrators cannot modify, so the record is the same one written at 22:14. | ||
|
|
||
| The investigation now has a concrete starting point: a single person to talk to, and evidence that is hard to dispute. Remove any one of those conditions and the trace collapses. A shared admin account means anyone could have done it. Unsynchronized clocks mean the login and the deletion may not even appear to be related. Logs stored on the same server could have been wiped along with the table. |
There was a problem hiding this comment.
When an attacker controls the known laptop, steals the authenticators, or hijacks an authenticated session, these logs can look identical while j.martin did not perform the deletion. NIST defines authentication as proof that the claimant controls authenticators bound to the account, not proof that the enrolled person performed every subsequent action. Treat this evidence as identifying an account and an investigation lead, and require corroboration before describing the action as attributable to a single person or hard to dispute.
Useful? React with 👍 / 👎.
| ## Concepts | ||
|
|
||
| Before any technique makes sense, the field needs a shared vocabulary: what we protect, who might attack it, how they get in, and what we do about it. Assets, attack surface, threats, threat actors, vulnerabilities, exploits, and controls are the building blocks, and the CIA triad of confidentiality, integrity, and availability defines what being secure actually means. These terms combine into the single idea the rest of the library serves, which is risk. | ||
|
|
||
| ## Principles |
There was a problem hiding this comment.
These new Concepts and Principles entries are plain headings and prose, so the Foundation section page provides no link to either new child index. This conflicts with the section-page requirement in .github/CONTRIBUTING.md:72 that every child page and subsection be linked, and the French mirror has the same omission. Link the headings or descriptions to concepts/index.md and principles/index.md so readers can navigate into the added sections.
Useful? React with 👍 / 👎.
…t vs person attribution (Codex review)
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f1be15e27
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | What you shrink | The question to ask | Typical measures | | ||
| | --- | --- | --- | | ||
| | **Data** | Does this purpose actually need this field, and for how long? | Collect only required fields, set retention periods, delete or archive when the purpose is served | |
There was a problem hiding this comment.
When the stated processing purpose has ended, archiving the same identifiable records does not minimize the data held or its breach exposure, and it contradicts the deletion step below and this page's own storage-limitation explanation. GDPR allows longer archival retention only for specified public-interest, scientific, historical, or statistical purposes with safeguards, not ordinary indefinite archiving (GDPR Article 5). Recommend deletion or anonymization by default, qualifying archival retention with a separate valid purpose, and mirror the correction in French.
Useful? React with 👍 / 👎.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: db20da24fb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| The most common way to classify a control is by where it acts on the timeline of a security event. | ||
|
|
||
| 1. **Preventive controls act before the event** and try to stop it from happening at all. Access permissions, strong authentication, encryption, firewalls, and security awareness training all lower the likelihood that an attack succeeds. | ||
| 2. **Detective controls act while it unfolds** by revealing that something has happened or is happening. Logging and monitoring, intrusion detection systems, audits, and alerts on unusual activity do not block anything, but they shorten the time an event goes unnoticed. |
There was a problem hiding this comment.
Defining detective controls as acting only while an event unfolds excludes retrospective log review and audits, even though audits are listed in this same sentence. Detective controls identify that an event occurred either during or after it; for example, NIST explicitly requires audit capabilities that support after-the-fact incident investigations. Describe these controls as operating during or after an event so readers do not misclassify forensic review, and make the same correction in the French mirror.
Useful? React with 👍 / 👎.
| Authentication evidence is traditionally grouped into three factors. Each has its own weak spot, which is why combining them matters. | ||
|
|
||
| - **Something you know:** passwords and PINs. They can be guessed, phished, or leaked from one service and replayed on another when people reuse them. | ||
| - **Something you have:** hardware tokens, authenticator apps, or passkeys bound to a device. They resist remote guessing, but the device can be lost or the user tricked into approving a login. |
There was a problem hiding this comment.
This groups distinct possession authenticators under failure modes that do not apply to passkeys: passkeys may be synchronized rather than bound to one device, and WebAuthn passkeys are verifier-bound and phishing-resistant, so tricking a user into approving an attacker's login describes push-notification MFA rather than passkeys. NIST separately classifies out-of-band push and phishing-resistant cryptographic passkeys and explicitly recognizes syncable passkeys. Split these authenticator types and state their respective weaknesses, including in the French mirror.
Useful? React with 👍 / 👎.
|
|
||
| # Zero trust | ||
|
|
||
| **Zero trust** is a security model built on a single rule: no user, device, or network location is trusted by default, and every request to access a resource must be verified before it is allowed. Its slogan is "never trust, always verify." Instead of asking "is this connection coming from inside our network?", a zero trust system asks "who is this, what device are they on, what are they asking for, and does that make sense right now?" and it asks that question again for every request. |
There was a problem hiding this comment.
Saying that zero trust repeats the full verification for every request overstates the model and can imply that every application request requires a new authentication decision. NIST SP 800-207 defines access to each resource as granted on a per-session basis and notes that trust evaluation may have occurred recently rather than immediately before each transaction; a scoped session can then be monitored and revoked as conditions change. Use per-resource access or session wording here and in the repeated French and authentication-page claims.
Useful? React with 👍 / 👎.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6c4af2880a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | Property | The question it asks | What a failure looks like | Controls that serve it | | ||
| | --- | --- | --- | --- | | ||
| | Confidentiality | Can only the right people read it? | A breach exposes customer records | Encryption, access controls, authentication | |
There was a problem hiding this comment.
For the bank-tampering and silent configuration-edit scenarios named in this row, an attacker who can modify the data can normally recompute an ordinary checksum, so it does not establish integrity against malicious changes. NIST explicitly warns that even an unkeyed cryptographic hash provides no assurance when an adversary can compute a new value; name a MAC or digital signature here, or qualify checksums as detecting accidental corruption, and make the same correction in the French mirror.
Useful? React with 👍 / 👎.
|
|
||
| **The surprise neighbor.** An in-scope IP range turns out to include addresses now leased to a different company. Scope on paper does not match reality, and those hosts belong to someone who never consented. | ||
|
|
||
| **The verbal yes.** A client contact says on a call, "Go ahead and try the VPN too." Until that is confirmed in writing by someone with authority, it is implied consent, not authorization. |
There was a problem hiding this comment.
A spoken “go ahead” is express oral consent, not implied consent; implied consent is inferred from conduct or circumstances, while express consent may be given verbally or in writing (Cornell LII). Written confirmation may still be required by the agreement, necessary to prove scope, or needed from someone with actual authority, but this example teaches the central terminology incorrectly; describe the VPN as outside the written rules of engagement until they are amended, and correct the French mirror as well.
Useful? React with 👍 / 👎.
6c4af28 to
d47e7e9
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d47e7e959f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - A [vulnerability](vulnerabilities-and-exploits.md) is the flaw that would let it succeed, such as an unpatched server. | ||
| - The **harm** is the realized loss, measured against the [CIA triad](cia-triad.md): data disclosed, altered, or made unavailable. | ||
|
|
||
| A threat with no matching weakness stays hypothetical. A weakness that no actor cares to exploit stays dormant. Risk appears only when both line up over an [asset](assets-and-attack-surface.md) worth something. |
There was a problem hiding this comment.
Risk does not require an interested actor or an exploitable weakness: power loss, fire, hardware failure, and accidental deletion can create real risk to an asset without anyone choosing to exploit it. The universal claim here conflicts with the page's broad definition of a threat and can cause readers to omit environmental and accidental threats; restrict this statement to adversarial risk or include non-adversarial threat sources.
Useful? React with 👍 / 👎.
|
|
||
| The order is not optional. A system must know who a principal is before it can sensibly decide what that principal may do, so authentication always comes first and authorization follows. The two are often shortened to "authN" and "authZ" to keep them distinct in speech and in code. | ||
|
|
||
| A useful test: if the answer changes when a different person logs in, it is authentication. If the answer changes when the same person requests a different resource, it is authorization. A valid login that then reaches someone else's records is an authorization failure, not an authentication one, even though both happened in the same request. |
There was a problem hiding this comment.
When Alice may export payroll but Bob may not, the answer changes when a different person logs in, yet that decision is authorization, not authentication. Authentication verifies the claimed identity; authorization commonly varies by that identity and the requested action or resource, so this proposed test teaches readers to misclassify ordinary role- and user-based access checks.
Useful? React with 👍 / 👎.
| 4. Inside the mailbox, they find a folder link set to public months earlier for a contractor. | ||
| 5. Records leave the company, unnoticed for weeks because nothing watches for bulk downloads. | ||
|
|
||
| No step required malice, and none looked dramatic. Breaking the chain anywhere, a password manager, a second factor, a link that expires, an alert on unusual access, would have stopped it. |
There was a problem hiding this comment.
In this walkthrough, step 3 has an attacker deliberately replay stolen credentials and the later steps culminate in records leaving the company, so the conclusion that no step required malice contradicts the scenario. If the intended lesson is that the analyst's contributions were ordinary mistakes, limit the claim to those user actions rather than erasing the attacker's deliberate conduct.
Useful? React with 👍 / 👎.
|
@codex review |
d47e7e9 to
f5993cf
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5993cf755
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## Two questions, asked in order | ||
|
|
||
| The order is not optional. A system must know who a principal is before it can sensibly decide what that principal may do, so authentication always comes first and authorization follows. The two are often shortened to "authN" and "authZ" to keep them distinct in speech and in code. |
There was a problem hiding this comment.
For public resources, login pages, and explicit deny decisions, the caller can be authorized or rejected without first establishing an identity; the OWASP Authorization Cheat Sheet explicitly notes that authentication is not always required. Saying the order is never optional teaches an incorrect access-control invariant, so qualify this as the usual sequence for identity-protected resources and update the French mirror.
Useful? React with 👍 / 👎.
|
|
||
| ## Where this sits among the fundamentals | ||
|
|
||
| A vulnerability is only a risk when it lives on something worth protecting and someone wants to abuse it. It is part of the [assets and attack surface](assets-and-attack-surface.md) you expose, exploitation is what [threats and threat actors](threats-and-threat-actors.md) attempt, a successful exploit breaks one or more goals of the [CIA triad](cia-triad.md), and [controls and countermeasures](controls-and-countermeasures.md) exist to close the flaw or blunt its impact. |
There was a problem hiding this comment.
When malformed benign input triggers a memory bug or an operator accidentally activates a dangerous configuration, a vulnerability creates risk even though nobody wants to abuse it. NIST's threat-source definition explicitly includes situations that accidentally trigger vulnerabilities, and this repository's threats-and-threat-actors.md:25 now recognizes such events. Replace the willing-abuser requirement with reachability by a threat source or event, including in the French mirror.
Useful? React with 👍 / 👎.
|
|
||
| ## Naming flaws so everyone means the same thing | ||
|
|
||
| Two public catalogs keep the industry speaking a common language. CVE (Common Vulnerabilities and Exposures) assigns a unique identifier to each specific publicly known vulnerability, so a single flaw has one name everywhere. CWE (Common Weakness Enumeration) classifies the underlying weakness types, the recurring patterns from the first table. A CVE entry points to the CWE category it belongs to, linking the one instance back to the general mistake. |
There was a problem hiding this comment.
A CVE record does not necessarily point to a CWE: the official CNA rules say records should use CWE and explicitly allow the problem type to remain undetermined when insufficient information exists. Readers will encounter valid CVEs without a CWE mapping, so describe this as an optional or common relationship rather than a property of every entry, and mirror the correction in French.
Useful? React with 👍 / 👎.
| | ARPANET host software | Connect research computers | The open RFC process that still governs internet standards | | ||
| | CERN document sharing | Organize physics papers | The World Wide Web | | ||
|
|
||
| In every row the unintended use eventually mattered more than the intended one. That is the repurposing move: a tool built for one goal is turned toward another, and the surprise becomes the real contribution. |
There was a problem hiding this comment.
The CERN row does not support the claim that every example became an unintended use: CERN says the Web was conceived and developed specifically for information sharing among scientists, which is the purpose named in the table. Reframe these as inventions that outgrew their original audience rather than asserting that each was an unintended repurposing, and make the same change in the French mirror.
Useful? React with 👍 / 👎.
| |---|---| | ||
| | Curiosity justifies the act | Motive does not undo damage to real systems and people | | ||
| | Access is the only way to learn | Labs, capture-the-flag events, and authorized tests teach the same skills legally | | ||
| | "You call us criminals" is unfair | Authorization, not a hostile label, is what actually separates lawful work from a crime | |
There was a problem hiding this comment.
For an uninvited scan or research activity, lack of permission alone does not establish a crime, while owner permission cannot legalize conduct outside that owner's authority or other applicable laws. For example, the U.S. DOJ's CFAA policy requires additional access and knowledge elements and treats charging as a fact-specific decision. Describe authorization as the boundary for authorized ethical testing, with criminal liability depending on conduct and jurisdiction, and correct the French row too.
Useful? React with 👍 / 👎.
f5993cf to
6fff39e
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6fff39e011
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| # Assets and attack surface | ||
|
|
||
| **An asset is anything an organization would be harmed to lose, and the attack surface is the complete set of points where those assets can be reached or attacked.** The two ideas only make sense together. An asset with no way in is not at risk, and a way in that leads to nothing of value is not worth an attacker's time. Security lives in the overlap: a valuable thing, plus a path to it. |
There was a problem hiding this comment.
An asset can remain at risk even when no attacker can reach it: fire, power loss, hardware failure, and accidental deletion can all affect an isolated asset, as this commit itself acknowledges in threats-and-threat-actors.md:25. Calling such an asset “not at risk” teaches readers to omit non-adversarial threats from risk assessment; qualify this as adversarial attack risk and present attack surface as only one source of exposure, including in the French mirror.
Useful? React with 👍 / 👎.
|
|
||
| ## The export-control origin of a loaded term | ||
|
|
||
| The phrase "dual-use" did not start with computers. It comes from arms control, where a dual-use good is a technology, such as a centrifuge, a chemical precursor, or a strain of pathogen, with both civilian and military uses. The Wassenaar Arrangement, a multilateral export-control regime founded in 1996, exists to track such goods as they cross borders. In 2013 its control list was expanded to cover "intrusion software," an attempt to treat exploit and surveillance tools like weapons. The reaction from researchers was immediate: the same code a government might buy for surveillance is what a defender uses to test and patch, so a rule written to stop one blocks the other. The episode showed how hard the category is to regulate when the item is knowledge rather than hardware. |
There was a problem hiding this comment.
This wording implies that the 2013 list directly controlled exploit payloads as “intrusion software,” but the controls covered systems and software for generating, commanding, controlling, or delivering intrusion software, plus related development technology; the U.S. government's implementation FAQ explicitly says proprietary machine-executable exploits are outside the relevant software control (BIS FAQ). Distinguish the controlled tooling and technology from the payload itself so this historical example, and its French mirror, do not teach the wrong export-control scope.
Useful? React with 👍 / 👎.
| | Mechanism | What it produces | What it still cannot do | | ||
| |---|---|---| | ||
| | Logging | A timestamped record that an identity performed an action | Prove the record was not altered afterward | | ||
| | Auditing | Protected, reviewable logs that are collected and analyzed | Stop the actor from claiming the account was not theirs | |
There was a problem hiding this comment.
Auditing does not itself produce protected logs or make a log durable; it is the independent review and examination of records and activities, while integrity protection, collection, and retention are separate audit-log controls (NIST audit definition). This table and the following sentence therefore teach a false progression from logging to tamper resistance. Separate audit review from audit-log generation and protection, and make the same correction in the French page.
Useful? React with 👍 / 👎.
|
|
||
| ## The confused deputy and broken access control | ||
|
|
||
| The most common failures sit in authorization. **Broken access control** means the server trusts the client to stay inside its lane: changing an ID in a URL reaches another account's data because the server authenticated the session but never re-checked ownership. The **confused deputy** is subtler, where a trusted program is tricked into misusing its own higher privileges on behalf of a less privileged caller. Both come from checking identity once and then assuming every later action is allowed. |
There was a problem hiding this comment.
A confused-deputy flaw can occur on the caller's first request and even after the caller was correctly authenticated, so it does not require identity to have been checked once and then reused. The failure is that an intermediary exercises its own greater authority without preserving or constraining the original requester's authority, as described by MITRE CWE-441. Replace the shared-cause conclusion so learners do not conflate this flaw with stale or missing per-request authorization, and update the French mirror as well.
Useful? React with 👍 / 👎.
…er Culture, Human Element, Principles), EN + French Add 26 leaf pages across five Foundation sections. Each page has an original, subject-driven section structure derived from its own topic (no shared template), with tables, worked scenarios, and prose cross-links. Add a new Concepts section index, link each section index to its leaves, and move the CIA triad to Concepts. Fully accented French mirror for every page.
6fff39e to
f014f92
Compare
Adds the 26 Foundation leaf pages defined in the Library Structure tree (Concepts, Ethics and Philosophy, Hacker Culture, Human Element, Principles), plus the new Concepts section index, and updates the section indexes to link them. Each page has its own subject-specific structure (no shared template). French mirrors under i18n/fr/foundation.
Lint: no em/en dashes, no curly quotes, no leaked tags, FR accents present, References/Références last, 0 broken relative links.