How to unleash the power of an effective security engineering team

Security teams are comprised primarily of operations, compliance, and policy-related roles. Security engineering teams, on the other hand, are builders. They build services, automate processes, and streamline deployments to support the core security team and its stakeholders. Security engineering teams are typically made up of software and infrastructure engineers, architects, and product managers.

The collective security/security engineering team mindset is also that of a builder, quite different from that of a penetration tester or third-party risk management assessor. This presents a challenge to security leaders. As security engineering teams continue to grow in prominence, CISOs need to be intentional with their structure and development.

The three focus areas necessary for a high-performing security engineering team are foundational technical skills, leadership skills, and individualized soft skills.

Technical security engineering skills

Engineering is fundamentally a technical discipline, so naturally, one of the foundational pieces of this role will be rooted in technology. These are the skills security engineering teams need to have.

Understand the technical environment

That it’s key to understand and work within a technical environment feels like an obvious statement, but it needs to be said. For example, if your organization is deploying services in Kubernetes and your engineering team has never touched a container, that could be problematic. It’s not a deal breaker, but operating with a high level of technical aptitude around the technologies across the environment will positively correlate to efficiency and effectiveness.

A counterpoint to this is the intentional infusion of diversity into a team. By this, I mean diversity of skill sets, perspectives in problem-solving, and experience levels across different parts of an organization. There are of course many ways to seek and curate that diversity in a team, from gender and ethnicity to educational background, to past job experience and age. Diversity can be a powerful additive to the creative energy of a team as ideas are challenged, debated, and iterated.

However, leaders should manage diversity across perspectives and experiences carefully. Excessive levels of variation and friction in the thinking and collaboration process can have the opposite intended effect. This frequently leads to analysis paralysis where teams are stuck in a state of thinking about doing instead of doing. A similar condition that can emerge from overly diverse teams is a complex set of interdependent outputs that have linked failure conditions. In Drifting into Failure, Sidney Dekker explores this concept in more detail looking at the cultural conditions relating to complex interdependent systems.

Own the entire stack

Security engineering teams should be able to build and operate the services they produce. You build it. You run it. This level of ownership within a group is vital from a technical competence standpoint and culturally, setting the tone around accountability. Technically speaking, a team that can own its services will proficiently manage infrastructure, CI/CD tooling, security tooling, application code, deployments, and the operational telemetry emitted from a service. In addition, the skills backing all that support as a team are likely to be highly transferable in support of other groups across the organization.

Embrace the developer experience (DevX)

Teams that understand, embrace, and optimize for DevX are likely more favored. Beyond that, it will have a particular focus on eliminating friction. Friction makes things take longer and cost more, creates longer learning cycles, and can lead to frustration. Less friction will lead to things generally running much smoother.

Sometimes friction is necessary and should be intentional. An example is a forced code review on critical code before it’s merged. If that pause, review, and merge flow is based on an intentional decision, that is justified, intentional friction. If the security team pursues friction in the developer release process, it should be anchored on specific needs—a compliance control that specifies a manual review as part of change management, for example. These controls should not be deployed without careful consideration; the friction introduced to developers represents an opportunity cost that could outweigh any ill-defined risk that is being considered by the security team.

Security engineering teams that embrace developer experience as a first-class priority will need to understand the tooling and flows that go into writing quality software at different layers of the stack. Adopting that developer-first mindset might demand infrastructure or platform engineering skills. On the other hand, the output of a security engineering team may affect others who are also involved with the work of automating workflows, connecting services to one another, and in essence, instrumenting more and more of an environment together to scale. All this work helps developers move faster and with less friction. Less friction leads to more flexibility and more speed in delivery. Regardless, this is a trait and guide that will benefit a security engineering team in its productivity and fostering and cultivating the empathy of those it serves.

Security engineering leadership and collaboration skills

Security engineering teams will not be working in a vacuum regardless of their scope and project load. Working alongside and in service of others is an essential ingredient in the mission. It’s a necessary part of the whole, helping others move towards successful outcomes.

