CI­BER­SE­GU­RI­DAD Y SE­GU­RI­DAD DE PRO­CE­SOS

PQ - - SEGURIDAD INDUSTRIAL - Por Arturo Tru­ji­llo, di­rec­tor de Con­sul­to­ría de Se­gu­ri­dad de Pro­ce­sos. De­kra Pro­cess Sa­fety (em­pre­sa aso­cia­da a BE­QUI­NOR, Aso­cia­ción Na­cio­nal de Nor­ma­li­za­ción de Bie­nes de Equi­po y Se­gu­ri­dad In­dus­trial)

A lo lar­go de las úl­ti­mas dé­ca­das, la prác­ti­ca del con­trol in­dus­trial ha evo­lu­cio­na­do ha­cia sis­te­mas de ma­yor in­ter­ac­ti­vi­dad y fa­ci­li­dad de uti­li­za­ción. Pa­ra ello, la in­ter­co­nec­ti­vi­dad de sis­te­mas ha si­do cla­ve. Hoy en día, la prác­ti­ca to­ta­li­dad de las plan­tas de pro­ce­sos dis­po­nen de sis­te­mas de con­trol au­to­má­ti­co que, a me­nu­do, se im­bri­can en los di­ver­sos ni­ve­les de di­gi­ta­li­za­ción de la com­pa­ñía: des­de el ni­vel de cam­po (ins­tru­men­tos, ac­tua­do­res, re­lés…) has­ta el más al­to ni­vel de ser­vi­do­res cor­po­ra­ti­vos.

T al co­mo es una cons­tan­te en la ma­yor par­te de ac­ti­vi­da­des hu­ma­nas, es­tas me­jo­ras han ge­ne­ra­do un ries­go. En es­te ca­so, el de ser víc­ti­mas de un ata­que ma­lin­ten­cio­na­do que al­te­re el fun­cio­na­mien­to pre­vis­to del sis­te­ma de con­trol au­to­má­ti­co de la plan­ta y pue­da, por tan­to, pro­vo­car da­ños ma­te­ria­les, a la ca­li­dad del pro­duc­to o, en el lí­mi­te, un ac­ci­den­te con da­ños po­ten­cia­les a las per­so­nas, el me­dio am­bien­te y los ac­ti­vos. De es­ta for­ma, re­cien­te­men­te se ha desa­rro­lla­do la nue­va dis­ci­pli­na de la ci­ber­se­gu­ri­dad, encaminada a pro­te­ger los sis­te­mas in­for­má­ti­cos de es­te ti­po de ata­ques. A su vez, la se­gu­ri­dad de pro­ce­sos in­ten­ta pre­ve­nir o mi­ti­gar la ocu­rren­cia de even­tos que com­por­ten la pér­di­da de con­trol de ma­te­rias pe­li­gro­sas o fuen­tes de ener­gía. Por lo tan­to, exis­te un ám­bi­to de in­ter­ac­ción en­tre es­ta dis­ci­pli­na y la ci­ber­se­gu­ri­dad: la pre­ven­ción y mi­ti­ga­ción de es­ce­na­rios de ries­gos de pro­ce­so cau­sa­dos por ci­be­ra­ta­ques. Con­vie­ne, en pri­mer lu­gar, in­tro­du­cir al­gu­nos con­cep­tos bá­si­cos: • La Real Aca­de­mia Es­pa­ño­la de­fi­ne pe­li­gro co­mo “ries­go o con­tin­gen­cia in­mi­nen­te de que su­ce­da al­gún mal.” El con­cep­to que­da su­fi­cien­te­men­te cla­ro, pe­ro pa­ra po­der ana­li­zar­lo des­de un pun­to de vis­ta téc­ni­co ne­ce­si­ta­mos al­go más de ri­gor. • El da­ño o con­se­cuen­cia es la mag­ni­tud del per­jui­cio cau­sa­do por un es­ce­na­rio ac­ci­den­tal (se tra­ta del “mal” en la de­fi­ni­ción de la Real Aca­de­mia). En fun­ción del ti­po de es­ce­na­rio que se es­té ana­li­zan­do, el da­ño puede ser per­so­nal, me­dio am­bien­tal o ma­te­rial. • La pro­ba­bi­li­dad es una me­di­da ma­te­má­ti­ca de la ma­yor o me­nor ve­ro­si­mi­li­tud que atri­bui­mos a un es­ce­na­rio ac­ci­den­tal. Nor­mal­men­te es un nú­me­ro real com­pren­di­do en­tre ce­ro y uno, am­bos in­clui­dos. Así, por ejem­plo, un even­to prác­ti­ca­men­te se­gu­ro re­ci­bi­rá una pro­ba­bi­li­dad pró­xi­ma a la uni­dad, mien­tras que a uno que con­si­de­ra­mos prác­ti­ca­men­te im­po­si­ble le asig­na­re­mos una pro­ba­bi­li­dad pró­xi­ma a ce­ro. • De una for­ma ma­te­má­ti­ca es­tric­ta, de­fi­ni­mos el ries­go co­mo la es­pe­ran­za ma­te­má­ti­ca de da­ño. Más sim­pli­fi­ca­da­men­te, el ries­go es el pro­duc­to de la pro­ba­bi­li­dad por el da­ño:

Ries­go = pro­ba­bi­li­dad × da­ño

Que­da cla­ro que es­tas de­fi­ni­cio­nes no que­dan li­mi­ta­das al mun­do de la se­gu­ri­dad de pro­ce­sos ni de la ci­ber­se­gu­ri­dad. Cual­quier ti­po de even­to que pue­da cau­sar un da­ño (fi­nan­cie­ro, de ca­li­dad de pro­duc­to…) ad­mi­te el mis­mo tra­ta­mien­to. En es­te con­tex­to, el cre­cien­te cau­dal de noticias re­la­ti­vas a ci­be­ra­ta­ques po­ne cla­ra­men­te de ma­ni­fies­to que ni la pro­ba­bi­li­dad ni el da­ño son nu­los. Así, por ejem­plo, el gi­gan­te de la ali­men­ta­ción Mon­de­lez In­ter­na­tio­nal re­por­tó la dis­mi­nu­ción del 3% de sus ven­tas del se­gun­do tri­mes­tre de 2017, mien­tras que Rec­kitt Benc­ki­ser anun­ció 110 mi­llo­nes de li­bras es­ter­li­nas de pér­di­das en el mis­mo pe­rio­do. En am­bos ca­sos, por ra­zón del vi­rus ‘Pet­ya’ (fuen­te: Fi­nan­cial Ti­mes). En la ma­yor par­te de los ca­sos pu­bli­ca­dos, el da­ño es me­ra­men­te eco­nó­mi­co. Sin em­bar­go, ca­be tam­bién pre­gun­tar­se cuá­les po­drían ser las con­se­cuen­cias de un po­si­ble ci­be­ra­ta­que con fi­na­li­dad de cau­sar da­ño a las per­so­nas o el me­dio am­bien­te. En es­te sen­ti­do, son nu­me­ro­sos los ejem­plos de ac­ci­den­tes y cua­si-ac­ci­den­tes per­fec­ta­men­te do­cu­men­ta­dos cu­ya cau­sa ini­cial fue un fa­llo del sis­te­ma au­to­má­ti­co de con­trol. Aun­que en su mo­men­to es­tos fa­llos fue­ron no pro­vo­ca­dos, de­be con­si­de­rar­se la po­si­bi­li­dad de que en un fu­tu­ro pue­dan lle­gar a ser­lo.

