¿CÓ­MO PUE­DEN LOS BUE­NOS APRO­VE­CHAR EL DNS?

A me­nu­do es uti­li­za­do por la gen­te ma­la pa­ra com­pro­me­ter la red de una em­pre­sa, pe­ro una for­ma de usar­lo del su la­do es pre­Vi­nien­do los cer­ti­fi­ca­dos SSL no au­to­ri­za­dos.

IT Now Costa Rica - - SUMARIO - CIO

A me­nu­do es uti­li­za­do por la gen­te ma­la pa­ra com­pro­me­ter la red de una em­pre­sa, pe­ro una for­ma de usar­lo del su la­do es pre­vi­nien­do los cer­ti­fi­ca­dos SSL no au­to­ri­za­dos.

Lo pri­me­ro es que las Au­to­ri­da­des de Cer­ti­fi­ca­ción de Au­to­ri­za­ción (CAA por sus si­glas en in­glés) de­be­rán co­men­zar a im­ple­men­tar a un re­gis­tro es­pe­cial de sis­te­ma de nom­bres de do­mi­nio (DNS) que per­mi­ta a los pro­pie­ta­rios de do­mi­nios es­pe­ci­fi­car quién es­tá au­to­ri­za­do a emi­tir cer­ti­fi­ca­dos SSL pa­ra los mis­mos.

Es­te re­gis­tro se con­vir­tió en un es­tán­dar en 2013, pe­ro no tu­vo un gran im­pac­to en el mun­do real por­que las au­to­ri­da­des de cer­ti­fi­ca­ción (AC) no es­ta­ban obli­ga­das a cum­plir con él.

El re­gis­tro per­mi­te al pro­pie­ta­rio de un do­mi­nio en­tre­gar a las au­to­ri­da­des de cer­ti­fi­ca­ción una lis­ta quie­nes pue­den emi­tir cer­ti­fi­ca­dos SSL/ TLS pa­ra ese do­mi­nio. La ra­zón es li­mi­tar los ca­sos de emi­sión de cer­ti­fi­ca­dos no au­to­ri­za­dos, que pue­den ser ac­ci­den­ta­les o in­ten­cio­na­les, si una AC es­tá com­pro­me­ti­da o tie­ne un em­plea­do ma­lin­ten­cio­na­do.

Ba­jo las re­glas de la in­dus­tria crea­das por el CA/Brow­ser Fo­rum, una or­ga­ni­za­ción que reúne a los prin­ci­pa­les pro­vee­do­res de na­ve­ga­do­res y AC, las au­to­ri­da­des de cer­ti­fi­ca­ción de­be­rán va­li­dar que las so­li­ci­tu­des de cer­ti­fi­ca­dos SSL sean ori­gi­na­das los pro­pie­ta­rios de los do­mi­nios o por que tie­ne el con­trol de ellos.

Es­ta ve­ri­fi­ca­ción de la pro­pie­dad, que sue­le ser au­to­ma­ti­za­da, exi­ge so­li­ci­tar al pro­pie­ta­rio del do­mi­nio que cree un re­gis­tro TXT del DNS con un va­lor es­pe­cí­fi­co o que car­gue có­di­gos de au­to­ri­za­ción en una ubi­ca­ción es­pe­cí­fi­ca de la es­truc­tu­ra de su si­tio, de­mos­tran­do así su con­trol so­bre el do­mi­nio.

Sin em­bar­go, la pi­ra­te­ría en un si­tio web tam­bién po­dría dar a un ata­can­te la ca­pa­ci­dad de pa­sar por di­chas ve­ri­fi­ca­cio­nes y so­li­ci­tar un cer­ti­fi­ca­do vá­li­do pa­ra el do­mi­nio com­pro­me­ti­do. Un cer­ti­fi­ca­do de es­te ti­po po­dría ser uti­li­za­do pos­te­rior­men­te pa­ra lan­zar ata­ques man-in-the-midd­le con­tra los usua­rios o pa­ra di­ri­gir­los a pá­gi­nas de phis­hing (su­plan­ta­ción de iden­ti­dad).

El ob­je­ti­vo de­trás del re­gis­tro CAA es li­mi­tar quién pue­de emi­tir cer­ti­fi­ca­dos pa­ra un do­mi­nio. Por ejem­plo, el re­gis­tro CAA de Google es: google.com 86400 IN CAA 0 is­sue”sy­man­tec. com”. Es­to sig­ni­fi­ca que Google au­to­ri­za es­pe­cí­fi­ca­men­te a Sy­man­tec a emi­tir cer­ti­fi­ca­dos pa­ra su nom­bre de do­mi­nio prin­ci­pal.

