You are on page 1of 11

FACULTAD DE INGENIERIA

ESCUELA DE COMPUTACIN


ASIGNATURA

Normalizacion y Estandares


Analisis de controles


DOCENTE


Lic. Omar Torres



PRESENTA

AR100535
LP100389
Geovanny Enrique Araujo Roque
Milton Alfonso Loza Padilla
CD110321 Leonardo Miguel Cruz Diaz








CIUDADELA DON BOSCO, 17 DE SEPTIEMBRE DE 2014
No y Nombre
Clausula
Objetivo de
Control
(nombre y
explicacin)
Controles
Identifcados
Recursos
necesarios
Estrategias de
implementacin
12. Adquisicin,
Desarrollo y
Mantenimiento
de Sistemas de
Informacin
12.1
Requerimientos
de seguridad de
los sistemas de
informacin

Objetivo:
Garantizar que la
seguridad sea una
parte integral de
los sistemas de
informacin.

Se debieran
identificar todos
los requerimientos
de seguridad en la
fase de
requerimientos
de un proyecto; y
debieran ser
justificados,
acordados y
documentados.

Sistemas de
operacin,
infraestructura,
aplicaciones
comerciales,
productos de
venta masiva,
servicios y
aplicaciones
desarrolladas por
el
usuario.



12.1.1 Anlisis y
especificacin de
los requerimientos
de seguridad
- Especificar los
requerimientos
de los controles
de seguridad para
programa
informativos
nuevos y en uso.

- Estos controles
deben de reflejar
el valor comercial
de los activos en
informacin
involucrados y
dao que causara
en una falla o
ausencia.

- Si los productos
son comprados, se
debiera realizar un
proceso de prueba
y adquisicin
formal, los cuales
deben traer a
detalle la
seguridad lo cual
deben ser
evaluados
- Los requerimientos de
seguridad para la seguridad de la
informacin y los procesos para
implementar la seguridad
debieran ser integrados en las
primeras etapas de los proyectos
de
sistemas de informacin.


- Si el producto comprado
satisface las necesidades de
seguridad este puede ser
implementado y con el tiempo se
actualiza segn la seguridad
requerida pero si no satisface se
debieran reconsiderar el riesgo
introducido y los
controles asociados antes de
comprar el producto.
12.2
Procesamiento
correcto en las
aplicaciones





Objetivo: Prevenir
errores, prdida,
12.2.1 Validacin
de la input data
Se debiera validar
la input data para
las aplicaciones
para asegurar que
esta data sea
correcta
y apropiada.
Se debieran realizar chequeos del
input de las transacciones
comerciales, la data fija (por
ejemplo nombres y direcciones,
lmites de crdito, nmeros de
referencia de los clientes), y
tablas de parmetros (por
ejemplo; precios de venta,
moneda, tasas de cambio, tasa
tributaria). Se debieran
considerar los siguientes
modificacin no
autorizada o mal
uso de la
informacin
en las
aplicaciones

Diseo de
controles
apropiados para
asegurar el
procesamiento
correcto estos
debieran incluir la
validacin de la
input data,
procesamiento
interno y output
data.
lineamientos:

a) input dual u otros chequeos de
data; tales como chequeo de
lmites o limitar los
campos a los rangos especficos
de la input data; para detectar los
siguientes
errores:

1) valores fuera de rango;
2) caracteres invlidos en los
campos de data;
3) data incompleta o faltante;
4) exceder los lmites superiores
e inferiores del volumen de data;
5) data de control no autorizada o
inconsistente;






b) revisin peridica del
contenido de los campos claves o
archivos de data para
confirmar su validez e integridad;

c) inspeccionar los documentos
de input de la copia impresa en
caso de cambios no
autorizados (todos los cambios a
los documentos de input debieran
ser autorizados);

d)procedimientos para responder
a los errores de validacin;

e) procedimientos para probar la
aprobacin de la input data;

f) definir las responsabilidades de
todo el personal involucrado en el
proceso de input
de data;(ROLES)

