Discussion :

[hegros]

les iraniens ne feront pas d'essais ? NON ....

Il y a pleins de pays qui font des essais non ? Ils doivent faire quoi les iraniens des OGM ?

mais on a pas le droit de compromettre la sécurité avec un OS sensible aux virus..

Il n'y a aucun système informatique insensible aux virus que se soit un Unix RT machin ou window certifié seveso ou pas.


Ce n'est pas une solution technique, et d'autant moins logicielle, qui assure le plus haut degré de sécurité dans ces systèmes. La sécurité logicielle niveau OS c'est comme les rétro-virus chez l'homme, une base de connaissance.

D'ailleurs est-ce que tu connais un système insensible aux virus ? Il y a eu une expérience avec un homme est une puce électronique intégré dans sa main ou son bras et le résultat c'est qu'il y a eu effectivement de la transmission d'un virus.

Là où je suis plutôt d'accord c'est que dans les systèmes industriels il n'y a pas toujours de très haut niveau de sécurité niveau informatique bien que ce risque soit contrôlé.


http://www.futura-sciences.com/fr/ne...r-venus_25525/

les solutions sont électromécaniques pas informatique

[zaventem]

J'ai peut-être raté une étape mais comment est-on passé des "attaque les infrastructures industrielles" à "attaque les infrastructures nucléaires"?

[el_slapper]

J'ai peut-être raté une étape mais comment est-on passé des "attaque les infrastructures industrielles" à "attaque les infrastructures nucléaires"?

Parceque les systèmes SIEMENS attaqués par le virus en question sont, entre autres, utilisés dans les installations nucléaires iraniennes.

[jacqueline]

Il y a pleins de pays qui font des essais non ? Ils doivent faire quoi les iraniens des OGM ?



Il n'y a aucun système informatique insensible aux virus que se soit un Unix RT machin ou window certifié seveso ou pas.


Ce n'est pas une solution technique, et d'autant moins logicielle, qui assure le plus haut degré de sécurité dans ces systèmes. La sécurité logicielle niveau OS c'est comme les rétro-virus chez l'homme, une base de connaissance.

D'ailleurs est-ce que tu connais un système insensible aux virus ? Il y a eu une expérience avec un homme est une puce électronique intégré dans sa main ou son bras et le résultat c'est qu'il y a eu effectivement de la transmission d'un virus.

Là où je suis plutôt d'accord c'est que dans les systèmes industriels il n'y a pas toujours de très haut niveau de sécurité niveau informatique bien que ce risque soit contrôlé.


http://www.futura-sciences.com/fr/ne...r-venus_25525/

les solutions sont électromécaniques pas informatique

Je ne vais pas écrire dix pages sur les droits d'Unix, sur comment on sécurise le systéme et les applications..et comment on peut empécher un virus de s'installer, ou de s'éxécuter.

Ni expliquer comment fonctionne le systéme des secure levels de FreeBSD et OpenBSD, avec les chflags.

Pourquoi y a t-il des correctifs de sécurité ? S'ils avaient testé leur OS ou leur programme, il y en aurait beaucoup moins.

La bible est le site du CWE, qui recense les vulnérabilités et les classent par famille . ( comme par exemple de ne pas avoir controlé les données d'entrées, ou d'utiliser un systéme de cryptage devenu ob solète, faire éxécuter un rpogramme avec des droits trop élevés..etc etc )

Ils ont sorti le top 25.

C 'est la bible du programmeur. Si les gens épluchaient leur OS avec ce bouquin, il y auraient moins de vulnérabilités..

Open BSD font des audits de code.

C'est ce que font aussi les éditeurs de l' OS certifié..

C'est beaucoup plus long.



Bien d'accord sur électromécanique.

Les systémes industriels bien foutus ont des sécurités internes, et des sécurités externes indépendantes, autonomes, non informatisées. Qui sont testées régulièrement et controlées par les DRIRE lorsque c'est dans leur domaine.

Parfois, selon le niveau de risque une protection contre les ordres maintenus ( soit par un bug logiciel, soit par une panne de carte de sortie, soit un court circuit ).

En cas de panne de capteur ou de liaison de télémesure, il y a ce qu 'on appelle la conduite en mode dégradé.

En dernier ressort , les mises en état de sécurité , qui peut être le status quo si un organe ouvert à fond ou fermé ne sont pas des positions de sécurité.

Lorsqu'il est nécessaire de doubler les sytémes, en général protection contre l'incendie, les cables empruntent des chemins différents, les salles de commande sont nettement séparées. On évite les "modes communs" ( applicable à bien des choses..)

Toutes ces sécurités , à l'époque où il n' y avait pas de normes, étaient le B A BA de tout automaticien, l' expérience, puis des méthodes : analyse des modes de défaillance , analyse de risques.

Au tout début, vu le prix des calculateurs, ces installations étaient réservées aux gros systèmes, et donc étudiées et testées par une équipe aux multiples compétences.

La norme était que si on bouzillait quelque chose on était tous virés sur le champ et que c'en était fini de l'informatisation.

EDF a refusé l'informatisation des PWR, suite à un gros pépin dans une centrale thermique classique avec une première expérience de relayage statique. Le calculateur se contente de relever des mesures pour une analyse ultérieure.

Les EPR seront inévitablement pilotées 100 % informatique, mais avec des sécurités externes classiques.

Mais j'hallucine de voir le CNRS se lancer dans l'étude d'un controle commande de nuke, avec trois ingés débutants, qui n'ont jamais mis les pieds dans une centrale nucléaire..et qui n'ont aucune expérience de l'info indus..

Plus tard , les automates étant devenus plus performants, on a confié des automatisations à de jeunes ingés , pour leur premier boulot..combiné à un prestataire qui n'a pas assez d'expérience , ne connait pas du tout le processus industriel qu 'il va piloter, et qui embauche un stagiaire ou un intérimaire . Ca donne le même résultat que si j'allais installer SAP dans une boite..

Pas d'expérience non plus pour tester leur logiciel..

Une autre particularité du temps réel, c'est le découpage du sytéme de conduite en taches, selon des priorités et la synchronisation des taches. Ce n'est pas inné. ca demande donc une bonne connaissance du processus industriel qu 'on pilote.

si non met un calculateur, c'est pour calculer . En général c'est de la régulation, numérique donc.. sur un gros systéme c'est un peu space..par rapport à la théorie..

Autre chose que j'ai vu, mais ça c'est du à un pingre de chef : L'automate qui fait tout.. ( non on ne va pas en acheter trois ) j'ai vu ça dans un audit, et je leur ai dit : vous avez oublié la prise pour le tuyau de l'aspirateur, autrement l'automate pouvait faire le ménage..


Il y a des fonctions qu'il faut nettement séparer, histoire de ne pas tout perdre sur une panne. On nest dans le noir complet.. Il est beaucoup plus difficile d'évaluer la charge maximum , et surtout de la tester . L'automate ne peut plus suivre et se met en rideau.. on perd des fonctions vitales.. qui isolées sont plus faciles à tester, et ne sont pas à la merci d'un bug dans une appli secondaire..

Mais c'est un job passionnant et bien payé par rapport au SI.

[jacqueline]

J'ai peut-être raté une étape mais comment est-on passé des "attaque les infrastructures industrielles" à "attaque les infrastructures nucléaires"?

Tout simplement parce qu 'ils*utilisent le même système et la même appli de supervision, que pour une usine d'embouteillage..

