4 Comments

Great Post Ross

I feel that the mindset of security leaders need to change. As you wrote, it is hard to get hired as a rookie security person.

It relates to the lack of team structure and processes. If you design and run your teams with heroic behavior and divas you need super human mates. If you have well structured work, junior people will be able to do entry level tasks and more senior other tasks

Look at the manufacturing sector, they have apprenticeship, they have workers, technicians and engineers... not a cohort of people

I think security (and IT in general) is still at its infancy regarding team structure

Expand full comment
Nov 13, 2023·edited Nov 13, 2023Liked by Ross Haleliuk

You mention what I'll call "development driven tooling" above (configuration as code, api-first,...), which is definitely one of my pet peeves. To demonstrate: when I started my first job at Alcatel Lucent (years ago now, before devops), I became so frustrated from having to configure their routers over and over again, that I wrote a program to generate the network configuration for all routers in the system. (Had I known "infrastructure as code" was coming, I'd stayed a bit longer at that job... )

Suffice to say, I'm pretty "pro" development driven tooling. The problem is, not everybody has access to the right (dev) talent, so they'll resort to a "box that does the thing", because that's better than nothing and it'll scale the talent they have better. It reminds me of the build vs buy debate years ago: the software native companies mostly went the build way, the others bought.

I'm pessimistic about the upskilling & attracting more engineers sections. In my experience: only a subset of any population has an engineering mindset (needed to programmatically scale stuff, be it config or triage) and security is no exception. Also: trying to attract software engineers is difficult: only some have an interest and as a group they are also very much in demand.

All this to say that while I would love dev driven tooling and open access to tools (god yes please!), I think there's a big incentive for vendors to keep providing a closed box which does the "difficult stuff", which you can then operate using cheaper labor and processes. Code is not the only way to scale. I'm not against that, it's the way to reach the goal when you don't have as much access to dev resources. And it makes vendors and MSSP's are very happy ;-)

Expand full comment