Implementaciones de controles posterior a un proceso de reingeniería (página 2)

2.2.3 Suministro de Energía

-Toda empresa debe
poseer un UPS (Uninterruptable Power Supply/Fuente
Ininterrumpida de Energía) para protegerse de cualquier
suspensión o caída del suministro
eléctrico.

-Adicionalmente al UPS debe existir un Generador de
Energía a ser utilizado en casos de emergencia
también, el cual debe ser probado periódicamente
a fin de asegurar su operación.

-Tanto el Generador de energía como el UPS
deben proyectarse a ser utilizados hasta el 70% de su
carga.

-Cabe indicar que el UPS está en constante
funcionamiento, no sólo para soportar la ausencia de
luz por un
periodo determinado sino también en intermitencias o
picos eléctricos. Es importante hacer una correcta
evaluación de las especificaciones que
debe tener un UPS antes de adquirirlo a fin de que este soporte
todos los equipos del centro de procesamiento y afines. Esta
evaluación debe estar a cargo del
Responsable de Sistemas.

-Los equipos deben ser mantenidos
regularmente.

-La energía del centro de procesamiento y
afines debe ser exclusiva y no compartida con otras
áreas.

-En casos de emergencias es importante que el personal del
centro de procesamiento esté familiarizado con los
procesos
respectivos a fin de qué, al momento de trabajar
sólo con energía brindada por el UPS, los equipos
no indispensables sean apagados, a fin de alargar el tiempo de
suministro alterno de energía.

-Como herramienta de emergencia, se debe contar
siempre con linternas a pilas.

2.2.4 Aire
Acondicionado

-El centro de procesamiento debe ser mantenido a una
temperatura
entre 18-19°C, con una humedad entre el 45%-50%.

-Para el centro de procesamiento debe existir
independiente del sistema central
de aire
acondicionado, dos equipos de aire
acondicionado "especiales" de los cuales uno actúe como
respaldo del otro cuando este no pueda operar correctamente. La
característica de estos equipos no es la
común de los aires acondicionados normales. Estos
equipos principalmente acondicionan automáticamente la
temperatura,
la humedad, controlan el fluido de aire y son silenciosos,
evitando de esta forma, daños en las computadoras
y demás equipos que conforman el centro de
procesamiento.

-En casos de contingencias en las cuales no se cuente
con la operatividad del acondicionador de aire principal y a
falta del equipo de respaldo; podrían mantenerse
disponibles ventiladores de pedestales a fin de refrescar los
equipos principales mientras dure la emergencia.

2.2.5 Detección de Agua

Es muy raro que una empresa utilice
detectores de agua en sus
centros de procesamiento no por su ineficacia sino por falta de
conocimiento
sobre la existencia de estos tipos de equipos. Estos
dispositivos son importantísimos para mantener al centro
de procesamiento, lejos de filtraciones de agua, principalmente
en los puntos débiles, como son los lugares cercanos a
los equipos de aire acondicionado.

-Estos dispositivos pueden ser detectores de agua por
sonido o por
sensibilidad. Se pueden usar individualmente de acuerdo a las
necesidades de cada empresa o pueden combinarse, es decir;
pueden usarse en ciertos sectores claves los sensores de
agua y humedad (lugares donde se ubiquen equipos
acondicionadores de aire) y en otros pueden usarse los
detectores audibles (cercanos a griferías o ductos de
agua).

-Las alarmas deben ser mantenidas y probadas
periódicamente para asegurar su
operación.

-De forma complementaria a los sistemas
automáticos, se puede detectar visualmente filtraciones
o emanaciones de agua en los pisos falsos, tumbados o
paredes.

2.2.6 Guardias de
Seguridad

-Los Guardias de Seguridad
deben asegurar la vigilancia permanente de las oficinas y
principalmente del centro de procesamiento y afines. Ninguna
persona no
autorizada podrá ingresar al centro de procesamiento sin
el permiso respectivo.

-Deberán también verificar que el personal de
visita se encuentre en el piso y con la persona
visitada. De igual forma el egreso de visitantes debe quedar
registrado y deberá ser controlado a través de
las tarjetas de
visita y del registro de
firma y hora de salida por parte del visitante.

-Dependiendo de las dimensiones de la empresa y de
la sensibilidad de la información que manejen, se suelen
establecer cámaras de seguridad
por pisos o sectores, las cuales son monitoreadas por grupo de
guardias de seguridad en los sitios de control
destinados para el efecto.

2.2.7 Telecomunicaciones

Se define a las comunicaciones como el arte y la ciencia
de "Comunicar". Este simple concepto se
extiende a las telecomunicaciones, las cuales consisten en
"Comunicar" a través de alguna distancia, utilizando
medios
electrónicos, eléctricos, ópticos, por
cable, fibra o electromagnéticamente. Las
telecomunicaciones son sencillamente, medios de
transmisión, recepción e intercambio de
señales.

-Entre las seguridades que deben observarse en el
ámbito de telecomunicaciones están los Cables de
comunicaciones y eléctricos deben
mantenerse de forma protegida para asegurar que funcionen
adecuadamente.

-Los equipos de comunicación como módems, nodos,
controladores, servidores,
etc. deben estar protegidos dentro del lugar físico
donde se encuentren y en un ambiente
acorde a las especificaciones técnicas proporcionadas
por el manufacturador y/o proveedor del equipo.

-En toda la empresa y
principalmente en el centro de procesamiento, los cables
eléctricos deben estar dentro de canaletas o
tuberías de plástico que es un material no
conductor de energía
eléctrica. Para el caso de cables de redes (transmisor de voz y
datos,
generalmente se utilizan tuberías
metálicas).

-Los cables, sean estos eléctricos o no, deben
estar en sitios perfectamente señalados para el efecto y
ordenados, utilizando los elementos necesarios que se
encuentran en el mercado para
su protección contra circuitos o
daños producidos por negligencia, agua, roedores,
etc.

-Actualmente las empresas
dedicadas al diseño de ambientes, proporcionan paredes
movibles las cuales tienen integrado en la panelería,
las canaletas para cables. Es importante recalcar que este tipo
de panelería debe ser usada fuera del área de
procesamiento, ya que generalmente el material que las recubre
es de tela, por tanto de fácil combustión.

Si bien es cierto que el Administrador
de empresas
encargará al Responsable de Sistemas de su empresa la
ejecución o instalación de cableado
eléctrico o estructurado (para redes), no es menos cierto
que debe conocer sobre cuales serán los puntos que deben
cubrirse en este tipo de instalaciones:

-Instalación eléctrica: Proyecto y
ejecución de obra civil, tendido de ductos
(plástico), tendido de cables. Provisión e
instalación de: tomacorrientes, tableros, supresores de
pico (estabilizadores de tensión-UPS), etc.

-Cableado
Estructurado: Proyecto y
ejecución de obra civil, tendido de ductos
(metálico o plástico), tendido de canaletas,
tendido de cables de voz y datos.
Provisión e instalación de: gabinetes,
conectores, patcheras, hubs, ruteadores, etc. provisión
e instalación de equipamiento informático y su
correspondiente software.

-Servicio de
mantenimiento de redes: Puede incluir todo
el equipamiento informático (Servidores,
computadoras
personales, impresoras,
etc.), como así también el chequeo y
corrección de problemas en
el tendido de la red y sus componentes
activos. En
instalaciones preexistentes, se ofrece el Servicio de
Certificación de la Red.

