Ville du Parc - SISR, May 2023 session

Mission A1 - Identifying personal and sensitive data

The town council, as the data controller, must notably comply with:

• Purpose & lawfulness: collect for specified, explicit, and legitimate purposes (civil registry, appointments), with a lawful basis (public service mission).
• Minimisation: collect only data that is strictly necessary.
• Information & rights: inform users (purpose, retention period) and guarantee their rights (access, rectification, erasure); obtain consent where required.
• Security & retention: ensure confidentiality and integrity (encryption, restricted access), limit retention periods, appoint a DPO, and maintain a record of processing activities.

In the event of a data breach: notify the CNIL within 72 h and inform individuals if the risk is high.

• For the council: damage to reputation and public trust; legal and financial penalties (penalties from the CNIL, with the GDPR leaving each Member State to determine whether a municipality can be fined (art. 83.7), liability of the mayor, remediation costs).
• For users: identity theft (fake ID documents, opening accounts in the victim's name); fraud / scams (data resale, unsolicited contact, blackmail), and invasion of privacy.

Mission A2 - Assessing digital risks

1. Redundant infrastructure: 2 server rooms and 2 network cores across 2 geographical sites (BCP).
2. ESX hypervisor cluster (6 physical servers) with automatic failover in the event of a host failure.
3. RAID 50 SAN arrays (2 × 200 TB) replicated via fibre between the two datacentres.
4. RSTP enabled on all switches → loop-free redundant topology.
5. Veeam backups, encrypted, with integrity hash, stored offline across 2 sites, restores tested regularly.
6. Secure premises: UPS-backed mains power, dual air conditioning, badge + biometric access control.

a) CIA consequences of ransomware on the servers

Criterion	Consequence
Availability	Very severe impact: encrypted files make servers and services unavailable (civil registry, line-of-business applications), paralysing the town hall.
Integrity	Major impact: data is encrypted/modified, making it unusable without the decryption key.
Confidentiality	Limited impact here: the chosen EBIOS scenario (cyberterrorist 'disrupt the IS with a ransom demand') does not exfiltrate data; Ryuk itself does not perform exfiltration.

b) Severity, likelihood and risk scenario

According to the EBIOS RM workshops: severity = 4/4 (dreaded event 'loss/destruction of data', critical impacts) and likelihood = 4/4 (operational scenario 'phishing → ransomware' deemed very likely). In the matrix (severity 4, likelihood 4), this is scenario R2, located in the maximum risk zone (to be treated as a priority).

c) Measures already taken to mitigate this risk (workshop 5)

• Phishing awareness (status Completed) - cuts off the initial vector.
• Enhanced monitoring of inbound/outbound traffic (IOC) - In progress.
• Encrypted and offline backups (Veeam) - allow restoration without paying.
• Event log analysis and IS security audit - in progress / to be launched.

Solution	Severity	Likelihood	Justification
Sandbox	unchanged	reduced	The unverified program runs in an isolated, ephemeral environment: if it is ransomware, it does not reach the host system and is destroyed on closing → the infection is less likely to succeed. The severity of an 'actual' infection remains the same if it occurs regardless.
Application Guard	unchanged	reduced	Untrusted sites/files open in an isolated container separate from the OS → the entry vector (attachment / malicious site) is compartmentalised, reducing the probability of malicious code executing on the workstation.

Both solutions act on likelihood (probability of the attack succeeding), not on severity (impact if it succeeds anyway, e.g. via a privileged account).

Mission B1 - Improve the password policy

a) Impacts of a very short expiry (less than 1 month) vs long / unlimited, depending on account type:

• User accounts (low sensitivity): an expiry period that is too short is counterproductive (ANSSI recommendation R24) - users choose weak, predictable or reused passwords (incrementing a digit) and write them down. Having no expiry limit + a strong password is preferable.
• Privileged accounts (highly sensitive): maintaining an expiry period remains relevant (recommendation R25) because compromising such an account is critical; an unlimited period leaves a secret valid indefinitely in the event of a leak.

b) Recommended expiry period for privileged accounts: between 1 and 3 years (R25), with immediate expiry upon suspected compromise.

Three changes: change the group, test PasswordLastSet (password modification) instead of LastLogonDate, and set the limit to -365 days:

$groupe  = "Administrateurs de l'entreprise"          # au lieu de "Admins du domaine"
$membres = Get-ADGroupMember -Identity $groupe -Recursive

foreach ($un_membre in $membres) {
    $user         = Get-ADUser -Identity $un_membre.SamAccountName -Properties *
    $dateDerniere = $user.PasswordLastSet              # au lieu de LastLogonDate
    $limite       = (Get-Date).AddDays(-365)           # au lieu de -180
    if ($dateDerniere -lt $limite) {
        Write-Host "$($user.SamAccountName) - mot de passe inchangé depuis le $dateDerniere"
    }
}

Mission B2 - Enhance high availability for web services

HAProxy balances the load (Round-Robin) across multiple web servers: it absorbs traffic spikes without overloading a single server, ensures continuity during outages or maintenance, and provides security (DDoS and brute-force detection/blocking, intrusion logging). It eliminates the single point of failure (SPOF) on the web server side.

