360 Degree Cyber Security, LLC

Tag Archive:incident response

Ready or not?

Last week, the city of Allentown was hit with Emotet, malware that started as a banking trojan.  Reports indicate that the initial entry into their municipal business environment occurred via phishing.  Once the malware was downloaded and installed, it began to replicate itself across the city government’s network infecting devices and stealing login credentials.  This has resulted in the city’s financial system being offline, the city’s camera surveillance being taken offline, and the city’s police department being disconnected from the Pennsylvania law enforcement network.

 It is estimated that the cost to remediate this attack will be close to $1 million. This same malware has infected other government and public-school facilities.  In fact, this past January, the same malware cost the Rockingham, North Carolina school district $314,000 to recover from the infection.

 What is Emotet?  Emotet is malware that started out as a banking trojan three years ago.  It was originally designed to sniff network traffic for user login credentials.  Over the last three years, the malware has morphed to allow for custom modules to be added.  Last year, the malware started to use the EternalBlue exploit developed by the NSA and later leaked to the public.  This exploit allows the malware to spread across Windows networks on devices that have not been patched.  The malware is not easily blocked as it can be delivered via .js, .pdf, and .doc/.docx files.

 What can be done?  Ensure that you are auditing your patching to verify that patches are being applied as they should.  Not saying that this malware spread via the EternalBlue exploit, however as a method that it does spread by, are you ready to prevent it from spreading.

Why perform a patch audit?  Sometimes patches may be pushed in an automated fashion, but for whatever reason just don’t make it on to a system and may require a more hands on approach. 




Incident Response – Not as simple as pulling the plug

Imagine this…  You are in charge of a major bank’s cyber security operations center.  It is 2:10AM and your cell phone is blowing up.  The network has been compromised.  The night time analyst has identified a worm and isolated it in……….  a system that controls the air conditioning at one of the branches.  A threat exists… Yes… But does not warrant taking down all of the banks networks.  It does indicate that extra vigilance and investigation are required.   The analyst performed all the steps as outlined in the incident response plan and mitigated the threat.

A well-defined and practiced incident response plan will provide the guidelines necessary to make a determination by the network administrator if the system/network should be shut down immediately or require remediation in place.

The response plan should take into consideration the criticality of the system, the value of the information, and the attack/threat characteristics.  Depending on the system/network’s purpose questions about the operation of the system need to be answered.  Questions such as:

•    Is the system critical to life/death/dismemberment?  Will physical damage result from an attack on the system?  What would happen if the device or network was disconnected or immediately shut down?
•    Does the device support critical infrastructure?  Will fail safe’s kick in if the system/network access is removed?
•    Is the device simply a database that contains personally identifiable information (PII) or electronic protected health information (ePHI)?
•    Is the network/device a mail server or web site server?

With the network/devices and criticalities identified, make a determination on the threat and how pervasive is it.

•    Is it a worm?
•    Is it a botnet?
•    Is information being ex-filtrated?
•    Are devices being remotely controlled preventing use?
•    What are the characteristics of the attack?

It is these types of questions that need to be answered and documented in an incident response plan.

A good example of an attack occurred late last year in Germany.  A steel mill in Germany was attacked that caused actual physical damage.  The attackers took control of a blast furnace and prevented an orderly shutdown of the furnace.  Technicians Utilized immediate emergency shutdown procedures over riding the control system at the furnace and prevented further damage (Zetter, 2015).  This example highlights that removing the system from the attack prevented subsequent damage.

However if the system is a critical system, like a power substation controller, and the attack vector appears to be a worm that is not immediately degrading the network or system, it may be beneficial leaving the system as is and attempting to mitigate the problem by migrating the responsibilities elsewhere.

A case can be made either way for shutting down the system/network immediately.  Factors such as attack impact and system criticality must be weighed.  A good response plan will take into account many such scenarios and will allow for improved decision making, coordination between internal and external entities, and a unified response which will ultimately result in the limitation of data.

Zetter, K. (2015, January 8). A cyber attack has caused confirmed physical damage for the second time ever. Retrieved 2015, March 26 from http://www.wired.com/2015/01/german-steel-mill-hack-destruction/