How to build a security operations center?

Building a SOC is a great experience either for the people who will work on it or for the company that will adopt it. With the increase of network complexity and attack sophistication, getting hacked is becoming just a question of time. Preventing security breaches is not more the right cybersecurity strategy for companies.

Therefore, having a SOC is becoming a must for companies, and doing it the right way is even more important. So, how to build a security operation center?

Building a security operation center goes through five main steps:

1. Assessing Security Operations Capabilities
2. Defining the SOC strategy
3. Designing the SOC Infrastructure
4. Building the SOC services
5. Preparing the SOC services for the start

In this article, I am going to explain in detail and step by step how we can build a Security operation center. We are going to see in detail the technologies used in this system and what are the most popular ones.

This article will be a base for a series of other blog posts, where each phase will get explained in detail in several more articles. So trust me if you are trying to build a SOC, just keep reading I was there once too.

Assessing Security Operations Capabilities

Before starting to build your Security operation center, the first thing everyone should think of is the why and what we want to build. The SOC strategy and Capabilities are the first things to analyze and to discuss with superiors and decision-makers to know where you want to go with your SOC.

Assessing Security operations Capability is the first step in the process of building a SOC. Knowing what you have as capabilities (software, processes …) that can be used in a SOC is necessary to better identify the gaps and the requirement to meet your SOC goals. Therefore, the results of this step will be used as a base in the next steps.

The assessment of those capabilities must follow a good methodology to optimize the results. Therefore, Cisco has proposed a very good methodology to better perform this step:

1. Identify the SOC business and IT goals.

Identify the SOC business and IT goal is an important step in the assessment methodology. I mean if you want to calculate the maturity of your SOC you will need to compare what was achieved till that moment with the SOC business and IT goals.

Identifying the SOC business and IT goals might not be easy to do and may need many interviews with managers and superiors. For example, you may ask some questions about people like Business executives, business managers, or even IT managers and IT users. The main idea is to get as clear as a possible idea about the goal of the SOC project.

• Identify the capabilities that are to be assessed based on the SOC goals.

After identifying the business and IT goals, the next step is to identify the IT process that helps accomplish those goals. An IT process is just a combination of processes, people, and technology that work in harmony to meet the IT goal.

• Organize the collected information about capabilities.
• Analyze the collected information and assign maturity levels to the assessed capabilities.
• Present, discuss, and formalize the findings.

I won’t discuss the 3, 4, and 5 steps in this blog post to not make it too long and boring. However, In the following blog posts, I will explain each step more in detail to better understand how we can TECHNICALLY perform each step.

Defining the SOC strategy

Now that you know exactly what the Business and the IT goals, it is easy to create a strategy that leads to those goals. This step is typically based on the past one, which means a wrong capability assessment exercise will result in a totally wrong strategy. So be sure everything in the past step is correct before starting this one.

A SOC strategy is basically a document that contains at least the following elements:

• SOC mission statement
• SOC strategic goals
• SOC scope
• SOC model of operation
• SOC services
• SOC capabilities development roadmap
• SOC key performance indicators (KPI) and metrics

As I said earlier, all those elements will be explained in detail with examples in the next blog posts. However, I would like to highlight and give an idea about what the SOC scope needs to contain.

Actually, the SOC Scope needs to have at least the following elements:

• Time period: which mean when you SOC objectives and goals need to be meet.
• Locations: the physical location of the monitored devices
• Networks: the networks you need to monitor
• Ownership: Knowing which devices and networks are related to the IT department and need to be monitored is necessary.
• Organization strategy: The SOC should operate under the business goal of the company which will give it the ability to work in harmony with the other departments.
• Used technologies: here you will need to identify the technologies that will get monitored in the SOC, to better choose the monitoring tools.
• Resources and expertise: the required expertise to handle this kind of technologies.
• Timelines: after having all this information, you will get a better idea about the time you need to accomplish this project.
• Model of operation: outsourcing versus in-house capabilities.
• Compliance: the company compliances need to be taking in consideration will developing a SOC.
• Budget: of course the allocated budget to build the SOC (the larger the scope is the bigger budget would be needed)

There is a very nice document developed by IBM that gives some good ideas to take into consideration will making a SOC strategy.

Designing the SOC Infrastructure

Designing the SOC infrastructure should take into consideration many aspects related to the way the data access security and the way devices would be monitored. During the SOC design, the SOC architect must work with many business units to take a better decision that supports the SOC strategy and roadmap.

For me, the first step is to take a look at the vendors who work with the company to get an idea about what technologies they offer. This way the SOC may benefit from already established contracts and support.

