¿Cuándo pensaremos en la seguridad del software?

La priorización de costos, alcances, tiempos, UX, UI, SEO siempre está por delante. La seguridad pareciera ser lo que nadie desea abordar en desarrollo de software. Me gustaría comenzar este artículo entendiendo que en el estado del arte de las tecnologías de la información podemos encontrar un sinfín de gamas, familias de productos para responder diferentes tipos de problemáticas o software, también en muchos casos software que no necesariamente necesitamos, pero igual adquirimos por distintos motivos o ideas del negocio.

Es ahí donde el rol del oficial de seguridad de la información debe estar cual águila atento a los movimientos que se van dando, si es un software en datacenter propio.

Los riesgos de usar software inseguro no son simplemente que se filtren datos (aunque el daño reputacional es el peor): en cientos de casos, sistemas inseguros dan acceso a su red corporativa, a ataques laterales a otros servidores o a centros de control para campañas de distribución de malware de todo tipo. No le baje la importancia, estime bien su criticidad, sepa qué activos tiene.

En el caso de que adquiera un software para manejar data de su organización:

• ¿Fue el software desarrollado bajo un modelo de desarrollo seguro?
• ¿El proveedor conoce Safe Code, OWASP SAMM?
• Si la respuesta es afirmativa, pregunte cuál. ¡No acepte respuestas difusas!
• ¿La empresa tiene una política de seguridad vigente?
• ¿La empresa tiene una política de desarrollo seguro vigente?
• ¿La empresa tiene una política de confidencialidad y privacidad de la información vigente?
• ¿Cómo gestiona los riesgos de seguridad la empresa?

Sobre la ciberseguridad del producto:

• ¿El sitio tiene HTTPS?
• ¿El desarrollo tiene configurado el hardening sobre el servidor?
• ¿El desarrollo tiene configurado el hardening sobre la plataforma?
• ¿El desarrollo tiene fases de QA documentadas?
• ¿El desarrollo tiene apoyo de análisis de vulnerabilidades durante la codificación?
• ¿El producto tiene una prueba al menos de vulneración basada en algún estándar internacional?
• ¿El proyecto tiene definido versionamiento, despliegue y gestión de parches?
• ¿Cómo se gestionan los días cero?, ¿hay un protocolo en caso de vulneración crítica?
• ¿La plataforma tiene al menos un test de penetración?

Si es una compra de un servicio en la nube:

Preguntar antes todo lo anterior, y además:

• ¿Cuál es el SLA asociado al servicio?
• ¿Existe un tiempo de recuperación tolerable asociado?
• ¿Existe un objetivo de recuperación definido?
• ¿Existe un acuerdo de no divulgación asociado?
• ¿Es un servicio con mesa de ayuda 24x7, 12x5, 8x5?
• ¿La mesa de ayuda es robotizada?
• ¿Dónde están sus datos?
• Al cargar los datos en los servidores de la empresa, ¿siguen siendo de su propiedad?

¿Qué opina usted?