aclar_llamado_a157524_16

Vista previa del material en texto

ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 1 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
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
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 2 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Índice 
 
INTRODUCCIÓN ..................................................................................................................................... 5 
OBJETIVO .................................................................................................................................................... 5 
ALCANCE..................................................................................................................................................... 5 
CONSIDERACIONES GENERALES ........................................................................................................................ 5 
ASIGNACIÓN DE RESPONSABILIDADES O FUNCIONES Y RESPONSABILIDADES ............................................................. 6 
POLÍTICA ................................................................................................................................................ 7 
REQUISITOS DE SEGURIDAD DE LOS SISTEMAS ..................................................................................................... 7 
Análisis y Especificaciones de los Requisitos de Seguridad ................................................................. 7 
AMBIENTES EN EL PROCESO DE DESARROLLO. .................................................................................................... 8 
Desarrollo: ........................................................................................................................................... 8 
Testeo:................................................................................................................................................. 8 
Producción: ......................................................................................................................................... 8 
CONTROL DE ACCESO .................................................................................................................................... 9 
CONTROLES CRIPTOGRÁFICOS ....................................................................................................................... 10 
Utilización de Controles Criptográficos. ............................................................................................ 10 
Cifrado ............................................................................................................................................... 11 
Firma Digital ..................................................................................................................................... 11 
Servicios de No Repudio .................................................................................................................... 11 
Administración de Claves .................................................................................................................. 12 
Protección de Claves Criptográficas ............................................................................................................. 12 
Procedimientos y Métodos .......................................................................................................................... 12 
SEGURIDAD DE LOS ARCHIVOS DEL SISTEMA ..................................................................................................... 13 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 3 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Protección de los archivos en el disco duro ....................................................................................... 13 
Control del Software Operativo ........................................................................................................ 14 
Protección de los Datos de Producción ............................................................................................. 14 
Control de Cambios a Datos de Producción ...................................................................................... 15 
Control de Acceso a las Bibliotecas de Programas Fuentes .............................................................. 16 
SEGURIDAD EN LAS COMUNICACIONES ............................................................................................................ 17 
SEGURIDAD DE LOS PROCESOS DE DESARROLLO Y SOPORTE ................................................................................. 17 
Procedimiento de Control de Cambios .............................................................................................. 17 
Revisión Técnica de los Cambios en el Sistema Operativo ................................................................ 18 
Canales Ocultos y Código Malicioso .................................................................................................. 18 
AUDITORÍA Y TRAZABILIDAD. ......................................................................................................................... 19 
VERIFICACIÓN DE LA SEGURIDAD. ................................................................................................................... 19 
Verificación de la seguridad en el desarrollo intracomponente. ....................................................... 19 
Verificación de la seguridad de un componente. .............................................................................. 20 
Verificación de la seguridad de la aplicación. ................................................................................... 20 
Verificación de la seguridad de sistemas de aplicaciones. ................................................................ 21 
Verificación del estado de salud de la aplicación en producción. ..................................................... 21 
SEGURIDAD EN LA IMPLEMENTACIÓN .............................................................................................................. 21 
Validación de Datos de Entrada ........................................................................................................ 22 
Utilización de Estándares. ................................................................................................................. 23 
Fallar Seguro ..................................................................................................................................... 23 
Autenticación y cifrado de Mensajes ................................................................................................ 24 
Validación de Datos de Salida ........................................................................................................... 24 
ANEXO – ROLES DEFINIDOS Y RELACIONADOS EN SEGURIDAD EN EL PROCESO DE DESARROLLO DE 
SOFTWARE. .......................................................................................................................................... 25 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 4 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
RESPONSABLE DE LA GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN....................................................................... 25 
RESPONSABLE DEL DESARROLLO .................................................................................................................... 25 
RESPONSABLE DE INFRAESTRUCTURA ..............................................................................................................25 
RESPONSABLE DE AUDITORÍA ........................................................................................................................ 25 
DUEÑO DE LA INFORMACIÓN ........................................................................................................................ 25 
RESPONSABLE INFORMÁTICO DE LA APLICACIÓN ............................................................................................... 25 
DUEÑO DE LA INFORMACIÓN (DE LA APLICACIÓN) ............................................................................................. 25 
IMPLANTADOR ........................................................................................................................................... 25 
IMPLANTADOR DE CAMBIOS EN DATOS ........................................................................................................... 25 
ADMINISTRADOR DE CÓDIGO Y PROGRAMAS FUENTES ....................................................................................... 25 
RESPONSABLE DE VERIFICACIÓN .................................................................................................................... 26 
ANEXO B – DOCUMENTACIÓN A ENTREGAR. ....................................................................................... 27 
DOCUMENTO DE ANÁLISIS DE RIESGOS. .......................................................................................................... 27 
DOCUMENTO DE REQUISITOS DE SEGURIDAD. .................................................................................................. 27 
DOCUMENTO DE DISEÑO DE CONTROLES DE SEGURIDAD. ................................................................................... 27 
DOCUMENTO DE IMPLEMENTACIÓN DE CONTROLES DE SEGURIDAD. ..................................................................... 27 
DOCUMENTO DE GESTIÓN DE EXCEPCIONES DE SEGURIDAD. ............................................................................... 27 
REFERENCIAS ....................................................................................................................................... 28 
 
 
 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 5 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
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. 
Definir y documentar las normas y procedimientos de seguridad que se aplicarán durante el 
ciclo de vida del Proceso de Ingeniería de Software. 
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. 
El grupo de Gestión de Seguridad de la Información será el encargado de las definiciones 
presentadas en este documento así como proponer los cambios que sean pertinentes. 
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. 
En la etapa de Implementación deben implementarse los controles de seguridad además de 
aplicarse los controles relativos al proceso de desarrollo de software, aquellos controles que 
deban estar en la aplicación, como por ejemplo validaciones a realizarse en el software, 
encriptado, etc. 
En fase de Verificación se debe verificar adecuadamente que los requisitos de seguridad de la 
aplicación se cumplen. 
Notar que ciertos controles serán transversales a todas las fases. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 6 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Asignación de Responsabilidades o Funciones y Responsabilidades 
 
