Beginner’s guide: How to setup a SOC (Security Operations Center)

Lot of people asks me to put something about setting up a SOC. So from today onwards, I’ll be posting articles about, how to set up a SOC. Unlike my other tutorials, SOC is not a specific tool/device, which you can simply ‘fit and forget’. So you need lots of patience and hard work to build one. As usual I’ll posting set-by-step instructions from planning to setting up the SOC.  But before that we need to learn some basics. We need all of you networking, system administration and security skills for this. As a minimum requirement to start, you need to have the following skills

• Networking basics (Preferred CCNA)
• Basic system administration (Linux and windows)
• Security administration (Firewall / UTM management)

In other words if know how to configure networking devices, knows how to install package in windows and Linux, and knows at least how to open close ports in firewall, then we’re good to go. I’ve tried my best to write the article from the very basics stuff.

Why do we need a SOC?

This is the very first question I hear from client, while talking about security. Most of them really don’t understand the value of having a SOC in their environment.  Just for an example, look at the following topology diagram.

 In this particular scenario, the server in the DMZ has access to both inside zone and outside zone. But the user is not allowed to access anything other than the server.  In order to publish a server in to the internet, the webserver port must be forwarded from DMZ to outside zone, in the firewall. Here comes the challenge, since the port must be kept open in the firewall, the first line of defense wont block any access from internet to the server via the forwarded port. So the hacker can hack the server from internet. After he has gained sufficient privileges on the server, he then can access the internal network. So what will be your defense against it? Larger the network, harder it will be to be individually monitor each and every device.  Here comes the necessity of SOC in picture. This is only a small example of what a SOC can do. A full functional SOC has limitless functionalities

What is a SOC?

SOC is nothing but the entire security perspective of an IT infrastructure in a single window. It will have all the necessary information to effectively identify threats and thus reducing the time required to eliminate it. It is simply the center point, the nucleus of all security related information. The SOC enables ability for continuous detection, gather actionable intelligence on threats, understand the vulnerabilities, generate reports an even more. We’ll discuss about these in details, later. If you have a very limited human resource and time, and looking for an extremely low budget SOC, then definitely that will be a DIY. So here I’ll explain how to start it from scratch.

A SOC need mainly three components people, process and technology 

The SOC people

Finding the right skilled personnel in a short time is a very difficult task. So it is always an easier option if you could pool somebody from networking team, administration team and security team. Anyways at the time of deployment we need these teams to work hard.  It is recommended that the SOC team should be on 24 hr shift. But that also varies from the requirement. After setting up for the SOC for the first time, it is very usual to have plenty of alerts/alarms in the SOC. These alerts/alarms may range from simple vulnerabilities to complex malware in the network. Gradually the SOC team will resolve each every single issue. And finally there will be some residual risk left, which comes under risk management. But other than these the SOC team will be keep monitoring the systems.

SOC staff can classified into four Hierarchical groups.

Tier 1 Security Analyst

He is ‘front end’ or the ‘first responder’ in the SOC team.  He is the one who creates tickets depending upon priority and risk of the event. He also does the end point checks like vulnerability scanning, checking whether logs are coming or not, real time monitoring etc.

Tier 2 Security Analyst

He is the guy who actually goes through the alarm/event raised by Tier 1 analyst.  He then checks for any IOC (indicators of compromise). He also collects much more details like applications configs, related logs of particular events, compare/check for any existing vulnerabilities which has been exploited, an often give a remediation or recovery procedures.

Tier 3 Expert Analyst

He always has an eye on vulnerability data but, he keeps exploring different ways to identify different types of threats and their impact on assets. These people don’t wait for any escalated incidents; instead they try to exploit vulnerabilities and keep a track of impact of such vulnerabilities

SOC Manager

He is the only one person who coordinates across all teams for reducing the risk factor. He runs reports on various aspects like, tickets opened/closed, compliance status, Top attacker and attacked host etc. He reports to management about the security posture of enterprise and provide suggestion if any.

The SOC Process

A SOC process is simply a repeatable procedure that every SOC team must have. Even though majority of the work are done by our tools we still need some manually intervention to make sure everything is working fine. The process/procedure is not static set of checklist which we can download from internet. Here are few

• Monitoring procedure.
• Event Classification and Triage process
• Notification procedure (email, mobile, home, chat, etc.).
• Escalation procedures.
• Incident logging procedures.
• Incident investigation procedures
• Compliance monitoring procedure.
• Report development procedure.

 

