Keyrus

Keyrus

• Administration of more than 300 physical and virtual servers on Hyper-V and VMWare
• Ensured availability and performance of network applications
• Troubleshooting network problems
• IT security
• Architecture planning and implementation of new systems
• Planning for system migration
• Manage Active Directory, Exchange, and other applications
• Optimization of the IT environment
• Technology Update
• Backup management
• Support for development teams
• Control of IT equipment
• Preparation of workstations
• Inventory management of IT equipment
• Participation in new projects and systems implementation
• IT support for more than 100 employees • Managing SSL Certificates

Thomas Sabo

Thomas Sabo

• Administration of physical and virtual servers on Hyper-V
• Creating a new network with Windows Server 2012 R2
• Active Directory, DNS, DHCP, IPv4, and IPv6
• Installing and Configuring Microsoft Lync 2013
• Migrating from Exchange 2010 to Exchange 2013
• Installing Sage ACCPAC Accounting Software
• Data monitoring and network security
• Installation of workstations
• IT support for more than 80 employees
• Deployment of Hoëltl POS across Canada
• Advisor for Google AdWords (PPC)
• Windows Server 2003, 2008, 2012 / R2, XP, Vista, Windows 7/8 / 8.1
• Microsoft SQL Database Management 2005/2008/2012
• IP cameras and surveillance equipment
• Electronic access control
• Network printers, scanners and fax machines
• Network attached storage (NAS)

Quebecor

Quebecor

Migration of Archambault systems to Renaud-Bray following the sale of this division by Quebecor.
Segregation of Archambault’s AD, applications and data from Quebecor’s infrastructure.
Systems integration at Renaud-Bray.

• Administration of 993 physical and virtual servers
• Responsible for the migration of Archambault systems to Renaud-Bray
• GardaWorld Security Clearance Level 5
• Access to datacenters across Quebec
• MPLS Network
• Active Directory (2003, 2008R2), DNS, DHCP, IPv4, and IPv6
• Hybrid phone system (Nortel, Avaya)
• Exchange 2007, 2010, 2013
• TSM Tivoli Storage Manager (physical and virtual environment backups)
• Data monitoring and network security
• IT support for hundreds of employees
• Windows Server 2003, 2008, 2012 / R2, XP, Vista, Windows 7/8 / 8.1
• Microsoft SQL Database Management 2005/2008/2012
• Fiber Channel SAN storage Promise Vtrak, IBM V7000 and Tivoli
• iSCSI Clusters
• Sun Microsystems Blade Servers
• IBM AS400
• CentOS 6.5, 7, XEN, Nginx
• VMware ESXi v4.1 and v6
• Blackberry Enterprise Server
• Nagios infrastructure monitoring
• IP cameras and surveillance equipment
• Electronic access control
• Network printers, scanners and fax machines
• Segregation of data

Le SIEM, une garantie majeure pour sécuriser vos réseaux ?

Le SIEM, une garantie majeure pour sécuriser vos réseaux ?

Interview de Cyrille Aubergier

Un SIEM (Security Information and Event Management) a pour objectif de collecter et d’analyser tous les évènements de sécurité et d’en générer à la fois des rapports et des tableaux de bord. Le but est donc de surveiller les réseaux en temps réel pour améliorer leur sécurité. Expert en analyse de logs et des processus opérationnels de sécurité, Cyrille Aubergier revient sur les principaux enjeux du SIEM.

Quels sont selon vous les principaux critères de choix d’un bon SIEM ?

Quels que soient les SIEM, il n’existe pas entre eux de différences fondamentales. Leurs fonctions principales restent la collecte et l’analyse des logs, puis la génération de rapports et de tableaux de bord.

Toutefois, les trois points importants sur lesquels doivent se porter l’attention sont, selon moi :

  1. Le mode de licence : s’il est inadapté au nombre d’équipements, d’IP et de mégabits, la complexité et le coût peuvent devenir bloquants dans certains cas.
  2. Le potentiel de personnalisation et d’évolution du SIEM me paraît aussi déterminant. Un SIEM doit être capable par exemple de customiser des agents de collection de logs. Il doit aussi être en mesure de recevoir des logs d’application ou des notifications d’évènements à partir d’équipements développés en interne. Les rapports et tableaux de bord doivent être eux aussi personnalisables.
  3. La rapidité des mises à jour me semble enfin essentielle, puisque les anti-virus et les sondes de détection ont besoin d’être fréquemment mis à jour. De fait, le SIEM doit pouvoir l’être aussi.

