Data Security Requirements

Prepararse para responder preguntas de seguridad de los datos

Flujos de datos

Crea (o actualiza, en caso de ser necesario) un diagrama o una descripción del flujo de datos que ilustre cómo la app o el sistema trata datos de la plataforma.

1. Cliente: incluye todo el software del cliente, como navegadores, dispositivos móviles y cualquier otro tipo de dispositivo compatible.
2. Servidor: incluye cualquier entorno de servidor o nube relacionado e identifica:
1. Los componentes donde los datos de la plataforma:
1. ingresan o salen de los entornos de servidores (p. ej., escuchas web y API REST), y
2. están escritos en almacenamientos persistentes o duraderos, como bases de datos, discos o archivos de registro.
2. El modelo de hospedaje:
1. Autohospedado: los servidores propios de una organización que se ejecutan en un centro de datos propio o compartido.
2. Infraestructura como servicio (IaaS): como AWS EC2, Microsoft Azure IaaS y Google Compute Engine.
3. Plataforma como servicio (PaaS): como AWS Elastic Beanstalk, Google App Engine y Force.com.
4. Backend como servicio (BaaS): como AWS Amplify, Azure Mobile Apps, Firebase y MongoDB Switch.
5. Híbrido: alguna combinación de los modelos mencionados.

Al final, el diagrama o la descripción del flujo de datos debería incluir:

1. Dónde se generan, transmiten, almacenan o renuevan los tokens de acceso de la API de Meta, tanto en el software del cliente como del servidor (si corresponde al diseño del sistema).
2. Cómo recuperar datos de la plataforma desde las API de Meta, específicamente enfocándose en la información de identificación personal (PII), como el nombre, la dirección de correo electrónico, el sexo, la fecha de nacimiento y otros datos de usuario de una persona.
3. Cómo usas, almacenas y transmites estos datos.
4. Cualquier parte externa a la que se envíen datos de la plataforma.

Preparación de evidencia

Es posible que debas enviar evidencia para respaldar las respuestas relativas a las medidas de protección de seguridad de los datos que implementes. Te recomendamos leer la Guía de evidencia incluida en este documento, donde hay ejemplos de documentos aceptados y cómo prepararlos. Aceptamos los tipos de archivos habituales junto con capturas y grabaciones de pantalla. Asegúrate de que los archivos no estén protegidos con contraseña. Puedes subir varios archivos, con un límite de 2 GB por archivo. Aceptamos archivos con extensión .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip y .zipx.

Tipos de evidencia

Para las apps que requieren subir evidencia relacionada con prácticas de protección de seguridad de datos, Meta exige dos tipos de documento:

1. Evidencia de política o procedimiento: un documento que contenga una política o un procedimiento que detalle el enfoque en materia de seguridad de datos para [esta protección].
2. Evidencia de implementación: información del sistema o la app, como la configuración de una herramienta o una captura de pantalla, que demuestre la forma en que implementaste determinada protección.

Evidencia de política o procedimiento

Evidencia de política o procedimiento, también denominado control administrativo, hace referencia a un documento escrito que describe el enfoque de una determinada práctica de protección de seguridad de datos. El formato de esta clase de documento puede variar: puede ser un extracto de un conjunto de políticas internas, un fragmento o la totalidad de una página de la wiki interna, o bien un documento nuevo creado con este propósito en el caso de que no cuentes con ningún documento preexistente. En cualquier caso, la evidencia de política o procedimiento que subas debe explicar con claridad cómo se relaciona el enfoque de una política determinada con los requisitos de Meta. Debes proporcionar únicamente la política o el documento que resulte relevante y necesario para las revisiones de seguridad de Meta, o utilizar el cuadro de texto vacío asociado con la pregunta en cuestión para dirigir a nuestros revisores a la(s) sección(es) relevante(s).

Evidencia de implementación

La evidencia de implementación muestra la manera en que implementaste la política o el procedimiento en la práctica directamente mediante una captura o grabación de pantalla. Como los desarrolladores no utilizan siempre las mismas configuraciones, no podemos proporcionar ejemplos para cada situación. La evidencia de implementación debe, en la medida de lo posible, demostrar el mismo nivel de detalle que el de los ejemplos que proporcionamos.

Exhaustividad de la evidencia

Entendemos que puede resultar complejo preparar evidencia de implementación que demuestren cabalmente la implementación de una determinada práctica de protección de la seguridad de los datos. En este sentido, debes enviar evidencia según las pautas indicadas a continuación, procurando ocultar la información confidencial del documento antes de enviarlo:

1. La evidencia de política o procedimiento debe cumplir o exceder los requisitos de Meta
1. Meta revisará la evidencia de política o procedimiento para comprobar que se ajuste a los requisitos de Meta en relación con una determinada protección.
2. Debes procurar que el documento resalte las secciones relevantes
3. Por ejemplo, en relación con la protección sobre permitir cifrado TLS 1.2 o superior para todas las conexiones de red donde se transmitan datos de la plataforma, una evidencia aceptable debería indicar con claridad lo siguiente:
1. Los datos de la plataforma de Meta no deberán transmitirse a través de redes que no sean de confianza en un formato no cifrado.
2. Todos los agentes de escucha web (p. ej., equilibradores de carga conectados a internet) que reciben o devuelven datos de la plataforma se configurarán de manera que se encuentre habilitado el uso de TLS 1.2.
3. Todos los agentes de escucha web que reciben o devuelven datos de la plataforma se configurarán de manera que los siguientes protocolos no estén habilitados: SSL v2, SSL v3, TLS 1.0 y TLS 1.1
2. La evidencia de implementación debe mostrar uno o más ejemplos de la implementación de cada política o procedimiento.
1. Debes subir uno o varios documentos, capturas de pantalla o configuraciones de herramientas que demuestren la manera en que implementaste cada protección.
2. Meta revisará la evidencia de implementación para asegurarse de que coincida con la evidencia de política o procedimiento.
3. Por ejemplo, en relación con la protección Permitir cifrado TLS 1.2 o superior para todas las conexiones de red donde se transmitan datos de la plataforma, una evidencia aceptable debería incluir el informe de prueba de SSL de Qualys para uno de los dominios web que esté configurado de acuerdo con la política o el procedimiento.

Ocultación de datos confidenciales de la evidencia

No envíes evidencia que contenga alguno de estos valores de manera legible (sin ocultar). Si utilizas un editor de imágenes para hacer una captura de pantalla, superpone un cuadro de texto negro sobre el valor en cuestión. Si utilizas un editor de PDF, asegúrate de ocultar el texto utilizando una herramienta que realmente elimine el valor en lugar de solo superponer una capa y conservar el texto (p. ej., la herramienta de eliminación en la app de previsualización de Apple).

• Datos de salud
• Datos financieros
• Direcciones IP
• Contraseñas, credenciales y tokens de acceso
• Claves de cifrado
• Direcciones postales
• Información de identificación personal sobre una persona (excluidas las empresas y otras organizaciones comerciales), empleados u otros datos que permitan la identificación directa o indirecta de la persona, por ejemplo:

  • Nombre
  • Direcciones de correo electrónico
  • Identificadores de usuario
  • Fechas de nacimiento
  • Datos de ubicación
  • Datos de salud
  • Afiliación política, social o cultural
  • Datos que de cualquier otro modo permitan identificar a una persona en el contexto específico de la evidencia
• Pasos de reproducción detallados sobre vulnerabilidades (p. ej., en un informe de prueba de penetración).
• Datos que los desarrolladores sepan o les permitan razonablemente saber que son relativos a menores de 13 años.

Proteger los datos de la plataforma almacenados en el servidor con cifrado en reposo

Pregunta: ¿Aplicas el cifrado en reposo a todos los datos de la plataforma almacenados en una nube, servidor o entorno de centro de datos?

Intención

El cifrado en reposo protege los datos de la plataforma solicitando una clave de descifrado independiente para desencriptarlos. Se trata de una medida adicional de seguridad contra accesos de lectura no autorizados.

• En los entornos de servidores o de la nube, donde suelen concentrarse los datos de la plataforma relacionados con todos los usuarios de una app, el cifrado en reposo reduce el riesgo de filtración de datos.
• Este tipo de cifrado protege, por ejemplo, contra accesos no autorizados a copias de seguridad de bases de datos, que posiblemente no estén tan protegidas como las propias bases de datos de producción.

Resumen de los requisitos

Si almacenas datos de la plataforma en el servidor:

• DEBES proteger los datos:

  • Con cifrado en reposo.
  • con medidas de protección alternativas aceptables (consulta Medidas de protección alternativas aceptables).

• En relación con el tipo de cifrado utilizado:

  • Puedes aplicar esta medida en la app (p. ej., cifrando o descifrando columnas específicas de una base de datos) o en discos completos.
  • Aunque recomendamos aplicar sistemas de cifrado estándar del sector (como AES, BitLocker, Blowfish, TDES o RSA), no exigimos longitudes de clave ni algoritmos concretos.

En caso de que el desarrollador NO almacene datos de la plataforma en el servidor, no se aplicará este requisito.

Casos especiales

Almacenamiento en el servidor mediante infraestructuras como servicio (IaaS), autohospedaje u hospedaje híbrido

Esta pregunta es pertinente si almacenas datos de la plataforma a través del hospedaje IaaS (como AWS EC2, Microsoft Azure IaaS o Google Compute Engine), autohospedaje o un enfoque híbrido.

Almacenamiento en el servidor mediante productos de software como servicio (SaaS), plataforma como servicio (PaaS) o backend como servicio (BaaS)

Sin embargo, hay otros modelos de hospedaje backend que se consideran casos especiales.

Esta pregunta no es pertinente si almacenas datos de la plataforma mediante alguna de las siguientes opciones (y no usas IaaS, autohospedaje ni hospedaje híbrido). En su lugar, debes describir esta relación en la sección Proveedor de servicios de la evaluación de protección de datos.

• BaaS: p. ej., AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase y MongoDB Switch.
• PaaS: p. ej., AWS Elastic Beanstalk, Google App Engine y Force.com.
• SaaS: p. ej., MailChimp y Salesforce.

