hardening

Las empresas y proveedores de software por lo general ofrecen sus productos con unas configuraciones generalizadas con el fin de adaptarse a la mayoría de entornos en los cuales se instale, facilitando el proceso de despliegue y puesta en producción, focalizándose en usabilidad, funcionalidad y adaptabilidad. Es por ello que en dichas instalaciones se pueden encontrar nombres de usuario y contraseñas por defecto, gran cantidad de servicios en ejecución, controladores, scripts y otros componentes que dependiendo del escenario se pueden o no necesitar.  Este acercamiento se puede sintetizar en la siguiente frase: “Lo que no está expresamente prohibido está permitido”, en donde el objetivo es la operatividad sobre seguridad.

Lamentablemente esta visión operativa entra en conflicto con una posición de seguridad responsable en donde se requiere de una minimización de la superficie de ataque, detención de servicios y eliminación de componentes no necesarios y cambio de valores por defecto para evitar posibles vulnerabilidades y ataques. En este caso, se aplicaría el concepto de “lo que no está expresamente permitido está prohibido”. El principal problema al que se enfrenta este modelo es que debe ser personalizado y adecuado a cada entorno en específico en función de sus necesidades para que las configuraciones de seguridad no penalicen la operación. Para poder implementar esta estrategia se necesita que la organización documente puntualmente las funcionalidades que estén permitidas y aquellas que están denegadas y describa los pasos para implementar dichas configuraciones.

Uno de los requerimientos claves en términos de seguridad lógica dentro del estándar PCI DSS es el requisito 2 “No utilizar contraseñas de sistemas y otros parámetros de seguridad provistos por los proveedores”.  El objetivo de dicho requisito es garantizar que cada activo que pertenezca al entorno de cumplimiento (sistemas operativos, bases de datos, equipos activos de red y aplicaciones) tenga relacionado un documento en donde se especifiquen los parámetros de seguridad que requiere para la correcta gestión de la confidencialidad, integridad, disponibilidad, trazabilidad y no repudio. Este documento se conoce como “estándar de configuración segura” o “guía de hardening (securización)” adaptada a las necesidades y particularidades de la organización y alineada con los demás controles de PCI DSS.

La definición de un flujo de despliegue en producción que cumpla con los parámetros de seguridad de PCI DSS sería el siguiente (ver req. 6.4 de PCI DSS):

  1. Instalación del software en un entorno de desarrollo/pruebas y validación de su operatividad e integración
  2. Aplicación de los parámetros descritos en la guía de configuración segura, adaptación a las necesidades puntuales de la organización y gestión de excepciones (proceso de securización)
  3. Puesta en producción

Lamentablemente, muchas organizaciones – ya sea por desconocimiento, por restricciones de tiempo en los proyectos o por simple negligencia – olvidas la implementación del punto 2 (securización), exponiendo el activo, su información y los elementos a su alrededor a riesgos injustificados.  Y es gracias a este fallo cuando vienen los problemas (para ejemplos ver aquí, aquí, aquí y aquí).

Por otro lado, la seguridad es un concepto que se degrada con el tiempo. Diariamente se encuentran nuevas vulnerabilidades, se publican nuevas versiones de software y hay cambios en el entorno de cumplimiento, cambios que deben ser adaptados y documentados para que el nivel de seguridad permanezca estable a lo largo del tiempo. Por ello,  las guías de configuración segura deben ser actualizadas constantemente y su aplicación validada de forma periódica. De igual manera, todo el personal administrativo y operativo debe conocer la existencia de estas guías para garantizar su correcta aplicación como base de una estrategia de defensa en profundidad.

El requerimiento 2.2 de PCI DSS define lo siguiente:

” 2.2 Desarrolle normas de configuración para todos los componentes de sistemas. Asegúrese de que estas normas contemplen todas las vulnerabilidades de seguridad conocidas y que concuerden con las normas de alta seguridad de sistema aceptadas en la industria.”

Es por ello que se vuelve indispensable que en una organización que quiera alinearse con PCI DSS se desarrollen una serie de guías de configuración segura, una por cada tecnología que integre el entorno de cumplimiento.

En este artículo se describirán una serie de recursos en Internet que pueden servir en el momento de la redacción y personalización de dichas guías y un listado de los controles de PCI DSS que deben estar cubiertos en dichos documentos.

Los controles de PCI DSS y los estándares de configuración segura

Para PCI DSS una guía de configuración segura debe cumplir con el objetivo del estándar: la gestión de los riesgos asociados a un potencial fraude con tarjetas de pago. Es por ello que no cualquier documento de securización genérico sirve, por lo que se debe definir un estándar de configuración segura específico y ajustado a las necesidades de la empresa por cada tecnología y sistema presente en el ámbito de cumplimiento.

checklist

A continuación se presenta un listado de referencia en una hoja de cálculo de Microsoft Excel con los controles mínimos de PCI DSS que deben ser cubiertos por un estándar de configuración segura (o guía de hardening):

PCIDSS Hardening Guide v3.2

Sitios web de referencia para la redacción de estándares de configuración segura

No existe una guía de configuración segura específica para PCI DSS. Cada estándar de configuración segura ha de ser particular y adaptado al entorno especifico de la organización, cumpliendo los controles que exige la normativa. Sin embargo, muchos sitios web ofrecen documentos que pueden ser usados como referencia en la redacción y desarrollo de estos estándares. Igualmente, es muy común que los desarrolladores y fabricantes publiquen en sus sitios web buenas prácticas y recomendaciones de configuración de seguridad que son recursos válidos en este proceso. A continuación se enumeran algunos de ellos.

Referencias generales

A continuación se referencian una serie de sitios web con documentación general relacionada con configuración segura:

Referencias por Fabricante/Tecnología

A continuación  se presentan una serie de enlaces de referencia con base en fabricantes y tecnologías específicas (organizado alfabéticamente):

En estas URLs se podrá encontrar información general de diversas tecnologías:

El proyecto BetterCrypto ha desarrollado una guía muy interesante en la cual describen los pasos a implementar para la configuración de cifrado en SSL, PGP y SSH en diferentes plataformas. Aunque el documento aún se encuentra en borrador (draft), es una muy buena guía para el cumplimiento de los controles 3 y 4 de PCI DSS:

¿Conoce algún otro sitio de referencia para la redacción de guías de configuración? ¿Alguno de los enlaces listados arriba tiene problemas? Todas las ideas, sugerencias, erratas y comentarios son bienvenidos en los comentarios o en el foro.