Quelles sont les erreurs les plus fréquemment commises au moment d’installer un SIEM ?

Il ne faut pas se contenter d’installer un SIEM avec les configurations du constructeur et/ou par défaut, car elles ne sont souvent pas suffisantes. Les configurations doivent être personnalisées et adaptées aux besoins des utilisateurs. Il ne faut pas non plus penser que les rapports initiaux suffisent. Il faut créer ses propres rapports d’analyse, adaptés aux différentes menaces identifiées.

Une autre erreur fréquente est de mal anticiper la taille des données, que ce soit pour le stockage ou pour l’exploitation des bases de données. En effet, une base de données mal construite ou insuffisamment rapide restera à bien des égards inexploitable.

Un inventaire insuffisant des équipements sera aussi gênant. Ce serait clairement une erreur de ne pas assigner suffisamment de ressources à l’analyse des rapports et à la personnalisation de la détection de la menace. A cet égard, sur une base de 24/7, une équipe de 10 personnes me paraît nécessaire. L’équipe doit se répartir entre la recherche des accidents, la gestion des configurations et la recherche d’analyses.

Ensuite, l’activation des logs vers le SIEM doit impérativement faire partie des procédures de déploiement de n’importe quel équipement. Dès qu’un nouvel équipement ou un nouveau service est mis en place, ses logs doivent être envoyés vers le SIEM.

Comment améliorer la détection d’attaques dans un SIEM ?

Généralement, un tableau de bord de sécurité regroupe des équipements par fonction et périmètre. Par exemple, un tableau de bord peut regrouper tous les pare-feux entre Internet et l’interne. Pour renforcer la détection, l’idéal est de créer un tableau de bord centré sur la menace, en fonction d’une analyse de risque clairement définie. Il faut alors faire un focus sur une alerte spécifique, en listant les équipements qui vont fournir des logs selon un scénario d’attaque.

Il est possible également de réajuster les seuils de détection selon le nombre d’itérations dans une période de temps donnée. L’assignation de ressources dédiées à l’analyse et à la remise de rapports réguliers me paraît également utile.

Il est aussi possible de créer des nouvelles alarmes temps réel, basées sur un indice de compromission ou d’activité suspicieuse. Cela permettra à l’opérateur d’activer certaines fonctionnalités comme la capture du trafic ou bien d’initier de nouveaux indices adaptés à chaque fonctionnalité.

Quels sont les bénéfices d’un SIEM en termes de ROI ?

Le coût initial est souvent un frein au déploiement d’un SIEM, mais il est pleinement justifié car le fait de rassembler les logs des équipements sous une équipe unique en 24/7 permet d’économiser des ressources en termes d’analyse de logs et de rapports. Cela permet aussi d’exploiter pleinement les équipements, puisqu’on contrôle en temps réel leur bon fonctionnement. De plus, les rapports, une fois classés et analysés, renforcent l’analyse globale des évènements liés à la sécurité. Ils permettent d’intervenir en cas de mauvaise configuration de l’équipement, ce que tous les exploitants ne font pas, souvent par manque de temps ou de connaissances.

Il est possible par ailleurs de mutualiser les coûts en utilisant le SIEM sur des fonctions annexes. Par exemple :

  • l’inventaire des équipements ;
  • l’archivage de données pour des raisons régulatrices,
  • les réponses aux audits de compliance,
  • la surveillance de la disponibilité d’un équipement.

De manière générale, l’apport des SIEM est de constituer une garantie contre les désastres en matière de sécurité. Un SIEM est le seul outil qui permet réellement de comprendre ce qui se passe dans un réseau : il vous en donne l’état et le pouls. De ce point de vue, le gain est majeur !

Organisation, ingéniosité et curiosité : les trois qualités du gestionnaire de SIEM

Organisation, ingéniosité et curiosité : les trois qualités du gestionnaire de SIEM

