SEGURIDAD EN
ENDPOINTS
Objetivo de la sesión Contenido
Se espera que el estudiante identifique cuales
son las amenazas mas comunes hacia los
Endpoints y la manera de poder protegerlos.
¿QUE ES UN ENDPOINT?
▪ Un Endpoint o punto final, es cualquier dispositivo que corresponda
físicamente a la parte final de una red.
▪ Los computadores de escritorio, laptops, tablets, smartphones y
dispositivos de oficina de red como impresoras y cámaras de seguridad
también son considerados Endpoints.
Criterios de
Evaluación de
Seguridad
COMMON CRITERIA: CERTIFICACIÓN DE SEGURIDAD
• ¿Es posible demostrar la seguridad de un producto?
• Demostrar que un producto es seguro (libre de vulnerabilidades) es como demostrar que
una ciudad construida junto a un río nunca se va a inundar.
• Sin embargo, sí que es posible asegurar con un determinado nivel de garantía que un
producto satisface unos requisitos funcionales de seguridad.
COMMON CRITERIA: CERTIFICACIÓN DE SEGURIDAD
COMMON CRITERIA: CERTIFICACIÓN DE SEGURIDAD
• Common Criteria es un estándar reconocido internacionalmente para evaluar las
funcionalidades y garantías de seguridad de los productos de IT(ISO 15408).
• Los certificados de Common Criteria cuentan con un reconocimiento mundial e
interprofesional
• Un producto certificado Common Criteria tiene un elemento diferenciador en términos de
seguridad, ya que ha sido evaluado por un tercero bajo una metodología de evaluación
sólida y bien definida.
COMMON CRITERIA: CERTIFICACIÓN DE SEGURIDAD
• Perfil de protección (PP)
• Requisitos funcionales y de aseguramiento específicos
• Se aplica a una categoría de productos, no a uno solo
• Objetivo de Evaluación (TOE)
• El producto o sistema específico que se está evaluando
• Objetivo de seguridad (ST)
• Escrito por el proveedor o desarrollador para explicar las especificaciones funcionales
y de garantía del producto, y cómo cumplen con los requisitos de CC o PP.
• Nivel de Garantía de Evaluación (EAL)
• Calificación combinada de evaluación funcional y de aseguramiento
COMMON CRITERIA: CERTIFICACIÓN DE SEGURIDAD
• Primera Parte: Introducción y Modelo General.
• Segunda Parte: Requisitos Funcionales
de Seguridad.
• Parte Tres: Requisitos de Garantía de
Seguridad
• (establece un conjunto de componentes
de aseguramiento – Niveles de
Aseguramiento de la Evaluación (EAL).
COMMON CRITERIA: REQUISITOS DE SEGURIDAD
• Los requisitos de garantía definen los atributos de seguridad (o contramedidas) que se
deben proporcionar en el sistema de información para que el propietario del sistema pueda
tener un nivel medible de garantía de que los riesgos se han abordado (o mitigado) lo
suficiente.
• Los requisitos funcionales explican las funciones operativas que un sistema de información
debe realizar para ayudar a que los sujetos accedan a los objetos.
Requisitos de seguridad de la
información
Requerimientos funcionales: Requisitos de garantía:
Para definir el comportamiento Para establecer la confianza de
de seguridad del producto o que la función de seguridad se
sistema de TI. desempeñará según lo previsto.
COMMON CRITERIA: PERFIL DE PROTECCIÓN
• El perfil de protección (PP) es una
especificación independiente de la
implementación de los requisitos de
seguridad de la información.
• Objetivos de seguridad
• Requisitos funcionales de seguridad
• Requisitos de aseguramiento de
la información
• Suposición y justificación
COMMON CRITERIA: ST & TOE
• Security Target (ST) es similar a PP.
Es una respuesta del proveedor a PP que
contiene información específica de la
implementación para demostrar cómo el
objetivo de evaluación (TOE) aborda PP.
• Objetivo de evaluación (TOE) es el
producto o sistema específico que se
está evaluando.
COMMON CRITERIA: ST & TOE
• El Nivel de Garantía de Evaluación (EAL) es la calificación combinada de la evaluación
funcional y de garantía.
• – EAL 1: Funcionalmente probado
• – EAL 2: Estructuralmente probado
• – EAL 3: Probado y comprobado metódicamente
• – EAL 4: Metódicamente diseñado, probado y revisado
• – EAL 5: Semiformalmente diseñado y probado
• – EAL 6: verificado, diseñado y probado semiformalmente
• – EAL 7: formalmente verificado, diseñado y probado
• EE. UU. reconoce los productos que han sido evaluados bajo el patrocinio de otros
signatarios y de acuerdo con los Criterios comunes internacionales para el Acuerdo de
reconocimiento de evaluación de seguridad de tecnología de la información (CCRA) solo
para EAL 1-4.
COMMON CRITERIA
• https://www.fortinet.com/corporate/about-us/product-certifications/common-criteria
• https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-platform-
common-criteria
• https://www.cisco.com/web/strategy/government/security_certification/certSecurity_Assuran
ce.pdf
• https://www.paloaltonetworks.com/legal-notices/trust-center/tech-certs
VULNERABILIDADES Y
EXPOSICIONES
COMUNES (CVE)
VULNERABILIDADES Y EXPOSICIONES COMUNES (CVE)
• MITRE comenzó en 1958, patrocinado por la Fuerza Aérea de los EE. UU. para unir a la
comunidad de investigación académica y la industria para diseñar el entorno terrestre
semiautomático, o SAGE, un componente clave de la defensa aérea de la era de la Guerra
Fría.
• Fue fundada como una empresa sin fines de lucro para servir como asesores objetivos en
ingeniería de sistemas para agencias gubernamentales, tanto militares como civiles.
• En 1999 MITRE lanzó el proyecto de Common Vulnerabilities and Exposures (CVE) que
consiste en una base de datos de vulnerabilidades y exposiciones de seguridad de la
información divulgadas públicamente, con el objetivo de identificar y categorizar
vulnerabilidades en software y firmwares.
VULNERABILIDADES Y EXPOSICIONES COMUNES (CVE)
• Antes de que se iniciara CVE en 1999, era muy difícil compartir datos sobre
vulnerabilidades en diferentes bases de datos y herramientas.
• Cada proveedor mantenía su propia base de datos, con su propio sistema de identificación
y diferentes conjuntos de atributos para cada vulnerabilidad y por lo general se mantenían
ocultas al público.
• El objetivo de CVE ha sido el de facilitar el intercambio de información sobre
vulnerabilidades conocidas entre organizaciones y hacerlas accesibles al público, con la
condicionante que se hacen públicas hasta que exista una mitigación para las mismas.
VULNERABILIDADES Y EXPOSICIONES COMUNES (CVE)
Identificadores CVE
• Cada nueva entrada de CVE recibe una identificación única.
• Existen tres maneras de que una vulnerabilidad reciba un nombre único que la identifique:
• Mitre como corporación editora y CNA ( Autoridad de Númeración CVE) Primaria.
• CVE asignados por CNAs autorizados para sus propios productos (por ejemplo,
Microsoft, Oracle, HP, Red Hat, etc.)
• Un coordinador externo, como el Centro de Coordinación CERT, puede asignar
números CVE para productos no cubiertos por otros CNA.
• Más allá de su ID único, cada CVE recibe una fecha de entrada que indica cuándo fue
creado por MITRE, seguido de un campo de descripción individual y un campo de
referencia (CVE-YYYY-NNNNN).
VULNERABILIDADES Y EXPOSICIONES COMUNES (CVE)
Análisis de gravedad CVE
• El Common Vulnerability Scoring System (CVSS) es un conjunto de estándares abiertos
para asignar un número a una vulnerabilidad para evaluar su gravedad.
• Las puntuaciones CVSS oscilan entre 0,0 y 10,0. Cuanto mayor sea el número, mayor será
el grado de gravedad.
• Cada CVE recibe una puntuación, que indica su gravedad de seguridad.
• La puntuación CVSS sigue una fórmula compuesta por varias métricas de seguridad. Las
métricas involucradas en la determinación de la gravedad de una vulnerabilidad incluyen:
• Vector de acceso,
• Complejidad del ataque,
• Confidencialidad de los datos procesados por el sistema que contiene la
vulnerabilidad,
• Integridad del sistema explotado.
VULNERABILIDADES Y EXPOSICIONES COMUNES (CVE)
Sitios de Interés
• https://www.cve.org/
• https://www.cvedetails.com/
• https://www.exploit-db.com/
VULNERABILIDADES Y EXPOSICIONES COMUNES (CVE)
Consultas al grupo
• Solo el 86% de todas las vulnerabilidades de código abierto informadas se incluyen en la
lista CVE de MITRE ¿Qué ocurre con el resto de vulnerabilidades que no son informadas?.
• ¿Qué desventajas puede tener el hecho de que exista una lista de vulnerabilidades
reconocidas para los diferentes fabricantes de productos tecnológicos?.
• ¿Cómo es el proceso de reporte de una vulnerabilidad para ser ingresada a la base de
datos CVE de MITRE?
RECOMENDACIONES
PARA LA SEGURIDAD
DE ENDPOINTS
RECOMENDACIONES PARA LA SEGURIDAD DE ENDPOINTS
1. Es recomendable habilitar los perímetros de seguridad básicos, como la configuración de
firewall para su red para filtrar el tráfico de red, la autenticación del dispositivo, etc.
2. Escanee regularmente los dispositivos en su red en busca de vulnerabilidades y
actualícelos con los últimos parches. Esta práctica protegerá los dispositivos de la mayoría
de las amenazas de seguridad.
3. La autenticación de factor múltiple se puede implementar para autenticar a los usuarios.
4. Con frecuencia educando a los empleados sobre las medidas de seguridad efectuadas en
toda la organización.
5. Se debe aplicar una política estricta de acceso VPN para conectarse a la red de la
organización.
RECOMENDACIONES PARA LA SEGURIDAD DE ENDPOINTS
1. Recopile información regularmente sobre la fecha de vencimiento de la garantía del
hardware de TI.
2. Escanee los sistemas para el uso de software sin licencia.
3. Bloquee las aplicaciones que pueden causar tiempo de inactividad en la productividad y /
o pueden causar asfixia en el ancho de banda. Por ejemplo: juegos, descargas a través de
torrents, etc.
Autoría
Presentación
Ing. Edwin Joel Bulnes
Derechos reservados, Dirección de Educación Continua, Unitec.
Referencias
• Luis Gómez Fernández y Pedro Pablo Fernández Rivero, Cómo implantar un
SGSI según UNE-ISO/IEC 27001:2014, ISBN 978-84-8143-901-4.
• Edward Humphreys, Implementing the ISO/IEC 27001 ISMS Standard, Second
Edition, ISBN 13: 978-1-60807-930-8
Créditos
