Read Now:  The Ultimate Guide to Linux Patch Management

X

Full-circle Patching: The Impact of Post-Patching Application Testing on Business Continuity and Security

Patch Management Smart Automation

You already know that working in the security operations center (SOC) is incredibly stressful. But do you know exactly how stressful it is? And more importantly, do you know what you can do about it?

According to recent Ponemon research, 78% of employees working on SOC teams say their job is “very painful,” and 75% say increased workload is the reason for their burnout. With long hours and increased responsibilities due to the stress of maintaining cloud, hybrid, and legacy environments, along with remote work and dissolving definitions of network perimeters, many feel the only solution is for their organizations to implement a higher degree of automation to help share the unrealistic workload.

While patching and vulnerability remediation is probably the least glamorous aspect of security operations, it could easily be the simplest, most effective way to prevent a data breach and other serious business consequences: downtimes caused by system failures due to a security vulnerability (as in DoS attacks), not to mention the pricey ransoms hackers demand these days following a data breach.

But what happens when trying to keep up with patching actually increases the risk to your business by causing downtime, like when a patch breaks something? In an ideal world, according to CSO Online, every organization would “test patches before doing wide-scale production deployments and have a back-out plan in case a patch causes problems.”

However, this testing step can add a lot more work—and it won’t find every problem. So if you’re manually rolling out patches, sometimes all you can do is sit back and hope for the best. At least until now.

Now, JetPatch is letting you take back control of the patching process and eliminate stress. We’ve partnered with LoginVSI to offer you a better way to automate testing and reduce the chances of downtime after patching. Let’s see how it works.

The Current Situation

Right now, many organizations are spending a lot of time testing patches in the lab or in the pre-production environment. This is often the best way to ensure that the patch doesn’t impact performance or create errors to the overall system once it’s rolled out live across the entire organization.

This makes sense, since, according to a recent Tripwire article, “Enterprises cannot go about installing patches blindly without understanding potential impacts of the change brought by a patch.”

CSO Online says, “The conventional wisdom is that all patches should be tested across broad swathes of different types of devices and configurations before testing. Only after thorough and complete testing are patches allowed to be deployed.” 

But they also acknowledge that this degree of testing is almost impossible. And even if it were possible, it would massively impact productivity by diverting your security team for long periods of testing. Instead, they recommend choosing “non-critical servers, user workstations and devices [to] be your full-time guinea pigs.” Then, you can test new patches on these devices, and wait a few days to see if something breaks.

However, this kind of testing step adds several problem points within the patch cycle:

Figure 1. Red circles indicate potential trouble spots during the patch cycle.

 

As this diagram illustrates, there are a few potential trouble spots during the patch cycle. Manual testing can be slow, as well as time and resource consuming, and since you’re not testing in the real environment, the results aren’t always clear or decisive. Then, after deploying the patch, there’s a “wait and see” period where you have to hope that the patch hasn’t broken a mission-critical application.

Clearly, pre-deployment testing is not good enough for most organizations. Why?

  • It takes too long to get results (a few days to a week at least).
  • It might not turn up all problems (rare bugs, unusual incident triggers).
  • It may not pick up on performance issues (e.g., just a few seconds longer for a frequently used app can seriously hinder your org’s productivity).
  • It doesn’t lend itself well to automation, since you’re often rolling out and testing manually.

As the Tripwire article points out, “An organization’s ability to thoroughly test patches depends on scale and resources… testing every possible configuration is hard for any organization. As you scale, it becomes impossible. More nodes mean an increase in the number of scenarios that need to be tested. Those considerations can quickly spiral out of control.”

Both because of inherent problems in this test model, as well as because of the time it takes to do it right, many organizations end up skipping the testing phase altogether, which clearly isn’t a good solution either. So how can you stay in control of your patch process? 

That’s where the JetPatch/LoginVSI joint solution comes in, keeping your company secure while saving time and upping your odds of patching success.

The JetPatch/LoginVSI Workflow

JetPatch has partnered with LoginVSI, an industry leader in application testing, to give you an all-in-one tool to test the functionality and performance of the applications post-patching. The joint solution of JetPatch and LoginVSI generates a constant feedback loop that ensures you can take care of pre-deployment testing automatically and get more effective results in much less time.

LoginVSI offers a range of comprehensive testing:

  • Performance and availability – Will the patch slows down your existing workflow?
  • Application load – Can the patch handles usage at scale?
  • Compatibility – Will the patch works with all your existing applications?

Together, JetPatch and LoginVSI deliver a flexible solution that offers you a few different potential scenarios, depending on what works best for your organization:

  • Run application testing in the lab first to predict patching success.
  • Run application testing across your environment after rollout to determine that nothing has been damaged by the patch.

For a 3-minute overview of how it all works, watch our video at https://www.youtube.com/watch?v=1ZgVWy7AWcw

For instance, if you choose to lab-test before rolling out a patch, here’s how it works:

  • JetPatch gathers all the patches needed for your environment.
  • LoginVSI tests patches before rollout and provides you with clear, comprehensive results.
  • LoginVSI test results are fed into JetPatch predictive analytics, giving you a clear picture of potential impacts on your systems.
  • You can then choose which patches to deploy based on these test results.

By combining the automation of JetPatch with the comprehensive application testing of LoginVSI, you add several advantages to your patch cycle while fixing the trouble spots identified above:

Figure 2. Constant feedback loop ensures efficiency and fast turnaround from testing to production

 

The JetPatch/LoginVSI combination also adds app testing functionality— yet another way of showing our commitment to building full automation into the patch cycle. When patching is easier, faster, and more effective, it’s more likely to get done, period.

Talk to us about how to get started automating and streamlining your patching and testing process in minutes.

Shai Toren
Shai Toren
Shai is CEO and co-founder of JetPatch. Former GM at ClearOne, Shai is a proven leader with over 20 years of executive management and technology experience. https://www.linkedin.com/in/shai-toren-a35804/
schedule demoORlearn more
Start Patching the Right Way
Free Trial