The 3 Ways GRC tools are holding you back

The job of GRC teams is getting harder. They’re overworked, under pressure and taking on increasing responsibility. Then they have added regulatory demands from governments, agencies, and trade groups. And the traditional GRC tools that they rely on aren’t making things any easier.

GRC teams are dealing with ever more inbound demands for security information and metrics from a burgeoning list of stakeholders – from regulators and auditors who can levy a hefty fine if they find the security programme (or the security information presented) is inadequate, or investors who will withhold M&A activity if they find issues in security.

These requests are often urgent, with regulators demanding ever-faster turnaround. The head of GRC at an American bank told us that a Middle Eastern regulator recently asked them to fill out a 200-point questionnaire in just two days. Needless to say, the team lost sleep those two days as they hustled to meet the deadline.

Perhaps more worrying than the volume of demands from regulators, is that requests are becoming harder to address. To illustrate, instead of asking whether you have an endpoint detection and response solution, Singapore’s Notice 655 Requirements for Cyber Hygiene for Banks (effective August 2020) requires banks to attest to having EDR deployed and operational on every asset. That’s a big ask of any enterprise to know all its assets, let alone whether a tool is switched on and operational, and have that level of detailed insight always up-to-date, to be able to report accurately.

And regulators are just part of the problem – risk assessments, auditors and frankly any other stakeholders are all asking questions and sending requests to the GRC teams, all in an uncoordinated fashion. In turn, GRC teams are under increasing pressure to meet all demands. The most worrying aspect is that the constant pressure and strain has a detrimental effect on the people and processes, which in turn affects the quality of the reporting. 

There is a solution though – organisations can help GRC teams meet these increasing demands by automating the process of creating visibility, measurement and reporting. The offset of this solution is that traditional GRC tools don’t have the required automated and data-driven capabilities.

Traditional GRC Tools are Inadequate

While GRC teams have GRC tools, these typically fail to provide the necessary insight to address regulators’ demands. Although GRC tools are designed to manage policies, they are less able to provide hard, data-driven evidence that these policies are being followed. GRC tools most commonly rely on qualitative questionnaires to provide evidence of compliance, rather than a derivation of the true state of security risk from instrumentation. They may capture quantitative data analysis, but this data must be input manually, potentially resulting in human error and bias. GRC tools have not traditionally been designed to ingest large data volumes from hundreds of tools and manage data, while maintaining performance and usability, and have instead needed to manage the inability to scale through data sampling. Additionally, aligning the measurements to the business/organisational structure is also a major challenge.

Instead, GRC teams are forced to go to the security tools and security operations teams, who in turn gather this information manually – not ideal when your security team is already swamped by the everyday blocking-and-tackling they must do against cyber threats. Because the security team is usually firefighting security issues, addressing requests from GRC overloads them, burning time, energy and emotional capacity. Recent research finds that security teams spend 36% of their time on collecting metrics and the number is increasing (Source: Panaseer Security Leader’s Peer Report, 2019). Essentially, that’s a lot of dollars lost. 

In today’s environment with scarce, expensive security resources, organisations cannot afford to distract their security operations teams. Yet that’s precisely what happens. The GRC team in your organisation is hard-pressed to get the answers they need in a timely fashion. What’s worse, when they do get information, they’re not confident it’s complete or accurate – nobody wants to stand behind the data. According to a Panaseer commissioned research, 89% of large enterprises have concerns based on lack of visibility and insight into trusted data.

Here are three reasons GRC teams are hamstrung to get the job done.

1. Lack of accurate asset inventory

In order to determine whether devices are well managed and have proper controls, your organisation must first know exactly what devices you have. You need an accurate, up-to-date inventory to understand control gaps, vulnerabilities, endpoint security, privileged access, identity and access, patching as well as application security and user awareness issues.

The configuration management database (CMDB) is often touted as the golden source of information about all the devices an organisation runs, whether they’re laptops, servers, virtual devices or containers. However, the hard truth is that CMDBs are never complete and accurate because they’re dependant on manual processes.

