Marco de seguridad: Administración de configuración | Mitigaciones

Producto o servicio Artículo
Aplicación web
Base de datos
API web
Dispositivo IoT
Puerta de enlace de campo de IoT
Puerta de enlace de nube de IoT
Límite de confianza de la máquina
Almacenamiento de Azure
WCF

Implementación de la directiva de seguridad de contenido [CSP] y deshabilitación de Javascript en línea

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias An Introduction to Content Security Policy (Introducción a la directiva de seguridad del contenido), Content Security Policy Reference (Referencia a la directiva de seguridad del contenido), Security features (Características de seguridad), Introduction to content security policy (Introducción a la directiva de seguridad del contenido), Can I use CSP? (¿Puedo usar la directiva de seguridad de contenido [CSP]?)
Pasos

La directiva de seguridad de contenido (CSP) es un mecanismo de seguridad de defensa en profundidad, una norma de W3C, que permite controlar el contenido insertado en el sitio a los propietarios de aplicaciones web. La CSP se agrega como encabezado de respuesta HTTP al servidor web y se aplica en los exploradores del lado del cliente. Es una directiva basada en una lista de elementos permitidos: un sitio web puede declarar un conjunto de dominios de confianza desde los que se puede cargar contenido activo, como JavaScript.

La CSP ofrece las siguientes ventajas de seguridad:

  • Protección frente a XSS: si una página es vulnerable a XSS, los atacantes pueden aprovecharlo de dos maneras:
    • Insertando <script>malicious code</script>. Esta vulnerabilidad de seguridad no funcionará debido a la restricción básica 1 de CSP.
    • Insertando <script src="http://attacker.com/maliciousCode.js"/>. Esta vulnerabilidad de seguridad no funcionará, ya que el dominio que controla el atacante no estará en la lista de dominios permitidos de CSP.
  • Control de la exfiltración de datos: si cualquier contenido malintencionado de una página web intenta conectarse a un sitio web externo y robar datos, la CSP anulará la conexión. Esto se debe a que el dominio de destino no estará en la lista de elementos permitidos de CSP.
  • Defensa contra el secuestro de clic: el secuestro de clic es una técnica de ataque con la que un adversario puede enmarcar un sitio web auténtico y forzar a los usuarios a hacer clic en elementos de la interfaz de usuario. La defensa actual contra el secuestro de clic se consigue mediante la configuración de un encabezado de respuesta X-Frame-Option. No todos los exploradores respetan este encabezado y la implementación de la CSP será un método estándar de defensa contra el secuestro de clic
  • Informes de ataques en tiempo real: si se produce un ataque de inserción de código en un sitio web con la CSP habilitada, los exploradores desencadenarán automáticamente una notificación a un punto de conexión configurado en el servidor web. De esta manera, la CSP actúa como sistema de advertencia en tiempo real.

Ejemplo

Ejemplo de directiva:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com 

Esta directiva permite a los scripts cargar solo desde el servidor de la aplicación web y de Google Analytics. Se rechazarán los scripts que se carguen desde cualquier otro sitio. Cuando se habilita la CSP en un sitio web, para mitigar los ataques XSS, se deshabilitan automáticamente las siguientes características.

Ejemplo

Los scripts en línea no se ejecutarán. Ejemplos de scripts en línea

