vendredi 5 juillet 2019

2 ans de poste

2 ans de poste... Pas vraiment de plaisir... Un blog qui porte bien son nom...

Il y a cette période de l'année où tout le monde panique pour la certification ISO27001. Il faut broder, pisser de la doc, changer les dates un peu partout. Un peu de pipeau, de dextérité et parfois de vérité quand on sait que ce n'est pas grave ou ça ne sera pas une non conformité majeure. C'est passé. Allez, le gros du job est fait.

On a la certification alors qu'on ne sait pas patcher correctement notre SI, que je chasse encore Wannacry qu'il faut que je recommence pour Bluekeep.

Aujourd'hui un collègue quitte la société poussé dehors, mais avec une enveloppe. Bizarrement on sent une sorte de soulagement. Une sorte de burn out conscient, on ne sait plus où on en est, mais on sait que ça ne tourne pas rond. On bosse beaucoup, mais ce n'est pas efficace. J'ai appris comme tout le monde le jour même qu'il terminait ce soir. C'est le 2ième à qui ça arrive. Je vais parler un peu avec lui. En fait il sourit. On discute, on fait le même bilan de toute façon. Puis il me lâche qu'il n'est pas le dernier et qu'il y a déjà du monde sur la liste.

Bref, en cherchant à peine je trouve que c'est un "jeune" qui est arrivé avec moi et qui gère l'AD. C'est la clé de voûte de l'identité, du SI... Il était bon en plus, toujours impliqué pour renforcer la sécurité. Mais il voulait du renfort... Du renfort compétent, mais introuvable à bon prix sur le marché. Limite c'est de sa faute, il aurait du faire jouer son réseau. Ca fait un an qu'il cherche et il a refusé des juniors, puis on lui dit qu'en 1 an le junior il aurait été opérationnel. Donc qu'il a mal calculé son coup.

Bref, il maîtrise AD super bien, il n'est pas heureux et il se prend des reproches. Il trouvera mieux ailleurs et pourtant il a déjà été très persévérant.

En fait notre DSI a déformé absolument tous les postes de manager en responsable de portefeuilles et chef de projet :
- Quelle est ta roadmap ?
- Qui est le sponsor ?
- Est-ce que toutes les charges sont dans l'outil de gestion de projet ?
- Est-ce que les projets avancent bien ?
- Est-ce que tu as calculé combien ça coûte en build et run ?
- Est-ce que les ressources pour faire build et run sont bien réservées dans l'outil de gestion de projet ?
- Est-ce que tu peux faire le calcul de combien ça coûte par entité ou par utilisateur pour faire la refacturation ?
- Est-ce que ton équipe impute bien ? (sinon on ne sait pas combien de temps ils ont passé sur un projet et on ne peut pas refacturer comme il faut)
- Est-ce que tu es fidèle au forecast ?
- Est-ce que tu as bien négocié les prix avec l'éditeur ? Allez y a moyen de faire 10 ou 15% de mieux, c'est une question de principe.

Honnêtement on est trèèèèèèèès loin de l'espèce de Graal qu'on appelle "client final". C'est clairement pire que dans une société de service où on faisait des forfaits et on assumait. Ici les missions sont décousues, les priorités changent sans arrêt. Les projets traînent en longueur. Tout coûte trop cher. Mes seuls projets qui avancent vaguement sont liés à des exigences client... Mais il y a trop de projets par rapport aux admin et ingé qui peuvent réaliser les projets, et même les opérer par la suite.

Mais par dessus tout le quotidien c'est de la gestion de projet, du reporting, de la négociation de prix et en aucun cas faire son boulot initial, sa spécialité, ce pourquoi on apporte une valeur ajoutée. Bref tout le monde est au bout du rouleau et je sens que ça va empirer avec les départs.

J'ai l'espoir de monter un SOC, mais je désespère réussir à me débarrasser des autres sujets pour m'y consacrer et surtout avoir le budget au moment venu... Si ça ne passe pas, je n'attendrais pas qu'on me remercie.





samedi 29 septembre 2018

Conseil ou client final ?

Au mariage d'un de mes anciens consultants, au milieu d'une bande de petits jeunes, on m'a posé la question : "Alors c'est mieux d'être chez un client final ou dans le conseil ?"

J'ai bien sûr une réponse toute faite, "C'est bien plus facile de gérer 2 enfants en bas âge en ayant une situation stable, c'est-à-dire savoir où on va tous les jours." OK, mais quand mes enfants vont grandir, est-ce que ça sera toujours intéressant ? Quels sont les avantages et inconvénients ?