g) crear un registro de las
actividades involucradas en el
proceso de input de data.
(MEMOS)
12.2.2 Control del
procesamiento
interno
Los chequeos de
validacin se
debieran
incorporar en las
aplicaciones para
Asegurar que se minimicen los
riesgos
de fallas en el procesamiento que
lleven a la prdida de la
integridad. Las reas especficas
detectar cualquier
corrupcin de la
informacin a
travs de errores
de procesamiento
o actos
deliberados.

Los chequeos de
validacin
requeridos
dependern de la
naturaleza de la
aplicacin y el
impacto comercial
de
cualquier
corrupcin de la
data.



a
considerarse incluyen:

a) el uso de funciones agregadas,
modificadas y eliminadas para
implementar cambios
en la data;
b) los procedimientos para evitar
que los programas corran en el
orden equivocado o
corran despus de una falla en el
procesamiento previo.
c) el uso de programas
apropiados para recuperarse de
fallas para asegurar el correcto
procesamiento de la data;
d) proteccin contra ataques
utilizando
excesos/desbordamientos de la
memora
intermedia.

Se debiera preparar una lista de
chequeo apropiada, se debieran
documentar las actividades y
los resultados se debieran
mantener seguros.





Los ejemplos de los chequeos
que se pueden
incorporar incluyen lo siguiente:

a) controles de sesin o lote, para
conciliar los saldos del archivo de
data despus de
las actualizaciones de la
transaccin;

b) controles de saldos, para
chequear los saldos de apertura
comparndolos con los
saldos de cierre anteriores;

c) validacin de la input data
generada por el sistema.

d) chequeos de la integridad,
autenticidad y cualquier otro
dispositivo de seguridad de
la data o software cargado o
descargado, entre la computadora
central y las
remotas;

e) totales hash de registros y
archivos;

f) chequeos para asegurar que los
programas se corran en el
momento adecuado;

g) chequeos para asegurar que los
programas sean corridos en el
orden correcto y
terminados en caso de una falla, y
que se detenga el procesamiento
hasta que se
resuelva el problema;

h) crear un registro de las
actividades involucradas en el
procesamiento
12.2.3 Integridad
del mensaje
Se debiera
identificar los
requerimientos
para asegurar la
autenticidad y
proteger la
integridad
del mensaje en las
aplicaciones, y se
debieran
identificar e
implementar los
controles
apropiados.
Se debiera realizar una
evaluacin de los riesgos de
seguridad para determinar si se
requiera
la integridad del mensaje y para
identificar el mtodo de
implementacin ms apropiado

Se pueden utilizar tcnicas
criptogrficas (ver 12.3) como un
medio apropiado para
implementar la autenticacin del
mensaje.
12.2.4 Validacin
de la output data
Se debiera validar
la output data de
una aplicacin
para asegurar que
el procesamiento
de la
informacin
almacenada sea el
correcto y el
apropiado para las
circunstancias.
La validacin del output puede
incluir:

a) chequeos de comprobacin
para comprobar si el output data
es razonable;
b) conteo de control de
conciliacin para asegurar el
procesamiento de toda la data;

c) proporcionar la informacin
suficiente para un lector o el
sistema de procesamiento
subsiguiente para determinar la
exactitud, integridad, precisin y
clasificacin de la
informacin;

d) procedimientos para responder
a las pruebas de validacin de
output;

e) definir las responsabilidades
de todo el personal involucrado
en el proceso de output
de data;

f) crear un registro de las
actividades en el proceso de
validacin del output de data.
12.3 Controles
criptogrficos

Proteger la
confidencialidad,
autenticidad o
integridad a travs
de medios
criptogrficos.

Se debiera
desarrollar una
poltica sobre el
uso de controles
criptogrficos.
.
12.3.1 Poltica
sobre el uso de
controles
criptogrficos.

Se debiera
establecer una
gestin clave para
sostener el uso de
tcnicas
criptogrficas
Se debiera
desarrollar e
implementar una
poltica sobre el
uso de controles
criptogrficos
para
proteger la
informacin.

