Download Resumen ISO

Resumen
12.4.
Seguridad de los archives del sistemas
Asegurar la seguridad de los archivos de del sistema.
12.4.1.
Control de software en producción
Debe tenerse un estricto control del software que se instala en un sistema operacional.
Para poder minimizar
observaciones.








estos
riesgos
deberían
considerarse
las
siguientes
La actualización de las librerías de los programas deben realizarse por el
administrador con autorización de la gerencia.
Los sistemas operativos deben tener solo código ejecutable, nada de desarrollo.
La implantación de un código ejecutable debe realizarse en un sistema por
separado.
Es necesario el uso de un sistema de control de configuración para poder tener
un control del software implementado así como la documentación.
Debería existir una estrategia de restauración no actualizada antes de que se
implementen los cambios.
Se debe tener un registro de la auditoria de las actualizaciones a las librerías de
programas.
Se debe retener las versiones anteriores de software como medida para
cualquier contingencia.
Las versiones antiguas deben ser archivadas junto con toda la documentación
que les precede, durante el tiempo en que los datos sean retenidos.
Todo software adquirido debe mantenerse en el nivel de soporte ya que con el tiempo
los proveedores dejaran de suministrar versiones antiguas.
Cualquier decisión de sobre actualización se debe tomar en cuenta los requisitos del
negocio, los parches deberán ser aplicados solo si estos ayuden a remover o minimizar
las vulnerabilidades.
Solo debe darse acceso físico y lógico a los proveedores cuando sea imprescindible
por motivos de soporte, previa autorización de la gerencia. Las actividades realizadas
por los proveedores deberán supervisadas.
12.4.2.
Protección de los datos de prueba del sistema
Los datos de prueba deberán ser escogidos, protegidos y controlados de manera
cuidadosa.
No se recomienda el uso de bases de datos que contengan información personal. Si
esta información se utilizase se debe modificar o remover antes de realizar las
respectivas pruebas. Se recomienda seguir los siguientes controles para proteger los
datos cuando se usen para pruebas.




Los procedimientos de control de acceso usados en sistemas operacionales
también deben usarse en sistemas de prueba.
Se recomienda autorización por separado cada vez que se copie información
operativa a un sistema de prueba.
La información operativa debe ser borrado del sistema prueba una vez que este
termina su aplicación.
Se debe registrar la copia y uso de la información operativa para un seguimiento
de auditoría.
Los sistemas de prueba requieren volúmenes de datos que sean lo más parecidos a los
datos operacionales.
12.4.3.
Control de acceso a los códigos de programas fuente
El acceso a los códigos de programas fuente debe ser restringido o controlado
estrictamente para evitar cambios no intencionales. Se debe tomar en cuenta las
siguientes pautas.







Las librerías de programas fuente no deben residir en el sistema operativo.
El código y librerías de programas fuente deben ser manipulado de acuerdo a
las especificaciones establecidas.
El personal de apoyo informático no debe tener libre acceso a las librerías de
programas fuente.
La actualización de librerías y entrega de programas a los desarrolladores debe
hacerlo solo el responsable con la autorización del gerente de soporte
informático.
Los listados de programas se lo debe tener en un entorno seguro.
Se debe tener un registro de auditoría para todos los accesos a las librerías.
El mantenimiento y copia de librerías debe estar sujeta a procedimientos
estrictos de control de cambios.
12.5.
Seguridad en los procesos de desarrollo y soporte
Mantener la seguridad del software de aplicación y la información.
12.5.1.
Procedimientos de control de cambio
La implementación de cambios debe ser controlada usando procedimientos formales
de cambio. Esto comprende la introducción de sistemas nuevos y cambios a los
sistemas existentes, los cuales deben seguir un proceso formal de documentación,
especificación, prueba, control de calidad e implementación.
La aplicación de y sus procedimientos de control de cambios deben estar integrados
siempre que sea posible. Este proceso debe incluir:










El mantenimiento de un registro de los niveles de autorización acordados.
La garantía de que los cambios se realizan por usuarios autorizados.
La revisión de los controles y procedimientos de integridad para asegurarse de
que los cambios no los debiliten.
La identificación del software, información, bases de datos y hardware que
requiera una mejora.
Obtener la aprobación formal antes de empezar un trabajo.
La garantía de aceptación del usuario.
La garantía de actualización de la documentación así como el archivo o
destrucción de la documentación antigua.
El mantenimiento de control de versiones de toda actualización del software.
La garantía del cambio de la documentación operativa.
La garantía de la adecuación del tiempo de la implantación de los cambios para
no dificultar los procesos de negocio.
Las buenas prácticas incluyen la prueba del nuevo software en un ambiente segregado
de los ambientes de producción y desarrollo.
12.5.2.
Revisión técnica de los cambios en el sistema operativo
Se debe revisar y probar las aplicaciones del sistema cuando se efectúan cambios,
para asegurar que no impactan adversamente en el funcionamiento o en la seguridad.



La revisión de los procedimientos de control de aplicación y de integridad para
asegurar que los cambios en el sistema operativo no han sido comprometidos.
La garantía de que los fondos anuales cubran las revisiones y las pruebas del
sistema que requiera los cambios del sistema operativo.
La garantía de que los cambios del sistema operativo se realicen a tiempo para
realizar revisiones antes de su implantación.

La garantía de que los cambios sean apropiados para la continuidad del
negocio.
12.5.3.
Restricciones en los cambios a los paquetes de software
No se recomienda modificaciones a los paquetes de software. Deben limitarse a
cambios necesarios que sean controlados estrictamente.
Cuando haya necesidad de modificarlos se debe incluir estos aspectos.