Working with the IT teams at this level is also necessary to make a good decision about how to monitor devices and where to put monitoring the monitoring tools. Here is a list of other very important things you should take into consideration will designing the SOC infrastructure:

• Model of operation
• Facilities
• SOC internal Layout
• Physical and virtual security
• Video wall
• SOC Analyst Services facilities
• Active Infrastructure and network
• Access to systems
• SOC data storage
• Collaboration tools

All these elements will be discussed and explained in detail in the next blog posts.

Building the SOC services

At this level, you will need to start building the main services offered by your SOC. Therefore, I am going to give you some of the most important services that all Security operation centers at least need to offer.

• Gather, evaluate, and store events from relevant data sources with the goal of detecting and investigating security incidents digitally.
• Detect, evaluate, and manage information security incidents’ containment. The key goal is to be able to react quickly and limit the disaster while minimizing the impact.
• Run the vulnerability management program or collaborate closely with system administrators who are responsible for vulnerability management.
• Assist with security awareness seminars to educate users on the significance of detecting and reporting security events.
• Advanced digital investigation, including performing detailed and deep analysis of systems in a forensically sound manner.

Now that you know what your services would be, you will need to acquire the right tools to do that.

Gathering or collecting events from different supervised devices in the network is the most important task of the SOC. However, estimating the amount of logs data that your collection tool will receive per day is a necessary task. This task is called sizing and unfortunately, there is no exact way to perform it. In addition, oversizing your solution may result in you paying too much for it, while undersizing may result in the system crashing or you losing crucial event data.

As I said, to do the sizing of the collecting tool you are going to buy, you should calculate the number of events generated per second (EPS). Unfortunately, the only way to calculate the EPS is by putting a syslog server in your network, and keeping it connected for 24h. Then you should analyze the results to identify log trends during normal and peak times.

In the building process, not only the tools are important, people that will use them are also very important and also very rare. Personally, I think finding people that will work in harmony, training them, and especially keeping them is the most difficult part of the SOC building process. This is not just my personal idea too, most security experts I have talked to, have the same idea.

I will not get into this as it was a whole debate between HR and security experts. However, I would like to give you some ideas about what kind of people or experts you will need in your SOC.

Here is a list of profiles you should look for and what they do in the SOC:

• SOC manager

Managers or team leads provide the leadership of teams within the SOC, normally aligned with common sets of services.

• Analysts

Analysts are usually the heart of any SOC and may provide a variety of services within the SOC. Responsibilities can include security event monitoring, incident report investigation, incident handling, threat intelligence, vulnerability intelligence, and reporting

• SOC engineer

Security engineers are usually responsible for the testing, staging, and deploying of new technology platforms or major releases/updates to those platforms.

• SOC operators

Whereas SOC engineers tend to focus on new projects, SOC operators spend their time maintaining and operating the currently deployed SOC platforms.

• Other Support Profiles:
  • Business operations and finance
  • Project managers
  • Business continuity planning / disaster-recovery (BCP/DR) coordination and support
  • Compliance and audit support
  • Incident and problem managers
  • Process/procedure developers
  • Training specialists
  • Communications specialists
  • Vendor and contract management

Preparing the SOC services for the start

Even if it seems very easy, starting the SOC operations is not like pushing the red start button. In fact, there is a lot of challenges that you may face and that you will need to solve while doing this. In this part of the blog post I am going to talk about some of the key challenges, and how you can overcome them.

The first challenges that I would like to talk about are the ones related to people. Most of the time, the SOC building decision comes after either a big breach that was detected in the company or due to some big hack that happens near it. Therefore, when the event is still new, CEO and managers tend to take some courageous decisions and try to invest as much as possible because they understand and feel the importance of cybersecurity at that moment.

Unfortunately, after you finish designing and building the SOC, most of the time those decisions and those feelings change and the budget may get lower than the one defined at the beginning. Therefore, a good SOC manager needs to be prepared to adjust his requirements and his design to the new budget.

One more thing, the team you have just recruit is still fragile and they may feel some stress as starting the SOC will not be that easy. Due to some Human resource policies, the team might not be complete at the begging of the SOC or inexperienced.

More challenges will be faced related to processes and technologies. What you should know about this process’s challenges is that having a process in the SOC to do something, does not replace the user SOC analyst or manager experience. This gets much clearer when the team faces a blocking situation and needs the SOC leader’s intervention.  

Technology solutions are not challenges free too. Deploying all the desired technologies before going live is not always possible. In addition, finding the expertise that will make deploy or maintain your technologies is not always possible either.