Se requiere la interacción de las áreas de Gestión de la Seguridad de la Información, 
Coordinación del Desarrollo, ATEC, Auditoría interna, así como el Dueño de la Información y el 
usuario dueño de la aplicación. En consecuencia los actores responsables involucrados serán el 
Responsable de la Gestión de Seguridad de la Información, el Responsable del Desarrollo, el 
Responsable de Infraestructura, el Responsable de Auditoría, el Dueño de la Información y el 
Usuario dueño del sistema (o un representante del conjunto de usuarios finales del sistema). 
El Responsable de la Gestión de Seguridad de la Información, el Responsable del Desarrollo, el 
Responsable de Infraestructura, el Responsable de Auditoría, el Dueño de la Información y el 
Usuario del sistema deberán en función de la criticidad de la información, especificar los 
requisitos de encriptación que sean requeridos, así como definir los métodos que mejor 
implementen dichos requisitos. 
El Responsable de Gestión de Seguridad, en conjunto con el Responsable del Desarrollo, y el 
Responsable de Infraestructura, definirán el proceso administrativo de claves, así como 
también la administración de las técnicas criptográficas que deban utilizarse. 
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). 
El Responsable del Desarrollo y el Responsables de Infraestructura deberán documentar y 
mantener actualizado quienes obtienen acceso a los datos, y quienes acceden a los datos 
reales (en caso de necesitarse). 
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. 
El Usuario de la aplicación deberá participar en el Análisis de Requisitos, así como en el 
entrenamiento de la misma. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 7 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Política 
1. 
Requisitos de Seguridad de los Sistemas 
La metodología definida para el desarrollo de las aplicaciones deberá considerar los aspectos 
de seguridad y control durante todo el ciclo de vida del desarrollo. 
Análisis y Especificaciones de los Requisitos de Seguridad 
Se deberá incluir un proceso de evaluación de riesgos durante la etapa de especificación de 
requisitos, en la cual debieran participar el Responsable de Gestión de Seguridad de la 
Información, el Responsable del Desarrollo, el Responsable de Infraestructura, el Responsable 
de Auditoría, el Dueño de la Información y el Usuario Dueño. Deberá documentarse el 
resultado de dicha evaluación.En base al análisis de riesgos realizado deberá generarse un documento o un apartado en el 
documento de requisitos del sistema que identifique los requisitos de seguridad especificados 
para la mitigación de los riesgos identificados 
Debieran considerarse el nivel que se debe cumplir de los tres principios básicos de la 
seguridad de la información: 
 Confidencialidad 
 Integridad 
 Disponibilidad 
