Mostrando 3 respuestas a los debates
  • Autor
    Entradas
    • #44428
      lmtorres
      Participante

      Buen día

      Dentro de todo el trabajo que he venido realizando con el estándar PCI DSS, que básicamente han sido revisiones del nivel de cumplimiento o análisis de brecha para estimar lo que falta para cumplir en una empresa, siempre he tenido dudas con respecto a algunos controles que la normativa exige cumplir y que en muchas ocasiones los clientes interpretan de manera diferente.

      En principio cuando hablamos del requisito 10.4.2 (v2.0) quisiera saber que métodos utilizan para poder hacer una «revisión de las configuraciones del sistema y los valores de configuración de sincronización para verificar que el acceso a los datos de tiempo esté limitado sólo a personal que tenga necesidad de negocios de tener acceso a los datos de tiempo», esto es un control de acceso por usuarios al servidor NTP? es verificar que esté configurado el servidor NTP y solo lo haga el administrador?, lo mismo el control 10.4.3 que indica que se debe verificar que «La configuración de tiempo se recibe de fuentes aceptadas por la industria», cuales son esas fuentes aceptadas por la industria? los que aparecen en las listas del ntp.org? hay alguna lista internacional vigente? alguna ISO? etc…

      Por otro lado también he tenido dudas con respecto al control 8.4, requiere que las contraseñas se almacenen o transmitan de tal manera que no sean legibles basados en el uso de criptografía sólida, que es considerado por el SSC una criptografía sólida? algún algoritmo especial? usar un método de intercambio con llaves de algún tamaño mínimo (sabemos que llaves de menos de 512 bits son inseguras), en el caso de los que usan Active Directory, como se verifica la SAM? es posible determinar si las contraseñas de usuarios están almacenadas seguras?

      Así como los anteriores, hay otros más, pero no quiero hacer extenso el foro en esta ocasión, si alguien de la comunidad tiene alguna indicación al respecto se la agradezco.

      Saludos

    • #44525
      David Acosta
      Participante

      Buenos días:
      Antes que nada, gracias por participar.
      + Respecto a la primera pregunta relacionada con el requisito 10.4.2: Son dos partes. 1) Cuando se habla acerca de control de acceso a las configuraciones del sistema y valores de configuración se refiere a permisos en los ficheros de configuración, ya sean DAC (Control de Acceso Discrecional), MAC (Control de Acceso Mandatorio) o RBAC (Control de Acceso basado en Roles). Es decir: revisión de permisos. La idea detrás de este requerimiento es garantizar que nadie más salvo el personal autorizado pueda cambiar las configuraciones del sistema de tiempo de la organización. Por ejemplo: En el caso de NTP, validar los permisos del fichero de configuración ntp.conf. 2) Se habla también de «acceso a los datos de tiempo», es decir al servicio como tal. Para ello, la idea es validar que existan una serie de restricciones (ACL, por ejemplo) que limiten el acceso al servidor. Por ejemplo: En ntp.conf esto se puede implementar con la directiva «restrict».
      Muchos de estos parámetros deberían estar descritos en la guía de configuración segura del servicio de NTP que debería hacer parte del control 2.2 y en este requisito simplemente se validan que estén configurados de forma correcta para gestionar el riesgo de manipulación no autorizada del servicio.
      + Respecto a la pregunta del requisito 10.4.3, se habla de «fuentes aceptadas por la industria». El Navigating de PCI DSS v2.0 dice «…More information on NTP can be found at http://www.ntp.org, including information about time, time standards, and servers…». Es decir: en función de tu ubicación geográfica puedes usar un servidor de los descritos en http://www.ntp.org. Por otro lado, en cada país siempre se tiene un servidor de tiempo oficial. Para el caso de España el servidor de tiempo es el servidor del Real Instituto y Observatorio de la Armada (http://www.armada.mde.es/ArmadaPortal/page/Portal/ArmadaEspannola/ciencia_observatorio/prefLang_es/), en México el Centro Nacional de Metrología (CENAM), en Colombia el Instituto Nacional de Metrología y en Chile el Servicio Hidrográfico y Oceanográfico de la Armada de Chile (SHOA), por solo nombrar algunos.
      + Respecto al control 8.4: La descripción de criptografía sólida (Strong Cryptography) la puedes encontrar en el glosario de PCI DSS:
      «… Strong Cryptography:
      Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 (www.csrc.nist.gov/publications/) for more information…» https://www.pcisecuritystandards.org/security_standards/glossary.php#S
      En Windows, las contraseñas son generadas y almacenadas empleando un algoritmo de hash. Dependiendo de la versión del sistema operativo y de su configuración, se generan dos tipos de claves: LAN Manager hash (LM Hash) y Windows NT hash (NT hash – basado en MD4) que se almacenan en el fichero Security Accounts Manager (SAM) ubicado en C:WindowsSystem32configSAM y en Active Directory en C:WindowsNTDSntds.dit. Adicionalmente, para prevenir volcados de estos ficheros de hash se emplea un cifrado empleando una clave denominada SYSKEY. Más información en http://support.microsoft.com/kb/102716
      El uso de un algoritmo o de otro en Windows depende de la configuración de tu servidor y para ello, dicha configuración debe ser establecida en la guía de configuración segura de esta plataforma.
      Espero que esta información te sea de utilidad.
      Saludos,
      David

    • #44526
      lmtorres
      Participante

      David, había pasado agradecerte por las aclaraciones, han sido de mucha utilidad.

      Aprovecho para consultarte algo adicional, el pentest externo que la empresa tiene que hacer para asegurar el cumplimiento del control 11.3 necesariamente tiene que abarcar todos los servicios públicos de la empresa o puede limitarse a los que están asociados al CDE?. Esto surgió de un cliente que no tiene servicios públicos que manejen datos de tarjeta y tiene trabajos de pentest sobre otras aplicaciones y quiere saber si son válidos para el control. La verdad me dejó con dudas y por eso la aclaración.

      Saludos

    • #44527
      David Acosta
      Participante

      Hola:
      En este caso la respuesta es una sola palabra: segmentación.
      Tanto los escaneos internos y externos de vulnerabilidades (req. 11.2) y las pruebas de penetración internas y externas (req. 11.3) deben cubrir todos los elementos que se encuentren en el entorno de cumplimiento. Si los equipos que procesan, almacenan o transmiten datos de tarjetas de pago se encuentran en el mismo segmento que otros equipos que no interactúan con tarjetas, directamente dichos equipos entran en el entorno. Por eso, una forma de minimizar el alcance es empleando segmentación. En el estándar PCI DSS v3.0 (que puedes descargar aquí: http://www.pcihispano.com/pci-dss-y-pa-dss-v3-0-disponibles-en-espanol/) encontrarás los apartados «Alcance de los requisitos de las PCI DSS» y «Segmentación de red» y el Anexo D: «Segmentación y muestreo de instalaciones de negocios/Componentes de sistemas» que definen cómo se debe segmentar y evaluar la validez de dicha segmentación para definir qué equipos entran o no en el alcance.
      Así mismo, en la versión 3.0 de PCI DSS viene un nuevo requerimiento (req. 11.3.4) que establece la necesidad de ejecutar pruebas de penetración para validar la segmentación si ha sido implementada en el entorno.
      En conclusión: Las pruebas de penetración tienen que cubrir TODOS los elementos del CDE. Si no existe segmentación, todos los elementos que convivan dentro del mismo segmento de red en donde se encuentran equipos cubiertos por PCI DSS deberán ser analizados también. Si existe segmentación, la prueba deberá validar que la segmentación está correctamente implementada.
      Espero que esta respuesta te sea de utilidad.
      Saludos,
      David

Mostrando 3 respuestas a los debates
  • Debes estar registrado para responder a este debate.