How to do Security Analysis

This article will discuss the five-step SOC Analyst Method. The five sections are Reason for the Alert, Supporting Evidence, Analysis, Conclusion, and Next Steps. Learning the method gives you the fundamental knowledge required to analyze and prepare a security alert for further action or a conclusion.

What Is the SOC Analyst Method?

The SOC Methodology emerges as a product of extensive cybersecurity experience, providing a structured approach to analyzing security events. The five-step SOC Analyst Method offers a manual process that, despite the prevalence of AI and automation tools, remains a valuable skill set. This knowledge not only distinguishes you within the cybersecurity community but also proves indispensable in specific situations where manual analysis adds depth to threat comprehension and response strategies.

Following these five steps in sequence results in a comprehensive overview of a security event, spanning from its beginning to its conclusion. Figure illustrates the security event gateway, which develops from the ground up, including a proposed allocation of time for each step. While certain events may demand more or less time in specific steps, the general guideline suggests dividing the time spent on a security event in this manner.

Figure 1–1. Security Event Gateway

• 5% is for identifying and understanding what caused the alarm to trigger.
• 40% is for gathering and documenting all evidence pertaining to the alarm.
• 40% is for studying the evidence, checking the reputation of the indicators, looking for historical correlations, and otherwise determining if this is malicious behavior.
• 10% is for crafting a conclusion that is the result of your security analysis, and taking any necessary immediate actions.
• 5% is for determining the next steps, if any.

Let’s dive into each step and explain how to conduct a security investigation.

Reason for the Security Alert

This section explains why the alert was triggered. The SOC is a series of triggers for malicious behavior and the first thing you will need to do is have a solid understanding of why it triggered.

The reality is the SOC is extremely fast paced and the breadth of knowledge that is required to conduct a security analysis is immense. Don’t be afraid of rolling up your sleeves and digging into an alert that you haven’t seen before to find what it is looking for and why this particular instance looks malicious. Without understanding the logic behind why it looks suspicious, you won’t know what evidence to collect to build a case to analyze.

Every tool has different signatures, so the first place to look is the documentation from the vendor. The simplest way is to search the Internet for information about it. Just google the alert title. It’s usually that simple unless it’s a custom rule in which case you should refer to your internal documentation if you have any. You may be in a situation where there is no documentation, but this step is critical and you cannot continue until you understand the rule.

Once you understand what the rule is looking for, the next piece is understanding what happened to cause this particular alert to trigger. For instance, the rule might be configured to alarm if it matches any IP address on a blacklist, and the second part is finding what IP address triggered this particular alarm.

Examples:

This alarm was fired due to a ransomware variant being detected on the endpoint machine “Machinename123” and not cleaned.

This alarm fired due to numerous external login attempts against a public facing web server “login.xyz.com”.

This alarm fired due to the domain admin “twall” adding the user “testtest” to the admin group “xyz_TEST_ADMINS”.

In your analysis, this is the first thing that the reader will read and it will help them quickly understand what the alert is about.

Supporting Evidence

This section is for listing the supporting logs and evidence that you find while building the timeline of the event. Building a timeline is essentially looking at what happened directly before and after the alarm triggered. What you are trying to determine in the analysis step that follows is if this alert triggered on malicious activity or is there some other benign reason this rule has been fired. In this step, however, we are doing nothing more than collecting and documenting supporting evidence to later analyze.

Note Usually I will start with a timeline of 24 hours before and after, then adjust as the analysis progresses if needed. But if you need to widen the timeline, more supporting evidence goes here.

The first part of supporting evidence I like to target is identity. Add the job title of who was targeted, username, email, last login and if they’re a VIP or privileged user and any other relevant details.

And then document the device name, device IP address, and any information you have about the asset. Is this a user workstation, server, is it dev or prod?

Then include any information about the files associated with the alert, their hash, file size, and signer.

Next, paste any logs that you have for the event that may be helpful to reference from. Endpoint logs, SIEM logs, firewall/network logs, IDP/IPS logs, anything that you find that may be helpful to think about and analyze in the next step.

Start thinking if this activity would be a part of their job description and what tools you have internally that might have information about this event. For instance, it may be a good time to check your ticketing system to see if any maintenance was happening that could trigger this.

Next, document any actions the account has taken recently. For instance, have they recently had an account lockout or changed their password? Have they downloaded any big items recently or downloaded many different items in a short period? Document any suspicious email actions deleting and sending unusual amounts of emails. Document any suspicious mail forwarding rules. You are looking to document anything that the account did in the timeline that may be pertinent to the alarm that triggered.