However, a single HAProxy would itself become a SPOF: if it fails, the entire portal becomes inaccessible. HAProxy is therefore duplicated (active/passive with virtual IP / VRRP) so a second load balancer can take over → end-to-end high availability.

A certificate issued by a recognised public CA is automatically validated by citizens' browsers (pre-installed chain of trust). It guarantees site authentication (genuine portal, not a spoofed site), encryption of communications (personal, banking data), and no security warnings for users. A self-signed certificate would trigger a warning and undermine trust - unacceptable for a public service open to the general public.

Strategy	Where to place the certificate	How far traffic is encrypted
A - TLS Termination	On the HAProxy servers (decryption takes place at the load balancer)	Encrypted from client to HAProxy; in plain text between HAProxy and web servers (internal VLAN 55). Allows HAProxy to inspect/route HTTP.
B - Pass-Through	On the web servers (HAProxy does not decrypt, it forwards)	Encrypted end-to-end, from client to web servers; HAProxy relays the TLS stream without inspecting it.

The web servers have migrated to VLAN 55 SERVEURS_WEB. HTTPS/HTTP traffic from the HAProxy instances (DMZ) to this VLAN must be opened. To be added to the table (stateful mode, implicit return):

No.	Action	Protocol	Source	Source port	Destination	Dest. port
11	Pass	TCP	HAProxy (DMZ 172.16.0.0/16)	any	VLAN55 SERVEURS_WEB	https (443)

(If TLS termination - strategy A -, the backend can use http (80): adjust the destination port accordingly.)

Mission B3 - Securing the library local network

a) Events observed in the Wireshark capture + probable cause

Thousands of identical frames: this is a burst of SYN packets to the server (10.15.0.253) without the final ACK of the 3-way handshake. This is a SYN flood attack, a denial of service (DoS): the server allocates a connection for each SYN received and exhausts its connection table. Possible cause: a malicious user physically connected to an RJ45 socket in the library.

b) Impact on library services

The overloaded server becomes slow or even unavailable: the loan management application and file sharing between employees no longer respond → service disruption at the counter, making it impossible to record loans/returns.

a) Actions to take on the switch to secure the 42 ports

1. Enable port-security on the 42 interfaces (fa0/1 to fa0/42), in access mode.
2. Automatically learn authorised MAC addresses with sticky (the 1st connected machine) → no manual collection of MAC addresses.
3. Limit to 1 MAC address per port (only one workstation per socket).
4. Define a violation action (shutdown or restrict).
5. Disable (shutdown) the 4 unused ports (B39-B42, i.e. fa0/39 to fa0/42).

b) CISCO commands

! Sécuriser les prises utilisées B01 à B38 (fa0/1 à fa0/38)
Switch(config)# interface range fa0/1 - 38
Switch(config-if)# switchport mode access
Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 1
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# switchport port-security violation shutdown

! Désactiver les 4 prises inutilisées B39 à B42 (fa0/39 à fa0/42)
Switch(config)# interface range fa0/39 - 42
Switch(config-if)# shutdown

Mission C1 - Analyse and investigate the incident

a) Probable root cause: a phishing email opened by a user in the civil registry department, who clicked on a malicious link. This link triggered the download of BazarLoader, the first stage of the Bazar → Ryuk infection chain.

b) Classification: confirmed security incident (not a false positive). Identified indicators of compromise:

• Outbound connection to IP 34.217.209.239 = BazarLoader C2 server (see document C3, port 443, GET /www/html/var/generic/doc).
• MAIRIE-SERV-EC-PC06 workstation logs: presence of C:\PerfLogs\P64.exe and C:\PerfLogs\comps1524.txt - directory, executable and files characteristic of Ryuk/UNC1878 (document C4).

The absence of a known Ryuk hash and registry key is expected: the attack is at the BazarLoader / pre-encryption stage (infection→encryption delay of 3 h to 5 days), which highlights the value of having disconnected the workstation in time.

c) Other potentially affected machines: Ryuk spreads laterally by scanning private ranges 10.0.0.0/8, 172.16.0.0/16 → 172.31.0.0/16 and 192.168.0.0/16 (ICMP ping then SMB share enumeration). To check: all servers/workstations reachable on these networks, especially file servers / shares, and any host that contacted 34.217.209.239 or the listed C2 servers. We search for the same IOCs (P64.exe, comps*.txt, C:\PerfLogs\) in the centralised logs (10.50.1.100).

• Eradication: keep the workstation isolated; remove malicious files (P64.exe, comps*.txt, registry key ...\Run\svchost and scheduled task), disable/reset potentially compromised accounts (especially the privileged account used for propagation), run an up-to-date antivirus/EDR.
• Recovery (safest option): reinstall the workstation from scratch (re-image) using a clean image, restore data from a clean backup (offline Veeam) prior to the infection, reset passwords for the affected accounts, then reconnect the workstation to the network under heightened monitoring (verifying absence of reinfection / C2 communication).

1. Email filtering: anti-spam/anti-phishing, attachment sandboxing, URL rewriting/analysis, blocking dangerous extensions.
2. Multi-factor authentication (MFA) on accounts (especially privileged ones): limits the impact of stolen credentials.
3. Surface reduction & detection: least privilege (no local admin), Application Guard / sandboxing, blocking known IOCs on firewalls/proxies, and regular phishing simulations to measure and maintain vigilance.