En mar­zo, el CA/B Fo­rum de­ci­dió ha­cer obli­ga­to­ria la com­pro­ba­ción de re­gis­tro CAA co­mo par­te del pro­ce­so de emi­sión de cer­ti­fi­ca­dos. Es­te re­qui­si­to en­tra­rá en vi­gor el 8 de sep­tiem­bre y las AC que no cum­plan es­ta nor­ma vio­la­rán las re­glas de la in­dus­tria y se arries­ga­rán a su­frir san­cio­nes.

Ade­más de la eti­que­ta “is­sue”, el re­gis­tro CAA es­ta­ble­ce otra, lla­ma­da “io­def ”, que tam­bién se­rá de cum­pli­mien­to obli­ga­to­rio pa­ra las AC. Es­ta per­mi­ti­rá al pro­pie­ta­rio del do­mi­nio es­pe­ci­fi­car una di­rec­ción de co­rreo elec­tró­ni­co o una di­rec­ción URL don­de las AC pue­dan re­por­tar las so­li­ci­tu­des de cer­ti­fi­ca­dos que en­tren en con­flic­to con la po­lí­ti­ca de do­mi­nio del CAA.

Ayu­dan­do a los bue­nos

El DNS es un com­po­nen­te bá­si­co de la in­fra­es­truc­tu­ra que a me­nu­do es pa­sa­do por al­to cuan­do se pien­sa en la se­gu­ri­dad. Fre­cuen­te­men­te es uti­li­za­do por la gen­te ma­la pa­ra com­pro­me­ter a una red em­pre­sa­rial. La se­gu­ri­dad del DNS ge­ne­ral­men­te es per­ci­bi­da co­mo la pro­tec­ción de su ar­qui­tec­tu­ra, de la in­fra­es­truc­tu­ra de va­rios vec­to­res de ata­que o del man­te­ni­mien­to de una lis­ta de si­tios web en blan­co y ne­gro pa­ra con­tro­lar el ac­ce­so a los do­mi­nios ma­li­cio­sos, to­do lo cual es sin du­da es una par­te im­por­tan­te, pe­ro hay mu­chos más con­tro­les de se­gu­ri­dad e in­te­li­gen­cia, que pue­den ge­ne­ra­ra be­ne­fi­cios del DNS pa­ra ser uti­li­za­dos por los bue­nos co­mo una ven­ta­ja. Hu­ma­yun Wahab, ge­ren­te de mar­ke­ting de pro­duc­to de Blue­cat Net­works, enu­me­ra las di­ver­sas ven­ta­jas del DNS in­terno y ex­terno pa­ra que las em­pre­sas que pue­dan mi­ti­gar proac­ti­va­men­te las ame­na­zas, co­no­ci­das y des­co­no­ci­das.

1 -Vi­si­bi­li­dad in­ter­na y ex­ter­na

Ya sea una in­fra­es­truc­tu­ra de IT, un ser­vi­dor cor­po­ra­ti­vo, un es­cri­to­rio, un or­de­na­dor por­tá­til, un sis­te­ma POS, dis­po­si­ti­vos no con­fia­bles co­nec­ta­dos a una red de in­vi­ta­dos e in­clu­so dis­po­si­ti­vos no ad­mi­nis­tra­dos, co­mo te­lé­fo­nos in­te­li­gen­tes o cual­quier otra “co­sa” co­nec­ta­da, to­dos usan DNS pa­ra co­mu­ni­car­se in­ter­na y ex­ter­na­men­te. Su om­ni­pre­sen­cia le pro­por­cio­na una tre­men­da vi­si­bi­li­dad in­ter­na y ex­ter­na en la red, la que pue­de ayu­dar a ma­ne­jar los ni­ve­les ca­da vez ma­yo­res de ries­go que plan­tean los ma­los ac­to­res in­ter­nos y las ame­na­zas ex­ter­nas.

2-Des­cu­brir la in­ten­ción de un usua­rio o dis­po­si­ti­vo co­nec­ta­do a la red

La ri­que­za de datos ge­ne­ra­dos por los ser­vi­cios del DNS pro­por­cio­na una opor­tu­ni­dad pa­ra apren­der el com­por­ta­mien­to tí­pi­co del usua­rio/clien­te, el que pue­de ser uti­li­za­do pa­ra iden­ti­fi­car si em­pie­za a des­viar­se de ese per­fil o si co­mien­za a su­pe­rar la to­le­ran­cia al ries­go que una em­pre­sa ha es­ta­ble­ci­do. Por ejem­plo, si un clien­te o usua­rio es­ta­ble­ce una co­mu­ni­ca­ción con un do­mi­nio re­cién ge­ne­ra­do fue­ra de las ho­ras nor­ma­les de tra­ba­jo, di­ga­mos al­re­de­dor de las 3 am; y trans­fie­re va­rios gi­gaby­tes de datos, es un buen in­di­ca­dor de un com­por­ta­mien­to ma­li­cio­so.