La première notion importante est que dans le conseil on est un centre de profit et dans une DSI on est un centre de coût. Dans le conseil, on sait exactement combien on rapporte à la société sur la base de son TJM et avec le montant des contrats. Bien sûr la société veut maximiser les profits et limiter l'investissement, mais je n'ai jamais eu de stress lié à l'argent que je rapportais. Dans mon poste actuel, il n'y a pas un rapport direct entre ce que je fais au quotidien et mon salaire. Je me sens parfois comme un imposteur, parfois surqualifié et je n'ai pas l'impression de faire progresser suffisamment le niveau de sécurité de la société.

La deuxième notion qui est profondément différente est la gestion de budget. Il y a forcément de la gestion de budget dans le conseil avec les recrutements, les formations et le matériel, mais on sait estimer combien rapporte un consultant supplémentaire. Dans une DSI on est plutôt sur des renouvellements de firewalls qu'on peut repousser à l'année suivante (indéfiniment), ou envisager de mettre en place un bastion à 60k€ ou des sondes IPS ou encore un EDR. Cela dépend du niveau de maturité. Chaque investissement doit être mis en rapport avec un risque pour l'entreprise, que personne ne sait estimer précisément et que personne ne veut assumer. Il faut donc savoir convaincre des gens qui ne sont absolument pas intéressés par la sécurité et qui sont de toute façon réticent de faire des investissements sans ROI.
Honnêtement, c'est ce point qui est le plus complexe (et intéressant) pour moi à l'heure actuelle. J'ai été formé pour trouver les problèmes, leur résolution et donc leur budgétisation était loin d'être ma préoccupation.

La résolution des problèmes et la mise en place de solution de sécurité sont un point très différent entre le conseil et une DSI. On se rapproche plus d'un métier d'intégrateur que de conseil. C'est un aspect que j'avais toujours abordé de façon superficielle. Je sais quoi attendre d'une solution de sécurité, mais je dois maintenant savoir comment faire la configuration ou en tout cas pousser mes collègues administrateurs système et réseau pour le faire. Même si la mise en place est très longue car elle dépend des disponibilités d'autres personnes (déjà sous l'eau), il y a une satisfaction quand les projets aboutissent. J'éprouve également de la satisfaction à comprendre comment améliorer la sécurité de notre environnement Office365 ou faire des tableaux de bord sur la base des outils de sécurité. Je vois bien qu'il y a un déficit dans les personnes qui maîtrisent la sécurité d'O365 à l'heure actuelle et j'y vois une opportunité.

Au final, ce sont 2 métiers très différents. Pour l'instant je pense apprendre énormément sur le fonctionnement d'une DSI et la gestion de budget. Je ne suis pas fixé sur le fait de rester en interne chez un client final ou retourner dans le conseil. Ce qui me manque aujourd'hui, c'est d'avoir un chef avec qui je peux avoir des discussions ouvertes et fréquentes, pas un directeur avec qui je dois prendre rendez-vous toutes les 2 semaines via son assistant. Bien s'entendre avec son chef, être en phase sur la stratégie et être dans une société qui a de vrais besoins en sécurité déjà perçus par la direction seront mes critères pour choisir mon prochain poste.

vendredi 2 février 2018

Bilan de presque un an de poste

Depuis quelques jours je cherche à faire un bilan de l'année passée. D'abord qu'est-ce que j'ai réalisé et qu'est-ce que ça a amélioré ? Et qu'est-ce que je peux attendre d'une année supplémentaire dans la même société ?

Je suis arrivé pour remplacer le RSSI qui a été détaché de la DSI pour rejoindre la Direction Générale. Il a donc laissé vacant un poste plutôt organisationnel, mais comme il garde ce rôle, une personne plus technique avait du sens.

L'attente principale de mes chefs en termes de sécurité est de conserver la certification ISO27001 qui comme on le sait, ne garantit absolument pas le niveau de sécurité ou maturité de la société. Bref ma tâche est d'assurer le suivi du plan d'action contenant nos 2 principales non-conformités : avoir un PCA et faire des revues d'habilitation tous le 6 mois.

En arrivant, je n'en ai fais qu'à ma tête, j'ai scanné le réseau de fond en comble et planté le cœur de réseau 1 ou 2 fois avec masscan et nmap... J'ai refait une cartographie réseau pour pouvoir attribuer mes découvertes à un responsable bien précis. WannaCry m'a bien aidé avec une faille RCE.

  • Réseau non fiable
  • Systèmes vulnérables 600 en mai 2017, 200 en janvier 2018
  • Cartographie réseau à jour

J'ai ensuite passé du temps sur une cartographie Internet. J'ai découvert du Drupal avec la faille LDAP (2 serveurs corrigés) et un Oracle Web Application Server de 2008 (pas corrigé). Des tonnes de WordPress et plugin pas à jour (corrigés). Une filiale qui fait du développement maison avec du PHP sur IIS sur Windows 2000 (ouvert sur Internet).

  • 1600 IP
  • 400 hostnames
  • Des développements maison hébergés sur nos infra
On a un SIEM qui est saturé rien qu'avec les logs des DC. Il n'a aucune règle prédéfinie adaptée à des DC. La règle qui génère le plus d'alerte est celle sur 10 échecs d'authent en moins de 2 minutes avec un compte qui commence par "adm". Après 1 mois d'échange avec les espagnols, aucune piste n'a permis d'identifier le phénomène. 2 mois après je me rends compte qu'il s'agit du même serveur qui fait sapin de Noël dans Nessus avec une belle vulnérabilité MS08-067... 2 mois après encore, je trouve un créneau pour exploiter la faille avec Metasploit, je creuse, j'augmente le niveau de log, ça ne vient pas d'une authent à destination de ce serveur, mais du serveur qui a un service qui tente de s'authentifier. Je lance Redline, je fais un petit forensic, c'est SQL Server qui a un compte local, mais avec une authent sur un autre domaine. Il s'agissait de Netbackup qui sauvegardait sur un serveur d'un autre domaine...

Concernant le SIEM, je suis désespéré qu'il soit saturé avec si peu de données, mais il est mal géré. J'ai bloqué le projet d'upgrade au profit du recrutement d'un admin sécurité. 2 mois que je n'ai pas de nouvelle à propos de ma fiche de poste...

Toujours sur le SIEM, j'aurai préféré avoir de la visibilité sur les tentatives d'authentification depuis Internet, donc avoir les logs des VPN, d'OWA et de l'extranet. Le but étant d'activer la géolocalisation des IP et de voir des anomalies... Finalement lors d'une tentative de brute force nous sommes remonté à OWA et l'IP source était... celle du reverse proxy. Les logs du reverse proxy... inexistants (ça serait trop gros ©l'admin Exchange).

