Les entreprises font face aujourd’hui à de nouveaux modes de consommation de l’informatique où les API jouent un rôle essentiel pour développer de nouveaux services et faciliter les échanges avec les clients et les partenaires. Si cette nouvelle « économie de l’API » génère de formidables potentiels de croissance, elle pose également de nouvelles problématiques en matière de sécurité et de confidentialité des données échangées, auxquelles il faut apporter des réponses adaptées et efficaces. Êtes-vous certain de l’intégrité de vos API ? Les réseaux sociaux, les services Cloud ou encore les terminaux mobiles ont bouleversé les conditions d’accès aux données et aux services, en même temps qu’ils ont généré de nouvelles opportunités de croissance pour les entreprises. C’est dans ce contexte que les API web, véritables couches communes faisant l’interface entre différents systèmes, plateformes et appareils, se sont peu à peu imposées dans la sphère technologique. Et ce n’est qu’un début : selon le cabinet Gartner, les trois quarts des entreprises du Fortune 500 envisagent d’ouvrir une API au cours de l’année. Toutes ces API participent à enrichir les services fournis aux utilisateurs : transmettre des résultats d’examens médicaux en ligne, gérer ses comptes bancaires depuis son téléphone mobile, consulter un historique de commandes sur sa tablette… Mais aussi séduisants et pratiques que soient ces services, ils n’en soulèvent pas moins des questions critiques quant à la sécurité des données qui transitent via ces API. Les entreprises l’ont bien compris et la sécurisation de leurs API est au coeur de leurs préoccupations. Non toutefois sans un certain nombre d’idées reçues qui en empêchent la pleine efficacité…

1. L’opacité d’une API suffit à la protéger
La première erreur consiste à penser qu’une API est protégée de fait, seules les équipes impliquées
dans son développement en connaissant les rouages. Une approche assurément inefficace sur le
long terme, dans la mesure où si un produit ou un service est doté d’une API, celle-ci finira par susciter la curiosité de tiers qui ne manqueront pas de l’examiner. Et, pour peu qu’ils soient
malveillants, de s’en servir à mauvais escient. Le constructeur automobile Tesla a failli en faire
l’amère expérience : il avait choisi de ne pas documenter l’API de l’un de ses véhicules électriques
de luxe, ni d’y appliquer de règles d’authentification, estimant qu’elle ne présentait pas de risques
critiques en termes de sécurité. Jusqu’à ce qu’il découvre qu’elle permettait potentiellement à
n’importe qui de déclencher des actions à distance sur la voiture. En d’autres termes :
documentation et authentification doivent être les deux clés de voûte d’une API sécurisée.

2. Seul le contrôle des accès compte, les usages importent peu
Si des règles strictes d’authentification permettent de contrôler les accès à l’API, elles ne suffisent toutefois pas à en garantir pleinement l’intégrité. Il est également essentiel de contrôler, via un audit détaillé, la façon dont l’API est utilisée. D’abord pour disposer de données légalement exploitables en cas d’attaques malveillantes, ensuite pour garantir sa conformité avec les réglementations industrielles en vigueur. C’est particulièrement vrai pour les entreprises de secteurs sensibles, comme la santé ou l’énergie, où les contraintes réglementaires sont particulièrement fortes. Notons par ailleurs l’intérêt économique de connaître l’usage qui est fait d’une API au fil du temps …

3. Le protocole SSL a fait son temps
Les technologies évoluent et la tentation est grande de succomber à l’attrait de la nouveauté. Pour
ce qui est de la gestion des API, le protocole SSL a beau avoir de la bouteille, il n’en demeure pas
moins LA référence en matière de sécurisation des échanges. Ce n’est d’ailleurs pas un hasard si
une société comme Amazon, qui gère chaque mois des milliards d’interactions, n’autorise les accès à son API que via SSL. Et les nouveaux standards d’authentification, comme OAuth, doivent davantage être envisagés comme des compléments à SSL plutôt que comme des alternatives.

4. Rien ne vaut un système de sécurité maison
SSL, OAuth, OpenID, SAML, SW-Security et autre authentification HTTP : le nombre et la complexité des combinaisons et procédés possibles d’authentification poussent certains programmeurs à développer leurs propres systèmes de sécurité. Bien mal leur en prend, non seulement ils s’infligent une surcharge de travail, mais prennent aussi le risque de générer un système faillible. La moindre modification, aussi légère soit-elle, sur un standard existant, altère potentiellement l’efficacité – éprouvée – de celui-ci et expose l’API à des risques inconsidérés.