3. Controles relativos a
los sistemas

3.1 Controles de Acceso
lógico

3.1.1 Necesidad de los
controles

Los Controles de Acceso lógico son de vital
importancia ya que permiten proteger los recursos tales
como programas,
archivos,
transacciones, comandos,
utilitarios, etc.

Definiremos los lineamientos para implementar los
mecanismos de control
sobre el acceso lógico tanto local como remoto, a los
recursos del
centro de procesamiento de
datos y afines.

-A nivel general, los permisos de acceso deben estar
basados en la necesidad del usuario por conocer la información. Esto implica que los
permisos deben ser respaldados y justificados de acuerdo a la
función que desempeña el usuario.

-En casos de emergencia en que los recursos suelen
estar desprotegidos y, en las que se requiere que otra persona
diferente a la autorizada efectúe un acceso
lógico, deberá hacerlo siempre bajo adecuada
supervisión. Posterior a la emergencia
deberá darse de baja ese usuario y clave o reemplazada
con una nueva clave por seguridad.

-Los sistemas de
control de acceso lógico deben contemplar las
violaciones al mismo. Mantener un registro
histórico de todos los accesos inclusive de los intentos
fallidos o violaciones de su seguridad debe producirse en forma
automática.

-Las claves de acceso deben resguardarse en sobres
debidamente sellados y guardados en caja fuerte. En casos de
emergencia, el responsable de la caja fuerte bajo
autorización del Responsable de Sistemas, podrá
entregar a quien este último indique, la clave que
está resguardada. Deberá mantenerse un registro
de los accesos a estas claves respaldadas y las autorizaciones
respectivas.

-Los usuarios son responsables de las claves que
tienen asignadas. Por ningún motivo debe divulgarse o
intercambiarse claves con otros usuarios. Cualquier resultado
de no-cumplimiento de este punto, quedará exclusivamente
bajo responsabilidad del usuario
respectivo.

-La empresa debe establecer un ente que se encargue de
administrar las seguridades, usuarios y claves. Las funciones
asignadas será la de controlar y mantener actualizada la
lista de usuarios y claves asignadas a los diferentes recursos
y de establecer políticas de cambios periódicos a
fin de evitar desviaciones en las seguridades de los
recursos.

3.1.2
Identificación de Usuarios

-Los usuarios no deberán nunca compartir sus
identificaciones como usuarios y sus claves o contraseñas.
Cada nuevo usuario debe ser solicitado y justificado al
Responsable de sistemas y una vez aprobado, deberá ser
canalizado a través del Administrador de
seguridades para su asignación y control
respectivo.

-Es importante que el Responsable de Sistemas
informe tanto
al solicitante como al Administrador de Seguridades, cuales son
los tipos accesos que tendrá el nuevo usuario, así
como también los no accesos, los cuales inclusive
podría abarcar hasta restricciones a nivel de
terminales.

-Ningún usuario puede crearse sin su
correspondiente clave o contraseña (password) ya que este
constituye el único medio de control de
seguridades.

-Las claves deben consistir como mínimo de 6
caracteres alfanuméricos (números y letras), los
cuales serán elegidos por el usuario. En otras ocasiones y
dependiendo de los recursos a los que se tendrá acceso,
las claves son asignadas directamente por el Administrador de
seguridades e informadas al usuario, ejm.: usuarios de red y
claves de red.

-Es importante que el Administrador de usuarios
no tenga dentro de sus registros la
misma clave para otros usuarios. De producirse este caso,
deberá cambiarse la clave inmediatamente e informado al
usuario respectivo de la nueva clave. También debe en
este caso tomar en cuenta los siguientes
factores:

*No deben existir claves de diferentes usuarios
con caracteres iguales en las mismas posiciones, ejm: 123SRRG y
123LRRG.

*Debe estipularse la cantidad de caracteres
numéricos a usarse en la clave.

*Debe estipularse la cantidad máxima de
caracteres.

-Las claves deberán ser cambiadas
mínimo cada 30 días. Para los casos de claves de
usuarios altamente sensitivos deberá evaluarse un
tiempo mayor
de cambio.

-Los intentos fallidos deberían ser
máximo en un total de tres con clave incorrecta.
Cumplidos los tres intentos fallidos, el usuario debe quedar
inhibido. Estos intentos deben quedar registrados en el
sistema para
su posterior control.

-Las claves no deben visualizarse. Su almacenamiento debe ser en forma encriptada
(codificada).

-Cada acceso a cada recurso debe contener una
clave específica y no repetirse.

-Si el usuario considera el cambio de su
clave por perdida de su confidencialidad, debe solicitar al
Administrador de seguridad, la asignación de una nueva
clave inmediatamente.

-Hay programas que
contienen usuario y clave por default (defecto) para facilitar
su instalación. Esta debe cambiarse una vez que el
programa
haya sido instalado.

-Las claves deben respaldarse en sobres de
seguridad y deberán realizarse pruebas
aleatorias para verificar su autenticidad y
actualidad.

3.1.3
Suspensión de Permisos

Los permisos deben ser suspendidos por las
siguientes causas:

-Cuando los empleados se ausenten por
Vacaciones.

-Cuando su usuario y clave no haya sido
utilizado por un lapso de 30 días.

-A evaluación del Administrador de
seguridades y Responsable de Sistemas por accesos en fines de
semana y feriados.

-Cuando supere los intentos máximos de
accesos fallidos a recursos asignados o no.

En cualquiera de estos casos se debe analizar e
investigar los motivos y para rehabilitar el usuario,
deberán solicitarse las autorizaciones nuevamente,
dependiendo del tipo de suspensión aplicada. Para el
caso de suspensiones por inactividad del sistema, este debe
solicitar la re-entrada de la clave
nuevamente.

3.1.4 Acceso a
Datos

-Los datos serán almacenados en medios
magnéticos tales como disquetes, cartuchos o cintas. A
estos datos, solo podrá accesar el personal
autorizado.

-La información impresa debe clasificarse
de acuerdo a su seguridad.

-En caso de accesos fallidos a datos, el sistema
debe mantener dicha información en detalle con el nombre
del usuario, fecha, aplicación, archivos, etc.
A los que se pretendía accesar, así como
también el número de intentos.

-De igual forma el sistema debiera llevar un
control sobre los intentos exitosos posteriores a varios
intentos fallidos. Estos pueden manejarse a través de
logs (archivos de actividades cronológicas) de seguridad
que deben ser revisados periódicamente por el
Administrador de seguridad.

-Las empresas deben diseñar el procedimiento
que les permita asegurar con éxito el Control de las
seguridades de accesos a datos.

3.1.5 Acceso a
Programas y Utilitarios

Los accesos a programas y utilitarios deben
estar segmentado de acuerdo al perfil del usuario. La
clasificación general es:

• Los usuarios del sistema
• Los programadores del sistema
  y,
• Personal de producción.

Los usuarios del sistema son los que
podrán generar transacciones reales, o usar las funciones del
sistema en producción. Podrán también
accesar a los archivos generados por el sistema producto de
las transacciones.

