Compliant - but not secure
Many organisations use compliance as drivers for their security activities, and in some cases it could be argued that security really wouldn’t get a great deal of buy in at all from the corporate powers without the presence of compliance demanding that measures exist. Whilst compliance & legislation outlines some ground rules of security, I believe there are two key points in the nature of enforcing compliance that ultimately - and ironically - means that correct level of security is not achieved following a compliance mandate alone.
The first of these lies in the fact that compliance, such as PCI:DSS, is written by an external party with protection of information that is specific to them – i.e. what they see as ‘their’ intellectual property or risk, if you will. So the issue this raises is that someone else is dictating levels of security to satisfy their data protection requirements – not you and nor your data. This was highlighted recently when, in discussion with a business security head in the finance vertical, it was identified that comparing the configuration and patching levels of a test server, one following a compliance program and the other a vulnerability programme, still left the test device open to vulnerabilities even though it met the requirements of compliance.
The second point follows on directly from the first: someone else is telling you to what to do, and how to spend hard earned revenue, in exchange for no real tangible operational improvement or increase in turnover. This in turn creates an immediate negative feeling towards having to pay out to satisfy someone else’s demands, especially with the limited education or help to show to the internal business powers the importance and rational of security work. Unsurprisingly, this often results in reluctance to provide funding and the resulting measures that are implemented are only there to ‘tick a box’ and likely to be ad hoc, unsustainable solutions. To make things worse, if this wasn't bad enough, the effectiveness and success of the security solutions are then compromised along with the ability to maintain long-term compliance. And then one year later, further investment is required to bring back up the security levels to meet compliance. Again.
In short, following a compliance mandate as the basis of a security strategy is unlikely be effective in delivering the true level of required security. Moreover, board level organisational support and understanding isn't high - security has been begrudgingly implemented. The answer to this, given that the issue of security cannot be ignored, is to develop a strategy determining the security controls of the organisation, involving the business powers to generate greater understanding and buy-in. Using frameworks such as ITIL and ISO, relevant compliance mandates, and spending time to understand the concerns of the business creates the security yardstick from which to measure. Identifying the gaps and requirements in technology, resources and processes is the next step, and the result of this should produce a relevant strategy, understood by the business, able to deliver and maintain the right security levels – oh, and achieving compliance.
