Unshakeable Salt

I’m not going to pick any political sides in this post, but we need to mention ‘roll your own’ when it comes to security.

Todays news is that one political party has been under a “large sophisticated cyber attack“. This shouldn’t be a surprise to anyone. I’m certain that all the parties in the UK will be under some form of attack the majority of the time. Some will be partially successful, the vast majority will be prevented. Todays was the former, but it has already been confirmed to be just a low level DDOS attack with a side serving of rhetoric.

What’s the issue ?

This issue I have with todays incident lies with the subsequent press release. Please note that I say ‘release’ as in singular, rather than series of releases as part of a cyber response communication plan:

So far as we’re aware none of our information was downloaded and the attack was actually repulsed because we have an effective in-house developed system by people within our own party.

Todays press release regarding the cyber attack on a political party

To reiterate, this was not a sophisticated DDOS attack. It did not even reach the levels to quantify an acknowledgement by the National Cyber Security Centre (NCSC). If it had been, then it would not have been resolved in house. For large scale attacks you need expertise, you need resources and solutions from multiple global partners. Even a minor DDOS attack ( such as purchased DDOS-as-a-service attack ) can not be handled with roll your own solutions.

For security people like myself, communications like the one above are a big red danger flag. It highlights the lack of a suitable vetting process, including the advice and guidance from specialist security resources.

Roll your own

The gripe I have with roll your own security solutions is that they rarely follow a Secure Development Lifecycles (SDLC). In todays delivery focussed world, they are created with agility in mind, but delivered to a Minimum Viable Product. At which point, they are chucked over a wall into the operations space and not progressed.

I’ve touched on SecDevOps & DevSecOps in previous blog posts, but the importance about the SDLC within security engineering is paramount. Organisations wishing introduce new technical controls into their security toybox are recommended to utilise an Enterprise Security Architect. If you have one of those, you can also use them to ensure your security press releases make sense.

Lets have a breakdown of todays press release, through the eyes of a cynical security specialist:

“So far as we’re aware none of our information was downloaded”

So far : we have only looked back 5 minutes

aware : plausible deniability. We have told our security team not to tell us until after we have made this press release

our information : but plenty of yours and other peoples

downloaded : But it may have been changed or deleted ?

“attack was actually repulsed”

Repulsed is a very strange word to use. It’s more military than technical. You repulse an attacking army, but you prevent a cyber attack. Unless of course they prevented the cyber attack with rude, crude or cold responses. ( geeky pun: http error code 530 ‘Site is Frozen’ should be utilised for this)

developed system

It’s been chucked over the fence from development into operation. Past tense, ‘in place’ – with assumptions that it must be doing its’ job. No mention of monitoring, continuous improvement, expansion and fettling to adapt and change with their organisations risk.

So which party was it?

Well if you had read the news, you will already know. I’m not picking fault with this particular party – I’ve voted for them. All the parties are equally at fault and this isn’t a political post.

These are political parties trying to convince the public to vote for them. The way they describe, handle and response to a cyber incident is an indicator of how well they can handle the other affairs of government.

Outside of politics, this is an indicator of how well your company will deal with business affairs. Looking at the Norsk Hydro incident earlier this year as a prime example of how tp handle cyber incident communications. Some minor quibbles aside, they performed well and that assisted in recovery. A poor communication plan like todays effort would have potentially prevented any recovery at all.

As a final take away from this blog article, ask yourself a few questions:

  • How well prepared is your communications plan?
  • Does it cover the threats and risks that your business is exposed to?
  • Have you sought security specialist advice?

Remember, prior planning prevents pretty poor performance. When your big cyber incident hits, to minimise loss you need to be quick, accurate and concise with your comms.

Next Post