A New Solution to the Cybersecurity Skills Gap: Building Security into Operational Teams

Security leaders have been raising the alarm for years about the ongoing cybersecurity skills shortage. Even as cyberattacks become increasingly sophisticated, and frequent, corporate defense teams are having more trouble filling open positions. The problem can seem insurmountable, but it shouldn't be.

One solution that few companies have considered is extricating the security team from operations. Consider how much less daunting the skills gap problem would look if corporate security narrowed its focus to governance, oversight, supervision, and auditing, while pushing the implementation and management of security systems out to the operational teams that use them.

Such a change would be dramatic. The corporate security function would shrink substantially, both in staffing and in the number of specific tasks it's responsible for, but it would become more strategic — and more effective.

Today's Less-Efficient Approach

The typical security team today involves themselves in all manners of operational activities. For example, when the development group is creating a new application, security staff may get involved in design details, settings for underlying technologies, and determining which users can access development servers.

But the centralized security team may not immediately have the operational knowledge to make those decisions. They may have to dedicate significant time to understanding the business drivers behind the application, the structure, and expertise of individuals on the development team, etc.

The development team managers already have the requisite expertise in operational aspects of putting together their solution. The corporate security team has expertise in the controls needed to prevent specific attacks. Why not let each group specialize in their core competency?

How It Would Work

As I envision it, the security team could take responsibility for establishing, at an abstracted level, the controls needed to protect the application, both during development and after launch. But they could hand off responsibility to the development group for building those controls. The development team could decide which security software and configurations they need, set specific security policies, and determine user permissions. Then, the corporate security team could inspect the development environment — and the resulting application — to ensure that the requested controls were implemented and are performing as expected.

This approach would put detailed decision-making in the hands of the people closest to those decisions. The security team would need to know a little bit about the technologies the development group uses, but mostly they would just need to be controls experts who set expectations for the security outcomes the operations groups should achieve.

Consider access control. How should people get authenticated to enter the company's development environment? What credentials are sufficient to prove they are who they say they are? It makes sense for the corporate security group to own the high-level governance of access control, but they would need to learn a great deal about the development environment and development team to effectively answer these questions. Meanwhile, people on the development team already have this knowledge. Letting them make the decisions down in the weeds of their group's access control policies is only logical.

Development processes are one example. The security team I'm envisioning wouldn't be involved in building networks; they would provide control requirements to the networking team, then make sure those requirements were followed. In a cloud setting, the security team might set high-level expectations, then do inspection scanning, looking for anomalies. But that would be the extent of their involvement in cloud security decisions.

What This Change Would Mean

Obviously, my vision would require a total restructuring of IT. In some ways, it would move security activities more toward where they were a quarter century ago. Back when security was usually not a separate function, companies taught security best practices to operational subject-matter experts throughout the organization. Expertise was widely distributed, but security was only a small slice of anyone's job responsibilities.

Consolidating security activities into a centralized function has created experts who specialize in the subject. These highly qualified and hard-to-find professionals should focus on setting the overall direction of the company's security strategy, dictating the controls necessary to prevent certain types of attacks, and providing governance and oversight to ensure those controls are effective.

I would like to see the industry re-evaluate whether other, more operational responsibilities — routine firewall maintenance or configuration of SaaS apps, for example — are appropriate for the central security group. I think those tasks are better suited for the individuals who are connecting, architecting, designing, implementing, and configuring the company's systems. They have the expertise to make correct decisions about securing systems and processes with which they are intimately familiar.

An organizational structure that shifts security decisions out to operations groups may shrink some of the day-to-day responsibilities of the security team. However, it would also elevate the team's level of decision-making, free staff time for more strategic activities, and provide a tidy solution to the perpetual challenge of finding professionals with security-specific credentials.