Category: Governance

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;

  1. 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;
  2. Integration of System Settings Policies – your policies will dictate your minimum security standards; passwords, access control, logging etc.;
  3. Integration of Data Classification Policies – if your systems are to be configured differently for different data classification levels, this will need to be defined;
  4. 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;
  5. 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;
  6. 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;
  7. 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;
  8. 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;
  9. 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;
  10. 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!]

With number 6, I completed my Security Core Concept series:

  1. Security Core Concept 1: Risk Assessment / Business Impact Analysis
    • Management buy-in
    • Examine your business processes 
    • Valuate and prioritise your data assets 
  2. Security Core Concept 2: Security Control Choice & Implementation
    • Perform gap analysis to determine control weaknesses
    • Mitigate control gaps based on priority
    • Think twice before throwing technology at a gap, perform robust vendor diligence if you do buy anything
  3. Security Core Concept 3: Security Management Systems
    • Make sure your controls are working
    • Begin control optimisation and measurement
    • Begin PDCA cycle 
  4. Security Core Concept 4: Governance & Change Control
    • Management buy-in
    • Interdepartmental co-operation and communication
    • Manage all business process and changes
  5. Security Core Concept 5: Incident Response (IR) & Disaster Recovery (DR)
    • Know what your baselines are
    • Standardise, centralise, and monitor
    • Test it, test it again, and keep testing it until everyone knows their part 
  6. Security Core Concept 6: Business Continuity Management (BCM) & Business As Usual (BAU)
    • Management buy-in (yes, that’s the THIRD time I’ve said that)
    • The goal is not security, it’s staying in business securely
    • BAU is where the true value of the core concepts is realised

…and have hopefully expressed in enough detail, the advantages of not only each of these steps, but of a security program ‘done right’.

What I have only alluded to, but will now examine in greater detail, is how the 6 Core Concepts make any regulation / standard / framework related to data security an afterthought.  Not that they aren’t useful, nor can they be ignored, but you’d already be ‘compliant’ with them.  The concepts themselves have been around for generations, and there are many treatises on each and every one.  There are even entire institutions dedicated to perfecting single concepts, but it’s only when you combine them all in a manner appropriate to YOUR business do they make sense.

I’m also talking about the fact that not one regulation the world-over goes deeper, and/or broader in their data security requirements, than you need to go for your business. They can’t, as the very names ‘standard’ and ‘framework’ automatically preclude, provide complete relevance to your organisation.  Nor can they possibly cover every nuance of every business type, sector, and culture.

What these regulations are trying to accomplish – but none state this outright – is a shift in culture away from function/profit only, to security enabled function/profit.  All 6 core concepts are basic fundamentals of security, yet are mostly ignored for reasons innumerable.  I hesitate to use the phrase business responsibility – I have enough issues with sounding like a lecturer – but that’s what it amounts to; you are responsible to protect the data in your possession.

But can you imagine going about your business, secure in the knowledge that no matter what security requirement or regulation gets thrown at you, you are already there!  Maybe not entirely, but the adjustments will be minimal, and will never require the level of effort that even PCI requires from you year after year.

In a nutshell;  If you do security properly, you will ALREADY be compliant with the security requirements of PCI / HIPAA / PoPI / SoX / SSAE-16 / GDPR / Swedish Personal Data Act / …and so on!

No more multiple annual audits / assessments (assuming you have some form of GRC tool), you will not only be compliant ALL the time, you can easily VALIDATE your compliance!

But none of this will be possible if your CEO doesn’t believe in it.  One again this phrase applies;

The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter business goal here], it’s the CEOs fault, and no-one else’s.

It does not matter what the goal, from PCI compliance, to great customer service, to an ethical salesforce, to a security culture that enables to business to grow responsibly, it’s the CEO who is responsible. And accountable.

I am pulling the following from where the sun doesn’t shine (no, not Scotland), but I would estimate that any time the CEO spends evangelising an appropriate security culture will be paid back 100-fold in terms of resource / capital / DR cost savings.

And it’s all so simple.  Not easy, but it is simple.

