Ata­que in­te­li­gen­te

Las em­pre­sas dis­fru­tan de los be­ne­fi­cios de In­ter­net de las Co­sas o In­te­li­gen­cia Ar­ti­fi­cial, pe­ro po­cas to­man con­cien­cia de que en esas in­no­va­cio­nes anidan los fu­tu­ros ci­be­ra­ta­ques. Có­mo pro­te­ger­se.

Apertura (Argentina) - - Sumario - Se­gui­nos en fa­ce­book.com/aper­tu­ra­com en twit­ter.com/aper­tu­ra­com Walter Duer

Si tan so­lo usa­ras esa in­te­li­gen­cia pa­ra ha­cer el bien”, le plan­teó al­gu­na vez Su­per­man a su ar­chi­rri­val Lex Lut­hor, sor­pren­di­do por­que Lut­hor de­ci­dió em­plear al­go tan po­si­ti­vo y pro­duc­ti­vo pa­ra ha­cer al­go tan ma­lo. En al­gún pun­to, lo mis­mo ocu­rre con las nue­vas tec­no­lo­gías y su uti­li­za­ción por par­te de hac­kers: la nu­be, la mo­vi­li­dad, In­ter­net de las Co­sas (IOT) y has­ta la In­te­li­gen­cia Ar­ti­fi­cial (IA) son fuen­te de in­nu­me­ra­bles be­ne­fi­cios pa­ra las or­ga­ni­za­cio­nes. Pe­ro tam­bién el ni­do don­de se es­tán ges­tan­do ata­ques in­for­má­ti­cos ca­da vez más com­ple­jos y di­fí­ci­les de de­te­ner.

“An­tes de 2000, los ata­can­tes ne­ce­si­ta­ban en gran me­di­da ac­ce­so fí­si­co a los sis­te­mas pa­ra cau­sar da­ños”, cuen­ta Fe­de­ri­co Tan­de­ter, di­rec­tor de Ac­cen­tu­re pa­ra Su­da­mé­ri­ca de Ha­bla His­pa­na. “La in­tro­duc­ción de nue­vas tec­no­lo­gías ha ero­sio­na­do las de­fen­sas tra­di­cio­na­les de los sis­te­mas”, agre­ga.

“Los CIOS y due­ños de ne­go­cios ne­ce­si­tan pen­sar la se­gu­ri­dad de ma­ne­ra ho­lís­ti­ca pa­ra sus cen­tros de da­tos ex­ten­di­dos, es de­cir, in­fraes­truc­tu­ras de cómpu­to que abar­quen nu­bes pri­va­das, pú­bli­cas y dis­tri­bui­das”, de­fi­ne Sat­yam Vag­ha­ni, VP de Tec­no­lo­gía de Nu­ta­nix, es­pe­cia­li­za­da en ha­bi­li­tar a los equi­pos de IT a cons­truir ar­qui­tec­tu­ras mul­ti­cloud.

Los ries­gos re­la­cio­na­dos con la compu­tación en la nu­be ya son co­no­ci­dos. “La no cer­te­za del con­trol de la in­for­ma­ción en com­pa­ra­ción con sus be­ne­fi­cios si­gue ge­ne­ran­do res­que­mo­res en mo­ver la ope­ra­ción de IT allí”, re­cuer­da Car­los Cas­ta­ñe­da, res­pon­sa­ble de Pre­ven­ta de Ci­ber­se­gu­ri­dad de Unisys La­ti­noa­mé­ri­ca. Sin em­bar­go, siem­pre apa­re­cen nue­vos ries­gos. Co­mo el que iden­ti­fi­ca Vag­ha­ni, aso- cia­do con el desa­rro­llo de apli­ca­cio­nes ba­sa­do en mi­cro­ser­vi­cios en la nu­be. “Una gran can­ti­dad de ser­vi­cios más pe­que­ños pue­den ac­tua­li­zar­se y ser mo­di­fi­ca­dos con ma­yor ra­pi­dez que los sis­te­mas de soft­wa­re mo­no­lí­ti­cos, por lo que las or­ga­ni­za­cio­nes que no cuen­tan con una in­fra­es­truc­tu­ra de se­gu­ri­dad es­pe­cí­fi­ca, si per­mi­ten que ca­da ser­vi­cio con­fi­gu­re su pro­pia se­gu­ri­dad pa­ra agi­li­zar el desa­rro­llo de soft­wa­re, se ob­tie­ne una vul­ne­ra­bi­li­dad in­trín­se­ca, de­sigual y di­fí­cil de co­rre­gir”.

