La experiencia de T&E consiste en brindar conocimiento temprano de las fortalezas y debilidades del sistema durante el proceso de desarrollo durante el ciclo de vida del sistema.

Se requiere conciencia para gestionar el riesgo

Datos empíricos para validar modelos y simulaciones.

Pruebas de rendimiento técnico y madurez del sistema.

Determinación de la eficiencia, adaptabilidad y supervivencia de la operación y el mantenimiento.

Identificar, gestionar y reducir riesgos

Se requiere conciencia para gestionar el riesgo

Datos empíricos para validar modelos y simulaciones.

Pruebas de rendimiento técnico y madurez del sistema.

Determinación de la eficacia operativa, adaptabilidad y supervivencia.

Trabajar con organizaciones patrocinadoras para establecer o evaluar estrategias de T&E para apoyar la adquisición/desarrollo del programa;

Proporcionar métodos de T&E que puedan gestionar en profundidad los riesgos;

Monitorear los procesos de T&E y los cambios que puedan ser necesarios;

Evaluar y proporcionar recomendaciones sobre la idoneidad de los planes y procedimientos de prueba para pruebas de desarrollo o pruebas operativas;

Además, se espera comprender la lógica detrás de los procedimientos de adquisición/desarrollo para establecer y ejecutar estrategias de T&E;

Espere comprender las actividades específicas de las pruebas de T&E, como las pruebas de interoperabilidad;

Este grupo suele denominarse equipo de producto integrado de T&E y está formado por expertos en T&E, representantes de los usuarios del cliente y otras partes interesadas;

La estrategia de T&E es un documento vivo y el equipo es responsable de actualizarlo cuando sea necesario;

El equipo debe garantizar que el proceso de T&E incluya estrategias de adquisición y que el sistema cumpla con los requisitos operativos según las capacidades utilizadas;

Por ejemplo, el análisis del registro de enrutamiento es útil para identificar incidentes de seguridad, infracciones de políticas, comportamientos fraudulentos y problemas operativos.

Realizar auditorías e investigaciones forenses;

Apoyar las investigaciones internas;

Establecer una línea de base;

Identificar tendencias operativas e identificar problemas a largo plazo;

Necesidad de equilibrar los recursos limitados de gestión de registros con datos de registro generados continuamente

Producción y almacenamiento de troncos.

Necesidad de proteger la integridad, confidencialidad y disponibilidad de los registros.

Asegúrese de que los administradores de seguridad, sistemas y redes analicen los datos de registro de forma regular y eficaz.

Definir los requisitos y objetivos de registro

Los requisitos y recomendaciones de registro deben generarse junto con los recursos y las técnicas de análisis detalladas necesarias para implementar y mantener el registro.

Protección de registros originales.

Optimice los registros y los requisitos, en función de la reducción percibida del riesgo organizacional y los recursos y el tiempo esperado necesarios para realizar la gestión de registros.

Establecer responsabilidades y roles de gestión de registros

Una arquitectura de gestión de registros abarca el hardware, el software, la red y los medios utilizados para generar, transmitir, almacenar, analizar y procesar registros.

El diseño de un marco de gestión de registros debe considerar las necesidades actuales y futuras del marco de gestión, así como las fuentes de registros independientes en toda la organización.

Los administradores del sistema deberían recibir apoyo adecuado;

Incluyendo difundir información, brindar capacitación, proporcionar un punto de contacto para preguntas y respuestas, Proporcionar orientación técnica específica, herramientas y documentación correspondientes, etc.

Responsabilidades del administrador de registros

Proceso de gestión de registros

Fuente de registro

desafío

prácticas clave

Métodos de monitoreo web diseñados para capturar o analizar cada transacción de cada usuario en la web o aplicación.

También conocido como medición del usuario real, métricas del usuario real o monitoreo de la experiencia del usuario final (EUM).

monitoreo pasivo Método de monitoreo pasivo

Modo monitor

