.png)
I had spent a good chunk of team as a Security Analyst, as both a Tier I and Tier II position. It’s a pretty hot niche in Cyber Security right now as it does tend to give more entry level roles in the Cyber Security role, but it is still pretty tough to break into given it is pretty important in defending an organization from potential security threats. If you are like myself in the past, you are likely reading this article right now to get a jump into this career, so I have put together a pretty on the fly but also accurate guide into the life of a SOC analyst, such as the day-day and also some real-life scenarios I have dealt with during my time in those positions as well. I will also throw in a tad bit of information as I do often sit in and in some scenarios, conduct the technical interviews with potential new SOC analysts on our team.
A Genuine Look at The SOC Analyst Day to Day
I’ll be honest, it is a bit hard to describe the overall vibe of a SOC Analysts Day to day. Truthfully some days are painfully boring where you will actually want to learn more about a new certification or new skill just to keep your eyes open, but then the next day can be an absolutely chaotic day of non-stop investigations and alerts. I’d sum it up as one word, unpredictable. But the unpredictability is due to the nature of the job itself and the responsibilities that come along with the position as well.
A good majority of a SOC analysts' day will be involved with monitoring security alters in some form or another. In most cases, these alerts will likely appear in one centralized location to avoid having to jump around multiple platforms non-stop which would 100% just lead to missed alerts, so definitely familiarize with some sort of SIEM. For example, I have worked in shops where all of our logging was centralized within Microsoft Sentinel, which allowed us to configure alerts that would create their incidents all in one place. I also have worked in spots where everything piled into a ticketing platform. It’s just about the same just with different cosmetics. Alerts will generate from your different security solutions such as IDS, firewalls, EDR (Endpoint Detection and Response solutions, so onso forth, and you will need to conduct investigations to confirm the next course of action or confirm if it is a false positive or not.
For example, you could be sitting there with the most boring workday of your life and get hit with an alert out of the blue that a server randomly just had an huge increase of traffic outbound to an unknown location. You’re next step is jumping into see what is actually going, is this a compromised server exfiltrating data or is this an expected alert? It can really change in a minute.
A SOC analyst’s day is often unpredictable, filled with routine tasks interspersed with moments of high tension. Below are some of the primary daily responsibilities:
Monitoring Security Alerts and Ticket Queues
Monitoring the security alerts is one thing, and often times you will come across poorly configured security solutions that are non-stop firing away nonsense alerts that should be tuned out…but not being an engineer you likely will just have to deal with that until it’s eventually greenlighted to be configured properly. However that brings us to the next point, analyzing the incidents that take place. As I briefly touched upon previously, any alert that is generated, is required an analysis or as I call, an investigation to confirm the legitimacy of it. This often times will likely be false positives but you can’t go ahead and deem it is a false alarm without documenting that you properly analyzed any logs, etc. This could be a plethora of situations, for example if the engineers are performing expected maintenance on a server, this could be as simple as following up to confirm the suspicious activity. However, it could become even more intricate. For example, if you happen to work at a place with public facing applications, their likely will be some sort of security system set up to detect potential attacks. In my previous spot, we had an IDS linked to this public facing application to flag if the corresponding web server received any potential suspicious queries against it. I luckily never did, but I do remember for at tabletop exercise we mimicked a SQL injection attack that actually raise an alert with our IDS.
Responding to Actual Alerts
Unfortunately, not ever analysis will actually be an expected activity. Many times, compromises do take place, or at least it may require the situation to be treated as until proven otherwise. If an investigation suggests an alert cannot be determined to be legitimate or not, or in some cases, it does prove to be a legitimate threat, a SOC analyst will be the first line of defense to minimize potential damage. For example, if a security solution were to detect that a specific machine had been infected with some sort of malware, you would need to intervene immediately. Without going into too much detail, hypothetically, you would likely isolate the machine immediately from the network to allow for further forensic investigation to get origin of the malware detected and the IOCs (indicators of compromise) to further detect, if any, the spread to other enterprise hardware. (Given the nature of a compromise, a legal team, stakeholders, etc. would likely be involved here and the severity of the issue, would likely involve a Digital Forensic specialist if there is not one present on the team already).
Threat Hunting…Sometimes
Depending on the team itself and the organization, a SOC analyst can end up in with their hands in a bunch of different niches as well. For example, my favorite niche I ended up getting the opportunity to do a lot work was threat hunting. It wasn’t my primary responsibility as I had to handle all the previous mentioned job duties, but I got pretty into it when I could. It essentially gave me the green light to utilize our logs to search for potential threatening activity on our network that may have been going on under the radar. I really enjoyed this, as it allowed me to start to enter the world of Threat Intelligence which is where I eventually specialized with my next role. For example, threat intelligence feeds exist in the wild that will post / share information of exploits they have detected in the wild, such as an attackers IP address they noticed performing recon on their network. As a SOC Analysis, you could utilize your tools to search for that very same IP address to “hunt” and see if there are any signs of this bad actors IP targeting your org. Or not.
Documentation, Documentation and more Documentation…
My least favorite, but to each their own, is the documentation and reporting that follows a SOC Analysts Day to day. Nearly everything you do, or investigate, will be expected to follow with thorough documentation of your process. This is especially important because at some point, depending on the size of your org + the industry you work in, technical auditors will be tasked with reviewing your activity. If you are just closing out incidents with proper documentation and reporting, this will be a huge red flag that your boss will receive a report on. Even false positives or benign alerts generated by a misconfigured security platform will need proper documentation for a 3rd party to understand the full story. For example, I remember at my very first security analyst gig I used to get so frustrated since I did not have the permissions to actually configure a security platform, as this was handled by the security engineers, and I had to respond to clearly false positive alerts generated every single day by our known Nessus box. (Nessus is a vulnerability scanner, so it obviously was generating non-stop alerts from probing our devices every single day).
What is expected an interview?
This is entirely dependent on the job description itself, but I’m just going to give my two cents from when my place is personally hiring for a SOC analyst position. We tend to be a bit more technical focused and expect a bit more out of interviewees, but it also very stated as so in the job description. This is not the same for all SOC Analyst job positions as some are much more clearly defined as more entry level roles. Keep in mind, for a good majority of Cyber Security job postings that mention entry level, this almost always means specifically to the Cyber Security niche of IT, but they do tend to expect some sort of technical background. A really good portion of folks that break into a Cyber Security specific job at first come from backgrounds as System Administration, Network Engineers, etc. more often than without any technical background at all.
For the few base questions, I throw out your way, I will assume we are hiring for a very specifically mentioned entry level role. We do tend to expect a level of technical expertise beforehand as opposed to coming in completely raw.
For example, a common question to start off is usually discussing the difference between what an IPS and IDS is. We don’t expect an extremely technical answer but just assume the basic knowledge is understood for various cyber security tool terminology.
For our situation, our tier I analysts are often tasked with dealing with the analysis of phishing emails. For that very reason, we want to make sure that our new hires are comfortable or at least familiar with the general parts of an email that you would analyze. For example, we’d likely ask what things you would look at if you were tasked with investigating a suspicious email. Nothing crazy detailed but just an overall look at your thought process and also ensuring you are aware of the under the hood aspects of an email. Trackmen has a wonderful room on this with hands on work. Also, you can refer to me recent article as well where I do a deep dive on analyzing an email as well.
A very common question that is hit with entry level Cyber Security roles in general is asking them how they try to keep up to date with Cyber Security news. There is really no right or wrong answer, but it does gauge on the interest level of potential employees as well. Cyber Security is a pretty hot sector as it does have lucrative paychecks in many instances, so we like to make sure our candidates actually have an interest in Cyber Security as for our entry level roles, mentoring is something we really take pride on.
Again, most interviews I’ve done with SOC analysts are not really that crazy technical, and neither are the ones I conduct as well. Often times a resume paints a good enough picture but the factors like soft skills and thought processes that you can’t really gauge from a piece of paper are the goals of uncovering here. Regarding soft skills, this is usually picked up on during the conversation in general, but we will still push out a few questions more oriented for that aspect of a candidate sometimes as well. For example, getting a gauge on high pressure work situations they have been in or maybe even just a question about what they want want to or are hoping to learn next in Cyber Security etc.
I’d check out my previous articles about this part of the SOC analysis journey but I’m going to keep this article moving in the meantime.
Don’t Forget The Foundations
At the very at least, a SOC Analyst should definitely have the knowledge of the foundational aspects of Cyber Security as a whole. This will often be intertwined with foundational knowledge in IT in general but if you were focus on one topic outside of Cyber Security to shore up on, is networking. In my opinion, you must at least be able to understand the concepts of Cyber Security from a foundational level to take the step into becoming a SOC Analysis. A good portion of the job in some respects does come in hands on training as often times you will end up using platforms you have never touched before, but the foundational knowledge will remain the same. For example, an investigation may call for you investigate the traffic of a workstation and an endpoint on the internet. If you are not familiar with the basics of networking in general and how a machine would interact with the internet, you will really not be able to begin trying to analyze logs that often times will contain some pretty raw information to interpret. Another example would be not understanding ports / protocols as well. Understanding these will really help you understand and analyze network traffic which definitely will be part of your day to day. For example, if you are reading a log and see an endpoint making a connection over port 445, and then you read further into the log and see files being interacted with, if you are not aware of what the SMB protocol is, you will be at a loss to further analyze the actual traffic place and if it is normal or not. So on and so forth. TryHackMe has some awesome paths to follow for a pretty cheap price. I’m not even an affiliate of any sort but I believe they literally have an entire hands-on module for SOC analysis or Jr. Soc Analysis.
Operating System
Also, my advice would be to understand the operating system at a pretty high level for the position you are going for an interview for. For 95% of situations, I would say this would most likely involve interacting with Windows OS workstations. Being able to learn the operating system at a deeper level will make investigating issues much easier, as you will be able to start to comprehend what is normal vs not normal, and where to actually look for potential suspicious activity taking place. For this reason, I would really suggest looking up System Administration courses online for the operating system you likely will end up applying to be a SOC analyst at. This will give you a pretty good advantage as you will understand the ins and outs of the Windows OS and Windows Server OS will keeping a keen eye to potential things that will come in handy from a security analysis perspective.
TryHackMe — Soc Analysis + Jr. Security Path
There is really a plethora of online resources to take advantage of, but I would really suggest TryHackMe for SOC analysis in general as it is pretty affordable. I’d just grab a month of it, see if this stuff is what you are really interested in (as there material is hands on) and then take it from there. Again, I am not an affiliate at all nor make any money mentioning TryHackMe but I still regularly use it to shore up on stuff either I haven’t worked with in a while or new material they release that is relevant. They do a pretty solid job of constantly updating new learning rooms with material.
Where Most SOC Analysts start from:
Again, this is just from my personal experience, but I do poke around a lot of forums in general and it does seem to be pretty common even outside just my bubble. But the reality is that a really high amount of people that become SOC Analysts do not come from a specifically cyber security focused position originally, but they do commonly come from some sort of IT background. As I mention in a good amount of my articles, it is mainly due to the notion that hiring managers want to hire people that have had experience either maintaining or working hands on with technology they are going to be expected to investigate at a deeper level. This isn’t the case for all hires as there are plenty that come in without a technical background, but I am just going to give a few examples of what I commonly see.
Help Desk (Actually where I began)
I actually began my career as a Help Desk / IT support guy for a company that had employees all on Windows OS. I had no clue what I was doing prior, but I honestly learned a ton such as working with Active Directory, Azure Active Directory and going through Event Log data when a computer or application was crashing etc. It turns out a good portion of these skills come in pretty handy as sometimes I do need to review users' permissions in Azure Active Directory / Active Directory, or review logs of a user being added to security groups that may be suspicious etc. Also, another example is that sometimes I may need to sift through a lot of logs that involve specific event IDs, or specific processes to threat hunt after learning of a campaign in the wild etc. Although it wasn’t a glamorous job, I learned so much. Also, soft skill wise, having to deal with IT issues for customers definitely increased my ability to keep it cool in high stress scenarios. There is nothing really like troubleshooting an urgent issue for a user especially if they are a higher up…
System Administrators:
I actually began as a Help Desk Support guy and became a System Administrator at the same place. This is where I really started to feel like I was understanding stuff at a deeper level. I was working with Windows Server, managing group policy, working with the security admin on lower level security stuff (our team was small), learning Powershell to work with Microsoft Azure / Office 365 administrative work, working with pushing out patches, etc. Either way, the stuff I learned at this point in my career absolutely translated when I started interviewing for security focused positions. Being able to say I learned scripting, assisted the Security Administrator with patching, analyzing phishing emails, isolating computers that were suspicious from the Microsoft Defender platform, so and so forth, was pretty clutch when I interviewed. I genuinely can’t imagine interviewing for security positions without this experience. (Keep in mind, everything I mention here can definitely be self-taught, I just got lucky and happened to be mentored in my time here)
Network Engineers:
Although I never worked directly as a network engineer, I would say this is the strongest pool of new hires we take in. This is because a good portion of a SOC analysis job is analyzing network activity at a pretty raw level. For example, if you look up WireShark, you will see tutorials of pretty deep investigations into network packets, that if you have a background working with networking in this level of detail, will be pretty valuable. When I was a System Administrators, I luckily did get hands-on work with Cisco Meraki a bit, so I was able to talk about that a bit in my interviews. This again is why I say to really ensure you build a solid foundation in networking. Being able to investigate into network traffic and understand why network traffic may be unusual, etc., can be really valuable for investigating potential network intrusions.
Final Advice
This is an article that I wanted to push out there since I have received a good amount of questions on my most recent SOC analysis posts. I wanted to really make sure that those who are looking to break into a SOC analysis position are aware of what foundational knowledge is expected, whether through self-learning or hands on professional experience. As one who is often in the conversations with the hiring of SOC analysts, I wanted to make an informative article about what I commonly am evaluating during my interviews, not from a resume perspective, but when the actual technical part of an interview takes place.
Again, if you are serious about pursuing this position and currently are not working in an IT position to any capacity, if possible, I highly recommend doing so. The hands-on work you will receive with the foundational parts of IT are extremely helpful and often times will come in handy with your day to day as a Security Analyst, not to mention may save your butt when you get asked about it an interview.
My overall advice regardless, is get on TryHackMe and check out the Security Analyst path. If you are raw, check out the beginner paths as well. I AM NOT AFFILIATE NOR MAKE ANY MONEY FROM TRYHACKME, they are just a damn good service for a beginner.
Make sure to check out my other posts about SOC Analyst and Cyber Security job advice!
Comments