6 Tips for Building an Effective SOC

Security operations centers (SOCs) can range in size and scale and typically involve a confluence of skills, processes, tools, and hundreds if not thousands of security alerts. Whether an SOC is big or small, security professionals are often seeking resources to build and improve the effectiveness of their SOC.

That’s why an RSAC Unplugged 2019 presentation titled, Detection & Response: Building Effective SOC Operations, by Tithirat Siripattanalert, CISO and CDO at True Digital Group, caught our eye. She lays out several ideas for building (or improving) a SOC. Here are some of her ideas that stood out to us.

1) Put the basics in place first.

Before building a security operations center, Ms. Siripattanalert suggests getting the security fundamentals right. She says that includes foundational steps like eliminating insecure servers and protocols, segmenting your networks, and centralizing password management. In her presentation, it also includes having basic tools in place – such as firewalls and anti-malware – and also both IDS and IPS that can perform signature- and behavioral-detection.

2) Understand your environment.

The SOC needs to know what it’s defending, so the process of inventorying and documenting assets and applications is pivotal. The SOC should have a list of standard software that is installed on both servers and endpoints. Similarly, it needs to understand the function of each application and what other assets are involved in the typical network transaction.

Good documentation provides two key benefits in incident response. First, it helps the security analyst to distinguish between normal and abnormal activity as an incident emerges – for example, a non-standard application suddenly running on a server. Second, if an IP address is compromised, the analyst can assess its capacity to spread.

3) Establish well-defined goals.

Well defined goals will guide the tools and processes the SOC implements. If the goal is compliance, then the team will evaluate where sensitive data is stored and review the security controls that have been put in place. If the goal is to monitor for a breach or malware infection, then the team can assess the types of tools required to prevent or detect – and provide the necessary visibility in the event of an attack.

She recommends classifying assets based on the sensitivity of the information they manage. This provides a way to establish priorities. One of the pitfalls she has observed is organizations that attempt to monitor everything, and that often quickly overwhelms a team with alerts and false positives.

4) Choose flexible and scalable technology.

Flexibility and scalability have specific meanings in Ms. Siripattanalert’s viewpoint. By flexible, she means it provides a way for analysts to customize how they view information. She spoke of an example where a security tool triggered an alert, but when the team began investigating, the tool was not flexible enough to show them the details of the possible payload.

Similarly, she says scalability has to do with volume. She notes as an organization adds data to monitoring tools, it sometimes takes longer processing time. Scalable tools can handle larger sets of data without slowing processing performance.

5) Develop an incident response plan.

Developing an incident response plan starts with setting clear roles and responsibilities for every member of the team. In the course of planning who will be doing what, you also need to assess whether or not that individual has the access and tools to fulfill her or his defined responsibilities. For example, sometimes the security team needs help from the IT operations team to gain access needed to contain a threat.

This set up another point:  An incident response plan needs to be rehearsed and not just with security or IT, but also with other business partners that could potentially be involved in a high severity event. This includes executive leaders, public relations, legal, human resources, the call center, and even third-party partners.

The point is well made because research by PwC has shown that the top 25% of security professionals communicate and collaborate effectively with peer groups across the business.

6) Requisite skills and knowledge.

For all the tools and process, Ms. Siripattanalert noted, “people are the most important part of SOC implementation.” She identified some of the requirements of SOC staff are as follows:

  • Knowledgeable about threats and vulnerabilities;
  • Understanding of the environment, systems, networks, routing and configuration;
  • Competency in using fundamental security tools; and
  • “Logical thinking” meaning if malware lands on a server the staff instinctively start thinking about where they should look next (which echoes the sentiment we’ve previously heard from Rebecca Wynn in this Q&A).

The cybersecurity talent shortage makes finding people with all of these skills challenging. So, Ms. Siripattanalert suggests recruiting people from related technical shops such as the helpdesk or network team and training them. In addition, she suggests external candidates with statistical or mathematical backgrounds are trainable.

Importantly, the talent crunch isn’t just about recruiting but retention too. She recommends leaders work at improving career development and mentoring programs. Life in the SOC can be “boring” at times, so it’s important to provide opportunities for staff to grow by giving them a rotation with the pentest or threat hunting team, for example.

* * *

Her full presentation is embedded nearby, runs less than 30 minutes in length, and is worth taking some time to watch.

>>> Are you headed to the 2019 Threat Hunting & Incident Response Summit by the SANS Institute in New Orleans? If so, please do stop by the expo floor on September 30th and October 1st and let us show you how we’ve simplified network threat hunting.

If you enjoyed this post, you might also like:
The 10 Tenets of CISO Success Frank Kim Presented at RSA

*** This is a Security Bloggers Network syndicated blog from Bricata authored by Bricata. Read the original post at: