Only engineers can secure the cloud
At least for now...
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.
There’s been a large jump in subscribers in the last month. I appreciate all the support! I will continue to write a mixture of my thoughts on security engineering and various products, but I’m open to any feedback on new topics.
I’m still hiring Senior Security Engineers to join my team! If anyone is interested or knows any who is interested, please apply and/or reach out.
At this point, people might be tired of me advocating for more engineering in security. I know, but I’ve also supported operational security because I believe that cybersecurity risk management has to happen one way or the other. Not everyone has the privilege of spending engineering resources on security. That is, security is not a product feature that we can choose to delay because we don’t have the right talent. In this newsletter, I specifically discuss why only engineers can secure the cloud. To be clear, this doesn’t mean that you need security engineers, but engineering resources of some sort are required.
The power of engineering context
If I had to summarize my post in one word, it would be context. Of course, in general, context is important, but how important is it?
For better or worse, most companies are using technology more than they realize, and as a result, it’s likely the biggest threat and risk surface in a company. Although it’s possible to learn more about software engineering or technology, it’s hard to fully grasp the risks and threats without understanding how the technology is created or built. Without the fundamental skills, it’s easy to miss the nuances and not fully comprehend the options to fix the issue. When you build something, you can understand the tradeoffs and technical decisions that were possibly made in the design. Another important note is that more of the technology stack requires software engineering expertise than before. Engineering controls almost every part of the technology stack. For example, with the use of the cloud and the adoption of agile, there is a larger focus on automation and engineering operations.
Moreover, this is actually where a key disparity lies between the hacker and the security professional. The hacker is looking to exploit technical flaws whereas a security professional tends to think in terms of risk and compliance. The security engineer doesn’t solve this problem, but he/she bridges the gap. Engineers understand the technological nuances so that they know what technical mechanisms a hacker who has spent significant time might want to exploit.
Engineering influence
It’s a common perception that security behaves like auditors or consultants. They tend to find problems. Sometimes, they come up with solutions, but those tend to be presented with little or no context. There’s also been a lot of talk about “shift left.” Although I hate that phrase, it’s less focused on developers doing security or fixing problems earlier on in the development cycle, but it’s more about gathering context and influencing a set of technical decisions that make security easier. What do I mean by this?
Practically, yes, in most organizations, having developers spend some time on security is an amazing feat and a good outcome of “shifting left.” The next level is to influence engineering decisions. Of course, there will also be tech debt, but companies are always trying to revamp and redesign their platforms to reduce or eliminate that debt. Typically, a group of influential engineers take on this task at a company. The exact title varies by company, but they are known as the “staff+ engineers.” These engineers take on seemingly ambiguous but ambitious projects. What’s important to know here is that it’s hard to be invited to this group even as an engineer and thus, it’s hard to be in the room when important tech decisions are made.
What about security architects? Yes, they help with security architecture in a company and are consulted on major projects, but they are usually not in the “primary” room when this group makes decisions. The reason for this is that they usually lack a deep technical background and honestly the engineering cachet comparatively. These architects also typically aren’t involved in the actual building of the resulting proposal. Therefore, it’s beneficial to have a staff+ level software engineer who knows and understands the downstream effects of technical decisions on security because they know how to influence and advocate for security in the design phase of important engineering projects.
The message here is that it’s hard to do security if you don’t have engineering influence because you’re playing from behind. It’s tough to have engineering influence in these types of projects where engineers have limited influence themselves!
Creating realistic resource allocation
Another advantage is that engineers can better influence and understand resource allocation. That is, how many engineering resources are needed to solve a security problem? It’s possible for a regular security professional to do this, but it’s easy for them to miss the nuances and interdependencies of a security issue because they tend to lack the necessary context. For example, it might seem easy to fix a bug, e.g. just upgrading the package. However, upgrading a package might create downstream issues. It might have breaking changes, and it has to go through a whole engineering process to ensure that it doesn’t create any quality or product issues.
Companies have tried to have engineering management without engineering experience. It’s accepted that this is a failure mode. Why would we do this for security projects related to engineering then? Having an engineer makes it easier to ask and more likely to receive the resources they need to accomplish the security goals of a project. In any organization, executives and leadership like to have accurate resource allocation and understanding, so having the right capabilities is critical to achieving the desired outcomes.
The need for more tools
Above, I talked about how engineers have the right context to achieve the proper security outcomes. As a result, they are the only ones who have a chance to ensure there are proper security measures in the cloud and that it’s built for security quality and reliability.
However, does this mean with the lack of engineers, we have to take on substantial security risk? No. That’s the reasoning behind the “at least for now” comment. With proper tooling and abstractions they create, we can enable others, namely non-engineers, to build securely in the cloud. For example, we allow non-operating systems experts to build securely on top of operating systems. Unfortunately, we aren’t at the maturity level for security (and engineering tooling) to allow for this. Most security tools are designed for operational security teams because they are a bigger market. Similarly, engineering tools for the cloud are primarily designed for engineers. With time, we will have the proper tools.
Takeaway
Solving security challenges in a technology stack is tough. It’s much easier with engineering and likely only truly possible at this time with engineering talent. Currently, only engineering has the context and influence to solve these issues properly… at least for now. We should invest more in tools that abstract away the complexity of new technologies, making it easier for both security and engineering to manage these systems, but for now, we have to accept the reality: only engineers can build securely in the cloud.