First things first, let's break down the acronym. SOC stands for Security Operations Center, and an analyst is someone who analyses things (obviously). Put them together, and you get a security whiz who analyses the heck out of everything to keep an organization's digital assets safe.
They're the ones who keep an eye on an organization's computer systems 24/7, looking for any suspicious activity, potential threats, or security breaches. If something looks fishy, it's the SOC analyst's job to investigate it and determine if it's a real threat or just a false alarm.
A lot of people think it might sound boring, but I can tell you that being a SOC analyst requires a keen eye, quick thinking, and the ability to handle high-pressure situations.
I've always had a love for technology and a fascination with solving problems. I remember spending countless hours as a kid tinkering with computers and trying to figure out how they worked. As I got older, that love for IT never faded, and I found myself drawn to the field of cybersecurity.
Pursuing my enjoyment of IT in general, I joined the RAF as a Cyberspace Communications Specialist. Down the line, a little luck played a part in landing my first role in information security when an opening came up for an internal transfer into a security-focused role within the RAF. (My picture is still on the RAF's page for the Cyberspace Communications Specialist role!)
Once in my first security-focused role I eventually found myself involved in building the first deployed SOC in the MoD (Ministry of Defence). The learning curve was steep, which made it even more fun and challenging. Due to the role being greenfield, the flexibility to build at our discretion was a particularly fun part of what was quite a daunting task.
Ultimately, it was my love for IT, passion for solving problems, and desire for a fun and exciting job that inspired me to become a SOC analyst. And I'm so grateful that I get to do something I love every day while also making a difference in the world of cybersecurity.
The idea of being able to protect organizations from digital threats and keep sensitive information safe was a huge draw for me. Plus, the prospect of a career where I could work with cutting-edge technology and always be challenged by new problems sounded like a dream come true.
I can’t go into too much depth here for obvious reasons, but the two most challenging publicly known incidents I’ve worked on were likely the HO-Mobile data breach (which impacted 2.5 million users) and the HSE ransomware attack by Conti (which degraded Ireland’s public health services).
I think my key takeaway from both incidents is the criticality of having efficient IR (incident response) processes and ensuring the real basics are done right. In my experience, the vast majority of incidents I’ve handled aren’t APTs chaining multiple zero-day exploits to compromise an environment, but instead human error, and misconfigurations.
I’m not a SOC Analyst anymore, but I’ll speak about the tools I found most useful back then. First and foremost an appropriately configured SIEM solution. Not only should the SIEM solution be appropriately configured, but endpoint logging configured with a level of granularity that adds value to the security analysis process.
The next tool isn't a tool as such, but I believe it adds a whole lot of context that's needed when performing SOC duties: Accurate architecture diagrams of the environment you are monitoring. These are something that in my experience hardly ever exist and if they do, are often wildly outdated and therefore not accurate.
It’s quite the juggling act. Like trying to walk and text at the same time—not impossible, but it requires some finesse.
First things first, being proactive is always better than being reactive. Just like getting regular checkups with your doctor can prevent health issues down the line, proactively detecting potential security threats can prevent major incidents from happening in the first place. However, we can't ignore incidents that are already happening. Responding to these incidents quickly and efficiently can prevent further damage from occurring.
So, how do we balance the two? Here are a few tips:
Set up automated security monitoring systems that can detect potential threats in real time. In an ideal world these automated systems, for example a SOAR tool or automated workflow in whichever XDR solution you are using, would take reactive measures for you to isolate any security events.
Create a clear incident response plan that outlines the steps to be taken when an incident occurs. This will help you respond quickly and efficiently, without wasting time deciding what to do.
Prioritize incidents based on their severity and potential impact. This will help you respond to the most critical incidents first, while still being proactive in detecting potential threats.
Continuously review and update your security measures. This will help you stay ahead of potential threats and ensure that your incident response plan is up-to-date.
If you want to pursue a career as a SOC analyst, or even if you just want to enter the field as a SOC analyst before venturing into other roles I have the following advice:
Firstly, understand the role you are interested in and what kind of position you’d like to fill. If you are interested in performing a hybrid analyst/engineer type role, for example, the traditional SOC environment is probably not the place you’d want to end up.
Research the certifications that are relevant to your position, watch reviews and videos, and read blogs on how they’ve helped others in the industry before you spend your hard-earned money on them.
A lot of positions will ask for experience with a large variety of tooling—if you have the resources, then build a home lab. If you don’t have the resources available, maybe you can make use of some free AWS, Azure, or GCP credits.
Have fun. Learning doesn’t have to be boring. Platforms like Hack The Box can be used to gamify learning and ensure it doesn’t become mundane. Hack The Box is actually the platform (way before I started my role here) that I used to hone my skills. I can hand on heart say that in at least half of the incidents I’ve dealt with in the past, I’ve played similar content within the HTB platform from the offensive side. The understanding of how a Red teamer/attacker thinks, operates, and moves throughout the environments we’re defending is pivotal.
It's pretty important for a SOC analyst to work closely with other departments & teams in their organization. Below are some examples of exactly how working with other teams can happen:
Engineering Team: SOC analysts often collaborate closely with the engineering team to gain a deeper understanding of the organizational processes of how application may be rolled out, or even a high-level as to the architecture of the network. Additionally, prior to any additional security tooling being deployed SOC analysts may have to work with the engineering teams to understand any potential performance issues that may occur. The relationship between IT engineering teams and SOC teams is pivotal to the security stance of an organization.
Compliance Team: SOC analysts may at times work alongside the organizational compliance team, to assist in ensuring regulatory and compliance requirements are met.
DFIR (digital forensics and incident response) team: - Now before we delve into this, a point to note is that there is often a blurred line between the DFIR team and the SOC analyst team. The reason for this is that often, the initial parts of an incident can be carried out by the analyst. Regardless, DFIR specialists and analysts often work together to ensure the rapid response, containment, and remediation of security incidents and the retrospective root cause analysis.
Training and Awareness: SOC analysts in some organizations may be expected to help out in the cybersecurity awareness/training program in order to educate other employees of the potential cybersecurity risks and best practices.
That SOC analysts can or should detect/prevent all security incidents. SOC analysts play an important role in detecting and preventing incidents from occurring, but it simply isn’t possible to prevent all attacks from being successful.
Attackers are smart—period. With ever-evolving tradecraft, no system is 100% foolproof. SOC analysts exist to work to minimize the risk of security events/incidents and ensure they are detected and addressed as quickly as possible.
As cybersecurity threats become increasingly complex and sophisticated, analyst roles have evolved and will continue to do so evolve in the following ways:
Increased automation: Over the past few years, SOC analysts have increasingly relied on automation tools to help detect and respond to security incidents. This trend is likely to continue as these tools become more sophisticated and better at detecting threats.
Broader skill sets: In the past, analysts were primarily focused on monitoring security logs and responding to incidents. Today, SOC analysts are expected to have a broader range of skills, including knowledge of cloud security, data analytics, and threat intelligence.
Greater collaboration: To ensure that security risks are identified and addressed, the need to work closely with other teams (such as IT, engineering, and compliance) will continue to rise. This trend is likely to continue as organizations seek to strengthen their overall security posture.
Focus on Threat Hunting: In addition to monitoring security logs for incidents, SOC analysts are increasingly engaging in proactive threat hunting. This involves actively searching for signs of potential threats before they can cause damage to the organization.
Increased emphasis on soft skills: While technical skills are still important for SOC analysts, soft skills such as communication, collaboration, and problem-solving are growing in importance.
Outsourcing: Some organizations are now outsourcing their SOC functions to third-party providers. This allows them to benefit from the expertise of experienced SOC analysts without having to hire and train them in-house.
Mean Time to Detect (MTTD): This measures the average amount of time it takes for the SOC team to detect a security incident. A lower MTTD indicates that the SOC team is more effective at detecting threats.
Mean Time to Respond (MTTR): This measures the average amount of time it takes for the SOC team to respond to a security incident once it has been detected. A lower MTTR indicates that the SOC team is more effective at responding to threats.
False Positive Rate (FPR): This measures the percentage of security alerts that are determined to be false positives. A lower false positive rate indicates that the SOC team is more effective at filtering out non-threatening alerts.
Incident Closure Rate (ICR): This measures the percentage of security incidents that are successfully resolved by the SOC team. A higher incident closure rate indicates that the SOC team is more effective at responding to and resolving security incidents.
Risk Reduction: This can be a bit harder to quantify, but could be evaluated through metrics such as the number of successful attacks prevented or the potential financial impact of the averted attacks.
Establish an efficient triage process that enables the SOC team to quickly evaluate the severity and urgency of each alert. A great help in establishing severity is an understanding of any assets affected, so an asset inventory detailing the criticality of specific hosts can greatly reduce the time to triage.
Comms are key: Ensure that clear communication channels are established between the SOC and other stakeholders in your organization. This will help in the triage and prioritization process.
Single pane of glass—try and ensure that your analysts have one place to look for all the data. Use your SIEM! If there's a log for it, a SIEM tool can ingest it. This applies whether you utilize ELK, Splunk, Graylog, or any other tool.
Before building a SOC, determine the specific needs of your organization. There's no point in beginning the SOC build until you fully understand and have assessed your organization's current security posture.
Don’t buy everything. Ensure that you invest in the correct tools and technologies. There is a wide range of security tooling available at varying price points. Understand what the use cases are and don’t buy a tool until you fully understand how it will help your organization’s security posture.
Establish metrics and KPIs to measure the effectiveness of your SOC team once built. Down the line, this will help identify potential areas of improvement and additionally demonstrate the value of what is quite often an expensive team to build.
Said it before and I’ll say it again: IR processes! You should clearly define your incident response processes. Ensure roles and responsibilities are established and assigned to relevant team members, whilst making sure they’re easy to follow. There's no point in an IR plan looking like War and Peace.
Hire the right people. A SOC team is only as effective as the people in it, so ensure you invest in hiring experienced and qualified individuals with a wide array of skills. Be sure to provide ongoing training and professional development to entice this talent to stay and continue to upskill! Ig0r has a great post on how HTB recruits top talent through the HTB Community.
I’ve used HTB for probably just over three years and have loved every minute of it. I’m pretty sure the first machine I pwned was a machine called Curling—that was a good day!
Curling is an Easy difficulty Linux box which requires a fair amount of enumeration. The password is saved in a file on the web root. The username can be download through a post on the CMS which allows a login. Modifying the php template gives a shell. Finding a hex dump and reversing it gives a user shell. On enumerating running processes a cron is discovered which can be exploited for root.
Obviously, my job here is to bring all things Blue to the platform, but there is already a variety of forensic and reversing challenges under the “Challenges” category. Both the forensic focus challenges and the machines on the platform have seriously helped advance my skill sets. There have even been incidents I’ve handled in which the same type of vulnerabilities exploited at work were the ones I abused on HTB.
Play forensics challenges on HTB
My career path is similar to a lot of others, with quite a generic approach through the system administration space and eventually into the information security field. I did also have quite an interest in IT at a young age. I have fond memories of working with the IT administration team as a student at Oakwood High School when I was growing up in Rotherham! A picture paints a thousand words as usual here:
Cyber threats are becoming increasingly sophisticated and widespread. As a result, SOC analysts play a critical role in identifying and mitigating these threats to protect organizations.
SOC analysts have a broad range of responsibilities, including monitoring security logs, analyzing threat intelligence, responding to incidents, and collaborating with other teams within the organization. Their work is critical to maintaining the overall security posture of the organization.
The role of a SOC analyst has evolved over time, and will continue to do so as cybersecurity threats become increasingly complex. As a result, SOC analysts must stay up-to-date on the latest technologies, tools, and techniques to ensure that they can effectively detect and respond to threats.
Metrics are an important tool for measuring the effectiveness of SOC teams. By tracking key metrics such as mean time to detect, mean time to respond, and incident closure rate, SOC teams can evaluate their performance, identify areas for improvement, and demonstrate their value to the organization.
Author Bio: Sabastian Hague (sebh24), Defensive Content Lead, Hack The Box
Sabastian Hague is a seasoned cybersecurity professional with over eight years of experience in the field. After serving in the Royal Air Force as a specialist in all things SOC, he went on to work for Vodafone's global CERT team before taking on a role as a senior security consultant with SpiderLabs and working on numerous high-profile incidents. He is now the Defensive Content Lead at Hack The Box.
Seb has numerous industry certifications including GIAC Certified Detection Analyst (GCDA), GIAC Continuous Monitoring Certification (GMON), GIAC Certified Incident Handler (GCIH), GIAC Certified Intrusion Analyst, Offensive Security Certified Professional (OSCP), Blue Team Level 1 (BTL1), Blue Team Level 2 (BTL2), Cybereason Threat Hunter (CCTH).
Ophie, May 11, 2023