Debiendo agregarse los siguientes: trazabilidad y no repudio. 
El Responsable de Gestión de Seguridad de la Información, el Responsable del Desarrollo, el 
Responsable de Infraestructura y el Dueño de la Información, deberán especificar y aprobar los 
controles que satisfagan a los distintos requisitos, pudiendo incluso solicitar una evaluación 
previa de los mismos, para verificar la viabilidad del control. 
Deberá especificarse el mapeo entre el requisito de seguridad y uno o más controles que 
implementen el requisito. 
Se deberán considerar controles manuales como apoyo a los automáticos, de manera 
obligatoria, y no asumir que porque de forma automática ya se cumple con ese requisito 
entonces se puede omitir la implementación del mismo. 
Al especificar controles de seguridad se deberán evaluar los controles propuestos 
considerando el costo, esfuerzo, criticidad de la información y/o los bienes que quieren 
protegerse y las probabilidades del riesgo que mitiga. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 8 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Considerar que la inclusión de este proceso y el diseño de los controles en etapas tempranas 
del desarrollo siempre es menos costoso que considerarlas en la implementación o luego de 
ella. 
Ambientes en el Proceso de Desarrollo. 
Se deberá contar con tres ambientes completos para el ciclo de ingeniería de software. 
Estos ambientes serán: 
Desarrollo: 
 Es el ambiente propio de los desarrolladores. 
 El desarrollador es el responsable del mantenimiento del ambiente, 
 Se recomienda utilizar en lo posible productos semejantes a los empleados en 
producción de manera de disminuir las diferencias. 
Testeo: 
 Es el ambiente en el cual se realizan las pruebas de caja negra a las aplicaciones. 
 Deberá replicar exactamente en productos y configuración al ambiente de producción, 
siendo recomendable además que también utilice una réplica exacta de la 
infraestructura. 
 La administración del mismo deberá estar en manos de infraestructura, el Responsable 
de Infraestructura deberá indicar quien de su sector será el o los encargado/s de este 
ambiente. 
 El personal del desarrollo no deberá acceder a la administración de este ambiente, 
pero sí podrá participar en las pruebas a realizar en el mismo, siendo lo ideal que el 
personal vinculado al área de Verificación, sea el único encargado de realizar las 
pruebas en este ambiente. 
 Este ambiente es exclusivo de Testeo y no deberá en ningún momento, salvo las 
excepciones acordadas por el Responsable de Seguridad, el responsable de 
Infraestructura y el responsable de Desarrollo, apuntar a datos de producción. Con 
respecto a los datos los mismos deberán ser enmascarados tal cual lo explica en 
Protección de los Datos de Producción. 
Producción: 
o Es el ambiente operativo. 
o La administración del mismo deberá estar en manos de infraestructura, el 
Responsable de Infraestructura deberá indicar quien de su sector será el o los 
encargado/s de este ambiente. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 9 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
o El personal del desarrollo no deberá acceder a la administración de este ambiente. 
o No se deberán realizar pruebas que modifiquen datos en este ambiente. 
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. 
El tipo de autenticación/autorización varía de acuerdo al sujeto y a los nodos. Es recomendable 
que entre distintos nodos exista autenticación, y autorización. Por ejemplo en una interacción 
entre un usuario con una aplicación web, que se aloja en un servidor web, el cual se comunica 
con un servidor de aplicaciones, el que finalmente accede a la bases de datos. A nivel de 
comunicación con la base de datos, si la aplicación/componente es de solo lectura, deberá 
utilizarse un usuario de genérico propio de la aplicación para acceder a la base de datos (no es 
compartido con ninguna otra aplicación) con derechos de solo lectura. 
Si la aplicación/componente es de escritura, entonces pueden tomarse, por ejemplo, las 
siguientes alternativas: 
1. Tener un usuario de la base de datos genérico propio de la aplicación con derechos de 
lectura/escritura. 
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. 
Según la criticidad de la aplicación/componente y el costo/beneficio ganado por la utilización 
de estas opciones se elegirá la número 1, 2, o alguna otra alternativa que sea debidamente 
justificada. 
Para cualquier caso deberán activarse los controles de auditoría necesarios. 
En la siguiente figura de ejemplo el servidor web coincide con el servidor de aplicaciones. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 10 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
User1
Servidor
Datos
user1@domain
User2
User3
user2@domain
user3@domain
user: application_A 
(read/write)
 