El nú­me­ro de dis­po­si­ti­vos y sen­so­res dis­tri­bui­dos en cam­po que en­vían in­for­ma­ción a sis­te­mas cen­tra­les, o IOT, es una ver­da­de­ra fuen­te de opor­tu­ni­da­des pa­ra los ci­ber­cri­mi­na­les. “IOT ha mos­tra­do ser el es­la­bón más dé­bil de la ca­de­na, al­go que se vio el año pa­sa­do en el úl­ti­mo ci­be­ra­ta­que glo­bal. Y son jus­ta­men­te los dis­po­si­ti­vos IOT los que cre­cen a ma­yor rit­mo”, cuen­ta Car­los Abril CEO de la con­sul­to­ra es­pe­cia­li­za­da en trans­for­ma­ción di­gi­tal Atos pa­ra la Ar­gen­ti­na, Co­lom­bia y Uru­guay.

Por lo pron­to, IOT su­po­ne la con­ver­gen­cia de IT con las tec­no­lo­gías ope­ra­cio­na­les (OT). “Un ata­que en la red OT po­dría des­en­ca­de­nar even­tos que lle­gan a los sis­te­mas de ne­go­cio y una in­fec­ción de malwa­re en la ca­pa de IT po­dría ex­ten­der­se has­ta los pro­ce­sos de au­to­ma­ti­za­ción y de­ri­var en gra­ves pro­ble­mas ope­ra­cio­na­les”, sos­tie­ne Tan­de­ter.

De­ni­se Gius­to Bi­lic, es­pe­cia­lis­ta en se­gu­ri­dad in­for­má­ti­ca de ESET La­ti­noa­mé­ri­ca, sos­tie­ne que pa­ra pre­ve­nir los ata-

ques a es­tos equi­pos de­ben te­ner­se en cuen­ta dos as­pec­tos. El pri­me­ro es el téc­ni­co, “don­de im­ple­men­tar la se­gu­ri­dad en la pla­ta­for­ma cons­ti­tu­ye un re­to con­si­de­ra­ble, ya que las téc­ni­cas tra­di­cio­na­les de se­gu­ri­dad –co­mo el fil­tra­do, el ci­fra­do y la au­ten­ti­ca­ción– pue­den con­su­mir una enor­me ca­pa­ci­dad de pro­ce­sa­mien­to y an­cho de ban­da, lo que pue­de so­bre­car­gar los sis­te­mas”. El se­gun­do tie­ne que ver con la con­cien­ti­za­ción de los usua­rios: “La crea­ción de un plan de ca­pa­ci­ta­ción so­bre ries­gos de se­gu­ri­dad es vi­tal pa­ra mi­ni­mi­zar la po­si­bi­li­dad de un ata­que exi­to­so”.

Christian O’flaherty, ge­ren­te de Desa­rro­llo Re­gio­nal pa­ra La­ti­noa­mé­ri­ca de In­ter­net So­ciety, agre­ga una ter­ce­ra pa­ta: la se­gu­ri­dad en las apli­ca­cio­nes mó­vi­les y los ser­vi­cios de bac­kend que so­por­tan los dis­po­si­ti­vos o sen­so­res de IOT. “Mu­chas em­pre­sas uti­li­zan dis­po­si­ti­vos de ni­vel de usua­rio, co­mo te­le­vi­so­res in­te­li­gen­tes o geo­lo­ca­li­za­do­res, sin con­si­de­rar que no es­tán cons­trui­dos con las mis­mas pro­tec­cio­nes que los cor­po­ra­ti­vos”, di­ce. Tam­bién re­co­mien­da mi­rar a lar­go pla­zo: “Es ne­ce­sa­rio com­pren­der las ca­pa­ci­da­des del ci­clo de vi­da del pro­duc­to y lo que ha­rá cuan­do ya no sea ac­tua­li­za­ble o se­gu­ro o có­mo se ha­rá la tran­si­ción de los da­tos ad­qui­ri­dos si es ne­ce­sa­ria”.

