About

What this library contains

Failure patterns: structural, recurring failures of an organization or architecture that make a cybersecurity incident worse. The model is CWE’s — a taxonomy of generic weaknesses, independent of any specific case.

An entry describes a pattern, not an event. It exists to help you ask “does this apply to us?” and, if so, know what to do — before an incident, and during one.

What it does not contain

No entry mentions a client, a specific industry, a date, a geographic location, or a product or vendor name. This is not an editorial precaution — it is a design constraint. A pattern that only makes sense with the detail of a real case is not a pattern yet.

The trade-off is accepted: entries are less dramatic than an incident write-up. In exchange, they are reusable by someone whose environment has nothing to do with the one where the pattern was observed.

How to read an entry

Each entry carries three independent scales.

• Severity — what the failure costs when it surfaces during an incident.
• Detection difficulty — how hard the pattern is to spot in your own environment before it hurts. A severe pattern that is trivial to detect does not warrant the same effort as a moderate one that is nearly undetectable.
• Frequency observed — how often the pattern is seen in the field. It is meant to prioritize, not to measure risk.

The five sections always follow the same order: the pattern, what it costs, how to check whether you’re affected, what to do ahead of time, and what remains possible once you’re already in an incident.

Pattern names stay in English

Like CWE identifiers or ATT&CK technique names, an entry’s title is a taxonomy identifier, not a sentence to translate — it stays identical in French and English. The content itself is written in both languages.

Who publishes this

Secur01, a managed security services provider. The patterns come from incident response practice, generalized to the point of no longer being traceable to anyone.