topic Re: Some thoughts on Vulnerability Management in Tech Talk

Some thoughts on Vulnerability Management

Gary — Sun, 08 Oct 2017 17:51:18 GMT

Some thoughts on vulnerablitiy management that some may find interesting over on Cybrary.

https://www.cybrary.it/0p3n/thoughts-vulnerability-management/

Kind Regrads

Gary

Re: Some thoughts on Vulnerability Management

Caute_cautim — Sun, 08 Oct 2017 19:22:14 GMT

Why do we make it a wackamole situation, constantly when dealing with vulnerabilities. Especially when at least 41% according to cybersecurity reports indicates that they are insider issues due to human error or misconfiguration. Therefore if an organisation has a policy of only applying patches to their systems once every two months and if necessary applying critical ones, due to reports in the public, which indicate attacks are under way. Isn't it about time, we looked at automation, and set up Standard Operating Environments (SOEs), for each platform or component and have a system regularly passively scan for for compliance and misconfiguration issues. Treat systems on a lifecycle basis from activation to deactivation, and ensure consistency across the board, ensuring patching is applied in good time on a regular basis consistently Only apply human input, when a reboot is required in alignment with change management processes. We have the capabilities, apply the policy and automate and reduce your risks profiles.

Re: Some thoughts on Vulnerability Management

TzarasanatoR — Sun, 08 Oct 2017 19:27:50 GMT

The CVSS calculator can help organzations prioritize remediation of vulnerabilities. It also has the benefit of being well documented.

Re: Some thoughts on Vulnerability Management

Robert — Sun, 08 Oct 2017 19:39:49 GMT

All too often it's treated as a numbers game chasing numbers doesn't drive the correct behaviour.

There needs to be more awareness of context to target high risk systems.

Re: Some thoughts on Vulnerability Management

Caute_cautim — Sun, 08 Oct 2017 19:55:26 GMT

Totally, agree, some organisations don't even know what their actual inventory is or whether they are fully licensed or supported. It you are serious about priotectng the organisation, whether you use existing infrastructure or the cloud, you have to apply the appropriate approach, consistent with your risk appetite. How many have actually worked out their own risk appetite? What they can afford to sacrifice or is it a case of cyber security insurance has my organisation covered? My brand and reputation is protected, I think?

@Robert wrote:
All too often it's treated as a numbers game chasing numbers doesn't drive the correct behaviour.

There needs to be more awareness of context to target high risk systems.

Re: Some thoughts on Vulnerability Management

DHerrmann — Sun, 08 Oct 2017 20:44:46 GMT

Follow the SANS Top 20, and you'll be OK. #1 in that list is an inventory of devices; #2 is a software inventory.

Like sports, if you have excellent fundamentals, the other stuff usually falls in line.

Re: Some thoughts on Vulnerability Management

kimberdray — Thu, 12 Oct 2017 04:09:06 GMT

Implementing the SANS /CIS Critical Security Controls (CSC) is admittedly challenging in many environments. You cannot protect or proactively anticipate your risks without knowledge of what exists and where; the foundations of CSC 1 and 2.

Since we define vulnerabilities as known badness that exists in our applications or services, another approach would be to focus on security by design.

For various reasons, security is often an afterthought and vulnerability and risk assessment can take place far too late in the process.

The OWASP Top 10 2013 (present) https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project and pending 2017 RC2 provide a list of known web application security risks that can raise awareness with your project teams and implementors but I lean towards the SANS Web Application Checklist: https://software-security.sans.org/resources/swat for a more proactive security planning checklist.

Re: Some thoughts on Vulnerability Management

RJRHODES — Thu, 12 Oct 2017 12:01:41 GMT

Couldn't agree more on making sure you're handling the fundamentals. One of the biggest probelms I've seen is folks that say they patch their systems, yet have no real process to ensure they are doing it on a regular basis. Without proper management oversight, expectations (based on risk), and consequences for not following the process, bad things happen.

Re: Some thoughts on Vulnerability Management