Pres­tar aten­ción

Una de­bi­li­dad de los pro­duc­tos IOT es­ta­ría… en los mis­mos pro­duc­tos. “La fal­ta de un es­tán­dar a ni­vel de in­dus­tria y re­gu­la­cio­nes re­cién en desa­rro­llo ha­cen que en la ma­yo­ría de los dis­po­si­ti­vos el ni­vel de se­gu­ri­dad sea in­su­fi­cien­te”, ex­pli­ca Santiago Pon­ti­ro­li, ana­lis­ta de Se­gu­ri­dad en Kas­persky Lab. “El pro­ble­ma es que, en al­gu­nos ca­sos, el des­co­no­ci­mien­to de esa tec­no­lo­gía por par­te de los fa­bri­can­tes los lle­vó a co­me­ter erro­res que po­drían ge­ne­rar que la vul­ne­ra­bi­li­dad de un so­lo dis­po­si­ti­vo se ex­pan­da a to­dos los pro­du­ci­dos”, coin­ci­de Nor­ber­to Ma­ri­ne­lli, fun­da­dor y CEO de Cer­ti­sur, em­pre­sa que pro­vee ser­vi­cios de con­fian­za pa­ra ga­ran­ti­zar las transac­cio­nes so­bre re­des pú­bli­cas co­mo In­ter­net.

¿Cuá­les son las cla­ves pa­ra ha­cer más se­gu­ro un es­que­ma IOT? De­be ga­ran­ti­zar­se la pro­tec­ción de los sen­so­res que emi­ten in­for­ma­ción sin in­ter­ven­ción hu­ma­na, con po­lí­ti­cas que van des­de man­te­ner ac­tua­li­za­do el soft­wa­re o el firm­wa­re del dis­po­si­ti­vo an­te las úl­ti­mas vul­ne­ra­bi­li­da­des de­tec­ta­das por el fa­bri­can­te has­ta el mo­ni­to­reo y la de­tec­ción de ac­ce­sos no au­to­ri­za­dos al equi­po, pa­san­do por me­ca­nis­mos es­tric­tos y mi­nu­cio­sos de ac­ce­so, tan­to re­mo­to co­mo en cam­po (de­ben te­ner sis­te­mas de alar­ma o mo­ni­to­reo, o es­tar en cons­truc­cio­nes con pro­tec­ción).

“Tam­bién de­be im­ple­men­tar­se un SOC (Se­cu­rity Ope­ra­tion Cen­ter) que per­mi­ta de­tec­tar des­víos sos­pe­cho­sos en el fun­cio­na­mien­to de la red, co­mo la apa­ri­ción de dis­po­si­ti­vos no au­to­ri­za­dos o cam­bios en el vo­lu­men de trá­fi­co, pa­ra iden­ti­fi­car si hay da­tos del sen­sor que se pier­den o son ma­ni­pu­la­dos”, apun­ta Tan­de­ter.

“De­be evi­tar­se la co­ne­xión pun­to a pun­to. Si, por ejem­plo, exis­te la po­si­bi­li­dad de ma­ne­jar to­do me­dian­te el uso de APIS, es im­pres­cin­di­ble con­tar con un API Ma­na­ge­ment que de­tec­te e im­pi­da ata­ques”, re­co­mien­da Her­nán Co­nos­ciu­to, ar­qui­tec­to se­nior de So­lu­cio­nes de Ci­ber­se­gu­ri­dad, Nu­be y Al­ma­ce­na­mien­to de Red Hat.

Avast anun­ció Smart Li­fe, una he­rra­mien­ta de se­gu­ri­dad pa­ra IOT que uti­li­za IA pa­ra iden­ti­fi­car y blo­quear las ame­na­zas. “Por ejem­plo, si un ter­mos­ta­to de ca­le­fac­ción se en­cien­de a una ho­ra inusual y trans­mi­te da­tos en al­to vo­lu­men a un país des­co­no­ci­do, Smart Li­fe po­drá apa­gar el dis­po­si­ti­vo y aler­tar al usua­rio”, ex­pli­ca Mi­chal Sa­lat, di­rec­tor de In­te­li­gen­cia de Ame­na­zas de la com­pa­ñía.

Sea­mos in­te­li­gen­tes

