Frankly Speaking 8/30 - Security is easier with engineers

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.

I can’t believe it’s almost the end of summer. It definitely felt like more of a normal summer compared to the past. Traveling has actually given me a lot more ideas for my blog, which is nice. So, I’m not worried about a shortage of content. As always, if you’re ever interested in chatting about any of the topics, feel free to send me an email.

Please consider using your professional development budget to sign up for a paid subscription. It helps me keep going with this newsletter!

LET’S BE FRANK

I restarted my blog by discussing the responsibilities of a security engineer. I’ve also discussed some reasons why security needs more engineers. That post describes how security engineers can create engineering-based solutions that can improve security operations. This post, however, dives a bit deeper into why having software engineers work on security can make certain aspects of security easier. It also resolves and refines some of my thoughts on why most security tools on the market suck.

In this week’s newsletter, I’m going to dive into the following:

• Some specific examples of how programs can improve operationally with engineering help

• Why almost all security tools don’t make sense for security engineers

• What the next generation of security tools will look like

How engineers can improve security operations

I’ll give a few examples of how engineers can improve security operations because of the context they possess. Honestly, it’s no different than any other operational or product problem that engineers need to solve.

Don’t get me wrong. Security is not easy, but it’s not as hard as security professionals and others claim it is. I don’t think it’s any harder than software engineering, but like with software engineering, anything can be further complicated and made more difficult when there are bad processes and a lack of context. In engineering specifically, lack of context is a common cause of difficulty in engineering. Teams commonly work in well-defined silos, but when they have to interact with a part of the product/codebase they don’t have familiarity with, it can make the work difficult. If the company doesn’t have good processes, that can make the situation even more complex.

In many ways, security is similar. Most security teams are completely isolated from engineering teams, and engineering teams don’t want to work with them. A lot of the tension stems from goal misalignment and misunderstanding between the teams. It also doesn’t help that many times, security teams don’t empathize with the struggles of engineering teams. For example, many security initiatives slow down engineering, and consequently product, delivery velocity, but security doesn’t try hard enough to create a compromise between security and engineering velocity.

However, it’s not security’s fault! It’s the organization’s. As IT has shifted to DevOps and filled DevOps with software engineers, they assumed the relationship between DevOps and security would magically remain despite now the skillset change. The leadership thought that security would work the same with engineers as it did with IT professionals. Surprise! They don’t.

Most leadership teams don’t understand why the “shift left” trend creates operational efficiency for security. It’s not purely a technical issue, but there’s also a significant people element aspect — having engineers work with engineers is just easier. Although possible, it’s hard for traditional IT security professionals to fully empathize with engineering without having done any software engineering.

This isn’t an impossible problem to solve. The obvious way is to make the security team have mostly engineers, which is why this post is titled “Security is easier with engineers.” However, not every company has the privilege to do this. I don’t have any thoughtful alternative solutions as of this newsletter, short of getting the security some engineering experience in one way or the other. I will leave this as an open question that is worthy of discussion.

Other than what I described above, why does having engineers make security easier? Well, most tools are premised on the fact that security is isolated and has limited to no visibility. With context, the security team can be productive without having to coordinate or rely on other engineering teams for support.

For example, CSPMs provide visibility around configurations and cloud assets. However, if your team had engineers, they can work productively with DevOps to learn their Terraform configurations and access cloud consoles to figure this out. Of course, this doesn’t eliminate the need for a CSPM because there could be many assets to monitor, but at least, it creates a good starting point. The security team has context on the important assets and where to find configurations (and the files where they live). This way, they can create more effective cloud security. In addition, the security team doesn’t have to rely on DevOps to ensure a successful cloud security posture management program, thus also reducing the amount of required DevOps resources and interruptions.

Similarly, for application security, security teams with context on the application can best identify which vulnerabilities are easy or difficult to fix and what teams they belong them. Triaging would be a lot simpler. Moreover, with proper context, the security engineering team can perform these smaller fixes themselves!

Overall, if the security team can do its job with limited engineering interaction, that should be an operational win for the company!

Why most security tools annoy security engineers

I touched on this in the section above. Most security tools are meant to create visibility for the security team without having to interact with engineering. It’s hard to do anything in security when other teams don’t collaborate to provide the proper context. The issue with security is that they are also incapable of getting the context themselves. As a result, for many security tools, the main value proposition is to create visibility so that security can perform the right actions to secure the company better rather than shooting in the dark.

However, with security engineers, that’s unnecessary. They can get the visibility and context themselves. They know how to work with engineers in a productive and effective manner to gain context with minimal disruption. As a result, the main value of these tools goes away. Many times, security engineers even have to configure these tools to be much less noisy and create processes around them, so it actually requires more time than building the tool themselves. That’s why the value of these tools to a security engineer is not high. The main product focus of the security doesn’t provide value, and it doesn’t help that they can scrap together functionality within existing tools and not have to learn a new tool.

What the next generation of security tools will look like

I believe the legacy security market will continue to be big, i.e. a market where security teams don’t have engineers. However, as we train more security engineers and supply-demand for them becomes similar to software engineers or at least more stabilized, companies will realize that security is no longer a cost center but has similar value to a DevOps team. The next generation of security tools will reflect that new reality.

With that said, we will see more platforms where security is not the primary focus. Many engineers are already familiar with certain tools and would love if those tools could be used for a security use case. For example, Datadog is a good example. It already provides observability and visibility into both the infrastructure and application. If it can be re-purposed more easily, we can see current generation CSPMs losing a ton of value or becoming irrelevant. Why do we need another tool to monitor our infrastructure when one already exists and is centralized? Datadog also performs well in the most important function for cloud security posture management — monitoring!

You can probably think of other examples where it makes sense to add a security use to a tool, such as DevOps incident response tools having a security use case or log infrastructures being used for security logs. The list goes on. The reality of security platforms is that security will be a large use case, but the tools might start with a broader set of engineering use cases.

In my opinion, this might be better for the industry. It allows for better operations and better tool consolidation within a company. As an engineer, I think a lot about value creation through operational efficiency, and value capture will happen organically. Unfortunately, too many security tools today think primarily about value capture without caring too much about how that value is created or sustained.

Security is hard, but it’s not an intractable problem. If we include engineers into the mix, we can greatly simplify it so that we can focus on the most complex problems just like how we do in many other parts of engineering. So, I encourage organizations to think about building security teams with engineers and put in the effort to “shift left.”