Los programadores solo deben tener acceso al
ambiente de
pruebas o
desarrollo.
No deben tener acceso a transacciones reales o a accesar a
funciones del sistema en producción.

-El personal de producción, debe
asegurarse que acceda solo a la información definida
para cada usuario. Podrá efectuar las tareas definidas
para el área de producción pero previniendo el
acceso a datos mediante cualquier tipo de herramienta de
programación o a través de
programas de aplicación.

-Las bibliotecas
de los programas y utilitarios deben estar separadas tanto para
desarrollo
como para producción.

-Es importante que los programas en desarrollo
también sean mantenidos a nivel de versión y con
los datos de fecha, hora y usuario que lo desarrolló. Es
vital mantener al menos la última y penúltima
actualización, de esta forma en caso de reversión
se podrá ir a cualquiera de las dos últimas
versiones.

-En caso de ser necesario, sí se puede
permitir el acceso de bibliotecas
del ambiente de desarrollo tanto al usuario del sistema como al
personal de producción.

-Antes de que un sistema sea pasado a
producción debe efectuarse una evaluación del
nivel de seguridades que brinda ese programa o
utilitario. Es importante que un Auditor de Sistemas y el
responsable de Control
Interno verifique para determinar si el sistema cumple con
las especificaciones técnicas y contiene las seguridades
y controles adecuados.

-Los cambios que se efectúen posteriores
a programas en producción deben efectuarse de acuerdo al
Control de Cambios.

3.1.6
Controles de Aplicación

Los Controles de Aplicación se
constituyen en aquellos enfocados a controles por los
usuarios y controles por los sistemas. Los controles
por los usuarios están dados sobre los datos de entrada,
datos fijos, ítems rechazados o en espera, datos de
salida. Los controles por los sistemas se enfocan en los datos
de entrada, ítems en espera, y sobre el
procesamiento.

Los controles por los usuarios se refieren a la
responsabilidad que el mismo debe tener en la
preparación y aprobación de las transacciones
(datos de entrada); en la modificación de datos fijos en
los archivos maestros y de tablas del sistema
responsabilizándose por la integridad y exactitud de los
mismos (datos fijos); en el control de las transacciones
rechazadas o en suspenso, las cuales deben ser corregidas
inmediatamente de acuerdo a su fecha contable (ítems
rechazados y en suspenso) y finalmente es el responsable de los
errores o desviaciones presentadas y detectadas en los datos de
salidas.

Los Controles por los sistemas son aquellos que
proveen y garantizan que los datos ingresados son digitados
íntegramente (datos de entrada); que los ítems
rechazados y en suspenso se identifiquen correctamente y se
mantengan pendientes de una solución (ítems
rechazados y en espera); y finalmente que el sistema posea
mecanismos de control del procesamiento para asegurar que la
información fue procesada con los archivos de datos
correctos y además brindando a través de las
diferentes etapas del procesamiento, un seguimiento de la
transacción que permita mantener una adecuada evidencia
de auditoría (sobre el
procesamiento).

Entre los diferentes controles por los sistemas
se pueden citar los de entrada de datos, los cuales
están dados mediante la generación de controles
por transacciones, controles por totales, controles por
secuencia, controles por tamaño de registro,
verificación de clave, etc. Estos controles no deben ser
seleccionados sino mas bien aplicados todos, ya que tienen una
función específica durante todo el trayecto de la
operación de entrada.

• Con los Controles por transacciones se
  establece una aprobación de la misma antes de su
  procesamiento, esto en aprobaciones
  automatizadas.
• Para aprobaciones manuales es
  preferible que esta sea dada al final del procesamiento o
  cuando la transacción ya está completa, ejm.:
  Cuando se efectúa un ingreso de una compra en el sistema
  de compras y la
  aprobación del pago de la misma se realiza antes de
  dicho ingreso al sistema, mediante firma en un documento; no se
  estará seguro de que
  el ingreso se haya efectuado de forma correcta con las
  cantidades, proveedor y demás datos de la
  transacción original. Para evitar fraudes, es importante
  en este caso aprobar o firmar una vez que la transacción
  haya sido completada, es decir al final.
• Existe otro tipo de controles que van dirigidos
  al mantenimiento de la información, respecto
  de cambios de ítems, precios,
  cantidades, etc.
• Con los Controles por Totales se establece un
  registro que asegure que todas las transacciones ingresadas
  sean totalizadas.
• Los Controles por Secuencia son aquellos que
  automáticamente o manualmente va generando una secuencia
  del registro ya sea a nivel de formularios
  pre-numerados o a través de una secuencia generada
  automáticamente por documento que se
  ingresa.
• Los Controles de tamaño de Registro
  confirman que la longitud del mensaje quede registrada de
  acuerdo a los parámetros técnicos establecidos y
  se evite la transmisión de información no
  contemplada en la transacción. En algunos casos
  también puede evaluarse la necesidad de
  transmisión de la información de forma codificada
  la cual hará más difícil el descifrar la
  información. Esto último es muy usado cuando la
  información es altamente sensitiva.
• Los Controles de Aplicación deben en
  todo caso asegurar que los usuarios accesen o afecten
  sólo lo autorizado y definido para cada uno de
  ellos.

3.1.7 Controles de
Actividades del Programador de
Sistemas.

Las Actividades del programador de sistemas
deben asegurar que el programa diseñado cumpla con los
requerimientos solicitados, seguridades e inviolabilidad del
caso. El Responsable de sistemas se encargará de
verificar antes de que el programa sea puesto en
producción, de que el programador haya documentado
debidamente el programa o cambio, que se hayan efectuado las
rutinas de validación y verificación y de que se
hayan completado las pruebas del sistema.

Es importante que se realicen verificaciones de
las entradas y salidas de datos para todos los registros y que
sea imposible la manipulación de algún registro
en particular, por ejm.: Los programadores de aplicaciones
bancarias (cuentas
corrientes o ahorros) podrían programar débitos o
créditos a cuentas sin
que estas sean detectadas a simple vista. Es vital que se
implante un mecanismo de control y verificación que
certifique que el programa en mención cumple con los
requerimientos solicitados y las seguridades del
caso.

3.1.7.1 Casos Reales
sobre accesos no autorizados a sistemas informáticos y
fraude – El
Pentágono, Citibank, Banco Barings de
Londres, Universidad
Spring Arbor de Michigan y Proinco-Ecuador

Caso 1: Acceso al Sistema del
Pentágono.

Debido a las implicancias políticas y estratégicas que
vivió EE.UU. en la crisis con
IRAK, la
noticia se divulgó enseguida. El subsecretario de
Defensa, John Hamre, se apresuró a desmentir que el
acceso del hacker al
Pentágono, haya sido efectuado a sus sistemas secretos.
Puntualizó que si hubieron entradas, pero estas fueron a
la red de información no clasificada. Así mismo
trató de visualizar el ataque como "un juego"
según sus expresiones, con el propósito de
quitarle lo dramático de la
situación.

A los pocos días del ataque, fue detenido
finalmente el joven sospechoso de haber entrado ilegalmente a
las computadoras del Pentágono. El pirata parece ser que
era un israelí llamado Edhud Tenebaum de 18
años cuyo nombre ficticio (nick) es "el analista" y que
entró desde las computadoras y la red de su escuela para
no dejar rastros personales de su paseo virtual por las
instalaciones militares americanas.