<script> some JavaScript code </script>
Event handling attributes of HTML tags (for example, <button onclick="function(){}">
javascript:alert(1);

Ejemplo

Las cadenas no se evaluarán como código.

Example: var str="alert(1)"; eval(str);

Habilitación del filtro XSS del explorador

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias Filtro de protección de XSS
Pasos

La configuración del encabezado de respuesta X-XSS-Protection controla el filtro de script entre sitios del explorador. Este encabezado de respuesta puede tener los siguientes valores:

  • 0: Esto deshabilitará el filtro
  • 1: Filter enabled Si se detecta un ataque de scripting entre sitios (XSS), para detenerlo, el explorador saneará la página
  • 1: mode=block : Filter enabled. En lugar de sanearla, cuando se detecta un ataque XSS, el explorador impedirá la representación de la página
  • 1: report=http://[YOURDOMAIN]/your_report_URI : Filter enabled. El explorador saneará la página y notificará la infracción.

Se trata de una función de cromo que usa los informes de infracción de la CSP para enviar detalles al URI que elija. Las dos últimas opciones se consideran valores seguros.

Deshabilitación obligatoria del seguimiento y la depuración de las aplicaciones ASP.NET antes de la implementación

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias ASP.NET Debugging Overview(Información general de depuración ASP.NET), ASP.NET Tracing Overview (Información general de seguimiento ASP.NET), How to: Enable Tracing for an ASP.NET Application (Habilitación del seguimiento para una aplicación ASP.NET), How to: Enable Debugging for ASP.NET Applications (Habilitación de la depuración para aplicaciones ASP.NET).
Pasos Cuando el seguimiento está habilitado para la página, cada explorador que lo solicite también obtiene la información de seguimiento con los datos del estado interno del servidor y del flujo de trabajo. Esta información podría ser confidencial. Cuando está habilitada la depuración en la página, los errores que se producen en el servidor provocan el seguimiento de pila completo de los datos que se presenta al explorador. Esos datos pueden exponer información confidencial del flujo de trabajo del servidor.

Acceso exclusivo a archivos JavaScript de terceros de orígenes de confianza

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Debe hacerse referencia a archivos JavaScript de terceros únicamente desde orígenes de confianza. Los puntos de conexión de referencia deben estar siempre en TLS.

Comprobación de que las páginas con autenticación con ASP.NET incorporan defensas contra el secuestro de clic

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias OWASP click-jacking Defense Cheat Sheet (Hoja de referencia rápida de OWASP sobre la defensa ante el secuestro de clic), IE Internals - Combating click-jacking With X-Frame-Options (Elementos internos de Internet Explorer: combatir el secuestro de clic con X-Frame-Options)
Pasos

El secuestro de clic, también conocido como "clickjacking" o "ataque UI redress", se produce cuando un atacante utiliza varias capas transparentes u opacas para engañar al usuario para que haga clic en un botón o vínculo de otra página al intentar hacer clic en la página del nivel superior.

Estas capas se logran al elaborar una página malintencionada con un iframe, que carga la página de la víctima. Por lo tanto, el atacante "secuestra" el clic destinado a su página y los enruta a otra página, muy probablemente propiedad de otra aplicación, dominio o ambos. Para evitar el secuestro de clic, establezca los encabezados de respuesta HTTP X-Frame-Options adecuados que indiquen al explorador que no permita enmarcar a otros dominios

Ejemplo

El encabezado X-FRAME-OPTIONS se puede establecer a través de web.config de IIS. Fragmento de código de web.config para los sitios que nunca deben enmarcarse:

    <system.webServer>
        <httpProtocol>
            <customHeader>
                <add name="X-FRAME-OPTIONS" value="DENY"/>
            </customHeaders>
        </httpProtocol>
    </system.webServer>

Ejemplo

Código de web.config para los sitios que solo deben enmarcar las páginas del mismo dominio:

    <system.webServer>
        <httpProtocol>
            <customHeader>
                <add name="X-FRAME-OPTIONS" value="SAMEORIGIN"/>
            </customHeaders>
        </httpProtocol>
    </system.webServer>

Comprobación de que solo se permiten orígenes de confianza si CORS está activado en las aplicaciones web ASP.NET

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Formularios Web Forms, MVC5
Atributos N/D
Referencias N/D
Pasos

La seguridad del explorador impide que una página web realice solicitudes AJAX a otro dominio. Esta restricción se conoce como la directiva de mismo origen y evita que un sitio malintencionado lea datos confidenciales de otro sitio. Sin embargo, a veces puede ser necesario exponer las API de forma segura para que las consuman otros sitios. Uso compartido de recursos de origen cruzado (CORS) es una norma de W3C que permite mayor flexibilidad a los servidores en la directiva de mismo origen. Con CORS, un servidor puede permitir explícitamente algunas solicitudes de origen cruzado y rechazar otras.

CORS es más seguro y más flexible que las técnicas anteriores, como JSONP. En esencia, la habilitación de CORS se traduce en la incorporación de algunos encabezados de respuesta HTTP (Access-Control-*) en la aplicación web, lo cual se puede hacer de un par de maneras.

Ejemplo

Si se puede acceder a web.config, CORS puede agregarse mediante el siguiente nodo:

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <clear />
        <add name="Access-Control-Allow-Origin" value="https://example.com" />
      </customHeaders>
    </httpProtocol>

Ejemplo

Si no se puede acceder a web.config, CORS puede configurarse mediante la incorporación del código de C# siguiente:

HttpContext.Response.AppendHeader("Access-Control-Allow-Origin", "https://example.com")

Tenga en cuenta que es fundamental garantizar que la lista de orígenes del atributo "Access-Control-Allow-Origin" se establece en un conjunto de orígenes finito y de confianza. Si esto no se configura correctamente (por ejemplo, se establece el valor como "*"), los sitios malintencionados podrán desencadenar solicitudes de origen cruzado a la aplicación web sin restricciones, por lo que la aplicación se volverá vulnerable a ataques CSRF.

Habilitación del atributo ValidateRequest en las páginas de ASP.NET

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Formularios Web Forms, MVC5
Atributos N/D
Referencias Request Validation - Preventing Script Attacks (Validación de solicitudes: prevención de ataques de script)
Pasos

La validación de solicitudes, una característica de ASP.NET desde la versión 1.1, impide que el servidor acepte contenido con HTML sin codificar. Esta característica está diseñada para ayudar a evitar algunos ataques de inserción de script mediante los cuales el código de script del cliente o HTML puede enviarse sin que se sepa a un servidor, almacenarse y presentarse a otros usuarios. Se recomienda encarecidamente validar todos los datos de entrada y codificar el código HTML cuando corresponda.

La validación de solicitudes se realiza mediante la comparación de todos los datos de entrada con una lista de valores peligrosos. Si se produce una coincidencia, ASP.NET genera un HttpRequestValidationException. De forma predeterminada, la característica de validación de solicitudes está habilitada.

Ejemplo

Sin embargo, se puede deshabilitar en el nivel de página:

<%@ Page validateRequest="false" %> 

o en el nivel de aplicación

<configuration>
   <system.web>
      <pages validateRequest="false" />
   </system.web>
</configuration>

Tenga en cuenta que esta característica de validación de solicitud no es compatible con la canalización de MVC6 ni forma parte de esta.

Uso de las últimas versiones locales de las bibliotecas de JavaScript

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos

Los desarrolladores que utilizan bibliotecas estándar de JavaScript como JQuery deben usar versiones aprobadas de las bibliotecas de JavaScript comunes sin errores de seguridad conocidos. Un procedimiento recomendado es usar la versión más reciente de las bibliotecas, ya que contienen correcciones para las vulnerabilidades de seguridad conocidas de las versiones anteriores.

Si no se puede usar la versión más reciente por motivos de compatibilidad, debe utilizarse la anterior mínima aceptable.

Versiones mínimas aceptables:

  • JQuery
    • JQuery 1.7.1
    • JQueryUI 1.10.0
    • JQuery Validate 1.9
    • JQuery Mobile 1.0.1
    • JQuery Cycle 2.99
    • JQuery DataTables 1.9.0
  • Ajax Control Toolkit
    • Ajax Control Toolkit 40412
  • ASP.NET Web Forms and Ajax
    • ASP.NET Web Forms and Ajax 4
    • ASP.NET Ajax 3.5
  • ASP.NET MVC
    • ASP.NET MVC 3.0

No cargue nunca bibliotecas de JavaScript desde sitios externos, como redes CDN públicas

Deshabilitación del rastreo automático de MIME

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias IE8 Security Part V: Comprehensive Protection (Seguridad de IE8 [parte V]: protección total), MIME types (Tipos de MIME)
Pasos El encabezado X-Content-Type-Options es un encabezado HTTP que permite a los desarrolladores especificar que su contenido no se debe someter a un rastreo de MIME. Este encabezado se ha diseñado para mitigar los ataques de rastreo de MIME. Para cada página que podría incluir contenido controlable por el usuario, debe usar el encabezado HTTP X-Content-Type-Options:nosniff. Para habilitar el encabezado necesario globalmente para todas las páginas de la aplicación, puede realizar una de las siguientes acciones

Ejemplo

Agregue el encabezado en el archivo web.config si la aplicación está hospedada en Internet Information Services (IIS) 7 o posteriores.

<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff"/>
</customHeaders>
</httpProtocol>
</system.webServer>

Ejemplo

Agregue el encabezado mediante el método global Application_BeginRequest

void Application_BeginRequest(object sender, EventArgs e)
{
this.Response.Headers["X-Content-Type-Options"] = "nosniff";
}

Ejemplo

Implemente un módulo HTTP personalizado

public class XContentTypeOptionsModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += newEventHandler(context_PreSendRequestHeaders);
}
#endregion
void context_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
if (application == null)
  return;
