74 countries hit by NSA powered WannaCrypt ransomware

The WannaCrypt ransomware worm, or WanaCrypt or Wcry, exploded across 74 countries on May 12th, 2017, infecting hospitals, businesses, universities, national telecommunication companies and other organizations.

WannaCrypt is installed on Windows computers by a worm that spreads across networks by exploiting a vulnerability in Microsoft’s SMB file-sharing services. It specifically abuses a bug designed MS17-010 that Redmond patched in March for modern versions of Windows. Unpatched systems, or ones running legacy versions such as Windows XP, are therefore vulnerable and can be attacked.

This bug was previously exploited by the NSA to hijack and spy on its targets. Its internal tool to do this, codenamed Eternalblue, was stolen from the agency, and leaked online in April, putting this US government cyber weapon into the hands of any willing miscreant. Almost immediately, it was used to hijack thousands of machines on the internet.

Now someone has taken that tool and strapped it to ransomware: the result is a variant of WannaCrypt, which spreads via SMB and, after landing on a computer, encrypts as many files as it can find. It charges $300 or $600 in Bitcoin to restore the documents. It is adept at bringing offices and homes to a halt by locking away their data.

And it installs Doublepulsar, a backdoor that allows the machine to be remotely controlled. That’s another stolen NSA tool leaked alongside Eternalblue. The malware is also controlled via the anonymizing Tor network by connecting to hidden services to receive further commands from its masters.

Fortunately, a kill switch was included in the code. When it detects that a particular web domain exists, it stops further infections. That domain was created earlier today, halting the worldwide spread of the nasty.

The software nasty has today ransacked the UK’s national healthcare service, forcing hospitals to shut down to non-emergency patients; torn through Spanish telco Telefónica; and many other organizations. In what is looking like one of the biggest malware attacks in recent memory, the bulk of the infections are in Russia, including the state’s interior ministry; the virus has claimed high-profile targets around the world.

16 NHS health trusts in the UK were taken out by the malware. Prime Minister Theresa May said the code “has crippled” Brit hospitals, and that Blighty’s surveillance nerve center GCHQ is looking into the outbreak. The NHS is thought to have been particularly hard hit because of the antiquated nature of its IT infrastructure. A large part of the organization’s systems are still using Windows XP, which is no longer supported by Microsoft, and Health Secretary Jeremy Hunt cancelled a pricey support package in 2015 as a cost-saving measure.

Computers were locked in Aintree, Blackpool, Broomfield Hospital in Essex, Colchester General Hospital, all hospital systems in Derbyshire, Great Yarmouth, East and North Hertfordshire, James Paget hospital in Norfolk, Lanarkshire, and Leicester.

US companies have also been hit. FedEx told The Reg: “Like many other companies, FedEx is experiencing interference with some of our Windows-based systems caused by malware. We are implementing remediation steps as quickly as possible. We regret any inconvenience to our customers.” Essentially, staff have been told to turn off their non-critical systems, and to keep it that way until the mess is cleaned up – which could take the whole weekend, or longer.

Meanwhile, Scottish Power was also reported as hit, but it told us that it just took down some non-essential systems as a precaution.

To counter the spread of the malware, security firms are pushing out file and network traffic signature to detect the ransomware-worm hybrid’s presence and kill it. Microsoft was quick off the ball and has pushed signatures for the malware for its systems.

“Today our engineers added detection and protection against new malicious software known as Ransom:Win32.WannaCrypt,” a Microsoft spokesperson told The Reg.

“In March, we provided a security update which provides additional protections against this potential attack. Those who are running our free antivirus software and have Windows Update enabled, are protected. We are working with customers to provide additional assistance.”

NSA exposure puts us all at risk

As described above, the worm uses the EternalBlue and DoublePulsar exploits swiped from the NSA’s arsenal of hacking tools. It would have been great if the bugs targeted by the agency had been patches years ago; instead, they were patched by Microsoft in March just before the Shadow Brokers dumped the programs online in April. We assume either the NSA or the brokers tipped off the Redmond giant so that updates to kill off the SMB bug could be pushed out before the exploits publicly leaked.

So, yes, Microsoft issued security fixes to address the vulnerabilities attacked by those cyber-weapons, but as is the way with users and IT departments big and small, not everyone has patched, or can patch, and are now paying the price. The initial infection point appears to be spam emails with the malware hidden in attachments. The malware is a hybrid design that also has a worm element, allowing it to spread through internal networks for maximum infection possibilities.

According to an analysis by Payload Security, the malware drops a number of programs on the system, including Tor, and adds itself to the Windows Registry so it persists across reboots. It can fetch software modules to gain new abilities, and uses various techniques to hinder reverse-engineering: decrypted samples of the executables are available from the above links.

The code encrypts a wide variety of documents on a computer, including any attached storage, and snatches any keys for remote-desktop access. It deletes volume snapshots, and disables system repair tools. It also scans the infected system’s settings to work out the user’s language, and pulls up a ransom demand in the correct lingo for the victim. It changes the desktop backdrop, too, to grab the victim’s attention.

According to a study by Kaspersky, it appears the malware controllers are getting greedier as infection rates grow. The initial infections asked for $300 worth of Bitcoin, however later infection notices have upped this price to $600. A check on the Bitcoin strings show a few thousand dollars’ worth of Bitcoin have already been sent to the criminals.

“We have recorded more than 45,000 attacks of the WannaCry ransomware in 74 countries around the world, mostly in Russia,” said Kaspersky’s research team.

“It’s important to note that our visibility may be limited and incomplete and the range of targets and victims is likely much, much higher.”

What is to be done?

This is just the first wave: there is nothing stopping someone from making a new worm that attacks the MS17-010 bug to silently compromise vulnerable systems, or adapting the WannaCrypt binaries to cause more damage.

So, what’s the solution? If you’re already infected then there’s not a lot you can do other than wipe the system and reinstall from offline unaffected backups – if you have them.

It’s possible that the malware writers will have screwed up and put the decryption key in the code itself – such slip-ups have happened in the past. Researchers are picking the code apart byte by byte trying to find such clues, but this looks like a reasonably sophisticated piece of software so that’s a long shot.

If you haven’t been infected, make sure your security patches are up to date. Kill off SMBv1 at the very least, and block access to it from outside your network. The exploits the malware uses have already been patched, and there’s no excuse for getting caught out as a private user. It’s understandable that IT managers with annoying corporate policies and heavy workloads have been forced to hold back patches, or are unable to apply them. If you can update your installations, drop everything and get patching.



• 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)



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.