How avoiding system crash’s after patching

The IT security is getting a lot of attention nowadays. That is a great move but is it the only way to use tools which are watching everything what’s going on in the system landscape? Are they addressing the real problem? Might it not be better to start as the first at the starting line instead from the box behind the race field? More small and easy tasks are helping as well and reducing the work load in monitoring the systems afterwards. You can following every professional standard your IT knows of in keeping your system safe and up-to-date - and still be ending in a fatal crash.

We are putting you on the real starting line and helping you acting instead of reacting by avoiding any crash related to patching. Let’s walk through the example of the Equifax data breach at 2017 where ignoring an easy task of less than an hour caused a loss of more than 650 Mio US$.



Data breach disaster

As it is still some time ago but the settlement of the Equifax data breach disaster is just happening now. Let’s take that as an example how the IT security world looks like still now. Believing that the blame of a single person shows how far Equifax was at the time from adopting good security practices throughout their teams. The core error was to have a security process that relies on one individual rather than to share the security responsibility across teams, starting with developers.

The Equifax report findings also describe an “execution gap between IT policy development and operation”. This information leads to a picture of Equifax running siloed engineering, operations and security teams. They did not integrate operational or security practices into their development workflows or application lifecycles. These are the core issues which DevSecOps aims to solve, by shifting much of the security testing into the development process allowing vulnerabilities in code and open source libraries to be identified and fixing as early and as quickly as possible. The security responsibilities are shared across *all* developers, and security tests are baked into all stages throughout the development workflow. This is a real contrast to how Equifax relied on a single member of staff. Let’s use good DevSecOps practices to implement techniques which are helping to avoid security gaps.

Actions to take during development

  • Development: If the application code was still being actively developed, development teams would be locally developing, building and testing the application. Integrating security testing to identify vulnerable dependencies would flag issues, making it clear to the teams of developers that the new vulnerability exists as well as offering automated remediation advice.
  • CI:Any new build run by a CI server would automatically test application dependencies as a task. This would immediately flag the new vulnerability, breaking the CI job and forcing a remediation action before continuing.
  • Monitoring: Whether or not applications are being actively developed or not, if they’re running in production they should be actively monitored. Any new vulnerabilities that are disclosed could then be dealt with immediately. Notifications would be sent to development teams to fix the vulnerabilities.
  • Runtime: Using runtime security tools, any abnormalities in behavior or vulnerable function invocations would immediately be flagged allowing teams to react to security incidents as they happen.

Is that enough? What’s going in production?

If all those actions and tools are in place why there is still a high chance to see successful cyber-attacks. A lot of easy detectable issues might be fixed. But now the systems are in real world running 24/7 and hit by an exponential increase of cyber-attacks year over year. So the DevSecOps teams are still discovering issues and creating patches. What is happening there? Every day new patches are getting created by different vendors. Keeping up with that amount of updates without having processes or patching tools in place in a normal staffed IT department is a real challenge. Even though assuming there are tools a lot of patches are still not done right away. They are rolled out much later or not at all.

Why that???

Let’s go to the crowd, ask a simple question and watch out to the answers!!

“How long do you wait until you update your systems with the latest patch?”

Answer 1

“I've upgraded Java in the past and got locked out of my switch management. However, if there is a critical vulnerability that is being addressed, you are almost compelled to update! Very frustrating. This is why we should have a world policy to cut the gonads off hackers who actually do any real damage to systems they do not manage.

I usually wait at least a week or 2 to make sure the masses don't have problems with them. Much like the recent update that causes a lot of inadvertent Blue screens.”

Answer 2

“Usually after 1 week in our own company and one week later at our customers networks. We want to test/verify/check/debug it first in our own place before we bring it to our customers

One week because we look for troubles others have first.”

Answer 3

“The same day update comes out, or no later than next day. I have an automated system that fetches updates everyday, if available, and deploys them to machines on the network. I don't disturb it with delays, maybe it's risky if update turns out to cause problems, but some updates are critical, especially when it comes to Flash, so hesitation might cause more problems than potential problems with untested update.

Windows updates (WSUS): for workstations immediately after Patch Tuesday, for servers usually within a month.Java, Flash and others: almost never.. at least not automated. We definitely need to look into that.”

Conclusion

More than 90% of all users are waiting a week or longer to patch the latest versions. Why? They do not want to be the first ones to fix the problems of new patches. But as soon they know the hackers knows as well……. Do they have tools to keep track on patches which could help? Could not the same happen as in the Equifax example by still working like this? Waiting that long time in a constantly changing world is not one of the greatest ideas.

The Solution: Predictive patch management

Patches are obviously a crucial part of cyber security, but actually applying them can be tedious, time-consuming and disruptive to the business. That's possibly why Equifax chose to patch its systems reactively rather than proactively, and why it had numerous different groups responsible for it.

Using a predictive automated patch management tool can greatly speed up the application of important fixes and take the headache out of validating them. In addition, it prevents IT from having to reactively apply patches, improving the company's overall security by automatically deploying them with minimal human interaction.

Monax4U offers a predictive Patching platform for Security Updates. As Google tells you in real time how to avoid traffic and when to start as well we do it for patches. Our AI analyses every update prior to the roll out and tells you exactly how to update and when it is the best time to start.