« La bonne or­ga­ni­sa­tion dé­pend des rai­sons qui ont pro­vo­qué la conver­gence »

Fran­çois Mo­reau de Saint Mar­tin, di­rec­teur des grands clients In­dus­trie et IT, chez Orange Bu­si­ness Ser­vices

IT for Business - - L’ENQUÊTE - MA­RIE VA­RAN­DAT

les pro­jets ré­pondent à trois prin­ci­paux pro­blèmes - sé­cu­ri­té, ex­ploi­ta­tion conju­guée des don­nées OT/IT et en­fin pro­duc­ti­vi­té -, l’or­ga­ni­sa­tion à mettre en place dé­pen­dant de la prio­ri­té don­née à une ou l’autre de ces mo­ti­va­tions. Glo­ba­le­ment, on peut es­ti­mer que, cô­té ges­tion du risque et de la cy­ber­sé­cu­ri­té, les équipes IT ont plus d’ex­pé­rience et sont donc mieux pla­cées dès lors qu’elles ont dé­jà en charge la res­pon­sa­bi­li­té de la sé­cu­ri­té de l’en­tre­prise. Idem sur la da­ta : les équipes OT n’ont gé­né­ra­le­ment pas le sa­voir-faire pour les ex­ploi­ter, d’au­tant que leurs don­nées doivent être croi­sées avec les don­nées IT. Sur la pro­duc­ti­vi­té, en re­vanche, les équipes OT maî­trisent mieux les pro­cess mé­tiers. Elles sont donc souvent plus per­ti­nentes. En pra­tique, ce sont souvent les équipes IT qui prennent les com­mandes mais, quelle que soit l’or­ga­ni­sa­tion, IT et OT doivent col­la­bo­rer. du rythme des in­ves­tis­se­ments in­dus­triels : les ma­chines sont pré­vues pour du­rer 10 à 15 ans, ce qui est un non-sens à l’échelle de L’IT. Sa­chant que les fa­bri­cants de ma­chines-ou­tils n’au­to­risent pour ain­si dire au­cune mo­di­fi­ca­tion, sous peine de perdre la ga­ran­tie, ajus­ter la sé­cu­ri­té aux risques qui ne cessent d’évo­luer sup­pose des ap­proches spé­ci­fiques » , pré­cise Ch­ris­tophe Au­ber­ger. D’au­tant que, dans les mi­lieux in­dus­triels, il n’est pas rare de rem­pla­cer la CPU d’un au­to­mate vieux de 10 ans par une nou- velle CPU iden­tique. Les équi­pe­ments sont non seule­ment pé­rennes, mais ils sont aus­si peu évo­lu­tifs, ce qui ne manque pas d’in­con­grui­té pour un in­for­ma­ti­cien ha­bi­tué à l’ac­cé­lé­ra­tion des ob­so­les­cences : mises à jour lo­gi­cielles et cor­rec­tifs font par­tie de leur quo­ti­dien. En­fin, le moindre chan­ge­ment peut aus­si avoir un ef­fet do­mi­no. Ré­sul­tat, les en­tre­prises pré­fèrent par­fois avoir des sys­tèmes d’ex­ploi­ta­tion pé­ri­més plu­tôt que de tou­cher à une confi­gu­ra­tion ul­tra-fer­mée ou per­son­na­li­sée.

Afin de conti­nuer à ca­pi­ta­li­ser sur un exis­tant sans y tou­cher, la ma­jo­ri­té des ac­teurs du mar­ché pré­co­nisent la créa­tion de «bulles», prin­cipe qui consiste à en­tou­rer les sys­tèmes de contrôle in­dus­triels (ICS) d’une pro­tec­tion avec une ana­lyse mi­nu­tieuse de tout ce qui entre et sort de cette bulle. En d’autres termes, la sé­cu­ri­sa­tion des en­vi­ron­ne­ments in­dus­triels passe par le prin­cipe bien connu des RS­SI de « MZ » (Mi­li­ta­ry Zone) qu’on ap­pli­quait il n’y a pas en­core si long­temps au sys­tème d’in­for­ma­tion avec une dé­marche glo­bale re­po­sant sur plu­sieurs couches de dé­fense (ré­seau, ma­té­riel et ap­pli­ca­tions) et des so­lu­tions de dé­tec­tion d’in­tru­sion, IPS (In­tru­sion Pre­ven­tion Sys­tem) et autres ex­ten­sions pour pare-feu spé­ci­fiques aux mi­lieux in­dus­triels.

