Data Security Requirements

Preparación para responder preguntas sobre seguridad de los datos

Procesos de datos

Crea (o actualiza, si fuera necesario) un esquema del proceso de datos o una descripción que indique cómo la aplicación o el sistema realiza el tratamiento de los datos de la plataforma.

1. Lado del cliente: incluye todo el software del cliente, como los navegadores, los dispositivos móviles y cualquier otro tipo de dispositivos compatibles.
2. Lado del servidor: incluye todos los servidores o entornos en la nube relacionados e identifica lo siguiente:
1. Los componentes a través de los cuales los datos de la plataforma:
1. entran en el entorno del servidor o salen de este (p. ej., oyentes web y API REST)
2. se escriben en espacios de almacenamiento duraderos, como bases de datos, discos o archivos de registro
2. El modelo de alojamiento, por ejemplo:
1. Alojamiento propio: los servidores de una organización, ubicados en un centro de datos propio o compartido.
2. Infraestructura como servicio (IaaS): como AWS EC2, Microsoft Azure IaaS o Google Compute Engine.
3. Plataforma como servicio (PaaS): como AWS Elastic Beanstalk, Google App Engine o Force.com.
4. Backend como servicio (BaaS): como AWS Amplify, Azure Mobile Apps, Firebase o MongoDB Switch.
5. Híbrido: una combinación de los modelos anteriores.

Esto es lo que, en última instancia, debe incluir el esquema del proceso de datos o la descripción:

1. Dónde se generan los identificadores de acceso de la API de Meta y dónde se transmiten, almacenan y renuevan, tanto en el software del cliente como en el del servidor (si el diseño del sistema lo permite).
2. Cómo recuperas datos de la plataforma de las API de Meta, especialmente la información de identificación personal 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 utilizas, conservas y transmites dichos datos.
4. Los proveedores de terceros a los que se envíen los datos de la plataforma.

Preparación de documentación de prueba

Es posible que debas enviar documentación de prueba 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 documentación de prueba 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 documentación de prueba

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

1. Documento de prueba 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. Documento de prueba 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 una determinada protección.

Documento de prueba de política o procedimiento

Documento de prueba de política o procedimiento, también denominado documento de 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, el documento de prueba 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 a la pregunta en cuestión para dirigir a nuestros revisores a las secciones relevantes.

Documento de prueba de implementación

Un documento de prueba de implementación muestra directamente la manera en que implementaste la política o el procedimiento en la práctica 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. El documento de prueba 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 documentación de prueba

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

1. El documento de prueba de política o procedimiento debe cumplir o exceder los requisitos de Meta
1. Meta revisará el documento de prueba 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 en el documento se destaquen 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, un documento 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 esté 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 estén inhabilitados: SSL v2, SSL v3, TLS 1.0 y TLS 1.1
2. El documento de prueba 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á el documento de prueba de implementación para asegurarse de que coincida con el documento de prueba 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, un documento de prueba 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 documentación de prueba

No envíes documentación de prueba que contenga alguno de estos valores de manera legible (sin ocultar). Si utilizas un editor de imágenes para hacer una captura de pantalla, oculta el valor en cuestión con un cuadro de texto negro. Si utilizas un editor de PDF, asegúrate de ocultar el texto utilizando una herramienta que realmente elimine el valor en lugar de limitarse a añadir una capa y conservar el texto (p. ej., la herramienta de eliminación en la aplicación de previsualización de Apple).

• Datos sanitarios
• Datos financieros
• Direcciones IP
• Contraseñas, credenciales e identificadores de acceso
• Claves de cifrado
• Direcciones postales
• Información de identificación personal sobre una persona física (excluidas las empresas y otras organizaciones empresariales), 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 sanitarios
  • Afiliación política, social o cultural
  • Datos que de cualquier otro modo permitan identificar a una persona en el contexto específico del documento presentado
• 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.

Protección de datos de la plataforma almacenados del lado del servidor con cifrado en reposo

Pregunta: ¿aplicas cifrado en reposo a todos los datos de la plataforma almacenados en la nube o un entorno de centro de datos o de servidor?

Propósito

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 servidores o entornos en la nube, donde suelen concentrarse los datos de la plataforma relacionados con todos los usuarios de una aplicación, el cifrado en reposo reduce el riesgo de filtración de datos.
• Entre otras amenazas, este tipo de cifrado protege 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 requisitos

En caso de almacenar datos de la plataforma del lado del servidor:

• Es OBLIGATORIO proteger los datos:

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

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

  • Puedes aplicar la medida en la aplicación (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 del lado del servidor, no se aplicará este requisito.

Casos especiales

Almacenamiento del lado del servidor mediante infraestructuras como servicio (IaaS), autoalojamiento o alojamiento híbrido

Esta pregunta es pertinente si almacenas datos de la plataforma a través de alojamiento de IaaS (como AWS EC2, Microsoft Azure IaaS o Google Compute Engine), autoalojamiento o una estrategia híbrida.

Almacenamiento del lado del servidor con productos de software como servicio (SaaS), plataforma como servicio (PaaS) o backend como servicio (BaaS)

No obstante, hay otros modelos de alojamiento de backend que se consideran casos especiales.

Esta pregunta no es pertinente si almacenas datos de la plataforma mediante alguna de las opciones siguientes (y no usas IaaS, autoalojamiento ni alojamiento híbrido). En su lugar, debes describir esta relación en la sección “Proveedor de servicios” de la Evaluación de la 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 o Salesforce.

Almacenamiento del lado del servidor con API de Meta

Esta pregunta no es pertinente si almacenas datos de la plataforma únicamente a través de una API de Meta (por ejemplo, con player.setDataAsync()) en el SDK de juegos instantáneos.

Información sobre pruebas

Si se te solicita la presentación de pruebas que demuestren esta protección, es necesario que sigas las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

Ejemplos de pruebas 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 siguientes comandos.

$ aws dynamodb list-tables --output table

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


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

"ENABLED"

AWS DocumentDB

Es necesario configurar AWS DocumentDB para aplicar cifrado en reposo. Para obtener un grupo 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 de AWS S3 pueden configurarse para aplicar 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 permitidas

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

1. Confidencialidad de los datos de la plataforma: si el almacenamiento de datos específicos de la plataforma se considera de alto o bajo riesgo. Deberás determinar qué atributos de usuario de datos de la plataforma específicos se almacenan del lado del 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 aplicaciones 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 las pruebas: es necesario indicar si un auditor independiente ha evaluado estas protecciones, por ejemplo como parte de una auditoría SOC2.

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

Pregunta: en referencia a datos almacenados en dispositivos personales y de la organización, ¿se aplica cifrado en reposo a todos los datos de la plataforma almacenados en estos dispositivos, o cuentas con reglas y políticas para reducir el riesgo de pérdida de datos?

Propósito

En caso de que un desarrollador permita almacenar datos de la plataforma en dispositivos como portátiles de empleados o unidades de almacenamiento extraíbles (p. ej., unidades USB), existe un riesgo elevado 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 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 sí permitida). Dichos 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 formaciones anuales sobre la gestión permitida de los datos de la plataforma en dispositivos personales y de la organización.

