Some thoughts on vulnerablitiy management that some may find interesting over on Cybrary.
https://www.cybrary.it/0p3n/thoughts-vulnerability-management/
Kind Regrads
Gary
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.
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.
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.
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.
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.
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.
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.