Se deberá diseñar y desarrollar los componentes responsables de distintos dominios de 
negocio. El resto de las aplicaciones/componentes que requieran datos de un determinado 
dominio del negocio, no deberán acceder directamente a los datos en sí, sino que reutilizarán 
estos componentes. De esta manera se unifica el control de acceso a los datos, basados en la 
creación de distintos dominios de seguridad determinados por el negocio. 
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. 
Utilización de Controles Criptográficos. 
El B.P.S. define el siguiente conjunto de controles criptográficos, a fin de determinar su 
correcto uso. 
Para ello se indica que se utilizarán controles criptográficos en los siguientes casos: 
1. Para la protección de claves de acceso a sistemas, datos y servicios. 
2. Para la transmisión de información clasificada, fuera del ámbito del B.P.S. 
3. Para el resguardo de información, cuando así surja de la evaluación de riesgos 
realizada por el Dueño de la Información y el Responsable de Seguridad Informática. 
4. Se desarrollarán procedimientos respecto de la administración de claves, de la 
recuperación de información cifrada en caso de pérdida, compromiso o daño de las 
claves y en cuanto al reemplazo de las claves de cifrado. 
5. El Responsable del Desarrollo, del Área Informática propondrá la siguiente asignación 
de funciones: 
a. Implementación de los Controles Criptográficos 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 11 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
6. Los Certificados Digitales Personales utilizados en cualquiera de sus aplicacionesdeberán cumplir con los requisitos propuestos por la ASIT, en particular deberán ser 
brindados por una empresa u organización reconocida como CA. 
7. Si se utilizara Dispositivos criptográficos USB, se deberán seguir las pautas propuestas 
la ASIT. 
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. 
Se tomarán recaudos para proteger la confidencialidad de las claves privadas. 
Asimismo, es importante proteger la integridad de la clave pública. Esta protección se provee 
mediante el uso de un certificado de clave pública. 
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. 
Cuando se requiera el no repudio de elaboración de un documento, o de pertenencia de un 
documento, se recurrirá a la firma digital de documentos. Utilizando certificados digitales, 
acorde al punto Firma Digital. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 12 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Si se requiere el No Repudio de una variación a nivel de datos, entonces deberá realizarse un 
registro de auditoría de cada cambio que el usuario realiza, explícita o implícitamente, 
permitiendo de esta manera identificar el conjunto de pasos que el usuario realizó, y replicarlo 
en un nuevo ambiente. 
Administración de Claves 
Protección de Claves Criptográficas 
Se implementará un sistema de administración de claves criptográficas para respaldar la 
utilización por parte del Organismo de los dos tipos de técnicas criptográficas, a saber: 
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. 
Se proporcionará una protección adecuada al equipamiento utilizado para generar, almacenar 
y archivar claves, considerándolo crítico o de alto riesgo. 
Procedimientos y Métodos 
Se redactarán procedimientos necesarios para: 
 Generar claves para diferentes sistemas criptográficos y diferentes aplicaciones. 
 Generar y obtener certificados de clave pública de manera segura. 
 Distribuir claves de forma segura a los usuarios que corresponda, incluyendo 
información sobre cómo deben activarse cuando se reciban. 
 Almacenar claves, incluyendo la forma de acceso a las mismas por parte de los 
usuarios autorizados. 
 Cambiar o actualizar claves, incluyendo reglas sobre cuándo y cómo deben cambiarse 
las claves. 
 Revocar claves, incluyendo cómo deben retirarse o desactivarse las mismas, por 
ejemplo cuando las claves están comprometidas o cuando un usuario se desvincula del 
Organismo (en cuyo caso las claves también deben archivarse). 
 Recuperar claves perdidas o alteradas como parte de la administración de la 
continuidad de las actividades del Organismo, por ejemplo para la recuperación de la 
información cifrada. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 13 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
 Archivar claves, por ejemplo, para la información archivada o resguardada. 
 Destruir claves. 
 Registrar y auditar las actividades relativas a la administración de claves. 
 
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). 
Además de la administración segura de las claves secretas y privadas, deberá tenerse en 
cuenta la protección de las claves públicas. Este problema es abordado mediante el uso de un 
certificado de clave pública. Este certificado se generará de forma que vincule de manera única 
la información relativa al propietario del par de claves pública/privada con la clave pública. En 
consecuencia es importante que el proceso de administración de los certificados de clave 
pública sea absolutamente confiable. 
Este proceso es llevado a cabo por una entidad denominada Autoridad de Certificación (AC) o 
Certificador. 
Seguridad de los Archivos del Sistema 
Se garantizará que los desarrollos y actividades de soporte a los sistemas se lleven a cabo de 
manera segura, controlando el acceso a los archivos del mismo. 
Protección de los archivos en el disco duro 
Ningún programa podrá acceder a archivos y/o carpetas en los sistemas que no sean de su 
propiedad. Esto deberá cumplirse independientemente de si las aplicaciones se encuentran 
alojadas en Servidores de Aplicaciones o en Computadoras de Escritorio. 
Los archivos propios de cada aplicación deberán guardarse en lugares predefinidos. 
En el caso de las aplicaciones de escritorio, deberá acordarse un lugar donde el sistema 
operativo en el cual se corre la aplicación le provea al usuario la capacidad de guardar archivos 
de aplicaciones, evitando la necesidad de derechos especiales para la ejecución de estos 
programas, como puede ser la escritura de archivos en el disco duro en la ruta raíz. 
En el caso de las aplicaciones alojadas en servidores deberá acordarse un lugar donde la 
aplicación deberá acceder, 
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. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 14 / 28 
CREADO: 2009-11-23 VERSIÓNDEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Control del Software Operativo 
Se definen los siguientes controles a realizar durante la implementación del software en 
producción, a fin de minimizar el riesgo de alteración de los sistemas. 
 Toda aplicación, desarrollada por el Organismo o por un tercero tendrá un único 