Información sobre pruebas

Si se te solicita la presentación de pruebas que demuestren esta protección, es necesario que sigas las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

Puedes utilizar una de las opciones siguientes 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 portátiles y teléfonos móviles.

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 permitidas y no permitidas 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, formación o recordatorios periódicos por correo electrónico).

Ejemplos de pruebas

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 ha creado normas sobre el uso de los datos y obliga a todo el personal a conocer y cumplir estas políticas.

Protección de los datos de la plataforma transmitidos por 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? Además, ¿te aseguras de que los datos de la plataforma no se transmitan en ningún caso por redes públicas de forma no encriptada (p. ej., mediante HTTP o FTP) y de que nunca se usen los protocolos de seguridad SSL v2 y SSL v3?

Propósito

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 o impedir su lectura por parte de terceros no autorizados.

• Para proteger los datos de la plataforma que se transmiten entre redes no fiables (como internet), el cifrado en tránsito hace que resulten ininteligibles 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 (a estas intromisiones se las denomina 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 requisitos

Tanto si se tratan datos de la plataforma del lado del servidor como si no:

• 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:

  • Debes habilitar TLS 1.2 o una versión superior.
  • Debes inhabilitar 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 superior.
• Meta recomienda, pero no exige, que el cifrado en tránsito se aplique a las transmisiones de datos de la plataforma que se encuentren en redes privadas en su totalidad, p. ej., la nube privada virtual (VPC).

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

Información sobre pruebas

Si se te solicita la presentación de pruebas que demuestren esta protección, es necesario que sigas las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación. Usar la herramienta de prueba del servidor SSL de Qualys es una manera directa de producir pruebas de implementación que demuestren 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 los que se ejecuten en puertos distintos a los estándar).
• Marca la opción "No mostrar los resultados en los paneles" para evitar que los resultados se añadan 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 los que transmites datos de la plataforma, o de quienes los recibes, y que tienen una configuración TLS diferente.

Ejemplos de pruebas 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 solo incluye las primeras dos páginas, pero debes incluir el resultado completo de la prueba.

Medidas de protección alternativas permitidas

Es posible que protejas los datos en tránsito de la plataforma mediante un tipo diferente de cifrado distinto a TLS. Esto puede ser aceptable si proporciona un nivel de protección equivalente. En este caso, deberás enviar los detalles sobre el tipo de cifrado usado para que Meta lo revise:

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

Testeo para detectar vulnerabilidades y problemas de seguridad en la aplicación y los sistemas

Pregunta: ¿Realizas tests en a la aplicación y los sistemas para detectar vulnerabilidades y problemas de seguridad al menos cada 12 meses? (Por ejemplo, ¿realizas tests de penetración manuales?).

Propósito

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

• Desarrolladores de aplicaciones que usan la plataforma de Meta para tratar datos de la plataforma con software que programan por medio de aplicaciones 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 a los datos de la plataforma de forma no autorizada.

Resumen de requisitos

Aplicables a todos los desarrolladores:

• Debes haber testeado el software que se usa para tratar datos de la plataforma con el objetivo de detectar vulnerabilidades por medio de lo siguiente:

  • Un test de penetración en la aplicación o el sistema.
  • Un escaneo o análisis estático del software para detectar vulnerabilidades.
• Asimismo, los resultados del test deben indicar que no quedan vulnerabilidades críticas o graves sin resolver.
• El test debe haberse llevado a cabo en los últimos 12 meses.

Requisitos adicionales para desarrolladores que tratan datos de la plataforma del lado del servidor:

• Debes haber testeado específicamente el software del lado del servidor por medio de lo siguiente:

  • Un test de penetración en la aplicación o el sistema.
  • 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 alojamiento en la nube. Este requisito se aplica independientemente de la modalidad de alojamiento (p. ej., backend como servicio, plataforma como servicio, infraestructuras como servicio, alojamiento propio o un modelo híbrido).

Información sobre pruebas

Si se te solicita la presentación de pruebas que demuestren esta protección, es necesario que sigas las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

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

• Presentar pruebas que demuestren que se ha realizado un test de penetración o se ha ejecutado una herramienta de análisis estático de software. Las pruebas deben incluir lo siguiente:

  • Una declaración que establezca el ámbito del test.
  • La fecha en la que se ha llevado a cabo el test (debe haberse realizado en los últimos 12 meses).
  • Un resumen o una lista de las vulnerabilidades detectadas durante el test. Debe incluir una categorización de la gravedad (p. ej., crítica, grave, media, baja, informativa). Se espera que no queden vulnerabilidades críticas o graves sin resolver.

• Si corresponde (es decir, si usas un host en la nube como AWS, GCP, Azure, etc.), presenta pruebas que demuestren que se ha llevado a cabo una revisión de la configuración de la nube, como los resultados tras ejecutar NCC Scout Suite, AWS Config u otro similar. Si esto no es aplicable en el caso de tu organización, remite un documento que explique por qué no es posible revisar la configuración de la nube.
• Elimina u oculta la información confidencial en los documentos de pruebas antes de enviarlos, como los pasos detallados de reproducción de la vulnerabilidad.

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

• Presentar pruebas que demuestren que se ha realizado un test de penetración o se ha ejecutado una herramienta de análisis estático de software. Las pruebas deben incluir lo siguiente:

  • Una declaración que establezca el ámbito del test.
  • La fecha en la que se ha llevado a cabo el test (debe haberse realizado en los últimos 12 meses).
  • Un resumen o una lista de las vulnerabilidades detectadas durante el test. Debe incluir una categorización de la gravedad (p. ej., crítica, grave, media, baja, informativa). Se espera que no queden vulnerabilidades críticas o graves sin resolver.
• Elimina u oculta la información confidencial en los documentos de pruebas antes de enviarlos, como los pasos detallados de reproducción de la vulnerabilidad.

Ejemplos de pruebas

