Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Database Security
Authentication
Mobile
Privacy
Compliance
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
5 Pitfalls to Avoid When Running Your SOC
Newest First  |  Oldest First  |  Threaded View
Jeff.schilling
50%
50%
Jeff.schilling,
 User Rank: Author
12/22/2014 | 3:26:07 PM
Re: Centralized planning &decentralized execution
First, thank you for your service as well.  I offer one clarification to your comment that a SOC is reactionary only.  At FireHost, our security methodology for our SOC is to Protect, Detect, Respond, Recover.  You may recognize that from several DOD and NIST standards as the model for cyber security operations.  I believe that a SOC should be as active in protection or hardening operations (Vulnerability discovery, Patch management direction, Security Control tuning) as they are in detecting and responding.  Some organziations may make this outside of the scope of the SOC, my personal opinion is it belongs in the SOC.

 

To answer your question, I think I am on the same track as you with my SOC, though I don't see it as a "poor man's" SOC.  I think you have and brilliant idea.  Most SOCs have Security Analysts with basic security experience and skills that track incident handling.  I am filling my SOC positions with people with an Incident Response background, who understand how to do host level and network forensics.  I am in a unique position in that my SOC protects our cloud environment.  Our SOC analysts routinely work with customers to examine their servers they host with us as we discover indicators of compromise.  For me these IR skills are required for my SOC Incident Management team.

 

As I mentioned in a previous response, recommend you set up an operational process that allows you to daily review the tactical information you receive from your security operations and controls.  We use the OODA targeting process (Observer, Orient, Decide Act).  We do both Daily and weekly OODA huddles and targeting meetings to ensure we are actioning anything we learn through Threat intelligence or discover/detect through security operations.

 
Jeff.schilling
100%
0%
Jeff.schilling,
 User Rank: Author
12/22/2014 | 2:25:11 PM
Re: Centralized planning &decentralized execution
Great commentary.  At FireHost, we subscribe to the OODA Targeting process (Obeserve, Orient, Decide, Act).  Think of these as swim lane processes that are constantly in motion on a perpetual basis.  We have twice daily OODA huddles where our Incident Management team goes over tactical infomation exchange to ensure synchronizaiton between the Incident managment team, Security Device managment and the Vulnerability Threat Management team.  Then our weekly OODA Targeting meeting is what I would describe more of a "week in reveiw" and gets into the first stages of problem management if you follow the ITILv3 process.  Our Audit and compliance team manages our GRC process that our weekly OODA meetings feed problems to the risk register for more complex problem resoultation.  In other words, the secruity issue which require more than the folks that work for me to solve.

 

 
ODA155
50%
50%
ODA155,
 User Rank: Ninja
12/22/2014 | 2:10:54 PM
Re: Centralized planning &decentralized execution
@Jeff.schilling,... THANK YOU FOR YOUR SERVICE. I'M also U.S. Army, retired... although my day-to-day was not information security or even technology, I got into this after I retired. What you described as a centralized plan development and decentralized execution is at a high level exactly how I was expected to do my job. Sure, the strategic thinking\planning is always done at a higher level, but if I'm the guy on the ground, you have to give me the leeway to make decisions based on what I see locally, not how you see in from the comfort of your "Press Box" (I like that). Also, I find "the military mind" is a perfectthing for InfoSec, we've already been conditioned not to trust anyone :-).

One thing I think people should know and understand about a SOC, it's first role is totally reactionary for the purpose or monitoring, unless it's been designed with some kind of offensive capability. And the response to any emergency is only as good as the preparations, operational policy and procedure... standards, guidelines and how well these defences were prepared and maintained. And the folks of the SOC need to understand those same things because it will give them a better view of the big picture if they know for instance what exactly is being fed into the SIEM or when\what was the last FW rules change and does that CVE just released contain anything that can be used to exploit any critical or user systems.

One question, I just finished a SIEM integration, we cannot afford a SOC, but I'm trying to build a "poor man's SOC", if you will. I want to plug our IR-Teams into the SIEM, get them training on that so they can have that situational awareness on a day-to-day. What else would you recommend?

