Critical Updates for IT Systems

Compliance Patch Level The author of this report has been tasked with discussing the overall subject of patch compliance level. Indeed, the pros and cons of using the patch compliance level framework will be assessed. There will also be an assessment of several critical things such as the patch compliance level of a given patch, what level of patch compliance is safe and what needs to be considered when evaluating the current patch compliance level.

Patching is very much a security-related matter and helps both system and network administrators to keep their systems completely up-to-date and as safe as possible from vulnerabilities and hacking attacks. Not applying and installing needed patches to software such as operating systems, firmware, device drivers, databases and so forth can leave an enterprise information technology environment susceptible to attack.

While the deployment of patches should be planned and deployed carefully, it is very important to deploy them immediately and completely and the entirety of the process and progress should be monitored. Analysis To be sure, it is insanely important for computer hardware and software to be as updated and modernized as possible so as to protect computer systems and data from hackers. However, not all patches are safe or complete and indeed some are actually hazardous to install.

On the other hand, many to most patches should be installed right away without fail. While patches should generally be installed and kept up with fervor, every patch to a system needs to be assessed and contemplated before it is applied to an IT framework lest it create more problems than it solves. Even information technology professionals can get a little desensitized to all the patches and updates that are applied to their system.

There are many government agencies that are literally still running Windows XP, the Internal Revenue Service among them. However, even the most complacent information technology professional will get rocked a little bit when they learn that a pervasive protocol like Secure Socket Layer (SSL) gets hacked. Precisely that was revealed when news about "HeartBleed" came out in the news (Codenomicon, 2015). Given that, patches should generally be installed right away and the patch compliance level of said patches needs to be closely monitored.

Even so, just installing patches without inspecting them first can lead to headaches and other problems. At the same time, having a spate of vulnerabilities can lead to a frenetic situation for an information technology professional. A real-world example of this was realized when Java had a string of related yet different vulnerabilities that came out into the public eye in early 2013. As described by Tech Republic, even with the massively publicized issues, there are a lot of companies that just are not keeping up.

For example, Tech Republic assessed roughly six thousand organizations and found that roughly forty percent did not have the important and recent patches that they probably should have. As such, their patch compliance level was/is obviously very poor (Reenen, 2013). As already noted, however, patches are not always what they seem and they are not always the solution to a problem.

This could be because the patch is not applicable, it could be because it is not needed or it could mean that the patch may not meet the proper standards to deploy into an information technology hardware and/or software workspace. However, this is extremely rare and patches should generally be applied immediately upon release (SANS, 2015).

One upside to a patch compliance level system is that patches can be assessed and analyzed based on whether they fix the problem they purport to fix, whether the patch would create any new problems and so forth. Once that is figured out, the patch can be deployed and it can be verified that end users are accepting the patch as they should be. Once it is verified a patch should be installed, it is extremely important that this happen as soon as possible (Lavasoft, 2013).

One downside to a patch compliance system is that even the most careful audit of a patch, what is meant to do and so forth may not be enough to catch all potential problems. In short, ensuring patch compliance does not mean the problems will go away if the patch was not complete and/or did not address the true root of the problem. If the patch does not address the actual and entire problem, no amount of patch compliance percentage will fix all of the problems.

As mentioned before, even gold-standard encryptions standards like SSL can fall victim to a hack and there is often no telling how long it went on unabated before the problem was caught and what else might still be happening (Chan, 2004; Codenomicon, 2015). A pro-to doing patch compliance is that it can be linked and joined with a partnerships with the software vendor themselves.

For example, if a company is using the Oracle 10g platform, they can work directly with Oracle when it comes to software patches including why they are needed, how complete they are, whether there are other outstanding issues and so forth. They can also assist when it comes to the best ways to get the proper level of patch compliance on all of the relevant systems. The level of support rendered by vendors can vary greatly. This is true even for a single product.

Indeed, a fee might be necessary to get direct support and this is more likely to be the case the older a software suite is and how long it has been since it was installed and deployed (Oracle, 2015). The downside to such arrangements is that, unfortunately, companies may not be as forthright and honest about what they know and do not know.

For example, it would be interesting to know how much of a gap (if any) existed between the time HeartBleed came to light and when the leadership behind SSL actually came clean and did something about it. Even worse, it could be that the SSL power collective was completely unaware and had to be told of the issue by someone else. Regardless, the details probably don't favor the SSL powerbrokers because not knowing is bad but so is knowing something and not going public (Codenomicon, 2015).

Even an immediate revelation creates a question of how the SSL management could make such an egregious error and how long the vulnerability was present before it was caught. Even so, patches should generally be deployed so that as much of the risk as possible can be fettered out and stamped out (Chan, 2004). A pro of a software patch compliance system is that plenty of third party experts exist that can review things for themselves and offer their own assertions.

