Cyber security is an ever-changing landscape. As technology changes so must security procedures and techniques. Often in the cyber security realm of incident response, I am astounded by the lack of forethought given to newly emerging tools and tactics, such as threat intelligence.
Threat intelligence is important and must be properly dealt with if we are going to utilize it to its fullest capacity in cyber security. Sadly though, we are seeing a true lack of thought and strategy when it comes to actually implementing threat intelligence in the incident response process. This war story displays the wrong method of utilizing threat intelligence, both as a part of incident response and as a way to react to ongoing threats.
A company experienced what was classified as a breach, when several customers’ personally identifiable information (PII) was used to illegally access accounts and conduct criminal financial transfers. The initial response to this breach was admirable and strong. The incident response process was started. All involved parties were brought to the table to strategize on how to respond to the threat. From these discussions, they learned that the threat was ongoing, and attempts to gain access to customer accounts were happening almost on a daily basis.
The initial triage was conducted and several suspicious IP addresses were identified via network traffic. The criminal's method of operation was identified. They had used social engineering on the help desk personnel, and had been able to reset the victim's account password. At that point, the customer decided to involve law enforcement and contacted a federal agency to conduct a criminal investigation. So far so good, right?
Utilizing the suspicious IP addresses, responders were able to identify possible portions of the country where the suspect resided or from where they were attempting to illegally access the accounts. Log files were obtained that could be used to trace suspicious activity throughout the network, and a tool was installed on the network to monitor endpoints and servers for suspicious activity.
It was at this point that the focus changed.
The incident response process became focused on foreign IP addresses regardless of any associated intelligence. This meant that time was spent researching thousands of IP addresses for threat intelligence even though no other suspicious activity could be associated with those IP addresses. This was a waste of time and energy in the midst of the investigation. Focusing on foreign IP addresses, without any associated intelligence or suspicious actions, can waste valuable manpower and computing power without providing any useable return.
Not only did the focus switch to these foreign IP addresses, but the entire network team began to scour the logs looking for any foreign IP addresses accessing their network. It is important to note that each and every network in the world is constantly being scanned. There can be thousands of scans conducted against a large network every day, with no other suspicious activity. Focusing on such events during an active incident investigation weakens rather than strengthens your response.
Another issue that occurred during the investigation was over relying on the law enforcement assistance. Law enforcement will not conduct log file analysis or release details of any forensic analysis completed against hardware. I am a former law enforcement officer with experience in the local, state and federal levels of investigation and can testify that the focus of law enforcement is different than that of your internal security team. Law enforcement is going to focus on identifying, arresting and prosecuting the perpetrator, not on securing your network. They may be extremely hesitant to share information learned from their investigation with your security team, for obvious reasons. Rather than calling law enforcement in as a solution, look upon them as another tool to assist in protecting your network.
A final misstep in this investigation was the seemingly casual dismissal of a valuable network monitoring tool because of falsely reported data. Many CEOs and other C-level executives fail to notice hostility between IT teams. In the many incident response cases that I have worked, I have seen the security team relegated to a subservient position and treated dismissively, and sometimes with outright hostility, by other IT staff. Any recommendations made by the security team were treated with disdain and immediately thrust into the trash can by their IT associates. This is a failure that can cost your company dearly. C-level executives must be aware of the internal dynamics among their IT staff and deal with any issues that could impact their security. Division among staff members weakens your overall security posture.
What can we learn from this war story?
Here are some important points to reflect on before your next security incident:
- Do not lose focus in the investigation. If a clear methodology has been identified, stay focused on that issue. Do not get lost in the fog of the investigation. Stay focused and deal with the issue at hand.
- Define threat intelligence before implementing it as a solution. Raw threat feeds, unassociated foreign IP addresses and other similar “intelligence” forms are not actionable intelligence. Remember that all intelligence must be accurate, authoritative and actionable.
- Do not rely upon law enforcement for network security recommendations or techniques. Their focus is different from that of your security team. Do not expect law enforcement to share their information with you across the board. Certain items must be withheld for future prosecution or legal action.
- Identify interdepartmental hostility and deal with it before an incident occurs. C-level executives must take an active part in cyber security or experience the types of failures we have seen with other large-scale breaches. C-level executives are being held accountable for security failures, so prepare.
The NTT Security War Story blogs are intended to share with the reader our own experiences, sometimes good, sometimes bad. Take the lessons presented and use them to correct any flaws that might be identified in this blog. Enhance your security!