OWASP Top 10 para APIs y Web

Los 10 Riesgos Principales

Configuración insegura de la nube, contenedores u orquestadores

Vector de ataque

Actores maliciosos explotan configuraciones inseguras como buckets públicos, contenedores ejecutándose como root o recursos compartidos con el host.

Debilidad

Falta de validación y revisión en configuraciones predeterminadas o personalizadas en servicios cloud, contenedores o herramientas de orquestación.

Impacto

Accesos no autorizados, escalamiento de privilegios, exfiltración de datos o compromiso completo del entorno de ejecución.

Estrategias de mitigación

Aplicar configuraciones seguras por defecto y revisar IaC (Infrastructure as Code) antes del despliegue.
Evitar ejecutar contenedores con privilegios elevados o como usuario root.
Auditar y restringir los permisos de recursos como buckets, volúmenes compartidos y roles del orquestador.

Ejemplo de implementación

// Código vulnerable

// ❌ Dockerfile vulnerable: contenedor se ejecuta como root
FROM ubuntu:latest
RUN apt-get update && apt-get install -y nginx
CMD ["/usr/sbin/nginx", "-g", "daemon off;"]

// Código seguro

// ✅ Dockerfile seguro: define un usuario sin privilegios
FROM ubuntu:latest
RUN useradd -m appuser && apt-get update && apt-get install -y nginx
USER appuser
CMD ["/usr/sbin/nginx", "-g", "daemon off;"]

// Código vulnerable

apiVersion: v1
kind: Pod
metadata:
  name: vulnerable-pod
spec:
  containers:
    - name: insecure-container
      image: myapp:latest
      securityContext:
        privileged: true

// Código seguro

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
    - name: secure-container
      image: myapp:latest
      securityContext:
        runAsUser: 1000
        runAsGroup: 3000
        allowPrivilegeEscalation: false
        privileged: false
        readOnlyRootFilesystem: true

Buenas prácticas:

Revisar y aplicar políticas seguras por defecto en IaC.
Usar herramientas de escaneo de configuración como kube-bench, tfsec o Checkov.
Deshabilitar privilegios innecesarios y recursos compartidos entre host y contenedor.
Asegurar que ningún recurso esté expuesto públicamente sin justificación explícita.

Fallos de inyección (capa de aplicación, eventos cloud, servicios cloud)

Vector de ataque

Los atacantes aprovechan puntos de entrada donde no se validan adecuadamente los datos para ejecutar código malicioso, comandos del sistema o manipular estructuras de datos.

Debilidad

Falta de sanitización, validación o escapes en los datos que interactúan con servicios internos, bases de datos, o infraestructura cloud.

Impacto

Compromiso de datos, ejecución remota de código, acceso no autorizado o corrupción de servicios críticos.

Estrategias de mitigación

Validar y sanear estrictamente toda entrada de usuario en cada punto de interacción.
Usar consultas parametrizadas y evitar concatenaciones de strings en consultas a servicios o bases de datos.
Aplicar políticas de permisos mínimos para mitigar el alcance de una posible inyección exitosa.

Ejemplo de implementación

// Código vulnerable

// Vulnerable: comando del sistema con entrada directa
const { exec } = require('child_process');
app.get('/ping', (req, res) => {
  exec(`ping -c 3 ${req.query.host}`, (err, stdout) => {
    res.send(stdout);
  });
});

// Código seguro

// Seguro: validación estricta de entrada
const { exec } = require('child_process');
const isValidHost = host => /^[a-zA-Z0-9.-]+$/.test(host);
app.get('/ping', (req, res) => {
  const host = req.query.host;
  if (!isValidHost(host)) return res.status(400).send('Invalid host');
  exec(`ping -c 3 ${host}`, (err, stdout) => {
    res.send(stdout);
  });
});

// Código vulnerable

# Vulnerable: entrada sin validación en evento Lambda
resource "aws_lambda_function" "example" {
  function_name = "unvalidated-event"
  handler       = "index.handler"
  runtime       = "nodejs18.x"
  filename      = "lambda.zip"
  environment {
    variables = {
      DANGEROUS_COMMAND = var.user_input
    }
  }
}

// Código seguro

# Seguro: se define una variable validada y controlada
variable "safe_input" {
  type    = string
  default = "ping-default"
  validation {
    condition     = can(regex("^[a-zA-Z0-9.-]+$", var.safe_input))
    error_message = "Input must be a valid host."
  }
}

resource "aws_lambda_function" "example" {
  function_name = "validated-event"
  handler       = "index.handler"
  runtime       = "nodejs18.x"
  filename      = "lambda.zip"
  environment {
    variables = {
      SAFE_COMMAND = var.safe_input
    }
  }
}

Buenas prácticas:

Usar validadores de entrada centralizados o middleware para inputs comunes.
Evitar el uso de `eval`, `exec` o cualquier función que interprete entrada dinámica sin validación.
Configurar firewalls y WAFs para detectar y bloquear payloads de inyección.
Aplicar políticas de seguridad en eventos cloud, como reglas estrictas en triggers Lambda o Step Functions.

Autenticación y autorización inadecuadas

Vector de ataque

Los atacantes explotan servicios expuestos sin autenticación o con controles de autorización inadecuados, como APIs internas o consolas de administración.

Debilidad

Falta de autenticación robusta, roles excesivamente permisivos o políticas de acceso mal configuradas en microservicios o herramientas de orquestación.

Impacto

Acceso no autorizado a recursos sensibles, ejecución de acciones privilegiadas y expansión lateral en la infraestructura cloud.

Estrategias de mitigación

Implementar autenticación obligatoria en todas las interfaces, incluyendo APIs internas y consolas de gestión.
Aplicar el principio de menor privilegio al definir roles y permisos en IAM y orquestadores.
Habilitar auditoría de accesos y alertas sobre cambios en políticas de autorización.

Ejemplo de implementación

// Código vulnerable

# ❌ Vulnerable: Permisos excesivos en el rol
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: overly-permissive-role
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

// Código seguro

# ✅ Seguro: Permisos limitados a recursos específicos
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: limited-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

// Código vulnerable

// ❌ Hardcodear secretos en el código fuente es una mala práctica
const insecureDbPassword = "supersecreta123"; // Esto puede filtrarse 

function getInsecureDbUri() {
  return `postgresql://admin:${insecureDbPassword}@db:5432/mydb`;
}

console.log("Insecure URI:", getInsecureDbUri());

// Código seguro

// ✅ Usar variables de entorno y gestores de secretos

// Paso 1: Cargar variables de entorno desde el entorno del sistema o desde un gestor de secretos
const secureDbPassword = process.env.DATABASE_PASSWORD;

// Paso 2: Validar que la variable de entorno esté definida
if (!secureDbPassword) {
  throw new Error("La variable de entorno DATABASE_PASSWORD no está definida.");
}

// Paso 3: Construir el URI de forma segura
function getSecureDbUri() {
  return `postgresql://admin:${secureDbPassword}@db:5432/mydb`;
}

console.log("Secure URI:", getSecureDbUri());

Buenas prácticas:

Asegurar que todas las APIs y servicios internos cuenten con autenticación, incluso en entornos de desarrollo.
Revisar regularmente los permisos en IAM y RBAC para eliminar excesos o accesos obsoletos.
Separar los roles de acceso entre entornos (desarrollo, staging, producción).
Auditar y registrar cada intento de acceso a recursos sensibles o administrativos.

Fallos en la cadena de suministro de software y pipelines CI/CD

Vector de ataque

Los atacantes comprometen pipelines de CI/CD mal protegidos, imágenes de contenedor no confiables o flujos de integración sin control de integridad.

Debilidad

Falta de autenticación en servicios de CI/CD, uso de imágenes o dependencias no verificadas, o acceso no restringido a registros de imágenes.

Impacto

Compromiso del entorno de construcción o despliegue, introducción de software malicioso y pérdida de integridad del sistema.