if (application.Response.Headers["X-Content-Type-Options "] != null)
  return;
application.Response.Headers.Add("X-Content-Type-Options ", "nosniff");
}
}

Ejemplo

Puede habilitar el encabezado necesario solo para páginas específicas si lo agrega a respuestas individuales:

this.Response.Headers["X-Content-Type-Options"] = "nosniff";

Eliminación de encabezados de servidor estándar de los sitios web de Windows Azure para evitar la creación de huellas digitales

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos EnvironmentType: Azure
Referencias Removing standard server headers on Windows Azure Web Sites (Eliminación de encabezados de servidor estándar de los sitios web de Windows Azure)
Pasos Los encabezados como Server, X-Powered-By y X-AspNet-Version revelan información sobre el servidor y las tecnologías subyacentes. Se recomienda para suprimir estos encabezados para evitar la creación de huellas digitales en la aplicación

Configurar Firewall de Windows para el acceso al motor de base de datos

Título Detalles
Componente Base de datos
Fase de SDL Build
Tecnologías aplicables SQL Azure, OnPrem
Atributos N/A, SQL Version: V12
Referencias Procedimientos para configurar un firewall de Azure SQL Database, Configuración de firewall de Windows para el acceso al motor de base de datos
Pasos Los sistemas de firewall ayudan a evitar el acceso no autorizado a los recursos de los equipos. Si desea acceder a una instancia del motor de base de datos de SQL Server a través de un firewall, debe configurar el firewall en el equipo que ejecuta SQL Server para que lo permita