It may take years, even in smaller organisations, but the major costs are all front-loaded, and the long-term savings way in excess of the annual costs associated with constantly reacting.  Security is only effective if it’s mostly pro-active, and that’s exactly what the 6 Core Concepts are designed to do.

Don’t know where to start?

Ask.

[If you liked this article, please share! Want more like it, subscribe!]

You are probably wondering why I have taken a single aspect of the security program; change control, and raised it to the importance of a Core Concept. You are then probably wondering why I placed it under Governance, and not just an ISMS.

If you’re NOT wondering these things, I suspect you are new to security, or a friend of mine who’s reading this just to be nice.

However, if you accept my interpretation of what Governance is, it may make a little more sense; “Governance is where the IT and Business sides have appropriate conversations.” It’s a communication facilitator, where historically the business side rules and the IT side must do as it’s told, often without question.

You must also accept the concept of cybersecurity as a business enabler, and NOT a roadblock to profit or innovation. As I rather facetiously put it in The 6 Security Core Concepts;

Business: “I want this new functionality.”;

Security:“Sure, but do it this way.”

The business side is responsible for maintaining business growth / profit / market standing and a host of other objectives.This is far from easy, so they will do almost anything to meet those goals. It is up to IT and Security to encourage this innovation and out-of-the-box thinking, but do it in such a way as to ensure that the IT and security needs are built in from the beginning.

In a company with a well run Governance program, any ideas the business have will be run by the Governance Committee (or equivalent), which will include at least one, or more likely several members of the IT / Security teams (security, infrastructure, development etc.). The ideas will be discussed, input accepted EQUALLY from all participants, and a specific risk assessment report put together for senior leadership to review.The IT side’s input needs to include not only the risks, but the viability of the concept based on capital cost, resource allocation, outsourcing and so on.

That’s why they are enablers, because they are the ones who put the ideas into practical application. The greatest ideas in the world are useless if they stay on paper, and are potentially destructive if applied incorrectly.

Assuming I’ve made my point on Governance, and that you somewhat agree, I’ll move on to change control…

Change Control is defined by Wikipedia as; …”a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner.”

This needs no simplification, that’s EXACTLY what change control does …if it’s implemented properly. And that’s the issue in many organisations; the concept may be understood, but there are so many exceptions, and / or ways to circumvent the process, that you may as well not have change control at all.

Again, in The 6 Security Core Concepts I said; “If things don’t change, the only increase in security risk is from external sources. The threat landscape changes almost daily, why make things worse by screwing up internally?“

That’s really what it boils down to; known, and acceptable change. If you’re following the Core Concept series, you have:

  1. Given Governance full responsibility and maybe some accountability for the institution and maintenance of the security program;
  2. Performed your Risk Assessment with the full knowledge and blessing from senior leadership;
  3. Made all appropriate adjustments to your processes and infrastructure based on the RA’s finding and accepted priorities, and
  4. Initiated the Check and Act portions of the ISMS function to ensure that the controls work, and are on their way to being optimised

So why would you now undo all of that work by changing something without the Governance committee’s blessing?

Change Control includes EVERYTHING that changes; systems, applications, data stores, patching, policies, procedures, new functionality, people …EVERYTHING.

Of course Governance can turn some changes into operational norms; patching for example. As long as the process for testing new patches, and rolling them out across the enterprise is appropriately formalised, the Governance committee does not have to discuss it.

But what about firewall rule-set changes? The business side is demanding the testing of some new functionality that involves “Turning off the firewalls for a couple of minutes.”? The answer is of course, no, or HELL no to be more precise, but who has the authority to tell the business that? Right, the Governance Committee.

The institution of a change control culture is painful and slow, as new processes will always meet with resistance. But this is one area where there is no room for half measures, you either do it (and make the negative consequences clear to all), or don’t bother starting.

Finally, I have not gone into any detail of who should actually be ON the Governance committee, and what its charter should be, but that’s because it varies too much between organisations of difference size, complexity, and function. As long as you have equal representation from the IT and business sides, the individuals themselves will make themselves obvious over time. A limited tenure is important though, or the committee may either stagnate, or be controlled by the most forceful individual.

Governance is the heart and soul of your security program, and change control it’s most potent weapon, neither can be ignored.

[If you liked this article, please share! Want more like it, subscribe!]