WPA2

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

Ignorance

How to Run a GDPR Project

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 not compliance without the IT team.
    o
  6. The Project Manager – This one needs no explanation
    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!]

Top 10

Froud on Fraud’s Top 10 Cybersecurity Technologies to Implement in 2017

In direct response to a certain organisation’s ‘Top 10 Cyber Security Technologies to Watch in 2017’, [cough, Gartner, cough], I have come up my own list of bleeding edge security technologies that every organisation should spend millions of $/£/€/¥ on.

Yes, even if you don’t MAKE millions, you should borrow the money and buy them anyway.

Being honest, my fight to bring security ‘back to basics’ has failed – despite my enormous 210 person following – so I have decided to sell-out and promote nothing except buzz-phrases and acronyms. You know, like everyone else.

However, I am convinced that if you buy, implement, and actually take these technologies seriously, you can forget the security basics. The combination of these 10, never-seen-before, shiny new objects will provide the silver bullet you’re looking for:

  1. Directorate Approbation Paradigm (DAP) – Historically, achieving ‘management buy-in‘ was the ultimate goal for anyone attempting to implement a security program. Quite rightly, caring about the future of an organisation was considered naive, and proponents of this stone-aged technology were left begging for work on LinkedIn. Some of these poor souls even became CISOs. Now, with DAP technology, every single person in an organisation will take security seriously, even if their bosses don’t!
    o
  2. Command & Control Commission (CCC) – While not strictly a technology the CCC is responsible taking the output from the EIC below, combining it with the DAP above and obtaining the budget to buy everything else on this list. This is the spider in the middle of the web, making sure that all technologies work together. Called ‘governance‘ in the old days, the new CCC is clearly superior given that you’ve never heard of it, and it’s an acronym.
    o
  3. Protocol, Method, & Archetype Orchestrator (PMAO) – Much as leeches were seen as the go-to technology in medieval medicine, ‘policies, procedures and standards‘ were seen as a foundation for every security program. While clearly nothing more than a quaint superstition, they nevertheless laid the groundwork for the PMAO revolution. Imagine it; a series of artefacts designed to record not only an organisation’s entire security culture, but their process knowledge and system baselines as well! No way just policies, procedures and standards could do all of that!
    o
  4. Exposure Investigation & Computation (EIC) – I almost feel sorry for the poor saps who only had the ‘risk assessment‘ process to measure their risk profile. Can you imagine basing you risk treatment and technology purchasing decisions only on expert opinion and business goals!? Instead, EIC, in combination with AI, big data, The Cloud, and fairy dust, can tell you exactly how many millions to spend on technology! No more embarrassing moments when you try to explain to your boss how you tried to save them money by fixing the actual problem! Like people and process could ever be the problem!
    o
  5. Intelligence Preservation Administration Schema (IPAS) – Can you imagine the nerve of the International Standards Organisation when they came up with the Information Security Management System (ISMS)? A so-called ‘framework’ designed for “systematically managing an organization’s sensitive data” with – and you won’t believe this- “a set of policies and procedures”! How naive! Instead, with IPAS, you can basically ignore the hard work and common sense approach to doing security properly and hide behind an expensive appliance with flashing green lights! Blinking green, you know it’s working!
    o
  6. Transformation Regulation Authority (TAR) – Before the advent of TAR technology, organisations across the globe relied on a ‘change control board’ to ensure that unmeasured risk was not introduced into an environment. As yes, once again, actual humans – apparently those with ‘expert’ knowledge – were allowed to determine what was right for the business. A clearer case could not be made to put this in the safe ‘hands’ of technology written by someone else.
    o
  7. Episode Reply & Adversity Restoration (ERAR) – We’ve all seen those commercials from the 50’s where attractive actors extolled the virtues of smoking? Well, ‘incident response & disaster recovery‘ were just as misleading, and just as dangerous! Like anything involving people and process could possibly help you stay in business! ERAR on the other hand, will not only detect bad things happening, it will keep your business up and running! Surely THAT’S worth a few million all by itself!!
    o
  8. Capital Durability Projection (CDP) – The future of any organisation should never be placed in the hands of those who care. The experiment called corporate social responsibility failed because it was assumed that it’s the people who are the most important aspect of a business. At least now we know it’s money that’s most important, so the old concept of ‘business continuity planning’ can be replaced by EDC and those making the world better with technology. Finally the people can be safely ignored.
    o
  9. Asset Management (AM) – This is one aspect of security where technology is actually sadly lacking. Asset management is the centre of everything, and without it, no other aspect can be truly be done well. Spreadsheets just don’t cut it, and no GRC that I’ve seen gives asset management its due. This much change, even in The Cloud.
    o
  10. Continuous Compliance Validation (CCV) – This is an idea whose time has come, it’s about time technology provides a REAL solution to overly manual processes.

All facetiousness aside, I am a huge fan of technology. Or more accurately, I am a huge fan of the appropriate application of technology. If you buy something based on anything other than 1) the results of your risk assessment, and 2) answers to the RIGHT questions, you have no business being in charge of a budget.

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