La IA es una tec­no­lo­gía cu­yo po­der aún es di­fí­cil de es­ti­mar. En tér­mi­nos de se­gu­ri­dad de la in­for­ma­ción, pue­de ju­gar a fa­vor, tal co­mo re­la­ta Abril. “La gran can­ti­dad de ob­je­tos a pro­te­ger ha­ce que re­plan­tee­mos mu­chos pa­ra­dig­mas de se­gu-

ri­dad y ha­ya­mos desa­rro­lla­do nue­vos con- cep­tos co­mo la se­gu­ri­dad pre­dic­ti­va y pres­crip­ti­va y es­te­mos tra­ba­jan­do en la en­crip­ta­ción ho­mo­mór­fi­ca cuán­ti­ca, to­do apo­ya­do en he­rra­mien­tas de ma­chi­ne in­te­lli­gen­ce y quan­tum lear­ning ma­chi­ne”. Pe­ro tam­bién en con­tra, se­gún Oc­ta­vio Du­ré, ge­ren­te de In­ge­nie­ría de Soft­wa­re de Vm­wa­re: “Las es­ta­dís­ti­cas in­di­can que un dis­po­si­ti­vo IOT co­lo­ca­do en la red es ata­ca­do den­tro de los pri­me­ros vein­te mi­nu­tos de vi­da. La tec­no­lo­gía de IA da a es­tas ame­na­zas más po­der y no hay pro­tec­ción ca­paz de evi­tar­lo. Lo me­jor que po­de­mos ha­cer es mi­ti­gar el impacto evi­tan­do que los ata­ques se pro­pa­guen”.

¿Qué ocu­rri­ría si la IA lle­ga a la pro­duc­ción de vi­rus? “Hay ca­sos don­de el malwa­re em­plea téc­ni­cas avan­za­das pa­ra efec­tuar ata­ques si­gi­lo­sos y evo­lu­cio­na­dos ca­pa­ces de te­ner un aná­li­sis más pro­fun­do de la si­tua­ción y del comportamiento de los usua­rios lo­gran­do en­ten­der y co­no­cer los in­tere­ses y há­bi­tos de sus víc­ti­mas, lle­gan­do a imi­tar­las, crean­do si­tua­cio­nes te­rro­rí­fi­cas con com­por­ta­mien­tos anó-

ma­los que im­pli­can gran­des crí­me­nes ci­ber­né­ti­cos”, de­fi­ne Adriana Ji­mé­nez Soler, es­pe­cia­lis­ta de Pro­duc­to de la fir­ma de so­lu­cio­nes y te­le­co­mu­ni­ca­cio­nes IFX.

“Al­gu­nos in­ves­ti­ga­do­res de­mos­tra­ron que téc­ni­cas co­mo el ma­chi­ne lear­ning pue­den ser uti­li­za­das pa­ra au­to­ma­ti­zar ata­ques in­te­li­gen­tes con­tra la in­fra­es­truc­tu­ra de una com­pa­ñía y otros con­ci­bie­ron es­ce­na­rios avan­za­dos de in­ge­nie­ría so­cial en los que la IA es uti­li­za­da pa­ra imitar el lé­xi­co de una per­so­na y ga­nar la con­fian­za de otra”, cuen­ta Gius­to Bi­lic. Cas­ta­ñe­da in­di­ca que en la li­te­ra­tu­ra se en­cuen­tra des­de ha­ce unos años el con­cep­to Ar­ti­fi­cially In­te­lli­gent Vi­rus (AIV), que re­vi­sa la vin­cu­la­ción de tec­no­lo­gías de IA a malwa­re: “El pro­ble­ma de la uti­li­za­ción IA en un vi­rus o malwa­re es que re­que­ri­ría to­ne­la­das de re­cur­sos co­mo CPU y me­mo­ria pa­ra eje­cu­tar­se”.

“No co­no­ce­mos nin­gún malwa­re que apro­ve­che la IA, pe­ro hu­bo una com­pe­ten­cia en 2016 lla­ma­da Dar­pa Cy­ber Grand Cha­llen­ge, don­de el ob­je­ti­vo era crear un sis­te­ma de ata­que y de­fen­sa que ata­ca­ra de for­ma au­tó­no­ma el soft­wa­re enemi­go y se pro­te­gie­ra de los ata­ques”, re­la­ta Sa­lat. “Los re­sul­ta­dos mues­tran que es téc­ni­ca­men­te po­si­ble, aun­que to­da­vía es bas­tan­te pe­sa­do”.

