Old and new problem: Server patch management

記事をシェアする:

With the increasing number of targeted attacks against variety of vulnerabilities, many companies have been taking measures to deal with patch management for client PCs. However, there are still many organizations that work manually in an Excel-based patch management for server as well. In particular, some customers say that the internal servers may have been extended to apply required patches, or may continue to use the end of support OS or middleware.

Why does this happen? It seems that some of administrators still believe that the internal network, which is not directly connected to the Internet, is safe. But last year’s WannaCry campaign has revealed that this is a myth.

Also, patching to the server is a prerequisite to performing operational verification test, which requires a pre-system unit of cost/effort to be ensured. Servers that do not have an Internet connection may have a lower priority because they do not link directly to the feature enhancement to applications.

However, attacks against vulnerability include not only information leakage but also service disruption like Ransomware. As mentioned earlier, the idea of safety is already obsolete even if it is an internal network. So, planned patching is essential for all servers, not only internet-facing servers, because there is a possibility some servers may be used as stepping board.

When WannaCry ‘s campaign was widely reported, I heard that there were not a few IT staff in charge who spent much time and effort collecting configuration information of servers by e – mail to the administrator of each server. Despite this load, I also heard that the collected information depends on the skill level of each server administrator, so it was not necessarily accurate. This type of risk will continue to exist equally in any organization in the future. Visualization of patch application status is important so that temporary service suspension can be accurately determined when an incident occurs. In addition, reliable configuration information is indispensable for budgeting to plan version up OS/middleware against end of support.

As a solution to support such a mechanism, IBM offersIBM BigFix. IBM BigFix is compatible with not only Windows but also Linux, multi-vendor UNIX. It supports automating the collection of configuration information including patch application status, automatic application of hardening policies, and collection of vulnerability information.

Figure1: Server patch management by IBM BigFix

In IBM BigFix, IBM provides patch definitions called fixlets that automate patch application, so that each server administrator can save time checking the vendor site individually or download patches. In addition, fixlet supports not only OS but also some platform IBM Db 2 and IBM WebSphere. Each server administrator can see patch list to be applied to their servers in the IBM BigFix console. It is also possible to apply at the timing of the server operation.

Figure 2: Patch application from IBM BigFix Management Console

Although many vendors ship solutions of configuration management / patch distribution solutions for client PCs, IBM BigFix is a solution that can be centrally managed including not only clients but also servers. It is used inside IBM and outsourcing customers. IBM License Metric Tool (license management tool for IBM software) uses BigFix technology too. From the best practice in the industry, you can deploy it to important servers with confidence.

With its own Intelligent Agent architecture, IBM BigFix can always collect the latest configuration information from managed nodes. Please refer to this link about the architectural advantage.

In many organizations, patch management for servers depends on each server administrator’s skill and security awareness. But the integrated patch management infrastructure helps the effective governance and easy operation. It also optimizes operational costs. As a mechanism to support unterminated patch management, IBM BigFix makes it easier to handle when an incident occurs in the unlikely event.