Test de penetración: una organización encarga un test de penetración del software que ejecuta del lado del servidor, que se integra con las API de Meta y trata los datos de la plataforma. La empresa que realiza el test la completa y elabora un informe resumido como que el figura a continuación: Observa las anotaciones en color rojo, que indican la fecha en que se realizó el test (debe haberse hecho en 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 u oculta la información confidencial del informe (especialmente los pasos detallados de reproducción de la vulnerabilidad) antes de enviarlo.

Análisis estático: si se adopta un enfoque diferente, por ejemplo, la incorporación de una herramienta de análisis estático de software, exporta los resultados a un documento que incluya la fecha en que se ha ejecutado la herramienta y una lista que indique el tipo de problema detectado y si es grave o crítico.

Revisión de la 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"}]}'

[]

Medidas de protección alternativas permitidas

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

• No hay exclusiones en cuanto al alcance del VDP que resulten pertinentes para el tratamiento que realizas de los datos de la plataforma.
• En los últimos 12 meses se ha llevado a cabo una investigación sobre vulnerabilidades y se han elaborado informes al respecto, lo que suele demostrarse mediante al menos un informe de vulnerabilidades al 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 plazo de tiempo razonable (normalmente en menos de 90 días después de la fecha en que se envía el informe).

En este caso, las pruebas deben incluir lo siguiente:

• Una declaración del alcance y de qué manera se relaciona con el software que se usa para tratar los datos de la plataforma.
• Un informe de las presentaciones de vulnerabilidades 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 ha resuelto) y la categoría o puntuación de gravedad.

Protección de la clave secreta de la aplicación y los identificadores de acceso de la API de Meta

Pregunta: ¿las claves secretas de la aplicación y los identificadores de acceso de la API de Meta se protegen de las dos formas indicadas a continuación?

1. En ningún caso se almacenan identificadores de acceso de la API de Meta en dispositivos cliente, de modo que los identificadores no sean accesibles fuera de la aplicación en cuestión ni por personas distintas del usuario actual.
2. Se usa un almacén de datos (p. ej., Vault by Hashicorp) con un servicio independiente de administración de claves (KMS) si estas se almacenan en un entorno de centro de datos, servidor o la nube.

Propósito

Las claves secretas de la aplicación y los identificadores de acceso son fundamentales para la seguridad cuando las API de Meta toman decisiones sobre qué acciones permiten. 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 hemos autorizado en la aplicación (p. ej., leer los datos de las API de Meta sobre los usuarios de la aplicación).

• Cuando usas la plataforma de Meta, tienes acceso a credenciales confidenciales. Concretamente, los siguientes tipos:

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

Resumen de requisitos

Identificadores de acceso

1. En dispositivos cliente. Los identificadores de acceso de Meta deben escribirse de forma que ningún otro usuario o proceso puedan leerlos.
2. Lado del servidor. Si procesas o almacenas identificadores de acceso de Meta en el lado del servidor, estos identificadores deben cumplir los siguientes requisitos:
1. Deben protegerse usando un almacén de datos (p. ej., Vault by Hashicorp) con un servicio independiente de administración de claves (KMS) y de modo que el acceso a la clave de descifrado se limite a la aplicación.
2. No deben escribirse en los archivos de registro.

Clave secreta de la aplicación. Debe darse uno de estos dos supuestos:

1. Nunca expones la clave secreta de la aplicación fuera del entorno seguro del servidor (p. ej., esta clave nunca es devuelta por una llamada de red a un navegador o una aplicación para móviles y la clave secreta de la aplicación no está insertada en el código que se ha distribuido a los clientes nativos o de escritorio).
2. Alternativamente, debes haber configurado la aplicación como nativa o de escritorio para que las API de Meta no confíen en las llamadas que reciban que incluyan la clave secreta de la aplicación.

Información sobre pruebas

Si se te solicita la presentación de pruebas que demuestren esta protección, es necesario que sigas las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

Incluye documentación sobre la política de protección de la clave secreta de la aplicación y los identificadores de acceso de la API de Meta. Si la aplicación procesa identificadores de acceso de Meta en el lado del servidor, incluye pruebas que demuestren las protecciones que adoptas (p. ej., uso de un almacén, demostración de que los valores se almacenan en un formato cifrado o configuración de la aplicación para requerir pruebas de la clave secreta de la aplicación).

Ejemplos de pruebas

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

Una organización ha configurado su aplicación de Meta para requerir una prueba de la clave secreta de la aplicación para llamadas a la API.

Medidas de protección alternativas permitidas

1. Si no proteges los identificadores de acceso almacenados del lado del servidor usando un almacén de datos o cifrado a nivel de aplicación, tienes las siguientes opciones:
1. Proteger la clave secreta de la aplicación usando un almacén o cifrado de la aplicación en que solo esta pueda acceder a la clave.
2. Configurar la aplicación para requerir una prueba de la clave secreta de la aplicación para todas las llamadas de la API a Meta.
2. En caso de que la estrategia n.º 1 anterior no sea factible (es decir, si no puede requerirse la prueba de la clave secreta de la aplicación 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 identificadores de acceso en comparación con el riesgo de uso indebido de los identificadores de acceso almacenados.

Plan de respuesta ante incidentes y pruebas de los sistemas y procesos de respuesta ante incidentes

Pregunta: ¿Pruebas los sistemas y procesos que usarías como respuesta ante un incidente de seguridad (por ejemplo, una filtración de datos o un ciberataque) al menos cada 12 meses?

Propósito

Tarde o temprano, todas las empresas se enfrentan a incidentes de seguridad. Por eso es crucial que las organizaciones planifiquen con antelación quién debe aplicar cada medida para contener 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 enfrentarse a este problema puede limitar la duración de la incidencia y, en última instancia, 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, exigimos contar, al menos, con un plan básico que contemple las acciones 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 requisitos

Qué necesita el desarrollador:

• Un plan de respuesta ante incidentes que reúna los criterios mínimos de Meta.
• Dicho documento debe incluir, como mínimo, (1) los roles y responsabilidades, (2) la detección, (3) las medidas que deben adoptarse de conformidad con las obligaciones legales (como notificar una filtración de datos a las autoridades de control correspondientes y a los interesados) para la recuperación y (4) un proceso de revisión posterior al incidente.
• Pruebas documentadas de que el plan se ha testado recientemente (en los últimos 12 meses) y que todas las personas designadas en él han participado.

Información sobre pruebas

Sigue las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

• Envía el plan de respuesta ante incidentes (uno o más documentos). Este debería cubrir los aspectos siguientes: roles y responsabilidades, detección, reacción y recuperación, y revisión posterior al incidente.

  • Si no cuentas con un plan de respuesta ante incidentes, dispones de numerosos recursos en internet que pueden resultarte útiles, como la plantilla del plan de respuesta ante incidentes y las referencias y documentación adicional de Counteractive.
• Envía pruebas de que has testeado el plan en los últimos 12 meses. Estas pueden ser de distintos tipos, pero deben incluir lo siguiente:

  • Una descripción de la situación (por ejemplo, un ejercicio práctico en respuesta a un ataque de ransomware).
  • La fecha de la prueba.
  • El rol de cada participante.
  • Si alguna persona que figure en la sección de roles y responsabilidades del plan no ha participado en la prueba, es necesario explicar el motivo.
• Oculta la información confidencial (por ejemplo, los datos de carácter personal de las personas, como su nombre y dirección de correo electrónico) de los documentos que aportes como prueba antes de enviarlos. Ejemplos de pruebas

Plan de respuesta ante incidentes

Un desarrollador ha creado un completo plan de respuesta ante incidentes basado en esta plantilla. En las imágenes solo puede verse el índice, pero hay un enlace a continuación que dirige a la plantilla completa.

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

Prueba de respuesta ante incidentes

Un desarrollador ha llevado a cabo una prueba de su plan de respuesta ante incidentes en el contexto de un ejercicio práctico y ha documentado el resultado en función de esta plantilla.

Requerimiento de la autenticación multifactor para accesos remotos

Pregunta: ¿requieres autenticación multifactor para acceder remotamente a las cuentas que pueden conectarse al entorno del servidor o la nube o acceder a los servicios que usas para implementar, mantener, supervisar y operar los sistemas en los que almacenas Datos de la plataforma de Meta?

Propósito

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 aplicación o sistema. Existen herramientas muy 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 aplicaciones 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 han filtrado 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 aplicación de autenticación) al iniciar sesión.

