A Day in the Life of a SOC Architect

The security operations center (SOC) requires a number of roles in order to succeed day to day:

• SOC Analysts investigate security incidents raised by security tools.
• SOC Architects work directly with customers and security tools to design and tune security detections.
• Senior SOC Analysts work with customers, architects, and analysts to provide guidance in deeper investigation and detection design.

In this blog post, I will highlight some of my day-to-day tasks as a Security Architect to help others better understand how this role plays a part in security operations.

High level overview of what my day looks like

Depending on what’s happening and the workload on a given day, my day’s tasks may range from just a couple items to hundreds.

There are a few primary zones I tackle regularly. These include working with customers–usually via email or phone–and determining what is needed for security detections, tuning to provide accurate incident detection, and reviewing system logs for values that can be used to create security detections. Outside the usual tasks, I may be working with the SOC analysts to handle incidents, review prior created detections for improvement, and work on internal projects.

Although the tasks are numerous and there are often overlapping areas, for this writing I will focus on my three primary functions.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Main tasks performed by SOC Architects

1.) Working with customers to design security detections

Hurricane Labs provides services to a variety of business types. This means almost all security detections need to incorporate a custom design to fit around unique business goals, network, user space, compliance issues, infrastructure, and so on. The base of a security detection can often be reused across customers, but finer adjustments are then required to fit that particular environment.

The initial phase of creating a security detection includes a discussion with the customer outlining their goals, what their infrastructure looks like, what compliance areas are required, what type of system logs we will design the security detection around, and how they want any incidents raised by these detections to be handled. Outside the initial phase of designing a detection, there is a lot of back and forth discussion throughout the detection tuning process, the implementation phase, and sometimes following implementation.

For those of you who were considering this type of roll for as little human interaction as possible, think again–this is something I learned the hard way.

2.) Tuning security detections

Aside from the discussion on initial processes, a majority of my day is spent tuning security detections. This also includes a lot of discussion with the customer. We discuss most major changes during the tuning process with the customer to ensure the original goals are still met.

Tuning a detection includes reviewing the detection results for incorrect information, excluding values from the detection that fall outside the scope or are deemed benign, and setting thresholds so the detection does not overwhelm the customers or the analysts. There is a lot of back and forth discussion here to ensure we’re staying on target with customer goals.

At this point I perform a lot of external research on the attack methods the detection may cover, the log types used for the detection, and how a given attack may be executed. This research is done to reinforce that the detection actually does what it is designed to do and, again, ensure goals are being met. As a lot of IT/Cyber Security folk may say, “I know nothing; I’m just really good at Googling things.”

3.) Reviewing system logs

A major portion of the tuning process and initial design is reviewing system logs.

The main security product we work with at Hurricane Labs–and that I work with daily–is Splunk. Splunk collects log files generated by servers, web applications, security appliances, firewalls, and so forth. For the curious, you can even gather data from things as commonplace as coffee machines, thermostats, doorbells, and other IoT devices.

Portions of the log files collected in Splunk can be used to detect–and generate a notification–when malicious URLs are clicked, if communication with out-of-country IP addresses occurs, or what option users select, such as what the most popular drink order is from the coffee machine. Every device generates log files differently, with different formats, different content, and different useful points. This differentiation requires me to be extremely familiar with an abundant number of logs to create accurate and meaningful detections.

Conclusion

If you are considering a job role as a Security Architect and all of the above sounds appealing, then by all means pursue that role. If there are areas above, however, that are a bit deterring– such as all of the customer interaction–remember: like anything, those are skills that come with time and practice.

Hopefully, this post helped you gain a better understanding of the SOC Architect role. Best to you in your future cybersecurity endeavors!