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

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.

A propos des augmentations ridicules dans les grands groupes (mais pas que)

Je fais l'écho de mon post précédent (qui a 8 mois déjà). Je suis sorti du comité de revue des consultants avec la nausée. Malgré nos résultats, malgré notre discipline sous le feu des projecteurs, malgré la pénurie de pentesters... mon équipe a la même part que toutes les autres. Mon constat est encore plus consternant que celui de l'année précédente. 2,2% à partager dans l'équipe...

OK, pas la peine de chipoter, je n'aurai rien d'autre. Mon meilleur a posé sa dem, c'est bien le seul avantage que j'y vois. Les 3 nouveaux n'auront rien. Il me reste 5 gars et les 2,2% de 9 personnes. J'ai 2 gars au dessus du lot qui mérité qu'on les aligne sur le marché (en gros 10% d'augmentation par an).
Allons-y dans un premier temps pour leur mettre 10, un 3ième m'a demandé 5% sinon il va voir ailleurs. Et les 2 derniers les 2,2%. Mais voilà, ça dépasse. Au final j'en ai 2 à 7%, un à 2% et 2 à 1% alors qu'ils sont bons.

Alors je fais comment moi pour garder mon équipe dans la durée sur un marché hyper tendu et agressif ?

You only have one job

Je pense vivre actuellement l'audit le plus médiocre de ma carrière. Je réalise actuellement un audit pour le compte d'un responsable risques qui veut qu'on fasse son boulot à sa place.

En gros on a fait l'audit et découvert un certain nombre de vulnérabilités. D'habitude on s'arrête-là. Sauf qu'ici, il faut qu'on aille revoir chaque acteur pour lui demander le niveau de criticité de la faille, si le risque doit être traité, si c'est déjà dans un plan d'action et sinon quelle charge de travail ça représente. C'est intéressant, mais là le périmètre est une énorme infrastructure donc on a une équipe sécurité, une équipe réseau, des développeurs (web, mobile et API), des responsables d'équipe, des MOA, des exploitants, des correspondants sécurité, des RSSI et chacun se renvoie la balle.

Notre cher client nous indique que tant qu'on ne fait pas une boucle on doit suivre les pistes. Après 34 entretiens réalisés sans compter qu'il faut au moins appeler 3 fois pour avoir la personne et qu'en général ce n'est pas la bonne personne, c'est usant.

J'en suis venu à l'idée saugrenue de cacher des vulnérabilités de faible et moyenne importance pour éviter la chasse au responsable. Donc en gros, cher Client, fais ton boulot, je fais le mien et tu auras de meilleurs résultats parce que j'ai autre chose à faire que de passer les 3 quarts de ma charge à tenter de joindre les mauvaises personnes. Et un gros merci au junior qui souffre avec moi :)

L'illusion du score d'un pentest

"If you can not measure it, you can not improve it." Cette citation de Lord Kelvin a beaucoup de sens en sécurité et est la base des tableaux de bord. Pourtant j'ai du mal à trouver comment l'appliquer dans le cadre des tests d'intrusion.

J'imagine qu'il faudrait trouver ce qui est quantitatif et qualitatif dans le résultat de l'audit pour pouvoir réaliser une mesure, mais un audit n'est pas et n'a pas vocation à être exhaustif, ce qui implique que la quantité peut varier, notamment avec l'expérience de l'auditeur et le nombre de jours disponibles. L'objectif  d'un test d'intrusion est d'aller le plus en profondeur possible (p0wner le serveur, le réseau, le contrôleur de domaine), alors quand on trouve une injection SQL on va passer du temps dessus. Puis on a autre chose de plus intéressant à mettre dans le rapport que d'indiquer que la méthode TRACE est acceptée. Et pourtant c'est exactement ça qui va biaiser notre calcul car on n'aura pas une base cohérente entre les audits... Au passage, un camembert de répartition des failles par criticité n'a aucune valeur d'une part parce que la base est incohérente et d'autre part une appli avec 4 vuln critiques et 4 faibles ne devrait pas ressortir de la même façon qu'avec 1 critique et une faible.

Ensuite pour le qualitatif si on revient encore sur notre méthode TRACE, on peut trouver des discussions sur le sujet http://www.securityfocus.com/archive/107/533982/30/30/threaded avec des références à rapid7 (CVE à 6). Du côté de Qualys, c'est très inconsistant :

Toutes les failles n'ont pas non plus un CVE et pour régulièrement qualifier des failles avec un score CVE, c'est très dépendant de la personne qui définit les niveaux. Ça ne prend pas non plus en compte le fait qu'il y est 5 ou 1000 utilisateurs.

Bref, donner une note à un audit autrement qu'au pif semble impossible. Récemment j'ai croisé le projet CCWAPSS (Common Criteria Web Application Security Scoring) qui vise à changer la logique de calcul pour s'appuyer sur la chaine "applicative" :

