For the better part of 20 years I have fought with – and sometime against – my clients to help them achieve a particular standards of security. Whether it was PCI, ISO 27001 or any other standard, all I have ever done my whole career is beg my clients to take security a little more seriously. I’d say that I have failed more than I have succeeded, security is just not a priority to most organisations. Kinda like insurance.
Recently however, I have had the distinct pleasure to be told that neither the ISO 2700X standards or NIST Cybersecurity Frameworks are enough, they wanted more. A lot more. In fact, they wanted security so good that they could actually use it as a selling point for their services. For security itself to be a distinct and measurable competitive advantage.
Once the shock wore off, we had to work out how we would actually deliver this. Not only have I never been asked for more than ‘good enough’, I’ve never actually thought about what truly great security looked like. For individual components, yes, but not for a soup-to-nuts security program. And I have certainly not given much thought as to how I would begin the implementation of one. What was the point?
So where did we start? First, we had to address:
- What standard(s) to use for alignment – like it or not, unless you align yourself to industry accepted good practices, it is far more difficult to demonstrate the ‘appropriateness’ of your security program. Any client with regulatory compliance obligations must bear this in mind;
o
- How to determine what ‘great’ looks like – regardless of the request to go above and beyond, the final result has to be achievable. In an industry plagued with pointless technology and buzz-words, the final result has to be both achievable, and justifiable. If you cannot demonstrate a meaningful ROI you have wasted their money;
o
- What’s is foundational, and what is a separate project – In security, there are a number of basics you cannot do without. What I call core concepts. Management buy-in, governance, policy set etc. Then there are things that can begin as a project before consolidating the output with the whole (logging and monitoring, access control etc.);
o
- What are the client’s business goals / principles – as I’ve said too many times; security is only here to enable the business. If a security solution does not map to a goal it’s wrong; and
o
- How long do we have? – The implementation of any security program takes time, and the more you want the longer it takes. The desire for great security has enormous ramifications on resources and capital expenditure, and absolutely cannot be rushed. The resulting program must not only be sustainable, but it has to be embedded in the culture. We’re talking years, not months, and this must be understood at all levels.
You will notice however that at no point were we concerned with technology. Yes, technology will be enormously important – there can be no great without automation – but technology choices are driven by the processes they are meant to enhance, not a solution by themselves. Besides, it’s always the functional requirements you define first as you have no idea who’s going to be managing it yet.
So we ended up going with a combination of ISO 27001 and the NIST Cybersecurity Framework (v1.1), but we mapped these to what we considered to be the most logical groupings encompassing a full security program. Governance, Policy Set, Risk Management, Asset Management and so on. There are 18 of them.
But even this combination could only ever represent average, as ‘compliance’ with either standard is achievable long before you could be considered secure. So then we had to define a scale where average was where it should be, in the middle, and ‘great’ went up from there. We went with the ages old Capability Maturity Model (CMM), then mapped all of things we believe represent each level. ‘Defined’ = average.
For example, this is what Governance looked like:
The are simply no standards or documents for what happens next. The client has to understand what each of the groupings means, then they have to choose how far up the scale they wish to go. This is a long conversation, and if the results of this conversation aren’t understood at the Board level, we’re already derailed.
There are also many dependencies to consider. You can’t have great vulnerability management without very mature asset management, or business continuity without top notch incident response for example.
And above all, if the implementation of the program is not simple, with clear direction and guidance, the people who have to do the work will never get on board. Nor will they ever be able to manage it after we’re gone.
Honestly, I have no idea how this is going to end up, I’m in new territory for the first time in many years. This is also the first blog I think I’ve written where I’m not either trying to help, or bitching about someone/something.
I just thought I’d share something positive for a change, and I look forward to sharing my numerous mistakes and lessons learned! 🙂
[If you liked this article, please share! Want more like it, subscribe!]