Resumen de 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 aplicación 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 permitida 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 aplicación o un sistema).
• Adicionalmente, en caso de procesar datos de la plataforma del lado del 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 lado del servidor.

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

• Se recomienda el uso de una aplicación 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.

Información sobre pruebas

Si se te solicita la presentación de pruebas que demuestren esta protección, es necesario que sigas las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

• Las pruebas de la implementación deben 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 aplicación.
  • 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 pruebas 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 pruebas

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 aplicaciones de la nube para las que es pertinente esta política. Con esta estrategia, las pruebas deben mostrar la totalidad de la sección Elementos seleccionados para aclarar qué aplicaciones 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 ha configurado la autenticación de GitHub para requerir la autenticación multifactor a todos los miembros de la organización.

Medidas de protección alternativas permitidas

• 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 una o más de estas estrategias 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 han sufrido vulneraciones.
  • Interrupción de la autenticación: uso de una herramienta que introduzca periodos 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 las cuentas de usuario

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

Propósito

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 se precise.

• Las cuentas son la unidad básica de administración a la hora de conceder acceso a los sistemas, los datos y las funciones administrativas.
• Los permisos que se les conceden les 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 marcha 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 (p. ej., de un antiguo empleado).
  • (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 comunique que no consigue iniciar sesión. Pero si la cuenta que sigue activa pertenece a un antiguo empleado, 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 preciso de forma sistemática.

Resumen de requisitos

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

  • Los que se usan para comunicarse con otras personas (p. ej., Slack o el correo electrónico de la empresa).
  • Los que se utilizan para presentar software (p. ej., un repositorio de códigos).
  • Los que se han diseñado 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 frecuencia (como mínimo, una vez cada 12 meses) y disponer de un proceso que permita revocarlos si (1) ya no se precisan y (2) ya no se utilizan.
• 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 estos distintos tipos de acceso.

Información sobre pruebas

Sigue las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

• Política o procedimiento: es necesario proporcionar políticas y procedimientos documentados referentes a las prácticas de administración de cuentas. Este documento debe contener procedimientos para crear cuentas y otorgar permisos, indicaciones sobre la complejidad mínima de las contraseñas, una política de bloqueo de cuentas, una política de autenticación multifactorial, procedimientos de restablecimiento de cuentas y el proceso de revocación del acceso después de un periodo de inactividad y cuando alguien abandone la organización (p. ej., cuando un empleado dimita o se le despida).
• Pruebas de la implementación: hay que aportar pruebas de al menos uno de los siguientes procesos o herramientas que se haya implementado 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ódigos, (3) herramientas de implementación en el servidor o la nube, (4) portal administrativo del servidor o la nube o (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 pruebas que demuestren que:

  • Se ha revocado el acceso a estas herramientas por parte de los antiguos empleados de la organización (p. ej., un informe de reconciliación que compare las cuentas de usuario con datos fiables de los miembros actuales de la organización).
  • Se revocan los accesos que llevan un tiempo sin usarse (p. ej., un informe que muestre que la última fecha de acceso de un titular representativo de una cuenta de usuario activa se sitúa en los 90 días anteriores si el periodo máximo de inactividad es de tres meses).

Ejemplos de pruebas

Política o procedimiento: un desarrollador ha creado una norma de administración del ciclo de vida de acceso que incluye procedimientos para el otorgamiento, la revisión y la revocación del acceso.

Ejemplo de implementación: se revoca el acceso de antiguos empleados

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

Un desarrollador presenta un informe con pruebas de que se ha revocado el acceso de antiguos empleados. En él, se muestra que en un informe de reconciliación reciente (es decir, realizado en los 12 meses anteriores) se ha constatado que no existen cuentas de usuario activas en Google Cloud Identity de empleados que ya no están en activo, conforme a un informe de Workday sobre los 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 para administrar cuentas de usuarios y otorgar acceso a herramientas y sistemas de información.

Un desarrollador presenta pruebas de que se ha revocado el acceso cuando ya no se utiliza (es decir, no se ha realizado ningún inicio de sesión en los seis meses anteriores) a través del directorio de usuarios ordenado por último inicio de sesión, 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ódigos)

Un desarrollador usa una herramienta de inicio de sesión único para la administración de identidades y otorgar acceso a herramientas y sistemas de información. El desarrollador ha configurado GitHub para que requiera autenticación mediante inicio de sesión único.

Mantener el software actualizado

Pregunta: ¿Dispones de un sistema para mantener actualizados los entornos y el código del sistema, incluidos servidores, máquinas virtuales, sistemas de distribución, bibliotecas, paquetes y software antivirus?

Propósito

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

• Los desarrolladores de aplicaciones utilizan distintos tipos de software de terceros para ejecutar las aplicaciones 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 aplicaciones, los desarrolladores empaquetan estos componentes añadiendo su propio código personalizado.
  • Imágenes de máquina virtual, contenedores de aplicaciones y sistemas operativos: las aplicaciones 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 aplicaciones que empleados y colaboradores utilizan: por ejemplo, el software que se ejecuta en portátiles y dispositivos móviles y que un desarrollador usa para crear y operar su sistema.
• En estos componentes se detectan vulnerabilidades de seguridad constantemente y, para corregirlas, se lanzan parches.
• Las vulnerabilidades que se corrigen con estos parches se registran en bases de datos públicas y se clasifican según su gravedad (baja, media, alta o crítica).
• Por lo tanto, los desarrolladores deben administrar los parches de un modo sistemático en la plataforma de Meta y, para lograrlo, llevan a cabo las acciones siguientes:

  • Identificación de parches valiosos para sus aplicaciones o sistemas.
  • Priorización de la urgencia en función de la exposición.
  • Aplicación de parches en sus empresas de forma continua.

Resumen de requisitos

En el caso de los componentes de software siguientes (según corresponda), debes contar con un medio definido y reproducible que permita identificar los parches disponibles para corregir las vulnerabilidades de seguridad, priorizar según el riesgo y aplicar dichos parches de forma continua:

1. Bibliotecas, SDK, paquetes, contenedores de aplicaciones 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 aplicaciones para móviles).
3. Sistemas operativos y aplicaciones que usan los miembros para crear y operar las aplicaciones o los sistemas (p. ej., para operar los sistemas operativos y los navegadores que se ejecutan en los 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 varias estrategias para mantener distintos tipos de software actualizados (p. ej., bibliotecas que vienen empaquetadas en la aplicación frente a actualizaciones del sistema operativo de los portátiles de los empleados).

El diagrama siguiente muestra los casos en los que puede ser necesario aplicar parches en distintos tipos de arquitecturas.

Información sobre pruebas

Si se te solicita la presentación de pruebas que demuestren esta protección, es necesario que sigas las instrucciones indicadas en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

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

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

• Inventario: una captura de pantalla o un documento referente a una herramienta o proceso que, en última instancia y dentro del ámbito de aplicación, representa una lista de bibliotecas, paquetes, SDK, contenedores, servidores de aplicaciones y sistemas operativos que requieren un parche. Es necesario que existan inventarios de una muestra representativa de los tipos de software (p. ej., aplicaciones en la nube, aplicaciones cliente, 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 de los cuales se asigne una prioridad a los parches pertinentes.

  • Aplicación de parches
  • Una captura de pantalla o un documento que demuestre que, después de la identificación y la priorización de los parches pertinentes, estos se implementan en los destinos correspondientes.
• Deben incluirse políticas relativas al uso de software de fin de vida útil y el tiempo de resolución.

Ejemplos de pruebas

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 encontrar vulnerabilidades en las dependencias usadas en una aplicación de nodo. La siguiente imagen de ejemplo muestra diversas vulnerabilidades muy graves que requieren un parche.

Trivy

Un desarrollador usa Trivy para encontrar vulnerabilidades en una imagen de máquina. La siguiente imagen de ejemplo muestra bibliotecas con vulnerabilidades muy graves 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 sobremesa 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.

Sistema para registrar el acceso a datos de la plataforma y hacer un seguimiento de dónde se envían y almacenan

Propósito

Detectar accesos no autorizados a datos de la plataforma sin disponer de archivos de registro fiables puede ser muy difícil o incluso imposible para los desarrolladores.

• Los registros de auditoría ayudan a las organizaciones a registrar los eventos que se producen, por ejemplo, cuando un usuario concreto hace una consulta en tablas de bases de datos que contienen datos de la plataforma.
• Este tipo de registros hacen posible procesos como la activación de alertas automatizadas basadas en actividad sospechosa o los análisis forenses tras la detección de un incidente de seguridad.

Resumen de requisitos

Si tratas datos de la plataforma del lado del servidor, esto es lo que necesitas en dicho entorno:

• Debes mantener registros de auditoría de eventos clave (como accesos a los datos de la plataforma, uso de cuentas con permisos de alto nivel o cambios en la configuración de los registros de auditoría).
• Es necesario unificar los registros de auditoría en un archivo central y protegerlo para que no pueda modificarse ni eliminarse.

Información sobre pruebas

Si se te pide que aportes pruebas, deberás poder demostrar lo siguiente:

• Tienes conocimiento de cómo se almacenan los datos de la plataforma actualmente, cómo se accede a ellos y cómo se transfieren (por ejemplo, a través de un esquema del proceso de datos que muestre una panorámica general del sistema, que designe qué servicios conservan datos de la plataforma y que muestre puntos de entrada y salida, incluidas las transferencias a servicios de proveedores de terceros).
• Has implementado registros de auditoría que impiden su manipulación.
• Los eventos relacionados con el acceso a los datos de la plataforma quedan recogidos en los registros.

Supervisión de transferencias de datos de la plataforma y puntos clave en los que estos datos pueden salir del sistema (como terceros o extremos públicos)

Propósito

Saber cómo se espera que se realice el tratamiento de los datos de la plataforma y supervisar dicho proceso es una forma importante de que las organizaciones se aseguren de que ese tipo de datos se utilicen únicamente para los fines previstos.

• Los desarrolladores deben saber en todo momento cómo se conservan los datos y de qué manera se transmiten a través de redes y se hacen copias de seguridad (que pueden repetirse en otros lugares).
• Por ejemplo, con un proceso de supervisión pueden detectarse situaciones en las que se transmiten datos de la plataforma de un modo inesperado o a través de una red sin un cifrado adecuado de los datos en tránsito para que puedas tomar medidas al respecto.

Resumen de requisitos

Si tratas datos de la plataforma del lado del servidor, esto es lo que debes hacer en dicho entorno:

• Mantener un esquema del proceso de datos que muestre dónde se conservan, tratan y transmiten los datos de la plataforma en las redes.
• Configurar un sistema de supervisión (por ejemplo, registros de auditoría con un producto de supervisión automatizado) de las transferencias de datos de la plataforma fuera del sistema.
• Si es posible, configurar el sistema de supervisión para que envíe avisos y que estos puedan revisarse de inmediato si se producen transferencias de datos de la plataforma inesperados. (Consulta también el requisito Cómo tener un sistema automatizado de supervisión de registros y otros eventos de seguridad, y cómo generar alertas para eventos anormales relacionados con la seguridad).

Información sobre pruebas

Si se te pide que presentes pruebas que demuestren esta protección, sigue las instrucciones que se indican en Preparación de pruebas para preparar la política o el procedimiento y las pruebas para demostrar la implementación.

Debes enviarnos pruebas que demuestren lo siguiente:

• Tienes conocimiento de cómo se almacenan los datos de la plataforma actualmente, cómo se accede a ellos y cómo se transfieren (por ejemplo, a través de un esquema del proceso de datos que muestre una panorámica general del sistema, que designe qué servicios conservan datos de la plataforma y que muestre puntos de entrada y salida, incluidas las transferencias a servicios de proveedores de terceros).
• Has implementado registros de auditoría que impiden su manipulación.
• Los eventos relacionados con las transferencias de datos de la plataforma quedan recogidos en los registros. Los eventos deben incluir la fecha y la hora, la identidad del usuario o la aplicación que realiza la acción y el origen o el destino.

Cómo tener un sistema automatizado de supervisión de registros y otros eventos de seguridad, y cómo generar alertas para eventos anormales relacionados con la seguridad

Propósito

Depender de las personas a la hora de revisar e identificar comportamientos inesperados en un sistema moderno con acceso a internet es poco realista. Para ello existen herramientas que analizan archivos de registro y otras señales y que emiten avisos que un equipo humano se encarga de investigar.

Resumen de requisitos

Si tratas datos de la plataforma del lado del servidor, esto es lo que necesitas en el entorno del servidor:

• Una herramienta que sea capaz de analizar archivos de registro y otros eventos y de establecer reglas que emitan avisos si estas se activan, así como un mecanismo para asignar dichos avisos a las personas adecuadas (como un investigador de seguridad disponible).
• Introducir señales pertinentes en la herramienta (por ejemplo, registros de accesos web, intentos de autenticación, acciones que usuarios con privilegios de alto nivel llevan a cabo).
• Con el tiempo, ajustar y perfeccionar las reglas para equilibrar las señales y los eventos irrelevantes (como evitar que se generen demasiadas falsas alarmas, pero sin llegar a ignorar los eventos que deben investigarse).

Información sobre pruebas

A tal fin, los desarrolladores suelen adoptar una herramienta de gestión de eventos e información de seguridad como las siguientes:

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

Debes aportar pruebas que justifiquen que los orígenes de señales pertinentes se conectan con la herramienta que hayas elegido, que has configurado avisos y que estos se harán llegar al personal encargado de investigarlos, y que has diseñado un proceso para optimizar dichos avisos regularmente (por ejemplo, mediante ciclos mensuales de revisión y actualización).

Glosario

A

Tercero (“3rd party”): en la terminología de gestión de riesgos, “tercero” hace referencia a los desarrolladores de la plataforma de Meta (Meta constituye la entidad primaria y las personas que usan los productos de Meta, la secundaria).

Entidad cuaternaria (“4th party”): en la terminología de gestión de riesgos, “entidad cuaternaria” hace referencia a las empresas de las que los desarrolladores dependen para recibir los servicios que les permiten llevar adelante sus negocios (la entidad primaria es Meta; la secundaria, las personas que usan los productos de Meta, y la terciaria, los desarrolladores de la plataforma de Meta) Identificador de acceso (“Access token”): una credencial, como una contraseña, que 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 computación en la nube de Amazon.

ASID (“Identificador de usuario específico de la aplicación”, por sus siglas en inglés): identificador único que genera Meta cuando una persona elige usar una aplicación. Los ASID ayudan a mejorar la privacidad de los usuarios al dificultar que los conjuntos de datos correlacionen los usuarios entre las aplicaciones, ya que un único usuario que use dos aplicaciones tendrá diferentes ASID en cada una.

Clave secreta de la aplicación (“App secret”): una clave secreta que Meta pone a disposición de los desarrolladores a través del panel de aplicaciones. Contar con la clave secreta de la aplicación autoriza al software a realizar algunas acciones a través de la API Graph; por lo tanto, los desarrolladores deben asegurarse de que las personas no autorizadas no puedan obtener acceso a la clave secreta de la aplicación.

Aplicación comprometida (“App compromise”): si un agente malintencionado obtiene acceso no autorizado a la red interna de una organización debido a un error de configuración o una vulnerabilidad en su aplicación (p. ej., una vulnerabilidad del software en una aplicación web), se dice que la aplicación está comprometida. Un mecanismo de defensa contra una aplicación comprometida es ejecutar un test de penetración en ella. Consulta también “Red comprometida”.

Contenedor de la aplicación (“Application container”): un contenedor empaqueta el código del software y las dependencias relacionadas para que la aplicación 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 aplicación. El motor o software de tiempo de ejecución del contenedor de la aplicación aloja (ejecuta) la imagen del contenedor.

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

API (“Interfaz de programación de aplicaciones”, por sus siglas en inglés): permite que dos ordenadores se comuniquen a través de una red, por ejemplo, una aplicación para móviles que carga el clima del día para una determinada ubicación desde un sistema de previsión meteorológica centralizado.

Prueba de la clave secreta de la aplicación (“Appsecret proof”): una medida 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 aplicación) que demuestra que posee dicha clave secreta. La prueba de la clave secreta de la aplicación es el producto de una función hash (también llamada función unidireccional) que se basa en la clave secreta de la aplicación y el identificador de acceso. Configurar una aplicación para exigir pruebas de la clave secreta de la aplicación durante las invocaciones de la API Graph reduce el daño potencial de una vulneración de identificadores de acceso del usuario, ya que dichos identificadores no se pueden usar sin el parámetro adicional de la prueba de la clave secreta de la aplicación.

B

BaaS (“Backend como servicio”, por sus siglas en inglés): modelo de computación en la nube que ofrece a los desarrolladores de aplicaciones un conjunto de funciones del lado del servidor para que puedan centrarse en el desarrollo del frontend (es decir, la parte de la aplicación con la que interactúan los usuarios). Las soluciones BaaS son similares a las PaaS y, además, incorporan servicios como la autenticación de usuarios y notificaciones push para dispositivos móviles. Algunos productos de BaaS populares son AWS Amplify, Azure Mobile Apps, Firebase y MongoDB Switch.

C

Texto cifrado (“Cipher text”): sinónimo de datos cifrados. Texto cifrado es el nombre con el que se conoce a los datos que se transforman a un formato ilegible a través de un algoritmo de cifrado. El contrario de “texto cifrado” es “texto sencillo”.

Lado del cliente (“Client side”): las personas normalmente interactúan con servicios accesibles desde internet al abrir un sitio web en un navegador o al ejecutar una aplicación para móviles en un teléfono o una tableta. Se hace referencia al navegador o la aplicación para móviles como “lado del cliente” o “cliente local”. Los clientes formulan solicitudes desde ordenadores remotos (servidores) a través de internet.

Computación en la nube (“Cloud computing”): hace referencia 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 bastidores de servidores y cables de red). En su lugar, la organización puede adquirir estos activos cuando lo necesite y pagar por los servicios que consumen.