Estrategias de mitigación

Habilitar autenticación fuerte y control de acceso en herramientas y pipelines de CI/CD.
Usar solo imágenes y dependencias firmadas o provenientes de fuentes confiables.
Restringir el acceso a registros de contenedores y verificar el contenido antes del uso.

Ejemplo de implementación

// Código vulnerable

# ❌ Vulnerable: Usa imagen no verificada desde Docker Hub
actions:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: docker://node:latest
        with:
          entrypoint: "npm install"

// Código seguro

# ✅ Seguro: Usa imagen verificada y versionada desde fuente confiable
actions:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: docker://ghcr.io/your-org/node-builder:1.2.3
        with:
          entrypoint: "npm install"

// Código vulnerable

# ❌ Vulnerable: Instala dependencias sin control de versiones
FROM node:18
RUN npm install express

// Código seguro

# ✅ Seguro: Fija versiones y verifica integridad de las dependencias
FROM node:18
COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts --prefer-offline

Buenas prácticas:

Aplicar autenticación multifactor en accesos al sistema de CI/CD.
Utilizar repositorios de artefactos privados con control de versiones y políticas de revisión.
Escanear imágenes y dependencias antes del uso en ambientes de construcción o despliegue.
Separar entornos de CI/CD según el nivel de riesgo y tipo de aplicación (producción, testing, desarrollo).

Almacenamiento inseguro de secretos

Vector de ataque

Un atacante puede acceder a secretos expuestos o mal protegidos en contenedores, archivos de configuración o variables de entorno.

Debilidad

Almacenamiento de claves, tokens o contraseñas sin cifrado, uso de valores codificados o hardcodeados en el código fuente o dentro de imágenes.

Impacto

Compromiso de credenciales sensibles, acceso no autorizado a servicios internos o externos y escalada de privilegios.

Estrategias de mitigación

Utilizar servicios de gestión de secretos que cifren la información en reposo y en tránsito.
Evitar almacenar secretos en imágenes, repositorios o archivos de configuración sin cifrado.
Rotar los secretos periódicamente y aplicar el principio de mínimo privilegio en su uso.

Ejemplo de implementación

// Código vulnerable

# ❌ Vulnerable: Clave API hardcodeada
FROM node:18

ENV API_KEY="abc123-super-secret-key"

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm install
COPY . .

# La app accede a process.env.API_KEY dentro de app.js
CMD ["node", "app.js"]

// Código seguro

# ✅ Seguro: Clave API se inyecta al momento de ejecución
FROM node:18

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm install
COPY . .

# No se define la variable de entorno en la imagen.
# Se debe pasar en tiempo de ejecución usando `docker run -e` o un gestor de secretos.

# Ejemplo de ejecución segura (fuera de este archivo):
# docker run -e API_KEY=$API_KEY_FROM_SECRET_STORE myapp
CMD ["node", "app.js"]

// Código vulnerable

// ❌ Vulnerable: Secreto hardcodeado en el código
const dbPassword = "superSecret123";
connectToDatabase(dbPassword);

// Código seguro

// ✅ Seguro: Secreto obtenido desde un gestor de secretos externo
const dbPassword = process.env.DB_PASSWORD;
connectToDatabase(dbPassword);

Buenas prácticas:

Centralizar la gestión de secretos utilizando herramientas como HashiCorp Vault, AWS Secrets Manager o Azure Key Vault.
Evitar subir secretos a repositorios, incluso privados, mediante reglas de exclusión y escaneos automáticos.
Configurar alertas ante accesos inesperados a secretos o rotaciones no autorizadas.
Implementar rotación automática de secretos en sistemas críticos y documentar el procedimiento de acceso.

Políticas de red inseguras o con permisos excesivos

Vector de ataque

Un atacante aprovecha configuraciones de red mal definidas para interceptar, modificar o redirigir tráfico entre servicios internos.

Debilidad

Falta de segmentación, reglas de red demasiado permisivas, o comunicaciones sin cifrado entre servicios internos.