A con that exists is that not all of those sources know the full and complete story and they are much more likely to get important details wrong (or omit them entirely) since they obviously would know the software as well as someone who is personally part of the company that regulates the protocol, language, software or hardware. After all, a person may think they are an expert on Java and they may catch most things (JPF, 2015).

However, Oracle would (and should) know more than anyone as they are the company that owns the rights and the power when it comes to Java. Given the above, it is important to include information from the software vendor themselves as well as information from the outside so that the most completely picture possible is painted and portrayed. This allows for a more complete picture and definition of whether a patch passes muster and thus should be deployed.

Once again, patch compliance is important but it is not a cure-all (Chan, 2004; Oracle, 2015). Regardless, one pro of a patch compliance system is that there can be a final testing of the patch before it is fully deployed but after all other relevant details have been discovered. Getting it out there and getting the patch compliance at a high percentage is very important but it needs to be tested first.

A downside to this part of patch compliance level management is that it is not always possible to replicate the production environment when it comes to testing. Even so, the production and primary environment should mirror the test environment as much as is reasonably possible. This heightens the chance that problems with the patch that are compliance- or operations-related will be identifiable before the patch is put into production rather than after the fact.

One pro-when it comes to patch compliance level is that the implications of deploying a patch can usually be figured out in advance based on the prior steps mentioned (Microsoft, 2006). However, there can always be issues and problems that are not known until it is too late. However, massive and seismic complications are typically rare and thus should not generally present an issue (Chan, 2004).

A con of the patch compliance level management process is that having disparate and different people involved in the process can lead to disconnect between these peoples. For example if team builds computer workstations and a different team manages them after that, those teams might not be on the same page when it comes to the "base" installation and this would include the patches that are installed.

If someone, for example, is building workstations off of the first build or service pack of an operating system but a second one comes out, not only should the team for deployed computers be installing the second service pack for the existing workstations but the building team should be loading that service pack as well. The same thing goes for patches (Ping-Ju, Straub & Liang, 2015).

When the HeartBleed fix came out, any information technology person worth their salt would know that both existing systems should have the patch but also that new systems would need to have that patch as well, without question (Codenomicon, 2015; Ping-Ju, Straub & Liang, 2015).

The point is that to have a software patch compliance program that is effective, everyone involved in the process needs to be using the same process, the same set of patches and so forth unless there is a definite and defined reason to deviate from the norm (Ping-Ju, Straub & Liang, 2015).

Not only should existing workstations and systems get the patch pushed out so as to get the patch compliance level up as soon as possible but there should also be a system in place that makes the new systems deployed into the network fully patched before they are ever touched by an end-user. Doing otherwise would actually lead to a fall in compliance patch levels and that cannot be allowed to happen (Chan, 2004). Given the above, one would want to define what a proper patch compliance level is.

Indeed, there can and should be a monitoring of how many of the systems on the network have applied the patch. For those systems that have not had the patch installed, there should eventually be on why those systems are not patched yet. In a nutshell, patch compliance is the depth and breadth that the patch has reached. The lesser the patch compliance, the more vulnerable the system would tend to be. For example, if the HeartBleed patch is on ninety-five percent of systems, then that is quite good.

Having a high patch compliance is more important when the update is "emergency" in nature (Dadzie, 2005). Precisely an instance happened like this from Microsoft in August 2015 (Microsoft, 2015). However, that other five percent is extremely vulnerable and it relates to a protocol that is extensively used. In any event, machines that are not patched need to be isolated and patch as soon as possible so as to protect the wider network.

The needed and necessary patch compliance level would probably vary based on the patch in question and the systems involved, but a level of 80 to 90% would seem to be a bare minimum for regular to moderately important patches. For things like HeartBleed and the like, there should be a forced install with no further actions allowed until the patch is in place. The use of a "push" to systems and a reboot within a certain amount of time (e.g.

2-3 hours) is a good way to get a patch done and completed. The entire process can be automated and forced out in short order if the situation calls for it. For less important matters, those sort of updates can be scheduled in advance (Manage Engine, 2015). Either way, patch compliance level should be monitored and more forceful measures should be used if the level does not get very close to one hundred percent within a few days. People take vacations and the like so there will always be stragglers.

However, people that are skipping or otherwise avoiding the update need to be nagged and prodded until they comply (Dadzie, 2005). The importance and gravity of patch compliance and patches in general cannot be over-stated. While patches are not of much use when information technology professionals are poorly trained and ill-prepared for attacks and system holes, patches can indeed do a very good job of doing a lot of the work of information security professionals for them. Examples of information technology professionals acting ineffectually and poorly are not hard to find.