Un SIEM (Security Information and Event Management) a pour objectif de collecter et d’analyser tous les évènements de sécurité et d’en générer à la fois des rapports et des tableaux de bord. Le but est donc de surveiller les réseaux en temps réel pour améliorer leur sécurité. Après une première interview consacrée aux enjeux du SIEM, Cyrille Aubergier, expert en analyse de logs et des processus opérationnels de sécurité, explique comment gérer le SIEM au quotidien pour bénéficier de tout son potentiel de sécurité.

Comment mesure-t-on l’efficacité d’un SIEM ?

Dès lors que le SIEM a pour fonction de collecter le plus d’informations possible (tout équipement qui détient des informations de log peut l’envoyer au SIEM), plusieurs indicateurs permettent de mesurer  l’efficacité du SIEM. Je pense notamment aux statistiques suivantes :

  • le nombre moyen d’événements d’incident détectés ;
  • le rapport entre le nombre d’incidents ouverts et fermés ;
  • le rapport entre le nombre d’événements « parsés » (c’est-à-dire qui sont connus) et non parsés ;

Il est également judicieux d’identifier les ressources utilisées par les différents équipements pour déterminer si elles sont toujours en activités et quels sont les évènements pris en compte par  le collecteur de log.

Au-delà de toutes ces données, l’analyse des courbes de reporting générées par le SIEM demeure le principal outil de mesure de l’efficacité du SIEM. Les tableaux mis à disposition sont par nature assez vivants (ça monte, ça descend) et permettent d’identifier clairement  les raisons pour lesquelles, semaine après semaine, on observe des pics, des chutes, ou a contrario une forme de stabilité. A cet égard, il importe de mener des périodes d’analyse sur 1, 3 et 12 mois afin d’identifier clairement les tendances et analyser l’efficacité du SIEM sur la durée.

Combien de temps dure la phase de stabilisation ?

Cela dépend de la taille du réseau. Cela peut prendre un an sur un réseau hétérogène et étendu. Cette durée est indispensable pour comparer entre eux des logs sur une période donnée en rapport avec la même période de l’année précédente (un samedi de juillet 2014 avec le même samedi de juillet 2015 par exemple). Cette phase peut paraître longue, mais elle reste le meilleur moyen d’éliminer les bruits parasites et disposer des informations de sécurité les plus utiles et efficaces.

Quelles sont les erreurs les plus fréquemment commises dans la gestion des logs de sécurité ?

La première erreur consiste à ne pas surveiller suffisamment les équipements qui ne génèrent plus d’évènement. Il arrive en effet que certains équipements arrêtent de fonctionner et n’émettent plus d’alerte : c’est la pire des choses pour une SIEM. Ce défaut d’alerte provient souvent d’une mauvaise configuration des équipements. Il arrive aussi que la fonction de l’équipement qui envoie les logs ait tout simplement craché. Je pense aussi aux changements de configuration sur un parefeux, voire sur le système lui-même pour qu’il envoie les logs… Pour toutes ces raisons, il arrive que des équipements deviennent silencieux. Il est donc essentiel de les garder sous surveillance.

Il arrive aussi que des équipements communiquent énormément. Du coup, un silence prolongé, parfois d’une heure à peine, constitue en soi une alerte et peut signaler un problème. Il faut également surveiller les nouveaux équipements, ainsi que les opérations de mises à jour des équipements. Enfin, là aussi, l’analyse des données et des tableurs, appelés aussi baselinning, reste essentielle et ne doit pas être mise de côté au profit de la gestion des incidents par un membre du SOC.

Quelles sont les qualités requises pour gérer un SIEM ?

Un membre du SOC doit témoigner de trois qualités essentielles : l’organisation, l’ingéniosité et surtout la curiosité.

L’organisation, parce que ça prend du temps de faire une recherche, de fouiller une base de données… Il faut être efficace pour lancer plusieurs recherches à la fois et aller directement au but. Il faut donc établir un bon équilibre entre l’analyse pure et dure, la consultation des rapports et la gestion des incidents.

L’ingéniosité et la curiosité sont également indispensables : il faut avoir envie d’apprendre et vouloir comprendre.