responsable informático designado formalmente por el Responsable del Desarrollo al 
que se denominará Responsable Informático de la Aplicación y también un único un 
Dueño de la Información. 
 Ningún programador o analista de desarrollo y mantenimiento de aplicaciones podrá 
acceder a los ambientes de producción. 
 El Responsable del Desarrollo, propondrá la asignación de la función de “Implantador” 
al personal de su área que considere adecuado, quien tendrá como funciones 
principales: 
 
o Coordinar la implantación de modificaciones o nuevos programas en el 
ambiente de Producción. 
o Asegurar que los sistemas aplicativos en uso, en el ambiente de Producción, 
sean los autorizados y aprobados de acuerdo a las normas y procedimientos 
vigentes. 
o Solicitar la Instalación las modificaciones, controlando previamente la 
recepción de la prueba aprobada por parte del dueño de la información y del 
grupo encargado de la verificación. 
 
Además deberían seguirse los siguientes controles: 
 Guardar sólo los ejecutables en el ambiente de producción y/o archivos de 
configuración. 
 Llevar un registro de auditoría de las actualizaciones realizadas. 
 Retener las versiones previas del sistema, como medida de contingencia. 
 Definir un procedimiento que establezca los pasos a seguir para implementar las 
autorizaciones y conformes pertinentes, las pruebas previas a realizarse, etc. 
 Denegar permisos de modificación al implantador sobre los programas fuentes bajo su 
custodia. 
 Evitar, que la función de implantador sea ejercida por personal que pertenezca al 
sector de desarrollo de esa aplicación. 
 
Protección de los Datos de Producción 
Se prohíbe el uso de base de datos operativas (de producción) para la realización de pruebas. 
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. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 15 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Para proteger los datos de prueba se establecerán procedimientos que contemplen: 
 Despersonalización de los datos antes de su uso. Aplicar idénticos procedimientos de 
control de acceso que en la base de producción. De manera de replicar lo más 
posible el ambiente de producción. 
 Solicitar autorización formal para realizar una copia de la base operativa como base de 
prueba, llevando registro de tal autorización. 
 Eliminar inmediatamente, una vez completadas las pruebas, la información operativa 
utilizada. 
 
 Control de Cambios a Datos de Producción 
La modificación, actualización o eliminación de los datos operativos serán realizadas a través 
de los sistemas que procesan dichos datos y de acuerdo al esquema de control de accesos 
implementado en los mismos. 
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: 
 Se generará una solicitud formal para la realización de la modificación, actualización o 
eliminación del dato. 
 El Dueño de la Información afectada y el Responsable de Desarrollo aprobarán la 
ejecución del cambio evaluando las razones por las cuales se solicita. La justificación de 
las decisiones tomadas, así como la información sobre el cambio realizado deberá 
estar disponible para una posterior revisión de Auditoría. 
 Se generarán cuentas de usuario de emergencia para ser utilizadas en la ejecución de 
excepciones. Las mismas serán protegidas mediante contraseñas, sujetas al 
procedimiento de administración de contraseñas críticas y habilitadas sólo ante un 
requerimiento de emergencia y por el lapso que ésta dure. 
 Se designará un encargado de implantar los cambios denominados “Implantadores de 
cambios en Datos””, se deberá evitar que la función sea ejercida por personal que 
pertenezca al sector de desarrollo de esa aplicación. 
 Se registrarán todas las actividades realizadas con las cuentas de emergencia. Dicho 
registro será revisado posteriormente por el Responsable de Seguridad de la 
Información. 
 
 
 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 16 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Control de Acceso a las Bibliotecas de Programas Fuentes 
 
Para reducir la probabilidad de alteración de programas fuentes, se aplicarán los siguientes 
controles: 
 El Responsable del Área Informática, propondrá la función de “Administrador de 
código fuente” al personal de su área que considere adecuado, quien tendrá en 
custodia los programas fuentes y deberá: 
o Proveer al Área de Desarrollo los códigos fuentes solicitados para su 
modificación, manteniendo en todo momento la correlación código fuente / 
ejecutable. 
o Llevar un registro actualizado de todo el código fuente en uso, indicando 
nombre del programa, programador, Analista Responsable que autorizó, 
versión, fecha de última modificación y fecha / hora de compilación y estado 
(en desarrollo, testeo, o producción). 
o Verificar que el Responsable que autoriza la solicitud de un programa fuente 
sea el designado para la aplicación, rechazando el pedido en caso contrario. 
Registrar cada solicitud aprobada. 
o Administrar las distintas versiones de una aplicación. 
o Asegurar que un mismo programa fuente no sea modificado simultáneamente 
por más de un desarrollador. 
 Denegar al “Administrador de código fuente” permisos de modificación sobre los 