Impacto

Acceso no autorizado a datos internos, escalada lateral entre servicios y exposición de tráfico sensible a interceptación.

Estrategias de mitigación

Aplicar segmentación de red y políticas de comunicación estrictas entre servicios.
Configurar reglas de firewall o políticas de red que limiten el tráfico solo a lo necesario.
Cifrar todas las comunicaciones internas con TLS incluso dentro del clúster o VPC.

Ejemplo de implementación

// Código vulnerable

# ❌ Vulnerable: Sin política de red definida (tráfico libre entre pods)
apiVersion: v1
kind: Pod
metadata:
  name: backend
spec:
  containers:
  - name: app
    image: backend:latest

// Código seguro

# ✅ Seguro: Política que restringe el acceso solo desde el pod 'frontend'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

// Código vulnerable

# ❌ Vulnerable: Comunicación HTTP sin cifrado en servicios internos
upstream backend {
    server backend.internal:80;
}
server {
    location / {
        proxy_pass http://backend;
    }
}

// Código seguro

# ✅ Seguro: Comunicación cifrada con HTTPS entre servicios internos
upstream backend {
    server backend.internal:443;
}
server {
    location / {
        proxy_pass https://backend;
        proxy_ssl_verify on;
    }
}

Buenas prácticas:

Definir políticas de red específicas para cada microservicio, limitando qué servicios pueden comunicarse entre sí.
Auditar y revisar periódicamente las reglas de red, buscando accesos innecesarios o excesivos.
Implementar mecanismos de detección de tráfico anómalo o no autorizado dentro de la red interna.
Cifrar todo el tráfico, incluso en redes privadas, para reducir el riesgo de ataques tipo man-in-the-middle.

Uso de componentes con vulnerabilidades conocidas

Vector de ataque

Un atacante explota vulnerabilidades conocidas presentes en librerías, contenedores o servicios utilizados por la aplicación.

Debilidad

Uso de versiones obsoletas o inseguras de dependencias, contenedores o imágenes base sin aplicar actualizaciones o escaneos de seguridad.

Impacto

Ejecución remota de código, escalada de privilegios o compromiso total de la aplicación o infraestructura.

Estrategias de mitigación

Integrar escáneres de vulnerabilidades en el pipeline de CI/CD para detectar versiones inseguras.
Mantener actualizado el software base, contenedores e imágenes utilizadas.
Usar fuentes oficiales y confiables para obtener dependencias y firmar las imágenes utilizadas.

Ejemplo de implementación

// Código vulnerable

# ❌ Vulnerable: Uso de imagen obsoleta con vulnerabilidades conocidas
FROM node:10
WORKDIR /app
COPY . .
RUN npm install
CMD ["npm", "start"]

// Código seguro

# ✅ Seguro: Uso de imagen actualizada y estable con escaneo en CI/CD
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
CMD ["npm", "start"]

// Código vulnerable

// ❌ Vulnerable: Dependencia desactualizada
{
  "dependencies": {
    "express": "4.16.0"
  }
}

// Código seguro

// ✅ Seguro: Dependencia actualizada con herramientas de escaneo integradas
{
  "dependencies": {
    "express": "^4.19.2"
  },
  "scripts": {
    "audit": "npm audit"
  }
}

Buenas prácticas:

Utilizar herramientas automáticas como Snyk, Trivy o Dependabot para detectar y alertar sobre vulnerabilidades.
Restringir el uso de paquetes que no tengan mantenimiento activo o que no provengan de fuentes verificadas.
Adoptar políticas internas que obliguen a mantener una frecuencia de actualización de dependencias.
Revisar los cambios en las versiones antes de actualizarlas para evitar introducir regresiones o nuevas dependencias vulnerables.

Gestión inadecuada de elementos

Vector de ataque

Un atacante accede o explota servicios, microservicios o recursos en la nube que están activos pero no documentados ni supervisados.

Debilidad