5. Sécurité et processus métiers ne doivent faire qu’un
Confondre logique métier et logique de sécurité n’est pas une aussi bonne idée qu’il y paraît. D’une
part parce que cela démultiplie les opérations de maintenance puisque tout changement dans les règles de sécurité a des répercussions sur les processus métier. D’autre part parce que cela peut impacter les performances de votre réseau tout entier. Avoir une plateforme séparée dédiée à la sécurité permet à l’inverse de préserver les performances de votre système tout en y ajoutant une couche de protection supplémentaire contre de potentielles attaques.

6. Une API n’est pas concernée par les menaces web traditionnelles
Il ne faut pas oublier qu’une API web est avant tout une application web et qu’à ce titre, elle est
exposée aux mêmes menaces que ses consoeurs : attaques en déni de service (DDoS), injections SQL, etc. Autrement dit, sécuriser une API implique de tenir compte non seulement des nouvelles menaces propres à l’API, mais aussi des attaques typiques et connues visant les applications web dans leur ensemble.

7. XML, JSON : on doit choisir le format de données le plus adapté
PC plutôt que Mac ? Chat plutôt que chien ? Bordeaux plutôt que Bourgogne ? XML plutôt que JSON ? En matière de formats de description de données, nos préférences personnelles ne doivent pas guider notre choix : il faut opter pour les deux ! Gérer à la fois du XML et du JSON permet de renforcer la sécurité d’une API en autorisant les interactions avec des API partenaires sans se soucier du protocole qu’elles utilisent.

Peut-il exister pire que la location de temps de cerveau chère à Patrick Le Lay ? Oui, l’intoxication des contenus « interactifs » offerts par le protocole HbbTV, affirment Yossef Oren et Angelos Keromytis de l’Université de Columbia.

Une fois de plus, il s’agit d’une menace visant le monde merveilleux de l’Internet des Objets, conduite une fois encore en mode « man in the middle », et visant un protocole très largement utilisé par, TF1, France 2, France 3, France 4, France 5, M6, ARTE, France ô, NRJ 12, ou i>Télé. Le succès de ce système est tout aussi important Outre Rhin, et le procédé tend à être adopté un peu de partout dans le monde.

De manière très sommaire, HbbTV est une fonction réservée aux téléviseurs de nouvelle génération, connectés, et permettant d’offrir au spectateur des informations complémentaires issues d’Internet durant le déroulement d’une émission, essentiellement des compléments Web utilisant des standards connus (XHTML, CSS, JavaScript). Las, le retour d’information (encapsulé dans un flux assuré par l’opérateur de broadcast ou celui se faisant passer comme tel), n’est plus corrélé avec le moindre contexte Internet… ce qui pose quelques difficultés pour authentifier le contenu de la réponse.

Techniquement parlant, expliquent les chercheurs, l’attaquant expédie sa requête via son propre émetteur DVB-T, autrement dit par la voie des ondes. Plus de détails techniques au fil de la communication universitaire d’Oren et Keromytis. Jusqu’à présent, les attaques visant les téléviseurs connectés utilisaient le chemin inverse, à savoir la connexion internet elle-même.

Comme il n’existe strictement aucun mécanisme de question-réponse entre l’émetteur TV et le récepteur, l’attaquant est quasiment certain de toucher ses cibles, et d’ainsi pouvoir injecter n’importe quel contenu à destination des téléspectateurs. Pour autant que les téléspectateurs utilisent réellement un tuner TNT, car l’attaque elle-même devient un peu plus compliquée à réaliser si la télévision utilise les services vidéo d’une « box » d’opérateur ou une liaison descendante de satellite.

Dénis de service, spam, manipulation d’opinion, injection de troyens d’exploration du réseau local de chaque spectateur… le champ d’exploitation de ce genre de hack est quasi illimité. Les parades possibles, en revanche, se limitent à une surveillance stricte des volumes des requêtes « montantes », afin de deviner une activité anormale. Ceci fait, une fois détectés les destinataires (et néanmoins victimes) de ces flux piratés, il devient facile d’établir une cartographie de l’ensemble des foyers touchés, et ainsi établir le barycentre sur lequel doit logiquement se situer l’émetteur TV utilisé pour l’attaque. Reste, font remarquer les deux chercheurs, que les capacités techniques nécessaires à cette recherche peuvent être également considérées comme une forme de flicage des contenus demandés par les spectateurs, donc à une atteinte à leur vie privée… rien n’est simple dès lors que l’on touche aux grands médias audiovisuels

