The Security Consultant, The Service Desk and The IT Guy....

By Jason Brooks, J-Sec Consultancy

On my commute to work this morning, I overheard a rather animated conversation from the guy sat opposite me on the train. The one side of the conversation I could hear went something like this:

"I've asked you not once, not twice or even three times now, SWITCH THE SERVERS OFF NOW! They must be knocked off the network immediately....

What you have is an encrypting virus, it's encrypted seven of our servers, we are unable to decrypt the data...

The hackers are demanding a ransom for the decrypting keys...

I asked you 30 minutes ago to SWITCH THE SERVERS OFF...

No, I don't care that there are users trying to work; they will have no work at all if this virus continues seeking new opportunities on our networks and connected computers..."

Whoever the company was, it's clearly the start of a very bad day. Even listening to one side of the conversation and hearing the cast of people involved on this conference call, it was immediately apparent that the organisation had not rehearsed its threat management and Security Incident Response Plans.

Typically, we rehearse IT implementations, changes and back-outs, co-ordinating with our Service Desks, Change Management Teams, Operational Risk and Governance Partners. We even practice fire drills and business continuity management on a regular basis. As a result, everyone involved has a good understanding of what is needed of them and the chain of command/chain of authority.

When our IT systems are hit with a particularly nasty virus, there's a Titanic moment for all parts of the IT and business communities, they all see the iceberg coming...

The challenges the Security Consultant had were many:-

The IT Service Desk didn't understand the scenario and were more concerned with keeping their users happy and reducing the volume of calls to the help desk.

Change Management Teams didn't recognise this scenario and were trying to manage it as a server outage requiring a reboot or fail over to DR.

The IT Guy was given conflicting instructions...

Switch the Servers off, Don't Switch the Servers off.

The IT Guy knows it's a serious matter to power down equipment without proper change management and approvals in place.

The data centre teams were also unsure of what authority they had to power down the servers and services.

The authority struggle raged on for the full 90 minutes of my journey, during which time more files were being encrypted, more servers were being impacted and new network access points were being sought by the virus to continue its path of destruction across the organisation. There seemed to be an apathy of the resources involved to pull the right people out of meetings or make the necessary contacts.

Talking to the person on the train, it seems they had a variant of the CryptoLocker virus penetrate their organisation.

This is both an unfortunate and an interesting scenario. Switching over to DR would result in those files continuing to be encrypted by the virus, causing more disruption to the organisation. Patch management processes hadn't been properly implemented and validated.

Had their enterprise virus definitions been up to date, would they have experienced such a major outage?

As an organisation, you develop and document Security Incident Response Plans for varying scenarios. These plans are just as important to rehearse and understand as basic DR planning exercises.

Off the back of the news this week of a Californian hospital being hit with a $3.6million ransom demand to unlock their data, I would expect many CxO's are asking themselves what would happen to their organisation, data and business if they were hit by hacker's ransom demands?

In today's age of malware and criminal intent, it's time to start rehearsing your SIRPs to build trust and confidence in the teams that are dealing with these types of incident and prevent further damage by avoiding unnecessary delay in protecting your service.


NEW FOR 2024:




Sky Lounge

Privacy Policy & Disclaimer ¦ Copyright © The Payments Knowledge Forum 2017