Con nuestro template para crear tu guía de seguridad, acabarás rápidamente la actividad y con altas probabilidades de cumplir el requisito.
Esta guía cuenta con un checklist que nos ayudará a verificar rápidamente el cumplimiento de seguridad en todos tus sistemas, con lo cual podrás mantenerlos con una configuración adecuada.
Este checklist está enfocado a las revisiones que se deben realizar sobre las herramientas o servicios que soportan un área de TI o Desarrollo. Por lo que te recomendamos que una persona del área correspondiente diseñe e implemente este documento.
Nuestro template cuenta con los lineamientos básicos a revisar, sin embargo, puedes añadir cualquier otro rubro de revisión que consideres pertinente para complementar mejor su aplicación dentro de tu empresa.
El documento cuenta con seis secciones:
Objetivo
Alcance
Vigencia
Responsabilidades
Guía de seguridad en el desarrollo y mantenimiento de sistemas
Versionado
A continuación te explicamos cada una de estas secciones, cómo llenar el documento y los pasos a seguir.
Objetivo
En esta primera sección debes definir los objetivos generales que debe cumplir la creación de este documento.
Un objetivo puede ser, por ejemplo:
Esta guía tiene el objetivo de apoyar al cumplimiento de seguridad de la información para los sistemas que se compren o desarrollen en la empresa. También nos da las pautas para mantener estos sistemas con una configuración adecuada a lo largo de su ciclo de vida.
El ejemplo anterior también lo puedes encontrar dentro de nuestro template, pero recuerda que puedes complementarlo y/o ajustarlo a las necesidades de tu empresa.
Alcance
En esta sección debes indicar los procesos internos, las áreas funcionales o cualquier otro elemento de tu empresa que será alcanzado o afectado por este documento.
Un alcance puede ser, por ejemplo:
El siguiente documento alcanza a los procesos y controles definidos para el cumplimiento del Sistema de Gestión de la Seguridad de la Información de toda la organización.
El ejemplo anterior también lo puedes encontrar dentro de nuestro template, pero recuerda que puedes complementarlo y/o ajustarlo a las necesidades de tu empresa.
Vigencia
En esta parte hay que indicar la fecha en la que entrará en vigor el documento dentro de la empresa. Esto sucederá cuando sea aprobado y comunicado formalmente a todos los colaboradores que se requiera.
Se recomienda que la duración de la vigencia no exceda un año. Ya que revisar, mantener e incluso mejorar nuestra documentación es un requisito de seguridad muy importante.
Responsabilidades
En esta sección debemos indicar las personas o áreas responsables de validar la correcta aplicación y mantenimiento de los rubros indicados en el checklist.
Las responsabilidades se pueden asignar, por ejemplo, de la siguiente forma:
El encargado del proyecto y/o desarrollo es el responsable de contemplar los rubros aquí descritos para la gestión del mismo.
El ejemplo anterior también lo puedes encontrar dentro de nuestro template, pero recuerda que puedes complementarlo y/o ajustarlo a las necesidades de tu empresa.
Guía de seguridad en el desarrollo y mantenimiento de sistemas
Esta guía o checklist que te sugiere nuestro template se compone de cuatro columnas:
CATEGORÍAS
Las categorías son los temas que serán evaluados dentro del checklist, los cuales son los siguientes:
Conectividad y Seguridad Lógica
Se refiere a parámetros técnicos que pueden aplicarse a nivel de red o seguridad en una infraestructura lógica.Arquitectura
Contempla rubros sobre cómo debemos implementar un determinado servicio o aplicación.Controles de Accesos y Seguridad
Esta categoría valida la seguridad en el sistema operativo, bases de datos y aplicaciones.Proveedores
Indica los requisitos mínimos de seguridad para contemplar en la gestión o relación con proveedores de servicios.Recurso Humano
Esta categoría evalúa que se cuente con el personal calificado para operar el servicio o aplicación.Gestión Monitoreo
Esta categoría verifica que el servicio o aplicación genere y resguarde bitácora de eventos.
HW
En esta columna se indica si el requisito de la categoría aplica para hardware.
SW
En esta columna se indica si el requisito de la categoría aplica para software.
¿Cumple?
En esta columna debemos indicar la aplicabilidad o estatus del requisito evaluado, con respecto a la gestión del proyecto relacionado.
Para completar esta columna tenemos las siguientes opciones:
Cumple:
Cuando el requisito ya está implementado y funcionando correctamente dentro del servicio o desarrollo correspondiente.
No cumple:
Cuando el requisito no está implementado dentro del servicio o desarrollo correspondiente.
Cumple parcial:
Cuando el requisito está implementado pero quizá no funciona correctamente, o bien está en proceso de implementación para el servicio o desarrollo.
No aplica:
Cuando el requisito no forma parte del servicio o desarrollo por la naturaleza del mismo.
A continuación te mostramos un ejemplo de cómo llenar el checklist para la categoría de Conectividad y Seguridad Lógica, considerando un proyecto de un sistema de gestión de tickets que fue desarrollado in-house.
Nota: Un desarrollo in-house, se refiere al desarrollo interno; es decir, cuando la empresa desarrolla sus propios sistemas, con sus programadores y analistas.
La solución para nuestro ejemplo estará basada en un portal web, a la cual puedes acceder desde internet o la intranet organizacional.
Con base en la imagen anterior de un checklist, el cual fue llenado con información de ejemplo, concluimos lo siguiente:
2 validaciones no cumplen, las cuales son las siguientes:
Portal web expuesto a internet protegido con solución WAF, la cual aplica para software.
Los elementos protegidos por solución de firewall, la cual aplica para hardware.
Esto nos dice que estos requisitos no se encuentran aplicados en la solución evaluada y se tendrá que dar seguimiento hasta su implementación para actualizar su cumplimiento dentro del checklist.
1 validación cumple parcialmente, la cual es la siguiente:
Elementos protegidos por solución de IPS, la cual aplica para hardware.
Esto podría indicar por ejemplo, que actualmente la solución de IPS no está aplicada en el sistema evaluado dentro del proyecto y que sí se debería complementar.
1 validación no aplica, la cual es la siguiente:
Elementos protegidos por solución AntiDDoS, la cual aplica para hardware.
Esto quiere decir que la solución de AntiDDoS no aplica para el sistema que se está evaluando.
3 validaciones cumplen, las cuales son las siguientes:
Elementos protegidos por solución antivirus
Elementos protegidos por solución antimalware
Segmentación de red - VLAN, las cuales aplican todas para hardware.
Esto nos dice que la solución evaluada ya cuenta con antivirus, antimalware y segmentación de redes.
Otros ejemplos donde podemos aplicar este checklist son:
Al comprar o rentar una herramienta para gestionar logs, una para gestionar respaldos, una para gestión de tickets, etcétera.
Al estar creando un nuevo servicio o producto que posteriormente vamos a vender.
Versionado
La última parte de nuestro template es una de las partes más importantes de cualquier documento.
El versionado te permitirá identificar a las personas responsables de la elaboración, revisión y aprobación del documento.
Al versionar un documento puedes saber si está vigente, si cuenta con versiones obsoletas y tener registro de los cambios que ha sufrido.
Nuestro template te pide identificar los siguientes puntos:
Elaborado por:
Se recomienda indicar el nombre y rol de la persona responsable de la creación del documento.
Código de documento:
No existe una regla para generar códigos de documentos. Lo único que tienes que tener en cuenta es que debe ayudar a identificarlos fácilmente.
Sugerimos hacer una combinación de varios elementos, como puede ser el nombre de la empresa, el número de documento, una abreviatura de política (POL) o procedimiento (PRO), el número de versión (v1, v2, v3), etcétera.
Algunos ejemplos pueden ser: DM-001A, SGSI-V1-DM, POL-SGSI-V1.
Versión:
Al crear este descriptivo por primera vez, tendremos la versión 1 del documento (lo cuál se puede indicar cómo v1). Por lo tanto, al actualizar este documento, su versión cambiará.
Las modificaciones que le sigan se pueden indicar cómo v2, v3, v4, y así sucesivamente.
Fecha última de actualización:
Se debe actualizar esta fecha cada que se realice algún cambio al documento o se renueve su vigencia.
Revisado por:
Se recomienda indicar el nombre y rol de la persona responsable de la revisión del documento.
Aprobado por:
Se recomienda indicar el nombre y rol de la persona responsable de la aprobación del documento.
Hackmetrix insight:
Las personas involucradas en la elaboración, revisión y aprobación del documento no deben ser las mismas.
Esto porque, además de que te permite tener varios niveles de validación a tu documentación, te ayuda a cumplir y mantener la segregación de funciones dentro de tu empresa.
Cuando termines la tabla de versionado, debería verse algo así:
Recuerda que:
Debes llevar un buen control de las categorías y requisitos de la guía.
Es de suma importancia que lo que indicamos en la guía como “cumple” se encuentre realmente implementado, ya que no de ser así, podría generar observaciones o no conformidades directas en las auditorías, o bien generar brechas de seguridad al creer que tenemos algo implementado pero no es así.
La guía de seguridad en el desarrollo y mantenimiento de sistemas es un checklist muy sencillo que nos ayuda a cumplir con lo mínimo indispensable en cuestión de seguridad de la información en nuestros servicios o aplicaciones.
¡Califica este artículo con 😃 si ayudó a resolver tus dudas! Recuerda que también puedes contactarnos por nuestro chat de soporte y te brindaremos la atención que necesites.