Frankly Speaking - Why security is easy

The basic strategy isn't complicated

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.

Hope everyone had a good Thanksgiving weekend! I took a break last week to spend time with family and recharge, but now I’m back. Despite layoffs in the industry, dbt Labs continues to hire. Here are all our current job openings. If anyone is interested, feel free to ask them to apply through these links and/or reach out to me.

LET’S BE FRANK

A big part of this newsletter is about being transparent and honest. I feel that many security folks have become less direct, which might be happening for various reasons. However, I strongly believe this attitude is detrimental to the community as a whole. Security is one of those fields where being direct and precise can be the difference between a minor incident and a full-blown issue.

Anyway, in this newsletter, I’m going to discuss why I believe security is easy. Too many CISOs and heads of security complain that security is hard. I get it. You want more resources, and you want to say that it’s difficult to prevent an incident. However, security is no harder than any other software engineering discipline. Of course, an organization can mature various security programs they have, and as these programs mature, they will face more complex issues. With maturity, the ability to handle complexity improves.

My hot take for this week is that there is nothing inherently unique about security that makes it harder than other disciplines. Unfortunately, many security professionals use FUD as a way to achieve some agenda. Usually, this agenda involves getting more resources for the goal of having more resources. The basic components of a strong security program aren’t hard to build, and I will discuss below why these components aren’t hard to achieve even with limited resources.

Full prevention is impossible to achieve

This is pretty self-explanatory. The security industry has converged that nothing is fully preventable, and hacks/incidents can happen even for the most prepared. There is a business risk in trying to achieve full or even high prevention rates. For example, if you didn’t do any business, there would be no incidents! That’s not practical, but full prevention starts to create business and execution risks.

The security leader needs to set this expectation for the leadership team, especially if the executive team does not have a lot of security experience. So, if you can’t prevent everything, what can you do? Below, I describe two key tactics: solid incident response and methodical risk mitigation.

Mitigate the highest risks

It’s important to identify the highest risks in the organization and determine the effort and resources needed to resolve them. A leader should be clear about the impacts of these risks and how they can affect the business. It’s ok to take on some of these risks if there are limited resources or if they might affect the execution of key projects. There are security tools that you can buy to recognize these risks across an application and infrastructure. The product security risks are a bit trickier because they require some understanding of the business logic in the application.

Regardless, it’s likely that the initial “high-value” risks are related to identity and access management (IAM). The data speaks to this very clearly as over 80 percent of breaches are caused by leaked credentials. In most early organizations, this is low-hanging fruit, and spending time getting a clear IAM story is definitely worthwhile and can substantially mitigate risk. Another low-effort way is to install application and code scanning to detect high-risk vulnerabilities that might be easy to fix, such as package upgrades and dependency upgrades.

This is also a continuous process. As you mitigate risks, other risks that were put on the back burner will now be elevated, and you can dedicate time and resources to those.

Create a solid incident response plan

As described above, full prevention is an unrealistic policy, so an organization should be able to effectively respond to a security incident. Security incidents aren’t black and white. Many times, security events escalate into more serious incidents as a result of poor decision-making during incident response or just bad incident response preparation. There doesn’t need to be an incident response team, but there needs to be a solid incident response plan. Something as simple as this PagerDuty one adapted to your organization can provide some structure in a time of crisis.

Having one can help you identify gaps in your logging and certain response capabilities. I know many people dislike tabletop exercises, but early on, they can be a good way for a third party to identify some obvious, easy-to-fix gaps. It has to happen for compliance anyway so might as well use it to accomplish some simple goals.

Finally, it’s important to have a retainer with an external incident response firm. Even large companies have these retainers, and they can provide useful external counsel during an incident. These firms also typically provide training services that help you identify some basic gaps. Like other risks, it’s important to address some major gaps in incident response, but having one with some gaps is better than having none and makes it easier to incrementally improve the program.

Use security tools for critical infrastructure

I’ve written a bunch of posts (too many to even link) that I believe the cybersecurity market is bloated. However, many mature tools can help monitor and improve security in key infrastructure. For example, some tools can help detect unauthorized access or make access control much simpler and cleaner for your organization. I would encourage the use of these tools earlier on to ensure that you have some basic visibility into your environment in an automated way.

Fulfill compliance as efficiently as possible

One of the biggest mistakes a company tends to make early on is to focus too much on compliance because customers want certifications like SOC2 and ISO. Those are important, but it’s a distraction to focus too heavily and/or place too many resources into compliance requirements. Ultimately, they are a checkbox, and many of the controls don’t improve your security posture. These certifications are necessary and important, but you should try to achieve them as efficiently as possible so that you can focus your limited resources on more important security risks.

Conclusion

Doing the basics of security is easy. Although the strategies and framework above need to be slightly adapted to each organization, they aren’t complex or difficult to implement initially. No one should get “stuck” in their security strategy early on. It’s just a matter of execution.