SOC Mistake #3: You Oppose Staff Progress

I know, I know, it’s hard to get the staff for a SOC and once you’ve got them you don’t want to loose them but this can be one of your biggest mistakes, and lost opportunities.

Bit of a spoiler here for the remaining two SOC mistakes: I’ll cover the acquisition of talent in a later post, here I’m going to mainly talk about career progression and retention.

Retention of staff within a SOC can be one of the most challenging aspects of security operations management – constant turnover means that critical institutional knowledge that takes time to build is walking out of the door; offers from competitors can continually drive your staffing costs up; and attempting to keep someone whose heart is no longer in the job within your SOC can be incredibly corrosive on the morale of other staff members.

The first question is: why do they want to leave?  You should ensure that there is a way of obtaining free-text feedback of the reasons for leaving and there should be a formal exit interview, not only with HR but also with someone from the SOC management team.  Understanding why staff are leaving is the first step in attempting to stem the tide.

Often salary and benefits isn’t the only reason people want to move on: many SOCs we’ve assessed that don’t leverage well-built use cases that optimise automation, instead relying on the analyst to perform repetitive manual tasks over-and-over again can be really demotivating, as can building use case content that offers little opportunity for tuning resulting in the analyst continually seeing the same false positives again-and-again and is worried about implementing suppression in-case they miss something (see SOC Mistake #7: On Use Cases, You Model Your Defences, Not Your Attackers).  Similarly, if an Analyst feels that their job has little impact on the organisation because the SOC Manager is focused on technology, not how their function supports the business and can’t illustrate the value of what their staff are doing (see SOC Mistake #8: You don’t speak the language of business, you speak the language of security).  I’ve seen staff leave SOCs for better money elsewhere and then return their original organisation because the new company has the problems I’ve just highlighted, but their previous employer has not.

The other major reason people move on is because they’ve grown out of their current position.  This can be challenging because as you move up the SOC staffing ladder there are less-and-less positions available.  If you have a SOC that is proving value to the business and has nailed the foundations of security operations – good log management and leveraging SIEM to detect the known-knowns, you’re ready to move onto more advanced concepts such as using Hunt Teams to drive analytics to find the unknown-unknowns.  You’re ready to embrace not just tactical Indicators of Compromise as Threat Intelligence, but to build a team focused around adversary characterisation through the collection, analysis and dissemination of strategic, operational and tactical threat intelligence.  Measurable closed-loop feedback mechanisms and workflows can now be created between your different teams so the Cyber Threat Intelligence function can inform the Hunt Teams and Content Authors of new adversaries and techniques; the Hunt Teams can drive automation of their discoveries into SIEM Use Cases to maximise efficiency; and new artefacts discovered by the SOC Analysts can be feed into the Hunt Team for historical analysis…

All of these teams need staff – Cyber Threat Intelligence; Content Authors; SIEM and Log Management Engineering; Hunt Team Data Scientists, Analysts and Analytics Platform Engineers; and the owners of the event sources.  You can create a formalised career progression plans along a number of tracks – technical, analytical and managerial and then focus on developing measurable progress against these plans.  Supporting job rotation not only helps build bridges between the different teams for the roles they are doing now, it also allows a junior member of staff to plan where their next role might sit within the organisation and then follow the appropriate career progression path.

The career progression should not be limited to roles within the SOC.  I know many SOC Managers would like to keep their staff, but if they’re going to leave for a role outside of security operations, it would be best to keep them within the organisation.  I’ve seen Analyst leave to become developers, or go into IT architecture or operations positions.  How much easier would it be to build bridges between information security and the operational parts of the business if they had internal evangelists for the security function now working within those teams who intimately understand the threats the organisation faces and how attacks can, and do, manifest themselves?

So if you follow some of the guidance in my earlier posts and offer structured career progression paths, you may loose less staff but you have to accept people do move on.  So how do you deal with the challenge of staffing your SOC, you grow not buy and this will be the topic of my next post.