Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Aclar Llamado A157524 16
Aclar Llamado A157524 16
CSEI-GSEI
GSEI –Seguridad en el Proceso de Desarrollo de Software
24/11/09
Seguridad en el Proceso de
Desarrollo de Software
Versión 0.9
Índice
INTRODUCCIÓN ..................................................................................................................................... 5
OBJETIVO .................................................................................................................................................... 5
ALCANCE..................................................................................................................................................... 5
POLÍTICA ................................................................................................................................................ 7
Desarrollo: ........................................................................................................................................... 8
Testeo:................................................................................................................................................. 8
Producción: ......................................................................................................................................... 8
Cifrado............................................................................................................................................... 11
IMPLANTADOR ........................................................................................................................................... 25
REFERENCIAS ....................................................................................................................................... 28
Introducción
Objetivo
El presente documento tiene por objetivo describir las políticas de seguridad a implementar en
el proceso de desarrollo de software en el B.P.S.
Alcance
Este documento aplica a los sistemas informáticos desarrollados en el B.P.S. o desarrollado por
terceros para el BPS, la infraestructura que utilicen, y las personas que participen del proceso
de desarrollo, tanto explicita como implícitamente.
CDES, ATEC, Metodología y ASIT son las responsables de aprobar este documento.
Consideraciones generales
Desde las primeras etapas del proceso de Ingeniería de Software deben considerarse aspectos
de seguridad. Desde el análisis ya deben identificarse los requisitos de seguridad que luego la
aplicación deberá cumplir.
Deberá tenerse en cuenta que no solamente deben programarse las aplicaciones para que
cumplan con los requisitos de seguridad de la aplicación en sí, sino que además el proceso de
desarrollo deberá cumplir con los requisitos que se proponen en este documento, así como
también con los requisitos incluidos en las Políticas de Seguridad de la Información.
Durante el Análisis deben identificarse los requisitos de seguridad así como su respectiva
validación.
En la etapa de Diseño deberán diseñarse los controles necesarios para satisfacer los requisitos
identificados anteriormente.
El Responsable de Gestión de Seguridad verificará que los controles se apliquen, así como el
cumplimiento de los requisitos de seguridad para las aplicaciones. Verificará además, que el
diseño del sistema adhiera a las Políticas de Seguridad de la Información. Deberá verificar que
se apliquen correctamente los procedimientos de control de cambios que se hayan definido.
Se deberá verificar que los estándares tecnológicos publicados por la ASIT también están
siendo considerados. (esto como forma de comprobar que el sistema será compatible con el
entorno tecnológico de la organización y los objetivos estratégicos de la misma).
Auditoría interna podrá plantear requisitos de seguridad, así como luego deberá verificar que
se implementen los controles que satisfagan todos los requisitos de seguridad.
Política
1.
Debieran considerarse el nivel que se debe cumplir de los tres principios básicos de la
seguridad de la información:
Confidencialidad
Integridad
Disponibilidad
Deberá especificarse el mapeo entre el requisito de seguridad y uno o más controles que
implementen el requisito.
Desarrollo:
Es el ambiente propio de los desarrolladores.
Testeo:
Es el ambiente en el cual se realizan las pruebas de caja negra a las aplicaciones.
Producción:
o Es el ambiente operativo.
Control de Acceso
Todos los sistemas que no sean de libre acceso deberán contar con control de acceso basado
en roles.
La autorización deberá realizarse sobre el mismo sujeto que se autentica o también podrá
requerirse mayor información que permita obtener la autorización con granularidad más fina.
Como ejemplo: se autentica una aplicación, se autoriza a la aplicación junto con el usuario que
la utiliza.
2. Contar con dos usuarios de la base de datos propios de la aplicación. Uno tendrá
derechos de solo lectura y se utilizará para aquellas funciones donde solo se requiera
consulta. Y un segundo usuario con derechos de escritura.
user1@domain
User1
user2@domain Datos
user3@domain
User3
Controles Criptográficos
Se utilizarán sistemas y técnicas criptográficas para la protección de la información en base a
un análisis de riesgo efectuado, con el fin de asegurar una adecuada protección de su
confidencialidad e integridad.
Para ello se indica que se utilizarán controles criptográficos en los siguientes casos:
Cifrado
Mediante la evaluación de riesgos se identificará el nivel requerido de protección, tomando en
cuenta el tipo y la calidad del algoritmo de cifrado utilizado y la longitud de las claves
criptográficas a utilizar.
Firma Digital
Las firmas digitales proporcionan un medio de protección de la autenticidad e integridad de los
documentos electrónicos. Pueden aplicarse a cualquier tipo de documento que se procese
electrónicamente. Se implementan mediante el uso de una técnica criptográfica sobre la base
de dos claves relacionadas de manera única, donde una clave, denominada privada, se utiliza
para crear una firma y la otra, denominada pública, para verificarla.
Los algoritmos de firma utilizados, como así también la longitud de clave a emplear, son las
enumeradas en 0 Utilización de Controles Criptográficos.
Se recomienda que las claves criptográficas utilizadas para firmar digitalmente no sean
empleadas en procedimientos de cifrado de información. Dichas claves deben ser
resguardadas bajo el control exclusivo de su titular.
Al utilizar firmas y certificados digitales, se considerará la legislación vigente que describa las
condiciones bajo las cuales una firma digital es legalmente válida.
En algunos casos podría ser necesario establecer acuerdos especiales para respaldar el uso de
las firmas digitales. A tal fin se deberá obtener asesoramiento legal con respecto al marco
normativo aplicable y la modalidad del acuerdo a implementar.
Servicios de No Repudio
Estos servicios se utilizarán cuando sea necesario resolver disputas acerca de la ocurrencia de
un evento o acción. Su objetivo es proporcionar herramientas para evitar que aquél que haya
originado una transacción electrónica niegue haberla efectuado.
Administración de Claves
1. Técnicas de clave secreta (criptografía simétrica), cuando dos o más actores comparten
la misma clave y ésta se utiliza tanto para cifrar información como para descifrarla.
2. Técnicas de clave pública (criptografía asimétrica), cuando cada usuario tiene un par
de claves: una clave pública (que puede ser revelada a cualquier persona) utilizada
para cifrar y una clave privada (que debe mantenerse en secreto) utilizada para
descifrar. Las claves asimétricas utilizadas para cifrado no deben ser las mismas que se
utilizan para firmar digitalmente.
Todas las claves serán protegidas contra modificación y destrucción, y las claves secretas y
privadas serán protegidas contra copia o divulgación no autorizada.
Procedimientos y Métodos
Se redactarán procedimientos necesarios para:
A fin de reducir la probabilidad de compromiso, las claves tendrán fechas de inicio y caducidad
de vigencia, definidas de manera que sólo puedan ser utilizadas por el lapso (no debería ser
mayor a 12 meses).
Este proceso es llevado a cabo por una entidad denominada Autoridad de Certificación (AC) o
Certificador.
Los servidores de aplicaciones solo deberán acceder a los archivos que le pertenecen, y deberá
mantenerse el debido aislamiento entre las aplicaciones de un mismo servidor de aplicaciones
y entre los recursos que utilizan.
Deberán realizarse los controles necesarios para garantizar el control de acceso a los recursos
del sistema. Los sistemas deberán acceder únicamente a los archivos que les pertenecen. Es
recomendable que además que sean los sistemas propietarios de estos archivos los únicos
capaces de acceder a éstos.
Las pruebas de los sistemas se efectuarán sobre datos extraídos del ambiente de Producción y
se volcarán en el ambiente de testeo.
Una modificación por fuera de los sistemas a un dato (No Regular), almacenado ya sea en un
archivo o base de datos, podría poner en riesgo la integridad de la información.
Los casos en los que no fuera posible la aplicación de la precedente estrategia, se considerarán
como excepciones. El Responsable de Gestión de Seguridad de la Información definirá
procedimientos para la gestión de dichas excepciones que contemplarán lo siguiente:
Verificar que los cambios sean propuestos por usuarios autorizados (deberá indicarse
en la documentación de la aplicación/componente/sistema quienes son los usuarios
autorizados a solicitar cambios).
Mantener un registro de los niveles de autorización acordados.
Solicitar la autorización del Dueño de la Información, en caso de tratarse de cambios a
sistemas de procesamiento de la misma.
Identificar todos los elementos que requieren modificaciones (componentes de
software, bases de datos, hardware).
Revisar los controles y los procedimientos de integridad para garantizar que no serán
comprometidos por los cambios.
Obtener aprobación formal por parte del Responsable del Desarrollo para las tareas
detalladas, antes que comiencen las tareas.
Solicitar la revisión del Responsable de Seguridad Informática para garantizar que no se
violen los requisitos de seguridad que debe cumplir el software.
Efectuar las actividades relativas al cambio en el ambiente de desarrollo.
Obtener la aprobación por parte del usuario autorizado y del Área de Verificación
mediante pruebas en el ambiente correspondiente.
Actualizar la documentación para cada cambio implementado, tanto de los manuales
de usuario como de la documentación operativa.
Mantener un control de versiones para todas las actualizaciones de software.
Garantizar que la implementación se llevará a cabo minimizando la discontinuidad de
las actividades y sin alterar los procesos involucrados.
Informar a las áreas usuarias antes de la implementación de un cambio que pueda
afectar su operatoria.
Garantizar que sea el implantador quien efectúe el pasaje de los objetos modificados
al ambiente operativo, de acuerdo a lo establecido en “Control del Software
Operativo”.
En Ambientes en el Proceso de Desarrollo se presenta un esquema modelo de segregación de
ambientes.
Garantizar que los cambios en el sistema operativo sean informados con anterioridad a
la implementación.
Examinar los códigos fuentes (cuando sea posible) antes de utilizar los programas que
se externos que se posea el código.
Utilizar herramientas para la protección contra la infección del software con código
malicioso.
Auditoría y Trazabilidad.
Se utilizará un registro de auditoría, logging y monitoreo centralizado que provea herramientas
para su administración.
Deberá quedar registrado en el sistema métricas de uso y quienes utilizan los sistemas.
Se registrarán todas las actividades realizadas con las cuentas de emergencia creadas en las
bases de datos, tal cual se menciona en puntos anteriores.
Se deberá contar con un registro de los datos que se modifican, datos viejos y datos nuevos, y
timestamp. Esta actividad podrá ser realizada por la propia base de datos. Como se mencionó
anteriormente se deberá registrar y auditar las actividades relativas a la administración de
claves.
Verificación de la Seguridad.
La verificación de la seguridad se debe dar en distintos niveles:
Sistema de aplicaciones.
Es deseable contar con herramientas que ayuden al desarrollador a lograr este objetivo, para
facilitar su trabajo. Ejemplos de este tipo de herramientas pueden ser aquellas que realizan
revisiones de código automáticas.
Deberá especificarse que tipo de verificaciones se realizarán desarrollar y cuáles no, así como
la respuesta esperada considerando tanto casos de éxito como de falla.
También podrá ayudarse con el diseño y ejecución de las pruebas, con herramientas de
revisión de seguridad en el código de las aplicaciones, es decir test de seguridad de caja
blanca.
Puede ser útil además utiliza herramientas que testeen la seguridad del componente utilizando
métodos de caja negra.
Deberán evaluarse los distintos requisitos de seguridad de la interacción entre las aplicaciones
y diseñarse las debidas pruebas que verifiquen el cumplimiento de estos requisitos.
Por ejemplo:
Seguridad en la implementación
En el documento se han dado pautas y recomendaciones para distintas etapas, en esta sección
se busca describir aspectos relacionados de manera cercana a la implementación, conteniendo
en algunos casos algún detalle de diseño. El desarrollador no deberá remitirse a esta sección
solamente sino que deberá conocer todo el documento.
Se deberán seguir los estándares definidos en los circulares de tecnología publicados por ASIT.
Para evitar la pérdida, modificación o uso inadecuado de los datos pertenecientes a las
aplicaciones, se establecerán controles y registros de auditoría, verificando:
El procesamiento interno.
Este control deberá realizarse no solo tan cerca del punto de origen como sea posible (como
por ejemplo en la capa de presentación), sino también en el punto de entrada al sistema
(lógica de negocio), y en cada punto donde se tenga contacto con el mundo externo a la
aplicación (ejemplo, interfaces definidas que puedan ser utilizadas no solamente por la GUI de
la aplicación) controlando también datos permanentes y tablas de parámetros.
Control de secuencia.
Control de paridad.
Controles por oposición, de forma tal que quien ingrese un dato no pueda
autorizarlo y viceversa.
Fallar Seguro
Se definirá un procedimiento para que durante la etapa de diseño, se incorporen controles de
validación a fin de eliminar o minimizar los riesgos de fallas de procesamiento y/o vicios por
procesos de errores.
Las aplicaciones no deberán entrar en estado inconsistente. Para ello deberán implementarse
controles que capturen las situaciones de error posibles y que reaccionen frente a eventos
tanto esperados como inesperados.
Los mensajes de error mostrados por las aplicaciones en su interfaz gráfica deben contener
información destinada al usuario final. En ningún momento deberá contener información
propia del desarrollo ni del debug del sistema.
Los mensajes de error de las bases de datos, sistemas externos, y/o errores inesperados de
librerías o lenguajes de programación, deberán ser debidamente detectados y filtrados al
momento de retornar la información al usuario. Estos mensajes deberán ser logueados, para
una posterior revisión de auditoría, y para la corrección de errores. El mensaje de error no
debe mostrar más información que la estrictamente necesaria y lo más genérico posible a
efectos de no brindar información útil para posibles atacantes.
En aquellos sistemas que no posean interfaz gráfico, como pueden ser Servicios Web, en caso
de fallar tampoco deberá retornarse información no orientada al usuario.
Se evitará en todo momento sobre todo en aplicaciones y/o servicios que se utilicen desde el
exterior del organismo, el mostrar/enviar mensajes de error conteniendo información de
productos y/o versiones así como. Todos los errores del sistema deben ser captados
previamente a retornar información y notificar del error al usuario en un lenguaje amigable y
entendible relacionado a la lógica de negocio.
Responsable de Infraestructura
Es el responsable informático de la infraestructura informática del organismo.
Responsable de Auditoría
Es el responsable de las revisiones de auditoría
Dueño de la Información
Es un individuo no informático responsable del negocio del organismo.
Implantador
Es el encargado de realizar la puesta en funcionamiento de un componente o sistema
informático.
Responsable de Verificación
Es el responsable del diseño y ejecución de las pruebas de verificación de los sistemas y
componentes.
Referencias
1. www.owasp.org -accedido al 20/10/09.
2. www.arcert.gov.ar -accedido al 20/10/09.