Esto nos
brindaria:

a)
confidencialidad:
utilizando la
codificacin de la
informacin para
proteger la
informacin
confidencial o
crtica, ya sea
almacenada o
transmitida;

b)
integridad/autenti
cidad: utilizando
firmas digitales o
cdigos de
autenticacin del
mensaje para
proteger la
autenticidad e
integridad de la
informacin
confidencial o
crtica
almacenada o
transmitida;

c) no-repudiacin:
utilizando
tcnicas
criptogrficas
para obtener
prueba de a
ocurrencia o no-
Cuando se desarrolla una poltica
criptogrfica se debiera
considerar lo siguiente:

a) el enfoque gerencial sobre el
uso de los controles
criptogrficos a travs de la
organizacin, incluyendo los
principios generales bajo los
cuales se debiera
proteger la informacin
comercial (ver tambin 5.1.1);

b) en base a la evaluacin del
riesgo, se debiera identificar el
nivel de proteccin
requerido tomando en cuenta el
tipo, fuerza y calidad del
algoritmo criptogrfico
requerido;

c) el uso de codificacin para la
proteccin de la informacin
confidencial transportada
por los medios y dispositivos
mviles o removibles o a travs
de las lneas de
comunicacin;

d) el enfoque de la gestin de
claves, incluyendo los mtodos
para lidiar con la
proteccin de las claves
criptogrficas y la recuperacin
de la informacin codificada
en el caso de claves prdidas,
comprometidas o daadas;

e) roles y responsabilidades; por
ejemplo, quin es responsable de:

1) la implementacin de la
poltica;
2) la gestin de claves,
incluyendo la generacin de
claves (ver tambin 12.3.2);

f) los estndares a adoptarse para
ocurrencia de un
evento o accin.
la implementacin efectiva en
toda la organizacin.

g) el impacto de utilizar
informacin codificada sobre los
controles que se basan en la
inspeccin del contenido(por
ejemplo, deteccin de virus);
12.3.2 Gestin de
claves

Uso de tcnicas
criptogrficas para
la seguridad del
sistema.
-Polticas de
encriptacin
-Generador de
claves para
diferentes
sistemas
criptogrficos
-Medios seguros
para
transportacin de
claves
-Autenticaciones
mediante
certificados
-ISO/IEC 11770
para la gestin de
claves de
encriptacin
-ISO/IEC 9796 e
ISO/IEC 14888
para utilizacin de
claves pblicas y
firmas digitales
-Tener un servidor que sea el
generador de claves de
encriptacin y que se controle el
acceso fsico al mismo
-Aplicar antes las normas
especificadas en recursos
necesarios
-Manejar tiempos de vida para
contraseas
-Archivar claves para efectos de
auditoria
-Bloquear usuarios que han
dejado de laborar en la
organizacin
12.4 Seguridad de
los archivos del
sistema

Garantizar la
seguridad de los
archivos e
informacin del
sistema.
12.4.1 Control de
software
operacional

Procedimientos
para la instalacin
de software nuevo.
-Personal
autorizado para el
mantenimiento de
software
-Estrategias de
rollback, por
cualquier
dificultad que se
presente
-Copias de
versiones
anteriores al
programa
-Pruebas para
software nuevo
-Cdigo
ejecutable
aprobado y no
cdigo en
desarrollo
-Mantener registro de cada
cambio o instalacin que se
realiza
-Solo personal autorizado
realizara la instalacin de
software, no cualquier empleado
-Siempre realizar copias de
seguridad antes de realizar algn
cambio

12.4.2 Proteccin
de la informacin
del sistema

Medidas de
-Bases de datos de
prueba
-Autorizaciones y
registros para
copiar
-Brindar informacin necesaria a
la base de datos de prueba
-Si se necesita informacin
restringida para una prueba debe
eliminarse al momento de
precaucin para
asegurar la
informacin de la
organizacin
informacin a la
BD de pruebas
finalizacin de la misma
-Llevar un registro de la
informacin copiada a la BD de
pruebas
12.4.3 Control de
acceso al cdigo
fuente del
programa