Configuración de la nube (“Cloud configuration”): 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 que tienen autorización para hacer cambios en la configuración de la nube.

Controles compensatorios (“Compensating controls”): control de seguridad que difiere de un conjunto de requisitos estándar, pero cuyo objetivo es ofrecer una protección equivalente en caso de riesgo.

D

Base de datos (“Database”): 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 del lado del servidor.

Descifrado (“Decryption”): proceso mediante el cual los datos cifrados se restituyen a su formato original. Dicho de otro modo, el descifrado transforma el texto cifrado en texto sencillo.

E

Cifrado (“Encryption”): proceso mediante el cual los datos adoptan un formato que no puede ser utilizado por quien no puede descifrarlo. Dicho de otro modo, el cifrado transforma el texto sencillo en texto cifrado.

Cifrado en reposo (“Encryption at rest”): datos que se han protegido mediante cifrado cuando se escriben en un almacenamiento persistente (como una unidad de disco). El cifrado en reposo ofrece un nivel adicional de protección contra los accesos no autorizados, ya que un agente que pueda leer los archivos sin procesar en un dispositivo de almacenamiento verá el texto cifrado, pero no podrá descifrarlo mientras no consiga acceso a la clave de descifrado.

Cifrado en tránsito (“Encryption in transit”): datos protegidos mediante cifrado que se transmiten por una red. El cifrado en tránsito ofrece protección contra la interceptación en la ruta de red, ya que un agente que pueda leer los paquetes de red verá el texto cifrado, pero no podrá descifrarlo mientras no consiga acceso a la clave de descifrado.

