Conceptos fundamentales de seguridad

Conceptos Fundamentales de Seguridad

Amenaza, vulnerabilidad y riesgo no son sinónimos. La pregunta útil es qué podría pasar, por dónde y con qué consecuencias; después elegimos controles. Primero el mapa, luego los sellos.

Riesgo: Posibilidad de sufrir consecuencias adversas, considerando la probabilidad y el impacto de un escenario. No es el evento en sí.
Amenaza: Cualquier circunstancia o evento que pueda afectar negativamente a los activos.
Vulnerabilidad: Debilidad que puede ser aprovechada por una amenaza.

Dado que cada empresa valora activos específicos, tienden a diferir en el modo en que interpretan y abordan el riesgo. Una manera de interpretar el riesgo es considerar los posibles efectos que los eventos negativos pueden tener en una empresa. Otra forma de presentar esta idea es con el siguiente cálculo:

PROBABILIDAD x IMPACTO = una simplificación para ordenar el RIESGO. Multiplicar escalas ordinales no produce automáticamente una medida cuantitativa.

Los dos factores de riesgo comunes son las amenazas y las vulnerabilidades. El riesgo de que un activo sufra daños depende en gran medida de si una amenaza aprovecha las vulnerabilidades.

Categorías de Amenazas

Podemos distinguir acciones intencionales de sucesos accidentales. Es una entrada didáctica, no una taxonomía exhaustiva: también existen causas estructurales y ambientales.

Amenaza Intencional: Por ejemplo, un hacker malicioso que obtiene acceso a información confidencial al atacar una aplicación mal configurada.
Amenaza Involuntaria: En cambio, un empleado que sostiene la puerta abierta para una persona desconocida y le otorga acceso a un área restringida.

Categorías de Vulnerabilidad

Aquí agrupamos ejemplos técnicos y humanos; no son las únicas categorías ni todo error de una persona es por sí solo una vulnerabilidad explotable.

Vulnerabilidad Técnica: Por ejemplo, un software mal configurado que permita a una persona no autorizada acceder a datos importantes.
Vulnerabilidad Humana: Mientras tanto, un empleado olvidadizo que pierde su tarjeta de acceso en el estacionamiento.

CIA TRIAD

Confidentiality

La confidencialidad apunta a proteger la información sensible de intrusos o usuarios no autorizados.

Ejemplos de controles y capacidades:

Encriptación
- Convertir información en no legible para usuarios no autorizados.
Authenticación
- Asegurar la identidad de quién está intentando acceder al sistema o información. Generalmente con credenciales (password/biométrica/etc)
Control de acceso
- Definir y regular que recursos o información pueden acceder ciertos usuarios y bajo qué circunstancias

Integrity

La integridad busca impedir o detectar modificaciones y destrucción indebidas de la información; no es lo mismo que confidencialidad. Crucial para mantener consistencia, precision y fiabilidad en los sistemas y la información.

Ejemplos de controles y capacidades:

Checksums
- Permiten detectar cambios al comparar con una referencia confiable. Un checksum común detecta errores, pero no autentica el origen ni resiste por sí solo a quien puede cambiar dato y checksum
Permisos de archivos
- Asegurar que sólo los usuarios autorizados tengan la habilidad de modificar o borrar archivos específicos
Firmas digitales
- Técnica criptográfica que puede ser usada para autenticar la fuente e integridad de la información o mensajes.

Availability

La disponibilidad es el acceso oportuno y fiable a información y servicios para quienes lo necesitan y están autorizados. No equivale a eficiencia computacional

Ejemplos de controles y capacidades:

Redundancia
- Duplicados o respaldos de sistemas o archivos críticos que pueden ayudar a recuperar disponibilidad; necesitan pruebas de restauración y no garantizan continuidad por sí solos
Tolerancia al fallo
- Capacidad del sistema de continuar funcionando aun cuando hayan ciertas fallas
Respaldos
- Copias regulares de la información para prevenir pérdidas en caso de catástrofe (malwares, desastres naturales, fallas del sistema)

Los planes de seguridad se basan en tres elementos

Assets, Threats y Vulnerabilities

ASSETS Un asset (activo) es un item percibido como de valor para la organización.
- El edificio, equipos, información, empleados.
THREATS Los threats (amenazas) es una circunstancia o evento que tiene un impacto negativo en los activos.
- Ataques directos, phishing, filtraciones
- Pueden ser involuntarios o intencionales VULNERABILITIES Las vulnerabilidades son debilidades que pueden ser explotadas por una amenaza.
- Contraseñas no seguras, privilegios mal administrados, configuraciones por defecto.
- Pueden ser técnicas o humanas

imagen Ejemplo de un inventario de activos conectados en mi casa

La información tiene tres estados

En uso
- Datos que están siendo procesados o utilizados, por personas o programas
En tránsito
- Que está viajando de un punto a otro (una respuesta a un correo electrónico)
En descanso
- Datos almacenados. No depende de cerrar una sesión: pueden coexistir copias almacenadas, en uso y en tránsito

D.A.D.

Mnemotecnia para recordar fallos de CIA; no una clasificación exhaustiva de incidentes.

