Los atestados no siempre miden su postura defensiva

An atestación, por definición, is an indication that makes something evident. In the case of the security, specifically security programs it means to certify in an official capacity.

People often ask me what makes a good security program. As much as I would like to point to one aspect of my security perimeter to use as an example, there are multiple items to highlight. En industry relies on attestations and certifications to measure your security defenses. Engineers and operators will tell you that your actual security perimeter and threat assessment capabilities define your security program. I will tell you it is both compliance attestations as a measurement and the operational capabilities of your security team that define your program. Though attestations alone are not an accurate benchmark to measure a program.

Attestations are an industry necessity to ensure compliance with federal, local and state statutes as well as industry best practices. ISO, NIST or DoD standards form the baseline of most attestations. NIST, for example, publishes a set of standards and technical guides to help organizations build perimeter defenses that are “acceptable” a la government. As I will outline however, just because the standards are set doesn’t mean implementation is always stellar.

El despliegue de una herramienta no significa que aporte valor

Los controles permiten flexibilidad en la implantación y crecimiento operativo e innovación a lo largo del tiempo. Lamentablemente, algunas organizaciones aprovechan la flexibilidad para marcar la casilla, pero no disponen de defensas reales.

Un buen ejemplo de este problema son los sistemas de detección/protección de intrusos (IDS o IPS). Al igual que los escáneres de virus, la mayoría de las organizaciones invierten en IDS/IPS como una cuestión de prácticas de seguridad estándar para protegerse contra el tráfico malicioso y la filtración de datos. La industria está repleta de vendedores que fabrican diversas formas de sistemas IDS/IPS. Sin embargo, algunas organizaciones construyen sistemas en lugar de comprarlos.

I recently left one such organization that “built” their own intrusion detection system from open source tools. Auditors were told the system was a “fantastic tool”, and even given examples of traffic. When I dug deeper into the telemetry the tool was providing, I realized that traffic was not being analyzed at all. Rather, passing through the sensor as it was not configured to capture any traffic or alert at all. Furthermore, the credentials used to administer the tool were set up by a previous employee and were never updated after his departure. So essentially, the tool was sitting idle for months without any human intervention. Not only does this put the company at risk, but it also compromises the perimeter.

Un auditor avispado no habría detectado el problema porque las certificaciones no buscan información "operativa" sobre todos los sistemas: la norma es literalmente una capa de preguntas y respuestas. De hecho, la mayoría de las atestaciones miden simplemente si la herramienta existe, no la viabilidad operativa. Además, la mayoría de los auditores no son lo suficientemente técnicos como para discernir un IDS/IPS funcional de uno que no lo es. El grueso de la auditoría depende de que la empresa dé lo mejor de sí misma en lugar de responder a preguntas difíciles. Los auditores también tienen que cubrir una amplia gama de controles durante una auditoría, por lo que el tiempo es un factor importante en la calidad de su análisis.

Un certificado por sí solo le dirá que una empresa tiene un programa de seguridad maduro con controles. Exigir a un socio potencial que complete una encuesta de proveedores tampoco le proporcionará confianza. Las encuestas simplemente resumen la misma información en un formato diferente. Entonces, ¿cómo evaluar un programa de seguridad maduro?

Evaluar todo el programa de seguridad de la nube

En primer lugar, debe revisar como mínimo los certificados y el informe de resultados, no el resumen ejecutivo. Eso le proporcionará una visión general del programa revisado por un tercero. En segundo lugar, debería revisar si la empresa se somete a una prueba de penetración de terceros o a un programa de recompensas por fallos. Personalmente, no soy un fan de las recompensas por errores, pero soy un fan de las pruebas de penetración de terceros sobre una base anual. Las pruebas de penetración le proporcionan una prueba estructurada de sus defensas e información real sobre las vulnerabilidades. Por último, revise los documentos de seguridad (normalmente el índice) que la empresa utiliza como base para la implementación. Esto incluye (pero ciertamente no se limita a) una política de seguridad, respuesta a incidentes y gestión de vulnerabilidades. Un equipo de seguridad experimentado se ofrecerá a compartir esos documentos y artefactos como parte de la actividad normal.

I make it a matter of course to evaluate every vendor and partner from the perspective of access to company data. Meaning if the partner or vendor manages company data, they’re subject to more scrutiny than a vendor that does not. Keep in mind the business purpose when evaluating a security program. I review the business purpose and type of information involved, then evaluate from that perspective, rather than handle all partners and vendors the same. When in doubt, always ask for more information.