Just a few examples are the recent to fairly recent TJX, Target, Home Depot and Office of Personnel Management (OPM) hacks that have occurred in the United States (Fowler, 2015). With the TJX hack, the retail giant was using a wireless encryption standard in a very careless way. First of all, they were transmitting credit card and other confidential information over their wireless network. On its face, that is less than wise as their stores should absolutely be using wired Ethernet unless there is a practical or systemic reason why not.

When it comes to a brick and mortar store, such a reasons would be hard to find as running some cable would not be difficult. It would seem that TJX was cutting corners or they were just lazy. However, the bigger problem with the TJX debacle was that the wireless encryption they were using was WEP, which was compromised long before they stopped using it and were caught with a compromised system.

A really silly detail about the TJS hack is that they were considering a network upgrade before the proverbial floodgates burst ("TJX Contemplated," 2007). The Target and Home Depot hacks seemed to have been a situation where vendor and other accounts in the system were not configured properly and this surely comes down to lack of competent staff ("With 56 Million," 2014). However, it would seem that even the federal government is immune when it comes to gross incompetence.

As mentioned before, Windows XP is still being used on many Internal Revenue Service computers and that alone is a huge red flag. Indeed, official Microsoft Support for that operating ended some time ago and that would mean any newly discovered vulnerabilities with XP (which is a thirteen-year-old operating system) are not being fixed unless the federal government and Microsoft have an under-the-table support deal, which is unlikely (Willis, 2015).

Even more concerning was the recent revelation that the fingerprint and Social Security numbers of millions of government employees were snapped up by a devious hacker (Levine & Date, 2015). Beyond that, no less than Hillary Clinton was using a private email server set up by one of her aides.

Not to diminish the aide's computer expertise without full knowledge of what he knows or does not know, but the chances that the server was as secure as a government-ran system is unlikely and even the latter would seem to potentially be insufficient to protect the data (Enloe, 2015). Regardless of whose system, protocol or hardware is compromised, there tends to be a domino effect when the system, protocol or hardware in question contains a lot of data that is extremely sensitive, confidential and potentially harmful to people if exposed.

Indeed, no one was hurt or killed when the Target hack occurred but a lot of people's credit card information was exposed. This surely led to at least some fraudulent charges, a lot of new cards being issues with new credit card numbers and so forth. Even with no loss of life, the loss of productivity, inconvenience to the people involved and the damage rendered against Target's name and reputation is gigantic in scope when one seriously considers what happened (Lunden, 2015).

As far as how to truly deal with this problem, solutions would seem to be elusive as it would seem that not even government officials (e.g. Hillary Clinton) or government agencies seem capable of controlling and dealing with their own software security issues and this would surely include software patches and software patch compliance to at least some degree. Even so, a standard of compliance and performance needs to be set and the government should be the "go-to" example of the practice being done right and completely (Raywood, 2009).

Unless or until that occurs, the idea that the government is going to police compliance from businesses and individuals is a bit of a hard pill to swallow. Indeed, it would be like a Drug Enforcement Agency (DEA) agent being a crack addict but yet also arresting people for trafficking, dealing or using crack, all of which are obviously illegal (Enloe, 2015).

When it comes to software patches and hacking in general, it is clear that the United States government is behind the curve and the hackers of the world are clearly winning. The United States government and its agencies need to be modernized, nimble, capable and dynamic. There simply cannot be the lumber bureaucracy that leads to information technology resources festering and remaining out of date.

It is unconscionable for the IRS to still be using Windows XP when there have been four main updates to Windows since XP was released and that does not include service packs or other major updates to Vista, Windows 7, Windows 8 and now Windows 10 (Willis, 2015). To state the obvious, there are some people that are simply oblivious when it comes to keeping systems updated and operating properly.

However, none of those people should be walking the halls of information technology departments in major United States companies or government agencies and there is clearly a lot of incompetent people and/or outdates systems at both (Blue, 2015). Part and parcel of solving this issue is instilling the proper habits and frameworks at the college and even the high school level. Proper computing and online habits should be part of all information technology classes no matter what level they are taught at.

It should be drilled into the minds of young information technology gurus and fans that keeping computers updated and modernized is less a matter of cost and more a matter of what can go horribly wrong is a system is not fully capable of being protected against modern threats. Curriculums for people that major in information technology, computer science and so forth need to contain the necessary and important lessons that all information technology professionals should know.

Beyond that, the general education that all students take at college should include at least a basic understanding of what to do and what not to do when it comes to owning a maintaining a computer. Whether it be an IT major or a liberal arts major, there needs to be a minimum.