Almacenamiento en el servidor mediante las API de Meta

Esta pregunta no es pertinente si almacenas datos de la plataforma mediante la API de Meta, por ejemplo, usando player.setDataAsync(), en el SDK de juegos instantáneos.

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación.

Ejemplos de evidencia para demostrar la implementación

AWS RDS

AWS RDS: el cifrado en reposo es una opción configurable en AWS RDS, por lo que es necesario que los desarrolladores la seleccionen para que se aplique la protección.

Para obtener una instancia de RDS representativa que contenga datos de la plataforma, recupera su configuración StorageEncrypted con la herramienta AWS CLI.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

De forma predeterminada, AWS DynamoDB está cifrado en reposo. La configuración del cifrado en reposo para una tabla puede recuperarse mediante los comandos que se indican a continuación.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDB debe estar configurado para aplicar cifrado en reposo. Para obtener un clúster representativo que contenga datos de la plataforma, usa los siguientes comandos para recuperar la configuración StorageEncrypted.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

Los contenedores AWS S3 pueden configurarse para aplicar el cifrado en reposo a todos los objetos creados dentro de ellos. Usa estos comandos para ver una lista de los contenedores y recuperar la configuración del cifrado predeterminado del contenedor.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Consulta la documentación de Microsoft sobre el cifrado en reposo en Azure que sea pertinente para el uso que hace la organización de sus servicios.

Google Cloud Platform

Consulta la documentación de Google sobre el cifrado en reposo en Google Cloud Platform.

Medidas de protección alternativas aceptables

Si no implementas cifrado en reposo en el entorno del servidor, puedes proteger los datos de la plataforma de un modo alternativo que también sea aceptable. En tal caso, tienes que describir los siguientes elementos:

1. Confidencialidad de los datos de la plataforma: si el almacenamiento de datos de la plataforma específicos se considera de alto o bajo riesgo. Deberás determinar qué atributos de usuario de datos de la plataforma específicos se almacenan en el servidor.
2. Controles aplicados para reducir la probabilidad de daños concretos
1. Controles para proteger redes que contengan datos de la plataforma
2. Controles para proteger apps o sistemas que tengan acceso a datos de la plataforma
3. Controles para evitar la pérdida de medios de almacenamiento físicos (p. ej., dispositivos de almacenamiento de red fuera de servicio) que contengan datos de la plataforma
4. Controles para evitar la pérdida de medios de almacenamiento físicos (p. ej., dispositivos de almacenamiento de red fuera de servicio) que contengan datos de la plataforma
5. Controles para evitar accesos no autorizados a copias de seguridad de medios de almacenamiento que contengan copias de seguridad de datos de la plataforma
3. Solidez de la evidencia: es necesario indicar si un auditor independiente evaluó estas protecciones, por ejemplo, como parte de una auditoría SOC2.

Proteger frente a pérdidas de datos de la plataforma almacenados en medios extraíbles y dispositivos de la organización

Pregunta: Específicamente en relación con los datos almacenados en dispositivos personales y de la organización: ¿Aplicas cifrado en reposo o implementas políticas y reglas para reducir el riesgo de pérdida de datos para todos los datos de la plataforma almacenados en estos dispositivos?

Intención

En caso de que un desarrollador permita almacenar datos de la plataforma en dispositivos como computadoras portátiles de empleados o unidades de almacenamiento extraíbles (p. ej., unidades USB), existe un riesgo alto de que se acceda a ellos sin autorización en caso de robo o pérdida del dispositivo. Por esta razón, es necesario que los desarrolladores adopten medidas para minimizar este riesgo.

Resumen de los requisitos

• A fin de reducir el riesgo de acceso no autorizado a los datos de la plataforma, los desarrolladores deben disponer de controles técnicos (opción recomendada) o controles administrativos (opción no recomendada, pero aceptable). Estos controles deben ser pertinentes para los datos de la plataforma almacenados en los dispositivos de la organización (p. ej., portátiles) y medios extraíbles.

  • Controles técnicos: estos son algunos ejemplos de controles técnicos: 1) permitir que solamente se conecten a la red corporativa los dispositivos administrados; 2) aplicar cifrado de disco completo en los dispositivos administrados (p. ej., BitLocker); 3) impedir la conexión de medios extraíbles (p. ej., unidades USB) a dispositivos administrados; y 4) utilizar tecnología de prevención de pérdida de datos en dispositivos administrados.
  • Controles administrativos: los controles administrativos pueden ser documentación escrita sobre políticas y capacitaciones anuales sobre la gestión aceptable de los datos de la plataforma en dispositivos personales y de la organización.

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación.

Puedes utilizar una de las siguientes opciones o ambas: a) controles técnicos (p. ej., cifrado de disco) o b) reglas o políticas para reducir el riesgo de pérdida de datos de la plataforma almacenados en dispositivos de la organización, como computadoras portátiles y teléfonos celulares.

Ejemplos de controles técnicos:

• Impedir la conexión entre dispositivos no administrados y servicios confidenciales, como la red de producción.
• Aplicar cifrado de disco en dispositivos administrados (p. ej., a través de BitLocker en Windows o FileVault en Mac).
• Impedir el uso de medios extraíbles (p. ej., unidades USB) en dispositivos administrados.
• Usar software de prevención de pérdida de datos en dispositivos administrados para impedir la gestión incorrecta de los datos de la plataforma (p. ej., enviarlos como datos adjuntos en un correo electrónico).

Ejemplos de reglas o políticas:

• Documentación que describa las formas aceptables y no aceptables de gestionar datos en general y datos de la plataforma en particular.
• Un mecanismo para que los miembros de la organización conozcan las normas (p. ej., un acuerdo contractual como condición de empleo, capacitación o recordatorios periódicos por correo electrónico).

Ejemplos de evidencia

Una organización clasifica los datos de la plataforma de Meta como "datos privados" según su norma de clasificación de datos. La organización creó normas de gestión de los datos y obliga a todo el personal a conocer y cumplir estas políticas.

Proteger los datos de la plataforma transmitidos a través de redes con cifrado en tránsito

Pregunta: ¿Activas el protocolo de seguridad TLS 1.2 o una versión posterior para todas las conexiones de red que atraviesan, conectan o cruzan las redes públicas en las que se transmiten los datos de la plataforma? ¿Te aseguras también de que los datos de la plataforma nunca se transmitan a través de redes públicas sin cifrar (p. ej., por HTTP o FTP) y de que nunca se usen los protocolos de seguridad SSL v2 y SSL v3?

Intención

Los datos de la plataforma que se transmiten a través de internet son accesibles para todas las personas que pueden consultar el tráfico de la red. Por lo tanto, debes protegerlos mediante cifrado para impedir su lectura por parte de terceros no autorizados.

• Para proteger los datos de la plataforma que se transmiten entre redes no confiables (como internet), el cifrado en tránsito hace que resulten indescifrables en todas partes, excepto en los dispositivos de origen y destino.
• Dicho de otro modo, las partes que intervienen en el transcurso de la transmisión no pueden leer los datos de la plataforma, ni siquiera aunque tengan capacidad para consultar el tráfico de la red (lo que también se conoce como ataques de tipo "Man in the middle").
• El cifrado TLS es el más frecuente en tránsito porque los navegadores usan esta tecnología para proteger las comunicaciones en sitios web como los de los bancos.

Resumen de los requisitos

Ya sea que trates o no datos de la plataforma en el servidor:

• Los datos de la plataforma no deberán transmitirse a través de redes que no sean de confianza en un formato no cifrado.
• Para todos los agentes de escucha web (p. ej., equilibradores de carga conectados a internet) que reciben o devuelven datos de la plataforma:

  • Activa TLS 1.2 o una versión posterior.
  • Desactiva los protocolos SSL v2 y SSL v3.
• TLS 1.0 y TLS 1.1 solo deben usarse para la compatibilidad con dispositivos del cliente que no admiten TLS 1.2 o una versión posterior.
• Meta recomienda, pero no exige, que el cifrado en tránsito se aplique a las transmisiones de datos de la plataforma que encuentren en su totalidad en redes privadas; p. ej., la nube privada virtual (VPC).

En la tabla a continuación, se ofrece un resumen de la política del cifrado en tránsito para los diferentes tipos de transmisión.

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación. Usar la herramienta de prueba del servidor SSL de Qualys es una manera directa de producir evidencia de implementación que demuestre la configuración de uno de los agentes de escucha web.

• Ejecuta la herramienta de prueba del servidor SSL de Qualys frente a uno o más agentes de escucha web que estén configurados de forma idéntica (incluso cualquiera que se ejecute en puertos diferentes a los estándar).
• Marca la opción "No mostrar los resultados en los paneles" para evitar que los resultados se agreguen al sitio web de Qualys. Imprime toda la página de resultados de la prueba en formato PDF. Repite los pasos anteriores para todos los agentes de escucha web a quienes transmites los datos de la plataforma, o de quienes los recibes, que tienen una configuración TLS diferente.

Ejemplos de evidencia para demostrar la implementación

Este es un ejemplo generado a partir de la herramienta de prueba del servidor SSL de Qualys. Ten en cuenta las anotaciones en rojo en la sección "Configuración", que resumen qué versiones de SSL/TLS son compatibles. Nota: Este ejemplo incluye solo las primeras dos páginas, pero debes incluir el resultado completo de la prueba.

Medidas de protección alternativas aceptables

Es posible que protejas los datos en tránsito de la plataforma mediante diferentes tipos de cifrado, además de TLS. Esto puede ser aceptable si el enfoque proporciona un nivel de protección equivalente. En este caso, debes enviar los detalles sobre el tipo de cifrado usado en Meta para revisar lo siguiente:

• ¿es un cifrado simétrico o asimétrico?
• ¿Es un algoritmo de cifrado (p. ej., AES, BitLocker, TDES, RSA)?
• ¿Cuál es la longitud mínima de la clave?

Realiza pruebas a la app y los sistemas para detectar vulnerabilidades y problemas de seguridad