Fin de la vida útil del software (“End of Life [EOL] software”): momento en que una organización deja de ofrecer soporte (p. ej., crear parches para resolver vulnerabilidades de seguridad) para un producto de software. Dado que ya no se llevan a cabo tareas de mantenimiento del software, es muy arriesgado ejecutarlo.

G

Plataforma Google Cloud (“Google Cloud Platform, [GCP]”): conjunto de servicios de computación en la nube de la API Graph de Google. Forma principal en que las aplicaciones leen y escriben en el grafo social de Meta. Todos los SDK y productos de Meta interactúan con la API Graph de alguna manera.

H

Función hash (“Hashing function”): 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 las contraseñas. En lugar de almacenar la contraseña de un usuario como texto sencillo que podría robarse, las contraseñas se transforman primero con una función hash y luego se almacenan. Posteriormente, para confirmar que el usuario ha introducido 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 alojado (“Hosted environment”): hace referencia 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 housing con otros clientes. Esta opción es relativamente poco común actualmente debido a la popularidad que está cobrando la computación en la nube.

I

IdP (“Proveedor de identidad”, por sus siglas en inglés): servicio en la nube que se usa para centralizar la administración de identidades digitales y autenticar usuarios. Las organizaciones que utilizan este servicio suelen configurar aplicaciones en la nube y recurren a él para la autenticación de usuarios. Posteriormente, la organización puede administrar usuarios concediendo acceso a determinadas aplicaciones, creando e inhabilitando cuentas de usuario de manera centralizada dentro del IdP, en lugar de tener que hacerlo reiteradamente en cada aplicación en la nube.