Proteccin del
cdigo fuente para
evitar la
introduccin de
funcionalidad no
autorizada.
-Reglas de acceso
al cdigo fuente
-Registro de
acceso
-Procedimientos
de cambio para
actualizaciones y
modificaciones
-ISO 10007 e
ISO/IEC 12207
para la gestin del
ciclo de vida de
software
-Limitar el acceso a personal
autorizado
-Llevar un historial de cambios
realizados
-Gestionar niveles de usuarios
-Mantener el cdigo fuente en un
lugar seguro(fsico)
12.5 Seguridad en
los procesos de
desarrollo y
soporte

Mantener la
seguridad de
software y la
informacin del
sistema
12.5.1
Procedimientos del
control de cambio

Controlar la
implementacin de
cambios de un
software
-Documentacin
de cambios
-Pruebas de
sistema
-Controles de
calidad para
software
-Evaluaciones de
riesgo del cambio
-Identificar todo software que
desee ser aplicado
-Cambios realizados nicamente
por personal capacitado
-Actualizar la documentacin del
sistema al final de cada cambio
realizado
12.5.2 Revisin
tcnica de la
aplicacin despus
de cambios al
sistema

Luego de realizarse
algn cambio, debe
realizarse una
revisin tcnica en
la aplicacin de la
empresa para
asegurar que no ha
sufrido cambios
operacionales.
-Personal de
mantenimiento
-Procedimientos
definidos para el
control de la
aplicacin
-Horarios para
pruebas
establecidos
-Realizar pruebas en
procedimientos importante de la
aplicacin
-Asegurarse de cubrir los nuevos
mdulos con el presupuesto de
mantenimiento
-Informar con tiempo al personal
que se realizara una mejora al
sistema
-Realizar pruebas antes de la
implementation
12.5.3
Restricciones
sobre los cambios
en los paquetes de
software.

Explicacin:
No se debe de
promover a las
constantes
modificaciones a
los paquetes de
software que
maneja la empresa,
El software
original, el
mismo
suministrado
por los
vendedores
sin
modificacione
s.
Copia de
software
previamente
1) Realizar una copia del
software original
suministrado por el
vendedor.
2) Cualquier cambio al
software debe de tener
consentimiento del
vendedor; en todo caso si el
vendedor es quien hace los
cambios asegurar la
posibilidad de obtener
dichos cambios como
por lo que se debe
pretender a que los
cambios deben ser
limitados a menos
que sean
necesarios; en caso
de que se hagan
cambios, estos
deben de ser
controlados de
carcter estricto.
mencionado.
Documentacin
de cualquier
cambio/actualizac
in aplicado al
software.
actualizaciones.
3) Documentar cualquier
cambio o actualizacin del
software.
12.5.4 Filtracin
de Informacin.

Explicacin:
Cualquier
oportunidad o
coincidencia de
filtrado de
informacin debe
ser estrictamente
evitado.
Procedimient
os internos de
escaneo
constante del
flujo de la
informacin.
Procedimient
os que
permitan
enmascarar la
conducta del
sistema.
ISO/IEC.
1) Evitar en todo caso el
acceso no autorizado a la
red.
2) Tomar medidas para
protegerse contra cdigos
malware reduciendo el
riesgo de la explotacin de
canales encubiertos.
3) Monitorear constantemente
la utilizacin del recurso de
los sistemas de cmputo.
Monitoreo constante de las
actividades del personal y del
sistema siempre y cuando este
sea con el consentimiento de
algn ente legislativo.
12.5.5 Desarrollo
de software
abastecido
externamente.

Explicacin:
El desarrollo de
software que es
abastecido de
manera externa a la
organizacin, debe
de ser supervisada
por la misma.
Documentaci
n como:
Contratos de
Licencias,
Derechos de
propiedad
Intelectual,
Certificacin
de Calidad.
Ente
regulador, que
est al tanto y
al pendiente
de la
supervisin
del desarrollo
del software.