Thanks again!
aws0513
50%
50%
aws0513,
 User Rank: Ninja
12/22/2014 | 11:56:16 AM
Re: Centralized planning &decentralized execution
Great article Jeff!
As a retired military member, I can relate to all you provided.

My management of regional or field level security teams has always started with communications effort.  LOTS of communications effort.

I have established an ops-tempo for security services around a morning "stand-up" conference call with all of the security team leads.  During this meeting, we discuss the following items:
  • Status of operations including any personnel shortages
  • Current issues and alerts
  • Operational hurdles that need my interaction/intervention
  • Quick lessons learned
  • Project/tasker statuses

The meeting is limited to 30 min.  Anything I think is too complex to resolved quickly is promptly offboarded to separate discussions/communications after the meeting.  The general idea is to establish a constant presence with those people who are in distant locations, even for a few moments. 

The real benefits of this daily stand-up are
  • Dramatically improved situational awareness of security and operations status.
    There are times that I know about things going on that other executives are not even in tune with.
  • Established esprit-de-corps and cross-domain team mindset among all members of the security teams.
  • Stronger establishment of policy and standards practices among all teams.
  • Ramped up knowledge sharing and synergistic activity among all security team members.
  • Biggest win: a demonstrated effort to let other security teams know that I/we are there to help sort thought tough challenges.  Every day, team leads have a chance to bring concerns to the table and I/we always make an effort to give prompt response.
  • Very few timeline "misses".  We still have timeline pushes, but we usually identify those situations early enough to manage them.

Some would say that an every day meeting is too much. 
I say it is not enough.  Too often I have seen things that could have been quickly resolved if they were bought to the fore as soon as they were identified.  The old addage "that will have to wait until our next meeting" has lesser associated risk. 
The perception of the entire team by our customers is "efficient and effective" service.  That will always be a goal.
Jeff.schilling
50%
50%
Jeff.schilling,
 User Rank: Author
12/19/2014 | 10:58:05 AM
Re: Centralized planning &decentralized execution
Marilyn, thank you for your question.  The connectivity between a Global SOC and regional SOC is a tough problem, but not insurmountable with a good network engineer and a platform integration team who understands how the information flow needs to happen between the organizations.  Believe or not, the bigger challenge is establishing governance and business processes that dictate how you manage this construct.  That is an article in and of itself.  It really comes down to building a common set of security values across the global organization, grounded in policy, procedures and standards.  Once you get that in place, making the electrons flow is less of a problem.

 
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
12/19/2014 | 9:56:03 AM
Centralized planning &decentralized execution
Jeff, Great insights. But I wonder what kind of communication exists between the central and regional teams. Can you elaborate? 


COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/14/2020
Lock-Pickers Face an Uncertain Future Online
Seth Rosenblatt, Contributing Writer,  8/10/2020
Hacking It as a CISO: Advice for Security Leadership
Kelly Sheridan, Staff Editor, Dark Reading,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 New Cybersecurity Vulnerabilities That Could Put Your Enterprise at Risk
In this Dark Reading Tech Digest, we look at the ways security researchers and ethical hackers find critical vulnerabilities and offer insights into how you can fix them before attackers can exploit them.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17475
PUBLISHED: 2020-08-14
Lack of authentication in the network relays used in MEGVII Koala 2.9.1-c3s allows attackers to grant physical access to anyone by sending packet data to UDP port 5000.
CVE-2020-0255
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2020-10751. Reason: This candidate is a duplicate of CVE-2020-10751. Notes: All CVE users should reference CVE-2020-10751 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-14353
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2017-18270. Reason: This candidate is a duplicate of CVE-2017-18270. Notes: All CVE users should reference CVE-2017-18270 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-17464
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2020-17473
PUBLISHED: 2020-08-14
Lack of mutual authentication in ZKTeco FaceDepot 7B 1.0.213 and ZKBiosecurity Server 1.0.0_20190723 allows an attacker to obtain a long-lasting token by impersonating the server.