The security team members at ACME were scurrying around the office. The CISO was blasting orders, and the sysadmins were trying to follow it. The aftermath of a cyber-attack had left them all speechless, stressed, and overworked. Unlike typical malware/ransomware, the attack occurred from a simple-yet-critical misconfiguration. It led to a sensitive data leak of project and staff data.
Like their counterparts and many other large companies, ACME also used JIRA for project management. Within JIRA’s filters and dashboards, JIRA provides some visibility options to the user, like “All Users” and “Everyone,” respectively. These filter options would typically mean “sharing info with all users or everyone within the organization,” Instead, this shared information publicly.
This dangerous scenario resulted from an authorization misconfiguration in JIRA’s Global permissions settings.
The security team collectively never thought beyond the traditional definition of a vulnerability. But some members did think about it. But no one was ready to listen, and they were left helpless.
John, the sysadmin, wasn’t sure if the company’s security measures were enough. He followed the news of cyber-attacks, and plenty of research suggested that misconfigurations would be the next reason for cyber-attacks, and he was worried.
“What about the misconfigurations in the devices?” he had asked the CISO. And he was promptly shut down and told not to: “create problems as we have enough on our plate, besides only the vulnerabilities with CVE matter, right?”. It wasn’t the fault of the CISO either. Their team was understaffed and overworked, and they had enough on their plate, and the CISO was only prioritizing. But actions have consequences and
“Not my problem” became “everybody’s problem.”
The company here isn’t real, but the attack sure is. The JIRA misconfiguration in 2019 led to one of the world’s largest sensitive data leaks. Unlike other attacks caused by “traditional vulnerabilities,” a simple misconfiguration was its root cause, and this was just the beginning.
The Fundamental Problem
The story, as mentioned earlier, while loosely fictional, is eerily real. It happens every day in every security team of every organization. Probably yours, too.
Not thinking beyond the traditional vulnerability definition led to attacks from threats that weren’t within the scope.
Cyber-criminals are not limited to attacking the traditional way, and they find ingenious methods to exploit weaknesses and penetrate the defense of an organization. The traditional definition of vulnerability limits the scope and the vision of the security team and hinders them in preventing attacks.
Our preconceived notion of “vulnerability is a CVE” limits our ability to prevent attacks, and we need to break this notion within us and redefine the vulnerability definition.
Understanding The Traditional Vulnerability Definition:
Understanding the traditional definition of a vulnerability by breaking it down to its core can help us create a new, broader definition that has a bigger scope and coverage.
Different regulatory bodies define vulnerability differently. And generally,
“Vulnerabilities are bugs in software code that can be taken advantage of.”
After a bug is recognized as a vulnerability, it is registered as a CVE/NVD and assigned a CVSS score.
The National Institute of Standards and Technology (NIST) defines vulnerability as
“Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.”
This definition is more precise, covers a broader range of issues, provides clarity on the topic, and is much closer to a vulnerability’s ideal definition.
But, these definitions, while great, miss out on some critical entities that should be considered. Some of these entities do not have a CVE, yet they cause cyber-attacks and are a risk to your organization’s infrastructure.
Why do we need to “Redefine Vulnerabilities”?
Would you classify the following as a vulnerability?
• Misconfigurations and missing configurations
• Overlooked or ignored Assets
• Missing encryptions
• Employees with lousy cyber-hygiene practices
On a broader level of scope, they are. But we cannot assign a CVE to these entities, yet the results could be devastating if they are exploited.
Real-life cyber-attacks like the JIRA data leak(caused by misconfiguration) and the Marriott data leak of 2020(caused by user credential privileges)are just a few honourable mentions from a long list of attacks with Vulnerability 2.0 (as we like to call them) at its root cause.
These Vuln 2.0 are not covered in the traditional definition yet are quickly becoming one of the top causes of cyber-attacks. With the exploits from Vuln 2.0 still in their infancy, experts predict misconfigurations to be one of the leading causes of cyber-attacks soon.
The need to adapt to the changing landscape of these cyber threats necessitates redefining the vulnerability definition!
Redefining the Vulnerability Definition
A definition that incorporates the traditional vulnerabilities and the newer Vuln 2.0 must be set. A holistic definition that isn’t stuffed with technicalities and is simple enough to understand.
“Anything that puts your device or your organization at risk.”
This definition might sound vague, but it is true. It’s a definition that evolves as time passes and new vulnerabilities are discovered, surging in scope and not limited by technicalities.
If the CISOs and the sysadmins work with this definition in their minds, the organization’s defense would be nearly unbreachable. It would help exponentially minimize the attack surface and drastically reduce the chances of cyberattacks.
Additionally, this definition also brings the IT and security teams closer. It makes them take up the responsibility of preventing attacks and not push it on each other. As their scope broadens, they realize that their actions can also be the cause of attacks.
The Final Solution
“The need to adapt to the changing landscape of these cyber-threats necessitates redefining the vulnerability definition.”
The mindset of “vulnerability is a CVE” was only a part of the fundamental problem. Redefining the vulnerability definition is only the 1st step of the final solution.
Since the new vulnerability definition broadens our view, we need a revamped vulnerability management process that incorporates many new techniques and features.
- Broader and Redefined Vulnerability Definition: The obvious point we have talked about previously. Vulnerability management is not just mitigating CVEs; it must actively look for other security risks that can be exploited by attackers and rapidly mitigate them.
This can only be performed with newer and modern scanners that are reworked and revamped to identify newer security risks and accurately detect them. - Continuity and Automation in Vulnerability Detection and Mitigation: The number of vulnerabilities only rises, and automation and continuity of vulnerability management have become the key to preventing attacks. By making the scanning and remediation process automated and continuous, the chance of threat actors exploiting vulnerabilities reduces, and your job of protecting your organization becomes a little less stressful.
Automation of scanning and remediation reduces the load on your team, and you can breathe a sigh of relief with the improved security it provides.
3. Integrated Approach to Mitigating Security Risks:
Continuity and automation cannot be achieved with multiple siloed solutions. Hald-baked integrations can have a negative effect on your vulnerability management process and can expose you to cyberattacks. Smooth integration is critical for effective and rapid vulnerability detection and mitigation.
It can only be achieved by integrating individual processes(or products) into a single, continuous, and unified platform/process.
These steps become the instrument of change for your vulnerability management process and can help improve your organization’s defense.
As the vulnerability definition changes, the vulnerability management process must also evolve. By integrating new practices like system hardening and employing risk-based vulnerability assessment, we can make our system and our organization safer.
Conclusion
The imaginary attack at ACME wasn’t the fault of the CISO or the sysadmins under him individually. Attacks result from the collective failure of a team and the product they use, and blaming each other can only break the team’s spirit and nothing else.
Is the number of attacks prevented considered a performance metric for a sysadmin during their appraisal? Preventing cyber-attacks is a stressful job without tangible returns, but a difficult job nonetheless.
Attackers aren’t limited to exploiting “traditional vulnerabilities,” and to face these potential threats, we must expand our definition of vulnerability, improve the collaboration between IT and security teams, and bring them closer.