|
|
Cybercriminalité - Chiffres - Hacking
criminalité informatique
ministère
protection des données
| 24/9/2013 | Envoi question |
| 18/10/2013 | Réponse |
Aussi posée à : question écrite 5-9897
Aussi posée à : question écrite 5-9898
Aussi posée à : question écrite 5-9899
Aussi posée à : question écrite 5-9900
Aussi posée à : question écrite 5-9901
Aussi posée à : question écrite 5-9902
Aussi posée à : question écrite 5-9903
Aussi posée à : question écrite 5-9905
Aussi posée à : question écrite 5-9906
Aussi posée à : question écrite 5-9907
Aussi posée à : question écrite 5-9908
Aussi posée à : question écrite 5-9909
Aussi posée à : question écrite 5-9910
Aussi posée à : question écrite 5-9911
Aussi posée à : question écrite 5-9912
Aussi posée à : question écrite 5-9913
Aussi posée à : question écrite 5-9914
Aussi posée à : question écrite 5-9915
Eu égard à la cybercriminalité actuelle, je souhaiterais une réponse aux questions suivantes :
1. Pouvez-vous me décrire la situation présente dans vos services ? Ont-ils déjà été la victime de pirates ou de cybercriminels, et dans l'affirmative, combien de fois ?
2. Le nombre de cyberattaques contre vos services a-t-il augmenté ces dernières années ? Pouvez-vous préciser, le cas échéant en donnant des chiffres ?
3. Si vos services ont déjà été la cible d'attaques, quels étaient la nature et les effets de chaque incident ? Par exemple, a-t-on dérobé des informations, attaqué un serveur ou un PC ou saboté une infrastructure ? Pouvez-vous fournir des détails ?
4. Compte tenu des cyberattaques dirigées contre certains services publics, avez-vous pris des mesures en vue de renforcer la sécurité de vos services ? Si oui, lesquelles ? Si non, pourquoi pas ?
5. S'il est ou s'il devait être question d'une cyberattaque sur vos services, quelle est la procédure standard de traitement ?
6. Vos services ont-ils déjà dû s'adresser au parquet à la suite de faits de cybercriminalité, et à combien de reprises ? Pouvez-vous préciser ?
7. Vos services ou votre administration sont-ils tenus de signaler de telles attaques à FEDICT ou à CERT ? Pourquoi (pas) ?
8. Estimez-vous vraisemblable que vos services aient déjà été attaqués par des cybercriminels, mais que ces attaques soient passées inaperçues en raison de techniques flexibles faisant appel à des technologies avancées ?
Pour ce qui concerne l’Agence fédérale pour la sécurité de la chaîne alimentaire (AFSCA) :
1. En dehors des interceptions automatiques de virus ou spyware, des tentatives « normales » de pénétration qui sont captées et bloquées par notre « firewall » internet, et pour autant que l’AFSCA ait été capable de le détecter, l’AFSCA n’a pas été attaquée par des hackers ou cybercriminels. En 2012 l’AFSCA a subi une infection locale par une variante du « conficker » ; celle-ci a pu être facilement nettoyée et il n’y a pas eu de conséquence.
2. L’AFSCA n’a pas d’attaques cybernétiques à déplorer en dehors de l’infection susmentionnée. Une proportion de 0,05 % des e-mails entrants sont interceptés parce qu’ils contiennent l’un ou l’autre virus ou malware. Plus que jamais, l’AFSCA est très prudente et a accru la fréquence avec laquelle elle scanne ses systèmes à la recherche d’infections ; l’AFSCA applique plus rapidement les nouvelles versions de logiciels ou les mises à jour, ce qui engendre évidemment plus de travail de maintenance sans réelle valeur ajoutée.
3. Comme déjà expliqué au point 1, l’AFSCA a eu à déplorer en 2012 une infection sans conséquences importantes.
4. L’AFSCA a prévu un audit de sécurité TIC en 2014 afin d’avoir une vue – au vu du type de données qu’elle traite, de l’infrastructure qu’elle met en œuvre à cette fin et des personnes qui les utilisent – sur l’état de sécurisation des données et systèmes ; cet audit doit situer les mesures actuelles de l’AFSCA par rapport à un niveau de protection « normal », identifier des points faibles éventuels et le cas échéant identifier quelques actions d’amélioration prioritaires.
L’AFSCA a reçu ce 2 octobre 2013 l’aide du Computer Emergency Response Team (CERT) pour contrôler ses systèmes suite aux récentes découvertes d’infections à des fins d’espionnage. Les vérifications en elles-mêmes prendront quelques semaines.
5. Dans ce domaine, il n’y a pas de procédure « standard » de traitement parce que ni l’endroit, ni le contenu, ni la nature d’une attaque ni les conséquences ne sont prévisibles. Il y a bien quelques actions prédéterminées.
Par exemple pour les virus, spyware et similaires qui sont automatiquement détectés, neutralisés et rapportés par des logiciels de sécurité spécifiques, il y a un suivi du type et du nombre afin de découvrir à temps une propagation ou une attaque massive. La hiérarchie est informée en cas d’infection.
En cas de détection d’une attaque anormale depuis internet, notre connexion doit être immédiatement coupée et on fait appel à de l’assistance (entre-autres par une signalisation auprès du Service public fédéral Technologie de l'information et de la communication (FEDICT) et du CERT) pour déterminer les dégâts et pour prendre des contre-mesures. Toute tentative de chantage ou de vol de données fait l’objet d’une plainte déposée auprès de la police.
6. Non, cela ne s’est jamais passé à l’AFSCA.
7. Les services de l’AFSCA ne sont pas « légalement » obligés de signaler des attaques ; des tentatives ou des attaques anormales depuis internet sont signalées chez FEDICT parce que la connexion internet passe par FEDICT et pour ainsi tenter de faire en sorte que d’autres puissent aussi y échapper et se protéger contre la même attaque.
8. Malgré les mesures déjà prises, la probabilité que l’AFSCA ait déjà été attaquée sans l’avoir remarqué est faible mais pas exclue : les données que l’AFSCA traite sont peu attractives pour les espions ou les criminels ; d’autre part et même si l’AFSCA dispose d’assez de moyens financiers et de compétences techniques pour essayer de l’exclure, cela reste une poursuite sans fin entre des criminels qui recherchent constamment de nouvelles vulnérabilités et les exploitent, et des experts qui par après développent et appliquent des contre-mesures.
Pour ce qui concerne le Bureau d’Intervention et de Restitution belge (BIRB) :
1. En 2012, le BIRB a dû intervenir sur six PC infestés par des virus et nous avons pu maîtriser deux attaques externes sur le serveur mail.
2. La première cyber-attaque sur le serveur mail a eu lieu le 30 janvier 2012 et la seconde a eu lieu le 17 février 2012. Aucune autre cyber-attaque ne s’est produite depuis.
3. La première cyber-attaque visait le serveur de mail. Elle avait pour objet d’utiliser ce serveur comme relais d’envois de courriers indésirables. L’intrusion a été possible par le biais d’un compte électronique non suffisamment protégé. L’attaque a eu pour conséquence une indisponibilité temporaire des services de courriers électroniques. La deuxième attaque visait également le serveur de mail. Ce serveur a été l’objet de tentatives d’intrusions par la méthode de “force brute” mais sans succès pour les attaquants. Le serveur a été mis hors ligne pendant les deux jours du weekend. Le lundi suivant, tout est progressivement revenu à la normale.
4. La mesure principale mise place suite aux attaques a été de renforcer la complexité des mots de passe attribués à certains comptes du réseau interne.
5. La procédure principale est de mettre l’objet de l’attaque (serveur, station de travail, routeur, etc.) physiquement hors de portée de l’agresseur, ensuite de procéder à l’identification de la tactique utilisée par l’agresseur dans le but de la neutraliser. Tout incident de ce type donne lieu à un rapport communiqué au responsable INFOSEC du BIRB.
6. Le BIRB n’a pas dû avoir recours, à ce jour, pour ce type d’incident, au service du parquet.
7. Le BIRB n’a pas connaissance de directives précises en la matière.
8. Le point d’entrée et de sortie du réseau du BIRB est protégé par un Firewall. La technologie du Firewall est récente et constamment mise à jour de manière à garantir un niveau de protection maximal en regard des progrès technologique des cyber-attaques. Les serveurs accessibles de l’extérieur sont physiquement isolés dans une DMZ qui leur est dédicacée.
Pour ce qui concerne le Centre d'Étude et de Recherches vétérinaires et agrochimiques (CERVA) :
1. Réseau interne: non.
DMZ (Web site): oui (deux fois).
2. Non, rien constaté. L'équipe ICT est trop réduite que pour pouvoir scruter régulièrement les fichiers « LOG ».
3. Comme mentionné ci-dessus juste le site WEB. Toutefois, il ne contient aucune donnée confidentielle ou critique et peut être facilement reconstruit (attaque FTP).
Temps de réinstallation: 4h.
4. Non.
5. Déconnecter le(s) appareil(s) concerné(s) du réseau.
Checkup de ce(s) dernier(s).
Recherche des causes possibles via collègues ou Internet.
Agir en conséquence au niveau de la sécurité (mise à jour de certains logiciels, changement de mot-de-passe...).
Remise en service sur le réseau et surveillance accrue dans les jours suivants.
6. Non.
7. Non. Le CERVA a déjà pris contact avec BELNET lorsqu’il y a eu des problèmes avec le site Web.
8. Le CERVA ne le sait pas mais cela doit se produire. Jusque maintenant, les systèmes de sécurité ont bien fonctionné (checkpoint Manager, Trends Micro, Barracuda, etc.).
Pour ce qui concerne le Service public fédéral (SPF) Économie :
Je vous renvoie à la réponse apportée par mon collègue, le vice-premier ministre en charge de l'Économie, des Consommateurs et de la Mer du Nord, Monsieur Johan Vande Lanotte.
En ce qui concerne l'Institut national d’assurances sociales pour travailleurs indépendants (INASTI) :
1. L'INASTI n'a jamais été victime d'attaques de hackers ou de cybercriminels.
2. Sans objet. Voir réponse à la question 1.
3. Sans objet. Voir réponse à la question 1.
4. Une firme spécialisée en criminalistique IT a effectué récemment un « quick scan » des systèmes les plus exposés aux risques. En outre, des audits de sécurité IT sont réalisés régulièrement.
5. Les mesures à prendre en cas de cyberattaque dépendent de la gravité de l’attaque et du type d'attaque.
En général, la première priorité sera de limiter les dégâts (stopper les fuites de données, rendre à nouveau opérationnels les systèmes attaqués,…) et d'informer les instances compétentes (voir réponse à question 7).
En concertation avec les services compétents, l’INASTI essaiera ensuite d'identifier et de dépister les responsables.
Enfin, l’INASTI examinera de quelle manière il peut encore améliorer la sécurité de ses systèmes de telle sorte que l'il puisse éviter, à l'avenir, une telle attaque.
6. Sans objet. Voir réponse à question 1.
7. Les Institutions Publiques de Sécurité Sociale (nommée ci-après IPSS) utilisent une infrastructure de communication commune (backbone) : l'Extranet de la Sécurité sociale. Toutes les cyberattaques envers une IPSS doivent d'abord passer par BELNET, FEDMAN et enfin EXTRANET. À ces 3 niveaux, il existe des procédures d'escalade et des mesures de sécurité sont implémentées. Au niveau de l'Extranet, il y a des systèmes de monitoring (IDS + SIEM) ainsi qu’une équipe interne et une équipe externe qui analysent en permanence les données de ces systèmes de monitoring (interne = Smals; externe = firme externe). Si l'INASTI soupçonne une attaque, il active les procédures d'escalade. La Smals dispose de personnes de contact auprès de FEDICT et de BELNET ainsi que de procédures visant à utiliser, en cas d'attaques, une approche commune. Si nécessaire, des tiers (PROVIDERS/CERT/ Federal Computer Crime Unit (FCCU)...) y sont impliqués.
Au niveau de l'Extranet et d'une IPSS, des mesures sont prises afin d'éviter des incidents de sécurité (protection malware, IDS & SIEM, pare-feu, DMZ, application pare-feu,…). Si toutefois des cyberattaques sophistiquées du type « malware infection » (malware complexe, logiciel espion détection, ...) surviennent, les procédures d'escalade susmentionnées sont à nouveau lancées. Si une IPSS constate elle-même ce type d'attaque/d'infection, elle doit contacter la BCSS + la Smals (security+ supervision Smals). Ces dernières analyseront s'il y a un impact sur l'Extranet et sur les autres IPSS et prendront, à cet effet, les mesures adéquates (et lanceront, si nécessaire, une procédure d'escalade). S'il s'agit d'un problème local (donc limité à une IPSS), l'IPSS doit examiner s'il y a lieu d'en informer des tiers (FCCU, parquet, CERT...). Cela dépend toutefois du type d'incident et du cadre juridique y afférent (par ex. loi relative à la criminalité informatique).
8. Il est très difficile d'évaluer ce risque étant donné que l’INASTI ne dispose, jusqu'à présent, d'aucun élément lui indiquant que ses systèmes auraient déjà fait l'objet d'une attaque. Vu le nombre élevé de mesures de sécurité prises par l'INASTI et l'Extranet de la Sécurité sociale (voir ci-dessus), cette possibilité semble peu réaliste même si l’INASTI ne peut pas totalement l'exclure.
En ce qui concerne la DG Indépendants du SPF Sécurité Sociale :
Je vous renvoie à la réponse apportée par ma collègue, la vice-première ministre et ministre de la Santé publique, Madame Laurette Onkelinx.