Supposons la situation suivante, pas tout à fait inventée :
Dans une grande entreprise, un DRH exige de d'une partie des employés
qu'ils saisissent - via un logiciel maison - toutes sortes de données
(coordonnées des employés, données relatives à leurs emplois...) ce
logiciel est manifestement destiné au flicage du travail des employés.
Ce logiciel envoie les données par une connexion FTP sur un serveur qui
centralise les dossiers.
Un employé du service informatique, agacé par ce logiciel de merde,
découvre qu'il est possible de récupérer les paramètres de connexion au
serveur simplement en sniffant la connexion : adresse, login et mot de
passe circulent en clair. Ceci permet à n'importe qui de récuperer les
fichiers de données.
La faille est signalée par le bricoleur à sa hiérarchie. Le bricoleur se
contente de vérifier par la lecture d'un fichier et l'écriture/effacement
d'un autre qu'il a bien un accès complet au serveur. RIEN n'a été modifié.
Le logiciel est téléchargeable sur le web (référencé par google), son
démarrage nécessite un mot de passe trivial communiqué par courrier aux
employés, inchangé depuis 3 ans et commun à tous les employés.
Bref, l'aspect sécurité à été totalement bâclée.
Quel est la responsabilité de chacun dans ce merdier ?
Peut-on reprocher quoi que ce soit au découvreur de la faille, même si son
intention était bien de mettre les pieds dans le plat et le nez dans le
caca de certains.
Pour le fun, j'ajoute qu'il n'y a vraisemblablement aucune déclaration à
la CNIL du bidule ;-)
Méphisto
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
Le Tue, 09 Oct 2007 14:04:56 +0000, Professeur Méphisto a écrit:
Bonjour à tous
Supposons la situation suivante, pas tout à fait inventée :
Dans une grande entreprise, un DRH exige de d'une partie des employés qu'ils saisissent - via un logiciel maison - toutes sortes de données (coordonnées des employés, données relatives à leurs emplois...) ce logiciel est manifestement destiné au flicage du travail des employés.
Ce logiciel envoie les données par une connexion FTP sur un serveur qui centralise les dossiers.
Un employé du service informatique, agacé par ce logiciel de merde, découvre qu'il est possible de récupérer les paramètres de connexion au serveur simplement en sniffant la connexion : adresse, login et mot de passe circulent en clair. Ceci permet à n'importe qui de récuperer les fichiers de données.
La faille est signalée par le bricoleur à sa hiérarchie. Le bricoleur se contente de vérifier par la lecture d'un fichier et l'écriture/effacement d'un autre qu'il a bien un accès complet au serveur. RIEN n'a été modifié.
Le logiciel est téléchargeable sur le web (référencé par google), son démarrage nécessite un mot de passe trivial communiqué par courrier aux employés, inchangé depuis 3 ans et commun à tous les employés. Bref, l'aspect sécurité à été totalement bâclée.
Quel est la responsabilité de chacun dans ce merdier ?
Peut-on reprocher quoi que ce soit au découvreur de la faille, même si son intention était bien de mettre les pieds dans le plat et le nez dans le caca de certains.
Pour le fun, j'ajoute qu'il n'y a vraisemblablement aucune déclaration à la CNIL du bidule ;-)
Méphisto
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer pour intrusion dans un système informatique ; la facilité de la manipulation n'y changera rien.
A contrario, la boîte peut effectivement faire l'objet d'une attention particulière de la CNIL, mais il faut pour ça que cette dernière soit saisie.
Amicalement, -- Albert.
Le Tue, 09 Oct 2007 14:04:56 +0000, Professeur Méphisto a écrit:
Bonjour à tous
Supposons la situation suivante, pas tout à fait inventée :
Dans une grande entreprise, un DRH exige de d'une partie des employés
qu'ils saisissent - via un logiciel maison - toutes sortes de données
(coordonnées des employés, données relatives à leurs emplois...) ce
logiciel est manifestement destiné au flicage du travail des employés.
Ce logiciel envoie les données par une connexion FTP sur un serveur qui
centralise les dossiers.
Un employé du service informatique, agacé par ce logiciel de merde,
découvre qu'il est possible de récupérer les paramètres de connexion au
serveur simplement en sniffant la connexion : adresse, login et mot de
passe circulent en clair. Ceci permet à n'importe qui de récuperer les
fichiers de données.
La faille est signalée par le bricoleur à sa hiérarchie. Le bricoleur se
contente de vérifier par la lecture d'un fichier et
l'écriture/effacement d'un autre qu'il a bien un accès complet au
serveur. RIEN n'a été modifié.
Le logiciel est téléchargeable sur le web (référencé par google), son
démarrage nécessite un mot de passe trivial communiqué par courrier aux
employés, inchangé depuis 3 ans et commun à tous les employés. Bref,
l'aspect sécurité à été totalement bâclée.
Quel est la responsabilité de chacun dans ce merdier ?
Peut-on reprocher quoi que ce soit au découvreur de la faille, même si
son intention était bien de mettre les pieds dans le plat et le nez dans
le caca de certains.
Pour le fun, j'ajoute qu'il n'y a vraisemblablement aucune déclaration à
la CNIL du bidule ;-)
Méphisto
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
pour intrusion dans un système informatique ; la facilité de la
manipulation n'y changera rien.
A contrario, la boîte peut effectivement faire l'objet d'une attention
particulière de la CNIL, mais il faut pour ça que cette dernière soit
saisie.
Le Tue, 09 Oct 2007 14:04:56 +0000, Professeur Méphisto a écrit:
Bonjour à tous
Supposons la situation suivante, pas tout à fait inventée :
Dans une grande entreprise, un DRH exige de d'une partie des employés qu'ils saisissent - via un logiciel maison - toutes sortes de données (coordonnées des employés, données relatives à leurs emplois...) ce logiciel est manifestement destiné au flicage du travail des employés.
Ce logiciel envoie les données par une connexion FTP sur un serveur qui centralise les dossiers.
Un employé du service informatique, agacé par ce logiciel de merde, découvre qu'il est possible de récupérer les paramètres de connexion au serveur simplement en sniffant la connexion : adresse, login et mot de passe circulent en clair. Ceci permet à n'importe qui de récuperer les fichiers de données.
La faille est signalée par le bricoleur à sa hiérarchie. Le bricoleur se contente de vérifier par la lecture d'un fichier et l'écriture/effacement d'un autre qu'il a bien un accès complet au serveur. RIEN n'a été modifié.
Le logiciel est téléchargeable sur le web (référencé par google), son démarrage nécessite un mot de passe trivial communiqué par courrier aux employés, inchangé depuis 3 ans et commun à tous les employés. Bref, l'aspect sécurité à été totalement bâclée.
Quel est la responsabilité de chacun dans ce merdier ?
Peut-on reprocher quoi que ce soit au découvreur de la faille, même si son intention était bien de mettre les pieds dans le plat et le nez dans le caca de certains.
Pour le fun, j'ajoute qu'il n'y a vraisemblablement aucune déclaration à la CNIL du bidule ;-)
Méphisto
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer pour intrusion dans un système informatique ; la facilité de la manipulation n'y changera rien.
A contrario, la boîte peut effectivement faire l'objet d'une attention particulière de la CNIL, mais il faut pour ça que cette dernière soit saisie.
Amicalement, -- Albert.
Professeur M
Albert ARIBAUD a écrit :
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer pour intrusion dans un système informatique ;
D'accord, mais la manipulation qui a permis de découvrir la faille est justifiable par la nécessité de faire fonctionner le logiciel client. Le logiciel est totalement opaque, la documentation technique inexistante.
la facilité de la manipulation n'y changera rien.
Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de garantir, par ce que j'appellerai de bonnes pratiques de programmation, la confidentialité des données dont certaines sont personnelles ?
Méph'
-- C'est parce que la lumière est plus rapide que le son que certains ont l'air brillants avant d'avoir l'air con
Albert ARIBAUD a écrit :
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
pour intrusion dans un système informatique ;
D'accord, mais la manipulation qui a permis de découvrir la faille est
justifiable par la nécessité de faire fonctionner le logiciel client.
Le logiciel est totalement opaque, la documentation technique inexistante.
la facilité de la manipulation n'y changera rien.
Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de
garantir, par ce que j'appellerai de bonnes pratiques de programmation,
la confidentialité des données dont certaines sont personnelles ?
Méph'
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer pour intrusion dans un système informatique ;
D'accord, mais la manipulation qui a permis de découvrir la faille est justifiable par la nécessité de faire fonctionner le logiciel client. Le logiciel est totalement opaque, la documentation technique inexistante.
la facilité de la manipulation n'y changera rien.
Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de garantir, par ce que j'appellerai de bonnes pratiques de programmation, la confidentialité des données dont certaines sont personnelles ?
Méph'
-- C'est parce que la lumière est plus rapide que le son que certains ont l'air brillants avant d'avoir l'air con
Albert ARIBAUD
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
Albert ARIBAUD a écrit :
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer pour intrusion dans un système informatique ;
D'accord, mais la manipulation qui a permis de découvrir la faille est justifiable par la nécessité de faire fonctionner le logiciel client. Le logiciel est totalement opaque, la documentation technique inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais, mais là on parle de droit).
la facilité de la manipulation n'y changera rien.
Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de garantir, par ce que j'appellerai de bonnes pratiques de programmation, la confidentialité des données dont certaines sont personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL pour la question. :)
Amicalement, -- Albert.
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
Albert ARIBAUD a écrit :
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
pour intrusion dans un système informatique ;
D'accord, mais la manipulation qui a permis de découvrir la faille est
justifiable par la nécessité de faire fonctionner le logiciel client. Le
logiciel est totalement opaque, la documentation technique inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole
pas des manips, on demande à son auteur d'en faire une meilleure (je
sais, ça ne donne rien de bon en termes de délais, mais là on parle de
droit).
la facilité de la manipulation n'y changera rien.
Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de
garantir, par ce que j'appellerai de bonnes pratiques de programmation,
la confidentialité des données dont certaines sont personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL
pour la question. :)
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
Albert ARIBAUD a écrit :
A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer pour intrusion dans un système informatique ;
D'accord, mais la manipulation qui a permis de découvrir la faille est justifiable par la nécessité de faire fonctionner le logiciel client. Le logiciel est totalement opaque, la documentation technique inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais, mais là on parle de droit).
la facilité de la manipulation n'y changera rien.
Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de garantir, par ce que j'appellerai de bonnes pratiques de programmation, la confidentialité des données dont certaines sont personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL pour la question. :)
Amicalement, -- Albert.
patpro ~ Patrick Proniewski
In article , Albert ARIBAUD wrote:
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
> Albert ARIBAUD a écrit : > >> A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer >> pour intrusion dans un système informatique ; > > D'accord, mais la manipulation qui a permis de découvrir la faille est > justifiable par la nécessité de faire fonctionner le logiciel client. Le > logiciel est totalement opaque, la documentation technique inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais, mais là on parle de droit).
néanmoins, il a le droit de chercher les failles si il est responsable de la sécurité et/ou du bon fonctionnement de l'infrastructure informatique/réseau.
Il peut aussi sans problème dénoncer la politique de mot de passe de l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte d'utilisation des outils informatiques qui prohibe le partage de mot de passe, l'utilisation d'un même mot de passe au delà d'une durée données ... bref une raison valable aux yeux de la hiérarchie pour mettre le logiciel en quarantaine.
>> la facilité de la manipulation n'y changera rien. > > Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de > garantir, par ce que j'appellerai de bonnes pratiques de programmation, > la confidentialité des données dont certaines sont personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL pour la question. :)
je pense que dans ce cas il y a obligation de moyen, pas de résultat (le mot de passe est un moyen).
patpro
-- http://www.patpro.net/
In article <pan.2007.10.09.14.43.07@free.fr>,
Albert ARIBAUD <albert.aribaud@free.fr> wrote:
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
> Albert ARIBAUD a écrit :
>
>> A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
>> pour intrusion dans un système informatique ;
>
> D'accord, mais la manipulation qui a permis de découvrir la faille est
> justifiable par la nécessité de faire fonctionner le logiciel client. Le
> logiciel est totalement opaque, la documentation technique inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole
pas des manips, on demande à son auteur d'en faire une meilleure (je
sais, ça ne donne rien de bon en termes de délais, mais là on parle de
droit).
néanmoins, il a le droit de chercher les failles si il est responsable
de la sécurité et/ou du bon fonctionnement de l'infrastructure
informatique/réseau.
Il peut aussi sans problème dénoncer la politique de mot de passe de
l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte
d'utilisation des outils informatiques qui prohibe le partage de mot de
passe, l'utilisation d'un même mot de passe au delà d'une durée données
... bref une raison valable aux yeux de la hiérarchie pour mettre le
logiciel en quarantaine.
>> la facilité de la manipulation n'y changera rien.
>
> Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de
> garantir, par ce que j'appellerai de bonnes pratiques de programmation,
> la confidentialité des données dont certaines sont personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL
pour la question. :)
je pense que dans ce cas il y a obligation de moyen, pas de résultat (le
mot de passe est un moyen).
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
> Albert ARIBAUD a écrit : > >> A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer >> pour intrusion dans un système informatique ; > > D'accord, mais la manipulation qui a permis de découvrir la faille est > justifiable par la nécessité de faire fonctionner le logiciel client. Le > logiciel est totalement opaque, la documentation technique inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais, mais là on parle de droit).
néanmoins, il a le droit de chercher les failles si il est responsable de la sécurité et/ou du bon fonctionnement de l'infrastructure informatique/réseau.
Il peut aussi sans problème dénoncer la politique de mot de passe de l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte d'utilisation des outils informatiques qui prohibe le partage de mot de passe, l'utilisation d'un même mot de passe au delà d'une durée données ... bref une raison valable aux yeux de la hiérarchie pour mettre le logiciel en quarantaine.
>> la facilité de la manipulation n'y changera rien. > > Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de > garantir, par ce que j'appellerai de bonnes pratiques de programmation, > la confidentialité des données dont certaines sont personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL pour la question. :)
je pense que dans ce cas il y a obligation de moyen, pas de résultat (le mot de passe est un moyen).
patpro
-- http://www.patpro.net/
Professeur M
Albert ARIBAUD a écrit :
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais,
Je pousse la parano un peu plus loin : on n'a donc pas le droit de vérifier que les données transmises correspondent aux données saisies ? Il est parfaitement possible techniquement que le logiciel client en profite pour embarquer des fichiers autres que ceux souhaités.
Imagine que le DRH veuille, en complicité avec le programmeur, se faire envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes ?
Le «reverse engineering» n'est-il pas *parfois* légitime ?
mais là on parle de droit
C'est bien ce que j'attends des réponses à ma question. La bidouille est faite, le signalement aussi mais je veux me blinder complètement pour éviter les emmerdes. D'autant que je ne suis pas toujours en odeur de sainteté, à force d'avoir la grande gueule ;-)
Méph'
-- C'est parce que la lumière est plus rapide que le son que certains ont l'air brillants avant d'avoir l'air con
Albert ARIBAUD a écrit :
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole
pas des manips, on demande à son auteur d'en faire une meilleure (je
sais, ça ne donne rien de bon en termes de délais,
Je pousse la parano un peu plus loin : on n'a donc pas le droit de
vérifier que les données transmises correspondent aux données saisies ?
Il est parfaitement possible techniquement que le logiciel client en
profite pour embarquer des fichiers autres que ceux souhaités.
Imagine que le DRH veuille, en complicité avec le programmeur, se faire
envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes ?
Le «reverse engineering» n'est-il pas *parfois* légitime ?
mais là on parle de droit
C'est bien ce que j'attends des réponses à ma question.
La bidouille est faite, le signalement aussi mais je veux me blinder
complètement pour éviter les emmerdes. D'autant que je ne suis pas
toujours en odeur de sainteté, à force d'avoir la grande gueule ;-)
Méph'
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais,
Je pousse la parano un peu plus loin : on n'a donc pas le droit de vérifier que les données transmises correspondent aux données saisies ? Il est parfaitement possible techniquement que le logiciel client en profite pour embarquer des fichiers autres que ceux souhaités.
Imagine que le DRH veuille, en complicité avec le programmeur, se faire envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes ?
Le «reverse engineering» n'est-il pas *parfois* légitime ?
mais là on parle de droit
C'est bien ce que j'attends des réponses à ma question. La bidouille est faite, le signalement aussi mais je veux me blinder complètement pour éviter les emmerdes. D'autant que je ne suis pas toujours en odeur de sainteté, à force d'avoir la grande gueule ;-)
Méph'
-- C'est parce que la lumière est plus rapide que le son que certains ont l'air brillants avant d'avoir l'air con
Professeur M
patpro ~ Patrick Proniewski a écrit :
néanmoins, il a le droit de chercher les failles si il est responsable de la sécurité et/ou du bon fonctionnement de l'infrastructure informatique/réseau.
merci de ton soutien ;-) Une référence de texte ou de jurisprudence ?
Cela dit, je ne suis pas responsable de la sécurité du serveur FTP, tout juste d'une toute petite partie du réseau où est installé le client. En plus ce n'est pas mon métier, juste une fonction, officielle quand même, mais un peu annexe.
Il peut aussi sans problème dénoncer la politique de mot de passe de l'application.
C'est fait, en plus d'un tas d'autres griefs
D'ailleurs, peut être l'entreprise a-t-elle une charte d'utilisation des outils informatiques qui prohibe le partage de mot de passe,
non
l'utilisation d'un même mot de passe au delà d'une durée données
T'es fou ? je vais avoir une émeute ;-)
... bref une raison valable aux yeux de la hiérarchie pour mettre le logiciel en quarantaine.
« quarantaine » curieux nom pour la poubelle...
-- C'est parce que la lumière est plus rapide que le son que certains ont l'air brillants avant d'avoir l'air con
patpro ~ Patrick Proniewski a écrit :
néanmoins, il a le droit de chercher les failles si il est responsable
de la sécurité et/ou du bon fonctionnement de l'infrastructure
informatique/réseau.
merci de ton soutien ;-)
Une référence de texte ou de jurisprudence ?
Cela dit, je ne suis pas responsable de la sécurité du serveur FTP, tout
juste d'une toute petite partie du réseau où est installé le client.
En plus ce n'est pas mon métier, juste une fonction, officielle quand
même, mais un peu annexe.
Il peut aussi sans problème dénoncer la politique de mot de passe de
l'application.
C'est fait, en plus d'un tas d'autres griefs
D'ailleurs, peut être l'entreprise a-t-elle une charte
d'utilisation des outils informatiques qui prohibe le partage de mot de
passe,
non
l'utilisation d'un même mot de passe au delà d'une durée données
T'es fou ? je vais avoir une émeute ;-)
... bref une raison valable aux yeux de la hiérarchie pour mettre le
logiciel en quarantaine.
« quarantaine » curieux nom pour la poubelle...
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
néanmoins, il a le droit de chercher les failles si il est responsable de la sécurité et/ou du bon fonctionnement de l'infrastructure informatique/réseau.
merci de ton soutien ;-) Une référence de texte ou de jurisprudence ?
Cela dit, je ne suis pas responsable de la sécurité du serveur FTP, tout juste d'une toute petite partie du réseau où est installé le client. En plus ce n'est pas mon métier, juste une fonction, officielle quand même, mais un peu annexe.
Il peut aussi sans problème dénoncer la politique de mot de passe de l'application.
C'est fait, en plus d'un tas d'autres griefs
D'ailleurs, peut être l'entreprise a-t-elle une charte d'utilisation des outils informatiques qui prohibe le partage de mot de passe,
non
l'utilisation d'un même mot de passe au delà d'une durée données
T'es fou ? je vais avoir une émeute ;-)
... bref une raison valable aux yeux de la hiérarchie pour mettre le logiciel en quarantaine.
« quarantaine » curieux nom pour la poubelle...
-- C'est parce que la lumière est plus rapide que le son que certains ont l'air brillants avant d'avoir l'air con
patpro ~ Patrick Proniewski
In article <470b9713$0$27399$, Professeur Méphisto wrote:
patpro ~ Patrick Proniewski a écrit :
> néanmoins, il a le droit de chercher les failles si il est responsable > de la sécurité et/ou du bon fonctionnement de l'infrastructure > informatique/réseau.
merci de ton soutien ;-) Une référence de texte ou de jurisprudence ?
non, désolé :/
patpro
-- http://www.patpro.net/
In article <470b9713$0$27399$ba4acef3@news.orange.fr>,
Professeur Méphisto <professeur.mephisto@wanadoodoo.fr> wrote:
patpro ~ Patrick Proniewski a écrit :
> néanmoins, il a le droit de chercher les failles si il est responsable
> de la sécurité et/ou du bon fonctionnement de l'infrastructure
> informatique/réseau.
merci de ton soutien ;-)
Une référence de texte ou de jurisprudence ?
In article <470b9713$0$27399$, Professeur Méphisto wrote:
patpro ~ Patrick Proniewski a écrit :
> néanmoins, il a le droit de chercher les failles si il est responsable > de la sécurité et/ou du bon fonctionnement de l'infrastructure > informatique/réseau.
merci de ton soutien ;-) Une référence de texte ou de jurisprudence ?
non, désolé :/
patpro
-- http://www.patpro.net/
Albert ARIBAUD
Le Tue, 09 Oct 2007 16:51:23 +0200, patpro ~ Patrick Proniewski a écrit:
In article , Albert ARIBAUD wrote:
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
> Albert ARIBAUD a écrit : > >> A priori, je dirais que le bricoleur risque de voir la boîte >> l'attaquer pour intrusion dans un système informatique ; > > D'accord, mais la manipulation qui a permis de découvrir la faille > est justifiable par la nécessité de faire fonctionner le logiciel > client. Le logiciel est totalement opaque, la documentation technique > inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais, mais là on parle de droit).
néanmoins, il a le droit de chercher les failles si il est responsable de la sécurité et/ou du bon fonctionnement de l'infrastructure informatique/réseau.
Le Code Pénal ne prévoit pas cette excuse dans ses articles 323-1 à 323-3.
Il peut aussi sans problème dénoncer la politique de mot de passe de l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte d'utilisation des outils informatiques qui prohibe le partage de mot de passe, l'utilisation d'un même mot de passe au delà d'une durée données ... bref une raison valable aux yeux de la hiérarchie pour mettre le logiciel en quarantaine.
Il peut très bien faire tout ça, mais si en plus de décrire tout cela il effectue les manipulations décrites, celles-ci risquent de se voir retenues comme accès frauduleux à un système d'information automatisé, aggravé éventuellement des actes de modification.
>> la facilité de la manipulation n'y changera rien. > > Oui, mais le développeur et son commanditaire ne sont-ils pas tenus > de garantir, par ce que j'appellerai de bonnes pratiques de > programmation, la confidentialité des données dont certaines sont > personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL pour la question. :)
je pense que dans ce cas il y a obligation de moyen, pas de résultat (le mot de passe est un moyen).
Il ne me semble pas que la question du type d'obligation de pose ici ; je viserais plutôt, à voir ce qui est décrit, le fait que les moyens mis en oeuvre sont notoirement insuffisants au regard de l'état de l'art.
Amicalement, -- Albert.
Le Tue, 09 Oct 2007 16:51:23 +0200, patpro ~ Patrick Proniewski a écrit:
In article <pan.2007.10.09.14.43.07@free.fr>,
Albert ARIBAUD <albert.aribaud@free.fr> wrote:
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
> Albert ARIBAUD a écrit :
>
>> A priori, je dirais que le bricoleur risque de voir la boîte
>> l'attaquer pour intrusion dans un système informatique ;
>
> D'accord, mais la manipulation qui a permis de découvrir la faille
> est justifiable par la nécessité de faire fonctionner le logiciel
> client. Le logiciel est totalement opaque, la documentation technique
> inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne
bricole pas des manips, on demande à son auteur d'en faire une
meilleure (je sais, ça ne donne rien de bon en termes de délais, mais
là on parle de droit).
néanmoins, il a le droit de chercher les failles si il est responsable
de la sécurité et/ou du bon fonctionnement de l'infrastructure
informatique/réseau.
Le Code Pénal ne prévoit pas cette excuse dans ses articles 323-1 à 323-3.
Il peut aussi sans problème dénoncer la politique de mot de passe de
l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte
d'utilisation des outils informatiques qui prohibe le partage de mot de
passe, l'utilisation d'un même mot de passe au delà d'une durée données
... bref une raison valable aux yeux de la hiérarchie pour mettre le
logiciel en quarantaine.
Il peut très bien faire tout ça, mais si en plus de décrire tout cela il
effectue les manipulations décrites, celles-ci risquent de se voir
retenues comme accès frauduleux à un système d'information automatisé,
aggravé éventuellement des actes de modification.
>> la facilité de la manipulation n'y changera rien.
>
> Oui, mais le développeur et son commanditaire ne sont-ils pas tenus
> de garantir, par ce que j'appellerai de bonnes pratiques de
> programmation, la confidentialité des données dont certaines sont
> personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL
pour la question. :)
je pense que dans ce cas il y a obligation de moyen, pas de résultat (le
mot de passe est un moyen).
Il ne me semble pas que la question du type d'obligation de pose ici ; je
viserais plutôt, à voir ce qui est décrit, le fait que les moyens mis en
oeuvre sont notoirement insuffisants au regard de l'état de l'art.
Le Tue, 09 Oct 2007 16:51:23 +0200, patpro ~ Patrick Proniewski a écrit:
In article , Albert ARIBAUD wrote:
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:
> Albert ARIBAUD a écrit : > >> A priori, je dirais que le bricoleur risque de voir la boîte >> l'attaquer pour intrusion dans un système informatique ; > > D'accord, mais la manipulation qui a permis de découvrir la faille > est justifiable par la nécessité de faire fonctionner le logiciel > client. Le logiciel est totalement opaque, la documentation technique > inexistante.
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais, mais là on parle de droit).
néanmoins, il a le droit de chercher les failles si il est responsable de la sécurité et/ou du bon fonctionnement de l'infrastructure informatique/réseau.
Le Code Pénal ne prévoit pas cette excuse dans ses articles 323-1 à 323-3.
Il peut aussi sans problème dénoncer la politique de mot de passe de l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte d'utilisation des outils informatiques qui prohibe le partage de mot de passe, l'utilisation d'un même mot de passe au delà d'une durée données ... bref une raison valable aux yeux de la hiérarchie pour mettre le logiciel en quarantaine.
Il peut très bien faire tout ça, mais si en plus de décrire tout cela il effectue les manipulations décrites, celles-ci risquent de se voir retenues comme accès frauduleux à un système d'information automatisé, aggravé éventuellement des actes de modification.
>> la facilité de la manipulation n'y changera rien. > > Oui, mais le développeur et son commanditaire ne sont-ils pas tenus > de garantir, par ce que j'appellerai de bonnes pratiques de > programmation, la confidentialité des données dont certaines sont > personnelles ?
Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL pour la question. :)
je pense que dans ce cas il y a obligation de moyen, pas de résultat (le mot de passe est un moyen).
Il ne me semble pas que la question du type d'obligation de pose ici ; je viserais plutôt, à voir ce qui est décrit, le fait que les moyens mis en oeuvre sont notoirement insuffisants au regard de l'état de l'art.
Amicalement, -- Albert.
Albert ARIBAUD
Le Tue, 09 Oct 2007 17:13:36 +0200, patpro ~ Patrick Proniewski a écrit:
In article <470b9713$0$27399$, Professeur Méphisto wrote:
patpro ~ Patrick Proniewski a écrit :
> néanmoins, il a le droit de chercher les failles si il est > responsable de la sécurité et/ou du bon fonctionnement de > l'infrastructure informatique/réseau.
merci de ton soutien ;-) Une référence de texte ou de jurisprudence ?
non, désolé :/
Les textes de base sont le Code Pénal, articles 323-1 à 323-3.
En termes de jurisprudence, voir l'affaire Tati ou l'affaire Guillermito, qui sans tomber pile sur le sujet doivent donner des pistes intéressantes.
Amicalement, -- Albert.
Le Tue, 09 Oct 2007 17:13:36 +0200, patpro ~ Patrick Proniewski a écrit:
In article <470b9713$0$27399$ba4acef3@news.orange.fr>,
Professeur Méphisto <professeur.mephisto@wanadoodoo.fr> wrote:
patpro ~ Patrick Proniewski a écrit :
> néanmoins, il a le droit de chercher les failles si il est
> responsable de la sécurité et/ou du bon fonctionnement de
> l'infrastructure informatique/réseau.
merci de ton soutien ;-)
Une référence de texte ou de jurisprudence ?
non, désolé :/
Les textes de base sont le Code Pénal, articles 323-1 à 323-3.
En termes de jurisprudence, voir l'affaire Tati ou l'affaire Guillermito,
qui sans tomber pile sur le sujet doivent donner des pistes intéressantes.
Le Tue, 09 Oct 2007 17:13:36 +0200, patpro ~ Patrick Proniewski a écrit:
In article <470b9713$0$27399$, Professeur Méphisto wrote:
patpro ~ Patrick Proniewski a écrit :
> néanmoins, il a le droit de chercher les failles si il est > responsable de la sécurité et/ou du bon fonctionnement de > l'infrastructure informatique/réseau.
merci de ton soutien ;-) Une référence de texte ou de jurisprudence ?
non, désolé :/
Les textes de base sont le Code Pénal, articles 323-1 à 323-3.
En termes de jurisprudence, voir l'affaire Tati ou l'affaire Guillermito, qui sans tomber pile sur le sujet doivent donner des pistes intéressantes.
Amicalement, -- Albert.
Albert ARIBAUD
Le Tue, 09 Oct 2007 14:52:23 +0000, Professeur Méphisto a écrit:
Albert ARIBAUD a écrit :
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais,
Je pousse la parano un peu plus loin : on n'a donc pas le droit de vérifier que les données transmises correspondent aux données saisies ?
Cela, si. Par contre, effectuer une session FTP peut être considéré comme un accès frauduleux.
Il est parfaitement possible techniquement que le logiciel client en profite pour embarquer des fichiers autres que ceux souhaités.
Imagine que le DRH veuille, en complicité avec le programmeur, se faire envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes ?
Ce serait une énorme connerie du DRH, qui engagerait de plus la responsabilité du DSI et du patron, pour atteinte à la vie privée -- du moins si le salarié a bien identifié comme personnel le dossier où se trouvait ce fichier.
Mais bon, on dérive de la question initiale, là.
Le «reverse engineering» n'est-il pas *parfois* légitime ?
Parfois, oui : à des fins d'interopérabilité.
mais là on parle de droit
C'est bien ce que j'attends des réponses à ma question. La bidouille est faite, le signalement aussi mais je veux me blinder complètement pour éviter les emmerdes. D'autant que je ne suis pas toujours en odeur de sainteté, à force d'avoir la grande gueule ;-)
Se limiter à l'observation passive, telle qu'elle peut être faite dans le cadre du travail.
Ne pas mentionner les sessions FTP frauduleuses.
Ne pas présenter comme un cas d'école ce qui, en fin de compte, est un cas réel. :)
Consulter un avocat.
Amicalement, -- Albert.
Le Tue, 09 Oct 2007 14:52:23 +0000, Professeur Méphisto a écrit:
Albert ARIBAUD a écrit :
Cela n'est pas une excuse : si la documentation est opaque, on ne
bricole pas des manips, on demande à son auteur d'en faire une
meilleure (je sais, ça ne donne rien de bon en termes de délais,
Je pousse la parano un peu plus loin : on n'a donc pas le droit de
vérifier que les données transmises correspondent aux données saisies ?
Cela, si. Par contre, effectuer une session FTP peut être considéré comme
un accès frauduleux.
Il est parfaitement possible techniquement que le logiciel client en
profite pour embarquer des fichiers autres que ceux souhaités.
Imagine que le DRH veuille, en complicité avec le programmeur, se faire
envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes
?
Ce serait une énorme connerie du DRH, qui engagerait de plus la
responsabilité du DSI et du patron, pour atteinte à la vie privée -- du
moins si le salarié a bien identifié comme personnel le dossier où se
trouvait ce fichier.
Mais bon, on dérive de la question initiale, là.
Le «reverse engineering» n'est-il pas *parfois* légitime ?
Parfois, oui : à des fins d'interopérabilité.
mais là on parle de droit
C'est bien ce que j'attends des réponses à ma question. La bidouille est
faite, le signalement aussi mais je veux me blinder complètement pour
éviter les emmerdes. D'autant que je ne suis pas toujours en odeur de
sainteté, à force d'avoir la grande gueule ;-)
Se limiter à l'observation passive, telle qu'elle peut être faite dans le
cadre du travail.
Ne pas mentionner les sessions FTP frauduleuses.
Ne pas présenter comme un cas d'école ce qui, en fin de compte, est un
cas réel. :)
Le Tue, 09 Oct 2007 14:52:23 +0000, Professeur Méphisto a écrit:
Albert ARIBAUD a écrit :
Cela n'est pas une excuse : si la documentation est opaque, on ne bricole pas des manips, on demande à son auteur d'en faire une meilleure (je sais, ça ne donne rien de bon en termes de délais,
Je pousse la parano un peu plus loin : on n'a donc pas le droit de vérifier que les données transmises correspondent aux données saisies ?
Cela, si. Par contre, effectuer une session FTP peut être considéré comme un accès frauduleux.
Il est parfaitement possible techniquement que le logiciel client en profite pour embarquer des fichiers autres que ceux souhaités.
Imagine que le DRH veuille, en complicité avec le programmeur, se faire envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes ?
Ce serait une énorme connerie du DRH, qui engagerait de plus la responsabilité du DSI et du patron, pour atteinte à la vie privée -- du moins si le salarié a bien identifié comme personnel le dossier où se trouvait ce fichier.
Mais bon, on dérive de la question initiale, là.
Le «reverse engineering» n'est-il pas *parfois* légitime ?
Parfois, oui : à des fins d'interopérabilité.
mais là on parle de droit
C'est bien ce que j'attends des réponses à ma question. La bidouille est faite, le signalement aussi mais je veux me blinder complètement pour éviter les emmerdes. D'autant que je ne suis pas toujours en odeur de sainteté, à force d'avoir la grande gueule ;-)
Se limiter à l'observation passive, telle qu'elle peut être faite dans le cadre du travail.
Ne pas mentionner les sessions FTP frauduleuses.
Ne pas présenter comme un cas d'école ce qui, en fin de compte, est un cas réel. :)