Además del Pentágono, el joven
habría pirateado a otros diversos organismos de Israel y
otros tantos de los Estados Unidos.
Las informaciones contrastadas recogidas por estos dos
países habrían dirigido finalmente a descubrir la
identidad
del joven.

Además de "el analista" también se
detuvieron a un grupo de
jóvenes que supuestamente colaboraron en su entrada al
sistema del Pentágono. Una vez que se descubrió
esta entrada, los responsables de la misma pusieron tras la
pista del pirata informático a un total de 47 agentes
del FBI.

Pero producto de
este caso, apareció un documental sumamente detallado
por Discovery Channel durante los primeros meses del año
98 donde se indicaba que el mismo departamento de Defensa, ya
había sido atacado por un hacker en el
año de 1994 pero que por razones de seguridad en dicho
momento, el problema fue poco divulgado.

Como este caso, existen muchos más que
han sido presentados a público en general sobre fraudes
informáticos a entidades financieras, en la cual los
piratas informáticos accesan a las computadoras
centrales de las mismas, manipulando saldos de las cuentas
bancarias a su favor mediante un no tan complejo método,
pero con un gran grupo de gente especializada en este tipo de
fraudes. Conviene entonces que conjuntamente con los avances
tecnológicos, las empresas se preparen y, preparen sus
sistemas, invirtiendo en tecnología de punta que permita disminuir
los riesgos y en
muchos casos eliminarlos por completo.

Caso 2: Fraude a
Citibank

Este caso es el único documentado en la
historia de los
robos a bancos a
través de sus sistemas. El robo lo ejecutó un
pirata informático de nombre Vladimir Levin, de
nacionalidad Rusa, quién ingenió y
diseñó el más conocido robo de la historia en 1994 por un
monto de 10 millones de dólares del Banco
Citibank.

Este caso tuvo un gran despliegue publicitario
tanto en Estados Unidos
como en Europa. La
forma de operar de este hacker (pirata informático) era
accesando al sistema del Citibank y asignando millones de
dólares desde varias cuentas de clientes en
diferentes oficinas de Citibank alrededor del mundo, a las
cuentas de sus cómplices ubicados en: California,
Israel, Finlandia, Alemania,
Paises Bajos y Suiza. Todo esto lo hacía desde San
Petersburgo en Rusia y sin separarse de su teclado. Fue
arrestado por la Interpol en el año de
1995.

Este caso es extraordinario, no solo por el
monto de dinero que
fue robado ni el método
utilizado, sino por el revuelo que causó en la comunidad
Financiera y a la Industria de
Seguridad del Internet.

Con este caso, se renovaron preguntas acerca de
como el crimen informático prevalece y porqué el
sector financiero y comercial son adversos a
reportarlos.

Al respecto surgieron en su momento comentarios
tanto del sector financiero como de los fiscales e
Investigadores del caso. Por su lado el sector bancario a
través de sus representantes indicó que el
incidente de Citibank fue una casualidad y que de acuerdo a la
ley, el sector
financiero debe reportar las pérdidas experimentadas por
estos casos y que, el sugerir que ellos esconden
información es un error. Por otro lado los fiscales e
Investigadores se oponen a estas declaraciones indicando que el
caso no fue simple casualidad y, que en las experiencias
adquiridas trabajando con el sector financiero y comercial
sucede que, cuando ellos ven problemas,
los niegan y cubren todas las evidencias de lo que pasó
con el propósito de evitar perder la confianza que el
público deposita en la industria, y
también para evitar tener problemas con sus
superiores.

Actualmente el FBI de Nueva York desde el caso
de Citibank indican que han podido incursionar en el sector
privado en aproximadamente 500 compañías, y
aunque no han tenido una gran respuesta, saben que el camino
que siguen es el correcto para proteger a las
empresas.

Los crímenes cometidos a través de
computadoras se extienden más allá del robo de
dinero en
efectivo o a través de tarjetas de
crédito. También se propagan
grandemente a robo de secretos comerciales y estrategias
corporativas.

Finalmente, Citibank expresó a
través de Amy Dates, vocera del Banco; que a pesar de
este incidente, no perdieron un solo cliente y que
se alegran de haber tomado muy seriamente el suceso y
que

trabajarán con la justicia en
forma vigorosa para determinar a los responsables de estos
actos.

Caso 3: Fraude a Barings Bank of
London

En Febrero de 1995, El banco con más
años en Londres, Barings Bank se vino abajo con
pérdidas de más de Un Billón de
dólares. El escándalo estremeció al mundo
bancario internacional ya que se produjo por un empleado del
Banco de nombre Nicholas (Nick) William Leeson de 28
años, quién se desempeñaba como Trader
(negociante) del Banco y quién fue culpado por el gran
desastre. Actualmente y después de haber permanecido en
las cárceles de Alemania,
fue extraditado a Singapour donde se sigue el proceso.
Leeson fue el único envuelto en el colapso de Barings
Bank, aunque los investigadores señalan que los
Ejecutivos del Banco fueron también
culpables.

El caso ha sido analizado por políticos,
investigadores y gente de la banca
internacional, y todos coinciden en que el error estuvo en el
mismo banco, al permitirle a Lesson iniciar y terminar una
operación sin ningún tipo de control o supervisión de sus actividades. El era
director tanto del front-desk es decir responsables de las
operaciones;
como del back-office es decir
de la evaluación diaria de los compromisos efectuados,
es decir, el nivel de riesgos
adquiridos. En otras palabras, la misma persona debía
tomar las decisiones y controlar esas decisiones para impedir
que se corriesen demasiados riesgos.

En definitiva, la caída del Banco
Británico se debió a pérdidas acumuladas
por malas negociaciones de Leeson. El estudio de dos oficiales
investigadores reveló que el derrumbamiento de Barings
Bank se debió realmente a la "Incompetencia" en la
Administración y la falta de vigilancia
en tres importantes áreas donde se cometieron
equivocaciones mayores y estas fueron: Sistemas,
Supervisión y Control
Interno.

En las tres áreas se descuido
completamente la importancia del control. Y se indica la
"importancia del control" puesto que Barings Bank tenía
Auditores internos pero no se dio importancia a los informes
presentados por dichos auditores. Era evidente que sus
funcionarios no tenían el
conocimiento y destrezas necesarias para cubrir cada parte
del negocio. Barings Bank contaba con información, pero
no fue usada por negligencia.

Y todo ello parece cierto, ya que la dirección londinense del Barings estaba
informada de las operaciones que
realizaba Leeson, ya que transfirió fuertes sumas
durante los dos meses anteriores a la caída del banco
(400 millones de libras prestados por cerca de veinte bancos
japoneses). Quizá Nick Leeson mintió sobre las
verdaderas razones por las que pedía estas
transferencias, sin embargo, parece extraño la falta de
curiosidad de los directivos en cuanto al destino de
importantes sumas de dinero.

Realmente la catástrofe de Barings pudo
ser evitada. Reportes de Auditoría
Interna del Banco en el año de 1994 (un año
antes del suceso) mencionaron la necesidad de cambios en la
operación del Banco. Si este reporte se le hubiera dado
la importancia del caso, el derrumbe hubiera sido advertido e
impedido ya que, los auditores expresaron en su informe
claramente el peligro de que, Nick Leeson tenga ambas
responsabilidades en la negociación, así como
también su habilidad para infringir el sistema del
banco. Los Administradores del Banco ávidos del dinero
fácil producto de las negociaciones, no siguieron estas
recomendaciones y las consecuencias fueron
dramáticas.