Communicating and collaborating

Security engineering team members should be able to communicate with each other and stakeholders outside the group. In addition, they should have the demeanor to work well together to accomplish shared goals. Understanding what the problems are, what the friction points are, where the constraints are, and how security-led development can assist. These probing question areas reveal what the right things are. Ultimately, getting the right stuff done matters more than simply working efficiently.

All these questions are to be explored through intentional communication and collaboration efforts. This might manifest in human-centered design principles, matrix-based resources, or a team topologies-based alignment. Of course, there is no one-size-fits-all way to communicate and collaborate amongst and across teams. No matter the approach, it’s rooted in trust building, empathy, an interest in shared goals, and a willingness to set pride aside for the mission.

Leading and influencing others

Seth Godin, a best-selling author and marketing expert, posits that anyone can be a leader—that it’s a choice, not a title. It’s about the intersection of ideas, a gap in direction, and someone motivated enough to step up.

The success of security engineering teams, like others in the cybersecurity organization, are in a position where “success” is dependent on others. It’s independent of the team’s output, as optimal as that may be. Said another way, you can’t just build it and walk away. You must listen to others, engage them, influence them towards adoption, and more.

All that requires leadership. Specifically, leadership without authority. Members of a high-performing team should be able to self-start and help guide the security engineering team itself and build and use influence outside of the group. That could happen with peer stakeholders, or it could be with internal customers of a service. Leading without authority will move the team closer to successful outcomes regardless of who it is. Bringing together strong relationships, organizational knowledge and context, and technical expertise to influence others.

Soft skills for security engineers

A security engineer and the broader team’s skill base should continue beyond communication and collaboration. In this context, soft skills will refer to the myriad of non-technical skills that are more inwardly focused and complementary to the technical skills.

Time and priorities management

There will always be more to do, and engineering capability will likely begin inviting requests to build, harden, patch, or generally start meddling with software across an environment: more capacity, more demands, more things to do.

Time is the universal constraint for all teams. Because of that, both individuals and teams must become more effective at prioritizing what matters. Being efficient but doing the wrong things does not create progress. Many techniques exist to prioritize work, value versus complexity, and focus on customer satisfaction or weighting across various factors. Customer and compliance requirements are often responsible for driving team priorities. The prioritization approach matters less than ruthless adherence to prioritizing and protecting against the endless push for requests that take up more precious time.

Adaptability

Security engineering teams should be able to adapt to changing requirements, technologies, and circumstances. This is one of the joys of working in security and technology. Things are constantly changing.

Adaptability is more than the prioritization of one task over another. Adapting the approach to a problem based on stakeholder needs. Adapting to ownership stakes based on team growth and shifting stakeholder needs and intentionally engaging a diverse group of voices in the problem-solving process. Adapting process and workflow instead of just technology.

These are all examples of ways a security engineering team can embrace adaptability. The benefit to stakeholders and the broader security organization through all of this is agility and fluidity. An agile team is a more resilient team.

Continuous learning

Building on adaptability, a team that can continuously learn new skills, organizational context, policies, and ways of working is not only wise but necessary in the fast-moving world we live in today.

Security engineering team members should be consistently evolving, renewing themselves, and building on existing mental models and experiences. Adam Grant explores this in detail in Think Again, where he explores the notion of taking mental models from past experiences, extending them, and connecting them to solve new problems. This mental model construct allows people to step into situations with similar attributes to something they may have worked on prior and begin contributing, exploring, and doing.

Continuous learning can also have a ripple effect on culture across an organization. Knowledge leads to sharing; sharing creates discussion and discussing new things sparks interest and conversation. This collective evolution of the mental models that permeate the organization and how teams engage with and relate to security moves the collaborative culture forward.

Working in this highly specialized field does not mean that a high-performing team can only focus on technology. People, problem exploration, relationship building, and prioritization are all essential ingredients of the high-performing security engineering team. Take note to invest and curate these elements as you build yours.