But remember, we’re investigating the alert to copy the evidence at this stage. Try not to chase any theories too far just yet. In my experience, once you are staring at all of the data in text and thinking about it for a minute or two in analysis, you will have a better chance at a correct theory and conclusion. Time wise, it’s much faster to analyze with a complete picture of the evidence.

Others will read this analysis and will be able to understand how you got to the conclusion easily and quickly. All of the information that supports your analysis should be in the supporting evidence. You can and should go back and add more supporting evidence if your analysis pivots you in another direction.

Analysis

This section is where you take your supporting evidence then evaluate all of the information you’ve collected using threat intelligence, external and internal tools. You attempt to make connections between the supporting evidence to malicious behavior. There are a lot of online tools that are standard to use for this step. VirusTotal is perhaps the most common for checking the reputation of an indicator of compromise (file hash, IP address, URL, etc.) but any automated tool can do that today. What distinguishes you as a “better than machine analyst” is your thoroughness. The fact is automated tools simply haven’t reached the point of conglomeration where they even have the licenses to check it all. You will commonly get different answers about reputation from different tools. Check IP Void, URL Void, Spamhaus, AbusePDB, Cisco Talos, and document as many as you can.

A few of my commonly used free online tools are as follows:

• Virustotal: Use this tool to conduct research on IP address and URLs.
• Talos Intelligence: Use this tool to conduct reputational checks on IP addresses and URLs
• IPVoid: Use this tool to check blacklists for a particular IP address.
• URLVoid: Use this tool to check URLs for safety reputations.
• Reverse.it, Joe Sandbox, Any.run, Hybrid Analysis: Use these tools to analyze online/offline files and URLs for malware.
• Domaintools: Use Domaintools’ free whois service to research registrant information.
• Threat Crowd: Threat Crowd is a system for finding and researching artifacts relating to cyber threats.
• TOR Exit Node List: Check to see if the IP address is on a TOR exit node.
• IBM X-Force Exchange: Check the IoC for information in X-Force Exchange.
• Internet Archive: Use archive.org to get an idea on how long a website has been up or what it looked like in the past, recovering pages, malware samples, or other files that are no longer available.
• Urlscan.io: Use this tool to get a quick snapshot of the website and do a reputation check.
• WhereGoes: Use this tool to see where a link goes to.
• Reverse IP: Use Analytics tool Reverse IP to find out how many websites are hosted at the IP address.
• Google: Please never, ever conclude any analysis on an IoC without finding out what google has to say.

Note Depending on a company’s crown jewels and how their business operates, the way a company approaches cybersecurity varies. Where cybersecurity matters to keep the lights on, such as the financial and manufacturing industry, being thorough is more important and companies want to exceed compliance standards.

A Few Tricks…

Whois every time at the beginning of this section and paste it in. It saves a ton of clicks and tabbing back and forth. You’ll use that domain name or IP address many times and you’ll know where to find it.

Archive.org is useful and no one thinks to use it. You can see what a website looked like in the past, and I use it commonly for investigations where I need to guesstimate how long a website has been up.

Be sure to use websites to see where exactly a URL goes to. I use wheregoes.com in almost every investigation. Notice how many hops it’s taking. On more than a few occasions, I’ve thought the domain name was legitimate by looking at it, but after checking wheregoes, I noticed there were a few hops. Looking closer, it was a well-crafted lookalike domain name.

Google everything. I can’t stress this enough. You may have all the tools in the world, but a quick Google search almost always adds more context to an investigation. Often finding sandbox reports of a particular hash and allowing you to skip the step of executing it yourself. Remember that automation can’t Google search and gems like where researchers have published a write-up on their blogs for a piece of malware.

Note Be sure to be careful with Googling IPaddresses, ensuring you don’t visit the website.

Take snapshots of a website. If you want to visit a suspicious website, do so in a live session in a sandbox. I personally like urlscan.io for a quick reputation check and snapshot, while Joe Sandbox is better for a live session. You want snapshots because you don’t know when the website will be taken down. Phishing websites, for example, are often taken down by the attacker as soon as they’ve harvested a few credentials, and then redirect the URL to a legitimate site. As soon as you can, snapshot.

Historical analysis must be done every time. In your ticketing system, determine if this has happened before. When was the last time there was a ticket for this user or device? Also, has this attacker been seen before? If so, which happens frequently, how did the last analyst handle it? It’s important not to jump to conclusions; even though it may look similar, it should only be used as context for this investigation and a clue for how to verify this one.