Maî­tri­ser l’exis­tant

Tou­te­fois, la mise en place de ces zones sup­pose de maî­tri­ser un his­to­rique qui re­monte par­fois à trente ans. C’est pour­quoi les in­dus­triels sont souvent obli­gés de pas­ser par la case des au­dits de leur exis­tant afin de lis­ter les ma­chines, les lo­gi­ciels et les pro­ces­sus à pro­té­ger. En ap­pui sur une car­to­gra­phie à jour, ils peuvent ain­si éta­blir des zones et des sché­mas seg­men­tant les sys­tèmes, en s’ai­dant des ré­fé­ren­tiels dé­diés aux ins­tal­la­tions in­dus­trielles d’au­to­ma­tismes et de contrôle in­dus­triel tels que ISA 99 (re­prise par L’IEC sous la dé­si­gna­tion ISA/IEC 62443). Après des tra­vaux longs de plu­sieurs an­nées, le co­mi­té de stan­dar­di­sa­tion ISA 99 vient

d’ailleurs de faire évo­luer ses spé­ci­fi­ca­tions pour te­nir compte des nou­veaux en­jeux de sé­cu­ri­té.

Cet au­dit consti­tue éga­le­ment un préa­lable à la mise en place d’une po­li­tique d’ac­cès ri­gou­reuse et passe par l’iden­ti­fi­ca­tion des pro­fils ayant ac­cès au ré­seau, ou en­core la ca­té­go­ri­sa­tion des don­nées et des col­la­bo­ra­teurs. Sans ou­blier qu’une ma­chine qui n’est pas connec­tée au ré­seau n’est pour au­tant pas in­vul­né­rable. Il n’est pas rare en ef­fet que les mises à jour lo­gi­cielles soient ef­fec­tuées à l’aide de clés USB dans les mi­lieux in­dus­triels. Orange Cy­ber­de­fense vient d’ailleurs d’an­non­cer une borne mo­bile de dé­con­ta­mi­na­tion des clés USB pour ai­der les en­tre­prises à se pro­té­ger de ce genre de risque.