Comprobación de que solo se permiten orígenes de confianza si CORS está activado en ASP.NET Web API

Título Detalles
Componente API Web
Fase de SDL Build
Tecnologías aplicables MVC 5
Atributos N/D
Referencias Enabling Cross-Origin Requests in ASP.NET Web API 2 (Habilitación de solicitudes de origen cruzado en ASP-NET Web API 2), Funciones para CORS en ASP.NET Web API 2
Pasos

La seguridad del explorador impide que una página web realice solicitudes AJAX a otro dominio. Esta restricción se conoce como la directiva de mismo origen y evita que un sitio malintencionado lea datos confidenciales de otro sitio. Sin embargo, a veces puede ser necesario exponer las API de forma segura para que las consuman otros sitios. Uso compartido de recursos de origen cruzado (CORS) es una norma de W3C que permite mayor flexibilidad a los servidores en la directiva de mismo origen.

Con CORS, un servidor puede permitir explícitamente algunas solicitudes de origen cruzado y rechazar otras. CORS es más seguro y más flexible que las técnicas anteriores, como JSONP.

Ejemplo

En App_Start/WebApiConfig.cs, agregue el siguiente código al método WebApiConfig.Register

using System.Web.Http;
namespace WebService
{
    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            // New code
            config.EnableCors();

            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
        }
    }
}