programas fuentes bajo su custodia. 
 Establecer que todo programa objeto o ejecutable en producción tenga un único 
programa fuente asociado que garantice su origen. 
 Establecer que el Implantador de producción efectuará la generación del programa 
objeto o ejecutable que estará en producción (compilación), a fin de garantizar tal 
correspondencia. 
 Desarrollar un procedimiento que garantice que toda vez que se migre a producción el 
módulo fuente, se cree el código ejecutable correspondiente en forma automática. 
 Evitar que la función de “Administrador de código fuente” sea ejercida por personal 
que pertenezca al sector de desarrollo y/o mantenimiento. 
 Prohibir la guarda de programas o código fuente histórico (que no sea correspondiente 
a los programas operativos) en el ambiente de producción. 
 Prohibir el acceso a todo operador y/o usuario de aplicaciones a los ambientes y a las 
herramientas que permitan la generación y/o manipulación de los programas fuentes. 
 Realizar las copias de respaldo de los programas fuentes cumpliendo los requisitos de 
seguridad establecidos por el Organismo en los procedimientos que surgen del 
presente documento. 
 
 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 17 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Seguridad en las comunicaciones 
En aquellas aplicaciones/componentes cuya comunicación implique comunicación entre 
distintos nodos, ya sean virtuales y/o físicos, deberá protegerse la integridad de los datos, y la 
confidencialidad de los mismos (si así se requiere). Deberán seguirse los estándares y pautas 
de la organización. 
Seguridad de los Procesos de Desarrollo y Soporte 
Secontrolará la seguridad en los entornos y el soporte dado a los mismos. 
Procedimiento de Control de Cambios 
A fin de minimizar los riesgos de alteración de los sistemas de información, se implementarán 
controles estrictos durante la implementación de cambios imponiendo el cumplimiento de 
procedimientos formales. Éstos garantizarán que se cumplan los procedimientos de seguridad 
y control, respetando la división de funciones. 
Para ello se establecerá un procedimiento que incluya las siguientes consideraciones: 
 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. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 18 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
 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. 
 
Revisión Técnica de los Cambios en el Sistema Operativo 
Cada cambio que se considere significativo en el Sistema Operativo será evaluado y se deberá 
decidir si las aplicaciones serán revisadas para asegurar que no se produzca un impacto en su 
funcionamiento o seguridad. Esta revisión será obligatoria si se cambia de Sistema Operativo. 
Para ello, se definirá un procedimiento que incluya: 
 Revisar los procedimientos de integridad y control de aplicaciones para garantizar que 
no hayan sido comprometidas por el cambio. 
 Garantizar que los cambios en el sistema operativo sean informados con anterioridad a 
la implementación. 
 Asegurar la actualización del Plan de Continuidad de las Actividades del B.P.S. 
Canales Ocultos y Código Malicioso 
Un canal oculto puede exponer información utilizando algunos medios indirectos y 
desconocidos. El código malicioso está diseñado para afectar a un sistema en forma no 
autorizada y no requerida por el usuario. 
En este sentido, se redactarán normas y procedimientos que incluyan: 
 Adquirir programas a proveedores acreditados o productos ya evaluados. 
 Examinar los códigos fuentes (cuando sea posible) antes de utilizar los programas que 
se externos que se posea el código. 
 Controlar el acceso y las modificaciones al código instalado. 
 Utilizar herramientas para la protección contra la infección del software con código 
malicioso. 
 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 19 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Auditoría y Trazabilidad. 
Se utilizará un registro de auditoría, logging y monitoreo centralizado que provea herramientas 
para su administración. 
La información de auditoría deberá presentarse mediante un aplicativo de usuario final de 
forma que sea fácilmente legible y entendible, pudiéndose realizar reportes y estadísticas de 
uso de forma sencilla y precisa. 
Deberá quedar registrado en el sistema métricas de uso y quienes utilizan los sistemas. 
Se deberá guardar la trazabilidad completa de cada aplicación, funcionalidad, timestamp y el 
usuario de la aplicación para aquellas aplicaciones internas del organismo, cuando el mismo se 
desencadene una modificación que sea commiteada en los datos. 
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: 
 En el desarrollo de un componente, clase o conjunto de método. (en el código 
desarrollado o el que se está desarrollando). 
 En la vista externa de los componentes de una aplicación (caja Negra). 
 La aplicación (como sistema global). 
 Sistema de aplicaciones. 
 Estado de salud de la aplicación en producción. 