Chez Ca­ram­bar & Co, cet au­dit a été abor­dé de fa­çon très prag­ma­tique, comme l’ex­plique Marc Boul­lier, DSI de la so­cié­té. Pro­pul­sé à la tête d’un sys­tème d’in­for­ma­tion qu’il ne maî­tri­sait pas, il a com­men­cé par in­ter­con­nec­ter les cinq sites de pro­duc­tion au siège. « Mais avec toute cette in­for­ma­tique en usine, nous ne sa­vions pas tou­jours ce que fai­saient cer­tains ser­veurs, à quoi ser­vait tel équi­pe­ment, etc. En même temps, nous de­vions nous as­su­rer de la dis­po­ni­bi­li­té des ap­pli­ca­tions, ga­ran­tir les per­for­mances au­près de plus de 600 uti­li­sa­teurs et nous pré­mu­nir des com­por­te­ments dan­ge­reux sy­no­nymes d’at­taque po­ten­tielle sur une in­fra­struc­ture glo­bale dont nous ne maî­tri­sions pas des pans en­tiers, ex­plique-t-il. À vrai dire, je ne sa­vais pas vrai­ment par où com­men­cer. L’idée était bien en­ten­du d’ar­ri­ver à iden­ti­fier tout ce qui était fra­gile dans l’in­fra­struc­ture ou, en d’autres termes, tout ce qui pou­vait nous em­pê­cher de li­vrer nos clients ou nuire à la pro­duc­tion » . En ap­pui sur la so­lu­tion de su­per­vi­sion PRTG Net­work Mo­ni­tor de Paess­ler, qui pro­cède par dé­cou­verte et dé­ploie au­to­ma­ti­que­ment des agents en fonc­tion des flux iden­ti­fiés, Marc Boul­lier est par­ve­nu à re­prendre un contrôle d’au­tant plus urgent à mettre en place que, comme il le sou­ligne, « les lignes de pro­duc­tion em­barquent de plus en plus d’in­for­ma­tique et, dans le cadre de notre dé­marche de mo­der­ni­sa­tion, il y au­ra de plus en plus d’iot et de ro­bots dans nos usines » . En pra­tique, Marc Boul­lier a quelque peu dé­tour­né l’ou­til de su­per­vi­sion pour en faire une so­lu­tion d’ex­plo­ra­tion. Mais comme le sou­ligne Da­niel Crowe, vice pré­sident France, Be­ne­lux & Sou­thern Eu­rope de Nets­cout, édi­teur d’une so­lu­tion si­mi­laire qui prend éga­le­ment en charge les pro­to­coles spé­ci­fiques aux ré­seaux OT, « cette com­pré­hen­sion/vi­si­bi­li­té uni­fiée sur les deux vo­lets (OT et IT) est es­sen­tielle à la mise en oeuvre d’une sé­cu­ri­té ef­fi­cace » . En­fin, comme pour L’IT, la pro­tec­tion des ins­tal­la­tions in­dus­trielles passe aus­si par la mise en oeuvre de dis­po­si­tifs d’alerte ain­si que de plans de ré­ponse à un in­ci­dent. Ces plans sont d’au­tant plus cri­tiques que le pi­ra­tage d’une ma­chine peut bles­ser, voire tuer, un col­la­bo­ra­teur. Il faut donc être en me­sure de ré­agir très vite à la moindre alerte.

En d’autres termes, si elles de­mandent à être adap­tées aux mi­lieux in­dus­triels, les re­cettes pour pro­té­ger les ins­tal­la­tions sont glo­ba­le­ment connues des DSI et RS­SI. Pour au­tant, leur mise en oeuvre reste com­plexe. En cause, deux équipes qui ne parlent pas for­cé­ment la même langue.

Un rap­pro­che­ment com­pli­qué des équipes

Les in­for­ma­ti­ciens de ges­tion, les au­to­ma­ti­ciens et les équipes IT n’ont en ef­fet pas sui­vi les mêmes for­ma­tions. Ils uti­lisent non seule­ment des tech­no­lo­gies dif­fé­rentes, mais leurs pré­oc­cu­pa­tions sont aus­si di­ver­gentes. En OT, les équipes re­cherchent avant tout la su­reté de fonc­tion­ne­ment (évi­ter les pertes de ca­dence ou l’ar­rêt de la pro­duc­tion) et la sé­cu­ri­té des biens et des per­sonnes. Dans ce

« Les lignes de pro­duc­tion em­barquent de plus en plus d’in­for­ma­tique, il y au­ra de plus en plus d’iot et de ro­bots dans nos usines »

contexte, uti­li­ser du ma­té­riel ou du lo­gi­ciel ob­so­lète n’est pas un sou­ci dès lors que l’ins­tal­la­tion fonc­tionne comme at­ten­du. De la même fa­çon, L’OT n’est pas igno­rante des me­naces qui pèsent sur ses ins­tal­la­tions, mai­su­ne­sim­plea­na­ly­sean­ti­mal­ware – pra­tique cou­rante en IT – peut per­tur­ber le fonc­tion­ne­ment de lo­gi­ciels et de mo­dules souvent ba­sés sur des tech­no­lo­gies pro­prié­taires, et donc ra­len­tir la pro­duc­tion. En­fin, rem­pla­cer ou faire évo­luer une tech­no­lo­gie dans les mi­lieux OT im­plique souvent l’ar­rêt d’une ligne de pro­duc­tion : avant de pou­voir in­ter­ve­nir sur un four à forge, il faut le lais­ser re­froi­dir, puis le re­dé­mar­rer en es­pé­rant que le sys­tème re­par­ti­ra cor­rec­te­ment. Au­tre­ment dit, l’ar­rêt peut s’éter­ni­ser sur des se­maines et im­pac­ter sé­rieu­se­ment la pro­duc­tion.

