There's a skill that every experienced cybersecurity specialist develops.
But it's not taught in any training course.
Doublespeak.
Meaning - deliberately euphemistic, ambiguous, or obscure language.
It can come in the form of answering a different question from the one asked.
Or the ability to say something which can be interpreted in entirely contradictory ways - depending on the listener's biases.
Doublespeak can be a valuable defence.
But it usually obscures an inconvenient situation that needs addressing.
Last week, I experienced both.
---
Early in the week, I was helping a customer track down a suspected data leak.
The directors of the business asked - Is access to our data secure?
It is a simple, closed question.
A yes or no answer would suffice.
But - that's impossible.
Think of all the hundreds of people who have access...
From all the different devices...
With all the different situations and contexts surrounding their use...
Is there one that could be exploited or used in a novel way to gain access?
Maybe.
Answering in absolutes is impossible.
So, it was time to deploy doublespeak.
> Question: Is access to our data secure?
>
> Answer: We've undertaken the following actions:
> 1. Scoped to people with access to the data
> 2. Checked audit logs
> 3. ...
> We have not found anything anomalous or concerning.
This type of response isn't unique to cybersecurity.
You will find it in any due diligence process, whether buying a house, a business or starting a new project.
---
The second instance of doublespeak came later in the week.
It related to a vulnerability assessment that we had conducted.
Most of the vulnerabilities centred around a web server and a name service that appeared unsupported - with critical exploits in the wild.
At Fresh Security, we're always careful not to start these conversations from a we-are-right-you-are-wrong stance.
There are reasons and business decisions that can create this result.
So we're open to being told - That's a false positive or accepted risk.
In this case, we started with a request.
> Request: Please review the report and - as a priority - work with your supplier to address the vulnerabilities detected in the web server and name service.
>
> Supplier's response: Thank you for the detailed report.
> 1. We use long-term support, so you can't tell if we have patched or not.
> 2. Most of the web server modules marked as vulnerable aren't installed.
> 3. The name service is only used internally.
> 4. Blocking plaintext passwords and requiring MFA is a political decision. Users don't have to use them.
To a hurried reader - everything is in order.
The systems are safe.
Everyone is happy.
This is the power of doublespeak.
A closer look shows a different picture.
> 1. We use long-term support, so you can't tell if we have patched or not.
This is one of the situations where false positives can creep into vulnerability reports.
So I'm ready to receive higher accuracy data to remove the noise...
> 2. Most of the web server modules marked as vulnerable aren't installed.
"Most of the modules..."
And the ones that are installed... have they been updated?
It turned out the answer was - No.
They were critically vulnerable.
> 3. The name service is only used internally.
Great. That's the design intent, but...
Why can I access it from across the internet?
And the software version used is definitely not supported.
There is no long-term support for this version.
> 4. Blocking plaintext passwords and requiring MFA is a political decision. Users don't have to use them.
I hear what you're saying, but this is not an opinion.
This is a prerequisite for maintaining our customer's cyber insurance policy.
Over several days and many emails, the customer reached a secure state.
Patches were applied.
False positives marked.
Firewall rules updated.
And risks accepted.
---
Doublespeak is a necessary evil to answer oversimplified, large-scale, closed questions.
But at a small, specific scale, it just creates problems for the future.