Bilan sur le SIEM :
  • Pas d'alerte utile
  • Périmètre sensible non pris en charge
  • SIEM saturé
Décidé à mesurer l'efficacité des moyens de sécurité et sur du long terme leur amélioration, j'ai commencé à mettre en place des indicateurs. Je me suis alors confronté à la réalité du terrain... aux effets des dérives du temps... Sur Active Directory impossible de trouver un champ pour savoir si un utilisateur est un interne ou un prestataire. Donc impossible de mesurer avec précision le ratio d'externe avec un compte qui n'expire jamais. Rien pour indiquer s'il s'agit d'un compte de service ou d'un BAL partagée pour faire des stats sur les lastlogontimestamp ou lastpasswordset. 30% de la population a "password not required", j'ai alors découvert que ça permet à un admin de reset un compte avec un mot de passe vide, mais l'utilisateur lui-même doit respecter la stratégie de mots de passe. J'ai 40% des machines avec passwordlastset à plus d'un an. En effet, les machines ont un mot de passe sur le compte machine et il est renouvelé régulièrement (6 mois, mais devrait être plus court). J'ai donc 40% de comptes machine qui ne servent à rien. Je n'ai pas de CMBD à jour pour comparer le nombre de machines...
  • Très peu de nouveaux KPI produits
  • Qualité de production très approximative
Bref, j'ai identifié une montagne de problèmes, mais assez peu de choses ont bougé.

Les admins avaient un compte utilisateur simple et un compte admin. Les admins de domaine ont maintenant un compte supplémentaire. Pour Office 365 ils ont encore un autre compte avec MFA (merci Deloitte pour le prétexte). Quand je dis que la bonne pratique serait d'avoir un poste dédié pour l'administration, on me regarde avec des grands yeux. Aucun espoir d'y arriver...

J'ai réussi à faire réduire le nombre d'évènements Windows collectés par le SIEM pour faire de la place pour autre chose. J'arrive à m'opposer à la publication d'applications directement sur Internet et dans un VLAN mutualisé... J'ai fait configurer la verrouillage des comptes après 5 échecs d'authentification (utilisateurs et admins).