De son cô­té, L’IT donne la prio­ri­té à l’in­té­gri­té des sys­tèmes et des don­nées. Les ins­tal­la­tions in­dus­trielles étant de­ve­nues une cible, ils cherchent bien en­ten­du à cou­vrir le pé­ri­mètre. Pour Fay­çal Hadj, so­lu­tion ar­chi­tect IOT chez Cis­co, édi­teur de la so­lu­tion OT In­dus­trial Net­work Di­rec­tor de sé­cu­ri­sa­tion glo­bale d’ins­tal­la­tions in­dus­trielles, « du point de vue hu­main, le pro­blème po­sé par la conver­gence des ré- seaux est as­sez si­mi­laire à ce­lui qu’on a connu avec l’es­sor de la té­lé­pho­nie sur IP qui a en­gen­dré des ten­sions entre équipes IT et PABX à cause des re­cou­pe­ments de pé­ri­mètres et de res­pon­sa­bi­li­tés. OT et IT se re­gardent au­jourd’hui dans les yeux, cher­chant à sa­voir qui va prendre le des­sus. D’après ce que nous avons pu consta­ter sur le ter­rain, les DSI n’ont pas for­cé­ment en­vie de prendre le contrôle : les rythmes sont dif­fé­rents, ils ne maî­trisent pas for­cé­ment les en­jeux mé­tiers… On as­siste plu­tôt à un ren­for­ce­ment des équipes OT avec des pro­fils IT » . Tou­jours aus­si prag­ma­tique, Marc Boul­lier a pré­fé­ré la col­la­bo­ra­tion au conflit, ap­por­tant son sou­tien aux équipes OT : « le bon fonc­tion­ne­ment des ins­tal­la­tions est as­su­ré par notre équipe de main­te­nance in­dus­trielle. Mais, sans le sup­port de L’IT, ils ont par­fois du mal à an­ti­ci­per un pro­blème et à iden­ti­fier sa source. Ty­pi­que­ment, nous avons ré­cem­ment eu un sou­ci avec nos bad­geuses, lié à la syn­chro­ni­sa­tion avec un ser­veur. Grâce à notre so­lu­tion de su­per­vi­sion, nous pou­vons leur ap­por­ter une aide pré­cieuse sur l’an­ti­ci­pa­tion et la com­pré­hen­sion du pro­blème » .

De fait, comme le sou­ligne Fran­çois Mo­reau de Saint Mar­tin, «il existe beau­coup de va­riantes du point de vue or­ga­ni­sa­tion­nel. Cer­taines pri­vi­lé­gient la cen­tra­li­sa­tion de la ges­tion des ré­seaux IT et OT en créant une équipe trans­verse qui cha­peaute la DSI et l’équipe OT. D’autres pré­fèrent don­ner la main à une des deux équipes exis­tantes. Ty­pi­que­ment, cer­tains pa­trons ont du mal à lâ­cher l’ou­til de pro­duc­tion entre les mains de L’IT qui ne com­prend pas tou­jours les en­jeux mé­tier » .

De fait, la « bonne » or­ga­ni­sa­tion dé­pend avant tout de la culture de l’en­tre­prise, mais quelle que soit l’op­tion choi­sie, la qua­li­té de la col­la­bo­ra­tion entre les deux équipes est un fac­teur dé­ter­mi­nant dans la réus­site d’un pro­jet de conver­gence.

(*) En 2015, au vo­lant d’une Jeep Che­ro­kee, le jour­na­liste An­dy Green s’est fait ha­cker son vé­hi­cule : de conni­vence avec le jour­na­liste, deux pi­rates ont pris le contrôle à dis­tance afin de dé­mon­trer la vul­né­ra­bi­li­té des nou­veaux vé­hi­cules connec­tés.

La ques­tion de l’or­ga­ni­sa­tion et du lea­der­ship dé­pend des rai­sons qui mo­tivent la conver­gence. En gé­né­ral,

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.