IAM (“Administración de identidades y de acceso”, por sus siglas en inglés): hace referencia a la categoría de herramientas y procesos que se utilizan para administrar cuentas y conceder acceso a los sistemas.

IaaS (“Infraestructura como servicio”, por sus siglas en inglés): modelo de computación en la nube que 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 otorga a las organizaciones un mayor control sobre la configuración de sus activos en la nube, pero a costa de una mayor complejidad a la hora de administrar dichos activos. Algunos productos de IaaS populares son AWS EC2, Microsoft Azure IaaS y Google Compute Engine.

L

Biblioteca (“Library”): componente fundamental de software preexistente. Suele ser de una empresa o un desarrollador externo y se utiliza para gestionar determinadas tareas dentro de la aplicación o el sistema de otro desarrollador. Las bibliotecas simplifican el desarrollo de las aplicaciones, ya que el 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 aplicación deben saber qué bibliotecas están en uso y mantenerlas siempre actualizadas.

M

Aplicación de un cliente de telefonía móvil o para móviles (“Mobile client or mobile app”): aplicación que alguien instala en un teléfono o tableta desde una tienda de aplicaciones para móviles (p. ej., App Store de iOS o Google Play Store). Es habitual que los clientes de telefonía móvil 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 la API Graph a través del SDK de Facebook para Android).

MFA (“Autenticación multifactor”, por sus siglas en inglés): método de autenticación en el que se requiere de más de un factor para obtener acceso a una aplicación o un sistema. En comparación con la autenticación de un solo factor (que solo se basa en una contraseña para autenticar a un usuario), la MFA suele solicitar una contraseña y uno o más de estos elementos: un código enviado por correo electrónico o SMS, un código de una aplicación de autenticación, la verificación de datos biométricos o una llave de seguridad. La MFA protege frente a las apropiaciones de cuentas al hacer más difícil que personas no autorizadas entren a la fuerza en una cuenta, por ejemplo, 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 (“Native software”): las aplicaciones que se descargan e instalan en ordenadores portátiles o dispositivos móviles se conocen como software nativo (p. ej., la aplicación de Facebook para iOS). En cambio, una aplicación que se ejecuta dentro de un navegador se conoce como aplicación web (p. ej., abrir Facebook con el navegador Chrome).

Red comprometida (“Network compromise”): el hecho de que un agente malicioso consiga acceso no autorizado a la red interna de una organización debido a un error de configuración o una vulnerabilidad de la red. Un mecanismo de defensa contra una red comprometida es ejecutar un análisis para detectar errores de configuración y vulnerabilidades de la red con acceso a internet. Consulta también “Aplicación comprometida”.

Escaneo de red (“Network scan”): proceso de gestión de riesgos que utiliza software a fin de (1) identificar servidores activos en una red que responderán a comunicaciones remotas y, posteriormente, (2) comprobar si alguno de esos servidores está ejecutando versiones antiguas de software que se sabe que son susceptibles a ataques 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): herramienta que utilizan los desarrolladores de JavaScript para acelerar el proceso desarrollo al permitir que se incluyan paquetes ya creados en su aplicación o sistema. NPM incluye funciones para auditar el conjunto de paquetes que la aplicación utiliza e identificar paquetes que tienen vulnerabilidades de seguridad conocidas.

O

Contenedores de almacenamiento de objetos (“Object storage buckets”): tipo de almacenamiento en la nube que facilita que las organizaciones guarden archivos en almacenamiento persistente, incluidos archivos de gran tamaño, sin tener que preocuparse de ampliar la capacidad de activos físicos (como matrices de almacenamiento) ni de realizar copias de seguridad de los archivos para evitar perderlos en situaciones fortuitas, como incendios o inundaciones.

Sistema operativo (“Operating system”): software que se ejecuta en un ordenador o dispositivo móvil y que permite que las aplicaciones se ejecuten y utilicen el procesador, la memoria, el almacenamiento y los recursos de red de ese ordenador. Por ejemplo, Windows de Microsoft, macOS de Apple o iOS y Linux.

Miembro de la organización (“Organization member”): persona con una función determinada y responsabilidades dentro de una organización, como un empleado, un contratista, un trabajador eventual, un becario o un voluntario.

Dispositivo de la organización (“Organizational device”): ordenador o dispositivo móvil utilizado por el miembro de una organización a la hora de desempeñar una tarea para ella.

P

