OWASP Top 10 2017: Logging & Monitoring Makes the Hall of Shame

Fact #1: There is no effective incident response without logging and monitoring;

Fact #2: There is no effective disaster recovery without incident response; and

Fact #3: There is no effective business continuity without disaster recovery.

Therefore logging and monitoring should be a fundamental aspect of every security program, regardless of organisation size. So why is it performed so universally poorly? Don’t organisations want to stay in business?!

It’s not like EVERY STANDARD ON THE PLANET has it as a prerequisite! Well, except for these obscure ones:

  • ISO 27001 – A.12.4 Logging and monitoring
  • COBIT – F.10 Monitoring and Alert Services for Security-related Events
  • NIST – Anomalies and Events (DE.AE)
  • PCI DSS – Requirement 10: Track and monitor all access to network resources and cardholder data
  • …and so on

So you can imagine my surprise and delight when OWASP – more commonly known for coding vulnerabilities – singled this out as one of their Top 10 for 2017. Yes, it barely snuck in at number 10, but there it is, finally in the light of day.

Unfortunately, OWASP isn’t exactly up there with the NISTs of the world, so the importance of this is probably lost on most. I mean, the DSS uses [loosely] the OWASP Top 10 as one of its “industry accepted best practice” providers, which is actually why a lot of people have even heard of OWASP in the first place.

So now what? What difference is this going to make?

Well, very little probably, if you don’t understand now just how important centralised logging and monitoring is, you probably never will. If you’re in a position where this makes a difference (you’re in technology or cybersecurity) then the only time your organisation will care is when your business suffers a loss. Then I’m sure you’ll start to care as you’re updating your CV/resume.

Honestly, I really don’t know where I’m going with blog. It was either write about this or the bloody GDPR again. But it’s really the privacy regulations that are beginning to drive things like this forward. Record keeping, data breach notifications, accountability and so on all have an enormous impact in how we will be running our businesses and logging is intrinsic to them all.

In my consulting practice I very rarely use the word ‘recommend’, and I try never to mention the names of security control vendors except as examples. So while the due diligence is yours in terms of finding the right logging solution for your organisation’s needs, I HIGHLY recommend that you start looking.

I’m sure there’s some out there, but I’ve yet to see one argument for not performing logging and monitoring, and I’m willing to bet there are no valid ones. The problem, like most things in security these days is that the name is just not sexy enough. Perhaps if we include in a brand new acronym like ‘Episode Reply & Adversity Restoration (ERAR)’ as I did in Froud on Fraud’s Top 10 Cybersecurity Technologies to Implement in 2017 it would get more attention?

Whatever it takes…

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

Security Good Practices

When Security Good Practices Aren’t Good Enough

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;
  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;
  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.);
  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
  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!]


WPA2 / KRACK, and the Coming Storm of Marketing BS!

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!]

CISO Hierarchy

To Whom Should the CISO Report?

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 on 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, they 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 CSOs 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.
  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.

Don’t be Loonquawl.

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

Babel Fish

Risk Register: The Only Way to Talk to the Board

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!]