monitoreo proactivo Enfoque de monitoreo proactivo o pre-responsivo

No rastrea las sesiones de usuarios reales

Totalmente controlable por el cliente control total sobre el cliente

Software de gestión de operaciones de Microsoft System Center

Aumentar valor

Patrones de programación inapropiados, como controles faltantes que afectan los datos del usuario, inyección SQL (validación de entrada)

Desajuste de la infraestructura de seguridad: control de acceso excesivo o configuración de cifrado débil;

Errores funcionales en la infraestructura de seguridad: las instalaciones de control de acceso en sí mismas no restringen el acceso al sistema;

Errores lógicos en el proceso de implementación: Por ejemplo, el usuario realiza un pedido sin pagar

25 mejores

Caja blanca (pruebas estructurales/pruebas de caja abierta) frente a pruebas de caja negra (pruebas funcionales/pruebas de caja cerrada)

Pruebas dinámicas VS. Pruebas estáticas Pruebas dinámicas frente a pruebas estáticas

Manual versus automatización Pruebas manuales frente a pruebas automatizadas

superficie de ataque

Tipos de aplicaciones

calidad

Tecnología de soporte

Rendimiento y utilización de recursos

Revisión de seguridad de la arquitectura

Modelado de amenazas -

Análisis de código fuente estático (SAST) y revisión de código manual (análisis de código estático y revisión de código manual)

Análisis de código binario estático y revisión binaria manual (análisis de código binario estático y revisión binaria manual)

Pruebas de penetración manuales o automatizadas

Escaneo automatizado de vulnerabilidades

Herramientas de prueba Fuzz Herramientas de prueba Fuzz

Se recomienda utilizar tecnología de prueba de seguridad pasiva para monitorear el comportamiento del sistema y analizar los registros del sistema.

Durante el mantenimiento del software, las pruebas de parches son muy importantes

Las pruebas de software tienen sus limitaciones y es imposible completarlas al 100%.

Los planes de prueba y los casos de prueba deben desarrollarse lo antes posible en la fase de desarrollo del software.

Las pruebas de seguridad del software generalmente comienzan con pruebas a nivel de unidad y terminan con pruebas a nivel de sistema.

Pruebas estructuradas (prueba de "caja blanca") prueba de desempaquetado

Los casos de prueba se basan en el conocimiento adquirido a partir del código fuente, especificaciones de diseño detalladas y otros documentos de desarrollo;

Cobertura de declaración Cobertura de declaración

Cobertura de decisión (sucursal) Cobertura de decisión

Cobertura de condición Cobertura de condición,

Cobertura para múltiples afecciones Cobertura para múltiples afecciones

Cobertura de bucle Cobertura de bucle

Cobertura de ruta cobertura de ruta

Cobertura de flujo de datos Cobertura de flujo de datos

Los casos de prueba se definen en función de lo que se supone que debe hacer específicamente el producto de software;

Los principales desafíos para los casos de prueba son el uso previsto y la funcionalidad del programa, así como las interfaces internas y externas del programa;

Las pruebas funcionales deben aplicarse a cualquier nivel de prueba de software, desde pruebas unitarias hasta pruebas a nivel de sistema.

Caso normal Caso de uso común

Requisitos de salida forzados de salida,

Robustez Robustez

Combinaciones de entradas Combinaciones de entradas

debilidad debilidad

Proporciona una alta cobertura estructural

Generar datos aleatorios a partir de una distribución definida según el entorno operativo (uso previsto, uso peligroso o uso malicioso del producto de software);

Genere grandes cantidades de datos de prueba y utilícelos para cubrir áreas específicas o áreas de preocupación, proporcionando una mayor probabilidad de identificar condiciones operativas únicas y extremadamente raras que no fueron previstas por los diseñadores y evaluadores;

razón

Objetivo

Pruebas de nivel de unidad (módulo o componente) prueba de unidad