Enfin, l’expérience reste bien sûr très importante. Il n’est pas nécessaire pour autant d’avoir une forte expérience sur les fonctions sécurité, car elle peut être compensée par une expérience dans le domaine des applications, des équipements de passerelles, etc.  Chaque équipement dispose de logs de sécurité, si bien chaque type d’expérience demeure parfaitement utile.

Quels sont les prochains défis qui s’imposent aux SIEM ?

Les SIEM sont appelés à collecter de plus en plus d’informations et à multiplier les sources : en plus des syslog, il faut tenir compte des snmp, du netflow, et des autres applications qui peuvent potentiellement générer des alarmes.

A l’avenir, il faudra également mettre en corrélation des règles d’alerte avec de nouvelles sources d’événements, comme les événements de sécurité provenant d’applications ou de bases de données. Il faudra aussi corréler les événements de type réseau/sécurité avec les événements d’anomalie des serveurs ou des bases de données. Il n’existe pas aujourd’hui d’analyse corrélée de tous ces événements. Par exemple, l’interrogation intense d’un serveur SQL constitue un indice de compromission, mais pas une preuve. De même, un événement signalant des connexions avec un serveur à partir de droits différents constitue lui aussi un indice, mais pas une preuve. En revanche, une fois corrélés entre eux, les deux évènements forment une alarme qu’il faut surveiller.

Il faut donc répertorier et rapprocher entre eux tous les éléments de sécurité et toutes les anomalies détectées, qu’ils viennent des serveurs, des applications ou des réseaux. Cette mise en corrélation est très peu effectuée aujourd’hui, car les domaines d’expertise restent souvent séparés. Une distinction est établie de fait entre l’expert qui comprend les anomalies de fonctionnement d’une base de données et celui qui comprend les anomalies de sécurité sur un réseau.

Un bon gestionnaire de SIEM doit donc disposer de l’ensemble de ces compétences, mais aussi et surtout faire preuve de logique et d’organisation pour croiser efficacement les données et surveiller plusieurs équipements différents.

Enfin, à l’avenir, il faudra également être en mesure de conserver le plus grand nombre possible de données,  et ce le plus longtemps possible. Cela permettra à la fois de mener des enquêtes sur les événements passés et d’identifier d’éventuelles failles dans les procédures de surveillance en temps réel. Cela passe en outre par une amélioration de la gestion des bases de données qui contiennent les événements de sécurité. Il faudra les rendre plus performantes et plus facilement interrogeables afin de gagner du temps.

Du bon usage des logs de sécurité

Du bon usage des logs de sécurité

La magie du SIEM (enfin) révélée

Connaitre l’état de la sécurité d’un système d’information requiert bien souvent la mise en place d’un outil de gestion de ses évènements. Depuis les règles de collecte des évènements de sécurité jusqu’à la mise en place d’un indicateur hebdomadaire de niveau de la sécurité, voici une méthode pour monter un tableau de bord qui pourra s’appliquer à une nouvelle infrastructure ou une infrastructure existante.

Appelé SIEM pour « Security Information and Event Management », SEIM (« Security Event Information Management »), SEM (« Security Event Management ») ou simplement SIM (« Security Information Management »), cet outil a pour ambition de traiter les nombreux évènements générés par les composants d’un système d’information. Il doit aussi assurer les principales fonctions de traitement suivantes :

  • collecte des évènements
  • agrégation des évènements
  • corrélation des évènements
  • reporting des évènements
  • archivage des évènementsNe pas établir un niveau de sécurité, ne pas analyser les évènements de sécurité, leur évolution et leurs caractéristiques, revient à ne pas maîtriser son infrastructure réseau
  • Les évènements (logs ou alertes) de sécurité sont en effet parmi les seules informations qui permettent à la fois de mesurer le niveau de sécurité, de détecter d’éventuelles menaces et d’enclencher les éventuelles actions à entreprendre, le tout en temps réel ou pas.

Mise en place d’un tableau de bord