Pregunta: ¿Realizas pruebas a la app y los sistemas para detectar vulnerabilidades y problemas de seguridad cada 12 meses como mínimo? Por ejemplo, ¿realizas pruebas de penetración manuales?

Intención

Los desarrolladores deben realizar pruebas que permitan descubrir de manera proactiva posibles vulnerabilidades y problemas de seguridad para, en un escenario óptimo, evitar incidentes incluso antes de que se produzcan.

• Desarrolladores de apps que usan la plataforma de Meta para tratar datos de la plataforma con software que programan por medio de apps y sistemas que configuran y operan.
• El software y las configuraciones de los sistemas pueden contener vulnerabilidades de seguridad que agentes malintencionados podrían aprovechar para acceder de forma no autorizada a los datos de la plataforma.

Resumen de los requisitos

Aplicables a todos los desarrolladores:

• Debes haber sometido a prueba el software que se usa para tratar datos de la plataforma a fin de detectar vulnerabilidades por medio de lo siguiente:

  • una prueba de penetración de la app o el sistema, o
  • un escaneo o análisis estático del software para detectar vulnerabilidades.
• Los resultados de la prueba deben indicar que no quedan vulnerabilidades críticas o graves sin resolver.
• La prueba debe completarse dentro de los últimos 12 meses.

Requisitos adicionales para desarrolladores que tratan datos de la plataforma en el servidor:

• Debes haber sometido a prueba específicamente el software del servidor para detectar vulnerabilidades de seguridad por medio de lo siguiente:

  • una prueba de penetración de la app o el sistema, o
  • un escaneo o análisis estático del software para detectar vulnerabilidades. También debes haber comprobado la configuración de la nube para identificar problemas de seguridad si usas un proveedor de hospedaje en la nube. Este requisito se aplica independientemente del enfoque de hospedaje (p. ej., BaaS, PaaS, IaaS, hospedaje propio o enfoque híbrido).

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación.

Si la organización trata los datos de la plataforma en un entorno de servidor o nube, debes hacer lo siguiente:

• Presentar evidencia que indique que se completó una prueba de penetración o se ejecutó una herramienta SAST. Dicha evidencia debe incluir lo siguiente:

  • Una declaración que manifieste el alcance de la prueba.
  • La fecha en que se completó la prueba, que debe ser dentro de los últimos 12 meses.
  • Un resumen o una lista de las vulnerabilidades detectadas durante la prueba. Estos deben incluir una categorización de la gravedad (por ejemplo, crítica, grave, media, baja, informativa). Habitualmente, esperamos que no queden vulnerabilidades críticas o graves sin resolver.

• Si corresponde (es decir, si usas un hospedaje en la nube como AWS, GCP, Azure u otro similar), presenta evidencia que indique que se llevó a cabo una revisión de la configuración de la nube, por ejemplo, proporciona el resultado tras la ejecución de NCC Scout Suite, AWS Config o similar. Si esto no se aplica a la organización, incluye en la evidencia un documento que explique por qué no es posible revisar la configuración de la nube.
• Elimina o reformula información confidencial en la evidencia, como los pasos detallados de reproducción de la vulnerabilidad, antes de enviarlos.

Si la organización NO trata los datos de la plataforma en un entorno de servidor o nube, debes hacer lo siguiente:

• Presentar evidencia que indique que se completó una prueba de penetración o se ejecutó una herramienta SAST. Dicha evidencia debe incluir lo siguiente:

  • Una declaración que manifieste el alcance de la prueba.
  • La fecha en que se completó la prueba, que debe ser dentro de los últimos 12 meses.
  • Un resumen o una lista de las vulnerabilidades detectadas durante la prueba. Estos deben incluir una categorización de la gravedad (por ejemplo, crítica, grave, media, baja, informativa). Habitualmente, esperamos que no queden vulnerabilidades críticas o graves sin resolver.
• Elimina o reformula información confidencial en la evidencia, como los pasos detallados de reproducción de la vulnerabilidad, antes de enviarlos.

Ejemplos de evidencia

Prueba de penetración: una organización encarga una prueba de penetración del software que ejecuta en el servidor y que se integra con las API de Meta y trata los datos de la plataforma. La empresa que realiza la prueba la completa y elabora un informe resumido como el que figura debajo. Observa las anotaciones en color rojo, que indican la fecha en que se realizó la prueba (debe ser dentro de los últimos 12 meses). También se ofrece un resumen de las vulnerabilidades críticas o graves no resueltas en el momento en que concluye la prueba (o la repetición de la prueba, si corresponde). Elimina o reformula información confidencial del informe (en particular, los pasos detallados de reproducción de la vulnerabilidad) antes de enviarlo.

Análisis estático: si se aplica un enfoque diferente, por ejemplo, una herramienta SAST, exporta los resultados a un documento que incluya la fecha en que se ejecutó la herramienta SAST y una lista de los hallazgos que indique el tipo de problema detectado y si es grave o crítico.

Revisión de configuración de la nube

Un desarrollador usa NCC Scout Suite con el conjunto de reglas predeterminado de su proveedor de servicios en la nube (en este caso, AWS) para revisar la configuración de la nube y detectar vulnerabilidades y problemas de seguridad. La herramienta genera un archivo JSON que incluye los resultados detallados de la ejecución. En este ejemplo, hay diversos problemas marcados con el nivel de gravedad "Peligro", que el desarrollador debe revisar y resolver.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

Otro enfoque para revisar la configuración de la nube para desarrolladores que usan el conjunto de reglas de Amazon Web Services.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

Protecciones alternativas aceptables

Si estás implementando un Programa de divulgación de vulnerabilidad activo (VDP), por ejemplo, las plataformas BugCrowd o HackerOne, puedes presentarlo como medida de protección alternativa en lugar de una prueba de penetración o un análisis de vulnerabilidades. Para demostrarlo, debes presentar evidencia que indique lo siguiente:

• No hay exclusiones en cuanto al alcance del VDP que sean relevantes en el tratamiento que realizas a los datos de la plataforma.
• No hay una investigación ni informes reales en curso sobre vulnerabilidades que correspondan a los últimos 12 meses. Esto habitualmente se registra con, al menos, un reporte de vulnerabilidad válido por mes.
• A las vulnerabilidades enviadas (válidas) se les asigna una puntuación de gravedad, por ejemplo, con el sistema CVSS 3.1.
• Las vulnerabilidades se resuelven en un intervalo razonable, que suele ser menor que 90 días después de la fecha en que se envía.

En este caso, la evidencia debe incluir lo siguiente:

• Una declaración del alcance y de qué manera se interrelaciona con el software que se usa para tratar los datos de la plataforma.
• Un informe de las presentaciones de vulnerabilidades reales en el programa en el transcurso de los últimos 12 meses. El informe debe incluir el título de la vulnerabilidad, la fecha de presentación, la fecha de resolución (si se resolvió) y la categoría o puntuación de gravedad.

Proteger la clave secreta de la app y los tokens de acceso a la API de Meta

Pregunta: ¿Se protegen la clave secreta de la app y los tokens de acceso a la API de Meta mediante ambas medidas?

1. Los tokens de acceso a la API de Meta nunca se almacenan en dispositivos de los clientes en un lugar que sea accesible fuera de la app y el usuario actuales.
2. Mediante el uso de un repositorio de datos (por ejemplo, Vault de Hashicorp) con un servicio de administración de claves independiente, en el caso de que se almacenen en una nube, un servidor o un entorno de centro de datos.

Intención

Las claves secretas de la app y los tokens de acceso son fundamentales como medida de seguridad cuando las API de Meta toman decisiones sobre qué acciones deben permitir. Si un agente no autorizado accede a estas credenciales, podría llamar a las API de Meta suplantando la identidad del auténtico desarrollador y realizar cualquiera de las acciones que autorizamos en la app (p. ej., leer los datos de nuestras API sobre los usuarios de la app).

• Tienes acceso a credenciales confidenciales cuando usas la plataforma de Meta. Específicamente:

  • Token de acceso: cuando alguien autoriza una app, el software obtiene esta credencial, que se usa en posteriores llamadas a la API.
  • Clave secreta de la app: Meta comparte esta clave con los desarrolladores con el objetivo de que solo accedan a ella agentes de confianza (p. ej., los administradores de apps) de la organización.
• Si un agente no autorizado consigue leer estas credenciales confidenciales, puede usarlas para llamar a las API de Meta como si fuera tú (lo que en ocasiones se conoce como suplantación de identidad), lo que deriva en el acceso no autorizado a los datos de la plataforma.
• Por lo tanto, estas credenciales deben protegerse de accesos no autorizados para evitar la suplantación.

Resumen de los requisitos

Tokens de acceso

1. En dispositivos cliente. Los tokens de acceso de Meta deben componerse de forma que ningún otro usuario o proceso puedan leerlos.
2. En el servidor. Si procesas o almacenas tokens de acceso de Meta en el entorno del servidor, estos deben cumplir los siguientes requisitos:
1. Deben protegerse mediante el uso de un repositorio de datos (por ejemplo, Vault de Hashicorp) con un servicio de administración de claves independiente y en un lugar donde el acceso a la clave de descifrado se limite a la app.
2. No deben escribirse en archivos de registro.

Clave secreta de la app. Debe darse uno de estos dos supuestos:

1. Nunca expusiste la clave secreta de la app fuera del entorno seguro del servidor (p. ej., la clave nunca fue devuelta por una llamada de red a un navegador o una app para celulares, y la clave secreta de la app no se insertó en el código que se distribuyó a los clientes de celulares, nativos o de escritorio).
2. Debes haber configurado la app como nativa o de escritorio para que nuestras API de Meta ya no confíen en las llamadas que reciben que incluyen la clave secreta de la app.

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación.

Incluye documentación sobre la política de protección de la clave secreta de la app y los tokens de acceso a la API de Meta. Si la app procesa tokens de acceso de Meta en el servidor, incluye evidencia que demuestre las protecciones que adoptas (p. ej., uso de un repositorio, evidencia que muestre que los valores se almacenan en un formato cifrado o configuración de la app que exija que se compruebe la clave secreta).

