Over the course of the last year the word ‘Governance’ appears in no fewer than 26 of my 130-odd posts, and if you have read any of those posts you know how many times it appears in the PCI DSS v3.0.
Going beyond the standard therefore is clearly very simple. HAVE governance and you’re way ahead of the game.
It does however get mentioned in the ‘Information Supplement: Best Practices for Maintaining PCI DSS Compliance‘ released August 2014, when they refer to an “overarching security framework”. You’ve all read that right?
They of course mention the usual suspects; CoBIT, ITIL, ISO 2700 series, and NIST, but quite rightly leave the choice and detail up to you, as well as make the most sensible statement I’ve seen yet coming out from the SSC officially;
“Integrating PCI DSS controls into a larger, common set of security controls is often the easiest path to ongoing PCI DSS compliance. Overarching security frameworks allow security teams to focus on a single target rather than trying to accommodate multiple (and sometimes conflicting) sets of requirements. It also provides for a common set of terms and metrics that can help avoid confusion when articulating security and compliance strategies to key stakeholders. When PCI DSS is integrated into an organization’s overall risk-based security strategy, it makes it easier to incorporate specific PCI DSS activities into the normal day-to-day operations of the security team. This, in turn, helps to ensure these activities are conducted on a regular, ongoing basis, which can make maintaining PCI DSS compliance a much more manageable task.“
But who manages this? There are no governance frameworks that will work without a governance FUNCTION.
The IT Governance Institute’s definition is: “… leadership, organizational structures and processes to ensure that the organisation’s IT sustains and extends the organisation’s strategies and objectives.”
Or to put it my way: “The business side and the IT side having appropriate conversations.” Sounds trite, but this is exactly what is missing in most organisations where the business side dictates the immediate goals while the IT side is left working tactically without any concept of where their actions fit into the whole; i.e. the business’s goals.
But it’s not always the business side’s fault, the IT departments in a lot of organisations start with saying no and work their way up from there. This gives them the reputation of being business-blockers and everyone in their right mind will work around those if they want anything done.
Regardless of fault – there is no room for the blame-game in security – this is easily resolved if both sides place nice and set up some form of governance function. Call it what you will, but it is responsible for the following;
- Business Continuity Management / Plan – As representatives of [almost] all departments, the governance function will be responsible for the development and maintenance of the business continuity processes, which will be owned and ratified by the CEO / BoD.
- Risk Assessment / Business Impact Analysis – it is up to the governance function to ensure that the frequency, scope, and analysis of the RA / BIA processes are in-line with the business goals as handed down by the CEO / BoD
- Vulnerability Management / Risk Register – Unless the function of analysing risk and putting some form of prioritised remediation plan in place is centralised, you can never implement appropriate security.
- Change Control – Number 4 on my list, but EXTREMELY important! As I’ve said many times; If nothing in your environment changes, the only way risk can increase is by a change to the external threat landscape. Your vulnerability management process should take care of the external stuff, which, by strange coincidence, is also managed by governance.
- Vendor Due Diligence / Technology Purchases – Tack-on requirement, but my OCD doesn’t allow for only 4 bullets. That said, both of these item have critical security implications and should have governance oversight.
The composition of the governance function, their charter, and their ongoing processes cannot be dictated by any framework or standard, and must be entirely suited to the organisation in question. Industry sector, political / geographical region, culture and so on all have influence on the final result, so this is not something I can address in a blog.
As usual, I will end this with an ‘if you don’t have the skill-set in-house, go find it’ comment, but when it comes to the development and maintenance of a good security program, nothing has more overarching influence and benefit than governance done well.
‘Simple and appropriate’ is the mantra here, like it is in all things related to information security.