Fu­tu­ro im­per­fec­to

“Na­da pre­vie­ne que los desa­rro­lla­do­res de malwa­re uti­li­cen la mis­ma tec­no­lo­gía pa­ra ge­ne­rar malwa­re más po­de­ro­so y di­fí­cil de com­ba­tir: el fu­tu­ro de la se­gu­ri­dad in­for­má­ti­ca po­dría in­cluir malwa­re in­te­li­gen­te tra­tan­do de no ser de­tec­ta­do por so­lu­cio­nes in­te­li­gen­tes”, de­fi­ne Tan­de­ter.

La gran pre­gun­ta es has­ta qué pun­to se­rá po­si­ble com­ba­tir un malwa­re in­te­li­gen­te. “Al igual que el ce­re­bro, es di­fí­cil sa­ber exac­ta­men­te có­mo apren­de la IA, lo que di­fi­cul­ta la se­gu­ri­dad. Con­tro­lar los da­tos de los cua­les se ali­men­tan los sis­te­mas es un pri­mer pa­so, ya que ha­cer­lo le da al pro­pie­ta­rio cier­to con­trol de lo que la IA pue­de apren­der”, de­ta­lla Sa­lat.

Mien­tras tan­to, al­gu­nas em­pre­sas si­guen pe­lean­do con­tra vi­rus de los ’80. “Es ne­ce­sa­rio des­te­rrar que una so­lu­ción de se­gu­ri­dad va a re­sol­ver to­das las vul­ne­ra­bi­li­da­des. Eso ya no exis­te más”, in­di­ca Pablo Du­bois, ge­ren­te de Pro­duc­tos de Se­gu­ri­dad del pro­vee­dor de co­mu­ni­ca­cio­nes Cen­tur­ylink pa­ra Amé­ri­ca la­ti­na. “Las so­lu­cio­nes se de­ben plan­tear en mo­de­los de ca­pas, pro­te­gien­do ca­da una y te­nien­do en men­te que po­si­ble­men­te ya se ha­yan vul­ne­ra­do, por lo que es ne­ce­sa­rio con­si­de­rar có­mo con­tro­lar o mi­ni­mi­zar ese ries­go”, agre­ga.

“Es im­po­si­ble im­pe­dir al 100 por cien­to cual­quier ata­que, por lo que es tan o más im­por­tan­te sa­ber có­mo ac­tuar an­te un he­cho que pre­ve­nir­lo”, di­ce. “Los es­pe­cia­lis­tas de­ben es­tar pre­pa­ra­dos pa­ra en­fren­tar­lo”, am­plía Co­nos­ciu­to.

“Ya exis­te un gran atra­so en la se­gu­ri­dad de los ac­ti­vos fí­si­cos y ló­gi­cos de las em­pre­sas, en especial en em­pre­sas lo­ca­les. Cuan­to más se in­vier­te en di­gi­tal trans­for­ma­tion y se pien­sa só­lo en los pro­ce­sos de ne­go­cios y no en la se­gu­ri­dad, ese ries­go cre­ce ex­po­nen­cial­men­te”, ad­vier­te Abril.

La se­gu­ri­dad de la in­for­ma­ción ame­na­za con desafíos nue­vos y po­de­ro­sos mien­tras las em­pre­sas aún no re­sol­vie­ron el es­ce­na­rio del pa­sa­do in­me­dia­to. ¿Es po­si­ble re­sol­ver es­te di­le­ma. Ji­mé­nez Soler con­clu­ye: “Hay dos ti­pos de em­pre­sas. Las que ya fue­ron hac­kea­das y las que to­da­vía no lo sa­ben”.

De­ni­se Gius­to Bi­lic, de ESET: “La ca­pa­ci­ta­ción es cla­ve pa­ra mi­ni­mi­zar la po­si­bi­li­dad de un ata­que exi­to­so”.

Fo­to: Gra­cie­la De­cur­gez.

Pablo Du­bois, de Cen­tury Link:”hay que pen­sar la se­gu­ri­dad en ca­pas”.

Newspapers in Spanish

Newspapers from Argentina

© PressReader. All rights reserved.