Outre les besoins de contrôle de conformité, de rétention légale ou d’analyse post-mortem, la supervision à des fins de détection d’une menace passe par les modules suivants :

  • analyse des évènements,
  • corrélation des évènements
  • alertes en temps réel et/ou rapports programmés
  • Nous excluons ici toutes les fonctions complémentaires que pourrait apporter un outil d’analyse de logs, comme les fonctions d’inventaire de parc, de gestion de tickets d’incident ou autre rétention d’information à des fins d’archivage règlementaire.

Un SIEM n’est pas autonome

Malgré tous les efforts marketing des éditeurs, il est important de savoir qu’un SIEM ne fonctionne pas tout seul. Les mécanismes d’extraction syntaxique d’informations à partir d’un événement collecté ne s’avèrent pertinents que s’ils se basent sur des grammaires déjà connues.

Les agents de collectes proposés par les SIEM ne s’appuient effectivement que sur une partie des informations qu’ils ont jugées intéressantes d’un point de vue de la sécurité.

Selon qu’il s’agisse d’évènements issues d’un équipement passif avec peu de fonctionnalités comme un boitier VPN ou d’un équipement très utilisé avec des fonctionnalités avancées comme un serveur proxy, le nombre d’événements de sécurité intéressants à collecter ne sera pas le même :

  • d’une part, les agents de collecte ne connaissent pas les particularités de votre réseau pour y trouver des informations pertinentes,
  • d’autre part, ils ne connaissent pas non plus tous les équipements et la manière dont ces derniers organisent l’information dans leurs logs (par exemple, équipement Huawei).

Exhaustivité de l’analyse

Il est donc nécessaire de mettre tout d’abord en œuvre une méthode d’analyse structurée, de la définition des informations à collecter jusqu’à l’élaboration des tableaux de bord finaux, en passant par la mise en place, nous le verrons, de niveaux de référence.

À titre d’exemple encore, pour un routeur Cisco dont la fonction est de simplement aiguiller le trafic, il y aura peu d’événements à collecter. À l’inverse, une passerelle Internet, proposant de multiples fonctions comme un pare-feu, un composant de filtrage d’URL ou un antivirus, produira en comparaison une multitude de fichiers de journalisation et donc d’évènements à collecter.

De plus, les équipements évoluent constamment ainsi que les logs générés. Il est donc nécessaire d’analyser cette évolution des logs afin d’accroitre les évènements considérés comme pertinents pour la sécurité (cas de journaux Windows ou de sondes IDS).

Inventaire des sources

La première étape consiste à lister l’ensemble des équipements qui constitue les sources des évènements ou logs. Sources qui seront de plus en plus nombreuses, car selon le SANS Institute, une nouvelle génération de SIEM, appelés « SIEM v2 » se concentre sur la collecte la plus vaste possible d’informations, ne se basant plus uniquement sur des informations issues des syslogs, mais aussi netflow ou SNMP par exemple.

Cette volonté d’étendre à l’infini la collecte d’informations est sans doute tout autant liée à la baisse des coûts de stockage et de temps-machine (CPU) qu’à l’optimisation du fonctionnement des bases de données et autres moteurs internes des SIEM.

Nous commencerons donc ici notre projet avec un nouvel équipement de sécurité à introduire dans l’infrastructure de notre système d’information.

Préparation de l’analyse

La collecte des données événementielles brutes s’effectue soit par une extraction directe de logs provenant de l’équipement, soit par la réception de ces logs par un agent déjà configuré sur notre environnement.

Le volume de données sera sans doute proportionnel au nombre de fonctionnalités qui sont déployées sur l’équipement. Cependant, par expérience, pour qu’une analyse soit pertinente, il faudra collecter au moins 10.000 évènements chaque jour.

Munis de ces évènements, il vous sera à présent utile de disposer :

  • de la documentation du fournisseur ou éditeur de l’équipement fournissant les logs
  • d’un éditeur de texte permettant de manipuler des chaines via des expressions régulières (ex : « EditPad Lite 7 »)
  • d’un tableur bureautique (ex : Microsoft Excel)Analyse syntaxique par élimination
    Les logs ou évènements doivent à présent être analysés manuellement. Pour cela, nous allons devoir les classer par catégories :
  • les logs non nécessaires ou incomplets,
  • les logs relatifs à l’administration de l’équipement,
  • les logs relatifs à la disponibilité de l’équipement,
  • les logs relatifs aux services assurés par l’équipement (ex : journaux de connexions dans le cas d’un serveur proxy).
  • On peut utiliser la documentation de l’équipement, l’information de catégorisation (facility level) pour définir le modèle de reconnaissance (appelés aussi « patterns ») qui va différencier ses logs des autres.

