Je fais appel à vous car je n'ai pu apporter réponse à une amie
qui me demande de l'aide, sur certains sites de jurisprudences
je n'ai trouver que le cas où il est question de l'employeur non
des employés entre eux.
Voici son cas :
Mon amie travaille dans une société informatique et s'est fait piraté
sa boite au lettre par une de ses collègues laquelle s'est procurer le
mot de passe et utilise des informations privées qu'elle a fait sortir
de l'entreprise.
Qu'elle droit à mon amie contre elle ?
Qu'encours légalement la frauduleuse ?
Quels sont les devoirs de la société et que peut elle contre cet employé
?
A qui s'adresser pour porter plainte ? et quels seront alors les suites
?
Il y a donc une grosse faille dans la sécurité du système informatique de cette entreprise et dans le cas que vous avez cité, l'administrateur du système est aussi coupable que la personne qui a utilisé ce mot de passe.
C'est même une faute professionnelle grave de la part de l'admin ! Pffff ! On voit de ces trucs ! Les bras m'en tombent...
-- Roland Mattéoli
SP&B disait:
Il y a donc une grosse faille dans la sécurité du système informatique de
cette entreprise et dans le cas que vous avez cité, l'administrateur du
système est aussi coupable que la personne qui a utilisé ce mot de passe.
C'est même une faute professionnelle grave de la part de l'admin !
Pffff ! On voit de ces trucs ! Les bras m'en tombent...
Il y a donc une grosse faille dans la sécurité du système informatique de cette entreprise et dans le cas que vous avez cité, l'administrateur du système est aussi coupable que la personne qui a utilisé ce mot de passe.
C'est même une faute professionnelle grave de la part de l'admin ! Pffff ! On voit de ces trucs ! Les bras m'en tombent...
-- Roland Mattéoli
manu
Roland Matteoli wrote:
> Il y a donc une grosse faille dans la sécurité du système informatique de > cette entreprise et dans le cas que vous avez cité, l'administrateur du > système est aussi coupable que la personne qui a utilisé ce mot de passe. C'est même une faute professionnelle grave de la part de l'admin !
Souvent on demande à l'admin de deployer des outils qui n'ont pas été conçus dans un soucis de sécurité et qui peuvent être cassés trivialement. La complication pour mettre en place des outils surs est souvent refusée par la hierarchie (plus cher et plus long à deployer) ou par les usagers (plus compliqué à utiliser).
La vie de tous les jours de l'admin consiste à se dire: "ce truc n'est pas sûr, il faudrait deployer ca. Mais 80% des clients des usagers ne le supportent pas, donc il faudrait mettre à jour tout le parc. On a ni le budget ni les moyens humains pour le faire. Tant pis". Et encore c'est dans le cas où il existe une solution sécurisée. Souvent ca se résume à "l'outil que tel service a décidé d'acheter n'est pas sécurisable. Tant pis".
Bon, il y a aussi parfois negligence de l'administrateur, mais la pierre reste quand même la pupart du temps à jeter à d'autres personnes. Je me souviens d'un logiciel de base de données accessible par le web où les mots de passes étaient visibles dans l'URL (requetes GET là où il aurait fallu du POST). A partir du moment où il a été décidé d'utiliser ce logiciel, que faire?
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Roland Matteoli <rmatteoli@alussinan.org> wrote:
> Il y a donc une grosse faille dans la sécurité du système informatique de
> cette entreprise et dans le cas que vous avez cité, l'administrateur du
> système est aussi coupable que la personne qui a utilisé ce mot de passe.
C'est même une faute professionnelle grave de la part de l'admin !
Souvent on demande à l'admin de deployer des outils qui n'ont pas été
conçus dans un soucis de sécurité et qui peuvent être cassés
trivialement. La complication pour mettre en place des outils surs est
souvent refusée par la hierarchie (plus cher et plus long à deployer) ou
par les usagers (plus compliqué à utiliser).
La vie de tous les jours de l'admin consiste à se dire: "ce truc n'est
pas sûr, il faudrait deployer ca. Mais 80% des clients des usagers ne le
supportent pas, donc il faudrait mettre à jour tout le parc. On a ni le
budget ni les moyens humains pour le faire. Tant pis". Et encore c'est
dans le cas où il existe une solution sécurisée. Souvent ca se résume à
"l'outil que tel service a décidé d'acheter n'est pas sécurisable. Tant
pis".
Bon, il y a aussi parfois negligence de l'administrateur, mais la pierre
reste quand même la pupart du temps à jeter à d'autres personnes. Je me
souviens d'un logiciel de base de données accessible par le web où les
mots de passes étaient visibles dans l'URL (requetes GET là où il aurait
fallu du POST). A partir du moment où il a été décidé d'utiliser ce
logiciel, que faire?
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
> Il y a donc une grosse faille dans la sécurité du système informatique de > cette entreprise et dans le cas que vous avez cité, l'administrateur du > système est aussi coupable que la personne qui a utilisé ce mot de passe. C'est même une faute professionnelle grave de la part de l'admin !
Souvent on demande à l'admin de deployer des outils qui n'ont pas été conçus dans un soucis de sécurité et qui peuvent être cassés trivialement. La complication pour mettre en place des outils surs est souvent refusée par la hierarchie (plus cher et plus long à deployer) ou par les usagers (plus compliqué à utiliser).
La vie de tous les jours de l'admin consiste à se dire: "ce truc n'est pas sûr, il faudrait deployer ca. Mais 80% des clients des usagers ne le supportent pas, donc il faudrait mettre à jour tout le parc. On a ni le budget ni les moyens humains pour le faire. Tant pis". Et encore c'est dans le cas où il existe une solution sécurisée. Souvent ca se résume à "l'outil que tel service a décidé d'acheter n'est pas sécurisable. Tant pis".
Bon, il y a aussi parfois negligence de l'administrateur, mais la pierre reste quand même la pupart du temps à jeter à d'autres personnes. Je me souviens d'un logiciel de base de données accessible par le web où les mots de passes étaient visibles dans l'URL (requetes GET là où il aurait fallu du POST). A partir du moment où il a été décidé d'utiliser ce logiciel, que faire?
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
SP&B
> Bon, il y a aussi parfois negligence de l'administrateur, mais la pierre reste quand même la pupart du temps à jeter à d'autres personnes. Je me souviens d'un logiciel de base de données accessible par le web où les mots de passes étaient visibles dans l'URL (requetes GET là où il aurait fallu du POST). A partir du moment où il a été décidé d'utiliser ce logiciel, que faire?
Bonjour,
Vous avez entièrement raison, le responsable n'est effectivement pas toujours l'administrateur, mais aussi très souvent sa hiérarchie. Toutefois l'admin. doit au minimum informer la tête pensante des risques et dangers encourus, et faire le maximum pour leur éviter d'acheter des logiciels à risque.
> Bon, il y a aussi parfois negligence de l'administrateur, mais la pierre
reste quand même la pupart du temps à jeter à d'autres personnes. Je me
souviens d'un logiciel de base de données accessible par le web où les
mots de passes étaient visibles dans l'URL (requetes GET là où il aurait
fallu du POST). A partir du moment où il a été décidé d'utiliser ce
logiciel, que faire?
Bonjour,
Vous avez entièrement raison, le responsable n'est effectivement pas
toujours l'administrateur, mais aussi très souvent sa hiérarchie.
Toutefois l'admin. doit au minimum informer la tête pensante des risques et
dangers encourus, et faire le maximum pour leur éviter d'acheter des
logiciels à risque.
Sincères salutations.
--
Jean-Claude FLAJOULOT
Sécurité, Pointage & Biométrie
SPetB_no.spam@wanadoo.fr
enlever _no.spam pour me contacter en PV.
> Bon, il y a aussi parfois negligence de l'administrateur, mais la pierre reste quand même la pupart du temps à jeter à d'autres personnes. Je me souviens d'un logiciel de base de données accessible par le web où les mots de passes étaient visibles dans l'URL (requetes GET là où il aurait fallu du POST). A partir du moment où il a été décidé d'utiliser ce logiciel, que faire?
Bonjour,
Vous avez entièrement raison, le responsable n'est effectivement pas toujours l'administrateur, mais aussi très souvent sa hiérarchie. Toutefois l'admin. doit au minimum informer la tête pensante des risques et dangers encourus, et faire le maximum pour leur éviter d'acheter des logiciels à risque.
Vous avez entièrement raison, le responsable n'est effectivement pas toujours l'administrateur, mais aussi très souvent sa hiérarchie. Toutefois l'admin. doit au minimum informer la tête pensante des risques et dangers encourus, et faire le maximum pour leur éviter d'acheter des logiciels à risque.
D'autant plus que c'est souvent l'admin qui portera le chapeau devant la justice.
-- Roland Mattéoli
SP&B disait:
Vous avez entièrement raison, le responsable n'est effectivement pas
toujours l'administrateur, mais aussi très souvent sa hiérarchie.
Toutefois l'admin. doit au minimum informer la tête pensante des risques et
dangers encourus, et faire le maximum pour leur éviter d'acheter des
logiciels à risque.
D'autant plus que c'est souvent l'admin qui portera le chapeau devant la
justice.
Vous avez entièrement raison, le responsable n'est effectivement pas toujours l'administrateur, mais aussi très souvent sa hiérarchie. Toutefois l'admin. doit au minimum informer la tête pensante des risques et dangers encourus, et faire le maximum pour leur éviter d'acheter des logiciels à risque.
D'autant plus que c'est souvent l'admin qui portera le chapeau devant la justice.
-- Roland Mattéoli
manu
SP&B wrote:
Vous avez entièrement raison, le responsable n'est effectivement pas toujours l'administrateur, mais aussi très souvent sa hiérarchie. Toutefois l'admin. doit au minimum informer la tête pensante des risques et dangers encourus, et faire le maximum pour leur éviter d'acheter des logiciels à risque.
Souvent on se retrouve devant le fait accompli: la solution a deployer a déjà été choisie, il faut faire avec. Les phénomènes d'externalisation à tout va de tout un tas de tâches (étude, intégration, exploitation) à des boites différentes accentuent d'ailleurs encore plus le problème.
Il arrive même qu'il n'y ait même pas de solution sécurisée disponible sur le marché. Les editeurs se sont dit que ca irait bien comme ca, et à moins de ré-ecrire un logiciel à la hauteur (et l'admin n'est pas là pour ca), il n'y a rien à y faire.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
SP&B <SPetB_no.spam@wanadoo.fr> wrote:
Vous avez entièrement raison, le responsable n'est effectivement pas
toujours l'administrateur, mais aussi très souvent sa hiérarchie.
Toutefois l'admin. doit au minimum informer la tête pensante des risques et
dangers encourus, et faire le maximum pour leur éviter d'acheter des
logiciels à risque.
Souvent on se retrouve devant le fait accompli: la solution a deployer a
déjà été choisie, il faut faire avec. Les phénomènes d'externalisation à
tout va de tout un tas de tâches (étude, intégration, exploitation) à
des boites différentes accentuent d'ailleurs encore plus le problème.
Il arrive même qu'il n'y ait même pas de solution sécurisée disponible
sur le marché. Les editeurs se sont dit que ca irait bien comme ca, et à
moins de ré-ecrire un logiciel à la hauteur (et l'admin n'est pas là
pour ca), il n'y a rien à y faire.
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Vous avez entièrement raison, le responsable n'est effectivement pas toujours l'administrateur, mais aussi très souvent sa hiérarchie. Toutefois l'admin. doit au minimum informer la tête pensante des risques et dangers encourus, et faire le maximum pour leur éviter d'acheter des logiciels à risque.
Souvent on se retrouve devant le fait accompli: la solution a deployer a déjà été choisie, il faut faire avec. Les phénomènes d'externalisation à tout va de tout un tas de tâches (étude, intégration, exploitation) à des boites différentes accentuent d'ailleurs encore plus le problème.
Il arrive même qu'il n'y ait même pas de solution sécurisée disponible sur le marché. Les editeurs se sont dit que ca irait bien comme ca, et à moins de ré-ecrire un logiciel à la hauteur (et l'admin n'est pas là pour ca), il n'y a rien à y faire.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