• Authentication
• Authorization
• User’s Input Sanitization
• Error Handling and Information leakage 
• Password/PIN Complexity 
• User’s data confidentiality 
• Session mechanism 
• Communication security 
• Patch management 
• Administration interfaces 
• Third-Party services exposure 

Pour chaque critère on indique s'il y a une faille, si c'est correct ou si c'est au niveau des "best practices". Ce qui nous refait tomber dans un biais : il n'existe pas de liste exhaustive des bonnes pratiques. Ce qui, une nouvelle fois (ou comme toujours), nous ramène à l'expertise de notre auditeur.

Alors quand un client demande "comment on se positionne par rapport à notre secteur d'activité ?", on va rester flou et faire "à dire d'expert". Puis si tous les autres étaient mauvais, est-ce que ça serait une bonne raison pour être mauvais également ?

A propos d'orange

Disclaimer : Je ne cherche pas à faire de la diffamation, ce qui va suivre reflète ce que je pense vraiment.

Update : J'avais raté ce discours de Stéphane Richard : "A chaque attaque, nous progressons". Au moins il y a du positif :-)

A l'annonce d'un deuxième piratage de données à caractère personnel depuis le début de l'année chez orange, je ne peux m'empêcher de réfléchir à cette situation (allez savoir pourquoi). Ma piste principale est qu'il n'y a pas vraiment plus de piratage qu'avant, mais qu'on en parle plus (Why Has There Been So Much Hacking Lately? Or Is It Just Reported More? A Freakonomics Quorum). En effet orange étant opérateur Internet, il est soumis à l'obligation de notifier les personnes victimes d'un vol de données (legifrance).

Il est évident qu'orange a une surface d'attaque immense entre les jeux éphémères, les sites promotionnels, les différents portails, les applications pour les utilisateurs et les applications internes. De plus les jeux et sites promotionnels sont généralement créés par des startups qui n'ont aucune idée des bonnes pratiques de codage. Côté portail, on peut repérer des grosses pointures comme Laurent BUTTI qui maitrise son sujet (vous trouverez de nombreux articles dans MISC (où il publie à titre personnel ?) ou dans les archives de l'ossir). Mais force est de constater qu'il travaille aussi bien en boite blanche qu'en boite noire... Si vous voulez lire plein de discussion d'expert sécurité d'orange, leur blog est pas mal.

D'un autre côté orange veut devenir un leader en sécurité informatique et pour cela a racheté Atheos, mais j'ai peur que ça tourne comme pour AQL (racheté en 2007) dont le CESTI a depuis été fermé (pas vraiment de message officiel, mais AQL ou orange ne figure plus sur le site de l'ANSSI).

Mais il ne faut pas confondre centre de cout et centre de profit. Ces sociétés ont été rachetées pour vendre du service directement aux clients d'orange business service et non pour servir l'interne. A noter qu'on trouve un entretien de Nicolas Furgé (responsable des offres sécurité chez OBS) qui noie le poisson en mélangeant les experts qui sont sur des projets internes et ceux qui travaillent pour les clients. Et hop ! OBS devient ainsi la "plus importante société de services européenne dans le marché de la cyberdéfense, renforçant son positionnement d’acteur majeur dans ce domaine sur le plan mondial".

Pour l'anecdote, après le piratage d'un jeu à 2 balles d'orange en 2009 (ou 2010, je ne trouve pas d'archive), quelques pentesters d'AQL ont voulu faire du proactif et ont failli se faire licencier pour tentative d'intrusion... De quoi mettre la bonne ambiance et donner envie de contribuer à sa société.

Pour faire un peu dans l'analyse, je dirai qu'orange a une surface d'attaque colossale et qu'on n'entend pas parler de tous les piratages et surtout que  les piratages ne sont pas tous détectés... La sécurité au sein d'orange n'est pas en avance sur les autres sociétés et les process internes sont vieux jeu. orange va conserver Athéos telle quelle et vendre du service, pourtant 130 experts supplémentaires ne seraient pas inutiles pour améliorer la sécurité interne d'orange. Je m'attends à davantage de piratages massifs tels que peuvent en subir des Google, Microsoft et Facebook et j'espère qu'orange mette en place une "vraie" dynamique sécurité en interne (à différencier d'un service minimum pour réparer la casse).
Petite idée pour la fin : Ca serait beau qu'orange soit une des premières société française à mettre en place un bug bounty (viadeo en a déjà un).



Quelques archives de piratages d'orange :
http://www.ehackingnews.com/2012/10/news-nullcrew-hacked-orange-uk.html
http://www.dslreports.com/forum/r22439596-Orange-French-Portal-Hacked-250-000-accounts-compromised

