Casterman - SLAM, 2025 session

The method: for each story, assess the need for confidentiality, integrity, availability based on the impact of a breach on the data handled.

a) Confidentiality (story 1): high level if the story handles personal/strategic data (whose disclosure would cause harm); low if it involves public information (e.g. catalogue).

b) Integrity (story 3): high level if data alteration would distort business operations (e.g. rights, pricing, content of a book to be published).

c) Difference in proof (stories 2 vs 3): the need for traceability/evidence is stronger where it is necessary to prove who did what (sensitive, legally binding action) than for a routine operation.

1. Unavailability: encryption of data and servers → operations blocked (BDPro unusable).
2. Financial loss and data breach: cost of the ransom/recovery, and in the case of double extortion, data exfiltration followed by publication (damage to confidentiality and reputation).

1. Backups: regular, tested, offline/immutable (3-2-1 rule) - to restore without paying.
2. Updates: systematic (OS, applications) - closing exploited vulnerabilities.
3. Antivirus/EDR + email filtering (ransomware often arrives via phishing). (You can also add: network segmentation, MFA, awareness training.)

a) The CNIL must be notified (within 72 hours); and affected individuals must be informed if the breach poses a high risk to their rights and freedoms.

b) The breach must be recorded in the data breach register (maintained by the data controller).

a) Passwords stored in plaintext must be removed because, in the event of a database leak (theft, injection, compromised backup), all accounts are immediately usable by the attacker - including elsewhere (password reuse).

b) The appropriate solution is hashing, not encryption: a password must never be decryptable. A salted hash is stored (e.g. bcrypt/Argon2) and hashes are compared at login. Encryption is reversible (a stolen key exposes everything) -> unsuitable for passwords.

a) The table HistoMotDePasse remains empty because the trigger does not insert the old password: either the check on mdpExisteHisto is mishandled (the action is only executed in a branch that is never reached), or theINSERT INTO HistoMotDePasse statement is missing from the logic.

b) Correction: if mdpExisteHisto returns false, the trigger must (1) INSERT the old password into HistoMotDePasse, (2) count this user's entries, (3) delete the oldest if the total exceeds 5, (4) update mdpActuel/dateHeureMdpActuel in Utilisateur - in that order.

It guarantees integrity (the PDF has not been modified after signing) and authenticity/non-repudiation (it genuinely comes from the publisher). For the printer, it provides proof that they are printing the exact, approved version intended by Casterman.

An encrypted transfer suitable for large files: for example SFTP (SSH File Transfer Protocol) to a dedicated server, or an end-to-end encrypted transfer solution - not by email (file size limits and confidentiality not guaranteed).

It checks user permissions and returns true if the requested (table, operation) pair is authorised:

public boolean possedeDroit(String uneTable, String uneOperation) {
    for (Droit d : this.lesDroits) {
        if (d.getTable().equals(uneTable)
         && d.getOperation().equals(uneOperation)) {
            return true;
        }
    }
    return false;
}

SELECT COUNT(*) AS nb_delete
FROM Log
WHERE operation = 'delete'
  AND dateHeure >= NOW() - INTERVAL 30 MINUTE;

a) The provided query does not meet the requirement: it lists the idUtilisateur values, but does not count per user and applies no threshold ("more than 5 additions"). It is missing a GROUP BY and a HAVING.

b) Correction:

SELECT idUtilisateur, COUNT(*) AS nb_ajouts
FROM Log
WHERE nomTable = 'BandeDessinee'
  AND operation = 'insert'
  AND dateHeure >= CONCAT(CURRENT_DATE(), ' 08:00:00')
GROUP BY idUtilisateur
HAVING COUNT(*) > 5;

These are write methods: DELETE deletes a resource and PUT modifies/replaces it. If poorly controlled, they allow data alteration or destruction -> directly compromising database integrity.

Before executing the deletion, authorisation is checked via autoriseAction(). If the requester lacks permission, an HTTP 403 (Forbidden) status is returned without touching the database:

si NON autoriseAction(demandeur, ...) :
    réponse HTTP 403 (Forbidden)   // accès refusé
sinon :
    exécuter la suppression
    réponse HTTP 200/204

Creating a second dedicated API, public but read-only for the catalogue alone, applies the separation of privileges: public access does not expose write operations or sensitive data and does not share authentication with the business API. Conversely, modifying the existing API would have expanded and weakened it.

a) Two problems: (1) the email returns the username and a plaintext password -> direct leak if the inbox is compromised (meaning the password is known/stored in plaintext); (2) there is no proof that the requester is the account holder (no verification, no expiry).

b) Secure approach: send a single-use reset link containing a short-lived random token that leads to a form where the user sets a new password (never sent by email, and stored hashed).