La versión OpenSSL causa un error de Cumplimiento de PCI

Hasta que pueda obtener un escaneo limpio o hacer que su PCI-QSA se apague con una prueba de que cumple con las normas, es su responsabilidad cumplir los requisitos de cumplimiento independientemente de las implicaciones de seguridad del mundo real.

El cumplimiento no es igual a la seguridad y la seguridad no es el cumplimiento igual.

Dicho esto, por lo general, una organización documentará la prueba de ambos proveedores de que un determinado CVE encontrado en un escaneo se aborda mediante una subversión de parche / aplicación específica, así como una prueba de que todos los sistemas en una Zona PCI tienen esa versión de código aplicado (depende de lo que realmente involucre la remediación).

El QSA puede entonces certificar que el hallazgo de la exploración ASV es en realidad un falso positivo.

Su pregunta también está conduciendo a otro problema: ¿Qué sucede si hay una vulnerabilidad conocida importante y el proveedor no la soluciona? Cuando este sea el caso, es posible que tenga que crear sus propias soluciones para solucionar la vulnerabilidad. También se encuentra con el caso en el que alguien podría argumentar que sí, la última versión de su distro puede ser solo X, pero la última versión de OpenSSL (o aplicación de inserción aquí) es Y. En este escenario, usted es responsable de los parches de nivel de aplicación mantenerse actualizado además de los parches del sistema operativo . Por lo tanto, al no actualizar el paquete individual, está fuera de cumplimiento.

Por compilación de OpenSSL, creo que encontrará que no es particularmente difícil, pero primero lo prueba en otro sistema (no en producción).

En última instancia, aún debe consultar a su QSA (suponiendo que tenga uno), ya que pueden proporcionarle una orientación muy específica que puede ayudarlo. Un buen QSA también puede ahorrarle tiempo aquí. Es posible que el procesador de la tarjeta no quiera avisarle en caso de que haya una demanda más adelante. Una vez más, pregunte a su QSA.

Desde un punto de vista de seguridad estricto, ignorando todo lo relacionado con el cumplimiento: Siempre asegúrese de que su superficie de ataque esté bien parcheada a la versión de parche más actual y, cuando sea posible, agregue controles adicionales para la defensa en profundidad. Las herramientas como Fail2Ban pueden ser tus amigos aquí. Del mismo modo, tenga en cuenta que la aplicación de parches no resuelve sus problemas de seguridad, realmente necesita controles adicionales para proteger sus datos. Del mismo modo, cumplir con cualquier estándar de cumplimiento dado no le dará una buena arquitectura de seguridad. Realmente necesita diseñar seguridad en lo más profundo de su solución y no solo tratar de cumplir con una guía de cumplimiento básica o niveles de parches de proveedores.

Tenga en cuenta que si es el custodio de los datos o el propietario de los mismos, tiene la responsabilidad directa de mantener el sistema que protege estos datos (o el acceso a ellos) tan seguro como sea posible. No basta con confiar en los parches.

La seguridad y el cumplimiento a veces son objetivos en competencia. Lamentablemente, estos dos no siempre están alineados y no es raro ver que el dinero gastado por las empresas se retira de las cosas que realmente protegen los datos y se gastan en cosas. eso hace que una organización "cumpla" (a veces este proceso incluso aumenta el riesgo). Tenga cuidado de no confundir estos dos objetivos. Tiene un problema de cumplimiento Y un problema de seguridad, no son lo mismo. Si mantiene estos dos objetivos por separado, encontrará buenas soluciones para ambos más fáciles que si intenta resolver ambos con La misma solución cada vez. Es genial cuando una solución los soluciona a ambos, pero esto no siempre sucederá de la manera que usted quiere.

Finalmente, diríjase a esto con su proveedor de distribución también. Agregar presión sobre ellos para mantenerse al día con los parches de seguridad cuando sea posible ayudará a priorizar los esfuerzos de seguridad.