Ajoutons (et l’étude Oren – Keromytis n’en fait pas mention ) que la majorité des récepteurs fonctionnant encore en réception hertzienne utilisent des antennes yagi, relativement directives, et bien entendu pointées en direction de l’émetteur local. Ce qui implique que l’émetteur pirate doit non seulement être situé peu ou prou dans la proximité dudit émetteur officiel (l’atténuation d’une yagi « hors lobe » dépasse rapidement les 10 dB), et est nécessairement capable de développer une puissance apparente rayonnée très supérieure à celle de l’émetteur officiel pour éviter tout risque d’hétérodynage. A moins que les pirates acceptent de restreindre leur attaque à l’échelle d’un quartier et, à l’aide d’un émetteur moins puissant, ne visent qu’un secteur de la zone couverte par la station officielle.

Tout ça ressemble donc fortement à une très belle analyse de risque « en chambre », pas franchement impossible à réaliser, mais hautement improbable compte tenu du rapport gain/infrastructure technique à déployer. La menace est en revanche tout à fait sérieuse dans le cadre d’une opération d’intoxication ciblée (genre spear phishing audiovisuel ne visant qu’un immeuble ou une personne), mais n’a, dans ce contexte, aucun caractère novateur. Le coup du « faux émetteur » est vieux comme le monde de la radiotransmission, et ce genre d’attaque par intoxication a même fait l’objet de plusieurs productions Hollywoodiennes, notamment l’Arnaque, avec Robert Redford et Paul Newman. Un peu de technologie « hype » ne change rien au principe d’insécurité qui caractérise tout système de diffusion « one to many » dépourvu d’un véritable protocole d’authentification en temps réel.

La règle définissant les mois pairs comme mois « fastes » en matière de correctifs I.E. est en passe de devenir lettre morte. Juin en apporte la preuve, avec ce colmatage de tellement de failles affectant Internet Explorer qu’il faut au bas mot 9 « pages écran » pour couvrir tous les CVE concernés. Dire que le correctif MS14-035 est critique frise plus l’humour absurde que l’euphémisme.

Jugées critiques également, ces quelques possibles exploitations à distance dans Microsoft Graphic et de sa rustine MS14-036 qui élimine 2 CVE. Les autres alertes sont simplement qualifiées d’importantes, notamment un risque d’attaque distante via Word, une fuite d’information par le biais des services XML, un déni de service par le truchement d’un paquet TCP forgé et une falsification dans le cadre d’une session RDP.

Chez Adobe, on signale la résolution de 6 CVE touchant Flash Player.

Chez Mozilla, sont signalées 10 CVE ( 7 colmatages) dans Firefox 30, beaucoup plus dans la version 29. L’absence de date précise pour ce qui concerne le traitement de chaque CVE rend difficile toute chronologie des correctifs pour le mois en cours.

Un an jour pour jour après la publication des toutes premières fuites concernant Prism, le « contrat de confiance NSA » qui liait les principaux éditeurs US à l’agence de renseignement, Microsoft demande une réforme des pratiques de la No Such Agency et réclame que les éventuels mécanismes d’écoute et de déchiffrement s’arrêtent aux frontières des Etats-Unis, nous informent nos confrères de Network World. Cette trop grande surveillance pourrait avoir des conséquences néfastes sur le business et la confiance accordée aux produits commercialisés par l’éditeur.

Aux frontières des USA, entendons par là que Microsoft tolère les écoutes de la NSA au-delà desdites frontières, et ne formule sa prière que pour ce qui concerne le territoire fédéral. Le fait de barbouzer les clients « étrangers » que nous sommes ne semble pas particulièrement impacter la confiance desdits clients. Après tout, lorsque plus de 98 % des outils diffusés dans le monde sont sous le contrôle de AOL, Apple, Dropbox, Facebook, Google, LinkedIn, Microsoft, Twitter ou Yahoo, on craint nettement moins les risques de désaffection au profit d’un concurrent mort depuis longtemps.

