Community
User resistance is feedback, not defiance
I was at a conference last week in Nashville and on a panel about AI security in Boulder the week before, so this week’s post is a wee later than I had hoped for. While I’m quite domestic by inclination at both events I was reminded about the power of community and really energized, which inspired this post.
There’s a kind of poetry that emerges when we discuss relationships, trust, and human systems as living things rather than mechanical processes. I’ve written elsewhere about how cybersecurity professionals might benefit from viewing their organizations not as hierarchies of power represented by an org chart, but as dynamic webs of influence and personality. Like any living being, our communities are more than an aggregation of individuals. Our role is to guide and sustain that whole - while recognizing that some of our most effective levers of influence operate at the smallest, most human scales.
This post expands on an idea I raised earlier about developing a posture of community as part of our broader strategic framework. Recall that I defined our goal as a discipline: to establish a strategic posture based on knowledge, visibility, and community. The more I reflect on this, the more I’m convinced I need to expand that list - a topic for a future post - for now I want to expand on ‘community’ and try to provide some more practical guidance on how to attain it.
By “community,” I mean not only the people who make up our organization but also their interrelations - essentially the organization’s ecology, defined by both its interconnectedness and environment. The first step along this path is to recognize that our traditional demographics are a poor lens through which to view our organizations: we have staff, faculty, alumni, and of course students1. But the alignment of these categories with almost any single dimension (e.g., risk, knowledge, or expertise) is at best weak and at worst entirely absent.
Compounding our challenge is that we have been regularly trained to distrust end users. We’re surrounded by examples suggesting they are poor stewards of digital information. We’re regularly cleaning up sensitive data spills, from data stored insecurely, placed in unlicensed cloud services, or shared with commercial versions of popular software. Not to mention data stored in protected services but with overly promiscuous access rights. All of which erodes our ability to remain empathetic and cultivate trust.
The poor fit of our traditional demographic categories, together with our learned distrust, is highly constraining. Rather than developing a holistic model of our community, we remain entirely reactive. Too often I’ve seen a disproportionate response to service misuse - shutting off all the water to fix a dripping faucet. We see that spreadsheet of patient data leaked through email, and we clamp down on using email to share sensitive data. We struggle to perform forensics on student information shared from DropBox so we launch a campaign to encourage use of our sanctioned equivalent. I fear that by and large these efforts are counterproductive: they push users outside of our ecosystem of services into the ones they prefer, and thus out from under our span of control2. These reactions may temporarily reduce risk, but they also reinforce a posture of control rather than collaboration. If our goal is to build a posture of community, we need to move beyond reactive containment toward a model of engagement—one grounded in trust, empathy, and shared purpose.
If our traditional demographics are poorly aligned with cybersecurity needs, we need to find alternate ways to segment our population. Let’s first consider the idea of agency within our community and how to enable it. Can we simply allow users to self-select where they sit on the spectrum from master to novice? And what are the dimensions of that spectrum? Some users may be extremely sensitive to issues of cybersecurity but utterly helpless as to the correct practices they should adopt. Others may confidently engage in strong cybersecurity practices but be naïve about the risks from scams. Few understand cybersecurity beyond a few well publicized practices and have no idea how to articulate it in other dimensions (such as ordinary business processes). This diversity of users can lead to overwhelming demands on the team building training or awareness content.
While self-identification by users carries some risk, by allowing them to choose their own journey you fundamentally establish a relationship built on trust. It asks an individual to reflect on their own level of expertise and consequently make an attestation about themselves and their ability to practice effective cybersecurity3. Thus we’ve changed “oh crap, I have to sit through this canned course” to “what is it that I believe I need to know?” The individual shares in the accountability for what they’re about to engage with, shifting the directionality from merely receiving to actively pulling the necessary information. Surely shared decision-making is intrinsically collaborative4. Finally, even if it remains an external compliance requirement that everyone sit through some training, by allowing individuals to choose the shortest and most optimal training, you’ve now made a gesture of respect, respecting both their agency and their time. Trust develops through the aggregation of small gestures, so why not open with one?
User-driven segmentation can bring structure to your community, but the implementation challenges remain substantial. How do you balance self-selection with compliance? How do you measure effectiveness? What does ‘minimal viable training’ actually contain? My inclination would be to abandon the simple metric of ‘percent of population that’s completed training’ and move towards outcome driven metrics. Perhaps ‘percent of population involved in a user mediated security incident’ would make more sense. Naturally one should pay close attention to the usual engagement metrics generated by your communications tools.
With regards to compliance, to some degree your hands are tied. However you can allow any mandatory training required by, say, a funding agency or research partner to substitute for institutional requirements. Don’t get wrapped around the axle by comparing the content and mandating training to fill gaps. The strength of the trust you’re building with your community is far more important than being a stickler over details.
Of course, now that you have this multi-dimensional beast laid out with fuzzy boundaries and conflicting abilities, you need to feed it. Many of us have gone down the road of identifying those who have an account compromise, or fall for a phishing email (whether real or internally generated) and then target those users with some form of required training. For some segment of the population this seems reasonable, but I have trouble seeing beyond the punitive nature of doing this - usually known as ‘the beatings will continue until morale improves’ approach.
But if we’re interested in having a community that’s aware and prepared, focusing on only the points of failure does nothing for the vast majority of members. Remember, once everyone has self-identified their own cybersecurity profile, you now have the information you need to enrich your communications and training plans.
So what would it mean to view your community holistically w/regard to security awareness and training? My philosophy is that we need to move from “users are the weakest link” to “users are adaptive agents in a poorly designed system.” This leads me to the following list of organizing principles for a community building program.
The core principle is that not everyone’s the same. Thus, not everyone should receive the same training or communications.
Segment users intelligently. People don’t mind some information or training if they recognize the need for it. We’ve started down this path through self-identification as discussed above.
Demonstrate empathy. View user resistance less as recalcitrance, than as a problem with your service. People choose weak passwords because passwords are awful to manage and use. User resistance is feedback, not defiance.
Enablement is key. Recognize that most things can be done with appropriate security - even sending a file of sensitive data via email5.
Be relevant; security learning decays rapidly when detached from context. Focus on providing training related to commonly executed tasks. This implies you know what people are doing that entails risk.
Think about timing. Training should largely be delivered on demand (just-in-time training).6
You’re training humans, so be sensitive to tone. Training should never be punitive.
How we do something matters. For example, gamification is often condescending and embarrassing when directed at mature adults. A cute chatbot name (SecurityHulk) isn’t something most senior faculty really want to interact with.
When I first began thinking about awareness and training from this perspective, I was really focused on two elements: using a chat tool to deliver training snippets on demand and tailoring communications around security events in the popular press. Because our communicative impact often pales in comparison to public media, I believe we’re best off riding the coattails of what’s happening IRL.
I wanted to develop a library of text and video snippets demonstrating a modest number of secure practices. My hope was to offer them as a collection which individuals could choose from as desired; one’s annual training requirement would be met by completing some minimum number annually. We were unsuccessful at delivering on this vision for several reasons - the lack of skilled staff to produce content and an inability to obtain permission to substitute our content for the officially sanctioned material. Even more challenging, I found my staff spent far too much time polishing each video snippet; the notion that we might need to be nimble got lost in the desire to produce polished artifacts.
That was then. Today the landscape has shifted dramatically with LLMs having created a new world of content production7. Simply asking Gemini, Claude, or ChatGPT how to securely send a file via email results in incredibly accurate and helpful answers. Combined with light training, it’s easy to see how these tools could power the library I dreamed of in the past. As to communications, I imagine we’d mimic the subscription model so much online media uses: allowing users to choose topics of interest and frequency of message (and perhaps medium) then tailoring the content to their interests and skill level.
You can see how much commitment this requires. We need to understand how services are used; this probably means generating a use case inventory for each service. We’d need to devote time to tailoring messages for different segments of our communities based on self-reported skill and awareness levels. Critically, rather than fighting our services, we’re going to have to make peace with their use in ways we’ve traditionally shied away from.
Yes, this approach requires real investment - understanding how people actually use services, tailoring content to their context, and embracing a flexibility we’ve often resisted. But this strategic investment is exactly what it means to build a posture of community. The question isn’t whether we have time for this level of engagement, but whether we can afford to persist with approaches that alienate the very people we need as partners in security. Trust, like security itself, is built iteratively, through sustained attention, humility, and shared effort.
This is plainly higher education-esque, though I suspect much of what I’m going to argue throughout this post is relevant for commercial organizations as well.
I do recognize that more often than not our responses are dictated by organizational leadership trying to actively demonstrate how serious they take a breach. The need for this performative management action speaks volumes about how poorly they trust in the general program of cybersecurity and privacy management. But reactive executive mandates are no substitute for sustained institutional commitment.
The core challenge to compliance is the evidence base itself. Security training has been widely shown to have little or no statistical correlation with security outcomes - a fact we confirmed internally with our own graduate research. If traditional training is ineffective, asking individuals to simply attest to their level of expertise may be the only viable mechanism for demonstrating an ‘aware and prepared’ community to compliance bodies.
To be sure, this is a fine line. The cynical will say you’ve just asked them to choose their instruments of torture.
It’s rare that a service deployment project includes an analysis of what skills a person needs to securely use the service. It should - and then be followed by a focused campaign of providing training on those skills.
You might note that this implies an instrumented environment. You need data on user behavior to time interventions effectively.
I’m torn about this comment. On one hand I see LLMs as a revolutionary way to tailor messages to a heterogenous population, not unlike targeted marketing. On the other using LLMs in this way seem to counter my deeper philosophy that we’re trying to establish a relationship based on trust. Perhaps we allow users to select a ‘customize and enrich with AI’ checkbox when setting communications preferences helps thread the needle?