Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
interno
para
sistemas
Pgina 1
Pgina 2
Pgina 3
Pgina 4
Pgina 5
Pgina 6
Pgina 7
modifique su contenido.
Un dispositivo de CallBack (devolucin de llamada) requiere que un usuario remoto
llame a la computadora, se identifique, cuelgue y espere a que la computadora llame al
nmero autorizado del usuario. Este control asegura la aceptacin de la transmisin de datos
slo de mdems autorizados. Sin embargo, un dispositivo de call-forwarding (retransmisin
de llamada) puede malograr este control transfiriendo el acceso de un nmero autorizado a
uno no autorizado.
Destruccin controlada de documentos: Un mtodo para hacer cumplir las restricciones
al acceso es destruir los datos cuando ya no se los utilizan ms. Por lo tanto, los documentos
en papel pueden destruirse y borrarse los medios magnticos.
CONTROLES DE APLICACIN
Controles de INPUT
Controles de edicin:
1) Listado de Errores: La Edicin (validacin) de datos debe producir un listado de
errores automtico acumulativo que incluye no slo errores encontrados durante el
procesamiento actual sino tambin errores de procesamientos anteriores no corregidos. Cada
error debe ser identificado y descripto y debe consignarse la fecha y hora en que fue
detectado. Puede ser necesario que las transacciones errneas deban ser registradas en un
archivo en suspenso. Este proceso constituye la base para el desarrollo de informes
adecuados.
2) Los controles de campo son pruebas de los caracteres de un campo para verificar que
son apropiados para ese campo. Por ejemplo, el nmero para la Sistema de Seguridad Social
o para el Sistema Tributario debe contener caracteres de determinado tipo.
3) Los totales financieros resumen sumas en unidades monetarias en un campo de
informacin de un grupo de registros.
4) Un total ciego (hash total) es un total de control sin un significado definido, tal como
el total del nmero de legajo o nmero de factura utilizados para verificar la integridad de los
datos. Por lo tanto, el total ciego para el listado de empleados por parte del departamento de
RRHH puede ser comparado con el total generado al correr el programa de nmina o
liquidacin de haberes.
5) Un Control de Redundancia requiere que se enven datos adicionales que sirvan como
control sobre los otros transmitidos, por ejemplo, parte del nombre de un cliente puede
compararse con el nombre asociado con el nmero de cliente transmitido.
6) Un control de retorno (eco) es un control de input sobre la transmisin en las lneas de
comunicacin. Los datos son devueltos a la terminal del usuario para compararlos con los
datos transmitidos.
7) Los controles de integridad de la transmisin de datos determinan si toda la
informacin necesaria ha sido enviada. El software informa al remitente si se ha omitido
algo. Un control de transmisin suplementario numera y fecha cada mensaje enviado desde
una determinada terminal. Este procedimiento permite la verificacin de la integridad de la
secuencia y el establecimiento de los totales de control para cada terminal.
Controles de Procesamiento:
1) Algunos controles de input son tambin controles de procesamiento, por ejemplo:
lmites, razonabilidad y pruebas de seales.
2) Otras pruebas de la lgica de procesamiento son el control de transcripcin (posting),
sumas cruzadas y balanceo en cero. Un control de transcripcin es la comparacin del
contenido de un registro antes y despus de actualizarlo. Las sumas cruzadas comparan un
gran total con la suma de sus componentes. Un control de balanceo en cero suma los montos
positivos y negativos transcriptos cuyo resultado neto debe ser cero.
3) Deben generarse totales de control entre corrida y corrida (ejemplo: cantidad o
Thomson Reuters
Pgina 8
Pgina 9
Pgina 10
COBIT provee un conjunto de 34 objetivos de control de alto nivel para cada uno de los
procesos de IT. Alcanzar todos los objetivos de control asegura que una organizacin tenga
un adecuado sistema de control para el ambiente de IT. Los procesos de IT los agrupa en 4
dominios:
Planning and organization. Este dominio abarca estrategia y tctica, y concierne a la
identificacin de la forma en que TI puede contribuir mejor al logro de los objetivos del
negocio. Adems, la realizacin de la visin estratgica necesita ser planeada, comunicada y
administrada para diferentes perspectivas. Finalmente, se debe instalar una organizacin
apropiada as como tambin una infraestructura tecnolgica apropiada.
Acquisition and implementation. Para realizar la estrategia de TI, es necesario que las
soluciones de TI sean identificadas, desarrolladas o adquiridas, as como tambin
implementadas e integradas en el proceso del negocio. Adems, los cambios en los sistemas
existentes y el mantenimiento de los mismos estn amparados por este dominio para
asegurarse que el ciclo de vida contine para estos sistemas.
Delivery and support. Se refiere a la entrega efectiva de los servicios requeridos, que
van desde las operaciones tradicionales pasando por los aspectos de seguridad y continuidad
hasta el entrenamiento. Para prestar servicios, se deben establecer los procesos de soporte
necesarios.
Monitoring. Todos los procesos de TI necesitan ser evaluados regularmente a travs del
tiempo por su calidad y el cumplimiento con los requerimientos de control. Este dominio
resuelve as la supervisin del proceso de control de la administracin y el aseguramiento
independiente suministrado por la auditora interna y externa u obtenida de fuentes
alternativas.
Cada uno de los procesos de IT contenidos en estos 4 dominios se describen utilizando la
siguiente informacin:
Objetivos de control de alto nivel.
Objetivos de control detallados.
Criterios de informacin que afectan al proceso.
Los recursos de IT que utiliza el proceso.
Caractersticas tpicas dependendiendo del nivel de madurez.
Factores crticos de xito.
Indicadores clave de performance, es decir "lag indicators". (KPI)
Indicadores clave de objetivos, es decir "lead indicators". (KGI)
COBIT describe que para satisfacer los objetivos del negocio, la informacin que es
entregada a los procesos principales debe tener las siguientes caractersticas:
Requerimientos de calidad.
Eficacia: se ocupa de la informacin que es relevante y pertinente al proceso de negocio
adems de que sea distribuida a tiempo, correctamente, consistentemente y de una manera
utilizable.
Eficiencia: se refiere a la provisin de informacin a travs de uso ptimo (ms
productivo y econmico) de los recursos.
Requerimientos de seguridad.
Integridad: relativa a la exactitud y completitud de la informacin adems de su validez
en relacin a los valores y expectativas del negocio.
Disponibilidad: relativo a la disponibilidad de la informacin cada vez que se la
requiera, es decir ahora y en el futuro.
Confidencialidad: se refiere a la proteccin de la informacin sensible al acceso no
autorizado.
Thomson Reuters
Pgina 11
Requerimientos legales
Cumplimiento: se ocupa de la conformidad con las leyes, regulaciones, arreglos
contractuales donde los procesos del negocio estn involucrados.
Confiabilidad: relativa a la provisin de la informacin apropiada para operar la
organizacin y realizar los reportes financieros.
COBIT define que los recursos utilizados en IT son:
Datos: se entiende desde el sentido amplio de la palabra, internos y externos,
estructurados y no estructurados, sonidos, grficos, etc.
Sistemas de aplicacin: se entiende por todos los procedimientos manuales y
programados.
Tecnologa: se entiende por el hardware, sistemas operativos, redes, administracin de
base de datos, multimedia.
Facilidades: son todos los recursos involucrados para alojar y dar soporte a los
sistemas de informacin
Gente: incluye las habilidades del staff de IT, concientizacin y productividad para
planificar, organizar, adquirir, distribuir, dar soporte, monitorear y evaluar los sistemas de
informacin y los servicios.
Plan: Establecer el SGSI (Sistema de Gestin de la Seguridad de la Informacin).ISO
27001:2005
Definir el alcance del SGSI.
Establecer una poltica que:
Incluya los objetivos de SI.
Considere los requerimientos legales o contractuales de SI.
Establezca los criterios para la evaluacin de riesgos.
Est aprobada por la Direccin.
Establecer una metodologa de evaluacin del riesgo. (ISO 13335-3).
Identificar los riesgos.
Identificar los activos dentro del alcance de SGSI.
Identificar las amenazas en relacin con esos activos.
Identificar las vulnerabilidades de esos activos que pueden ser aprovechadas por esas
amenazas.
Identificar los impactos en funcin de la confidencialidad, integridad y disponibilidad
de los activos.
Analizar y evaluar riesgos.
Establecer frecuencia e impacto.
Estimar el nivel de riesgo.
Determinar si el riesgo es aceptable o debera ser tratado.
Identificar y evaluar las distintas opciones de tratamiento de riesgos
Seleccionar los objetivos de control y los controles del Anexo A de la norma ISO.
27001. Contiene 133 controles, segn 39 objetivos de control agrupados en 11 clusulas.
Aprobar por parte de la Direccin los riesgos residuales.
Definir una Declaracin de Aplicabilidad (SOA) que contenga:
La justificacin de los nuevos objetivos de control y controles seleccionados y los ya
implantados.
Los objetivos de control y controles excluidos del Anexo A de la norma ISO 27001.
Thomson Reuters
Pgina 12
Pgina 13
II. Desarrollo
Las fases propuestas para el SDLC son las siguientes:
1. Fase I: Iniciacin
La iniciacin de un sistema (o proyecto) comienza cuando se identifica una necesidad o
oportunidad de negocio. Se debera asignar a un Lder de proyecto para gestionar el mismo.
Esta necesidad de negocio se documenta en un documento llamado "Conocimiento de la
Propuesta" para su aprobacin y poder pasar a la siguiente fase.
2. Fase II: Desarrollo de la propuesta (Factibilidad)
En esta fase de revisa la factibilidad y la aptitud de la propuesta. El documento "Lmite
del sistema" identifica el alcance del mismo y requiere la aprobacin para comenzar la
siguiente fase. El estudio de factibilidad es bsicamente la prueba del sistema propuesto a la
luz de su viabilidad, alcanzando los requerimientos del usuario, uso efectivo de los recursos y
el costo de la eficiencia. El objetivo del estudio de factibilidad es no resolver el problema
pero obtener el alcance.
Durante este estudio los costos y beneficios se estiman con mucha precisin.
3. Fase III: Planificacin (Anlisis funcional)
La propuesta se desarrolla ms fuertemente para describir cmo el negocio operar una
vez que el sistema se implemente y la evaluacin del impacto en los empleados y
privacidad del cliente. Para asegurar que los productos y / o servicios proveen la capacidad
requerida a tiempo dentro del presupuesto se definen, los recursos del proyecto,
actividades, cronogramas, herramientas y revisiones. Adicionalmente, la certificacin y
actividades de acreditacin de seguridad comienzan con la identificacin de los
requerimientos de seguridad del sistema y la realizacin de una evaluacin de
vulnerabilidades.
La planificacin es la fase vital en la creacin y mantenimiento de aplicaciones de
negocio exitosas. Tambin es uno de los aspectos ms olvidados del desarrollo, porque los
desarrolladores, quienes trabajan bajo presin producen rpidamente aplicaciones a menudo
saltan algunos anlisis y evaluacin de necesidades.
4. Fase IV: Anlisis de requerimientos (Anlisis Funcional).
Se deben definir formalmente los requerimientos funcionales del usuario y delinear los
requerimientos en trminos de datos, la performance del sistema, la seguridad y el
mantenimiento del sistema. Todos los requerimientos se deben definir con un suficiente
nivel de detalle para poder realizar el diseo del sistema. Todos los requerimientos
necesitan ser medibles y probados y relacionados con la necesidad u oportunidad de
negocio identificada en la Fase de iniciacin.
Dependiendo de la aplicacin, los desarrolladores pueden crear un simple prototipo del
software o ms mdulos detallados de todo el sistema que van a producir. El prototipo
muestra a los usuarios cmo se vern las pantallas, las cuales permiten a ellos opinar
sobre la apariencia del sistema y proveer a los desarrolladores mejores comentarios sobre
los requerimientos funcionales.
5. Fase V: Diseo.
Durante esta fase se disean las caractersticas fsicas del sistema. Se establece el
ambiente de operacin, se definen los subsistemas principales y sus entradas y salidas, se
asignan recursos a los procesos. Cualquier requerimiento de entrada del usuario o aprobacin
se debe documentar y revisar por el usuario. Se especifican las caractersticas fsicas del
sistema y se prepara un diseo detallado del mismo. Los subsistemas identificados durante el
diseo se utilizan para crear una detallada estructura del sistema.
Cada subsistema se particiona en uno o ms unidades o mdulos. Especificaciones lgicas
se preparan para cada mdulo de software.
Muchas organizaciones encuentran problemas y riesgos aumentados porque no elaboran
Thomson Reuters
Pgina 14
un plan de Retiro de la aplicacin, durante la etapa de diseo. Este plan debera solucionar
problemas potenciales como cambios de proveedor, que el proveedor se vaya del negocio y
cambios en la tecnologa que no son incompatibles con la direccin de la organizacin. La
organizacin debera revisar este plan una o dos veces al ao o cada vez que la misma realice
cambios en su arquitectura tecnolgica. Se deberan tener en cuenta tambin no slo el
sistema en s mismo sino tambin los sistemas que se vinculan a l.
6. Fase VI: Desarrollo.
Las especificaciones detalladas durante la fase anterior se traducen en hardware,
comunicaciones y software ejecutable. El software debe ser probado por unidad, luego en
forma integrada y reprobado de una manera sistemtica. El hardware se ensambla y prueba.
Un enfoque para el diseo del sistema fsico es el diseo de arriba hacia abajo, que constituye
la prctica de de definicin de un sistema por su propsito general y luego, progresivamente
refinar el nivel de detalle en la forma de una jerarqua. Por lo tanto, comienza con el anlisis
de los objetivos y polticas organizativos amplios, como base para el diseo del proceso. Este
paso requiere una comprensin del ambiente de la entidad y sus actividades significativas. El
prximo paso es determinar las decisiones que deberan tomar los gerentes y la informacin
requerida para ello. Los informes y reportes necesarios, bases de datos, inputs, mtodos de
procesamiento y especificaciones del equipo pueden entonces ser definidas. Por otro lado, el
Diseo Estructurado del sistema fsico es un enfoque modular. Cada mdulo o subsistema
est definido funcionalmente y el grado de interdependencia entre ellos se minimiza. Este
proceso simplifica el desarrollo y aumenta la adaptabilidad de los componentes de sistema
pero exige una cuidadosa definicin de los mdulos y los enlaces e interfases.
El diseo fsico de la base de Datos depende del sistema existente por lo que puede ser
necesario desarrollar nuevos archivos y bases de datos, puede ser factible la modificacin de
una base de datos existente o bien ninguna de ellas. Entretanto el desarrollo de los
programas implica la codificacin de los mismos, de acuerdo con las especificaciones de la
fase de diseo fsico y la posterior evaluacin de los resultados. En este caso podemos
mencionar los enfoques de la programacin estructurada dividiendo a la serie de programas
del sistema en "mdulos" discretos de acuerdo a las especificaciones funcionales y cada uno
de ellos puede ser codificado por un grupo por separado, por lo cual facilita la seguridad,
acelera el proceso de desarrollo y facilita el mantenimiento. Por su parte, el desarrollo de
procedimientos incluye la redaccin de manuales tcnicos, formularios y otros materiales
para todas las personas que utilizarn, mantendrn o trabajarn de alguna manera con el
sistema. Los flujogramas constituyen una ayuda esencial en el proceso de desarrollo para
entender la lgica del sistema, sus entradas y salidas e interfaces.
7. Fase VII: Integracin y prueba
Los diversos componentes del sistema son integrados y sistemticamente probados. El
usuario prueba el sistema para asegurar que los requerimientos funcionales, tal como fueron
definidos en el documento "Requerimientos funcionales", son alcanzados por el sistema
desarrollado o modificado. Previo a instalar y poner operativo el sistema en el ambiente de
produccin, el sistema debe ser sometido a las actividades de certificacin y acreditacin.
Esta fase es crtica en funcin del xito a largo plazo del sistema y debera ser incorporada
en todas las fases del SDLC. El nuevo sistema desarrollado debera ser probado contra los
criterios clave de performance definidos por el usuario con la finalidad de asegurar que el
sistema provee las funciones deseadas y performa a un nivel aceptable. Esto requiere que en
la medida de lo posible, el sistema sea probado bajo condiciones muy cercanas a situaciones
del mundo real.
Existen muchos tipos de pruebas:
* Individuales: cuando los programas son codificados, compilados y llevados a
condiciones de trabajo, se deben probar individualmente con datos de prueba preparados.
Cualquier hecho no deseable se debe notificar y corregir.
* Sistema: Luego de realizarse las pruebas individuales a cada uno de los programas y
Thomson Reuters
Pgina 15
removidos todos los errores, se debe realizar esta prueba con datos reales. Los resultados
deben ser analizados y corregidos todos los errores que pudieran surgir.
Una vez asegurado que el sistema corre libre de errores, se llama a los usuarios con sus
datos reales para mostrar al mismo ejecutando de acuerdo a los requerimientos definidos por
ellos.
8. Fase VIII: Implementacin.
El sistema o las modificaciones al nuevo sistema se instalan y se hacen operativas en el
ambiente de produccin. Esta fase se inicia luego que el usuario ha probado y aceptado el
sistema y contina hasta que el sistema est operando en produccin en concordancia con los
requerimientos definidos por el mismo. Esta fase es cuando la teora se transforma prctica.
Luego de cargado el sistema, comienza la etapa de entrenamiento a los usuarios. Los temas
principales son:
* Cmo ejecutar el paquete.
* Cmo ingresar los datos.
* Cmo procesar los datos.
* Cmo sacar reportes.
La instalacin se puede realizar:
* Corrida paralela: cuando el viejo y nuevo sistema conviven al mismo tiempo durante un
perodo de tiempo con la finalidad de comparar los resultados de ambos sistemas y en caso de
existir diferencias la operacin no se ve afectada.
* Corrida piloto: es cuando el nuevo sistema se instala de a partes por un perodo de
tiempo y se van agregando ms mdulos a medida que el anterior no tenga errores, hasta
completar la instalacin total.
* Fase IX: Operaciones y mantenimiento
Durante la operacin del sistema es monitoreada su performance en concordancia con
los requerimientos del usuario y las necesidades de cambio incorporadas al mismo. La
operacin del sistema se evala peridicamente a travs de revisiones de proceso para
determinar cmo se puede hacer al mismo ms eficiente y efectivo. Las operaciones
continan hasta que el sistema se pueda adaptar eficientemente para responder las
necesidades de la organizacin. Cuando se identifiquen modificaciones o cambios necesarios
a realizar, el sistema reingresa en la Fase de Planificacin.
9. Fase X: Disposicin
Las actividades de esta fase aseguran la terminacin ordenada del sistema y preserva la
informacin vital relativa al mismo en el caso que sea requerida en el futuro. Se pone
particular nfasis en la preservacin de los datos procesados por el sistema, para que los
mismos sean efectivamente migrados al otro sistema o archivados en concordancia con las
regulaciones y polticas aplicables a la gestin de los registros, para futuros potenciales
accesos.
El modelo de Madurez establecido con el enfoque COBIT determina que
III. Conclusiones
Tal como se seal en el cuerpo del presente, el control y la auditora sobre el desarrollo y
disposicin de los sistemas y aplicaciones es de crucial importancia con mltiples
implicancias y finalidades: satisfaccin de los objetivos de control interno, cumplimiento de
requisitos de SOX, cumplimiento de los requisitos de COBIT, Res. 4609 del BCRA, Norma
ISO 27001 e IRAM 17799. Esta problemtica a su vez tiene que ver con los objetivos por los
cuales se justifica la intervencin de la funcin de Auditora Interna en el diseo o examen de
la adecuacin de los sistemas y procesos con el objeto de satisfacerse de los siguientes
tpicos distinguiendo si se trata de situaciones de implantacin de sistemas o procesos
nuevos o modificaciones a los existentes (Control de Cambios):
Thomson Reuters
Pgina 16
Thomson Reuters
Pgina 17