Deux communiqués successifs préviennent d’un grave défaut l’un dans OpenSSL, l’autre dans la bibliothèque de fonction GnuTLS. La première, portant l’immatriculation CVE-2014-0224, ouvre la voie à une possible attaque « man in the middle ». Ce problème serait endémique et remonterait au moins aux éditions datant de 1998. Le second trou, concernant GnuTLS, est référencé CVE-2014-3466, et appartient à la famille des buffer overflow. Peut en découler une exécution de code arbitraire en mémoire ou un crash système. Les nouvelles versions 3.1.25, 3.2.15 et 3.3.4 corrigent cette erreur précise le bulletin d’alerte.

Lorsque l’équipe de développement de Truecrypt a annoncé l’arrêt brutal du développement de cet outil de chiffrement multiplateformes, les pires suppositions ont fusées, tant dans la presse que sur les blogs. Suppositions d’autant plus alarmistes que la première phrase, marquée au fer rouge en tête de page, ne laisse place à aucun doute « WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues ». De là à se demander, par simple réflexe post-snowdenien, si ces « security issues », et plus particulièrement d’éventuels erreurs d’implémentations plus ou moins volontaires, n’auraient pas été provoquées.

Pourtant, comme le fait remarquer Hervé Schauer, au fil de sa lettre d’information mensuelle, Truecrypt a été audité maintes et maintes fois : une initiative de l’Open Crypto Audit, deux audits CSPN en France comme le rappel un communiqué de l’Ansi. Lequel Ansi, au passage, recommande la migration vers d’autres solutions de chiffrement, toutes « closed sources » et commerciales.

Pour l’heure, donc, Truecrypt doit être considéré comme relativement fiable, et si l’on ne craint pas d’être la cible des attentions particulières de la NSA, et il est urgent de ne pas paniquer. Particulièrement pour ce qui concerne les personnes exploitant différentes versions (Windows/Linux/OSX) du programme. Un fork Helvétique devrait permettre aux inconditionnels de ce programme open source de perdurer encore.

Il y a un peu plus de 4 ans, David et Robert Maynor s’offraient un émetteur-récepteur logiciel (SDR) et entamaient un long travail de fuzzing dans le domaine du sans-fil. Rien n’est gratuit. Car contrairement à une faille Heartbleed qui ne parvient à émouvoir qu’un tout petit cénacle de spécialistes du chiffrement, les hacks radio « parlent » aux oreilles de la presse, et touchent notamment la dernière marotte des politiques en mal de popularité : l’internet des objets. Et c’est donc sur le thèmes « objets interconnectés, avez-vous donc une RAM que je puisse exploiter » que Bob Graham s’interroge sur la divulgation (ou non) d’un exploit radio visant les stimulateurs cardiaques, alias pacemakers. Et de décrire par le menu ce drame cornélien du chercheur qui trouve, et dont la découverte (ou plus exactement la publication de sa découverte) pourrait avoir pour conséquence extrême la mort de porteurs de ce genre d’appareil.

Outre le fait que ce genre de travaux s’opère généralement « en chambre », avec des niveaux de puissance ridicules, des distances de liaison se comptant en décimètres, et une totale absence de tests « grandeur réelle » en milieu urbain perturbé et à grande puissance/distance, on peut se demander si ce genre d’introspection blogo-sécuritaire ne frise pas la provocation. Certes, le domaine médical, à l’instar du secteur de l’automatisme industriel, a vécu, des années durant, avec l’absolue certitude que les techniques touchant à la radioélectricité relevaient de la sorcellerie et de la haute technologie, « inaccessible au commun des mortels ». Une forme de sécurité par l’obscurantisme en quelques sortes. Mais pour ce qui concerne le choix éthique du chercheur (dois-je ou ne dois-je pas communiquer le résultat de mes recherches à l’occasion d’une conférence technique telle que la DefCon), la question peut-elle sérieusement se poser ? Pour quelle raison existerait-il deux poids, deux mesures, entre le monde logiciel et le monde médical ? Le « full disclosure » raisonné, avec communication préalable auprès des éditeurs, correction des bugs puis divulgation après un laps de temps nécessaire au déploiement de correctifs est devenu une quasi-norme de nos jours. Tout comme est devenue une quasi-habitude le fait de rémunérer correctement les chercheurs ayant fait l’effort de découvrir et d’analyser une faille de sécurité. Que la cible soit un instrument médical ne change rien à l’affaire. A moins… à moins que cette industrie n’ait pas coutume de raisonner en termes de « fenêtre de vulnérabilité », de « calendrier de correction », de « campagne de déploiement de correctifs »… ou de barème publié de « bug bounty ».

