Contrôle d'accès physique : étude des cartes sans contact

Magazine
Marque
MISC
Numéro
79
Mois de parution
mai 2015
Domaines


Résumé
Quelqu'un a pénétré dans la nuit dans vos locaux. Trois serveurs, pourtant installés dans un local sécurisé, ont disparu. Ils contenaient l'ensemble des données critiques de l’entreprise. Pourtant, aucune trace d'effraction. Ce scénario catastrophe est-il crédible ?

L'authentification par badge, pour rentrer dans un bâtiment ou un local sécurisé, est devenue banale. Ces installations, mises en place lors de la construction, sont faites pour durer de nombreuses années. Alors, si le système n'évolue pas, comment sont prises en charge les vulnérabilités découvertes au fur et à mesure des années ? Après un tour d'horizon du fonctionnement des systèmes de contrôle d'accès physique et de quelques vulnérabilités, nous proposerons une méthode pour déterminer le type de badge et mesurer un premier niveau de risque. Puis nous examinerons des techniques d'attaques avancées avant de conclure sur un niveau de risque réel.

1. Architecture

On trouve sur le marché deux grandes catégories d'architecture. La première approche, centralisée, consiste à utiliser un numéro qui sert d’identifiant et les droits d’accès sont stockés sur un serveur en central. Cette façon de procéder permet d’enregistrer un utilisateur à distance ou...

Cet article est réservé aux abonnés. Il vous reste 97% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite


Articles qui pourraient vous intéresser...

Migrez de iptables vers nftables

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Il y a cinq ans, je lisais un premier article sur nftables [1] : l’outil semblait intéressant, mais il n’était pas disponible sur ma machine. En 2019, une distribution majeure, Debian, a basculé sur nftables avec sa version 10 (Buster) [2] : il est donc temps de voir comment migrer du vénérable pare-feu iptables vers son successeur.

Cas pratique sur la sécurisation d'un cluster Kubernetes

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Cet article présente trois exemples de problèmes de sécurité rencontrés sur des clusters Kubernetes, causés par un manque de maîtrise des applications déployées sur un cluster par ses administrateurs ou par les développeurs des applications s’y exécutant. Nous donnons ensuite des pistes afin de mieux maîtriser et sécuriser ces applications.

Sauvegardez vos données, centralisez vos logs et supervisez votre sécurité

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Nos serveurs présentent désormais une surface d’attaque réseau maîtrisée et une sécurisation système d’un niveau cohérent avec notre modèle de menaces. De même, le service SSH tournant sur ces serveurs est configuré de manière optimisée. Nous pouvons donc être relativement sereins si nos adversaires sont d’un niveau intermédiaire. Et si malgré toutes ces protections, une attaque comme un rançongiciel réussissait ? Et bien dans ce cas-là, pour l’instant, notre infrastructure serait particulièrement vulnérable. Aucune sauvegarde externalisée. Pas de centralisation des traces. Une supervision sécurité inexistante. Remédions à cette situation afin d’élever le niveau de maturité de la sécurité de notre infrastructure.

Investigation numérique de l’image disque d’un environnement Windows

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Une investigation numérique requiert de nombreuses étapes. Celles-ci varient en fonction des données disponibles. Une des plus importantes est l’analyse de la mémoire vive (voir MISC N°111 [1]). L’analyse de la mémoire de masse, constituée des événements propres au système d’exploitation apporte de nouveaux éléments. Une fois celles-ci terminées, la corrélation des deux nous permettra de confirmer d’éventuelles hypothèses.