Category: Security Good Practices

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:

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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!]

This is going to be my shortest blog ever, because basically it’s just a warning: IGNORE THE MARKETING BULLSHIT AND THE DOOMSDAY JOURNALISTS!

Every time there is an outbreak of malware, or a new vulnerability exposed, or a protocol deprecated, the marketing departments of every security vendor go into overdrive. Their only goal; to make more money. Not to help, not to provide sound advice so that people don’t make bad decisions based on FUD, and not even because they know what the Hell they’re talking about.

Just money.

And the newspapers do what they do best; create panic with little to no understanding of the subject.

Yes, WPA2 has likely been broken, but because of the integrity of the researcher who discovered it we won’t have any information about it until later today. Which means we currently have no idea of the impact.

Apparently this is the guy you need to be watching; http://www.mathyvanhoef.com/

So here is what I would be doing right now if I were you:

  1. Determine what the impact would be on your organisation is WPA2 were truly broken;
  2. Update EVERY relevant device, as by now most of the bigger manufacturers should have a patch or a workaround;
  3. Tell your entire employee base NOT to panic, but they too should update their home computers (anti-malware etc.), mobile devices and home routers;
  4. Update your incident response plan to cover any issues.

The one thing you should NOT do is be part of the problem! Don’t spread rumours, spread fact, and be part of the SOLUTION! Share this blog if you want, or at least articles like it.

The security industry is rapidly becoming a bunch of used car salesmen, let’s each do our part to get THIS one right.

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

I actually feel kinda silly writing this blog because the answer to the subject question seems so obvious. But even among seasoned cybersecurity professionals, the question of the CISO’s reporting structure has taken on a life of its own. I cannot imagine a more pointless debate.

But, for the sake of argument – and to keep this blog short – let’s assume there are only 2 types of ‘reporting’:

  1. To a direct line manager (Administrative Reporting); and
  2. To the recipients of the CISO’s functional output (Functional Reporting).

The most appropriate example for this – due to it’s many similarities – is Internal Audit (IA). I’ve never seen these folks administratively report to a manager who is not either the Chief Financial Officer (CFO) or the Chief Legal Officer (CLO)/General Counsel (GC). Nor would I ever expect to, as what they do is so well established that no-one questions their hierarchy.

Why is cybersecurity more complicated?

The very concept of IA dictates that their administrative management cannot influence their output in any way. I believe such conflict of interest actually goes against some regulations/legislations. Not only must they have this complete autonomy in the creation of their output, they must have total immunity from any backlash related to its content. Especially from their direct line managers, in whose hands the auditor’s career rests.

Same for the CISO.

For IA, the recipients of the functional output just happen to be their protectors as well; The Board of Directors (or CEO if the BoD does not exist). This ‘dotted-line’ reporting structure allows the auditor’s to report the whole truth to the ultimate decision makers without fear of retribution.

Same for the CISO.

So why is the CISO role so different? Does it really matter to whom they report administratively as long as they have both access to, and the protection of the BoD? Just like IA, the only thing a CISO should have to worry about is their own ability/competence to perform the function. And if, as I HIGHLY recommend, make the CISO role a Board appointment (or don’t bother having one), both the BoD and CISO are fully aware of each other’s responsibilities in this regard.

So if you accept that it’s really only the BoD dotted-line that matters, to whom should the CISO report administratively to help avoid the inevitable politics?

Common CISO Administrative Reporting Structures

  1. Direct to the CEO – This is the ideal of course, as you can usually assume that to have this hands-on approach the CEO takes security seriously. Seriously enough anyway. That said, in this configuration the BoD must take a more active role in order to ensure full CISO independence;
  2. To the CSO – A true CSO will generally have more than just data security as their remit, but CISO and CSO are very often used interchangeably. So depending on what the CSO actually does, this can be a good fit if s/he does not interfere with the CISO’s access to the BoD;
  3. To the CTO – To me this is almost the definition of conflict of interest, this never works even if the BoD dotted-line is in full effect;
  4. Any other member of the C-Level – At this point, the duties of the CISO are so far removed from the knowledge/skill-set of their manager that it almost doesn’t matter which one you choose. This will be ‘administrative-only’ reporting to the nth degree. But as long as the CISO’s relationship with the BoD is healthy, this should not detract from the CISO’s ability to get the job done; and/or
  5. Below C-Level – If the CISO role is more than 2 layers beneath the CEO, don’t bother having one, it’s clear neither the CEO or the BoD gives a damn.

