GRC – Governance, Risk, Compliance

Once you decide "YES we want to be more secure"

The way forward is to get serious about Governance, Risk and Compliance (GRC)

which means everything that I have talked about in past posts:

Governance means making Risk Assessments of Data that you have.

And making risk assessments means develop paperwork or a paper trail of all of your IT assets.

This means you need an inventory of all of your assets, both hardware and software. And now it is paramount that you make a comprehensive list... Why?

Because you need to know what you have so that you can set up a patch list. Patch means to upgrade software and hardware (including IoTs - Internet Of Things).

So interesting to note, but PCI compliance  requires inventory management (a list of your devices).

For PCI compliance it is required to keep the PCI machines free from viruses and attacks. But what if the attackers come in from elsewhere? This is the weakness of PCI compliance.

As I have mentioned in my blogpost: Risk Managament has failed us.

This is what a standard Risk Management matrix is where some systems are

classified Low, Med, and High.

The problem with this model is that the low and medium get hacked, and now the attacker comes in from the inside.

The problem is how fast the systems get patched with new vulnerabilities.

As new vulnerabilities get discovered there is a small amount of time, sometimes 3-6 months which the well funded hacker can purchase a relatively easy hack into your network. Once inside the attacker can perform more functions until they can get to what you are defending (sometimes only your reputation).

So as I mentioned in my blogpost at

If the patch list is extensive then new monthly patches become difficult to implement since one has to test them first. We can't just assume the patch is good with all of our current applications and install as soon as it is available, we have to test first. Testing takes time and resources. And here is where the OODA loop explains our dilemma as the defense team (or otherwise known as blue team)

The Cybersecurity OODA Loop is Observe, Orient, Decide, Act diagram explains exactly the problems of defense reactions with patching.  It has to do with our time delay of when we have the patches and when they are tested, then finally installed.

If you think this is not a problem just do a little research, where Tripwire noted that there were 188 security patches in a year, or 15 patches in a month (for 2015)

But 188 security patches are just the ones security folks are interested in, as you can see in the diagram above (from Tripwire report) the full number of patches are in the thousands for the year.  The problem is especially acute for Adobe Flash and Java as they have serious vulnerabilities and require patching monthly.  So one really does have to make choices as to what patch to install first.

One can see that as Tripwire says "Patch Fatigue" is real. And there is no slowing down with security and functionality patches. IT departments can get fatigued and then patches get installed infrequently and with a serious time lag. This is why hackers are successful, as many IT departments are not organizationally capable of handling this issue.


But this is _why_ we are here. We can help you devise Governance tricks of the trade to ensure that only a small time delay is allowed.

Contact us to discuss your Governance - Risk - Compliance needs.