The last thing you do in this step is pause. Pause to review everything up until this point for accuracy and add any supporting evidence that was overlooked.

Conclusion

This section states the result of each section that led you to your action. The reason for alarm, the supporting evidence, and your analysis should be presented in a precise, clear, and easy-to-read manner and in that order. Be sure not to make this section too lengthy. The idea is that a reader can read it and know what to look for in the previous sections to find more detail if they need to. The last sentence of a conclusion states the action you took and every conclusion must have an action. This could be as simple as “Closed ticket due to false positives” to “Isolated the machine and escalated to the Incident Response team.”

Examples:

This alarm triggered due to user “kmax” visiting a webpage that contained suspicious Javascript with iframes that redirect. Evidence from the proxy logs proved the user was redirected to another website, but it resulted in a 404 error. Analysis of the referring website showed that it contained the iframes that redirected the user to the potentially malicious website. The landing page has a malicious reputation on Virustotal, URL Void, and URLScan. I submitted the referring URL to be reclassified as malicious and closing alarm as resolved because the malware was never received.

This alarm triggered due to user “guam” visiting a website containing suspicious obfuscated code. Evidence shows that the user successfully visited this website. After decoding the Javascript, I found the Javascript contained “Eval()” statements. By changing the “eval()” to “alert()” I was presented with the landing URL. Analysis of the landing URL by virustotal, senderbase, URLvoid, and hybrid analysis has proven this website was malicious. I submitted the machine for a reimage and reset their credentials.

Next Steps

Sometimes you’ve taken immediate action or weren’t able to take immediate action on a security event, and there are still items pending. For instance, you’ve just sent the device off for a reimage and you need to follow up with the user when they are online. Or this ticket is part of a greater incident and its pending close by a master ticket. Or maybe you were still unsure about what to do after the analysis and needed to escalate it to a higher tier in the SOC.

It is perfectly acceptable to put N/A in the Next Steps sections and that is what will be most common because you’ve closed the ticket. If there is anything here at all, it needs to be tracked and the ticket must not go into a closed status until it is resolved by a higher tier or the Incident Response Team. This section is sometimes used for tickets where a security event becomes a security incident and the Incident Response Team needs to be involved because the ticket has become more serious than what the SOC normally deals with. This may be the case if the asset is a critical asset, or there is evidence of data exfiltration, or the user is a VIP user that gets the white glove treatment. Each SOC will define what constitutes escalating to become a Security Incident and the ticket has traveled through all tiers of the SOC and still isn’t resolved.

Whichever the case, if the ticket remains open, there are recommended next steps.

Summary

The last thing I want to cover in the article is masking. All URLs that you copy and paste into the analysis need to include brackets [.] around the periods and this is crucial. It makes it so there are no accidental clicks by anyone reading the analysis.

www[.]google[.]com

This method, when used properly, gives structure to a security analysis, allowing for greater readability by higher tiers in the SOC and to provide for quick details for complex Incident Response investigations. It also serves as a tool for you to learn how to conduct a proper security investigation. You may find that you don’t need to use it all of the time, but I encourage you to learn this method so you have it when you need to use it. I have taught this method for the past ten years and some companies have chosen to use this method for every ticket, and some only require their junior analysts to use it as a training tool on how to conduct a security investigation. In my last role, I was customer facing for a managed SOC, and it was common for a customer to want a “deep dive” after our analysts had finished the ticket because they wanted more detail. In all cases, after applying the method, they had all the details they wanted to feel we made the right decision. I know it may seem like more work for you, but in the long run, learning to apply this method will only benefit your career.

Download the SOC Analyst Method Template here. and practice with the honeynetwork project.

Tyler Wall is the founder of Cyber NOW Education by night and works full time in the cybersecurity industry as his day job. He creates cybersecurity training material in his free time, often after feeling the need to shout what he’s just learned and also because a little bit of passive income never hurt anyone.

He holds bills for a Master of Science from Purdue University, and also CISSP, CCSK, CFSR, CEH, Sec+, Net+, A+ certifications

You can connect with him on LinkedIn.

Get 20% off all courses in our On-Demand catalog with coupon code “MEDIUMFRIENDS”

For a limited of time get a free copy of Jump-start Your SOC Analyst Career eBook that was published June 1, 2024, in exchange for a review on Amazon. Email tyler@cybernoweducation.com