SANS ISC: Is Your SOC Flying Blind? - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Can you imagine being pleased to learn that the pilot of your next flight had anything less than full visibility into the operation of the next airplane you board? Why would you settle for anything less for your Security Operations Center (SOC)? How long can your you stand for your SOC team to not know there is a problem in your environment? 

When building a SOC several years ago, I recall making screens ready in the event of an unexpected, yet necessary VIP tour. The intent of these is to impress those dignitaries by displaying cool things that are happening on your network. After you have finished impressing your VIPs, what actionable information should be displayed in your SOC to help them respond to threats in your environment?

Consider spending time this week ensuring your SOC wall is populated with meaningful screens that add value to your SOC by asking these questions.

• Which security controls are not sending data to your SOC?
• Would your SOC know when your most critical systems stopped sending their logs?
• What is the baseline of traffic volume in and out of your sensitive network zones?
• What is the health status of your security agents?

Share what you find valuable on your SOC wall!

 

Russell Eubanks

ISC Handler

@russelleubanks

SANS Instructor

Learn more at the upcoming SOC Summit!

 

I will be teaching next: Implementing and Auditing the Critical Security Controls - In-Depth - SANS Amsterdam January 2019

One thing I've found useful are security-specific nagios checks and dashboards. For instance, I banged out some checks that would watch the rate of syslog events from various critical nets. This sounds silly but if that value ever fell below a certain threshold or hit zero, clearly something is wrong. I also had nagios checks for all the capture NICs on all the snort sensors. If those NICs ever dropped blow a minimal threshold or went above a threshold, either might be interesting enough for a human to get involved. Simple. But after all, if a tree falls in the forest and the snort sensors aren't seeing any packets... There's LOTS of people out there who forget to monitor their security infrastructure to ensure it's actually operating properly.

I also had a dashboard that showed the WAN traffic with "weathermap lines" that'd show direction and rate of traffic flow as well as icons that'd change color if, say, an interface started showing more errors than "normal" - sortofa WAN traffic lava lamp. I'd set it up for the netops team but found it useful in SecOps as well. You quickly get a feel for what "normal" looks like and ab-normal pokes you in the eye - it might just be a busy net or someone stupidly mirroring TBs of data over the WAN or it might be a compromised system running OpenVAS scans.

I wrote my own syslog daemon (small budgets 'n all that) which parsed and indexed log data into an elasticsearch DB. But it also let me write some log analysis modules that looked for sequences of events and which could log their own "A human might want to look at this" sort of log event. Having a kibana dashboard or three summarizing "interesting" (tm) things seen in the logs would be of value in a SOC. And VIPs can usually "get" a pie chart showing IPs hitting your DNS filters and what they were querying for, or a multi-line chart showing the types of DNS queries being seen (ie, a big spike in MX record queries would be "interesting").

Sooooooo many opportunities here....