A tí­tu­lo de ejem­plo, cer­ca de las 4: 00 de la ma­ña­na del 28 de mar­zo de 1979 se pa­ra­ron las bom­bas pri­ma­rias de ali­men­ta­ción del cir­cui­to se­cun­da­rio de la Cen­tral Nu­clear de Th­ree Mi­le Is­land (TMI; Ha­rris­burg, Pennsyl­va­nia, USA) a cau­sa de una ave­ría me­cá­ni­ca o eléc­tri­ca. Es­to im­pi­dió la eva­cua­ción de ca­lor del sis­te­ma pri­ma­rio en los ge­ne­ra­do­res de va­por. Aun­que los sis­te­mas de con­trol pa­ra­ron in­me­dia­ta­men­te la tur­bi­na y el reac­tor, la pre­sión en la va­si­ja de és­te em­pe­zó a au­men­tar rá­pi­da­men­te da­do que el cir­cui­to se­cun­da­rio era in­ca­paz de eva­cuar el ca­lor re­si­dual ge­ne­ra­do. Pa­ra evi­tar que esa pre­sión lle­ga­se a ser ex­ce­si­va, la vál­vu­la de ali­vio de pre­sión (si­tua­da en la tapa del pre­su­ri­za­dor) se abrió. La vál­vu­la de­bía ce­rrar­se al dis­mi­nuir la pre­sión, aun­que por un fa­llo no lo hi­zo. Las se­ña­les que lle­ga­ban al ope­ra­dor no in­di­ca­ron que la vál­vu­la se­guía abier­ta, aun­que de­bie­ron ha­ber­lo mos­tra­do. En con­se­cuen­cia, la vál­vu­la abier­ta cau­só que la pre­sión con­ti­nua­ra dis­mi­nu­yen­do en el sis­te­ma. Des­pués de to­da una se­cuen­cia de even­tos, al ca­bo de unos 130 mi­nu­tos del su­ce­so ini­cia­dor, la par­te su­pe­rior del reac­tor que­dó sin re­fri­ge­ra­ción, con lo que el cir­co­nio de las vai­nas de los ele­men­tos com­bus­ti­bles reac­cio­nó con el va­por de agua, ge­ne­ran­do hi­dró­geno. Es­te hi­dró­geno ex­plo­tó, ex­po­nien­do ele­men­tos de com­bus­ti­ble al agua de re­fri­ge­ra­ción. Fi­nal­men­te, una par­te del nú­cleo se fun­dió, de­jan­do una ma­sa de com­bus­ti­ble que pos­te­rior­men­te hu­bo de ser re­ti­ra­da. La lim­pie­za del reac­tor fue un pro­yec­to con una du­ra­ción de 14 años y un cos­te to­tal de cer­ca de 975 mi­llo­nes de dó­la­res. No exis­te ni la más mí­ni­ma sos­pe­cha de que el ac­ci­den­te en TMI fue­ra de­bi­do a un ci­be­ra­ta­que; de he­cho, in­ter­net ni si­quie­ra exis­tía en esa fe­cha. No obs­tan­te, hoy en día de­be­mos plan­tear­nos si un ac­ci­den­te de es­te ti­po po­dría ha­ber si­do pro­vo­ca­do… Y la res­pues­ta es que sí, sal­vo que se adop­ten las me­di­das ade­cua­das pa­ra pre­ve­nir­lo. El su­ce­so ini­cia­dor del ac­ci­den­te fue el pa­ro de las bom­bas del cir­cui­to se­cun­da­rio (que po­dría ha­ber si­do pro­vo­ca­do), mien­tras que el su­ce­so fue es­ca­lan­do de­bi­do a que los ope­ra­do­res to­ma­ron de­ci­sio­nes erró­neas ba­sa­das en la in­for­ma­ción equí­vo­ca fa­ci­li­ta­da por el sis­te­ma de con­trol (que tam­bién po­dría ha­ber si­do ma­ni­pu­la­do). La vál­vu­la de se­gu­ri­dad del pre­sio­na­dor no pu­do ha­ber si­do ac­tua­da por un ci­be­ra­ta­que, pe­ro la in­di­ca­ción in­co­rrec­ta de que per­ma­ne­ció abier­ta sí lo pu­do ha­ber si­do. El men­sa­je que de­be­mos ex­traer de una con­si­de­ra­ción de es­te ti­po es que ne­ce­si­ta­mos po­der de­ter­mi­nar y me­dir có­mo de vul­ne­ra­ble es nues­tro pro­ce­so fren­te a un ci­be­ra­ta­que ya que, ob­via­men­te, las con­se­cuen­cias po­ten­cia­les no se­rás las mis­mas en una cen­tral nu­clear que una em­bo­te­lla­do­ra de agua mi­ne­ral. Por su par­te, el ries­go, cual­quie­ra que sea su ti­po, de­be ges­tio­nar­se siem­pre en las fa­ses que que­dan es­que­ma­ti­za­das en la fi­gu­ra ad­jun­ta.

Res­pues­ta le­gal y nor­ma­ti­va

Ob­via­men­te, los le­gis­la­do­res no pue­den per­ma­ne­cer aje­nos a un ries­go po­ten­cial, de­ben re­gu­lar­lo. Así, el Par­la­men­to Eu­ro­peo y el Con­se­jo pro­mul­ga­ron el 6 de ju­lio de 2016 la Di­rec­ti­va (UE) 2016/1148, re­la­ti­va a las me­di­das des­ti­na­das a ga­ran­ti­zar un ele­va­do ni­vel co­mún de se­gu­ri­dad de las re­des y sis­te­mas de in­for­ma­ción en la Unión. Es­ta Di­rec­ti­va re­quie­re a los es­ta­dos miem­bros a iden­ti­fi­car los ser­vi­cios crí­ti­cos que po­drían ser víc­ti­mas de ci­be­ra­ta­ques y crear las es­truc­tu­ras ade­cua­das pa­ra ha­cer­les fren­te. La Di­rec­ti­va fue com­ple­men­ta­da en 2018 por el Re­gla­men­to de Eje­cu­ción (UE) 2018/151 de la Co­mi­sión, de 30 de enero de 2018, por el que se es­ta­ble­cen nor­mas pa­ra la apli­ca­ción de la Di­rec­ti­va (UE)

LOS PRO­CE­SOS NO SE PUE­DEN CON­TRO­LAR CO­RREC­TA­MEN­TE A ME­NOS QUE LOS COM­PO­NEN­TES IN­DI­VI­DUA­LES PRE­SEN­TEN UN FUN­CIO­NA­MIEN­TO FIABLE

2016/1148 del Par­la­men­to Eu­ro­peo y del Con­se­jo en lo que res­pec­ta a la es­pe­ci­fi­ca­ción de los ele­men­tos que han de te­ner en cuen­ta los pro­vee­do­res de ser­vi­cios di­gi­ta­les pa­ra ges­tio­nar los ries­gos exis­ten­tes pa­ra la se­gu­ri­dad de las re­des y sis­te­mas de in­for­ma­ción, así co­mo de los pa­rá­me­tros pa­ra de­ter­mi­nar si un in­ci­den­te tie­ne un im­pac­to sig­ni­fi­ca­ti­vo. En el mo­men­to de re­dac­tar es­ta no­ta (ju­nio de 2018), la Di­rec­ti­va es­tá pen­dien­te de tras­po­si­ción al or­de­na­mien­to ju­rí­di­co es­pa­ñol. Por otra par­te, des­de ha­ce ya al­gu­nos años di­ver­sos or­ga­nis­mos han ido pu­bli­can­do nor­mas téc­ni­cas pa­ra ha­cer fren­te al ries­go de ci­be­ra­ta­ques. En el pre­sen­te do­cu­men­to ana­li­za­re­mos, aun­que sea bre­ve­men­te, la fa­mi­lia de nor­mas ISA/ IEC 62443, que es he­re­de­ra de la ISA-99. Am­bos or­ga­nis­mos ( la In­ter­na­tio­nal Elec­tro­tech­ni­cal Com­mis­sion y la In­ter­na­tio­nal So­ciety for Au­to­ma­tion) tie­nen una lar­ga tra­di­ción en el ám­bi­to de la au­to­ma­ti­za­ción y la se­gu­ri­dad. La fi­gu­ra ad­jun­ta mues­tra un re­su­men es­que­má­ti­co del al­can­ce de es­ta fa­mi­lia de nor­mas. De­be des­ta­car­se que es­tas nor­mas mues­tran un no­ta­ble pa­ra­le­lis­mo con la más co­no­ci­da nor­ma IEC EN 61508, que es­tan­da­ri­za la se­gu­ri­dad fun­cio­nal. Se es­ta­ble­ce de es­ta for­ma un nue­vo pa­ra­le­lis­mo en­tre la ci­ber­se­gu­ri­dad y la se­gu­ri­dad de pro­ce­sos. Así, la nor­ma ISA/IEC 62443 de­fi­ne los lla­ma­dos “Se­cu­rity Le­vels” ( SL), o ni­ve­les de ro­bus­tez del sis­te­ma de con­trol au­to­má­ti­co fren­te a ci­be­ra­ta­ques (de la mis­ma for­ma que la IEC EN 61508 de­fi­ne los “Sa­fety In­te­grity Le­vels” o SIL co­mo gra­dos de ro­bus­tez fren­te a fa­llos no pro­vo­ca­dos).

Ejem­plo de he­rra­mien­ta de eva­lua­ción de ries­gos

