The answer, as any good consultant will tell you, is; “That depends.”
Usually that’s a our way of saying we don’t know the answer, but then again, we don’t have to, we’re consultants, and it’s up to you to tell us more so we can now go get the answer for you.
Like most things, GRC must start with a definition in order to apply context, and according to my old friend Wikipedia, GRC is “… the umbrella term covering an organization’s approach across these three areas.”
Which tells us absolutely nothing, so now we have to break it down:
- Governance – Per my Security Core Concept 4: Governance & Change Control, governance is “…where the IT and business sides have conversations.”
o
- Risk [Management] – “…is the set of processes through which management identifies, analyses, and, where necessary, responds appropriately to risks that might adversely affect realisation of the organisation’s business objectives.”
o
- Compliance – “…means conforming with stated requirements (defined for example in laws, regulations, contracts, strategies and policies)“
Hopefully you are asking yourself why these 3 things were ever apart in the first place for us to even need GRC to bring them together. Done properly, Risk Management is owned by Governance, who have already taken compliance into account while designing their overarching security framework. In other words, if Governance had been doing their job correctly, the way they approach risk management would spit compliance out the back end.
To understand why this is not the case in an overwhelming percentage of businesses, is to get back to how security is viewed in the first place; 1) Governance does not exist, or if it does, it has no authority, 2) Risk Management is woefully inadequate, and is certainly nowhere near the old Plan > Do > Check > Act (PDCA) cycle, and 3) Compliance is seen as an annual project and not part of Business-as-Usual.
Despite the fact that GRC is a term that should be redundant, it is seen as a goal in and of itself, and in my view, may detract from the business’s true end goal; Staying in business responsibly, with IT/IS as enablers. The 4 Foundations of Security, and the 6 Security Core Concepts lay down some of the groundwork necessary to design an effective security framework, but neither these, nor GRC really get to the detail of how you begin this process.
You should start with an inventory of your assets, ALL of them. i.e. Asset Management.
There are a significant number of GRC tools and applications out there, and while I’m sure their intentions are good, they fall a long way short of providing the functionality necessary to do GRC well.
For a start, how can any GRC tool not begin with Asset Management, and I don’t just mean input from vulnerability scans, or network enumeration tools, which are only a small part of what asset management entails. Assets are not just network devices and servers, assets are applications, processes, people, locations and so on, and without a good understanding of what these are, how can you perform a risk assessment, or monitoring, or incident response, or disaster recovery, or…..
True asset management will include all the following, and no GRC tool I know of can do it all;
- Front-End, Off-Line Audit and Data Collection Tool – inputting the information into the GRC tool is a laborious process, and not all information can be gathered while online. An offline assessment tool should be configured to run both your asset data collection processes, as well as any compliance process that you are subject to (PCI for example). This offline tool can be used by external auditors, and internal auditors alike to build the full asset picture;
- Integration of System Settings Policies – your policies will dictate your minimum security standards; passwords, access control, logging etc.;
- Integration of Data Classification Policies – if your systems are to be configured differently for different data classification levels, this will need to be defined;
- Network Enumeration & Network Mapping – accept feeds from network mapping and enumeration tools in order to a) find and make initial stab at node identification, and b) gather any other ad hoc information available;
- Vulnerability Scanning – accept feeds from scanning tools to ensure that a) all systems are covered in the scans, and b) systems meet both policy and security minimums. Ideally, the GRC tool would also feed into the scanning tools to provide up-to-date scan profiles, and exception rules;
- Automated Collection of Validation Evidence – PCI requires an annual validation of compliance, and only against a sample of systems. Security done correctly will have continuous compliance (i.e. near real-time), and automated validation of requirements (access control, passwords, logging etc). This could be achieved by either server based agents, or integration with AD/LDAP for credentialed remote procedure calls;
- Baselined System Profiles – it is not enough to know the OS, IP, Hostname, location, owner etc (the usual asset management minimums), you should have record of it’s patch level, running services, listening ports, disk space, memory, even temperature. A baselined system can then report against ANY anomalies;
- Firewall & Router Ruleset Validation – if you can feed a firewall or router ruleset into this system, you can a) compare it to the known business justifications, but you can also compare it to the system profiles to ensure you have no rules without corresponding business processes, running services on systems without corresponding rules, insecure services and so on. Ideally, you could even create and maintain your network diagrams from this;
- Change Control & Trouble Ticketing – The change control process should feed into the ‘GRC’ tool to ensure that all monitoring and alerting mechanisms are up to date, and not triggering false positives. Alerts FROM the GRC tool should automatically create trouble tickets based on a the data classification, system ‘sensitivity’/priority;
- Ease of Use – there is no point have ANY system or process that is too difficult to set-up, or impossible to maintain.
There are two main ways GRC vendors get you to use their product; 1) they ‘give’ you the software to use as part of a consultancy engagement, then charge you licensing fees if you want to keep the product after the engagement is complete, and 2) sell you the product, set it up for free (or a nominal charge), then hope you need them to come back and engage them as a managed service provider for ongoing maintenance.
I’m not saying either of these is bad, you just need to decide EXACTLY what it is you want from your GRC tool and perform your due diligence accordingly.
No GRC tool can do everything I described, so you either must buy several different systems and integrate them yourselves, or forget the GRC tool and run the above functionality in an operations centre.
Call it GRC if you want, but it’s not security until it’s simple enough to implement, and cost-effective enough to add real business value.
Do your due diligence before you buy anything, and again, if you need help, ask.
[If you liked this article, please share! Want more like it, subscribe!]