Caso 4: Fraude a la Universidad
(cristiana) Spring Arbor en Michigan.

En Mayo de 1995 se desató otro
escándalo por Fraude. Esta vez le tocó a la
Universidad Spring Arbor ubicada en Michigan. El acusado: John
Bennett de 57 años, cristiano evangélico que
disfrutaba de una reputación intachable en los
círculos altruistas de Filadelfia.

La forma de operar de Bennett consistía
en aplicar el sistema clásico de Pirámide de
Ponzi, el cual permitió a Charles Ponzi despojar de su
dinero a varias personas de Boston las cuales perdieron todos
sus ahorros. Ponzi convencía a la gente de entregar su
dinero a cambio de darles un rédito del 50% al
término de tres meses. Con los fondos de quienes se
animaban a invertir, Ponzi saldaba las cuentas que se iban
venciendo, pero la mayoría de los primeros
"beneficiados" re-invertían sus ganancias. Como era de
esperarse, la gigantesca pirámide acabó por
venirse abajo y miles de personas fueron
estafadas.

El sistema de Bennett en consecuencia era una
pirámide, la cual fue descubierta por Albert Meyer, un
profesor de contabilidad
de la universidad de Spring Arbor y en la cual también
era contador. Meyer vio en los estados de cuenta de la
Universidad, transferencias altas de dinero a una cuenta
bancaria perteneciente a una fundación llamada Herencia de
valores.
Investigando el caso, Meyer fue informado, que Herencia de
Valores era
una fundación que les servía de intermediaria
entre la Universidad y la Fundación Nueva Era (con sede
en Pennsylvania) de la cual Bennett era su Director. Bennett
indicaba a las instituciones incautas que él
repartía dinero de benefactores anónimos.
Así si una institución sin fines de lucro
reunía cierta cantidad en donativos como era el caso de
la Universidad Spring Arbor, "los benefactores" se
comprometían a aportar una suma igual.

Al conocer Meyer esta información, sus
dudas respecto a si era o no una pirámide de Ponzi,
quedaron despejadas. Luego de pasar un tiempo en el cual
él seguía investigando el tema y conversando con
varios funcionarios de Spring Arbor, esta recibió su
dinero con el rédito ofrecido. En estas circunstancias,
la Universidad no podía desconfiar cuando ellos
recibían su dinero crecido y puntualmente, sencillamente
lo tomaban como un préstamo sin garantía, el cual
siempre era devuelto puntualmente.

Meyer entonces agudizó más sus
investigaciones
e incluso llegó a la máxima administración de la Universidad a
exponer su preocupación, pero como respuesta obtuvo de
que " fue duro hacer crecer los fondos y que no necesitaban de
su intromisión". A pesar de ello, Meyer solicitó
al Servicio de Recaudación fiscal
copias de las declaraciones de impuestos.
Aquí pudo observar que Bennett a pesar de recibir a
manos llenas las inversiones,
no había ningún registro de
ellas.

Luego de la serie de investigaciones
y consultas que realizó Meyer, se descubrió
completamente el Fraude. Bennett fue acusado de fraude
financiero y de transferir indebidamente más de 4,2
millones de dólares de las cuentas de la
fundación, a la de sus propios negocios.
Las pérdidas estimadas ascienden a más de 100
millones de dólares.

Caso 5: Proinco Sociedad
Financiera S.A (Ecuador)

En el mes de junio de 1999 se descubrió
un perjuicio de más de cinco millones de sucres contra
Proinco Sociedad
Financiera S.A., por parte de un sujeto que utilizó
ilícitamente la tarjeta mastercard gas #
550141007500776. Aunque no significó mucho dinero,
esté caso fue un ejemplo de como se estafó a esta
entidad ecuatoriana con la utilización de una tarjeta
que por error no había sido anulada.

Este caso no es el único ni será
el último de muchas formas de fraudes con dinero
plástico que se producen a nivel mundial y del cual
nuestro país no es la excepción. Existen
movimientos especializados para fraudes con dinero
plástico, que van desde montaje de cajeros falsos,
clonación de tarjetas, hasta la compra de
números de cuentas de poco movimiento
para sustraer el dinero
sin ser detectado fácilmente. Estos grupos trabajan
regularmente con personal insertado en las mismas instituciones a las que les realizan los
fraudes.

Estas anomalías suelen ser detectados
sólo cuando el cliente
presenta su reclamo a la institución financiera, sin
embargo, muchos de estos casos no son solucionados debido a la
ausencia de control en los procesos.
Normalmente la misma persona que comete el fraude es
quién recibe el reclamo o quién lo procesa, lo
cual difícilmente permite detectar los
fraudes.

3.2 Control de
Cambios

3.2.1 Razones para
establecer un Control de Cambios

Es importantísimo el determinar
mecanismos para dar cumplimiento a un Control de cambios
efectuados en cualquier elemento del ambiente de
producción como pueden ser programas, equipos,
utilitarios, etc. Con esto se da una estructura
de formalidad a la administración de los cambios a fin
de que estos sean evaluados técnicamente y a nivel de
empresa o negocio y, para que los cambios sean incorporados de
forma consistente con la respectiva autorización del
Responsable de sistemas.

Así mismo el control de cambios se
completa con el análisis de impacto en el usuario final
el cual debe estar en pleno conocimiento
de los mismos. Estos riesgos deben ser evaluados y analizados
con antelación.

El control de cambios es una herramienta
fundamental para mantener registro cronológico de lo que
está sucediendo en nuestro sistema computacional o sus
dispositivos. No solo es un medio de información que
permite actualizar la documentación técnica sino
también permite la toma de
decisiones respecto a la solución de fallas o
inconsistencias presentadas posterior a las implementaciones de
dichos cambios.

Como ejemplo se cita un caso sencillo en el
área de facturación de una empresa que no
contempla el control de cambios. Por efectos de las leyes
impositivas una empresa decide eliminar de la
facturación la Retención en la Fuente. Dicho
cambio es solicitado por el Gerente
Administrativo al Gerente de
sistemas. El cambio se realiza y en la siguiente
facturación ya no consta el valor de la
retención en la fuente, pero se determina que el
Subtotal más el Impuesto al
Valor Agregado no coincide con el Total de la factura.

El Gerente Administrativo comunica al Gerente de
sistemas el particular y este último busca al
programador que realizó el cambio para exponerle el
problema. El programador no está, se encuentra de
vacaciones. ¿Cuál considera usted que es el
resultado de este caso?. Pues muchos, pérdida de tiempo,
falta de documentación, imposibilidad de
delegación del trabajo a otro programador por falta de
información, retrasos en la facturación, costos por
incumplimiento de facturación, afectación en el
flujo de
caja y muchos innumerables problemas más. Ahora la
solución del problema era realmente sencilla si se
contaba con la información del Cambio que había
realizado el programador, cuyo trabajo pasó a
producción sin la supervisión y aprobación
debida. El problema fue que el programador al estructurar un
nuevo algoritmo
para el campo Total factura,
tomó solamente el campo del Subtotal y eliminó el
campo de retenciones y lamentablemente el campo del I.V.A
también. Estos inconvenientes podrían haberse
solucionado llevando un Control de los
Cambios.

