1. Para el desarrollo del trabajo, el estudiante debe leer el caso “INCUMPLIMIENTO DE SEGURIDAD EN TJX”, revisa este caso :
2.  
3. Cuando Richel aceptó la oferta de TJX dos meses antes, estaba seguro de que estaba haciendo
4. una inteligente carrera. Como director de información (CIO) de un
5. pequeño minorista canadiense, Richel conocía a TJX como un mego minorista y líder de mercado
6. en una categoría de nicho en América del Norte. También era consciente de que la compañía
7. había sido atacada por piratas informáticos en diciembre del 2006. La administración había
8. minimizado el ataque durante la entrevista de trabajo, en la que Richel no podía obtener
9. información más allá de lo que estaba disponible en el dominio público. Richel se había movido
10. para firmar con la compañía porque el panel había expresado confianza en su experiencia en la
11. industria minorista y su capacidad para gestionar la seguridad de la tecnología de la información
12. (TI). La posición también se estaba creando para él. Richel estaba impresionado. En cuanto a la
13. piratería, sabía por experiencia que todos los minoristas, grandes y pequeños, eran vulnerables
14. a los ataques y que una de las mejores garantías era el compromiso de alto nivel con la seguridad
15. de TI.
16. Cuando comenzó a rastrear el desarrollo en detalle durante el período interino, Richel se dio
17. cuenta de que la escala de intrusión había aumentado. Si bien TJX había dicho que los datos de
18. aproximadamente 46 millones de titulares de tarjetas de crédito y débito se habían visto
19. afectados, una demanda colectiva presentada por las instituciones financieras interesadas, a
20. fines de octubre de 2007, había colocado el número en unos 94 millones. The Boston Globe,
21. al llamarlo la mayor violación de datos personales que se haya reportado en la historia de la
22. seguridad de TI, citó a un profesional de Gartner Inc. diciendo: "Este es el mayor robo de tarjetas
23. de todos los tiempos. Ha hecho un daño considerable”3
24. . Las demandas de los clientes afectados
25. y las instituciones financieras avanzaban rápidamente. La Oficina Federal de Investigaciones
26. (FBI) del gobierno de los Estados Unidos ya formaba parte de la investigación interna de la
27. compañía.
28. Ahora, sentado en su automóvil en el tráfico, a minutos de comenzar su posición en TJX, Richel
29. estaba reflexionando sobre los problemas, varios nuevos para él, con los que tendría que lidiar
30. de manera simultánea y rápida.
31. ANTECEDENTES DE LA EMPRESA
32. TJX fue el minorista de ropa y artículos para el hogar más grande de los Estados Unidos en el
33. segmento fuera de precio. TJX se ubicaba en el puesto 138º en el ranking 500 Fortunas para el
34. año 2006. Con US$ 17,4 mil millones en ventas para el año que termina enero de 2007, la
35. compañía tenía más del triple de tamaño de Ross Stores Inc., su competidor más cercano.
36. Fundada en 1976, TJX operaba ocho negocios independientes bajo un paraguas común: T.J.
37. Maxx, Marshalls, HomeGoods, A.J. Wright y Bob's Stores en los Estados Unidos; Winners
38. y HomeSense en Canadá; y T.K.Maxx en Europa. El grupo tenía más de 2400 tiendas y alrededor
39. de 125000 asociados.
40. Como un minorista fuera de precio, TJX ocupaba el espacio entre los grandes descuentos que
41. vendían productos sin marca a precios bajos y tiendas departamentales o especializadas que
42. vendían productos con marca a precios Premium. TJX vendió prendas de vestir de marca y
43. modas para el hogar a precios entre 20% y 70% más bajos que las tiendas departamentales o
44. especializadas. A lo largo del año, compró mercadería directamente a los fabricantes a precios
45. mayoristas, en contraste con las mercaderías del departamento y las tiendas especializadas, que
46. a menudo se quedaban con exceso de productos en cada temporada como resultado de
47.  
48. 3
49. Jenn Abelson, "La violación de datos en TJX es llamada la más grande de la historia", The Boston Globe,
50. 29 de marzo del 2007
51. Página 3 9B08E003
52. cancelaciones de pedidos atrasadas, plazos de producción incumplidos y cambios de
53. programación.
54. La eficiencia operativa, las relaciones con los proveedores y la escala eran cruciales para una
55. tienda fuera de precio, mientras que la moda era la variable más importante para los
56. departamentos y las tiendas especializadas. Para las tiendas fuera de precio, la calidad de los
57. sistemas de información internos fue fundamental para mantener los márgenes, entre los más
58. bajos en ventas minoristas y para mantenerse competitivo. Los sistemas de TI ayudaron a
59. grandes minoristas como TJX a conectar personas, lugares e información a lo largo de la cadena
60. de valor. Ellos permitieron la entrega rápida de los datos, lo que facilita las decisiones rápidas
61. en diferentes niveles. Los proveedores, compradores, comerciantes, asociados de tiendas,
62. clientes e instituciones financieras estaban interconectados a través de las redes de TI,
63. aumentando así la productividad del minorista (rendimiento del producto desde la fabricación
64. hasta las ventas). Las tecnologías en la tienda (como los quioscos y los escáneres portátiles de
65. códigos de barras de precios / inventarios) ayudaron a los minoristas a mejorar el servicio al
66. cliente y diferenciar sus tiendas de las de los competidores. Muchos minoristas invirtieron
67. en tecnologías de gestión de relaciones con los clientes (CRM) para aumentar los ingresos
68. dirigiéndose a los clientes más rentables.
69. TJX había presenciado un cambio de guardia en el nivel más alto de la administración en el otoño
70. del 2005. Un enfoque en el "crecimiento de ventas rentables" había llevado a un rebote en los
71. resultados financieros para el año que terminó en enero del 2007. En una empresa en la que los
72. márgenes eran bajos, los ingresos netos como porcentaje de ventas habían aumentado (ver
73. Anexo 1).
74. LA INTRUSION INFORMATICA4
75. Fue el 18 de diciembre del 2006, que la compañía se enteró de la piratería (ver Apéndice 1 para
76. un glosario de términos utilizados en investigaciones de intrusión y detección de
77. computadoras). La presencia de software sospechoso, archivos de computadora alterados
78. y datos mezclados fueron algunas de las primeras evidencias de la intrusión. Involucraba al
79. segmento de la red de computadoras que maneja tarjetas de pago (tanto tarjetas de crédito
80. como tarjetas de débito), cheques y transacciones de devolución de mercancías para
81. los clientes. Parecía afectar a todos los ocho negocios de la compañía y todas las tiendas en los
82. Estados Unidos, Puerto Rico, Canadá y el Reino Unido. La compañía comenzó rápidamente una
83. investigación interna y llamó a los consultores de seguridad - General Dynamics Corporation e
84. International Business Machines (IBM) Corporation - al día siguiente. Este último confirmó, el 21
85. de diciembre, que los sistemas informáticos de la compañía habían sido "intervenidos" y que el
86. intruso todavía estaba en los sistemas. Al planear contener la intrusión y proteger los datos de
87. los clientes, la compañía notificó a los funcionarios encargados de hacer cumplir la ley. El Servicio
88. Secreto de los EE. UU sugirió que la divulgación de la intrusión podría impedir una investigación
89. criminal en curso y que, por lo tanto, TJX debería mantener la confidencialidad hasta que
90. el Servicio Secreto le haya indicado lo contrario. A la compañía sólo se le permitió notificar a los
91. bancos contratantes, a las compañías de tarjetas de crédito y de débito, y a las compañías de
92. Procesamiento de cheques sobre la intrusión.
93. El 21 de febrero de 2007, TJX hizo un anuncio público del tiempo y el alcance de la intrusión. Dijo
94. que un intruso no autorizado accedió por primera vez a sus sistemas informáticos en julio del
95. 2005, en fechas subsiguientes al 2005 y nuevamente desde mediados de mayo de 2006 hasta
96.  
97. 4 10-K Declaraciones, www.tjx.com/investorininformation/SECfilings/10-K/03/28/2007, 28 de Marzo del
98. 2007.
99. Página 4 9B08E003
100. mediados de enero de 2007. Afirmó que no se habían robado datos de los clientes después del
101. 18 de diciembre del 2006. La compañía dijo que al tratar de identificar la naturaleza de los datos
102. que fue robada por el intruso, TJX se enfrentó a tres obstáculos. Primero, antes de que se
103. descubriera la intrusión que había eliminado, en el curso ordinario de los negocios, el contenido
104. de muchos archivos que habían sido robados. Los archivos pertenecían a registros que se
105. remontaban al 2002. En segundo lugar, la tecnología utilizada por el intruso había hecho
106. imposible que TJX determinara el contenido de la mayoría de los archivos robados el 2006. En
107. tercer lugar, TJX creía que algunos datos fueron robados durante el pago del Proceso de
108. aprobación de la tarjeta. Por lo tanto, no pudo identificar con precisión la naturaleza de todos
109. los datos que eran vulnerables al robo5
110. .
111. La compañía dijo:
112. No creemos que los números de identificación personal (PIN) de los clientes se
113. hayan comprometido, ya que, antes del almacenamiento en el sistema de Framingham,
114. se cifran por separado en las tiendas de Puerto Rico y Canadá de los EE. UU en la página
115. de PIN, y porque no almacenamos los PIN en el sistema de Watford.
116. El "sistema Framingham" procesó y almacenó información relacionada con tarjetas de débito y
117. crédito, cheques y mercancías no devueltas para devoluciones de los clientes de tiendas TJMaxx,
118. Marshalls, HomeGoods y A.J.Wright en los Estados Unidos y Puerto Rico, y en tiendas Winners
119. y HomeSense en Canadá. El "sistema Watford" procesó y almacenó información relacionada con
120. las transacciones de la tarjeta de pago en TKMaxx en el Reino Unido e Irlanda.
121. Hasta diciembre de 2006, cuando se descubrió la intrusión, TJX almacenaba la información
122. personal de los clientes en su sistema Framingham. La información, recibida de sus tiendas en
123. los Estados Unidos, Puerto Rico y Canadá, se refería a devoluciones de mercancías sin recibos y
124. algunas transacciones de cheques. La información personal consistía en los números de la
125. licencia de conducir y los números de identificación (ID) (tales como identificación del estado,
126. en algunos casos incluyendo números de seguridad social), junto con los nombres y direcciones
127. de los clientes que habían devuelto bienes. Desde el 7 de abril de 2004, la práctica era cifrar la
128. información antes de fuera almacenado. Los caracteres reales se sustituyeron por cifrado,
129. utilizando un algoritmo de cifrado proporcionado por el proveedor de software.
130. TJX aseguró a sus clientes de tarjetas de pago que sus nombres y direcciones no se incluyeron
131. con los datos de la tarjeta de pago que se creían robados por cualquier período, porque no
132. procesó ni almacenó esa información ni en el sistema de Framingham ni en el de Watford, en
133. relación con las transacciones de tarjetas de pago. También asegura a sus clientes de que el 3
134. de abril de 2006, el sistema de Framingham enmascararon los PIN de tarjetas de pago y algunas
135. porciones de información de transacciones de cheques. Para las transacciones después del 7 de
136. abril de 2004, el sistema Framingham codificaba todas las tarjetas de pago y verificaba
137. información de la transacción. Con respecto al sistema de Watford, las prácticas de
138. enmascaramiento y encriptación se implementaron en varios momentos para varias partes de
139. los datos de la tarjeta de pago.
140. Investigaciones posteriores revelaron que los datos habían sido recogidos por un grupo de
141. residentes de Europa del Este (que se especializa en recolectar números de tarjetas de crédito
142. robadas), que a su vez los pasaron a un grupo en Florida. Ambos grupos formaban parte de una
143. red de fraude diversificada cuyas actividades se incluyen la fabricación de “plástico blanco, " Una
144.  
145. 5 Página de preguntas frecuentes, en el sitio web de la compañía, disponible en http:
146. //www.tjx.com/tjx_faq.html, consultada el 13 de febrero del 2008.
147. Página 5 9B08E003
148. tarjeta simple con una banda magnética correctamente codificada. Aunque no se puede usar en
149. encuentros personales con empleados de ventas minoristas, el plástico blanco se puede deslizar,
150. sin riesgo de detección, durante las auto compras (en las estaciones de servicio y en algunas
151. tiendas de cajas grandes). El grupo de Florida, bajo la observación del Servicio Secreto, también
152. se especializó en la fabricación de tarjetas de crédito falsas con relieve, logotipos, hologramas y
153. tiras magnéticas debidamente codificadas. Se dijo que el grupo había aplicado nuevas bandas
154. magnéticas que contenían los datos robados para generar tarjetas falsas. Habiendo hecho esto,
155. recurrieron a una táctica común entre los estafadores: usó las tarjetas de crédito falsas para
156. comprar tarjetas de regalo (generalmente hasta $ 400, antes de que se requiriera una
157. identificación adicional) y luego canjearon las tarjetas de regalo en las tiendas más tarde. La
158. técnica del flotador de tarjetas de regalo era atractiva para los estafadores porque les daba
159. tiempo. Cuando la víctima de robó de una tarjeta de crédito la detectó, fue solo una cuestión
160. de horas antes de que la tarjeta fuera invalidada y su poder de gasto hubiera caducado, un
161. resultado que la compra de tarjetas de regalo eludió.
162. ¿COMO PASO?
163. Richel supo a través de su investigación preparatoria que había una opinión generalizada entre
164. los profesionales de seguridad de TI de que los sistemas TJX habían sido intervenidos en
165. múltiples puntos de ataque. Esta teoría podría explicar en parte la enormidad de la intrusión,
166. que afectó a millones de personas. Estos múltiples puntos incluidos el cifrado, el ataque
167. inalámbrico, las unidades USB en los quioscos de las tiendas, el procesamiento de registros y el
168. cumplimiento de las Prácticas de auditoría. Aunque TJX identificó el cifrado como una
169. vulnerabilidad particular, Richel sintió que tendría que investigar completamente los otros
170. informes de múltiples vulnerabilidades de seguridad como una primera prioridad en su nuevo
171. rol.
172. Cifrado
173. TJX había hecho el siguiente anuncio de cómo, pensó, había ocurrido la intrusión.
174. A pesar de nuestras prácticas de enmascaramiento y encriptación en nuestro sistema
175. Framingham en 2006, la tecnología utilizada en la intrusión de la computadora durante
176. 2006 podría haber permitido al Intruso poder robar datos de la tarjeta de pago de
177. nuestro sistema Framingham durante la emisión de la tarjeta de pago Proceso de
178. aprobación, en el que los datos se transmiten a los emisores de tarjetas de pago sin
179. cifrado. Además, creemos que el intruso tuvo acceso a la herramienta de descifrado para
180. el software de cifrado utilizado por TJX.
181. Ampliamente utilizado en la industria minorista para proteger la información de tarjetas de
182. crédito en transacciones de comercio electrónico, cifrado fue un proceso de codificar la
183. información para que no fuera legible hasta que el destinatario la pudiera descifrar. Dado que
184. las tarjetas de crédito no podían procesarse cuando sus números estaban encriptados (o
185. codificados), un delincuente inteligente podía buscar una forma de obtener los datos durante
186. ese período de tiempo cuando estaba en una estado de estar "en claro", es decir, cuando fue
187. descifrado (o descifrado) - por menos de un segundo. Además, como TJX descubrió, los intrusos
188. tenían la clave de descifrado para el software de cifrado (WEP) que estaba en uso en TJX.
189. Si bien la visión de TJX de cómo ocurrió el ataque parecía legítima, Richel sintió que podría
190. haber otros puntos de entrada para la intrusión de la computadora.
191. Página 6 9B08E003
192. Ataque inalámbrico
193. El Wall Street Journal fue uno de los primeros en sugerir que el robo de TJX comenzó en julio de
194. 2005 con un hackeo inalámbrico de una tienda Marshalls en St. Paul, Minnesota. Dijo el informe:
195. Los ladrones apuntaron una antena con forma de telescopio hacia la tienda y usaron una
196. computadora portátil para decodificar la transmisión de datos a través del aire entre
197. dispositivos portátiles de control de precios, cajas registradoras [puntos de venta,
198. probablemente] y las computadoras de la tienda. Eso les ayudó a piratear la base de
199. datos central de la matriz de Marshalls, TJX Cos. En Framingham, Massachusetts, para
200. robar repetidamente información sobre los clientes.
201. La tecnología inalámbrica era un medio popular para atacar a las cadenas minoristas. "Al
202. concentrarse en esas pequeñas armas de mano (control de precios) y sus interacciones con el
203. controlador de la base de datos, puede capturar direcciones IP. Esa es su Gateway", dijo el diario
204. a un auditor. También informó que los atacantes realizaron "la mayoría de sus robos durante los
205. períodos pico de ventas para capturar gran cantidad de datos y utilizaron esos datos para
206. descifrar el código de encriptación". Añadió:
207. Escucharon digitalmente a los empleados que ingresaron a la base de datos central de
208. TJX en Framingham y robó uno o más nombres de usuario y contraseñas. Con esa
209. información, configuraron sus propias cuentas en el sistema TJX y recopilaron datos de
210. transacciones, incluidos números de tarjetas de crédito, en aproximadamente 100
211. archivos grandes para su propio acceso. Pudieron ingresar al sistema TJX de forma
212. remota desde cualquier computadora en Internet. Confiaban tanto en no ser detectados
213. que se dejaron mensajes cifrados entre sí en la red de la compañía, para decirles qué
214. archivos ya se habían copiado y evitar la duplicación de trabajos.
215. Unidades USB en los quioscos de la tienda
216. Una historia de InformationWeek sugirió que la violación de datos había comenzado en TJX con
217. los quioscos en la tienda como puntos de entrada. "La gente que inició la brecha abrió la parte
218. posterior de esos terminales y usó unidades USB para cargar el software en esos terminales",
219. dijo la historia.
220. Las unidades USB contenían un programa de utilidad que permitía al intruso o intrusos
221. tomar el control de estos quioscos informáticos y convertirlos en terminales remotos
222. que se conectaban a las redes de TJX. Los firewalls en la red principal de TJX no estaban
223. configurados para defenderse contra el tráfico proveniente de los quioscos. Por lo
224. general, las unidades USB en los quioscos de la computadora se utilizan para conectar
225. ratones o impresoras.
226. Procesando Registros
227. En sus presentaciones ante la Comisión de Bolsa y Valores de EE. UU., TJX había puesto en riesgo
228. el número 46 millones de tarjetas. Pero en sus presentaciones ante los tribunales, los bancos
229. habían colocado el número en 94 millones. La discrepancia sugirió que TJX no tenía los datos de
230. Página 7 9B08E003
231. registro necesarios para realizar un análisis forense. Dichos registros generalmente
232. proporcionan información sobre los archivos en el sistema, cuando se agregaron, cambiaron,
233. accedieron, el formato de los contenidos, etc.
234. Prácticas de Cumplimiento
235. Los Estándares de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) fueron un
236. sólido plan de seguridad para los minoristas (ver el Anexo 2). Los documentos judiciales
237. mostraron que TJX no había cumplido con nueve de los doce requisitos que cubrían el cifrado,
238. los controles de acceso y firewalls.
239. Prácticas de Auditoría
240. Bajo PCI DSS, un auditor aprobado tenía que realizar una auditoría anual in situ y escaneos de
241. red trimestrales en lo que se denominó negocios de Nivel 1, aquellos que procesaron más de
242. seis millones de transacciones de tarjetas de crédito por año. Compañías de nivel 2 y 3 --aquellas
243. que procesaron entre 20,000 y seis millones de transacciones de tarjetas de crédito por año -
244. tuvieron que completar un cuestionario de autoevaluación anual y hacer que un proveedor
245. aprobado realice exploraciones de red trimestrales. TJX había pasado un chequeo de PCI DSS.
246. Los auditores no habían notado tres problemas clave con los sistemas TJX: la ausencia de
247. monitoreo de la red, la ausencia de registros y la presencia de datos no cifrados almacenados
248. en el sistema. Tampoco habían preguntado por qué TJX había retenido los datos de los clientes
249. años después de que debieran haber sido eliminados. Parte de la información robada provino
250. de transacciones concluidas en 2002.
251. EL VERANO DEL DESCONTENTO
252. Durante el verano de 2007, se presentaron una serie de acciones colectivas contra TJX en cortes
253. estatales y federales en Alabama, California, Massachusetts y Puerto Rico, y en cortes
254. provinciales de Canadá en Alberta, Columbia Británica, Manitoba, Ontario, Quebec y
255. Saskatchewan, en nombre de los clientes cuyos datos de transacciones supuestamente se vieron
256. comprometidos por la intrusión de la computadora. También se presentó una acción contra TJX
257. en un tribunal federal de Massachusetts, supuestamente en nombre de todas las instituciones
258. financieras que emitieron tarjetas de crédito y débito utilizadas en las tiendas TJX durante el
259. período de la braceta de seguridad. Las acciones afirmaron reclamos por negligencia y leyes
260. consuetudinarias relacionadas y / o causas legales de acción derivadas de la intrusión, y
261. buscaron diversas formas de alivio, incluidos daños, recursos judiciales o equitativos
262. relacionados, daños múltiples o punitivos y honorarios de abogados. Una serie de agencias
263. gubernamentales también estaban llevando a cabo investigaciones sobre si TJX había violado las
264. leyes relativas a la protección del consumidor.
265. DESARROLLOS RECIENTES
266. Para agosto de 2007, TJX había reservado un costo de US $ 168 millones por la violación de datos
267. que había anunciado en febrero. $ 118 millones en costos después de impuestos tomados en el
268. trimestre más reciente y $ 21 millones proyectados como un posible golpe para 2008 además
269. de los $ 29 Millones ya reportados en trimestres anteriores. El Boston Globe había citado a un
270. funcionario de TUX diciendo que la cifra trimestral después de impuestos de US $ 118 millones
271. era aproximadamente $ 196 millones antes de impuestos, y que los $ 21 millones para 2008
272. eran aproximadamente $ 35 millones antes de impuestos.
273. Página 8 9B08E003
274. El 21 de septiembre de 2007, la compañía celebró un acuerdo de conciliación, sujeto a las
275. aprobaciones de los tribunales, en relación con las acciones colectivas de los clientes. Según el
276. acuerdo, los clientes que habían devuelto la mercancía sin un recibo y a quienes TJX había
277. enviado cartas que informaban que su licencia de conducir u otra información de identificación
278. podrían haber sido comprometidas, se les ofreció un seguimiento crediticio durante tres años,
279. junto con la cobertura del seguro contra robo de identidad pagada por TJX. La compañía también
280. reembolsaría a estos clientes el costo documentado de los reemplazos de la licencia de conducir.
281. La compañía debía ofrecer cupones a los clientes que demostraron que compraban en las
282. tiendas TJX durante los períodos relevantes y que habían incurrido en ciertos costos como
283. resultado de la intrusión. TJX también organizaría un evento especial único de apreciación del
284. cliente de tres días, en el que los precios se reducirían en un 15 por ciento.
285. 12 DE NOVIEMBRE DEL 2007
286. Cuando se vio el letrero de la sede de TJX, Richel sintió una renovada determinación de ver la
287. crisis floreciente en TJX como una oportunidad. Usaría sus habilidades de liderazgo empresarial,
288. combinadas con sus habilidades para trabajar con la organización de TI, para mantenerse al
289. tanto de la situación. Él vio que sus prioridades se dividían en dos áreas distintas: a corto y largo
290. plazo. La prioridad a corto plazo era comprender los puntos de falla y mejorar e implementar la
291. seguridad de los sistemas en TJX. A largo plazo, Richel tuvo que trabajar para minimizar los
292. riesgos, para que la intrusión no volviera a ocurrir. Lo más importante es que necesitaba
293. asegurar el compromiso de la administración con el hecho de que la seguridad de TI era un
294. problema comercial y no un problema de tecnología.
295. El primer visitante que tuvo en su oficina ese día fue Vincent George, quien se presentó como el
296. gerente de servicio al cliente de la compañía. "Bienvenido a la fiesta", dijo, dándole una copia
297. de una carta que había recibido por correo el día anterior (vea el Apéndice 2); "Te alcanzaré más
298. tarde en el día".
299.  
300. Fin del caso
301.  
302. También revisar el Estándar ISO/IEC 27001 (Anexo A)
303.  
304. ANEXO A
305. (NORMATIVO)
306.  
307. OBJETIVOS DE CONTROL Y CONTROLES DE
308. REFERENCIA
309.  
310. Los objetivos de control y controles listados en la Tabla A.1 son directamente derivados desde y alineados con los listados en ISO/IEC 27002:2013[1], Cláusulas 5 a 18 y se utilizan en el contexto con el Apartado 6.1.3.
311.  
312. TABLA A.1 – Objetivos de control y controles
313.  
314. A.5 Políticas de seguridad de la información
315. A.5.1 Dirección de la gerencia para la seguridad de la información
316. Objetivo: Proporcionar dirección y apoyo de la gerencia para la seguridad de la información en concordancia con los requisitos del negocio y las leyes y regulaciones relevantes.
317. A.5.1.1 Políticas para la seguridad de la información Control
318. Un conjunto de políticas para la seguridad de la información debe ser definido, aprobado por la gerencia, publicado y comunicado a los
319. empleados y a las partes externas relevantes.
320. A.5.1.2 Revisión de las políticas para la seguridad de la información Control
321. Las políticas para la seguridad de la información deben ser revisadas a intervalos planificados o si
322. ocurren cambios significativos para asegurar su conveniencia, adecuación y efectividad continua.
323. A.6 Organización de la seguridad de la información
324. A.6.1 Organización interna
325. Objetivo: establecer  un  marco  de  referencia  de  gestión  para  iniciar  y  controlar  la
326. implementación y operación de la seguridad de la información dentro de la organización.
327. A.6.1.1 Roles  y responsabilidades para la seguridad de la
328. información Control
329. Todas las responsabilidades de seguridad de la información deben ser definidas y asignadas.
330. A.6.1.2 Segregación de funciones Control
331. Las funciones y áreas de responsabilidad en conflicto deben ser segregadas para reducir oportunidades de modificación no autorizada o no intencional o mal uso de los activos de la
332. organización.
333. A.6.1.3 Contacto con autoridades Control
334. Contactos apropiados con autoridades relevantes deben ser mantenidos.
335.  
336.  
337.  
338.  
339.  
340. Tabla A.1 (continuación)
341. A.6.1.4 Contacto con grupos especiales de interés Control
342. Contactos apropiados con grupos especiales de interés   u   otros   foros   de especialistas en
343. seguridad y asociaciones profesionales deben ser mantenidos.
344. A.6.1.5 Seguridad de la información en la gestión de proyectos Control
345. La seguridad de la información debe ser tratada
346. en la gestión de proyectos, sin importar el tipo de proyecto.
347. A.6.2 Dispositivos móviles y teletrabajo
348. Objetivo: Asegurar la seguridad del teletrabajo y el uso de los dispositivos móviles.
349. A.6.2.1 Política de dispositivos móviles Control
350. Una política y medidas de seguridad de soporte
351. deben ser adoptadas para gestionar los riesgos introducidos por el uso de dispositivos móviles.
352. A.6.2.2 Teletrabajo Control
353. Una política y medidas de seguridad de apoyo deben ser implementadas para proteger
354. información a la que se accede, se procesa o almacena en sitios de teletrabajo.
355. A.7 Seguridad de los recursos humanos
356. A.7.1 Antes del empleo
357. Objetivo: Asegurar que los empleados y contratistas entienden sus responsabilidades y son convenientes para los roles para los que se les considera.
358. A.7.1.1 Selección Control
359. Las verificaciones de los antecedentes de todos los candidatos a ser empleados deben ser llevadas a cabo en concordancia con las leyes, regulaciones y ética relevantes, y debe ser proporcional a los requisitos del negocio, la clasificación de la información a la que se tendrá
360. acceso y los riesgos percibidos.
361. A.7.1.2 Términos y condiciones del empleo Control
362. Los acuerdos contractuales con los empleados y contratistas deben estipular responsabilidades de éstos y de la organización respecto de la
363. seguridad de la información.
364. A.7.2 Durante el empleo
365. Objetivo: Asegurar que los empleados y contratistas sean conscientes y cumplan con sus
366. responsabilidades de seguridad de la información.
367. A.7.2.1 Responsabilidades de la gerencia Control
368. La gerencia debe requerir a todos los empleados y   contratistas aplicar la   seguridad de   la
369. información en concordancia con las políticas y procedimientos establecidos por la organización.
370.  
371.  
372.  
373.  
374. A.7.2.2 Conciencia, educación y capacitación sobre la seguridad de la información Control
375. Todos los empleados de la organización y, cuando fuera relevante, los contratistas deben recibir educación y capacitación sobre la conciencia de la seguridad de la información, así como actualizaciones regulares sobre políticas y procedimientos de la organización, según sea relevante para la función del trabajo que
376. cumplen.
377. A.7.2.3 Proceso disciplinario Control
378. Debe haber un proceso disciplinario formal y comunicado para tomar acción contra empleados que hayan cometido una infracción a la seguridad
379. de la información.
380. A.7.3 Terminación y cambio de empleo
381. Objetivo: Proteger los intereses  de la organización como parte del proceso de cambio o
382. terminación de empleo.
383. A.7.3.1 Terminación o cambio de responsabilidades del empleo. Control
384. Las responsabilidades y deberes de seguridad de la información que siguen siendo válidos luego de la terminación o cambio de empleo deben ser definidos, comunicados al empleado o contratista
385. y forzar su cumplimiento.
386. A.8 Gestión de activos
387. A.8.1 Responsabilidad por los activos
388. Objetivo: Identificar los activos de la organización y definir responsabilidades de protección
389. apropiadas.
390. A.8.1.1 Inventario de activos Control
391.  
392. Información, Otros activos asociados con información e instalaciones de procesamiento de información deben ser identificados y un
393. inventario de estos activos debe ser elaborado y mantenido.
394. A.8.1.2 Propiedad de los activos Control
395. Los activos mantenidos en el inventario deben ser propios.
396.  
397.  
398.  
399.  
400.  
401. Tabla A.8 (continuación)
402. A.8.1.3 Uso aceptable de los activos Control
403. Las reglas para el uso aceptable de la información y activos asociados con la información y con las instalaciones de
404. procesamiento de la información deben ser identificadas, documentadas e implementadas.
405. A.8.1.4 Retorno de activos Control
406. Todos los empleados y usuarios de partes externas deben retornar todos los activos de la organización en su posesión a la conclusión de su
407. empleo, contrato o acuerdo.
408.  
409. A.8.2 Clasificación de la información
410. Objetivo: Asegurar que la información recibe un nivel apropiado de protección en concordancia
411. con su importancia para la organización.
412. A.8.2.1 Clasificación de la información Control
413. La información debe ser clasificada en términos de los requisitos legales, valor, criticidad y sensibilidad respecto a una divulgación o modificación no autorizada.
414. A.8.2.2 Etiquetado de la información Control
415. Un conjunto apropiado de procedimientos para el etiquetado de la información debe ser desarrollado e implementado en concordancia con el esquema de clasificación de la
416. información adoptado por la organización.
417. A.8.2.3 Manejo de activos Control
418. Los procedimientos para el manejo de activos deben ser desarrollados e implementados en
419. concordancia con el esquema de clasificación de la información adoptado por la organización.
420. A.8.3 Manejo de los medios
421. Objetivo: Prevenir la divulgación, modificación, remoción o destrucción no autorizada de
422. información almacenada en medios.
423. A.8.3.1 Gestión de medios removibles Control
424. Se debe implementar procedimientos para la gestión de medios removibles en concordancia
425. con el esquema de clasificación adoptado por la organización.
426.  
427.  
428.  
429.  
430.  
431. Tabla A.8 (continuación)
432. A.8.3.2 Disposición de medios Control
433. Se debe poner a disposición los medios de manera segura cuando ya no se requieran, utilizando procedimientos formales.
434. A.8.3.3 Transferencia de medios físicos Control
435. Los medios que contienen información deben ser protegidos contra el acceso no autorizado, el mal
436. uso o la corrupción durante el transporte.
437. A.9 Control de acceso
438. A.9.1 Requisitos de la empresa para el control de acceso
439. Objetivo: Limitar el acceso a la información y a las instalaciones de procesamiento de la
440. información.
441. A.9.1.1 Política de control de acceso Control
442. Una política de control de acceso debe ser establecida, documentada y revisada basada en requisitos del negocio y de seguridad de la
443. información.
444. A.9.1.2 Acceso a redes y servicios de red Control
445. Los usuarios deben tener acceso solamente a la
446. red y a servicios de red que hayan sido específicamente autorizados a usar.
447. A.9.2 Gestión de acceso de usuario
448. Objetivo: Asegurar el acceso de usuarios autorizados y prevenir el acceso no autorizado a los
449. sistemas y servicios.
450. A.9.2.1 Registro y baja de usuarios Control
451. Un proceso formal de registro y baja de usuarios debe ser implementado para permitir la asignación de derechos de acceso.
452. A.9.2.2 Aprovisionamiento de acceso a usuario Control
453. Un proceso formal de aprovisionamiento de acceso a usuarios debe ser implementado para asignar o revocar los derechos de acceso para todos los tipos de usuarios a todos los sistemas y
454. servicios.
455. A.9.2.3 Gestión de derechos de acceso privilegiados Control
456. La asignación y uso de derechos de acceso privilegiado debe ser restringida y controlada.
457. A.9.2.4 Gestión de información de autentificación secreta de usuarios Control
458. La asignación de información de autentificación secreta debe ser controlada a través de un proceso de gestión formal.
459.  
460.  
461.  
462.  
463.  
464. Tabla A.9 (continuación)
465. A.9.2.5 Revisión   de derechos de acceso de usuarios Control
466. Los propietarios de los activos deben revisar los derechos de acceso de usuario a intervalos regulares.
467. A.9.2.6 Remoción o ajuste de derechos de acceso Control
468. Los derechos de acceso a información e instalaciones de procesamientos de información de todos los empleados y de los usuarios de partes externas deben removerse al término de su empleo, contrato o acuerdo, o ajustarse según el
469. cambio.
470. A.9.3 Responsabilidades de los usuarios
471. Objetivo: Hacer  que  los  usuarios  respondan  por  la  salvaguarda  de  su  información  de
472. autentificación.
473. A.9.3.1 Uso de información de autentificación secreta Control
474. Los usuarios deben ser exigidos a que sigan las prácticas de la organización en el uso de
475. información de autentificación secreta.
476. A.9.4 Control de acceso a sistema y aplicación
477. Objetivo: Prevenir el acceso no autorizado a los sistemas y aplicaciones.
478.  
479. A.9.4.1 Restricción de acceso a la información Control
480. El acceso a la información y a las funciones del sistema de aplicación debe ser restringido en concordancia con la política de control de
481. acceso.
482. A.9.4.2 Procedimientos de ingreso seguro Control
483. Donde la política de control de acceso lo requiera, el acceso a los sistemas y a las aplicaciones debe ser controlado por un
484. procedimiento de ingreso seguro.
485. A.9.4.3 Sistema de gestión de contraseñas Control
486. Los sistemas de gestión de contraseñas deben ser interactivos y deben asegurar contraseñas de calidad.
487. A.9.4.4 Uso de programas utilitarios privilegiados Control
488. El uso de programas utilitarios que podrían ser capaces de pasar por alto los controles del sistema y de las aplicaciones debe ser restringido
489. y controlarse estrictamente.
490. A.9.4.5 Control de acceso al código fuente de los programas Control
491. El acceso al código fuente de los programas debe ser restringido.
492.  
493.  
494.  
495.  
496.  
497. A.10 Criptografía
498. A.10.1 Controles criptográficos
499. Objetivo: Asegurar  el  uso  apropiado  y  efectivo  de  la  criptografía  para  proteger  la
500. confidencialidad, autenticidad y/o integridad de la información.
501. A.10.1.1 Política sobre el uso de controles criptográficos Control
502. Una política sobre el uso de controles criptográficos para la protección de la información debe ser desarrollada e
503. implementada.
504. A.10.1.2 Gestión de claves Control
505. Una política sobre el uso, protección y tiempo de vida de las claves criptográficas debe ser desarrollada e implementada a través de todo su
506. ciclo de vida.
507. A.11 Seguridad física y ambiental
508. A.11.1 Áreas seguras
509. Objetivo: Impedir acceso físico no autorizado, daño e interferencia a la información y a las
510. instalaciones de procesamiento de la información de la organización.
511. A.11.1.1 Perímetro de seguridad física Control
512. Perímetros de seguridad deben ser definidos y utilizados para proteger áreas que contienen
513. información sensible o crítica e instalaciones de procesamiento de la información.
514.  
515. A.11.1.2 Controles de ingreso físico Control
516. Las áreas seguras deben ser protegidas por medio de controles apropiados de ingreso para asegurar que se le permite el acceso sólo al personal autorizado.
517. A.11.1.3 Asegurar oficinas, áreas e instalaciones Control
518. Seguridad física para oficinas, áreas e instalaciones debe ser diseñada e implementada.
519. A.11.1.4 Protección contra amenazas externas y ambientales Control
520. Protección  física   contra  desastres   naturales,
521. ataque malicioso o accidentes debe ser diseñada y aplicada.
522. A.11.1.5 Trabajo en áreas seguras Control
523. Procedimientos para el trabajo en áreas seguras debe ser diseñado y aplicado.
524.  
525.  
526.  
527.  
528.  
529. Tabla A.11 (continuación)
530. A.11.1.6 Áreas de despacho y carga Control
531. Los puntos de acceso, como las áreas de despacho, carga y otros puntos en donde personas no autorizadas pueden ingresar al local deben ser controlados, y si fuera posible, aislarlos de las instalaciones de procesamiento de la información para evitar el acceso no
532. autorizado.
533. A.11.2 Equipos
534. Objetivo: Prevenir la pérdida, daño, robo o compromiso de activos e interrupción de las
535. operaciones de la organización.
536. A.11.2.1 Emplazamiento y protección de los equipos Control
537. Los equipos deben ser ubicados y protegidos para reducir los riesgos de amenazas y peligros ambientales, así como las oportunidades para el acceso no autorizado.
538. A.11.2.2 Servicios de suministro Control
539. Los equipos deben ser protegidos contra fallas de
540. electricidad y otras alteraciones causadas por fallas en los servicios de suministro.
541. A.11.2.3 Seguridad del cableado Control
542. El cableado de energía y telecomunicaciones que llevan datos o servicios de información de soporte debe ser protegido de la interceptación,
543. interferencia o daño.
544. A.11.2.4 Mantenimiento de equipos Control
545. Los equipos deben mantenerse de manera correcta para asegurar su continua disponibilidad
546. e integridad.
547.  
548. A.11.2.5 Remoción de activos Control
549. Los equipos, la información o el software no deben ser retirados de su lugar sin autorización
550. previa.
551. A.11.2.6 Seguridad de equipos y activos fuera de las instalaciones Control
552. La seguridad debe ser aplicada a los activos que están fuera de su lugar tomando en cuenta los distintos riesgos de trabajar fuera de las
553. instalaciones de la organización.
554.  
555.  
556.  
557.  
558.  
559. Tabla A.11 (continuación)
560. A.11.2.7 Disposición o reutilización segura de equipos Control
561. Todos los elementos del equipo que contengan medios de almacenamiento deben  ser verificados para asegurar que cualquier dato sensible y software con licencia se haya eliminado o se haya sobre  escrito de manera
562. segura antes de su disposición o reutilización.
563. A.11.2.8 Equipos de usuario desatendidos Control
564. Los usuarios deben asegurarse de que el equipo desatendido tenga la protección apropiada.
565. A.11.2.9 Política de escritorio limpio y pantalla limpia Control
566. Una política de escritorio limpio de papeles y de medios de almacenamiento removibles, así como una política de pantalla limpia para las instalaciones de procesamientos de la
567. información debe ser adoptada.
568.  
569. A.12 Seguridad de las operaciones
570. A.12.1 Procedimientos y responsabilidades operativas
571. Objetivo: Asegurar que las operaciones de instalaciones de procesamiento de la
572. información sean correctas y seguras.
573. A.12.1.1 Procedimientos operativos documentados Control
574. Los procedimientos operativos deben ser documentados y puestos a disposición de
575. todos los usuarios que los necesitan.
576. A.12.1.2 Gestión del cambio Control
577. Los cambios en la organización, procesos de negocio, instalaciones de procesamiento de la información y sistemas que afecten la seguridad de la información deben ser controlados.
578. A.12.1.3 Gestión de la capacidad Control
579. El uso de recursos debe ser monitoreado, afinado y se debe hacer proyecciones de los futuros requisitos de capacidad para asegurar el desempeño requerido del sistema.
580. A.12.1.4 Separación de los entornos de desarrollo, pruebas y operaciones Control
581. Los entornos de desarrollo, pruebas y operaciones deben ser separados para reducir los riesgos de acceso no autorizado o cambios al entorno operativo.
582.  
583.  
584.  
585.  
586. Tabla A.12 (continuación)
587. A.12.2 Protección contra códigos maliciosos
588. Objetivo: Asegurar que la información y las instalaciones de procesamiento de la información
589. estén protegidas contra códigos maliciosos.
590. A.12.2.1 Controles contra códigos maliciosos Control
591. Controles de detección, prevención y recuperación para proteger contra códigos maliciosos deben ser implementados, en combinación con una
592. concientización apropiada de los usuarios.
593. A.12.3 Respaldo
594. Objetivo: Proteger contra la pérdida de datos
595. A.12.3.1 Respaldo de la información Control
596. Copias de respaldo de la información, del software y de las imágenes del sistema deben ser tomadas y probadas regularmente en concordancia con una
597. política de respaldo acordada.
598. A.12.4 Registros y monitoreo
599. Objetivo: Registrar eventos y generar evidencia
600. A.12.4.1 Registro de eventos Control
601. Registros (logs) de eventos de actividades de usuarios, excepciones, fallas y eventos de seguridad de la información deben ser producidos,
602. mantenidos y regularmente revisados.
603. A.12.4.2 Protección de información de registros. Control
604. Las instalaciones para registros (logs) y la información de los registros (logs) deben ser
605. protegidas contra la adulteración y el acceso no autorizado.
606. A.12.4.3 Registros del administrador y del operador Control
607. Las actividades del administrador del sistema y del operador del sistema deben ser registradas y los registros (logs) deben ser protegidos y
608. revisados regularmente.
609. A.12.4.4 Sincronización de reloj Control
610. Los relojes de todos los sistemas de procesamiento de la información relevantes dentro de una organización o dominio de seguridad deben estar sincronizados a una fuente de tiempo de referencia
611. única.
612. A.12.5 Control del software operacional
613. Objetivo: Asegurar la integridad de los sistemas operacionales
614. A.12.5.1 Instalación de software en sistemas operacionales Control
615. Procedimientos deben ser implementados s para controlar la instalación de software en sistemas
616. operacionales.
617.  
618.  
619.  
620.  
621.  
622. Tabla A.12 (continuación)
623. A.12.6 Gestión de vulnerabilidad técnica
624. Objetivo: Prevenir la explotación de vulnerabilidades técnicas
625. A.12.6.1 Gestión de vulnerabilidades técnicas Control
626. Información sobre vulnerabilidades técnicas de los sistemas de información utilizados debe ser obtenida de manera oportuna, la exposición de la organización a dichas vulnerabilidades debe ser evaluada y las medidas apropiadas deben ser
627. tomadas para resolver el riesgo asociado.
628. A.12.6.2 Restricciones sobre la instalación de software Control
629. Reglas que gobiernen la instalación de software
630. por parte de los usuarios deben ser establecidas e implementadas.
631. A.12.7 Consideraciones para la auditoría de los sistemas de información
632. Objetivo: Minimizar el impacto de las actividades de auditoría en los sistemas operacionales.
633. A.12.7.1 Controles de auditoría de sistemas de información Control
634. Requisitos de las auditorías y las actividades que involucran la verificación de sistemas operacionales deben ser cuidadosamente
635. planificados y acordados para minimizar la interrupción a los procesos del negocio.
636. A.13 Seguridad de las comunicaciones
637. A.13.1 Gestión de seguridad de la red
638. Objetivo: Asegurar la protección de la información en las redes y sus instalaciones de procesamiento de la información de apoyo.
639. A.13.1.1 Controles de la red Control
640. Las redes deben ser gestionadas y controladas para
641. proteger la información en los sistemas y las aplicaciones.
642. A.13.1.2 Seguridad de servicios de red Control
643. Mecanismos de seguridad, niveles de servicio y requisitos de gestión de todos los servicios de red deben ser identificados e incluidos en acuerdos de
644. servicios de red, ya sea que estos servicios se provean internamente o sean tercerizados.
645. A.13.1.3 Segregación en redes Control
646. Grupos de servicios de información, usuarios y sistemas de información deben ser
647. segregados en redes.
648. A.13.2 Transferencia de información
649. Objetivo: Mantener   la   seguridad   de   la   información   transferida   dentro   de   una
650. organización y con cualquier entidad externa.
651.  
652.  
653.  
654.  
655.  
656. Tabla A.13 (continuación)
657. A.13.2.1 Políticas y procedimientos de transferencia de la información Control
658. Políticas, procedimientos y controles de transferencia formales deben aplicarse para proteger la transferencia de información a través del uso de todo tipo de instalaciones de
659. comunicación.
660. A.13.2.2 Acuerdo sobre transferencia de información Control
661. Los acuerdos deben dirigir la transferencia segura de información del negocio entre la organización y
662. partes externas.
663. A.13.2.3 Mensajes electrónicos Control
664. La información involucrada en mensajería electrónica debe ser protegida apropiadamente.
665. A.13.2.4 Acuerdos de
666. confidencialidad o no divulgación Control
667. Requisitos para los acuerdos de confidencialidad o no divulgación que reflejan las necesidades de la organización para la protección de la información
668. deben ser identificados, revisados regularmente y documentados.
669. A.14 Adquisición, desarrollo y mantenimiento de sistemas
670. A.14.1 Requisitos de seguridad de los sistemas de información
671. Objetivo: Garantizar que la seguridad de la información es una parte integral de los sistemas de
672. información a través del ciclo de vida completo. Esto también incluye los requisitos para sistemas de información que proporcionen servicios sobre redes públicas.
673. A.14.1.1 Análisis y especificación de requisitos de seguridad de la información Control
674. Requisitos relacionados a la seguridad de la información deben ser incluidos dentro de los requisitos para nuevos sistemas de información o
675. mejoras a los sistemas de información existentes.
676. A.14.1.2 Aseguramiento de servicios de aplicaciones sobre redes públicas Control
677. La información involucrada en servicios de aplicaciones que pasa sobre redes públicas debe ser protegida de actividad fraudulenta, disputa de contratos o divulgación no autorizada y
678. modificación.
679. A.14.1.3 Protección de transacciones en servicios de aplicación Control
680. La información involucrada en las transacciones de servicios de aplicación debe ser protegida para prevenir transmisión incompleta, ruteo incorrecto, alteración no autorizada de mensajes, divulgación no autorizada, duplicación o respuesta no
681. autorizada de mensajes.
682.  
683.  
684.  
685.  
686.  
687. Tabla A.14 (continuación)
688. A.14.2 Seguridad en los procesos de desarrollo y soporte
689. Objetivo: Garantizar que la seguridad de la información esté diseñada e implementada dentro del
690. ciclo de vida de desarrollo de los sistemas de información.
691. A.14.2.1 Política de desarrollo seguro Control
692. Reglas para el desarrollo de software y sistemas deben ser establecidas y aplicadas a desarrollos
693. dentro de la organización.
694. A.14.2.2 Procedimientos de control de cambio del sistema Control
695. Cambios a los sistemas dentro del ciclo de vida del desarrollo deben ser controlados por medio del uso de procedimientos formales de control de
696. cambios.
697. A.14.2.3 Revisión técnica de aplicaciones después de cambios a la plataforma operativa Control
698. Cuando se cambian las plataformas operativas, las aplicaciones críticas para el negocio deben ser revisadas y probadas para asegurar que no haya impacto adverso en las operaciones o en la
699. seguridad de la organización.
700. A.14.2.4 Restricciones sobre cambios a los paquetes de software Control
701. Modificaciones a los paquetes de software deben ser disuadidas, limitadas a los cambios necesarios y todos los cambios deben ser estrictamente
702. controlados.
703. A.14.2.5 Principios de ingeniería de sistemas seguros Control
704. Principios para la ingeniería de sistemas seguros deben ser establecidos, documentados, mantenidos y aplicados a cualquier esfuerzo de
705. implementación de sistemas de información.
706. A.14.2.6 Ambiente de desarrollo seguro Control
707. Las organizaciones deben establecer y proteger apropiadamente los ambientes de desarrollo seguros para los esfuerzos de desarrollo e integración de sistemas que cubren todo el ciclo
708. de vida del desarrollo del sistema.
709. A.14.2.7 Desarrollo contratado externamente Control
710. La organización debe supervisar y monitorear la
711. actividad de desarrollo de sistemas contratado externamente.
712. A.14.2.8 Pruebas de seguridad del sistema Control
713. Pruebas de funcionalidad de la seguridad deben ser llevadas a cabo durante el desarrollo.
714.  
715.  
716.  
717.  
718.  
719. Tabla A.14 (continuación)
720. A.14.2.9 Pruebas de aceptación del sistema Control
721. Programas de pruebas de aceptación y criterios relacionados deben ser establecidos para nuevos sistemas de información,
722. actualizaciones y nuevas versiones.
723. A.14.3 Datos de prueba
724. Objetivo: Asegurar la protección de datos utilizados para las pruebas
725. A.14.3.1 Protección   de datos de prueba Control
726. Los datos de prueba deben ser seleccionados cuidadosamente, protegidos y controlados.
727. A.15 Relaciones con los proveedores
728. A.15.1 Seguridad de la información en las relaciones con los proveedores
729. Objetivo: Asegurar protección a los activos de la organización que son accesibles por los proveedores
730. A.15.1.1 Política de seguridad de la información para las relaciones con los proveedores Control
731. Requisitos de seguridad de la información para mitigar los riesgos asociados con el acceso por parte del proveedor a los activos de la organización deben ser acordados con el proveedor y documentados.
732. A.15.1.2 Abordar la seguridad dentro de los acuerdos con proveedores Control
733. Todos los requisitos relevantes de seguridad de la información deben ser establecidos y acordados con cada proveedor que pueda acceder, procesar, almacenar, comunicar, o
734. proveer componentes de infraestructura de TI para la información de la organización.
735. A.15.1.3 Cadena de suministro de tecnología de información y comunicación Control
736. Los acuerdos con proveedores deben incluir requisitos para abordar los riesgos de seguridad de la información asociados con los servicios de tecnología de la información y comunicaciones y la cadena de suministro de
737. productos.
738. A.15.2 Gestión de entrega de servicios del proveedor
739. Objetivo: Mantener un nivel de seguridad de la información y entrega de servicios acordado en línea con los acuerdos con proveedores.
740. A.15.2.1 Monitoreo y revisión de servicios de los proveedores Control
741. Las organizaciones deben monitorear, revisar
742. y auditar regularmente la entrega de servicios por parte de los proveedores.
743.  
744.  
745.  
746.  
747.  
748. Tabla A.15 (continuación)
749. A.15.2.2 Gestión de cambios a los servicios de proveedores Control
750. Los cambios a la provisión de servicios por parte de proveedores, incluyendo el mantenimiento y mejoramiento de políticas, procedimientos y controles existentes de seguridad de la información deben ser gestionados tomando en cuenta la criticidad de la información del negocio, sistemas y procesos involucrados y una
751. reevaluación de riesgos.
752. A.16 Gestión de incidentes de seguridad de la información
753. A.16.1 Gestión de incidentes de seguridad de la información y mejoras
754. Objetivo: Asegurar un enfoque consistente y efectivo a la gestión de incidentes de seguridad de la información, incluyendo la comunicación sobre eventos de seguridad y debilidades.
755. A.16.1.1 Responsabilidades y procedimientos Control
756. Las responsabilidades de gestión y los procedimientos deben ser establecidos para asegurar una respuesta rápida, efectiva y ordenada
757. a los incidentes de seguridad de la información.
758. A.16.1.2 Reporte de eventos de seguridad de la información Control
759. Los eventos de seguridad de la información deben ser reportados a través de canales de gestión
760. apropiados tan rápido como sea posible.
761. A.16.1.3 Reporte de debilidades de seguridad de la información Control
762. Empleados y contratistas que usan los sistemas y servicios de información de la organización deben ser exigidos a advertir y reportar cualquier debilidad observada o de la que se sospecha en cuanto a seguridad de la información en los
763. sistemas o servicios.
764. A.16.1.4 Evaluación y decisión sobre eventos de seguridad de la información Control
765. Los eventos de seguridad de la información deben ser evaluados y debe decidirse si son clasificados
766. como incidentes de seguridad de la información.
767. A.16.1.5 Respuesta a incidentes de seguridad de la información Control
768. Los incidentes de seguridad de la información deben ser respondidos de acuerdo con los
769. procedimientos documentados.
770. A.16.1.6 Aprendizaje de los incidentes de seguridad de la información Control
771. El conocimiento adquirido a partir de analizar y resolver los incidentes de seguridad de la información debe ser utilizado para reducir la
772. probabilidad o el impacto de incidentes futuros.
773.  
774.  
775.  
776.  
777.  
778. Tabla A.16 (continuación)
779. A.16.1.7 Recolección de evidencia Control
780. La organización debe definir y aplicar procedimientos para la identificación, recolección, adquisición y preservación de información que pueda servir como evidencia.
781. A.17 Aspectos de seguridad de la información en la gestión de continuidad del negocio
782. A.17.1 Continuidad de seguridad de la información
783. Objetivo: La continuidad de seguridad de la información debe estar embebida en los sistemas de
784. gestión de continuidad del negocio de la organización
785. A.17.1.1 Planificación de continuidad de seguridad de la información Control
786. La organización debe determinar sus requisitos de seguridad de la información y continuidad de la gestión de seguridad de la información en situaciones adversas, por ejemplo durante una
787. crisis o desastre.
788. A.17.1.2 Implementación de continuidad de seguridad de la información Control
789. La organización debe establecer, documentar, implementar y mantener procesos, procedimientos y controles para asegurar el nivel requerido de
790. continuidad de seguridad de la información durante una situación adversa.
791. A.17.1.3 Verificación, revisión y evaluación de continuidad de seguridad de la información Control
792. La organización debe verificar los controles de continuidad de seguridad de la información que han establecido e implementado a intervalos regulares para asegurarse que son válidos y
793. efectivos durante situaciones adversas.
794. A.17.2 Redundancias
795. Objetivo: Asegurar la disponibilidad de las instalaciones y procesamiento de la información
796. A.17.2.1 Instalaciones de procesamiento de la información Control
797. Las instalaciones de procesamiento de la información deben ser implementadas con redundancia suficiente para cumplir con los
798. requisitos de disponibilidad.
799. A.18 Cumplimiento
800. A.18.1 Cumplimiento con requisitos legales y contractuales
801. Objetivo:  Evitar  infracciones   de   las   obligaciones   legales,   estatutarias,   regulatorias   o
802. contractuales relacionadas a la seguridad de la información y a cualquier requisito de seguridad.
803.  
804.  
805.  
806.  
807.  
808. Tabla A.18 (continuación)
809. A.18.1.1 Identificación de requisitos contractuales y de legislación aplicables Control
810. Todos los requisitos legislativos, estatutarios, regulatorios y contractuales relevantes así como el enfoque de la organización para cumplir con estos requisitos deben ser explícitamente identificados, documentados y mantenidos al día para cada
811. sistema de información y para la organización.
812. A.18.1.2 Derechos de propiedad intelectual Control
813. Procedimientos apropiados deben ser implementados para asegurar el cumplimiento de requisitos legislativos, regulatorios y contractuales relacionados a los derechos de propiedad intelectual y uso de productos de software
814. propietario.
815. A.18.1.3 Protección de registros Control
816. Los registros deben ser protegidos de cualquier pérdida, destrucción, falsificación, acceso no autorizado y divulgación no autorizada, de acuerdo con los requisitos legislativos,
817. regulatorios, contractuales y del negocio.
818. A.18.1.4 Privacidad y protección de datos personales. Control
819. La privacidad y la protección de datos personales deben ser aseguradas tal como se requiere en la legislación y regulación relevantes donde sea
820. aplicable.
821. A.18.1.5 Regulación de controles criptográficos Control
822. Controles criptográficos deben ser utilizados en cumplimiento con todos los acuerdos, legislación y regulación relevantes.
823. A.18.2 Revisiones de seguridad de la información
824. Objetivo: Asegurar que la seguridad de la información está implementada y es operada de
825. acuerdo con las políticas y procedimientos organizativos.
826. A.18.2.1 Revisión independiente de la seguridad de la información Control
827. El enfoque de la organización para manejar la seguridad de la información y su implementación (por ejemplo objetivos de control, controles, políticas, procesos y procedimientos para la seguridad de la información) debe ser revisado independientemente a intervalos planeados o
828. cuando ocurran cambios significativos.
829.  
830.  
831.  
832.  
833.  
834. Tabla A.18 (continuación)
835. A.18.2.2 Cumplimiento de políticas y normas de seguridad Control
836. Los gerentes deben revisar regularmente el cumplimiento del procesamiento de la información y de los procedimientos dentro de su área de responsabilidad con las políticas, normas y otros requisitos de seguridad
837. apropiados.
838. A.18.2.3 Revisión del cumplimiento Control
839.  técnico Los sistemas   de   información   deben   ser
840.   revisados regularmente respecto al
841.   cumplimiento de las políticas y normas de
842.   seguridad de la información de la
843.   organización.
844.  
845. Fin del anexo A
846.  
847. Revisar la Norma - NCH ISO27032 (capítulo 12)
848.  
849. 12 Controles de Ciberprotección
850.  
851. 12.1 Visión general
852. Una vez que se identifican los riesgos a la Ciberprotección y se bosquejan las directrices apropiadas, se pueden seleccionar e implementar los controles de Ciberprotección que apoyan a los requisitos de seguridad. Esta cláusula da una visión general de los controles clave de Ciberprotección que se pueden implementar para apoyar las directrices especificadas en esta norma.
853.  
854. 12.2 Controles a nivel de aplicación
855. Los controles a nivel de aplicación incluyen los siguientes:
856.  
857. a) Exponer notificaciones cortas con resúmenes claros, concisos y de una sola página (con un lenguaje simple) de las políticas online esenciales de la compañía. Mediante estas notificaciones, los usuarios pueden tomar decisiones más informadas acerca de compartir su información online. Estas notificaciones cortas deberían estar en conformidad con todos los requisitos normativos y proveer links a declaraciones completas y otra información relevante, para que los consumidores que quieran más detalles puedan hacer click fácilmente para leer la versión completa. Con una sola notificación, los consumidores pueden tener un acercamiento más consistente acerca los bienes de la compañía, con los mismos estándares y expectativas de privacidad, que se extienden a numerosos sitios.
858.  
859.  
860. © ISO 2012 - Todos los derechos reservados
861. 36 © INN 2015 - Para la adopción nacional
862.  
863. Licenciado por el INN para SUPERINTENDENCIA DE BANCOS E INSTITUCIONES FINANCIERAS R.U.T.: 70.023.270-0 - Creado: 2017-04-12
864. Licencia sólo 1 usuario. Copía y uso en red PROHIBIDOS
865. NCh-ISO 27032:2015
866.  
867.  
868.  
869. b) Asegurar el manejo de sesiones para las aplicaciones Web. Esto puede incluir mecanismos online como cookies.
870. c) Asegurar la validación y manejo de las entradas para prevenir ataques comunes, tales como la Inyección SQL. En base en que los sitios Web, los cuales en general se consideran como confiables, se están usando cada vez más para la distribución de códigos maliciosos, la validación de entrada y salida se debe realizar mediante un contenido activo y mediante un contenido dinámico.
871.  
872. d) Asegurar el scripting de la página Web para prevenir ataques comunes como las Secuencias de Ordenes en Sitios Cruzados o Cross-site Scripting.
873. e) Revisar y testear la seguridad de los códigos por medios de entidades cualificadas apropiadamente.
874.  
875. f) El servicio de la organización, ya sea provisto por la organización o por una parte que represente a la organización, se debería proveer de manera que el consumidor pueda autentificar dicho servicio. Esto puede incluir haciendo que el proveedor use un sub-dominio desde un nombre de dominio con marca registrada de la organización y posiblemente el uso de credenciales HTTPS registradas a nombre de la organización. El servicio debería evitar el uso de métodos engañosos donde los consumidores tengan dificultades para determinar con quien se está relacionando.
876.  
877. 12.3 Protección del servidor
878.  
879. Los controles siguientes se pueden usar para proteger a los servidores contra accesos no autorizados y el hosting de contenido maliciosos en dichos servidores:
880.  
881. a) Configurar los servidores, incluyendo los sistemas operativos subyacentes, de acuerdo a una guía de configuración de seguridad base. Esta guía debería incluir una definición apropiada de los usuarios de los servidores versus los administradores, reforzar los controles de acceso en los directorios y archivos de programa y sistema y habilitar el registro de auditoría de, particularmente, la seguridad y otros eventos de fallas en el sistema. Es más, se recomienda instalar un sistema mínimo en un servidor para reducir el vector de ataque.
882.  
883. b) Implementar un sistema para probar e implementar actualizaciones de seguridad y asegurarse de que el sistema operativo y aplicaciones del servidor se mantengan actualizados rápidamente cuando estén disponibles nuevas actualizaciones de seguridad.
884.  
885. c) Realizar seguimiento del desempeño de seguridad del servidor a través de revisiones constantes de los registros de auditoría.
886.  
887. d) Revisar la configuración de seguridad.
888.  
889. e) Ejecutar controles anti software malicioso (como spyware o malware) en el servidor.
890.  
891. f) Escanear todo el contenido alojado y subido, de manera regular, usando controles actualizados anti software malicioso. Reconocer que un archivo puede, por ejemplo, aún ser un spyware o malware si no se detecta con los controles actuales debido a limitaciones o a información incorrecta.
892. g) Realizar evaluaciones de vulnerabilidades y pruebas de seguridad de manera constante para aplicaciones y sitios online para asegurase de que se mantiene su seguridad de manera adecuada.
893.  
894. h) Hacer escaneos constante en busca de compromisos.
895.  
896.  
897.  
898.  
899.  
900.  
901. Li< INN ES FINANCIERAS
902. R.U
903.  
904. NCh-ISO 27032:2015
905.  
906.  
907.  
908. 12.4 Controles para los usuarios finales
909.  
910. La siguiente es una lista incompleta de controles que los usuarios finales pueden usar para proteger sus sistemas contra ataques y abusos conocidos:
911.  
912. a) Usar sistemas operativos compatibles con los parches de seguridad más actualizados que han sido instalados. Los consumidores organizacionales tienen una responsabilidad de estar conscientes de, y seguir, una política organizacional relacionada a los sistemas operativos compatibles. Los consumidores individuales deberían estar conscientes de, y considerar el uso, sistemas operativos recomendados por el proveedor. En todos los casos, el sistema operativo se debería actualizar con respecto a los parches de seguridad.
913. b) Usar las últimas aplicaciones de software compatibles con los parches más actualizados instalados. Los consumidores organizacionales tienen una responsabilidad de estar consiente de, y seguir, una política organizacional relacionada a los sistemas operativos compatibles. Los consumidores individuales deberían estar conscientes de, y considerar el uso, de sistemas operativos recomendados por el proveedor. En todos los casos, el software de aplicación se debería actualizar con respecto a los parches de seguridad.
914.  
915. c) Usar herramientas anti-virus y anti-spywares. Si es factible, un proveedor de servicios como un ISP debería considerar trabajar en conjunto con vendedores de seguridad confiables, para ofrecerle a los usuarios finales dichas herramientas como parte del paquete de suscripción al servicio, para que los controles de seguridad estén disponibles luego de registrar la suscripción o luego de su renovación. Los consumidores organizacionales tienen la responsabilidad de estar consciente de, y seguir, una política organizacional relacionada al uso de herramientas de software de seguridad. Los consumidores individuales deberían usar las herramientas de software de seguridad. Estos se deberían dirigir al proveedor por cualquier software de seguridad recomendado, provisto o discontinuado. En todos los casos, el software de seguridad se debería actualizar con respecto a los parches de seguridad y a las bases de datos de firmas.
916.  
917. d) Implementar dispositivos de seguridad anti-virus y anti-spywares apropiados. Los navegadores Web y barras de herramientas de navegador comunes incorporan actualmente capacidades como bloqueadores de pop-ups que evitan que sitios Web maliciosos muestren ventanas que contienen spywares o softwares engañosos que puedan abusar de las debilidades del sistema o navegador o usar la ingeniería social para engañar a los usuarios para que los descarguen e instalen en sus sistemas. Las organizaciones deberían establecer una política para habilitar el uso de dichas herramientas. Las organizaciones proveedoras de servicios deberían recopilar una lista de herramientas recomendadas y se debe fomentar su uso entre los usuarios finales, con una orientación sobre sus habilitaciones y permisos concedidos para los sitios Web a los que los usuarios desearían acceder.
918.  
919. e) Habilitar bloqueadores de script. Habilitar bloqueadores de script o una configuración de seguridad Web más alta para asegurarse de que sólo se ejecuten en un computador local los Scripts que provengan de fuentes confiables.
920.  
921. f) Usar filtros de suplantación de identidad. Los navegadores Web y barras de herramientas de navegador comunes suelen incorporar esta capacidad, la que podría determinar si el sitio que está visitando el usuario se encuentra en una base de datos de sitios Web de suplantación de identidad conocidos, o si contiene patrones de script que sean similares a aquellos que se consideren como típicos sitios de suplantación de identidad. El navegador podría proveer alertas, normalmente en forma de resaltos codificados con color, para advertir a los usuarios del potencial riesgo. Las organizaciones deberían establecer una política para habilitar el uso de dicha herramienta.
922.  
923. © ISO 2012 - Todos los derechos reservados
924. 38 © INN 2015 - Para la adopción nacional
925.  
926. Licenciado por el INN para SUPERINTENDENCIA DE BANCOS E INSTITUCIONES FINANCIERAS R.U.T.: 70.023.270-0 - Creado: 2017-04-12
927. Licencia sólo 1 usuario. Copia y uso en red PROHIBIDOS
928. NCh-ISO 27032:2015
929.  
930.  
931.  
932. g) Usar otros elementos de seguridad disponibles, para los navegadores Web. Constantemente, a medida que surgen nuevos riesgos de Ciberprotección, los proveedores de navegadores Web y de barras de herramientas de navegador agregan nuevas capacidades de seguridad para proteger a los usuarios en contra de riesgos. Los usuarios finales se deberían mantener actualizados acerca de estos desarrollos, al aprender acerca de dichas actualizaciones que son provistas normalmente por los proveedores de herramientas. Las organizaciones y proveedores de servicios deberían revisar de manera similar estas nuevas capacidades y actualizar las políticas y servicios pertinentes para cumplir de mejor manera las necesidades de sus organizaciones y consumidores, así como abordar los riesgos relacionados a la Ciberprotección.
933.  
934. h) Habilitar un firewall y un HIDS personales. Los firewalls y HIDS personales son herramientas importantes para controlar los servicios de red que acceden al sistema de un usuario. Varios sistemas operativos nuevos tienen firewalls y HIDS personales incorporados. Si bien estos elementos están habilitados de manera predeterminada, los usuarios o aplicaciones pueden inhabilitarlos, lo que conlleva a exposiciones no deseadas de la seguridad de la red. Las organizaciones deberían adoptar una política sobre el uso de un firewall y un HIDS personales y evaluar herramientas o productos adecuados para implementar que se habilite su uso por defecto a todos los empleados. Los proveedores de servicios deberían fomentar el uso de funciones de firewall y HIDS personales y/o sugerir otros productos de firewall y HIDS personales de terceros que han sido evaluados y considerados como confiables, además de educar y ayudar a los usuarios a habilitar una seguridad de red básica a nivel de sistema de usuario final.
935.  
936. i) Habilitar actualizaciones automáticas. Si bien los controles de seguridad técnicos descritos anteriormente son capaces de lidiar con la mayoría de los softwares maliciosos en sus respectivos niveles operacionales, éstos no son muy efectivos en contra del abuso de vulnerabilidades que existen en los productos de sistemas operativos y aplicaciones. Para prevenir dichos abusos, la función de actualización disponible en los sistemas operativos, así como aquellas provistas por las aplicaciones en las que confían los usuarios (por ejemplo, productos anti-spyware y anti­ virus evaluados por terceros confiables) se deberían habilitar para que realicen actualizaciones automáticas. Esto asegurará que los sistemas se actualicen con los últimos parches de seguridad cada vez que estén disponibles, cerrando la brecha de tiempo para que se lleven a cabo los abusos.
937.  
938. 12.5 Controles contra los ataques de ingeniería social
939.  
940. 12.5.1 Visión general
941.  
942. Los Cibercriminales recurren cada vez más a tácticas psicológicas o de ingeniería social para tener éxito.
943.  
944. EJEMPLO 1 El uso de correos electrónicos que contienen un URL  que dirige a  los usuarios desprevenidos a sitios Web de suplantación de identidad.
945.  
946. EJEMPLO 2 Correos electrónicos fraudulentos que le piden a los usuarios dar su información de identificación personal o información relacionada a propiedad intelectual corporativa.
947.  
948. La proliferación de las redes sociales y los sitios de comunidad provee nuevos vehículos que habilitan aún más la realización de fraudes y estafas insólitas. De manera creciente, dichos ataques también están trascendiendo la tecnología, más allá de los sistemas de PC y de la conectividad de red tradicional, aprovechando el uso de teléfonos móviles, redes inalámbricas (incluyendo Bluetooth) y Voz sobre IP (VolP).
949.  
950.  
951.  
952. © ISO 2012 - Todos los derechos reservados
953. © INN 2015 - Para la adopción nacional 39
954.  
955. Licenciado por el INN para SUPERINTENDENCIA DE BANCOS E INSTITUCIONES FINANCIERAS R.U.T.: 70.023.270-0 - Creado: 2017-04-12
956. Licencia sólo 1 usuario. Copia y uso en red PROHIBIDOS
957. NCh-ISO   27032:2015
958.  
959.  
960.  
961. Esta cláusula provee un marco de controles aplicable para gestionar y minimizar los riesgos de Ciberprotección en relación a los ataques de ingeniería social. La orientación provista en esta cláusula se basa en la noción de que la única forma eficaz de mitigar la amenaza de ingeniería social es través de la combinación de:
962. — tecnología de seguridad;
963.  
964. — políticas de seguridad que establezcan reglas básicas para el comportamiento personal, tanto como individuo como en forma de empleado; y
965. — una educación y formación apropiadas. Por lo tanto, el marco de trabajo abarca:
966. — políticas;
967.  
968. — métodos y procesos;
969.  
970. — personas y organizaciones; y
971.  
972. — controles técnicos aplicables.
973.  
974. 12.5.2 Políticas
975.  
976. En la misma línea de las prácticas comunes para la gestión de riesgos de seguridad de la información, se deberían determinar y documentar políticas básicas que gobiernen la creación, recopilación, almacenamiento, transmisión, intercambio, procesamiento y uso general de la información personal y organizacional y de la propiedad intelectual en Internet y en el Ciberespacio. Particularmente, esto se relaciona con las aplicaciones como la mensajería instantánea, el blogging, el intercambio de archivos P2P y las redes sociales, las que normalmente están más allá del alcance de la red empresarial y la seguridad de la información.
977.  
978. Como parte de las políticas corporativas, declaraciones y sanciones relacionadas al mal uso de las aplicaciones del Ciberespacio se deberían también incorporar, para disuadir las prácticas de mal uso por parte de los empleados y terceros en las redes corporativas o sistemas que acceden al Ciberespacio.
979.  
980. Se deberían desarrollar y publicar políticas administrativas que promuevan la conciencia y entendimiento de los riesgos de Ciberprotección y fomentar, u obligar, el aprendizaje y desarrollo de competencias en contra de ataques de Ciberprotección, particularmente, de ataques de ingeniería social. Esto debería incluir requisitos para la asistencia constante a sesiones informativas y capacitaciones.
981.  
982. Al promover políticas y una conciencia adecuadas sobre los riesgos de ingeniería social, los empleados ya no se pueden declarar ignorantes frente a dichos riesgos y requisitos y, al mismo tiempo, sobre el desarrollo del entendimiento de las buenas prácticas y políticas esperadas de las redes sociales externas y otras aplicaciones del Ciberespacio, por ejemplo, el acuerdo de política de seguridad del proveedor de servicios.
983.  
984. 12.5.3 Métodos y procesos
985.  
986. 12.5.3.1 Categorización y clasificación de la información
987.  
988. Para apoyar las políticas para promover una conciencia y protección de la información corporativa clasificada y sensible personal, incluyendo las propiedades intelectuales, se deberían implementar procesos para la categorización y clasificación de la información.
989. © ISO 2012 -Todos los derechos reservados
990. 40 © INN 2015 - Para la adopción nacional
991.  
992. Licenciado por ei INN para SUPERINTENDENCIA DE BANCOS E INSTITUCIONES FINANCIERAS R.U.T.: 70.023.270-0 - Creado: 2017-04-12
993. Licencia sólo 1 usuario. Copia y uso en red PROHIBIDOS
994. NCh-ISO 27032:2015
995.  
996.  
997.  
998. Para cada categoría y clasificación de la información involucrada, se deberían desarrollar y documentar controles de seguridad específicos para la protección contra la exposición accidental y el acceso no autorizado intencional.
999.  
1000. Los usuarios en las organizaciones podrían de esta manera hacer la diferencia entre las diferentes categorías y clasificación de la información que generan, recolectan y manejan. Los usuarios pueden así ejercer la precaución necesaria y hacer uso de los controles protectores cuando utilicen el Ciberespacio.
1001.  
1002. También se deberían desarrollar y publicar procedimiento de cómo manejar las propiedades intelectuales de una compañía, los datos personales y otra información confidencial.
1003.  
1004. 12.5.3.2 Conciencia y formación
1005.  
1006. La conciencia y formación de seguridad, incluyendo la actualización constante de conocimientos y aprendizajes pertinentes, son elementos importantes para contrarrestar ataques de ingeniería social.
1007.  
1008. Como parte del programa de Ciberprotección de una organización, a los empleados y subcontratistas se les debería requerir que cursen un número mínimo de horas de formación para asegurar que estén conscientes de sus roles y responsabilidades en el Ciberespacio, además de los controles técnicos que éstos deberían implementar como individuos al usar el Ciberespacio. Además, como parte del programa para contrarrestar los ataque de ingeniería social, dicha formación debería incluir contenidos como los siguientes:
1009.  
1010. a) Las últimas amenazas y formas de ataques de ingeniería social, por ejemplo, cómo ha evolucionado la suplantación de identidad desde los sitios Web falsos hasta una combinación de Spams, Cross Site Scripting y ataques de Inyección SQL.
1011.  
1012. b) Cómo la información individual y corporativa se puede robar y manipular a través de ataques de ingeniería social, otorgando un entendimiento de cómo los atacantes se pueden aprovechar de la naturaleza humana, cómo lo es la tendencia a estar de acuerdo con las peticiones hechas con autoridad (aunque ésta pueda ser falsa), conductas amigables, presentarse como víctima y la reciprocidad entregando algo de valor o prestar ayuda.
1013.  
1014. c) Qué información necesita estar protegida y cómo protegerla, de acuerdo con la política de seguridad de la información.
1015.  
1016. d) Cuándo informar o escalar un evento sospechoso o aplicación maliciosa para dirigirse a las autoridades u organismo   de respuesta, y la información   disponible sobre   estos contactos. Por ejemplo, ver Anexo B.
1017.  
1018. Las organizaciones que proveen aplicaciones y servicios online en el Ciberespacio deberían proveer materiales que cubran los contenidos anteriores dentro del contexto de sus aplicaciones o servicios, para promover la conciencia entre los suscriptores o consumidores.
1019.  
1020.  
1021.  
1022.  
1023.  
1024.  
1025.  
1026.  
1027.  
1028. © ISO 2012 - Todos los derechos reservados
1029. © INN 2015 - Para la adopción nacional 41
1030.  
1031. Licenciado por el INN para SUPERINTENDENCIA DE BANCOS E INSTITUCIONES FINANCIERAS R.U.T.: 70.023.270-0 - Creado: 2017-04-12
1032. Licencia sólo 1 usuario. Copia y uso en red PROHIBIDOS
1033. NCh-ISO 27032:2015
1034.  
1035.  
1036.  
1037. 12.5.3.3 Pruebas
1038.  
1039. Los empleados deberían firmar una aceptación de que ellos aceptan y entienden los contenidos de la política de seguridad de la organización. Como parte del proceso para mejorar la conciencia y asegurar que se preste atención a los riesgos, una organización debería considerar la ejecución de pruebas periódicas para determinar el nivel de conciencia y conformidad con las políticas y prácticas pertinentes. Los empleados pueden contestar una prueba escrita o cursar una CBT para determinar si entienden los contenidos de las políticas de seguridad de la organización. Dichas pruebas pueden incluir, pero no se limitan a, la creación de sitios dirigidos y controlados de suplantación de identidad, Spams y correos electrónicos fraudulentos, usando contenidos de ingeniería social verosímil. Al conducir dichas pruebas, es importante asegurarse de que:
1040.  
1041. a) los servidores y contenidos de prueba estén todos dentro del control y comando del equipo de prueba;
1042.  
1043. b) se involucren, si es posible, a profesionales que tienen experiencia previa en la conducción de dichas pruebas;
1044.  
1045. c) los usuarios estén preparados para dichas pruebas por medio de programas de conciencia y formación; y
1046.  
1047. d) se presenten todos los resultados en un formato global, para proteger la privacidad de un individuo, puesto que el contenido presentado en dichas pruebas puede avergonzar a los individuos y causar preocupaciones sobre la privacidad, si es que no se maneja adecuadamente.
1048.  
1049. NOTA          Se puede tener en consideración la ética y la legislación de cada país.
1050.  
1051. 12.5.4 Personas y organización
1052.  
1053. Si bien los individuos son los primeros blancos de los ataques de ingeniería social, una organización también puede ser una potencial víctima. Sin embargo, las personas siguen siendo el punto de entrada principal para los ataques de ingeniería social. Como tal, las personas necesitan estar conscientes de los riesgos relacionados en el Ciberespacio, y las organizaciones deberían establecer políticas pertinentes y dar pasos proactivos para patrocinar programas relacionados para asegurar la conciencia y competencia de las personas.
1054.  
1055. Como guía general, todas las organizaciones (incluyendo empresas, proveedores de servicios y gobiernos) deberían motivar a los consumidores en el Ciberespacio a aprender y entender los riesgos de ingeniería social en el Ciberespacio y los pasos que deberían dar para protegerse a sí mismos contra ataques potenciales.
1056.  
1057. 12.5.5 Técnicos
1058.  
1059. Además de establecer políticas y prácticas en contra de ataques de ingeniería social, se deberían considerar también controles técnicos y, donde sea posible, adoptarlos para minimizar la exposición y potencial de abusos por parte de ciber malhechores.
1060.  
1061. En el nivel del personal, los usuarios del Ciberespacio deberían adoptar la guía analizada en 11.3.
1062.  
1063. Las organizaciones y los proveedores   de servicios deberían   dar los pasos   relevantes descritos en 11.4.4, para facilitar la adopción y uso, por parte de los usuarios, de los controles técnicos de seguridad.
1064.  
1065.  
1066.  
1067. © ISO 2012 - Todos los derechos reservados
1068. 42 © INN 2015 - Para la adopción nacional
1069.  
1070. 31 el INN para SUPERINTENDENCIA DE BANCOS E INSTITUCIONES FINANCIERAS R.U.T.: 70.023.270-0 - Creado: 2017-04-12
1071. Licencia sólo 1 usuario. Cop a y uso en red PROHIBIDOS
1072. NCh-ISO 27032:2015
1073.  
1074.  
1075.  
1076. Las organizaciones y proveedores de servicios también debería adoptar las guías provistas en 11.4, las que son importantes como controles básicos en contra de los ataques de ingeniería social en el Ciberespacio.
1077.  
1078. Además, se deberían considerar los siguientes controles técnicos, útiles en contra de ataques específicos de ingeniera social:
1079.  
1080. a) Cuando hay Información sensible personal o corporativa involucrada en aplicaciones online, se debe considerar la provisión de soluciones de autenticación sólidas, ya sea como parte de la autenticación de acceso y/o cuando se ejecuten transacciones críticas. Una sólida autenticación se refiere al uso de dos o más factores adicionales de verificación de identidad sobre o más allá del uso del ID y contraseña de un usuario. El segundo factor y los factores adicionales pueden ser provistos utilizando una tarjeta inteligente, tokens biométricos u otros tokens de seguridad de mano.
1081.  
1082. b) Para los servicios basados en Web, las organizaciones deberían considerar usar un “Certificado de Alta Seguridad” para proporcionar una seguridad adicional a los usuarios online. Muchas Autoridades Comerciales (CA) y navegadores de Internet son capaces de soportar el uso de dichos certificados, lo que reduce la amenaza de ataques de suplantación de identidad.
1083.  
1084. c) Para asegurar la seguridad de los computadores de los usuarios que se conectan al sitio o aplicación de la organización, o del proveedor de servicios en el Ciberespacio, se deberían considerar controles adicionales para asegurar un nivel mínimo de seguridad, tales como la instalación de las últimas actualizaciones de seguridad. El uso de dichos controles se debería publicar en el Acuerdo de Servicios de los Usuarios Finales y/o en la Política de Seguridad y Privacidad del Sitio, según proceda.
1085.  
1086. 12.6 Disposición de la Ciberprotección
1087.  
1088. El Anexo A describe controles técnicos adicionales que se pueden aplicar para mejorar la disposición en el área de detección de eventos, a través de una Darknet para Seguimiento; la investigación, a través de Tracebacks; y la respuesta, a través de una Operación Sinkhole, como parte de la Ciberprotección de una organización.
1089.  
1090. 12.7 Otros controles
1091.  
1092. Otros controles pueden incluir algunos relacionados a la alerta y cuarentena de dispositivos que están comprometidos en actividades sospechosas u observadas, a través de la correlación de eventos desde los elementos del proveedor de servicios y/o empresa como los servidores DNS, el flujo de red de router, la filtración de mensajes salientes y las comunicaciones peer-to-peer.
1093.  
1094.  
1095. Luego, responder las siguientes preguntas:
1096. ¿Qué aspecto(s) consideras clave(s) de la falla en la seguridad de TJX que requieren atención?   
1097. ¿Cómo debería mejorar y fortalecerse la seguridad informática de la empresa? (Proponer topología de implementación) ¿Cuáles son sus prioridades a corto plazo y sus planes a largo plazo?  
1098. ¿TJX fue víctima de ingeniosos delincuentes cibernéticos o creó sus propios riesgos? ¿Cómo organizaciones inteligentes y confiables se involucran en este tipo de situación? 
1099. ¿Qué lecciones me llevo de este caso? 
1100.  
1101.  
1102.  
1103.  
1104.  
1105.  
1106.  
1107.  
1108.  
1109.  
1110.  
1111.  
1112.  
1113.