Asegúrese de que los archivos binarios estén ofuscados si contienen información confidencial
Título
Detalles
Componente
Límite de confianza de la máquina
Fase de SDL
Implementación
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Asegúrese de que los archivos binarios estén ofuscados si contienen información confidencial como secretos comerciales o lógica de negocios confidencial que no se deba revelar. Esto sirve para detener la ingeniería inversa de ensamblados. Para este fin se pueden usar herramientas como CryptoObfuscator.
Considere la posibilidad de usar el sistema de cifrado de archivos (EFS) para proteger información confidencial específica del usuario
Título
Detalles
Componente
Límite de confianza de la máquina
Fase de SDL
Build
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Considere la posibilidad de usar el sistema de cifrado de archivos (EFS) para proteger información confidencial específica del usuario frente a adversarios con acceso físico al equipo.
Asegúrese de que se cifre la información confidencial almacenada por la aplicación en el sistema de archivos
Título
Detalles
Componente
Límite de confianza de la máquina
Fase de SDL
Implementación
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Asegúrese de que la información confidencial almacenada por la aplicación en el sistema de archivos esté cifrada (por ejemplo, mediante DPAPI) si no se puede aplicar EFS.
Asegúrese de que no se almacene contenido confidencial en la memoria caché del explorador
Título
Detalles
Componente
Aplicación web
Fase de SDL
Build
Tecnologías aplicables
Genérico, formularios Web Forms, MVC5, MVC6
Atributos
N/D
Referencias
N/D
Pasos
Los exploradores pueden almacenar información para la memoria caché y el historial. Estos archivos almacenados en caché se guardan en una carpeta, como la carpeta Archivos temporales de Internet en el caso de Internet Explorer. Si se vuelve a hacer referencia a estas páginas, el explorador las muestra desde su memoria caché. Si se muestra información confidencial al usuario (por ejemplo, su dirección, datos de la tarjeta de crédito, número del seguro social o nombre de usuario), podría quedar almacenada en la memoria caché del explorador y, por tanto, ser recuperable mediante un examen de la memoria caché del explorador o simplemente al presionar el botón "Atrás" del explorador. Establezca el valor del encabezado de respuesta cache-control en "no-store" para todas las páginas.
Esto se puede implementar por medio de un filtro. Puede usar el siguiente ejemplo:
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Cifre las secciones de los archivos de configuración de la aplicación web que contengan información confidencial
Los archivos de configuración tales como web.config y appsettings.json se suelen usar para almacenar información confidencial, como nombres de usuario, contraseñas, cadenas de conexión a la base de datos y claves de cifrado. Si no protege esta información, la aplicación es vulnerable a atacantes o usuarios malintencionados que obtienen información confidencial, como nombres de usuario y contraseñas de cuentas, nombres de bases de datos y nombres de servidores. Según el tipo de implementación (Azure o local), cifre las secciones confidenciales de los archivos de configuración mediante DPAPI o servicios como Azure Key Vault.
Deshabilite explícitamente el atributo HTML autocomplete en formularios y entradas confidenciales
El atributo autocomplete especifica si un formulario debe tener Autocompletar activado o desactivado. Cuando está activado, el explorador completa automáticamente los valores en función de los que el usuario haya escrito antes. Por ejemplo, cuando se escribe un nombre y una contraseña nuevos en un formulario y se envía este, el explorador le pregunta si se debe guardar la contraseña. A partir de entonces, cuando se muestre el formulario, el nombre y la contraseña se rellenan automáticamente o se completan cuando se escribe el nombre. Un atacante con acceso local podría obtener la contraseña no cifrada de la memoria caché del explorador. De forma predeterminada, la función Autocompletar está habilitada y se debe deshabilitar explícitamente.
Asegúrese de que la información confidencial que se muestra en la pantalla del usuario esté enmascarada
Título
Detalles
Componente
Aplicación web
Fase de SDL
Build
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
La información confidencial, como contraseñas, números de tarjeta de crédito, números del seguro social, etc., debe estar enmascarada cuando se muestre en pantalla. El objetivo es impedir que el personal no autorizado acceda a los datos (por ejemplo, contraseñas vistas por encima del hombro, personal de soporte que ve los números del seguro social de los usuarios). Asegúrese de que estos elementos de datos no sean visibles sin cifrar y que estén enmascarados correctamente. Esto se debe tener en cuenta al aceptarlos como entrada (por ejemplo, tipo de entrada="contraseña") y mostrarse de nuevo en la pantalla (por ejemplo, mostrar solo los últimos 4 dígitos del número de tarjeta de crédito).
Implemente el enmascaramiento dinámico de datos para limitar la exposición de información confidencial a usuarios sin privilegios
La finalidad del enmascaramiento dinámico de datos consiste en limitar la exposición de la información confidencial, con lo que se impide que los usuarios vean datos a los que no deberían poder acceder. El enmascaramiento dinámico de datos no pretende evitar que los usuarios de la base de datos se conecten directamente a ella y ejecuten consultas exhaustivas que expongan información confidencial. El enmascaramiento dinámico de datos complementa a otras características de seguridad de SQL Server (auditoría, cifrado, seguridad de nivel de fila…) y se recomienda encarecidamente que se utilice junto con ellas para proteger mejor la información confidencial en la base de datos. Tenga en cuenta que esta característica solo es compatible con SQL Server a partir de 2016 y Azure SQL Database.
Asegúrese de que las contraseñas se almacenen en formato de hash con sal
Las contraseñas no se deberían almacenar en bases de datos de almacén de usuarios personalizadas. En su lugar, los hash de contraseña se deben almacenar con valores sal. Asegúrese de que el valor de sal del usuario es siempre único y de que aplica b-crypt, s-crypt o PBKDF2 antes de almacenar la contraseña, con un número de iteraciones de factor de trabajo mínimo de 150 000 bucles para eliminar la posibilidad de ataques de fuerza bruta.
Asegúrese de que la información confidencial en las columnas de la base de datos esté cifrada
La información confidencial, como los números de tarjeta de crédito, debe estar cifrada en la base de datos. Los datos se pueden cifrar con cifrado de nivel de columna o con una función de aplicación mediante las funciones de cifrado.
Asegúrese de que el cifrado de base de datos (TDE) esté habilitado
La característica Cifrado de datos transparente (TDE) de SQL Server ayuda a cifrar la información confidencial en una base de datos y a proteger las claves que se usan para cifrar los datos con un certificado. Esto impide que alguien que carezca de las claves use los datos. TDE protege los datos "en reposo", es decir, los archivos de datos y de registro. Ofrece la posibilidad de cumplir muchas leyes, normativas y directrices establecidas en diversos sectores.
Asegúrese de que las copias de seguridad de la base de datos estén cifradas
SQL Server tiene la capacidad de cifrar los datos mientras se crea una copia de seguridad. Al especificar el algoritmo de cifrado y el sistema de cifrado (un certificado o una clave asimétrica) cuando se crea una copia de seguridad, se puede crear un archivo de copia de seguridad cifrado.
Asegúrese de que la información confidencial relevante para la API web no se guarde en el almacenamiento del explorador
Título
Detalles
Componente
API Web
Fase de SDL
Build
Tecnologías aplicables
MVC 5, MVC 6
Atributos
Proveedor de identidades - ADFS, Proveedor de identidades - Id. de Microsoft Entra
Referencias
N/D
Pasos
En algunas implementaciones, se guardan artefactos confidenciales pertinentes para la autenticación de la API web en el almacenamiento local del explorador. Por ejemplo, artefactos de autenticación de Microsoft Entra como adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key, etc.
Todos estos artefactos están disponibles aun después de que se cierren la sesión o el explorador. Si un adversario obtiene acceso a estos artefactos, puede volver a usarlos para acceder a los recursos protegidos (las API). Asegúrese de que todos los artefactos confidenciales relacionados con la API web no se guarden en el almacenamiento del explorador. En aquellos casos en que el almacenamiento del lado cliente sea inevitable (por ejemplo, las aplicaciones con una sola página (SPA) que aprovechan los flujos de OAuth/OpenIdConnect implícito necesitan almacenar localmente los tokens de acceso), use opciones de almacenamiento sin persistencia. Por ejemplo, es preferible SessionStorage a LocalStorage.
Ejemplo
El siguiente fragmento de código JavaScript es de una biblioteca de autenticación personalizada que guarda artefactos de autenticación en almacenamiento local. Se deben evitar estas implementaciones.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for Internet Explorer, as sessionStorage does not work for localhost.
};
Cifre la información confidencial almacenada en Azure Cosmos DB
Título
Detalles
Componente
Azure DocumentDB
Fase de SDL
Build
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Cifre la información confidencial en el nivel de aplicación antes de almacenarla en DocumentDB o almacene cualquier información confidencial en otras soluciones de almacenamiento como Azure Storage o SQL de Azure.
Use Azure Disk Encryption para cifrar discos usados por máquinas virtuales
Título
Detalles
Componente
Límites de confianza de máquinas virtuales de IaaS de Azure
El Azure Disk Encryption es una nueva característica que está actualmente en su versión preliminar. Esta característica le permite cifrar los discos de datos y del sistema operativo usados por una máquina virtual de IaaS. Para Windows, las unidades se cifran mediante la tecnología de cifrado de BitLocker estándar del sector. Para Linux, los discos se cifran mediante la tecnología DM-Crypt. Se integra con Azure Key Vault para permitirle controlar y administrar las claves de cifrado del disco. La solución Azure Disk Encryption admite los tres siguientes escenarios de cifrado de cliente:
Habilitar el cifrado en nuevas máquinas virtuales de IaaS creadas a partir de archivos VHD cifrados por el cliente y claves de cifrado proporcionadas por el cliente, que se almacenan en Azure Key Vault.
Habilitar el cifrado en nuevas máquinas virtuales de IaaS creadas en Azure Marketplace.
Habilitar el cifrado en máquinas virtuales de IaaS existentes que ya se ejecutan en Azure.
Cifre los secretos en aplicaciones de Service Fabric
Los secretos pueden ser cualquier información confidencial, como cadenas de conexión de almacenamiento, contraseñas u otros valores que no se deben administrar en texto sin formato. Use Azure Key Vault para administrar claves y secretos en aplicaciones de Service Fabric.
Realice el modelado de seguridad y use unidades de negocio y equipos cuando sea necesario.
Título
Detalles
Componente
Dynamics CRM
Fase de SDL
Build
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Realice el modelado de seguridad y use unidades de negocio y equipos cuando sea necesario.
Minimice el acceso a la característica para compartir en entidades críticas.
Título
Detalles
Componente
Dynamics CRM
Fase de SDL
Implementación
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Minimice el acceso a la característica para compartir en entidades críticas.
Entrene a los usuarios sobre los riesgos asociados con la característica Compartir de Dynamics CRM y los procedimientos recomendados de seguridad.
Título
Detalles
Componente
Dynamics CRM
Fase de SDL
Implementación
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Entrene a los usuarios sobre los riesgos asociados con la característica Compartir de Dynamics CRM y los procedimientos recomendados de seguridad.
Incluya una regla de estándares de desarrollo que prohíba mostrar detalles de configuración en la administración de excepciones
Título
Detalles
Componente
Dynamics CRM
Fase de SDL
Implementación
Tecnologías aplicables
Genérico
Atributos
N/D
Referencias
N/D
Pasos
Incluya una regla de estándares de desarrollo que prohíba mostrar detalles de configuración en la administración de excepciones fuera del desarrollo. Pruebe esto como parte de las revisiones del código o de la inspección periódica.
Use el cifrado del servicio Azure Storage (SSE) para datos en reposo (versión preliminar)
Cifrado del servicio Azure Storage (SSE) para datos en reposo le ayuda a asegurar y proteger sus datos con el fin de cumplir con los compromisos de cumplimiento y seguridad de su organización. Con esta característica, Azure Storage cifra automáticamente sus datos antes de continuar al almacenamiento y los descifra después de la recuperación. La administración de claves, cifrado y descifrado es completamente transparente para los usuarios. SSE se aplica solo a blobs en bloques, blobs en páginas y blobs en anexos. Los otros tipos de datos, como tablas, colas y archivos, no se cifrarán.
Flujo de trabajo de cifrado y descifrado:
El cliente habilita el cifrado en la cuenta de almacenamiento.
Cuando el cliente escribe datos nuevos (PUT Blob, PUT Block, PUT Page, etc.) en Blob Storage, cada escritura se cifra mediante un cifrado AES de 256 bits, uno de los cifrados de bloques más sólidos disponibles.
Cuando el cliente necesita acceder a datos (GET Blob, etc.), estos se descifran automáticamente antes de que se devuelvan al usuario.
Si el cifrado está deshabilitado, las escrituras nuevas se dejan de cifrar y los datos cifrados existentes siguen cifrados hasta que el usuario los reescriba. Mientras el cifrado esté habilitado, se cifrarán las escrituras en el Almacenamiento de blobs. El estado de los datos no cambia cuando el usuario habilita y deshabilita el cifrado de la cuenta de almacenamiento.
Microsoft almacena, cifra y administra todas las claves de cifrado.
Tenga en cuenta que, en este momento, Microsoft administra las claves utilizadas para el cifrado. Microsoft genera las claves originalmente y administra su almacenamiento seguro, así como la rotación periódica de acuerdo con la política interna de Microsoft. En el futuro, los clientes tendrán la posibilidad de administrar sus propias claves de cifrado, y se proporcionará una ruta de migración de las claves administradas por Microsoft a las administradas por el cliente.
Use el cifrado en el cliente para almacenar información confidencial en Azure Storage
La biblioteca de cliente de Azure Storage para el paquete NuGet de .NET admite el cifrado de datos dentro de las aplicaciones cliente antes de cargarlos en Azure Storage y el descifrado de los datos mientras se descargan al cliente. La biblioteca también admite la integración con Azure Key Vault para la administración de las claves de la cuenta de almacenamiento. Esta es una breve descripción de cómo funciona el cifrado del lado cliente:
El SDK de cliente de Azure Storage genera una clave de cifrado de contenido (CEK), que es una clave simétrica de un solo uso.
Los datos de usuario se cifran mediante esta CEK.
Se encapsula la CEK (cifrada) con la clave de cifrado de clave (KEK). La KEK se identifica mediante un identificador de clave y puede ser un par de clave asimétrico o una clave simétrica que puede administrarse de forma local o guardarse en Azure Key Vault. El propio cliente de almacenamiento no tiene acceso a KEK. Simplemente invoca el algoritmo de ajuste de clave proporcionado por Key Vault. Los clientes pueden elegir usar proveedores personalizados para encapsular y desencapsular la clave si así lo desean.
A continuación, se cargan los datos cifrados en el servicio Azure Storage. Consulte los vínculos de la sección Referencias para ver detalles de implementación de bajo nivel.
Cifre la información confidencial o de identificación personal guardada en el almacenamiento local de teléfonos
Si la aplicación escribe información confidencial, como información de identificación personal del usuario (correo electrónico, número de teléfono, nombre, apellidos, preferencias, etc.), en el sistema de archivos del dispositivo móvil, se debería cifrar antes de escribirla en el sistema de archivos local. Si la aplicación es empresarial, considere la posibilidad de publicar la aplicación mediante Windows Intune.
Ejemplo
Intune se puede configurar con las siguientes directivas de seguridad para proteger datos confidenciales:
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Ejemplo
Si la aplicación no es empresarial, use el almacén de claves proporcionado por la plataforma, llaveros para almacenar claves de cifrado, con cualquier operación criptográfica que se pueda realizar en el sistema de archivos. En el siguiente fragmento de código, se muestra cómo acceder a la clave del llavero con xamarin:
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
Ofusque los archivos binarios generados antes de distribuirlos a los usuarios finales
Los archivos binarios generados (ensamblados en apk) se deben ofuscar para detener la ingeniería inversa de los ensamblados. Para tal propósito se pueden usar herramientas como CryptoObfuscator.
Establezca clientCredentialType en Certificate o Windows
Si se usa un token UsernameToken con una contraseña sin cifrar en un canal no cifrado, se expone la contraseña a atacantes que puedan rastrear los mensajes SOAP. Es posible que los proveedores de servicios que usan UsernameToken acepten las contraseñas enviadas sin cifrar. Si se envían contraseñas sin cifrar por un canal no cifrado, se puede exponer la credencial a atacantes que puedan rastrear el mensaje SOAP.
Ejemplo
La siguiente configuración del proveedor de servicios WCF usa UsernameToken:
No se ha definido la seguridad de transporte ni de mensajes. Las aplicaciones que transmiten mensajes sin seguridad de transporte ni de mensajes no pueden garantizar la integridad ni la confidencialidad de los mensajes. Cuando un enlace de seguridad de WCF se establece en None, se deshabilitan la seguridad de mensajes y la de transporte.
Ejemplo
La siguiente configuración establece el modo de seguridad en None.
Modo de seguridad En todos los enlaces de servicio, existen cinco modos de seguridad posibles:
Ninguno. Desactiva la seguridad.
Transport. Usa la seguridad de transporte para la autenticación mutua y la protección de mensajes.
Message. Usa la seguridad de mensajes para la autenticación mutua y la protección de mensajes.
Both. Permite proporcionar la configuración para la seguridad de transporte y de mensajes (solo es compatible con MSMQ).
TransportWithMessageCredential. Las credenciales se pasan con el mensaje, y la capa de transporte proporciona la protección de mensajes y la autenticación del servidor.
TransportCredentialOnly. Las credenciales del cliente se pasan con la capa de transporte y no se aplica la protección de mensajes. Use la seguridad de mensajes y de transporte para proteger la integridad y confidencialidad de los mensajes. La configuración siguiente indica al servicio que use la seguridad de transporte con las credenciales del mensaje.