Falta de inventario y documentación de activos cloud como APIs, contenedores, buckets o microservicios; recursos no eliminados o fuera del alcance de la observabilidad.

Impacto

Exposición de datos sensibles, incremento de la superficie de ataque, ejecución no autorizada de código o consumo de recursos innecesarios.

Estrategias de mitigación

Mantener un inventario actualizado y automatizado de todos los activos cloud, incluyendo microservicios, APIs y recursos desplegados.
Implementar herramientas de descubrimiento de activos y escaneo continuo de entornos cloud.
Establecer políticas de limpieza y gobernanza para eliminar recursos obsoletos o no utilizados.

Ejemplo de implementación

// Código vulnerable

# ❌ Código vulnerable: bucket público sin control ni inventario
# Este bucket fue creado para compartir archivos temporalmente
aws s3api create-bucket --bucket dev-temporal-data --region us-east-1
aws s3 website s3://dev-temporal-data/ --index-document index.html
aws s3api put-bucket-policy --bucket dev-temporal-data --policy file://public-policy.json

# El bucket queda público y no se elimina ni se documenta.

// Código seguro

# ✅ Código seguro: bucket con control, TTL y acceso restringido
aws s3api create-bucket --bucket dev-temporal-data --region us-east-1 \n  --create-bucket-configuration LocationConstraint=us-east-1

# Bloquear acceso público por defecto
aws s3api put-public-access-block --bucket dev-temporal-data \n  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Agregar tags para visibilidad e inventario
aws s3api put-bucket-tagging --bucket dev-temporal-data --tagging 'TagSet=[{Key=Environment,Value=Dev},{Key=TTL,Value=7d}]'

# Definir una política de ciclo de vida para eliminar objetos automáticamente
aws s3api put-bucket-lifecycle-configuration --bucket dev-temporal-data --lifecycle-configuration file://lifecycle.json

// Código vulnerable

# ❌ Vulnerable: Servicio no registrado ni con etiquetas para trazabilidad
aws ec2 run-instances --image-id ami-123456 --instance-type t2.micro

// Código seguro

# ✅ Seguro: Instancia lanzada con etiquetas de auditoría y centralización en inventario
aws ec2 run-instances \
  --image-id ami-123456 \
  --instance-type t2.micro \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Environment,Value=dev},{Key=Owner,Value=infra-team}]'

Buenas prácticas:

Etiquetar todos los recursos cloud con información de propietario, propósito y entorno.
Automatizar la detección de activos desconocidos mediante herramientas como AWS Config, Azure Purview o GCP Asset Inventory.
Auditar regularmente el entorno cloud en busca de servicios obsoletos o sin uso reciente.
Centralizar la definición de recursos a través de Infrastructure as Code para mantener consistencia y trazabilidad.

Límites de cuota de recursos computacionales mal definidos

Vector de ataque

Un atacante o proceso malicioso puede explotar la ausencia de límites en los recursos computacionales para agotar CPU, memoria u otros recursos compartidos.

Debilidad

No establecer límites de uso en contenedores, funciones serverless o servicios expuestos, lo cual permite consumos excesivos o desequilibrados.

Impacto

Degradación del servicio, denegación de servicio (DoS) o interrupción total de otros procesos críticos debido a recursos agotados.

Estrategias de mitigación

Definir límites y solicitudes explícitas de CPU y memoria para todos los contenedores o funciones desplegadas.
Implementar políticas de cuotas a nivel de namespace, proyecto o tenant en entornos multiusuario.
Monitorear el uso de recursos y aplicar autoscaling controlado para evitar desbordes inesperados.

Ejemplo de implementación

// Código vulnerable

# ❌ Vulnerable: Pod sin límites de recursos
apiVersion: v1
kind: Pod
metadata:
  name: unlimited-app
spec:
  containers:
  - name: app
    image: myapp:latest

// Código seguro

# ✅ Seguro: Pod con límites y solicitudes de recursos definidos
apiVersion: v1
kind: Pod
metadata:
  name: limited-app
spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