Et c’est peut-être là le principal iatus.

Lorsqu’en 2009 Alex Sotirov, Dino Dai Zovi et Charlie Miller ont, à l’occasion de CanSecWest, entamé leur campagne « no more free bugs », ils s’adressaient à une profession d’éditeurs directement impliquée dans le développement de logiciels et firmwares. Langage d’informaticiens pour des informaticiens. Aujourd’hui, ce discours peut-il être entendu par les industries de l’automatisme, du contrôle de processus, de l’équipement médical, des équipementiers de la grande distribution, des secteurs financiers, automobiles, aéronautiques ? … Bref, de tous ceux qui, sans appartenir au monde du développement logiciel, développent leurs propres programmes ? Et lesdits industriels seront-ils enclins à récompenser ces chercheurs en cas de découverte d’un bug majeur, sans considérer ladite recherche comme une tentative de racket ?

La véritable question que pose Robert Maynor va bien au-delà du simple problème du full disclosure or not full disclosure. Elle interroge l’ensemble des secteurs d’activités qui, par un biais ou par un autre, ont numérisé leurs outils et applications, et n’ont pas toujours pris en compte la dimension infosec. Ni budgétisé les coûts induits… remerciements aux chercheurs y compris. Un « à votre bon cœur » qui s’annonce avec un hack de pacemaker, voilà qui atteint des sommets lacaniens.

Comme chaque année, la Nuit du Hack (28 au 29 juin) succède immédiatement au cycle de conférences Hack in Paris (23-27 juin ). 12 conférences, 10 ateliers techniques se tiendront durant toute la durée du traditionnel concours de hacking informatique (CTF). Comme les années précédentes, cette manifestation ouverte à tous, se déroulera dans l’enceinte d’Eurodisney, du 28 au 29 juin prochain. Rappelons que la conférence Hack in Paris, destinée aux professionnels de la sécurité, aura lieu les jours précédents, du 23 au 27 juin, même lieu. Les inscriptions seront possibles jusqu’au jour d’ouverture.

Deux nouveautés en 2014. Une chasse au bug dotée d’un montant de 5000 euros est proposée par la société Qwant. Et surtout, dès potron-Minnie (de 10H à 18 H) se déroulera la NDH Kids, parrainée par l’Esiea. Les hackers de 8 à 16 ans suivront les traces de Géo Trouvetou, un éventail d’ateliers les attend. Une source occulte et généralement digne de foi nous laisse entendre que l’on attend une invasion de dominoux.

Tout comme l’an passé, sous la double casquette CNIS Mag/Electrolab, notre équipe animera deux ateliers techniques sur les principes du « software defined » et sur l’instrumentation de précision dans le domaine des mesures électriques et radioélectriques.

La base de données clients de eBay a été « intrusée », laissant sans défense près de 145 millions de possesseurs de comptes inscrits sur ce site d’e-commerce. L’attaque, précise le communiqué US, a été rendue possible grâce au vol préalable d’identifiants d’employés de l’entreprise. C’est donc via le réseau interne que s’est perpétré le vol massif.

Le communiqué en langue française, en revanche, est un peu plus inquiétant. Il précise notamment « Pensez à utiliser des mots de passe différents pour tous vos sites et tous vos comptes. Si votre mot de passe est identique, prenez le temps de le changer partout ». Ce qui, sur le coup, semblait indiquer assez clairement que les hash des mots de passe n’étaient pas salés. Car, à moins de vouloir faire passer un message subliminal, à quoi d’autre pourrait bien servir un « conseil en matière de sécurité informatique » émis de la part d’une entreprise qui n’a pas su garantir ladite sécurité. Et ce malgré les formules émaillant le début du communiqué telles que « Nous accordons une importance primordiale à la sécurité de notre site ».

Une simple analyse des habitudes d’usage tend à prouver que la majorité des clients des grands sites marchands (eBay parmi tant d’autres) utilisent les mêmes identifiants et mots de passe avec les services de payement en ligne, Paypal notamment. Si l’hypothèse du non-salage des hash stockés par eBay se confirme, les usagers devront en priorité surveiller l’activité de leurs comptes et redoubler de méfiance envers tout email de phishing visant à récupérer les codes CVV.

1 juillet 2014, Rendez-vous à l’Intercontinental Paris Avenue Marceau

Entreprise Mobile, Sociale et dans le Cloud