Condición de la plataforma 6.a.i (“Platform Term 6.a.i”): hace referencia a la sección (6), encabezado (a), párrafo (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 añaden funcionalidades nuevas. Todos los tipos de software reciben parches, incluidos los sistemas operativos, los contenedores, las bibliotecas y los SDK.

Test de penetración (“Penetration test”): ataque simulado contra una aplicación o un sistema en el que se intenta detectar vulnerabilidades en el código o la configuración que un agente no autorizado podría tratar de aprovechar. Quienes llevan a cabo este tipo de tests usan herramientas similares a los cibercriminales para realizar tareas de reconocimiento, detectar posibles puntos débiles y probar las vulnerabilidades que se podrían aprovecharse para conseguir acceso no autorizado. Al finalizar este test se creará un informe con los resultados y la gravedad de cada problema. La organización que mantiene el software tiene la responsabilidad de diseñar las correcciones pertinentes para resolver las vulnerabilidades.

Texto sencillo (“Plain text”): sinónimo de “datos sin cifrar”. Es el nombre que se le da a los datos que no están protegidos con cifrado. PaaS (“Plataforma como servicio”, por sus siglas en inglés): modelo de computación en la nube en el que el cliente implementa una aplicación en una plataforma administrada por el proveedor de servicios en la nube. En comparación con IaaS, PaaS es más fácil de administrar para los clientes, ya que el anfitrión 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 aplicación donde se ejecuta la aplicación del cliente. Algunos productos de PaaS populares son AWS Elastic Beanstalk, Google App Engine y Force.com.

Puerto: cuando un cliente establece una conexión con un servidor a través de 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 aplicación 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 (“REST API”): estilo ampliamente adoptado de desarrollo de servicios accesibles por web en el que el cliente y el servidor se comunican utilizando el protocolo HTTP. Un desarrollador de la plataforma de Meta puede alojar una API REST en un subdominio como api.ejemplo.com, desde el que su aplicación para móviles envía y recibe datos de la plataforma.

S

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

Secure Sockets Layer (SSL) (“Capa de puertos seguros”): 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”, por sus siglas en inglés).

Servidor: ordenador que proporciona servicios en modo remoto a través de una red. Los navegadores y aplicaciones para móviles se conectan a los servidores a través de internet.

Computación sin servidor (“Serverless computing”): modelo de computación en la nube en el que el anfitrión 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 del servidor (“Server side”): a los datos o la computación en el otro lado de una conexión de red (es decir, en un servidor) se los considera “del lado del servidor”. En cambio, a los datos o la computación en un dispositivo local, como un ordenador portátil o un dispositivo móvil, se los considera “del lado del cliente”.

SSO (“Inicio de sesión único”, por sus siglas en inglés): procedimiento en el que las aplicaciones 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 aplicación de la organización, los usuarios se benefician de tener un único conjunto de credenciales, en lugar de tener varias (p. ej., un nombre de usuario y una contraseña) para cada aplicación.

SDK (“Kit de desarrollo de software”, por sus siglas en inglés): 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. Tal como ocurre con las bibliotecas, los desarrolladores que usan SDK en sus aplicaciones deben mantenerlos siempre actualizados.

SaaS (“Software como servicio”, por sus siglas en inglés): permite que los clientes usen aplicaciones basadas en la nube a través de internet. A diferencia de PaaS o IaaS, un cliente de una aplicación SaaS no implementa código personalizado ni tiene la responsabilidad de configurarla, actualizarla o crear parches para ella, ya que de todo esto se encarga el proveedor de dicha aplicación. Algunos productos de SaaS populares son Dopbox, MailChip, Salesforce y Slack.

Análisis estático (“Static analysis”): consulta “SAST, Tests de seguridad de aplicaciones estáticas”.

SAST (“Tests de seguridad de aplicaciones estáticas”, por sus siglas en inglés): enfoque para detectar vulnerabilidades en software mediante la ejecución de una herramienta especializada en el código fuente. Una herramienta de SAST identificará vulnerabilidades potenciales, como las que se mencionan en el proyecto OWASP Top 10. Posteriormente, el desarrollador es el encargado de revisar los resultados, distinguir entre verdaderos positivos y falsos positivos, y corregir las vulnerabilidades en el software. Una herramienta de SAST puede ser útil porque permite a los desarrolladores detectar vulnerabilidades antes de llegar a la fase de producción. Sin embargo, a diferencia de un test de penetración, una herramienta de SAST no podrá detectar vulnerabilidades en la configuración de producción de la aplicación.

T

Cifrado de datos transparente (“Transparent data encryption”): 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 este método, el software de la base de datos administra las claves de cifrado y gestiona de modo transparente las operaciones de cifrado (al escribirse) y las operaciones de descifrado (al leerse).

TLS (“Seguridad de la capa de transporte”, por sus siglas en inglés): modelo de cifrado en tránsito que utiliza el cifrado para proteger los datos transmitidos por redes frente a interceptaciones en la ruta de red. TLS es la versión segura moderna de la tecnología obsoleta anterior llamada SSL.

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

V

VM (“Máquina virtual”, por sus siglas en inglés): una máquina virtual es muy similar a un contenedor “hipervisor”, mientras que un contenedor de aplicaciones se ejecuta en un motor de contenedor. La diferencia principal es que una imagen de la máquina virtual contiene un sistema operativo, mientras que un contenedor de aplicaciones no. Tanto las máquinas virtuales como los contenedores de aplicaciones contienen aplicaciones y dependencias como bibliotecas.

VPC (“Nube privada virtual”, por sus siglas en inglés): 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 los tiempos previos a la nube.

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

VDP (“Programa de recompensas por detección de vulnerabilidades”, por sus siglas en inglés): enfoque en el que las organizaciones encargan informes de vulnerabilidades de seguridad a investigadores (a veces llamados “hackers éticos”) a fin de detectar y corregir riesgos de seguridad antes de que agentes maliciosos saquen provecho de ellos. Para que un VDP sea eficaz, necesita una serie de investigadores que busquen vulnerabilidades de manera activa, analistas de la organización que revisen la divulgación de datos entrantes y evalúen su prioridad, e ingenieros expertos en ciberseguridad que puedan crear e implementar las correcciones pertinentes.

Escaneo de vulnerabilidad (“Vulnerability scan”): enfoque que utiliza software para buscar vulnerabilidades en servidores, redes y aplicaciones. En comparación con los test 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, los tests de penetración suelen detectar las vulnerabilidades que no encuentra un escaneo de vulnerabilidad debido a que los expertos evaluadores de penetración cuentan con aptitudes analíticas e instintos difíciles de encontrar en los métodos estrictamente automáticos. Consulta también “Escaneo de red”.

W

Aplicación web (“Webapp”): programa que se ejecuta en los navegadores y está compuesto por recursos como documentos HTML, código JavaScript, vídeos y otros archivos multimedia y CSS para la aplicación de estilos. A diferencia de las aplicaciones para móviles, que se instalan en un teléfono móvil desde una tienda de aplicaciones, una persona solo tiene que seleccionar una aplicación web en un servidor remoto desde su navegador (p. ej., www.facebook.com) sin tener que seguir los pasos de instalación.