Transitioning GSecops from Deployment to SOC ready

We're kicking off the process of transitioning our Google SecOps functions to the Security Operations Center (SOC). Our main goal is to make this a super smooth handover, and that means getting all the technical ducks in a row before we go live.

We're looking for your insights on a few key things:

  • What are the absolute technical must-haves we need to ensure are in place for a successful transition?
  • When it comes to making our SOC as effective as possible, what are your thoughts on email notifications, dashboard views, or going all-in with SOAR (Security Orchestration, Automation, and Response)?
  • Any great blogs or documentation you've come across that could help us out here?
Solved Solved
0 2 282
1 ACCEPTED SOLUTION

Very good question and the materials above provided are fantastic.

There's a few best practices I would definitely recommend observing as you operationalize, these come from observing some of our deployments over time:

1. Operationalize SOAR. That doesn't necessarily mean go all in on automation day 1, in fact often over automating at first is often a mistake. What I mean by that is setting as a policy that anything actionable is a case and you leave as little as possible to email/manual intervention - ad hoc reports or searchers or processes. Just make sure people work a case queue out of SOAR essentially. Invest in basic enrichment and triage playbooks and what's important here is to really nail down your SOC roles and case stages as they play a huge role. Of course you can change them but the point is to be intentional. Don't cram everything in an unassigned queue unless there's a purpose. Have a point of view on the metrics that you want to measure and mock up some basic dashboards that measure things like dwell time, TTI, TRR. SOAR reporting is far more powerful then people think and if you start with a weekly report that highlights key metrics that informed your further operationalization and tuning, then you're off to a great start.

2) Observing this will naturally enforce other best practices like tuning detections and so on. Curated and other detections can be noisy and it's important for the case load to be manageable so with the transition you probably want to have a roadmap of which ones you're going to turn on alerting vs just live. It's a bad practice to just let cases stagnate without being worked so be intentional about the actual volume of cases that come in. 80/20 rule can serve great here without making too much investment in detection engineering.

3) Personally I'm a huge fan of operationalizing UEBA, although this can be tricky and can come a bit later. Assetizarion and stitching  need to be properly implemented and a lot of implementers ignore this, but it's very powerful. The idea is to be able to still gather some risk modelling on a user/asset even with live but non alerting rules, and elevate a user/asset as risky or an alert once enough signals gather.

4) incorporate your security monitoring or anything operational into SOAR as much as possible. log source down etc. One of the best implementations I've seen had an automated case every day to order lunch. It's not necessary the use case that matters but the habit to be in the platform, see the curated slice of data and continuously improve it that makes a great implementation and subsequently transformation. Alternatively if you have 5 places to look at 5 different things, then a lot of the value gets washed away.

5) Significantly skill up at least one of your security engineers with aspects of SecOps and I would most notably call out SOAR. Parsing, rules and others are important too but I find that just a single person can make a difference and make a bad team good and a good team great. Find someone capable and savvy, with good technical chops, capable of learning Python and logstash and such, and invest in their upskilling. There's ok training but it's mostly a learning by doing adventure. Incorporate them with your implementers, give them an ambitious project maybe retain someone to help them through it in the early stages. If there's one good predictor of a success that I've found in my experience, it's the presence of at least one great security engineer that truly owns and loves the system.

6) Find creative ways to deal with change management. The SOC has psychological  blockers. That's normal. Change is hard, new systems can become less productive for a short time, you have to re-wire habits, timelines are stressful etc. We found that things like gamification, hands on learning, slower and more thoughtful transition, access to an expert on demand etc are the best patterns. Sitting people in a classroom for x days and hoping they pick it up is just not as effective.

There's definitely more subtle things to do to ensure a great transition - examples that come to mind include things like critical reporting etc, but I feel like these are a great starting point. 

Hopefully this helps!

View solution in original post

2 REPLIES 2

There is a lot of great material in the community that can help with adoption.  Under Articles and Information there is the Community Blog.  Particularly John Stoner's New to Google SecOps: series that has been going on for a few years.  Beside Google Cloud Security Community there are Chris Martin's @thatsiemguy blogs on Medium.

Very good question and the materials above provided are fantastic.

There's a few best practices I would definitely recommend observing as you operationalize, these come from observing some of our deployments over time:

1. Operationalize SOAR. That doesn't necessarily mean go all in on automation day 1, in fact often over automating at first is often a mistake. What I mean by that is setting as a policy that anything actionable is a case and you leave as little as possible to email/manual intervention - ad hoc reports or searchers or processes. Just make sure people work a case queue out of SOAR essentially. Invest in basic enrichment and triage playbooks and what's important here is to really nail down your SOC roles and case stages as they play a huge role. Of course you can change them but the point is to be intentional. Don't cram everything in an unassigned queue unless there's a purpose. Have a point of view on the metrics that you want to measure and mock up some basic dashboards that measure things like dwell time, TTI, TRR. SOAR reporting is far more powerful then people think and if you start with a weekly report that highlights key metrics that informed your further operationalization and tuning, then you're off to a great start.

2) Observing this will naturally enforce other best practices like tuning detections and so on. Curated and other detections can be noisy and it's important for the case load to be manageable so with the transition you probably want to have a roadmap of which ones you're going to turn on alerting vs just live. It's a bad practice to just let cases stagnate without being worked so be intentional about the actual volume of cases that come in. 80/20 rule can serve great here without making too much investment in detection engineering.

3) Personally I'm a huge fan of operationalizing UEBA, although this can be tricky and can come a bit later. Assetizarion and stitching  need to be properly implemented and a lot of implementers ignore this, but it's very powerful. The idea is to be able to still gather some risk modelling on a user/asset even with live but non alerting rules, and elevate a user/asset as risky or an alert once enough signals gather.

4) incorporate your security monitoring or anything operational into SOAR as much as possible. log source down etc. One of the best implementations I've seen had an automated case every day to order lunch. It's not necessary the use case that matters but the habit to be in the platform, see the curated slice of data and continuously improve it that makes a great implementation and subsequently transformation. Alternatively if you have 5 places to look at 5 different things, then a lot of the value gets washed away.

5) Significantly skill up at least one of your security engineers with aspects of SecOps and I would most notably call out SOAR. Parsing, rules and others are important too but I find that just a single person can make a difference and make a bad team good and a good team great. Find someone capable and savvy, with good technical chops, capable of learning Python and logstash and such, and invest in their upskilling. There's ok training but it's mostly a learning by doing adventure. Incorporate them with your implementers, give them an ambitious project maybe retain someone to help them through it in the early stages. If there's one good predictor of a success that I've found in my experience, it's the presence of at least one great security engineer that truly owns and loves the system.

6) Find creative ways to deal with change management. The SOC has psychological  blockers. That's normal. Change is hard, new systems can become less productive for a short time, you have to re-wire habits, timelines are stressful etc. We found that things like gamification, hands on learning, slower and more thoughtful transition, access to an expert on demand etc are the best patterns. Sitting people in a classroom for x days and hoping they pick it up is just not as effective.

There's definitely more subtle things to do to ensure a great transition - examples that come to mind include things like critical reporting etc, but I feel like these are a great starting point. 

Hopefully this helps!