¿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 El Salvador - - Sumario -

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/Browser 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 Goo­gle es: goo­gle.com 86400 IN CAA 0 is­sue”sy­man­tec. com”. Es­to sig­ni­fi­ca que Goo­gle 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ásico 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 da­tos 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 da­tos, es un buen in­di­ca­dor de un com­por­ta­mien­to ma­li­cio­so.

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.

La ubi­cui­dad del DNS y los da­tos 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 da­tos 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.

Newspapers in Spanish

Newspapers from El Salvador

© PressReader. All rights reserved.