Verificación de la seguridad en el desarrollo intracomponente. 
Se debe verificar la seguridad del código que se está desarrollado intracomponente, sin 
esperar a que sea verificado cuando se esté listo. 
Es tarea del desarrollador realizar esta verificación. 
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. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 20 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Sin embargo las revisiones automáticas no deben sustituir la labor manual humana, ya que 
esta siempre detecta mayor cantidad o gravedad de situaciones inseguras, ambas técnicas 
deben complementarse. 
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. 
Se documentarán las decisiones tomadas. 
Verificación de la seguridad de un componente. 
Deberán diseñarse pruebas de verificación de la seguridad en para cada componente y sus 
interacciones. Debido a la variedad en la criticidad de los componentes, es posible que el 
diseño de estas pruebas pueda recaer en la responsabilidad del desarrollador, o bien del 
Responsable de Verificación. 
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. 
Verificación de la seguridad de la aplicación. 
La verificación de una aplicación deberá ser cuidadosamente diseñada y deberá incluir la 
verificación de la seguridad de la misma y su entorno. 
En ambiente de desarrollo cuando la aplicación se encuentre en desarrollo, la verificación de la 
aplicación es responsabilidad del desarrollador. También es de utilidad complementar el 
testeo, utilizando herramientas que chequen la seguridad del código desarrollado.Deberá realizarse la verificación de la seguridad de la aplicación en un ambiente de testeo que 
simule el ambiente de producción. De esta manera posibles errores son detectados 
previamente a su puesta en producción. Para esto es conveniente utilizar además de las 
pruebas diseñadas por el Responsable de Verificación, el uso de una herramienta que testeo la 
seguridad de las aplicaciones utilizando métodos de caja negra. 
Una vez puesta en producción la aplicación, deberán realizarse verificaciones correspondientes 
a la seguridad de la aplicación que no interfieran con el negocio. 
Podrán realizarse test selectivos sobre determinados grupos de aplicaciones. 
Ninguna herramienta de verificación o pruebas manuales en ambientes de producción 
deberán modificar datos. Esto deberá ser garantizado. 
 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 21 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Deberán crearse además: 
1. Procedimientos que establezcan la revisión periódica de los registros de auditoría de 
forma de detectar cualquier anomalía en la ejecución de las transacciones. 
2. Procedimientos que establezcan los controles y verificaciones necesarios para prevenir 
la ejecución de programas fuera de secuencia o cuando falle el procesamiento previo. 
3. Procedimientos que realicen la validación de los datos generados por el sistema. 
4. Procedimientos que verifiquen la integridad de los datos. 
5. Procedimientos que controlen la integridad de registros y archivos. 
Verificación de la seguridad de sistemas de aplicaciones. 
En varias ocasiones las aplicaciones tienen que interactuar con otras, y en esta situación el 
nivel de seguridad de las mismas puede verse desprotegido. 
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. 
Deberán definirse procedimientos que aseguren el orden correcto de ejecución de los 
aplicativos, la finalización programada en caso de falla, y la detención de las actividades de 
procesamiento hasta que el problema sea resuelto. 
Verificación del estado de salud de la aplicación en producción. 
Se deberá proveer mecanismos de controlar la integridad y la disponibilidad de la 
aplicación/componente. 
Por ejemplo: 
 Proveer servicios al ser invocados chequen la disponibilidad e integridad de cada 
uno de los componentes que utiliza el componente a llamar. 
 Proveer transacciones testigo. 
 
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: 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 22 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
 La validación de datos de entrada. 
 El procesamiento interno. 
 La autenticación de mensajes (interfaces entre sistemas) 
 La validación de datos de salida. 
Validación de Datos de Entrada 
Se definirá un procedimiento que durante la etapa de diseño, especifique controles que 
aseguren la validez de los datos ingresados, tanto en la capa de presentación, como en la capa 
de negocio. 
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. 
Este procedimiento considerará los siguientes controles: 
 Control de secuencia. 
 Control de monto límite por operación y tipo de usuario. 
 Control del rango de valores posibles y de su validez, de acuerdo a criterios 
predeterminados. 
 Control de paridad. 
 Control contra valores cargados en las tablas de datos. 
 Controles por oposición, de forma tal que quien ingrese un dato no pueda 