Frankly, the CISO’s reporting structure is irrelevant if you haven’t chosen the right CISO for the right reasons. And AS a CISO, if you had no input to your reporting structure why did you take the job in the first place?

I am reminded of the eternal classic “The Hitchhiker’s Guide to the Galaxy” by Douglas Adams:

“Forty-two!” yelled Loonquawl. “Is that all you’ve got to show for seven and a half million years’ work?”

“I checked it very thoroughly,” said the computer, “and that quite definitely is the answer. I think the problem, to be quite honest with you, is that you’ve never actually known what the question is.”

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

Ever wondered how really effective cybersecurity professionals not only get direct access to the CEO / Board of Directors (BoD), but actually manage to get a budget out of them? Better even than that, they get the entire C-Suite to evangelise the organisation’s security program on their behalf!

It’s quite easy actually, they speak the same language as the CEO / BoD. This is not the language of security, it’s the language of business goals. Or to put it crassly, it’s the language of money.

For example, if you are a CSO / CISO and have reported to your Board how many malware attacks your controls blocked, or how well your firewall is working I’m surprised you still have a job. The vast majority of Board members care nothing for the detail, and frankly, nor should they. As much as I have preached about how the CEO /BoD should care about security, what I’m really saying is that they should at least appear to care.

The only ones who actually care about cybersecurity [for its own sake] are those with a vested interest. Practitioners, consultants, and especially product vendors, all say they are passionate about security. They may well be, but as an analogy, are you ever passionate about your car insurance? No, of course not, quite the opposite, you just know you have to have it.

Security is no different to insurance in this respect, it’s not like sales or marketing where there is an obvious correlation between the effort and result. With security, the effects are invariably seen only when things have gone horribly wrong. Even then, the Board don’t care about security itself, they care about how the failure of security affected the bottom line. Coincidently, this is often when they start asking all the wrong questions and throw money at the symptoms not the root cause. Like hiring a CISO for example.

Even as one of those with a direct vested interest in security, I am absolutely fine with this. I know my place, which is to provide a direct link from the individual IT assets to the business’s goals. If I can’t show how a risk to the assets at my level can affect an entire business at theirs, how can I possible expect them to understand what I’m talking about? And to be clear, it’s my job to perform this translation, not theirs.

The Babel Fish that performs this modern day miracle? The Risk Register.

I’d say about 75% of organisations I’ve helped over the years have no risk register at all, 20% have only a business risk register, and the remaining 5% have separate business and IT registers. Not one has a single register that maps the IT risks to the business goals. Not one. Worse is the fact that all of these risk registers were very poorly conceived and resulting in nothing but poor decision-making.

The single risk register I’m talking about is the one where anyone can view their part of it and determine exactly how their actions can affect the whole. Does this mythical creature even exist!?

So how DO you map assets to business goals?

Like everything else in security, it’s actually simple. Bloody difficult, but simple.

Step 1: Do Asset Management Properly – I can already exclude every organisation I worked with, and I’ve only heard rumours of this being done well. Basically, if you don’t know what you’ve got, you can’t manage it, let alone perform any step that follows;

Step 2: Map Your Assets to Your Business Processes – I am often amazed that asset dependencies are not fully mapped. How do you perform change control properly if you have no idea how you’re impacting the business process that the changing assets support? How can you prioritise assets? Dependencies, inter-dependencies and data flows must be fully defined;

Step 3: Perform a Business Impact Analysis on Every Business Processes – If you can’t even take a stab at valuing each of your business processes, how can you prioritise them? Whether you can directly quantify them (e.g. revenue) or only qualify them (e.g. HR) you have to know what they are worth to you;

