Black Hat: The Forensics Factor

Monday, August 8, 2016 @ 09:08 AM gHale


By Gregory Hale
It is inevitable; an attack happens. The next move is to understand what happened so you can understand any holes and prevent something from happening in the future.

That is where Digital Forensics and Incident Response (DFIR) comes into play.

RELATED STORIES
Black Hat: Drone ICS Attack Possible
Black Hat: IT-OT Learning Curve
Network Monitoring: Keeping an Eye on IIoT
The Wireless Edge
Ransomware Masked as Rockwell Update

“We want to find evil in an incident,” said Chris Sistrunk, senior consultant at FireEye during his Wednesday briefing entitled, “What’s the DFIRence for ICS” at Black Hat USA 2016. “We want to make sure everything comes back to a safe state. ICS anomalies sometimes they occur, but when does it become an incident?”

When it comes to recovering from an attack it is all about learning and growing from the incident.

For embedded devices the user should collect in terms of physical data: Exact location of the device; device description; identifying information; connections like serial, Ethernet and USB; front/back panel LED status; power consumption; temperature (if running hot), and evidence of tampering.

For digital data, the user should collect: Running configuration, including user accounts; last-known good configuration; running firmware, approved firmware; CPU usage percentage, memory usage percentage including RAM and storage; running processes; active ports like serial, Ethernet and USB; logs, and a memory dump.

While there are similarities with IT like when, where, how the ICS remains affected, regularly reporting the status to management, and writing a report of what exactly happened.

In addition, ICS must also: Return the ICS to normal quickly and safely, ICS devices have RTOS and ICS protocols; analysis to verify anomalies, and how and when to regain control of the ICS.

An incident happens where the user found an increase in network activity, strange behavior or a failure of some type. It is now time to investigate to determine if it is known bad code or an unknown piece of code. After that determination, the user would need to figure out if he or she needs to escalate the event into a security incident and then determine who to call, engineers, system administrators, public relations, safety folks, or maybe the system vendor.

One of the main things the user should not do is turn off the system.

“If you turn off the system, that could erase and good data.” Sistrunk said. “You don’t want to lose forensic evidence.”

As a result, first responders should collect and learn what the user and event logs reveal, he said. Also, does the configuration match the firmware and they should also see if the firmware approved from FAT/SAT.

They should also be aware of the running configuration, along with the last known good configuration and the standard configuration. Also, they should know if the configuration and logic are correct for the process. They should also know if the communications (serial, Ethernet, USB, wireless) are normal.