Politica y Seguridad de Proyecto
Politica y Seguridad de Proyecto
Politica y Seguridad de Proyecto
1
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
Contenido
1 Objetivo....................................................................................................................................... 3
2 Alcance ....................................................................................................................................... 3
3 Definiciones .............................................................................................................................. 3
4 Directrices................................................................................................................................... 4
4.1 Seguridad en los procesos de desarrollo y soporte ......................................................... 4
4.2 Política de Desarrollo seguro ............................................................................................. 4
4.3 Procedimientos de control de cambios en sistemas ......................................................... 15
4.4 Revisión técnica de las aplicaciones después de cambios en la plataforma de
operación...................................................................................................................................... 16
4.5 Restricciones en los cambios a los paquetes de software ............................................... 17
4.6 Principios de construcción de los sistemas seguros ......................................................... 19
4.7 Ambiente de desarrollo seguro ........................................................................................ 21
4.8 Desarrollo contratado externamente ................................................................................... 23
4.9 Pruebas de seguridad de sistemas ................................................................................. 25
4.10 Pruebas de aceptación de sistemas ............................................................................ 26
Definir y ejecutar las pruebas de aceptación de software a partir de los siguientes
elementos: .................................................................................................................................... 26
4.10.1 Gestión de vulnerabilidades .................................................................................. 27
4.11 Protección de datos de prueba .................................................................................... 28
5. Información de contacto.......................................................................................................... 30
6. Revisión de la guía .................................................................................................................. 30
7. Referentes ................................................................................................................................ 30
7.1 Referentes Normativos ..................................................................................................... 30
7.1.1 Referentes de política nacional ............................................................................. 30
7.1.2 Referentes de políticas del MEN........................................................................... 30
2
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
1 Objetivo
Asegurar que la seguridad digital esté diseñada y sea implementada en el ciclo de vida planeación y
desarrollo de los sistemas de información del MEN.
2 Alcance
Esta guía política aplica para todos los desarrollos de sistemas de información nuevos y mejoras a los
existentes en el MEN.
3 Definiciones
3
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
4 Directrices
4.1 Seguridad en los procesos de desarrollo y soporte
Objetivo:
Asegurar que la seguridad digital esté diseñada y sea implementada en el ciclo de vida planeación y desarrollo de los sistemas de información del MEN.
Manual de Seguridad
Se deben establecer y aplicar reglas para el desarrollo de
Digital y Guías de
En esta fase se deben considerar los siguientes aspectos: Política.
Oficina de tecnología
y sistemas de
Definir el alcance Protocolo de ciclo de
información
Especificar los atributos de calidad en seguridad que debe cumplir la arquitectura, vida del software.
Operador TI
así como las métricas a utilizar y los rangos de valores aceptables para el MEN.
(Aplicaciones,
Especificar la estructura y los requerimientos Documentación de
Fábrica de software,
la organización.
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
información que tiene el MEN.
4. Tipos de registro que el sistema debe generar, acceso a los recursos, niveles de
privilegios, perfiles de usuario. Los tipos de acceso a los datos deben ser
estructurados de acuerdo con los perfiles definidos, lectura, escritura, modificación
y eliminación.
5. Definir cómo será el modo de autenticación al ingreso al aplicativo, por ejemplo,
usuario y contraseñas, tokens, entre otros.
6. En esta etapa es necesario identificar los riesgos del proyecto entre los cuales se
deben contemplar, entre otros, los siguientes:
5
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
Baja disponibilidad por parte de los líderes del proyecto.
7. También se deben definir las acciones correctivas y/o preventivas que se tendrán
en el proyecto, tales como:
6
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
proyecto.
1.2 Validar el cumplimiento de los requisitos definidos en la Fase I Planificación - Listas de chequeo de
Análisis – Diseño de Sistemas en el MEN. Oficina de tecnología verificación de las
y sistemas de fases del desarrollo y
Validar el cumplimiento de los requisitos mediante la aplicación de la Lista chequeo Fase información mantenimiento de
I Planificación - Análisis – Diseño de sistemas seguros en el MEN. software.
2.1 Requisitos de Seguridad para la Fase II
2.1.1 En desarrollo
7
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o Autentificar adecuadamente: La información confidencial y los sistemas informáticos
sólo deben ser accesibles por las personas con los roles y permisos definidos en la
fase I.
o No utilizar campos ocultos para almacenar información sensible, porque esto
permitiría que se exponga datos e información del funcionamiento interno de los
aplicativos, permitiendo que sean manipulados
o En caso de que se requiera hacer uso de campos ocultos, debe justificarse por qué
es la única alternativa técnica posible, y se debe garantizar que la información
almacenada en ellos no sea confidencial o sensible; si esto no es posible, se deben
utilizar mecanismos de cifrado con el fin de que se garantice su integridad y
confidencialidad.
o Comprobar las entradas: Es necesario que se verifique y controle los datos que son
introducidos en los aplicativos, estos deben estar dentro del rango de valores válidos
para el tipo de dato, es decir si son de tipo numérico que lo sean y que no sobrepasen
la longitud determinada, sobre todo en los que son tipo cadena.
o Valores límite de salida: Aquí se debe controlar la salida de los métodos, que el dato
resultante de una operación esté dentro de los parámetros definidos antes de
asignarlo.
o Formato de salida: Los formatos de salida no deben ser cambiados por funciones
debido a que estos pueden ocasionar errores asociados con el manejo del buffer.
o Validar los argumentos que se pasan a un componente en otro ámbito de control con
el fin de que no se introduzcan argumentos alternativos, utilizando la misma
codificación de caracteres, validando los datos resultantes de una combinación de Operador TI
datos de diferentes fuentes, ya que los datos individuales pueden haber pasado la (Aplicaciones,
validación, pero violar las restricciones una vez hayan sido combinados Fabrica de software,
o Asegurar que los métodos que llevan a cabo controles de seguridad sean declarados Seguridad)
como privados o finales, prohibiendo la extensión de los mismos ya que las clases
no finales pueden verse comprometidas si una subclase maliciosa reemplaza los
métodos y omite las comprobaciones.
8
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o Proteger la información que se muestra sobre los procesos activos ya que muchos
sistemas operativos permiten a un usuario observar la información de procesos que
pertenecen a otros usuarios. Esta información puede incluir argumentos de línea de
comandos o la configuración de la variable de entorno, lo que puede provocar un
ataque contra el software por parte de otros usuarios si entre esos datos se incluye
información confidencial.
o Evitar el uso de datos reales de carácter personal en las pruebas anteriores a la
implantación o modificación de un sistema, salvo que se garantice el nivel de
seguridad correspondiente al tipo de información tratada.
o Evitar que el usuario tenga acceso a alguna referencia directa a un objeto de la
aplicación, como un archivo, directorio, base de datos, o clave, como un parámetro
del URL o dentro de un formulario, es decir se debe utilizar mapas de referencias
indirectas para referencias objetos del servidor, empleando contraseñas que
garanticen que el usuario que intenta acceder al recurso dispone de los permisos
suficientes, así como evitar la publicación directa de recursos a través del acceso
directo mediante una URL que pueda ser predicha.
o Evitar generar código a partir de valores ingresados por el usuario.
o Utilizar Stored Procedures en lugar de sentencias SQL dinámicas.
o Controlar que los datos de salida sean adecuados, es decir, que cumplan con lo
solicitado en los requerimientos, como por ejemplo que el valor obtenido se
encuentre dentro de los parámetros definidos. Si esta acción no se tiene en cuenta
puede hacer que la funcionalidad desarrollada falle o regrese un resultado que no
corresponda, así como permitiendo que el aplicativo no realice las acciones
requeridas.
9
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o Emplear nombres descriptivos, en la declaración de variables, es decir, que hagan
alusión a su nombre y no a su tipo.
o Evitar el uso de variables Globales, dado que se puede acceder a estas variables
por terceras funciones ya sea por malicia o por infortunio asignando un valor no
deseado, este tipo de variables puede ser accedido por muchas funciones durante
la ejecución del programa, siendo muy difícil de detectar las fallas que genera.
o Inicializar siempre las variables.
o La aplicación deberá generar y almacenar un log de auditoria sobre las tablas y
transacciones críticas, que permita consultar como mínimo: ID de usuario, fecha,
hora, nombre de la máquina donde ejecutó la aplicación, dirección IP, MAC, tabla
modificada, acción ejecutada (creación, modificación, borrado). Si el volumen de
datos y la carga transaccional de la aplicación no es muy elevada es aconsejable
registrar los valores anteriores y actuales.
o Los comentarios que contenga el código fuente deben ir enfocados a describir la
funcionalidad que se está programando, en los bloques de código extenso es
recomendable dividirlos e introducir un comentario al principio con el fin de guiar al
desarrollador, sería óptimo que exista una línea blanca de separación, estos
comentarios no deben ser excesivos, es decir describiendo lo obvio.
o Reutilización de Código Fuente: En lo posible se recomienda la reutilización de
código fuente cuya calidad haya sido verificada, ya que la no reutilización de código
induce a errores cada vez que se desarrolla un nuevo componente de la solución.
En caso de requerir funciones de seguridad específicas es recomendable hacer uso
de librerías y/o piezas de código ya construidas para tal fin, con el fin de aprovechar
la experiencia de los desarrolladores especializados en estas áreas.
o No excederse con el número de niveles en las instrucciones anidadas.
o No mezclar datos con código.
o Evitar usar métodos con muchos parámetros, en caso de que sea necesario es
recomendable contemplar la creación de una clase que contenga las propiedades
requeridas.
10
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o No hacer comparaciones explícitas con expresiones booleanas con true o false, es
mejor asignar la condición a una variable y utilizar la variable en las comparaciones,
nombre las variables de forma afirmativa.
o Se deben validar todos los parámetros de las interfaces de programación de
aplicaciones (API) exportadas, verificando que sean válidos, esto incluye los datos
que parecen ser coherentes pero que están más allá del intervalo de valores
aceptado, como los tamaños de búfer excesivos. No utilice aserciones para
comprobar los parámetros de las API exportadas, porque las aserciones se quitarán
en la versión de lanzamiento.
o Se debe considerar emplear las API criptográficas desarrolladas por firmas
reconocidas (IBM, Microsoft, entre otros.) o por la académica, en lugar de escribir a
su propio software criptográfico, con ello los desarrolladores podrán concentrarse en
la generación de aplicaciones.
o Cuando una funcionalidad se requiera implementar en diferentes aplicaciones se
recomienda crear una función, una rutina, un servicio o un componente que sea
reutilizable para cualquier aplicación.
o Todas las comunicaciones deben ser seguras.
2.1.3 En Verificación de Cumplimiento de Especificaciones del Sistema
o Las pruebas iniciales se deben realizar a partir de los requerimientos y los atributos Documentación de
Oficina de tecnología
ded calidad definidos y aprobados. El alcance de estas pruebas es validar que el los proyectos de
y sistemas de
sistema cumple con los atributos de calidad, el funcionamiento esperado y los sistemas de
información
requisitos de seguridad de acceso al sistema, a los datos y procesos definidos, así información.
como a los distintos recursos del sistema.
o Las pruebas funcionales deben ser coherentes con las funcionalidades solicitadas y
deben buscar descartar errores que se presenten al utilizar el aplicativo o el módulo
desarrollado.
11
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o En caso de que el requerimiento provenga de un mantenimiento es necesario
verificar todas las funcionalidades del sistema que se puedan afectar por la
integración de la nueva funcionalidad o la solución del problema que dio origen al
mantenimiento.
o También es necesario probar el control de acceso al aplicativo, con el fin de valorar
que únicamente accedan los usuarios autorizados y sólo a los módulos definidos de
acuerdo con su rol.
o Las pruebas de seguridad funcional se deben basar en los requerimientos definidos
con respecto a:
o Al preparar los datos para pruebas, estos preferiblemente no deben ser reales; sin
embargo, teniendo en cuenta que para algunas pruebas puede ser una tarea
compleja la preparación manual de datos y que puede ser ineficiente debido a la
integridad referencial que deben mantener las relaciones de los registros y llegase a
ser necesario emplear información real para las pruebas, esta información debe ser
anonimizada, con el fin de preservar la confidencialidad de la información empleada.
o Adicionalmente a los datos de prueba, sean creados o los reales anonimizados, se
deben realizar pruebas utilizando variaciones no válidas de éstos en los diferentes
módulos de la aplicación en donde se solicite datos, es decir, con diferente signo,
tipo, longitud, fuera del rango solicitado, caracteres especiales, valores nulos y/o
12
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
aleatorios. Esto con el fin de garantizar que la aplicación es robusta y responde
apropiadamente a datos inválidos.
o Es necesario realizar pruebas de rendimiento de software, estructurando escenarios
que sometan la aplicación a su máximo rendimiento y consumo de recursos para
verificar que se cumplen con los atributos de calidad apropiados.
o Para las pruebas que se realicen a los aplicativos Misionales del MEN, deben ser
realizadas por una persona diferente al desarrollador que implementó el
requerimiento.
o Aunque el proyecto haya tenido que ajustar y actualizar su cronograma por
ampliación o reducción de tiempo, nunca se debe recortar el tiempo destinado para
las pruebas. Se debe asegurar siempre que el proyecto que se entregue esté libre
de errores, y, si se recorta el tiempo en pruebas, pueden presentarse muchos más
errores de los habituales.
o No se debe publicar ningún aplicativo sin la debida aprobación de acuerdo con los
procedimientos establecidos.
2.1.4 Validar el cumplimiento de los requisitos definidos en la Fase II Desarrollo –
Verificación de Cumplimiento de Especificaciones del Sistema- Verificar Software
Seguro- Realizar la publicación del Software en ambiente de preproducción y Listas de chequeo de
gestionar aprobación del área funcional. Oficina de tecnología verificación de las
y sistemas de fases del desarrollo y
Validar el cumplimiento de los requisitos mediante la aplicación de la Lista chequeo Fase información mantenimiento de
II Desarrollo – Verificación de Cumplimiento de Especificaciones del Sistema- Verificar software.
Software Seguro- Publicar el Software en el ambiente de preproducción y gestionar
aprobación del área funcional en el MEN.
3. Fase III - Sensibilizar el uso del sistema de información, Realizar la puesta en
Documentación de
producción del Sistema de Información o Mantenimiento de Software, Realizar el Oficina de tecnología
los proyectos de
mantenimiento de software o atención a incidencias del sistema de información. y sistemas de
sistemas de
información
información.
En esta fase se contemplarán:
13
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
implementación la confidencialidad, integridad y disponibilidad que afecten o
modifiquen estos requerimientos.
15
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
Los cambios a los sistemas dentro del ciclo de vida de desarrollo se deben
tienen definidos en el MEN, para asegurar la integridad del sistema, las aplicaciones y
los productos, desde las primeras etapas de diseño a través de todos los esfuerzos de
mantenimiento posteriores. Este proceso debe incluir:
Comités CAB y ECAB
Una valoración de riesgos de seguridad digital.
Análisis de los impactos de los cambios y la especificación de los controles de
seguridad.
El uso de un sistema de gestión de versiones, que permita recuperar versiones
especificas cuando se requiera.
cambios.
Oficina de tecnología
y sistemas de Procedimiento de
información Gestión de Cambios
Propender por el cumplimiento del Procedimiento de gestión de cambios ST-PR-12 y el
ST-PR-12
Instructivo Lineamientos Gestión de cambios ST-IN-03 definidos en el MEN para
asegurar la integridad del sistema, las aplicaciones y los productos, desde las primeras
Instructivo
etapas de diseño a través de todos los esfuerzos de mantenimiento posteriores.
Lineamientos Gestión
de cambios ST-IN-03
Exigir que en los nuevos sistemas y cambios importantes a los sistemas existentes se
ejecute un proceso formal de documentación, especificación, pruebas, control de calidad
y gestión de la implementación.
16
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
y sistemas de
Lineamientos Gestión
o Revisar los procedimientos de integridad y control de aplicaciones para información
de cambios ST-IN-03
asegurar que no estén comprometidos debido a los cambios en las Operador de
plataformas de operaciones. servicios TI
ST-PT-01 Protocolo
(Aplicaciones,
o Garantizar que la notificación de los cambios en la plataforma operativa de Paso a Producción
Infraestructura,
se hace a tiempo para permitir las pruebas y revisiones apropiadas antes para la Entrega en
Seguridad)
de la implementación. Productivo de Nuevas
o Garantizar que se hacen cambios apropiados en los planes de Soluciones
continuidad del negocio. Tecnológicas.
o Garantizar que los cambios realizados en sistemas de información se
revisan escaneando vulnerabilidades y mitigándolas.
Controlar las modificaciones al software del MEN, las cuales se deben limitar a los
todos los cambios se
Procedimiento de
Se deben desalentar
las modificaciones a
cambios necesarios.
los paquetes de
deben controlar
Gestión de Cambios
estrictamente.
17
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o El riesgo de que los procesos de integridad y los controles incluidos se vean
comprometidos;
o Tener el consentimiento del proveedor (vendedor).
o Obtener del proveedor (vendedor) los cambios requeridos, a medida que se
actualiza el programa estándar;
o El impacto, si el MEN llega a ser responsable del mantenimiento futuro del
software como resultado de los cambios;
o La compatibilidad con otro software en uso en el MEN.
Plan de
Implementar un plan de gestión de actualizaciones de software para asegurar que
actualizaciones
se instalen las actualizaciones de aplicaciones y de parches aprobados más
Contrato con el
recientes para todo el software autorizado.
operador de TI.
Procedimiento de
Gestión de Cambios
Exigir que todos los cambios se prueben y documenten completamente, de manera
ST-PR-12
que se puedan aplicar nuevamente, si es necesario, a futuras actualizaciones de
Instructivo
software.
Lineamientos Gestión
de cambios ST-IN-03
Procedimiento de
Gestión de Cambios
ST-PR-12
Instructivo
Requerir en todos los cambios el escaneo de vulnerabilidad y el plan para la Lineamientos Gestión
mitigación de estas. de cambios ST-IN-03
Escaneo de
vulnerabilidades y
plan de mitigación.
18
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
19
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o Nunca confiar en los datos que ingresan a la aplicación, todo dato debe ser
verificado para garantizar que lo que está ingresando a los sistemas es lo
esperado y además evitar ataques por inyección de código.
o Cualquier funcionalidad, campo, botón o menú nuevo debe agregarse de acuerdo
con los requerimientos de diseño. De esta forma se evita tener porciones de
código que resultan siendo innecesarias.
o Cualquier cambio que se haga debe quedar documentado, esto facilitará
modificaciones futuras.
o Como parte de las actividades del ciclo de vida del desarrollo SDL se deben tomar
como referencias prácticas reconocidas de desarrollo seguro, por ejemplo:
Microsoft SDL, OWASP, SANS CWE Top 25, CERT Secure Coding, entre otras. El
desarrollo de software debe estar alineado con los requerimientos de seguridad
establecidos contractualmente, por normativas o regulaciones aplicables al MEN.
o Para intercambiar información sensible, se deben utilizar protocolos seguros para
cifrar las comunicaciones. En el caso de almacenamiento la información
confidencial debería estar cifrada utilizando algoritmos fuertes y claves robustas.
o Los principios y los procedimientos de construcción establecidos se deben revisar
con regularidad para asegurar que están contribuyendo efectivamente a mejorar
los estándares de seguridad dentro del proceso de construcción de software en el
MEN.
o Haber pasado por un proceso completo de pruebas (técnicas, funcionales,
seguridad, etc.) y certificación los sistemas de información del MEN, antes de ser
liberados a producción en un ambiente dedicado para tal fin.
20
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o Controlar para que todos los usuarios de la aplicación y el software que se
ejecuten en el servidor (base de datos, sftp, apache, iis, jboss, tomcat, etc.)
tengan los mínimos privilegios sobre el sistema.
o Garantizar que no se permita la transferencia de archivos con configuraciones
del sistema a los usuarios.
o Controlar si la aplicación requiere que el usuario adjunte archivos, verificar que
solo este permitido el envío de documentos con extensiones específicas, por
ejemplo: doc, docx, pdf. No permitir que el usuario adjunte archivos con
extensiones asp, txt, php, jsp, exe, etc.
o Validar los archivos enviados al servidor por el usuario en la estructura de su
cabecera, ya que la extensión puede ser falsificada por este.
o Controlar para que los archivos que son enviados por el usuario no sean
almacenados en el mismo entorno de trabajo de la aplicación, se recomienda
guardarlos en un dispositivo aislado.
o Controlar y de ser posible solo permitir el cargue de archivos .pdf a los sistemas
de información y, en la medida de lo posible, no deben incluir scripts.
o Controlar para que los archivos transferidos al servidor por el usuario no se
almacenen con permisos de ejecución, sólo de lectura.
o No utilizar rutas especificas en los parámetros o variables, se recomienda,
utilizar índices que internamente se asocien a directorios o rutas predefinidas.
o utilizar protocolos seguros, tales como SSH, SFTP, FTPS, VPN SSL, IP SEC,
etc. Para la comunicación y transferencia de archivos.
o Todos los sistemas que implementen Web Services dentro de su
funcionamiento, deben contar con mecanismos de seguridad adecuados. Se
deben tener en cuenta los siguientes aspectos, sin limitarse a:
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
Informe de
supervisión a los
actividad de desarrollo de
y hacer seguimiento de la
sistemas contratados
Supervisar y hacer seguimiento de la actividad de desarrollo de sistemas contratados contratos con los
externamente por el MEN. proveedores de
externamente
23
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
o Los requisitos contractuales para prácticas seguras de diseño, codificación y
pruebas.
o El suministro del modelo de amenaza aprobado al desarrollador externo.
o Las pruebas de aceptación para determinar la calidad y exactitud de los
entregables.
o La entrega de evidencias de que se usaron umbrales de seguridad para
establecer niveles mínimos aceptables de calidad de la seguridad y de la
privacidad.
o La entrega de evidencias de que se han hecho pruebas suficientes para
garantizar que el sistema está protegido contra contenido malicioso intencional
y no intencional en el momento de la entrega.
o La entrega de evidencias de que se han hecho pruebas suficientes para
garantizar que el sistema está protegido contra la presencia de vulnerabilidades
conocidas.
o Derecho contractual con relación a procesos y controles de desarrollo de
auditorías.
o Documentación eficaz del ambiente de construcción usado para crear los
entregables.
o Aceptar las políticas y procedimientos que se encuentran dentro de este
documento.
o Cumplir con el procedimiento del protocolo de paso a producción.
ST-PT-01 Protocolo
de Paso a Producción
Realizar para todos los sistemas desarrollados, un proceso de verificación de código
para la Entrega en
antes de su salida a producción, incluyendo aquellas librerías de terceros que son
Productivo de Nuevas
incluidas en el desarrollo (DLL).
Soluciones
Tecnológicas.
24
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
Establecer programas de prueba para aceptación y criterios de aceptación
Programas de
relacionados para los sistemas de información nuevos, actualizaciones y nuevas
prueba.
versiones.
seguridad:
o Las revisiones de código pueden ser realizadas por terceros contratados para
tal efecto, o por personal interno capacitado para hacerlo con el fin de asegurar
de funcionalidad de la seguridad.
ST-PT-01 Protocolo
la idoneidad de quien realiza dicha actividad. de Paso a Producción
o Puede realizarse a través de herramientas automáticas o mediante técnicas para la Entrega en
manuales. Productivo de Nuevas
o Los cambios en el código fuente deben ser revisados por personas diferentes Oficina de tecnología Soluciones
al autor de este, con conocimiento en técnicas de verificación de código y y sistemas de Tecnológicas.
desarrollo seguro. información
o Las revisiones de código deben estar orientadas a verificar que la codificación Pruebas de
cumpla con todos los requerimientos expuestos en la presente política. Seguridad
o Las observaciones generadas en la revisión deben ser atendidos antes de la Pruebas de Stres
puesta en producción del sistema.
o Los procesos de revisión deben alinearse a los requerimientos de normativas
y regulaciones aplicables al MEN.
o Una evaluación del riesgo de vulnerabilidades en el código debe realizarse y
valorarse con los interesados en el software creado.
25
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
ST-PT-01 Protocolo
de Paso a Producción
Verificar que los aplicativos cuenten con las últimas versiones estables, tanto a nivel
para la Entrega en
de software como de sistema operativo, parches de seguridad, servidor de
Productivo de Nuevas
aplicaciones, base de datos, máquina virtual de java, etc., antes del despliegue.
Soluciones
Tecnológicas.
ST-PT-01 Protocolo
Realizar por lo menos una revisión del código antes de liberarlo en producción, y poder de Paso a Producción
llevar a cabo las actividades de remediación y seguimiento a estas vulnerabilidades para la Entrega en
antes que salga a producción. En este proceso se deben tener en cuenta las Productivo de Nuevas
vulnerabilidades más importantes en la industria (OWASP Top 10, CWE Top 25, etc.). Soluciones
Tecnológicas.
ST-PT-01 Protocolo
versiones, se deben establecer
criterios de aceptación relacionados para los sistemas de información nuevos, de Paso a Producción
programas de prueba para
aceptación relacionados.
aceptación y criterios de
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
Atributos de calidad.
Reportes de análisis de riesgo.
Requisitos de seguridad de la información.
Incluir en las pruebas de requisitos de seguridad de la información los siguientes
puntos: ST-PT-01 Protocolo
Llevarse a cabo sobre componentes y sistemas integrados. de Paso a Producción
Hacer uso de herramientas automatizadas, tales como herramientas de análisis para la Entrega en
de códigos o escáneres de vulnerabilidad, y verificar que se han corregido los Productivo de Nuevas
defectos relacionados con la seguridad. Soluciones
Realizar una prueba de intrusión, en ambiente productivo definitivo, pero con Tecnológicas.
acceso controlado con el fin de conocer y evaluar las condiciones de seguridad
que rodean el ambiente final con el fin de hacer ajustes finales, el responsable Pruebas de
de esta revisión debe ser una persona diferente al desarrollador (Por ejemplo: Seguridad
revisión por pares). Pruebas de Stres
Realizar pruebas de Ethical Hacking antes de salir a producción. Al identificar Planes de Pentest
una vulnerabilidad técnica en el proceso de desarrollo de un sistema, se debe
identificar el riesgo asociado y el plan de acción para remediarla.
programas de
relacionados.
versiones, se
aceptación y
sistemas de
prueba para
ST-PT-01 Protocolo
información
criterios de
aceptación
s y nuevas
establecer
para cambios entre ambientes para así poder llevar a cabo las actividades de Oficina de tecnología
Para los
nuevos,
deben
de Paso a Producción
remediación y seguimiento a estas vulnerabilidades antes que salga a producción. y sistemas de
para la Entrega en
En este proceso se deben tener en cuenta las vulnerabilidades más importantes información
Productivo de Nuevas
en la industria (OWASP Top 10, CWE Top 25, etc.).
27
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
Operador TIC Soluciones
Seguridad y Tecnológicas.
aplicaciones
Escaneo de
vulnerabilidades y
gestión de la
remediación
Realizar una prueba de intrusión, antes de realizar la puesta en producción o
puesta a disposición de usuario final de un sistema aplicación, en ambiente
productivo definitivo, pero con acceso controlado con el fin de conocer y evaluar Planes de Pentest
las condiciones de seguridad que rodean el ambiente final con el fin de hacer
ajustes finales. El responsable de esta revisión debe ser una persona diferente al
desarrollador (Por ejemplo: revisión por pares).
28
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
SOPORTE A
CONTROL DIRECTRICES ACTORES
DIRECTRICES
propósitos de las pruebas, todos los detalles y contenido sensibles se deben
proteger eliminándolos o modificándolos.
29
GUÍA - POLÍTICA SEGURIDAD EN LOS Código: ST-GU-04
PROCESOS DE DESARROLLO Y DE Versión: 1
Rige a partir de su publicación
SOPORTE en el SIG
5. Información de contacto
Cualquier inquietud relacionada con la Guía - Política seguridad en los procesos de desarrollo
y soporte, favor remitirla al correo seguridaddigital@mineducacion.edu.co.
6. Revisión de la guía
Esta guía debe ser revisada por la OTSI como mínimo una vez al año.
7. Referentes
7.1 Referentes Normativos
Dominio A.14 Adquisición, desarrollo y mantenimiento de sistemas
Control de Cambios
Fecha de
Versión Naturaleza del cambio
vigencia
01 A partir de su Se unificó el manual de seguridad informática y el manual de políticas
publicación en de seguridad de la información y se creó una guía por cada política para
el SIG especificar las directrices, responsables y soportes.
Registro de aprobación
Elaboró Revisó Aprobó
Nombre Luis Carlos Nombre Lina Mercedes Nombre Roger Quirama Garcia
Serrano Durán Martínez
Pinzón
Cargo Contratista de Cargo Profesional Cargo Jefe de la Oficina de
la Especializado - Tecnología y Sistemas de
Oficina de Subdirección de Información
Tecnología y Desarrollo
Sistemas de Organizacional.
Información
30