Pruebas de nivel de integración Pruebas de integración (probar las interfaces entre módulos)

Pruebas a nivel del sistema prueba del sistema

Examen de ingreso

Las pruebas del sistema presentarán el comportamiento del producto de software en un entorno específico;

Los procedimientos de prueba, los datos de las pruebas y los resultados de las pruebas deben documentarse de manera que permitan decisiones de aprobación/rechazo;

Los productos de software empresarial son complejos y las pruebas de productos de software deben mantener la coherencia, la integridad y la eficacia;

Las tareas de mantenimiento del software son diferentes del mantenimiento del hardware. El hardware tiene medidas de mantenimiento preventivo pero el software no;

Requiere verificación válida de cambios.

Revisión del plan de validación de software Revisión del plan de validación de software,

Verificación de excepción de evaluación de anomalías,

Seguimiento de identificación y resolución de problemas Seguimiento de identificación y resolución de problemas,

Evaluación de cambios propuestos Solicitar una evaluación de cambios

Iteración de tarea iteración de tarea,

Actualización de documentación Actualización de documentación

Casos de prueba desde la perspectiva de usuarios normales que utilizan el sistema.

Casos de uso desde la perspectiva de alguien con intenciones maliciosas en el sistema.

Asegúrese de que la aplicación funcione como se esperaba y falle si se encuentran errores durante las pruebas directas.

Asegúrese de que su aplicación maneje adecuadamente las entradas no válidas o el comportamiento inesperado del usuario.

Principalmente verifica si los diferentes componentes de la aplicación o el desarrollo del sistema están sincronizados entre sí;

Desde un nivel técnico, las pruebas de interfaz se utilizan principalmente para determinar diferentes funciones como Si los datos se transfieren según lo diseñado entre los diferentes elementos del sistema.

Se utiliza para garantizar la calidad del software.

Descubrimiento, recopilación de información sobre el objetivo (descubrimiento)

Enumerar, realizar escaneo de puertos y métodos de identificación de recursos.

Exploración de vulnerabilidades, identificación de vulnerabilidades en sistemas y recursos identificados.

explotar, intentar explotar una vulnerabilidad para obtener acceso no autorizado

Informar a la dirección y presentar informes y recomendaciones de seguridad a la dirección.

Pruebas de caja negra, comprensión cero, el equipo de penetración prueba sin comprender los objetivos de la prueba

Pruebas de caja gris, pruebas basadas en conocer cierta información relacionada con el objetivo de la prueba.

Pruebas de caja blanca, pruebas basadas en la comprensión de la esencia del objetivo.

0 conocimientos

conocimiento parcial

todo conocimiento

Marque una variedad de números de teléfono para encontrar módems disponibles

Algunas organizaciones todavía utilizan módems como respaldo de las comunicaciones.

La marcación de guerra es una forma de intrusión en la red de una organización diseñada para eludir firewalls y sistemas de detección de intrusiones (IDS).

Los ataques de marcación de guerra implican intentos de obtener acceso a los recursos informáticos y de red internos de una organización a través del acceso telefónico, Esto brinda comodidad a los piratas informáticos.

autotest

Hay vulnerabilidades en la capa del kernel.

Contramedida: asegúrese de que los parches de seguridad para el sistema operativo se implementen rápidamente después de realizar pruebas adecuadas en el entorno para mantener la ventana de vulnerabilidad lo más pequeña posible.

Contramedidas: buenas prácticas de programación y educación para el desarrollo, código fuente para escáneres automáticos, Biblioteca de programación mejorada para utilizar lenguaje fuerte para evitar desbordamientos del búfer

Los piratas informáticos redirigen enlaces simbólicos para obtener acceso no autorizado.

Contramedida: al escribir programas (especialmente scripts), no hay forma de evitar la ruta completa del archivo.

Un descriptor de archivo es un número utilizado por muchos sistemas operativos para representar archivos abiertos en un proceso. Ciertos números de descriptor de archivo son universales y tienen el mismo significado para todos los programas.

