Three Keys to a Successful SOC

Josh-T
The KickStarter
Published in
6 min readMay 13, 2019

| VISIBILITY | CAPABILITY | AUTHORITY |

I speak with a considerable number of organizations about their security program and the tools they are using to protect their organization. I want share my thoughts on three areas that security teams are rarely prepared to discuss. I feel these three items are critical to maturing security teams and security operations centers (SOC).

Security is not all about the technology that the team implements. The security tools market is massive and it continues to grow. The success or lack of success doesn’t come down to the brand or feature otherwise we would have a very small security tools market consisting of a select number “silver bullets”. The success of a tool implementation, in many scenarios, is dependent on the deployment, configuration, and usage. I believe the leading factors in selecting tools often times come down to price, the sales team, brand loyalty, and reviews from industry analysts. The most successful security teams are not built on the cheapest products, best in breed products, and rarely work like that fancy demo. I like fancy PowerPoint presentations too, but it goes like the golf saying “Drive for show, putt for dough”. You can see the best presentation or hear the greatest sales pitch ever, but if you can’t implement a product and align to your process than it won’t help you win. Security teams rarely find success in buying the brand name or using products because they have always liked the brand (fanboys). Successful teams are built on mature processes, procedures and metrics that matter.

Security teams and security operations centers come in all shapes and sizes. Time management, security awareness, patching, vulnerability scanning, and publishing company policies factor into the success of any security team. But there should be a starting point for building and breeding success. I start with three keys that are intertwined with just about every aspect of security in an organization.

Visibility

Does the security team have visibility to the information and assets inside the organization to effectively protect, detect, and correct a security incident? Ask a CISO what their mission is and they will tell you they manage risk, compliance, prioritize the company security requirements, and their team mitigates security incidents. Every single part of their mission requires visibility in the organization.

Note: I realize there is much more to the mission, but I am siding with brevity for the moment.

How can the security team identify a threat targeting an asset if they don’t have network visibility. Simple access to information like Netflow will enable the SOC to analyze and understand communications between assets on the network. Visibility to the communications lead into visibility to assets and gaining an understanding of what is managed, rogue, BYOD etc. A security team cannot easily protect what they don’t know about! Unknown assets cause longer investigations and limit situational context. Do the SOC a favor and tackle asset and device identification early for them. There are many ways to approach identifying assets, segmenting assets, building an asset inventory and discovering new assets.

Set a goal to gain visibility to network traffic and begin understanding the assets on the network. Gain visibility into common connections (IP, Port, Protocol, times) that the devices are establishing on the network. This visibility will help build the security team baseline.

Example Scenario:

Identify database servers and gain understanding of the IP addresses that connect to the databases. Once the IP addresses are vetted, identify the port/protocol. After you know the common connections and the times, you will be able to identify anomalies. If a new device with an abnormal IP address suddenly connects to a database the SOC should have this visibility and be prepared to investigate. It may be more obvious if that abnormal IP is attempting to connect on a different Port or protocol.

Laptop in LAN with an IP in DHCP scope attempts to connect to SMB on port 445 to an MS SQL server that normally has connections from static IP addresses in LAN on port 1433.

Capability

SOC capability questions I ask typically result in blank stares and tilted heads. The question I ask “What capabilities does your SOC have?” One of my measures for maturity starts with that one question. I try to understand what the SOC is equipped to do. If the team doesn’t have the capability to detect a random IP in DHCP scope establishing a non standard connection to a database server, then it tells me a lot about the maturity of the team. My questions do reveal some information about security tools, but the answer I am looking for should include process, playbooks, and metrics.

Think about the following questions:

  1. Does your security team or SOC have the ability to protect, detect, and correct malware events that are successful and unsuccessful?
  2. Does your security team have a process for all malware events?
  • Malware detected and blocked, cleaned, quarantined
  • Malware detected and failed to block, clean, quarantine

3. Does your security team measure malware events?

  • Blocked, cleaned, quarantined
  • Failed block, clean, quarantine
  • Blocked at perimeter vs blocked on endpoint
  • Number of detections per filename/ hash
  • Total number of detection trending over time with standard deviations. This week is xx% lower than previous xx weeks…

4. Does your security team understand where they detect malware? Perimeter, zone, workstation, server, etc…

  • Blocks on servers compared to user devices
  • Blocks at workstations vs NIPS or web proxy

5. Does your security team have a continuous improvement process to increase or strengthen defenses?

  • Blocks on workstations but not at perimeter, go enhance perimeter detection via policy or better technology

These are just a handful of questions for just one of many capabilities. These questions should lead into developing or refining process, policy, procedures, measurement, and build on gaining visibility.

Sadly I believe that organizations are buying products / tools and they believe that fulfills capability and the mission stops when the deployment is complete — ish. Why, lack of time, resources, skill, and maturity.

Authority

Providing a security team with visibility and establishing capabilities will get you to the goal line, but you cannot cross the line unless you give them authority. I see security teams crumble and live in a state of defeat more than I want. Imagine performing an investigation and all details lead to a true positive and require quick response, but the SOC can’t access the asset or make emergency changes. SOC teams need the ability to stop an attack.

An analogy to consider. A person is shot and emergency responders are dispatched.

  • What if the authority to call emergency responders (911 for many countries) was limited. Helping those in need would be slower and dramatically lower in volume.
  • What if the emergency responders didn’t have authority to clear traffic using lights and sirens? The time to respond and provide care would be higher and lives would be lost.
  • What if the authority to triage the patient wounds was not provided to emergency responders? If medical care was limited to doctors and nurses in a physical emergency room and responders were only tasked with transporting the patient, then lives would be lost.
  • What if the authority to perform CPR on a patient who stops breathing at the scene of the crime or during transportation to the emergency room? Again, lives would be lost
  • What if the authority to rush a patient into an emergency room and bypass other patients sitting in the waiting room? Lives would be lost

SOC teams might not be saving a human life in the literal sense, but not having the authority to respond to a security threat can have devastating impact to the business. This happens every day and the results are published in the media frequently. Work on establishing playbooks with process and procedures that dictate how, when, and to what extent the SOC team has the authority to effectively respond.

When you combine these keys together you have a recipe for success in building and maturing a security team.

1. Give the authority and capability to isolate devices on the network when security teams have visibility to identify suspicious and malicious events and rogue devices.
2. Give the authority and capability to change policies and rules in security tools to stop an attack that was discovered through visibility to suspicious and malicious events.
3. Give the authority and capability to access assets and thoroughly investigate suspicious or malicious events that are detected (through visibility).
4. Give the authority and capability to access information about the assets in the environment so the team can build context, prioritize. and a deeper understanding during an investigation.
5. Give limited but necessary authority and capability to disable accounts, shutdown services, or shutdown systems in the network to stop suspicious or malicious events that are detected (through visibility).

--

--

Josh-T
The KickStarter

Cyber security expert who has suddenly fallen in love with learning Python.