C'est vraiment, vraiment, vraiment dur. Cela nécessite un audit très complet. Si vous êtes sûr que l'ancienne personne a laissé derrière elle quelque chose qui va faire boom, ou qu'elle doit être réembauchée parce qu'elle est la seule à pouvoir éteindre un incendie, il est temps de supposer que vous avez été piraté par une partie hostile. Traitez cela comme si un groupe de pirates était venu et avait volé des trucs, et que vous deviez nettoyer après leur désordre. Parce que c'est ce que c'est.
- Vérifiez chaque compte sur chaque système pour vous assurer qu'il est associé à une entité spécifique.
- Il faut se méfier des comptes qui semblent associés à des systèmes mais dont personne ne peut rendre compte.
- Les comptes qui ne sont associés à rien doivent être purgés (cela doit être fait de toute façon, mais c'est particulièrement important dans ce cas).
- Changez tous les mots de passe avec lesquels ils ont pu entrer en contact.
- Cela peut être un véritable problème pour les comptes de services publics, car ces mots de passe ont tendance à être codés en dur.
- S'il s'agissait d'un service d'assistance répondant aux appels des utilisateurs finaux, supposez qu'il a le mot de passe de tous ceux qu'il a aidés.
- S'ils avaient l'accès à Active Directory en tant qu'administrateur d'entreprise ou de domaine, ils ont dû prendre une copie des mots de passe avant de partir. Ils peuvent être craqués si rapidement maintenant qu'un changement de mot de passe à l'échelle de l'entreprise devra être imposé en quelques jours.
- S'ils avaient un accès root à une boîte *nix, ils sont partis avec les hashs des mots de passe.
- Passez en revue toutes les utilisations de clés SSH à clé publique pour vous assurer que leurs clés sont purgées, et vérifiez si des clés privées ont été exposées pendant que vous y êtes.
- S'ils ont eu accès à des équipements de télécommunications, changez les mots de passe des routeurs, commutateurs, passerelles et PBX. Cela peut être une véritable plaie car cela peut entraîner des pannes importantes.
- Effectuez un audit complet de vos dispositifs de sécurité du périmètre.
- Assurez-vous que toutes les failles du pare-feu mènent à des dispositifs et des ports autorisés connus.
- Veillez à ce que toutes les méthodes d'accès à distance (VPN, SSH, BlackBerry, ActiveSync, Citrix, SMTP, IMAP, WebMail, etc.) ne soient pas assorties d'une authentification supplémentaire et vérifiez-les pour détecter les méthodes d'accès non autorisées.
- Assurez-vous que les liaisons WAN distantes sont tracées par des personnes pleinement employées, et vérifiez-le. Surtout les connexions sans fil. Vous ne voulez pas qu'ils partent avec un modem cellulaire ou un téléphone intelligent payé par l'entreprise. Contactez tous ces utilisateurs pour vous assurer qu'ils disposent du bon appareil.
- Effectuer un audit complet des dispositifs internes d'accès privilégié. Il s'agit de choses comme l'accès SSH/VNC/RDP/DRAC/iLO/IMPI à des serveurs que les utilisateurs généraux n'ont pas, ou tout accès à des systèmes sensibles comme la paie.
- Travailler avec tous les vendeurs et prestataires de services externes pour s'assurer que les contacts sont corrects.
- Assurez-vous qu'ils sont éliminés de toutes les listes de contacts et de services. Cela devrait être fait de toute façon après tout départ, mais c'est particulièrement important maintenant.
- Vérifiez que tous les contacts sont légitimes et que leurs coordonnées sont correctes, ceci afin de trouver les fantômes qui peuvent être usurpés.
- Commencez à chercher des bombes logiques.
- Vérifiez tous les automatismes (programmateurs de tâches, tâches cron, listes d'appels UPS, ou tout ce qui fonctionne selon un calendrier ou est déclenché par un événement) pour détecter les signes du mal. Par "tous", je veux dire tous. Vérifiez chaque crontab. Vérifiez chaque action automatisée de votre système de surveillance, y compris les sondes elles-mêmes. Vérifiez chaque planificateur de tâches de Windows, même les stations de travail. À moins que vous ne travailliez pour le gouvernement dans un domaine très sensible, vous ne pourrez pas vous permettre de tout vérifier, mais faites-en autant que vous le pouvez.
- Validez les binaires des systèmes clés sur chaque serveur pour vous assurer qu'ils sont bien ce qu'ils devraient être. Cette opération est délicate, surtout sous Windows, et presque impossible à réaliser rétroactivement sur des systèmes uniques.
- Commencez la chasse aux rootkits. Par définition, ils sont difficiles à trouver, mais il existe des scanners pour cela.
La décision de lancer un audit d'une telle ampleur doit être prise à un niveau très élevé. La décision de traiter cette affaire comme une affaire criminelle potentielle sera prise par votre équipe juridique. S'ils choisissent de faire d'abord une enquête préliminaire, allez-y. Commencez à chercher.
Si vous trouvez une quelconque preuve, arrêter immédiatement .
- Informez votre équipe juridique dès que vous trouvez quelque chose de probable.
- La décision de la traiter comme une affaire criminelle sera prise à ce moment-là.
- Une action supplémentaire par des mains non formées (vous) peut gâcher des preuves et vous ne voulez pas ça, sauf si vous voulez que le coupable soit libre.
- Si des experts en sécurité extérieurs sont engagés, vous êtes leur expert local. Travaillez avec eux, selon leurs directives. Ils comprennent les exigences légales en matière de preuves, pas vous.
- Il y aura un lot de négociation entre les experts en sécurité, votre direction et votre conseiller juridique. C'est prévu, travaillez avec eux.
Mais, vraiment, jusqu'où devez-vous aller ? C'est ici que la gestion du risque entre en jeu. De manière simpliste, il s'agit de la méthode consistant à équilibrer le risque attendu et la perte. Les administrateurs système le font lorsque nous décidons dont l'emplacement hors site où nous voulons placer les sauvegardes ; le coffre-fort d'une banque ou un centre de données hors région. Déterminer dans quelle mesure cette liste doit être respectée est un exercice de gestion des risques.
Dans ce cas, l'évaluation commencera par quelques éléments :
- Le niveau de compétence attendu des personnes qui partent
- L'accès des défunts
- L'attente que le mal soit fait
- Les dommages potentiels de tout mal
- Exigences réglementaires pour la déclaration d'un mal perpétré ou d'un mal trouvé de manière préventive. En général, vous devez signaler le premier cas, mais pas le second.
La décision de se plonger dans ce labyrinthe dépendra des réponses à ces questions. Pour les départs d'administrateurs de routine où l'attente du mal est très faible, tout le cirque n'est pas nécessaire ; il suffit probablement de changer les mots de passe des administrateurs et de recoder les hôtes SSH externes. Encore une fois, c'est la posture de sécurité de la gestion des risques de l'entreprise qui détermine cela.
Pour les administrateurs qui ont été licenciés pour cause, ou dont le mal est apparu après leur départ normal, le cirque devient plus nécessaire. Le pire scénario est celui d'un paranoïaque de type BOFH qui a été notifié que son poste sera licencié dans 2 semaines, car cela lui donne beaucoup de temps pour se préparer ; dans des circonstances comme celles-ci L'idée que se fait Kyle d'une généreuse indemnité de départ. peut atténuer toutes sortes de problèmes. Même les paranoïaques peuvent pardonner beaucoup de péchés après l'arrivée d'un chèque contenant 4 mois de salaire. Ce chèque coûtera probablement moins cher que le coût des consultants en sécurité nécessaires pour débusquer leurs méfaits.
Mais en fin de compte, il s'agit de comparer le coût de la détermination d'un mal commis avec le coût potentiel d'un mal commis.
10 votes
+1, j'aime cette question. C'est ce que je préfère le moins quand je traite avec un nouveau client, surtout si le dernier est parti en mauvais termes.
101 votes
Dans la plupart des endroits que j'ai quittés, le fait que je ne sois pas là pour dire "Ne faites pas ça" suffit à faire tomber le réseau. Je n'ai pas besoin de laisser des portes dérobées.
28 votes
@Paul, cela suggère que vous n'avez pas documenté correctement. Espérons que la ou les nouvelles personnes feront cette partie de leur travail correctement.
76 votes
@John, vos utilisateurs et collègues lisent la documentation ? Où puis-je en trouver ?
18 votes
@Paul, utilisateurs - non, pourquoi le feraient-ils ? Collègues (en supposant que vous voulez parler des informaticiens) - oui. La lecture de la documentation devrait être la première étape d'un nouveau travail.
3 votes
Cette question a été Slashdotted : it.slashdot.org/story/10/08/24/2014256/…
2 votes
Wow... je n'ai jamais vraiment pensé que je verrais un jour quelque chose en rapport avec moi être slashdotté... AWESOME !!!
3 votes
@Jason - Je me demandais pourquoi il y avait tout d'un coup une énorme saut dans les vues. Il est bon de voir que l'architecture SOFU peut supporter d'être slashdotté.
1 votes
Voir l'article correspondant Le responsable informatique s'en va
3 votes
Wow, je ne savais pas que tant de gens lisaient encore slashdot. Génial !
1 votes
Excellente question ! Je n'y ai jamais pensé.