Upload
trantram
View
224
Download
0
Embed Size (px)
Citation preview
Ransomware: Expérience vécue
à la Commission scolaire des
Appalaches
Présentation pour les participants au G.G.T. de la GRICS
16 février 2017
Contenu de la présentation
Introduction
Quelques statistiques générales
Historique de notre cas
Aspect technique du ransomware et dommages
Précautions et recommandations
Remerciements et conclusion
Introduction
La CS des Appalaches est centralisée à Thetford
Mines
24 établissements et 1 centre administratif
Environ 5000 élèves et 900 employés
Équipe TI composée de 7 personnes
Environ 3000 ordinateurs
Quelques statistiques
99,5% des logiciels ransomware sont indétectables
par les antivirus.
Source: Colloque RISQ 2016, La cybersécurité : une responsabilité collective
Quelques statistiques
92% des attaques de type ransomware sont issues de
l’ouverture d’un courriel malveillant ou de la
consultation d’un site web impropre (proposition
non-sollicitée de téléchargement ou d’installation)
Source: Colloque RISQ 2016, La cybersécurité : une responsabilité collective
Quelques statistiques
On répertorie environ 70 000 attaques de type
ransomware quotidiennement dans le monde.
C’est pratiquement 1 attaque par seconde…
Source: Colloque RISQ 2016, La cybersécurité : une responsabilité collective
Quelques statistiques
De ce nombre, environ 3,8% conduisent au paiement
d’une rançon.
Source: Colloque RISQ 2016, La cybersécurité : une responsabilité collective
Quelques statistiques
Ce qui génère des revenus d’environ 1 000 000$ par jour pour les cybercriminels.
Source: Colloque RISQ 2016, La cybersécurité : une responsabilité collective
Historique de notre cas
1- L’étendue des dommages
18/50 de nos serveurs sont totalement encryptés
dont les DNS, DFS, DC, BDsql, FS, Web etc.
95% des données des BD sont encryptées
Les BK Veeam effacés à 100%
Les BK Tivoli sont morcelés et incomplets
Des centaines (?) de postes sont atteints
Historique de notre cas
2- La Résolution
2.1- Cellule d’urgence
STIC
CERT/AQ
MEES
SQ
Firme externe
Direction générale
GRICS
Historique de notre cas
2- La Résolution
2.2- Sécurisation et stabilisation
Distribution des rôles
Communications externes: DG
Communications internes: Coord. STIC et ligne urgence
Liens autres CS: CSDN
Serveurs: 2 techniciens et firme externe
Décentralisés: 2 techniciens et 1 opératrice
Réseautique: 2 techniciens et firme externe
Notre système en entier est considéré comme une pièce à
conviction: libération mardi 6 septembre 11h00
Historique de notre cas
2- La Résolution
2.3- Priorisation-Aspect financier interne: payer les
employés
-Aspect financier externe: payer les
fournisseurs
-Aspect financier externe: taxes
scolaires
-Serveurs centraux: DC, DNS,
BDsql, DFS
-Serveurs applicatifs et de
stockage/partage: FS
-Postes décentralisés
Historique de notre cas
2- La Résolution
2.4- Gestion des communicationsExternes et média
DG en partenariat avec MEES et SQ
Coord. STIC avec CERT/AQ
Internes
Coord. STIC (2 rencontres STIC par jour)
Via poste Assistance TI
Via courriel et chaîne téléphonique
Table régionale CR-TIC 03-12
Lien avec la CSDN
Historique de notre cas
2- La Résolution
2.5- Opérabilité et contexte
Implantation d’urgence de stations de nettoyage et
d’impression
- hors réseaux
- affichage papier voyant
- tous les établissements et tous les services
Parce qu’une telle situation multiplie les clés USB et le
partage de ces dernières
Historique de notre cas
2- La Résolution
2.6- Réseautique
Directive sans équivoque basée sur le principe de
précaution.
Reconstruction de la réseautique complète: routage,
VLAN, DMZ
Historique de notre cas
2- La Résolution
2.7- Serveurs centraux ∆T = 2 semaines
Remonter tous les serveurs centraux et liens AD
Tenir compte de la nouvelle réseautique et du
principe de précaution
Assurer que le travail accompli est en sécurité
Historique de notre cas
2- La Résolution
2.8- Serveurs de fichiers ∆T = ±3 semaines
Remonter les serveurs de BD
Nombreux décalages entre les dates des
données récupérables (dommages amplifiés)
Remonter les serveurs d’application
Entrée en scène de la GRICS avec des protocoles
sur mesure pour relèvement des applications
Remonter les serveurs de stockage et de partage
Resserrement des droits AD
Nouvelle réseautique
Historique de notre cas
2- La Résolution
2.9- Assainissement décentralisé ∆T = 8 semaines en parallèle pour compléter
Dualité nettoyage/remplacement
Plan quinquennal devancé
650 remplacements et 2350 nettoyages
Assurer l’impression par photocopieur
Rétablir la réseautique par étape
Augmentation des effectifs: MEES
Saveur vanille
Historique de notre cas
2- La Résolution
2.10- Personnalisation ∆T = ±12 semaines
Reconduction de l’état de situation antérieur des
logiciels en fonction d’une BD d’inventaire saine
Rétablissement de toutes les imprimantes selon un
principe de « bon parent »
Maximisation des interventions sur place
publication d’un calendrier de visite
plusieurs intervenants en simultané
Historique de notre cas
2- La Résolution
2.11- Atterrissage ∆T = 16 semaines, Joyeuses Fêtes
Retour aux pratiques de service usuelles
- Poste d’assistance TI
- Requêtes de services normales
Aspect technique
1-Voix d’entrées
Impossibilité de déterminer formellement
autodestruction des traces
journalisation incomplète
Spectre de possibilités limité
courriel avec pièce jointe
téléchargement sur site web
exploitation d’une faille JBoss
Aspect technique
2- Nature du ransomware
Il s’agit d’une variante moderne du ransomware
SamSam (Samas)
Attaque le 4 septembre VS premières
mentions vers le 29 août
Chiffrement avec une clé 2048 bits
Effacement des « shadows » et BK
Présence de mimikatz
Aspect technique
2- Fonctionnement
1- Une faille est exploitée (spectre limité) afin de
pouvoir exécuter du code à distance dans le réseau
Aspect technique
2- Fonctionnement
2- La faille est ensuite exploitée afin d’installer une
série d’outils, dont le balayage réseau afin de
compromettre de réels accès réseau
Aspect technique
2- Fonctionnement
3- L’outil de balayage réseau (notamment mimikatz)
est ensuite déployé afin de voler des données
d’authentification. Au besoin, le processus se répète
afin d’étendre les dommages.
Aspect technique
2- Fonctionnement
4- Une fois l’authentification « domain admin »
obtenue, l’outil de chiffrement est déployé
massivement.
Aspect technique
3- Dommages amplifiés à la CSA
Existence d’authentifications « domain admin » avec
sécurité faible
Existence d’usagers possédant des droits
administratifs sur leur poste
Cloisonnement (DMZ et réseautique) trop faible
BK Veeam sur la même DMZ que les serveurs
BK Tivoli incomplets
Certains IPS inactifs sur le parefeu
Précautions et recommandations
1- Des BK irréprochables
Veeam derrière un parefeu dédié avec clé manuelle,
isolement réseautique complet
Tivoli avec suivi journalier écrit
Spécifications détaillées dans les définitions de tâches
Effectuer des tests de relève
Précautions et recommandations
2- Un AD suivi et rigoureux
Minimiser (éliminer) l’existence de codes génériques
Minimiser (éliminer) les droits d’administration
locaux des postes
Augmenter la complexité des authentifications,
forcer le changement fréquent
Assurer une journalisation exemplaire des accès
pour le retraçage
Précautions et recommandations
3- Éduquer les personnes
La sécurité de l’information dépasse les limites
atteignables par une service informatique.
Le risque 0 n’existe pas, l’équilibre dans la dualité
risque/opérabilité doit être déterminé, publié,
expliqué et assumé.
La connaissance et l’engagement de tous sont
nécessaires.
Précautions et recommandations
4- Assurer une veille
Sur l’évolution des menaces pour ajuster les
équipements et les pratiques
Sur l’évolution des équipements
Sur le travail du personnel en TI