Cyber Security

Cyber Security in Plain English

It’s no secret that the infosecurity industry has a love affair with acronyms. EDR, MSSP, IDS, SIEM, AV – these are our ‘solution’ acronyms, with CNA and CNE our advanced attack ‘problem to be solved.’ But what exactly do they all mean? Is it time to decipher the acronyms and eliminate Geek Speak so everyone knows what’s going on?

Why do we love acronyms?

The use of terminology and acronyms are useful to infosecurity insiders for two reasons:

From a board perspective this communication failure adds to the mystique of what is already perceived to be a dark art, which can lead to a lack of effective oversight – or worse, a misalignment between business strategy and the security strategy needed to support the business.

How many reading the opening lines of this article wondered why the solutions had been listed first, before the problems had been addressed? Again, this is representative of a communications failure – the cyber security industry pumps billions of dollars into product, service or solution messaging, specifically designed for one purpose – to sell something.

It’s fair to say that nation-state or criminal threat actors have not gone to similar lengths to advertise their objectives. Hence solution is primary, problem is secondary and not well understood, and all of it is wrapped up in inaccessible terminology and acronyms.

Time to decode

Rather than continue to hide behind three letter acronyms, here’s the ‘problem’ in plain English:

–        CNE: Computer network exploitation. This is stealing a copy of the information held by a company, and could be Intellectual Property theft, merger and acquisition positioning, oil flow data, customer data or staff data.

–        CNA: Computer network attack. This prevents a company from doing business, by wiping hard drives, erasing backups, turning up the steel furnace temperature or closing the gas pipeline valve.

Now apply the ‘Plain English’ exercise to the ‘solution’ codes, and ultimately dispense with the billion-dollar marketing campaigns, and all parties can simply start talking about attack paths instead. Forget acronyms, blinky boxes and ever-increasing metrics – here’s the question the business needs to ask:

“Of all the attack paths currently open to critical assets, which paths need to be effectively monitored and/or shut down?”

In fairness, this question can be difficult to answer as it comes with prerequisites, so let’s decipher it further so there can be no misperception.

The first element is defining what exactly are the critical assets of the business and where they reside. After all, you can’t protect what you don’t know you have. Make sure that there is an inventory of what facilities, systems, and equipment which, if destroyed, degraded, or otherwise rendered unavailable, would affect the reliability or operability of the organisation. In addition this must include the information the company relies on to function – customer data, research and development information, accounts payable, employee records.

The next element is understanding how these assets could be targeted and importantly by whom.  Attackers prefer to take the path of least resistance, making the least effort with the greatest likelihood of success. There may be multiple routes an attacker can take to reach a given critical asset in an organisation. As an example, an attack path may start with an initial user compromise through spear phishing, escalate to the harvesting of legitimate user credentials, and end with the attacker having full access to the critical asset as if they were an employee. Clearly, understanding the full extent of these routes in crucial in determining the appropriate security controls.

The next time the internal security team is looking for budget to protect the organisation, make sure the proposed solution answers the question of which attack paths are open to critical assets, in plain English terms. Before any budget is allocated, or money changes hands, make sure everyone is clear as to what the solution is actually for, and that it is trying to solve a problem that the organisation actually has? Or worse – and we see this time and again with our Incident Response teams in the wild – is it actually solving anything at all? Don’t allow acronyms to confuse the issue – instead demand the cyber security team speak in plain English.

Leave a Reply

Your email address will not be published. Required fields are marked *