C2 Corner: Security as a Product

When Chris invited me to write for the C2 Corner, I was just about to head out on our annual family vacation to coastal Delaware. Where the access ramps meet the sand at Bethany Beach, you will find that most effective of preventive control: umbrella rentals. This "shade as a service" vendor offers a clear value proposition: "protect your skin, rent an umbrella." Looking across the beach, you will see countless umbrellas offered by this vendor in a postcard-perfect scene. In the cybersecurity world, this level of voluntary preventive control adoption would be a miracle. But the strategy is straightforward: offer a product, be visible, make the value clear, and find common ground with your customers.

Deploying and managing your security controls is more difficult than renting shade, but the same rules apply: go where the value is, and align your controls with how your customers experience risk. Employees of your organization are the primary consumers of your security program - that's your product - because the controls are usually established around their workloads.

Over the course of my career, I have seen the steady pressure applied to cybersecurity organizations to shed the (often accurate) perception that the security team is the "department of no," and evolve into the "department of how," with a grounded emphasis on strategic risk management as opposed to a default risk avoidance posture. I see less discourse on strategies or frameworks to actually make that shift happen, but opportunities well-grounded in research are worth unfolding here.

Security as a Product, Not an Edict

Many practitioners and security leaders will enact their charge like an edict: "forsooth, these controls are deployed to protect the business, and we shall have them in place" - the organizational variant of "because I said so."

I encourage practitioners to shift to a product-oriented approach. "Here's the risk. The sun can seriously harm you, and here is how we know. Luckily, we can prevent that harm by deploying this control. We will manage the control for you and measure its effectiveness. If it isn't working, we'll improve it or find another path."

At a previous role, my organization had a surprisingly high incidence of malware on removable media (USB drives). As a result, we disabled mounting of removable media on endpoints via our EDR tooling. We knew this would be unpopular, so we took the product approach. We conducted internal research to determine how many employees actually needed to use removable media, and why. We then set up an offramp for those employees and set up an approval flow for the use of removable media for circumstances like conference speakers. We clearly defined the problem and presented the evidence to the company in plain English. Were people thrilled? No, but they did accept our decision in good faith and without resentment.

Your responsibilities as a product owner extend beyond control deployment. A product that people do not want to use isn't a good product. Fostering empathy, a culture of blamelessness, and visibly celebrating wins serves as a worthy investment in leadership capital to be accessed in the unfortunate times where we really have to say "no."

Supporting Frameworks: From Subjugation to Collaboration

Practitioners have made progress in moving away from the "department of no" and into a role where security teams can drive and bring real value, but many of us are still on the journey to a product-based approach. Early controls were deployed to teams, regardless of whatever impact the control had on their work, or if it was one of a hundred endpoint agents or authentication flows that was mostly security theater, or where the value just isn't evident to users.

Right now, we're in the middle, where controls can be built for teams. Secrets detection, for example, is a useful technical control for business data, but it also protects employees from their own mistakes. Accidents happen, which is where we can control the narrative: the detection is a product feature. When paired with a culture of blamelessness, an engineer stopped by a detection will feel relief, not anxiety.

Strive for the next step: build your security program with teams. "Security is everyone's responsibility" is a common refrain among practitioners, but I rarely see it put into action that rewards rather than penalizes. Your employees should have a stake in the outcome, and they should have the opportunity to shape that product into one they want to use. Resist the urge to use "well, they'll be forced to use it anyway" as a lever here, and instead explore two product-first ways of thinking.

The first is the "jobs to be done" framework, co-invented by Clayton Christensen and Bob Moesta. Your business is hiring your security program to perform a role, so consideration for both what the business is doing and how your security product can help them do their jobs can result in strategic and operational wins. You need not follow the framework to the letter, but consider its principles.

The second is a Scandinavian theory of collaboration called participatory design, which focuses on an iterative and diverse design process where users are encouraged to advocate for their needs. While we can't accommodate every desire our teams have as they relate to control deployment, where we can't fully meet a need, participatory design leads us to make meaningful and informed product compromises.

Shaping Your Product-First Approach

These are not ineffective platitudes I learned about in graduate school. Leveraging the jobs to be done framework and participatory design together informed a zero trust network access (ZTNA) implementation project I executed in 2024. We made the problem large, the risk visible, and the benefits clear. We listened to employees, gathered feedback, and knew how to defeat existing pain points while simultaneously enhancing security. Hearing the SVP of Engineering at the time say that the new solution was "way better, faster, and easier" than the old VPN-based solution was a highlight of my career.

Before I wrote this piece I looked at the other entries in the C2 blog, and they reinforced a theme I have seen across my now 19-year career in technology: the technology is not the hard part. The technology is easier to use and the tools are more effective than they've ever been. Organizations have noticed: the bar is higher for security practitioners and teams to evolve into generating more value and business alignment. Here's some career advice: in broad strokes, a career is always smoother when you are where the value is, whether you're deploying umbrellas or ZTNA.

In security, finding the value and optimizing for it is challenging, moreso than looking good on a beach and selling umbrella rentals. Since I am half Irish and would not look good on a beach selling umbrella rentals, I have to try to solve the cybersecurity problems in front of me, and luckily the problem - mitigating the risk - is similar. Security has profound impacts on the day-to-day operations of the business, and these impacts can coexist with offering a compelling product.

Offer the product teams would want to choose.

Joseph McMahon is a cybersecurity architect and engineer with almost 20 years working in tech across private industry and government. He holds a CISSP and a Master of Information technology from Virginia Tech with a specialization in cybersecurity leadership. When not working, he can be found traveling and spending time with his family.

‍

Chris' Note:

One of the goals of C2 Corner has always been to give experienced practitioners a place to share lessons they’ve learned in the real world. Joseph’s perspective is a great example of that.

One point that especially resonated with me is the idea that security teams should think of themselves as building products, not just enforcing controls. The best security programs don’t succeed because people are forced to use them. They succeed because they’re designed around how people actually work and because the value is obvious.

We see the same pattern every day at Abstract. Whether it’s reducing unnecessary data, simplifying detections, or helping analysts spend more time investigating instead of managing infrastructure, the organizations that get the most value aren’t just deploying new technology. They’re removing friction for the people responsible for defending the business.

Joseph’s article is a reminder that good security isn’t just about stronger controls. It’s about earning adoption, building trust, and solving problems in a way that makes security an enabler instead of an obstacle.

Thanks to Joseph for contributing to C2 Corner and sharing lessons that every security leader can apply.

— Chris Camacho

‍

‍