Nouvelles Vulnérabilités et Cybermenaces : comment assurer sa cybersécurité ?

Conseils & Solutions

Cliquer ici pour : S’inscrire en ligne à la matinée Sécurité

Un thème récurrent qui a encore toute sa place face à l’ouverture du SI. La tendance à la consumérisation des outils de travail, au Bring Your Own Device, au BYO ID dorénavant, l’utilisation intensive des réseaux sociaux dans le business, l’ouverture du SI aux partenaires et fournisseurs sont autant de nouvelles préoccupations en termes de sécurité pour la DSI sans compter l’employé désormais mobile. Quels risques ? Quelles menaces ? Comment se défendre ? Etat de l’art des vulnérabilités potentielles et conseils et solutions.

Exceptionnellement afin de fêter la trêve estivale, à l’issue de cette matinée, autour d’un verre de champagne nous procéderons à un tirage au sort avec à la clé le Nouvel ipad et d’autres tablettes sous Android à gagner.

Où ?

CNIS Event a choisi un endroit en plein cœur de Paris, à deux pas des champs Elysées et de l’Arc de Triomphe. A deux pas des endroits business les plus stratégiques de Paris (Porte Maillot, Palais des congrès, La Défense…) comme facile d’accès pour ceux de l’extérieur qui viennent tout spécialement assister à la matinée CNIS Event (aéroports Orly et Roissy, accès aisé aux trains grandes lignes via la station de RER Charles de Gaulle-Etoile à proximité, parking).

InterContinental Paris avenue Marceau
64, avenue Marceau,
75008 Paris
Tél : +33 (0)1 44 43 36 36
Pour s’y rendre : métro George V (ligne 1), RER Charles de Gaulle-Etoile (Ligne A),Bus Arrêt Bassano (Ligne 92 Porte de Champerret – gare Montparnasse), parking 75 avenue Marceau, Paris 8

Pour qui ?

Les Responsables sécurité, les DSI, les décisionnaires d’une façon générale que ce soit de l’infrastructure ou de l’entreprise en ce qui concerne les PME-PMI, les CIL, les avocats et juristes de l’entreprise, les consultants bien entendu. Tous sont concernés par la question des changements d’habitudes sociétales qui ont permis de faire entrer dans le système d’information les réseaux sociaux, la consumérisation des équipements et ce, en plus de la mobilité des employés quand ils ne travaillent pas de chez eux … Il faut connaître et comprendre à qui, à quoi on a à faire pour pouvoir envisager et organiser la protection de son système d’information. Un discours d’expertise et de sensibilisation qui concerne tout le monde.

Cliquer ici pour : S’inscrire en ligne à la matinée Sécurité

Agenda

• • 8H30 – Accueil des participants : petit-déjeuner et Networking
  • 9H00 – Vulnérabilités et cybermenaces des SI Modernes, Frédéric Connes, expert sécurité chez HSC ,
  • 9H20 – Expertise sécurité, retour terrain de Sourcefire/Cisco
  • 9H40 – Conseils, guide et expertise, par Chadi Hantouche du Pôle Sécurité Solucom 
  • 10H00 – Expertise sécurité, retour terrain par un spécialiste NTT Security/Checkpoint
  • 10H20 – Panel sur « Entreprise Mobile, Sociale et dans le Cloud : Comment assurer sa cybersécurité ?» avec un avocat qui abordera la partie juridique, Justin Ganivet, Consultant sécurité Lexsi qui nous parlera de son vécu terrain et de ses solutions, un consultant pour la stratégie, Patrick Duboys, à la tête d’une statut-up qui parlera de sécurisation des identités et des échanges numériques , Médéric Leborgne, Directeur Technique Blackberry nous parlera de l’ouverture de la plateforme d’administration à toutes les tablettes et PDAs du marché. Animé par un analyste ou un journaliste IT
  • 11H00 – PAUSE Networking
  • 11H20 – Retour terrain mise en oeuvre de la Sécurité au sein d’une entreprise moderne, par CEIS
  • 11H40 – Retour Terrain : expertise sécurité par un spécialiste du marché
  • 12H00 – Minute Juridique : les impacts juridiques du SI moderne par Maîtres Olivier Itéanu et Garance Mathias
  • 12H20 – Tirage au sort de Tablettes (Nouvel Ipad & tablettes Android, Samsung et co.) autour d’un verre de champagne
  • 13H 00– Clôture de la conférence