Reactions and Advice following the 2018 Scalar Security Study
- March 2, 2018
Just like the three previous years, the 2018 Scalar Security Study and the resulting Cyber Security Readiness of Canadian Organizations Report didn’t disappoint. Statistics such as 87 percent of responding organizations had suffered a breach during the previous 12 months is a simple indicator that Canadian organizations are truly struggling to protect themselves. While the report outlined several cybersecurity weaknesses, organizational blind spots and lessons learned, I walked away with three big themes and have some advice on how Canadian organizations can respond to them.
Given the growth in infrastructure, high profile vulnerabilities and malware, this is not a huge surprise. Organizations are overwhelmed with vulnerabilities and Security and IT have some natural tension on how and when to remediate them. Security teams want the most severe vulnerabilities remediated immediately but IT teams want infrastructure and applications to be available. With the volume of vulnerabilities typically found with each scan, the goals of neither team are actually realistic.
The only way to get this problem solved is to better connect security and IT data. Security understands the severity of each vulnerability from the CVSS score. IT understands what each IP address inside their organization actually is. Getting this data correlated on the same platform enables Security and IT teams to know which vulnerabilities and systems really matter to their organization, not a generic one. This way Security and IT can reduce the work down to a more realistic number of important vulnerabilities to remediate quickly and save the rest for the next maintenance window.
Since Security and IT teams are don’t understand which vulnerabilities truly expose their infrastructure, it’s no wonder they can’t install security updates and patches quickly enough. When workers are overwhelmed with data, they generally put it into the best data repository at everyone’s fingertips – a spreadsheet. And when it comes time to communicate with other teams about this data, they generally use the best communication tool at everyone’s fingertips – email. This is exactly how most organizations are handling the response to vulnerabilities. They take vulnerability data, put it in a spreadsheet and then email different team members to get it into patching cycle during a maintenance window.
This is a process that is ripe for using automation, especially if you have heeded the advice in the first theme where you get security and IT data onto the same platform. You should be able to automatically prioritize which systems have the most important vulnerabilities to solve. And then automatically assign the remediation task to the right person and track every step in between. A truly efficient vulnerability response process would also automatically trigger a rescan of the remediated system for a closed-loop process.
Just like the manual processes outlined for security updates and patching, the incident response process for most organizations is managed through spreadsheets and emails. I’d argue that this process is even more complex than they process for remediating vulnerabilities. The vulnerability response process involves a limited set of tools and actions. You might have one or sometimes multiple vulnerability scanners and then the action taken is to patch the affected system at some point. Security incident response planning is exponentially different. Most organizations have dozens of security tools that can create an alert and each type of alert has its own set of actions for investigation and response. In some cases, organizations may have some of these processes outlined in a security “runbook”. They are typically static documents, if available at all.
There’s a better way to plan for security incident response. First, just like in the vulnerability scenario outlined earlier, get security and IT data onto the same platform. Any alert from security tools should be correlated with IT data to prioritize which problems are most important to solve first based on business context. Next, digitize the security runbook Take the most typical parts of the runbook and create online workflows for them. For example, for a malware outbreak, the right tasks should be automatically sent to the right people as part of the runbook to solve the problem. And when all of the tasks are tracked in a single system, you can look for places to improve and update.
Blog originally featured here.