3.2.2
Procedimiento
de Control de Cambios

Para el caso de los cambios en programas o
utilitarios se seguirá el siguiente
procedimiento.

-Recepción del requerimiento por parte
del usuario autorizado.

– Evaluación del impacto a causarse con
el cambio.

– Aprobación de usuario de los riesgos e
impacto a causarse con el cambio.

– Ejecución del cambio en ambiente de
desarrollo.

– Definición de pruebas del cambio
solicitado.

– Pruebas del cambio por personal de desarrollo
en ambiente de desarrollo.

– Auditoría de
sistemas al cambio a realizarse.

– Control Interno del cambio a
realizarse.

– Depuración del cambio luego de auditoría y control
interno.

– Pruebas del cambio por parte de los usuarios,
en ambiente de desarrollo.

-Aprobación formal del Usuario en el
registro de control de cambios.

– Aprobación formal del Responsable de
Sistemas en el registro de control de
cambios.

-Determinación de Instrucciones y
criterios por escrito, necesarios para la correcta
transferencia al ambiente de producción y su
reversión en caso de que sea necesario
ejecutarlo.

-Determinación de lugar, fecha, hora,
recursos físicos y humanos requeridos para la
implementación del cambio en el ambiente de
producción.

Para el caso de cambios en equipos (hardware) se
seguirá el siguiente
procedimiento.

-Recepción del requerimiento por parte
del usuario autorizado.

-Evaluación del impacto a causarse con el
cambio

-Aprobación de usuario de los riesgos e
impacto a causarse con el cambio.

-Definición de pruebas del cambio
solicitado

-Determinación de Instrucciones y
criterios por escrito, necesarios para el correcto cambio de
hardware.

-Determinación de lugar, fecha, hora,
recursos físicos y humanos requeridos para la
implementación del cambio en el ambiente de
producción.

-Ejecución del cambio.

-Aprobación formal del Usuario en el
registro de control de cambios.

-Entrenamiento
al usuario

-Actualización del inventario de
equipos

-Actualización del inventario de
configuración de equipos y de los planos de la sala de
computación.

-Revisión de contratos de
mantenimiento y garantías para los equipos, de tal
manera que se asegure el soporte necesario para la
configuración efectuada.

3.2.3 Modelo de
Formato para Control de Cambios

3.3 Producción y
Operaciones

3.3.1 Criterios a
aplicarse en los controles de Producción y
Operaciones

Los criterios están dados en la operación
de normas
sólidas, consistentes, confiables y seguras que permitan
entregar el servicio con la mayor calidad.

Estos criterios serán aplicados a los aspectos
organizativos, de programación, seguimiento de la
producción, medios de almacenamiento, documentación y
administración de problemas.

3.3.2 Procedimientos de
la función de Producción y Operaciones.

Para el caso de la
Organización del área de producción y
operaciones se contemplará lo siguiente:

– El personal de operación no deberá
desempeñar ningún rol en la creación o
modificación de programas o aplicaciones o de
sistemas.

– No deberá tener responsabilidades de
actualización del sistema
operativo.

– No deberá tener acceso como usuario a aplicaciones
específicas.

-Deben tener una descripción del cargo y funciones
específicas y ser adecuadamente entrenado para cumplir
con sus responsabilidades.

-Deberá contar con adecuada supervisión para
asegurar el correcto cumplimiento de sus deberes.

Para el caso de la Planeación y seguimiento de la
producción se contemplará lo siguiente:

-Solo las tareas autorizadas serán procesadas con
datos de producción, minimizando así el riesgo de
omisión y con un orden y planificación predecible.

-Es preferible que las actividades de planeación de carga, ejecución y
seguimiento de procesos sean lo mas automatizado posible.

-En casos de que la intervención del operador sea
inevitable, deben entregarse instrucciones precisas para las
actividades a realizar, las cuales deben ser registradas y
analizadas posteriormente.

-En caso de resultados emergentes, se deberá contar
con procedimientos
de contingencia para dar respuesta a dichos resultados.

-La planeación de los procesos debe considerar la
prioridad de este entre las diferentes aplicaciones.

-Deben implantarse controles para prevenir o detectar la
ejecución de tareas no autorizadas por la
planeación de la producción.

-Para los casos en que usuarios requieran de tareas no
establecidas o incluidas dentro de la planeación de la
producción, se debe establecer un procedimiento de
excepción adecuadamente controlado y con las
autorizaciones correspondientes.

-El ambiente de producción y los procedimientos de
operaciones deberán garantizar que sea utilizada la
versión correcta de programas y los archivos
respectivos.

Para el caso de la Protección de medios de
almacenamiento se contemplará lo siguiente:

-Operaciones, es responsable de que los datos almacenados en
medios magnéticos se encuentren adecuadamente
protegidos, controlados y que sean auditables.

-Para controlar la seguridad física de medios
tales como cintas, cartuchos y disquetes, estos deben ser
almacenados en un área protegida, existiendo un registro
de la ubicación de todos los medios magnéticos
que son utilizados en el área de sistemas.

-Deberán registrar todos los ingresos y
salidas de medios magnéticos de la
instalación.

-Los medios magnéticos almacenados deberán
debidamente etiquetados con su contenido, fechas y orden
cronológico.

Para el caso de la documentación se
contemplará lo siguiente:

-Una planeación o cartilla diaria, paso a paso de las
actividades normales del operador.

-Una planeación o cartilla diaria de los procesos con
inicio y fin de cada operación.

-Los procedimientos de contingencia para los procesos

-Los procedimientos de contingencia para las fallas de
hardware, software,
telecomunicaciones.

-Las instrucciones en el manejo de medios magnéticos
y registros de aquellos que ingresan o son retirados de la
sala.

-El registro de problemas del área de operaciones

-El registro de accesos a la sala de computación.

-El responsable del área de sistemas debe asegurar
que toda la documentación requerida para las operaciones
esté completa, correcta y actualizada.

Para el caso de la administración de problemas se
contemplará lo siguiente:

-Todas las fallas operacionales e incidentes anormales,
deberían ser registrados en un Reporte de Problemas, con
los detalles de hora, tipo de problema, síntomas y las
acciones
iniciales realizadas. Cada reporte deberá ser
identificado en forma única y se deberá asignar
lo más rápidamente posible la responsabilidad
para su investigación y resolución.

-Mantener un registro de los problemas el cual deberá
ser revisado periódicamente por el Responsable de
sistemas.

-Todas las llamadas que requieran el soporte de proveedores
o personal de sistemas, deben ser registradas con
información del tiempo de respuesta de tales llamadas y
las acciones
tomadas, para su análisis posterior.

-Debe existir un procedimiento de revisión regular
que incluya un análisis de tendencia de los problemas y
permita asegurar que todos son resueltos.

-Se debería considerar la evidencia registrada en el
sistema de administración de problemas, a objeto de
tomar decisiones relativas a la oportunidad que se realice el
mantenimiento de rutina y reemplazo de equipamiento.