Si un programa utiliza descriptores de archivos de manera insegura, puede permitir que un atacante aproveche los privilegios del programa para proporcionar entradas inesperadas al programa o hacer que la salida vaya a un lugar inesperado.

Contramedidas: las buenas prácticas de programación y la educación sobre desarrollo, los escáneres automatizados de código fuente y las pruebas de seguridad de las aplicaciones son formas de reducir este tipo de vulnerabilidad.

No eliminar los factores de vulnerabilidad ambiental antes de ejecutar los procedimientos.

Puede permitir que un atacante lea o escriba datos inesperados o ejecute comandos no autorizados

Contramedidas: buenas prácticas de programación y educación sobre desarrollo, escáneres automatizados de código fuente y pruebas de seguridad de aplicaciones.

Cuando un proceso padre crea un proceso hijo, se debe prestar atención a las condiciones de carrera y la autorización mínima.

Permisos inadecuados de archivos o directorios

Contramedida: verificación de la integridad del archivo, también verifique los permisos de los archivos y directorios esperados

Conciencia utilizada para definir la seguridad de la información actual, las vulnerabilidades y los peligros para respaldar las decisiones de riesgo de seguridad de la información de la organización;

Cualquier esfuerzo y proceso utilizado para respaldar el monitoreo de la seguridad de la información en toda la organización debe comenzar con una estrategia ISCM sofisticada definida por la alta dirección;

Se basa en una comprensión clara de la tolerancia al riesgo organizacional y ayuda a las empresas a establecer prioridades y gestionar la coherencia del riesgo en toda la organización;

Incluir métricas para proporcionar un verdadero significado de la postura de seguridad en todos los niveles organizacionales;

Garantizar la eficacia continua de todos los controles de seguridad;

Verificar el cumplimiento de los requisitos de seguridad de la información impulsados ​​por la misión organizacional/funciones comerciales, leyes y regulaciones nacionales, orientación, estándares de orientación;

Todos los activos de TI de la organización están informados y se facilita la visibilidad de la seguridad de los activos;

Asegurar el conocimiento y control de los cambios en los sistemas y el entorno organizacional;

Mantener el conocimiento de las amenazas y vulnerabilidades.

Monitoreo continuo de seguridad de la información (ISCM) de organizaciones y sistemas de información federales

Los programas ISCM se establecen para recopilar datos basados ​​en indicadores de medición preestablecidos, lo que facilita la explotación de los cambios de información en parte a través de los controles de seguridad que se han implementado.

El monitoreo de riesgos en toda la organización no se puede lograr de manera efectiva confiando en procesos manuales separados o procesos únicamente automatizados:

Las mediciones incluyen toda la información relacionada con la seguridad proveniente de la evaluación y el monitoreo producida por herramientas automatizadas, así como procedimientos manuales, organizada en información significativa para respaldar la toma de decisiones y los requisitos de presentación de informes.

Las métricas deben estar impulsadas por objetivos específicos para mantener o mejorar la postura de seguridad.

Las métricas desarrollan datos a nivel de sistema que dan sentido al contexto de misión/negocio o a la gestión de riesgos organizacionales;

Métricas de medición de información relevante para la seguridad obtenida en diferentes momentos y con distintos niveles de latencia.

Volatilidad del control de seguridadVolatilidad del control de seguridad

Categorías del sistema/Niveles de impacto Categorías del sistema/Niveles de impacto

Controles de seguridad u objetos de evaluación específicos que proporcionan funciones críticasControles de seguridad u objetos de evaluación específicos que proporcionan funciones críticas

Controles de seguridad con debilidades identificadas Controles de seguridad con debilidades identificadas

Tolerancia al riesgo organizacional Tolerancia al riesgo organizacional,

Información sobre amenazasInformación sobre amenazas

Información de vulnerabilidad

Resultados de la evaluación de riesgosResultados de la evaluación de riesgos