Los Pro­cess Ha­zard Analy­sis (PHA) son una fa­mi­lia am­plia­men­te ex­ten­di­da de mé­to­dos de iden­ti­fi­ca­ción de pe­li­gros y aná­li­sis de ries­gos. Pro­ba­ble­men­te el miem­bro más po­pu­lar es el aná­li­sis fun­cio­nal de ope­ra­bi­li­dad o HAZOP (de la ex­pre­sión in­gle­sa “Ha­zard and Ope­ra­bi­lity Study”). Re­cien­te­men­te se ha desa­rro­lla­do una ex­ten­sión de es­te mé­to­do, es­pe­cial­men­te adap­ta­da a la iden­ti­fi­ca­ción de ries­gos re­la­cio­na­dos con ci­be­ra­ta­ques. Una de las fi­gu­ras ad­jun­tas mues­tra un es­que­ma de es­te mé­to­do. Co­mo puede com­pro­bar­se en ella, el PHA de se­gu­ri­dad es, en esen­cia, un es­tu­dio HAZOP en el que, ade­más, nos plan­tea­mos si las cau­sas o sal­va­guar­das son ro­bus­tas o no fren­te a un ci­be­ra­ta­que. Así, por ejem­plo, si la cau­sa es del ti­po “fa­llo del la­zo de con­trol de tem­pe­ra­tu­ra del reac­tor”, con­clui­re­mos que es vul­ne­ra­ble a un ci­be­ra­ta­que. Por el con­tra­rio, si la cau­sa es “car­ga de ca­ta­li­za­dor equi­vo­ca­do al reac­tor por error hu­mano”, con­clui­re­mos que la cau­sa no es vul­ne­ra­ble a un ci­be­ra­ta­que. Análo­ga­men­te, las sal­va­guar­das po­drían ser vul­ne­ra­bles o no. Una sal­va­guar­da del ti­po “alar­ma de al­ta pre­sión con ac­tua­ción por el ope­ra­dor” o “fun­ción ins­tru­men­ta­da de se­gu­ri­dad que cor­ta el va­por por al­ta pre­sión” son vul­ne­ra­bles, mien­tras que una del ti­po “dis­co de rup­tu­ra” no lo es.

OTRO DE LOS AS­PEC­TOS QUE MÁS HA EVO­LU­CIO­NA­DO ES LA INTERFASE EN­TRE EL OPE­RA­DOR Y EL INS­TRU­MEN­TO

Si iden­ti­fi­ca­mos un es­ce­na­rio pe­li­gro­so ( es de­cir, uno con con­se­cuen­cias pa­ra la se­gu­ri­dad de las per­so­nas, del me­dio am­bien­te o de los ac­ti­vos) pa­ra el que tan­to la cau­sa co­mo to­das las sal­va­guar­das son vul­ne­ra­bles a un ci­be­ra­ta­que, ten­dre­mos que ad­mi­tir que es­te es­ce­na­rio po­dría ser ge­ne­ra­do ex­ter­na­men­te, a con­se­cuen­cia de un ci­be­ra­ta­que. En es­te ca­so, de­be­re­mos de­ter­mi­nar el SL co­rres­pon­dien­te, nor­mal­men­te en fun­ción de la mag­ni­tud de las con­se­cuen­cias. La equi­va­len­cia en­tre mag­ni­tud de con­se­cuen­cias y SL se es­ta­ble­ce me­dian­te una ma­triz si­mi­lar a las ma­tri­ces de ries­go em­plea­das ha­bi­tual­men­te en los HAZOP con­ven­cio­na­les. Una vez com­ple­ta­do el PHA de se­gu­ri­dad, se ob­tie­ne una lis­ta de es­ce­na­rios po­ten­cia­les, y de los SL re­que­ri­dos pa­ra pro­te­ger­los. És­ta es la in­for­ma­ción de par­ti­da pa­ra las fa­ses pos­te­rio­res del ci­clo de vi­da del ries­go; fun­da­men­tal­men­te, pa­ra el di­se­ño o ve­ri­fi­ca­ción del sis­te­ma de con­trol, de tal ma­ne­ra que cum­pla el SL exi­gi­do, de acuer­do con la nor­ma ISA/IEC 62443.

Newspapers in Spanish

Newspapers from Spain

© PressReader. All rights reserved.