-Todas las soluciones
identificadas como cambios a ser incorporadas en el ambiente de
producción, deberán ser registradas, seguidas y
manejadas por los procedimientos de control de
cambio. Adicionalmente se deberá registrar el origen
de la solución, identificando cual fue el problema o
falla.

-Informar a todos los usuarios afectados por el impacto de
los problemas identificados y de los progresos obtenidos en la
solución del problema.

4. Respaldos y recuperacion de
programas

4.1 Procedimiento de
Respaldos y Recuperación de Programas

-Los Respaldos deberán ser efectuados de acuerdo a la
periodicidad dependiente de su contenido. Es importante que se
mantengan respaldos diarios, semanales, quincenales y mensuales
de información altamente sensitiva. Para el
análisis de la periodicidad del respaldo debe tomarse en
cuenta el volumen de
información perdida en caso de contingencia y la fecha
del último respaldo. Por ejemplo, si el respaldo se hace
diariamente y surge una contingencia un día
miércoles, se perderá información no
respaldada equivalente a un sólo día, partiendo
de la existencia del respaldo diario del día martes.

-Los sistemas
operativos y programas en general deben ser guardados en su
versión original y la que se utiliza en
producción.

-En caso de cambios se requiere que se mantengan respaldadas
siempre las versiones originales, la versión antes del
cambio y la versión producto del cambio,
asemejándose a un esquema generacional de abuelo, padre
e hijo.

4.2 Procedimiento de
Almacenamiento de Medios Magnéticos

-Los respaldos de datos y programas de alta sensibilidad
deben siempre mantenerse en bóvedas externas, a prueba
de fuego. Se escogerán sitios de preferencia uno en la
ciudad donde opera la empresa pero distanciada de la misma, y
otra fuera de la ciudad. Una copia de los archivos claves puede
ser mantenida dentro de las instalaciones de la empresa con las
debidas seguridades, para permitir su utilización en
procesos de recuperación.

-Adicionalmente se deben contemplar controles asociados al
transporte
de dichos respaldos. Estos controles pueden estar dados por uso
de valijas con llave, registros de movimientos de los respaldos
hacia y desde las bóvedas de seguridad o caja fuerte y
el Uso de vehículos de seguridad donde sea
apropiado.

-Los medios magnéticos deben ser etiquetados
adecuadamente de tal forma que permita su obtención y
fácil identificación y recuperación de los
archivos requeridos.

-Normalmente los respaldos que son requeridos y que se
considerarían como información altamente
sensitiva son:

*Programas elaborados por la propia empresa

*Programas adquiridos mediante licencia y que sean sujetos
a actualizaciones permanentemente y/o customizaciones.

*Archivos de Datos: Información contable,
financiera, administrativa, de compras, y
de producción y otros que la empresa estime
sensitivos.

-Los procedimientos de respaldos deben ser continuamente
probados de tal forma que se compruebe la efectividad de los
mismos mediante su restauración y
verificación.

-Así mismo se debe evaluar periódicamente los
sitios de respaldo, su facilidad de acceso y los procedimientos
de control de acceso a los medios magnéticos
almacenados.

-Al menos anualmente deben ser revisadas las cintas,
cartuchos y disquetes mantenidos por largos periodos de tiempo
en las bóvedas de seguridad. Deben ser probados para
constatar su operación.

-Adicionalmente, deben establecerse todos los requisitos que
sean necesarios para implementar los controles básicos
en la recuperación de programas o datos. Estos
serán de responsabilidad del analista que
desarrolló el programa, o del usuario en el caso de
recuperación de Datos. Es importante que el
Administrador de Seguridad de Datos asesore en estos
requisitos.

-Junto con el almacenamiento magnético de programas,
debe considerarse el almacenamiento de documentación que
corresponda a los procedimientos de operaciones para
ejecución de respaldos, Procedimientos para
recuperación de fallas menores usando los respaldos de
la instalación, Procedimientos de recuperación de
fallas mayores usando los respaldos externos, Procedimientos de
Respaldos luego de la Recuperación por fallas menores y
mayores (retorno a la normalidad).

4.3 Modelos de
Formato Control, Recuperación y Almacenamiento de
Respaldos.

5. Controles aplicados
en la
administracion del personal.

La administración
de personal es un área en la que confluyen varias
disciplinas; incluye conceptos de psicología industrial
y organizacional, ingeniería
industrial, derecho laboral,
ingeniería de seguridad, medicina laboral, ingeniería de sistemas, etc. Los temas son
diversos como diversas resultan las disciplinas mencionadas
anteriormente. Por tanto la Administración
de personal se refiere tanto a aspectos internos de la
organización como a externos o
ambientales.

Podremos entonces definir que la Administración de
personal consta de subsistemas independientes como se indica en
el cuadro a continuación:

Estos subsistemas están estrechamente
interrelacionados y son interdependientes, pero a pesar de ello
no existe una forma única de establecerlos, ya que eso va
acorde con la empresa y dependiendo de diversos factores como son
los organizacionales, humanos y tecnológicos.

Para el efecto, se crean políticas o reglas que
permiten dirigir las funciones y asegurar que estas se realicen
de acuerdo con los objetivos
deseados.

Algunas de estas reglas se crean para establecer
"Controles Administrativos" cuya orientación es impedir
que los empleados desempeñen funciones que no le
pertenecen o pongan en peligro el éxito de funciones
específicas.

Los Controles aplicados a la Administración de
personal se centran en todos los subsistemas y principalmente en
los temas de los cuales se hablará en el transcurso de
este capítulo.

5.1 Objetivo de
los Controles Administrativos

Este capítulo trata sobre los controles que
deben establecerse en los puntos sensitivos del área
administrativa y a los cuales se va a centrar la
temática, como son el personal, su contratación,
vacaciones, entre otros.

5.2
Contratación y término de
Contratos

El proceso de Reclutamiento y Contratación del personal
así como de servicios
externos debe estar perfectamente evaluado. Los contratos
deberán contener integrado en sus cláusulas, las
políticas y normas de
seguridad de datos que lleva a cabo la empresa.

El personal de servicio externo deberá ser
evaluado de acuerdo a los mismos criterios de seguridad
aplicados para el personal permanente de la empresa.

Cuando un empleado interno o externo deja de prestar
servicios,
debe suspenderse las autorizaciones que este tenga tanto de
acceso lógico como físico a las instalaciones,
sistemas o datos. El ejecutivo principal del área a la
que pertenecía el empleado es el responsable de informar
de acuerdo a las políticas que establezca la empresa, la
ausencia permanente del empleado.

El Departamento Administrativo por su parte
deberá revocar todos los permisos de acceso que haya
tenido el empleado, así como recuperar las tarjetas
magnéticas de acceso y credenciales de la empresa e
inhabilitarlas. Deberá verificarse la devolución
de toda la documentación de carácter confidencial
que haya sido manejada por el empleado.

5.3 Políticas
Administrativas

5.3.1
Vacaciones

El personal que deba tomar vacaciones y principalmente
del área de sistemas de la empresa, lo realizará
conforme a las disposiciones internas. Se sugiere que dicho
personal no haya dejado de tomar por propia voluntad sus
vacaciones por un periodo de 2 años. Algunos fraudes
informáticos tienden a descubrirse cuando quienes los
comenten toman vacaciones; tiempo en el cual no tienen acceso
al sistema o son reemplazados mientras duran sus vacaciones.
Cabe indicar al Administrador de Empresas que este es un punto
de seguridad básica que debe tomar muy en cuenta dentro
de los controles administrativos.