Exemples de chaine de caractère : « %ADMIN% », « %PROXY% » ou encore « %AAA% »).

Les évènements à rejeter et à conserver

Un certain nombre d’évènements sont à rejeter, car ils sont :

  • sans lien avec des informations propres à la sécurité,
  • insuffisamment explicites,
  • non utilisables par des mécanismes de corrélation,
  • non utiles pour l’élaboration des rapports finaux.
  • Exemples de logs non suffisants :

Exemples de patterns de logs à conserver :

  • les évènements ayant en commun la chaine de caractère (Authentication, Authorization, Accounting),
  • les évènements de connexion/déconnexion ayant en commun la chaine de caractère (Network Address Translation).

Création d’un dictionnaire d’évènements

Pour chaque évènement que nous décidons de conserver ou rejeter, il nous faut à présent créer une expression régulière qui va correspondre à tous les événements de ce type, et enregistrer cette expression dans un document de travail avec notre tableur.

Pour le moment, notre document de travail liste les types d’évènements, la décision associée de conserver ou rejeter, et leur associe une étiquette (par exemple, « REJECT001 » pour le 1er type de logs à rejeter).

Pour les évènements conservés, il sera nécessaire de fournir plus d’informations :

  • nom de l’élément : il doit être le plus explicite possible en indiquant si possible le type de log concerné (exemple: « CISCO-CUST_1001_BAD-AUTH »),
  • pattern de correspondance (.*Login/sAccepted\s :% 1.*),
  • numéro d’alarme unique (tel qu’associé dans le SIEM),
  • sévérité de l’alarme (telle qu’associée dans le SIEM. Elles sont en général basées sur la sévérité mentionnée dans le syslog),
  • données récupérées par le pattern (exemple : « user=$1|srcip=$2|srcport=$3|destip=$4|destport=$5 »),
  • action à entreprendre (par exemple, générer un email),
  • commentaires (indications pour les futures règles de corrélation).Implémentation des collecteursAu final, notre agent de collecte va utiliser au moins quatre groupes de règles :
  • En vertu du principe des vases communicants, toutes ces règles de syntaxe doivent être appliquées dans l’agent de collecte du SIEM en plus des règles existantes.
  • L’utilisation d’une convention de nommage s’avère très puissante. Par exemple : « DEVICETYPE_ALARMTYPE_ALARMID_DETAILS ».
  • les règles « custom reject »,
  • les règles fournies par le SIEM,
  • les règles « custom »,
  • les règles « catch all rules » (tout ce qui n’est pas parsé).Une fois les évènements collectés et analysés, il reste à les intégrer dans un tableau de bord. Celui-ci sera fonction d’un périmètre souhaité. Par exemple :
  • Tableaux de bord
  • un tableau de bord pare-feu du réseau interne pour les évènements de sécurité associés (leurs logs vont être regroupés ensemble puisqu’ils font face aux mêmes niveaux de menace),
  • un tableau de bord « Authentication, Authorization, Accounting » pourra être construit à partir de l’association de l’ensemble des évènements de type « AAA », quels que soient les équipements sources.

Figure 3 : Exemple de tableau de bord : flux IP de l’entreprise

Intégration et surveillance

Au final, l’intégration passe par la création de règles d’analyse syntaxique dans les agents de collecte, la définition des alarmes (avec leurs sévérités, les actions à prendre,…) et la création ou la mise à jour de rapports programmés. Ce travail est accompli pour chaque nouvel équipement ou chaque nouvelle alarme créée.

Il est également important de mettre en œuvre une procédure d’analyses régulières de chaque rapport par les équipes du SOC (Security Operations Center) :

  • analyses quantitatives (nombres d’événements),
  • analyses qualitatives (sévérités des événements).Chaque évènement non classifié devra également être analysé pour classement éventuel dans les catégories « à rejeter » ou « à conserver ». Ces analyses peuvent être aussi longues que le réseau est complexe.
  • Mis à part les alarmes générées en temps réel, cette revue hebdomadaire permettra dans un premier temps de supprimer les « bruits » jusqu’à atteindre un niveau de stabilité qui permette de détecter des évènements de sécurité peu verbeux.