BrianKunick — Fri, 13 Oct 2017 21:02:54 GMT

If organizations are waiting two months to patch vulnerable systems, they are giving hackers two months head start in compromising those systems. If the organizations fall under compliance requirements, they have only 30 days to fully remediate critical vulnerabilities.

Thirty days is a long time, too long, to wait for patching critical vulnerabilities. The thirty day window is imposed to force those companies who are slow to respond from getting hurt from their own inaction. Your enterprise should have a defined policy to term limit unpatched vulnerabilities.

You can bet that if they are waiting thirty days or more to patch, they are not giving any consideration to vulnerabilities experienced by their systems to which no patch exists.

Re: Some thoughts on Vulnerability Management

jrisner1 — Mon, 16 Oct 2017 15:41:44 GMT

I used to work in the banking Industry for a Major Bank and then a Major Credit Union. We would use Shavlik and SCCM to push patches every month when major patches were released. We would also push out-of-band patches when the threat was considered high. It was a major battle and we were always busy but it was a labor of love and a little bit of pride in reaching 98% every month at the bank and 92% every month at the credit union. Once you get a good team together it can go rather smoothly. In order to patch our Tier I apps we would often do them from 12-3am on Sunday Morning and a couple of times went longer. The challenge is getting everything in place and automation plays a big part in making this successful. We were a 10 man team and 5 of those men only did scripting.

Re: Some thoughts on Vulnerability Management

Caute_cautim — Mon, 23 Oct 2017 00:06:07 GMT

A good response, these days, we need to definitely automate, we cannot rely on traditional methods using resources, which are definitely dwindling. Other techniques include BigFix Lifecycle, as you stated in a similar way to Shavalik, and SSCM. The same principles need to be applied to Compliance and baseline policies, which ensure that patches are applied in good time, after sufficient testing and come from a reliable verified source. These would be applied, and rollback available if there were issues and additional manual intervention is required. It in fact is a form of "hygiene" for systems regardless of the underlying Operating System and applications used. I know of at least organisation, who has an "n-2" approach this is definitely not the best approach these days, as they themselves missed the original WannaCry attacks, due to the fact good security intelligence was available and they were made away of the forthcoming attack. Fortunately they responded accordingly to notifications and carried out the necesary patching. They were extremely lucky, many others were not.

Re: Some thoughts on Vulnerability Management

Joe_Zajac — Sun, 29 Oct 2017 14:02:54 GMT

Agreed on the numbers game aspect. Keeping the organization secure has to become the main (and only) driver rather than getting the vulnerability off of an audit report, but in 2017, the numbers still seem to take precedence.

Re: Some thoughts on Vulnerability Management

kolobl — Sun, 29 Oct 2017 14:08:44 GMT

I think you are spot on.

Vulnerabilities are more the result of mis-configurations and leaving systems in their default configurations. So, user awareness training for system admins and information users should be prioritise to limit the number of vulnerabilities. In addition, having hardened system images that can be cloned for all new installations and configurations can indeed help in reducing the number of vulnerabilities.

Re: Some thoughts on Vulnerability Management

Allison — Sun, 29 Oct 2017 17:50:21 GMT

We need to go a step further and make vulnerability data more immediately available to systems engineers, proactively engaging them to make remediation a part of their deployment cycles. Vulnerability management does not equal patch management - not all vulnerabilities are addressed by a patch and there are legitimate business reasons for alternate configurations. Technology changes will continue to accelerate and we will continue to fail if we separate those who make security decisions from those who make design decisions. DevOps is all about telemetry so we need to make security requirements and its data a part of development and delivery pipelines.

Re: Some thoughts on Vulnerability Management

DGreen — Sun, 29 Oct 2017 19:44:53 GMT

Good article. These thoughts run through my head when prioritizing vulnerabilities. Sometimes it's difficult for senior management to understand the difference between a vendor rated critical vulnerability with an exploit versus without. Instead of being surgical when resource constraints are an issue we are often forced to take a broad approach of all this or all that (unless you change the vendor rating).

Re: Some thoughts on Vulnerability Management