1) Pruebas antes de la
instalacin para detectar
cualquier malware.
2) Considerar la
documentacin
mencionada en los
recursos necesarios para
este control.
3) Estricta revisin de los
documentos legales, como
contratos, certificados y
derechos de acceso para la
auditoria de calidad y
seguridad.
2.6 Gestin de
la
Vulnerabilidad
Tcnica.

Explicacin:
Buenas
prcticas para la
12.6.1 Control de
las
vulnerabilidades
tcnicas.

Explicacin:
Obtener y
documentar de
Inventario
completo y
actualizado de
los activos
con la
informacin
especifica; en
1) Mantener actualizados los
inventarios de los activos.
2) La organizacin debe de
definir los roles asociados
a la gestin de la
vulnerabilidad tcnica.
3) Una vez identificada una
reduccin de
riesgos
resultantes con
respecto a la
explotacin de
las
vulnerabilidades
tcnicas
mencionadas
con
anterioridad.
manera oportuna
informacin
respecto a las
vulnerabilidades de
los sistemas de
informacin que se
estn utilizando,
evaluar dichas
vulnerabilidades y
tener medidas de
control apropiadas
para tratar riesgos
asociados a esta.
caso de
software
tomar en
cuenta
nmero de la
versin y
personas
dentro de la
organizacin
responsables
del software.
Software o
recursos de
informacion
que se
utilizara para
identificar
vulnerabilidad
es tcnicas.
Parches
evaluados
previamente
como
alternativa en
cuanto a una
vulnerabilidad
.
vulnerabilidad tcnica
potencial que debe de ser
tratada, identificar riesgos
asociados y acciones
viables a tomar.
4) Monitoreo constante del
correcto funcionamiento
del proceso de control.
13. Gestin de un
incidente en la
seguridad de la
informacin.
13.1 Reporte de
los eventos y
debilidades de
la seguridad de
la informacin.

Explicacin:
Asegurar a que
cualquier evento
o debilidad en
cuanto a la
seguridad de la
informacin sea
comunicado de
manera que se
pueda tomar de
la manera ms
ptima una
accin
correctiva
oportuna.
13.1.1 Reporte de
los eventos en la
seguridad de la
informacin.

Explicacin:
Cualquier evento de
la seguridad de la
informacin debe
de ser reportado a
travs de canales
gerenciales de
comunicacin
apropiados.
Procesos de
retroalimentac
in en cuanto
a los
resultados a
los incidentes
despus de
haber sido
tratado.
Procedimiento
s para poder
tratar
apropiadamen
te cualquier
incidente en la
seguridad.
Procedimiento
s para el
reporte de
eventos en la
seguridad de
la informacin
de los
1) Verificar toda la
informacin que se
utilizara para identificar
vulnerabilidades
relevantes.
2) Todo personal debe de
tener presente que en caso
de cualquier evento de
seguridad de la
informacin, tomar la
conducta correcta sin
tomar acciones por cuenta
propia.
3) Desde la capacitacin de los
empleados se les debe de
poner al tanto de las
incidencias de seguridad
para estos ser evitados en el
futuro.
sistemas
informticos.
Contacto para
el reporte de
eventos de
seguridad de
la
informacin.
Tcnicos
responsables
que estn al
tanto de
cualquier
conducta
anmala del
sistema.
ISO/IEC
18044.

13.1.2 Reporte de
las debilidades en
la seguridad.

Explicacin:
Todo usuario
inmerso
directamente en la
organizacin de los
sistemas y servicios
de informacin
reporten cualquier
debilidad de
seguridad
observada o
sospechada en el
sistema o los
servicios en
funcionamiento.

Documentacin
de los reportes de
los usuarios
empleados,
contratistas de la
empresa respecto
a cualquier
debilidad de la
seguridad de la
informacin.
1) Los usuarios deben de
estar capacitados para
desarrollar reportes
formales en cuando a
incidentes de la seguridad.
2) Los usuarios deben de tener
conciencia de que no deben
de tratar debilidades
sospechadas.

You might also like