Comment votre entreprise peut se prémunir contre la cyberfraude ?

Comment votre entreprise peut se prémunir contre la cyberfraude ?

Chaque année, le nombre de victimes de la cyberfraude augmente. Il faut dire que les pirates informatiques ont recours à des moyens de plus en plus sophistiqués. Quelles sont leurs tactiques les plus fréquentes vis-à-vis des entreprises, et comment peut-on s’en protéger ?

Selon les dernières données du Centre antifraude du Canada, pas moins de 78 millions de dollars auraient été dérobés en 2014, et environ 42 200 plaintes auraient été déposées, essentiellement pour hameçonnage (phishing).

 

Cette technique consiste pour le fraudeur à faire croire à la victime qu’elle s’adresse à une institution de confiance, sa banque par exemple, afin de lui soutirer des renseignements personnels comme ses mots de passe, ses numéros de carte de crédit, etc.

 

Il est difficile d’obtenir des données concernant la cyberfraude contre les entreprises, car il existe une certaine culture de non-divulgation à ce sujet. Néanmoins, on sait que les sociétés n’échappent pas aux stratagèmes des criminels du Web qui tentent de leur dérober des montants d’argent ou des informations sensibles.

 

Des tactiques éprouvées par les fraudeurs

 

Quelles sont les stratégies fréquemment utilisées par les cyberfraudeurs pour prendre des entreprises dans leurs filets ? « Ils ciblent généralement une personne précise au sein de l’entreprise, le directeur financier par exemple », explique Cyrille Aubergier, chargé de cours sur le piratage informatique au certificat en cyberenquête de Polytechnique Montréal, également expert sécurité chez Orange, anciennement France Telecom.

 

Le criminel informatique tente ensuite d’introduire un programme malveillant, communément appelé malware, dans l’ordinateur de cet employé, par l’intermédiaire d’un lien Internet ou d’un fichier contenu dans un courriel. Le malware effectuera alors de la recherche et de la collecte d’informations (coordonnées bancaires, numéros de compte, noms des responsables financiers avec les signatures, etc.) et fouillera l’historique de navigation pour vérifier notamment si on a accédé à des comptes bancaires à partir de l’ordinateur.

 

Il peut aussi installer un capteur des touches utilisées sur le clavier afin de récupérer les mots de passe. « C’est arrivé en 2013 au directeur financier d’une grande chaîne de télévision sportive, BelN Sports. Des virements bancaires ont été effectués par les pirates informatiques pour 2,4 millions d’euros », illustre M. Aubergier.

 

Autre type d’escroquerie fréquente : la « fraude du président ». Dans ce cas, les fraudeurs réunissent beaucoup d’information sur l’entreprise ciblée, sur ses processus, les échelons hiérarchiques, les personnes qui tiennent les cordons de la bourse, etc.

 

Puis, ils font parvenir un courriel au directeur financier ou au comptable de l’entreprise, en lui faisant croire qu’il a été envoyé par le président, dans lequel on lui demande de virer de toute urgence une importante somme sur un compte dont on fournit les coordonnées, afin de pouvoir finaliser une acquisition qui doit demeurer confidentielle. « Le tout se fait généralement dans l’urgence, un vendredi à 17 h. Il ne reste plus que peu d’employés au bureau, et il est difficile d’effectuer des vérifications », explique Cyrille Aubergier.

 

En général, on profite du fait que le président est absent, idéalement en voyage d’affaires à l’étranger. Le comptable transfère la somme, qui se retrouve évidemment entre les mains des pirates informatiques.

 

Autre tactique fréquente des cyberfraudeurs : un courriel émanant faussement d’un fournisseur demandant que les paiements soient désormais effectués sur un autre compte bancaire. Le stratagème n’est découvert que lorsque le véritable fournisseur se plaint de ne pas avoir été payé depuis plusieurs mois.

 

