Seguridad de la Información

La autoevaluación del control (CSA) puede definirse como una técnica de la dirección que asegura a los stakeholders (accionistas, clientes y otros) que el sistema de control interno es confiable. Asegura que los empleados estén consientes de los riesgos del negocio y que realicen revisiones proactivas periódicas de los controles. Esta es una metodología usada para revisar los objetivos clave del negocio, los riesgos involucrados en alcanzar los objetivos de la organización y los controles internos diseñados para administrar estos riesgos en un proceso colaborativo formal y documentado. En la práctica, CSA es una serie de herramientas que abarcan desde simples cuestionarios hasta talleres de facilitación diseñados para recopilar información sobre la organización, solicitándola a los que tienen conocimientos de trabajo cotidiano de un área, así como también a sus directivos. Las herramientas usadas durante un proyecto de CSA son las mismas ya sea que el proyecto sea técnico, financiero

A través de los vídeos de inteco se explica claramente los Sistema de Gestión de la Seguridad de la Información (SGSI) Also Know As Information Security Management System (ISMS). Estos videos enfrentan la familia de normas ISO/IEC 27000, ver siguiente recuadro: 27000: Generalidades y vocabulario, términos y conceptos relacionados con la seguridad de la información, visión gral. De esta famila de estándares, introducción a SGSI, y descripción del ciclo de mejora continua.  27001: Requerimiento del Sistema de Gestión de Seguridad de la Información, norma certificable para los SGSI de las organizaciones. 27002: Código de buenas prácticas para la Gestión de la Seguridad de la Información, describe objetivos de control y controles recomendables en cuanto a la seguridad de la información. 27003: Guía de Implementación de SGSI e información acerca del uso del modelo PDCA y los requerimientos de sus diferentes fases. 27004: Estándar para la medición de la efectividad de la impleme

Alfa y Beta: Es una versión muy clara del sistema de aplicación que puede no contener todas las características que están planeadas para la versión final. Típicamente, el software va a través de dos etapas de prueba antes de que se le considere terminado. La primera etapa, llamada prueba alfa, es a menudo realizada sólo por los usuarios dentro de la organización que desarrolla el software. La segunda etapa, la conocida prueba beta, es un tipo de prueba de aceptación de usuario, requiere generalmente un número limitado de usuarios externos. La prueba beta es la última etapa de prueba, y por lo general implica enviar el producto a los sitios de prueba fuera del entorno de desarrollo para exponerlo al mundo real. La prueba beta acostumbra a ser precedida por un ciclo repetitivo de pruebas alfa. Prueba Piloto: Una prueba preliminar que se enfoca en aspectos específicos y predeterminados de un sistema. No está destinada a reemplazar otros métodos de prueba, sino más bien para proveer una

QAT se enfoca en las especificaciones de documentación y en la tecnología empleada, verifica que la aplicación función como se documentó por medio de pruebas de diseño lógico y la tecnología misma. Asegura que la aplicación reúna las especificaciones técnicas documentadas y los productos. QAT se ejecuta en primera instancia por el dpto. SI. La participación del usuario final es mínima y a solicitud. No se enfoca a las pruebas de funcionalidad. UAT soporta el proceso de asegurar que el sistema esté listo para producción y que el mismo satisfaga todos los requisitos documentados. Los métodos incluyen: Definición de las estrategias y procedimientos de prueba   Diseño de casos y escenarios de prueba Ejecución de pruebas   Utilización de los resultados para verificar la preparación del sistema Los criterios de aceptación son criterios definidos que deben ser satisfechos por un producto para satisfacer las necesidades predefinidas del usuario. Un plan UAT debe ser documentado para

Las siguientes pruebas, relacionadas con uno de los enfoques antes definidos en este blog puden ser efectuadas, basadas en el tamaño y en la complejidad del sistema modificado: Prueba de Unidad: Es la prueba de un programa o módulo individual. Se usan varios casos de prueba que se concentran en la estructura de control del diseño procedimiental. estas pruebas aseguran que la operación interna del programa funciona en conformidad con la especificación. Prueba de Interfaz o de Integración: Es una prueba de hardware o de software que evalúa la conexión de dos o más componentes que pasan información desde un área a otra. El objetivo es tomar módulos probados por unidad y construir una estrutura integrada basada en el diseño. Prueba del Sistema : Se dice que es una seria de pruebas diseñadas para aseguraar que los programas modificados, objetos, esquema de base de datos, etc., que conforman un sistema nuevo o modificado funcionen correctamente de forma colectiva. Los procedimientos

El Proceso de Prueba, ayuda a asegurar que todas las partes del sistema funcionen como se espera, los elementos básicos para las actividades de prueba de software de aplicación son: Plan de Prueba: Se realizan en las primeras etapas del ciclo de vida y son ajustados hasta la etapa efectiva de prueba, estos planes identifican las porciones específicas del sistema que van a ser probadas. Los planes de prueba también especifican los niveles de severidad de los problemas encontrados. El examinador o tester determina la severidad del problema identificado durante la prueba. Dependiendo del nivel de severidad del problema identificado, el mismo puede ser reparado o bien permanecer en el sistema. A menudo los problemas de presentación en la Interfaz se clasifican como de severidad más baja y pueden no ser reparados si las limitaciones de tiempo se convierten en un problema para el administrador (lider, jefe) de proyecto. El sponsor del p