Ca ne fait pas lourd pour une année de travail, les admins sont sous l'eau, ni proactifs et ni réceptifs. Je cherche donc à avoir un admin dédié à la sécurité pour prendre en charge ce genre de travaux. Cette année risque d'être consacrée au RGPD et peu à la technique. S'il y a des débouchés techniques, ça sera sur de la rétention et de la traçabilité, mais rien pour renforcer l'infra déjà existante. Pas de budget pour l'informatique... J'essaies de passer par le budget du RSSI pour lancer une campagne de phishing, mais il n'a pas plus de liberté que la DSI...

J'en reviens donc à la base de la sécurité quand il faut tout prouver : l'analyse de risque. Je vais donc tenter cette année de décrire les risques au maximum. Ce n'est pas ma spécialité, mais au moins ça me fait apprendre comment marche la sécurité dans le monde de l'entreprise car quand on est consultant et qu'on intervient chez un client, tout ce travail a déjà été fait...




samedi 27 janvier 2018

Les rapports de pentest sont un échec !



A la demande générale de mon lecteur, je vais profiter de mon blog pour faire un constat sur les rapports de pentest.

J'ai 13 ans d'expérience en tests d'intrusion (mais pas que) et depuis 1 an je suis passé du côté obscure de la force, le côté où on peut s'appuyer sur des consultants pour faire notre travail...

Quand j'ai débuté en 2005, les rapports étaient très techniques, on me disait de mettre les rapports nessus et nmap en intégralité en annexe, mes rapports pouvaient faire 250 pages (et on imprimait énormément à cette époque). Première phrase de la synthèse managériale, "Au regard des audits réalisés pour des clients du milieu (bancaire, assurance, militaire, énergie - rayer la mention inutile) sur des plateformes similaires, nous estimons que vous niveau de sécurité est (police taille 30, en gras, rouge, centré - très satisfaisant/satisfaisant/passable/insuffisant)."
Second paragraphe, un baragouin technique. Troisième paragraphe, un tableau de vuln. Chapitre suivant un gros mélange de fiches vulnérabilités/recommandations.

Vers 2008, on a dégagé les annexes et traces d'outil, en synthèse on mettait plein de tableaux de  croisement des criticités, complexité de correction, estimation des priorités. Dans les fiches vulns, la description de la recommandations hyper précise avec le hardening IIS/Apache/Tomcat.

