33 Principios de Seguridad IT de la NIST (National Institute of Standards and Technology) recomendados.

Ttotalmente recomendable revisar y aplicarlo en cualquier fase que nos encontremos en el desarrollo de un sistema en nuestra propia empresa o entidad.

Estos principios están basados en la publicación de la NIST Special Publications 800–27 Rev A, Engineering Principles for Technology Security, es un análisis personal, también he tomado otras normas como la ISO 27001 (ISO de Seguridad de la Información), PCI (Norma de protección de los datos de tarjetahabientes) y OWASP ( proyecto abierto de seguridad en aplicaciones Web) como mejores practicas en “Desarrollo Seguro de Software”.

A continuación muestro algunos principios que me llamaron la atención:

Principio 1 y 2: Establecer una política de Seguridad solida como base fundamental.

En otras normas tamb ién es fundamental, por ejemplo en la ISO de Seguridad de la Información ISO 27001 (Según la cláusula 4.3.1, los documentos del SGSI) y en la PCI (Payment Card Industry) el Requerimiento No 12 “Maintain an Information Security Policy”.

NIST 800–27:

ISO: https://www.iso-27001.at/download/

PCI:https://pcicompliance.stanford.edu/sites/default/files/pci_dss_v3-2.pdf

Principio 4: Asegurarte que los desarrolladores de software han sido capacitados en “Desarrollo Seguro”.

Como complemento agrego el link de OWAS (Open Web Aplicacion Security Project), super importante que el área de desarrollo de software de las empresas tengan una capacitación sobre este proyecto, a continuación muestro un Checklist muy completo que toda área de desarrollo de software debería seguir para cumplir los requerimientos de seguridad.
OWASP: https://www.owasp.org/index.php/Sobre_OWASP

Principio 5: Reduce el riesgo a un nivel aceptable
También va de la mano con la ISO 27001 y la ISO 27005 de Gestión de Riesgo. Uno de los pilares de la Seguridad de la Información, Identificar y Controlar el Riesgo que tienes en la Empresa, controlarlo con los controles más idóneos que tengas para reducir el riesgo.

Por ejemplo de la ISO 27001:2013

En el caso de la PCI también te recomienda analizar los riesgos que tienes en las empresas:

Principio 6: Asumir que sistemas externos son inseguros y el Principio 16 Implementa la seguridad por capas
Como Internet, Proveedores, Consultoras en general “terceros” que se conectan a tu red para entregar o recibir información que tú produces o necesitas.

Se asume inseguro por que no tienes ningún control en las redes/Sistemas externos quizás tienen un nivel de seguridad pero tú no lo sabes, por ello debes implementar niveles de seguridad por capas que permitan un control de acceso y adicionalmente un servicio de control como AAA (Accounting Authorization Accounting) así podrás autorizar y tener eventos que reporten la actividad realizada entre otros controles más específicos a aplicar, permitir el ingreso de solo el servicio que esta previamente validado.

Principio 9: Protege la Información mientras esta siendo procesada, en transito y donde esta alojada.

Como ejemplo para el caso de PCI, este principio va en el corazon de la PCI
donde indica que cuando se transfiere, recibe, procesa y donde se aloja información de Tarjetas de Crédito se debe proteger la información de los tarjetahabientes, definición de es el nombre que recibe el usuario de una tarjeta de crédito y débito
PCI:https://pcicompliance.stanford.edu/sites/default/files/pci_dss_v3-2.pdf

Principio 15: Esforzarse por la facilidad de uso operacional
Cuanto el control es más elaborado a aplicar, muchas veces es más costoso y la operación será más compleja. Ejemplo cuando pedimos una contraseña fuerte para usuarios de dominio, constantemente hemos recargado al service desk y mal estar constante de usuarios. Aquí se recomienda encontrar el equilibrio entre el mejor control y la fácil adopción de usuarios, administradores, claro capacitándolos y cada cierto tiempo revisando la eficiencia del control aplicado si realmente los usuarios han podido adoptarlo adecuadamente.

Principio 17: Limitar el daño frente a un Ataque.
Los sistemas deberían ser resistentes ante un ataque, por lo tanto debe
limitarse el daño, y poder recuperarse rápidamente cuando ocurre un ataque.

Ejemplo: Si tenemos servicios públicos como un servidor Web, Correo,
o alguna aplicación en Internet y esta conectado a la red Interna en la misma red de los usuarios de la empresa sin ninguna restricción esto es un grave Error!!, ya que si cualquier servicio público es comprometido desde Internet o desde la red Interna que sería lo más probable “el atacante” podrá ingresar a otros servicios de la red Interna sin ningún problema, por ello es recomendable:

• Servicios públicos estén en una red independiente de la red interna como una DMZ para servicios públicos, DMZ para Proveedores
• Con Políticas de firewall tanto de “entrada” como de “salida” de tráfico
• Registros Events/logging activado para identificar y revisar intentos de intrusión.
• Aseguramiento del mismo servicio público a nivel del servidor como un “Hardening del Servidor”.

Fuente Principal: NIST Special Publications 800–27 Rev A, Engineering Principles for Technology Security desarrollado por la NIST (National Institute of Standards and Technology).

goo.gl/RGU546