Ejemplo

El atributo de EnableCors se puede aplicar a métodos de acción en un controlador como se indica a continuación:

public class ResourcesController : ApiController
{
  [EnableCors("http://localhost:55912", // Origin
              null,                     // Request headers
              "GET",                    // HTTP methods
              "bar",                    // Response headers
              SupportsCredentials=true  // Allow credentials
  )]
  public HttpResponseMessage Get(int id)
  {
    var resp = Request.CreateResponse(HttpStatusCode.NoContent);
    resp.Headers.Add("bar", "a bar value");
    return resp;
  }
  [EnableCors("http://localhost:55912",       // Origin
              "Accept, Origin, Content-Type", // Request headers
              "PUT",                          // HTTP methods
              PreflightMaxAge=600             // Preflight cache duration
  )]
  public HttpResponseMessage Put(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  [EnableCors("http://localhost:55912",       // Origin
              "Accept, Origin, Content-Type", // Request headers
              "POST",                         // HTTP methods
              PreflightMaxAge=600             // Preflight cache duration
  )]
  public HttpResponseMessage Post(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
}

Tenga en cuenta que es fundamental garantizar que la lista de orígenes del atributo EnableCors se establece en un conjunto de orígenes finito y de confianza. Si esto no se configura correctamente (por ejemplo, se establece el valor como "*"), los sitios malintencionados podrán desencadenar solicitudes de origen cruzado a la API sin restricciones, por lo que la API se volverá vulnerable a ataques CSRF. EnableCors se puede decorar en el nivel de controlador.

Ejemplo

Para deshabilitar CORS en un determinado método en una clase, se puede utilizar el atributo DisableCors tal y como se muestra a continuación:

[EnableCors("https://example.com", "Accept, Origin, Content-Type", "POST")]
public class ResourcesController : ApiController
{
  public HttpResponseMessage Put(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  public HttpResponseMessage Post(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  // CORS not allowed because of the [DisableCors] attribute
  [DisableCors]
  public HttpResponseMessage Delete(int id)
  {
    return Request.CreateResponse(HttpStatusCode.NoContent);
  }
}
Título Detalles
Componente API Web
Fase de SDL Build
Tecnologías aplicables MVC 6
Atributos N/D
Referencias Habilitación de solicitudes de origen cruzado (CORS) en ASP.NET Core 1.0
Pasos

En ASP.NET Core 1.0, CORS puede habilitarse mediante middleware o MVC. Al utilizar MVC para habilitar CORS se utilizan los mismos servicios CORS, pero no middleware de CORS.

Enfoque 1 Habilitación de CORS con middleware: para habilitar CORS para toda la aplicación, agregue el middleware de CORS a la canalización de solicitud con el método de extensión UseCors. Cuando se agrega el middleware de CORS mediante la clase CorsPolicyBuilder, puede especificarse una directiva de origen cruzado. Existen dos formas de hacerlo:

Ejemplo

Lo primero que se hace es llamar a UseCors con una expresión lambda. La expresión lambda toma un objeto CorsPolicyBuilder:

public void Configure(IApplicationBuilder app)
{
    app.UseCors(builder =>
        builder.WithOrigins("https://example.com")
        .WithMethods("GET", "POST", "HEAD")
        .WithHeaders("accept", "content-type", "origin", "x-custom-header"));
}

Ejemplo

Lo segundo es definir una o varias directivas CORS con nombre y seleccionar la directiva por el nombre en tiempo de ejecución.

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options =>
    {
        options.AddPolicy("AllowSpecificOrigin",
            builder => builder.WithOrigins("https://example.com"));
    });
}
public void Configure(IApplicationBuilder app)
{
    app.UseCors("AllowSpecificOrigin");
    app.Run(async (context) =>
    {
        await context.Response.WriteAsync("Hello World!");
    });
}

Enfoque 2 Habilitar CORS en MVC: los desarrolladores pueden usar también MVC para aplicar CORS específico por acción, por controlador o globalmente para todos los controladores.

Ejemplo

Por acción: para especificar una directiva de CORS para una acción específica, agregue el atributo [EnableCors] a la acción. Especifique el nombre de la directiva.

public class HomeController : Controller
{
    [EnableCors("AllowSpecificOrigin")] 
    public IActionResult Index()
    {
        return View();
    }

Ejemplo

Por controlador:

[EnableCors("AllowSpecificOrigin")]
public class HomeController : Controller
{

Ejemplo

Globalmente:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.Configure<MvcOptions>(options =>
    {
        options.Filters.Add(new CorsAuthorizationFilterFactory("AllowSpecificOrigin"));
    });
}

Tenga en cuenta que es fundamental garantizar que la lista de orígenes del atributo EnableCors se establece en un conjunto de orígenes finito y de confianza. Si esto no se configura correctamente (por ejemplo, se establece el valor como "*"), los sitios malintencionados podrán desencadenar solicitudes de origen cruzado a la API sin restricciones, por lo que la API se volverá vulnerable a ataques CSRF.

Ejemplo

Para deshabilitar CORS en una acción o un controlador, utilice el atributo [DisableCors].

[DisableCors]
    public IActionResult About()
    {
        return View();
    }

Cifrado de secciones de los archivos de configuración de la API web que contienen datos confidenciales

Título Detalles
Componente API Web
Fase de SDL Implementación
Tecnologías aplicables Genérico
Atributos N/D
Referencias Cómo: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI (Procedimiento para cifrar secciones de configuración en ASP.NET 2.0 mediante DPAPI), Especificar un proveedor de configuración protegida, Uso de Azure Key Vault para proteger los secretos de la aplicación
Pasos 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.

Comprobación de que todas las interfaces de administración están protegidas con credenciales seguras

Título Detalles
Componente Dispositivo IoT
Fase de SDL Implementación
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Las interfaces administrativas que expone la puerta de enlace de dispositivo o campo deben protegerse con credenciales seguras. Además, debe protegerse con credenciales seguras el resto de interfaces expuestas, como Wi-Fi, SSH, recursos compartidos de archivo o FTP. De forma predeterminada, no deben usarse contraseñas poco seguras.

Comprobación de que no se puede ejecutar código desconocido en los dispositivos

Título Detalles
Componente Dispositivo IoT
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias Enabling Secure Boot and BitLocker Device Encryption on Windows 10 IoT Core (Habilitación del arranque seguro y del cifrado de dispositivos de BitLocker en Windows 10 IoT Core)
Pasos El arranque seguro de UEFI restringe el sistema para permitir solo la ejecución de archivos binarios firmados por una entidad determinada. Esta característica evita que se ejecute código desconocido en la plataforma y pueda debilitar su seguridad. Habilite el arranque seguro de UEFI y restrinja la lista de entidades emisoras de certificados de confianza para la firma de código. Firme todo el código que se implementa en el dispositivo a través de una de las entidades de confianza.

Cifrado del sistema operativo y otras particiones en los dispositivos IoT con Bitlocker

Título Detalles
Componente Dispositivo IoT
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Windows 10 IoT Core implementa una versión ligera de cifrado de dispositivos de BitLocker, que depende en gran medida de la presencia de un TPM en la plataforma, incluido el protocolo preOS necesarios en UEFI que toma las medidas necesarias. Estas medidas de preOS garantizan que el sistema operativo posterior tiene un registro definitivo de cómo se inició el sistema operativo. Cifre con Bitlocker las particiones del sistema operativo, así como cualquier otra partición donde se almacenen datos confidenciales.

Comprobación de que solo se habilita el mínimo número de servicios o características en los dispositivos

Título Detalles
Componente Dispositivo IoT
Fase de SDL Implementación
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos No habilite ni active características o servicios en el sistema operativo que no sean necesarias para el funcionamiento de la solución. Por ejemplo, si el dispositivo no requiere la implementación de una interfaz de usuario, instale Windows IoT Core en modo "desatendido".

Cifrado del sistema operativo y otras particiones de la puerta de enlace de campo de IoT con Bitlocker

Título Detalles
Componente Puerta de enlace de campo de IoT
Fase de SDL Implementación
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Windows 10 IoT Core implementa una versión ligera de cifrado de dispositivos de BitLocker, que depende en gran medida de la presencia de un TPM en la plataforma, incluido el protocolo preOS necesarios en UEFI que toma las medidas necesarias. Estas medidas de preOS garantizan que el sistema operativo posterior tiene un registro definitivo de cómo se inició el sistema operativo. Cifre con Bitlocker las particiones del sistema operativo, así como cualquier otra partición donde se almacenen datos confidenciales.

Comprobación de que las credenciales de inicio de sesión predeterminadas de la puerta de enlace de campo se modifican durante la instalación

Título Detalles
Componente Puerta de enlace de campo de IoT
Fase de SDL Implementación
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Comprobación de que las credenciales de inicio de sesión predeterminadas de la puerta de enlace de campo se modifican durante la instalación

Comprobación de que la puerta de enlace de la nube implementa un proceso para mantener actualizado el firmware de los dispositivos conectados

Título Detalles
Componente Puerta de enlace de la nube de IoT
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos Elección de puerta de enlace: Azure IoT Hub
Referencias Información general sobre la administración de dispositivos de IoT Hub, Tutorial de Device Update para Azure IoT Hub con la imagen de referencia para Raspberry Pi 3 B+.
Pasos LWM2M es un protocolo de Open Mobile Alliance para la administración de dispositivos IoT. La administración de dispositivos IoT de Azure permite interactuar con dispositivos físicos mediante trabajos de dispositivo. Asegúrese de que la puerta de enlace de la nube implementa un proceso para mantener al día de forma rutinaria el dispositivo y otros datos de configuración mediante la administración de dispositivos de Azure IoT Hub.

Comprobación de que los dispositivos tienen controles de seguridad de punto de conexión configurados según las directivas organizativas

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 controles de seguridad de punto de conexión de los dispositivos, como BitLocker para el cifrado a nivel de disco, antivirus con las firmas actualizadas, firewall basado en el host, actualizaciones de sistema operativo, directivas de grupo, etc. estén configurados según las directivas de seguridad de la organización.

Comprobación de la administración segura de las claves de acceso de almacenamiento de Azure

Título Detalles
Componente Azure Storage
Fase de SDL Implementación
Tecnologías aplicables Genérico
Atributos N/D
Referencias Guía de seguridad de Azure Storage: administración de las claves de la cuenta de almacenamiento
Pasos

Almacenamiento de claves: se recomienda almacenar las claves de acceso de Azure Storage en Azure Key Vault como secreto y hacer que las aplicaciones recuperen la clave del almacén. Se recomienda esto por los siguientes motivos:

  • La aplicación nunca tendrá la clave de almacenamiento codificada de manera rígida en un archivo de configuración, lo que elimina la posibilidad de que alguien acceda a las claves sin permiso específico
  • El acceso a las claves se controla con Azure Active Directory. Esto significa que el propietario de la cuenta puede conceder acceso a la serie de aplicaciones que necesitan recuperar las claves de Azure Key Vault. Las demás aplicaciones no podrán acceder a las claves si no se les concede específicamente el permiso
  • Regeneración de claves: por motivos de seguridad, se recomienda disponer de un proceso para volver a generar las claves de acceso de almacenamiento de Azure. Los detalles sobre por qué y cómo planear la regeneración de claves se documentan en el artículo de referencia de la Guía de seguridad de Azure Storage

Comprobación de que solo se permiten orígenes de confianza si CORS está activado en Azure Storage

Título Detalles
Componente Azure Storage
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias CORS Support for the Azure Storage Services (Compatibilidad de CORS para los servicios de Azure Storage)
Pasos Azure Storage permite habilitar el uso compartido de recursos entre orígenes. Puede especificar los dominios que pueden tener acceso a los recursos de cada una de las cuentas de almacenamiento. De forma predeterminada, el uso compartido de recursos entre orígenes está deshabilitado en todos los servicios. Puede habilitarlo mediante la API de REST o la biblioteca de clientes de Storage para llamar a uno de los métodos a fin de establecer las directivas del servicio.

Habilitación de la característica de limitación del servicio de WCF

Título Detalles
Componente WCF
Fase de SDL Build
Tecnologías aplicables .NET Framework 3
Atributos N/D
Referencias MSDN, Fortify Kingdom
Pasos

No limitar el uso de recursos del sistema podría provocar el agotamiento de estos y, en última instancia, la denegación del servicio.

  • EXPLICACIÓN: Windows Communication Foundation (WCF) ofrece la posibilidad de limitar las solicitudes de servicio. Permitir demasiadas solicitudes de cliente puede superar al sistema y agotar sus recursos. Por otra parte, permitir solo un pequeño número de solicitudes a un servicio puede impedir que los usuarios legítimos lo usen. Cada servicio debe ajustarse y configurarse individualmente para permitir la cantidad adecuada de recursos.
  • RECOMENDACIONES Habilite la característica de limitación del servicio de WCF y establezca los límites adecuados para la aplicación.

Ejemplo

El siguiente es un ejemplo de configuración con la limitación habilitada:

<system.serviceModel> 
  <behaviors>
    <serviceBehaviors>
    <behavior name="Throttled">
    <serviceThrottling maxConcurrentCalls="[YOUR SERVICE VALUE]" maxConcurrentSessions="[YOUR SERVICE VALUE]" maxConcurrentInstances="[YOUR SERVICE VALUE]" /> 
  ...
</system.serviceModel> 

Revelación de información de WCF mediante metadatos

Título Detalles
Componente WCF
Fase de SDL Build
Tecnologías aplicables .NET Framework 3
Atributos N/D
Referencias MSDN, Fortify Kingdom
Pasos Los metadatos pueden ayudar a los atacantes a obtener información sobre el sistema y a planear la forma de ataque. Los servicios de WCF pueden configurarse para exponer los metadatos. Los metadatos proporcionan información descriptiva detallada del servicio y no se deben difundir en entornos de producción. Las propiedades HttpGetEnabled / HttpsGetEnabled de la clase de ServiceMetaData definen si un servicio va a exponer los metadatos

Ejemplo

El código siguiente indica a WCF que difunda los metadatos del servicio

ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = true; 
smb.HttpGetUrl = new Uri(EndPointAddress); 
Host.Description.Behaviors.Add(smb); 

En un entorno de producción no se difunden los metadatos del servicio. Establezca las propiedades HttpGetEnabled / HttpsGetEnabled de la clase ServiceMetaData en false.

Ejemplo

El código siguiente indica a WCF que no difunda los metadatos del servicio.

ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); 
smb.HttpGetEnabled = false; 
smb.HttpGetUrl = new Uri(EndPointAddress); 
Host.Description.Behaviors.Add(smb);