2. CONOCER LA
INSTITUCION CONOCER TI PRIORIZAR ELABORAR EL
Auditor General
PGAS
Evalúa
APRUEBA
NO NO EL PGAS
APRUEBA
EL PGAS
SI
SI SIBC ALTA DIRECION
Modificar el PGAS
Elaborar el Plan
Detallado
COBIT A
Designación de
comisiones Proceso de TI
3. Índice
1. Conocer la Institución: MSC Perú
2. MSC & TI
3. Inventario de los SIBC & Matriz de Priorización
4. PGAS
5. Designación de Comisiones
6. Objetivos de la AS
7. Plan detallado de AS
5. MEDITERRANEAN SHIPPING
COMPANY – Perú
MSC Perú es una empresa de línea
naviera y agencia marítima de
transporte de carga contenerizada.
MSC es una compañía privada,
fundada en 1970 y una de las
compañías líderes en el sector
naviero internacional.
Índice
Oficinas en Lima – San Isidro
6. HISTORIA DE MSC EN PERÚ
MSC Perú comenzó
actividades en 1994
ofreciendo el servicio de/a
la Costa Este de Estados
Unidos de Norte América
al/del puerto del Callao.
MSC Matriz (Ginebra - Suiza)
Empresa que nace en 1970, como
un pequeño armador convencional,
pero en la actualidad es uno de los
líderes en su rubro.
Índice
8. Servicios
MSC del Perú ofrece cuatro servicios
semanales de Línea y un servicio feeder
exclusivo que conecta Ilo (Salaverry,
Chimbote y Matarani) con Callao.
• String 1 / Europa
• String 2 / Américas
• Andes Express / Asia
• Servicio Condor / Todos Destinos
• Feeder Inés
Servicio Feeder Inés
Otros Servicios:
Almacenamiento
Agenciamiento Marítimo
Agenciamiento de Aduana
Transporte
Inspección Fitosanitaria
Índice
9. DATOS DE LA INSTITUCIÓN
• NOMBRE: MEDITERRANEAN SHIPPING COMPANY DEL PERU
• RUBRO: NAVIERA
• SERVICIOS QUE BRINDA: TRANSPORTE MARITIMO,
• VOLUMENES DE VENTA: MAS DE 100000 TEUS.
• VOLUMENES DE VENTA, BALANCES, ORGANIGRAMA, FODA,
CADENA DE VALOR: CONFIDENCIAL.
• PRINCIPALES CLIENTES: QUIMICA NAVA, SOUTHER PERU, MINSUR.
PRINCIPALES COMPETIDORES: SODIMAC, TOTTUS, SAGA
FALABELLA, GLORIA, KIMBERLY CLARK, MAERSK, CCAV.
Índice
11. FUNCIONES POR EQUIPO DE TRABAJO
Coordinación
Oficina
Administrativa
Unidad de
Capacitación
Unidad de
Gestión, Capacidad
y Marketing
12. PLATAFORMA
1. PLATAFORMA
• 1.1. BASE DE DATOS
SQL 2008
TAMAÑO: 10 GB
VOLUMEN DE CRECIMIENTO:
0.05 %
CANTIDAD DE TRANSACCIONES
MENSUALES: 1 MILLÓN
Índice
14. PLATAFORMA
• 1.2. SERVIDOR DE APLICACIÓN
SERVIDOR FISICO CLLWSB01 (5 SERVIDORES
VIRTUALES)
PAGINAS WEB(IIS)
COMUNICACIÓN DE FAX MODEN(FAX
EXPRESS CASTELLE)
PROGRAMA DE TRANSMISION
ELECTRONICA(TCI)
ARCHIVOS (FILE SERVER)
ACTIVE DIRECTORY (ADS)
Índice
15. PLATAFORMA
1.3. DESARROLLO
VISUAL BASIC.NET & C#
1.4 SISTEMA OPERATIVO CLIENTE
WINDOWS 7 ULTIMATE
1.5. SISTEMA OPERATIVO SERVIDOR
WINDOWS SERVER 2008
1.6. HERRAMIENTA DE DISEÑO
RATIONAL ROSE
Índice
16. ARQUITECTURA
• Multicapas – (3)
Es una arquitectura cliente-servidor en el que la
presentación, el procesamiento de la solicitud, y la
gestión de datos son, lógicamente, los procesos por
separado. Por ejemplo, una aplicación que utiliza
middleware de datos de solicitudes de servicio entre un
usuario y una base de datos cuenta con varios niveles de
arquitectura. El uso más extendido de la arquitectura de
múltiples niveles es la arquitectura de tres niveles.
N-tier arquitectura de la aplicación proporciona un
modelo para los desarrolladores para crear una
aplicación flexible y reutilizable. Mediante la ruptura de
una aplicación en niveles, los desarrolladores sólo tienen
que modificar o añadir una capa específica, en lugar de
tener que reescribir toda la aplicación más. Debe haber
un nivel de presentación, un acceso de las empresas o
de nivel de datos, y un nivel de datos.
22. RED DE DATOS
4. Red de Datos
ESQUEMA Y PLANO DE LA RED DE DATOS, ELEMENTOS QUE CONFORMAN LA RED
TALES COMO: FIREWALL, RUTEADORES, SWITCH, SERVICIOS QUE BRINDA CADA
DISPOSITIVO (REDES VIRUTALES, MAPEO DE PUERTOS), ETC. LOS PLANOS DE
FLUIDO ELECTRICO Y DE LA RED DE DATOS DEBEN ESTAR EN LA MISMAESCALA
TANTO SI SE PRESENTAN EN PAPEL COMO EN UN ARCHIVO DE AUTOCAD.
23. DATOS RELEVANTES
• ¿Cómo se da el mantenimiento?
Dependiendo de los requerimientos funcionales de cada departamento, actualmente
se trabaja con 3 proveedores de SW ( cuscar, devwork, sidequest) se cotiza con los 3 y
se toma la mejor opción con entrega de código fuente.
• ¿Desde cuanto se utiliza, quienes lo hicieron?
En el 2009, se desarrolló para reemplazar el sistema anterior que estaba hecho es
FOXPRO y era necesario el cambio debido al desarrollo de la empresa ya que había
muchos requerimientos que no podían ser contemplados por la otra empresa, se
empezó por un desarrollo interno, se contrataron programadores para los primeros
años para los dos primeros módulos pero por tema de tiempo se cotizo con
proveedores externos para agilizar el desarrollo del sw.
• ¿Alguna eventualidad o percances que haya ocurrido?
Debido a que reemplaza al anterior sistema, se tomo como base los requerimientos
funcionales que ya existían y se complementaron con las nuevas necesidades que se
origino a partir del crecimiento de la empresa en el mercado. Por tal motivo los
percances fueron subsanados en la etapa de pruebas del sw.
• Otros puntos a considerar.
Se comenzó con el desarrollo SQL 2005 se esta migrando a 2008 , visual se migro a
2010, y existe una pagina web con la misma funcionalidad para la conexión en
provincia.
31. DESCRIPCIÓN DEL SIBC DE MAYOR
PRIORIDAD – SISAM WEB
Descripción de la Seguridad
Utilizacion de Active
Directory para manejar
las contraseñas de
usuario que son las
mismas que las de
correo electrónico y las
mismas que la de los
sistemas utilizados.
32. DESCRIPCIÓN DEL SIBC DE MAYOR
PRIORIDAD – SISAM WEB
Esquema en Línea y Esquema de Los Manuales
de Usuario
33.
34.
35.
36. OBJETIVO 1
Examinar la confidencialidad e integridad de la información asignada a cada
usuario junto al repositorio de datos.
1.1 Determinar la existencia de un login de acceso al sistema
1.1.1 Comprobar el tiempo de caducidad
1.1.2 Comprobar que no quede registro o almacenamiento alguno de los datos proporcionados al
ingresar
1.1.3 Bloquear la cuenta una vez pasada el límite de intentos fallidos para el ingreso (3 veces)
1.1.4 Comprobar en el terminal el registro y acciones de las cuentas que ingresan fuera de la
intranet.
1.2 Monitorear las acciones realizadas por las cuentas que accedan
Verificar acceso a la información correspondiente
1.3 Asegurar la integridad de la información de mayor importancia
37. OBJETIVO II
Revisar las normas y protocolos que se han implementado para la
manipulación de datos en la aplicación
2.1 Evaluar si el login accede a la información que le corresponde
2.1.1 Monitorear registro de información accedida o solicitada
2.1.2 Comprobar intentos fallidos para el acceso a información protegida
2.2 Analizar el procedimiento de revisión de la información actualizada (ingresos, alteraciones,
eliminaciones) al sistema.
2.3 Revisar los diferentes niveles de autorización por login
2.4 Verificar la desactivación del login por motivos de cese, vacaciones, licencia, etc.
2.5Determinar la seguridad que posee el sistema
2.5.1Verificar las reglas de caducidad y complejidad de contraseñas
2.5.2 Reportes de ingresos por login
2.5.3 Verificar los cambios realizados por login
38. OBJETIVO III
Evaluar la capacitación a los usuarios para entender la
concepción, funciones y diseño del sistema web
3.1 Establecer un cronograma para la capacitación del personal
3.1.1 Coordinar con los creadores de la web una reunión para la explicación
de la concepción
3.1.2 Analizar las funciones y controles que van a tener las cuentas
3.2 Establecer la prioridad y restricciones con la que van a contar todas las cuentas
que accedan al sistema
3.2.1 Asignar diferentes niveles de manipulación
3.3 Evaluar las limitaciones, debilidades que se puedan corregir, así como nuevas
opciones que permitan las mejoras y facilidad de uso
39. OBJETIVO IV
Evaluar si la adaptabilidad del sistema funcione
correctamente al interactuar con otros SIBC.
4.1.- Revisar la interoperabilidad entre los terminales tanto internos como externos.
4.2 –Revisar la extensibilidad, ya que se necesita la posibilidad para aceptar en el
futuro nuevas funcionalidades.
4.3.- Verificar que la portabilidad funcione correctamente
4.3.1 Comprobar el registro de eventos al interactuar con otras terminales.
4.4 Verificar la escalabilidad de los componentes para aumentar o disminuir el
rendimiento o la capacidad a las demandas
4.4.1 Verificar que los registros de rendimiento se encuentren en escalas
óptimas
40. OBJETIVO V
Verificar disponibilidad del sistema web en sus diferentes escenarios.
5.1 Comprobar que el sistema funciona las 24 horas del día, 7 días a la semana.
5.1.1 Verificar el diagnóstico y resolución relacionado a incidencias
5.1.2 Evaluar el impacto de los cambios en el plan de disponibilidad
5.1.3 Comprobar el sistema de respaldo ante posibles incidentes
5.1.4 Optimizar la capacidad de infraestructura de Ti
5.2 Garantizar el acceso a la información toda vez que se requiera
5.3 Evaluar los posibles riesgos
5.4 Evaluar la tolerancia a fallas que ya se ha planificado