Requisitos de presentación de informesRequisitos de notificación

Por ejemplo, la Ley Federal de Gestión de Seguridad de la Información de EE. UU. (Ley Federal de Gestión de Seguridad de la Información FISMA) exige que las agencias federales realicen autoauditorías y auditorías independientes de terceros del sistema de seguridad de la información de la organización al menos una vez al año;

Los profesionales de la seguridad de la información necesitan comprender los requisitos descritos en las normas legales para brindar protección, pero rara vez se logra una protección completa o una gestión de riesgos de los sistemas de información;

Los profesionales de seguridad de la información deben garantizar el alcance y la adaptación adecuados para obtener la cantidad adecuada de controles en el nivel correcto para el sistema de destino.

Para centrarse en las competencias básicas, reducir los gastos e implementar nuevas funciones de aplicaciones más rápidamente, las organizaciones Subcontratación continua de sistemas, procesos comerciales y procesamiento de datos a proveedores de servicios;

La organización actualiza periódicamente el proceso de seguimiento y gestión de riesgos de subcontratación del proveedor de servicios de outsourcing;

Históricamente, muchas organizaciones han confiado en los informes de la Declaración sobre Normas de Auditoría (SAS) 70 para sentirse más cómodos con las actividades de subcontratación. Sin embargo, la SAS 70 se centra en el control interno sobre los informes financieros (ICOFR) en lugar de en la disponibilidad y seguridad del sistema.

El informe SAS70 fue retirado en 2011 y reemplazado por el informe SOC (Control de organización de servicios);

Están familiarizados con los procesos de trabajo dentro de la organización.

alta eficiencia de trabajo

Capaz de identificar con precisión los puntos más problemáticos.

Puede hacer que el trabajo de auditoría sea más flexible y la administración puede cambiar constantemente las necesidades de la auditoría, lo que permite al equipo de auditoría ajustar el plan de auditoría en consecuencia.

Su acceso a los sistemas de información es relativamente limitado.

Existe la posibilidad de que exista un conflicto de intereses que impida la objetividad.

Ha auditado muchos sistemas de información diferentes y tiene una rica experiencia.

Desconocen la dinámica y la política dentro de la organización objetivo. permanecerá objetivo y neutral

Alto costo

Aún tienes que lidiar con los recursos agregados para organizarlos y supervisar su trabajo incluso con una NDA.

Falta de comprensión del funcionamiento interno de la organización.

A diferencia del informe SOC 1/SOC 2, el informe SOC 1 requiere que el proveedor de servicios describa su sistema y defina los objetivos de control y los controles relacionados con el control interno sobre la información financiera;

Los informes SOC1 generalmente no cubren servicios y controles que no son relevantes para los informes ICOFR del usuario.

Muchos proveedores de servicios comenzaron a utilizar los informes SOC1 para servicios básicos de procesamiento financiero en 2011;

Informes de período de tiempo que cubren el diseño y la efectividad operativa Informes que cubren el diseño y la efectividad operativa durante un período de tiempo

Los principios y directrices definen específicamente la seguridad, disponibilidad, confidencialidad, integridad del procesamiento y privacidad;

Proporcionar más allá del control interno sobre la información financiera (ICOFR);

Según las necesidades de los proveedores de servicios y sus usuarios, se puede utilizar un enfoque modular para facilitar Los informes SOC2/SOC3 pueden cubrir uno o más principios;

Si el proveedor de servicios de TI no tiene impacto o tiene un impacto indirecto en el sistema financiero del usuario, se utilizará el informe SOC2;

Los informes SOC3 se utilizan generalmente para informar a una amplia gama de usuarios sobre sus niveles de seguridad sin revelar controles detallados ni resultados de pruebas;

1. Los nuevos empleados deben leer y firmar la Política de uso aceptable (AUP)

2. Confirmar el cumplimiento de las AUP por parte de los empleados mediante la auditoría de las cuentas de los empleados.

