Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

sécurité

  • Introduction à la sécurité dans le Cloud (entre autre)

    Bonjour à toutes et à tous,

    Je vais tenter ici de faire un petit article sur le cloud et la sécurité, oui j'en vois certain(e)s (là au fond) qui sont déjà prêt(e)s à partir :) mais mon boulot m'a pas mal fait bosser sur le sujet ces derniers temps, du coup je voulais faire un petit retour d'expérience (vraiment petit), et comme ça vous verrez aussi pourquoi je dis que mon boulot me donne un coup de vieux et n'a que très peu de technique :P (vous imaginez pas comment je suis content quand j'ai un peu de forensic ou un audit technique à faire :D). Mais bon la réflexion métier c'est pas mal non plus (si vous verrez).

    Revenons à nos moutons avec la sécurité dans le cloud computing (du point de vue du client). Par contre ne vous imaginez pas que je vais vous sortir mes livrables comme ça hein, juste quelques axes de réflexions.

    Disclamer : Cet article bien qu'expliquant des problématiques réelles est à prendre aussi avec de l'humour (surtout concernant les textes barrés :)).

    Déjà qu'est-ce que le cloud computing : vous vous dites il nous prend pour des cons, mais je vous assure ce n'est pas clair pour tout le monde, même dans une DSI :

    Donc le cloud computing c'est du bullshit ou on vous vend des choses que l'on savait déjà faire mais avec un bel emballage commercial ... euh non, sors de ce corps moi maléfique ! Plus sérieusement pour résumer le Cloud Computing c'est la capacité d'offrir un service (on va y revenir), à la demande, modulable, et normalement accessible de partout/tout le temps (on ne parlera pas du cas des clouds privés dans cet article).

    Alors je parlais de services, beaucoup d'entre vous (tou(te)s ?!?) ont déjà vu des acronymes comme IaaS, DaaS, STaaS, SaaS, PaaS ... bref *aaS. En soit peu importe le modèle de service, on peut en étudier que trois (oui les trois qui les contrôlent tous), tous les autres ne sont que des spécialisations de ces derniers. Il faut donc comprendre les termes :

    Le reste clairement n'est que du bullshit encore pire que les trois que je viens de citer du langage commercial.

    Et donc la sécurité dans le cloud comment on l'aborde ? Comme toujours en étudiant les menaces, les vulnérabilités et les risques ... mais aussi, comme on doit le faire avec toute externalisation, les rôles et responsabilités. C'est ce premier point que l'on va déjà aborder.

    Et pour commencer on va apporter un nouveau mot CSP : Cloud Service Provider : bref pour faire simple (et pas faire de superbe phrase à rallonge, parce que, on est pas au boulot ici) c'est l'hébergeur, celui-ci qui offre du service de Cloud Computing.

    Les rôles et responsabilité : Pour expliquer les rôles et responsabilités nous allons prendre un scénario avec des CSP multiples (vous allez comprendre très vite).

    Imaginons que vous preniez un abonnement à une application en mode SaaS. Et que cette application conserve des données à caractères personnelles (donc sensibles surtout du point de vue de l'image si vous vous les faites leaké).

    Bon vous allez me dire rien de très complexe là dedans, mais détrompez-vous, les rôles et responsabilités sont très complexes dans ce cas.

    Dans notre petit scénario, comme je l'avais dit, il y a des CSP multiples c'est à dire : que le CSP qui vous loue du SaaS, loue lui même du PaaS à un autre CSP, qui lui même loue du IaaS à un autre CSP (et on peut même imaginer que ce dernier CSP loue ces locaux à une autre entreprise, mais bon, on se contente du point de vue "cloud", vous voyez que c'est du bullshit :)).

    Donc regardons un peu ce que dit la CSA (non pas notre organisme de censure de l'audiovisuel, mais la Cloud Security Alliance ...) :

    Offres /

    Responsabilités

    IaaS PaaS SaaS
    Données Clients Clients Partagée
    Logiciels Clients Partagée Partagée
    Systèmes Clients Partagée  CSP
    Virtualisation Partagée  CSP  CSP
    Réseaux Partagée  CSP  CSP
    Physique CSP  CSP  CSP

    Ce tableau est bien sur une vue simplifiée du problème, mais cela donne un bon point de vue concernant le petit scénario qui nous concerne. En effet dans le cas de CSP multiplent les resposabilités ne sont pas toutes prises par la seule entreprise avec laquelle vous avez un contrat, alors, que faire en cas de problème ? Très bonne question ... et la reponse est ********************** (ou 42 au choix) :). Sans compter que VOUS mettez des données personnelles sur des services externes, donc votre responsabilité peut aussi être jouée sur ce coup là.

    On pourrait évoquer les problèmes liés aux données de paiements (mais la prochaine version de PCI devrait revenir la dessus). En clair si vous faites le choix de l'externalisation, mesurez bien les risques (et aussi les menaces) qui pèsent sur vous.

    Parlons justement des risques : globalement voici ce qui vous pend au nez :

    • Le service ferme -> Perte de données
    • Le service est piraté (et vous n'êtes pas forcément la cible, mais vous êtes touchés) -> Altération / perte de données
    • Un petit malware se balade sur le service de cloud -> Altération / Perte de données
    • Problème matériel -> Perte de données

    Alors d'ou viendrait le vrai problème : je sais pas au hasard une vulnérabilité dans un produit de type OpenStack ou autres, un attaque sur/via les outils de virtualisation (hyperviseur) ... en gros c'est tellement le bordel que l'on ne sait pas trop d'ou pourrait venir le coup :). D'ailleurs je compte bien pondre dans très peu de temps un bien meilleur article concernant la sécurité de la virtualisation (donc un peu plus technique que celui-ci).

    Quelques menaces/vulnérabilités et risques en vrac : 

    • Infrastructure mal dimensionnée (c'est arrivé au cloud nokia)
    • API mal protégé (51 incidents répertoriés par la CSA entre 2008 et 2012)
    • Un bon vieux comptes user ou opérateur qui se fait pirater (et on sait que ça arrive souvent)
    • Une bonne vielle catastrophe naturelle (ou pas)
    • ... je vous laisse imaginer/en chercher d'autres.
    Conclusions ?

    On ne le dira jamais assez, le cloud c'est le mal !, le passage au Cloud n'est pas une chose aussi facile que certains ont tendance à croire ! Car sur cet article je n'ai parlé que des préliminaires (oh oui c'est bon ça) après il faut penser à d'autres choses : comme les problématiques d'authentifications par exemple (oh tiens j'en vois d'autres au fond qui font la gueule !).

    Donc je vais arrêter là cet article, si vous avez des questions, ou pour en parler plus / échanger des idées, n'hésitez pas à me contacter par le moyen que vous voulez.

    Je reviendrai peut être un jour avec un autre article sur le sujet, mais normalement, je vais vous préparer un article un peu plus technique concernant la virtu un de ces quatre, donc comme d'habitude ça sera écrit sur un coin de table (comprendre rapidement) avec plein de fautes d'orthographe à l'intérieur :D.

    Sinon retrouvez d'autres lectures sur Paranoiac Thoughts (comme toujours).

  • Retour sur le SSTIC 2010

    Voilà le SSTIC c’est donc terminé hier, je vais donc faire un rapide retour sur cet évenement. Malheureusement je n’ai pas pu assister à celle du vendredi matin (tiens donc !), et à première vue concernant l’une très particulièrement c’est pas une mauvaise chose J.

    M’enfin avant d’en venir sur quelques confs qui m’ont pas mal plus un petit mot d’abord sur l’ambiance : sérieusement j’avais un peu peur avant d’aller la bas de me retrouver dans un évenement « hype » « trop commercial », mais au final il n’en ai rien. Très bonne ambiance, des personnes qui connaissent à la fois le marché de la sécurité et la « scène » ça fait plaisir (je n’ai pas dis que c’était le cas pour tous, mais concernant la majorité des gens que j’ai rencontré c’était le cas), j’ai d’ailleurs eu la bonne surprise de voir quelqu’un que je voyais régulièrement aux 2600 Lille il fut une époque J.

    Maintenant passons aux confs que j’ai plus qu’apréciée (ça veut pas dire que toutes les autres étaient de la merde, mais bon on a le droit d’avoir des préférences non ?) :

    VirtDbg : Undébogueur noyau utilisant la technologie de virtualisation matérielle VT-x

    Ce qui nous a été présenté c’est un débugueur noyau installant un hypervisieur via une carte équipé d’un FPGA et permettant ainsi d’injecter l’hyperviseur par le bus PCI et donc les accès DMA. L’avantage de cette technique et de pouvoir observer par exemple des malwares ayant des moyens de protection contre la virtualisation, ou des mécanismes internes à Windows 7 (DRM et PatchGuard). J’espère que le projet va avancer et aussi que la publication de l’article va bientôt être public afin que vous puissiez voir un peu la chose.

    Analyse de l’éfficacité du service fourni par une IOMMU

    Ce que j’ai adoré, c’est surtout la démonstration très visuelle, ça c’était cool. Après concernant l’étude en elle-même : il s’agissait au fait de montrer que les mécanismes de protection contre les attaques DMA de type IOMMU (techno Intel VT-d) sont bypassable (par usurpation d’identité d’un périphérique ou la modification de la structure des données en mémoire).

    Quelques éléments en matière de sécurité des cartes réseau

    Une conf un peu flippante sur une vulnérabilité qui touchait des cartes réseau Brodcom. En gros ça s’en prenait aux fonctionnalités d’administration à distance (ASF 2.0).

    Et les deux conférences de Harald Welte à propos de OpenBSC et OsmocomBB : Je vous laisse chercher J.

    Bon après ces trois jours très sympatiques : retour au « train train » quotidien.

  • NTOP (sécu pas chère 2) et Haïku le retour

    Oui je vous avais parlé dans un précédent post d'un petit programme nommé ntop qui permet d'avoir une certaine idée de ce qui se passe sur votre réseau. Donc un petit post ici pourune fois que j'ai, et que je reprends, le temps de poster sur ce bon vieux blog :).

    Donc NTOP comme ça fonctionne : comme beaucoup d'outils de ce genre il faut faire un petit port mirroring (ou utiliser un TAP), comme le montre ce schéma (trouvé sur le site de ntop).

     

    ntop_world.png

    Donc j'ai eu l'occasion de tester un peu cette petite bête et sérieusement pour quelque chose qui s'installe et se configure aussi facilement (donc un apitude et une petite commande et c'est bon sous Debian) c'est assez performant et utilisable.

    L'interface web est assez claire :

     

    ntop_trafficpage.PNG

    Enfin bref, un très bon outil (du moins pour ce que j'en ai vu). Je vous le conseil sérieusement.

    Sinon Haiku, je ne sais pas si certains d'entre vous s'en souviennent il y a quelque temps j'ai fait un petit test de Haiku, et il semblerait que dernièrement un système basé sur celui-ci ai fait son apparition, je vous laisse le découvrir.

    Voili, voilou ... à la prochaine !

  • La sécurité pas chère : Surveillance et analyse réseau, partie I

    Voilà j'ai décidé sur mon blog de faire une petite série d'article nommée : la sécurité pas chère :).
    Le but est de prendre certains produits commerciales du marché (performant ou pas), et de voir comment mettre en place les même fonctionnalités avec du libre.
    Pour cela je ferais dans un premier temps l'analyse du produit, puis celle des équivalents libres (je mettrais aussi des articles sur mon site afin de montrer comment configurer ces équivalents).
    Je veux bien sur éviter de partir dans le troll libre/non libre, donc je m'attacherais uniquement à la partie technique.
    Donc la première série de ces articles sera sur ... Norton Antivirus ... non je troll, j'ai choisi les sondes d'analyses et de surveillance réseau, dans un premier temps je voulais citer des marques, mais il m'a été conseillé de ne pas le faire.

    Comment cela fonctionne :
    Au fait pour mettre en place une sonde de surveillance c'est assez facile, la sonde se met en "parallèle" du flux réseau (au putain la remonté des études en électrotechnique :)), en gros vous faites un port mirroring du flux que vous désirez analyser vers la sonde, et elle se charge du reste.
    Sur la sonde un OS propriétaire est installé (au fait, dans les cas que j'ai rencontré il s'agit d'un FreeBSD modifié, notamment au niveau du système de fichier afin de pouvoir enregistrer et traiter les données plus rapidement et efficacement). Ensuite un bon nombre d'outils vous donne la possibilité d'analyser, de visualiser et de rejouer le trafic qui a été enregistré par la sonde (parmi ces outils y a snort d'ailleurs).
    Le tout se fait via une interface web.
    Voilà (en gros bien sur car c'est un peu plus complexe que ça mais voilà ...).
    Je vais donc essayer de lister des outils, et de faire des docs qui vont avec, qui pourraient permettre de simuler ce produit (et vu que je parle de pas cher, on va essayer de chiffrer le tout en matos/ coût humain tant qu'on y est :)).

    Commençons :
    Tout d'abord le matériel, bon pour faire une petite sonde, il nous faut une box avec 3 cartes réseaux (une recording, une d'administration et une pour rejouer le trafic enregistré). Pour pouvoir enregistrer pas mal de chose on va aussi se prendre 2 To de DD (sans RAID hein on fait pas 
    de backup :), oui j'ai pas dis que j'allais faire tout à votre place non plus).
    En choisissant du matériel, un minimum stable, mais pas cher, on peu facilement se faire un tour pour 400€ de budget.

    Passons maintenant à l'Os, comme dit plus haut c'est un FreeBSD modifié, donc vous pouvez très bien choisir un FreeBSD ou n'importe quel *BSD, mais moi juste pour faire un peu troller je vais prendre un GNU/Linux :).

    Donc maintenant voici quelques idées d'applications à mettre en oeuvre pour analyser/surveiller le trafic réseau :
    .ntop
    .etherape
    .tcpdump
    .wireshark
    .Snort
    et d'autres ...

    Nous verrons comment mettre en place tout cela dans le prochain petit article sur le sujet (et surtout comment faire fonctionner entre eux les outils afin que ce soit pas trop borde*****), qui sait peut-être pour Noël :).

    Bonne journée à tous et à toutes.

    P.S. : Article court, car à l'origine j'avais décris plus précisément un outil existant, mais comme dit plus haut, il m'a été déconseillé de citer une marque en particulier.