// Código vulnerable

// ❌ Vulnerable: Función lambda sin configuración adecuada de memoria
{
  "FunctionName": "processLargeFiles",
  "Runtime": "nodejs20.x",
  "Handler": "index.handler",
  "Timeout": 900
}

// Código seguro

// ✅ Seguro: Función lambda con asignación de memoria controlada
{
  "FunctionName": "processLargeFiles",
  "Runtime": "nodejs20.x",
  "Handler": "index.handler",
  "Timeout": 300,
  "MemorySize": 512
}

Buenas prácticas:

Establecer límites de CPU y memoria como parte obligatoria del ciclo de despliegue.
Auditar regularmente los consumos y aplicar ajustes automáticos según la carga histórica.
Evitar valores por defecto indefinidos en plataformas cloud o Kubernetes.
Aplicar pruebas de carga para validar el comportamiento del sistema bajo condiciones de consumo extremo.

Registro y monitoreo ineficaces

Vector de ataque

Un atacante puede aprovechar la falta de monitoreo para ejecutar acciones maliciosas sin ser detectado, como movimientos laterales, exfiltración de datos o uso abusivo de recursos.

Debilidad

Ausencia de registro de actividades críticas, monitoreo de red deficiente o nula supervisión de procesos en contenedores y hosts.

Impacto

Fallas en la detección temprana de incidentes, pérdida de trazabilidad, demoras en la respuesta a incidentes o incumplimiento de requisitos normativos.

Estrategias de mitigación

Implementar herramientas de monitoreo y logging centralizado para contenedores, hosts y red.
Habilitar alertas automáticas ante comportamientos anómalos o patrones sospechosos.
Registrar eventos de seguridad relevantes como accesos, errores, cambios en configuración y operaciones privilegiadas.

Ejemplo de implementación

// Código vulnerable

# ❌ Vulnerable: Contenedor sin configuración de logging
FROM node:20
COPY . /app
CMD ["node", "index.js"]

// Código seguro

# ✅ Seguro: Uso de driver de logging y redirección de logs
FROM node:20
COPY . /app
CMD ["node", "index.js"]
# Configurar logging driver al ejecutar:
# docker run --log-driver=json-file --log-opt max-size=10m --log-opt max-file=3 myapp

// Código vulnerable

# ❌ Vulnerable: No se recolectan logs ni se monitorea la actividad
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: web
        image: webapp:latest

// Código seguro

# ✅ Seguro: configurar el servicio para recolección de logs y monitoreo
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: web
        image: webapp:latest
      - name: log-forwarder
        image: fluentd:latest
        volumeMounts:
        - name: logs
          mountPath: /var/log/app
      volumes:
      - name: logs
        emptyDir: {}

Buenas prácticas:

Centralizar logs con herramientas como ELK, Fluentd, Loki o Cloud-native solutions como CloudWatch o Stackdriver.
Asegurar que todos los contenedores, funciones y servicios generen logs estructurados.
Definir políticas de retención y revisión periódica de logs.
Monitorear métricas clave y establecer alertas proactivas en eventos de seguridad o disponibilidad.

¿Qué es OWASP?

Riesgos específicos en entornos cloud

Los 10 Riesgos Principales

Configuración insegura de la nube, contenedores u orquestadores

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Fallos de inyección (capa de aplicación, eventos cloud, servicios cloud)

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Autenticación y autorización inadecuadas

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Fallos en la cadena de suministro de software y pipelines CI/CD

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Almacenamiento inseguro de secretos

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Políticas de red inseguras o con permisos excesivos

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Uso de componentes con vulnerabilidades conocidas

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Gestión inadecuada de elementos

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Límites de cuota de recursos computacionales mal definidos

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Registro y monitoreo ineficaces

Vector de ataque

Debilidad

Impacto

Estrategias de mitigación

Ejemplo de implementación

Buenas prácticas:

Estadísticas de Seguridad en la Nube

Recursos Adicionales

Documentación Oficial

Herramientas de Seguridad