autorizarlo y viceversa. 
Por otra parte, se llevarán a cabo las siguientes acciones: 
1. Se definirá un procedimiento para realizar revisiones periódicas de contenidos de 
campos claves o archivos de datos, definiendo quién lo realizará, en qué forma, con 
qué método, quiénes deberán ser informados del resultado, etc. 
2. Se definirá un procedimiento que explicite las alternativas a seguir para responder a 
errores de validación en un aplicativo. 
3. Se definirá un procedimiento que permita determinar las responsabilidades de todo el 
personal involucrado en el proceso de entrada de datos. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 23 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Utilización de Estándares. 
La utilización de estándares de la industria favorece que se desarrollen soluciones que con 
herramientas (cómo metodologías, paradigmas, IDE,s, bibliotecas, patrones) que sean 
conocidas. Esto permite conocer tantos sus fortalezas como sus debilidades y vulnerabilidades. 
La organización deberá definir estándares para los siguientes aspectos: 
 Lenguajes de Programación que se utilizarán. 
 Entornos de desarrollo (IDE’s). 
 Requisitos que deben cumplir las librerías para ser utilizadas. 
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. 
Los datos que la aplicación utilice no pueden resultar inconsistentes. 
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. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 24 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco dePrevisión Social 
CSEI-GSEI 
Autenticación y cifrado de Mensajes 
Cuando una aplicación tenga previsto el envío de mensajes que contengan información 
clasificada, se implementarán los controles criptográficos determinados en el punto Controles 
Criptográficos. 
Validación de Datos de Salida 
Se establecerán procedimientos para validar la salida de los datos de las aplicaciones, 
incluyendo: 
 Comprobaciones de la razonabilidad para probar si los datos de salida son admisibles. 
 Control de conciliación de cuentas para asegurar el procesamiento de todos los datos. 
 No proveer información que no es necesaria. 
 De ser posible proveer sin perjuicio del punto anterior información suficiente, para que 
el lector o sistema de procesamiento subsiguiente determine la exactitud, totalidad, 
precisión y clasificación de la información. 
 Procedimientos para responder a las pruebas de validación de salidas. 
 
 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 25 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
ANEXO – Roles definidos y relacionados en Seguridad en el 
Proceso de Desarrollo de Software. 
Responsable de la Gestión de Seguridad de la información 
Es el responsable informático de las definiciones de seguridad de la información en el 
organismo. 
Responsable del Desarrollo 
Es el responsable informático de todo el desarrollo de software del organismo. 
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. 
Responsable Informático de la Aplicación 
Es el informático encargado de la aplicación. 
Dueño de la Información (de la aplicación) 
Es un individuo no informático responsable del negocio del organismo relacionado a la 
aplicación. 
Implantador 
Es el encargado de realizar la puesta en funcionamiento de un componente o sistema 
informático. 
Implantador de Cambios en Datos 
Es el encargado de realizar cambios en los datos en producción. 
Administrador de Código y Programas fuentes 
Es el encargado de la gestión de la configuración de los programas y código fuente. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 26 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Responsable de Verificación 
Es el responsable del diseño y ejecución de las pruebas de verificación de los sistemas y 
componentes. 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 27 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
ANEXO B – Documentación a Entregar. 
Documento de Análisis de Riesgos. 
Documento producto de la etapa de Evaluación de riesgos realizada por el Responsable de 
Gestión de Seguridad de la Información, el Responsable del Desarrollo, el Responsable de 
Infraestructura y el Dueño de la Información. 
Documento de Requisitos de Seguridad. 
Documento o apartado en el Documento de Requisitos de cada sistema en el cual se especifica 
aquellos requisitos relativos a la seguridad. 
Documento de Diseño de Controles de Seguridad. 
Documento en el cual se describen los controles de seguridad diseñados para cumplir con los 
requisitos. 
Documento de Implementación de Controles de Seguridad. 
Documento que incluye detalles de implementación de los controles de seguridad diseñados 
previamente. 
Documento de Gestión de Excepciones de Seguridad. 
Este documento debe ser elaborado por el Responsable de Gestión de Seguridad de la 
Información, el Responsable del Desarrollo, el Responsable de Infraestructura y el Dueño de la 
Información. Contendrá las decisiones sobre que aquellas excepciones que deban hacerse con 
respecto a los controles de seguridad pautados como estándares del organismo y que no 
puedan implementarse en la aplicación. 
 
 
 
 
ARCHIVO: ANEXO6_GSEI_-_Seguridad_en_el_Proceso_de_Desarrollo_de_Software_v0.9 Nº. PÁG: 28 / 28 
CREADO: 2009-11-23 VERSIÓN DEL: 24/11/2009 
 
 
Banco de Previsión Social 
CSEI-GSEI 
Referencias 
1. www.owasp.org -accedido al 20/10/09. 
2. www.arcert.gov.ar -accedido al 20/10/09. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
http://www.owasp.org/
file:///D:/Users/mpapaleo/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/96T7O07U/www.arcert.gov.ar