3-Apli­ca­ción de po­lí­ti­cas

Uno de los desafíos en el mun­do de la se­gu­ri­dad es la apli­ca­ción de po­lí­ti­cas en to­dos los dis­po­si­ti­vos de una em­pre­sa. En po­cas pa­la­bras, hay de­ma­sia­dos dis­po­si­ti­vos, sis­te­mas ope­ra­ti­vos y otras “co­sas” en la red; al­gu­nas de los cua­les ni si­quie­ra son pro­pie­dad de la em­pre­sa, por lo que un agen­te de con­trol no se pue­de ins­ta­lar en ellos. DNS cam­bia es­te mo­de­lo dan­do vi­si­bi­li­dad a lo que ca­da dis­po­si­ti­vo es­tá in­ten­tan­do ha­cer, da­do que el DNS es­tá en una po­si­ción úni­ca pa­ra per­mi­tir o ne­gar el ac­ce­so a los re­cur­sos, es fá­cil fi­jar una po­lí­ti­ca que per­mi­ta o nie­gue ac­ti­vi­da­des es­pe­cí­fi­cas ba­sa­das en el cri­te­rio es­ta­ble­ci­do. Por ejem­plo, con el DNS se pue­de es­ta­ble­cer una po­lí­ti­ca pa­ra ha­bi­li­tar el ac­ce­so a las re­des so­cia­les en una red inalám­bri­ca de in­vi­ta­dos, pe­ro no en los ac­ti­vos pro­pie­dad de la em­pre­sa.

4-Eva­lua­ción y pun­tua­ción de ries­gos

Una de las for­ta­le­zas que el DNS pro­por­cio­na co­mo pla­ta­for­ma de se­gu­ri­dad es su ca­pa­ci­dad de lle­var el con­tex­to a una so­li­ci­tud de­ter­mi­na­da. Es­to per­mi­te eva­luar el ries­go ge­ne­ral de una ac­ción, la cual pue­de ser blo­quea­da o per­mi­ti­da en ba­se a la to­le­ran­cia de­ter­mi­na­da por la or­ga­ni­za­ción. Por ejem­plo, si un clien­te con­sul­ta www. yahooX.com, el DNS pue­de ser uti­li­za­do pa­ra ha­cer una se­rie de pre­gun­tas so­bre esa con­sul­ta y pro­por­cio­nar una pun­tua­ción de su ries­go, lo que ge­ne­ra­rá un cur­so de ac­ción, co­mo blo­quear la so­li­ci­tud, su re­di­rec­ción o al­gún otro.

5- Se­gu­ri­dad fo­ren­se

La ubi­cui­dad del DNS y los datos que pro­por­cio­na no só­lo fa­ci­li­tan la vi­si­bi­li­dad de to­da la ac­ti­vi­dad en una red, sino que tam­bién pro­du­cen datos ho­nes­tos que pue­den ser ana­li­za­dos pa­ra lo­ca­li­zar la raíz de una vio­la­ción, una vez que se la ha iden­ti­fi­ca­do. Es­tos datos fác­ti­cos in­clu­yen de­ta­lles co­mo dis­po­si­ti­vos de ori­gen, su ti­po, el sis­te­ma ope­ra­ti­vo, las apli­ca­cio­nes o ser­vi­cios que se eje­cu­tan en ese dis­po­si­ti­vo, los do­mi­nios a que ac­ce­de, etc. Es una mi­na de oro de in­for­ma­ción pa­ra uti­li­zar en la se­gu­ri­dad fo­ren­se.

6- Pos­tu­ra de se­gu­ri­dad me­jo­ra­da

Una es­tra­te­gia de de­fen­sa en pro­fun­di­dad y las tec­no­lo­gías que la apo­yan son ex­tre­ma­da­men­te va­lio­sas. Aun­que ca­da ni­vel tie­ne su pro­pio al­can­ce y pro­pó­si­to, el DNS pue­de me­jo­rar o in­clu­so con­ver­tir­se en el sis­te­ma de se­gu­ri­dad de la or­ga­ni­za­ción, sin ne­ce­si­dad de des­ple­gar nue­vas in­fra­es­truc­tu­ras, re­des de re­di­se­ño o in­te­rrum­pir las prác­ti­cas ope­ra­ti­vas ac­tua­les.

Una de las for­ta­le­zas que el DNS pro­por­cio­na co­mo pla­ta­for­ma de se­gu­ri­dad es su ca­pa­ci­dad de lle­var el con­tex­to a una so­li­ci­tud de­ter­mi­na­da.

Newspapers in Spanish

Newspapers from Costa Rica

© PressReader. All rights reserved.