The Problem with Patching is it’s not a Panacea

Remember when it seemed like everyone held his or her breath every Microsoft Patch Tuesday wondering how bad it would be? Unless it’s a pervasive security flaw such as the BASH shell vulnerability (a command line program for UNIX systems/ run on 80 percent of the servers online), which led to the Shellshock attacks, patching isn’t the hair-on-fire exercise it once was. As many companies rushed to address the BASH vulnerability, they found that the patch had it’s own errors and flaws. Companies had to take down their systems as many as four times as each subsequent patch had performance issues or killed system processes. Many became frustrated at the amount of application downtime this caused for key applications run on UNIX. Patching can lead to the discovery of new bugs.

Oracle issues patches once every three months. They let everyone know this is happening. This is about the right cadence for an activity that seems to have moved from being a security issue to a system hygiene task that supports system performance. Vulnerabilities and attack vectors will always be present and historically people have believed that patching is the solution. Patching is an extreme measure that may or may not be successful in blocking an attack or deterring an attacker from going forward.

You may be thinking to yourself, “what about so-called zero-day vulnerabilities?” I used to work with a company called White Hat. They work to find vulnerabilities and understand how long it will take to get them fixed. Sometimes it takes months or in some cases, years before there is a fix. That’s why I don’t believe in patching as a way to increase one’s security posture–it simply takes too long. If you hire White Hat now, they may not find something for years, and then they may have find or build a fix for it.

Security teams have realized that for the attacker, taking advantage of a software vulnerability can happen anywhere in the attack chain of activities but isn’t required to compromise a system. They don’t need to take advantage of a yet to be discovered software vulnerability when they can take advantage of human vulnerabilities to simply hack-the-human to get credentialed access to systems. This reduces the level of expertise the attacker needs. Unless it’s a zero-day vulnerability, there is always a risk that an IPS may alert the security team to the attacker’s presence. It’s also possible for an attacker to use the vulnerability-based attack as a diversion that sucks up valuable time and recourses. This is why the attack vector focus needs to change to an identity behavior-based approach to detection and what’s known as user behavior intelligence.

Perfect programming simply doesn’t exist. As long as humans create computer code, there will always be numerous vulnerabilities created in the code that will never be found. Consider patching an extreme measure that may or may not be successful in blocking a future attack or deterring an attacker from going forward. Don’t rush to patch – look to create a compensating control and perform adequate testing before patching. Do make monitoring user credential activity and the discovery of account take-over and user impersonation a priority for your organization.

Want to see a system that automates the detection of attackers using compromised accounts?  Click the demo button below.