Disclosure
- La divulgación no autorizada afecta la confidencialidad; publicar información autorizadamente no constituye ese fallo
Alteration
- La alteración indebida afecta la integridad; una actualización legítima no es por definición un fallo
Destruction/Denial
- Destruir la información haría que esta ya no esté disponible, lo mismo el denegar su acceso a quien lo necesite

ISO/IEC 19249

La ficha de ISO/IEC TS 19249:2017 confirma que es un catálogo de principios arquitectónicos y de diseño. Las listas siguientes son mi resumen didáctico del material de estudio; falta contrastar nombres, cantidad y detalle contra el texto normativo completo.

Separación de dominios: Cada componente relacionado se agrupa en una sola entidad. Cada entidad se le debe asignar un grupo común de atributos de seguridad.
- Por ejemplo: los niveles de seguridad de los procesadores x86: El kernel del SO funciona en el ring 0 (más privilegio), pero las aplicaciones corren en el ring 3 (menos privilegio). El ejemplo es esquemático y no cubre todos los modos de ejecución ni virtualización.
Realizar capas: Un sistema estructurado en capas se vuelve más fácil de imponer políticas de seguridad en distintos niveles.
- Por ejemplo: En el Modelo OSI, cada capa provee de un servicio específico a la capa que le precede.
Encapsulación: Simplificar los métodos a realizar. Por ejemplo en la programación orientada a objetos (OOP), escondemos implementaciones de bajo nivel para prevenir manipulación directa y proveemos de un método específico para ese objetivo.
- Por ejemplo: Una API es un método de encapsulación.
Redundancia: Introducir capacidad alternativa puede mejorar disponibilidad. No garantiza integridad ni evita fallos comunes entre réplicas.
- Por ejemplo: un servidor con dos PSU. Si una falla, el sistema continua funcionando.
Virtualizacion: Compartir el hardware para múltiples sistemas operativos. Esto permite tener entornos de prueba, potenciar el alcance de la seguridad, análisis de material desconocido en un entorno controlado, cuyo aislamiento debe evaluarse y la observación controlada de programas maliciosos.

Como resumen de diseño seguro, con la atribución normativa pendiente:

Menor privilegio: Respondiendo la pregunta "¿quién puede acceder qué?". El principio enseña que debes proveer el mínimo de permisos a alguien para que pueda realizar la tarea necesaria.
- Por ejemplo: Una persona necesita leer un documento para realizar su trabajo. Sólo le damos permisos de lectura y no de escritura.
Minimizar superficie de ataque: Reducir interfaces, servicios y permisos innecesarios limita oportunidades de ataque. No hace falta demostrar una vulnerabilidad concreta para retirar una exposición que no necesitamos.
- Por ejemplo: Al realizar un hardening Linux de un SO, deshabilitamos todos los servicios que no necesitamos.
Validación de parámetros centralizados: Muchas amenazas ocurren al recibir información ingresada por usuarios. Ingresos inválidos pueden ser usados para explotar vulneraciones, como la inyección SQL.
- Por ejemplo: Validar tipo, formato y restricciones donde se reciben los datos y usar consultas parametrizadas. Un ORM no sanitiza automáticamente todo uso ni protege consultas crudas concatenadas.
Servicios de seguridad general centralizados: Reutilizar servicios y políticas coherentes donde corresponda, diseñando su disponibilidad y límites. Centralizar no es un mandato de poner todos los controles en un único punto.
- Por ejemplo: Un servidor centralizado para auth.
Prepararse para los errores y manejo de errores: Siempre considerar que los errores y excepciones VAN a ocurrir y hay que estar preparado para ello.
- Por ejemplo: Un usuario intentando comprar un producto que no está en stock.

Zero Trust vs Trust but Verify

Confiar pero verificar: aquí lo uso como contraste conceptual; no es un modelo normativo definido por disponer de logs. Registrar actividad ayuda a investigar, pero observar después no sustituye decidir el acceso.
Zero Trust: no concede confianza implícita solo por ubicación de red o propiedad del equipo. Autenticación y autorización se evalúan para el acceso al recurso, junto con el estado y contexto relevantes. Eso no significa declarar maliciosa a toda persona.

La microsegmentación es una estrategia posible. No es la única arquitectura Zero Trust ni basta con dividir VLANs. Las políticas deben limitar acceso sin ignorar continuidad y recuperación; no existe una regla general de «aplicar todo y después bajar a confiar». NIST SP 800-207.

Amenaza vs Riesgo

Una vulnerabilidad es algo susceptible a ser atacado o dañado, una debilidad.
Una amenaza es un potencial peligro asociado a dicha vulnerabilidad.
El riesgo es básicamente que tan probable es que un oponente explote una vulnerabilidad y dicho impacto que podría causar.

#to-do

Contraste conceptual: NIST: integridad y riesgo.

+----------------------------------------+
| Floure &                               |
| Tachibana's guild                      |
| [Hikari · Nozomi]                      |
| SEAL: sha256/12: 8a00388aede5          |
| STATUS: LITURGY_IN_PROGRESS            |
+----------------------------------------+

Conceptos fundamentales de seguridad