Vous venez de recevoir un rapport de votre hébergeur ou d’un tiers indiquant que votre site héberge du contenu de phishing ? Bien que votre premier réflexe puisse être de supprimer les fichiers, de changer les mots de passe et de tout mettre à jour le plus rapidement possible, ce serait une grosse erreur. En prenant quelques minutes pour recueillir des informations, vous obtiendrez un meilleur résultat.
Dans cet article, nous discuterons de ce qu’il faut faire si votre site web a été infecté par un contenu de phishing et comment trouver les vulnérabilités et nettoyer votre site. Selon le type d’hébergement que vous avez choisi, votre fournisseur peut être en mesure de vous aider. Quoi qu’il en soit, je vous recommande de consulter un professionnel qui a déjà traité ce genre de question.
Étape 1 – Trouvez la source de l’infection
Il est primordial de trouver la source de l’infection. Ne faites aucun changement avant de mener une enquête complète, car cela réduit vos chances de trouver la source. Les hackers sont très bons pour couvrir leurs traces. De plus, la vulnérabilité d’origine n’est généralement exploitée qu’une seule fois pour télécharger son propre malware. La plupart des indices n’indiqueront pas l’attaque initiale, à moins que les pirates n’aient été négligents. Donc, vous avez besoin de tous les indices disponibles.
Outre le fait de rechercher les vulnérabilités du site, vous devez trouver tout le contenu de phishing téléchargé. Il y en a probablement plus d’un. Les sites de phishing sont particulièrement difficiles à trouver puisqu’ils sont conçus pour ne pas perturber votre site. Leur contenu semble être normal pour les scanners, ce qui rend la détection automatisée inefficace.
Comment l’infection par le contenu de phishing se produit-elle ?
Avant d’entrer dans les détails, il importe de comprendre comment et pourquoi les sites sont infectés par un contenu de phishing. Souvent, les pirates utilisent des ordinateurs compromis pour héberger des contenus et actions malveillantes, y compris le vol d’identité, la fraude financière, ainsi que la collecte de données sensibles auprès des victimes pour une utilisation illégale future. D’autres pirates le font dans le but d’obtenir un contrôle administratif sur les sites web légitimes des entreprises et organisations afin de pouvoir dissimuler leurs activités de phishing.
Le but d’un site de phishing est d’accéder aux informations d’identification d’un utilisateur. Les cibles les plus communes sont les banques et les grandes entreprises comme Apple, Ebay, Google, Paypal et Microsoft. Mais en réalité, toute organisation ou entreprise de toute taille peut être une cible. Les entreprises ont leurs propres équipes de sécurité dédiées et elles reçoivent également de l’aide de la part des agences gouvernementales et de sociétés de sécurité privées. Par conséquent, les sites de phishing sont normalement découverts et éliminés assez rapidement.
Cela oblige les pirates informatiques à utiliser rapidement des outils automatisés pour gérer le réseau de sites et de serveurs de messagerie qu’ils ont piratés. Par conséquent, tout obstacle que mettez en place pourrait réduire les chances que les pirates informatiques ciblent votre site. Il est beaucoup plus efficace pour eux de passer au prochain site non sécurisé.
Les raisons les plus courantes qui amènent les cybercriminels à attaquer un site ou un serveur sont les mises à jour non appliquées, les sites mal sécurisés pendant leur conception, les mots de passe faibles et les scripts personnalisés non sécurisés. Pour en savoir plus, vous pouvez lire notre récent article sur la nécessité de mettre à jour vos applications et d’utiliser des mots de passe forts.
Lors de sa conception, votre site est-il sécurisé ?
Il y a une chose que même les administrateurs expérimentés négligent parfois : la sécurité de leur site lors de sa conception. Si des pirates parviennent à accéder à votre compte via une vulnérabilité sur votre site pendant cette phase, ils auront également accès à votre site habituel. Par ailleurs, il est fortement recommandé de supprimer tout site en phase de conception ou d’essai une fois les travaux terminés.
Enquêtez sur la sécurité des réseaux
Lors d’une enquête de sécurité, prenez des notes détaillées sur ce que vous découvrirez au fur et à mesure de votre progression. Tâchez de ne pas enlever ni de modifier aucun détail. Notez le chemin complet vers tous les sites de phishing que vous trouverez, ainsi que les fichiers malveillants, les injections de code et les scripts contenant du code non sécurisé. Gardez également trace de leurs horodatages et de toutes les entrées de journal connexes. Ensuite, vous pouvez utiliser ces informations pour déterminer la meilleure marche à suivre et pour supprimer les éléments malveillants.
Souvent, vous recevez un rapport sur des dossiers spécifiques. Mais parfois, l’information dont vous disposez est limitée. Plusieurs experts en matière de sécurité informatique à qui j’ai parlé aiment utiliser Sucuri Sitecheck pour vérifier s’il y a des problèmes connus.
https://sitecheck.sucuri.net/
Pour cet exemple, nous avons un rapport d’un lien de phishing pointant sur notre site WordPress qui s’exécute sur un serveur cPanel.
http://www.example.com/Apple/securelogin.html
C’est un exemple de base des tactiques les plus courantes utilisées par les pirates informatiques. Il y a beaucoup de variantes et, franchement, même les professionnels sont parfois perplexes. En réalité, les pirates informatiques sont intelligents et changent constamment de tactique.
Cela dit, la plupart des professionnels de la sécurité abordent une enquête de phishing sans jamais avoir vu le site et sans connaître le codage personnalisé. La procédure décrite ci-dessous peut sembler fastidieuse, mais avec un peu de pratique, vous pouvez faire une recherche complète et nettoyer un site web de taille standard en 10 à 15 minutes. C’est valable pour un serveur web Apache Linux/Unix.
Tout d’abord, examinez l’horodatage des dossiers infectés
Pour commencer, vous devez examiner les horodatages des fichiers concernés. Vous n’avez pas modifié ou supprimé les fichiers, n’est-ce pas ? Si oui, ne vous inquiétez pas. Vous trouverez probablement d’autres fichiers malveillants plus tard lors de votre enquête.
Pour voir l’horodatage complet, vous devez utiliser la commande « stat ». Utilisez-le sur le fichier que vous connaissez déjà.
# cd /home/user/public_html/Apple
# stat securelogin.html
File: `securelogin.html’
Size: 37062 Blocks: 80 IO Block: 4096 regular file
Device: 807h/2055d Inode: 101845956 Links: 1
Access: (0644/-rw-r–r–) Uid: ( 500/ user) Gid: ( 500/ user)
Access: 2015-04-15 09:11:12.000000000 -0400
Modify: 2015-04-10 15:35:11.000000000 -0400
Change: 2015-04-12 10:15:27.000000000 -0400
Si vous regardez de près les informations ci-dessus, vous pouvez voir que les dates de modification sont différentes. « Modify » fait référence au contenu du fichier, tandis que « Change » fait référence aux métadonnées (nom de fichier, autorisations, etc.). La date de modification est généralement la plus importante, mais les deux peuvent être nécessaires pendant l’enquête.
Étape 2 – Comparez aux journaux
Maintenant que vous avez le temps de connaître le moment où certains des changements ont eu lieu, vous pouvez les comparer aux journaux. Les journaux d’accès Apache sont le meilleur endroit pour commencer. Si rien ne se trouve dans Apache, vous trouverez probablement un téléchargement dans les journaux FTP ou cPanel. Puisque les journaux Apache sont l’endroit le plus courant pour trouver les informations dont vous avez besoin, nous allons nous concentrer sur ce sujet.
La plupart du temps, vous devez voir les commandes POST afin de filtrer les journaux pour le POST ainsi que la date et l’heure.
# grep POST /usr/local/apache/domlogs/user/example.com|grep ‘10/Apr/2015:15’|less
Les horodatages ne correspondent pas exactement. Apache enregistre le temps d’accès au début de la transaction, tandis que le système de fichiers enregistre la date de la dernière écriture dans le fichier. Gardez cela à l’esprit lorsque vous consultez les journaux.
Base de données ARIN et GeoIP
Dans ce cas, vous trouverez plusieurs centaines d’entrées comme celle ci-dessous. Veuillez noter qu’il ne s’agit que d’un exemple et que l’adresse IP n’est donc pas valide.
50.123.234.345 – – [10/Apr/2015:15:35:03 -0400] « POST /wp-content/uploads/2013/06/xXx.php HTTP/1.0 » 200 42726 « – » « Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) »
Il y a plusieurs signes évidents d’activités malveillantes dans cet enregistrement. Pourquoi y a-t-il un fichier PHP dans le répertoire de téléchargement ? Cette zone est normalement réservée aux images et aux documents. Il ne devrait pas être là. Il utilise également HTTP 1.0 et ne fournit pas de lien référer qui sont des signes d’une requête chiffrée. Et la requête est identifiée comme Googlebot, mais si vous vérifiez l’adresse IP dans la base de données ARIN ou l’outil GeoIP, vous verrez qu’elle n’appartient pas à Google.
Tactiques courantes de piratage informatique
Maintenant que vous avez un tracé à suivre, examinez le fichier « xXx.php ».
Exemple :
# cd wp-content/uploads/2013/06
# stat xXx.php
stat: cannot stat ‘xXx.php’: No such file or directory
Comment est-ce possible ? Le fichier a été déplacé ou supprimé par l’attaquant pour vous écarter de la piste. C’est une tactique courante, mais elle ne vous ralentira pas trop. Le fichier devrait être retrouvé plus tard s’il a été déplacé. Pour l’instant, vous pouvez passer à l’indice suivant : l’heure du changement. Examinez à nouveau les journaux à la recherche de l’heure de changement que vous avez vue plus tôt. Il devrait maintenant y avoir un lien vers un fichier différent utilisant une nouvelle adresse IP et un nouvel agent utilisateur.
60.123.234.345 – – [12/Apr/2015:10:15:18 -0400] « POST /wp-content/themes/twentythirteen/js.php HTTP/1.1 » 200 42726 « http://www.example.com/index.php » « Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 »
Cette requête ne semble pas être chiffrée comme la précédente. Cependant, elle POSTE un fichier dans le thème suivant, ce qui est inhabituel. Examinez le contenu du dossier pour voir si vous pouvez découvrir ce qu’elle faisait.
# cd wp-content/themes/twentythirteen
# less js.php
<?php
eval(« \x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28’TZNJr6NWEIX/S2860V0wXEZFWTCbeR6M3gYwYGPAYDDTrw+d11KyODqqc75alapcsvaPH18bRX5tNHU6dkr42nDmdPrMuNPZU9Ip6rv7xdDE986/HP47g98ZPDl49qR8zr856lf3vxlnfm6Rob2HOZOcPck1tTfwo6spdVI44uguvQ9jzgSqaF21ZaNQa1dpHJbONPlj/BmHNIMRZuIVzFsCyENDxPeZSPFdZgyxuXa3J5Z3N5xnN76CI2LWB4lXJn1HEO8hAQu/OBLdOn6yIBqaAwZhXQLY4/wE8dwYWfq2QXrkAgiVKgaVGm8+53atgmSTvC4PoURROxF2lpEfkZDfsrHTOvHYLkwMwTV/7L1YAeEGFnwUaIvYA0GstHc+C2WbfIqhLRjsWsfC5Jq3pkSKjr1pQfjWFsVSJJ9tX5FPJL5IwqtYvEI8ZCM6mqQqQQoNT1iekREAIppZoijdMyOa7VRleP1YKZn2L9haEKreXTZ3sQMFa+30RvrZeA+tkVP1T+Vdvf4as9hcxnUZXz8NdeRGUDZBNBmp45VK68U72rgm9Louj9bFT97evDbsojCk+5Y+x1QYtUZO7KBA/QLQ3gwJQq67fCD2Hd4+Of/JfacNFcCMScHyg1/kMdTFNjtE/kgSzS5bKZhyJWUEG9tn3PpAbmX1V2uPOd95ZV019QIt28v8stORIBEo4zVFo6XbzaPzouZpT1mG91DDdEMaXiU34Ol5HZIb7+4qGmsUlyYpW+gteoCUn6j0rvvCe3KsOm7MF/dBLhvvw4lXewJRXTXciwO74VvqN2I6L0KPt2jwGssgryOHjkMXTy1feRziWFxhgQxvl82JSTwYh1gNVVb2YPbK19sseHFc/TBx3LJTd9R7yW61N4lKTjxyeduKFIHYhnwriUgtYbu8yfyDR/owt4L65WIUhJ6zZg3Kbo8YoxpeMBwe9vFdpZ+iOQhTwDFkDaEebJiDkR8ZkfBcfAY6VrJiPzaMqTsCH3nSs8mDlOIIiGZWP0MvYWSgKQ5gcrCAzfz75/l97H+C/I8///oH’\x29\x29\x29\x3B »);?>
Code PHP obfusqué
C’est du code PHP obfusqué qui ne signifie pas nécessairement qu’il est malveillant. Il y a de bonnes raisons de le faire et cela pourrait vraiment faire partie du thème. Vous pouvez utiliser UnPHP.net pour le décoder. Bien que ce service ne le décode pas toujours complètement, il vous donnera généralement suffisamment d’informations pour déterminer s’il est malveillant ou dangereux.
Si vous parvenez à décoder le script, vous constaterez qu’il s’agit d’un script standard pour télécharger des images (pour ce cas précis, je ne voulais pas inclure de vrai code malveillant). De toute façon, ce fichier a été utilisé par l’attaquant. Ajoutez-le à votre liste et continuez à suivre le tracé en faisant correspondre les horodatages des fichiers aux entrées du journal.
Quand arrêter l’enquête ?
Si vous suivez ce même processus sur le fichier « js.php », vous constaterez peut-être qu’il mène à un autre fichier à tracer ; qu’il indique une vulnérabilité dans notre application ou notre thème ; ou même qu’il pourrait pointer vers lui-même. Mais supposons que dans ce cas, vous n’avez rien trouvé de suspect dans les registres.
C’est bien, mais parfois ce n’est pas si évident. Filtrez les logs de manière un peu différente cette fois-ci pour voir tous les POST de cette IP.
# grep POST /usr/local/apache/domlogs/user/example.com|grep 60.123.234.345|less
Vous devrez peut-être filtrer davantage les résultats pour trouver les informations importantes. Supposons que vous trouvez le script suivant :
60.123.234.345 – – [21/Apr/2015:10:52:21 -0500] « POST /wp-login.php HTTP/1.1 » 200 1937 « http://www.example.com/wp-login.php » « Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 »
60.123.234.345 – – [21/Apr/2015:10:53:03 -0500] « POST /wp-admin/theme-editor.php HTTP/1.1 » 200 17862 « http://www.example.com/wp-admin/theme-editor.php » « Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 »
Cela indique soit un mot de passe compromis, soit une vulnérabilité dans WordPress. Vous pouvez consulter les journaux plus en détail pour savoir de quel type il s’agit. Pour gagner du temps, à ce stade, je vous recommande d’appliquer les mises à jour si elles sont disponibles et de réinitialiser tous les mots de passe administrateur.
Cependant, vous ne devriez pas arrêter l’enquête à ce stade. Qu’il s’agisse du compromis initial ou non, il y aura probablement plus de fichiers malveillants que ce que nous savons. Bien souvent, il y a même plusieurs compromis distincts à l’avenir.
Continuez la recherche sur les fichiers et répertoires récemment modifiés
Maintenant que vous avez épuisé la liste des fichiers malveillants connus, vous devez faire preuve de créativité pour trouver les autres éléments. J’espère que vous n’avez pas encore modifié de fichiers, sinon les résultats de ces tests peuvent être faussés.
Pour cette partie de l’enquête, vous devez commencer dans le répertoire racine du document du compte de l’utilisateur affecté. Examinez la structure des répertoires et les fichiers les plus récemment modifiés à l’aide de la commande suivante :
# ls -lrt
Vous pouvez voir tout de suite des annuaires avec le nom de compagnies ou des répertoires qui ne suivent pas vos conventions de nommage. Cherchez également les fichiers dont les horodatages ne sont pas synchronisés avec les fichiers environnants. Vous devrez examiner le contenu et les entrées pertinentes du journal afin de détecter tout objet suspect que vous avez trouvé, comme vous l’avez fait précédemment.
Pour trouver la majeure partie du contenu du phishing, il est préférable d’examiner chaque répertoire à 2 ou 3 niveaux de profondeur à partir du répertoire racine du document. Dans chaque répertoire, examinez la structure du répertoire et le contenu des fichiers qui n’apparaissent pas à leur place. S’ils semblent malveillants, comparez-les aux journaux et, bien entendu, documentez tout.
Enfin, revenez au répertoire racine du document et effectuez quelques recherches ciblées. Commencez par rechercher tous les fichiers qui ont été modifiés au cours de la dernière semaine. Il se peut que vous ayez besoin d’augmenter les recherches sur les 30 ou 90 jours auparavant. Si la liste est trop longue, réduisez-la avec grep. Vous pouvez même filtrer les fichiers que vous connaissez déjà.
# find . -type f -mtime -7 | less
# find . -type f -mtime -7 | egrep -v ‘cache|log|Apple’ | less
Il est parfois utile de vérifier les fichiers contenant des changements récents. Dans la plupart des cas, les résultats ne seront pas très différents, mais il pourrait y avoir des résultats clés.
# find . -type f -ctime -7 | less
Les liens symboliques sont couramment utilisés pour tenter de sortir du compte d’un utilisateur. Passez en revue tous les éléments que vous trouverez à l’aide de la commande suivante (la plupart des sites Web n’utilisent pas de liens symboliques du tout et il est presque toujours sûrs de les supprimer.
# find -type l
Vous avez presque terminé, mais faites une autre recherche pour vous assurer que vous avez tout trouvé. Voici une commande souvent utilisée pour détecter l’obscurcissement du code. Ceci est commun avec les codes malveillants :
# egrep -l ‘eval|gzinflate|base64_decode|str_replace|str_rot13’ *
Bien entendu, cela détectera également de nombreux éléments qui sont des parties valides de votre site. Vérifier chaque fichier avec le codage et l’accès aux fichiers journaux pour s’assurer qu’ils sont non seulement valides, mais aussi sûrs et protégés.
Nettoyer le désordre causé par le phishing
Maintenant que vous avez une liste de fichiers malveillants et que vous avez identifié les vulnérabilités de vos sites, vous devez vous sortir de cette situation. Faites une sauvegarde avant de continuer. S’il s’agit d’un grand site, j’aurais commencé la sauvegarde au moment de mon enquête. Oui, même une sauvegarde du site compromis pourrait être utile. Un bon administrateur n’est jamais trop prudent !
Après la sauvegarde, supprimez complètement tous les fichiers malveillants et réinitialisez tous les mots de passe qui ont pu être compromis. Souvent, les fichiers de code injectés devront être nettoyés manuellement. Ouvrez ces fichiers dans un éditeur de votre choix et supprimez les injections de code. Les injections de code malveillant se trouvent généralement sur la première ou la dernière ligne d’un fichier (mais pas toujours).
Un bon administrateur système n’est jamais trop prudent !
Si vous avez identifié des modèles avec les requêtes malveillantes dans les logs, vous pouvez les bloquer avec des règles .htaccess. Par exemple, si toutes les demandes provenaient du même sous-réseau ou même du même pays, vous pourriez les bloquer temporairement jusqu’à ce que vous ayez entièrement sécurisé votre site. Voici une excellente référence pour le codage htaccess.
http://perishablepress.com/stupid-htaccess-tricks/
Vous pouvez maintenant mettre à jour toutes les applications sur votre site et réparer tous les scripts non sécurisés que vous avez trouvés dans l’enquête. Lors de la mise à jour de votre logiciel, assurez-vous de vérifier d’autres éléments comme Timthumb et TinyMCE, car elles sont souvent négligées. Si vous utilisez un CMS comme WordPress, la mise à jour des éléments suivants est généralement suffisante pour résoudre les problèmes :
- Le noyau WordPress
- Tous les plug-ins
- Et les thèmes
Mais si vous avez un site sur mesure, il est probable que vous avez trouvé un formulaire de téléchargement non sécurisé pendant l’enquête. Vous devrez ajouter une validation au script pour éviter qu’il ne soit mal utilisé. La méthode la plus simple est d’ajouter un mot de passe dans votre script pour que vous seul puissiez l’utiliser.
Retrait de la cote
Vous avez trouvé les vulnérabilités de vos applications. Alors vous, pouvez :
- Supprimer les fichiers malveillants
- Réinitialiser les mots de passe
- Mettre à jour votre site.
Votre site est maintenant propre, sûr et n’héberge plus de contenu malveillant. Cependant, vos utilisateurs voient toujours un avertissement de sécurité sur leur navigateur ou via leur antivirus. Heureusement, il est beaucoup plus facile de se faire radier de ces listes que de se faire radier d’une liste noire de spam.
Le moyen le plus commun d’obtenir des rapports surs est d’utiliser Google Safe Browsing. Vous pouvez utiliser le lien suivant pour demander une radiation. Google explorera à nouveau votre site et vérifiera s’il y a des problèmes. Si vous n’en trouvez aucun, vous devriez être retiré de la liste bientôt.
https://www.google.com/safebrowsing/report_error/
Les erreurs les plus courantes qui causent des problèmes de sécurité sont les mêmes partout. Mises à jour non appliquées, sites de développement négligés, mots de passe ou comptes de test faibles et scripts personnalisés peu sûrs.
Je suis sûr que vous avez trouvé au moins un de ces problèmes au cours de ce processus. Ne t’inquiète pas, ça arrive.
Comment minimiser la vulnérabilité de votre site Web ?
Comment minimiser la vulnérabilité de votre site Web aux attaques de hameçonneurs ?
- Durcissement du système d’exploitation du serveur. Le « durcissement » est un processus de sécurisation d’un système d’exploitation de sorte qu’il puisse être difficile à attaquer. Utilisez des scanners de vulnérabilité commerciaux et open source et des outils d’analyse de base de sécurité pour identifier les vulnérabilités.
- Durcissement des applications Web. Il s’agit d’un processus de sécurisation des logiciels d’application de serveur Web, des applications web et des scripts, ainsi que du contenu dynamique contre les attaques. Encore une fois, utilisez des scanners de vulnérabilité web commerciaux et open sources pour identifier les paramètres de configuration incorrects et le contenu exploitable. Envisagez d’utiliser un pare-feu d’application web commercial ou open source et une technologie de filtrage de contenus pour fournir un examen en ligne et en temps réel du trafic Web entrant afin de détecter les modèles d’attaque et les anomalies.
- Gestion des correctifs. Maintenez les niveaux de correctifs actuels sur tous les systèmes d’exploitation et applications utilisés pour votre site Web.
- Programmation sécurisée, scripts sécurisés. N’utilisez pas de programmes exécutables sans vérifier l’authenticité et la fiabilité du développeur et l’intégrité du code lui-même. L’Open Web Application Security Project (OWASP) est une source utile pour apprendre à programmer et à écrire des scripts en toute sécurité.
- Compartimentation. Créez des domaines de sécurité au sein de votre réseau et séparez-les par des systèmes de sécurité (par exemple, des pare-feu) afin de limiter les attaques réussies contre un serveur ou un service.
- Examen de routine. Effectuez régulièrement des tests de vulnérabilité et de pénétration du réseau, de l’hôte et du web. Si possible, demandez à une partie indépendante, expérimentée et certifiée, d’effectuer une évaluation de la sécurité des systèmes qui prennent en charge votre site web.
- Mise en œuvre des meilleures pratiques en matière de filtrage de pare-feu. Limitez la circulation aux pare-feux aussi étroitement que possible.
- N’autorisez l’accès qu’aux ports TCP ou UDP où vos services autorisés le permettent. Limitez davantage les flux aux adresses IP des systèmes sur lesquels vous hébergez les services d’écoute. Limitez également les flux de trafic sortant des serveurs.
Maintenant que tout va bien avec votre site, gardez ces choses à l’esprit. Connectez-vous régulièrement à votre site pour vérifier les mises à jour. Utilisez des mots de passe forts et supprimez tous les comptes de test et sites en cours de développement. Si vous avez des scripts personnalisés, assurez-vous d’ajouter une validation à votre code pour éviter les abus. Tout cela contribuera à rendre la vie d’un hameçonneur difficile. Rappelez-vous toujours qu’un bon administrateur système n’est jamais trop prudent !
La première ligne de défense d’une entreprise est l’administrateur système, le héros infatigable qui travaillent 24 heures sur 24, 7 jours sur 7 et 365 jours par an pour vous assurer que l’infrastructure informatique soit toujours sécurisée. Nous avons dressé une liste de ressources qui vous seront utiles si jamais vous êtes victime d’un incident ou d’une brèche de sécurité.