tag:blogger.com,1999:blog-21139284.post371297944811326025..comments2022-11-09T14:31:44.615+01:00Comments on Carpe Diem: PCI-DSS 2.0: Mi análisis de los cambiosAntonio Ramoshttp://www.blogger.com/profile/07193537464512243030noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-21139284.post-67175567983382693522010-12-16T19:04:08.261+01:002010-12-16T19:04:08.261+01:00Efectivamente, Álvaro.
PCI DSS solo cubre una par...Efectivamente, Álvaro.<br /><br />PCI DSS solo cubre una parte de la cadena de procesamiento, en concreto, los datos de autenticación del titular de tarjeta pero existen otros estándares que cubren otros aspectos: PA-DSS, PCI PED, etc.Antonio Ramoshttps://www.blogger.com/profile/07193537464512243030noreply@blogger.comtag:blogger.com,1999:blog-21139284.post-64430942185172049012010-12-15T03:18:27.148+01:002010-12-15T03:18:27.148+01:00Buenas, Antonio
Al hilo del PCI DSS y en relación...Buenas, Antonio<br /><br />Al hilo del PCI DSS y en relación con la LOPD...mira en los comentarios<br /><br />http://www.ayudaleyprotecciondatos.es/2010/12/02/firma-tableta-electronica/<br /><br />http://www.ayudaleyprotecciondatos.es/2010/12/13/identificacion-mediante-pin/<br /><br />Ya sé que PCI DSS no llega hasta este punto, pero creo que no se ha de olvidar que la gestión de seguridad de los pagos no se recoge completamente con PCI DSS<br /><br />Un saludoÁlvaro Del Hoyohttps://www.blogger.com/profile/01953024271095733531noreply@blogger.comtag:blogger.com,1999:blog-21139284.post-21326521977377309422010-11-17T23:04:19.893+01:002010-11-17T23:04:19.893+01:00Hola, Anónimo.
Estas modificaciones aparecen en l...Hola, Anónimo.<br /><br />Estas modificaciones aparecen en los requerimientos 6.2 y 6.5.6.<br /><br />En el 6.2, se habla de establecer un proceso para identificar y calificar la nuevas vulnerabilidades de seguridad que se descubran. Respecto a tu pregunta, el criterio debe ser una best practice de la industria (p.e. CVSS) y lo que nos dice es que, como mínimo, las más críticas, deberían ser clasificadas como de riesgo "alto".<br /><br />El 6.5.6 está encuadrado en el requerimiento que nos pide desarrollar aplicaciones basadas conforme a guías de configuración segura y prevenir las vulnerabilidades típicas en los procesos de desarrollo para incluir, entre otras, las vulnerabilidades "altas" identificadas en el punto anterior y que, en cualquier caso, serán las que toquen en cada momento, en línea con las típicas listas de OWASP, SANS, etc.). De esta forma, las aplicaciones que se ponen en producción nunca deberían tener vulnerabilidades de nivel alto, aunque sí de nivel medio o bajo...<br /><br />Perdona por la longitud del comentario.Antonio Ramoshttps://www.blogger.com/profile/07193537464512243030noreply@blogger.comtag:blogger.com,1999:blog-21139284.post-88725246553225072992010-11-17T15:57:17.433+01:002010-11-17T15:57:17.433+01:00Con respecto al requerimiento de calificar las vul...Con respecto al requerimiento de calificar las vulnerabilidades, además de identificarlas y de solventar las de riesgo "alto" (best practice hasta el 30 de junio de 2012), ¿el SSC va a fijar los criterios para calificar las vulnerabilidades, o será a interpretación de cada QSA? ¿qué sucede con aquellas no identificadas como riesgo "alto"? ¿hasta el 30/06/12, todas las vulnerabilidades se entienden de riesgo "alto"?Anonymousnoreply@blogger.com