Ejemplos de evidencia

Una organización usa AWS Secrets Manager para almacenar datos confidenciales de forma segura, incluida la clave secreta de la app de Meta.

Una organización configuró su app de Meta de modo que se exija comprobar la clave secreta de la app en llamadas a la API.

Medidas de protección alternativas aceptables

1. Si no proteges los tokens de acceso almacenados en el servidor usando un repositorio de datos o cifrado en la app, tienes las siguientes opciones:
1. Proteger la clave secreta de la app usando un repositorio o cifrado en la app donde la clave solo está accesible para la app.
2. Configurar la app para que se exija comprobar la clave secreta de la app en todas las llamadas a la API a Meta.
2. En caso de que no sea factible adoptar el primer enfoque (es decir, si no puede exigir que se compruebe la clave secreta de la app porque bloquearía ciertas llamadas necesarias a la API), Meta tendrá en cuenta otros controles que hayas implementado para limitar el riesgo de uso no autorizado de los tokens de acceso, en comparación con el riesgo de uso indebido de los tokens de acceso almacenados.

Implementar un plan de respuesta a incidentes y probar los sistemas y procesos que se utilizan para este fin

Pregunta: ¿pruebas los sistemas y los procesos que usarías para responder ante un incidente de seguridad (p. ej., filtración de datos o ciberataque) al menos cada 12 meses?

Intención

Todas las empresas se enfrentan a incidentes de seguridad en algún momento. Por lo tanto, es crucial que las organizaciones planifiquen con antelación quién debe aplicar cada medida para controlar el incidente, comunicarlo a las partes interesadas, recuperarse y aprender de lo ocurrido.

• Si se produce un incidente de seguridad, haber diseñado previamente un plan o un manual junto a un equipo capacitado para abordar este problema puede disminuir la duración del incidente y, en última instancia, limitar la exposición de los datos de la plataforma.
• Aunque el nivel de sofisticación para responder a los incidentes variará en función de la empresa, requerimos, al menos, un plan básico que contemple las actividades clave (detección, reacción, recuperación y revisión) y los nombres de las personas asignadas a los distintos roles y responsabilidades.

Resumen de los requisitos

El desarrollador debe contar con lo siguiente:

• Un plan de respuesta a incidentes que cumpla los criterios mínimos de Meta.
• Este documento debe incluir al menos lo siguiente: (1) roles y responsabilidades; (2) detección; (3) pasos para tomar medidas de conformidad con las obligaciones legales aplicables (p. ej., notificación de filtración de datos a autoridades de supervisión y partes interesadas relevantes) y recuperación; y (4) un proceso de revisión posterior al incidente.
• Pruebas documentadas de que el plan se probó recientemente (en los últimos 12 meses) y todas las personas designadas en él participaron.

Guía de evidencia

Sigue las instrucciones que figuran en Preparación de evidencia a fin de preparar evidencia tanto de política y procedimiento como de implementación.

• Envía el plan de respuesta a incidentes (un documento o varios). Este debe abarcar los siguientes temas: roles y responsabilidades, detección, medidas y recuperación, y revisión posterior al incidente.

  • Si no cuentas con un plan de respuesta a incidentes, existen muchos recursos útiles disponibles en internet, como la plantilla de respuesta a incidentes y referencias y lecturas adicionales de Counteractive.
• Presenta evidencia que indique que probaste el plan en los últimos 12 meses. Puedes hacerlo de varias formas, pero debes incluir lo siguiente:

  • Una descripción de la situación (p. ej., un ejercicio de preparación en respuesta a un ataque de ransomware)
  • La fecha en que se realizó la prueba
  • El rol que desempeñó cada participante
  • Una justificación para los empleados designados en la sección de roles y responsabilidades del plan que no participaron
• Oculta la información confidencial (p. ej., información de identificación personal, como nombre o dirección de correo electrónico) en la evidencia que presentes antes de enviarla. Ejemplo de evidencia

Plan de respuesta a incidentes

Una desarrollador elaboró un plan de respuesta a incidentes integral en función de esta plantilla. En estas imágenes, se muestra solo el índice de contenido, pero debajo hay un enlace que dirige a la plantilla completa.

Consulta la plantilla del plan de respuesta a incidentes de Counteractive (formato docx) completa.

Prueba de respuesta a incidentes

Un desarrollador puso a prueba su plan de respuesta a incidentes mediante un ejercicio de preparación y documentó los resultados en esta plantilla.

Requerir la autenticación multifactor para accesos remotos

Pregunta: ¿Requieres autenticación multifactor para el acceso remoto a todas las cuentas que se pueden conectar a tu entorno en la nube o de servidor o que pueden acceder a los servicios que usas para implementar, mantener, supervisar y operar los sistemas en los que almacenas los datos de la plataforma de Meta?

Intención

Una técnica que los agentes malintencionados suelen emplear para acceder a datos confidenciales es obtener acceso en primer lugar a las herramientas con las que un desarrollador crea u opera su app o sistema. Existen herramientas sofisticadas diseñadas para hackear las cuentas que solo están protegidas con contraseñas. La autenticación multifactor constituye una medida adicional de seguridad que nos ayuda a protegernos frente a este riesgo.

• Los desarrolladores de software usan distintas herramientas para crear, implementar y administrar sus apps o sistemas.
• Estas herramientas se usan frecuentemente de forma remota a través de internet (p. ej., un empleado que trabaja desde casa y envía una nueva función de software o actualiza la configuración de la nube).
• Es muy probable que las herramientas protegidas con la autenticación de un solo factor (nombre de usuario y contraseña) sufran ataques dirigidos a apropiarse de las cuentas. Por ejemplo, los atacantes pueden probar distintas combinaciones de nombres de usuario y contraseñas que se filtraron desde una herramienta para obtener acceso a otra.
• Para protegernos de estos ataques, la autenticación multifactor solicita, además de una contraseña, un factor adicional (p. ej., un código generado por una app de autenticación) al iniciar sesión.

Resumen de los requisitos

En lo que respecta al tratamiento de los datos de la plataforma por parte de las organizaciones, este tipo de autenticación (que no se limita a solicitar una contraseña) puede proteger la integridad del acceso remoto a las siguientes herramientas:

• Herramientas para implementar y administrar cambios de código o configuración en la app o el sistema.
• Acceso administrativo a un entorno de servidor o nube (cuando corresponda).

En concreto, se requiere autenticación multifactor o una protección alternativa aceptable en los siguientes casos:

• Herramientas de colaboración o comunicación (p. ej., el correo electrónico del negocio o Slack).
• Repositorio de código (p. ej., GitHub u otras herramientas diseñadas para hacer un seguimiento de los cambios realizados en el código o la configuración de una app o un sistema).
• Además, en caso de tratar datos de la plataforma en el servidor:

  • Herramientas de implementación de software: se usan para implantar código en el entorno de servidor o nube (p. ej., Jenkins u otras herramientas de integración continua/implementación continua (CI/CD).
  • Herramientas administrativas: portales u otros tipos de acceso para administrar o supervisar el entorno de servidor o nube.
  • Acceso remoto a servidores: SSH, escritorios remotos o herramientas similares diseñadas para iniciar sesión de forma remota en servidores que operan en el servidor.

Respecto a la implementación de la autenticación multifactor:

• Se recomienda el uso de una app o hardware de autenticación (p. ej., YubiKey) y es preferible a utilizar códigos enviados por SMS.
• No obstante, las organizaciones pueden usar cualquier implementación de autenticación multifactor.

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación.

• La evidencia de la implementación debe mostrar que se aplica autenticación multifactor a las herramientas pertinentes para el entorno anteriormente indicado (es decir, herramientas de colaboración, repositorio de código, implementación en el servidor o la nube, portal administrativo del servidor o la nube, acceso remoto al servidor o la nube).
• La implementación variará en función de la configuración:

  • Por ejemplo, si usas un proveedor de inicio de sesión único (SSO), puede tratarse de una captura de pantalla de una configuración global de la organización o bien de una captura de una configuración específica de cada app.
  • Si no tienes un proveedor de SSO, puede ser una captura de pantalla de la configuración de una herramienta en particular.
• En todo caso, necesitamos evidencia de que la autenticación multifactor está habilitada para todos los usuarios y no tan solo un ejemplo de una cuenta con la autenticación habilitada.

Ejemplos de evidencia

AzureAD

Una organización usa AzureAD como solución de inicio de sesión único. Esta política requiere autenticación multifactor.

A continuación, se determinan las apps de la nube para las que se aplica esta política. Con este enfoque, la evidencia debe mostrar la totalidad de la sección Elementos seleccionados para aclarar qué apps de la nube requieren autenticación multifactor.

Okta

Esta regla requiere autenticación multifactor en todos los inicios de sesión.

AWS IAM

Este es un ejemplo de una política de AWS IAM que permite configurar la autenticación multifactor, pero prohíbe otras acciones si dicha autenticación no está presente.

GitHub

Una organización configuró la autenticación de GitHub para requerir la autenticación multifactor a todos los miembros de la organización.

Medidas de protección alternativas aceptables

• Para cualquier tipo de acceso remoto que exista en la organización, pero en el que no se aplique autenticación multifactor, es necesario describir si se usan uno o más de estos enfoques para evitar que alguien se apropie de la cuenta:

  • Requisitos de contraseña segura: p. ej., que las contraseñas tengan una complejidad mínima o prohibir palabras del diccionario o contraseñas que ya se sepa que sufrieron vulneraciones.
  • Interrupción de la autenticación: uso de una herramienta que introduzca períodos de espera cada vez mayores entre intentos fallidos de inicio de sesión con el mismo origen.
  • Bloqueos automáticos: p. ej., un mecanismo de bloqueo automático del inicio de sesión en una cuenta después de 10 intentos fallidos.

Sistema de mantenimiento de cuentas de usuario

Pregunta: ¿Dispones de un sistema de mantenimiento de cuentas (asignación, revocación, revisión del acceso y los privilegios)?

Intención

Mantener un buen estado de administración de las cuentas es muy importante para evitar que estas se utilicen de forma no autorizada con el objetivo de acceder a los datos de la plataforma. Concretamente, los desarrolladores deben asegurarse de revocar el acceso a los recursos o sistemas cuando ya no sea necesario.

• Las cuentas son la unidad básica de administración a la hora de conceder acceso a sistemas, datos y funciones administrativas.
• Los permisos que se conceden permiten realizar acciones específicas. Se recomienda conceder a cada cuenta los permisos mínimos que necesite, lo que se conoce como "principio de mínimo privilegio".
• Cuando alguien se va de una organización, es fundamental que sus cuentas de usuario se inhabiliten de inmediato por varios motivos:

  • (1) Para impedir el acceso de esa persona (es decir, el exempleado).
  • (2) Para reducir las probabilidades de que una persona no autorizada use la cuenta sin ser detectada. Por ejemplo, un agente malintencionado puede aplicar ingeniería social para que el servicio de asistencia de TI restablezca la contraseña de una cuenta. Si esta cuenta pertenece a un empleado actual, es muy probable que reporte que no consigue iniciar sesión. Pero si la cuenta que sigue activa pertenece a un exempleado, el problema puede pasar inadvertido.
• Teniendo esto en cuenta, las organizaciones deben contar con medios que les permitan administrar cuentas, conceder permisos o privilegios y revocar el acceso cuando ya no sea necesario de forma sistemática.

Resumen de los requisitos

• Debes disponer de herramientas o procesos para administrar las cuentas si trabajas con los siguientes sistemas, herramientas o apps:

  • Aquellos que se usan para comunicarse con otras personas (p. ej., Slack o correo electrónico comercial).
  • Aquellos que se utilizan para enviar software (p. ej., un repositorio de código).
  • Aquellos diseñados para administrar y operar el sistema (en relación con el tratamiento de los datos de la plataforma).
• Es necesario revisar los accesos concedidos con regularidad (como mínimo, una vez cada 12 meses) y disponer de un proceso que permita revocarlos si (1) ya no sean necesarios y (2) ya no se usan.
• También debes implementar un proceso que permita revocar el acceso a estas herramientas sin demora cuando alguien deje de pertenecer a la organización.
• Meta no requiere:

  • Que se utilice una herramienta en particular. Los desarrolladores pueden utilizar un producto de directorio como Google Cloud Identity o Microsoft Azure Active Directory, un producto en la nube como AWS Identity and Access Management (IAM), o bien una hoja de cálculo que se mantenga actualizada de forma habitual.
  • Que haya una única herramienta consolidada de administración de cuentas para los distintos tipos de acceso.

Guía de evidencia

Sigue las instrucciones que figuran en Preparación de evidencia a fin de preparar evidencia tanto de política y procedimiento como de implementación.

• Política o procedimiento: es necesario proporcionar políticas y procedimientos documentados referentes a las prácticas de administración de cuentas. Se espera que este documento contenga procedimientos de creación de cuentas, concesión de permisos, complejidad mínima de las contraseñas, política de bloqueo de cuentas, política de autenticación en varios pasos, procedimientos de restablecimiento de cuentas y proceso de revocación del acceso tras un período de inactividad y cuando alguien abandona la organización (p. ej., cuando un empleado renuncia o se lo despida).
• Evidencia de implementación: se debe aportar evidencia de al menos uno de los siguientes procesos o herramientas implementados para administrar cuentas (o bien indicar que no pueden aplicarse al entorno): (1) correo electrónico de la empresa y herramientas de colaboración; (2) repositorio de código; (3) herramientas de implementación en el servidor o la nube; (4) portal administrativo del servidor o la nube; (5) inicio de sesión remoto en el servidor o la nube (p. ej., SSH o escritorio remoto). Específicamente para la herramienta o el proceso representativos, es necesario incluir evidencia que demuestre lo siguiente:

  • Se revocó el acceso de exempleados de la organización a estas herramientas (p. ej., se elabora un informe de reconciliación que compara las cuentas de usuario con datos confiables de los miembros actuales de la organización).
  • Se revocan los accesos que llevan un tiempo inactivos (p. ej., se elabora un informe que muestra que la última fecha de acceso del titular representativo de una cuenta de usuario activa se sitúa dentro de los 90 días anteriores si el período máximo de inactividad es de tres meses).

Ejemplos de evidencia

Política o procedimiento: un desarrollador creó una norma de administración del ciclo de vida de acceso que incluye procedimientos para conceder, revisar y revocar el acceso.

Ejemplo de implementación: se revoca el acceso de exempleados

Un desarrollador usa Workday como fuente confiable de datos de Recursos Humanos (RR. HH.), incluida información sobre situación laboral actual. Este desarrollador usa Google Cloud Identity como proveedor de identidad (IdP) para administrar cuentas de usuarios y otorgar acceso a herramientas y sistemas de información.

Un desarrollador presenta evidencia que indica que se revoca el acceso de exempleados. Para ello, presenta un informe que muestra que se ejecutó un informe de reconciliación reciente (es decir, en los 12 meses) en el que se constata que no existen cuentas de usuario activas en Google Cloud Identity de empleados que ya no están trabajando, conforme a un informe de Workday sobre empleados actuales.

Ejemplo de implementación: se revoca el acceso cuando ya no se utiliza

Un desarrollador usa Google Cloud Identity como su proveedor de identidad (IdP) para administrar cuentas de usuarios y otorgar acceso a herramientas y sistemas de información.

Un desarrollador presenta evidencia que indica que se revoca el acceso cuando ya no se utiliza (es decir, no hubo inicios de sesión en los últimos seis meses). Para ello, usa el directorio de usuarios almacenado por inicio de sesión más reciente con el objetivo de demostrar que no existen cuentas de usuario activas en las que el último inicio de sesión fuera anterior a este.

Ejemplo de implementación: GitHub (repositorio de código)

Un desarrollador usa una herramienta de inicio de sesión único (SSO) para la administración de identidades y para conceder acceso a herramientas y sistemas de información. El desarrollador configuró GitHub para que solicite autenticación mediante SSO.

Mantener el software actualizado

Pregunta: ¿Tienes un sistema para mantener actualizados los entornos y el código del sistema, que incluya servidores, máquinas virtuales, distribuciones, bibliotecas, paquetes y software antivirus?

Intención

Los componentes de software se actualizan o corrigen constantemente para resolver vulnerabilidades de seguridad y, finalmente, agotan su vida útil cuando ya no son compatibles. Los desarrolladores que aprovechan o necesitan estos componentes deben disponer de información actualizada para no ejecutar software en el que se hayan detectado vulnerabilidades.

• Los desarrolladores de apps utilizan distintos tipos de software de terceros para ejecutar las apps o los sistemas con los que tratan los datos de la plataforma.
• Por ejemplo, los desarrolladores necesitarán algunos de estos componentes o todos ellos:

  • Bibliotecas, SDK y paquetes: para crear las apps, los desarrolladores empaquetan estos componentes agregando su propio código personalizado.
  • Imágenes de máquina virtual, contenedores de apps y sistemas operativos: las apps se ejecutan en uno o varios de estos contenedores, que ofrecen servicios como la virtualización y permiten acceder a las redes y las unidades de almacenamiento.
  • Navegadores, sistemas operativos y otras apps que utilizan los empleados y colaboradores: por ejemplo, el software que se ejecuta en computadoras portátiles y dispositivos móviles y que un desarrollador usa para crear y operar su sistema.
• En estos componentes se detectan constantemente vulnerabilidades de seguridad y, para corregirlas, se lanzan los parches.
• Las vulnerabilidades que se corrigen con estos parches se registran en bases de datos públicas y se clasifican por gravedad (baja, media, alta o crítica).
• Por lo tanto, los desarrolladores que usen la plataforma de Meta deben administrar los parches de forma sistemática en nuestra plataforma al:

  • Identificar parches valiosos para sus apps o sistemas.
  • Priorizar la urgencia en función de la exposición.
  • Aplicar parches en sus negocios de forma continua.

Resumen de los requisitos

En el caso de los siguientes componentes de software (según corresponda), necesitas medios definidos que te permitan identificar reiteradamente los parches disponibles para resolver las vulnerabilidades de seguridad, priorizar el riesgo y aplicar los parches de forma continua:

1. Bibliotecas, SDK, paquetes, contenedores de apps y sistemas operativos que se usan en entornos de servidor o nube.
2. Bibliotecas, SDK y paquetes que se usan en dispositivos cliente (p. ej., en apps para celulares).
3. Sistemas operativos y apps que usan los miembros para crear y operar sus apps o sistemas (p. ej., para operar los sistemas operativos y los navegadores que se ejecutan en las computadoras portátiles de los empleados).

Meta no requiere el uso de una herramienta específica para estas actividades. Es habitual que una organización use varios enfoques para mantener actualizados distintos tipos de software (p. ej., bibliotecas en la app frente a actualizaciones del sistema operativo de las computadoras portátiles de los empleados).

El siguiente diagrama muestra los casos en los que quizá sea necesario aplicar parches en distintos tipos de arquitecturas.

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación.

Dentro del ámbito de aplicación, comienza identificando los tipos de software en el entorno, p. ej., bibliotecas, SDK, paquetes, imágenes de máquina virtual, contenedores de apps, navegadores, sistemas operativos y otras apps que utilicen los empleados o colaboradores.

Es posible que cuentes con una o más herramientas que usas en las siguientes actividades:

• Inventario: un documento que consta de una captura de pantalla o que indica que una herramienta o proceso que, en última instancia, representa una lista de bibliotecas dentro del ámbito de aplicación, paquetes, SDK, contenedores, servidores de apps y sistemas operativos que requieren un parche. Es necesario que haya inventarios de una muestra representativa de los tipos de software (p. ej., apps en la nube, apps de clientes, dispositivos de empleados).
• Identificación de parches de software disponibles: es necesario contar con una herramienta o un proceso para identificar parches de seguridad existentes que sean pertinentes para el inventario.
• Priorización: debe existir una herramienta o un proceso (p. ej., tickets de Jira, incidencias de GitHub, hoja de cálculo de seguimiento) a través del cual se asigne una prioridad a los parches pertinentes.

  • Aplicación de parches
  • Un documento que conste de una captura de pantalla o que demuestre que, después de la identificación y la priorización de los parches pertinentes, estos se implementan en los destinos correspondientes.
• Incluye políticas relativas al uso de software de fin de vida útil (EOL) y tiempo de resolución.

Ejemplos de evidencia

Snyk para una aplicación de NodeJS: un desarrollador usa la interfaz de línea de comandos (CLI) de Synk para identificar dependencias empaquetadas de terceros con vulnerabilidades de seguridad conocidas y prioriza estas últimas en función de su gravedad.

NPM Audit

Un desarrollador usa NPM Audit para detectar vulnerabilidades en las dependencias usadas en una app de nodo. La siguiente imagen de ejemplo muestra diversas vulnerabilidades muy graves que requieren un parche.

Trivy

Un desarrollador usa Trivy para detectar vulnerabilidades en una imagen de máquina. La siguiente imagen de ejemplo muestra diversas vulnerabilidades muy graves en bibliotecas incluidas en esta imagen que requieren un parche.

Windows Server Update Services (WSUS)

Un desarrollador usa Windows Server Update Services (WSUS) para administrar su flota de servidores y equipos de escritorio o portátiles. La siguiente imagen de ejemplo muestra una vista de administrador de la herramienta WSUS, que permite revisar, aprobar e implementar actualizaciones de Windows.

Implementa un sistema para registrar el acceso a los datos de la plataforma y rastrear dónde se envían y almacenan

Intención

Sin archivos de registro confiables, puede resultarles difícil a los desarrolladores detectar el acceso no autorizado a los datos de la plataforma.

• Los registros de auditoría permiten a las organizaciones registrar que ocurrió un evento, por ejemplo, que un usuario particular realizó una consulta tomando los índices de una base de datos que contiene datos de la plataforma.
• Esos registros pueden respaldar procesos, como la activación de alertas automáticas, en función de actividades sospechosas o un análisis forense luego de que se identifique un incidente de seguridad.

Resumen de los requisitos

Si tratas datos de la plataforma en el servidor, debes hacer lo siguiente en dicho entorno:

• Mantén registros de auditoría que registren eventos clave (por ejemplo, acceso a datos de la plataforma, uso de cuentas con permisos elevados, cambios en la configuración del registro de auditoría).
• Los registros de auditoría se deben consolidar en un repositorio central y se deben proteger de modo que no se alteren ni eliminen.

Guía de evidencia

Si se te solicita presentar evidencia, debes demostrar lo siguiente:

• Estás al tanto de cómo se accede a los datos de la plataforma, y cómo se almacenan y se transfieren, por ejemplo, por medio de un diagrama de flujo de datos que muestre un panorama general del sistema, designe servicios que almacenan los datos de la plataforma, y muestre puntos de ingreso y egreso, incluidas transferencias previstas a servicios de terceros.
• Se implementaron registros de auditorías inviolables.
• Los eventos relacionados con el acceso a los datos de la plataforma se capturan en los registros.

Supervisa las transferencias de datos de la plataforma y de puntos clave por los que pueden abandonar el sistema (por ejemplo, terceros, puntos de conexión públicos).

Intención

Para una organización, conocer las expectativas de tratamiento de los datos de la plataforma y, luego, supervisar el tratamiento real son factores fundamentales para garantizar que dichos datos solo se usen para los fines previstos.

• Los desarrolladores deben estar al tanto de cómo los datos de la plataforma se almacenan, se transmiten por medio de redes y se escriben en copias de seguridad (que se pueden replicar en otros lugares).
• Por ejemplo, la supervisión hace posible identificar situaciones en las que los datos de la plataforma se transmiten de un modo inesperado, o bien determinar si se transmiten a través de una red sin el cifrado adecuado mientras están en tránsito, lo que te permite tomar medidas al respecto.

Resumen de los requisitos

Si tratas datos de la plataforma en el servidor, debes hacer lo siguiente en el entorno de dicho servidor:

• Mantén un diagrama de flujo de datos preciso que muestre dónde se almacenan, se tratan y se transmiten los datos en las diversas redes.
• Configura la supervisión (por ejemplo, registros de auditoría con un producto de supervisión automatizado) para controlar las transferencias de datos de la plataforma fuera del sistema.
• Si es posible, configura el sistema de supervisión para generar alertas que se revisen de inmediato en caso de transferencias inesperadas de los datos de la plataforma (consulta también el requisito que figura debajo: Establece un sistema automatizado para supervisar registros y otros eventos de seguridad, así como para generar alertas que adviertan sobre eventos anormales o relacionados con la seguridad).

Guía de evidencia

Si se te solicita presentar evidencia que demuestre esta protección, sigue las instrucciones que figuran en Preparación de evidencia para preparar evidencia que demuestre tanto la política o el procedimiento como la implementación.

Debes proporcionar evidencia que indiquen lo siguiente:

• Estás al tanto de cómo se accede a los datos de la plataforma, y cómo se almacenan y se transfieren, por ejemplo, por medio de un diagrama de flujo de datos que muestre un panorama general del sistema, designe servicios que almacenan los datos de la plataforma, y muestre puntos de ingreso y egreso, incluidas transferencias previstas a servicios de terceros.
• Se implementaron registros de auditorías inviolables.
• Los eventos relacionados con transferencias de datos de la plataforma se capturan en los registros; los eventos deben incluir la hora, la identidad del usuario o de la app que realiza la acción, y la fuente y el destino.

Establece un sistema automatizado para supervisar registros y otros eventos de seguridad, así como para generar alertas que adviertan de eventos anormales o relacionados con la seguridad

Intención

No es realista depender de personas para que revisen e identifiquen de forma manual comportamientos inesperados en un sistema moderno al que se puede acceder por internet. En lugar de ello, existen herramientas que pueden procesar archivos de registro y otras señales a fin de alertar sobre situaciones que se deben investigar más a fondo.

Resumen de los requisitos

Si tratas datos de la plataforma en el servidor, debes hacer lo siguiente en el entorno de dicho servidor:

• Contar con una herramienta capaz de procesar archivos de datos y otros eventos, y de establecer reglas que generen alarmas si se activan, así como un mecanismo que dirija las alarmas a las personas (por ejemplo, a un investigador que esté disponible).
• Procesar varias señales en la herramienta (por ejemplo, registros de accesos web, intentos de autenticación, acciones que realizan usuarios con privilegios elevados).
• Con el tiempo, ajustar y perfeccionar las reglas para equilibrar las señales con el ruido (es decir, evitar que haya demasiadas falsas alarmas, pero, a su vez, no ignorar eventos que ameriten una investigación).

Guía de evidencia

Un desarrollador comúnmente adoptaría una herramienta de administración de eventos y seguridad de la información para este fin, por ejemplo:

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

Debes proporcionar evidencia que indique que las fuentes de señales relevantes se dirigen a la herramienta elegida, que se configuraron alarmas o desencadenantes, que las alarmas se dirigen al personal responsable del seguimiento y, por último, que hay un proceso por el cual se ajustan las alarmas de manera periódica (por ejemplo, mediante revisión mensual o ciclos de actualización).

Glosario

A

Tercero o tercera parte: En la terminología de administración de riesgos, tercero o tercera parte se refiere a los desarrolladores de la plataforma de Meta (la primera parte es Meta y la segunda parte son las personas que usan los productos de Meta).

Cuarta parte: En la terminología de administración de riesgos, la cuarta parte hace referencia a las firmas en las que los desarrolladores dependen para prestarles servicios que les permitan llevar adelante sus negocios (la primera parte es Meta, la segunda parte son las personas que usan los productos de Meta y la tercera parte son los desarrolladores de la plataforma de Meta). Token de acceso: Una credencial, como una contraseña, que le permite al software llamar a una API para que realice una determinada acción (p. ej., leer datos del perfil de un usuario).

Amazon Web Services (AWS): Paquete de servicios de informática en la nube de Amazon.

Identificador específico de la app (ASID): Un identificador único que genera Meta cuando una persona elige usar una app. Los ASID ayudan a mejorar la privacidad de los usuarios al dificultar que los conjuntos de datos correlacionen los usuarios entre las apps, ya que un único usuario que use dos apps tendrá diferentes ASID en cada una.

Clave secreta de la app: Una clave secreta compartida que Meta pone a disposición de los desarrolladores a través del panel de apps. Contar con la clave secreta de la app autoriza al software a realizar algunas acciones a través de la API Graph; por lo tanto, los desarrolladores deben vigilar que las personas no autorizadas no puedan obtener acceso a la clave secreta de la app.

App comprometida: Si un agente malintencionado obtiene acceso no autorizado a la red interna de una organización a través de un error de configuración o vulnerabilidad en su app (p. ej., una vulnerabilidad del software en una app web), se dice que la app está comprometida. Una defensa contra una app comprometida es ejecutar una prueba de penetración en la app. Consulta también "red comprometida".

Contenedor de la app: Un contenedor empaqueta el código de software y las dependencias relacionadas para que la app se ejecute en diferentes tipos de servidores (p. ej., servidores que ejecutan diferentes sistemas operativos como Linux o Windows Server). Un desarrollador creará una imagen de un contenedor que empaquete su app. El motor o software de tiempo de ejecución de una app hospeda (ejecuta) la imagen del contenedor.

Cifrado de la app: Método para proteger los datos donde el software de la app realiza las operaciones de cifrado y descifrado. Por el contrario, la seguridad de la capa de transporte (TLS) cifra fácilmente los datos en tránsito cuando una app establece una conexión segura con un servidor remoto (p. ej., utilizando HTTPS) y los proveedores en la nube ofrecen servicios para cifrar datos en reposo de manera transparente.

Interfaz de programación de apps (API): Permite que dos computadoras se comuniquen a través de una red, por ejemplo, una app para celulares que carga el clima del día para una determinada ubicación desde un sistema de pronóstico del tiempo centralizado.

Prueba de la clave secreta de la app: Una capa adicional de seguridad para las llamadas de la API a Meta mediante la cual el desarrollador genera un parámetro (la prueba de la clave secreta de la app) que demuestra que posee dicha clave secreta. La prueba de la clave secreta de la app es el producto de una función hash (también llamada función unidireccional) que se basa en la clave secreta de la app y el token de acceso. Configurar una app para exigir pruebas de la clave secreta de la app durante las invocaciones de la API Graph reduce el daño potencial de una vulneración de tokens de acceso del usuario, ya que dichos tokens no se pueden usar sin el parámetro adicional de la prueba de la clave secreta de la app.

B

Backend como servicio (BaaS): Un modelo de computación en la nube que brinda a los desarrolladores de apps un conjunto de funciones del servidor para que puedan concentrarse en el desarrollo del frontend (es decir, la parte de la app con la que interactúan los usuarios). Las soluciones BaaS son similares a las PaaS y, además, agregan servicios como autenticación de usuarios y notificaciones push para dispositivos móviles. Por ejemplo, estos son algunos de los productos BaaS populares: AWS Amplify, Azure Mobile Apps, Firebase y MongoDB Switch.

C

Texto cifrado: Sinónimo de datos cifrados; texto cifrado es el nombre que se les otorga a los datos que se transforman a un formato ilegible a través de un algoritmo de cifrado. Lo opuesto a texto cifrado es texto sin formato.

Lado cliente: Las personas normalmente interactúan con servicios accesibles desde internet al abrir un sitio web en un navegador o al ejecutar una app para celulares en un teléfono o tableta. Se hace referencia al navegador o la app para celulares como "lado cliente" o "del cliente local". Los clientes formulan solicitudes desde computadoras remotas (servidores) a través de internet.

Computación en la nube: Se refiere a un estilo de administración de servidores, redes y almacenamiento de modo que una organización no tenga que preocuparse del entorno físico (es decir, un centro de datos lleno de estanterías de servidores y cables de red). En su lugar, la organización puede adquirir estos activos según sea necesario y pagar los servicios que consumen.

Configuración de la nube: El conjunto de opciones de computación en la nube que una organización establece según el uso que hace de un proveedor en la nube que ejecuta un determinado software. Algunos ejemplos de configuración de la nube incluyen qué tipos de conexiones en la red se permiten o bloquean, dónde se escriben los archivos de registro y durante cuánto tiempo se conservan, y el conjunto de usuarios autorizados a hacer cambios en la configuración de la nube.

Controles compensatorios: Un control de seguridad que difiere de un conjunto de requisitos de referencia, pero cuyo objetivo es entregar protección comparable contra un riesgo.

D

Base de datos: Software que permite almacenar, leer, actualizar y eliminar datos arbitrarios. Las bases de datos se pueden ejecutar en clientes y en servidores. Las organizaciones que se integran con la plataforma de Meta almacenarán comúnmente los datos que obtienen de la API Graph en una base de datos que se ejecuta en un servidor.

Descifrado: Proceso mediante el cual datos cifrados se restituyen a su formato original. En otras palabras, el descifrado transforma texto cifrado en texto sin formato.

E

Cifrado: Proceso mediante el cual los datos se traducen a un formato que no puede ser utilizado por quien no pueda descifrarlos. En otras palabras, el cifrado transforma texto sin formato en texto cifrado.

Cifrado en reposo: Datos protegidos mediante cifrado al escribirse en un almacenamiento persistente (p. ej., una unidad de disco). El cifrado en reposo brinda una capa adicional de protección contra el acceso no autorizado, ya que un agente que puede leer los archivos sin procesar en un dispositivo de almacenamiento verá el texto cifrado, pero no podrá descifrarlo hasta tanto no obtenga acceso a la clave de descifrado.

Cifrado en tránsito: Datos protegidos mediante cifrado al transmitirse por una red. El cifrado en tránsito brinda protección contra la interceptación por la ruta de acceso de red, ya que un agente que puede leer los paquetes de red verá el texto cifrado, pero no podrá descifrarlo hasta tanto no obtenga acceso a la clave de descifrado.

Software que llegó al fin de la vida útil (EOL): Cuando una organización elige dejar de brindar soporte (p. ej., crear parches para resolver vulnerabilidades de seguridad) para un producto de software, se considera que el software llegó al fin de su vida útil (software EOL). Como el software deja de recibir mantenimiento, es muy riesgoso ejecutar un software EOL.

G

Plataforma Google Cloud (GCP): Conjunto de servicios de computación en la nube de API Graph de Google; la forma principal en que las apps leen y escriben en la gráfica social de Meta. Todos los SDK y los productos de Meta interactúan con la API Graph de alguna manera.

H

Función Hash: Función criptográfica que toma cualquier dato como valor de entrada y lo convierte en un código corto que no se puede revertir a la entrada original. En criptografía, las funciones hash se usan para proteger datos como contraseñas, en lugar de almacenar la contraseña de un usuario como texto simple que podría ser robado, las contraseñas se transforman primero con una función hash y luego se almacenan. Por último, para confirmar que un usuario introdujo la contraseña correcta, el sistema utilizará la misma función hash para transformar la entrada y comparar el hash resultante con el valor almacenado. También llamada función unidireccional, ya que el hash de salida no se puede revertir a la entrada original.

Entorno hospedado: Se refiere a un conjunto de servidores, redes y dispositivos de almacenamiento remotos que una organización ejecuta en su propio centro de datos o dentro de un centro de datos ubicado en conjunto (o co-ubicado) con otros clientes. Este acuerdo es relativamente poco común en la era moderna debido a que la computación en la nube se ha vuelto más popular.

I

Proveedor de identidad (IdP): Un servicio en la nube usado para centralizar la administración de identidades digitales y autenticar usuarios. Las organizaciones que utilizan el IdP normalmente configuran apps en la nube para basar la autenticación de un usuario en el IdP. La organización puede así administrar usuarios concediendo acceso a apps seleccionadas, creando e inhabilitando cuentas de usuario de manera centralizada dentro del IdP, en lugar de tener que hacerlo de forma repetitiva con cada app en la nube.

Administración de identidades y acceso (IAM): Se refiere a la categoría de herramientas y procesos que se utilizan para administrar cuentas y conceder acceso a los sistemas.

Infraestructura como servicio (IaaS): Un enfoque de computación en la nube que les permite a los clientes configurar servicios de computación, almacenamiento y redes sin ser responsables de los activos físicos (p. ej., administrar un centro de datos repleto de servidores, dispositivos de red y matrices de almacenamiento). En comparación con PaaS, IaaS le otorga a una organización más control sobre la configuración de sus activos de la nube, pero a costa de una mayor complejidad a la hora de administrar esos activos. Por ejemplo, estos son algunos de los productos IaaS populares: AWS EC2, Microsoft Azure IaaS y Google Compute Engine.

L

Biblioteca: Componente fundamental de software preexistente, por lo general, de una empresa o desarrollador externo, que se utiliza para manejar ciertas tareas dentro de la app o del sistema de otro desarrollador. Las bibliotecas simplifican el desarrollo de una app porque un desarrollador no tiene que empezar de cero cuando ya existe una biblioteca para una determinada función. Sin embargo, las bibliotecas pueden contener vulnerabilidades de seguridad, o pueden incluir bibliotecas adicionales que sí las contengan. Por lo tanto, los desarrolladores que utilizan bibliotecas como parte de su app deben saber qué bibliotecas están en uso y mantenerlas actualizadas en el tiempo.

M

App de un cliente de telefonía celular o app para celulares: App que una persona instala en un teléfono o tableta desde la tienda de apps para celulares (p. ej., iOS App Store o Google Play Store). Es común que los clientes de telefonía celular se comuniquen a través de internet con la API REST de una organización y también lo hagan con otras partes (p. ej., con el API Graph vía el SDK de Facebook para Android).

Autenticación multifactor (MFA): Método de autenticación que requiere de más de un factor para obtener acceso a una app o un sistema. En comparación con la autenticación de un factor que solo se basa en una contraseña para autenticar a un usuario, la MFA normalmente requerirá una contraseña más uno o más de estos: un código enviado por correo electrónico o SMS, un código de una app de autenticación, una exploración biométrica o una llave de seguridad. La MFA protege de las apropiaciones de cuentas al hacer más difícil que personas no autorizadas entren a la fuerza a una cuenta, p. ej., iniciando sesión después de varios intentos con una dirección de correo electrónico conocida y contraseñas comunes hasta lograrlo.

N

Software nativo: Las apps que se descargan e instalan en computadoras portátiles o dispositivos móviles se conocen como software nativo (p. ej., la app de Facebook para iOS). En oposición, una app que se ejecuta dentro de un navegador se conoce como app web (p. ej., abrir Facebook con el navegador Chrome).

Red comprometida: Si un agente malicioso logra obtener acceso no autorizado a la red interna de una organización mediante un error de configuración o vulnerabilidad de la red, eso se conoce como red comprometida. Una defensa contra una red comprometida es ejecutar un análisis para identificar errores de configuración y vulnerabilidades de la red con acceso a internet. Consulta también "app comprometida".

Escaneo de red: Un proceso de gestión de riesgo que utiliza software a fin de (1) identificar servidores activos en una red que responderán a comunicaciones remotas, y luego (2) comprobar si alguno de esos servidores está ejecutando versiones antiguas de software que se sabe que son susceptibles de una o más vulnerabilidades de seguridad. Una organización puede usar el escaneo de red periódicamente, por ejemplo, para asegurarse de que no haya puertos abiertos inesperados en el perímetro de su red.

Node Package Manager (NPM): Una herramienta que utilizan los desarrolladores de JavaScript para acelerar el desarrollo al permitir que se incluyan paquetes pregenerados en la app o el sistema de un desarrollador. NPM incluye funciones para auditar el conjunto de paquetes que la app utiliza e identificar paquetes que tienen vulnerabilidades de seguridad conocidas.

O

Depósitos de almacenamiento de objetos: Un tipo de almacenamiento persistente en la nube que facilita que las organizaciones guarden archivos en almacenamiento persistente, incluso archivos que son muy grandes, sin tener que preocuparse por ampliar activos físicos como matrices de almacenamiento, ni por cómo realizar copias de seguridad de los archivos para asegurarse de que no se pierdan en caso de un desastre, como un incendio o una inundación.

Sistema operativo: El software que se ejecuta en una computadora o dispositivo móvil que permite que las apps se ejecuten y utilicen el procesador, la memoria, el almacenamiento y los recursos de red de esa computadora. Por ejemplo, Windows de Microsoft, macOS de Apple o iOS y Linux.

Miembro de la organización: Una persona con una función y responsabilidades dentro de una organización, por ejemplo, un empleado, un contratista, un trabajador temporal, un pasante o un voluntario.

Dispositivo de la organización: Una computadora o dispositivo móvil utilizado por el miembro de una organización al desempeñar una tarea para ella.

P

Condición de la plataforma 6.a.i: Se refiere a la sección (6), encabezado (a), inciso (i) de las Condiciones de la plataforma de Meta que describe las obligaciones de los desarrolladores de la plataforma en materia de seguridad de datos.

Paquete: Sinónimo de biblioteca.

Parche: Actualizaciones de software que resuelven vulnerabilidades de seguridad, corrigen errores o agregan funcionalidades nuevas. Todos los tipos de software reciben parches, incluso los sistemas operativos, los contenedores, las bibliotecas y los SDK.

Prueba de penetración: Un ataque simulado contra una app o un sistema en el que el evaluador intenta detectar vulnerabilidades en el código o la configuración que podrían ser aprovechadas por un agente no autorizado. Los evaluadores de penetración usan herramientas similares a los cibercriminales para llevar a cabo tareas de reconocimiento, detectar potenciales debilidades y probar las vulnerabilidades que se podrían utilizar para obtener acceso no autorizado. Al final de esta prueba, el evaluador creará un informe que describa los hallazgos, junto con la gravedad de cada uno, y la organización que mantiene el software es responsable de preparar las correcciones para resolver las vulnerabilidades.

Texto sin formato: Un sinónimo de datos sin cifrar; es el nombre que se les da a los datos que no están protegidos con cifrado. Plataforma como servicio (PaaS): Un enfoque de computación en la nube donde el cliente implementa una app en una plataforma administrada por el proveedor de servicios en la nube. En comparación con IaaS, PaaS es más simple de administrar para los clientes, ya que el host de la nube no solo administra los activos físicos (es decir, los servidores, dispositivos de almacenamiento y dispositivos de red), sino también el sistema operativo y el contenedor de la app donde se ejecuta la app del cliente. Por ejemplo, estos son algunos de los productos PaaS populares: AWS Elastic Beanstalk, Google App Engine y Force.com.

Puerto: Cuando un cliente hace una conexión a un servidor por internet, la dirección de destino tiene dos partes: (1) una dirección de protocolo de internet (IP) para el servidor y (2) un número de puerto en ese servidor al que responderá una app en particular. Los protocolos comunes usan puertos reservados (p. ej., HTTPS usa 443), pero un desarrollador puede usar puertos personalizados para las comunicaciones de red si lo desea.

R

API REST: Un estilo ampliamente adoptado para desarrollar servicios accesibles por web donde el cliente y el servidor se comunican utilizando el protocolo HTTP. Un desarrollador en la plataforma de Meta puede hospedar una API REST en un subdominio como api.ejemplo.com, desde el que su app para celulares envía y recibe datos de la plataforma.

S

Secure Shell (SSH): Un protocolo de comunicación seguro que permite que los administradores inicien sesión en los servidores de forma remota y ejecuten programas en dichos servidores. Se dice que es seguro porque las comunicaciones entre el cliente y el servidor están protegidas de filtraciones, a diferencia de los protocolos anteriores como Telnet. También se lo denomina Secure Socket Shell.

Secure Sockets Layer (SSL): Una versión obsoleta y no segura de cifrado en tránsito. La versión segura moderna se denomina seguridad de la capa de transporte (TLS).

Servidor: Una computadora que proporciona servicios de modo remoto a través de una red. Los navegadores y apps para celulares se conectan a los servidores por internet.

Computación sin servidor: Un modelo de computación en la nube donde el host de la nube administra la infraestructura física, el sistema operativo del servidor y el contenedor. El desarrollador solo es responsable del código personalizado y las bibliotecas asociadas, además de la configuración de la nube.

Lado servidor: A los datos o la computación del otro lado de una conexión de red (es decir, en un servidor) se los llama "del servidor" o "lado servidor". En contraposición, a los datos o la computación en un dispositivo local, como una computadora portátil o dispositivo móvil, se los llama "del cliente" o "lado cliente".

Inicio de sesión único (SSO): Una disposición en la que las apps dependen de un directorio de usuarios centralizado (es decir, un IdP) para autenticar a los usuarios. Además de centralizar la administración de las cuentas de los usuarios y el acceso a la app para la organización, los usuarios se benefician de tener un único conjunto de credenciales, en lugar de exigirles que tengan diferentes credenciales (p. ej., un nombre de usuario y una contraseña) para cada app.

Kit de desarrollo de software (SDK): Un componente básico de código que un desarrollador puede utilizar para simplificar el proceso de desarrollo para una determinada necesidad. Por ejemplo, Meta crea y mantiene SDK que simplifican el trabajo con la API Graph para los desarrolladores de iOS y Android. De manera similar a una biblioteca, los desarrolladores que usan SDK en sus apps tienen que mantenerlos actualizados con el transcurso del tiempo.

Software como servicio (SaaS): Permite que los clientes usen apps basadas en la nube a través de internet. A diferencia de PaaS o IaaS, un cliente de una app SaaS no despliega código personalizado ni tiene la responsabilidad de configurar, actualizar o emparchar la app SaaS, ya que todo esto es responsabilidad del proveedor de dicha app. Por ejemplo, estos son algunos de los productos SaaS populares: Dopbox, MailChip, Salesforce y Slack.

Análisis estático: Consulta "Pruebas de seguridad de apps estáticas".

Pruebas de seguridad de apps estáticas (SAST): Un enfoque para detectar vulnerabilidades en software mediante la ejecución de una herramienta especializada contra el código fuente. Una herramienta SAST identificará vulnerabilidades potenciales, como aquellas mencionadas en el proyecto OWASP Top 10. Luego, el desarrollador es el encargado de revisar los hallazgos, distinguir verdaderos positivos de falsos positivos y corregir las vulnerabilidades en el software. Una herramienta SAST puede ser útil porque permite que los desarrolladores encuentren vulnerabilidades antes de que se desplieguen en la producción. Sin embargo, a diferencia de una prueba de penetración, una herramienta SAST no podrá detectar vulnerabilidades en la configuración de producción de la app.

T

Cifrado de datos transparente: Un tipo de cifrado en reposo que suele aplicarse al almacenamiento de las bases de datos (es decir, el contenido de la base de datos en sí y sus archivos de registro). Con esta disposición, el software de la base de datos administra las claves de cifrado y maneja de modo transparente las operaciones de cifrado (al escribirse) y las operaciones de descifrado (al leerse).

Seguridad de la capa de transporte (TLS): Un modelo de cifrado en tránsito que utiliza el cifrado para proteger los datos transmitidos por redes de filtraciones en la ruta de acceso de red. TLS es la versión segura moderna de la tecnología obsoleta anterior llamada SSL.

Autenticación en dos pasos (2Fac): Un sinónimo de autenticación multifactor. Almacén: Un sistema de administración secreto para datos confidenciales como claves de cifrado, tokens de acceso y otras credenciales. Un almacén permite tener un estricto control sobre quién puede acceder a los secretos que contiene y ofrece servicios adicionales, como el almacenamiento de registros de auditoría.

V

Máquina virtual (VM): Una máquina virtual es muy similar a un contenedor de apps; se ejecuta en un host llamado hipervisor, mientras que un contenedor de apps se ejecuta en un motor de contenedor. La principal diferencia es que una imagen de la máquina virtual contiene un sistema operativo, mientras que un contenedor de apps no. Tanto las máquinas virtuales como los contenedores de apps contienen apps y dependencias como bibliotecas.

Nube privada virtual (VPC): Un término utilizado por AWS para referirse a un conjunto de recursos en la nube que se asemejan a una red tradicional en un centro de datos en la época previa a la nube.

Vulnerabilidad: Un defecto en un sistema o app del que alguien podría aprovecharse, por ejemplo, para leer datos que no tendría derecho a leer de otro modo.

Programa de divulgación de vulnerabilidades (VDP): Un enfoque en el que las organizaciones encargan informes de vulnerabilidades de seguridad a investigadores (a veces llamados "hackers éticos") para que se puedan detectar y corregir las vulnerabilidades antes de que las aprovechen agentes maliciosos. Un VDP eficaz requiere una serie de investigadores que busquen vulnerabilidades de manera activa, analistas dentro de la organización que revisen las divulgaciones entrantes y evalúen su prioridad, e ingenieros expertos en ciberseguridad que puedan crear y desplegar las correcciones pertinentes.

Escaneo de vulnerabilidad: Un enfoque que utiliza software para buscar vulnerabilidades en servidores, redes y apps. En comparación con una prueba de penetración, ejecutar un escaneo de vulnerabilidad es más económico y, por lo tanto, se puede ejecutar reiteradamente (p. ej., de manera mensual o trimestral). Sin embargo, una prueba de penetración suele detectar las vulnerabilidades que no detectó un escaneo de vulnerabilidad debido a que los expertos evaluadores de penetración aportan habilidades analíticas e instintos que son difíciles de replicar dentro de los enfoques estrictamente automáticos. Consulta también "escaneo de red".

W

App web: Las apps web son programas que se ejecutan dentro de los navegadores y están compuestas por recursos como documentos HTML, código JavaScript, videos y otros archivos multimedia y CSS para la aplicación de estilos. En oposición a una app para celulares que una persona instala en su teléfono celular desde una tienda de apps, una persona simplemente selecciona una app web en un servidor remoto desde su navegador (p. ej., www.facebook.com) sin necesidad de tener que seguir los pasos de instalación.