Share via

5.1 Security Considerations for Implementers

  • Article

The USS provides the DSS with all updates that ultimately are intended for client computers. It is important to prevent man-in-the-middle or other forms of spoofing attacks from providing the DSS with invalid or malformed metadata and rogue content. To ensure secure download of all data from the USS, the DSS performs these checks:

  • It accepts only updates that are signed by Microsoft certificates.

  • Depending on the operating system, it accepts only content files whose SHA hash matches the SHA hash specified by the USS in the update metadata.<78>

As a result, it is strongly recommended that the USS be configured so that all metadata communication is done over HTTPS instead of HTTP. Using Secure Sockets Layer (SSL) server certificate verification ensures that the client is talking to the real server and closes any possible man-in-the-middle attacks.

There are two strategies one can use to reduce the impact of Denial Of Service (DOS) attacks against the USS:

  • Turn on authentication, and deny access to unauthenticated DSS. This will allow one to quickly disable access to rogue DSS machines.

  • Be sure no single operation takes too much processing time on the USS. This will require an attacker to keep up a steady stream of requests to deny access to the server, so a simple network trace will identify the offending machine and shut it down. This applies to requests sent by "spoof clients" (for example, a virus emulating a client that tries to pass an unbounded set of parameters to various methods).

If the USS implementation stores and displays any data passed to it from DSS, it is important to ensure the data is not malformed, especially if it is displayed in the context of a scripting language (for example, from JScript, from within a webpage, or used within SQL).