Mostrando 1 respuesta al debate
  • Autor
    Entradas
    • #44427
      Carlos
      Participante

      Hola,

      como novato total en este tema, llevo un tiempo leyendo y releyendo el PCIDSS, y la verdad es que cada vez que lo leo me parece mas ambiguo dejando muchos aspectos abiertos a la interpretación.

      Guardando las distancias del articulo de la web «La red ideal PCI DSS», mi intención es mas humilde, montar el mínimo necesario para el cumplimiento del PCIDSS. La estructura depende del escenario y demás, pero me voy a poner en el mas simple,… una persona que tiene que guardar PANs en un servidor (ni lo consulta ni opera ni nada, vamos al caso sencillo, solo lo guarda y los borra en X días)

      Después del primer vistazo a los requerimientos del PCI, uno se da cuenta de que tener el servidor PCI «en casa» se hace inviable, ya que necesita cumplir los requisitos de acceso físico al ordenador. Con lo que tenemos que recurrir a la busqueda de un alojamiento que cumpla este requisito. Echando un vistazo a internet, se puede encontrar alguno (incluso gratuitos el primer año), pero ya nos surge las primeras dudas referentes al PCI:

      * ¿Cuantos equipos tengo que contratar? Según el punto 2.2.1 «Implement only one primary function per server», entonces si nuestra intención solo es almacenar, con uno suficiente. Pero claro, necesitamos un «interfaz» para guardar esos datos… ¿ya se considera otra función? Claro, aquí entra en juego un poco la lógica, ya que aunque estrictamente hablando sea dos funciones, es mucho menos seguro separarlo en dos servidores y dejar abierto la base de datos fuera de la propia maquina, que instalarlo todo en el mismo servidor y la base de datos solo escuche peticiones desde localhost ¿no?

      * Por otro lado, tenemos el punto 1.3 v3.0 «Prohibit direct public access between the internet and any system component in the card holder data enviroment». ¿Qué se puede considerar acceso directo a internet? Si tengo un firewall con todo a deny menos a un puerto concreto de una IP concreta… ¿se considera que está conectado a internet? Hombre, físicamente lo está, pero a nivel lógico no.

      * En cuanto a la persona que introduce la información, suponiendo que lo escriba directamente en el «interfaz». ¿Debería también pasar el PCI la red desde donde lo está metiendo?. Yo pienso que no, ya que por poner un ejemplo, los TPVs virtuales. ¿Quién no ha metido su tarjeta alguna vez para realizar una compra? Evidentemente es imposible abarcar todo.

      ¿Qué pensáis? Como comentaba al principio, una cosa es lo que ponga en el requisito y otra bien distinta la interpretación real que se le pueda dar.

    • #44524
      David Acosta
      Participante

      Hola Carlos:

      Entiendo tus comentarios. El estándar PCI DSS (al igual que otros estándares y normativas) trata de ser lo suficientemente genérico para aplicar tanto a un comercio pequeño como a un proveedor de servicios internacional, pero a la vez trata de cubrir al máximo los detalles lógicos, físicos y administrativos delegados en estas tareas. Siendo así – y lo digo por experiencia en implementación y auditoría – siempre se encuentran escenarios atípicos. Y es aquí en donde vienen las ambigüedades y las diferentes interpretaciones entre los QSA o ISA encargados de los proyectos. Lo que debe primar en este tipo de casos es la gestión óptima del potencial riesgo identificado, en donde pesa bastante el criterio y la experiencia de la persona que te esté asesorando en el proceso.

      Ahora bien, respecto al cumplimiento. La recomendación del PCI SSC es que si no se requieren almacenar, procesar o transmitir datos de tarjeta, no se haga (ver http://www.pcihispano.com/una-revision-a-los-10-mitos-comunes-de-pci-dss/ MITO 9: PCI DSS obliga a almacenar datos de tarjetas). Si definitivamente por una justificación técnica o administrativa requieres acceder a datos de tarjetas de pago, los controles que te aplicarán dependerán de tu tipo de servicio (comercio o proveedor de servicios), los canales de pago presentes y la cantidad de transacciones anuales que proceses. Con estas variables, sabrás si tienes que asumir una auditoría o un Cuestionario de Evaluación, que puede ser del tipo A (13 preguntas), B (29 preguntas), C (40 preguntas), C VT (51 preguntas) o D (288 preguntas) y si te aplican o no escaneos ASV.

      Por poner un ejemplo sencillo alineado a tu pregunta: Un comercio que almacena datos de tarjetas de pago (PAN) para transacciones recurrentes (un cobro periódico o un cliente que no quiere digitar los datos de su tarjeta cada vez que hace una compra). Digamos que es un comercio electrónico y tiene un servidor web, un servidor de aplicaciones y una base de datos (3 equipos independientes). Tiene varias opciones para trabajar con base en una gestión del riesgo:
      + Minimizarlo: Puede optar por hacerlo él mismo (es decir: implementar todos los servicios con su propia infraestructura). Dependiendo de la cantidad de transacciones anuales, debe cumplir con un SAQ D o con una auditoría, con lo cual le aplican todos (o la gran mayoría) de controles del estándar. Para minimizar el potencial riesgo de tener todo este proceso in-house, debe aplicar los controles de PCI DSS, lo cual le implicaría implementar firewalls, antivirus, FIM (File Integrity Monitoring), servidor de log centralizado, servidor de NTP, WAF (Web Application Firewall), IDS/IPS, por solo nombrar algunos y obviamente todo el marco normativo y procedimental asociado.
      + Transferirlo: Así mismo, puede optar por delegar en un tercero ciertos controles de PCI DSS, por ejemplo en un proveedor de hosting seguro que cumpla con PCI DSS. Obviamente, los costes no serán los mismos que un hosting normal, pero de esa forma delega el cumplimiento de determinados controles a un tercero y los refuerza con el control 12.8 (gestión de proveedores). O puede contratar una empresa certificada en PCI DSS que capture, almacene, procese y transmita los datos de tarjeta a su nombre y aplicar a un SAQ A (13 preguntas).
      + Eliminarlo: Hacer un análisis coste/beneficio de darle este servicio al cliente (que implicaría cumplir todos los controles de la normativa) o retirar este servicio y de esta forma minimizar el cumplimiento al mínimo.
      Obviamente, asumir el riesgo no es una opción válida.

      Como ves, todo es cuestión de coste/beneficio.

      Respecto al apartado de ingreso manual de datos a través de un TPV. Aquí hay que hacer varias aclaraciones:
      + Si eres tu el que ofrece ese servicio (por ejemplo: personal de tu empresa en un call center que capturan los datos de la tarjeta y los digitan en un TPV Virtual) debes aislar los equipos que efectúan esta tarea. Aquí aplicarían los controles del SAQ C y SAQ C VT.
      + Si es tu cliente quien los digita (por ejemplo: yo como comprador en tu tienda virtual) pues tu no puedes aplicar controles sobre un equipo que no puedes gestionar (mi ordenador, en este caso), por lo cual esos equipos están fuera del alcance.

      Siento si se ha quedado algo por fuera pero tampoco quiero hacer la respuesta más larga. Espero que te sea de utilidad. O si prefieres, abre diferentes discusiones con temas puntuales, para que las respuestas sean más específicas.

      Saludos,

      David

Mostrando 1 respuesta al debate
  • Debes estar registrado para responder a este debate.