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...




1 commentaire:

  1. "Cette année risque d'être consacrée au RGPD et peu à la technique."
    C'est dommage de dire ça sachant que si techniquement aucun effort n'est fait, ça va faire mal...

    RépondreSupprimer