software patching.jpg Getty Images

How Microsoft WSUS Fits into Your Security Strategy

Here's how Microsoft WSUS for software patching can be leveraged in a variety of security use cases.

If you do a Web search on the phrase “IT security best practices,” blogs and articles about the importance of software patching will be right up there in the results. Patch management is critically important to keeping your IT resources secure. After all, one of the main reasons why software vendors go through the trouble of creating patches is to address security vulnerabilities that have been discovered. Given the importance of software patching, it stands to reason that deploying a patch management tool such as Microsoft WSUS (Windows Server Update Service) is also important.

Of course, Windows Update can download patches from Microsoft even if you don’t have a Microsoft WSUS server, so it’s worth considering the advantages that WSUS (and similar tools) gives you over just letting your systems download patches on their own.

One of the most important reasons for using Microsoft WSUS is that WSUS can add an extra layer of protection to the servers on your network. Imagine that an organization has a file server that stores all of the user’s unstructured data. Does that file server need Internet access? In most cases, the answer is probably no. A user would not typically access the file server directly through the Internet. Instead, a remote user would likely connect to a VPN and then access the server.

Indeed, the internet is an undeniably hostile environment. The servers on your network should be completely isolated from the Internet unless there is a compelling business reason for providing the server with internet access. A Microsoft WSUS server can help you keep infrastructure servers and application servers from ever having to reach out to the internet. Rather than downloading operating system patches directly from Microsoft, the servers can download patches from a trusted WSUS server on your own network.

There are actually a few different ways in which you can design a WSUS architecture to shield your backend environment. Smaller organizations, for instance, commonly use only a single Microsoft WSUS server. Such a server can be configured with two separate network adapters (physical or virtual). One of these adapters connects to a network segment that has access to the internet (so that WSUS can download patches), while the other adapter attaches to an isolated network segment with no Internet access. This allows the hosts on that segment to download patches from the WSUS server without being exposed to Internet traffic.

Another option is to create a hierarchy of WSUS servers, a model used primarily in larger organizations. The idea is that although a single Microsoft WSUS server can download all of the necessary patches from Microsoft, that one server probably does not have sufficient resources to service all network clients.

Rather than trying to use a single WSUS server to service thousands of network clients, the WSUS server downloads updates from Microsoft and then pushes those updates to a collection of several downstream WSUS servers. Those WSUS servers can then collectively service the network clients. Some organizations take this process a step further and designate specific WSUS servers to handle patches in various languages. For example, one WSUS server might handle client computers that are configured to use English, while another WSUS server might handle French clients. Similar techniques are sometimes used for servicing specific branch offices.

Regardless, there is no rule that says that a hierarchical WSUS deployment can be used only in large organizations. Smaller shops can also take advantage of a WSUS hierarchy as a way of providing an additional level of isolation between network servers and the internet.

In some situations, organizations must guarantee that servers containing the most sensitive data remain totally isolated from the Internet, and even a hierarchical WSUS server deployment constitutes an unacceptable level of risk. In these types of situations, it is possible to use a less common architecture called disconnected WSUS.

The idea behind this approach is simple. The organization deploys two WSUS servers. One of these WSUS servers exists on an isolated network segment, while the other is placed on a segment with access to the Internet. There is no relationship or connectivity between the two servers. The WSUS server on the segment with internet access downloads patches in the usual way. Those patches are then exported to removable media, which can then be imported into the isolated WSUS server. This allows the isolated WSUS server to issue patches to the hosts on the isolated network segment, but without the risk of exposing the hosts (even indirectly) to the Internet.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish