Cybersecurity analyst 101: methodology

One of the most challenging things to learn as a new analyst is a methodology for investigating events. There is just so much information out there on network, host, malware, forensics, etc. This info will make your head spin.

Truthfully, learning analysis takes years, and you will never learn it all. That’s a good thing in my book because this career would get stale if we could learn everything over night. For sanities sake, run your own race and learn at your own pace. This blog will walk through the steps you should be taking when you are triaging alerts as a new cyber security analyst.

Ok, enough pep talk. Let’s get to it

Methodology?

The term “methodology” can mean a variety of things depending on who you ask.  For this blog, I am talking about the processes you go through to get from a suspicious event to a conclusive “yes its bad” or “no it’s okay”.
For me, I like the ideas of frameworks. They provide guidance at different stages of the investigation so that I never feel lost. And keep in mind, this isn’t a rigid process. As I learn new skills, I add new tools to my process. Currently, I am digging into host-based forensics. I hope to gain more insight into system artifacts left on Windows hosts and add additional tools to my methodology.
Back to the point, you should always be learning, and each person’s methodology is completely based on their own competencies. Now since you are starting out, I will provide a barebones basic framework for you to learn and build off of. However, feel free to tweak this approach to suit your style

Methodology Flow

This flow begins at the mindset that we received an alert of a suspicious event. This is opposed to we went hunting and found something.
For those who haven’t worked in a Security Operations Center, also known as a SOC, the analyst typically has a dashboard of some sort where events come in. These events are identified via security tools such as anti-virus, Intrusion Detection, Web Application Firewalls, etc. Essentially any type of security tool will feed into a SIEM which is used to centralize logging

Security Dashboard - Rights belong to Splunk

Also, because I don’t know what tools you will have access to, I will generalize to what types of data you should be looking for

Actually the Methodology

Understand the Alert

One of the biggest mistakes new analyst make is not truly understanding the alert that fired. Missing this step can lead to hours of wasted time, going down rabbit holes that do not really matter.
The name of the alert is usually an indication of what it is looking for. For instance, you may see the signature, “Trojan.Ransom.WannaCryptor.H” from BitDefender. To understand the name we can simply take a quick look in google.

Microsoft states that this is, “known as WannaCrypt, WannaCry, WanaCrypt0r, WCrypt, or WCRY”. Great WannaCry. Unfortunately, the Microsoft link is lacking on technical details so we must go somewhere else.
SecureWorks has a very detailed analysis of this malware. We should go through this and understand the stages of the malware. How does the system get infected? What happens on the host once infected? How does the malware spread? These are to just name a few questions I need answered before moving on.
Obviously, with ransomeware, we would want to isolate the host immediately but I want to just focus on the analysis piece right now.
​
At the end of this stage, we should have a list of questions that need to be answered based on how the malware or security threat is expected to behave. These questions will guide the next step.
​

Know what logs are available

For some organizations, this is an obvious answer but for MSP’s, you never know. Each customer is entirely different. Different security products. Different SIEM. Different processes. All the things different.

Take the time to get the gist of what information you have available to look through. Hopefully, at a minimum, network logs are available.
​
Based on the information collected from this step, I would start my investigation in the most data-rich area. Whether this is a network or host. You will be most successful where you have the most data.
Subsequently I would analysis the next most data rich logs

Start thinking timeline

From the first bit of information, I would start documenting a timeline. Because most companies are inundated with logs, if they have a SIEM, time of important events are one of the most essential pieces of information.

MSP’s typically work with large national and international businesses. With these, you can expect millions of logs in a big heavy lifting SIEM such as ArcSight or Splunk. The more you can narrow your searches down the easier time you will have. Time will be your first bit of information to work from because your alert will have a timestamp.
​
With each bit of useful information, document and continue to add to your timeline.
In a perfect world, you will know when the initial infection occurred all the way to when the host was isolated. For an actual attacker in the network, your time will include the initial recon, exploitation, all the way through lateral movement.
​

Gather Evidence

This step kinda goes in hand with building a timeline. After you know what the alert is for and you know the logs available, start diving in.

Keep in mind the activity you are looking for and narrow your searches to that specific information. For instance, if you are looking for web requests, these are going to be in network logs. On the other hand, if you are looking for system commands, these will be in system logs.
​
Also, don’t forget to look around each of these events to see if anything else suspicious has occurred. Typically attacks happen in a chain of events. To learn more about attacker methodology see one of my other blogs geared toward this topic. Understanding the flow of an attack is important because attacks are not always black and white. Remember the bad guys are working just as hard to hide from you. The signs you are looking for are often not obvious but the methodology is almost always the same.
​

Document

All the cool queries you run don’t really mean much if you don’t document well. This is another step that is often neglected. Make sure when you annotate, others reading your analysis understand the event that occurred. This means talking about your conclusions and having supporting evidence for those conclusions.
​
Think about it from the perspective of a homicide detective. They can’t convince a jury the murderer is guilty unless they have crucial evidence such as means, motive and opportunity. If you don’t have the logs to support your analysis, it didn’t happen

Tools and Links

A Cyber Union blog isn’t complete without some great tools.

Below is a list of links that either I use or have been recommended.
​
https://www.virustotal.com – Used to lookup hashes, IP’s, domains, filenames
https://urlscan.io/ - Used to interact with a suspicious website to gather more info
https://mxtoolbox.com/SuperTool.aspx - Used to lookup network-based info such as a domain, IP, DNS, blacklists
https://forensicswiki.org/wiki/Main_Page - Great resource for host-based forensics
https://attack.mitre.org/matrices/ - Great place to learn about attacker methodology and exploits used in each step
​