El riesgo de debilitamiento de las medidas de control, incorporados y sus
procesos de integridad.
La obtención del consentimiento del vendedor.
La posibilidad de obtener los cambios requeridos como actualización normales
por parte del vendedor.
El impacto obtenido como resultado de la adquisición de la responsabilidad del
mantenimiento futuro del software como resultado de los cambios.
12.5.4.
Fuga de Información
Las fugas de información deben ser prevenidas, para este propósito se debe tomar en
cuenta los siguientes aspectos.





Escaneo de medios de salida y comunicaciones para información oculta.
Sistema de modulación y enmascarado.
Haciendo uso de sistemas y software que se considera de lata integridad.
Monitoreo regular de las actividades del personal y del sistema.
Monitoreo del uso de recursos en sistemas de cómputo.
12.5.5.
Desarrollo externo del software
El desarrollo de externo del software debe ser supervisado y monitoreado por la
organización.






Acuerdos bajo licencia, propiedad de datos y derechos de propiedad intelectual.
Certificación de calidad y exactitud del trabajo realizado.
Acuerdos para hacerse cargo en el caso de fallo de terceros.
Derechos de acceso para auditar la calidad y exactitud del trabajo realizado.
Requisitos contractuales sobre la calidad y funcionalidad segura del código.
Pruebas preliminares antes de la implantación para detectar código malicioso.
12.6.
Gestión de la vulnerabilidad técnica
Reducir los riesgos resultantes de la explotación de las vulnerabilidades técnicas
publicadas.
12.6.1.
Control de las vulnerabilidades técnicas
Se debe obtener a tiempo a tiempo la información sobre las vulnerabilidades técnicas
de los sistemas de información utilizadas. Para poder adoptar las medidas necesarias
para tratar con estos riesgos.
Es necesario tener un inventario actual y completo de activos como prerrequisito para
una efectiva gestión de vulnerabilidades. Las siguientes pautas deben ser tomadas en
cuenta para establecer un proceso de gestión de vulnerabilidades técnicas efectivas.









La organización debe definir roles y responsabilidades como el monitoreo de
vulnerabilidades, la evaluación de la vulnerabilidad de riesgo, el parchado y
cualquier otra responsabilidad.
Los recursos informáticos que se utilizan para identificar las vulnerabilidades y
mantener precaución ante ellos de deben identificar para el software y otras
tecnologías. Este recurso debe actualizarse basado en cambios en el inventario
o cuando se encuentre un mejor recurso.
Se debe definir una línea de tiempo para reaccionar ante notificaciones de
vulnerabilidad.
Una vez identificados las vulnerabilidades, la organización debe identificar los
riesgos y las acciones que se llevaran a cabo.
Dependiendo en que tan urgente sea tratar con una vulnerabilidad la acción a
tomarse debe ser llevada de acuerdo a controles de gestión de cambios o
siguiendo los procedimientos de respuesta ante incidentes en la seguridad de
información.
Si un parche esta disponible se debe tomar en cuanto los riesgos de instalación.
Los parches deben ser probados y evaluados antes de su instalación con el fin
de verificar su funcionamiento, y no se convierta en efectos secundarios.
Un registro de ingreso debe ser mantenido para todos los procedimientos
comprendidos.
Se debe evaluar y monitorear la gestión de procesos en la vulnerabilidad
técnica.
La gestión de vulnerabilidad técnica puede ser vista como una sub-función de la
gestión de cambios. Si no es posible una prueba de los parches se puede considerar
una demora en el parchado para evaluar los riesgos asociados, basándonos en la
experiencia de otros usuarios.
13. Gestión de incidentes en la seguridad de información
13.1.
Reportando eventos y debilidades de la seguridad de información
Asegurar que los eventos y debilidades en la seguridad de información asociados con
los sistemas de información sean comunicados de una manera que permita que se
realice una acción correctiva a tiempo.
13.1.1.
Reportando los eventos en la seguridad de información
Un procedimiento de reporte de eventos debe ser establecido junto con una respuesta
a incidencias y procedimientos.
Todos los empleados deben estar conscientes de sus responsabilidades de reportar
cualquier evento en la seguridad de información lo más rápido posible. Los
procedimientos de reporte deben incluir los aspectos a continuación.




Procesos de retroalimentación para asegurar que dichos eventos reportados
sean notificados de los resultados después de que el tema haya sido cerrado.
Formularios de reportes en la seguridad de información con el fin de apoyar la
acción de reporte y ayudar a la persona a recordar las acciones necesarias en
caso de un evento.
El comportamiento correcto a se emprendido en caso de un evento en la
seguridad de información. Como notar los detalles importantes y no llevar a cabo
ninguna acción por cuenta de uno mismo.
Referencias a un proceso formal disciplinario establecido para tratar con
empleados, o terceros que cometan una abertura en la seguridad.
Algunos ejemplos de eventos e incidentes en la seguridad son




Perdida de servicio, equipo o instalaciones.
Aberturas en los arreglos de seguridad física.
Cambios incontrolables en el sistema
Mal funcionamiento de software o hardware.
13.1.2.
Reportando debilidades en la seguridad de información
Todos los empleados, contratistas y terceros que son usuarios de los sistemas y
servicios de información deben anotar y reportar cualquier debilidad observada o
sospechada en la seguridad de estos.
Todos los empleados, contratistas y terceros deben reportar estas materias a sus
gerencias o directamente al proveedor del servicio lo más pronto posible con el fin de
prevenir los incidentes en la seguridad de información. Deben ser informados que por
ninguna circunstancia deben tratar de probar una debilidad sospechosa. Probar las
debilidades puede ser interpretado como un potencial mal uso del sistema y puede
ocasionar daño al sistema o servicio de información y resultar en responsabilidad legal
para el individuo que realiza la prueba.