Se protéger… oui, mais comment ?

 

La protection commence par une certaine dose de méfiance. On ne clique pas sur certains liens, et on n’ouvre pas de documents contenus dans des courriels provenant de sources inconnues.

 

Natasha Rocheleau, directrice principale, Solutions de Gestion de trésorerie Entreprises à la Banque Nationale, insiste sur le fait qu’il faut sensibiliser ses employés à la cyberfraude et instaurer de bonnes pratiques à l’interne. « Dans le cas de la fraude du président, il y a des signaux qu’il faut reconnaître : l’urgence, la confidentialité, le fait que le bénéficiaire ne soit pas connu de la personne qui effectue la transaction, etc.

 

Il est essentiel de mettre en place des procédures de vérification et d’identification. Une bonne pratique consisterait, par exemple, à communiquer avec le président à un numéro de téléphone ou à une adresse courriel que l’on connaît pour s’assurer que la demande vient effectivement de lui », suggère-t-elle.

 

Pour les transactions à risque, elle recommande l’utilisation d’une solution d’authentification telle qu’une clé SécurID par exemple, ou tout autre authentifieur ou jeton d’authentification qui affiche un code chiffré à intervalle fixe. Il s’agit d’une protection supplémentaire qui empêche l’accès au site, à moins d’avoir en main la solution d’authentification avec soi et d’entrer la bonne séquence numérique au moment de l’accès au site.

 

La « sécurité renforcée » est une mesure de sécurité supplémentaire qui permet d’accéder à certains sites Web en enregistrant des ordinateurs personnels, qui seront ainsi liés au code d’utilisateur. Lorsqu’une session est ouverte sur un ordinateur non enregistré, le système demandera à l’utilisateur de confirmer son identité en répondant à l’une des trois questions personnelles créées dans le profil.

 

Le recours à des processus de sécurité renforcés est également une bonne façon de se prémunir contre la cyberfraude. « Lorsqu’une transaction est effectuée à partir d’un ordinateur qui n’est pas reconnu par l’institution financière, des questions supplémentaires seront posées pour authentifier l’utilisateur. On peut aussi imposer des limites de montant par employé de l’entreprise, exiger des autorisations supplémentaires d’une autre personne à l’interne, etc.

 

Il existe toute une panoplie de solutions bancaires par Internet qui permettent de se protéger », mentionne Mme Rocheleau. Attention : il est facile de se laisser berner, les messages d’hameçonnage sont de mieux en mieux conçus, bien traduits et sans fautes d’orthographe, et les sujets abordés suscitent la curiosité, la pitié, la surprise… Alors, restez sur vos gardes !

 

Quatre conseils pour se prémunir contre la cyberfraude

 

Limitez l’accès à Internet des ordinateurs qui traitent des informations sensibles.

Effectuez régulièrement les mises à jour de sécurité. Tous les mois, on met à jour Windows, Flash, Macromedia, Java, l’antivirus,

Avant d’autoriser un transfert d’argent, on vérifie directement auprès des intéressés.

Ne comptez pas aveuglément sur l’antivirus ou l’anti-malware pour se protéger : s’il s’agit d’une nouvelle menace, ce logiciel n’est pas encore programmé pour la reconnaître.

Neurocom International

Neurocom International

Juin 1999 – septembre 2001, NEUROCOM, France / Canada / É.-U.

Position: Expert sécurité et réseau,

Déploiement de solutions de sécurité pour les clients suivants: Zodiac North America, unisélect, Astom Transport (8 sites), Crédit Agricole (Fr), Gemplus(Fr), Cartier.

 

Autre position : consultant Sécurité: pour Hydro-Québec(5 mois):

Sécurisation des postes de travail, ainsi que le service de consultation de la consommation électrique.

École Polytechnique

École Polytechnique

Cyrille Aubergier

Depuis 2015, Polytechnique Montréal.

Position: Chargé de cours

Perquisition d’une transaction électronique (Cyberfraude CF200)

Piratage informatique (Cyberenquete, CY140, interim)

 

Cours en entreprise, prévu début 2017:

  • Surveillance de sécurité (SOC, SIEM, attaque ciblée)
  • Devenez premier répondant en enquête numérique.