WinCC est très répandu. ( c'était donc une bonne cible pour les pirates )

Pas de problèmes si c'est une petite usine, mais pas dans un site à risque et surtout pas en réseau..


Avant ces systémes industriels étaient bien isolés, maitenant il faut les relier au SI...ca se fait sans problème, pour la lecture on peut blinder et on passe par un serveur pour ne pas trop solliciter l'automate..

Récement j'ai découvert que des boites avaient besoin que l' ERP envoie des données dans les automates de la chaine de fabrication.

Le loup est rentré dans la bergerie..

Comment l'automate peut savoir si c'est l'ERP ou un rootkit qui lui envoie des données ?


ou pire (car si on a mis une signature dans l'appli ce serait inefficace) un rootkit qui fait réagir l' ERP afin qu 'il envoie une mauvaise donnée ?

Parfois l'ERP ( Ezpublish ) est relié au site de commande en ligne

[minimwa25]

Ce qui est le plus effrayant là dedans, c'est que l'on joue mtn avec la vie des gens

[yoyo88]

Récement j'ai découvert que des boites avaient besoin que l' ERP envoie des données dans les automates de la chaine de fabrication.

Le loup est rentré dans la bergerie..

Comment l'automate peut savoir si c'est l'ERP ou un rootkit qui lui envoie des données ?


ou pire (car si on a mis une signature dans l'appli ce serait inefficace) un rootkit qui fait réagir l' ERP afin qu 'il envoie une mauvaise donnée ?

Parfois l'ERP ( Ezpublish ) est relié au site de commande en ligne

Rien d’anormal ou de révolutionnaire, les ERP servent en partie a sa, certains etait plus spécialiser que d'autres dans se domaine.

[hegros]

J'ai peut-être raté une étape mais comment est-on passé des "attaque les infrastructures industrielles" à "attaque les infrastructures nucléaires"?

Parce que stratégiquement c'est plus intéressant et que le cas échéant cela fait plus de dégâts.

Il ne faut pas oublier que siemens c'est un peu du tout et n'importe quoi ils font aussi bien du matériel pour les centrales que des machines à laver, ce ne sont pas des spécialistes des centrales nucléaires.


Et mettre le paquet en sécurité informatique ou autre cela n'exclura jamais les contrôles et vérification manuels des états des machines.

[Katleen Erna]

Mise à jour du 22.11.2010 par Katleen
Des indices dans le code de Stuxnet informent sur son créateur, une équipe de 6 à 10 personnes mandatées par une nation d'après les experts

Un chercheur travaillant pour Securicon (entreprise spécialisée dans les traces numériques ou empreintes digitales que les hackers laissent derrière eux) s'est minutieusement penché sur les entrailles de Stuxnet.

Son analyse a ainsi révélé que le malware est constitué de plusieurs blocs distincts. L'un cible les systèmes de contrôle industriels, un autre renferme les méthodes de diffusion du ver et un dernier concerne la manière dont ses créateurs avaient prévu de dialoguer avec lui et de le contrôler.

Autrement dit, il se pourrait qu'une partie du code puisse "parler" et fournir une piste menant à son développeur.

En effet, le logiciel prévu pour s'en prendre aux PLCs (Programmable Logic Controllers) des centrales nucléaires. De quoi prendre le contrôle à distances de certains appareils, comme des pompes ou des moteurs.

Pour savoir comment prendre la main sur de tels équipements, il faut en connaître un rayon sur le sujet, estime Tom Parker. Il fallait par exemple savoir quel langage de programmation a été utilisé, etc. De quoi établir une liste de suspects bien ciblée.

Comme "les compagnies de l'Ouest ont tendance à automatiser toutes leurs productions", il est probable qu'il s'agisse là d'un indice sur la provenance du ver. Pour concevoir Stuxnet, il fallait connaître les systèmes nucléaires d'Iran et probablement y avoir accès.

Mais l'expert de noter que cette partie est la seule à être hautement sophistiquée : "les parties liées à son implémentation dans un système, ainsi qu'à son contrôle ne sont pas si avancées que cela" comparé à d'autres malwares, déclare-t-il.

A son avis, des pirates informatiques chevronnés n'auraient pas eu recours à des codes aussi rudimentaires pour ces deux parties (distribution et contrôle).

Il suggère que l'assemblage du code de Stuxnet a été réalisé par une nation, plutôt que par une branche de crime organisé.

Et pour lui, le pays derrière tout cela pourrait avoir eu un rôle à jouer dans le processus de développement de la plateforme PLC, en demandant à une nation de l'Ouest de s'en occuper, avant d'y ajouter son propre code pour les deux autres parties.

Le chercheur explique que ses analyses révèlent que c'est probablement un groupe de 6 à 10 personnes est à l'origine.

En complément de ces découvertes, des informations apportées par Symantec avancent que ce sont les contrôleurs des fréquences situées entre 807 et 1210 Hz qui étaient visés. Ces dispositifs permettent la régulation d'un moteur.
Une telle précision montre que les cibles étaient clairement définies.

Symantec se demande si Stuxnet a atteint son objectif, et pense que la réponse est positive, puisqu'aucune variante du malware n'a été observée.

Mais Tom Parker remarque que le logiciel malveillant n'a pas survécu aussi longtemps que l'auraient espéré leurs créateurs.

Sa neutralisation par les firmes de solution antivirus a du en faire fulminer plus d'un, puisque de ce fait, l'énorme investissement placé dans Stuxnet n'est plus utilisable. Dommage. Ou pas.

Sources : Securicon, Symantec

[mteirek_m]

[B]Mise à jour du 22.11.2010 par Katleen
[SIZE="3"]
.../
Dommage. Ou pas.

Sources : Securicon, Symantec

On ne peut imaginer qu'il existe encore sur notre planète des idiots qui se croient tout permis. On ne joue pas avec la pompe qui refroidit le coeur ou n'importe quelle partie d'une centrale nucleaire.

Une fois ca pete, personne n'est a l'abri, ca traverse les frontieres et ca fait des victimes partout. Risque de contamination a l'echelle mondiale.

C'est tres serieux, et il faut des investigations plus serieuses que ca, le commanditaire est un criminel potentiel très dangeureux ( que ca soit une bande d'idiots ou un état fou).

[jacqueline]

Je ne sais pas si connaître la nationalité des auteurs apportera qqchose, pour la suite..

On peut espérer toutefois que Siemens n'a pas relié directement ses automates sur son réseau de SCADA.

Leur dernier livre blanc.

Siemens WinCC and PCS 7 Security Concept whitepaper.

https://a248.e.akamai.net/cache.auto...B/wp_sec_b.pdf


Pas mal le lien ci dessous ( il n 'y a pas que les pirates ) avec des exemples de protections

http://www.tofinosecurity.com/sites/...ay%202009).pdf

Normes industrielles : IEC-61508 ( générale pour l'industrie ) IEC-61513 ( nucléaire )
IEC 61784 ( Industrial communication networks - Profiles )

http://www.surete-fonctionnement.cle...t-ses-derives/

Ca commence à être balaise


Recommandations du NRC ( sécuriité nucléaire américaine ) Application des normes pour le nucléaire


http://www.nrc.gov/reading-rm/doc-co...991/cr6991.pdf


Mais bon c'était en Iran et l' AIEA ne peut pas y mettre les pieds..Ont-ils respecté le normes ???

Les iraniens parlaient de 30 000 postes infectés : un sacré réseau..

[Katleen Erna]

Mise à jour du 23.11.2010 par Katleen
Stuxnet n'aurait "pas réussi à accomplir sa mission" en Iran, d'après le vice-président du pays

Le vice Président Iranien Ali Akbar Salehi, responsable du projet nucléaire "pacifique" de son pays, s'est exprimé publiquement à propos de l'affaire Stuxnet.

Il a ainsi déclaré que le malware n'avait pas mené a bien sa mission, puisqu'il aurait été intercepté avant d'avoir atteint sa cible (à savoir des composants clé des équipements nucléaires iraniens : les contrôleurs).

"Depuis plus d'un an, les nations de l'Ouest ont essayé d'implanter le virus dans notre environnement nucléaire afin de gêner nos activités", a-t-il déclaré, évoquant la thèse d'un complot étranger.

Malgré ce démenti officiel, il est établit que le programme nucléaire iranien souffre d'importants retards, et que des centaines de centrifugeuses ont été mises hors service dans les centrales du pays. Ces ralentissements ont-ils été causés par Stuxnet ? Ou par des problèmes techniques ? Dur de le savoir.

Source : Allocution d'Ali Akbar Salehi sur la télévision iranienne

[aladdin20]

Apres tout, il faut que la justice voit le jour, et que le (ou les coupables) paye ses fait.
Déjà, c'est pas une chose qui peu passer inaperçu, se sont des établissement NUCLÉAIRES, pas un jeu, et si on commence à ce faire ce genre de grande bêtise les uns contre les autres, il n'y aura pas qu'un seul Tchernobyl dans le monde!!!

[bugsan]

(...) responsable du projet nucléaire "pacifique" de son pays (...)

Tu voulais dire "civil" non ? On a l'habitude des articles doutant du caractère civil du projet (malgré les déclarations de plusieurs agences de renseignement US en 2007).
Mais sous entendre un caractère agressif et va-t-en-guerre c'est un peu fort de café.

[Flaburgan]

pas besoin que ce soit du militaire pour qu'il y ait un danger. Une centrale qui pète et tout le monde y reste, militaire comme civil, pirate comme juge, dictateur comme soldat de la paix...

[zaventem]

Une centrale qui pète et tout le monde y reste, militaire comme civil, pirate comme juge, dictateur comme soldat de la paix...

Bon pour faire péter une centrale nucléaire, c'est à mon avis un rien plus compliqué que cela entre les équipements redondants, les sécurités et en dernier recours l'arrêt du cœur... A mon sens le plus gros danger était de rendre la centrale inopérante pour un long moment, entrainant de graves problèmes énergétiques.

[Flaburgan]

Bien sûr, je n'imagine pas stuxnet capable de cela, et je pense que personne sur terre est assez débile pour faire péter une centrale nucléaire volontairement (enfin, j'espère )

[Lyche]

Bien sûr, je n'imagine pas stuxnet capable de cela, et je pense que personne sur terre est assez débile pour faire péter une centrale nucléaire volontairement (enfin, j'espère )

Einstein disait :

Deux choses sont infinies : l'Univers et la bêtise humaine. Mais, en ce qui
concerne l'Univers, je n'en ai pas encore acquis la certitude absolue.

je suis pas certains que personne ne tenterais le coup pour quelques milliards de $..

[atb]

je suis pas certains que personne ne tenterais le coup pour quelques milliards de $..

Tout à fait d'accord. J'en ai vu des gents qui se sont entretué pour quelques centaines d’€ . Alors là avec des millions ou milliards

Si on réfléchi bien, les intérêts en jeux, ne peuvent qu'être ceux d’un ou plusieurs états. Mais si l’Iran venait a sauté, je crois les US vont perdre gros, non ?

[Lyche]

Je crois que ça les arrangeraient, ils pourraient s'approprier le pétrole iranien par la force vue qu'actuellement aucune armée dans le monde ne peut se déplacer aussi rapidement et n'est plus puissante que celle des USA Y'a qu'a voir l'Irak.. ils n'y sont pas allé pour les beaux yeux des Irakiennes..