Módulos CPAN de Perl en un entorno PCI-DSS

¿Puede señalar la sección en Requisitos de DSS de PCI y procedimientos de evaluación de seguridad 2.0 que está utilizando para justificar esto? No está del todo claro si el problema es el hecho de que se trate de un código de terceros o de que se obtenga a través de un repositorio administrado colectivamente.

Si esto es solo una auditoría PCI-DSS, discuta su caso:

  

PA-DSS no se aplica a las aplicaciones de pago desarrolladas por comerciantes y proveedores de servicios si se usan solo de forma interna (no se venden, distribuyen ni otorgan licencias a un tercero), ya que esta aplicación de pago desarrollada internamente se tratará como parte del cumplimiento normal de PCI DSS del comerciante o proveedor de servicios. [página 9]

y

  

Nota: No es un requisito de PCI DSS utilizar aplicaciones validadas PA-DSS. [página 16]

Debe revisar su código personalizado (PCI-DSS §6.3.2), no necesariamente todos (PA-DSS §5.1.4).

En un sentido estricto, los códigos o repositorios de terceros no auditados son riesgos. Necesita demostrablemente comprender y gestionar esos riesgos.

Deberías tener un inventario detallado:

• Lista de hardware y software crítico en uso en el entorno de datos del titular de la tarjeta, junto con una descripción de la función / uso para cada

Para cumplir con el Requisito 6 , debe tener un proceso verificable para usar ese inventario para verificar y aplicar oportunamente las actualizaciones de seguridad relevantes (§6.1, §6.2) para software de terceros. . Esto también debe estar cubierto por sus procedimientos documentados de control de cambios (§6.4.5).

Debe tener un proceso para evaluar (no auditar) los módulos para que las características que se incluyen en PCI-DSS se verifiquen y se comprendan (por ejemplo, se relacionan con la autenticación, el cifrado y el registro). ). Probablemente, esto signifique que necesita tener aprobadas versiones de referencia de ciertos paquetes y pautas de configuración (por ejemplo, para tiendas de CA, cifrados permitidos), donde sea relevante.

Debe contar con un proceso documentado para configurar CPAN, que incluye, entre otros, un conjunto de espejos aprobados, que requieren gpg / Module::Signature (donde sea posible), procedimientos para buscar claves de firma de desarrolladores y que requiera un proxy para que las descargas son registradas y rastreables.

  

Piensa que deberíamos tener a alguien del exterior que audite todo el código de CPAN que queremos instalar. Esta persona necesitaría tener una sólida formación en seguridad y un profundo conocimiento de Perl. Desafortunadamente, no conocen a nadie así.

Bueno, ¿por qué no piensa lo mismo para las rpm? Solo le parece más riesgoso porque se siente perdido allí. Pero es solo una impresión y no un miedo lógico. En ambos casos, debería poder hacer un seguimiento de los cambios antes de actualizar / instalar algo. Sin embargo, para que la sociedad prospere, todos debemos depender de otros y confiar en los sistemas de seguridad. Parece que el CPAN no es lo suficientemente seguro, sin siquiera investigarlo adecuadamente. La forma más segura probablemente sería descargar una máquina desde una fuente confiable (averiguar cuál es la primera), crear un paquete y desplegarlo. Actualizar solo cuando hay un problema de seguridad. Dicho sistema de seguimiento es obligatorio para cualquier infraestructura importante. Esos fueron mis dos centavos.

Ahora, acerca de su pregunta, cómo otras compañías que trabajan con Perl están manejando este problema. Desde mi propia experiencia, utilizamos paquetes proporcionados por el sistema de empaquetado del sistema operativo. Simplemente porque CPAN resultaría demasiado doloroso, algunos paquetes no se compilarían limpiamente, algunas pruebas fallarían. Subcontratar ese trabajo a los empacadores parecía una buena idea de negocio. Y no estoy imaginando ningún beneficio de seguridad. Las firmas de los paquetes no están disponibles / habilitadas en todos los sistemas operativos, por lo que es claramente una cosa para investigar para sus propios sistemas.

Entonces, si tienes algo que recordar: no des por sentado nada. No hay una sola respuesta correcta. OpenSuse podría no proporcionar más seguridad que CPAN, pero podría. Si todo se reduce a la seguridad del espejo que está usando, es posible que necesite en ambos casos para asegurarse de que se puedan verificar los paquetes o paquetes.

CPAN se envía con Perl, está más cerca de la fuente desde mi punto de vista y también tiene beneficios. Entonces, este no es un problema real en este punto.

Para lo que vale, aquí está OpenBSD Makefile utilizado para crear paquetes: enlace . Como puedes ver, usa cpan. OpenBSD es bien conocido por su seguridad inmediata, no creo que OpenSuse haga algo significativamente diferente.

Siga usando CPAN solo si ve una ventaja en ello. La seguridad no es un problema aquí, cada uno tiene que estudiarse de manera diferente (recuperación / comprobación de suma de comprobación, duplicados) pero desde mi punto de vista, uno no es más seguro que otro.

Los paquetes pueden ser parches de código CPAN +, los parches podrían corregir errores o quizás crear otros, no hay forma de saberlo.