3. Recupere la lista de nuevos empleados del departamento de recursos humanos y compárela con las cuentas de empleados abiertas en el sistema por el departamento de TI para garantizar la eficacia de la comunicación entre los dos departamentos.

4. La política también debe aclarar el tiempo de vencimiento de la cuenta, la política de contraseñas y el alcance de la información a la que pueden acceder los usuarios.

Problemas con el uso de cuentas privilegiadas

1. Normalmente, cada cuenta de usuario de computadora tiene derechos de administrador local y el personal de administración y mantenimiento del servidor tiene derechos de administrador de dominio, los cuales son riesgosos.

2. La adición, eliminación o modificación de cuentas deberá estar estrictamente controlada y documentada.

3. Implementar una gestión jerárquica de los permisos de las cuentas de administrador.

4. Utilice cuentas privilegiadas solo cuando sea necesario y utilice cuentas restringidas para el trabajo de mantenimiento diario.

1. Suspender las cuentas que ya no estén en uso.

2. Obtener una lista de egresados ​​de corto y largo plazo del Ministerio de Recursos Humanos, Compare el estado de la cuenta con el sistema informático y elimine las cuentas de los empleados que han estado sin trabajo durante mucho tiempo. Y suspender el uso de cuentas para excedencias de corta duración.

Archivos de usuario

base de datos

datos de correo electrónico

Situación de copia de seguridad de datos de prueba

Analizar diversos escenarios de amenazas que puede enfrentar la organización

Desarrollar un plan para probar todas las copias de seguridad de datos de misión crítica en cada escenario.

Aproveche la automatización para minimizar la carga de trabajo del auditor y garantizar que las pruebas se realicen con regularidad

Minimizar el impacto del plan de prueba de respaldo de datos en los procesos comerciales para que pueda realizarse con regularidad.

Garantizar la cobertura para que todos los sistemas sean probados, pero no necesariamente dentro de la misma prueba.

Registre los resultados para saber qué funcionó y qué necesitaba mejorarse.

Corrija o mejore cualquier problema que haya documentado.

Prueba de lista de verificación Prueba de lista de verificación

Prueba de recorrido estructurada Prueba de recorrido estructurada

Prueba de simulación Prueba de simulación

Prueba paralela Prueba paralela

Prueba de interrupción total Prueba de interrupción total

La capacitación en seguridad se refiere al proceso de enseñar una habilidad o un conjunto de habilidades que permite a las personas desempeñar mejor funciones específicas.

La capacitación en concientización sobre seguridad es el proceso de exponer a las personas a problemas de seguridad para que puedan reconocerlos y responder mejor a ellos.

En el contexto de la seguridad de la información, es el proceso de manipular a los individuos para que realicen acciones que violen los protocolos de seguridad.

El phishing es ingeniería social a través de comunicaciones digitales.

La descarga de un controlador es un ataque automatizado que se activa simplemente visitando un sitio web malicioso.

Los indicadores clave de desempeño (KPI) miden la eficacia con la que una organización realiza una tarea determinada en un momento determinado.

Una medida del riesgo inherente al realizar una determinada acción o conjunto de acciones.

Un informe técnico debe ser más que el resultado de una herramienta de escaneo automatizado o un inventario genérico.

Elementos de un buen informe técnico de auditoría

Los informes a los altos directivos deben ser concisos y fáciles de entender, centrándose en las conclusiones y recomendaciones clave.

El riesgo se describe mejor cuantitativamente y una forma de cuantificarlo es expresarlo en términos monetarios.

Métodos comunes de medición de riesgos

Las revisiones de la gestión deben realizarse periódicamente; de ​​lo contrario, el riesgo de inspección pasará de proactivo a reactivo.

La frecuencia de las reuniones también debe sincronizarse con el tiempo necesario para implementar las decisiones de la revisión anterior.

revisar la entrada

acción de gestión