Citando la norma ISO 27001:
Objetivo 1: Requisitos de seguridad de los Sistemas de información
Garantizar que la seguridad de la información es una parte integral de los sistemas de información en todo su ciclo de vida. Esto también incluye los requisitos para los sistemas de información que proporcionan servicios través de. Redes públicas.
- 14.1.1 Análisis y especificación de los requisitos de seguridad
- 14.1.2 Aseguramiento de los servicios de aplicación en las redes públicas
- 14.1.3 Transacciones en línea
Objetivo 2: Seguridad den los procesos de desarrollo y soporte
Garantizar que la seguridad de la información ha sido diseñada e implementada dentro del ciclo de vida del desarrollo de los de los sistemas de la información.
- 14.2.1 Política de desarrollo seguro
- 14.2.2 Procedimiento de control de cambio del sistema
- 14.2.3 Revisión técnica de aplicaciones después de cambios de las plataformas operativas
- 14.2.4 Restricciones a los cambios en los paquetes de software
- 14.2.5 Principios de la ingeniería de Sistemas Seguros
- 14.2.6 Ambiente de desarrollo seguro
- 14.2.7 Desarrollo subcontratado
- 14.2.8 Pruebas de seguridad del sistema
- 14.2.9 Pruebas de aceptación del sistema
Objetivo 3: Datos de prueba
Garantizar la protección de los datos utilizados para las pruebas
- 14.3.1 Protección de datos de prueba
Objetivo 1: Requisitos de seguridad de los Sistemas de información
Se trata de un requisito para la definición y documentación de los requisitos de seguridad para los sistemas de información.
Los controles son los siguientes
14.1.1 Análisis y especificación de los requisitos de seguridad
Deberemos incluir requisitos para la seguridad de la información en la fase de especificación de condiciones para sistemas de información. Esto supone tener en cuenta la seguridad además de las funcionalidades requeridas por una aplicación o sistema antes de su fase de desarrollo.
Los requisitos de seguridad deben tener en cuenta valoraciones del impacto en el negocio de posibles fallos de seguridad (daño potencial)
Tenga en cuenta la principal ventaja de prever requisitos de seguridad en las fases tempranas de un desarrollo es el ahorro de costes ya que un rediseño puede ser mucho más costoso sin contar con los daños potenciales de los fallos no previstos en la seguridad
¿Qué controles de seguridad debemos considerar en una especificación?
Para ello podemos tener en cuenta factores como:
- ¿Qué nivel de confianza requiere la aplicación? Con ello podremos determinar los requisitos de autenticación.
- Especificaciones de la provisión de accesos para
- Usuarios
- Usuarios privilegiados y técnicos de mantenimiento
- ¿Qué funciones y responsabilidades requiere de los usuarios?
- ¿Qué necesidades de protección tienen los activos involucrados? (análisis de riesgos)
- ¿Qué requisitos de seguridad se derivan de los procesos del negocio?
- Registros de transacciones
- Supervisión y monitoreo
- Requisitos de no-repudio
- Otros
- ¿Qué otros controles de seguridad son aplicables?
- Interfaces para el registro y supervisión
- Sistemas de detección de fugas de datos
- Otros
En el caso de servicios a través de redes públicas hay controles específicos en los puntos siguientes 14.1.2 y 14.1.3
En el caso de compras de aplicaciones a terceros deberíamos establecer como control de seguridad:
- Procesos de compras formales que incluyan periodos de prueba y validación del producto
- Aplicar criterios de evaluación de riesgos para tomar medidas de control adicionales si el producto no satisface totalmente las necesidades de seguridad
- A la hora de integrar un software en aplicaciones o sistemas propios considere si es necesario configurar las aplicaciones, sistemas y Software a implantar en relación a la seguridad. Elabore procedimientos y asegúrese de que se implementan
- Defina protocolos de homologación y aceptación de productos de forma que se incluyan siempre criterios de seguridad de la información
- Aplique los criterios de aceptación de productos en actualizaciones de Software y en nuevas funcionalidades de productos en cuanto a criterios de seguridad. Una nueva funcionalidad puede ser muy interesante pero no debe vulnerar la seguridad de nuestros sistemas para que sea aceptable.
14.1.2 Aseguramiento de los servicios de aplicación en las redes públicas
Si utilizamos redes públicas para la transmisión de información sensible o para acceder a las aplicaciones deberemos tener en cuenta controles adicionales pues las redes públicas como internet suponen un riesgo adicional importante que debemos tener en cuenta si queremos salvaguardar nuestra información
En este caso hemos de valorar:
- El cifrado de las comunicaciones.
- Sistemas múltiples de autenticación.
- Uso de certificados digitales (Identificación segura de origen y destino).
- Sistemas de prevención de envío de información no permitida en redes publicas.
- Sistemas de protección para envíos involuntarios de archivos.
14.1.3 Transacciones en línea
Se trata de controles que garanticen la protección de las transacciones entre aplicaciones.
Los controles se han de aplicar para evitar
- Transacciones incompletas
- Errores de enrutamiento
- Mensajes no autorizados
- Alteración de los datos
- Divulgación de la información
- Duplicación de mensajes o reproducción no autorizada.
Para ello deberemos analizar la aplicabilidad de contar con controles tales como
- Uso de firma digital para garantizar las comunicaciones extremo a extremo
- Validación y verificación de autenticación en toda la cadena de transmisión
- El canal de comunicación es cifrado para garantizar la confidencialidad de las transmisiones
- La utilización de protocolos seguros
- Los datos de las transacciones se guardan en lugares no accesibles desde la red (Intranet, Entornos CLOUD etc.)
- La obtención de firmas digitales se debe garantizar que la seguridad se integra e incorpora a través de todo el proceso completo de gestión del certificado o firma.
- De poco valdría trabajar con una autoridad confiable si para obtener los certificados lo vamos publicando al no contar con métodos seguros para obtenerlos
Objetivo 2 Seguridad en los procesos de desarrollo y soporte
Se trata de controles para garantizar que se tienen en cuenta las necesidades de la seguridad de la información en los entornos de desarrollo de sistemas de información
14.2.1 Política de desarrollo seguro
Se deben establecer reglas para que la seguridad de la información sea tenida en cuenta en todo el proceso de desarrollo del software y en todo el ciclo de vida del mismo.
Estas reglas deben tener en cuenta aspectos como
- La seguridad en entornos de desarrollo
- La política determina la metodología que se aplica en el desarrollo del software
- Como se gestionan las distintas versiones de software
- Como se gestionan las vulnerabilidades del software
- Como se asegura los controles de seguridad en software subcontratado
- Como se establecen requisitos de seguridad en la fase de definición de funcionalidades del software
14.2.2 Procedimiento de control de cambio del sistema
Las actualizaciones de software suelen ser el punto crítico a tener muy en cuenta ya que pueden suponer un gran impacto en los entornos de desarrollo. Al igual que los entornos de producción en la fase de desarrollo deberemos vigilar y controlar estrechamente desde la actualización de los navegadores a las actualizaciones de los sistemas operativos y la introducción de nuevas funcionalidades
Para controlar estos cambios deberíamos proceder siempre bajo protocolos establecidos que tengan en cuenta
- El establecimiento de un proceso formal documentado para llevar a cabo los cambios
- La documentación de una especificación técnica o guía sobre la actuación para realizar los cambios
- La realización de pruebas y control de calidad sobre los cambios introducidos
- Gestionar la implementación mediante procesos de autorización, control de permisos y de planificación de los cambios
- La realización de una evaluación de riesgos antes de realizar y planificar los cambios
- Controlar que los requisitos de seguridad de los sistemas afectados no se vean comprometidos en la fase de implementación de los cambios
- Procesos de aprobación formal
- Restricción de accesos
- Control de personal y de tiempos
- Control de versiones de software
- Control de impacto en aplicaciones en servicio
- Limitación de actualizaciones automáticas en aplicaciones criticas
14.2.3 Revisión técnica de aplicaciones después de cambios de las plataformas operativas
“Un paso en falso y al traste con el negocio”
Después de una actualización deberíamos revisar y probar las aplicaciones para garantizar que los cambios no afecten a su operatividad
Para ello deberíamos tener en cuenta
- Proceso para revisar que se han realizado los cambios según las especificaciones y guías al efecto
- Planificar los cambios para que haya tiempo para realizar las pruebas
14.2.4 Restricciones a los cambios en los paquetes de software
“¿Actualizar por actualizar?”
Limitar los cambios en los paquetes software es una buena medida para delimitar o minimizar la posibilidad de generar incidentes. Se trata de limitar las actuaciones sobre el software a cambios absolutamente necesarios
Para ello deberíamos mantener una serie de criterios de actualización de forma que se revisen antes de realizar los cambios o pensar en hacerlos:
- ¿Cuál el riesgo de comprometer los procesos de control y de integridad existentes? Merece la pena correr el riesgo frente a los beneficios que obtendremos con la actualización
- ¿Contamos con el consentimiento o licencia del propietario del software?
- ¿Podemos evitar la actualización con versiones estables y estándar del Software?
- ¿Cuál es el impacto en los recursos sobre el mantenimiento del software a futuro?
- ¿Podemos garantizar la compatibilidad del software a instalar con el software existente?
14.2.5 Principios de la ingeniería de Sistemas Seguros
Los principios de ingeniería seguros nos requieren documentar procedimientos sobre cómo implementar medidas de seguridad en las técnicas de desarrollo como por ejemplo
- Procedimientos seguros para el diseño y codificación (elaboración de código seguro)
- Procesos de diseño de mecanismos de autenticación difíciles vulnerar
- Procesos de somatización de variables
- Procedimientos para el uso correcto de la criptografía
- Etc.
14.2.6 Ambiente de desarrollo seguro
La evaluación de riesgos para la seguridad de la información no solo debe afectar a los activos de información como software, datos o equipos y soportes sino que también debe aplicarse a los entornos de desarrollo, las personas, los procesos de desarrollo y las tecnologías utiliza dadas para determinar si es necesario aplicar medidas o controles de seguridad
Para evaluar si son necesarias controles de seguridad a las personas o procesos deberíamos tener en cuenta
- El grado de sensibilidad de los datos
- Los niveles de seguridad aplicables
- Los controles de seguridad definidos para cada tipo de información
- La confiabilidad del personal (ver 7.1.1)
- Las necesidades de separar entornos de desarrollo
- Los controles de acceso determinados para el entorno de desarrollo
- Las necesidades de respaldo de información
- Los controles y políticas para el traslado de información
14.2.7 Desarrollo subcontratado
Para la subcontratación de desarrollos de Software deberíamos tener en cuenta
- Establecer y supervisar el cumplimiento de los requisitos de seguridad
- Controlar y gestionar todos los aspectos de licencias y propiedades de código fuente
- Metodología y definición de las pruebas a realizar al software subcontratado
- Todo lo anterior debe ser plasmado en acuerdos firmados y consensuados con el proveedor
14.2.8 Pruebas de seguridad del sistema
Los requisitos para la seguridad de un sistema software deben ser probados como si se tratase de una funcionalidad más del software. Para ello debería implementarse un plan de pruebas documentado.
Las pruebas también deben incluir al software subcontratado
14.2.9 Pruebas de aceptación del sistema
El proceso de incorporación de nuevas aplicaciones actualizaciones o nuevas versiones de software debe estar sujeto a un proceso de aceptación donde se le realicen las pruebas funcionales y de seguridad planificadas.
Los entornos de pruebas deben ser distintos a los entornos de operación para evitar fallos en sistemas reales
Objetivo 3 Datos de prueba
Los entornos de pruebas no siempre cuentan con los mismos niveles de seguridad que los entornos de operación por lo que se deberían establecer controles para seleccionar los datos para los sistemas de prueba o entornos de desarrollo
14.3.1 Protección de datos de prueba
Si no existe otra posibilidad en los entornos de prueba deberíamos utilizar datos NO reales para los desarrollos y pruebas posteriores de los sistemas.
En caso de que esto no fuera posible deberíamos aplicar los mismos controles de seguridad (acuerdos de confidencialidad etc.) que aplicamos a los datos reales