5.3.2
Entrenamiento

El personal de sistemas debe acogerse al plan de
entrenamiento que la empresa tenga, siguiendo
los estándares y procedimientos de seguridad de datos y
a los aspectos específicos de seguridad de su puesto de
trabajo.

5.3.3 Uso de Recursos
Computacionales

El uso de recursos computacionales para asuntos
personales debe quedar prohibido.

El software que cada usuario opere debe ser asignado
de acuerdo a su utilización y el cual debe constar con
las licencias respectivas.

Los empleados deben estar familiarizados con el
almacenamiento de datos de carácter sensitivo o
confidencial.

Cabe indicar que cada usuario es responsable por el
equipo asignado, software utilizado, datos contenidos en
él y utilitarios que opere.

La empresa debe establecer políticas y
reglamentos claros respecto del uso de software ilegal (sin
licencia) y los no correspondientes a los estándares de
la empresa. De igual forma la empresa debe establecer un uso y
propiedad
claramente establecidas sobre los programas elaborados o
desarrollados por personal interno, lo cual normalmente se deja
reglamentado dentro de los contratos de trabajo.

6.
Conclusiones

– Todo proceso de la empresa debe contener actividades
de control y seguridad. Cualquier proceso de la empresa con o sin
la aplicación de Reingeniería no puede permanecer sin los
controles y seguridades tanto en sus datos como en sus
componentes.

– La ausencia de controles se presenta SIEMPRE en un
proceso Reingeniado y CASI SIEMPRE en procesos sin ningún
tipo de aplicación de herramientas
de mejoras de la eficiencia y
productividad.
La Reingeniería es una herramienta
metodológica excelente, viable y con grandes resultados y
mejoras dramáticas, pero no es menos cierto que deja a los
procesos frágiles y débiles, ya que, en su
afán de eliminar actividades que no agregan valor; crean
un proceso ausente de controles satisfactorios y por consiguiente
indispensables. De igual forma, procesos que no hayan pasado por
Reingeniería pueden presentar ausencias de controles si
estos no han sido considerados
estratégicamente.

 - El modelamiento del comportamiento
humano no es SUFICIENTE para asegurar niveles de controles y
seguridades satisfactorias. Existen muchos precursores de nuevas
técnicas y metodologías dirigidas al modelamiento
del comportamiento
humano y opuestos a los controles y seguridades habituales. El
modelamiento humano no es "suficiente" para asegurar que no se
cometerán errores o fraudes en los procesos. El
modelamiento humano aplica en temas marketeros,
estratégicos y de relaciones
humanas en los cuales son muy útiles, pero estos no
aplican en términos operativos y de
seguridades.

 -Finalmente, los beneficios de tener un
sistema de seguridad nunca podrán ser medidos
completamente, porque la mayoría de las empresas no
sabrán realmente "CUANDO" alguien tratará de
quebrantar sus seguridades. Sin embargo, es fácil
determinar objetivamente que los beneficios serán grandes,
producto de los costos evitados.
Es entonces, en estas circunstancias, donde los sistemas de
seguridad son "Invaluables. Las únicas ventajas y
desventajas que podrían usted encontrar en los sistemas de
seguridad están dadas en la alternativa de seguridad que
usted escoja e implemente, la cual le brindará mayor o
menor seguridad a sus procesos. La otra alternativa que se puede
ofrecer, es la de sencillamente no tener ningún sistema de
seguridad; lo cual resultaría absolutamente
negligente.

7.
Recomendaciones

• El administrador de empresas debe recordar que los
  procesos manuales o
  automáticos deben ser controlados adecuadamente y
  suficientemente sin caer en la negligencia o en el exceso.
  Aquí en este trabajo se ha brindado una herramienta que
  le permita al menos poder
  elaborar una lista de los puntos débiles en su empresa y
  saber que debe controlarlos. Usted cree que todo en su empresa
  marcha bien y no necesita absolutamente nada de lo sugerido en
  este trabajo? Si su respuesta es afirmativa, le recomiendo que
  lea el trabajo
  nuevamente si ya lo leyó;
  luego reúnase con su ejecutivo de Sistemas que es el
  mayormente involucrado en la implantación de controles y
  seguridades de datos, y pídale que le cuente
  detalladamente que hace cada área de departamento de
  sistemas. Le aseguro, que se quedará usted sorprendido
  de conocer que puede aplicar cada punto de su lista y de que
  podrá entrar a ese fabuloso mundo; que era antes
  desconocido e inentendible por usted.
• El administrador de empresas debe estudiar todas las
  alternativas y, si elige la Reingeniería; debe saber
  qué el nuevo proceso rediseñado debe equilibrarlo
  con una implantación de controles y seguridades
  suficientes y satisfactorias. Talvez no podrá efectuarlo
  con el mismo personal de Reingeniería, ya que los
  conceptos de Reingeniería y controles no comulgan mucho
  que digamos. Recomiendo entonces que el administrador consulte
  a su responsable de Sistemas y a su responsable de
  Reingeniería para llegar a un acuerdo tanto a nivel de
  productividad y eficiencia del
  proceso como también de sus seguridades.
• El Administrador de Empresas debe involucrarse
  más en todos los procesos de su empresa, tanto
  administrativos, operativos y de sistemas. Solo así
  tendrá una idea total de como se une cada eslabón
  de la cadena de procesos de su empresa.
• No importa cuanto usted invierta en seguridad de
  sistemas para proteger sus redes, componentes o datos, nunca
  piense que será una cantidad "suficiente" ya que siempre
  los adelantos tecnológicos exigen más para
  mantener fuera a los intrusos. Con esto entonces no verá
  la adquisición de seguridad como un gasto, sino como una
  inversión.

8.
Bibliografia

-Seguridad de Datos, Metodología Price Waterhouse Coopers
1992

-Plan de
Contingencias, Metodología Price Waterhouse Coopers
1997

-Como Hacer Reingeniería, Raymond L.
Manganelly y Mark M. Klein

-Administración de Recursos Humanos,
Idalberto Chiavenato 1994

-Administración de Empresas (teoría
y práctica, segunda parte), Agustin Reyes Ponce
1994.

-Revista "Mundo
Informático" Edición Abril 1998

-Revista
"Selecciones" Edición Junio 1996

-Diario el Universo
"Sección Sucesos" Julio-5-1999

Sitios de Internet para
consultas:

Agradecimiento

Mi Mami
Econ. Carlos Izurieta
Jenny Anchundia de Andrade
Washington Rodríguez
Carlos A. García
Victor M. Serrano
Oscar Ponce de León

Gracias

A todos ellos……… por su apoyo emocional,
su predisposición y colaboración para la
culminación de este trabajo.

Y un agradecimiento muy especial a Dios, quién me
ha dado la fortaleza necesaria para superar todos los
obstáculos.

A mi Mami…

**********

ahora la medallita estará
completa…

Trabajo enviado y realizado por:
Sonnia Rosado Garcia
28 años
Ingeniera comercial
(administradora de empresa)
Ecuador,
Guayaquil
sonnia_ros[arroba]hotmail.com
srosado[arroba]uole.com