security staffs must ensure to own the patch is up-to-date before updating. If a new machine increases suddenly in original system, security staffs have to examine their system status involves security patches are the newest as well. It is essential for security staffs to continue analyzing and monitoring all machines are far from vulnerabilities; moreover, they must notice all patches release from vendors and update at the short time. Many security vulnerabilities were caused by security staffs ignore to update security patches and let attackers can access to the systems with a malicious code. For this reason, an efficient tool is needed to monitor the patch status and report patches of all machines, such as Pakiti, Nuwa. In next section, we will discuss patch management tools in detail, and point out how to use it to improve the current VMIC system.
4.2 Online Patch Management - Pakiti
A growth of large scale grid and cloud infrastructures are in operation around the world, which means that security staffs must be careful of the following security risk.
Unpatched security vulnerabilities are often misused by wicked attackers to control machines or cause other harm to computers and other legal users. Security patch updates become one of the main causes of security incidents to affect computing infrastructures.
Hence, having a proper and instant patch management is crucial to keep the system in safety and to resist common attacks targeting known weak spots. Pakiti [40] is a system that provides a monitoring and notification mechanism to check the patch status of machines.
Pakiti was originally designed by Steve Traylen in 2004 at the Rutherford Appleton Laboratory (RAL) UK. In the beginning, it provided a simple client and server to enable
‧
the team to detect the nodes where patches were missing. Romain Wartel (RAL/CERN) took over this basic tool and transformed into Pakiti, hosted on SourceForge. EGEE Operational Security Coordination Team (OSCT) adopted this tool to start to monitor the security patch status of its more than 200 sites. For the moment, Pakiti is used by plenty of research organizations and computing infrastructures around the world.
4.2.1 Pakiti Architecture
Pakiti is a client/server model, where clients and servers are exchanging information using HTTP(S) protocol. Once installed Pakiti service, Pakiti client will send the list of installed packages to the relevant Pakiti server(s) every night, then Pakiti server compares the versions against versions which Pakiti server obtains from packages repositories and Open Vulnerability and Assessment Language (OVAL) [42] definitions from MITRE [43]
who applying systems engineering and advanced technology to critical national problems.
OVAL is an XML language allowing specifying vulnerability, and OVAL identifies a complete set of conditions that describe at least the version of software components.
OVAL is supported by RedHat, SuSe and Microsoft such as some large OS vendors.
These vendors issue up-to-date version on each release of security patches. The main procedure of Pakiti can be defined as follows (see Figure 4-2).
(1) The hostname of Pakiti server is giving in the client configuration and verified during the SSL/TLS handshake in order to reduce the risk of leaking sensitive information. The cron jobs update scripts are run regularly, so all the information is sent from Pakit client to the Pakiti server using HTTP POST over HTTPS.
(2) When Pakiti server receives client’s patches information, these data will save in Pakiti DB such as Mysql.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
(3) After receiving information from clients, Pakiti server will make a list on the website.
(4) Up-to-date patches information is provided according to packages repositories or CVEs by cron jobs.
(5) By another way, Pakiti clients do not send information to server directly. They transfer patches information to Nagios this monitoring tool.
(6) When Nagios server catches these patches information, it will send them to Pakiti server.
Figure 4-2 Pakiti environment
.
Pakiti uses a Web page provides a list of the registered systems and the list of the pending patches for them. This helps security staffs to keep multiples machines up-to-date and prevent unpatched machines to be kept silently on the network. In addition,
‧
a security module in Pakiti is able to distinguish security fixes from normal bug fixes/product improvement for all Linux distributions which has packages repositories based on rpm (yum) or dpkg (apt) and has different location for normal and security updates. For Linux distributions based on the RedHat, Pakiti is able to check packages against the Common Vulnerabilities and Exposures (CVEs) [44]. In the next release Linux distros based on SuSE will be also checked. Debian based distros are also a candidate, but Debian currently does not provide approved data in CVE format [41].
CVE (Common Vulnerability and Exposure) is an international security organization, the most credible to expose security weaknesses and publish news. For the moment, CVE cooperates with many global organizations and product manufacturers. CVE is a unified vulnerability number of format and report message from firewall, antivirus software, intrusion detection systems, and system vulnerability scanning tools. Each published weakness has only CVE number (for example, CVE-2008-0234), to ensure this weakness is already identified and described. Each independent weakness number databases are unified with the standard numbers.
By now, Pakiti has been utilized by many organizations in the world especially EGI Computer Security and Incident Response Team (CSIRT) on daily basis. According to the result of the risk assessment, EGI CSIRT uses it to monitor all related sites. When EGI CSIRT finds these sites are running the vulnerable software, they contact site managers and ask to apply the updates immediately. If site managers ignore notifications without updating security patches in time, EGI CSIRT will follow the critical vulnerabilities handling procedure to suspend these sites to avoid unstoppable risks.
Every day the EGI Pakiti server receives more than 2300 reports from EGI
‧
production sites. Only Authorized EGI CSIRT members and site security staffs can check the result through a web interface (https://pakiti.egi.eu/). An alerting email will also be sent to EGI CSIRT if a critical vulnerability has been detected. Until 2012, Pakiti server has collected about 400,000 reports from 22,000 nodes of 335 production sites over 6 months period [45].
Moreover, Pakiti is enough to be integrated into an existing monitoring infrastructure.
There are two ways from Pakiti server receive all information from clients. First is traditional way that the client sends the data directly to the server using HTTPS. Second is the client prints the data to its standard output, to let another monitoring tool such as Nagios [46] transfer the data to the server using another messaging mechanism.