Frankly Speaking 9/13/22 - Most security reports suck... and how security can deliver value.
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.
Two personal plugs! First, we are looking to hire a senior engineering manager for my team. If you know anyone who is interested, please reach out to me, and I can tell them why working at dbt Labs with me is awesome!
Second, I will be speaking at this LinkedIn webinar on Wednesday 9/14 at 10 am PT on what I believe is the future of security engineering with the CEO of one of my former portfolio companies, Appdome. Please join! I will also write a follow-up blog post about our conversation.
LET’S BE FRANK
A lot of traditional security practices have been on my mind, and I’ve been thinking more about how to scale them effectively. One of my biggest irritations is security reporting. Too many times, I’ve seen security teams justify their existence by showing off their long reports even though most of the contents don’t have proper context, making them feel irrelevant.
In this newsletter, I’ll talk about the following:
Why current reporting is outdated and creates friction
How security teams can use these reports and provide value
How security tools can fix their reporting
Current security reports are obnoxious
Let’s be honest. Does anyone actually like security reports? I don’t even think security teams like them. Yet, almost every security tool makes their reports a huge selling point. However, many of these reports are just a dump of either the audit logs or alerts and publicly available remediation information. Vulnerability management tools are the worst offenders along with cloud security posture management tools.
Many security teams use these long reports to justify their existence and value, but I think that’s an outdated mentality. I strongly believe that most sensible boards and executives believe in the value of having a strong security team and posture. If they don’t, these long reports showing issues will likely not convince them otherwise because they just show there is a problem. The goal and value of a security team are not to only detect relevant problems but also to solve them. I’ll touch on what this means later because it’s commonly misconstrued.
Unfortunately, many security teams just take the output of these reports and send them over to the corresponding engineering teams. Now, the engineering teams are tasked with fixes with minimal context and numerous questions. Do they need to fix all these alerts? How do I prioritize what to fix? What is the business impact of these problems?
This is the source of the friction because these aren’t supposed to be the types of questions individual engineering teams should be answering. As a result, engineering teams feel like they are doing the hard security work of figuring out how to incorporate fixes into the roadmap. In some ways, they want guidance from security teams, but security teams aren’t incentivized to provide clear guidance. It’s easier for engineering to fix all the problems. However, this isn’t practical.
Engineering teams have a mode of operation, and these reports are unpredictable and disruptive because it’s not clear how much work they generate. Engineers hate unpredictable work! It affects road mapping, resources, etc. This is another reason why I believe security is easier with engineers — they understand how engineering teams operate and can align with them appropriately.
It’s an unfortunate truth that a lot of security work is unpredictable, and the hard task, and thus the value, of security teams, is to provide some predictability. In some ways, that’s why security teams having their own engineering resources (through the hiring of engineers) is the best way to handle this. For example, minor package bumps can be done by security engineering teams, and it forces the security team to understand the engineering process, which also makes them more empathetic to the current challenges facing the engineering organization.
Not all companies have the privilege to hire good security engineers or any security engineers at all, so what can they do?
Security needs to do security work…
It’s common to fall into the trap of building a security program where you buy a lot of tools and then generate reports. However, it’s important you provide value and solutions. I talk about this a lot, but what do I mean by this?
Let’s use vulnerability management as an example because it tends to be one of the more contentious areas. The application security tools create many reports about vulnerabilities. However, many of these vulnerabilities are not actionable. They either don’t have a fix or have a breaking fix. Instead of dumping this report into engineering, security should filter and decide what vulnerabilities need to be fixed. For example, if a vulnerability isn’t publicly exposed and doesn’t have a fix, it’s probably safe to ignore it because there’s not much to do except remove the library, which isn’t practical.
In this situation above, security acts as a filter between the tools and the engineering team. Security has more context on the risk and security-related issues than engineering teams. But, what about ambiguous situations? Security should provide its perspective and discuss it with the engineering team and possibly the leadership team to understand the business implications. Instead of forcing a solution, they should make it part of a larger business discussion. In the end, every business has to take risks, and security issues are no different. A company has to take reasonable security risks, and it’s important to figure out how that aligns with the business goals of the company. This type of alignment will substantially reduce friction and provides value because security is contributing to business solutions. It’s not just an operational team anymore that is rigid in its goals, e.g. have no vulnerabilities, install all tools to detect issues, etc. Moreover, it allows engineering to focus on implementing technical solutions, which is work that they know how to do and is thus more predictable.
Reports are a starting point to surface all potential issues to the security team, and the security team can provide value not by sending these reports but by analyzing and filtering them to find the most relevant ones to send to engineering and working with them to fix any issues (or security engineering can do it themselves). Moreover, they need to set the framework so that these fixes align well with the business and its goals. This is hard but where I believe security can demonstrate substantial value as they can decide how to provide security while maintaining engineering velocity, leading to better organizational resourcing.
In the end, security needs to provide an interface to provide actionable items for engineering so that engineering can be enabled to reduce security risk in a business-aligned manner. To be clear, engineering should be security conscious and be enabled to build secure products, but engineering should never have to do security or make security decisions!
How security tools can improve reporting
Here are some ideas on how security tools can improve reporting:
Prioritization. I know some tools have prioritization based on certain criteria. However, there should be ways to allow security teams to influence the prioritization score based on their business needs.
Customization. Some tools allow for report customization, but it should be easier to customize reports to contain the findings that the security team wants. Also, tools should allow teams to include their own information.
The “critical, high, medium, low, etc.” classification is vague. There needs to be a better way to classify vulnerabilities and findings.
Less is more. Have less information by default and allow a team to adjust what else is included.
Security teams shouldn’t just be tool operators. They should use the tools to achieve their objectives of informing and aligning with the company on risk and goals. Only this way can the security team enable engineering and deliver value.