Whilst asset discovery tools exist to scan the organisation’s network to find new devices, this process doesn’t lead to a complete inventory for many reasons. Manual configuration of where and when to scan can miss sections of the network. Assets that are not online during the scan can be missed. Firewalls can block scanners. Agent-based reporting requires agents to have been deployed correctly and comprehensively.

Manual processes exist to document other asset types, such as databases and applications, and link them together to create relationships between applications and the supporting infrastructure. Populating the CMDB with business context is another challenge. These manual processes are inaccurate and error-prone, increasing the likelihood that people will fail to complete the tasks necessary to keep the system up-to-date. 

As a result, many organisations decide not to use the CMDB as a complete golden source, but rather as a repository of just business-critical apps and infrastructure. In fact, security teams in some organisations maintain their own list of inventory, in conflict with IT teams, which leads to arguments and more time wasted. This diminishes the value of the CMDB in providing comprehensive visibility.

As organisations increasingly adopt Internet of Things (IoT) devices, organisations wishing to track these devices using the CMDB face additional challenges due to the large numbers of devices that continuously come on and offline. And cloud environments add another level of complexity to this problem. 

The CIS Critical Security Control Number 1 is device inventory. You can’t have visibility into controls or understand how to remediate vulnerabilities and the priorities for remediation if you don’t understand your inventory. Insufficient asset visibility impedes full understanding of your cybersecurity posture and improvement of that posture within complex and fragmented environments. 

2. Inability to validate controls

With GDPR, regulators have shown that they are willing to be lenient on organisations that have experienced security breaches if they can demonstrate that they had reasonable security measures in place and were taking due care in protecting the personal information of their customers. 

Currently, there’s no quick way to see whether all reasonable controls have been applied at any given point in time. Each individual control technology, such as EDR, can only report on what it knows. You need a second source to uncover unknown assets. The analysts that pull together the control information may not consider this verification piece. If they do, they must correlate data from multiple sources. Yet they typically don’t have the tools to do so efficiently.

Additionally, many organizations assume that control configurations remain constant. But controls can drift for many reasons, including manual configuration errors, a firewall rule change that prevents the device from accessing the update server, or updates that don’t install correctly as the overwhelmed security teams ignore error reports.

Even if you determine whether a device has a control, you don’t know whether those controls are available, configured properly and switched on. And more tools do not equal greater visibility.  An overabundance of tools and controls may give your company false confidence in your security posture. 

3. GRC tools don’t have access to the right data

Many organizations employ GRC tools to establish a common foundation for managing policies, controls, risks, assessments and deficiencies across an organization. However, these tools are manually driven. You have to type in the data that comes from all of your controls and tools which makes it difficult to get complete and accurate data into these tools. 

Traditional GRC solutions designed to oversee risk management and compliance programs in today’s complex environments do not provide the continuous monitoring and automation controls necessary for proactive and continuous risk identification, prioritisation and remediation. In fact, research leaders like Gartner have predicted that GRC is coming to an end.

In addition, IoT sensors and endpoints are currently being built into a growing range of systems, and a range of smart appliances inside the office. Because these systems rarely consider security a core requirement, they introduce greater risk and increase the importance of controls and mitigations to address these risks.

Change is swift and continuous

Without a full inventory of technical assets and clear, precise, quantitative data about security control deployment, security leaders will doubt the trustworthiness of their data. Time wasted on inefficient manual data collection and reporting processes often result in incomplete, siloed assessments and an incomplete picture of the overall security posture.

Conventional GRC tools offer an internal framework of controls that ensure each area of governance, risk and compliance is being addressed. However, in today’s era, we need integrated solutions that aren’t just focused on internal controls but are designed to mitigate cybersecurity risk as part of a holistic approach.

While your organisation is swimming in data about your devices and controls, all this data won’t do you any good in helping you address regulators requests unless you have visibility into it.

In the next post in this series, we’ll discuss a solution that makes it quick and easy for GRC teams to gain access to all the data they need to meet regulators’ demands.

If you’ve got questions about anything in this post, feel free to get in touch on Twitter, Linkedin or email to carry on the conversation.