Frankly Speaking - Security is not everyone's responsibility!

Don't let the security organization be lazy.

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

This post voices my frustration regarding how technical leadership perceives security. In my opinion, this notion of security being everyone’s responsibility stems from three main and flawed assumptions. First, security expertise isn’t necessary for the company. Second, there’s no business reason to have a dedicated security team. Third, even with a dedicated security team, they cannot handle all the issues and require support from other parts of the organization, especially engineering.

Let’s unpack some of these assumptions. For context, my belief is that everyone, especially engineering teams, should care about security, but it’s unreasonable to say that everyone should be responsible for security. The nuance here is essential and related to the assumptions mentioned above.

So who is responsible for security?

Security is responsible for security! Although this might seem obvious, it’s not a commonly held belief. The ownership of security should solely land on the security organization. Having multiple owners is worse than having no owners, and by pushing responsibility onto other teams, the security organization risks having an impasse.

So, why do security teams typically want to push responsibility onto other teams? The reasoning behind it is actually valid: it’s impossible for security to cover everything. However, there is an analog to security, which is QA. It’s impossible for QA to cover the testing, but they don’t push the burden of testing onto everything. Sure, teams create their own tests, but QA is responsible for creating the framework to allow individual teams to ensure the quality of their code and product. It is not each team’s job to figure out how to test their code. Their job is to conceptualize the tests, and QA helps make them a reality. Also, QA’s job is to ensure proper test coverage and to ensure teams are using the testing framework effectively. In essence, QA is responsible for the “health” of the quality program.

Similarly, security should create the framework and standards to enable engineers to build securely. This way, engineers have the proper context to write secure software. Security has to create the proper processes to get engineers to care and make it easy for them to do security. That is their responsibility.

Why do organizations struggle with security ownership?

To take a step back, many organizations either believe that the security team should own everything and always be imposing security, or they believe that there’s no strong need for security as a function or believe that security is primarily an operational function rather than an engineering function. I don’t blame them because security has traditionally been an operational function, mainly being perceived as insurance. However, given the increased frequency of hacks and greater demand from customers for trust, security has become a growth and engineering function. Yet, the mentality around how security engineering should operate hasn’t been fully resolved.

Regardless, it is unwise to ask engineers to do security without another responsible party. It’s true that engineers can figure out security, but it will distract them from their core deliverables — quite frankly, it’s too much cognitive load. This belief stems from the fact that some engineering leaders believe security is “easy to learn,” but history and data have shown this isn’t true. In the same way, engineers don’t have to worry about infrastructure, DevOps, and QA. They also shouldn’t have to worry about security. Moreover, they lack the context to understand the risk and priority of certain security issues, which further creates frustration and delays deliverables.

In many ways, security can act as an internal service. I hesitate to fully classify them as this because product security is customer-facing and critical to growth, especially in certain sectors like healthcare and finance.

Security needs to collaborate with engineering

The question now becomes so how does security make this work? I’ve advocated in past posts as well as above that engineering teams rarely have sufficient context to make an informed security decision. Similarly, it’s ineffective for security to impose on engineering without proper engineering context. At the same time, it’s difficult and too much cognitive load for security to gather substantial amounts of engineering context.

What’s the best path forward? They have to thread the needle like DevOps and QA by creating frameworks and abstractions that make security easy. Rather than imposing security standards and requirements on security teams, they need to collaborate with teams to make an important calculus: balancing business and security risk.

There is a business risk whenever security delays and/or vetoes a product feature or deliverable. The goal of security is not solely to make decisions. I would argue that security engineering should not be decision-makers but rather problem-solvers. They should work with engineering teams to find solutions that minimize both security and business risk. That changes security’s role to more of an engineering-focused function than an operational function. Of course, there are rare instances where security should veto something. This model makes security more internal service-like. Security can also be product-facing in certain types of industries where it could help overcome growth barriers, like finance and healthcare.

Conclusion

Security should take ownership of their domain, and engineering teams shouldn’t let them take the easy way out by either allowing them to impose arbitrary security standards and requirements without sufficient context. Similarly, it’s the job of security to show its value by partnering with engineering teams to show they are needed and deliver product/platform value rather than taking an operational role. This way, it’s clear to executive and engineering leadership that security plays a valuable role, and having engineers just “do security” is not an effective option.

Security engineering plays a big role in this, and I would even argue that security teams with a strong security engineering function are necessary for this operating model to succeed. Security should see themselves as problem-solvers rather than decision-makers and enforcers. This is a change in the way security typically operates, but that’s ok. Security needs to adapt and is long overdue for some change!