Step 4: Map Your Business Processes to Your Business Goals – This can be tricky as you’re going from the 100% technical to the 100% business. But if you have no idea whether or not your goals are achievable with your current assets, they aren’t very good goals, are they?

In theory and for example, you now know that if a certain database is lost; a) the business process that will fail, b) the potential losses, and c) the goals that may now become unachievable. Not every goal obviously (e.g. M&A), but definitely the ones that got you this far.

So, when you next talk to the BoD, you can show them the possible impact of not spending money on database redundancy where it hurts the most

Their pockets.

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

First: If you think that as a cybersecurity ‘expert’ I know how to run a GDPR project a) you can’t be that familiar with GDPR, and b) you have not read any of my previous blogs.

Second: If you have read my previous blogs and clicked into this blog hoping to get advice on how to run a GDPR project, you weren’t ‘listening’. At most I am a first conversation and a pointer to your next.

Then again, would you be reading this right now if the title was; “GDPR: No Idea What I’m Doing, But Here’s Yet Another Opinion.”?

So like everyone else on this little regulatory bandwagon – with the possible exception of privacy lawyers – all I have are opinions, and what I hope is a little common sense. Here in the UK for example, the GDPR is just an expansion of the Data Protection Act of 1998, which in turn was a consolidation of previous acts, some dating back to 1984. And if that’s not enough, ‘The Guidelines on the Protection of Privacy and Transborder Flows of Personal Data‘ published in 1980 by the Organisation for Economic Co-operation & Development (OECD) contained many of the basic tenets upon which the GDPR is predicated:

  1. Collection Limitation Principle;
  2. Data Quality Principle;
  3. Purpose Specification Principle;
  4. Use Limitation Principle;
  5. Security Safeguards Principle …and so on.

That means privacy lawyers have had 37 years to get good at this stuff and pass it on to all fledgling privacy lawyers. The rest of us may have some knowledge, but this will only ever be enough to overlap with the legal profession. This overlap will then hopefully enable us to translate the lawyer’s legalese into a language relevant to our respective departments. This is actually critical to GDPR implementation as lawyers do NOT have the final say, it will always be a negotiation.

Why is this not enough? Why would any non-lawyer even want the task of applying GDPR’s Recitals and Articles into a business’s specific context? Do you think you’ll make enough money to retire before you’re discovered as an incompetent? I have never seen a clearer case for a team effort.

The GDPR Implementation Team

  1. The Lawyer – For some reason everyone assumes that when I say lawyers should lead the effort, they come back with expressions of horror. “Lawyers can’t project manage!”, “Lawyers can’t operationalise GDPR!” and so on. By lead, I mean setting the goals and objectives. You know, leading, not managing. Only lawyers are truly qualified to provide proper context, so they should make their case first;
    o
  2. The Salesman – Like it or not, GDPR will have an impact on your business. Leave the sales team out and you have ruined any chance you have of making that impact a positive one;
    o
  3. The Marketer – As with the salesman, there is no reason that ‘compliance’ with GDPR can’t have a positive impact on an organisation, even its bottom line. The marketing / PR spin is the face of your efforts;
    o
  4. The People Person – Sounds better than the HR person, but I have never understood why these folks have so little part in projects like this. They are the Keepers of the Culture, use them;
    o
  5. The Technologist – While there is very little directly related to technology in the GDPR, it’s clear that technology has a huge role to play in its implementation. There is no compliance without the IT team;
    o
  6. The Project Manager – This one needs no explanation; and
    o
  7. The Cyber-Peep – Where there is data and technology, there is a need for security wrappers, but this role is no more critical than the others. That’s like saying the wheels are the most important part of a car.

And yes, if there are other departments they should be included too. Privacy cannot be siloed.

What’s missing is something to bring it all together. If only there was an organisational function that took the input from all of these departments and stakeholders and formulated a plan to accomplish the business’s goals! Wait, sounds a lot like Governance, doesn’t it?

It’s already far too late to be proactive, but you have until the 25th of May, 2018 to appear to be proactive. Get your team together and don’t waste this opportunity.

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