The SOC Technology

The term SOC technology simply refers to the tools we use. That can be anything from a simple packet analyzer like wireshark, IDS, Netflow to a complex SIEM (Security Information and Event management). Instead of using individual tools, most enterprises choose SIEM. Because It is an all-in-one solution, which does pretty much everything in analyzing the logs. You can forward your device logs into it. SIEM process/convert the logs into events. In simple words, it simply  sort, filter logs into a human readable form. Then connects those processed events to it related ones (correlating events).  Then checks further detailed information of that particular incident in cloud database (Threat Intel). Finally SIEM gives you a full picture of what went wrong. There is a huge miss understanding among SOC beginners, they believe setting up a SIEM will be SOC. Always remember, a fully functional SOC needs the P-P-T as we discussed. I will be putting up even more articles regarding setting up SIEM.

How do I test my SOC?

So do you think you need to test your SOC? Yes you need to. Basically we make some “USE CASES”, a simple checklist, which ultimately make sure that the SOC is working properly as intended by the SOC manager. Say for an example, I’m a SOC manager. I want to make sure that my SOC identifies bruteforce attempts. So I ask my L3 Analyst to do a bruteforce attempt to one of my server and check whether my SOC was able to identify it. Initially when the SOC is setup, the SOC manager conducts “USE CASE’ validation in order to verify that all those expectations from SOC are met.  It is a good practice to run “USE CASES” monthly. The use case must be defined in such a way that it is a ‘hacker attack’ towards the devices, endpoints or even policies. Following are few examples for use cases

• Service disruption (DOS)
• Network probing from external IP
• Accessing malicious website
• Exploit traffic towards a vulnerability
• Multiple login failure
• Log source stopped sending logs
• Antivirus alert

FAQ

Right now, when I’m posting this article, I work for the company TripleHat Security Lab LLP. We got plenty of customers in the terms of SOC. I’m putting few of hilarious and common questions; I’ve received from our clients. 

•  Can I decommission my firewall, since SOC is protecting us?

SOC is not a device that stops attacks from external world. It only helps to identify the attacks. The SOC stands on top of your devices, you remove the logs sources (devices), then you might be missing Important information.

• What is the difference between “SPAN” and “LOG”? which of it must be forwarded to SIEM

A span is a copy of your entire network traffic (configured in core switch), while log is a piece of information that reflect a recent activity on a particular asset. You have to send both SPAN and LOG into the SIEM

• How do I install HIDS agent in my perimeter firewall?

The HIDS (Host intrusion detection system) are meant for anything that runs an operating system like Windows, Linux etc. The firewall, router, switch etc. are considered as devices which run firmware. So we can’t install HIDS in them instead we forward device logs into SIEM

• Do I need forward SPAN from my switch if forward SYSLOG from same switch to SIEM?

You need to forward both SPAN and SYSLOG from switch to SIEM. If somebody is trying to bruteforce the console or shuts an interface down, you’ll have that information in SYSLOGS. But if it is a malware, which is spreading across network then SIEM will identify by its NIDS sensor, by feeding the SPAN traffic into it.

• My SOC is in air gaped network, I would like to have the real-time threat feed.

In order to have it in real-time you need to connect your SIEM to internet. There is no point of having information about a malicious IP that attempts bruteforce attacks in internet, with respect to your completely isolated environment.

• My policies ask me to shutdown servers at the end of the day, when is the best time to shutdown SIEM?

It is highly recommended you don’t shutdown a SIEM until it is an emergency/maintenance etc. You must run vulnerability scans and asset discovery scans in SIEM. So you can schedule those vulnerability scans, backups, checking for updates etc. over midnight. So it doesn’t put too much network bandwidth at day time.

• We have our own IDS/IPS, then why it is mandatory to IDS in SIEM?

Your IDS/IPS must be capable of identifying threats but they can’t correlate with other events/activities in network. So either you can send the LOGS of you Intrusion system to the SIEM or you can rely on both SIEM and your IDS/IPS systems.

• Which all people should have access to SIEM?

That is completely up to your discretion. But usually only the SOC people have complete access. The management and other technical staff will have an executive dashboard, tickets etc. with minimum user rights

• Should I run authenticated scan or unauthenticated scan?

It is better if you run authenticated scan, since it will have less false positives.

• Which is the best SIEM tool for us?

That completely depends on your budget, number of assets and how big your enterprise is.

Click here to see a beautiful video on SOC