Caute_cautim — Sun, 29 Oct 2017 20:12:47 GMT

I agree: However the security community and many vendors are actively collaborating towards the CVE approach: https://cve.mitre.org/ Which is a standard way of ensuring vulnerabilities are reported and hooked into the vulnerability solutions available on the market.

So to take an example: https://exchange.xforce.ibmcloud.com/vulnerabilities/132756

You will note that the site immediately uses the CVE rating with a CVSS rating along with sufficient information for most users to realise the impact, severity and the potential remedy.

Take the recent "Bad Rabbit" situation: https://exchange.xforce.ibmcloud.com/collection/XFTAS-SI-2017-00001-Bad-Rabbit-51701e9c25aaaf7e02b19fa6d63ccc80

This is an advisory, so such attacks can provide early notifications of pending issues - something vulnerability scanning and management cannot provide. This is an initiative by IBM, to raise the bar, and ensure people and systems actually collaborate actively, sharing information both in the public and by private groups as required. But at least the information is available in a digestible format for those interested, and also in summary form, which can easily be digested by senior staff as well.

So by using vulnerability scanning and collaborative sharing of information, one can be much be prepared with timely notifications and to follow through to ensure they are protected or at least plan for the worst scenario.

Re: Some thoughts on Vulnerability Management

Yallaen — Sun, 29 Oct 2017 20:53:08 GMT

First, kudos to all who replied on this topic. Your thought processes and ideas on this topic are spot-on. We have in place various methods to make this about risk. The higher the CVE number, the greater the risk of the VULNERABILITY.

I have stressed repeatedly to my students in my classes that the top 1-2 priority should be INVENTORY: Hardware and Software. How do you protect what you don't know about? And what you DO know about, how are you protecting it?

There is a critical position that I feel is missing in this argument/discussion: EXPLOIT-ABILITY! If I have an embedded system that is totally off-network, and it has a high vulnerability, do I stop it from flying/sailing/building/cleaning etc., just because it has a high vulnerability? If the EXPLOITABILITY of the device is LOW, I think the CVE rating should be downgraded. There are products out there that do that. They work in conjunction with industry rated vuln scanners (i.e. Nessus), and re-prioritize the findings to have you focus on those systems that are actually an issue.

Everyone chases the CVE rating or CVSS scores. For the most part, you can safely do that. But as a hacker, do I necessarily want to focus my attention on the High or Critical vulnerabilities, knowing that MOST companies will patch those within 24 hours, or a week?

This is also a mind-set. I have seen this at several Fortune 500 companies, where the cycle of 30 day patching becomes imbedded and though-of as a requirement ("oh, we need a patch, well, we do that every 30 days). That mindset is outdated and wrong.

Re: Some thoughts on Vulnerability Management

Caute_cautim — Sun, 29 Oct 2017 21:04:08 GMT

Excellent: Keep the good work up with your students. Which leads into the subject of "hygiene" - i.e. as you state if you don't know what you are protecting, and it is regularly updated and maintained, then things can leap out of the dark and bite very hard indeed, when you least expect it. This relates closely to Service Management and ITIL practices. Basic "hygiene".

Re: Some thoughts on Vulnerability Management

SecWizz — Mon, 30 Oct 2017 13:20:34 GMT

The 30-day target for applying patches to high risk vulnerabilities is difficult to meet with production service systems. Deciding whether to apply each patch requires understanding the impact to production systems and any interaction with the running configuration. Patches do not always work as expected and patch installation can be complicated for many systems such as DBMS or even high availability network devices. So patches need to be tried first in a staging environment that matches the production environment. Not every one has such an environment. Patch installation instructions need to be bullet proof and account for the specific production service configuration. And guess what, the patch from the vendor may not be available for the particular OS or configuration you use. Or the patch may end up requiring an OS upgrade that necessitates more testing with production services. In a large development and support organization, ticking off all the boxes and getting approval to deploy might take a few more days. So the 30-day target can be a tough one to meet, even for CAT 1 critical vulnerabilities.