Vers 2013, on présentait des scénarios crédibles avec les différentes vulnérabilités identifiées. Mais quasiment pas de recommandation technique à base de lignes de commandes (au passage, c'est incroyablement plus rapide à rédiger).

Ces différentes époques pour moi correspondent à des sociétés différentes et donc des approches différentes des clients, mais je suis persuadé qu'aucune des approches n'étaient efficaces. En effet en 2017 j'ai fait réaliser un audit et début 2018 je fais le bilan que rien n'a progressé. Je fais le constat que d'une part le rapport a raté sa cible et d'autre part qu'en interne, on ne sait pas utiliser ce type de rapport technique.

Ce que je constate, c'est qu'un rapport d'audit à 2 cibles :
  • La direction qui va devoir débloquer un budget et prioriser les actions de correction par rapport aux besoins business
  • Les admins qui ont besoin de directives claires et des moyens d'estimer les effets de bord.
Je constate également (j'étais également dans ce cas) que les charges sont tout le temps sous-estimées :
  • On considère que la recommandation est appliquée en production sans risque et sans retour arrière.
  • On considère que le client a les ressources compétentes en interne et disponibles pour corriger.
  • On considère que notre recommandation est une façon de corriger la faille, qu'il peut y en avoir d'autres et qu'il faut de toute façon anticiper les effets de bord (pourtant à l'opposé du premier point).
Mes conseils :
  • Il manque vraiment de communication avec le client pour comprendre la façon de travailler des équipes et qui il faut convaincre pour débloquer un budget.
  • La synthèse devrait idéalement faire ressortir des risques métier qui comprennent les dirigeants.
  • Il faut que les dirigeants prennent connaissance des rapports et aient une soutenance spécifique.
  • Il faut intégrer dans les recommandations des conseils pour identifier et éliminer les effets de bord.
Evidemment, là où ça coince :
  • La sécurité/technique est ignorée des dirigeants, ils ne veulent pas savoir que ça ne va pas et ne veulent pas que ça coûte plus cher.
  • Les pentesters ne sont pas formés et par nature n'aiment pas faire des analyses de risques.
  • Les pentesters ont peu de temps pour rédiger les rapports et travailler avec les vieilles technos pour identifier les effets de bord, n'est pas leur priorité.
Ma conviction est que les pentesters sont en vase clos, pas assez ouverts sur les problématiques des admins afin de vraiment les aider, sinon ils restent pétrifiés comme un lapin devant les phares d'une voiture. Le manque d'implication de la direction est un vrai problème interne chez les clients.

PS : Tout commentaire sera le bienvenu.
PS2 : L'illustration symbolise un message mal délivré à son destinataire.

jeudi 26 octobre 2017

Investigation du jour sur une fraude au président

Début d'après-midi avant d'aller en réunion, un utilisateur ouvre un incident de sécurité concernant un cas de fraude au président. Jusqu'à maintenant je me disais qu'une fois détecté par l'utilisateur il n'y a plus de risque et je classais l'affaire.
Ici un élément a attiré ma curiosité, il y a un typosquatting en plus avec un 1 à la place d'un L. Pourquoi se donner tant de mal ? Qu'est-ce qu'il se cache derrière ?

Avant de creuser, j'ai identifié 5 destinataires du même message, fait blacklisté le domaine et préparé une comm pour le RSSI... Place aux choses sérieuses. =)

Première étape le whois, je passe par RiskIQ au lieu de domaintools.
Je découvre que le domaine est déposé chez "PDR Ltd. d/b/a PublicDomainRegistry.com" avec une adresse mail chez outlook.com.
On peut voir que le nom a été déposé il y a 2 jours... Merci l'antispam qui laisse passer ça...

Ensuite on a une adresse IP associée au domaine qui pointe sur un range Google. (Pas creusé ce point.)
Plus de 1000 domaines ont pointé sur cette IP... Et beaucoup sont taggués comme malveillant par divers éditeurs (Kaspersky, emerging_threats). On voit l'intérêt de RiskIQ, même en version community.

Mais avec cette réputation comment le mail a-t-il pu passer ?

Seconde étape, analyse en profondeur des headers du mail et de l'enregistrement SPF lié au domaine.
Pour le SPF et les "dig" en général, il y a un outil de Google ici.

Magnifique, un service de messagerie online... Confirmé dans les headers mail c'est bien passé par eux et donc reverse DNS OK et SPF OK (et même DKIM).


En conclusion, un domaine acheté il y a 2 jours sans doute avec paypal ou une CB volée et de fausses infos, puis associé à un service de messagerie SaaS permet d'avoir la réputation suffisante pour passer les antispam actuels. Au vu de la réutilisation des données du whois, ces personnes font du volume et non de la qualité (mail en anglais entre 2 français ???).

vendredi 25 août 2017

Faire preuve de conviction

L'article précédent était resté 2 mois en brouillon dans Blogger. Depuis j'ai réussi à montrer au DSI (directeur) et à la DSI (direction) nos faiblesses. Ils sont engagés dans ces chantiers de hardening et je me retrouve pilote à suivre leur avancement avec leurs très peu de disponibilité...

Heureusement qu'il y a des incidents commet un brute force sur AD remonté par le SIEM et qui vient de nulle part... Les events Windows ont le bon goût de mettre le hostname et non l'IP source. On a fait la chasse à "Windows 7" et "freerdp"... Obligé de sniffer le réseau sur le DC... Pour tomber sur un port RDP ouvert sur Internet dans une filiale racheté avec les admins qui ont démissionnés depuis longtemps.
Il y a aussi eu ce ransomware, toute dernière version de Locky qu'on a réussi à tracer et qui est venu d'un vieux serveurs de mail gardé au cas où alors que la société a changé de nom depuis 7 ans. 7 ans qu'un serveur tourne en Roumanie (c'est pas la Roumanie, mais c'est pareil), sans être vraiment géré et sans antispam... Le routage des mails sur notre infra se fait par l'intérieur sans repasser par l'antispam. \o/

Je profite de ces occasions pour faire travailler les gens ensemble en leur faisant comprendre leurs responsabilités respectives... L'admin messagerie qui doit analyser les mails de la victime, le proxy web avec les navigations de la victime, puis de toutes les personnes qui se sont connectés au domaine malveillant, puis l'admin du serveur de fichiers pour faire la restauration...

Je fais bien mon rôle de "coordinateur sécurité", mon DSI a compris ma valeur ajoutée sur le sujet et commence à me faire confiance. J'essai aussi de mieux le cerner. C'est un gestionnaire qui ne fonctionner qu'avec des reportings, qui doit justifier les budgets, négocie des contrats et refacture aux filiales. Il a de nombreuses compétences, mais ne saurait pas faire une macro Excel ou calculer un sous-réseau. On a encore du temps pour s'apprivoiser l'un l'autre. Le poste commence à être intéressant.

Nouveau poste, nouvel environnement

Or donc, mes amis proches savent que j'ai changé récemment de poste. J'ai l'impression d'avoir fait un audit de 3 mois (loin d'être terminé) et j'ai d'ailleurs eu un pentest interne par une société tierce. Mais là où l'auditeur peut se satisfaire de trouver quelques failles, moi j'ai besoin de connaître un maximum de faiblesses et avoir une idée de ce qu'il peut arriver.

Pour poser un peu le contexte, le RSSI était sous la DSI, il a fait le travail de fond sur les politiques et, soi-disant, a été détaché de cette direction pour être impartial. Sa place était donc vacante et une personne plus technique et opérationnelle était la bienvenue. Sauf qu'on m'attend principalement pour piloter les actions 27001 et aider à la rédaction de propositions commerciales et plan d'assurance sécurité pour dire qu'on fait bien les choses. En gros mon chef ne comprend rien à mon expérience et à ce que je pourrai apporter de nouveau.

Je partage donc mon temps en 2 pour me garder une part de technique sans quoi ça ne sert à rien que je reste là-bas. J'ai profité de WannaCry pour scanner le réseau qui est très vaste. Un coup de masscan histoire de... mais le réseau a un peu mal tenu. On peut voir ici un bon conseil qui est de mettre le rate entre 5000 et 10000 pour commencer. J'étais à 10000, je suis obligé de faire à 1000 pour passer sous le radar. Le firewall qui porte les VPN des filiales a fièrement fêté ses 10 ans...

La semaine suivant WannaCry (15/05/2017) j'avais 580 machines vulnérables, en juin 300, en juillet toujours 300 machines avec une faille RCE dont l'exploit est public. Le patch management est défaillant dans plusieurs filiales. A tout hasard je vérifie heartbleed et je ne trouve que 6 machines vulnérables... On a une licence NESSUS que je vais faire chauffer :)

Comme je l'ai dit, il y a eu un pentest interne la semaine dernière et les auditeurs étaient concentrés sur les dernières techniques de hack sur Active Directory alors que la demande était de balayer large. Ils ont réussi à devenir admins du domaine avec les techniques presque imparables, mais sur un seul domaine. J'en arrive donc à lancer l'artillerie lourde : masscan (même pas peur) pour identifier les interfaces web et EyeWitness pour faire des screenshots.

Je passe en revue tous les Tomcat (tomcat//tomcat), les imprimantes (s'il y a un compte AD configuré pour déposer les scans sur un partage), toute interface d'admin. J'ai une brouette de NAS, switchs, imprimantes, interphone (!!!), carte TCP/IP pour centrale de sécurité (!!!) avec le mot de passe par défaut. Et là j'en ai sur toutes les filiales. (Un admin a détecté mon activité... Respect.)

Mon objectif est maintenant de montrer à mon chef (le DSI) que le niveau de maturité est bas et qu'on est tout sauf protégé. Le DSI veut que par moi-même (donc sans son appui) j'arrive à convaincre les IT manager de prendre le temps de corriger tous ses problèmes alors que déjà le patch management leur pose problème sous Windows. Je ferai de mon mieux... Je ne promets rien. J'espère qu'ils se sentiront mal quand j'aurai mis des indicateurs mensuels sur la correction des vulnérabilités.

Comme on dit, quand la prévention ne fonctionne pas, il faut se préparer pour la détection et la réaction. J'ai donc commencé à faire une cartographie et un inventaire, mais aucun document de référence n'est à jour pour permettre d'attribuer une IP à une filiale et donc à un contact précis... Espérons que l'antivirus fasse son boulot parce qu'en cas d'incident je suis à poil. (Oui, c'est une blague... on connait bien l'efficacité des antivirus.)

Donc à ce jour en nouveau chantier caché j'ai une auto-évaluation guide d'hygiène de l'ANSSI et d'autres matrices et guides sur la réponse à incident.