Ou encore le fail du logiel HADOPI et de la plateforme web qui allait avec :
http://sid.rstack.org/blog/index.php/413-hadopi-et-orange-unis-pour-le-pire
J'avais souvenir que Sid disait (à l'instar d'EADS) qu'il y avait des experts reconnus chez orange, mais que bien souvenant dans les grands groupes, ils ne sont pas consultés sur des projets sur lesquels ils auraient pu apporter leur précieuse expertise.

CVSS ou pas ?

Je suis actuellement sur une campagne de 15 pentests pour un client qui veut que l'on note chaque vulnérabilité avec un niveau CVSS. L'exercice est assez particulier et m'a fait perdre la foi dans cette métrique :)

Armé de mon petit calculateur de CVSS que j'ai développé en moins de 30 minutes en utilisant le manuel de référence, je m'en vais mettre des notes à mes vulns et là c'est la douche froide.

• Comment noter une fonctionnalité dangeureuse comme le transfert automatique de message dans Exchange ?
• Comment noter une faille dans un système d'authentification forte qui réduit alors l'authentification au seul mot de passe ?
• Comment qualifier le fait qu'un utilisateur puisse accéder aux interfaces d'administration d'un serveur ?
• Comment noter un bête XSS sur une applications interne ?

Il n'y a pas de réponse pour les 3 premiers points, mais on peut développer un peu sur le XSS.

• Faut-il considérer l'attaque depuis le réseau (Internet) ou depuis un adjacent network ?
• Est-ce que l'Access Complexity est élevé car nécessitant une phase d'ingénieurie sociale (phishing) ou moyenne car c'est un bête XSS sur un moteur de recherche ?
• Avec un XSS on peut voler le cookie d'une personne et accéder à l'application avec ses droits. On peut altérer ses données. Avec le cookie d'un admin on peut supprimer la base de données. Sauf qu'on attaque personne par personne. Comment qualifier l'impact DIC de façon pertinente ?

Bref, je finis par faire discrètement à ma sauce pour obtenir le niveau de criticité que j'estime satisfaisant. Mais parfois on tombe sur une vulnérabilité connue qui remonte dans un scan Nessus et là on doit accepter la criticité définie par l'éditeur qui peut être surestimée par précaution (ou le contraire). Par exemple les failles sur HP SMH peuvent aller jusqu'à 9.0 alors qu'il faut déjà avec un compte utilisateur sur un application de management de serveurs... alors qu'un XSS sans authentification sur la même application n'atteint que 4,3 et au passage la complexité est moyenne alors qu'il faut faire de l'ingénieurie sociale et qu'au final on pourrait voler un compte admin et compromettre totalement le serveur.

Un peu comme je l'évoque pour le XSS, il existe des scénarios qui enchaînent les failles. Par exemple une interface admin accessible, un contournement d'authentification, une élévation de privilège et compromission totale du serveur. Et puis quoi ? Avec des si on mettrait Paris en bouteille.

Ce dont il faut bien se souvenir quand on utilise CVSS, c'est qu'on mesure la criticité d'une vulnérabilité, on ne mesure pas le risque. Est-ce que l'entreprise est grande, a beaucoup de concurrence, a une population technophile (SSII), qui aime assez peu sa société (mauvaise rémunération) ? CVSS n'en tient pas compte. C'est à l'auditeur de faire une analyse de risque et de faire ressortir ce qui est réellement critique dans le contexte de l'entreprise.

La gestion risque/coût au quotidien

C'est étrange comment pour économiser quelques euros on peut intuitivement faire des paris et risquer de perdre plus.

Comme tous les 2 ans j'ai emmené ma voiture au contrôle technique et j'ai hésité à faire une pré-visite dans un garage. D'un côté je sais, je sens, qu'elle roule bien. Elle n'a que 7 ans. Il y a bien un impact sur le pare-brise, mais il est net et ne devrait pas se fissurer. Puis en fait la franchise est la même pour son remplacement ou pour une injection de résine... Alors ça peut attendre.

Bref je prends le risque d'emmener ma voiture directement au contrôle technique, mais je sais que je peux au moins contrôler les feux moi-même. Et ça n'a pas raté ! J'avais un feux de position et un feux de brouillard arrière grillés... Surtout que ça peut se changer tout seul. Bref je change les ampoules, mais le feux de brouillard ne veut rien savoir. Un tour sur Internet et je découvre d'une part qu'il n'est pas contrôlé et d'autre part... qu'il n'est pas utilisé, juste décoratif (pourquoi mettre une ampoule dans l'emplacement alors ?).

Résultat OK pour le contrôle technique. Ca aurait été bête de ne pas faire ce petit contrôle juste avant :)

PS : j'ai pris une ampoule Norauto et non Philips pour gagner 5€. Là encore je prends un risque, mais d'un autre côté ils les vendent par pack de 2. J'ai une marge de manœuvre :D